Cloning and Windows Reactivation

[kbrodeur]

I have a clone of a VirtualBox machine that was activated with Windows. The clone was made using Clone VDI using the generate a new UUID option. The original machine got corrupted and is totally useless but I was able to save its' vbox files. When I use this clone Windows wants me to activate it again. I've spent the last 3 days scouring this forum and the Internet trying numerous ways to bypass this reactivation but it keeps asking for reactivation. Can someone please give me clear step by step instructions on how to accomplish this? I'd appreciate any help I can get. Thank you.

[stefan.becker]

we cant help you, thats not legal to bypass. if it does not work, then use the phone activation. will be no problem, if you have a valid license.

[noteirak]

The reactivation process is part of the Microsoft licensing scheme.
If the hardware - or the IDs to be precise - change too much, reactivation will be required. This is to prevent people to move their Windows installation without getting a new license (Windows license is bound to a hardware, not to a person).

As for how to bypass it, we cannot help you, as pointed out by stefan. You will need to sort this out with Microsoft directly.

[kbrodeur]

I understand what you're saying. I know that trying to be dishonest with Microsoft is not right and that the license is bound to hardware not a person. That's why I asked this question originally. Because I'm using the same hardware (machine) on the same computer I assumed I was still in compliance. I inadvertently created a new UUID when I made the clone which I think is the cause of my problems. From my researching I thought there was a way just to copy the machine UUID from the original vbox files and virtualbox.xml to specific areas to prevent the machine from deactivating. It also looks like a person would be "out of activation" if their computer died and they wanted to use their VM on a new computer which doesn't seem right either. I do have a valid license but I've had to use the phone activation in the past and MS makes you jump through hoops and it's very frustrating. I'd probably buy a new license than go through that aggravation again. Thanks for your thoughts though. I appreciate it.

[noteirak]

To be more precise, I was refering to a copy (read hard drive moving) of a physical.computer.
Also,.they are special terms about virtualization in Microsoft licensing scheme, you should be aware of them.
For the rest, I hear you.

[BillG]

I understand what you're saying. I know that trying to be dishonest with Microsoft is not right and that the license is bound to hardware not a person. That's why I asked this question originally. Because I'm using the same hardware (machine) on the same computer I assumed I was still in compliance. I inadvertently created a new UUID when I made the clone which I think is the cause of my problems. From my researching I thought there was a way just to copy the machine UUID from the original vbox files and virtualbox.xml to specific areas to prevent the machine from deactivating. It also looks like a person would be "out of activation" if their computer died and they wanted to use their VM on a new computer which doesn't seem right either. I do have a valid license but I've had to use the phone activation in the past and MS makes you jump through hoops and it's very frustrating. I'd probably buy a new license than go through that aggravation again. Thanks for your thoughts though. I appreciate it.

Technically, a vm is not the same machine as the host on which runs. It shares the CPU, but it has its own (emulated) motherboard, mouse,keyboard, display, network card etc. The drivers for these devices are quite different from the drivers in the OS on the host, and certainly would not pass Windows activation checks as the "same" machine.

[mpack]

Contrary to what my colleagues may be saying, IMHO if you are repairing a broken VM then there is nothing shady about what you are trying to do.

If your VM is Win7 then I doubt the problem is the hard disk UUID, for confirmation read the "Which changes trigger reactivation in a Windows guest?" thread. The problem is almost certainly that you built a new VM around the cloned hdd, and in doing so you created a new VM UUID - which acts like a motherboard signature and is quite distinct from the disk UUIDs.

The cure is to remove (but not delete) the VM from the GUI, then edit the machine UUID in the .vbox file, then Machine|Add... it back. Just for added security you should make sure that everything else about the new VM is the same as the original working VM where possible: e.g. MAC address, RAM allocation size, network adapter type, disk controller type.

I'm assuming that the old VM settings file is available for reference, but of course it must be unregistered from the GUI, as you can't have two VMs with the same VM UUID.

Oh - and I'm also unclear from your original description whether this is the same physical host or not. Certain aspects of the physical host (e.g. the CPU type) is visible to the VM and may affect activation. So if you change hosts, at least to one with a different CPU, then reactivation will be unavoidable. However if your only problem was that your host was corrupted then I assume all you did was wipe the host and reinstall the host OS - the hardware will remain the same.

[kbrodeur]

Mpack, thank you. Your solution was exactly what I was looking for. I am running Windows 7 and using the VM on the same host computer. The original VM got corrupted on a hard drive that was dying. Luckily I cloned it before the drive died to another hard drive using your CloneVDI. I also had the vbox file from the original corrupted VM. You are right that I wrongly built a new VM around the cloned drive. I had tried copying the machine UUID to the new vbox file but I kept building a NEW machine instead of ADDING a new machine. I never even thought about adding a machine but looking back on all my troubles I've had with backups and reactivation problems, this makes total sense now.

I also want to thank you for your other posts where you point out how snapshots will always bite you and the importance of keeping your vbox files in the same folder as the vdi. This is sound advice.

Can you verify this is a proper and safe backup procedure avoiding reactivation problems? 1. Copy folder with vdi and vbox files to another drive. 2. If need to use backup, remove the original machine from the GUI. 3. ADD the backed up VM to the GUI.

Again, thank you for providing me with the solution to a broken VM. It appears from your comments that if I was trying to do something shady like using the VM on a different host then reactivation would be unavoidable. Thus, someone like you providing me with the solution doesn't have to worry that their advice could be used nefariously as it would only work if the facts were as I stated them. So I thank you again for looking at this problem through my eyes and not Microsoft's.

[mpack]

Can you verify this is a proper and safe backup procedure avoiding reactivation problems? 1. Copy folder with vdi and vbox files to another drive. 2. If need to use backup, remove the original machine from the GUI. 3. ADD the backed up VM to the GUI.

Yes, that would work and be perfectly safe. When backing up a VM you should always copy the entire VM folder plus contents to the backup disk. You don't need to use CloneVDI for this.

In fact the easiest way to restore a VM which is already registered is simply to copy the backup folder contents back into the original folder on your primary disk, overwriting what was there. So long as VirtualBox is shut down at the time, and you haven't changed the VM UUID, then VBox shouldn't even notice that you've done it. You only ran into problems because it was a new disk and a new .vbox file.

As you say, the procedures I've outlined above do not allow you to have multiple copies of the same Win7 VM on one host, nor copy Win7 VMs between hosts, hence I see no reason why Microsoft would get upset about what you're doing. MS are after the pirates who crack the installation keys and upload ISO images to a filesharing site. They don't care about Joe Shmoe making legitimate use of his own personal copy of the OS, and restoring a corrupted OS image from a backup is most certainly legitimate.