Refx Nexus 2.2.1 AIR ELicenser 2.2.1
Vladimir Stringfield
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.
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: -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 -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.
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.
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.
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 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.
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.
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.
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).
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.
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.
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:
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.
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.
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.
Shared computer activation is required for scenarios where multiple users share the same computer and the users are logging in with their own account. Normally, users can install and activate Microsoft 365 Apps only on a limited number of devices, such as 5 PCs. Using Microsoft 365 Apps with shared computer activation enabled doesn't count against that limit. If your users have their own computers and no one else uses those computers, use product key activation for Microsoft 365 Apps.
To activate Microsoft 365 Apps, TLS 1.2 must be enabled by default on the operating system. Some older operating systems, such as Windows 7 Service Pack 1 (SP1) and Windows Server 2012, need an update applied to enable TLS 1.2 by default. For more information, see Update to enable TLS 1.1 and TLS 1.2 as default secure protocols in WinHTTP in Windows. But, running Microsoft 365 Apps on these older operating systems isn't supported. For more information, see End of support resources for Office.
To use shared computer activation, you need an Office 365 (or Microsoft 365) plan that includes Microsoft 365 Apps and also supports shared computer activation. Shared computer activation is available for the following plans:
When you're using the Office Customization Tool at config.office.com or the wizard built into Microsoft Configuration Manager, make sure that you enable the option Shared Computer in the Product activation section.
If Microsoft 365 Apps is already installed and you want to enable shared computer activation, there are three options to choose from. A reinstallation isn't required. The device must be rebooted in order to apply the change.
Use Group Policy by downloading the most current Administrative Template files (ADMX/ADML) for Office and enable the "Use shared computer activation" policy. This policy is found under Computer Configuration\Policies\Administrative Templates\Microsoft Office 2016 (Machine)\Licensing Settings.
The Support and Recovery Assistant fully automates all of the steps to verify requirements for shared computer activation and to enable shared computer activation. It's available in two versions: enterprise and UI. Use the version that's best suited for your situation.
The Enterprise version of the Microsoft Support and Recovery Assistant is a command-line version. This version supports scripting for managing multiple devices, including those devices not immediately accessible. Download the Enterprise version.
To determine whether the user is licensed to use Microsoft 365 Apps, the Office Licensing Service has to know the user's account for Office 365. In some cases, Microsoft 365 Apps prompts the user to provide the information. For example, the user might see the Activate Office dialog box.
If your environment synchronizes Office 365 (Microsoft Entra ID) and local Active Directory (AD) accounts, users are unlikely to encounter any prompts. Microsoft 365 Apps can automatically retrieve the necessary information about the user's account in Office 365.
b1e95dc632