Recurring Office365 Authentication prompts in RDS Server 2022 and 2025

ibf 0 Reputation points
2026-03-12T19:23:55.9133333+00:00

We are experiencing intermittent Microsoft 365 authentication prompts in our Remote Desktop Services environment.

Users are occasionally prompted to re-enter their Microsoft 365 credentials in Outlook, even though the user profile and token cache directories are stored inside an FSLogix profile container.

The issue typically appears after several days of usage.

Outlook continues to function after re-authentication, but the repeated login prompts are disruptive for users.

Environment

  • Windows Server 2025 Remote Desktop Session Host or (not mixed)
  • Windows Server 2022 Remote Desktop Session Host
  • Multiple RDS servers in a farm
  • FSLogix Profile Containers
  • Microsoft 365 Apps for Enterprise
  • Shared profile storage on a file server (VHDX containers)

FSLogix is used to manage roaming profiles across all session hosts.

Key FSLogix configuration:

Enabled = 1

DeleteLocalProfileWhenVHDShouldApply = 1

RoamIdentity = 0

SizeInMBs = 102400

Profile containers mount successfully and the user profile loads correctly during login.

Authentication Configuration

To improve stability in the RDS environment we disabled WAM authentication and configured Office to use the ADAL authentication flow:

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

DisableAADWAM = 1

This was implemented because WAM-based authentication can cause instability in multi-session environments.

Token Storage

The following directories exist in the user profile and are stored inside the FSLogix container:

AppData\Local\Microsoft\IdentityCache

AppData\Local\Microsoft\OneAuth

AppData\Local\Microsoft\TokenBroker

However, the Windows Credential Manager does not contain any Microsoft Office authentication entries

Observed Behavior

Users intermittently receive a Microsoft 365 login prompt in Outlook even though:

  • The FSLogix profile container mounts successfully
  • Token directories exist in the user profile
  • Outlook was previously activated and functioning

The issue appears randomly after several days.

Event Log

Occasionally we observe related events in the Windows Event Log, including:

  • AppModel-State errors referencing Microsoft.AAD.BrokerPlugin
  • Application Hang events involving OUTLOOK.EXE

No related errors appear in the FSLogix logs, and profile containers mount successfully.

Troubleshooting Already Performed

We have already performed the following troubleshooting steps:

  • Verified that FSLogix containers mount correctly
  • Increased FSLogix container size to prevent disk space issues
  • Verified token cache directories inside the profile container
  • Confirmed that the FSLogix profile configuration is applied correctly
  • Verified that Outlook activation and licensing works correctly

Despite this, authentication prompts still occur intermittently.

We expect Microsoft 365 authentication tokens to persist correctly across sessions in an RDS environment using FSLogix profile containers.

Users should not be required to re-enter their credentials after successful authentication unless the token has expired or been revoked. We tried many but we cant find a solution. Maybe someone can help us?

Windows for business | Windows Server | User experience | FSLogix

