Update to Office 2013 Appstack breaks activation

[jpm2686]

It appears that performing an 'update' to the Office Appstacks may break activation. I'm guessing this is due to the KMS product key getting wiped out in the process. Since end users have no rights to modify the Office product key, let alone activate office, we are left with one option which is to create a new Appstack, install Office fresh, then apply the new Office patches. The same goes for updating Office Appstacks to include third party plugins.

Has anyone else seen this and know of a sensible solution outside of installing the Office apps within the parent image (and introducing many more pools to manage)?

[Jason_Marshall]

Updating an AppStack containing Office may cause a reconfigure to occur. Currently only a fresh provision of Office with updates will keep the license consistent and not cause to reconfigure.

[Ray_handels]

We had somewhat of the same problem with installing RSAT in an appstack. It did not disable the activation, it reactivated and thus created 2 activations which subsequenlty caused a corruption of the security database.

What we did is remove the Office Software protection platform service altogether before starting the sequence so it could not update the KMS license. I have no idea if this works while installing office updates but it's worth a shot.

[jpm2686]

Can you or anyone else elaborate on this? I would like to know if it is supported to modify the Office Software Protection Platform service and how to go about it to support building and updating an AppStack. For example, would I start the provisioning process, then set the Office Software Protection Platform service to 'disabled' throughout the install and subsequent updates and set the service back to 'manual' at some point later on? At what point would I run the commands to setup KMS activation (/sethst, and /act) - would this be done once or during every update to the AppStack? I really wish VMware had documented the whole Office activation process better - they appear to have gone out of their way to develop a few scripts to assist in Office activation, but unfortunately they don't seem to be able to handle the 'update' process well.

[Ray_handels]

If you install KMS into the golden image than that is the place to activate the software. If you have a writable volume my assumption is that it will eventually end up there but maybe Jason can elaborate on that?

Also, KMS activation is for 180 days, after 90 days (to my knowledge) it starts to update the license. What i think works best is to do a /act while updating the golden image where Office applications reside in. If in an appstack, that;s a good question. As said, i think it will be added into the writable volume or activated right after you start an office application.

regarding the Office Software protection service. It depends on were Office resides i guess. We have it installed into the base image. So the service is already in the golden image. I just delete the service alltogether just before i start the provisining process. If you would remove it during the provisioning process you could end up with a machine that doesn;t have the service at all and office will never actually activate itself.

[Jason_Marshall]

Ray you are correct and if using a Writable that can complicate the issue but we have some rules in place to prevent the activation from going to the Writable.

[chriskoch99]

Jason -- Can you elaborate on that?  We're having trouble with Office 2013 activation and users who have Writable Volumes.   Disabling the WV always fixes it.  In what AppVolumes version did these rules get introduced?  We're running 2.6 right now... planning to upgrade to 2.10 soon.

Thanks!

[VDIMega]

In my experience, if you didn't manage the activations properly to begin with, after four updates to a kms office appstack, you end up having to dispose of that appstack and make a new one.

By "manage properly" I mean re-arming the Office activation as the last step before closing an updated appstack.

It may also be necessary to force an office activation as part of the startup.bat script in the appstack too.  This is because in some instances I've found that after the appstack gets attached on login, Office doesn't activate on its own, triggering an office reconfiguration/repair.  This process takes about 15 minutes total if you add up Viso+Project+Office, and annoys users.  However, when I activated office by command line before opening it for the first time, I was able to avoid the auto reconfig/repair.

I struck out the lines above because if what Jason says is true, the inconsistent activation behavior is due to some pre-existing office activation stuff lodged on the actual main drive of some of my desktop VMs.  My desktop VMs don't refresh on logoff, they only refresh once a month, or on-demand as needed.

Jason (or another available VMware expert), can you comment on this please?

[Jason_Marshall]

If using 2.10 you should NOT launch or rearm Office as part of the update or provisioning. There are additional tools added to the provisioning process to assist with this now.

[VDIMega]

Is there an official guide on how to provision Office 2013 in 2.10?  Reading around the web about the different requirements and anecdotes for different versions of App Volumes makes it hard to know the right way to go about it.

[VDIMega]

I followed your advice and now Office 2013 activation doesn't break, but every so often, after a user logs in, he's prompted with the long "Configuring Office 2013" window because Office didn't activate correctly.

So now users get a properly activated office 2013 on 95% of the logins, but not 100%.  our machines refresh after every logoff, so its not that something is getting stuck on the actual C:\ drive of the VM.

The C:\Program Files (x86)\CloudVolumes\Agent\Logs\cv_startup_postsvc.log log file shows the office GVLK keys being applied whenever this works, but when it doesn't work it just says:

14:30:42.866 svoffice Windows 7 Enterprise  6.1.7601  64-bit

14:30:42.881 svoffice NoRereg start 2016-05-05

14:30:42.897 svoffice NoRereg end

and that's it.

Ideas?