Solved Office 2010 Intermitent KMS Activation Fail after image
TL;DR - After imaging office 2010 fails to activate and can’t be activated, is fixed by re-imaging.
So I have been having a really weird problem recently.
It’s only happened 3 times out of the last 13 computers imaged in the last few weeks, but 2 of those were yesterday.
Here’s what goes down.
I image the computer and all seems to go well. But then I try to open any Microsoft Office 2010 program. It pops up and then after a second or two it pops up an error about office activation failing and a repair attempt failed (the office 2010 setup splash screen pops up and disappears right before that)
If I go to the kms server and look at VAMT, I can add the host and update the license status and the kms server successfully activated windows 10 no problem but it doesn’t even see Office 14 (2010) as an activated device.
I played with the office ossp.vbs activation tool to manually add the kms host and port and attempted to activate but it keeps claiming no key is installed. I tried to use ossp.vbs to manually install the GVLK kms client key and it says the key is invalid. I tried adding it in the command line with and without dashes to no avail. Tried a MAK key too that also is claimed to be invalid, but I know that both keys are valid. I tried to look at the cmid (client machine id) and it says it doesn’t exist.
In the event viewer there was some error about not being able to register to proof of purchase or something like that.
Now here’s the kicker. The quickest way to fix this is to just re-image it and then it works. So why would sometimes office work perfectly fine and other times not so much. Could a weird network error cause this, like a part of the image doesn’t make it to the computer?maybe the ethernet cables are just that old? The first time this happened I had discovered the machine was plugging into the network with a cat 5 cable and we just upgraded the switch to a gigabit switch, so I swapped it out with a newer cat 5e so it could image faster and that’s when I discovered after reimaging the problem was fixed. The first time this happened I was unicast imaging 2 other computers that both worked fine. But when it happened yesterday the computers were being imaged individually.
I’m already trying to fix this on the image configuration level by completely uninstalling all office programs and reinstalling them clean to make sure the built in repair mechanism can open if it happens again.
So this problem definitely relates to a windows xp to windows 10 file transfer issue and is nothing to do with fog.
From what I found here http://helpdeskgeek.com/office-tips/fix-office-2010-cannot-verify-license-error-message/
I discovered that the file tokens.dat is indeed a part of activation.
If you happen to have a similar problem…
stop the service osppsvc
Delete or rename tokens.dat and cache.dat found at C:\ProgramData\Microsoft\OfficeSoftwareProtectionPlatform
Start the service osppsvc
Open any office program and let it do the self repair
This also fixes the problem of the office installer autoclosing when trying to repair or uninstall.
So I thought I had this figured out, but then it happened 4 more times.
While re-imaging only takes about 5 minutes, plus the time to restore the user’s files, It would be nice if I could find a way to prevent this weird anamoly
@ch3i Thanks, I read that too. However having now fixed that up and enforced ntp domain server settings with a gpo, I think it fixed it.
That and I discovered there was a token based activation .dat file from xp that was trying to restore when the error happened. So it may have been a mix of a few things. But I believe I remedied the issue and it wasn’t related to Fog at all. It was either my network time settings or my migration from xp to windows 10 restore snapin trying to restore something. (Located here from xp…
So if this happens to anyone else, check your time settings, set a internet time setting on your image, follow this guide if you need help with a active directory ntp setup http://blogs.technet.com/b/nepapfe/archive/2013/03/01/it-s-simple-time-configuration-in-active-directory.aspx
and don’t backup the above mentioned file when migrating from xp.
@Arrowhead-IT Hi, not sure but by default the tolerance is 5 minutes (based on best practices for Kerberos)
I have a new theory that I’m testing. I was troubleshooting an unrelated issue that may relate to time settings and it looks like my AD clock is like 2 minutes slow. I didn’t look at the time on the computers that broke, but I have seen the clock be wrong on an imaged computer once or twice.