During the last couple of weeks I have been helping customers implement Microsoft Teams in their Citrix VAD setups. A common denominator for most of the Teams implementations was Teams consuming a lot of resources, different Teams versions were present in the environment and Teams generating a huge amount of temporary or cached data in the user’s profile.
Do you know who the only partner certified by Microsoft for Teams optimization is? Hint - you're watching their channel now.That's right! Citrix has been col.
In this article I’ll share my experiences with Teams in Citrix VAD. This is by no means a best-practices install or configuration guide it’s more of a guide on how to avoid a couple of different pitfalls and hopefully also provide a great user experience with Teams in a Citrix VAD setup.
- Citrix Workspace offers a unified, secure and intelligent workspace platform that enables users to access their apps, desktops and data from anywhere and transforms employee experience. Citrix Workspace – Cloud Workspace for Modern Workforce - Citrix.
- The following article provides guidelines for troubleshooting the HDX optimization for Microsoft Teams in Citrix Virtual Apps and Desktops 1906.2 or higher. Citrix strongly recommends the latest current release Workspace app version. Most of the new features require an upgrade of Workspace app, hence the Current Release model is the preferred delivery mechanism.
If you are not familiar with Microsoft Teams, you might want to gather some information before installing or configuring anything with Teams in a Citrix VAD setup. Visit this site, if you want to know more about Microsoft Teams.
First of all I want us to be on common ground before going any further with this article, so we’ll have to cover the different ways of installing Microsoft Teams, as this is an area causing a bit of confusion. In this article I am using the 64-bit version of Teams and the 64-bit version of Office installed in Windows Server 2019 with using FSLogix Profile Container.
Installing Microsoft Teams Per-User:
Today there are 2 different ways of installing Microsoft Teams. You can install it either as a per-user install or a per-machine (machine-wide) install. Microsoft recommends to install Teams as a per-machine install in non-persistent setups.
The per-user install can be installed in a few different ways. Either via the Office 365 click-to-run installer, via an EXE file or via an MSI file, Microsoft isn’t making this easy! Both the EXE installer and MSI installer can be downloaded in either 32-bit or 64-bit, make sure to get to one matching the Windows architecture.
You can get the EXE file here:
https://products.office.com/en-us/microsoft-teams/download-app
You can get the MSI files here:
32-bit – https://teams.microsoft.com/downloads/desktopurl?env=production&plat=windows&managedInstaller=true&download=true
64-bit – https://teams.microsoft.com/downloads/desktopurl?env=production&plat=windows&arch=x64&managedInstaller=true&download=true
So, as you can there are 3 different ways of deploying Microsoft Teams as a per-user install, a bit of a mess if you ask me and I am not surprised if some finds it a bit confusing.
We’ll need to dive a bit deeper in how the per-user install actually works, even though it’s not the recommended way of deploying Microsoft Teams, there is some useful information for when we cover the migration from the per-user install to a per-machine later in this article.
Both the EXE file, MSI file and the Office 365 click-to-run “installs” a Teams.exe file and a setup.json file in C:Program Files (x86)Teams Installer:
In this case I have installed version 1.3.0.4461 of Teams:
The Teams.exe file is the actual installer, which installs Microsoft Teams in AppDataLocalMicrosoft the user’s profile. The installation is triggered by Teams.exe process via registry, which can be found here:
For copy/pasting:
HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeMicrosoftWindowsCurrentVersionRun
So a plain old registry value in Run is used to kick off Teams, not necessarily the best way to start an app in a non-persistent shared environment, but then again this is the per-user install of Teams, which is meant to be installed on a physical Windows 10 machine, not a shared environment.
As mentioned, during logon Teams is installed in the user’s profile and when Teams is started up and the user has logged on, this is how the Teams install folder looks like:
Once this is completed, the Update.exe process, now in the user’s profile, is used to start Teams. This is, again, done via registry:
For copy/pasting:
HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionRun
As you can see the Update.exe is executed with a few parameters. I have not been able to find any information as to why this procedure is used to start Teams in a per-user install. My guess is that this Update.exe process checks for any new releases of Teams during startup of Teams, and then downloads the latest version at some point.
Microsoft has a very short article about the update process here:
https://docs.microsoft.com/en-us/microsoftteams/teams-client-update
According to the article Teams is updated every two weeks, no specific time of day is mentioned, so we’ll have to assume that the update process just kicks in at random. I have had a Teams running in a session for a couple of hours, no update kicked in. I have tried to log on and log off several times with Teams auto launching, nothing. At a customer I have seen 3 different versions of Teams being used at the same time, by different users. This might complicate things a bit in terms of troubleshooting because of the different versions. Some users might have issues that other users don’t have because they user another version of Teams.
For the sake of this article, I have done a manuel update via the “Check for Updates” feature:
This kicks off the update process, where the Teams.exe process and the Updates.exe process both consume a considerable amount of CPU resources, both processes have the priority of “normal” in Windows, which means that it might slow any other applications down for a couple of minutes, especially if you have multiple users where this update kicks in at the same time.
The update process goes out to Microsoft and downloads the latest version of Teams to the AppDataLocalMicrosoftTeamsstage folder in the user’s profile:
Once the source files for the new version of Teams are downloaded, the user will get a notification about a new version being available:
If the user clicks the “Please refresh now” text box, the updater kicks in and is again consuming a considerable amount of CPU resources, still at “normal” process priority, which may once again potentially slow other apps down for a period of time.
Interesting stuff is also going on in the user’s profile. The “stage” folder is now removed, and replaced with a “previous” folder:
So the user now has two versions of Teams in the profile, the current updated version, which is installed in the “current” folder and is the one being actively used in the current folder, and then the previous version of Teams, which is no longer used, essentially now doubling the amount of space used for the Teams install. Considering that I have found no information of how a user might be able to revert to a previous version of Teams, there is nothing in the Teams app that enables the user to roll back to a previously used Teams version, I am having a difficult time understanding why it’s necessary to store the previous version in the user’s profile, why isn’t just deleted?
To wrap this section up, there really isn’t any reason to use a Teams per-user install in a shared environment. In a shared environment we should have a degree of control of the apps installed and update process of the apps, to ensure stability and functionality. With a Teams per-user install, we don’t have any control, from the moment it’s installed it’s out of our control, because we don’t control the update process.
Migrate Teams per-user to Teams per-machine
Now you have come this far and you might have realized that Teams isn’t installed in the correct and recommended way, you can go a few different ways. Leave it be, and hope that Microsoft doesn’t change anything major or add additional features, which might demand even more resources or maybe break existing functionality. Or remove the current Teams per-user install and deploy the Teams per-machine install instead, which is also the recommendation from Microsoft.
If you decide to leave Teams alone in it’s current state, then there is no reason for you to read any further. However if you want to deploy the Teams per-machine instead, then stay with me.
To be honest this isn’t really a migration, it’s really “just” an uninstall of Teams, and an install of Teams suited for non-persistent shared environments.
Switching to a Teams per-machine install is fairly easy, you are probably not expecting that, considering we have to go out to every single user profile and remove a Teams per-user install, but Microsoft has actually done some clever thinking, when it comes to removing Teams per-user.
Uninstall Teams per-user
The first thing we’ll need to do is to remove the Teams per-user install. In Windows Server 2019 we’ll go to Apps and Features select the “Teams Machine-wide installer” and click uninstall. In this case the name is not entirely accurate, or it is, but the “Teams Machine-wide installer” is the machine-wide, or the per-machine installer, but it can also do a Teams per-user install. You might see “Teams” or “Teams Installer” instead, this is because you have used the EXE installer, mentioned earlier.
Back on track. The uninstall should be pretty uneventful, it’s an uninstall like any other uninstall, other than this uninstall only removes the C:Program Files (x86)Teams Installer folder, and not the Teams installed in the user’s profile. So, how to remove Teams from the users profiles? This is where Microsoft has done some clever thinking. During the uninstall of Teams per-user, two registry values are created here:
For copy/pasting:
HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeMicrosoftWindowsCurrentVersionRun
We need the data in the value “TeamsMachineUninstallerLocalAppData”, this string will uninstall Teams per-user, in the user’s profile.
For copy/pasting:
%LOCALAPPDATA%MicrosoftTeamsUpdate.exe –uninstall –msiUninstall –source=default
You HAVE to use this uninstall string, it is not enough to just delete the Teams folder from the user’s profile, Teams will come back if you do and you could end up with a mix of Teams per-user and Teams per-machine, they are able to exist perfectly fine side by side, you don’t want that!.
If you leave both values where they are, Teams will be uninstall during the next logon. In some cases that might be OK, however if you want a more controlled process, let’s say you want to do the uninstall for a specific group of users or when user’s access a test-server, you can bring in something like Citrix Workspace Environment Management, to execute the uninstall string based on AD group membership or anything that would identify the server as a test-server or whether the Teams install is a per-user or per-machine.
If you are going with the WEM approach make sure that both the “TeamsMachineUninstallerLocalAppData” and “TeamsMachineUninstallerProgramData” values are deleted, before going any further.
In WEM we can use an external task to execute the uninstall string:
Instead of using an AD group membership as a filter for the Teams per-user uninstall, we can use a combination of two filter conditions doing File/Folder matches, making sure that Teams per-user is not uninstalled, unless there is a Teams per-machine installed on the Session Host/VDI. We will have to create a filter condition which is checking to see if “%LOCALAPPDATA%MicrosoftTeamscurrentTeams.exe” exists and another filter condition which is checking to see if “C:Program Files (x86)MicrosoftTeamscurrentTeams.exe” exists. The “C:Program Files (x86)MicrosoftTeams” folder is where the Teams per-machine is installed, we’ll cover that in a moment.
The filter conditions look like this:
With these conditions I can create a filter rule which can be assigned to the “Teams per-user uninstall” external task.
The filter rule looks like this:
For this filter rule to apply, both filter conditions have to me met.
The last thing we need is to assign the “Teams per-user uninstall” external task:
Go to Assignments and click the little arrow button
In the drop down box select the filter rule we just created
You should end up with an assignment looking like this.
To summarize – Via WEM we are now uninstalling Teams per-user if the user is logging on to a Session Host/VDI that has Teams per-machine installed and Teams per-user exists in the user’s profile. We now have a controlled way of getting rid of Teams per-user.
Install Teams per-machine (Machine-wide)
There are a lot of different articles and guides on how to install Teams in a non-persistent and/or shared environment, I recommend this article by fellow CTA Manuel Winkel:
https://www.deyda.net/index.php/en/2020/02/25/install-teams-onedrive-in-citrix-machine-based/
Going further, I am assuming that you are going with the WEM approach, if you are not there might be some slight differences in how Teams behaves.
Also be aware that Microsoft is not making things easy for us at the moment. Currently there are two different download links for the Teams per-machine MSI installer, make sure to get the version from the link i Manuels article, as this is the version currently supported by Citrix (CTX253754). Make sure to keep an eye on that CTX253754 article.
The most important thing to remember is to user the correct install parameters during setup, to make sure that Teams is deployed as a per-machine install. Either go to the article by Manuel, refer to the official “Teams for Virtualized Desktop Infrastructure” documentation or use this command:
msiexec /i Teams_windows_x64.msi ALLUSER=1 ALLUSERS=1
To verify that it is a Teams per-machine install, make sure that you have a “C:Program Files (x86)MicrosoftTeams” folder. The folder structure in here should look familiar to you:
Teams is launched from the “current” folder via the Teams.exe process and once again a registry value is used to do the launch.
The registry value can be found here:
For copy/pasting:
HKEY_LOCAL_MACHINESOFTWAREWOW6432NodeMicrosoftWindowsCurrentVersionRun
Personally I delete this registry value, because I don’t want Teams auto starting via registry. There might be situations where you want to have a bit more control over who is running Teams, maybe because of license enforce ment or maybe you are testing Teams, and only want a certain group of users to be able to access Teams. Or perhaps you just don’t want applications auto launching during logon.
To control the Teams startup, we’ll again turn to Citrix WEM. Create an action, in this case it’s just called “Teams”:
Assign the newly created Teams action:
In this case I have created filter rule with a filter condition with an AD group membership check, so my user will have to be a member of a specific AD group for the action to apply.
Configure Teams for automatic start up:
Make sure Auto Start has a green check mark.
This is it! Teams per-machine is now alive and kicking.
Profile Exclusions
Both Teams per-user and Teams per-machine downloads a huge amount of temporary/cache data during first launch just to immediately flush it again, and to be honest I am not entirely sure why or what kind of data is downloaded, especially not with the per-machine install. However if you are not configuring the correct exclusions, you might see your FSLogix Profile Container increase in size, as the temporary/cached Teams is written and flushed.
With a fresh FSLogix profile, I have seen the container expand to around 4-5GB in size when launching Teams, with writes going the the AppDataRoamingMicrosoftTeamsService WorkerCacheStorage folder. If you mount the profile container, when it’s not in use, you’ll find that there’s only around 400-800MB of data in the container, and nothing or very few small files in the AppDataRoamingMicrosoftTeamsService WorkerCacheStorage folder.
As with any other profile exclusions, you should of course do some testing, before implementing in a production environment
Citrix Workspace And Teams
UPDATE – 14-07-2020 (july 14, 2020):
If you are using FSLogix Office Container, do not include Teams data in the Office Container, as the exclusions mentioned will no apply to the Office Container, they only apply to the Profile Container.
This means that you should either leave this policy at not configured or configured it as disabled:
UPDATE – 19-05-2020 (may 19, 2020):
The list of exclusions, below, has once again been updated. Via a Citrix discussions forum post, I have been made aware that certain exclusions are breaking things.
Excluding “AppDataLocalMicrosoftTeamscurrentresourceslocales” apparently breaks the system tray menu.
Excluding “AppDataLocalMicrosoftTeamsCurrentLocales” apparently breaks SSO to Teams.
Do not add the folders with a strikethrough. If you do, test, test, test!
Exclusions:
AppDataLocalMicrosoftTeamsPackagesSquirrelTemp
AppDataLocalMicrosoftTeamscurrentresourceslocalesAppDataLocalMicrosoftTeamsCurrentLocales
AppDataRoamingMicrosoftTeamsService WorkerCacheStorage
AppDataRoamingMicrosoftTeamsApplication Cache
AppDataRoamingMicrosoftTeamsCache
AppDataRoamingMicrosoft TeamsLogs
AppDataRoamingMicrosoftTeamsMedia-Stack
AppDataRoamingMicrosoftTeams*.txt (Cannot be implemented with FSLogix Profile Container, as it does not support file exclusion or exclusions based on wildcards)
UPDATE – 03-05-2020 (march 3, 2020):
The list of exclusions, below, has been updated. According to the Microsoft Teams documentation the AppDataRoamingMicrosoftTeamsMedia-Stack should be excluded and the same goes with AppDataRoamingMicrosoftTeams*.txt files
Teams Outlook Add-in
For some reason the Teams per-machine Outlook add-in is not loaded, so when a user launches Outlook and wants to arrange a new Teams meeting, the Teams add-in is simply not there, and it’s nowhere to be found in the list of available add-ins:
I would expect the add-in to be between the Skype add-in and the OneNote add-in, but it’s not. I am not entirely sure what is going on here, but I have found a workaround which should bring the Teams add-in back.
UPDATE – 03-05-2020 (march 3, 2020):
Teams has to be launched at least once to be able to access the Teams plugin. This means that even if you activate the plugin in Outlook,during first logon, it does not work until Teams is launched. For now I haven’t found any solution to that issue.
The workaround is a minor registry change in HKCU, configuring the LoadBehavior value for Microsoft Outlook add-ins:
Windows Registry Editor Version 5.00
[HKEY_CURRENT_USERSoftwareMicrosoftOfficeOutlookAddInsTeamsAddin.FastConnect]
“Description”=”Microsoft Teams Meeting Add-in for Microsoft Office”
“LoadBehavior”=dword:00000003
“FriendlyName”=”Microsoft Teams Meeting Add-in for Microsoft Office”
This should bring back the Teams outlook add-in. We can, once again, use our trusted Citrix WEM to do the import where we’ll create a nice little action group, with the Teams shortcut and the registry values like this:
Apply the Teams Auto Start filter rule we created earlier, in this way we have everything around Teams in one single group.
And here is the highly demanded Teams outlook add-in:
Citrix HDX Optimization
The last thing we need to do is to make sure that Citrix HDX Optimization has kicked in.
The Teams HDX Optimization is supported in Citrix Virtual Apps and Desktops 1906.2 and later and you’ll also have to use Citrix Workspace App 1907, however Citrix strongly recommends using Citrix Workspace App 1912 or 2002. You will also need Teams version 1.2.00.31357, however Citrix recommends version 1.3.00 .4461 or later.
Refer to this article for additional information:
https://support.citrix.com/article/CTX253754
If all of the above mentioned criteria have been met, you should see a “Citrix HDX Optimized” notification in Teams (in about -> version):
The Teams HDX Optimization enables Teams video and audio calls to be offloaded to the local endpoint device, this feature offloads a considerable amount of CPU usage on the Session Host/VDI to the endpoint. Be aware that the Teams HDX Optimization feature is not available on Linux based devices, at the moment it’s only supported on Windows devices.
Citrix Workspace App Teams
Thank you for reading. If you have any questions feel free to contact me via Twitter, LinkedIN or in the World of EUC Slack channel.
We’re back to Teams. Time to take a delve into its murkiest areas – configuring a default user state, and trying to wrestle with JSON files.
So, we’ve got Microsoft Teams installed in our Citrix/RDSH environment (which hopefully you did by following the instructions that are out there in the community, or maybe by using the article from the first part in this series). However, as administrators of virtual and/or multi-user platforms, what we normally want is control over the user’s default experience.
Administrators in these environments like to set things up for their users so that they are a) easy to use, and b) optimal in terms of performance. This generally means that ahead of the user using the application, the optimal settings for the environment and the customer are applied.
Normal practice for these sorts of configuration settings is to do it via GPO, or Registry entries (which can obviously be applied via GPO as well). Teams, though….well, you may have guessed that ol’ Teams likes to do things its own way.
Teams configuration
There aren’t any GPOs for Teams (well, there’s one, but it doesn’t work). However, it also doesn’t use Registry settings either. Teams has taken a step back towards the 1990s, when we used .ini files to control app settings, and uses files with an extension of .json (JavaScript Object Notation) to load these settings.
The main file that drives the Teams client configuration is called desktop-config.json which sits in the same folder as the others above, %APPDATA%MicrosoftTeams. User interface settings, such as those shown below (although there are more) are primarily saved to this file.
When these options are selected, they are written to the desktop-config.json file (although some are not committed until Teams is restarted). Here’s an example of what the json file actually looks like.
You can spot pertinent settings in here if you look hard enough, they’re stored under the section called “appPreferenceSettings”. Within the settings under here, True means the option was selected, False means it was de-selected. Some of the settings shown in the screenshot above are mapped out to json entries below.
“openAsHidden” is “open application in background”
“runningOnClose” is “On close, keep the application running”
“disableGPU” is “Disable GPU hardware acceleration”
“registerAsIMProvider” is “Register Teams as the chat app for Office”
“enableMediaLoggingPreferenceKey” is “Enable logging for meeting diagnostics”
Citrix Workspace App Linux Teams
“currentWebLanguage” is the “App language” setting
and so on and so forth.
If you want to examine this file content more clearly, then PowerShell is your friend
You can then simply look at the $json object and have the information displayed much more clearly
I’m sure you can pick more of these out yourself as required. Alternatively, you can simply change settings within the Teams interface and then check the json file afterwards to see what has been modified (or even use Process Monitor to see it).
Now, I’m sure most admins don’t feel to intimidated by this. Naturally, they just think “well, I will set a bunch of default options in the json file, add it to the user profile, and then those options will be set for each user”. Right?
Wrong.
The desktop-config.json file doesn’t exist until Teams is launched for the first time. It is created when Teams is first run, and then, it is pre-populated with a bunch of specific settings. These initial settings don’t appear to be sourced anywhere, at least not independent of the Teams code itself. Some of them appear to be populated from variables within the user session (so the userid is that of the user if using SSO, the language reflects the system language, etc.), but others simply default to whatever Microsoft have decreed. A pertinent example is the “disable GPU” setting. Ideally, I’d like my non-GPU workloads to have this selected by default when Teams is first launched, but it is always de-selected.
Now, there is actually a way you can create a pre-staged JSON file and have Teams append to it, rather than aggressively overwrite it. We will get to that more in a bit.
Solving the problem
We shouldn’t really have to do this!
Let’s put this right out there – we’re just hacking a way around things here because Microsoft are unwilling, for whatever reason, to give us any way to preconfigure Teams for our user. Whether it is by GPO, Registry or simply by allowing us to stage a JSON file that is then absorbed into the user’s settings file, this is something that needs to be done to allow administrators more control over the default user environment. Sort it out, Microsoft (and stop ignoring my applications to the MVP program as well).
Editing the JSON file
It’s easy enough to insert values into the JSON file – you simply use a bit of PowerShell. Here’s an example using it to set the disableGPU value – you can change this to whatever you require
Citrix Workspace Linux Teams
It’s much easier than using batch scripting, but you can do it in batch if you’re allergic to PowerShell (thanks to the superior Google-powers of the World of EUC Slack channel for giving me this)
So we know we can do it – but can we do it in such a way as to be picked up at the right time by the Teams interface, and before the first launch?
Configuring prior to Teams launch
What we need to do is find a way to get these settings in place ahead of the first Teams launch, or pre-configure them in a way that means Teams doesn’t overwrite it.
At first I considered the idea of running Teams silently in the background to configure the file, and then relaunching it again when invoked by the user. Don’t even bother going down this route – running Teams silently is a particular nightmare, and one which I wouldn’t advise you look at. It really shows how much of a pain it can be, as even being run from the command line results in Teams vomiting errors all over the screen. Beneath is the hideous mess it throws out when it is run from PowerShell, and it does the same if you use the command prompt (even if you use start, and it actually ignores all further command line input after this as well, which makes it even more annoying)
I’ve been through a whole host of pain trying to make this work, and I’m not going to detail them all here. Suffice to say, trying to launch Teams silently is a no-go (I went as far as trying to do it with an automatic logon, which was way too far to take this).
You’ve basically got two options if you decide that you really want to pre-configure these options ahead of the user’s first Teams session. You can use some third-party tooling, or you can try with a pre-configured desktop-config.json file.
Third-party tooling
Citrix WEM
There are a number of third-party tools out there that people commonly use with EUC environments. Many of you are probably thinking of Citrix Workspace Environment Management as something that might be used here, but unfortunately, WEM lacks the capability to intercept processes as they launch (for now, anyway). You can run external tasks, but they don’t give you any control over the overwrite at that initial launch. So WEM can’t help, as yet.
PolicyPak
PolicyPak is the first product worthy of note when it comes to dealing with Teams. It has some excellent Teams capabilities, which allow you to preset the settings that you are pushing down to your users. PolicyPak is ahead of the rest of the competition because you get to choose the options from a GUI (as below) rather than having to edit the JSON file through a scripting engine.
Because PolicyPak injects the settings into the configuration files (initially) at Group Policy refresh, it technically creates a cut-down desktop-config.json file for the user prior to launch. Then PolicyPak continues to keep those settings updated in case the end user tries to make unwanted changes within the Teams app itself. Rather cheekily, I’ve actually dug into the pre-staged file and used this as the basis for the pre-staged config file in the next part of the article, so it’s a testament to the quality of the PolicyPak product that not only have they got this bit worked out, but they’re also doing it without you having to do any scripting, whether directly or through an engine. You can also use PolicyPak to either enforce the settings or simply set them up for the user at first launch, so it is flexible into the bargain.
Bone thug harmony the collection volume 1 zippyshare. The application of the settings works pretty much without issue, although you can sometimes see oddities – one thing I did notice is that the “openAsHidden” value is not honoured unless the Teams executable is launched with the –process-start-args “–system-initiated” arguments attached. To be fair, we called this out in the previous article and it is a Teams problem rather than a PolicyPak one. PolicyPak is always re-applying (or attempting to re-apply) the Teams application settings… precisely at the moment the Teams app is launched. This occurs provided Teams itself is actually already terminated before the next launch (and not still running in the background). Then at re-launch time, you should see your re-injected values at Teams launch time. It seems to work pretty reliably and certainly consistently enough for an enterprise environment
PolicyPak has stacks of features in it; it’s very much more powerful than people usually give it credit for and it is probably deserving of a much closer look. I’m going to be digging into some of the unmanaged device features very soon, as I have a use case that needs it – give them a look and see what else they can bring.
Ivanti UWM
Another tool that you can use for this is my old pal Ivanti User Workspace Management (the suite formerly known as AppSense). Ivanti UWM (specifically the Environment Manager piece) can hook a process and then do all sorts of funky things afterwards. In testing, this works really well, there’s no overspill into the user session, and because it is all driven through the EM GUI it’s pretty easy to set up. If you’re an existing UWM customer, I’d go this route without a second thought. Admittedly, it’s unlikely to drive new sales for this tweak alone – but it is a helluva reminder of the power that you get with the UWM product. I used to do amazing things with UWM, and it’s nice to see that it still has all that punch.
The configuration you need to set up in EM to get this working is shown below – admittedly EM has so many different features you could skin this in a number of different ways, but this was the setup that worked pretty quickly for me in testing.
As usual with UWM, everything is pretty self-explanatory. The Teams process launching starts the actions, and underneath you set a condition that means that this sequence will only run once per user session (this is a massive boon, because Teams often spawns more Teams.exe processes during a session to accommodate things such as calls, screen shares, etc.). After that it checks for a custom Registry value to see if this process has run previously – if it has, the sequence of actions stops. If the value doesn’t exist, it pauses for two seconds, then runs a PowerShell action that kills the Teams processes and replaces the required values in the JSON file. Once that’s done, the Registry flag value is written so it won’t run this process at next Teams launch, and then Teams is relaunched for the user. The whole process takes a few seconds and is pretty much invisible to the user.
Out of the tools I normally use PolicyPak and Ivanti UWM were the only ones I could get this working with, and PolicyPak was the only one that did it via a native GUI. However, you could use the method I’ve come up with in the next section to vastly simplify the UWM process to achieve this.
Doing it natively
Now I did say you could manage to do this without third-party tools, and I’ve managed it in my lab. However – I do feel a bit guilty about unpicking the PolicyPak method and using it to come up with a way to do it natively. I’m hoping Jeremy and the staff over there don’t mind me leveraging their product in this way – as I said they have a vast amount of features within their product and it’s not as if Teams configuration is their only handy piece!
When I started this I mentioned that most admins would think they could just create a pre-staged file and store it either in the default profile, or inject it into the user’s profile at first logon. Now, when I originally tested this it failed, and Teams simply flat-out overrode it. However, it turns out that the key bit is not particularly what goes into the JSON file, but more to do with how it is laid out.
Long story short – you need to pre-configure your desktop-config.json file into a particular format. I’ve been using the file below, and this seems to work every time for setting the configuration items correctly at first launch.
You can add to or change these settings as required, but be careful, as some of them seem to be specifically required for Teams not to overwrite the file (callingMWENabledPreferenceKey is one of those, which is odd as it is a setting for the desktop version of Teams, rather than the machine installer).
In order to deploy this file successfuly, I have copied it into the default profile in c:usersdefaultAppDataRoamingMicrosoftTeams folder as desktop-config.json, which works great for new users. You could also inject it into the user’s profile using a GPP Files item, but make sure that you select the Create rather than Update or Replace options to avoid overwriting it at every logon. Personally I find the default user profile option the best as it specifically applies to new users.
Once this is in place, you should see new users getting the settings you want them to, as below.
Testing of this shows it to be very reliable, new users get their JSON file pre-configured with my selected options. After spending a whole day trying to find a way to intercept and manipulate the JSON file with scripts, I’m glad to see there is a straightforward way at last!
Saving a desktop-config.json file with the above formatted content into the default profile will allow you to pre-stage settings for your users as you wish.
If you’ve read my previous Teams article, you will see that I used the presence of the desktop-config.json file in the user profile to give an indicator to Group Policy Preferences as to whether Teams had already been run. Obviously if you use this method of pre-staging, you will need to pick another file to provide this flag. Fortunately, the %APPDATA%MicrosoftTeams folder contains many items you could use for this – I’d suggest a folder such as %APPDATA%MicrosoftTeamsCache would be a good contender, I have updated the article to reflect this.
Summary
So, if you want to pre-stage Teams settings, you’ve got a few options. Both PolicyPak and Ivanti UWM can handle this without blinking, and if you’re a user of either of these technologies you’re already sorted. If you’re not, then using a JSON file formatted like the one above will allow you to do this – at least until Microsoft move the goalposts again.
A final note about pre-configuration of Teams – I’ve had a few requirements where people have wanted the users to, by default, open Teams links in the application without prompting. The Registry settings below should be enough to handle this for you.
Citrix Workspace Linux Teams Optimization
Stay tuned for another Teams series instalment on optimization which should be along quickly, and also for the next part of the logon times Odyssey, where we are moving into the murky world of profiles.
Citrix Workspace Homepage
3,131 total views, 8 views today