Jump to content
Welcome to our new Citrix community!
  • 0

Layered Image - Office 2016 Will Not Activate On First Boot


Jeff Perry1709155334

Question

Hypervisor: Nutanix AHV 5.52

Provisioning Method: MCS (XenDesktop/XenApp 7.15 CU2)

OS Layer: Windows 10 Enterprise x64 (Build 1709)

App Layer: Office 2016 Pro Plus x86

ELM Version: 4.12 (Upgraded from 4.11 where issue was also present)

 

I'm relatively new to app layering. Have looked at many many guides on how to publish Windows 10 & Office 2016, but have not yet successfully deployed an image where Office 2016 will activate properly.

 

Suspected issue: Across all the Win10/Office2016 images I've published from many many iterations of deleting & creating OS layers & Office App Layers & applying fixes & suggestions found online, I seem to always hit the following wall..   I verify after logging in to the resulting provisioned VMs & checking the ActivateOffice_log.txt file, it shows, what I assume is the \FromLayer\data.dat file did not copy to the store (Access Denied). This is not the same error many others see when logging in too early before the activation scripts run, stating it is in use by another process.

 

Here's what the script shows:

 

7/19/2018 3:41:43 PM - Wait for Service 'sppsvc' to get to State Stopped

7/19/2018 3:41:43 PM - Service 'sppsvc' State Stopped

Thu 07/19/2018-15:41:43.56- Copy the files from the layer into the 2.0 directory

Access is denied.

        0 files(s) copied.

        1 file(s) copied.

 

Further down it states: The Software Licensing Service reported that the product key is invalid.

Then further down, "<No installed product keys detected>.

 

