Outlook 365 app error 1001 on RDS environment ( FSLogix)

We're still seeing the issue, however it only occurs a short while after a user has changed their domain logon password. We sync on-prem AD to M365 via Azure AAD Sync.

Furthermore, it doesn't happen for all users when they are prompted to change their logon password. For example, this week there were five users who's passwords were due to expire and the issue only occurred for one of them.

Below are the steps that we follow when a user reports the problem with Outlook. We generally find we only have to go down as far as step 8.

1. Sign out of RDS fully. Then sign back in. Re-open Outlook and try clicking in the bottom right where it will either disconnected or need password. Click that and follow through the authentication process, multiple times if necessary. If an error pops up, close Outlook again and reopen it. Check if it has connected now.
2. Sign out of the Microsoft account via Excel.
3. Delete the Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy from C:\Users\AppData\Local\Packages
4. Delete IdentityCache and OneAuth folders from C:\Users(username)\AppData\Local\Microsoft.
5. Sign out of RDS profile and then sign back in.
6. Sign back in to the Microsoft account via Excel. An error message will most likely appear. Close Excel.
7. Open Outlook. Most of the time it will show Connected in the bottom right.
8. Open Excel and check to make sure it has signed back into the Microsoft account

If Outlook still won't play ball: 9. Locate the following key. Add the key if it is not present:

Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Common\Identity

Key name - EnableADAL

Key type: - DWORD

Key value – 1

10. Locate the following two keys and delete them if present:

Key location:

Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Common\Identity

Key 1 – DisableAADWAM

Key 2 – DisableADALatopWAMOverride

11. Open Credential Manager and delete all the credentials relating to Microsoft under the Windows Credentials section.
12. From Control Panel, open the Mail app, go to Show Profiles, highlight the Outlook profile, click Remove. Re-add the profile in the normal way.
13. Sign out of RDS and then sign back in.
14. Open Excel and sign in to the Microsoft account. Verify it has signed in successfully.
15. Open Outlook. It should show Connected in the bottom right.

Thanks for the post.

Not roaming the token is a big issue in environments with multiple session hosts in a collection.

This Citrix shellbridge fix, is Citrix proprietary, HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Citrix Virtual Desktop Agent. Unfortunately we are not using Citrix.

I have had a support ticket open with Microsoft for 11 months now. Unfortunately, Microsoft support is not providing me any helpful information. I wonder if Microsoft is working on a bug fix for this.

Does anyone else have a Microsoft support ticket open for this?

Is anybody else getting anywhere with Microsoft support?

Does anyone know if Microsoft is working on a bug fix?

Hello,

i have a Question. do you have the following notice in the redirections.xml?

<?xml version="1.0" encoding="UTF-8"?>

<FrxProfileFolderRedirection ExcludeCommonFolders="0">

<Exclude Copy="0">AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy</Exclude>

<Exclude Copy="0">AppData\Local\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy</Exclude>

<Exclude Copy="0">AppData\Local\Microsoft\TokenBroker</Exclude>

</FrxProfileFolderRedirection>

EDIT: Ok i didnt saw the reply from Admin Chris's posts. There is the notice.

Hi everyone

After loosing a lot of time investigating this b***-breaking issue, I found it worthy to spend some time sharing our solution here as well. Hopefully it might help some of you admins preventing more headaches on this MS issue.

One of our customers ran into this issue only since recently too! After many troubleshooting steps - thanks to everyone that contributed to this post btw - and going through all the presented workarounds (which sometimes seemed to work temporarily) we've found a permanent solution. Perhaps this will not be applicable to all of you, but at least our issue got solved using this method.

We are running RDS in a Citrix CVAD 2203 CU5 environment, so this might not be applicable to all of you, but the root cause might be related (as it is not Citrix... ;-)

*Servers are only domain (not hybrid or AAD) joined since Office is licensed using a different tenant.

Server 2019 OS standard 1809 build 17763.6293

Office 2402 build 17328.20588 (Semi-annual enterprise)

FSLogix 2210 hotfix 4 (2.9.8884.27471)

A login script runs the register WAM (Add-AppxPackage) commands for each user, and re-registers it if it is not present.

Resetting a user's profile did not solve the issue. Neither resetting appdata folders or what so ever. Even tried excluding FSLogix, rolling back PVS images, etc etc..

The cause lays in the password prompt not being able to be shown to the user, which generated this error [1001]. Once the user logs in by using a desktop instead of a published app, the issue did not occur! So this (CTX267071 - Shellbridge feature) is what we finally discovered and applied to all of our RDS (Citrix workers) servers which addressed the issue for us. This recommendation WAS described in the summary Lars posted here as well, via this link.

Solution:

HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\Citrix Virtual Desktop Agent
Name: Shellbridge
Type: REG_DWORD
Value: 1

Previous workaround:

Please note that the workaround described in this article was already applied for a couple of years, until now, since it suddenly does not work anymore!:

1. Disable Web Account Manager via registry.***

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity

“DisableADALatopWAMOverride”= dword:00000001

 

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Common\Identity

“DisableAADWAM”= dword:00000001

 

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Common\Identity

"DisableMSAWAM"= dword:00000001

 

Also mentioned there: ***    Disabling WAM as a workaround does not always work and may not be supported by Microsoft.

The above registry keys which served as a workaround for years have now been removed, as they no longer have a purpose for us.

Hope this helps! cheers to all

Now, after few weeks, the 1001 error returns! And other customers are now reporting similar issues as well (since end of September it seems).

This time, no difference whether the user is using published app or a full desktop. Issue occurs after authentication (password & MFA), after the "You are all set!" message and clicking OK.

After going through all the steps mentioned in Lars' post here again, discovered that the registry key "BlockAADWorkplaceJoin" kind of solves the 1001 error. HKLM:\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin -Name BlockAADWorkplaceJoin -Type DWord -Value 1

-> this fixes the issue of receiving the 1001 error on sign in. Remaining issue is that the token is not roamed in between sessions. One needs to perform an Office sign in again when starting a new Citrix session. It does not matter if FSLogix is used or not. Also, the profile exclusions and anti-virus have been ruled out here.

Other customers were also having the issue of not roaming the sign in anymore (having to activate Office again each new Citrix session). Of which some are also running Server 2022 btw.

Hoping someone has already found the solution for this.

Investigation still ongoing...