N00b question about Windows activation

[mpack]

To be honest, I suspect that most people who dual boot use an activation-disabled copy of Windows.

Or like me, after hitting the activation problem (and the limit after trying a couple of different VMs) they just bit the bullet and bought a new OEM copy of XP Pro to be used exclusively inside VMs.

Strangely though: my first experiments with VBox were with a retail copy of XP Pro, and that is what gave me activation issues. The OEM version of XP Pro SP2 asked me for a CD key of course, but it has never prompted me to activate! This is a mystery to me, but a convenient one!

[vkov_tinsky]

Hi Terry,

sudo -u terrydisk XAUTHORITY=/home/terry/.Xauthority VBOX_USER_HOME=/home/terry/.VirtualBox VirtuaBox

I tried that (adding the user to vboxusers & disk, allowing write access to ~/.VirtualBox) but when I try to run it like above I get

Code: Select all   Expand viewCollapse view

vt@ogimogi:~$ sudo adduser rawvb --no-create-home --ingroup vt
[...]
vt@ogimogi:~$ sudo adduser rawvb disk
[...]
vt@ogimogi:~$ sudo adduser rawvb vboxusers
[...]
vt@ogimogi:~$ sudo -u rawvb XAUTHORITY=/home/vt/.Xauthority VBOX_USER_HOME=/home/vt/.VirtualBox VirtualBox
No protocol specified
Qt WARNING: VirtualBox: cannot connect to X server :0.0

I though the point of including XAUTHORITY was to stop that but it's not working for me (I'm using Ubuntu 8.04). I fear there is something really stupid I've forgotten but I can't see what.

Regards,
VT

[TerryE]

I created my user using the Ubuntu GUI but it was the equivalent of --gid vb rather than --ingroup. You also need to do the chmod g=u of the .Xauthority of course. However what you are really doing here is running VirtualBox in a process with the UID rawvb and this needs the privilege to access the X display process owned by vt. Probably the easiest way to do this on a workstation which only has one interactive user is to just do a xhost +localhost, but this note is a good summary of the alternatives: xhost +localhost.

[vkov_tinsky]

Thanks, it's working now. I had forgotten the permissions for .Xauthority.

Code: Select all   Expand viewCollapse view

sudo adduser rawvb --no-create-home --ingroup vt
sudo adduser rawvb disk
sudo adduser rawvb vboxusers
chmod ug+rw ~/.VirtualBox .XAuthority
sudo -u rawvb XAUTHORITY=/home/vt/.Xauthority VBOX_USER_HOME=/home/vt/.VirtualBox VirtualBox


Regards,
VT

[TerryE]

Since you will be doing the sudo of VirtualBox a lot, its worth setting up an alias in .bashrc and also editing editing sudoers to avoid having to type the password every time.

If is also well worth you doing a knowledge search of the forum and the wider internet for your tutorial. Start with google using my site:forums.virtualbox.org trick. A few keywords that you might want to use are DMI, boot.in, hal.dll

Here's another tutorial you might want to look at http://forums.virtualbox.org/viewtopic.php?t=1966 as well as mine.

[vkov_tinsky]

A few keywords that you might want to use are DMI, boot.in, hal.dll

Hmm.. I thought I had boot.ini & hal.dll covered with point 8 in section IV?(I've tested everything that I've written).

I'll try the DMI stuff tomorrow (so I can write up that final section). I've been following the relevant threads in this forums closely.

***EDIT
I've referenced both of the articles you mentioned

[vkov_tinsky]

No luck with activation using a single XP installation. I can active it (WinXP SP2 retail) running on host and guest, but as soon as I switch to the other side I get the wonderful "Your hardware as changed significantly" message.

