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?

[Jason Ochs1709152296]

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.

[Tor Audun Fiskvatn]

We opened a case on this with Citrix Cloud support.

 

We had an engineer look at our solution. Citrix acknowledged the problem but could not fix it. The good thing is that they reported it in their channels to the Microsoft RDS team and promised us an update on the case. 

 

In their last comment they gave us a workaround witch looks a lot like the ones prior in this post, but I will give it a try later today.

Quote

Yes, the issue is on Windows side at the moment. Windows engineers are aware and working together with Citrix Engineers on this issue.
Apparently it is not easy fix and will take some time. So I don’t have time frame of the fix neither it is in my or Citrix hands anymore.

There is a workaround. However it is not supported by Windows so it is up to you if you want to try and test it.

Workaround:

1.    Remove the user profile from the VDA

2.    Office has dependencies on the explorer shell and fails even in RDP if the shell is modified.

a.    First step is to setup the AlternateShellStartup policy

                                      i.        In the server Group Policy Management Console, navigate to Local Computer Policy > User Configuration > Windows Settings.

                                     ii.        Click Scripts (Logon/Logoff), and then double-click Logon.

                                    iii.        Click Add.

                                    iv.        In the Script name box, type runonce.exe.

                                     v.        In the Script parameters box, type /AlternateShellStartup.

                                    vi.        Click OK two times.

3.    Web Account Manager seems to be causing the issue with the password box not popping up if only AlternateShellStartup is setup.

a.    Setup a registry Windows Setting -> Create HKEY_CURRENT_USER\ Software\Microsoft\Office\16.0\Common\Identity

                                      i.        REG_DWORD -> DisableADALatopWAMOverride

                                     ii.        Set value to 1

4.    Reboot the VDA

5.    Test office activation.

 

[James Kindon]

The bigger challenge before you go too far is that Microsoft doesn't support Office 365 Pro Plus on Server 2019 https://www.christiaanbrinkhoff.com/2019/04/27/the-little-unknown-secrets-of-using-office-365-proplus-and-office-2019-on-a-virtual-desktop-environment-survival-guide/

[James Kindon]

Backflip!

 

https://www.microsoft.com/en-us/microsoft-365/blog/2019/07/01/improving-office-app-experience-virtual-environments/ 

[Stevie]

Indeed. I forgot to mention that I also tried the EnableAdal registry key but to no avail.

 

So in my opinion , brief summary for the moment : though ofice 365 pro plus is supported on win 2019 rds and also works when using rds, is unusable with Citrix Xenapp. This is really a blocking factor. 

 

I'm out of ideas :-) 

[Ron Jameson]

I had opened a ticket with Citrix support shortly after this and in my lab setup, that was all current - I was able to get it working in my lab setup as my firewall was blocking some of the traffic outbound that was interfering with the modern authentication password screen.   All excited - I then tried this on a production setup which was not current (Xenapp 7.18) but added a 2019 server and O365...this failed with the same issue and in this case - did not see any firewall issues. 

 

Next plan was to get my production setup all the same as my lab setup which was CVAD 1906.2 and cross my fingers.   I did this 2 weeks ago...this still failed....same exact thing where in seamless it fails to show the password screen and yet if I RDP to the server or run a server desktop - it works fine.   My ticket is still open but now down to stripping down to retest as a new user, examine my GPO's, CTX policies to see what is happening.    I know this is all a seamless issue and O365 modern authentication - but my farm has made tweaks over the years on seamless settings so I want to see if I can find what would affect this.   Citrix support was not finding anything...yet I see this happening to others so I am not alone here.  

 

Hoping to get thru this testing in the next few days hoping to have some success.   I really want this to work so we can roll out O365 vs. 2019 OVL.

[Benjamin Toelle]

Nope

 

RDP: Passed

Citrix Published Desktop: Passed

Citrix Seamless Application: Failed

RDP Initial App: Failed

 

Citrix and Microsoft App technologies failing... 

