Microsoft Teams on Citrix XenApp

Teams is Microsoft’s new Skype and Slack-killer. But how well does it go on Citrix?

Introduction

Note – this article is now redundant. For updated information on Teams deployment on Citrix or other VDI/RDSH platforms, please see this series of articles.

Oh come sweet asteroid of death. Yes, that’s exactly how I feel after digging through the mess that is the guts of Microsoft Teams.

Teams is new. Teams is everywhere. Teams is going to put a bullet in the head of Skype for Business, eat Slack’s lunch, and be the face that launched a thousand Microsoft 365 subscriptions. But for those of us who manage XenApp and XenDesktop in non-persistent environments, Teams is a hideous glimpse of an application that Microsoft is so determined to dump onto every user that it possibly can, that it simply bypasses all the norms we’ve become used to, in the same way that Chrome and DropBox both can.

Installation of Teams

Firstly, when you download the Teams MSI (or, to give it the proper name, the “Teams Machine-Wide Installer”), you don’t actually install Teams when you run it. When you run this, it creates a folder in C:\Program Files (x86) called Teams Installer, and in there you will find two files only

This executable is auto-triggered at every user logon by an entry in the HKLM\Software\Wow643Node\Microsoft\Windows\CurrentVersion\Run area of the Registry which is also dropped by the Machine-Wide Installer

So when any user logs on to the machine, the executable from the c:\Program Files (x86)\Teams Installer folder runs, which triggers some more actions, namely:-

It spits out the Teams install into the user’s local profile, rather than anywhere in system areas

A desktop shortcut is written to the user’s profile (%USERPROFILE%\Desktop), with the target pointing to %LOCALAPPDATA%\Microsoft\Teams\Update.exe –processStart “Teams.exe”

A Start Menu shortcut is written to the user’s profile (%USERPROFILE%\Microsoft\Windows\Start Menu\Programs\Microsoft Corporation) which also points to %LOCALAPPDATA%\Microsoft\Teams\Update.exe –processStart “Teams.exe” as the target

It also drops an auto-start entry into the Registry, at HKCU\Software\Microsoft\Windows\CurrentVersion\Run, which points to the same executable as above with some slightly different parameters

The install (which is around 400MB to start with, and rapidly increases) will now follow the user because it is installed fully into the user profile. So if I log on to another XenApp server – even one without the “Machine-Wide Installer” installed, Teams is still available for use.

So when we install the Teams “Machine-Wide Installer” stub, we get a) an auto-launching app for every user that impacts performance as it installs into the user profile and then launches itself, and b) half a gigabyte of files dumped into our profile management tool for each instance of it, which will only grow bigger. Is there any way we can mitigate this impact?

Dealing with Teams

Once I’d investigated the app’s behaviour a bit more, I came up with a set of things I wanted to configure:-

1. Stop the auto-launch at every user logon – drop the shortcuts, yes, but remove the subsequent auto-run
2. Configure Teams so once the user had “installed” it (loosest possible use of the word), that it always opens up minimized. This is to ensure that when the user logs onto another session (such as from a meeting room kiosk or something) Teams doesn’t open up full-screen and expose any information
3. If possible, reduce the size of the profile load and allow Citrix User Profile Management to roam it successfully
4. Address any performance issues (not surprisingly, this is a complete resource hog)
5. Get rid of the splash screen when the application launches

So, let’s see what we managed to do. All of this was done using Citrix Virtual Apps 1811 and Citrix UPM 1811 on Windows Server 2016, fully patched.

Stopping the auto-launch

Once you’ve installed the Machine-Wide Installer on your XenApp server or gold image, run this PowerShell afterwards

(Get-Content ${ENV:ProgramFiles(x86)}’\Teams Installer\setup.json’).replace(‘false’,’true’) | Set-Content ${ENV:PROGRAMFILES(x86)}’\Teams Installer\setup.json’

This will remove the flag in the JSON file that says “noAutoStart=false” with “noAutoStart=true”. This means when the user logs in, it will create the two shortcuts, dump the install files into their profile, but it won’t then run the app afterwards and ask for login/start a sync.

Also (not related but maybe good to mention), you need to make sure IE Enhanced Security Configuration is disabled on your targets, otherwise the Teams modern authentication will fail

Open minimized

Now, once the user logs into Teams using their Office365 account, they have the option to set it to run minimized within the application options. However, for my purposes, I always want it to run minimized to the notification area. Unfortunately, there are not yet Group Policy Objects, InTune ADMX files or even Registry values that control Teams behaviour. Annoying, but not unexpected, given the dumpster fire that is the rest of the product from an admin perspective.

