Getting around Windows Activation when Virtualizing

VMWare . Windows XP

Scroll down to Setting up Automatic Activation to see the process if you are not interested in the background.

Background

When I first setup my VMware Server to run an existing Windows Install from a physical partition, I was asked to reactivate Windows XP before I could use it as a guest OS. All this required was to enter the product key, request verification and within a couple seconds everything ran fine. I received a lot of complaints from people saying that they were then again asked to reactivate Windows again once they booted back into Windows natively, and then again under VMware and so on every time the OS was booted in a different environment. I wasn’t sure what to tell readers and a web search brought up an endless number of forums with the same problem but no answers. My favorite answer had to be this one from a Microsoft tech saying “Running a virtual machine counts as running two copies of Windows”. Really? Maybe he should have read the user’s question more carefully. Regardless, I couldn’t really help since I couldn’t reproduce the problem.; that was until I upgraded my hard drive this week.

I found myself experiencing the same problem others had mentioned; I would boot natively and be asked to reactivate, it would work fine until I booted the VM and was again asked to reactivate. Remember that WPA (Windows Product Activation) typically allows you to reactivate twice through the internet and after that it requires you to call in. This meant that I was calling up MS every time I wanted to boot in a different environment; hardly practical considering it takes 10 minutes each time activating over the phone.

Reading up on WPA I learned that there are two files used to store the hardware info along with WPA data, WPA.dbl and WPA.bak (These files reside in C:\Windows\System32). If you go through the activation process in Windows natively as well as under VMware you will notice that the file size changes each time you reactivate. This means that if you replace the WPA files prior to booting based on whether you’re using VMware or booting natively you won’t have to reactivate. You will have WPA files for your native hardware and WPA files for your virtual hardware, just swap prior to boot.

I set out to write a script in Linux to perform this but ran into a much simpler solution that a Mac user developed. Linux users can follow the steps below to achieve the same results.

Setting up Automatic Activation

Step 1:

Boot into Windows XP natively. You will be prompted to activate your copy of Windows (if already activated, skip activation and just copy the files). Go ahead and reactivate your copy, this can be as simple as doing it through the web or going through a 10 minute phone call with Microsoft’s automated machine. Once Windows is activated:

-Navigate to C:\Windows\System32

-Create a new folder and name it “nativeboot”

-Copy and paste wpa.dbl and wpa.bak from C:\Windows\System32 into the new “nativeboot” folder

Step 2:

Boot into Linux. Run VMware and boot into Windows XP. You will be prompted to activate your copy of Windows. Go ahead and reactivate your copy, this can be as simple as doing it through the web or going through a 10 minute phone call with Microsoft’s automated machine. Once Windows is activated:

-Navigate to C:\Windows\System32

-Create a new folder and name it “vmware”

-Copy and paste wpa.dbl and wpa.bak from C:\Windows\System32 into the new “vmware” folder

Step 3:

You now have a copy of the WPA info for both your physical and virtual hardware! The next step is to guide Windows to use the right set of files when booting. The easiest way to do this is to setup a script that will be run when Windows boots:

-Open Notepad

-Copy and paste the following code:

@echo off

ipconfig /all | find "VMware" > network.tmp
for /F "tokens=14" %%x in (network.tmp) do set vmware=%x
del network.tmp

if defined vmware (
  echo VMware
  copy C:\\Windows\\System32\\vmware\\wpa.* C:\\Windows\\System32
) else (
  echo Native Boot
  copy C:\\Windows\\System32\\nativeboot\\wpa.* C:\\Windows\\System32
)

-Save the file as “activation.bat” in C:\

-Go Start>>Run>>gpedit.msc>>[enter]>>Computer Configuration>>Windows Settings>>Scripts>>Startup>>Add

-Choose “activation.bat” as the script to add.

Done!

Windows should now automatically choose the right WPA files and not require activation as you restart or change from physical to virtual hardware.

Additional Thoughts

Nevertheless, the fact that users need to go through this process to get their systems working is beyond stupid. WPA has in no way eliminated piracy and problems like this many times lead users to ditch legal software and go the route of pirated software which isn’t infested and crippled with WPA. It’s clear that Microsoft did not foresee these problems and still fails to address them. The fact that a call to MS tech support will result in them telling you that you will need two copies of Windows when virtualizing shows a lack of understanding as well as a lack of a clear solution. Even if you were to pay MS an additional $300 you would still be where you started if you are trying to virtualize a physical partition, you would just be out $300. This is because each copy of Windows can only handle one WPA file and can only be installed on one PC. When you switch environments, WPA thinks you are completely changing computers and requires reactivation. MS will try to tell you that virtualization requires two copies of Windows and that you are violating the EULA by virtualizing the same copy. THIS IS NOT TRUE. You only installed Windows once, it’s all the same set of files, and you’re still technically running it on the same original hardware since you are using the same CPU, Mobo, HDD, RAM, NIC, etc. What you are doing is not in violation of the EULA and don’t let Microsoft’s limitations in software design limit your options and your computer’s functionality.

Share this...Tweet about this on TwitterShare on FacebookPin on PinterestShare on TumblrShare on StumbleUponShare on Google+

Leave a Reply