The best environment is a fresh install. I have tested by simulating time by killing OSPPSVC and changing date then restarting. The way it works is: Install: 1.Check Rearm Count Before Install 2.If Rearm Count is 2+ Copy AutoRearm.exe to C:\Windows\AutoRearm\AutoRearm.exe 3.Set a Run Key in the registry. 4. Use the toolkit to create a backup then move it to C:\Windows\AutoRearm\Backups\AutoRearmBackup. AutoRearm: 1. Run at Boot Using the Run Key 2. Check what the lowest grace period is 3. If Results From Step 2 are 5 days or less, try to rearm. 4. If it rearms, good, close AutoRearm, else continue 5. Restore Backup and validate success, if successful rearm. Basically, run over a long period of time using AutoRearm and not activation, I have not been able to test it in real time. I recommending using VL or using license add to convert to VL as Retail has nags in 30 day grace.
It seems though rare its still possible to get the slic error "Access Denied" error on License Add. The way I am planning to install them will render it impossible to get this error with license add. Keep this in mind. EVERYTHING ospp.vbs does is just interact with WMI. By using WMI we cut out ospp.vbs (the middleman). How WMI installs the slic is it reads its contents to a string and installs using the string. We get "Access Denied error" as a result of writing a file, then deleting it and maybe writing it again. There are three possilbe places we get this error. 1. Deleting Keygen after use. Have not had this happen yet with Bosh's new functions. 2. Key Check. I fixed this for sure a long time ago. I have not got this error since BETA 1. 3. License Add. The most likely place. We create a list of slics, copy one, install it, delete it, then copy next one with same name. Because we are using multiple files with same name so fast after deleting, this is the prime place for the error. According to Bosh since we'll be installing by passing a string (the contents of the slic), we can read them as embedded resources without having to write them to disk making this #3 error impossible. Also one thing I did since BETA 4. Remove key custom no longer uses ospp.vbs. This has basically no effect on you at all, it just brings me down to license install before we do not need ospp.vbs and can remove the check for it. But focus on uncovering BETA 4 Bugs, as its radically changed. Barring the above bug, if no other problems occur I will make slic install WMI based and that will likely be final 2.0.
Keep in mind office opens and reads "Registration" key. The Retail and VL would be separate, and if you really wanted to be sure you could leave only the VL part. The PID itself could not be used as this key tells office what part it is. We do not force Retail to use MAK, rather, we make office read the right reg keys to use MAK as if it were. The office apps are not coded to be retail or VL, they read from registry what they are. Also, you could legitimately install Pro Plus VL over top Standard retail and the apps in both would read the VL Pro Plus and the Standard retail license. There are way more effective ways to brick people then the PID, which does not even have to be in the registry.
Well but what will happen if you used the KMS key generated PID / DigitalProductID and then just changed the key to MAK one? ..... please note that both of them are using VL edition as I know ........ Sample out of a MAK key and KMS client key : KMS client key : Code: [From DigitalProductID version 3] Generated PID from the old DigitalProductID : 82503-018-0000106-48490 Experimental BINK ID from the old DigitalProductID : 0x00000060 DVD codename from the old DigitalProductID : X16-08044 Converted base 16 value by decoding CD Key as base 24 value : 382B287E3379EA7AF58123CFC2638 Validation time of this key from the old DigitalProductID : Sat Oct 02 11:08:51 2010 Edition type from the old DigitalProductID : 0x00000003 (Volume Edition) Checksum of this old DigitalProductID generated : D4E1C23D MAK key : Code: [From DigitalProductID version 3] Generated PID from the old DigitalProductID : 82503-566-0042044-48566 Experimental BINK ID from the old DigitalProductID : 0x00000060 DVD codename from the old DigitalProductID : X16-08116 Converted base 16 value by decoding CD Key as base 24 value : BD0D26E452F57CE2AD6E22EDC3A Validation time of this key from the old DigitalProductID : Sat Oct 02 11:10:22 2010 Edition type from the old DigitalProductID : 0x00000003 (Volume Edition) Checksum of this old DigitalProductID generated : C44C9AE5 Both of them are using volume edition as I know (0x00000003)
Office itself doesn't care about the PID. It looks at what is in the Registration key. The Registration Key is like this. Master SKU: This is {9..... First digit after 9 is 0 for VL/Starter/SharePoint Designer and 1 for Retail. For the master SKU there are Keys alongside it for each possible key type fot VL or Retail. So It sees its VL then asks OSPPSVC which shows it the MAK license. We cannot have KMS and MAK keys installed at same time so MAK replaces KMS (Regardless of PID in registry). Office sees retail and vl as two different things. Office looks at the master SKUs to see what it can be considered part of (Office setup will let you install multiple suites). Because it looks at the master sku which dictates the key types, reading a Retail Master SKU in the registry will cause office to see if retail license is installed regardless of the suite being VL. So office runs and it doesn't see any mismatch.
No problem using AutoKMS Beta 3. After uninstalling Beta 3, rebooting, and installing Beta 4, I'm getting a dialogue box pop up right after restarting the machine: "AutoKMS has stopped working. Windows is looking for a solution" (or words to that effect - the dialogue doesn't stay on screen long). The error condition is logged in the Windows Event Viewer>Windows Logs>Application; Source: Windows Error Reporting, Event 1001: Don't know if that helps any. Windows 7 Home Prem. 64Bit, Office 2010 Pro+ Vol. 32bit No activation problems. Even with AutoKMS crashing I think it still may be reactivating ok, but not sure since I can't seem to get Beta 4 logging to turn on and stay on no matter the settings I try (both within, and by manually editing the ini file outside, the Toolkit app). The ini settings in the main Toolkit folder get set fine and stick, but the AutoKMS ini file in the Windows directory keeps reverting back to the original settings after a system restart. So even if I manually edit the file to turn on logging, the setting keeps reverting to false upon system restart (even tho' the Toolkit ini file retains the true setting fine). I tried changing permissions on the AutoKMS ini file to read-only after changing the logging setting and, while the setting did stick that time, there was no log file generated in the Windows directory like with Beta 3. Anyway, I don't know if anyone else is getting the AutoKMS crash with Beta 4; I uninstalled it, rebooted, and reinstalled Beta 3 and it's working fine again.
Seems to be something wrong with the ini. Try deleting ini and running it. Listed this as a possible bug. Not sure what causes it as it will make its own ini if there isn't one. That crash since its ini means it crashed before it activated.
No, no difference with or without the ini; still crashes. I use Kaspersky Internet Security Suite 2011 and have a few problems with it blocking or interfering with certain pgms (such as Acronis Backup & Recovery 10) but I have excluded the Toolkit, AutoKMS.exe, and keygen.exe in KIS so that's not it (just thought I'd mention that; also excluded AutoKMS in Windows Defender). And, like I said, Beta 3 version of AutoKMS works fine. EDIT: I'm wondering if it's a timing issue between the creation and deletion of the emulator and/or host? Or being started from the registry vs a scheduled task as in Beta 3; don't know why that would matter except, perhaps, in timing? Of course, I don't know what else may have changed in the AutoKMS executable itself. Anyways, fwiw.
Thanks for your work. Now autokms beat4 get pass of AV. Is it possible when setting is default, .ini file will not creat ?
About the ini, it is created on install of AutoKMS based upon settings in toolkit settings app. The System.FormatException occurs for some reason with ini (even if ini looks fine). It fails befor AutoKMS makes its log or does anything. Reading the ini settings is the first thing it does. If the ini is deleted, AutoKMS will create a ini with default settings. I had this happen once and it was ini related. Can someone without problems with AutoKMS attach their ini (not paste, but actually upload the file). Replace yours with it. Also, you can run toolkit open settings, configure AutoKMS, and hit save and it will remake the ini.
Though I've seen that error once, I have not gotten it in BETA 4 Toolkit. It appears that I call the wrong function in AutoKMS though. I have a load default settings for toolkit and AutoKMS (AutoKMS has less settings) but I load all settings. AutoKMS could be crashing if it tries to load settings not in its ini file. I'll look at AutoKMS and reup BETA 4 with fixed AutoKMS. Also, I see AutoKMS is using defaults as it is trying to read settings.ini and not AutoKMS.ini. I believe I made the changes and forgot to save them. I myself am not crashing but its ignoring the fact I set logging to false.
@CODYQX4 Thanks for your tools. By the way, Can you do me a favor for telling me how I can activate manually ( I mean what command lines to enter ) Thanks in advance
I suggest you look at "Office Repo" manual activation. It lists some commands. The toolkit does it with WMI so you could not do it the same way (ospp.vbs does the WMI stuff, we cut it out as its a middleman to me). The ospp.vbs /act switch is activation but for KMS you would need to have keygen running and KMS host set to 127.0.0.1 (ospp.vbs uses the /sethst:127.0.0.1 switch for this).
@CODYQX4 Thanks for your hint. I'll give it a test. But I wonder the reason why KMS only lasts 180 days ..... Is there any ways that we can set up longer... or it will automatically reset after 180 days instead of doing it again ? Thanks in advance
Beta 4.1 gets it done. No AutoKMS crash with this one. Logging works now, too. 1st entry right after install; 2nd entry after system restart. Great work. Tks much.
Because MS coded it that way. KMS is intended for machines constantly connected to company network that can easily be reactivated (they retry every 7 days). Your best bet is AutoKMS which reactivates every boot (I assume you will reboot within a 6 month period). It is fixed in the reup'd beta and is one of the most effective KMS reactivators, as it only reactivates KMS, all the scheduled tasks that use /act will try to reactivate MAKs which is slow, burns down the count, etc. This makes AutoKMS way more efficient than a simple batch on a task.