virtualbox.org

Now to post what I was planning on.

2 months ago when 4.0.2 came out I setup a Virtual folder and Windows 7 virtual.
I was preparing it for a MAC Book Pro.
I got it all updated and setup with all the software needed. Then activated it.
This was setup in it's own folder, and label virtual VM's which then had two folders, Virtual Disks, and Windows 7 folder.
Windows 7 virtual was in the Virtual Disks, and All the machine info was in the Windows 7 folder.

I setup virtual box on the Mac exactly the same then over wrote everything with the copied files from the setup machine.

It required reactivation. -- That means every item was the same as the as it was setup. e.g. windows 7.vbox, windows 7.vbox-prev and logs,
Thats when I figured it had to be CPU. Vbox lets to much of the CPU info thru. (or I thought it was)

Then the fiasco with update to version 4.0.4. Loss of permission to run VBOX. Had to fix the problem; then found I could load 3.12 and get it to work. Did that until, this Tuesday, then I fixed the permission, but the original Windows 7 folder still will not work one of the files or something. Got every thing to work with a new setting, but have to activate it again....

Perryg wrote:DWade,
That is what the MAC forums are for. You go there with MAC specific questions and here for VirtualBox specific questions.
I am sure they know what the utility is and can give you a step-by-step guide on it's use.

I am having problems with a windows activation.
And if I wanted to Post in Mac forum part I would have.

I wanted step by step instructions. So that everyone can do it and not have this irking problem of having to call microsoft every few weeks or days or months to reactive the darn window partition lIke I am having toooo.....

So you are really looking for a way to get around the Windows activation. Do you not see the legal ramifications of this?
As for you mentioning the permission utility that is what I was addressing.

DWade wrote:What is needed are those steps done like this:

DWade - this thread is not intended to be a tutorial. It was intended to be a simple list of the things to watch out for if you tend to do things that might provoke a high frequency of Windows activations, e.g. you move around between hosts a lot, depending on where you are. As Sasquatch says, one of the first things established in this thread in the first few messages was that the VM UUID is significant for Win7 activation. This thread is for establishing the facts, not teaching the workarounds.

You Know, that's not why I want it.

I get tired of reactiving windows. I have Purchased Licenses for the product.

So stop with the implications. This is the sixth reactivation of the product. and it realy get's to be a pain... Cause you have get by the computer, to an operator and explain what happened so you can get another reactivation code.

That's so that next time I have an error or and error with virtual box, it doesn't need to drawn out call to microsoft to re-activate.

DWade wrote:You Know, that's not why I want it.

I get tired of reactiving windows. I have Purchased Licenses for the product.

So stop with the implications. This is the sixth reactivation of the product. and it realy get's to be a pain... Cause you have get by the computer, to an operator and explain what happened so you can get another reactivation code.

That's so that next time I have an error or and error with virtual box, it doesn't need to drawn out call to microsoft to re-activate.

Have you tried adding a hardware id? if not, try it before activating. Then never change it, it might work unless Windows is looking at other hardware components like your cpu.

That is where my error is, No Hardware ID.

But, in using the VBoxmanage commands you must have the file in the folder you are going to modify the VM with. Also the following dlls VBoxDUU.dll and VBoxRT.dl . It is not registered with Window XP. I will check windows 7 some time later.
The commands are sometimes somewhat vauge. so I played with a blank vm and this is the command line. Testing.vdi is the vm and..
VBoxManage modifyvm Testing --hardwareuuid 05f2222c-9697-485b-b105-267a36c401fc (Hardware UUID Have to make it up, and it must be in the format I have typed in.)

I have not gotten it to create a uuid. Nor do I see that command. So may be I am missing it.

But I finally checked the windows 7 vm and it does not have a Hardware ID. So I am stuck for a while in re-activating it. Unless I can add a hardware Id and then re-activate again.
BUT ... I came here to give what caused the reactivation sequence in Windows 7. Upgrading from version 4.0.2 to version 4.0.4 on a Mac, cause it to change file permissions and could not get it to work. Fixing the permissions caused a reactivation., beacuse I could not keep the original folder with the VM data it keep erroring.
So a copy of the working VBOX (Testing.vbox) XML for the VM is a must, so it can be overwriiten in the new machine folder or a least the for editing the machine UUID and Harddrive UUID. -- Or at least I hope that will stop that.

