We are having a lot of Office activation issues, we are using Windows 10 clients with Office 365 ProPlus, sharedcomputerlicensing is enabled within the Office installation.
Every day we have a lot of users that have to activate their office license but when they try to activate Office they do not get a password prompt so the activation fails.
The workaround we have is to delete the local proflie and remove the personal certificates.zip from the UEM folder and logon again, the user can then activate office again.
The UEM version we are using is 9.2.0
We have added the following path to UEM to roam the license:
The 2 license tokens in %localappdata%\Microsoft\Office\16.0\Licensing are exported without issues.
Does anyone recognize this problem?
I don't know anything about Office licensing, but Overview of shared computer activation for Office 365 ProPlus | Microsoft Docs contains the following statement:
If a user goes to another computer that also is enabled for shared computer activation, the same steps occur. There is a different licensing token for each computer that the user logs on to.
Given that you indicated that you export the user's license tokens, maybe that's (part of) the issue? By using UEM to persist the license tokens, a license token could end up on a different machine than the one it was created for?
Thanks for your response.
That article also states the following:
If you don't use single sign-on, you should consider using roaming profiles and include the following two folders as part of the roaming profile:
So that's what we did and it seemed to work for a while, however in the past few weeks a lot of users have license issues.
Back to my earlier "I don't know anything about Office licensing" statement, I'm afraid... Would the Licensing token roaming approach that's described on that page be an alternative?
Can you tell me where in UEM you were able to specify to redirect/roam the two paths you indicate?
I have a similar environment with Windows 2012 R2 RDSH server, Office 365 ProPlus and UEM 9.3.
I've tried specifying a different folder with Group Policy for the Office licensing tokens, under the %userprofile%, but that didn't seem to work.
If you mean how to use UEM to roam settings from these locations: the UEM <LocalAppData> folder token corresponds with the %localappdata% environment variable in Windows.
If you create a custom Flex config file on the Personalization tab and enter the following in the Import/Export tab:
the content from those two folders will be saved at logoff and read back in at logon.
Please also read this, worth a try Overview of shared computer activation for Office 365 ProPlus | Microsoft Docs
Licensing token roaming Starting with Version 1704 of Office 365 ProPlus, you can configure the licensing token to roam with the user's profile or be located on a shared folder on the network. Previously, the licensing token was always saved to a specific folder on the local computer and was associated with that specific computer. In those cases, if the user signed in to a different computer, the user would be prompted to activate Office on that computer in order to get a new licensing token. The ability to roam the licensing token is especially helpful for non-persistent VDI scenarios.
To configure licensing token roaming, you can use either the Office Deployment Tool or Group Policy, or you can use Registry Editor to edit the registry. Whichever method you choose, you need to provide a folder location that is unique to the user. The folder location can either be part of the user's roaming profile or a shared folder on the network. Office needs to be able to write to that folder location. If you're using a shared folder on the network, be aware that network latency problems can adversely impact the time it takes to open Office.
All we did was set the GPO to the UEMProfiles location for each user and it's working perfect. When I check the O365 Console it only shows a single activation since we are using non-persistent VM's this was vital.
I would like to know if %localappdata%\Microsoft\Credentials is also required. Now the thread is almost one year old i would like to know if this is still valid.
I do not see any reference to %localappdata%\Microsoft\Credentials
hope someoen can clarify this.