You are currently activated, and should be able to install AutoKMS as long as AutoRearm is not installed. You should be able to install AutoKMS otherwise. If AutoKMS doesn't work even though you are currently Activated, run EZ-Activator and it will change the PID so that AutoKMS should work again.
After i take a backup, available rearms always keep in 5. (Status still become 30days.) Before that, it often goes 5->1->0 or 1->0 This happened from v2.1.
There is no blacklisting. It's just a bug in ZWT keygen that surfaces with a CMID/PID combination. A legit KMS host can always activate Office via KMS activation.
@Phazor And I was very disappointed in you back then when I realized that you told us some lies to keep us away from the truth and keep your tool unique. Copycat?!!! Get real man! I am not new to Office activation, go get some info about the persons that you are talking about! Where were you when I was developing methods for different problems regarding Office activation? Look at my posts and see how much inferrier you nulling method agains my newly developed strategy to circumvent persistent 8007000D error is. I am still pissed at you and your behavior coz I think you played an unfair game against CODYQX4 and Bosh by tryig to keep your tool unique thru secrecy. (Didn't you have the option to let them know about it thru PM or e-mail or whatever?!) I respected you man! I really did, but I actually stopped respecting you the moment I realized that you were telling everyone lies this whole time. You knew from the beginning that, that MS thingy! was just a lie to convince everyone. I am sorry, but you made me say this stuff. I am sorry everyone that you have to see two experts argue. I refrain from any further arguments. And I am sorry CODYQX4 and Bosh, I know this is totally off topic. But he said sth, so gimme the right to answer please.
Thats a good idea, actually! How about this: Well, theres little more to say, is there? Perhaps youd have been better off being less braggy about the matter...
BTW, your shortsightedness saddens me. (Or should i say sickens me.) I never lied to anyone here, the problem is simply that you are too fricken thick to comprehend that this is not something everyone should know about. Now Microsoft can take all the countermeasures they need and the well-working 77kb KMS solution might vanish with no options (like alternative PIDs) left. Thanks a lot.
I can't seem to find it. Also, note I need an actual live KMS server to do the test I want to do. On an unrelated set of testing (making sure my PID's work on Windows and Office). After nuking the ones that failed for office and finding a few more on the internet. I have 10 PIDs that work both on my Office 2010 on my PC and Win 7 SP1 Enterprise in a VM. While you said testing may have one not work, my goal was to axe ones that were tested never to work within my zone (so I know each one at least works some of the time, and 1 out of 10 should result in a match).
Thanks for the extra PID's but I managed to meet my quota of 10. Also, a friend of mine was able to with a real KMS server at work test my PID idea. You can have a PID 100% fail with KMSEmulator, but a server using the same PID will have no issue. This killed the last tiny doubt that the fault is 100% in the emulator, and it means someone skilled enough could probably fix it (I lack the knowledge of reverse engineering and cryptography to even attempt suck a task, but it should be possible to fix).
Well given that Phazor has passed out PID's and I have axed the bad ones, I have one more update planned. I'll replace the bad PID's in 2.1.3 with good ones, and I will make AutoKMS 100% independent of Office (you can currently activate windows, but it will bail out immediately if it doesn't find office, also, toolkit won't even let you currently install AutoKMS if Office 2010 is not installed.).
On second thought, since the other PC would be sending the same PID, but under a different hostname, it might also be because of that why the PID doesnt work with one, yet does with the other. Could be that the hostname is part of whats being stored/blacklisted...
Nope. I rigged things so that I could use a KMSEmulator elsewhere by rigging the hostsfile. Domain/IP has no effect whatsoever. There isn't a blacklist given things can match up except for the difference being a real vs fake server. The KMSEmulator is undoubtedly at fault. I don't even think it does anything to windows/office in any way shape or form that makes a difference, I just think KMSEmulator chokes out in certain scenarios due to flaws in the code of the keygen.
Of course Windows AutoKMS users still will have to explicitly enable Windows activation in Settings to use it. I'd rather not have to implement a windows KMS detector, I just assume the user has things setup right since they manually enabled the support. I'd have to check too many SKUs since there Vista/7/Server/Server R2/Other KMS Enabled Windows crap, and not only would it be a lot of code but doing the checks would be slow.
I dont doubt that the emulated Host is at fault, (or at least the cause), but there definitely is some blacklisting going on. (For lack of better term.) Otherwise we would have no persistent 8007000Ds, and we wouldnt be able to break the persistency by initiating a process that obviously 'unblacklists' the PID in question either. I think that much is logical. To give you more than speculations i will attach a screenshot. As you can see, the logged 8007000D is accompanied by another block that contains the CMID, the hostmachine name, the computer name, and more. This applies to all logged 8007000Ds. I dont think thats actually the blacklist, but im sure it looks very similar, wherever it is...