MCS Failing - Office Licensing Rearm Failed

[Terry Rebstein]

Hi, 

 

I've been working with support on this a little but not having luck yet. Was hoping maybe to see if anyone else may have some suggestions.

 

The scenario is a new W2K16 based Session Host with Office 2016. The app layer was prepared according to the recipe and we've checked the flag files and kms files etc. It all appears to be in the right place.

 

What happens is that the image template is deployed with the MCS connector and the snapshot auto created by App Layer ELM. Then when deploying via MCS, MCS fails with a "Office Licensing Rearm Failed". I have had some success powering on the image confirming everything looks healthy (windows activated, office activated) then shutting down and creating a manual snapshot which then deploys via MCS successfully. However I updated my OS layer and no other changes (just removed the previous windows versions via disk cleanup) and then tried deploying again. This time, neither the app layer snapshot, nor my manually created snapshot worked.

 

We are trying a Win10 image and having a similar experience (MCS fails). I've seen about bypassing the MCS rearm step but I am hesitant to make a global site setting that affects everything because one new image is broken.

 

When logging into the image created by app layering, everything looks healthy and activated. I do not open any office applications.

 

If I do the same thing and publish an image without office it all works.

 

Any help is appreciated. 

 

Some reference docs I've reviewed:

https://support.citrix.com/article/CTX224900

 

https://support.citrix.com/article/CTX223245

 

More info:

Broker version XenDesktop 7.9

VDA 7.11

[Rob Zylowski1709158051]

Terry I have seen in three cases where even though Office was activated and windows was activated on the master image they had to rearm the image before updating the catalog.

 

So first question does your master image have windows and office activated?

 

If they are then try running slm gr /rearm, shutdown and update the catalog.  See if that works.

 

Rob

[MBi]

Try to rename "C:\Program Files\Common Files\Microsoft
Shared\OfficeSoftwareProtectionPlatform\ospprearm.exe" (path can be different depending of yout version of Office) in you layer.

The error should disapear and Office should work properly. In my case it works and I am using KMS activation.

[Rob Zylowski1709158051]

PS I just noticed the different VDA version from DDC version.  I dont know if that also might have some effect.  It might be good to ask MCS support about that if my suggestion above doesn't help.  Also you can disable the checks in MCS so it will publish the image anyway and see if that works.

[Terry Rebstein]

Thanks Rob, to make sure we're talking the same thing:

 

Master Image = Image template generated from the ELM (App Layer final Output)

 

If that's the case, have you seen scenarios then where a user would need to consistently power on the generated image template, power it on and run a command, shutdown and snapshot  prior to rolling out via MCS? It's not a big step, but it does differ from how I thought App Layering usually works. Or is there always a way to resolve it once identified why the extra rearm is necessary after publishing.

 

Second question, the slmgr /rearm would only affect the Windows activation correct (not office)? If my issue appears to be specific to Office Rearm failing (as reported by MCS) then I would need to run cscript ospp.vbs /rearm after powering on the image template in that case?

 

Appreciate the feedback

[Rob Zylowski1709158051]

Hi Terry,

 

Yes the master image is the same as a published image.  Master image is the Citrix Term, published image the app layering term.

 

You woudl think the error woudl be for win activation but i havent found it easy to correlate the errors so its worth a try.

 

Its also very easy to add the slmgr /rearm to a script if you need it.  When we publish the image we boot the VM and we shut the vm down with our startup scripts.  Basically we inject a file and if that file is there the system is shutdown.

 

If you add a layer script that does this you can have it always run the command only during that first boot of the image

 

 

    IF NOT EXIST SomeFIle_Done (

          echo log something to a log file>Alogfile.txt

           slmgr /rearm >aLogfile.txt 2>&1

           echo We Ran Rearm>SomeFile_Done

    )  

 

So it will only run once then if somefile_done is there it wont run again.

 

But first jut try to rearm you mater image vm and update the catalog with it.  AGins assuming both windows and office are activated.  They must be activated for the regular process to work.

[Terry Rebstein]

Update, hopefully this maybe provides some more insight?

 

Failed to deploy via MCS, tried powering on and verifying office and windows activated, shutdown and failed to deploy via MCS again.

 

Fresh boot from app layer auto-created snapshot:

slmgr /dlv - shows activated

slmgr /rearm - succesfully completes, requires restart for changes (no restart done)

 

Shutdown and created new snapshot and deployed via MCS which failed.

[Rob Zylowski1709158051]

SorryI have nothing for you then.  I would open a ticket with the MCS support team. 

[Jens Loecke]

Hi All,

 

I had the same problem in a customers environment. In my case, it seems to me, for MCS rearm process to work, Office and OS of the Master Image should both be activated. In Case of using App Layering the deployed Image Template will always be a new vm which is used as new master images for MCS.

 

Upon first boot of this new vm the OS reports a massive change of Hardware and therefore looses the activation of Office and the OS.

 

MCS then runs into the errors. "Office Licensing Rearm failed" and "OS licensing rearm failed"

 

Only Workaround at this moment will be to start the newly deployed Image Template vm which we want to use as new master image and let Windows and Office activate. Then shutdown the vm and update the Machine catalog.

 

Adding a layer script like Rob said might automate this workaround.

[Terry Rebstein]

Interesting, we were finding this as well, where if we powered on the VM, shutdown then manually snapshotted it, we could then deploy via MCS. Unfortunately, it's been inconsistent in that after some new layer versions, our manual process breaks as well whcih leaves me stuck...

[Terry Rebstein]

Thanks, I was thinking about trying the ospprearm rename (based on an older MCS doc) I'm just wondering if it will impact he final state of activation in my finam MCS catalog deployed  VM's,. Wouldn't MCS need to rearm Office so the Vm's all come online with unique CMIDS?

 

When you do this in the Office App Layer, is it done when Office is activated? Or after running Rearm first? What state should office be in, once i rename the file?

 

Alternately, I was considering renaming the file in the Image template and then shutting down and creating the manual snapshot. This would mean Office is in an activated state right before being shutdown and having the file renamed. It's interesting to hear you had success doing this in the app layer as I would have thought it would interfere with the Unidesk scripts perhaps.

 

I may give it a shot anyways

[Terry Rebstein]

As an update the renaming of the ospprearm.exe did seem to work for us when doing it in the image template deployed from app layering. We then shutdown and created a new snapshot.

 

Will try doing it in the office layer next and see if we can skip the extra manual snapshot.

[Satoshi Kubo]

On 9/6/2017 at 9:24 PM, Rob Zylowski1709158051 said:

If they are then try running slm gr /rearm, shutdown and update the catalog.  See if that works.

 

We resolved the same issue by this slmgr /rearm before updating catalog from MCS.

As an additional step, we needed to create a snapshot from vSphere after shutdown.

 

1) App Layer ELM - Publish image template to vSphere

2) vSphere - Start published VM

3) VM - Sign-in as local admin and run slmgr /rearm (elevated cmd)

4) VM or from vSphere - Shutdown

5) vSphere Create snapshot

6) DDC - Update catalog with the snapshot