Skip to content

We’ve been busy creating a test environment for a client, in order to test several software upgrades.

We have a domain controller, a database server, and a web server.  We’ve brought the environment up in Windows Virutal Server 2005; and everything pretty much works except SharePoint.  Of interest, all three servers have OEM licenses in the live environment.  (These servers were procured without Volume Licensing, prior to my watch.)  Well, we’ve run into an issue with activating one of the servers in the test environment.

There are several issues to be aware of here:

  • Activating an OEM-licensed server on different hardware could be challenging, and here’s why.  An OEM version of software “lives and dies on the machine on which it was orignally installed.”  The OEM licensing model does not permit the movement of the software to other hardware / machines.  If you are able to move the OEM-licensed server image to another machine, and re-activate it, it’s because the profile of the new machine did not trigger the “dissimilar hardware / machine flag” (my terminology).  If you do trip the dissimilar machine flag, then there’s two ways to get around the re-activation problem: 
    • Method 1 – you have to “repair” the re-installed server software on the new machine with the same server operating system disk that you originally installed the software with, and then you can re-activate with another (different) OEM key.  You would have to get the other OEM key from your OEM (Dell, HP, etc.). 
    • Method 2 – if you don’t have the original installation disks, you can “repair” the restored server with, say, a volume-licensed copy of the server software, and then enter the key for the Volume-licensed software. 

In either case, you should be aware that you may lose certain critcal software / updates during the repair process.  This is what we’ve experienced.  We found that SharePoint would not work in the restored environment.  We also noticed that the C:\WIndows\assembly folder was empty!  The solution to this is to un-install the .NET Framework from the top down (uninstall most recent versions first, then un-install the rest of the versions, one-at-a-time, in reverse chronological order — that is, from most recent to oldest.)  Then, you need to re-install from oldest to newest.  Lastly, you may have also lost post-Service-Pack Updates, (for example, if your server was Windows Server 2003, SP2 with additional updates after SP2); so you’ll want to re-install those post-SP2 updates.   

We’ve been struggling with this problem, and feel like we finally have information that makes sense.  We got lots of pieces of partial information along the way (like: “It can’t be done.”); and am now pretty confident that we have answers that make sense, and are off  ̶  hopefully  ̶   to implement this approach.

Drop us a note

Please drop us a note via the form below with your comments or questions on this blog post; or if there is anything we can help you with.