How to Resolve Microsoft 365 Activation Issues in Citrix Published Apps Mode

Microsoft 365 Apps can be harder to troubleshoot when they run as Citrix Published Apps rather than on a normal Windows desktop.

A user launches Word, signs in, everything works. Then they log off.

Next time they launch it, Office asks them to sign in again. Or shows Unlicensed Product. Or activation works on one Citrix server and fails on another.

At that point it’s tempting to treat it as a licensing problem. Sometimes it is. In a shared Citrix environment there are usually several other things to check first.

The key distinction is that Microsoft 365 activation involves both licensing and user identity data, and in a shared computer scenario that data has to work every time the user starts an Office application, regardless of which session host they land on.

This is a troubleshooting reference rather than a writeup of one specific incident. Where the advice is version-dependent, I’ve said so.

Start with Shared Computer Activation

The first thing to establish is whether Microsoft 365 Apps is configured for Shared Computer Activation (SCA).

Microsoft designed SCA specifically for shared computers such as Remote Desktop Services and VDI, where multiple users sign in to the same machine and each activates using their own assigned licence. The details are in Overview of shared computer activation.

This matters for Citrix Published Apps because several users may be running Office on the same Windows Server simultaneously.

Check the installation

Open Word and go to:

File → Account → About Word

Shared Computer Activation should be shown in the About information when it’s enabled.

You can also check the registry:

HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration

Look for SharedComputerLicensing with a value of 1.

With PowerShell:

Get-ItemProperty `
    -Path "HKLM:\SOFTWARE\Microsoft\Office\ClickToRun\Configuration" `
    -Name SharedComputerLicensing

If SCA isn’t enabled, fix that before spending time on Citrix profiles or authentication. Nothing downstream will behave predictably without it.

The user’s licence also needs to support Shared Computer Activation.

Check the user’s licence

Worth doing the obvious things before getting into Citrix troubleshooting.

In the Microsoft 365 admin centre, confirm:

• The user has a Microsoft 365 Apps licence
• It’s assigned to the correct account
• It hasn’t expired or been removed
• The user is signing in with the account that holds the licence

If several users are affected, compare them rather than assuming they’re all in the same state. Often they aren’t.

Check whether activation is actually succeeding

This is the test that separates the two halves of the problem.

Shared Computer Activation stores licensing information under the user’s profile:

%LOCALAPPDATA%\Microsoft\Office\16.0\Licensing

After a successful activation, licensing files should appear there.

In a Published App session:

Test-Path "$env:LOCALAPPDATA\Microsoft\Office\16.0\Licensing"
Get-ChildItem "$env:LOCALAPPDATA\Microsoft\Office\16.0\Licensing"

Three outcomes, each pointing somewhere different:

The folder is never populated. Activation isn’t completing. Look upstream at the licence, SCA configuration, authentication and connectivity to Microsoft’s licensing services.

Files appear during the session, then are gone at the next logon. Activation works but the data isn’t persisting. That’s a profile problem, not a licensing one.

Files are present and activation still fails. Look at authentication and Conditional Access.

That distinction saves a lot of time. Most of the guides you’ll find treat all three as the same problem.

FSLogix and Office activation

FSLogix is commonly used to provide profile and Office data persistence in virtual environments.

The relevant setting is IncludeOfficeActivation, which controls whether Office activation data is redirected into the ODFC container. The default is 1.

HKLM\SOFTWARE\Policies\FSLogix\ODFC

Check it with:

Get-ItemProperty `
    -Path "HKLM:\SOFTWARE\Policies\FSLogix\ODFC" `
    -Name IncludeOfficeActivation

The full list is in FSLogix configuration settings.

Installing FSLogix doesn’t automatically fix activation

This is the assumption worth challenging.

Having FSLogix present isn’t enough. You need to establish:

1. The profile container is actually attaching
2. The ODFC container is configured as expected
3. Office activation data is being included
4. The user can write to the container
5. The container stays available throughout the session
6. The data is still there at the next logon

