Office 365 Pro Plus shared activation password screen not able to select

[Ron Jameson]

I am starting a set of Windows 2019 servers, XenApp 1903, Office 365 Pro Plus w/shared activation - thinking MS & Citrix had gotten this figured out by now...but alas, running into an issue in seamless mode where you sign in to O365 when it asks, but the next pwd popup screen is a ghost window I cannot pick.    This works fine in full desktop, just not seamless.    I am pretty sure MS still allows us to purchase a single Vol license of 2019 when we are fully licensed for O365 for each user and that has been the plan to get away from this problem - but I really wanted this to work as also heard MS moved the token to 30 days now which makes this doable.   Besides, 2019 being the last Vol license version to be released, we will eventually have no choice.

 

Has anyone been successful in getting this setup to work properly?

[Mathé de Wit]

I just did a test this morning with an RDS 2019 server and published Excel and dsregcmd /status as a RemoteApp.

It just works!

 

The difference between desktop, published app and remoteapp for me is WamDefaultSet, on the desktop and remoteapp it is YES, but with a published app it is set to NO.

 

I just created a call with Citrix, hopefully they have something.

[Stefanos Evangelou1709159370]

I have a new 1912 LTSR VAD environment with Windows Server 2019 VDAs and Microsoft 365 Apps latest version. The issue with suppressed password window is still here. I have tried all resolution steps proposed in this article but issue persists. Reverting to 2016 VDA is not an option. I am strongly considering using FsLogix Office365 containers which manage this behavior properly.

 

I wonder what is Citrix official recommendation to resolve this known issue? It seems that Citrix Profile Management cannot be used in such an implementation if none of the workarounds are successful.

[Brett Hill]

On 8/25/2020 at 8:30 AM, Stefanos Evangelou1709159370 said:

I have a new 1912 LTSR VAD environment with Windows Server 2019 VDAs and Microsoft 365 Apps latest version. The issue with suppressed password window is still here. I have tried all resolution steps proposed in this article but issue persists. Reverting to 2016 VDA is not an option. I am strongly considering using FsLogix Office365 containers which manage this behavior properly.

 

I wonder what is Citrix official recommendation to resolve this known issue? It seems that Citrix Profile Management cannot be used in such an implementation if none of the workarounds are successful.

 

Let me just first say thanks to all the bleeding edgers out there!  This did cause me grief, but I'm sure no where near what you all have had.

 

I'm in the process of setting up a new CVAD environment (CVAD 1912 LTSR CU1).  I've got Windows Server 2019 Version 1809 (OS Build 17763.1397) along with the latest Semi-Annual version of O365 Pro Plus (or whatever they're calling it now) version 16.0.12527.21104.  O365 is setup to run in Shared Computer Activation mode.  I'm only using UPM 1912 for profile management.

 

My problem was that, because of this same problem everyone's having, I couldn't launch any O365 app as an application by itself and be able to activate it anytime, more specifically Outlook.  It would always say that the mailbox was in use.  I don't have any extra plugins installed for Office, so I'm not sure if that's really a thing or not.  However, I could launch the desktop app and run the O365 apps, activating them (even Outlook), etc... no problem.

 

I finally happened across this thread after about 10 hours of trying to figure out why it wasn't working.  The registry keys mentioned in previous posts seemed to do the trick!

 

reg add "HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity" /v DisableADALatopWAMOverride /t REG_DWORD /d 1 /f

reg add "HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity" /v DisableAADWAM /t REG_DWORD /d 1 /f

 

I set them up in the User registry GPP and, now, with a brand new profile, I am able to login to Outlook and activate it and have it work correctly subsequently.  Excel and Word also work normally.  What  a relief!  I hope this is fixed soon!

[Glenn Deltour1709154181]

On 9/17/2020 at 1:47 PM, Brett Hill said:

 

I finally happened across this thread after about 10 hours of trying to figure out why it wasn't working.  The registry keys mentioned in previous posts seemed to do the trick!

 

reg add "HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity" /v DisableADALatopWAMOverride /t REG_DWORD /d 1 /f

reg add "HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity" /v DisableAADWAM /t REG_DWORD /d 1 /f

 

I set them up in the User registry GPP and, now, with a brand new profile, I am able to login to Outlook and activate it and have it work correctly subsequently.  Excel and Word also work normally.  What  a relief!  I hope this is fixed soon!

 

Above registry keys also did the trick for me. But only with a brand new (fslogix) profile. Setting the registry keys in an existing profile didn't work for me.

 

(running on server 2019, citrix VDA LTSR 1912.0.0.24265, latest o365 click to run, seamless published applications)

 

Thanks to everyone in this thread (AND my colleague pointing me to this topic) :-)

[Thorsten Ellmers1709153287]

On 8/20/2020 at 2:47 AM, Jonathan Burns said:

