Office 2010 Toolkit and EZ-Activator.

The Office Cleaner help you if you can't uninstall conventionally or it dies halfway through but I've yet to see one do a good enough job to allow reinstall and wind up in notifications mode if you were there before.

The one in the toolkit is based of the Microsoft Fixits for uninstall and they seem to get rid of all the obvious things but this isn't enough.

 

Yeah I laughed when I was expected to drop $200 for Home and Student (which doesn't even have Access or Outlook) after spending all my money on a new laptop, thankfully the internet allowed me to get Ultimate 07 for free along with any other app, or at least provide free/open substitutes.

 

That's what I bet, as I hunted down all license stuff. As a matter of fact License Delete already deletes all license stuff (which is just a drop in the bucket). There are file extensions (easier) and an inconceivable amount of CLSID entries which give no indication to their purpose yet nuking the wrong one could trash your OS. Whoever invented the registry in the first place should be shot. I'd rather every app store its own data in a file as it would make OS reinstalls so much easier if you could just save the needed INI's. Not to mention registry (Despite spread in several hives) is a single point of failure. I'd say every OS issue I've ever had has involved the registry.

 

Good news: It seems I've managed to restore backups after a reformat (still machine specific obviously).
Bad News: You need to know what key you used and I'm not sure if I can automate it.

If someone can come up with a reliable way to determine all digits of the key that will be a good thing. The PID in the registry is not good enough, but the PID displayed in Office 2010 apps might be. The registry one is a no go as it can be deleted or not update when changing keys or converting office.

Seems full auto should be possible if I had a way to obtain the keys, then I could just dump them to a file and use them when needed.

The part I'm kicking myself for is I removed Tokens Only Restore from V2.0.1 yet this method requires not screwing with the registry like a conventional restore, forcing me to readd it if this works.

 

[C#] Calculating an Office Product Key By Advanced PID is a topic I posted about this. Interesting thing is I can obtain Advanced PID (from Key Checker) via WMI, and this value unlike the PID, is unique, and certain parts of it don't actually matter (as the first 5 don't matter and there is a part tacked on it).

Unfortunately a key finder like Produkey reads DigitalProductID from the registry and does something to it but this value only updates when using setup.exe to change keys, and it can be deleted (and conversions are a no go either). So conventional (easy) means likely won't work.

EDIT: and the fact Office itself can display the partial key despite not keeping keys stored means it simply chooses not to reveal the whole key to make key theft hard.

 

I'm testing my new method as much as I can.

It seems it has allowed me several times to restore my MAK which the conventional method fails everytime. One thing that is an issue is that if the registry gets marked as tampered it does not work, but unmarking it (successful KMS activation) makes it work again. Since this is most typically for reformat+reinstall office people, they would not be broken right after Office 2010 install anyway. And EZ-Activator/Phazor are able to unbrick Office.

An act of desperation if we can't find any way to obtain the installed keys is to ask the user for them when making the backup, checking them against the installed keys (by stripping off the last 5 and seeing if they exist in activation status) and saying error if wrong. This still isn't a nice way though as I like automatic things. I could auto-add KMS keys to the list if KMS products are to be backuped since I know them all, if it comes down to this.

 

Ideally auto-obtain keys should be done, otherwise UI stuff would need added and would be a bit annoying. We'd validate keys by checking them against installed keys (only asking for non-KMS keys since we could simply see KMS SKU is installed and add thr appropriate key, same for Sharepoint Designer and Starter).

I really don't know how or if we can auto-obtain keys but we can get the Advanced PID easy but I don't understand how PIDGENX actually generates that info or how its used in the first place. Like I said "Produkey" checks a reg value which might not exist or be up to date.

 

Well I'm testing the implementation of the new backup method right now after I reinstall office (related to below). You'll have to hit checks to enable it much like you pressed a different button to do tokens only restore. All known keys will be auto-saved (KMS, Starter, Sharepoint Designer). Anything else will be asked for, and you'll have to enter any and all of them (most likely you'll have 1 MAK or something). I'll then dump them all into Keys.ini file and will only allow the new type of restore if it exists (otherwise you'll have to restore the old way). All builtin backup/restores (for AutoRearm, EZ-Activator, and rearm count) will not do the keys things as these Backups are done for temp purposes or purposes where a reinstall will not occur.