I added the DMI fields to the machine configuration. Now msinfo32 output matches apart from SMBIOS version (which is hardcoded in DevPcBios.h so I assume this isn't supposed to matter?).
I set DmiBIOS[Release|Firmware][Major|Minor] as suggested in this thread (e.g. to version of SMBIOS) but that can't right because now underneath the characteristics list produced by dmidecode -t0 I also get BIOS and Firmware revisions listed, which do not appear when issuing the command on the host (and there is no option to leave those blank?). Ouput of dmidecode -t0 matches however.

Maybe Windows just decides that too many devices change at the same time (that would be chipset,graphics,audio,network, hdd) and the bios information is not to blame at all.

*** Edit ***
This article seems to indicate the multiple hardware changes are indeed to blame. It looks like keeping a single installation of Windows XP activated, for use in VB and natively, is impossible.

[TerryE]

VT, thanks, I've been meaning to do an internet trawl, because I was asking myself basically the same Q -- "Just what is the Activation Trigger algo". What this article details accords with my vague recollections of this. In summary for those who can't be bothered to browse it splits the Windows installs into various categories:

• Activation disabled. This includes Enterprises with MS Enterprise or Software Assurance Agreements, and MSDN professionals who IIRC can install up to four copies of any MS product for development purposes.
  
  
• Bulk EOMs. So here if you by, say, an HP PC activation is disabled so long as you run the copy on the HP PC and the OS detects this by looking at the BIOS DMI information. It is this category that the DMI settings overcome.
  
  
• Other Installs. Here the 7 "green" out of 10 H/W device comparison based on Display, SCSI and IDE Adapters, NIC and MAC address, RAM size, processor type and serial number, system HDD + VSN, CD-ROM / CD-RW / DVD-ROM config. So change any three of these and you set the flag to dirty and require reactivation. In the case of full licences you may need to phone up the call centre and explain what you've done, but you will be granted a renewal. In the case of OEM installs MS will seek to constrain this to the original system, e.g. the change was due to in-system upgrade or replacement component after component failure.

Suffice it to say that the VBox VM is going to be so different from the underlying H/W to generate 9/10 reds. This is sufficiently over the >3 test to say that it is impossible under these circumstances to avoid reactivation. Hence you need will two copies of Windows to avoid this reactivation trigger, unless you buy a PC from a major OEM.

Well I got into this on my test rig mainly so I could answer these Qs, and now I know. I only paid my 30 shillings in the first place to do these tests on my Linux box. I am not about to pay another 30 (I do this work pro bono), and the only reason I need to use a Windows VM is to support this forum. I need the Windows host as well.

[vkov_tinsky]

Found the solution! Was much easier than I thought.

I've updated the article.

Regards,
VT

[TerryE]

Huummm, I do think that you need to state that in the case of a "large OEM" install, the DMI trick will work. You also need to be careful here. There are times when Windows sends this key back to MS + the licence key (e.g. windows genuine advantage). If you do this from the wrong configuration then you will trigger reactivation. The other thing that I have is a genuine unease, especially if you are running an OEM licence, that MS might take a strong objection to you running a dual boot configuration like this. Of course your licence is an agreement is an agreement of two parties. Since MS use "action by the second part" as deeming acceptance, you could always play them at their own game and email them suggesting that this is your interpretation of the agreement and that by continuing to provid e system updates they are indicating their acceptance. If they don't bother to reply ... But then again, I'm not a lawyer, and I don't need XP that much.

[vkov_tinsky]

Huummm, I do think that you need to state that in the case of a "large OEM" install, the DMI trick will work.

I don't agree. Automatic activation will work for the first activiation, but not the second (again due to the hardware changes). I'll add that later today.

If you do this from the wrong configuration then you will trigger reactivation.

As far as I know (and from my experience) the latest version of genuine (dis)advantage will only stop you from downloading updates/software bound by this check, not trigger anything else.

But then again, I'm not a lawyer, and I don't need XP that much.

Doesn't boil down to that: It's about whether you want to use a single installation in a "dual" boot with a single license.

Let's assume you need two licenses. How do you force Windows to use a different CD key when it asks to be reactivated? I did not see any such possibility. Or in other words the key is not stored in wpa.dbl (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ProductId). I do not have sufficient spare licenses to test this out. I thought I read somewhere that running Windows natively and in a VM on the same computer was allowed (recent change of terms). Anyway, as you say someone could ask Micro$oft.

If you feel as a moderator that what I've posted in the activation section is inappropriate feel free to remove it. (I don't mind since I now already know how to do it).

*** Edit ***
Ok, so this how you would change the product key. If you then could do the same trick as with wpa.dbl with registry key that could be the solution (for using two separate licenses). But as I said I do not have more than two licenses so can't try it out.

[TerryE]

Huummm, I do think that you need to state that in the case of a "large OEM" install, the DMI trick will work.

I don't agree. Automatic activation will work for the first activiation, but not the second (again due to the hardware changes).

Your conclusion is inconsistent with the following:

OEM versions

Restrictions of specific license types may limit the foregoing. OEM versions of Windows XP are licensed together with the hardware with which they are purchased, as an entity, and such a copy may not be moved to a different computer. Also, other specific license types (e.g., Academic licenses) are handled in different ways. These aren’t a WPA issue per se, but rather an issue of the license for that purchase, and therefore outside the scope of this discussion of WPA.

