Sorry everyone it's my first post...and i'm doing about the rudest thing I could do. But, After reading 100 pages of the previous thread and coming up with a couple of (maybe poor ideas)...and finding the thread had been closed!, I had to let it out. Ok, firstly for me the greatly reduced cost of W8 compared to W7 says to me that in most of the world Microsoft intend for piracy to be far of a smaller issue this time round. I'm by no means a tech god, but after reading some of the good points in the last 100 pages I think a couple of my ideas may be possible. I until recently was a Windows 7 deployment engineer for a large company, so have had access to VL editions and previous deployment methods + VAMT's for MS, obviously troubleshooting the various methods too. 1) Windows 7 was expensive, so you were more likely to nick it. 2) The Host codes used to create valid KMS Host servers were far too simply constructed from little more than some short RSA Keypairs. I guess they did a mod of the result to find what version of the OS it was for. This was also true of the SLP + SLIC2.1 ACPI tables, used for OEM activation. Although these were slightly more complex than the KMS server keys, a table valid for one model of laptop would happily activate an identical model as well, as long as the same version of windows was used (and you copied and pasted a SPP token + cert across too). This meant you could just dump a table out of a SLIC2.1 BIOS and inject it into another BIOS...or even the MFT, and it'd work. Anyone that's seen one of these Slic2.1 tables knows that there is no real data tying that table / token /cert to any particular laptop other than the Manufacturer and manuf ID....So MS could pair the files as tight as they liked with hashes + RSA etc, you could still just copy + paste. 3) I read in a post on here earlier a route I think W8 OEM auth files are sadly more likely to take. The auth files could be made up of uniquely identifing values relating to each PC. IE MAC Address, CPUID, UUID, Motherboard serial, HDD volume ID, other assorted hardware details. Hash those together and encode with RSA and that code ain't going to be activaing any other machines. This could be why there's been a much greater problem with peoples OS' deactivating after only small HW change. 4) The last bit to come..I can't see a reason for MS to push out permanent Activation keys any more. Each to connect to the VLMS to collect more VLK's to use as KMS and MAK keys for their client PC's after reimaging / upgrading etc. What if the KMS' +hosts were as strict as the OEM keys, in that as soon as it's used to activate a machine, it's tied to it. Add a limit of 1 activation of a MAK / KMS host per VLK, together with the VLK being tied to the IP's / subnets / domains of the customers sute and you're not gonna get many mini KMS's lasting long like that. The Hosts and already activated clients could even get new keys periodially pushed via SCCM / WSUS at the end of their grace period. The rest'd just die. It's specially bad with some people blingly pinging the few live servers in a looped batch file, and wondering why they drop (doh!). Anyway soz to put a downer on things, just thought if a few of us think about why it's not working...we could figure out how it could. Cheers.