SSO Failure: Microsoft Apps for single user on VDI

MurphyMurph

If you generated a brand new profile from scratch, but the DCOM error still occurs, the corruption is not related to their personal data. The user is inheriting a broken configuration the moment their new profile is provisioned. This confirms that the root cause actually resides on your golden image or within your FSLogix infrastructure, overriding our previous focus on the user's individual session.

You need to pivot back to your master golden image and verify the integrity of the base application packages. When a new user logs in, Windows relies on the system defaults to build their profile. If the Microsoft.AAD.BrokerPlugin is unregistered or missing core system files within the master image's C:\Windows\SystemApps directory, every new profile created from that image will generate that exact "File Not Found" event log. You should boot the golden image in maintenance mode, open an administrative PowerShell session, and run the package re-registration command globally for all users to repair the baseline provisioning system.

If the base packages on the golden image are healthy, you must inspect your FSLogix redirections.xml file. A misconfigured custom exclusion rule might be actively preventing the required AppData folders for the authentication broker from mounting or saving into the virtual disk during the logon process. This creates a conflict where the operating system attempts to launch the token broker, but the FSLogix filter driver effectively hides or blocks the path, instantly triggering the exact failure sequence you are experiencing.

MurphyMurph You should avoid applying this fix to your golden image. Because this authentication broker corruption is isolated entirely within a single user's localized AppData directory, modifying the master golden image will not resolve their specific profile issue and could unnecessarily alter the baseline for all your healthy users. The golden image is essentially a blank slate, whereas the problem here lies entirely within the user's unique profile container.

You need to perform this repair directly within the user's active session while they are logged into their non-persistent image. In a non-persistent environment, user data is typically retained using a profile management solution like FSLogix. By renaming the corrupted folder and running the PowerShell re-registration command during their active session, the newly repaired token broker state will be captured and permanently saved to their roaming profile disk the moment they log off.

If you prefer to handle this on the backend without user interaction, you can take an alternative administrative approach. You would ensure the affected user is completely logged off to release any file locks, temporarily mount their specific profile virtual hard disk from your network storage share, and manually delete or rename the corrupted Microsoft.AAD.BrokerPlugin folder from that disk. When the user logs into a new non-persistent session, Windows will automatically rebuild the missing folder from the system defaults.

VP

Hi MurphyMurph,

Based on the Event Viewer logs provided, the root cause of the auto-login failure is tied directly to a corrupted Entra ID authentication broker within your local Windows profile. Event 10001 error shows that the Microsoft.AAD.BrokerPlugin is failing to start because it cant find the necessary files, and this is what the 2147942402 error code points to. This plugin acts as the core engine for handling Microsoft 365 single sign-on and token requests on your machine. The Kernel-General event further confirms that the system is struggling to manage the registry hive specifically for this plugin's settings data. You can safely ignore the DistributedCOM 10016 error shown in your last image, as it is standard Windows background noise regarding security center permissions and is completely unrelated to your login issue.

Because this corruption is isolated to your local profile, the most effective approach is to manually reset the authentication broker package natively in Windows. To resolve this, you need to clear the corrupted plugin data and re-register the application package. First, sign out of all Microsoft applications and disconnect any work or school accounts from the Windows Settings app under the Accounts section. Next, open File Explorer and navigate to your local application data directory using the path C:\Users\your_username\AppData\Local\Packages. Inside this directory, locate the folder named Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy. Rename this folder by appending .old to the end of the name. This forces Windows to stop using the corrupted data while preserving it as a backup in case you need to revert the changes.

Once the corrupted folder is renamed, you need to tell Windows to rebuild the authentication broker. Open Windows PowerShell with administrative privileges and run the command Add-AppxPackage -DisableDevelopmentMode -Register "C:\Windows\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AppxManifest.xml" to execute the system repair. This command forces Windows to reinstall the broker plugin using the clean, native system files, generating a fresh folder in your local AppData path. After the command completes, perform a system reboot. Launch any Microsoft application and sign in once to establish a new authentication token, which should allow your auto-login functionality to resume normally.

