Jump to content


Photo

XA 7.6 Deployment Failure Error : Image Preparation Office Rearm Count Exceeded

Started by Neal Carter , 26 November 2014 - 02:48 PM
38 replies to this topic

Ludwig Riess Members
  • #21

Ludwig Riess
  • 5 posts

Posted 04 October 2016 - 12:13 PM

We are having the same issue.

At the weekend, we updatet our VDA from 7.6 to 7.11.

Now we have Problems with Office rearming when we use MCS

We found following Problem:

Software protection service takes too long to start.

 

But we found no solution till now. Hope somebody can help.



Vincent Raffy Members
  • #22

Vincent Raffy
  • 3 posts

Posted 04 October 2016 - 01:27 PM

I got this issue as well, when I upgraded from 7.8 to 7.11

 

My workaround: I just recreated a new machine catalog without any new features (I didn’t configure a cache for temporary data) and for the moment my problem has been solved without any action.

 

has anyone ever tried this solution?



Joe Marriott Members
  • #23

Joe Marriott
  • 24 posts

Posted 08 October 2016 - 02:54 AM

same issue here after updating vda from 7.6FP3 to 7.11 on a 2012R2 image with Office 2013. 

 

recreating catalog didn't fix it for me.  

 

office is activated in image and re-arm count has 3 remaining.  Tried manually rearming image before updating catalog and also not rearming, neither worked.  

 

dont want to disable MCS office rearm globally because its working fine for other machines which haven't been updated to 7.11 yet

 

renaming the office rearm files/folder sounds like it will break something else so would prefer not to do that



Mark DePalma Members
  • #24

Mark DePalma
  • 87 posts

Posted 12 October 2016 - 03:48 PM

I had this same issue in my brand new XA 7.11 site. I could easily have shifted my OS/Office rearming to my sealing script I am using to prep the image, but I wanted to solve the mystery... So here is what I did:

 

Disabled auto shutdown (from a controller):

Set-ProvServiceConfigurationData -Name ImageManagementPrep_NoAutoShutdown -Value $true

 

Turned on Machine Identity Service Agent logging in base image:

Set HKLM\SOFTWARE\Citrix\MachineIdentityServiceAgent | Logging=1 (DWORD)

 

Created a test catalog with this image

 

When booting up I saw the failure in the C:\image-prep.log file. The log file pointed to "System.Runtime.InteropServices.COMException (0x8007041D). This code is for a service not starting in a timely fashion.

 

Checked Event Log and sure enough the "Software Protection" service had failed to start because it timed out. This service is crucial to activation related tasks.

 

The default timeout setting for Windows services is 30000ms (or 30 seconds), so I bumped this up to 180000ms (or 3 minutes) via registry in my base image:

Set HKLM\SYSTEM\CurrentControlSet\Control | ServicesPipeTimeout=180000 (DWORD)

 

No more Office KMS related failures after doing this. I'd urge anyone who is having this issue to turn on logging and check their image-prep.log file for this issue.



Joe Marriott Members
  • #25

Joe Marriott
  • 24 posts

Posted 17 October 2016 - 07:06 PM

in our case the error only occurred if office 2013 was activated in the image prior to updating the MCS catalog.  We had a 2012R2 7.11 VDA mage the couldn't reach the KMS server and there wasn't any issues deploying it with MCS.  That was until the KMS communication was sorted out, then the next time the image was updated, the MCS deployment failed due to office activation failure.



Thomas Østergaard Members
  • #26

Thomas Østergaard
  • 2 posts

Posted 22 November 2016 - 01:15 PM

This solved the problem. Thanks Mark. :)



Christopher Yue Members
  • #27

Christopher Yue
  • 741 posts

Posted 25 November 2016 - 12:21 PM

I had this same issue in my brand new XA 7.11 site. I could easily have shifted my OS/Office rearming to my sealing script I am using to prep the image, but I wanted to solve the mystery... So here is what I did:

 

Disabled auto shutdown (from a controller):

Set-ProvServiceConfigurationData -Name ImageManagementPrep_NoAutoShutdown -Value $true

 

Turned on Machine Identity Service Agent logging in base image:

Set HKLM\SOFTWARE\Citrix\MachineIdentityServiceAgent | Logging=1 (DWORD)

 

Created a test catalog with this image

 

When booting up I saw the failure in the C:\image-prep.log file. The log file pointed to "System.Runtime.InteropServices.COMException (0x8007041D). This code is for a service not starting in a timely fashion.

 

Checked Event Log and sure enough the "Software Protection" service had failed to start because it timed out. This service is crucial to activation related tasks.

 

The default timeout setting for Windows services is 30000ms (or 30 seconds), so I bumped this up to 180000ms (or 3 minutes) via registry in my base image:

Set HKLM\SYSTEM\CurrentControlSet\Control | ServicesPipeTimeout=180000 (DWORD)

 

No more Office KMS related failures after doing this. I'd urge anyone who is having this issue to turn on logging and check their image-prep.log file for this issue.

 

Just found this post as I am experiencing the same issue.

 

The solution fix appear to be extending the time out as follows:-

Set HKLM\SYSTEM\CurrentControlSet\Control | ServicesPipeTimeout=180000 (DWORD)

 

