"Something Went Wrong [1001]" error when launching M365 published apps on Win2019 CVAD 2203 VDA's

[Glenn Dowling1709151535]

I am aware of an issue with Microsoft where there are problems getting M365 apps -- mainly Outlook -- to launch (post listed below).  Microsoft has not posted any solution as of yet, and the workarounds listed in the link seem to reference Win10 devices... not servers.

 

https://support.microsoft.com/en-us/office/error-something-went-wrong-1001-signing-in-to-microsoft-365-desktop-applications-6f63238d-d83c-437c-a929-de72fe819793

 

I have enabled the Shellbridge registry value (HKLM\Software\Citrix\Citrix Virtual Desktop Agent) on the VDA's which seemed to help some of my users... but not all.  I had earlier enabled the various registry values in HKCU\Software\Microsoft\16.0\Common\Identity -- "DisableADALatopWAMOverride", "DisableAADWAM", and "DisableMSAWAM" -- because of known issues related to Okta pop-ups.  VDA's also get rebooted every weekend.

 

Has anyone found a solution - temporary or otherwise - to get around this?  Or is everyone simply waiting for a Microsoft fix?

[Jeff Riechers]

Lookup Shellbridge.

 

https://support.citrix.com/article/CTX267071/password-field-not-displayed-when-publishing-any-office-365-application-such-as-excel-or-word-on-server-2019-or-windows-10

[Glenn Dowling1709151535]

40 minutes ago, Jeff Riechers1709152667 said:

Lookup Shellbridge.

 

https://support.citrix.com/article/CTX267071/password-field-not-displayed-when-publishing-any-office-365-application-such-as-excel-or-word-on-server-2019-or-windows-10

 

I had enabled the Shellbridge registry value (HKLM\Software\Citrix\Citrix Virtual Desktop Agent) on the VDA's which seemed to help some of my users... but not all. 

[Dennis Parker]

Shellbridge does nothing for this in our environment. 

A co-worker wrote a login script that deletes the Experiments keys, recreates them and denies access to them as a workaround.
It requires SetACL.exe: https://helgeklein.com/setacl/

Attached a .txt file that contains the ACLs we use with SetACL.exe.
 

put in a .cmd file:
 

@ECHO OFF
reg delete HKCU\Software\Microsoft\Office\16.0\Common\Experiment /f
reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentConfigs /f
reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentEcs /f

reg add HKCU\Software\Microsoft\Office\16.0\Common\Experiment /ve /f
reg add HKCU\Software\Microsoft\Office\16.0\Common\ExperimentConfigs /ve /f
reg add HKCU\Software\Microsoft\Office\16.0\Common\ExperimentEcs /ve /f

"%~dp0\SetACL.exe" -on hkcu\Software\Microsoft\Office\16.0\Common\Experiment -ot reg -actn restore -bckp "%~dp0\ExperimentACL.txt" -silent

reg delete HKCU\Software\Microsoft\Office\16.0\Common\Experiment\excel /f
reg delete HKCU\Software\Microsoft\Office\16.0\Common\Experiment\outlook /f
reg delete HKCU\Software\Microsoft\Office\16.0\Common\Experiment\sdxhelper /f
reg delete HKCU\Software\Microsoft\Office\16.0\Common\Experiment\word /f

reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentConfigs\ApplicationUpgradeCandidate /f
reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentConfigs\Ecs /f
reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentConfigs\ExternalFeatureOverrides /f
reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentConfigs\FirstSession /f
reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentConfigs\FirstSessionUpgradeCandidate /f
reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentConfigs\SDXInfo /f

reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentEcs\all /f
reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentEcs\excel /f
reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentEcs\outlook /f
reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentEcs\Overrides /f
reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentEcs\sdxhelper /f
reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentEcs\unknown_app /f
reg delete HKCU\Software\Microsoft\Office\16.0\Common\ExperimentEcs\word /f

 

ExperimentACL.txt

[Dennis Parker]

We are now seeing crashing with SDXHelper since doing the fix above. We are looking at a workaround for that right now.

[Jeff Riechers]

Did you do the rest of the items in that post?  The updated VDA, and windows updates?

 

So is it not even launching?  Or hanging on the auth process.

 

Also what are you using for your profile management?  UPM or FSLogix?

[Dennis Parker]

3 minutes ago, Jeff Riechers1709152667 said:

Did you do the rest of the items in that post?  The updated VDA, and windows updates?

 

So is it not even launching?  Or hanging on the auth process.

 

Also what are you using for your profile management?  UPM or FSLogix?

Yes to all of the things. 

Outlook launches, but hangs on Authentication when the token expires. 
Can create a new Outlook profile to work around for a while, but that's certainly not sustainable.
We use Citrix UPM, but the PM tech is not the issue at all here. It's something with Microsoft. MS Engineers are working on the issue. We provided tons of logs to them. 

[Glenn Dowling1709151535]

2 minutes ago, Jeff Riechers1709152667 said:

Did you do the rest of the items in that post?  The updated VDA, and windows updates?

 

So is it not even launching?  Or hanging on the auth process.

 

Also what are you using for your profile management?  UPM or FSLogix?

 

Assuming this was meant for me.  ?

 

VDA is 2203 LTSR CU3, and it gets Windows Updates on a monthly basis.  It seemed to start right after Microsoft 365 was updated in mid-October.

 

The other registry values were added to the VDA's weeks ago.  I thought I had mentioned that in my initial post.

 

It launches, but when it gets redirected for authentication through our Okta portal, that's when the fun begins.  

 

Profile Management = UPM

[Jeff Riechers]

Does it happen only on published applications?  Or does it happen on Desktops as well.

 

Was asking both of you.  Trying to find an answer for you both.

