A Great Response Regarding OEM/Upgrade Media

Earlier this week I wrote a piece called “For when you want to let go… but can’t completely.’  I got a few interesting responses to it, but one really well thought out one from H. Mertens.  Here is his comment, and my responses to him. -M

A clarification over the OEM/Upgrade media issue:

A OEM installed OS (typical in most laptop purchases) by license can’t be installed on different hardware (some exceptions with regards to repairs). You will be required to change the Product Key for the VM instance away from the OEM SKU to for a product SKU that you (in addition) legally own. A MSDN or TechNet subscription can definitely come in handy in these circumstances, but note that these offerings also set restrictions regarding usage/purpose of the OS installation.

All of these are really good points.  In my article I neglected to address licensing at all.  If your OS license is OEM then you are not allowed to virtualize it… or rather, you can do it, but you have to make sure that you have a legitimate license to attach to the VM, and yes you will have to re-activate the installation.

Your reference to "Upgrade" media has similar considerations with regards to licensing, since it is permanently tied to the OS license/SKU/Product Key that it was used to upgrade(and it typically that is an OEM SKU).

When I refer to Upgrade Media you are right, it is permanently tied to the OS license that it was used to upgrade, but I do not agree with your statement that it would necessarily or even probably be OEM.

I confess, it has been a decade since I delved into these issues, but back then (which is on target because of our discussion of Windows XP) you were able to install Windows XP on top of Windows XP, and it would fix a lot of issues but your applications would still work.  The reason I referred to OEM media is because with OEM you could still install on top of, but it would clean you out – no applications, no user profile.  It wouldn’t delete them, it would just put them into a directory called Windows.old.

Notwithstanding these licensing caveats, OEM and vendor specific Upgrade media, as you mention, is, generally, very hardware specific and usually will not install successfully on "foreign" hardware.

Not only will most OEM and vendor-specific OEM software not install on most ‘foreign’ systems, it is a violation of the EULA to try to do it.  OEM software is married to the motherboard of the system with which it was purchased, and there is no acceptable ‘repurposing’ of that license… for any reason.  If the motherboard dies, when you replace it you must also buy another OEM license.

Off-the-shelf, "Full-Package-Product" (FPP), which can be use as "upgrade" media, is a SKU which can be moved (not copied) from device to device.

*** So the question arises: if you are migrating an image of OEM licensed OS away from failing hardware and onto, say, a virtualized system, would that be seen as an acceptable reuse of the OEM license? ***

OEM software may not be virtualized.  In the event of Windows Server and Hyper-V, there are exceptions to this.  However on the client-side there are no “acceptable reuse” scenarios.

Hint: Typically I upgrade my laptop’s OS with a MSDN/TechNet version since the OEM versions typically are "Home", limited feature set, SKU’s. To aid installing a new OS, I do usually copy over the "%windir%\System32\DriverStore\" of the active OEM installation onto a USB stick so as to resolve "unknown" device issues (use the scan folder option in updating these under device manager). Subsequent Windows Update may upgrade these, but it usually goes over easier once they are "known" devices requiring, perhaps, an upgrade.

Here is where your in-depth understanding of licenses falters my friend; MSDN/TechNet licenses are not to be used on production machines… period.  They are for test/dev only.  As such I am reasonably sure that by installing the OS from that source onto your laptop you are violating the EULA.  It is a very common misunderstanding that many people make, but in short MSDN and TechNet are not meant to be ways of getting all of your production software cheap, they are meant for you to use exclusively for testing purposes.

If you are a Microsoft Partner, then there are acceptable alternatives.  Certain MPN Partners (I don’t know which) are given a number of licenses of most Microsoft software that they can use in production.  If you are not at that level then you can invest in the Microsoft Action Pack Subscription, which entitles you to use the same licenses on (I think) ten computers… in production.

With regard to the DriverStore directory I confess that I generally follow the advice of an old acquaintance… The drivers installed at the source are likely already out of date, and it is usually just as easy to download the latest version from the manufacturer’s website.  Fortunately for me, Microsoft IT has an image for my laptop including the drivers, so it’s not a concern.  However you might want to take a few minutes to download them… and yes, making sure you have the networking drivers is a good idea before you wipe and re-load!


2 responses to “A Great Response Regarding OEM/Upgrade Media”

  1. Hi Mitch,

    Appreciate this posting caught it on my RSS feed. You verified my thoughts on MS OEM client software. However could you please elaborate on this quoted information please as I’m curious as to the exceptions.

    “OEM software may not be virtualized. In the event of Windows Server and Hyper-V, there are exceptions to this.”


  2. Oops; you are correct re: my mistake about using MSDN/TechNet media – I should have said “replace” instead of “upgrade” when building up a test/dev (non-production) machine.

    Typically I build my test/dev system on top of a retail sourced notebook, and these generally are only available with a “home” OEM OS preinstalled (typically with a Windows “home” version, but some “disposal” Linux version are showing up now ;> ). As well, some computer shops that are assembling laptops will offer an “OS-free” version.

    I do find (perhaps more so with persnickety laptop hardware versus desktop hardware) having the …\DriverStore\ folder from the OEM installation as an initial source for identifying unknown hardware can generally speed up the subsequent upgrading of drivers from the MS Updates site.

    So Mitch…

    Of course, the best bet for a test/dev rig would leverage virtualization, but I find that the h/w specs for laptops can be an especially challenging, especially with regards to RAM upsizing (my experience being under the Windows 7 on a laptop and Windows VirtualPC). Have you had call to build from scratch (versus a corporate supplied imaged system) a Windows 8 with the Hypervisor/Hyper-V implement as a test/dev system? Any minimal recommendations re: minimal memory issues, CPU technology support beyond “SLAT”.

    Alas, my old Compaq F700, after long service and faithful service and rebuilds, has gone to join the “choir invisible” (ref: http://en.wikipedia.org/wiki/Dead_Parrot_sketch) and I just can’t settle on what I should (and could affordably) get in a test/dev laptop.

    Regards, Herb

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: