Microsoft Licensing and Virtualisation

Licensing is a pain in my arse. There are whole companies full of people who can tell you that you're doing it wrong. Personally I cannot stand licensing, and the only thing that I find more annoying (in this field) than the proliferation of Open Source and Free Software licenses (and figuring out what I'm allowed and not allowed to do and what is an "arms length" exactly - but thats another rant for another time), is the software licensing by Microsoft and other vendors who shall remain nameless for this article.

To try and make things easier at work two and a half years ago I put together a very small document/cheatsheet describing the licensing terms for various Microsoft products and virtualisation. Yesterday Microsoft released an updated document for Windows Server 2008 R2, and interestingly not much has changed for Window Server, with the exception of a few new products. The table below should help out a bit if you're confused 1.

Instances
Server ProductLicense TypePhysical 2Virtual 3
Windows Server Foundation (2008 only)OEM10
Windows Server StandardOEM, Retail, VL, SPLA11
Windows Server EnterpriseOEM, Retail, VL, SPLA14
Windows Server DatacenterOEM, VL1Unlimited
Windows Server WebOEM, Retail, VL, SPLA10
Windows Server HPCOEM, Retail, VL, SPLA11

I decided to check the licensing for other products, just incase I'd missed any changes. It doesn't look like it, so here the run down (as I understand it).

As a general rule, for anything per processor licensed, if you're running it in a virtual environment it will simply count the number of virtual processors you assign it.

It gets a bit complicated with SQL 2005 and newer. To quote Microsoft:

When licensed per Server or CAL Workgroup and Standard editions allow you to run any number of instances of the server software in one physical or virtual operating system environment on the licensed server at a time. Previously, only the Enterprise edition of the Server license allowed multi-instancing. When licensed per Processor Workgroup, Web, and Standard editions for each server you have assigned the required number of per processor licenses, you may run, at any one time, any number of instances of the server software in physical and virtual operating system environments on the licensed server. However, the total number of physical and virtual processors used by those operating system environments cannot exceed the number of software licenses assigned to that server. For Enterprise if all physical processors in a machine have been licensed, then you may run unlimited instances of SQL server 2008 in one physical and an unlimited number of virtual operating environments on that same machine.

As far as I'm aware anything else licensed per server doesn't currently have any special rules regarding virtualisation; so this includes Exchange, Sharepoint, and so on.

  1. It should be noted that I've only gone so far back as Windows Server 2003 for this table. I suspect that there are no particular dos or don'ts for anything older and you should probably just treat any virtualised instances as you would physical machines. If you know any different I'd love to hear it. ↩
  2. You can, of course, use the licence in a purely virtual environment. ↩
  3. On the same hardware as the physical licence. ↩

VMWare to Hyper-V Conversions

Over Christmas we had to do a bunch of VMWare to Hyper-V conversions at work. Once you've sufficiently prepared the VM, there are a whole bunch of ways you can do this, ranging from raw converting the vmdk, to mounting the vmdk and a blank vhd and then copying the contents between. We chose it as an opportunity to play with Disk2VHD from SysInternals.

If you're using SCSI disks in your VMWare VM then you will first need to ensure that you add the IDE controller driver, to hopefully avoid a BSOD when you boot under Hyper-V for the first time. Why don't you just set Hyper-V to use SCSI disks? Sadly because Hyper-V cannot boot from SCSI. Once you've added the driver and rebooted to ensure that it's stuck we simply ran Disk2VHD and pumped the VHD off to a network share.

Interestingly Windows 2003 x64 and 2008 were a lot more resistant to the change in "hardware" than older Windows versions, which needed a Windows repair, however I can't fault Disk2VHD for that as it was something I was expecting anyway.

What worried me most was that the first run we did Disk2VHD produced a mangled VHD which I managed to repair and get working by doing the following;

  1. Mounted the VHD and declined Windows offer to format the partition it could see.
  2. Extended the partition so that it filled the VHD (for some reason it had left a whole load of space free - none of the other conversions did this). I chose to use diskpart, but whatever you're comfortable with.
  3. Ran TestDisk to ensure that all was ok with the partition. In this case it threw up some weird error that I failed to note down and right now I can't 100% remember for sure if TestDisk helped or not. A chkdsk /f was definitely able to, however. After this the VHD was in perfect working order.

Fortunately all other conversions didn't seem to have this issue, and as much as I would've loved to investigate why this happened, I just didn't have the time.

Ubuntu Server 10.4 (Lucid Lynx) and Hyper-V

If you've noticed that the next Ubuntu Server version (10.4, Lucid Lynx) has the Hyper-V kernel modules packaged, alebit in drivers/staging, I'd suggest not dist-upgrade'ing even your development servers for the moment. The reason is simply that you need to devote time to ensuring that the kernel modules will continue to work with each kernel version - right now you can't seem to rely on the modules actually loading successfully from the corresponding /lib/modules/2.6.*/kernel/drivers/staging/hv directory. Which isn't a problem, provided that you have the time to deal with it.

The long and short of it is that if you're currently looking to use any flavour of Linux under Hyper-V the "old" rules still apply;

  • Use the legacy network adapter
  • Set static MAC addresses under the VM settings (unless you want to faff with udev)
  • and learn to live with the performance penalty

Windows Server 2008 R2 and CLOCK_WATCHDOG_TIMEOUT STOP errors

If you've got a Windows Server 2008 R2 box, running Nehalem based hardware you might find it handy to bookmark KB975530, which details a hotfix and workaround for CLOCK_WATCHDOG_TIMEOUT STOP errors you might receive with this configuration.

The Virtual PC Guy (Ben Armstrong) has a few more details on the problem.

Slow Relaying with Microsoft Exchange 2010

If you've got an application that sends messages via your Exchange 2010 server, using SMTP, you might've noticed that things have slowed down a bit. The reason for this is because the Exchange 2010 receive connectors have a "MaxAcknowledgementDelay" setting, that will inform you if the delivery is successful, within a certain time frame. If the timelimit is hit, it then acks the submission.

To disable this you can set your receive connector not to use this feature: Set-ReceiveConnector "Connector Name" -MaxAcknowledgementDelay 0

Further details are available on technet.