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.
2 Comments
One more thing to watch out for…on the repair…your Internet Explorer Browser version will revert back to the version that is associated with the original Windows Server 2003 CD. In our case, we reverted back to IE6. And you can imagine that in an evironment where it was expecting to have IE8, IE6 did not work. We’re going to install IE8 and that should bring back web browser functionality to the Web Server box.
I mentioned that you’re going to want to perform a Windows Update. If you do this, you might experience error 0X8007043B. We’ve found that this means your BITS and WUAUSERV services aren’t running. BITS is .NET Framework 3.0 installation. And WUAUSERV is required for Windows Update.
That problem can be resolved, we found, by updating registry key:
HKEY_Local_Machine\Softare\Microsoft\WindowsNT\CurrentVersion\SvcHost
double-click the netsvcs key
under Value Data
Add BITS and WUAUSERV to the list of services
Click OK
Exit
Restart the system.
This allowed Windows Update to work. We’re going to download a whole bunch of updates before we try again to install .NET Framework 3.0.