Office 365 doesn't seem to be activating

[Nick Panaccio]

I'm testing out O365 for the first time, but it doesn't appear to be activating (I get the 'Sign in to set up Office' screen when an O365 app launches) per ActivateOffice_log:

 

Thu 04/11/2019-11:04:47.97- Found Windows 10 will try to copy FromLayer\data.dat file to UEP  
Thu 04/11/2019-11:04:47.97- Office License file has been updated during the BIC Process 			
Thu 04/11/2019-11:04:48.07- Detected VDI operation; forcing office activation 
Thu 04/11/2019-11:04:48.11- Found File ProcessOffice365.txt - Skipping KMS Activation 

I tried following the recipe in CTX224566, but came across a few things that didn't make sense to me. For the Office 365 section, step 8 states: Run the Optimizer tool by right-clicking on RunOptimizer.cmd and choosing "Run As Administrator".  Select "Activate MS Office via KMS" or "Process Office 365".  Click "Save A-K" (the specific options may change in the future, so for instance it might say "Save A-J") to make sure the Office options are saved. I selected 'Process Office 365' and then saved the settings. Further down, it mentions re-arming Office, but if I attempt that, it fails with the following error:

 

There was an error when trying to rearm Office. You can try passing the SKU ID as a parameter. Passing the SKU ID is necessary if you are relying on an activation to permit an additional rearm.
Error: 0xc004fe00
On a computer running Microsoft Windows non-core edition, run 'slui.exe 0x2a 0xc004fe00' to display the error text.

 

Is it safe to assume that I don't actually have to re-arm Office 365? And that I don't need to select 'Office 2016 Pro Plus' like I had been for my previous installs? If it helps, this is on App Layering 1902, on a Windows 10 1709 x64 VDA (XenDesktop 7.15 LTSR CU2) on PVS. Below is my O365 config file:

 

<Configuration ID="GUID-Goes-Here">
  <Info Description="Microsoft Office 365 ProPlus" />
  <Add OfficeClientEdition="64" Channel="Broad" ForceUpgrade="TRUE">
    <Product ID="O365ProPlusRetail">
      <Language ID="en-us" />
      <ExcludeApp ID="Access" />
      <ExcludeApp ID="Groove" />
      <ExcludeApp ID="OneDrive" />
      <ExcludeApp ID="OneNote" />
      <ExcludeApp ID="Publisher" />
    </Product>
  </Add>
  <Property Name="SharedComputerLicensing" Value="1" />
  <Property Name="PinIconsToTaskbar" Value="FALSE" />
  <Property Name="SCLCacheOverride" Value="0" />
  <Updates Enabled="FALSE" UpdatePath="D:\" />
  <RemoveMSI />
  <AppSettings>
    <Setup Name="Company" Value="Company" />
  </AppSettings>
  <Display Level="None" AcceptEULA="TRUE" />
  <Logging Level="Standard" Path="C:\Windows\Temp" />
</Configuration>

 

[Gunther Anderson]

You would only have to rearm Office if you actually ran any of the components.  So almost always, it's safe to skip the rearm. 

 

If you version the Office layer, does "cscript ospp.vbs /dstatus" show Office?  Does it show if you run that in the published machine?

 

While you're looking at the Office layer, check to see if you have C:\Windows\System32\spp\store\2.0\FromLayer, which shouldn't exist in the Office Layer, but might have been inherited from the OS layer if you accidentally ran the Office optimizations there.  If you see the FromLayer folder, delete it and re-run the Optimizer to re-save the Office licensing information.

[Nick Panaccio]

I'm building a new O365 layer just to go through the motions again in case I missed something, following the CTX article line by line. I definitely don't have the FromLayer folder, so that's not an issue. I rebooted the VM after finishing with the ngen updates, and wound up having to forcibly power it down in XenCenter. Not terribly worried, as that happens on occasion. When it came back up, I ran the script:

 

PS C:\Program Files\Microsoft Office\Office16> cscript ospp.vbs /dstatus
Microsoft (R) Windows Script Host Version 5.812
Copyright (C) Microsoft Corporation. All rights reserved.

---Processing--------------------------
---------------------------------------
<No installed product keys detected>
---------------------------------------
---------------------------------------
---Exiting-----------------------------

Mind you, this is the packaging machine, not the finalized vDisk. I'll check again tomorrow when I complete this image and will post back.

 

Edit: Actually, I already see one issue from this morning - step 9. After running the optimizer and successfully saving the settings, I went ahead and ran 'Office2013Windows81_PREP.cmd'.

[Nick Panaccio]

I don't know if it was running that batch file, but rebuilding the layer appears to have worked. That 'Sign in to Office' screen never appears, and I do see two files in 'C:\Users\username\AppData\Local\Microsoft\Office\16.0\Licensing'. I also see no banner in the Office apps stating that it's not activated. Running the ospp.vbs script still shows 'No installed product keys detected', though.

[Gunther Anderson]

If it's working, I'll take it (and back away without making eye-contact).  I know old-school KMS licensing well, but all the various models of licensing in Office 365 are still a mystery to me.

[Nick Panaccio]

One more related question - with Office 365 activation being different than KMS activation, does this also mean that we can do away with the custom SettlementPeriodBeforeUse delay for the Delivery Groups?