In order to solve the O365 activation issue on the new 2019 Citrix servers I had to publish the following plug in Citrix for the 2019 delivery groups:  (And I made the app only visible to domain admins)

 

“C:\windows\systemapps\Microsoft.AAD.Brokerplugin_cw5n1htxyewy\Microsoft.AAD.Brokerplugin.exe”

 

When the second screen comes up this is the plug in that it calls.  (Apparently you have to publish it in Citrix in order for this plug in to work through Citrix).  

 

 

 

Hi Jonathan,

just to clarify, not really understand your sugguestion.

i did published an application as follows, but if i try to activate any Office Product, passwort promt does not showing up.

 

thx for a short answer in this cause

Greetings

Thorsten

[Peter Mommerency]

Digging up an old thread.
I just fixed this issue at a client simply by installing an older version of Office. 

Had the exact same issue since Tuesday, while it had been working fine for over a year. 
Found that on Tuesday morning, Office was automatically updated (Monthly channel > version 16.0.13628.20030)
Uninstall of entire Office suite, install again from SemiAnnual channel (version 16.0.12527.21416): immediately resolved...

 

Anyone else experience this? 

 

 

Edited January 8, 2021 by PMYPMY
added office versions

[Sebastien MARGUERITE]

Hello,

I have the same issue.

OS : Win2019

VDA version : 1912 CU3

Office version : proplus 2019 (seamless mode)

 

If I don't change anything, in Outlook the prompt for password never appears (white window).

If I create the registry key DisableADALatopWAMOverride the prompt appears and I can configure my mailbox.

But then, each time I open Outlook it will ask me my password.

So, I delete the registry key DisableADALatopWAMOverride, and then it's ok, Outlook opens without asking me my password.

 

I tried multiple things but nothing works, do you have an idea ?

 

in desktop mode, the registry key DisableADALatopWAMOverride it's not needed, the prompt for configuring mailbox password appears.

 

Regards,

[mmora302]

On 8/16/2021 at 1:52 PM, Jason Ochs1709152296 said:

I just spent a few weeks on this issue. I know this is an old thread, but I'll post what I found here to hopefully help people. First off, Microsoft does not recommend disabling ADAL or WAM to fix this issue. REF: https://docs.microsoft.com/en-us/office365/troubleshoot/administration/disabling-adal-wam-not-recommended. For those of you posting that as a solution, it's incorrect!

 

The bottom of the above article is a link to https://docs.microsoft.com/en-us/azure/active-directory/devices/troubleshoot-device-dsregcmd. I ran this dsregcmd on my older 2012R2 / 2016 boxes and pretty much everything was "NO." However, on my 2019 box AzureADJoined=YES and like the sample output I had tenant details populated with details. What was different was the user state. My user had NO for NGCSET, WORKPLACEJOINED, & WAMDEFAULTSET.  So, I focused on the User details and ran some tests with Outlook. After each test, I deleted my profile. In order to see these details, I published Command Prompt' to my O365 user. From there I launched the dsregcmd as well as launched Outlook.

1. Run published application. DSREGCMD showed No for user details. I ran Outlook and I saw the legacy Outlook sign in which didn't work. 
2. I RDP'ed to the box as the same user. DSREGCMD showed No for user details. I ran Outlook. Outlook built the profile successfully and I saw my e-mail. I reran the DSREGCMD and this time DSREGCMD showed WAMDEFAULTSET=YES. Same session. The only change was running Outlook! 
3. Back to the article about disabling adal/wam not recommended, I started looking at the troubleshooting steps. Recommendation #6 talks links here which talks about reinstalling an Azure AD WAM plugin. MS was kind enough to include the PowerShell command to look for the package and install it if necessary.  So I deleted my profile once more and tested my Command Prompt published application. 
   1. Start Command Prompt
   2. Run DSREGCMD. Noted user details all were NO.
   3. Entered PowerShell
   4. Entered the PowerShell command: if (-not (Get-AppxPackage Microsoft.AAD.BrokerPlugin)) { Add-AppxPackage -Register "$env:windir\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Appxmanifest.xml" -DisableDevelopmentMode -ForceApplicationShutdown } Get-AppxPackage Microsoft.AAD.BrokerPlugin
   5. Ran DSREGCMD again. This time WAMDEFAULTSET=YES. 
   6. Started Outlook. It built my Outlook profile successfully and then I had my e-mail. 

SOLUTION:

Execute the PowerShell command provided by Microsoft to check and install the AD WAM Plugin for each user. This plugin is stored in the user's profile. I created a logon script to run the command and linked to a GPO applied to my 2019 servers. Office activates automatically (unlike my 2012 servers which will popup a signon screen if profile is deleted.) Even Edge started logged in without any authentication. So, don't disable ADAL/WAM. You're just postponing the problem. Eventually you'll need to upgrade your Office build and you'll have to fix this.

