This week a customer informed us they had a strange problem with Office 365 Click-to-Run. The customer experienced two problems:
- When users start up an Office application, sometimes they would receive the following error: “There is a problem with your account, please try again later”.
- At random, some users were required to re-enter their Office 365 credentials; Single Sign-On was not working correctly.
In most cases, the “Fix me” button didn’t work for the users, nor did re-entering the credentials. The result: Office 365 activation didn’t work and they could not use their Office applications.
The customer environment
The customer environment consisted of the following components:
- Horizon Cloud with Hosted Infrastructure version 17.2
- Windows 10 build 1703
- Office 365 Click-to-Run (latest version)
- Non-persistent VDI (Instant Clone)
- VMware UEM 9.3
- ADFS implementation (Used for Single Sign-On)
Troubleshooting
The customer gave me some additional information. When they deleted the user’s profile, the problem was gone and the users could work again for a couple of days. However, the problem would always re-occur.
When I started troubleshooting, I used the following article for Office 365 Click-to-Run installation requirements, activation and roaming of the license token.
It turned out, the customer had installed Office 365 correctly in their base image. The most important part of non-persistent VDI is configuring the deployment.xml with the “SharedComputerLicensing” property, as indicated in the mentioned article.
Next, I reviewed the article how the license token renewal process works. The recommended approach is to always use Single Sign-On. The customer had implemented ADFS and SSO worked most of the time. However, as mentioned earlier, sometimes the users were prompted to re-enter their credentials again.
When I reviewed the VMware UEM configuration, the following two lines were added in the “Office 2016 – Shared Settings” personalization configuration:
As stated in the article, you only have to save (and roam) these settings if you do not use Single Sign-On. Since the customer had implemented ADFS, these lines could be safely removed from the VMware UEM configuration.
After we reset the VMware UEM profile settings (Office 2016 – Shared Settings.zip) for a couple of test users, the problem at first seemed to be solved. But after some more testing, we noticed the problem came back.
After some investigation on the internet, I found the following article.
At first, this didn’t seem to be related to our problem. But when we had a test user with the activation problem, we deleted the following registry key:
- HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity
After we restarted the Office application, the registry key was re-created and Single Sign-On worked immediately. The Office 365 activation was working again!
So, now we knew the solution, we could implement the fix. Within the VMware UEM Management Console, I could think of two ways to accomplish this:
Profile Cleanup the registry key tree
With this setting, the registry key tree will be deleted at each logoff. At each new logon, the registry key tree will be re-created.
Exclude the registry key tree
Configuring this setting means the registry key tree will not be saved into the user’s profile. It will have the same result as option one; the registry key tree will be re-created with each new logon.
For the existing users the personalization settings for the Office 2016 – Shared Settings needed to be reset, because the Identity key already existed in their profile. This was slightly more work, but we decided to implement this solution because I think it was a bit more “cleaner” than option one. In addition, this was still a pilot environment and not many users were accessing the platform at this time.
Conclusion
As you can see, VMware UEM provides us with a simple yet powerful way to manage the application profile settings. There were even multiple ways to solve the problem, the one necessarily better than the other.
Please note, I am by no means an Office 365 expert. If you can think of a better solution, please let me know in the comments!
will this work if we dont have an ADFS configured and have email addresses in a domain different than AD. Thanks.
LikeLike
I actually don’t know, I never tried a configuration you have right now. I think you might have to include the Licensing and Credentials folders in your user profile management tool.
LikeLike
Many thanks,
i have the same problem that office apps and ie11 crashes after login without an error on an rds server. i find your post over google and after delete of identity key it works perfect
LikeLike
Good to read this “old” blog post is still helping a lot of people! Thanks for sharing.
LikeLike