There are two versions of OEM Windows XP systems. One can be purchased separately, with qualifying subsidiary hardware, and installed with that hardware to an existing machine, to which it becomes bound. The software may be reinstalled and reactivated indefinitely as with a retail system as long as it is still on the original machine. It may not be transferred to a different computer. It is activated as described above, but if it were installed to hardware seen as not substantially the same, the activation would be refused as falling outside the license.

In the other OEM form, the system is provided pre-installed by a major supplier. Instead of activation, the system is ‘locked’ to the BIOS on the motherboard. The validity of this lock is checked at boot. As long as this is satisfied, other hardware may be changed freely, but any replacement motherboard must be for a compatible one supplied by the original maker.

If a BIOS-locked system is installed to a board where the lock fails, it enters a normal Activation process at startup. However, beginning 1 March 2005, the Product Key supplied on a label by the computer manufacturer, and used for the initial intallation, will not be accepted for activation. A new copy of Windows XP, with a license allowing installation on a different machine, will be needed. This means that any replacement motherboard (or upgrade to its BIOS) must be supplied by the original maker, who will ensure the lock is maintained.

[?y italics]. In otherwords, if you have a PC installed by Dell, HP, etc., then activation is locked to the BIOS and the DMI trick does work. However, if the final para still applies then this situation will only occur for systems more than three and a half years old.

Incidentally the Wikipedia article on WPA gives a consistent but more up to date view

[vkov_tinsky]

Activation Take #2

[mpack]

"OEM versions of Windows XP are licensed together with the hardware with which they are purchased"

This is going off at a slight tangent, but...

ISTM that Microsoft can't have it both ways. I believe their position is that you need a second license to run Windows inside a VM, because the VM counts as new hardware, even if you run it on the same physical host.

Therefore, if MS classifies virtual hardware as hardware for licensing purposes, then it also must qualify as hardware to which an OEM license can be bound.

ps. someone mentioned that MS maybe allows a second copy of one license to run inside a VM. I don't believe that is the case for any standard retail or home version of Windows. I believe that server versions of Windows allow multiple virtual instances, and obviously Enterprise versions can be installed on any "hardware" owned by the business. I don't know the exact details, but I'm pretty sure that is the gist of it.

[TerryE]

If you search the web, you can get some good dialogue on MSDN and on googling WPA or "Windows Product Activation" site:communities.vmware.com. There was one bizarre thread between a poster and an MSMVP which sort of went:

Poster: I want to run my XP on the bare H/W and in VMware
MSMVP: You need two licences for two systems.
Poster: What counts as different systems?
MSMVP: Different installations on different H/W
Poster: But I'm running the same OS on the same disk on the same H/W. The only difference is that VMware in the way on one profile.
MSMVP: But VMware is a different system. Your OEM agreement ties you to one system
Poster: So where does it say in my OEM agreement that I can't put a VM between the H/W and the OS? Just point out the clause.
MSMVP: <silence>
Poster: Why do I need to reactivate when I switch?
MSMVP: This is a perfectly reasonable check, it only takes a few moments or a telephone call
Poster: but once a day? ...

Get the drift? It does appear that we two inconsistent interpretations of an agreement which underpins the use of a purchase. As far as I can see, this issue doesn't seem to be one of a breach of any criminal code, but more a grey area in which MS's interpretation seems to differ from the logic applied by most users. MS could easily test its interpretation through the courts, but AFAIK they have chosen not to do so; the commercial danger here being that any judgement could just go against them establishing clear case-law that they are wrong. The grey status quo plus intimidation is effective in maintaining their commercial agenda. As far as I can see, this is to force consumers into an either / or when it comes to MS product vs. Open Source or Mac alternatives: to prevent consumers choosing intermediate solutions which live them a soft migration path from MS to dual boot, to dual boot + VM, to Linux/ Mac boot + VM, to Linux/ Mac boot. Certainly as far as the EEC is concern I suspect that taking this stance to court would fall foul of our Restraint of Trade legislation.

Back to the technical solution one blog entry Getting around Windows Activation when virtualizing, this uses a script attached to the group policy option for Computer Configuration>>Windows Settings>>Scripts>>Startup>>Add to run a test based on setting an environment variable vmware:

Code: Select all   Expand viewCollapse view

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

and then doing if / then / else logic based on whether this is defined. What the for does is to set the variable to the 14th token on the line containing vmware if that line exists. This is the CMD botch equivalent to the backticks operator. Still it does look like we can make startup quite swish.