Greetings, I have a client who runs 2 different Windows 7 workstations as database application servers. These Windows 7 "servers" host line of business applications that are critical to their business functions, however they operate in very small offices, each with under 10 users. My client has requested that I P2V these 2 Windows 7 machines onto their Hyper-V server in the cloud. The process of which is no problem, my question is regarding the licensing of these machines to support virtualization. And just to get this out of the way, yes indeed I have advised them to run Windows Server instead, but I'm told the software company who wrote the database application will not support Windows Server, so I'm at a dead end there; I need to bring the existing Win 7 boxes into Hyper-V. So, the question now is this: how can I license a Windows 7 OEM workstation so that I can P2V it into Hyper-v and continue to use it as a database application server, all the while maintaining Microsoft licensing compliance? My initial research and thoughts had me thinking that I would do the following: Upgrade to retail licenses so they are transferable, i.e. not bound the the hardware on those physical machines. Then upgrade to Open License with SA in order to have the appropriate rights to run in a virtual environment. I appreciate any insight anyone can offer! Thanks Science is a way of thinking much more than it is a body of knowledge. -- Carl Sagan

It might not be so straight forward and simple. In any case, after P2V you will still have the original computer untouched. So, if you are unable to activate your VM, you may simply return to your original configuration. The best course of action would be: You prepapre Hyper-VYou prepare fresh Windows 7 VM, fully patched and activated with either Retail or (preferably)Volume Licence key a.k.a MAK.You call LOB team to install LOB.You set up permissions on Hyper-V so that LOB team can access VM, but not mess other VMs on Hyper-VYou both document your procedures; disaster recovery plan, regular backups and restores, responsibilities, escallation procedures, acceptance test.

Thank you for the reply, but I am trying to avoid setting up a fresh installation. I wish to perform a P2V migration to preserve the existing configuration. I spoke with Microsoft Licensing Support and found out that my original idea was close, only that I do not need to purchase the retail editions. I only need to purchase Open License upgrades with Software Assurance for each OEM license that I am going to virtualize. So I will upgrade both OEM machines to the Open License with SA, then perform the P2V as I normally would with SCVMM. I was originally uncertain if the OEM license becomes portable after the OL+SA upgrade, but MS Licensing confirmed that it is, with the caveat that the OEM on the original machine "dies" once virtualized; so my client will need to purchase new OEM or retail licenses if they wish to reuse Windows on either of the machines. Science is a way of thinking much more than it is a body of knowledge. -- Carl Sagan

Chris, I'm glad you got that answer from Microsoft, because I would not have given it to you. They're wrong. (They don't know their own virtualization rules, which is gratifying, since these rules are incredibly complex, and customers struggle to understand them. It's good to see that Microsoft is equally confused, although that's not news to me. Most of my business consists of unconfusing customers who have been confused by Microsoft.) If they've given you that advice in writing and you've acted on it already, you're OK. You're acting on their advice even if they're wrong. However, if you don't have it in writing, read the following. First, Windows desktop OS licenses are ALWAYS assigned to physical devices, not to virtual machines. There are only two ways to plop a Windows desktop VM on a server. The server has a full Windows desktop license (OEM is best in your case), which is installed in the VM.Every desktop accessing the VM has SA. These are independent, that is you don't need to do both. Which one you choose depends on your current licensing situation. If all of your PCs have SA on Windows, you don't have to do anything. You don't even need to buy a Windows upgrade with SA for the VM running on the server. That VM is licensed for Windows by the SA on the desktops that access it. If every desktop that accesses the VM doesn't have SA, then I'd do the following. 1. Purchase two Windows 7 Professional OEM licenses and assign them to your Hyper-V servers. You can install those instances in your VM, but you won't want to, since you're going to use a P2V image. You buy them, but you don't install them anywhere. They are simply "assigned" to the servers. I know there's language in the OEM EULA about "intended for use on a new PC" but you can ignore it. It's not a real restriction. Lots of people use Microsoft software in ways that Microsoft didn't intend, and they're happy to cash the check. Also, arguably, this is a new PC. The Hyper-V server is, from a Windows desktop OS perspective, a bare PC, that is, it has no Windows license on it. You're getting it its first OEM license and it will then be a "PC" for the first time. That gives you the right to install a copy of Windows 7 in a VM on that machine. You also save money--the OEM license is less expensive than the Open upgrade license and you don't need SA. 2. Ensure that every machine that accesses that virtual machine has either a Windows 7 Professional License or SA (if it isn't already licensed for Windows 7). If they have a Windows 7 Pro OEM license, they can take advantage of a provision in the Windows 7 Pro OEM license that says a machine licensed for Windows 7 Pro (such as the VM running on your Hyper-V server) can be accessed without an additional license requirement by any machine that has the same license. (If an XP machine has SA it is also licensed for Windows 7 Pro, so that's the reason I say it needs either Windows 7 Pro OR SA.) Note that this is true even if you take Microsoft's advice. The 10 PCs that access the database running on the desktop machine must either have SA (which gives them the right to access remote virtual machines remotely) or they need the same Windows license that licenses the OS in the VM. You can't access that VM remotely from a machine that is only licensed for Windows XP and that does not have SA, for example. You can't even do that in your current (non-virtualized) scenario.Paul DeGroot Principal Consultant Pica Communications "Solving the Microsoft Licensing Puzzle"