Windows 8 preinstalled licenses, AKA OA2.2 and OA3.0 Latest news and summary. (20/06/2012) ***Will be updated if there are more news / changes.*** Preinstalled licenses of Windows 8 Sever will not use OA3.0. They will get OA2.2. This is just an updated SLIC, probably the marker only (just we had at windows 7). The reason for it is that OA2.2 can be activated offline against the SLIC in the BIOS. OA3.0 will be a online activation method ONLY. This was done to support offline servers. OA3.0 will be for pre-installed client SKU's only. How OA3.0 works: The OEMs have two platform servers. One is a OA3.0 key server and one a OA3.0 reporting server. The OEMs have a master image of windows 8 that has a master key installed. The purpose of this key is only one thing: To make w8 to be a pre-licensed version. (SLP channel) The key is more like the old XP pre-licensed key. This key is NOT OEM specific, however, it is edition specific. Anyway this key does not activate. It is only installed to determine the kind of licensing (SLP). Those keys are generic. Manufacturing process: -The system is built. Manufacturing of complete systems. -The system is brought online (online doesn't mean internet, just local network) and the OA3Tool is run (Either in WinPE or Full OS) and it requests a key from the key server, this generates a FULL MSDM table as output it contains the unique key for the particular system. - A firmware specific tool is then run (could be in WinPE or DOS or whatever they wrote the flash tools for) which takes the MSDM table file and injects its key into the firmware, to NVRAM, ROMHOLE, or to wherever it is specified by the UEFI or BIOS. The flash tool also checks to make sure that if a MSDM table does already exist, it fails. The OEM can invalidate and delete a MSDM table with the tool, however, they have to report then this invalidation to M$ via the reporting server and then they can delete the MSDM table and over-write. - The OS will be installed. - Once that is complete and all testing is complete (no more hardware changes) then the OEMs can run the OA3Tool again. This run of the OA3Tool generates the 128 bit hardware hash and reports that ALONG with the product key to the reporting server as CBR, the computer Build Report. The tool has the ability to generate the hardware hash when there is NO network connectivity. This has been updated and wasn't possible before. The reporting server then reports it (CBR) to M$ which sends an acknowledgement that it has received the Key+Hash. Once it has been received, then the CBR is removed from the PC. If any hardware is changed except for external USB devices, and internal expansion cards (PCIe, PCI, SATA) then the OEM has to re-report to M$ a new hardware hash with the key or activation will fail. Finally the OAtool is ran the last time again to lock the MSDM table to prevent any changes ever. Then the OEMs ship the hardware to the customer. The customer turns on the machine and goes through OOBE using the Master OA3 key which is valid for the key check but will not activate by itself. Within 4 hours of OOBE finishing the system will automatically attempt to activate by seeing the OA3 Master Key, then reads the MSDM table for the key AND generates a NEW hardware hash and sends both to M$, the M$ servers then check to match up the hardware hash and key and if it matches (does not have to be an exact match, there is slop in there, it isn’t known what can be different) then the system is activated. The essential requirements for OA3.0 are: - The smBIOS UUID MUST be non-zero - There has to be at least ONE MAC address in the system If the above aren't there OA3 won't work and will fail. The OEMIDs in the RSDT/XSDT tables don't matter at all. They did matter at older revisions of OA3, though (had to match those of the MSDMTable). They no longer check those as part of OA3 only the MSDM table matters. There are no certificates or anything like that either. OEM's pay for OS licenses based on number reported - number invalidated.
I just had to put the things together. Credits go to those who have a good will for the MDL community and support it.
Hmm.. that means we have to download Server evals directly from MS, mod our bios (or use a loader), then activate them offline. After that, we install the desktop experience & other things & make the Server to a workstation. No more OA3.0. Anyway, -> Yen
So MSDM contains nothing more than the key right? And from the moment the tool has ran the 3rd time it's read only? Anyway, it doesn't matter if it's read only, even if we replace it with "any" key, then that key still needs to be in MS servers. One question that does matter: Is the reply from the activation server (during actual activation) encrypted? What does the master key thing mean btw? Do we need separate isos for different channels, like back in the xp days? Or will the OEM master key be installed when no key is entered during setup, and the system will look after an MSDM as long as no retail key is entered?
Yen, Since using the OA3Tool is more or less a manual job, then the one in the factory that fires it up can use the product key that is on the sticker that is placed on the system. So changing enough hardware on a OEM-system could result in users either calling Microsoft for reactivation as we have seen before or calling the OEM for support on reactivation.
It's a description of how OEM installations of Windows 8 will be activated. My interpretation, if correct, is that Windows 8 Server will be easier to activate than Windows 8 client, because it'll use a method identical to what Windows 7 uses, so existing software to activate Windows 7 only have to be adapted slightly to work with Windows 8 Server. Windows 8 clients activate by something that sounds like KMS to me, at least basically. I only skimmed the article so don't sue me! @Yen, thanks for posting the info!
The key will be injected (flashed) into the firmware, this area THERE is always read only. I guess something will be signed or flagged as 'protected' as last step. So when moding a EFI it will detect any further alternation, except one could un-sign or remove the flag and re-sign, re-set the flag. Also to add a second MSDM table somewhere else in the firmware would invalidate OA3.0. But a loader could add a new MSDM table, unlink the original from RSDT / XSDT and link the new one. Except M$ checks the complete way from where the MSDM table (key) comes from (at the firmware) and has specified it. The ISOs are basically the same, I strongly guess. The master image already has the OA3.0 master key installed for unattended installations (Unattend.xml). I guess it can be applied to the retail version by skipping key imput during instalation or by -UPK / -IPK SLMGR commands. This key's only job is a flag to tell Windows that it's OA3.0 time. No idea if the activation data are encrypted. If you change enough hardware to require re-activation it will fail. It's not clear what happens if a mainboard has to be replaced by the OEM (RMA). The OEM has to either invalidate the original key, to request a new one and to generate a completely new MSDM table with oa3tool, or to send a new hardware hash to M$ only using the original key.
So question for dummies: Is server 2012 same or better than W8 client? or not recommended? I read articles about server 2008 where it was superiour to W7 in some/many cases. I'd not care about the appearence of an OS on my screen since I could have all future advantages of W8 as a "free" OS. Slic 2.2 should not be the problem for server ( and I'm not sure if this does not come for client as well ... crossed fingers) Yen is about to figure out all eventualities and this is most appreciated speaking for all arround, but maybe it'll turn into some easier way to go, finally.
I've made several attempts at using server versions of Windows, starting with Windows Server 2003, as a client OS. Basically, it can be done, but I couldn't stand that certain software would still refuse to install on it either because of it deep down still being a Server OS, or the particular version number of NT reported, et cetera. It just was never worth all the trouble to me to do so. I have used software that's available to reasonably easily turn Windows Server 2012 RC into a client OS; I did it in VMWare Workstation. But there are things that I haven't figured out yet, like if it's going to be possible to create Windows accounts on Server 2012 using a Microsoft email account, which I've been doing on both my desktop and laptop for settings syncing purposes since Windows 8 CP came out. I haven't seen the way to do that yet. One single thing might not stop me from using Server instead of the client, but these little things add up and it doesn't take too long before I get frustrated and give up. Your experience may differ, since everyone's needs and expectations and usage of Windows is different.
Thanks for the information, but I didn't ask for that. Why can't an OEM use the product key on the COA-sticker directly when they use OA3Tool?
Great article Yen... Seems to be quite a tedious task for OEMs. Although, We will get to know the exact procedure after the launch of first Win 8 bearing machines.
I *think* (correct me if I'm wrong) that the answer to your question is for the same reason OEMs didn't do this with Windows XP. Could they have/could they? Sure, but it would be much more effort. The OEM has a single OS/disk image for every one of the same model PC they are currently selling. They restore this image to a mass amount of hard drives to be used in a particular model they sell. The hard drives get installed in the PCs, and if the OEM does some kind of QA on the PC by powering it on before it leaves the factory, it's only long enough to POST or get to the BIOS, otherwise they would "ruin" the OOBE (Out of Box Experience - the questions a brand new installation of Windows is set up to ask you, customized by that particular OEM). Hence the same KEY gets used for every model that leaves the factory with the same Windows version. The COA stickers are only to adhere to the license agreement with Microsoft, it would be too much a PITA for them to probably insert a different key into every Windows installation.
The can make an image without using any product key for Windows. Then OOBE could be used to let the customer to enter the supplied product-key or it could be retrieved from the BIOS/UEFI. But then again, my question is not about the OS. It is about inserting the product key on the COA sticker into the BIOS/UEFI instead of requesting it of a server. Requesting it of server could be prone to a mismatch between the COA sticker and the one entered in the BIOS/UEFI. This could lead to a bad situation for the customer(s).
I have to be careful to differentiate 'facts' from speculations. Speculation: First we might elaborate why M$ has 2 keys, yes two licenses at OA systems? They have the COA_SLP and the OEM_SLP licenses. It seems the OEMs are adamant that the consumer has an additional way to (re)activate. So they updated OEM_SLP and kept COA_SLP. OA2.1 is an offline activation that doesn't require a hardware hash. This means this license remains as long as the BIOS exists. OA3.0 will be invalidated if enough hardware is changed, so the key is also invalidated. The consumer then would have to consult the OEM for reactivation. The COA key is an additional new key which can be used to reactivate through internet by the consumer at home. But regarding this there is lack of info and there are still some questions open. 'Fact': I don't have any infos about 'the key on the machine'. There is a key on the machine and the consumer needs it to REactivate if he has changed enough hardware (that requires reactivation) One attribute of MDL is to post about facts. So I honestly have to mention: I have no confirmation if this key is similar to COA or even a different key. But since the OA3tool requests one from the key server I strongly guess (it's plausible) the one on the machine is different and hence similar or equally to COA licenses. And made that consumers can reactivate online at home when changed too much hardware and the original has been invalidated. It seems there will be no more original COA, though.