What holds user settings is a JSON file in %APPDATA%\Microsoft\Teams called desktop-config.json. Rather than get gung-ho, the best option I could find was to edit the settings in this file at user logoff using a Group Policy logoff script (you could do it at logon as well, as long as it gets done at some point in the session then you’re good). A quick line of PowerShell will do the trick:-

(Get-Content $ENV:APPDATA\Microsoft\Teams\desktop-config.json).replace(‘”openAsHidden”:false’, ‘”openAsHidden”:true’) | Set-Content $ENV:APPDATA\Microsoft\Teams\desktop-config.json

Once this is done, a user logging in who already has the application “installed” will see it open minimized in the notification area, no matter what they configure in the GUI. Save the PowerShell as a .ps1 file and trigger it how you see fit (I chose a logoff script via GPO – pick your poison).

Reducing the bloat

Unfortunately this is a difficult matter, as everything that Teams needs to run – executables, libraries, modules, data – is all contained in the user profile. I managed to get UPM set so it only pulled about 200MB (!) instead of 400MB, but even so, that’s still awful.

Teams seems custom-designed for FSLogix, User Profile Disks, ProfileDisk or an Ivanti UWM VHD-Mount, and I’m wondering if the need to persist Teams data was a driving force in the FSLogix acquisition by Microsoft. Certainly, if you’re using one of these VHD solutions, then dealing with Teams data will be much less of a PITA.

It’s worth noting that the file called simply “RELEASES” in the Packages folder must be present otherwise the shortcut will not work (it just won’t launch the executable), which is why the exclusions below do not simply remove the Packages folder.

If you are using Citrix UPM or similar, this is the best I could do without breaking the application:-

Exclusion list – files

!ctx_localappdata!\Microsoft\Teams*.nupkg

Exclusion list – directories

!ctx_localappdata!\Microsoft\Teams\Current\Locales
!ctx_roamingappdata!\Microsoft Teams\Logs
!ctx_localappdata!\SquirrelTemp
!ctx_roamingappdata!\Microsoft\Teams\Application Cache
!ctx_roamingappdata!\Microsoft\Teams\Cache
!ctx_localappdata!\Microsoft\Teams\Packages\SquirrelTemp
!ctx_localappdata!\Microsoft\Teams\current\resources\locales

Default exclusion list – directories – ENABLED (this is required if you are using Teams with Google Chrome)

Files to synchronize – note the first two lines here, this excludes all locales from being captured except English. If you need other locales, configure the exclusions to suit your environment.

!ctx_localappdata!\Microsoft\Teams\Current\Locales\en*.pak
!ctx_localappdata!\Microsoft\Teams\current\resources\locales\locale-en*
!ctx_localappdata!\Microsoft\Teams\current\resources\locales\culture*

Also worth mentioning is that because this is (obviously) an Office 365 application, you need to roam the Office 365 licensing token correctly for the user’s logon details to persist. You can either capture this directly or use the GPO to redirect it to a different area and then grab it. There are a number of good articles on this already within the Citrix community.

Deal with performance issues

Teams is pretty atrocious performance-wise, once the user first logs in, it hammers the CPU pretty hard and will use a swathe of memory within its array of processes. From the point of view of the admin, there’s not a lot we can do without getting other tools involved. That’s why removing the “auto-install” flag is so handy, because it doesn’t start hammering the server until the user launches it for the first time. With “auto-install” on, a bunch of users logging on at the same time will bring the server to its knees. SO GET IT TURNED OFF!

Aside from that, there’s not much we can do, so using Workspace Environment Management or Ivanti Performance Manager or something similar might be a way to get it under control a bit. However – I haven’t tested doing anything like this. Once it is fully set up, it’s not as bad, but the initial launch and sync is definitely very stressful.

Remove the splash screen

I hate splash screens as a rule and like to get shot of them, waste of time and resources that they are.

Sadly this one appears to be here to stay. I can’t find any setting in any of the JSON files that seems to control the splash screen. If anyone finds out where it is, please let me know and I can update the article.

Summary

So if you want to use Microsoft Teams on XenApp or similar non-persistent:-

• Install the Machine-Wide Installer
• Turn off IE ESC for users
• Run the PowerShell to edit the setup.json file after install
• Configure a logon or logoff script to run it auto-hidden at logon using the PowerShell provided
• If using UPM or similar, configure the inclusions and exclusions as listed
• Ideally, use FSLogix or UPD or similar VHD tech to manage the profile
• Make sure to roam the user’s Office 365 credentials
• Pay attention to performance and address using tooling if necessary
• Get used to the splash screen

There is another way, though – forget about the Teams application on XenApp and just use the web client until they fix the absolute mess of its behaviour and configuration. It might perform just as badly as the full-fat client, but you don’t have to drag 500MB+ around for every user. You have been warned!