I know what you mean, but so far things are staying consistent. I test things case by case, carefully controlling the conditions, and given that the real server I cannot in any way make it fail by trying to "blacklist" it, and PID/CMID combos fail when KMSEmulator is at work, but never ever fail for the server, seems to suggest the response. Because I can't think of any other condition that is changed that matters, other than what is sending the KMS response.
For anyone who at any point has run Available rearms and wound up getting 5 but check status and have gone to grace mode: I have seen this happen during testing. My theory is this: I do the check by taking a temp backup, and then I loop running rearm counting it until fail. When that fail triggers, I restore the backup, delete the backup, and return the count. The Restore and the Delete are close together. It's possible the restore doesn't finish and the backup gets deleted somehow (though this in theory the way I set it up should through in every recognizable error that can go wrong be caught in the restore). Just to be sure I'll added a delay between restore and delete.
No, unfortunately changing the CMID does not necessarily solve the issue. If that were the case then a simple rearm would fix each and every persistent 8007000D. But it doesnt, according to collected data thus far it appears to be helping in the majority of cases, (at least with Windows), but i still have two VMs where everything is so screwed up that a simple a rearm (CMID change) wont help anymore. Only the PID swap breaks the persistence. Others have reported the same or similar scenarios. (Hope i understood you right...if not let me know.)
When I say CMID change, I am assuming that the new CMID is actually good (I know the new CMID can be bad as well). If it was always good, my repair would have worked 100% of time. About those VMs, how does the CMID change in the toolkit 2.1.3 play out? (As you get a shot for 10 changes, where a rearm is 5 max).
The biggest mistake when dealing with this thing is to be too confident in anything. Like i said, numerous times i thought i had found all pieces of the puzzle because everything stayed constant over many many tries. Even so eventually the whole building collapsed because all of a sudden the problems returned. For no apparent reason. Just a little tip based on own experience... EDIT: Sorry for posting this after your posts, it was supposed to go under my last one.
I'll keep that in mind, but given that server never fails while the emulator chokes is a strong sign. Something that makes it hard to confirm CMID vs a blacklist, is that any blacklist would be stored in the license files. If it were stored externally my CMIDTest would not be allowing me to create these scenarios and then just restore and get out of them. Any blacklist is in the same boat with the CMID. If we could read the license stuff we might find more info. Have you looked in tokens? They are mostly readable, where as I don't know how to read the registry stuff.
Be sure to take a backup, so you can try more then once, since a restore puts the CMID and any persistence back in place. You said a PID swap worked but a CMID change didn't, though you said you were using rearms which are limited, where a repair in itself is one CMID change, with option to do 10 CMID changes.
BTW, i do get what youre saying, but i dont quite understand how these two things are supposed to relate to each other? How can one CMID be 'bad' in relation to the Hosts response? How can another be 'good'? Dont get this wrong now, i dont mean it in a bad way, but it seems to make rather little sense? Is it just a speculation?
I did, because its one of the most obvious candidates, but thats not where its stored. I already have a backup, thats what i keep restoring the machine from. Please rephrase this.
Well keep in mind the Host reads the CMID (one use of it is to ID a client, a real world issue with CMID is where improper imaging deployment creates duplicate CMIDs and therefore KMS activation issues). I don't know exactly how it is used in detail, but the CMID is used in the response and letsgoawayhell agrees in one of his sig links. So CMID and PID are inputs to the response. If KMSEmulator is not generating responses exactly as it should, then it may not handle the inputs properly all the time (a combination of a CMID and PID may result in "Invalid Data" which is what 8000700D means). By changing one of the inputs and the combination now creating proper data, things work. By good CMID I mean that by leaving the PID alone, you come up with a CMID that when paired with the PID does not cause a problem.
I meant just a license backup as it's quicker than a full VM snapshot. What I mean is earlier you said "but i still have two VMs where everything is so screwed up that a simple a rearm (CMID change) wont help anymore. Only the PID swap breaks the persistence." You said a rearm change of CMID didn't work (but this is just one try, and you might run out of rearms before you get a "good" CMID). But you said PID change already worked, and I was saying that EZ-Activator will try to change the PID if normal activation with a blank PID fails, then do the CMID change, but it will most likely get a good PID and therefore not try to change the CMID (You can prevent this by disabling the PID fix so it first tries repair then CMID change if the repair failed (which repair=1 CMID change, afterwards means another 10 will be tried)
If it is of any other use to you, you can in toolkit options set a custom PID to use. By default activation is attempted with a blank one, but you or EZ-Activator can set a custom one. It just has to fit the normal format or blank (I don't for example let "gshfshfdfhdhfd" be a PID). Something I want to check is how my reinstall keys backups fit into this. Normal backups totally restore everything, where as reinstall keys replace the tokens and reinstall the keys (which can change registry). I'll post on that soon.
Well i see how you would think what youre thinking, and its good reasoning from where you stand, but unfortunately there is a flaw: The CMID is not transmitted during an activation request. I can intercept the entire traffic between the Host and the licensing module and the CMID is definitely not among the transmitted data. What now?