Can you advise if I should  rename back the file OSPPREARM.EXE found in C:\Program Files (x86)\Microsoft Office\Office 15?



Mark DePalma Members
  • #28

Mark DePalma
  • 87 posts

Posted 25 November 2016 - 03:35 PM

Just found this post as I am experiencing the same issue.

 

The solution fix appear to be extending the time out as follows:-

Set HKLM\SYSTEM\CurrentControlSet\Control | ServicesPipeTimeout=180000 (DWORD)

 

Can you advise if I should  rename back the file OSPPREARM.EXE found in C:\Program Files (x86)\Microsoft Office\Office 15?

 

No, no need to do that. That was just a hack to avoid the rearm altogether. OSPPREARM.EXE is what VDA runs to rearm Office. Extending the service timeout is the fix.



Christopher Yue Members
  • #29

Christopher Yue
  • 741 posts

Posted 25 November 2016 - 04:04 PM

Thanks Mark,

 

Just to clarify, once i have changed the timeout, I can revert to using the OSPPREARM.EXE as is.

 

Is that correct?

 

Right now I have renamed it as OSPPREARM.OLD so it can be ignored for MCS purposes.



Mark DePalma Members
  • #30

Mark DePalma
  • 87 posts

Posted 25 November 2016 - 08:05 PM

Thanks Mark,

 

Just to clarify, once i have changed the timeout, I can revert to using the OSPPREARM.EXE as is.

 

Is that correct?

 

Right now I have renamed it as OSPPREARM.OLD so it can be ignored for MCS purposes.

Yes, that is correct.



Mihails Rumjancevs Members
  • #31

Mihails Rumjancevs
  • 2 posts

Posted 18 January 2017 - 09:45 AM

I will add my 5 cent to this tread:

Have XenApp 7.9 together with App-V deployed office 2013 MAK license. By some reason, that is out of scope of this tread, MCS started to fail with update of servers from template. Stating: Office Licensing Rearm failed

Advice with renaming OSPPREARM.EXE helped.

Thank you everyone for advised options.



Jorge Rodríguez Ocaña Members
  • #32

Jorge Rodríguez Ocaña
  • 51 posts

Posted 20 January 2017 - 11:40 AM

I will add my 5 cent to this tread:

Have XenApp 7.9 together with App-V deployed office 2013 MAK license. By some reason, that is out of scope of this tread, MCS started to fail with update of servers from template. Stating: Office Licensing Rearm failed

Advice with renaming OSPPREARM.EXE helped.

Thank you everyone for advised options.

 

Have you tried to increase the timeout value?? Even for VDIs to get registered it's good to increase this value...



Mark DePalma Members
  • #33

Mark DePalma
  • 87 posts

Posted 24 January 2017 - 01:28 PM

I will add my 5 cent to this tread:

Have XenApp 7.9 together with App-V deployed office 2013 MAK license. By some reason, that is out of scope of this tread, MCS started to fail with update of servers from template. Stating: Office Licensing Rearm failed

Advice with renaming OSPPREARM.EXE helped.

Thank you everyone for advised options.

 

Definitely look at the timeout value. This is the proper way to solve this (if it is the issue). I laid out the steps for diagnosing the issue in an earlier post in this thread.



Simen Jacobsen Members
  • #34

Simen Jacobsen
  • 2 posts

Posted 08 March 2017 - 12:13 PM

Thanks Mark, the timeout value worked like a charm. I have XenApp 7.12.



Tim Husar Members
  • #35

Tim Husar
  • 19 posts

Posted 24 March 2017 - 05:45 PM

I had this today after an upgrade from 7.6 to 7.9. This Solution works!

THANK YOU



Vinoth Kumar Members
  • #36

Vinoth Kumar
  • 9 posts

Posted 11 May 2017 - 08:10 AM

Step 1    Ran Set-ProvServiceConfigurationData –Name ImageManagementPrep_Excluded_Steps –Value “OfficeRearm” 

Step 2   Renamed OSPPREARM.EXE on master to OSPPREARM-ACCESSRT.EXE

 

Step 3   start this service AppX Deployment Service(AppXSVC) on application server
 

Step 4   Created new Snapshot, shut down Master Image

 

 



Mark DePalma Members
  • #37

Mark DePalma
  • 87 posts

Posted 11 May 2017 - 12:12 PM

Step 1    Ran Set-ProvServiceConfigurationData –Name ImageManagementPrep_Excluded_Steps –Value “OfficeRearm” 

Step 2   Renamed OSPPREARM.EXE on master to OSPPREARM-ACCESSRT.EXE

 

Step 3   start this service AppX Deployment Service(AppXSVC) on application server
 

Step 4   Created new Snapshot, shut down Master Image

 

Not sure what you are trying to do here. You disable rearm in Citrix and then also rename the rearm executable. When is your image getting rearmed then?



Tu Vu Members
  • #38

Tu Vu
  • 5 posts

Posted 28 July 2017 - 06:40 PM

Running Xendesktop 7.12 and had problem with Office Rearm. Thanks to Mark DePalma about modifying "ServicesPipeTimeout". This solution works!!!

 

 



David Ott Members
  • #39

David Ott
  • 58 posts

Posted 06 September 2017 - 12:29 PM

Increasing the timeout did not work for me.  Renaming OSPPREARM.EXE fixed it.