Running Microsoft 365 Apps on Citrix DaaS 2026 (UPM Deep Dive)

When Word asks for activation after every Citrix logon, it is tempting to blame “the Office cache.” I would slow down before deleting anything. A missing licensing token, a failed sign-in, an unavailable profile store and a Conditional Access decision can look remarkably similar to the person trying to open a document.

Citrix Profile Management, often called UPM, can be part of a sound Microsoft 365 Apps design. It is not a legacy fallback that only copies files, and FSLogix is not a guarantee of seamless identity. The useful question is which component owns each part of the user state, and whether that combination is supported.

This technical revision was checked on 27 October 2026. It covers non-persistent Citrix DaaS workloads, Shared Computer Activation, classic Outlook, Teams and the OneDrive support boundary. It is a design guide, not a claim that these settings have been tested together in your environment.

Start with support and licensing, not an exclusion list

The original Windows Server 2022 baseline needs updating. According to Microsoft's Server support policy, full Microsoft 365 Apps support on Server 2022 ends with mainstream support in October 2026. That boundary has now passed. Microsoft's security-update provision through 10 October 2028, with feature updates stopping at Version 2608, is migration runway, not an extension of full support.

For a new Windows Server design, Server 2025 is the relevant supported candidate to evaluate: Microsoft lists Microsoft 365 Apps support through its mainstream-support period, ending in October 2029. That does not make every Citrix build, add-in or peripheral automatically compatible. Server 2016 and 2019 already passed their Microsoft 365 Apps support boundary in October 2025.

Before building the image, I would require the following:

A supported intersection of versions: Windows edition and patch level, Citrix VDA, UPM release/CU, Microsoft 365 Apps channel/build and application add-ins. Citrix DaaS being a cloud service does not update the VDA or UPM for you. Use the UPM requirements and compatibility references, including the requirements for your actual LTSR or CR branch.
Licenses assigned to each user that permit Shared Computer Activation: Microsoft 365 Apps for enterprise plans qualify, as does Microsoft 365 Business Premium. Business Standard does not include SCA rights. Verify the actual subscription, not just whether Word appears in the portal.
The other access rights: Citrix entitlement, Windows/virtualization access and RDS licensing where applicable remain separate from the Microsoft 365 subscription. If FSLogix is part of the design, check its entitlement separately rather than assuming it requires an additional purchase.
Working identity and connectivity: user account mapping, DNS, time, TLS, proxy behaviour, Microsoft sign-in/licensing endpoints and the applicable Conditional Access/MFA policies. Do not solve a sign-in problem by permanently disabling a security control.
A usable profile store: correct per-user SMB/share and NTFS permissions, low enough latency, capacity for growth, monitoring and a tested recovery path. A working first logon does not establish that the store can handle a morning logon surge.

Keep activation, authentication and profile persistence separate

Shared Computer Activation lets multiple individually licensed users use Microsoft 365 Apps on a shared machine. Each user still needs a valid entitlement. Activating Office as the image administrator does not activate it for everyone else.

Microsoft documents a 30-day SCA licensing-token validity period. Office attempts renewal as expiry approaches while the user is signed in and using the apps. Reliable access to the licensing service is therefore required; profile persistence is not an offline licensing workaround.

The default SCA token location is:

%localappdata%\Microsoft\Office\16.0\Licensing

That is not the same thing as an Entra Primary Refresh Token, a WAM sign-in cache, an Outlook OST or the Office document cache. Keeping a licensing token does not prove that authentication will be silent. Losing it does not guarantee activation will fail: Office can request another token when entitlement, authentication and connectivity are working.

Choose a UPM design deliberately

Modern Citrix Profile Management supports file-based profiles and VHDX containers. There are three useful patterns to distinguish:

File-based UPM: selected profile data is synchronized with the user store. Effective inclusions, exclusions and logoff completion matter.
File-based UPM with selected containers: large or application-specific data can use a container while the rest of the profile remains file-based.
Full UPM profile container: the profile is containerized. File-based policies do not all retain their previous meaning; use the container policy documentation rather than copying an old GPO unchanged.

FSLogix is another container design, not “the version that handles all identity automatically.” Storage performance, supported identity behaviour, locks, exclusions and failure handling still matter. Avoid having two profile products independently manage the same profile or application data. Any intentional coexistence needs a documented division of ownership and validation.

For file-based UPM, if you retain the default SCA location, ensure the relevant data is actually persisted. The corresponding path relative to the user profile is AppData\Local\Microsoft\Office\16.0\Licensing. Check the resultant policy, not just the GPO editor. Do not include all of AppData\Local to fix one missing folder.

