Office 365 activation issue on RDS running Office 365 Click2run (C2R) with Shared Activation (0x80004005)

Consider the following scenario

• An RDS environment that hosts one or more RDSH servers with Office 2013 Click 2 Run installed.
• Shared activation has been enabled
• Federation is not in place so activation relies on a user activating manually once by entering his O365 credentials
• Registry value NoDomainUser is configured to 1 (Advised by Microsoft in case of the scenario above) also see  https://support.microsoft.com/en-us/kb/2913639

A new user who doesn’t have a profile yet, logs on for the first time and launches an Office application for the first time and gets prompted with the Office 365 activation screen. This is expected behavior in environments where federation is not in place.

The user finishes the activation and is seems to have been successful when checking the account tab in Word at that time.

However, when the user closes Office (in the case Word) and opens another Office application, he’s now suddenly being prompted with the error “Sorry, we cannot verify the license currently installed for this product” Error code 0x80004005

This is because at this point no Credential has been created in the Credential store.

And the user has to perform activation again (even within the same RDS session).

Why is this? The fix by adding the NoDomainUser registry value does not completely fix the issue. This is because the first time an Office application is launched, it completely removes the Identity Registry Key (including the NoDomainUser registry value).

Process Monitor confirms this:

What Process Monitor also reveals is that prior to deleting the Identity key, the value or Version is queried, and it cannot be found, because no identity has been configured yet.

Apparently Office first checks if an identity version is in place and only if there isn’t, it removes the Identity key.

So how to make the fix complete? Besides adding the NoDomainUser based on the KB article, we also add a fake version registry value using a GPO Preference, and set that to apply Once.

This results in the following in the HKCU at first logon

This causes Office to think there is an identity in place and thus it does not remove the key, which allows the NoDomainUser key to do it’s work, which results in a successful activation at first logon!

I’ve Been in contact with the Office Team, and they have confirmed that an official fix is on track to go live in April update release!

When in doubt, use Process Monitor!