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

Microsoft 365 Apps are harder to troubleshoot when they run as Citrix Published Apps than on a normal Windows desktop, and activation is the problem I see raised most often. A user launches Word, signs in and everything works. They log off, and next time Office asks them to sign in again, shows Unlicensed Product, or activates on one Citrix server and fails on another.

It’s tempting to treat that as a licensing problem, and sometimes it is. In a shared Citrix environment, though, there are usually several other things to check first. 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, whichever session host they land on.

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

Start with Shared Computer Activation

Before anything else, establish whether Microsoft 365 Apps is configured for Shared Computer Activation (SCA). Microsoft designed SCA for shared computers such as Remote Desktop Services and VDI, where multiple users sign in to the same machine and each activates with their own licence. The details are in Microsoft’s overview of shared computer activation. It matters for Citrix Published Apps because several users may be running Office on the same Windows Server at once.

Check the installation

In Word, go to File > Account > About Word. When SCA is enabled, the About information says so. You can also check the registry value SharedComputerLicensing under HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration, which should be 1. With PowerShell:

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, because nothing downstream will behave predictably without it. Note that if a user activated Office before SCA was turned on, Microsoft says the activation needs to be reset for SCA to work. The user’s licence also has to be on a plan that supports SCA.

Check the user’s licence

Do the obvious checks before getting into Citrix troubleshooting. In the Microsoft 365 admin centre, confirm the user has a Microsoft 365 Apps licence, that it’s assigned to the correct account and hasn’t expired or been removed, and that the user is signing in with the account that holds it. 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. SCA stores licensing information in the user’s profile under %LOCALAPPDATA%\Microsoft\Office\16.0\Licensing, and licensing files should appear there after a successful activation. In a Published App session, run:

powershell

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

There are three possible outcomes, and each points somewhere different:

• The folder is never populated. Activation isn’t completing, so look upstream at the licence, the SCA configuration, authentication and connectivity to Microsoft’s licensing services.
• Files appear during the session but 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, because plenty of guides treat all three as the same problem.

FSLogix and Office activation

FSLogix is commonly used to persist profile and Office data in virtual environments. The relevant setting is IncludeOfficeActivation under HKLM\SOFTWARE\Policies\FSLogix\ODFC, which controls whether Office activation data is redirected into the ODFC container. Its default is 1. Check it with:

powershell

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

The full list is in Microsoft’s FSLogix configuration settings reference.

Installing FSLogix doesn’t automatically fix activation

This is the assumption worth challenging. Having FSLogix installed isn’t enough. You need to establish that:

• the profile container is actually attaching
• the ODFC container is configured as expected
• Office activation data is being included
• the user can write to the container
• the container stays available for the whole session
• 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.

It’s also worth checking the file share itself. Microsoft has warned that the April 2026 Windows Server update changes the default Kerberos encryption type from RC4 to AES-SHA1, and that FSLogix file shares not upgraded to AES-SHA1 may have access issues. A container that can’t attach can’t persist activation data either.

Does the problem follow the user or the server?

This is one of the simplest tests. Say you have three session hosts, CTX01, CTX02 and CTX03, and a user gets an activation error. Check which server hosted the session, then have the user launch the application on another.

If the problem follows the user, investigate the licence, identity, profile, FSLogix, licensing token and authentication. If it stays with one server, look at that server’s 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 in one user’s profile.

Check connectivity to Microsoft’s services

Microsoft 365 Apps communicates with the Office Licensing Service and the Activation and Validation Service, and a session host that can’t reach them can’t keep activation working. In Citrix environments, session hosts often sit behind proxy servers, web filtering, firewall rules, SSL inspection or 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 authentication. SSL inspection deserves particular attention, because it can break token acquisition in ways that look nothing like a network problem.

Base firewall and proxy allow lists on Microsoft’s published Microsoft 365 URLs and IP address ranges, not a static list of domains from an old article. Microsoft updates that data at the start of each month.

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 logs in Microsoft Entra ID and look for failed sign-ins around the time they launch Word. Note which Conditional Access policies applied, the failure reason, the authentication requirement, the client application, the device information and the correlation ID. That’s far more useful than trying registry settings from a forum post.

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 Web Account Manager (WAM) 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, and I’d be cautious about treating them as a standard activation fix today.

According to Microsoft’s MSAL migration guidance, all support and development for ADAL, including security fixes, ended on 30 June 2023, and applications should use MSAL instead. The history causes some confusion: the original deprecation date was June 2022 before it was extended, and older articles cite both dates. That’s one more reason to check rather than assume.

None of this means an old registry workaround can never apply to a particular legacy environment. It means it should be a targeted workaround for a diagnosed problem, not a default step in a modern deployment. If an article tells 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, because that advice was written against much older builds of both.

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

Hybrid Microsoft Entra join isn’t a universal answer

Hybrid Entra join can help 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. Work out whether a Conditional Access policy requires the device to be Entra joined, hybrid Entra joined, marked compliant, or known and trusted, and then whether the session host meets 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 the licence is broken, because the specific code matters. AADSTS500011, for example, 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.

Microsoft keeps the full list in its AADSTS error code reference. Record the complete error text, not just the number, because 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, but 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 whether activation succeeded, where the activation data was stored, whether it persisted after logoff, whether the profile container attached correctly, and whether the same problem occurs on another session host. With those answers, resetting the profile becomes a controlled step rather than guesswork.

Activation is a chain

The most practical 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 know that, the troubleshooting becomes targeted rather than speculative.

What I’d be cautious about

Some of the older advice was a valid workaround for a specific problem when it was written. That doesn’t make it appropriate default configuration now. I wouldn’t do any of the following in a current deployment without a diagnosed reason:

• disabling WAM by default
• 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

Troubleshooting checklist

Work through these in order. Each step rules out one link in the chain before you move to the next.

1. Confirm the licence. The user needs a Microsoft 365 Apps licence on a plan that supports SCA, assigned to the account they actually sign in with.
2. Confirm Shared Computer Activation. SharedComputerLicensing should be 1 under HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Configuration. If it isn’t, nothing further down the list will behave reliably.
3. Check the activation data. Look in %LOCALAPPDATA%\Microsoft\Office\16.0\Licensing during and after a session. Whether the files are absent, present, or disappearing between sessions directs everything that follows.
4. Check FSLogix. Verify that the profile and ODFC containers attach and stay attached, that IncludeOfficeActivation is set as expected, and that the file share accepts the user’s Kerberos authentication.
5. Compare session hosts. Launch the app on a different server. A problem that follows the user is a user or profile issue; one that stays with a server is a server issue.
6. Check the Entra sign-in logs. Look for failed sign-ins and Conditional Access decisions at the time Office launches, and note the correlation ID.
7. Check network and proxy access. Confirm the session host reaches the current Microsoft 365 licensing and authentication endpoints, and that SSL inspection isn’t touching that traffic.
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 before applying any registry workaround.

Microsoft references

• Overview of shared computer activation for Microsoft 365 Apps – how SCA works and how to enable it
• FSLogix configuration settings reference – ODFC container settings, including IncludeOfficeActivation
• Microsoft 365 URLs and IP address ranges – the current endpoint list for allow lists
• AADSTS error code reference – what each Entra sign-in error means
• 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.