Windows 10 Multi-User - Troubleshoot Office 365 App Sign-in Issues (Outlook, OneDrive, Teams)

Recently we’ve seen a trending issue across some of our earlier deployed WVD environments, in which Outlook, Teams and OneDrive are failing to re-aquire a sign-in token and not allowing us to re-enter a password.

For example, in Outlook we can see the status indicator in the bottom right corner of Outlook says “Need password” (show below) - however when we clicked the needs password button to re-enter the password the sign-in window would simply flicker open for a split second before closing.

In this scenario I have seen many websites suggest simply enforcing the “DisableADAL” registry key - forcing apps to use basic authentication. This approach is not recommended as it enforces basic authentication, which is insecure and becoming widely phased out.

To fix this issue correctly we must first identify what is causing the modern authentication refresh to fail.

Cause #1 - Missing AAD Token Broker AppX Package

We found that under some circumstances the Windows AppX package for the Azure Active Directory token broker was missing from the users profile.

This package is responsible for aquiring AAD access tokens using the Primary Refresh Token. Without it any attempts to re-authenticate using the PRT will immediately fail.

We can confirm that this is the root cause by running the following PowerShell command: Get-AppxPackage Microsoft.AAD.BrokerPlugin

If your PowerShell output is blank or does not look similar to the above screenshot then you are missing the AAD Broker Plugin, and will need to follow the below steps to re-add the package.

The Solution

To immediately fix the issue and allow the applications to authenticate you can run the following command to install the package:

Add-AppxPackage `
 -Register "C:\Windows\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Appxmanifest.xml" `
 -DisableDevelopmentMode

In our environment we implemented a simple check when the user logged in that would detect if the plugin was missing and re-install it should it be missing. Script provided below.

$brokerService = Get-AppxPackage Microsoft.AAD.BrokerPlugin

if($brokerService -eq $null){
    Write-Host "Broker service missing - reinstalling" -ForegroundColor Yellow
    Add-AppxPackage -Register "C:\Windows\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Appxmanifest.xml" -DisableDevelopmentMode
}Else{Write-Host "Broker service found - exiting now" -ForegroundColor Green}

You can implement this as a log-in script via Group Policy, using the “User Configuration” node.

Cause #2 - Device is Azure AD Registered State

In the first iterations of the Windows 10 Multi-User OS the ability to register the device against an Azure AD tenant was still avaliable to all users. If the user clicked the “use this account everywhere” button when signing into and Office 365 application, the device would register against the AAD tenant.

You can confirm this by logging into the Azure AD portal and navigating to “Devices” om the left-hand pane, from the devices blade find or search for your Windows 10 MU device.

Once you’ve located your device, check the status of the “Join Type” column, if you see “Azure AD Registered” like in the below screenshot, this is unfortunately root cause.

Follow the instructions below to manually clear out the tokens and get the authentication working again.

The Solution

Fix the user profile by manually clearing the AAD tokens

To fix the issue immediately for the user affected, you can manually clear out all stored AAD tokens from their physical location on the disk.

Navigate to the following path:

%LOCALAPPDATA%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AC\TokenBroker\Accounts

Delete all of the files inside of this folder (or copy them elsewhere) and then log-in and out from Windows. When you next open your Office 365 Application you will be met with the Office 365 sign-in screen, and the sign-in process should now work.

Prevent the issue from re-occuring

Microsoft had advised us through a Support Ticket that the only solution was to rebuild the VMs using a newer copy of the image, with AAD registration pre-disabled.

We did have some luck in reducing the issue frequency by combining the solution from Cause #1 and ensuring that SSO for Azure AD was enabled for the Windows 10 MU machines.

After eventually completely reprovisioning the clients VMs using the latest release of the Windows 10 Multi User image, the issue has not resurfaced since and we’ve had little to no issues with the AAD token broker, even without the self-healing script from cause #1.