2 answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-03-12T19:24:24.9466667+00:00

    The behavior matches known issues where Microsoft 365 authentication state and broker data are not roamed correctly in FSLogix-based multi-session environments, causing repeated prompts even though profiles mount successfully.

    Key points from the documented behavior:

    1. FSLogix 2210 and later stopped roaming certain Microsoft Entra ID (AAD) broker locations by default Starting with FSLogix 2210 (2.9.8361.52326), the following paths are explicitly not roamed as part of the user profile:
      • %USERPROFILE%\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
      • %USERPROFILE%\AppData\Local\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy
      • %USERPROFILE%\AppData\Local\Microsoft\TokenBroker
      These locations are directly related to Microsoft Entra ID token handling and the AAD Broker Plugin. When they are not roamed, users can be forced to re-authenticate to Microsoft 365 apps, Teams, OneDrive, etc., especially after reconnects or over multiple days. The event log entries mentioning Microsoft.AAD.BrokerPlugin align with this behavior.
    2. Recommended FSLogix configuration for Microsoft 365 token roaming The documented resolution for repeated Microsoft 365 authentication prompts in FSLogix environments is:
      • Install the latest FSLogix version.
      • Enable the RoamIdentity setting so that identity-related data is roamed correctly.
      RoamIdentity can be configured either:
      • Via registry: set the corresponding FSLogix RoamIdentity registry value to 1.
      • Or via Group Policy using the FSLogix ADMX templates.
      This setting is specifically called out to address scenarios where users are repeatedly prompted to authenticate to Microsoft Entra ID–based applications.
    3. Device join / PRT considerations The same FSLogix guidance also notes that for the best experience with Microsoft 365 authentication, the session hosts should be Microsoft Entra joined or Hybrid Microsoft Entra joined, so that a Primary Refresh Token (PRT) is created at sign-in. Standard domain-joined-only VMs rely on the Microsoft Entra ID plugin and are more prone to repeated prompts. In an RDS farm, ensuring that the hosts are Entra joined or Hybrid Entra joined, combined with RoamIdentity, is the recommended pattern.
    4. How this maps to the described environment In the described RDS setup:
      • FSLogix profile containers are working and profile data is roamed.
      • Token-related directories such as AppData\Local\Microsoft\IdentityCache exist, but AAD broker and TokenBroker locations may not be roamed due to the FSLogix 2210+ behavior.
      • Event logs show Microsoft.AAD.BrokerPlugin issues, consistent with non-roamed broker data.
      • Intermittent prompts after several days are consistent with tokens not being fully preserved across sessions and/or PRT not being available.
      Even though WAM is disabled and ADAL is used, the underlying Entra ID token/broker behavior and FSLogix profile handling still matter.
    5. Recommended actions
      1. Ensure the latest FSLogix build is installed on all RDS hosts (at least 2210 or later, ideally the current release).
      2. Explicitly enable RoamIdentity for FSLogix profiles:
        • Configure the FSLogix RoamIdentity setting (registry or Group Policy) to 1 for all users on all session hosts.
      3. Verify that the RDS hosts are Microsoft Entra joined or Hybrid Microsoft Entra joined so that a PRT is issued at sign-in. This significantly reduces repeated prompts for Microsoft 365 apps.
      4. After enabling RoamIdentity and confirming host join state, test with fresh user sessions (or test accounts) over several days to confirm that prompts no longer occur except when tokens legitimately expire or are revoked.

    These steps align with the documented FSLogix guidance for resolving repeated Microsoft 365 authentication prompts in multi-session environments.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. Domic Vo 33,190 Reputation points Independent Advisor
    2026-03-13T02:24:49.66+00:00

    Hello ibf,

    The behavior you are describing is a well‑known challenge in RDS environments with Microsoft 365 Apps when FSLogix is used to roam user profiles. Even though the token cache directories are correctly stored inside the FSLogix container, the underlying issue is that ADAL tokens are not always persisting reliably across multi‑session logons. This is especially true when WAM is disabled, because Office falls back to ADAL/MSAL flows that depend heavily on the TokenBroker and OneAuth directories. In multi‑user server environments, those components can occasionally fail to refresh tokens correctly, which results in Outlook prompting for re‑authentication after several days.

    From your configuration, the registry key HKCU\Software\Microsoft\Office\16.0\Common\Identity\DisableAADWAM = 1 is forcing Office to bypass WAM. While this avoids instability in multi‑session scenarios, it also removes the modern token refresh mechanism. Microsoft’s current guidance is that WAM should remain enabled in FSLogix environments, because FSLogix containers are designed to capture and persist the token broker cache. Disabling WAM often leads to exactly the intermittent prompts you are seeing.

    The most reliable fix is to re‑enable WAM by setting DisableAADWAM = 0 (or removing the key entirely) and ensuring FSLogix is updated to the latest release. Microsoft has addressed multiple token persistence issues in recent FSLogix builds, particularly around AppData\Local\Microsoft\TokenBroker and AppData\Local\Microsoft\OneAuth. You should also confirm that your FSLogix containers are not being mounted in read‑only mode and that the VHDX files are not reverting to snapshots, as this can silently discard token updates.

    Additionally, check that the Windows Credential Manager service (VaultSvc) is running and not disabled. Even though Office primarily uses token broker caches, certain refresh flows still rely on Credential Manager. If it is disabled, Outlook may fail to silently renew tokens.

    If you want to validate the root cause, monitor Event Viewer under Applications and Services Logs > Microsoft > Windows > AAD > Operational. Look for token refresh failures or broker plugin errors. If you see repeated failures from Microsoft.AAD.BrokerPlugin, that confirms the token broker is not persisting correctly, which is usually tied to WAM being disabled.

    In short, the intermittent prompts are not a FSLogix mounting issue but a side effect of disabling WAM. The best practice is to re‑enable WAM, keep FSLogix updated, and ensure the token broker cache is fully roamed inside the profile container. If you cannot re‑enable WAM due to prior instability, then you are essentially limited to ADAL token lifetimes, and users will continue to see prompts after several days because ADAL does not refresh tokens as seamlessly in RDS.

    I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

    Domic Vo.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.