DWade wrote:
VBoxManage modifyvm Testing --hardwareuuid 05f2222c-9697-485b-b105-267a36c401fc (Hardware UUID Have to make it up, and it must be in the format I have typed in.)

I havent used this on Windows but on Linux the syntax is
vboxmanage modifyvm /pathtovm/xmlvmfile.vbox --hardwareuuid SOMEGUID

In Linux and Mac you can use uuidgen to generate it.

DWade wrote:VBoxManage modifyvm Testing --hardwareuuid 05f2222c-9697-485b-b105-267a36c401fc (Hardware UUID Have to make it up, and it must be in the format I have typed in.)

Isn't the answer obvious? You set the hardware ID to be the same as the VM UUID you already activated it with. That replaces the hardware ID with an identical ID, making it permanent and not affecting your current activation.

mpack wrote:

DWade wrote:VBoxManage modifyvm Testing --hardwareuuid 05f2222c-9697-485b-b105-267a36c401fc (Hardware UUID Have to make it up, and it must be in the format I have typed in.)

Isn't the answer obvious? You set the hardware ID to be the same as the VM UUID you already activated it with. That replaces the hardware ID with an identical ID, making it permanent and not affecting your current activation.

Very good point

mpack wrote:I'm wondering if late model (post Vista release) generic (not BIOS locked) OEM XPs also lost the activation requirement entirely? This is just speculation, I doubt anyone outside of MS can answer that with authority.

In fact I was able to answer this definitively myself.

I recently came across a free tool which can analyze your Windows XP WPA database (WPA = Windows Product Activation, A.K.A. the need to activate your XP or later), and it tells you which of the hardware elements which contribute to triggering a reactivation have in fact changed since the last activation. Once I found this I was curious to know how near or far from activation I was on my various XP PCs.

It turns out that, for obvious reasons, the tool will refuse to run on XP variants which don't require activation, for example volume licensed copies. It ran ok on my XP retail host (no h/w changes since activation), but refused to run on my XP Pro OEM guest! This confirms that at least some generic OEM XP setup CDs had lost the activation requirement entirely. Perfect for a VM, talk about landing on your feet!

I've tried to read everything about stopping the reactivation of windows 7 and previous versions of windows. VirtualBox versions have changed some file extensions as new versions are released as well as other tasks. I setup RPD and tried to run BoxManage modifyvm Testing --hardwareuuid 05f2222c-9697-485b-b105-267a36c401fc as was posted by another user with the objective of "You set the hardware ID to be the same as the VM UUID you already activated it with." I couldn't get the BoxManage modifyvm to run. This thread has been active since 2009. There are many people trying to figure things out for themselves at great cost of time to them and the moderators. What is the chance a tutorial could be provided to put this issues to rest?

I won't actively create one, for the simple reason of licensing. You're using ways to avoid activation, thus allow yourself to run multiple copies on one license. This is against the license agreement itself, which states that it may be installed on only one system at a time. If people want to go through the trouble, they may as well read this thread as a hurdle to take. If it's too much, they shouldn't do it anyway IMO.

Ok I guess the first thoughts are that people are trying to get something for nothing. I would like to suggest a "feature": Move. All I would like to do is maintain the functionality of the VM. Just one licensed copy. I re-image my Host hard drive every couple months, install updates, and create an image of that. This way if something goes horribly wrong Malware or other, I can have a working system in a few minutes. Each time I did this with VirtualBox, the Guest activation is lost. If I could Move the Licensed and activated VM back to the newly re-imaged Host, I'd stand on my head and eat bug. The move "feature" would prevent the VM Guest from being used anywhere else. I used RouterSim software to study for my CCNA. I could move the simulator around with me. It was a great time saver.

juliemckean wrote:If I could Move the Licensed and activated VM back to the newly re-imaged Host, I'd stand on my head and eat bug

That will never work. The hardware of your physical PC and your VM is radically different, the cumulative changes are bound to trigger a reactivation. This is under Microsoft's control: you would have to approach Microsoft if you want them to change their policy (and I wouldn't hold your breath while waiting for a positive answer).

I suggest you use something like Acronis if all you need is a drive image backup tool.