If I reboot the VM via the OS or Hypervisor (so MCS doesn't reset it), Then office activates fine (I do not see additional file store file copy entries in the ActivateOffice_log.txt file.

 

If I shutdown & startup via Studio controls (VM is refreshed) it again fails office activation.

 

If I manually grab the \FromLayer\data.dat & overwrite the data.dat in the store, I am able to instantly see ospp.vbs /dstatus return information stating it's in NOTIFICATION mode. Then a simple ospp.vbs /act successfully activates it.  If I then drop the data.dat (that I just overwrote) into the store & check office activation, it goes back to "No installed product key".

 

I know the startup script which runs kmssetup.cmd runs as the system account (from what I know about start up scripts in windows).

I did verify the SYSTEM account does have full control of:   FromLayer folder, SPP\Store\2.0 folder, data.dat file, FromLayer\data.dat file.

 

 

A few notes on how I configured the image:

 

Created OS Layer:

* Installed Nutanix drivers & hypervisor tools.

* Updated windows to 1709 (deferred 1803 & disabled auto-update via local policy).

* Installed .net 3.5

* Disabled IPV6 in NIC & registry

* Disabled Windows Defender via registry

* Disabled Windows Maintenance via registry

* Removed recovery partition & Windows.old

* Installed App Layering OS Machine Tools (4.12), hit USE KMS

* Used Citrix Optimizer & Optimizer supplement for App layering & used mostly default settings to optimize.

* Ran Citrix App layering Image Prep Utility in C:\Windows\Setup\Scripts\

* Performed the following KMS actions:

       > slmgr /skms kmshostname.domain.com (specified my kms host)

       > slmgr /rearm

       - Rebooted the machine

       > slmgr /ipk XXXX-XXXX-XXXX-XXXX-XXXX (Used the GVLK key for Win 10 ent)

       > slmgr /ato

* Ran the JGSpiers App Layering Image Prep script (which handles various tasks including NGEN UPDATE for all packages).

       - Note: I recently started using this script... has not changed the symptoms.

* Verified kmssetup.cmd appears only once in startup scripts in the registry.

* Shutdown & finalized.

 

 

Created Office Layer

* Installed Office 2016 (omitted Publisher, OneDrive?, and Skype)

* Enabled windows update & installed all available office updates.

* Disabled windows update.

* Ran the RunOptimizer.cmd as Admin.

* Selected "Activate MS Office via KMS"

* Selected Office 2016 Pro Plus

* Clicked "Save  A-K"

* Ran Office2013Windows81_PREP.cmd script as Admin.

* Again ran the JGSpiers App Layering Image Prep Script

* Rearmed office.

* Shutdown & finalized.

 

 

Created Platform Layer:

* Installed VDA 7.15 CU2

* Renamed the host.

* Joined Domain (moved machine account to proper OU, then rebooted)

* Logged on as domain user, rebooted, logged on with local admin & deleted the domain user profile.

* Installed Receiver 4.9 LTSR with SSO enabled.

* Again ran the JGSpiers App Layering Image Prep Script

* Shutdown & finalized.

 

 

Here's something I don't quite understand about this issue...

In most of the images I've deployed in the weeks I've been troubleshooting this issue, If when I create the template, I select Elastic Layering: Application Layering, the exact issue described above is present.

If I set Elastic Layering to NONE, Office 2016 seems to activate right away, but throws a rearm error in MCS when creating the Machine Catalog.

To be clear, I'm not trying to elastically assign the Office layer.. just enabling the ability to use elastic layers with the resulting image.

 

Getting a bit frustrated with App Layering..  My first run out of the gate & vanilla Win10 / vanilla office 2016 just will not work, following any of the published guides.

 

Thanks for anyone who has any ideas on this one..  

 

 

Link to comment

23 answers to this question

Recommended Posts

  • 0

The service holding open the DAT file is the Office Software Protection Platform Service.  In Windows 10, it starts and stops whenever it feels like.  Normally, our scripts run before it has had any reason to start, allowing us to slip in the correct licensing file.  For some reason, yours doesn't.

 

One possible workaround is to take the files in the FromLayer folder, stash them on a file server, and when making (or editing) the Platform Layer, overwrite the Store files with the copies from Office.  That way, the highest priority layer - the one actually delivering the initial copy of those files - has the ones from Office.  Then, when our scripts try to overwrite them, it doesn't matter whether they succeed or not, since the right versions are already there.  It has to be the Platform Layer, and yes, this does mean that you have a Platform Layer which is specific to a version of Office.  But for now, it's probably the best workaround I can offer.

Link to comment
  • 0

Right.. When I publish the image, I select the OS Layer, The Office App Layer & the Platform Layer..  No elastic assignments whatsoever.

 

Windows does activate fine every time (early on in my image building work, I was seeing OSRearm errors in Studio when creating every catalog & ended up disabling OSRearm via powershell for all machine catalogs as a fix for that issue)

Haven't seen an issue with Windows activation at all, besides that.

 

Link to comment
  • 0

I'll try placing them in the store in the Platform layer & report back.

 

Question..  If it was the SPP service causing it, wouldn't I see the below symptoms?

* ActivateOffice_Log.txt would report the file is in use by another process

* It would fail to copy the token.dat file as well

 

I've not seen a reference to the "Access is Denied" error I'm seeing.

Link to comment
  • 0

While waiting for the new image (with the store files replaced in the platform layer) to build, I had a thought..

In one of my existing groups of machines affected by the issues, I configured group policy computer preferences to REPLACE the following files:

 

From:

C:\Windows\System32\spp\store\2.0\FromLayer\data.dat

C:\Windows\System32\spp\store\2.0\FromLayer\tokens.dat

 

To:

C:\Windows\System32\spp\store\2.0\data.dat

C:\Windows\System32\spp\store\2.0\tokens.dat

 

I then performed a shutdown via Studio, then booted the machines again.

I logged in about 30 seconds after the machines registered & found Office 2016 activated without issue.

Upon closer inspection, I see the ActivateOffice_Log.txt shows the file copy operation succeeded for both files as well.

This made me curious.. it seems as though the failure of the script is maybe tied to that specific data.dat file.

 

I'm going to try the platform layer idea as well, once my image finishes building, & decide which will be a better solution to use going forward.

 

I'm also going to try various things on the existing \2.0\data.dat file to see if there's something special about that file that would allow a GP preference to overwrite it, but not a startup script.

 

None of this, in my opinion, is a proper solution. Doesn't sit right with me, but I know how it is.. I may have to accept it for a while in the end.

 

I have had a case open with Citrix for a week, but haven't heard back yet.. If I find out anything helpful, I'll be sure to post here.

 

Link to comment
  • 0

Placing store files:

* \FromLayer\data.dat

* \FromLayer\tokens.dat

 

...in the Platform Layer also seems to be allowing Office 2016 to successfully activate at every boot.

 

Upon checking the ActivateOffice_Log.txt, I see the following:

Access is denied.

0 file(s) copied.

1 file(s) copied.

 

I realize this doesn't matter in this scenario because the files already exist in the store folder (\spp\store\2.0\) from placing them in this location in the Platform layer.

I point this out as it shows even after replacing the original DAT files in the store with the desired versions, the activation script is still getting an Access is Denied error.

 

Digging further into the root cause of the "Access is denied" error.

 

Link to comment
  • 0

Has there been any update on this issue. We experience this issue sporadically for a few months now. Something happened last month that exacerbated the issue. The mass failures had subsided but we will still get it sporadically. We have alerts that look for "Installation of the Proof of Purchase failed 0xC004E016" and are aware before a user logs on. We can manually/automatically remediate that by restarting the machine and usually it will register.

 

Are there any plans on a built in fix? I really don't like having these "workarounds" because if we make a change in our environment we are troubleshooting multiple moving targets and wasting a lot of time. If we build it into our platform layer and if someone else for some reason needs to create a new office layer they may not make the update and cause the issue again.

 

I am not sure if it has been fixed in the updated version of the ELM (1901). We are still using 7.15 and looking to upgrade. If someone can tell me it is fixed in 1901 it would make the choice to upgrade a lot easier. We have had a ticket opened for about a month in December during the height of our failures but nobody seemed to know what was going on. Since it settled down we archived the ticket but the problem is still happening.

 

Any information someone can provide would be great. If you need any more information please let me know.

Link to comment
  • 0

Chris this isn't a product issue that can be fixed in our code.  Its an issue with office licensing files and the way app layering works.   I would say that if you want it to be the most reliable it can be, then put the tokens.dat and data.dat into your platform layer replacing the original files.  Then the software protection platform does not need to be stopped and activation should be ok whether or not the script runs.

Link to comment
  • 0

Rob,

  My understanding of the problem is that App Layering has a system startup activation script that will stop a service and copy the the two .dat files.  The problem seems to be a timing issue between the service stopping and the dat files being locked.  A manual delete of the log files (that prevent the script from running a second time) and then re-running the script completes the registration. 

  At the point in time that we had our uptick, we actually created a single code line at the end of that app layering script that would check the log file for a failure.  If the licensing failure error is found it would simply issue a restart within the OS. There's no reason we couldn't have done a re-run of the script, but at the time that required more lines of code.  ;-)

 

  So since the script in question is part of the App Layering startup and we know that a failure can be detected and simply corrected by re-running the script.  I would conclude that the onus of corrective action falls entirely on the script step that is failing, not on the customer to circumvent the original intention of the script by manually adding the files to the platform layer.  (pardon the nit pick)  ;-)