This matters particularly when another profile or folder-redirection product is also in play. Microsoft documents exclusions that may be needed when an ODFC container runs alongside another profile solution, and a partial configuration can be worse than none.

Does the problem follow the user or the server?

One of the simplest and most useful tests.

Say you have three session hosts:

CTX01
CTX02
CTX03

A user gets an activation error. Check which server hosted the session, then have them launch the application on another.

If it follows the user, investigate the licence, identity, profile, FSLogix, licensing token and authentication.

If it stays with one server, investigate the Office installation, SCA configuration, Office build, Windows updates, FSLogix installation, connectivity, and any server-specific security software or policy.

This stops you changing a working session host when the problem is contained within one user’s profile.

Check connectivity to Microsoft’s services

Microsoft 365 Apps needs to reach the Office Licensing Service and related activation endpoints. A session host that can’t communicate with those services can’t maintain activation indefinitely.

This matters in Citrix environments where session hosts often sit behind:

• Proxy servers
• Web filtering
• Firewall rules
• SSL inspection
• Restricted outbound access

Don’t just test whether the server can browse to microsoft.com. The question is whether the required Microsoft 365 endpoints are reachable and whether anything is interfering with the authentication process.

SSL inspection is worth singling out. It can break token acquisition in ways that look nothing like a network problem.

Base firewall and proxy allow lists on Microsoft’s current published endpoint data rather than a static list of domains from an old article. Those endpoints change.

Conditional Access

Conditional Access can complicate Microsoft 365 sign-in from Citrix, and the symptom often looks like an Office problem.

A policy might require MFA, a compliant device, a trusted location, a specific authentication strength, or a particular client application. If the policy blocks the request, no amount of Office registry tuning will help.

Start with the user’s sign-in activity in Microsoft Entra ID. Look for failed sign-ins around the time the user launches Word.

Pay attention to:

• Which Conditional Access policies applied
• The failure reason
• The authentication requirement
• The client application
• Device information
• The correlation ID

That’s considerably more useful than trying registry settings from a forum post.

What about Windows Server 2019 and WAM?

This is where I’d be careful with older troubleshooting guides.

You’ll find plenty of articles recommending registry values under:

HKCU\Software\Microsoft\Office\16.0\Common\Identity

that disable the Windows Account Manager or force Office back towards ADAL authentication.

These appeared in Microsoft Q&A threads and third-party guidance for specific authentication problems around 2019 and 2020. I’d be cautious about treating them as a standard activation fix now.

ADAL reached end of support on 30 June 2023. Microsoft’s MSAL migration guidance states that all support and development for ADAL, including security fixes, ended on that date, and that applications should use MSAL instead.

Worth noting the history, because it causes confusion: the original deprecation date was June 2022, and it was extended. Older articles cite both dates, which is one more reason to check rather than assume.

That doesn’t mean an old registry workaround can never be relevant to a particular legacy environment. It means it should be treated as a specific troubleshooting workaround for a diagnosed problem, not a default step in a modern deployment.

If you find an article telling you to disable WAM simply because the session runs on Windows Server 2019, check the Office build, the Windows build and the exact authentication error before applying anything. Server 2019 is old enough now that the surrounding software has changed substantially since that advice was written.

One practical note: the registry value names in this area are spelled inconsistently across third-party guides. If you do decide a legacy workaround is warranted, get the exact value name from current Microsoft documentation rather than copying it from a blog post. A misspelled value does nothing and fails silently, which sends people to the next workaround while the original problem is untouched.

Hybrid Microsoft Entra join isn’t a universal answer

Hybrid Entra join can be useful where device identity matters for authentication and Conditional Access.

But it shouldn’t be presented as a general fix for Microsoft 365 activation in Citrix.

If you suspect device identity is involved, look at the actual authentication failure. Determine whether a Conditional Access policy requires the device to be:

• Microsoft Entra joined
• Hybrid Microsoft Entra joined
• Marked compliant
• Known or trusted

Then determine whether the session host satisfies that requirement.

The distinction worth holding onto is between:

“Hybrid Entra join fixed our particular authentication problem”

and:

“Hybrid Entra join is required to activate Microsoft 365 Apps in Citrix.”

