This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(128, 8%, 22%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EA%3C/text%3E%3C/svg%3E)
Hello,
We encounter an issue with M365 apps (Outlook, Work, Excel) on a specific environment ( Remote Desktop Service)
Sometime, when an user open his application (Outlook for instance) on a RDS, an authentification pop and ask for credentials. If the user enter his credentials, he encounter a 1001 error.
« We encountered an issue [1001] »
https://learn-attachment.microsoft.com/api/attachments/5a947921-955a-4688-ad93-acc305bf77c6?platform=QnA
We already try some step to resolve the issue that help in some case but not all the case, and not defintely for a same user ( Issue occur again) :
The main issue is that the error can occur again few day laterfor the same user.
We also generate some log from M365 apps client during the signin process with this link to help : https://learn.microsoft.com/en-us/office/troubleshoot/diagnostic-logs/how-to-enable-office-365-proplus-uls-logging
In the log I find the reference to the 1001 error but the log is a bit complex to understand or analyse.
0xa3e4 Microsoft Outlook Identity Authentication Client 48cmb Monitorable OneAuth log {"Message": "[MSAL:0004]\tERROR \tErrorInternalImpl:134\tCreated an error: 58tm1, StatusInternal::Unexpected, InternalEvent::None, Error Code 2147942403, Context '(pii)'", "IsError": true}
07/07/2023 09:04:21.440 OUTLOOK (0x8b30) 0xa3e4 Microsoft Outlook Identity Authentication Client 48cmb Monitorable OneAuth log {"Message": "[OneAuth:Error:58tm1:db6d7d6e-a557-4465-a968-a874c5e456e5] (Code:1001) An unexpected error occurred.", "IsError": true}
07/07/2023 09:04:21.440 OUTLOOK (0x8b30) 0xa3e4 Microsoft Outlook Identity Authentication Client 48cmb Monitorable OneAuth log {"Message": "[OneAuth:Error:9vdpp:db6d7d6e-a557-4465-a968-a874c5e456e5] Unexpected error code: 1001", "IsError": true}
Environment :
Using Classic Outlook on Windows for personal email, calendar, and contact management
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.
We've gone from about 5 a day to none in the last week as well and we've not done anything to change Office 365
Our 1001 errors stem from Workplace Join enabled on our VDIs and we should not have. We have been getting 1001 errors pretty consistently for a little over a month now. After this implementation, they have stopped and have so for approx 2 weeks. Here's what we noticed and what we did.
Our environment uses multi-session servers. Server 2019.
Some clients use profile containers, some use Citrix Profile Management. Both were having 1001 errors.
Because we had workplace join enabled in our non-persistent environment, every time someone authenticated and workplace joined, a duplicate device entry was created with the Hostnames of all our non-persistent VDIs. I saw this in Microsoft Entra, under devices. We had hundreds of Stale Devices, all dupes of our VDI hostnames. And hundreds of unmanaged devices in the same state. I removed all of those.
This article here clued me in to that and also the potential problems it may cause.
Quotation from the article:
"Failure to manage stale devices can lead to pressure increase on your tenant quota usage consumption and potential risk of service interruption, if you run out of tenant quota. You should follow the guidance documented below when deploying non persistent VDI environments to avoid this situation."
Also the registry entry it states to ensure that is set:
"When using non-persistent VDI, if you want to prevent adding a work or school account, ensure the following registry key is set:
HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin: "BlockAADWorkplaceJoin"=dword:00000001"
"
I set that key, via GPO on our VDIs.
After setting that registry key, new profiles authenticate without incident and more smoothly. There's no more attempt to WPJ. However, existing profiles that were created before the registry key above were set, still attempt to workplace join. With WPJ disabled via GPO, profiles in this state will attempt to WPJ, but eventually time out and auth successfully. (the little WPJ box just sits and spins for a minute or so) To address this, I made a batch script that deletes all the M365 authentication locations. This way we don't have to delete the entire user profile. The script definitely takes a more "scorched earth" approach. I run this within the logged-in user context. I then log off the user, log back in, attempt to authenticate again. It's usually successful. If not, I delete the entire profile under mail in control panel and try again.
Here's the batch. Please use at your own risk:
"
:: @echo off
setlocal
:: Delete directories
rd /s /q "%userprofile%\AppData\Local\Microsoft\IdentityCache"
rd /s /q "%userprofile%\AppData\Local\Packages\Microsoft.AccountsControl_cw5n1h2txyewy"
rd /s /q "%userprofile%\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy"
rd /s /q "%userprofile%\AppData\Local\Microsoft\TokenBroker"
rd /s /q "%userprofile%\AppData\Local\Microsoft\OneAuth"
rd /s /q "%userprofile%\Appdata\Local\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy"
:: Search for and delete TokenBroker directories
FOR /D /R "%localappdata%\Packages" %%D IN (*\AC\TokenBroker) DO (
IF EXIST "%%D" (
echo Deleting: %%D
rd /s /q "%%D"
)
)
:: Delete registry keys
reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\AAD" /f
reg delete "HKCU\Software\Microsoft\WindowsNT\CurrentVersion\WorkPlaceJoin" /f
reg delete "HKCU\Software\Microsoft\Office\16.0\Common\Identity\Identities" /f
reg delete "HKCU\Software\Microsoft\IdentityCRL" /f
endlocal
echo Script completed.
pause
"
Note:
-You'll need to disable the GPO "Prevent access to registry editing tools" for a bit if you want to prevent access denied when deleting those registry keys.
Other things I've found:
If you're including/excluding folders in your profiles after log off, make sure these two folders are included, or users will be asked to authenticate every fresh login.
'AppData\Local\Microsoft\OneAuth'
'AppData\Local\Packages\Microsoft.AccountsControl_cw5n1h2txyewy'
That's it. Maybe that makes sense. I hope that helps someone. I saw someone post in this thread that their 1001 errors just went away. Maybe this wasn't the cause and MS fixed something on their side. Either way, WPJ should not be enabled in an Non-Persistant VDI env per Microsoft, so at the very least, we're no longer getting duplicate and stale devices in Entra and the auth process is as it should be.
Summary:
1001 errors seem to occur during the WPJ process. Does your env need Workplace Join? If not, turn it off with the reg key above, then fix your existing profiles by nuking all M365 auth locations, and reauthenticate.
Great Post above
I did add the registry key to block WPJ back in April. However on checking Entra there are still the stale devices for the non-persistant RDS Servers - 47 of them. We'll take the above into consideration when planning next actions
Our 1001 errors stem from Workplace Join enabled on our VDIs and we should not have. We have been getting 1001 errors pretty consistently for a little over a month now. After this implementation, they have stopped and have so for approx 2 weeks. Here's what we noticed and what we did.
Our environment uses multi-session servers. Server 2019.
Some clients use profile containers, some use Citrix Profile Management. Both were having 1001 errors.Because we had workplace join enabled in our non-persistent environment, every time someone authenticated and workplace joined, a duplicate device entry was created with the Hostnames of all our non-persistent VDIs. I saw this in Microsoft Entra, under devices. We had hundreds of Stale Devices, all dupes of our VDI hostnames. And hundreds of unmanaged devices in the same state. I removed all of those.
This article here clued me in to that and also the potential problems it may cause.
Quotation from the article:
"Failure to manage stale devices can lead to pressure increase on your tenant quota usage consumption and potential risk of service interruption, if you run out of tenant quota. You should follow the guidance documented below when deploying non persistent VDI environments to avoid this situation."
Also the registry entry it states to ensure that is set:
"When using non-persistent VDI, if you want to prevent adding a work or school account, ensure the following registry key is set:
HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin: "BlockAADWorkplaceJoin"=dword:00000001"
"I set that key, via GPO on our VDIs.
After setting that registry key, new profiles authenticate without incident and more smoothly. There's no more attempt to WPJ. However, existing profiles that were created before the registry key above were set, still attempt to workplace join. With WPJ disabled via GPO, profiles in this state will attempt to WPJ, but eventually time out and auth successfully. (the little WPJ box just sits and spins for a minute or so) To address this, I made a batch script that deletes all the M365 authentication locations. This way we don't have to delete the entire user profile. The script definitely takes a more "scorched earth" approach. I run this within the logged-in user context. I then log off the user, log back in, attempt to authenticate again. It's usually successful. If not, I delete the entire profile under mail in control panel and try again.
Here's the batch. Please use at your own risk:
"
:: @echo offsetlocal
:: Delete directories
rd /s /q "%userprofile%\AppData\Local\Microsoft\IdentityCache"
rd /s /q "%userprofile%\AppData\Local\Packages\Microsoft.AccountsControl_cw5n1h2txyewy"
rd /s /q "%userprofile%\AppData\Local\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy"
rd /s /q "%userprofile%\AppData\Local\Microsoft\TokenBroker"
rd /s /q "%userprofile%\AppData\Local\Microsoft\OneAuth"
rd /s /q "%userprofile%\Appdata\Local\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy"
:: Search for and delete TokenBroker directories
FOR /D /R "%localappdata%\Packages" %%D IN (*\AC\TokenBroker) DO (
IF EXIST "%%D" (
echo Deleting: %%D
rd /s /q "%%D"
)
)
:: Delete registry keys
reg delete "HKCU\Software\Microsoft\Windows\CurrentVersion\AAD" /f
reg delete "HKCU\Software\Microsoft\WindowsNT\CurrentVersion\WorkPlaceJoin" /f
reg delete "HKCU\Software\Microsoft\Office\16.0\Common\Identity\Identities" /f
reg delete "HKCU\Software\Microsoft\IdentityCRL" /f
endlocal
echo Script completed.
pause
"
Note:-You'll need to disable the GPO "Prevent access to registry editing tools" for a bit if you want to prevent access denied when deleting those registry keys.
Other things I've found:
If you're including/excluding folders in your profiles after log off, make sure these two folders are included, or users will be asked to authenticate every fresh login.'AppData\Local\Microsoft\OneAuth'
'AppData\Local\Packages\Microsoft.AccountsControl_cw5n1h2txyewy'
That's it. Maybe that makes sense. I hope that helps someone. I saw someone post in this thread that their 1001 errors just went away. Maybe this wasn't the cause and MS fixed something on their side. Either way, WPJ should not be enabled in an Non-Persistant VDI env per Microsoft, so at the very least, we're no longer getting duplicate and stale devices in Entra and the auth process is as it should be.
Summary:
1001 errors seem to occur during the WPJ process. Does your env need Workplace Join? If not, turn it off with the reg key above, then fix your existing profiles by nuking all M365 auth locations, and reauthenticate.
This fix appears to be working for us.
For simplification I have narrowed down the specific changes that are required:
Add from admin account:
HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin: "BlockAADWorkplaceJoin"=dword:00000001"
Sign out of all Office apps on affected user account.
Open regedit on affected account and delete the following:
HKCU\Software\Microsoft\Windows\CurrentVersion\AAD
HKCU\Software\Microsoft\WindowsNT\CurrentVersion\WorkPlaceJoin
Delete the following folders from affected user's appdata:
%userprofile%\AppData\Local\Microsoft\TokenBroker"
%userprofile%\AppData\Local\Microsoft\OneAuth"
%userprofile%\AppData\Local\Microsoft\IdentityCache"
Open Word, sign in, account should sign in without issue.
After this all Office apps should now be signed in automatically or the sign in should work without issues.
Thank you both for your contributions our troubleshooting!
Update from my end...
I added the BlockAADWorkplaceJoin=1 reg key and it completely broke Office logins for me. I would click "Sign In" at the top of Word and it would just do nothing. When I tried in Outlook, I'd load my cached profile, and at the bottom, it would say "Needs password". I clicked it and it never prompts with a login screen. I removed to reg key and it's back to normal.
I'm curious, what version of Office are you guys using? I wonder if me not being on the latest (or simply a newer) version of Office is the reason mind broke completely. There's people using my servers right now but after a reboot tonight and blocking new connections, tomorrow I'll see if Office updates fix things.