[Stevie]

If any employee of Citrix is reading this... It's very easy to point to Microsoft, and it could well be that it's Microsofts responsability to fix thix.. but nevertheless it's also Citrix responsability to ask Microsoft for a quick fix.  It's all to easy to let customers out in the cold.

[Jerome Martinez]

For those that don't want to create a domain wide GPO to add the registry settings, you can also create a LOCAL Group Policy with a CMD file that adds the registry setting above.  Here is how:

• Log into the server you want to apply the policy to.  Open Notepad and add the following line: 
  •  reg add "HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity" /v DisableADALatopWAMOverride /t REG_DWORD /d 1 /f
• Save it in: C:\Windows\System32\GroupPolicy\User\Scripts\Logon. Save it as a CMD file.  ie:  "CitrixOutlookFix.cmd"
• Search for gpedit.msc hit enter.  This will open the Local Group Policy Editor
• In the Local Group Policy Editor go to:  USER CONFIGURATION-->WINDOWS SETTINGS-->SCRIPTS(LOGON/LOGOFF)-->and double click on LOGON
• Click on ADD and Browse to the "CitrixOutlookFix.cmd" file that you just created. 

This will take care of the registry setting.  You will also need to add the "runonce.exe" with the /AlternateShellStatup parameter in the same diaglog box.

[Stevie]

Sorry but this is bulll.... Office365 Pro proplus is supported on Windows 2019

 

see ->

 

https://redmondmag.com/articles/2019/07/09/office-365-proplus-windows-server-2019.aspx

 

https://cloudblogs.microsoft.com/windowsserver/2019/10/07/windows-server-2019-adds-support-for-office-365-proplus/

 

an it works on Windows 2019 RDS and Citrix Xenapp. I have it running in production env.

 

 

see my post of feb 7

 

"

So all that is needed are indeed 

 

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 also applied them via GPP 

 

tested on

 

windows 2019 1809 build 17763.1012 & windows 2019 1809 build 17763.973

VDA 1912

Office 365 C2R version 2001 build 12430.20184

 

Thanks a lot @mdalgri417 !!!

"

 

 

[Andy Vanderbeken]

I'm about to start a new master image with Windows 2019 server and Xenapp 1906 + Office 365 Pro plus click to run version. I'll be able to test that then and give an answer on my findings. I'll keep your post in mind until then.

[Andy Vanderbeken]

14 hours ago, James Kindon said:

The bigger challenge before you go too far is that Microsoft doesn't support Office 365 Pro Plus on Server 2019 https://www.christiaanbrinkhoff.com/2019/04/27/the-little-unknown-secrets-of-using-office-365-proplus-and-office-2019-on-a-virtual-desktop-environment-survival-guide/

 

thx for that very nice info. I'm not going down Office 365 Pro Plus route after all but rather Office 2019 on windows server 2019. Better not risk future trouble imho.

[Ron Jameson]

Been waiting for FSLogix to happen.  Not sure if that will fix my ghost frame issue - but may have to try it.   My testing has stalled until I get get my dev farm on the latest vs. just the VDA being current - and need to test the hated alternateshellstartup option in case that ghost window is using IE code to enter a password (MS will need to be punished if they keep using IE code in popups).

[Stevie]

Office 365 should now be supported on Windows 2019.

 

I am experiencing the same problems as hamlintech175  describes.

 

Installed Office 365 with shared activation on Windows 2019.

 

Office Version = latest version 1906 (build 11727.20244 C2R)

Xenapp VDA = Xenapp 7_1906

 

In Citrix full desktop everything works fine, in seamless mode the login page is simply not showing up.

When I use RDP it works also, so it clearly has something to do with seamless mode in combination with Win 2019 and the latest versions of Office 365

 

When I install an older version office 365 (for instance version 16.0.6965.2117)  than everything works fine.

 

Please Citrix... look in to this...

[Steve Ramwell]

Exactly the same issue here attempting to build the same setup.

 