The first can be a useful case study with evidence behind it. The second is a much broader claim and I wouldn’t make it without qualification.

Read AADSTS errors properly

If Office shows an AADSTS error, don’t assume it means the licence is broken. The specific code matters.

For example:

AADSTS500011

means the resource principal named in the authentication request wasn’t found in the tenant. Possible causes include the resource application not being provisioned or consented to, an incorrect resource URL, or an incorrect tenant ID.

That’s a very different problem from a licensing failure, and “AADSTS500011 means an Office licence problem” would send you in entirely the wrong direction.

The full list is in Microsoft’s Entra authentication and authorization error codes.

Record the complete error text, not just the number. The descriptive part usually names the specific resource or condition involved.

Don’t delete the profile first

Deleting the user’s Office identity and licensing data can make a broken profile appear to recover.

That doesn’t mean you’ve fixed anything.

If the container isn’t persisting the required data, the same problem returns at the next logon, and you’ve destroyed the evidence that would have told you why.

Before resetting anything, establish:

1. Did activation succeed?
2. Where was the activation data stored?
3. Did it persist after logoff?
4. Was the profile container attached correctly?
5. Did the same problem occur on another session host?

With those answers, resetting the profile becomes a controlled step rather than guesswork.

A practical troubleshooting sequence

1. Confirm the licence

The user needs a Microsoft 365 Apps licence that supports the activation method in use.

2. Confirm Shared Computer Activation

HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration
SharedComputerLicensing = 1

3. Check the activation data

%LOCALAPPDATA%\Microsoft\Office\16.0\Licensing

Present, absent, or disappearing between sessions? That answer directs everything that follows.

4. Check FSLogix

Verify the profile and ODFC containers attach correctly, and check IncludeOfficeActivation.

5. Compare session hosts

Does the problem follow the user or stay with one server?

6. Check Entra sign-in logs

Look for authentication failures and Conditional Access decisions at the time Office launches.

7. Check network and proxy access

Confirm the session host reaches the Microsoft 365 licensing and authentication endpoints, and that SSL inspection isn’t interfering.

8. Only then look at application-specific authentication

If the evidence points at WAM or Office identity components, investigate the specific Office and Windows builds involved. Don’t start here with registry workarounds copied from old forum posts.

Activation is a chain

The most useful way to think about this is as a chain rather than a single setting:

Microsoft 365 licence
        |
        v
Shared Computer Activation
        |
        v
User authentication
        |
        v
Microsoft licensing service
        |
        v
Office licensing data written
        |
        v
Citrix / FSLogix profile persistence
        |
        v
Next user session

A failure anywhere along that chain produces what looks like an Office activation problem.

So the useful question isn’t:

“What registry key fixes Office activation in Citrix?”

It’s:

“At which point in that chain is this user’s session failing?”

Once you’ve established that, the troubleshooting becomes targeted rather than speculative.

What I’d be cautious about

Several pieces of older advice I wouldn’t copy into a current deployment without a diagnosed reason:

• Automatically disabling WAM
• Forcing Office back to ADAL
• Assuming Windows Server 2019 is the root cause
• Assuming Hybrid Entra join will fix activation
• Deleting profiles before understanding the failure
• Treating every AADSTS error as a licensing problem
• Assuming FSLogix automatically makes activation persistent
• Using old Microsoft 365 endpoint lists

Some of these were valid workarounds for specific problems when they were written. That doesn’t make them appropriate default configuration now.

Start with Shared Computer Activation, verify the licence, check whether the licensing data is being written and whether it persists, then work through FSLogix, authentication and connectivity. The legacy WAM and ADAL workarounds belong at the end of the list, not the beginning.

Microsoft references

• Overview of shared computer activation for Microsoft 365 Apps – how SCA works and how to enable it
• FSLogix configuration settings – ODFC container settings including IncludeOfficeActivation
• Microsoft Entra authentication and authorization error codes – the AADSTS reference
• Migrate applications to MSAL – ADAL end of support and why the old workarounds are legacy

Daniel Lutton

From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.