An alternative is Microsoft's explicit SCA-token relocation mechanism. With the Office Deployment Tool, the optional properties are:

<Property Name="SCLCacheOverride" Value="1" />
<Property Name="SCLCacheOverrideDirectory"
          Value="%appdata%\Microsoft\Office\SCA" />

This example chooses a location inside each user's profile. Confirm that UPM persists that folder and that the user can write to it. The properties are only necessary when moving the token from its default location. Microsoft also permits a user-specific network folder, but warns that network latency can affect Office launch. Never use one shared token directory for every user, and do not modify the token files.

Deploy Office as a maintained image component

The essential ODT configuration for SCA is simple. For example, the following installs the enterprise product; adapt the product ID, architecture, languages and channel to your entitlement and application compatibility:

<Configuration>
  <Add OfficeClientEdition="64" Channel="MonthlyEnterprise">
    <Product ID="O365ProPlusRetail">
      <Language ID="en-us" />
      <ExcludeApp ID="Teams" />
    </Product>
  </Add>
  <Property Name="SharedComputerLicensing" Value="1" />
  <Display Level="None" AcceptEULA="TRUE" />
</Configuration>

This is a configuration example, not a pinned production release. Teams is managed separately. Validate Office bitness against add-ins and other installed Office components. Use a supported channel and build, with a controlled update source or deployment policy.

In a non-persistent pool, my preference is to update the reference image, test it, then replace or recompose drained machines. However, Updates Enabled="FALSE" is not a complete servicing strategy. If automatic updates are disabled on clones, someone still needs to own patch deadlines, emergency fixes, image rollout and rollback. Otherwise “version control” becomes an unpatched image.

Do not seal the image with a test user's signed-in Office state or pre-generated per-user activation data. Validate activation on a provisioned clone with a normal licensed user.

Hybrid join helps SSO. It does not transport SCA tokens.

The earlier claim that non-persistent VDI is fundamentally incompatible with hybrid join was too broad. Microsoft documents supported non-persistent hybrid-join scenarios, with infrastructure and vendor-specific limitations. The implementation must handle registration timing, cloning and stale device objects correctly.

A PRT represents user authentication in a device context; it is not a portable file to copy between VDAs. Do not clone an already registered device identity into every machine. Nor should you assume every ordinary reboot necessarily creates a new device ID: that depends on the provisioning and identity lifecycle.

Run dsregcmd /status in the affected user's session when investigating device registration and SSO. Interpret AzureAdJoined, DomainJoined and AzureAdPrt against the intended architecture. AzureAdJoined=YES and AzureAdPrt=YES are not universal SCA activation prerequisites. SSO is recommended; supported interactive authentication can still obtain an SCA license.

Remove the old blanket inclusion of Microsoft\IdentityCache. Microsoft's device-identity guidance explicitly identifies identity locations that must not roam, including IdentityCache, OneAuth, TokenBroker and AAD BrokerPlugin state. A supported SCA-token roaming feature does not authorize copying those device-bound authentication caches.

I would also remove any logon action that routinely deletes HKCU\Software\Microsoft\Office\16.0\Common\Identity. It is not a harmless best practice. Capture the failure first; if a documented activation or identity reset is needed, target the affected user, preserve evidence and follow the relevant Microsoft procedure. Deleting identity state at every logon can create the prompts you are trying to eliminate.

Outlook needs a cache and search design of its own

This section concerns classic Outlook. Do not assume the same profile and cache model applies to new Outlook.

Decide whether Cached Exchange Mode is appropriate for the workload, and size the cached-mail window, shared-mailbox content and storage accordingly. Copying a large, active OST through ordinary file synchronization is not the design I would choose for a non-persistent pool.

Citrix's Outlook search-index roaming feature uses separate VHDX files for the OST and search database. Its prerequisites include Windows Search, and its documented OS-specific configuration must be checked for the selected UPM release. Do not copy a Windows Search registry tweak into every catalog without choosing which component owns indexing.

Concurrent sessions need explicit attention. Citrix provides a concurrent Outlook-search feature with a configurable number of OST disks; additional sessions can fall back to local OST storage when that allocation is exhausted. Test the actual published-app and desktop session pattern, container capacity, detachment/recovery and search after moving to another VDA. “Outlook opens” is not the acceptance test.

Teams: profile persistence is only half the job

