Rearming Office should be a permanent fix. When installing Office, make sure you do not run any of the apps as that will activate Office on your master machine. Using ospprearm should clear out the activation. You could also run a repair of your Office suite which will accomplish this (and then some).
I've never had an issue with Office activation that wasn't solved by rearming, repairing, or clean install and not running the apps in my masters with any version of the Office suite.
Are you install Office with an ODT file to configure it?
No, I did not use an ODT to install Office.
So I ran the rearm on the image for office, created a new snapshot and recomposed the desktop. I have logged in/out several times and Office says it still needs to be activated. Should I see this activation happen right away?
Yes - Office should pull it's KMS key as soon as it's executed and activate.
From a command prompt within a linked-clone try running "nslookup -type=srv _vlmcs._tcp"
Does this return the record to the KMS server?
Thats a good thing to check, before we switched to AD activation, someone installed there own kms server and overwrote that key. If it did change make sure that the dns security is set correctly to prevent rogue kms servers from popping up.
Yes. When I type that command the two KMS servers we have are listed. Earlier this year, we setup a new KMS server on 2016 but realized that Office 2010 would not be able to use that server for activation so we took one our 2008 servers (previously a DC) and set that up with the KMS key for Office 2010. That server is listed first when I type the nslookup command.
However, Office is still not activated.
Few things to try using the "ospp.exe" tool from within the Office install path. All from the command prompt:
1) cscript ospp.exe /act - This will attempt to activate Office. If this succeeds, then you are most likely polling the wrong KMS server for automatic activation which leads into #2.
2) cscript ospp.exe /sethst:<servername>. If your port is non-standard (not 1688) use the /setprt:<port#> option also. Then try with the /act option.
2b) I'd recommend running ospp with the sethst option in your master image as that will set the KMS host for Office in your image.
Side question - are physical installs of Office 2010 working?
Thank you for these suggestions. I will try them right away.
Just to confirm, I am running the commands on my image where Office 2010 is installed, correct?
Side question answer - Yes, physical installs of Office 2010 are working without issue.
Probably try it from your linked-clone first. If #2 works, then run those commands, minus activation, in your image and push an update to your pool.
Ok so here are the results.
1) cscript ospp.exe /act produced this result:
2) cscript ospp.exe /sethst:<servername>:
Then try with the /act option (same result as before).
So, even though the results are the same before and after running the /sethst command, should I proceed with running that on my image and then recompose?
Also, just to confirm we are using Instant Clones and not Linked Clones.
This doesn't seem to be an issue with your instant clone, this looks like an issue with the KMS service (or at least connectivity to the service). Might want to check firewall port connectivity between systems on your clone subnet and the KMS server. Make sure TCP 1688 is open in both the Windows firewall on the KMS and on the network the KMS server is on.
Also verify that the Office Volume Licensing Pack is installed on your Office KMS system, but since other activations are working, I don't believe this is the case.
Since Office 2010 activation is working on physical devices (which would use the same KMS server as the virtual desktop), it doesn't seem like it would be anything to do with the KMS server...???
I did confirm that TCP 1688 is open in the Windows firewall on the KMS server. Will check with the our network person on the other suggestions below.
On the KMS server in the event logs, are you able to see the KMS request come in?
That is the correct log to be looking at.
As for your image, that means that your master cannot get to the KMS server either. Try installing a telnet client in your master and attempting to telnet to 1688 on your KMS server.
So...doing the whole Telnet exercise helped me to discover that my image was not resolving my KMS server to the correct IP Address. For some reason I had hardcoded our KMS server name/IP Address in the hosts file on the image (not sure why I had done this). Normally this wouldn't be a problem however back in August we changed the IP Address of that server due to an upgrade to our DCs. That particular server was previously a DC but was demoted when new DCs were built on 2016. Now the only reason that server exists is for activating Office 2010 via KMS.
After making the change I recomposed my desktops and now an interesting thing happens. When I first open an Office product and look at licensing, it says the "product activation required" and running the cscript ospp.vbs /dstatus command I see the below:
However, if I close the application (Word, Excel, etc.) and then reopen it, it is then activated. If I run the ospp.vbs /dstatus command after it has been reopened, the status now says LICENSED with remaining grace be 180 days; see below.
Its like there is a delay...any idea why this would be?
Thank you SO much for all of your help with this issue!