It makes far more sense to me that the app layering license script would  add some error checking in a couple possible ways:

- detect if the file is locked before attempting the copy (possibly confirm the service is indeed stopped too for good measure), and add some wait time/couple of retries.

- or detect the failure to activate in the log file and try the activation process again.

- (detect, then issue OS restart is really overkill, but was a valid way to address in a pinch)

 

Link to comment
  • 0

The script does have that in it.  It sits waiting for up to 5 minutes for the service to stop.  But it has no control over the service actually stopping which sometimes it doesn't do which is the issue.  The idea of using the platform layer makes it so that stopping the service is not required because the files are correct on the image in the first place.

Link to comment
  • 0

Which is odd considering that running the script a second time without a reboot resolves the issue.  That would make some code for detection of failure at the end of the script and re-run a valid improvement. 

Call it an opportunity for improvement and saving time avoiding a support call to educate the customer of the need to copy the .dat files when the script's single attempt didn't do the trick.  :-)  If that makes sense.

Link to comment
  • 0

Wanted to post an interesting development.  In our case we a line to the bottom of the app layering startup script OfficeActivation.cmd, which as I said in my last post parses the log file and if a failure is found it reboots.  (Actually, it issues a shutdown, since the Controller will just boot another one anyway, but I digress.)  That works like a champ, but that's NOT the most interesting part....

 

Separately we'd started an investigation into the uptick in blue-screen os crash occurrences with our last image post, but only just started.  SO back to the interesting part..

 

