When a user logs in and runs an Office component, they may immediately see "Please wait while setup configures microsoft office", which will run a repair function, which will fail.  If they have Lync installed, then that Office component might run immediately without any interaction from them.

Or the user may login and Office will work fine initially, but running it again a few minutes later shows the broken licensing.

If you look at C:Windows\Setup\Scripts\ActivateOffice_log.txt, you may see an error like this:

The Software Protection service is stopping.
The Software Protection service could not be stopped.

Wed 08/30/2017-10:13:12.09- Copy the files from the layer into the 2.0 directory
        1 file(s) copied.
The process cannot access the file because it is being used by another process.
        0 file(s) copied.
Wed 08/30/2017-10:13:12.66- Starting the service back up again 
The requested service has already been started.

See how we were unable to stop sppsvc, and thus unable to overwrite the Office licensing information with data captured from the layer.  This is because a user has already logged into this machine before our script was able to run.

When an App Layering image boots (or a Unidesk desktop), there is a system startup script called kmssetup.cmd which performs Windows and Office licensing actions to ensure that the product is properly activated.  In Windows 10 (and possibly other Windows versions), system startup scripts are delayed by a few minutes, meaning it's possible for a user to login to the VM before the activation scripts have run.  A user having logged in may experience licensing anomalies until our script has run.  They will definitely interfere with Office licensing in a way which causes the licenses to not appear at all, and cause Office to have to do an installation repair on its own.

Unfortunately, there is no way we can perform licensing functions before our startup script runs, and no way we can force Windows to run our script sooner.  The only option is to delay initial user logins until after the script has run.

Note that if you let the Office repairs run, they will eventually succeed and restore Office licensing.  That's usually not an acceptable option, however.  Certainly not in App Layering, where the repair has to happen on every boot.

For nonpersistent Unidesk desktops, this delay is automatically part of the desktop creation process.  For persistent Unidesk desktops, you should just add to your creation process a delay before allowing users to login, if at all possible.  Once the licensing has happened once on the Unidesk desktop, it will be fine going forward.

For App Layering images, however, that licensing is going to happen on every boot, because every boot is the first boot.  So on every boot, our script has to run, overwrite the license information with the captured Office licenses, and activate against the KMS server.  For App Layering, you need to make sure no user can login in the middle of that.

There are two approaches we know of.  The problem is that your Connection Broker may allow users to login quite early in the boot process.  Delaying the machine's availability to the broker will also delay the user logging into the machine.  Add Version to the platform layer.  You can identify the broker agent service in the platform layer and set it to "Automatic (Delayed Start)".  To set the specific delay, create a DWORD named AutoStartDelay within the broker agent service folder, and set it to the number of seconds to delay before the service will start.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<Service name>]
AutoStartDelay=240

The other approach is XenDesktop-specific, where you can set a "settlement period" for all machines in a delivery group, preventing them from accepting a user login until the delay is complete.  See this:

https://citrix.github.io/delivery-controller-sdk/Broker/Set-BrokerDesktopGroup/

set-brokerdesktopgroup -SettlementPeriodBeforeUse