Promo Two weeks ago, we published the The Register Guide to Windows Server 2012 as a free ebook.
To date there has been about 6,000 downloads, which is cool. To give you a flavour of the book, co-written by Trevor Pott and Liam Proven, we are republishing two extracts - but to read it all you need to get downloading.
Here, is the first extract, a chapter on Windows Server Licensing 2012.
There are only two full-feature editions of Windows Server now - Standard and Datacenter. Standard allows you to run two virtual instances and one physical instance on up to two CPU sockets. Datacenter allows you to run unlimited virtual instances in addition to the physical instance, again on two sockets.
If you have more than two sockets in a server, you must buy additional licences. You cannot divide server licences to use a single licence across two single-socket servers, but you can "stack" licences on a single machine. If you are using Standard and want to run more virtual instances, you can add more Standard licences on the same machine to bypass these limitations. The break-even point on Datacenter is five-and-a-half virtual instances, which means if you are going to run more than four virtual instances of Windows Server, get Datacenter.
It is important that you license your servers not according to how many virtual instances they will have on average, but according to the maximum possible instances they might be required to carry.
For instance, if you are creating a cluster of two single-licenced Windows Server Standard systems, then you should only run one VM per node. If you are forced to evacuate one node onto the other and moved two VMs off of the first server onto the second - which itself was already hosting two VMs - your second Windows Server Standard system would now be hosting four virtual instances and be out of compliance.
WS2012 still requires user and/or device CALs. Remote Desktop Services (RDS) and Active Directory Rights Management Services (RMS) also require their own CALs. VDI licensing and System Center licensing are separate affairs entirely.
While System Center’s licensing has been greatly simplified compared to its previous incarnation, actually figuring out what licenses you need still requires both a spreadsheet and a cheat-sheet. Two core concepts are Operating System Environments (OSEs) and Machine Licenses (MLs). OSEs are exactly what they sound like, an instance of an operating system, virtual or otherwise. MLs can be client, or server. Client MLs can be thought of as "per device CALs," though Microsoft doesn't use that terminology.
Server MLs are "per processor socket licenses", except that Microsoft now licenses in packs of two. This makes sense; the overwhelming majority of servers deployed are 2P systems. You can combine server MLs on a single system; two server MLs gives licenses for four processors allowing you to properly license a 4P system when a specific 4P ML doesn't exist. You cannot split a server ML; no licensing two 1P systems with a single server ML.
Datacenter allows you to run unlimited OSEs, provided you have enough MLs to cover your socket count. Standard allows you 2 OSEs; the break-even point for getting Datacenter instead of Standard is at 7 VMs on a given host. Compare and contrast with Windows Server above. The same basic principle applies: Standard equals 2 two virtual instances. The break-even point, however, is different.
System Center 2012 has three different client ML packs: Endpoint Protection (SCEP), Configuration Manager (SCCM and SCVMM) and the Client Management Suite Client ML (SCCM, SCOM, SCDPM, SCO). If you use the Core CAL Suite, it includes the Configuration Manager and Endpoint Protection Client MLs. The Enterprise CAL Suite Includes all three System Center 2012 Client MLs.
If System Center licensing required a spreadsheet and a cheat-sheet, to truly understanding VDI you’re going to need a young priest, an old priest and possibly a bottle or six of scotch. To start with, VDI has a few different flavours.
The first is Remote Desktop Services (RDS) - otherwise known as Terminal Server - in which multiple users log into a single Windows Server instance. With the new Fair Share feature and a lot of the enhancements to RemoteFX in RDS, this is a method worth considering if only for the simplicity of it all. You licence the appropriate number of Windows Server virtual instances to host the number of users you require, you buy a Windows Server CAL and an RDS CAL for each user and you’re done.
The extension to this is that you can give each user their own virtual machine by simply buying a Windows Server Datacenter license and spinning up one Server VM per user. This method was popularly considered a neat way to sidestep the byzantine complexity that Microsoft’s Vista/Windows-7-era VDI licensing was, as WS2012 allows two administrators to connect to the operating system without needing RDS installed.
Microsoft has explicitly forbidden this approach; if you are using instances of WS2012 as individual VMs for your users, you must get an RDS CAL for each user. Unlike the traditional RDS approach, however, your users can have their own VMs.
Microsoft’s official stance is that VDI is best done by using a Windows Client operating system. This is where things get dark. The intuitive licensing approach - buying a copy of Windows XP, 7, or 8, installing it in a VM and letting your users have at it - is explicitly outside of compliance. As soon as you put Windows Client inside a virtual machine - or remotely access a physical machine through RDP - you must licence the client device as well.
There are some basics to VDI licensing for Windows Client operating systems to know. Microsoft offers a licence called Virtual Device Access (VDA) which costs $100 per year. It is available only through volume licensing; signing a volume licensing agreement means agreeing to have Microsoft audit you each year, so make sure you have your ducks in a row. VDA licenses apply to client devices. Windows endpoints covered under Software Assurance (SA) have VDA rights and so do not need to pay this fee.
A single Windows VDA license allows that endpoint to be RDPed into a maximum of four Windows Client instances simultaneously. You must hold as many VDA licenses as you have thin clients and non-SA-covered endpoints accessing the VDI environment.
Extended Roaming Rights are another critical concept. Any device covered under VDA or SA allows the user to access a Windows Client from up to four x86 devices, so long as those devices are outside the corporate firewall. This is designed to allow users to access their work PC from home, or a personal laptop.
If that personal device - the canonical example is the personal Macbook - is brought into the office, then it is considered part of the work environment and must be covered by VDA or SA.
To summarise: if you have a PC at work covered by SA or VDA then you can access up to 4 VDI instances of a Windows Client operating system. You can use up to four computers not owned by the company outside of the corporate premises to access those same VDI instances. If you stop using your Macbook at the Starbucks across from the office, walk into the office with it and use it to RDP into a work VM, then that Macbook must be covered by VDA or SA.
ARM devices are licensed differently. If your company covers its PCs with Software Assurance and buys you a Windows RT tablet, then you can access a Windows Client instance from that Windows RT device.
Corporate-owned iOS, Android, Blackberry or other ARM devices must purchase a Windows Companion Subscription Licence. CSLs are per-user and cover up to four companion devices. Personally-owned ARM devices - including Windows RT devices - must be licensed under a CSL to access a Windows Client operating system.
None of the above brings Intune or Office 365 into the discussion, considers diskless PCs, or attempts to explain licensing Office in a virtual environment. It is not intended to offer exacting guidance: VDI licensing can change at any moment, and making sure you get the best possible set of licenses for your deployment can involve factors beyond those discussed above. It is always best to discuss your VDI plans with your VAR or Microsoft rep.
If possible, try to get a stamp of approval from MS on your deployment before you deploy. Remember that the burden of auditing is on the business - not Microsoft - and you may be asked to verify your compliance every year. It is strongly recommended that anyone considering VDI invest heavily in automated compliance tools. You’ll need them. ®