Windows 2019 (1809).

VDA 1906 (tried 1903 and 1811 too).

Office 365 1907 (11901) with shared computer activation.

 

Launch an Office app from XenApp, get prompted to sign in then the blank white box where the password prompt should be. RDP to the VDA then SSO works and Office 365 is activated automatically, no sign in required. Then launch an Office app with the same user on the same VDA via XenApp it retains the activation in the local profile.

 

For comparison I built a Server 2016 VM with the same VDA and Office versions, same OU/GPOs and the same test user account. When launched via XenApp, Office 365 is automatically activated by SSO as it ought to be.

 

So looks like something in Server 2019 is breaking whatever Citrix does for web redirection, causing SSO to break. Suspicion that it's something to do with that new Windows Defender Exploit Protection crap, but I've disabled everything I can to no avail.

 

Interesting to hear that older versions of Office 365 work too. I'll try and nail down the last working version as that might be an acceptable workaround until Citrix/MS get this fixed between them.

[Stevie]

ok thx.. keep us posted.

 

 

Btw FSLogix does not   fix  ghost frame issue, because I'm converting from RUP to FSLOGIX and have already tested this. @Ron Jameson

 

[Steve Ramwell]

OK so not exactly success, but progress with different O365 versions:

 

16.0.9126.2428 (1803) does not work; same symptoms as current and all in between versions I've tested.

16.0.8431.2372 (1708) doesn't work but behaves differently; prompts for sign-in, enter email then instead of password box you get an additional seamless Word window with no content pop up in the background that prevents you clicking anything else in Word.

16.0.8201.2278 (1705) works 100%; SSO on first app launch, no sign-in required. Unfortunately this version went out of support a year ago, so is not really a viable workaround even in the short term.

 

So what happened between those Office 365 builds? One likely answer is Modern Authentication, and indeed if you disable this with the following reg value it changes the sign-in dialog to a legacy one that does work with XenApp on Windows 2019 as attached:

 

HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\Identity:"EnableADAL"=dword:00000000

 

This still doesn't fix SSO so users still have to go through the sign-in process on initial profile creation so I wouldn't consider it an acceptable solution for production, but it's pointing in the right direction.

[Stevie]

No news on this issue yet ?

[Sam Cappelle]

Same issue here with seamless Virtual Apps and Desktops 1906.2 and Office 365 1908 on Server 2019. When can we expect to see solution for this?

[Benjamin Toelle]

Same issue here....

[Benjamin Toelle]

Citrix support asked us to launch the app via RDP Initial App to exclude Citrix components.

 

Same Issue with RDP Initial App.
https://support.citrix.com/article/CTX218256

 

Now we are also trying to find a solution with Microsoft Premier Support...

[Ron Jameson]

We tried that also, but something was not working even with that and they struggled in that test.     If I RDP into the server it works as it should - not sure how initial app differs from that other than explorer.exe runs in a full desktop.   If this is one of those cases where you need explorer.exe running, that does indeed pin it to seamless not working but also points a finger at MS for that password screen needing something in a full desktop.    Oddly, my lab setup works fine in seamless - so this is not a consistent issue for everyone that makes this more annoying.

[Benjamin Toelle]

Another note:

 

We found one single test user who does not have the issue with an existing profile or new profile. Strange...

 

Any ideas to compare the users?

[Ron Jameson]

I too just tried this again...https://support.citrix.com/article/CTX218256 following method 2, and this fails.   If this means the fault lies with Microsoft, 100% - I guess that means we have to turn to them.

[Stevie]

Not really sure that its 100% with microsoft.

 

In an rdp full desktop session (microsoft technology only) it works.

 

In a citrix full desktop: it works.

 

In a citrix seamless session, it does not work. I suppose that the citrix seamless software simply does not detect the login screen, and does not show it to the user , but the loginscreen is there in the background.

 

Edited September 16, 2019 by vilvovbj53
Forget something.