Use the current Teams VDI requirements for the host OS, patches, WebView2, VDA, UPM and Workspace app. The documented host floors include Server 2022 build 20348.2402 and Server 2025 build 26100.2886; these are minimums, not recommended patch targets. They do not extend Office support on Server 2022.

For Windows endpoints connecting to Citrix, legacy WebRTC optimization passed its support-end milestone on 1 October 2026; Microsoft lists end of availability for 1 April 2027. Evaluate the new SlimCore-based optimization with the supported Workspace app, Teams plugin and endpoint prerequisites. Those dates must not be generalized to Linux or macOS, which have different timelines.

Persist the documented Teams package/settings state, including AppData\Local\Packages\MSTeams_8wekyb3d8bbwe and the required TeamsSharedConfig files. Apply the vendor's current exclusions instead of excluding the entire package as “cache.” Microsoft specifically requires the TeamsTfwStartupTask registry state to persist in non-persistent VDI. Check the installed UPM release's MSIX handling and known fixes.

Then test a real call: confirm the optimization state, camera, microphone, screen sharing and endpoint CPU behaviour. A successful launch or a remembered account does not prove that media is offloaded.

OneDrive is a separate support decision

The earlier advice to “roam configuration only” was not sufficient. OneDrive needs a supported sync-database, file/placeholder and session-lifecycle design, not just its program-settings directory.

Citrix documents a UPM OneDrive container, including version-dependent concurrent-session capabilities. That is a Citrix capability statement. It does not automatically establish Microsoft support for every non-persistent UPM-only configuration.

Microsoft's OneDrive VDI guidance, updated on 8 October 2026, explicitly requires FSLogix for the Citrix Virtual Apps scenario it describes. It lists Windows 11 and Server 2025 in that scenario and requires per-machine OneDrive installation for non-persistent use. A blanket Server 2022 + UPM-only recommendation is therefore not defensible here.

If OneDrive is required, validate the exact desktop versus published-app scenario against both vendors' support statements before choosing the profile architecture. Also check Files On-Demand, Shellbridge where applicable, logoff behaviour and simultaneous-session restrictions. Citrix's concurrent OneDrive capability must not be treated as permission to mount the same FSLogix container concurrently.

Storage and session failures deserve a design, too

Protect the store: isolate users with the prescribed permissions, protect tokens and profile data, and provide backup/recovery. Container failover or replication is not a substitute for recoverable backups.
Measure the busy period: capture SMB/storage latency, mount time, logon duration, capacity growth and local write activity during realistic concurrency. Do not size only from the empty container.
Choose failure behaviour: UPM full containers can fall back to temporary profiles by default when unavailable. Assess the documented logoff-on-container-unavailable policy so a storage fault does not quietly become lost user changes.
Test multiple sessions: UPM container read/write ownership, optional multi-session write-back and application-specific containers have different semantics. Test a desktop plus published applications, reconnects and logoff order.
Keep security exceptions narrow: apply documented, product-specific AV/EDR exclusions only where needed and review their scope. Do not exclude all of AppData, disable scanning globally or grant broad access to containers for convenience.
Know the rollback boundary: restoring an old VDA image does not revert a profile schema, an application database or server-side policy. Test compatible recovery before a broad rollout.

The checks I would use before calling it ready

Confirm the support/licensing matrix and record the actual OS, Office, VDA, UPM, Teams, OneDrive and endpoint versions.
On a fresh clone, use an ordinary licensed user to launch Office and verify Shared Computer Activation under File → Account → About. Check effective SCA configuration and the configured token location without editing token files.
Log off cleanly, use a different VDA, then reboot/recompose and repeat. Separate activation failures from sign-in prompts and profile-store errors.
Exercise renewal or an approved token-expiry test, temporary endpoint/connectivity failure and container-unavailable behaviour. Do not declare success from a token created five minutes earlier.
Validate Outlook cache/search, Teams media optimization and the supported OneDrive scenario, including simultaneous sessions and clean logoff.
Rehearse the next image update and a targeted recovery. Keep UPM logs, Office activation errors and Entra sign-in correlation details; do not publish token contents.

I would not choose between UPM and FSLogix from a table saying one is “manual” and the other “automatic.” Both have capabilities and support boundaries worth understanding. Start with the application mix, particularly OneDrive, then choose who owns each piece of state.

The goal is not to make a licence prompt disappear once. It is to keep Office supported, preserve the right user data and know what happens when a host, token or share is no longer available.

Technical references

Microsoft and Citrix documentation checked on 27 October 2026. Citrix feature references below use the current Profile Management 2603 documentation; confirm availability and behaviour in your deployed LTSR/CU or CR branch.