- Microsoft Teams Through Citrix
- Citrix Microsoft Teams Microphone Not Working
- Microsoft Teams Citrix Hdx
Microsoft Teams The standard installation, that the user can perform through the Office365 portal, is a user-based installation. In a Citrix environment, this is only recommended for desktop operating systems (pooled or personal desktop). Citrix optimization of the Microsoft Teams solution was developed in partnership with Microsoft—enabling a secure unified communications platform for today’s modern workforce, and gives users the best possible Teams experience within a virtualized or cloud-hosted application or desktop. Moving to the modern desktop?
This article describes the requirements and limitations for using Microsoft Teams in a virtualized environment.
What is VDI?
Virtual Desktop Infrastructure (VDI) is virtualization technology that hosts a desktop operating system and applications on a centralized server in a data center. This enables a fully personalized desktop experience to users with a fully secured and compliant centralized source.
Microsoft Teams in a virtualized environment supports chat and collaboration. And with the Windows Virtual Desktop, Citrix, and VMware platforms, calling and meeting functionality is also supported.
- Microsoft Teams optimization will not work where VDA is installed with Single-session OS Core installation. Problem Cause MS Teams optimization will not work in this case because the two services on which MS Teams optimization depends - Citrix HDX HTML5 Video Redirection and Citrix HDX Teams Redirection are not part of VDA Single-session OS.
- Citrix will also invest in building a Microsoft-centric Citrix Workspace, providing deep integrations to optimize performance, functionality, and micro-apps for Windows Virtual Desktop and Microsoft 365, including Microsoft Teams. In addition, Citrix will use Azure and Microsoft 365 across its operations to accelerate innovation and enhance.
- This is a Live article - updated frequently with the latest info an known issues. Minimum Teams version: 1.2.00.31357 Recommended Teams version: 1.3.00.21759 (or higher) 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.
Teams in a virtualized environment supports multiple configurations. These include VDI, dedicated, shared, persistent, and non-persistent modes. Features are in continuous development and are added on a regular basis, and functionality will expand in the coming months and years.
Using Teams in a virtualized environment might be somewhat different from using Teams in a non-virtualized environment. For example, some advanced features might not be available in a virtualized environment, and video resolution might differ.
To ensure an optimal user experience, follow the guidance in this article.
Note
For details about Teams VDI on different platforms, see Teams features by platform.
Teams on VDI components
Using Teams in a virtualized environment requires the following components.
- Virtualization broker: The resource and connection manager to the virtualization provider, such as Azure
- Virtual desktop: The Virtual Machine (VM) stack that runs Microsoft Teams
- Thin client: The endpoint that the user physically interfaces with
- Teams desktop app: The Teams desktop client app
Teams on VDI requirements
Virtualization provider requirements
The Teams desktop app was validated with leading virtualization solution providers. With multiple market providers, we recommend that you consult your virtualization solution provider to ensure that you meet the minimum requirements.
Currently, Teams on VDI with audio/video (AV) optimization is certified with Windows Virtual Desktop, Citrix, and VMware. Review the information in this section to ensure that you meet all requirements for proper functionality.
Platforms certified for Teams
The following platforms have virtual desktop infrastructure solutions for Teams.
Platform | Solution |
---|---|
Windows Virtual Desktop | |
Citrix Virtual Apps and Desktops | |
VMware Horizon |
Windows Virtual Desktop
Windows Virtual Desktop provides AV optimization for Teams on VDI. To learn more and requirements and installation, see Use Teams on Windows Virtual Desktop.
Citrix Virtual Apps and Desktops requirements
Citrix Virtual Apps and Desktops (formerly known as XenApp and XenDesktop) provides AV optimization for Teams on VDI. With Citrix Virtual Apps and Desktops, Teams on VDI supports calling and meeting functionality in addition to chat and collaboration.
You can download the latest version of Citrix Virtual Apps and Desktops at the Citrix downloads site. (You'll need to sign in first.) The necessary components are bundled into the Citrix Workspace app (CWA) and Virtual Delivery Agent (VDA) by default. You don't need to install any additional components or plugins on CWA or the VDA.
For the latest server and client requirements, see this Citrix website.
VMware Horizon Workspace and Desktop requirements
VMware Horizon is a modern platform for secure delivery of virtual desktops and apps across the hybrid cloud. To offer a great end-user experience, VMware Horizon provides media optimization for Teams. This optimization improves overall productivity across virtual desktops and apps, and enhances user experience when calling and meeting using Teams.
You can download the latest version of VMware Horizon from the VMware Downloads page. The required media optimization components are part of the Horizon Agent and Horizon Client by default and there's no need to install any additional plug-in to use the optimization feature for Teams.
To get the latest requirements and instructions on how to configure media optimization for Teams, see this VMware website.
Install or update the Teams desktop app on VDI
You can deploy the Teams desktop app for VDI using a per-machine installation or per-user installation using the MSI package. Deciding on which approach to use depends on whether you use a persistent or non-persistent setup and the associated functionality needs of your organization.
For a dedicated persistent setup, either approach would work. However, for a non-persistent setup, Teams requires a per-machine installation in order to work efficiently. See the Non-persistent setup section.
With per-machine installation, automatic updates is disabled. This means that to update the Teams app, you must uninstall the current version to update to a newer version. With per-user installation, automatic updates is enabled. For most VDI deployments, we recommend you deploy Teams using per-machine installation.
To update to the latest Teams version, start with the uninstall procedure followed by latest Teams version deployment.
For Teams AV optimization in VDI environments to work properly, the thin client endpoint must have access to the internet. If internet access isn't available at the thin client endpoint, optimization startup won't be successful. This means that the user is in a non-optimized media state.
Dedicated persistent setup
In a dedicated persistent setup, users' local operating system changes are retained after users log off. For persistent setup, Teams supports both per-user and per-machine installation.
The following is the recommended minimum VM configuration.
Parameter | Workstation operating system | Server operating system |
---|---|---|
vCPU | 2 cores | 4,6, or 8 It's important to understand the underlying non-uniform memory access (NUMA) configuration and configure your VMs accordingly. |
RAM | 4 GB | 512 to 1024 MB per user |
Storage | 8 GB | 40 to 60 GB |
Non-persistent setup
In a non-persistent setup, users' local operating system changes are not retained after users log off. Such setups are commonly shared multi-user sessions. VM configuration varies based on the number of users and available physical box resources.
For a non-persistent setup, the Teams desktop app must be installed per-machine to the golden image. (To learn more, see the Install or update the Teams desktop app on VDI section.) This ensures an efficient launch of the Teams app during a user session.
Using Teams in a non-persistent setup also requires a profile-caching manager, for efficient Teams runtime data synchronization. Efficient data synchronization ensures that the appropriate user-specific information (such as a user's data, profile, or settings) is cached during the user's session. Make sure data in these two folders are synched:
- C:UsersusernameAppDataLocalMicrosoftIdentityCache (%localAppdata%MicrosoftIdentityCache)
- C:UsersusernameAppDataRoamingMicrosoftTeams (%appdata%MicrosoftTeams)
Note Illustrator software for mac free.
A roaming folder (or, if you are using folder redirection, a caching manager) is required to ensure that the Teams app has the runtime data and files required to run the application. This is necessary to mitigate network latency issues or network glitches, which would otherwise cause application errors and a slow experience due to unavailable data and files.
There are a variety of caching manager solutions available. For example, FSLogix. Consult your caching manager provider for specific configuration instructions.
Teams cached content exclusion list for non-persistent setup
Exclude the following from the Teams caching folder, %appdata%/Microsoft/Teams. Excluding these items helps reduce the user caching size to further optimize your non-persistent setup.
- .txt files
- Media-stack folder
- meeting-addinCache (%appdata%MicrosoftTeamsmeeting-addinCache)
Microsoft 365 Apps for enterprise considerations
Consider the following when you deploy Teams with Microsoft 365 Apps for enterprise on VDI.
New deployments of Teams through Microsoft 365 Apps for enterprise
Before you deploy Teams through Microsoft 365 Apps for enterprise, you must first uninstall any pre-existing Teams apps if they were deployed using per-machine installation.
Teams through Microsoft 365 Apps for enterprise is installed per-user. To learn more, see the Install or update the Teams desktop app on VDI section.
Teams deployments through Microsoft 365 Apps for enterprise updates
Teams is also being added to existing installations of Microsoft 365 Apps for enterprise. Since Microsoft 365 Apps for enterprise installs Teams per-user only, see the Install or update the Teams desktop app on VDI section.
Using Teams with per-machine installation and Microsoft 365 Apps for enterprise
Microsoft 365 Apps for enterprise doesn't support per-machine installations of Teams. To use per-machine installation, you must exclude Teams from Microsoft 365 Apps for enterprise. See the Deploy the Teams desktop app to the VM and How to exclude Teams deployment through Microsoft 365 Apps for enterprise sections.
How to exclude Teams deployment through Microsoft 365 Apps for enterprise
To learn more about Teams and Microsoft 365 Apps for enterprise, see How to exclude Teams from new installations of Microsoft 365 Apps for enterprise and Use Group Policy to control the installation of Teams.
Deploy the Teams desktop app to the VM
Download the Teams MSI package that matches your VDI VM operating system using one of the following links:
Note
For government clouds, see Install Microsoft Teams using Microsoft Endpoint Configuration Manager for the download links to the MSI files.
The minimum version of the Teams desktop app that's required is version 1.3.00.4461. (PSTN hold isn't supported in earlier versions.)
Install the MSI to the VDI VM by running one of the following commands:
Per-user installation (default)
This process is the default installation, which installs Teams to the %AppData% user folder. At this point, the golden image setup is complete. Teams won't work properly with per-user installation on a non-persistent setup.
Per-machine installation
This process installs Teams to the Program Files (x86) folder on a 64-bit operating system and to the Program Files folder on a 32-bit operating system. At this point, the golden image setup is complete. Installing Teams per-machine is required for non-persistent setups.
The next interactive logon session starts Teams and asks for credentials.
Note
These examples also use the ALLUSERS=1 parameter. When you set this parameter, Teams Machine-Wide Installer appears in Programs and Features in Control Panel and in Apps & features in Windows Settings for all users of the computer. All users can then uninstall Teams if they have admin credentials.It's important to understand the difference between ALLUSERS=1 and ALLUSER=1. The ALLUSERS=1 parameter can be used in non-VDI and VDI environments, while the ALLUSER=1 parameter is used only in VDI environments to specify a per-machine installation.
Uninstall the MSI from the VDI VM. There are two ways to uninstall Teams.
PowerShell script: You can use this PowerShell script to uninstall Teams and remove the Teams folder for a user. Run the script for each user profile in which Teams was installed on the computer.
Command line: Run the following command.
This process uninstalls Teams from the Program Files (x86) folder or Program Files folder, depending on the operating system environment.
Teams on VDI performance considerations
There are a variety of virtualized setup configurations, each with a different focus for optimization. For example, a configuration might focus on user density. When planning, consider the following to help optimize your setup based on your organization's workload needs.
- Minimum requirement: Some workloads might require a setup using resources that are above the minimum requirements. For example, workloads for developers who use applications that demand more computing resources.
- Dependencies: These include dependencies on infrastructure, workload, and other environmental considerations outside the Teams desktop app.
- Disabled features on VDI: Teams disables GPU-intensive features for VDI, which can help improve transient CPU utilization. The following features are disabled:
- Teams CSS animation
- Giphy auto-start
Teams on VDI with calling and meetings
In addition to chat and collaboration, Teams on VDI with calling and meetings is available with supported virtualization provider platforms. Supported features are based on the WebRTC media stack and virtualization provider implementation. The following diagram provides an overview of the architecture.
Important
If you currently run Teams without AV optimization in VDI and you use features that are not supported yet for optimization (such as Give and take control when app sharing), you have to set virtualization provider policies to turn off Teams redirection. This means that Teams media sessions won't be optimized. For steps on how to set policies to turn off Teams redirection, contact your virtualization provider.
Network requirements
We recommend that you evaluate your environment to identify any risks and requirements that can influence your overall cloud voice and video deployment. Use the Skype for Business Network Assessment Tool to test whether your network is ready for Teams.
To learn more about how to prepare your network for Teams, see Prepare your organization's network for Teams.
Migrate from Skype for Business on VDI to Teams on VDI
If you're migrating from Skype for Business on VDI to Teams on VDI, besides the differences between the two applications, there are some differences when VDI is also implemented. Some capabilities that aren't currently supported in Teams VDI that are in Skype for Business VDI are as follows:
- Per-platform policy to disable some AV features in VDI
- Give and take control when app sharing
- Screen share from chat without audio
- Simultaneous video and screen sharing send and receive
Teams on Chrome browser versus Teams desktop app for VDI
Teams on Chrome browser doesn't provide a replacement for the Teams desktop app for VDI with AV optimization. The chat and collaboration experience works as expected. When media is needed, there are some experiences that might not meet user expectations on the Chrome browser:
- The audio and video streaming experience might not be optimal. Users might experiences delays or reduced quality.
- Device settings aren't available in browser settings.
- Device management is handled through the browser and requires multiple settings in browser site settings.
- Device settings might also need to be set in Windows device management.
Teams on VDI with chat and collaboration
If your organization wants to only use chat and collaboration features in Teams, you can set user-level policies to turn off calling and meeting functionality in Teams.
Set policies to turn off calling and meeting functionality
You can set policies by using the Microsoft Teams admin center or PowerShell. It might take some time (a few hours) for the policy changes to propagate. If you don't see changes for a given account immediately, try again in a few hours.
Calling polices: Teams includes the built-in DisallowCalling calling policy, in which all calling features are turned off. Assign the DisallowCalling policy to all users in your organization who use Teams in a virtualized environment.
Meeting policies: Teams includes the built-in AllOff meeting policy, in which all meeting features are turned off. Assign the AllOff policy to all users in your organization who use Teams in a virtualized environment.
Assign policies using the Microsoft Teams admin center
To assign the DisallowCalling calling policy and the AllOff meeting policy to a user:
- In the left navigation of the Microsoft Teams admin center, go to Users.
- Select the user by clicking to the left of the user name, and then click Edit settings.
- Do the following:
- Under Calling policy, click DisallowCalling.
- Under Meeting policy, click AllOff.
- Click Apply.
To assign a policy to multiple users at a time:
- In the left navigation of the Microsoft Teams admin center, go to Users, and then search for the users or filter the view to show the users you want.
- In the ✓ (check mark) column, select the users. To select all users, click the ✓ (check mark) at the top of the table.
- Click Edit settings, make the changes that you want, and then click Apply.
Or, you can also do the following:
- In the left navigation of the Microsoft Teams admin center, go to the policy you want to assign. For example:
- Go to Voice > Calling policies, and then click DisallowCalling.
- Go to Meetings > Meeting policies, and then click AllOff.
- Select Manage users.
- In the Manage users pane, search for the user by display name or by user name, select the name, and then click Add. Repeat this step for each user that you want to add.
- When you're finished adding users, click Save.
Assign policies using PowerShell
The following example shows how to use the Grant-CsTeamsCallingPolicy to assign the DisallowCalling calling policy to a user.
To learn more about using PowerShell to manage calling policies, see Set-CsTeamsCallingPolicy.
The following example shows how to use the Grant-CsTeamsMeetingPolicy to assign the AllOff meeting policy to a user.
To learn more about using PowerShell to manage meeting policies, see Set-CsTeamsMeetingPolicy.
Migrate Teams on VDI with chat and collaboration to optimize Teams with calling and meetings
If you have an existing implementation of Teams on VDI with chat and collaboration in which you had set user-level policies to turn off calling and meeting functionality, and you're migrating to Teams with AV optimization, you must set policies to turn on calling and meeting functionality for those Teams on VDI users.
Set policies to turn on calling and meeting functionality
You can use the Microsoft Teams admin center or PowerShell to set and assign calling and meeting policies to your users. It can take some time (a few hours) for policy changes to propagate. If you don't see changes for a given account immediately, try again after a few hours.
Calling polices: Calling policies in Teams control which calling features are available to users. Teams includes the built-in AllowCalling calling policy, in which all calling features are turned on. To turn on all calling features, assign the AllowCalling policy. Or, create a custom calling policy to turn on the calling features that you want and assign it to users.
Meeting policies: Meeting policies in Teams control the types of meetings that users can create and the features that are available to meeting participants that are scheduled by users in your organization. Teams includes the built-in AllOn meeting policy, in which all meeting features are turned on. To turn on all meeting features, assign the AllOn policy. Or, create a custom meeting policy to turn on the meeting features that you want and assign it users.
Assign policies using the Microsoft Teams admin center
To assign the AllowCalling calling policy and the AllOn meeting policy to a user:
- In the left navigation of the Microsoft Teams admin center, go to Users.
- Select the user by clicking to the left of the user name, and then click Edit settings.
- Do the following:
- Under Calling policy, click AllowCalling.
- Under Meeting policy, click AllOn.
- Click Apply.
To assign a policy to multiple users at a time:
- In the left navigation of the Microsoft Teams admin center, go to Users, and then search for the users or filter the view to show the users you want.
- In the ✓ (check mark) column, select the users. To select all users, click the ✓ (check mark) at the top of the table.
- Click Edit settings, make the changes that you want, and then click Apply.
Or, you can also do the following:
- In the left navigation of the Microsoft Teams admin center, go to the policy you want to assign. For example:
- Go to Voice > Calling policies, and then click AllowCalling.
- Go to Meetings > Meeting policies, and then click AllOn.
- Select Manage users.
- In the Manage users pane, search for the user by display name or by user name, select the name, and then click Add. Repeat this step for each user that you want to add.
- When you're finished adding users, click Save.
Assign policies using PowerShell
The following example shows how to use the Grant-CsTeamsCallingPolicy to assign the AllowCalling calling policy to a user.
To learn more about using PowerShell to manage calling policies, see Set-CsTeamsCallingPolicy.
The following example shows how to use the Grant-CsTeamsMeetingPolicy to assign the AllOn meeting policy to a user.
To learn more about using PowerShell to manage meeting policies, see Set-CsTeamsMeetingPolicy.
Control fallback mode in Teams
When users connect from an unsupported endpoint, the users are in fallback mode, in which AV isn't optimized. You can disable or enable fallback mode by setting one of the following registry DWORD values:
- HKEY_LOCAL_MACHINESOFTWAREMicrosoftTeamsDisableFallback
- HKEY_CURRENT_USERSOFTWAREMicrosoftOfficeTeamsDisableFallback
To disable fallback mode, set the value to 1. To enable audio only, set the value to 2. If the value isn't present or is set to 0 (zero), fallback mode is enabled.
This feature is available in Teams version 1.3.00.13565 and later. Free poker software for mac.
Known issues and limitations
Client deployment, installation, and setup
- With per-machine installation, Teams on VDI isn't automatically updated in the way that non-VDI Teams clients are. You have to update the VM image by installing a new MSI as described in the Install or update the Teams desktop app on VDI section. You must uninstall the current version to update to a newer version.
- In Citrix environments, if the user disconnects from the Virtual Machine while Teams is running, Teams updates can result in the user to be in a non-optimized state for AV when they reconnect. We recommend that users quit Teams before they disconnect from Citrix Virtual Machine to avoid this scenario.
- Teams should be deployed either per user or per machine. Deployment of Teams for concurrent per user and per machine is not supported. To migrate from either per machine or per user to one of these modes, follow the uninstall procedure and redeploy to either mode.
- Windows Virtual Desktop and VMware don't support MacOS and Linux-based clients at this time.
Calling and meetings
The following calling and meeting features are not supported:
- Any multi-window functionality like the new meeting experiences or any functionality that comes with the new meeting experience
- Enhanced emergency services
- HID buttons and LED controls between the Teams app and devices
- Background blur and effects
- Broadcast and live event producer and presenter roles
- Location-Based Routing (LBR)
- Call park
- Call queue
- Shared system audio/computer sound
- Media bypass for Direct Routing
- Zoom control
Note
Microsoft Teams Through Citrix
We're working on adding calling and meeting features that are currently only available in non-VDI environments. These might include more admin control over quality, additional screen sharing scenarios, and advanced features recently added to Teams. Contact your Teams representative to learn more about upcoming features.
The following are known issues and limitations for calling and meetings:
- Interoperability with Skype for Business is limited to audio calls; there is no video modality.
- Only a single incoming video stream is supported in meetings or group calls. When multiple people send video, only the dominant speaker's video is shown at any given time.
- Incoming and outgoing video stream resolution is limited to 720p resolution. This is a WebRTC limitation.
- Only one video stream from an incoming camera or screen share stream is supported. When there's an incoming screen share, that screen share is shown, instead of the video of the dominant speaker.
- Teams doesn't switch to use the last audio device that a user selected, if the device is disconnected, and then reconnected.
- Outgoing screen sharing:
- Application sharing is not supported.
- Give control and take control:
- Not supported during a screen sharing or application sharing session.
- Supported during a PowerPoint sharing session.
- Citrix-only limitations
- When screen sharing in a multi-monitor setup, only the main monitor is shared.
- High DPI scaling on CWA is not supported.
For Teams known issues that aren't related to VDI, see Support Teams in your organization.
Troubleshooting
Troubleshoot Citrix components
Teams crashes or the Teams sign in screen is blank
This is a known issue with Citrix VDA versions 1906 and 1909. To work around this issue, add the following registry DWORD value, and set it to 204 (hexadecimal).
HKEY_LOCAL_MACHINESOFTWARECitrixCtxHookAppInit_DllsSfrHookTeams.exe
Then, restart VDA. To learn more, see this Citrix support article, Troubleshooting HDX optimization for Teams.
Related topics
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.
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.
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
Citrix Microsoft Teams Microphone Not Working
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
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.
Microsoft Teams Citrix Hdx
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.