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.