Hope this answer brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

VP

On non-persistent VDI, Microsoft 365 Apps single sign-on and activation depend on correct VDI configuration and on the AAD Broker/identity components not being roamed or corrupted. The event log entries around Microsoft.AAD.BrokerPlugin and token handling indicate that the local identity/token broker state is in a bad or inaccessible state, so SSO cannot complete and apps prompt for sign-in.

Use these checks and fixes for a single user on VDI:

1. Verify VDI and SSO configuration
   • For non-persistent VDI, configure Seamless Single Sign-On (SSO) with Microsoft Entra Connect so that the user is automatically signed in when starting a new session. See the guidance under Make sure Virtual Desktop Infrastructure (VDI) is configured correctly and Microsoft Entra seamless single sign-on.
   • Ensure Microsoft 365 credentials themselves are not roamed between VDI sessions. Roaming identity data can leave the token broker in a bad state and break SSO.
2. Avoid roaming AAD Broker and token data
   • Confirm that profile management tools or user profile disks are not roaming any data under %localappdata% for the following paths and keys, which must remain local on each VDI instance:
     • %localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
     • %localappdata%\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy
     • %localappdata%\Packages\<any app package>\AC\TokenBroker
     • %localappdata%\Microsoft\TokenBroker
     • HKEY_CURRENT_USER\SOFTWARE\Microsoft\IdentityCRL
     • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\AAD
     • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WorkplaceJoin
   • If these locations are currently roamed, update the profile configuration so they are excluded, then have the user start a fresh VDI session so new local identity data can be created.
3. Check shared computer activation and token roaming
   • If Microsoft 365 Apps are deployed with shared computer activation on RDS/VDI, and the user is repeatedly prompted to activate, enable licensing token roaming as described in Overview of shared computer activation for Microsoft 365 Apps.
   • If licensing token roaming cannot be enabled, configure the Session Collection to Store all user settings and data on the user profile disk so the Office licensing token persists between sessions.
4. Ensure ADAL and identity components are enabled locally
   • Confirm that ADAL is enabled on the VDI image:
     1. Open Registry Editor.
     2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\Common\Identity\EnableADAL.
     3. Set the value to 1.
     4. Restart the VDI and test Office sign-in/SSO again.
5. Clean up cached Office credentials for the affected user
   • On the VDI session where the issue occurs:
     1. Open Credential Manager → Windows credentials.
     2. Remove any entries for MicrosoftOffice16.
     3. In Settings → Accounts → Access work or school, disconnect any work account that is listed but not used for Windows sign-in.
     4. Restart the VDI session and try activating/signing in again.
6. If the environment is non-persistent and federated with SSO but still prompts every session
   • This matches the scenario where Office 2016/365 on non-persistent VDI with federated IdP and SSO still prompts for sign-in and logs errors like BlockedRequest or 0xc0f10005. In that case, collect Office ULS logs and open a support request so additional log analysis can be done.
7. If sign-in failures show error 1001 or similar
   • Review whether any profile migration or roaming tools have ever moved the AAD Broker or TokenBroker data listed above. Roaming those components is unsupported and can directly cause Office sign-in failures on both VDI and physical devices.
   • If this pattern matches, treat it as a profile/identity corruption issue, correct the roaming configuration, and test with a new, clean profile on the VDI.

Applying these steps focuses on ensuring that:

• VDI and Seamless SSO are configured correctly.
• AAD Broker and token data are kept local and not roamed.
• Office shared computer activation and licensing tokens are handled correctly.
• Cached or corrupted credentials are cleared so SSO can succeed.

References:

• Sign in issues when activating Microsoft 365 Apps
• Troubleshoot issues with shared computer activation for Microsoft 365 Apps
• Connection issues when signing in after updating to Office 2016 build 16.0.7967 on Windows 10
• Error “Something Went Wrong [1001]” signing in to Microsoft 365 Desktop Applications