App Layering/Unidesk: If user logs in before Office activation script runs, Office licensing will break

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_MACHINESYSTEMCurrentControlSetServices<Service name>]


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:

set-brokerdesktopgroup -SettlementPeriodBeforeUse


  • No Related Posts

Leave a Reply