[Dennis Parker]

3 minutes ago, Glenn Dowling1709151535 said:

 

Assuming this was meant for me.  ?

 

VDA is 2203 LTSR CU3, and it gets Windows Updates on a monthly basis.  It seemed to start right after Microsoft 365 was updated in mid-October.

 

The other registry values were added to the VDA's weeks ago.  I thought I had mentioned that in my initial post.

 

It launches, but when it gets redirected for authentication through our Okta portal, that's when the fun begins.  

 

Profile Management = UPM

Assumed it was meant for me. ?

It has been getting progressively worse for us. We are an MSP and it seems like it hit tenant by tenant, not specifically with any version of Office. 

[Dennis Parker]

Just now, Jeff Riechers1709152667 said:

Does it happen only on published applications?  Or does it happen on Desktops as well.

 

 

Can't answer that. We only use published applications. 

[Glenn Dowling1709151535]

2 minutes ago, Jeff Riechers1709152667 said:

Does it happen only on published applications?  Or does it happen on Desktops as well.

 

 

 

I mainly do published applications.  I do have one published desktop that has M365 installed, and I have only gotten 1 or 2 complaints there.  On the published apps, however, I have had ~50 users with the complaint.

[Jeff Riechers]

Try it out in Desktops if you can.  That will load different parts of the authentication process and will allow it to be narrowed down to Citrix's engine, or Office's engine.

 

Do you see any info in the Okta logs when this problem shows up?

[Glenn Dowling1709151535]

Before M$ released their article, I had contacted Citrix Support.  They managed to rule out Citrix as the cause by having me set up "RDP Initial App" and have it configured to launch Outlook.  Since it reoccurred there, they had washed their hands of the issue.  ? 

[Dennis Parker]

7 minutes ago, Jeff Riechers1709152667 said:

Try it out in Desktops if you can.  That will load different parts of the authentication process and will allow it to be narrowed down to Citrix's engine, or Office's engine.

 

Do you see any info in the Okta logs when this problem shows up?

There are other forums that I monitor that have complained about it in RDP sessions as well, so I'm fairly confident that it is an Office on TS issue. Been working on this for probably 6 months or more. 

I also doubt Microsoft would release anything like the article if they thought there was even a chance it was just a Citrix thing. ?

Edited November 2, 2023 by Dennis Parker
additonal commentary

[François BIAUCE]

Hello Glenn,

 

We had the same issue with VDA 2203 LTSR CU3 + W2019.

 

We tested different situations with the ShellBridge key and the 3 Windows Access Manager keys ("DisableADALatopWAMOverride", "DisableAADWAM", "DisableMSAWAM") :

 

Shellbridge 0
3 keys WAM 1
= KO , error 1001

 
 Shellbridge 1
3 keys WAM 1

= OK but we need to authenticate at each disconnection/reconnection and the user session does not close on the VDA when you close the application
 

Shellbridge 1
3 keys WAM 0

=OK but the user session does not close on the VDA but the password is not requested again. Best solution at the moment for us.
 

Shellbridge 0
3 keys WAM 0

=OK/KO We have the O365 licence failed activation
 

 

The 3rd configuration seams the best for us. After disconnect/reconnect several times. We don't have the issue anymore.

The problem about the user session not disconnected on the VDA is an other problem.

 

Regards,

 

François BIAUCE

[Pascal Springer]

Hello Every one.

we have still this issue, basicall in published Apps.
We are running Windows Server 2022, Citrix LTSR 2203 CU4, Citrix UPM with WEM. No vhdx profiles.

In the past - without this issue - we had all mentioned reg keys ("DisableADALatopWAMOverride", "DisableAADWAM", "DisableMSAWAM") keys activated and also this one:

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\16.0\Common\Identity\EnableADAL - DWORD 1
After the issue starts we tried it with deleting all mentioned keys , this did not help.
 

We tried it also with only this one:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Exchange\AlwaysUseMSOAuthForAutoDiscover - DWORD 1

Additoneld we did everything mentioned here:

https://support.microsoft.com/en-us/office/error-something-went-wrong-1001-signing-in-to-microsoft-365-desktop-applications-6f63238d-d83c-437c-a929-de72fe819793

Now we are testing Francois "Solution with only the mentioned Keys DWORD 0 and also
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Exchange\AlwaysUseMSOAuthForAutoDiscover - DWORD 1

But I think this will no help.

Does some have a real solutuion? It would be really nice to know :)

Regards

[Jeff Riechers]

Do you have these machines using hybrid azure join?  If they retrieve a PRT correctly it will help with the authentication.

However, if you aren't doing hybrid join you would need FSLogix to use legacy token preservation.  So make sure you have your admx for fslogix updated to the latest to give you that legacy token option.

[Pascal Springer]

Hi Jeff, sorry for the late response.

No we don't have hybrid join. VDAs using the onprem AD.

We also not using profile disks like fslogix. We are still on Citrix UPM only.

We are planing to move to profile disk with our new storage.. 

[Pascal Springer]

Sorry forgot to ask: So wich legacy token do you mean? 

[Jeff Riechers]

FSLogix's updated ADMX files have an option to store the Office legacy token in the profile.  If you don't have the hybrid joined and prt that legacy token will store their settings.

 

[Pascal Springer]

okay, so we are talking about the token in %localappdata%\Microsoft\Office\16.0\Licensing. 
For this we have only the machinie GPO active: "Use shared computer activation" 

The tokens from the user are stored in the profile in the mentioned path. They tokens are copied back to the network store at logoff. With the next login they have there token back.

This way it worked without any issues till 10.2023. With the Office patches from October 2023 it startet with some users seeing error 1001. Mostly always in published apps.