On a related note, I'm trying to simplify my License Repair code. I was calling msi files individually, and this gets complicated with H&B, H&S, Professional, and Starter as the first 3 use the same installer, and Starter is virtualized via Click2Run. By creating an XML file and calling Office setup.exe (in Office Setup Controller) with it, I can repair via that method. It also would prevent a theoretical issue where it seems Outlook and some SKU's actually have 2 possible MSI codes (but we only wind up seeing one in our Office DL's). I have to see if setup.exe method repairs as desired as I can just pass a name instead of an ID. I had to mess with SingleImage installer (H&B) to see some differences.

 

Not really, as having to enter your keys manually sucks. Still if it works it will be the only thing that can survive reformat.

It will work by me passing a new parameter to my current code (triggered by checkmarks). If false, restore as normal, if true, it does the new thing, installing keys from keys.ini (which are gathered during backup if set).

If we can find a way to determine the whole key reliably, then we won't have to ask for them.

 

OK the new trigger seems to be the difference between failing and rolling back and successful restoration of my MAK activation.

One thing I've done since it seems like some scenarios where I think office is bricked (when messing around with this kind of stuff), it isn't.

I've used "No Keys Installed" as the sure tell tale sign of failed backup/bricked office. However sometimes you simply can reinstall the keys and have the same status.

This makes use of a "Verbose" Check Activation. I added a setting to effectively to what /dstatusall does (list all installed licenses which are the type of keys can be installed). This mode allows me to troubleshoot better.

A problem I had is I wasn't checking the difference between no keys installed and totally screwed office. I use this line of text "<No installed product keys installed or possible license error>" (hidden when restoring but checked by me) to determine totally shot office (which requires repair + reactivation), but I was determining this on the lack of keys installed. By checking if licenses are installed (Listed as Unlicensed as no key is installed for them), I say "<No installed product keys detected>", if licenses are installed but keys aren't. The difference between the two is the latter may just require a key reinstall of the keys you used and you still have whatever activation you had, where as you are screwed if you get the or possible license error.

I determined this as I backed up 180 KMS activation and toggled Verbose mode, and saw that a true brick after I corrected the code will not detect any products even in verbose mode, where as if I detect things in verbose mode office is not bricked, I then reinstalled KMS key and all way well (This is when I tried restoring MAK without new method and it fell back to old backup failsafe) afterwards I reenabled the new tool and that made MAK work.

So what I'll do is if I detect the nonbricked no keys after restoring failsafe state to reinstall the keys.

 

To anyone else looking into improving backups or using backup like methods:

The fact that this new method works on reinstall OS yet the old method doesn't (even when using the exact same backup), means that the Trusted Store (the OfficeSoftwareProtectionPlatform reg key AKA OfficeSPPInfo.hiv (Toolkit/AutoRearm) or Backup.hiv (IORRT)) is responsible for holding whatever is at fault for the original method not working.

Just so everyone knows what the new method is (It's not really new):

Do you remember people using a script to copy over BETA activated tokens (plus some other crap that frankenbuilded it which is bad) and reinstall their beta MAK key?

Basically you do a tokens only restore (I scrapped it from the toolkit), then reinstall what keys you had when you took the backup. I store them in Keys.ini yet keep the backups such that this method or original method can be used. One thing to keep in mind is it's better the old way when restoring on a PC that you didn't reinstall OS (as in IORRT/AutoRearm should NOT use this new method as it makes things harder for no reward as you must have the keys and reinstall them). This is advised for MAK users to take backups with Key Save as this has gotten me my MAK activation back that I thought reinstalling Win 7 via SP1 disc would cost me forever.