Microsoft Teams on Citrix XenApp

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

Introduction

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!

10,814 total views, 10 views today

41 comments

  1. For “Configure a logon or logoff script to run it auto-hidden at logon using the PowerShell provided” the user needs to launch Teams and click Sign in on the initial screen before you can modify that JSON attribute right? I have been looking for a way to have it bypass the first run login screen, do you by chance know if that is possible?

    1. Yes that’s right, the JSON file isn’t populated fully until the user signs in for the first time, unfortunately. However you could try auto-populating the JSON file yourself, I guess. Not sure if SSO to Teams is possible – people often have multiple accounts.

  2. Sounds like it might be a candidate for creating symbolic links to the read-only content like exes and dlls from the user’s profile to a single central install on c: although a standard user doesn’t have rights to create symbolic links by default so that would need considering.

    If I get some time, I’ll have a play – creating symbolic links is native to PowerShell 5.x via:

    New-Item -ItemType HardLink

  3. Been testing this with FSLogix, using the MSI (Teams Machine Installer)

    Using this MSI should allow auto trigger using the path below in the registry
    TeamsMachineInstaller Data=%ProgramFiles%\Teams Installer\Teams.exe –checkInstall –source=default”

    However, for us Teams will not self trigger, when using FSLogix as the VDH will creates the teams folder in appdata\local\microsoft and under roaming. If i remove the –checkinstall this will work. However this cant be left on as it will reinstall regardless whether you have a teams or now, as the check is bypass and with FSLogix i believe will increase the VDH.

    Have you tested MSI, with FSlogix (teams enabled via GPP)
    thanks

  4. On setup.json instead of .replace(‘false’,’true’) – which replaces all false -> true in the config, it’s safer to go more specific and only do a noAutoStart=false -> noAutoStart=true substitution.

    Cheers.

  5. Looking to do this ourselves in a few weeks, but as we are heavy Skype voice and video users we’ve delayed until the first drop of the hdx pack hits (still lacking the functions of sharing and remote control). I’m expecting a train wreck and having to sort out a mess similar to the one that we’ve been left with a wholesale onedrive fb migration and having to try and make that work in server 2016 without files on demand.

  6. Very nice article and most entertaining to read!

    In our test environment (XenApp 7.6CU6, Win2012R2) I am currently testing a Teams installation without actually installing Teams. I just copy the contents (Update.exe, app.ico, .\packages, .\current) into %programfiles(x86)% (32bit because otherwise the webcam via hdx won’t work), and publish .\current\Teams.exe. This seems to work and eliminates the whole profile bloating, since the app doesn’t copy itself into AppData.
    The fact that the auto-update is also broken this way is good and bad. We pubish updates on a regular basis but they have to be tested, so it’s good that the app won’t update itself but on the other hand, I don’t have any clue what unneccesary errors may be produced because of all this.
    Has anyone got any experience in such an installation or does anyone know how to properly turn off the AutoUpdate?

    Thanks in advance!

  7. Use the machine-wide installer with the no auto launch flag set to pre-populate the json and save the PowerShell step.

    Pull the HKLM Run key for the installer and replace with a marginally delayed logon script (start-sleep anyone? lol) that checks the Appdata path and installs or exists – use the same command line switches so it leverages the json, otherwise it will be all default.

    This will work fine with FSLogix. I’m not sure how much of the FSLogix thing is prepopulated paths as the same command line works with a slight delay introduced. This may be the installer kicks off and the destination path is then subsumed by FSLogix so it fails out.

      1. msiexec /i Teams_windows_x64.msi OPTIONS=”noAutoStart=true”

        Worth a test with your other flags, see if they appear in the deployment json too.

    1. And how many users do you have on one server? We are also using Teams on XenApp and FSLogix, on a HP Moonshot system. But Teams is a performance killer. As soon as I have more than 5 users on one server and all are running Teams, CPU is on 100% and the server is crasching sooner or later.

      1. I normally only have about ten users per server in the lab but they aren’t doing a lot, to be fair. In that instance I’d use WEM or Ivanti to bring it under control.

  8. Hello,

    i have the problem that in my Enviroment with VDA 1811 Teams could be installed and startet and used one time. The next time then i close Teams and start it again the Main Windows comes up blank. It dosn’t work anymore.

    Did someone have the same error?

    Kind Regards

    1. I had the same issue with the second run of Teams. Blinking mouse cursor also appears. I copied the Teams folder to a central location on the XenApp server.

      My current work-around is deleting this file prior to starting Teams. With SSO configured users do not notice any issues.
      C:\Users\%username%\AppData\Roaming\Microsoft\Teams\settings.json

      1. Without wanting to break any NDAs, I think that a lot of the problems with Teams have been listened to, and we may well see some progress on these things in the future. Will update with an article as soon as anything that can be publicly announced comes along.

        1. Apparently the cat’s out of the bag. A per-machine Teams install is coming shortly according to the new out of Ignite.

          1. Yep, I’ve seen a preview and it looks good – *only* 90MB of rubbish in your profile instead of 500MB 🙂

      2. Excatly the same here. Thats so fu***ing anoying.

        First I’ve fighting with AppLocker and Teams. Than I figured out the issue with the flickering mouse with the 2nd start.

        It’s unbelivable that this software comes from Microsoft. I estimated that Microsoft has knowledge about Terminalservices and Application Programming.

    2. Yeah I have this Many times a week. My only work around is for the user to reinstall it. Kinda sucks. Teams is not Citrix or rdsh ready. The web version seems ok. But we don’t use video or calls. So I don’t know if the web would work for that.

    3. There is Workaround for this on (https://tech.xenit.se/teams-keeps-crashing-in-citrix/):

      “To get Teams to work on your Citrix environment if you experience this specific issue you need to exclude all Citrix Hooks from Teams.exe, you perform this by editing/adding the following registry value:

      32-bit version:
      HKLM\SOFTWARE\citrix\CtxHook\
      String Value: ExcludedImageNames
      Value: Teams.exe

      64-bit version:
      HKLM\SOFTWARE\WOW6432Node\citrix\CtxHook\
      String Value: ExcludedImageNames
      Value: Teams.exe

      Note: The server need to restart for the changes to take affect!”

  9. Would this help with Team.

    Large Profile handling – Files to be created as symbolic links

    AppData\Roaming\Microsoft\Teams\Application Cache\Cache\*.cache

  10. Office 365 ProPlus 1902 and newer builds now install Teams by default as well, but I noticed that the HKLM Run key that calls it is slightly different – “%ProgramFiles%\Teams Installer\Teams.exe –checkInstall –source=PROPLUS”. The actual files that get installed in the Teams Installer folder look the same. Any idea how changing the “source” from default to PROPLUS affects things? Does this mean the Teams app installed in this way might follow ProPlus’ update model and only update when ProPlus updates?

    1. Very good question, I hadn’t tried this. I’m assuming your initial feeling is correct, that it then fits in with the usual nuances of the ProPlus model.

  11. Hello,

    Thanks for this article !

    I think it’s a good idea to also exclude !ctx_localappdata!\Microsoft\Teams\current\previous fro Profile Management.

    Regards
    Julien

  12. Has anyone else seen while Teams is open in a session that you get a spinning wheel next to a mouse cursor?

  13. Did anyone get teams with ivanti EM VHD-redirect to work?
    We have Server 2016 XenApps (pvs) with the machine wide installer installed on it.
    When i configure the vhd mount and try to redirect %localappdata%\Microsoft\Teams to the vhd mount loaction, the teams installer deletes the symbolic links and recreates the folder again…

    So far our solution is to increase the cache size dramatically, so that we can handle 400mb per user in the write cache of provisioning …

  14. I just started testing the Teams per-machine installer in XD 7.15 LTSR today (W10 1709). Excluding ‘AppData\Roaming\Microsoft\Teams’ and sync’ing ‘AppData\Roaming\Microsoft\Teams\desktop-config.json’ in Citrix Profile Manager seems to keep the profile small and saves the user’s settings. I haven’t found any way to enable SSO for that first launch, though.

          1. That looks like the original installer with a tweak to allow installation to the “right” location maybe, not entirely sure

          2. Yes i can confirm that the new VDI bases installation is what we were looking for 🙂

            Make sure you install with the parameter ALLUSER=1 and the Teams client executable will be installed in C:\Program Files (x86)\Microsoft\Teams\current.

            Remove the following regkey to prevent autostart:

            REG DELETE HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run /v Teams /f

  15. Hello, does anywone know if it works in a non-persistent environment ( 7.15 ltsr MCS)
    and is it not supported or does it not work ?

    I know in the docs it says it is not supported but maybe it is not updated yet 🙂
    anyone tryed already ?

    1. it works for us. Xenapp 7.15 ltsr / PVS / AppLayering
      One thing i noticed is that the teams meeting addin is not showing in Outlook 2016.
      Any thoughts on that?

  16. well it also seems to work at our side. i do need to exclude C:\Users\%username%\AppData\Roaming\Microsoft\Teams\settings.json from roaming with the profile or else i ge the spinning wheel of death. after one succefull start.

Leave a Reply

Your email address will not be published. Required fields are marked *