[Block Office Activation.pkg
Iberio Ralda
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.
A: To launch an Amazon WorkSpace from a custom image, you will first need to pair the custom image with a hardware type you want that WorkSpace to use, which results in a bundle. You can then publish this bundle through the console, then select the bundle when launching new WorkSpaces.
A: As an administrator, you can create as many custom images as you need. Amazon WorkSpaces sets default limits, but you can request an increase in these limits here. To see the default limits for Amazon WorkSpaces, please visit our documentation.
A: As soon as you initiate a copy operation, you will be provided a unique identifier for the new Image being created as a copy of the original one. You can use that identifier to look up the status of that Image in the destination Region through the WorkSpaces console, APIs, or CLI.
A: No. There are no additional fees for copying Images across Regions. Maximum Image limits for your account in destination AWS Region will still apply. Once you reach this limit you will not be able to copy more Images.
A: All Amazon WorkSpaces launched after January 31, 2017, are built on general purpose solid-state drives (SSD) EBS volumes for both root and user volumes. Amazon WorkSpaces launched prior to January 31, 2017, are configured with EBS magnetic volumes. You can switch your Amazon WorkSpaces using magnetic EBS volumes to SSD EBS volumes by rebuilding them (more information can be found here). You can learn more about SSD EBS volumes here, and magnetic EBS volumes here.
A: You have flexibility in how you deploy the right set of applications to users. First, you choose which image type to build from, either basic or Plus, which determines the default applications that will be in the WorkSpaces. Second, you can install additional software on a WorkSpace and create a custom image which can be used to launch more WorkSpaces. For more detail see the bundle documentation.
For Windows, any applications that are compatible with the Windows 10 experience provided by Windows Server 2016 or Windows Server 2019 should run on your WorkSpaces. We recommend testing any software you would like to deploy on a "test" WorkSpace before delivering it to more users. You are responsible for ensuring that you remain compliant with any licensing restrictions associated with any software you intend to install on a WorkSpace.
A: Yes. You can increase the size of the root and user volumes attached to your WorkSpaces at any time. When you launch new WorkSpaces, you can select bundled storage configurations for root and user volumes, or choose your preferred storage size greater than the provided storage configurations. For storage configurations with 80 GB Root volume, you can choose 10 GB, 50 GB, or 100 GB for User volume. You can use storage configurations with 175 GB to 2000 GB Root volume along with 100 GB to 2000 GB User volume. Please note that you need to set the Root volume to 175 GB in order to expand the User volume in the range of 100 GB to 1000 GB. After your WorkSpaces have been launched, you can only increase the size of the volumes using the above configurations to up to 2000 GB for each Root and User volume.