...Since we put that tweaked copy of the image in place, all occurrences of those OS Crashes have been eliminated.  The theory is that the crash goes hand in hand with the office activation failure.  Either both the office activation issue and the blue screen are both a symptom of the same cause, or the office repair that the user sees due to the office activation failure is crashing the OS  (conjecture on my part).  Either way, now that the OS is shutdown/restarted immediately after an office activation fails, our blue-screen instances are no longer occurring.

(We'll still pursue generating the crashdumps and get those up to Citrix.  May provide some insight into the exact nature of this and future issues that result in a blue screen.)

Link to comment
  • 0

I'd like to resurrect this thread as I think I'm having the exact same behavior.  In my case it's a Windows 10 1809 image with Office 2013, using MCS on vSphere.  ELM is currently at 1905.

 

It appears that the issues occur only when Elastic Layering is enabled, and the Office activation errors are observed in ActivateOffice_log.txt prior to anyone logging in.  I also have multiple Event Log errors (CAPI2 #256-257. ESENT #413 to name a few) during boot of the Elastic image that are not present in the same image with Elastic Layering disabled.

 

Any guidance here would be greatly appreciated!

Link to comment
  • 0

Darrin,

Can you post the errors from your officeactivate.log file?

 

Normally the issue is that the data files were not created properly.

 

I usually find its easier to create a new layer and just follow the recipe than to try and fix an existing layer because the only time the dat files are correct on your packaging machine is when you first install office.

 

So i woudl recommend you create a new office layer.  If you havent upgraded your scripts from the gol image tools during your latest upgrade i woudl do that beforehand..  That way you will get the new functionality where we pre copy in the dat file when the image is published which is more reliable.

 

Rob

 

Link to comment
  • 0

Excerpts from the logs are copied below.  Note that during MCS image preparation, the initial boot occurs in UTC which is an issue I've been unable to resolve with multiple methods suggested on Citrix and VMWare articles.  I'm not sure if this is contributing to the issues, but again I only have issues when Elastic Layering is enabled.

 

In my latest test I had copied the "FromLayer" files to c:\windows\system32\spp\store\2.0 in the Platform layer as you suggested earlier in this thread.  I have previously rebuilt the Office 2013 layer from scratch using the published recipe, and the same layers have always worked in my PVS image on Xenserver with Elastic Layering enabled.

 

I did notice I'm still on version 4.13 of the App Layering Image Preparation Utility so I'm going to upgrade that now for my next test.  Could this be a factor?

 

-Darrin

 

==========================================================================================================================================

ActivateOffice_Log.txt:

 

Fri 09/06/2019-13:30:52.44- Found Windows 10 will try to copy FromLayer\data.dat file to UEP  
Fri 09/06/2019-13:30:52.45- Wait for SPPSVC to Stop to allow the updates  
Microsoft (R) Windows Script Host Version 5.812
Copyright (C) Microsoft Corporation. All rights reserved.

9/6/2019 1:30:52 PM - Wait for Service 'sppsvc' to get to State Stopped
9/6/2019 1:30:53 PM - Service 'sppsvc' State Running
9/6/2019 1:30:53 PM - Stopping service 'sppsvc' State Running
9/6/2019 1:30:53 PM - Stopping service 'sppsvc' State Running
9/6/2019 1:30:58 PM - Service 'sppsvc' State Stopped
Fri 09/06/2019-13:30:58.49- Copy the files from the layer into the 2.0 directory 
        1 file(s) copied.
        1 file(s) copied.
Fri 09/06/2019-13:30:59.11- Found File OfficeStd2013_KMS.txt - Activating OfficeStd2013_KMS 
Microsoft (R) Windows Script Host Version 5.812
Copyright (C) Microsoft Corporation. All rights reserved.

---Processing--------------------------
---------------------------------------
ERROR DESCRIPTION: An unknown error occurred.
---------------------------------------
---Exiting-----------------------------
ECHO is off.
Fri 09/06/2019-13:31:01.77- Activating Office using ospp.vbs 
ECHO is off.
 

kmssetup.log:

 

Fri 09/06/2019-13:30:43.94-kmssetup.cmd:Migrating Startup Scripts from Pre 4.2 to Post 4.2
Fri 09/06/2019-13:30:45.58-kmssetup.cmd:RunMode [0x1] Found in Registry 
Fri 09/06/2019-13:30:45.60-kmssetup.cmd:OSLayerEdit Not Found in Registry 
Fri 09/06/2019-13:30:51.75-kmssetup.cmd:Restting office Activation following a REBIC
Fri 09/06/2019-13:30:51.94-kmssetup.cmd:calling OfficeActivate.cmd
Fri 09/06/2019-13:31:01.88-kmssetup.cmd:OfficeActivate.CMD Complete
Fri 09/06/2019-13:31:01.88-kmssetup.cmd:calling NoReReg.cmd
Fri 09/06/2019-13:31:01.91-kmssetup.cmd:OfficeNoReReg Complete
Fri 09/06/2019-13:31:01.91-kmssetup.cmd:calling RunBuildScripts.ps1
Fri 09/06/2019-13:31:01.92-kmssetup.cmd:RunBuildScripts.ps1 Complete
Fri 09/06/2019-13:31:02.35-kmssetup.cmd:---------------Machine Name -----------
Fri 09/06/2019- 8:51:01.83-kmssetup.cmd:RunMode [0x1] Found in Registry 
Fri 09/06/2019- 8:51:01.89-kmssetup.cmd:OSLayerEdit Not Found in Registry 
Fri 09/06/2019- 8:51:10.67-kmssetup.cmd:calling OfficeActivate.cmd
Fri 09/06/2019- 8:51:11.87-kmssetup.cmd:OfficeActivate.CMD Complete
Fri 09/06/2019- 8:51:20.03-kmssetup.cmd:---------------Machine Name -----------

 

Link to comment
  • 0

The time issue happens when the Master image machine that's created has a virtual bios that has never been configured before.  The fix for that is to use a template created from a clone of your original gold image which was booted with windows and the right time zone.  Then the virtual bios has the correct time settings when the master image boots.  Just remember to remove the hard disk from the template.  You can also disable the image prep steps for office they arent needed in app layering becasue we do all that in scripts anyway.  If you wnat to do that let me know and ill pots the powershell commands

 

Link to comment
  • 0

Thanks!  Couple things on what you just suggested...

 

I have tried multiple times to use a running Windows 10 VM as the template for both the vSphere and vSphere MCS connectors; both as a VM with no drives and after converting to a VMWare template.  The time zone is correct throughout the Layered Image creation, and only switches to UTC during the MCS catalog update.  I did try setting Windows Time service to trigger on Network connection (since first boot is off-domain) which did not make a difference.

 

As for disabling image prep, I have tried this several times as well - it's not clearly documented whether we should use MCS image prep at all with a Layered image.  What I've found is that if I run the Powershell to disable image prep, it is re-enabled immediately after I start a catalog update.  I've tried this by disabling just the Office rearm and by disabling Image Preparation altogether with these respective commands:

 

Set-ProvSchemeMetadata -ProvisioningSchemeUid $psUID -Name ImageManagementPrep_DoImagePreparation -Value $false -AdminAddress $xdBroker

Set-ProvSchemeMetadata -ProvisioningSchemeUid $psUID -Name ImageManagementPrep_Excluded_Steps -Value "OfficeRearm,OsRearm" -AdminAddress $xdBroker

 

Interestingly (and/or frustratingly), I've never once had an issue with Windows activation in this environment.  :S

Link to comment
  • 0

You dont need image prep when using app layering becasue the built in scripting handles the same issues.  Its debatable if you ever need it truly.

 

I have never had an issue with disabling the prep

By DDC

Set-ProvServiceConfigurationData -Name ImageManagementPrep_Excluded_Steps -Value OsRearm
Set-ProvServiceConfigurationData -Name ImageManagementPrep_Excluded_Steps -Value OfficeRearm

 

By Catalog

Get ProvisioningSchemeUid from Get-BrokerCatalog

Set-ProvSchemeMetadata -ProvisioningSchemeUid xxxxxxx –Name ImageManagementPrep_Excluded_Steps -Value OfficeRearm
Set-ProvSchemeMetadata -ProvisioningSchemeUid xxxxxxx -Name ImageManagementPrep_Excluded_Steps -Value OsRearm
 

https://www.citrix.com/blogs/2016/04/04/machine-creation-service-image-preparation-overview-and-fault-finding/

https://support.citrix.com/article/CTX233683 note on this thew command is wrong in the text but right in the example

 

I dont understand why the time would change when the image prep happens I have not seen that issue before.

 

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...