The trouble with server audits is that they are incredibly complicated. It is very easy to fall foul of your licensing agreements indeed, many organisations are not even aware that they are not compliant. Most of us have been through a desktop audit so we are a bit more familiar with these. Those of us that have been through a server audit will know just how painful, time consuming and expensive these can be.
Desktop versus server audits
So, what are the differences between these two types of audit? When auditing a desktop or laptop it’s pretty straightforward in that generally one install requires one licence and it’s simple to compare audit data to licence documentation. With a server audit you also need to collect a multitude of server requirement and liability data as well as licence and contract data, but the complications come from the huge amount of different licensing models.
For example, requirements are unique for every publisher, for each application by a publisher and even for each version and edition of an application by a publisher – and then this could differ for each customer! If you think how many vendors there are such as Microsoft, Oracle, Symantec, HP, IBM etc, and how many products each offer, this means thousands of distinct licensing requirements that standard discovery tools just don’t recognise.
What are the common causes of non-compliance?
There are a multitude of issues impacting on the licence terms and agreements such as: what you do in test environments, disaster recovery environments, cross country usage; so the whole situation becomes even more complicated. Even the publisher’s own specialised scripts and tools need expert interpretation.
It’s likely that you are in breach of your licensing agreement if any of the situations below apply to your business:
- You have bought an application which was country specific but have since moved your data centre to another Country? It’s possibly not an obvious link between changing location and server compliance – especially if you have had the server licence for years and don’t know all the terms and conditions off the top of your head (who does?)
- You have outsourced some of your work to an external company who use your servers and software? This common practice could easily infringe on your licence agreements for many publishers – based on your existing licensing terms. Again, you wouldn’t necessarily think about compliance when implementing this change
- You have previously worked alongside subsidiary companies and signed a Universal Agreement to use common server software? Subsequently you legally separated from this group but are still using the same servers and software – you probably won’t be covered on the Universal Agreement and would need to buy a new licence agreement
- You bought a licence agreement for a certain type of usage – for example, that named users could access and use certain server software. If you then start using the server slightly differently, say, back end data loading and automatically processing the data into the application – you may need a different licence type, such as Processor licences which can cost a significant amount of money!
Of course audit tactics vary from vendor to vendor, and not all are guilty of exploiting server audits, but there are a few notable publishers who will use tactics to squeeze more money out of their customers. There is a lot of mystique surrounding the vendor server audit, and whether intentional or not, the fines are a great way for vendors to earn additional income!
Some rely on the customer’s fear, uncertainty and doubt to insist that they are non-compliant, and usually a customer is too scared to question them. It’s also not uncommon for vendors to audit a percentage of the business rather than the entire estate, and then audit the company again a year later issuing fines for shortfalls and non-usage – the statistics to back this up are phenomenal. I often see customers breaking relationships with their chosen publishers because of the way they behave in audits – it can get pretty ugly.
It’s useful to bear in mind that you are at greater risk of a server audit if you stop paying your maintenance fees, it will raise your profile with the vendor and this is often a prompt for them to consider an audit and if you are no longer a customer – why not?
Top tips to ensure you are prepared
There are a few ways to get your IT estate in check, but it’s more important to design and implement a system where you can keep on top of your IT assets – and know when you’re likely to risk non-compliance. The key to successful server software management is:
- Be fully aware of your licensing agreements, and their terms and conditions
- Remember to check your contracts every time you change any aspect of your IT, even if it seems like a small move – this can affect your agreements and you can find that you are no longer compliant
- It is very time consuming marrying up licences with servers and ensuring that all areas are in line with vendor contracts – it’s almost an impossible task to do this with a discovery tool alone
- Do remember though that you can’t rely on your discovery tool to know the different Terms and Conditions for every vendor, product, version and edition – you must do your own research and try to keep current.
And finally, you might want to consider outsourcing your Software Asset Management in part or in whole. You can rely on experts to assess your IT estate – taking the onus off you. They will be able to explain the different terms of your agreements and offer advice when you are thinking of making any changes that may contravene your licence agreements.
Some specialists even offer a managed compliance service where they remain responsible for keeping the business compliant with regular reporting and monitoring – then highlighting any potential issues to your business. At the end of the day server audits are another revenue stream for vendors and you need to be aware that they will be looking closely at all their customers – so it’s only a matter of time before you get that knock on the door.