SQL Server’s licensing guidelines are long and complex – yet organisations seem to suffer from the same few pain points.
A CIO recently asked me why SQL Server’s licensing rules were more complicated than using the product itself. Despite his suggestion, it’s not to keep companies like Coeo in business! SQL Server is a versatile product. Its licensing guidelines have to cope with both the smallest single server deployments and global, enterprise-wide environments. Organisations can use it in standalone configurations or complex multi-site and highly available solutions. It’s also a product in a highly competitive marketplace. A single sentence in the licence agreement can cost – or save - large organisations millions.
Despite its complexity, the organisations I work with always seem to misunderstand the same few sections of SQL Server’s licensing agreement.
Virtualisation use rights
According to Gartner, almost every server deployed today is virtual. This includes database servers. One of the benefits of virtualisation that organisations like is being able to move virtual machines between physical host servers. While transparent to the SQL Server services, Microsoft put restrictions on how often system administrators can move a virtual machine with SQL Server services.
Without Software Assurance, you can’t move a virtual database server very often. Software Assurance also brings the maximum virtualisation use right, where if a host server has all of its physical CPU cores licensed for the enterprise edition of SQL Server then it can host an unlimited number of virtual machines containing SQL Services. While I don’t sell licensing, I always recommend organisations who use SQL Server in virtual environments without Software Assurance make sure they’ve got a very good understanding of the licensing rules.
Failover server rights
Only very recently, a DBA told me you only need to license the instances of SQL Server that users connect to – passive failover cluster hosts and DR servers don’t need licensing. This is incorrect and a common cause of insufficient licensing.
Today, when you have the Software Assurance licensing addition you can deploy a failover server for each licensed server you deploy. That failover server could be a passive failover cluster host or a server hosting Availability Groups secondary replicas, database mirroring mirrors or log shipping targets. Whichever technology you use, you can only deploy one failover server for every licensed server.
Deploying a version of SQL Server newer than the licence you own is a benefit only available with Software Assurance, which is an annual subscription. These upgrade rights only exist when that subscription is being paid – otherwise organisations have to rollback to the version their licensing paperwork is for.
Again, I don’t sell SQL Server licensing nor do I write the licensing rules. I can only help organisations interpret and apply the licensing rules for SQL Server. However, I make sure that if an organisation begins using their upgrade rights, they need to have strategically agreed they’re going to commit to Software Assurance for the next few years. A decision to stop paying for Software Assurance means downgrading to the earlier version of SQL Server originally bought. I’ve never heard of anyone downgrading their database server.
As my friends in the US Air Force would say, I’m not a lawyer but I have stayed in a Holiday Inn. How an organisation manages its SQL Server licensing are legal as well as operational decisions – Coeo can only advise.
For a more official definition of SQL Server’s licensing guidelines please read the information Microsoft publish here. Additionally, also know how your licensing reseller can work with you.