Unfortunately this did not work for me on my 2019 servers Logging into Citrix and running the published app CMD, Running  powershell command above and running DSREGCMD /status still gets me WAMDEFAULTSET=NO.  Anyone else get this to work?

[mfprybell]

On 9/3/2021 at 3:42 PM, mmora302 said:

Unfortunately this did not work for me on my 2019 servers Logging into Citrix and running the published app CMD, Running  powershell command above and running DSREGCMD /status still gets me WAMDEFAULTSET=NO.  Anyone else get this to work?

 

This didn't work in my environment either.

 

EDIT:

Actually this did seem to work. I had mistakenly set the test  GP for script and not powershell script. 

Edited September 27, 2021 by mfprybell

[George Davidsen1709163167]

On 6/26/2019 at 10:16 AM, Ron Jameson said:

I am starting a set of Windows 2019 servers, XenApp 1903, Office 365 Pro Plus w/shared activation - thinking MS & Citrix had gotten this figured out by now...but alas, running into an issue in seamless mode where you sign in to O365 when it asks, but the next pwd popup screen is a ghost window I cannot pick.    This works fine in full desktop, just not seamless.    I am pretty sure MS still allows us to purchase a single Vol license of 2019 when we are fully licensed for O365 for each user and that has been the plan to get away from this problem - but I really wanted this to work as also heard MS moved the token to 30 days now which makes this doable.   Besides, 2019 being the last Vol license version to be released, we will eventually have no choice.

 

Has anyone been successful in getting this setup to work properly?

Did you ever get resolution?  It's now Jan 2022 and I'm having the issue on Svr 2019..

[Timo Hamalainen1709153432]

On 8/16/2021 at 9:52 PM, Jason Ochs1709152296 said:

I just spent a few weeks on this issue. I know this is an old thread, but I'll post what I found here to hopefully help people. First off, Microsoft does not recommend disabling ADAL or WAM to fix this issue. REF: https://docs.microsoft.com/en-us/office365/troubleshoot/administration/disabling-adal-wam-not-recommended. For those of you posting that as a solution, it's incorrect!

 

The bottom of the above article is a link to https://docs.microsoft.com/en-us/azure/active-directory/devices/troubleshoot-device-dsregcmd. I ran this dsregcmd on my older 2012R2 / 2016 boxes and pretty much everything was "NO." However, on my 2019 box AzureADJoined=YES and like the sample output I had tenant details populated with details. What was different was the user state. My user had NO for NGCSET, WORKPLACEJOINED, & WAMDEFAULTSET.  So, I focused on the User details and ran some tests with Outlook. After each test, I deleted my profile. In order to see these details, I published Command Prompt' to my O365 user. From there I launched the dsregcmd as well as launched Outlook.

1. Run published application. DSREGCMD showed No for user details. I ran Outlook and I saw the legacy Outlook sign in which didn't work. 
2. I RDP'ed to the box as the same user. DSREGCMD showed No for user details. I ran Outlook. Outlook built the profile successfully and I saw my e-mail. I reran the DSREGCMD and this time DSREGCMD showed WAMDEFAULTSET=YES. Same session. The only change was running Outlook! 
3. Back to the article about disabling adal/wam not recommended, I started looking at the troubleshooting steps. Recommendation #6 talks links here which talks about reinstalling an Azure AD WAM plugin. MS was kind enough to include the PowerShell command to look for the package and install it if necessary.  So I deleted my profile once more and tested my Command Prompt published application. 
   1. Start Command Prompt
   2. Run DSREGCMD. Noted user details all were NO.
   3. Entered PowerShell
   4. Entered the PowerShell command: if (-not (Get-AppxPackage Microsoft.AAD.BrokerPlugin)) { Add-AppxPackage -Register "$env:windir\SystemApps\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\Appxmanifest.xml" -DisableDevelopmentMode -ForceApplicationShutdown } Get-AppxPackage Microsoft.AAD.BrokerPlugin
   5. Ran DSREGCMD again. This time WAMDEFAULTSET=YES. 
   6. Started Outlook. It built my Outlook profile successfully and then I had my e-mail. 

SOLUTION:

Execute the PowerShell command provided by Microsoft to check and install the AD WAM Plugin for each user. This plugin is stored in the user's profile. I created a logon script to run the command and linked to a GPO applied to my 2019 servers. Office activates automatically (unlike my 2012 servers which will popup a signon screen if profile is deleted.) Even Edge started logged in without any authentication. So, don't disable ADAL/WAM. You're just postponing the problem. Eventually you'll need to upgrade your Office build and you'll have to fix this.

Thanks Jason! This workaround saved my day because we have some users who needs Microsoft Edge on Win2019 for one banking app so they had to use published desktop this far. Now they are much happier with published Edge. ?