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.
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: