Teams citrix

Teams citrix DEFAULT

Microsoft Teams has risen quite emphatically to prominence over the last six months or so. The reason for this is twofold – primarily, to do with the explosion of remote working that has occurred as a response to the COVID-19 pandemic, and also with the coincidence of the Skype for Business retirement date in August of 2020. This has resulted in many Citrix administrators having to deploy Teams into their Virtual Apps and Desktops environments – often quite rapidly.

Teams is Microsoft’s primary Office365 collaboration tool and is written in Electron, which makes it a bit of a pain to manage, like other Electron apps. An important point to make about Teams is that it cannot be run on-premises – it requires a cloud or hybrid model. This is because Teams hooks into Sharepoint Online, Exchange Online and Office365 Groups to drive the Teams experience. Exchange Online is the most important component to have so that your users can access the full features of the Teams product.

With Skype for Business running out of support and a huge percentage of the enterprise workforce now mandated to operate remotely, delivering Teams into Citrix environments suddenly became hugely important. But we didn’t just have to get it up and running – we had to get it up and running well. Video and audio (particularly video) were suddenly hugely important. For a lot of people, remote working is a huge cultural shift, and providing excellent collaboration facilities with the ability to interact directly with other humans is vitally important. The provision of realtime interaction is crucial – because drops in quality lead to disjointed contact, and for workers who are isolated from their colleagues, this can make a huge amount of difference. Indeed, the importance of top-quality video and audio isn’t just a business benefit to aid productivity any more, we’re actually potentially talking about people’s mental health and general happiness.

But what issues do we have putting Teams into a Citrix Virtual Apps and Desktops environment? I’ve had to divide this article into a very short series, unfortunately, so here’s the first instalment – dealing with installation.

Installation

Let’s start at the beginning, and arguably one of the trickiest parts of getting to grips with Teams – actually installing the damned thing.

Firstly, don’t use the Click To Run installer to install Teams, and make sure that you install the VDA prior to doing the Teams install. You can find the proper MSI installers at these links:-

32-bit Teams MSI install

64-bit Teams MSI install

The installer needs to be run with certain switches, so it should be called from msiexec (whether this is manually, or through some form of software deployment mechanism, is entirely up to yourself). The two switches you need to be concerned with are ALLUSER and ALLUSERS.

ALLUSERS simply means that an entry will be written into Programs and Features allowing the program to be uninstalled directly.

ALLUSER means that the automatic updater will be turned off, and this is crucially important for non-persistent and RDSH environments. Without this you will receive updates into multi-user or non-persistent environments and you will see a lot of problems.

If you are fully persistent – so for instance, using Teams on one-to-one machines where the user’s profile is stored locally – then you can get by with simply using the ALLUSERS switch on the installer, as below

If you are on any other form of environment other than fully persistent, then use both switches to ensure you don’t lose control of updates to your images

Now, onto the nitty-gritty. The Machine-Wide Installer drops a “stub” that is just the updater (and if you’ve installed using the right switches, this won’t run anyway). The executable and libraries go into c:\Program Files (x86)\Microsoft\Teams\current (again, as it doesn’t update, bit pointless for us), but everything else is dumped into the user profile. So the executable is called from the Program Files folder – but the cache and all the other moving parts are thrown into the user’s profile and carried around with them.

Let’s run through this process just for posterity (we have assumed an x64 target system – if you’re on x86 the filesystem and Registry paths will be slightly different).

Teams installer is run with switches

Files are written to c:\Program Files (x86)\Microsoft\Teams

Registry value written at HKLM\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Run that points to c:\Program Files (x86)\Microsoft\Teams\current\Teams.exe

Shortcut written to c:\Users\Public\Desktop that also points to c:\Program Files (x86)\Microsoft\Teams\current\Teams.exe

Shortcut written to C:\ProgramData\Microsoft\Windows\Start Menu\Programs

Uninstall entry written into Programs and Features or Apps and Features

Once this has completed, the next stage of “installation”, as it is, is triggered when the user logs onto a device that has the Machine-Wide Installer on it.

  • User logs on
  • Registry value in HKLM starts Teams.exe from the Program Files folder
  • Approximately 10MB of files are created in %APPDATA%\Microsoft\Teams
  • User is prompted for sign-in (or sign-in happens via pass-through)
  • Teams UI launches and begins initial setup
  • A further 5GB (approximately) of files are created within the user profile (most of which are deleted as part of this stage), session resource consumption spikes

Once initial setup and sync is completed (dependent on user setup), Teams is now fully “installed” into the user’s profile and this process will not need to be run again, as long as other devices the user accesses have the Teams Machine-Wide Installer and are using the same profile. Approximately 700-900MB of space in the profile is consumed by Teams data once this is completed (dependent on environment – this may be higher).

If you uninstall Teams, this simply removes the Machine-Wide Installer from the device – but what it also does is remove the executable that the users use to launch Teams (as well as the shortcut in %ALLUSERSPROFILE% that points to it). So despite having it still in their user profile, there’s no way for them to actually run the Teams client. However, it does mean that if they log onto a machine that does have the Machine-Wide Installer on it, they will not need to go through the first-run setup for a second time.

Teams does leave some remnants behind – mainly some device-specific filesystem entries

and a few logs and other folders in the profiles of users who may have launched Teams. As mentioned earlier, it is up to you whether to keep the profile-based entries (so that a user does not need to run the initial setup again), or to remove them entirely (usually would be done if you are trying to fix a Teams-related error that is tied to the user).

You can clear all this stuff up manually, or you can use some of the cleanup scripts that are out there (CTA Manuel Winkel has a good one here).

One final note to make about installation is that when you upgrade to a new Teams version, you must uninstall the old version fully before installing the new one. If you start every new build with a brand new image, then this isn’t an issue, but if you are simply making changes to an existing golden image (like you often would with MCS or PVS), then you need to be aware of it. Make sure in this situation you fully remove the old Machine-Wide Installer and do all necessary cleanup before installing the updated version.

Auto-setup and auto-launch

I’m going to refer to the automatic “first run” of Teams that triggers the initial setup as “auto-setup”. Auto-setup is a pain, for reasons you can probably guess. If you install the Machine-Wide Installer widely onto an estate, and then have thousands of users logging in the next day and launching Teams for the first time – that initial “burst” of resource utilization can cause a big problem.

Of course, as Citrix or RDSH admins, our first instinct is to disable the auto-setup from running so we can get a handle on it. If the users can launch Teams from the desktop or Start Menu shortcuts, then surely it is better to allow them to choose “when to launch Teams for the first time”?

If you go a-Googling, then there are immediately two methods of disabling the auto-setup that spring out:-

Use a switch with the command-line installer that blocks the auto-setup

Or, edit the setup.json file that sits in the Program Files (x86) folder, so that it no longer has the auto-start flag set (the PowerShell below changes this setting)

There’s one small problem with both these methods, though – neither of them works. When you log into an instance that has been configured with either of the above methods, Teams still launches the auto-setup routine.

The auto-setup is driven by the entry pointing to Teams.exe which sits in HKLM. When this program runs, auto-setup is started (if the user hasn’t used Teams before), or the Teams client starts (if the user has already done the auto-setup step).

So can we just delete the HKLM entry and have done with it that way?

Well, yes, but with a significant caveat. The problem is that once auto-setup has been run, on subsequent logons, the auto-launch (so not the first-time setup, but the automatic launch of Teams for a user who has already done the auto-setup step, which we will refer to as auto-launch from hereon in) is also driven by the HKLM Registry value. So if you delete the HKLM Registry value so that users trigger the auto-setup step themselves, then the users will have to remember to manually launch Teams every time they log in. This isn’t ideal – apps like Teams are good to get auto-launched, because otherwise users may miss important conversations and messages. And don’t forget – there is no option in the user interface to auto-start Teams with the Machine-Wide Installer. The “user” version of Teams (the one that auto-updates, which we don’t want to use) has the option to auto-start in the GUI…

…but the Machine-Wide Installer has that option removed, as you can see below

Now, our requirements appear to be thus – we want to disable the auto-setup, so that new users don’t all launch Teams at once and hammer the system resources, but once they have launched Teams for the first time, we want the program to auto-launch so they don’t have to run it manually. There is a way to do this – but first, I’m going to go off on a bit of a tangent, because it ties together with what we are going to do, so bear with me.

Open minimized to notification area

Teams does, both in the user and Machine-Wide Installers, have the option to “open application in background”. This means that it will launch minimized to the notification area rather than opening up full-screen. I think this is an important feature. You don’t want users logging on to shared meeting-room devices, for instance, and a confidential or embarrassing Teams conversation flashes up on the screen for all to see.

Obviously, there is the option in the user interface to enable this functionality…

This setting correlates to an entry in a user-based configuration file, %APPDATA%\Microsoft\Teams\desktop-config.json. There is a property in this file called openAsHidden which will be set to true or false dependent on the option you have selected in the GUI.

Of course, like all things Teams, there’s a problem with this. In that, it literally just ignores the setting in the UI and just opens up full-screen anyway. Way to go, Microsoft! Arbitrarily ignoring user-selected settings that could have potential security risks attached – priceless.

So as well as getting rid of the auto-setup but keeping the auto-launch, we also want to force Teams to actually honour the setting for openAsHidden from the GUI.

GPOs?

“Isn’t there a GPO for handling this?” Well, there is. There is one solitary GPO for Teams, and it looks really promising – just read the description

In my testing, however, this GPO doesn’t do anything. I made sure I applied the GPO before Teams was installed (as per the description), but it still launches automatically at first logon. Talk about a disappointment!

Solving it

We need to do three things, as we’ve already laid out – disable auto-setup, enable auto-start once the setup is triggered manually by the user, and also make sure that the openAsHidden flag is actually respected. How can we do this?

You need to do a bit of conditional Registry editing, so I’d use Group Policy Preferences, Workspace Environment Management, Ivanti User Workspace Manager, or any one of the myriad tools out there that can manipulate the user Registry based on certain parameters. For this example we’ve used GPP as everyone has access to that – tweak as required for your own solution.

I set up a Group Policy Preference Registry item that writes an HKCU Run entry pointing to Teams rather than HKLM (make sure you do not use Wow6432Node in the path – HKCU does not execute the Wow6432Node Run entry, if it exists)

  • Action – Replace
  • Hive – HKEY_CURRENT_USER
  • Key path – Software\Microsoft\Windows\CurrentVersion\Run
  • Value name – Teams Auto Start
  • Value type – REG_EXPAND_SZ
  • Value data – (below so can be copied better)

Also, use “Run in logged-on user’s security context” in the Common tab, and an Item-Level Targeting scoped as below

Also, alongside this configure a second GPP Registry item, this time as below

  • Action – Delete
  • Hive – HKEY_CURRENT_USER
  • Key path – Software\Microsoft\Windows\CurrentVersion\Run
  • Value name – Teams Auto Start

Again, use “Run in logged-on user’s security context” in the Common tab, and an Item-Level Targeting scoped as below

Update – if you’re using the pre-staging technique from the second article in this series, you need to use a file other than desktop-config-json to indicate that Teams has already been run. I recommend changing the GPP Item-Level Targeting filters above to look for a folder, %APPDATA%\Microsoft\Teams\Cache, instead of the JSON file.

Update 2 – if you’re using FSLogix Office Containers with the Teams data captured into the container, the Teams auto-start won’t work properly, because the Office container may not be mounted when Group Policy processing is done at logon (and henceforth it will delete the HKCU entry because it thinks the Cache folder doesn’t exist). If you are using Office365 Container for Teams (this won’t affect Profile Container though), you need to remove the second GPP entry, the one that does the Delete if the Cache folder isn’t there. However, what this means is that when your users run Teams for the first time, they will need to stay logged in long enough for a Group Policy refresh to occur and write the auto-start entry. Most users generally stay logged in for at least a single refresh cycle to occur, but if you think they might not, then you can add a conditional Scheduled Task to simply run a gpupdate early on in their first logon session,

Hopefully you see what we are doing here. The HKCU entry is only created when the desktop-config.json file exists (which means auto-setup has been run manually by the user). If the json file does not exist, the HKCU entry is cleared. The additional arguments on the executable – –process-start-args “–system-initiated” – ensure that the openAsHidden property is properly respected. If you’re not bothered about it opening minimized, then just set the HKCU Run entry to simply “%ProgramFiles(x86)%\Microsoft\Teams\current\Teams.exe”

What a palaver! Let’s summarize this Teams installation and config process:-

  • Always use the Machine-Wide Installer
  • Always install with the ALLUSER and ALLUSERS switches
  • Delete the HKLM Run entry that Teams drops into the Registry
  • Apply the Registry entries mentioned above through GPP, WEM, UWM, etc.

Now, if all this seems like a great big pain in the proverbials my fellow CTP and Teams wrangler Rene Bigler pointed out something that may be of interest. Over at Master Packager (www.masterpackager.com) there is a custom installer file where they have modified it so it can be installed everywhere, it removes the desktop shortcut, disables auto-setup and removes the Modify option. You can find it at the following link – https://www.masterpackager.com/blog/mst-to-install-microsoft-teams-msi-vdi-to-regular-windows-10

Another point to mention is that the Teams Machine-Wide Installer is meant only to be used on “VDI” platforms (VDI being used in the loosest possible terms). This is why at the start I said that the VDA must be installed before installing Teams. The Machine-Wide Installer is supposed to run only on Citrix, VMware Horizon and Windows Virtual Desktop and performs some checks to make sure it is in one of these environments otherwise it will fail with the error below

Of course, this makes it problematic if you’re using one of the other virtualization technologies out there (Parallels maybe), or if you want to package or layer your Teams install using some kind of application installer technology (App-V, AppVolumes, App Layering, Cloudpaging, etc.) I can’t speak for VMware Horizon or WVD, but if you need to trick your Teams Machine-Wide Installer into running on a non-VDI platform, simply create the following Registry key prior to running the installer so that you make it think it is running on Citrix

HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA

With this in place, you should be free to do what you want with the installer (or you could just avoid this and use the Master Packager version where they’ve already fooled it for you).

If you’re using the 1906 or 1909 version of the Citrix VDA, you may get issues with Teams crashing. Create a DWORD value in the following path – HKLM\SOFTWARE\Citrix\CtxHook\AppInit_Dlls\SfrHook\Teams.exe – and set it to 204 to resolve.

Finally, make sure you update Teams as often as possible. New versions come, even to the Machine-Wide Installer, a couple of times a month. If you want to keep on top of new features for your users you will need to keep an eye out for new updates to the binaries, and remember what I said – unless you are starting with a fresh base image every time you update, fully uninstall the old Teams version before installing the new one.

Summary

So there you have it – what a finickety application to have to try and deliver!

Bear in mind that Teams changes regularly, so that anything in this article could become out-of-date at any time – certainly my previous Teams article is now redundant. At time of writing, though, this all tested and worked as described.

The next part of this, where we will talk about session performance and the mysteries of the json files that drive Teams, will probably drop in a couple of weeks as I have part #3 of my logons series to publish first (contain your excitement!) Stay tuned!

 22,907 total views,  19 views today

Sours: https://james-rankin.com/articles/microsoft-teams-on-citrix-virtual-apps-and-desktops-part-1-installing-the-damned-thing/

Teams for Virtualized Desktop Infrastructure

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 Azure Virtual Desktop, Citrix, and VMware platforms, calling and meeting functionality is also supported.

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.

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 Azure 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.

Azure Virtual Desktop

Azure Virtual Desktop provides AV optimization for Teams on VDI. To learn more and requirements and installation, see Use Teams on Azure 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 are 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 are 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.

ParameterWorkstation operating systemServer operating system
vCPU2 cores4,6, or 8
It's important to understand the underlying non-uniform memory access (NUMA) configuration and configure your VMs accordingly.
RAM4 GB512 to 1024 MB per user
Storage8 GB40 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:\Users\username\AppData\Local\Microsoft\IdentityCache (%localAppdata%\Microsoft\IdentityCache)
  • C:\Users\username\AppData\Roaming\Microsoft\Teams (%appdata%\Microsoft\Teams)

Note

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-addin\Cache (%appdata%\Microsoft\Teams\meeting-addin\Cache)

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

  1. Download the Teams MSI package that matches your VDI VM operating system using one of the following links:

    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.)

  2. 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 adds a required registry key to the machine that lets the Teams installer know it is a VDI instance. Without it, the installer will error out, stating: "Installation has failed. Cannot install for all users when a VDI environment is not detected."

      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.

  3. 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.

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.

Diagram showing Teams on VDI 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:

  1. In the left navigation of the Microsoft Teams admin center, go to Users.
  2. Select the user by clicking to the left of the user name, and then click Edit settings.
  3. Do the following:
    1. Under Calling policy, click DisallowCalling.
    2. Under Meeting policy, click AllOff.
  4. Click Apply.

To assign a policy to multiple users at a time:

  1. 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.
  2. In the (check mark) column, select the users. To select all users, click the ✓ (check mark) at the top of the table.
  3. Click Edit settings, make the changes that you want, and then click Apply.

Or, you can also do the following:

  1. 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.
  2. Select Manage users.
  3. 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.
  4. 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:

  1. In the left navigation of the Microsoft Teams admin center, go to Users.
  2. Select the user by clicking to the left of the user name, and then click Edit settings.
  3. Do the following:
    1. Under Calling policy, click AllowCalling.
    2. Under Meeting policy, click AllOn.
  4. Click Apply.

To assign a policy to multiple users at a time:

  1. 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.
  2. In the (check mark) column, select the users. To select all users, click the (check mark) at the top of the table.
  3. Click Edit settings, make the changes that you want, and then click Apply.

Or, you can also do the following:

  1. 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.
  2. Select Manage users.
  3. 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.
  4. 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_MACHINE\SOFTWARE\Microsoft\Teams\DisableFallback
  • HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Teams\DisableFallback

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.

Disable audio and video settings for VDI

Teams VDI policies are available in the Microsoft Teams module. These policies are active and enforced on non-optimized VDI environments.

  • New-CsTeamsVdiPolicy
  • Grant-CsTeamsVdiPolicy
  • Remove-CsTeamsVdiPolicy
  • Set-CsTeamsVdiPolicy

Note

This is only for non-optimized environments.

Update a module name

update-Module -Name MicrosoftTeams -AllowPrerelease

Set policies to limit calling features

When users with this VDI Policy setting -DisableCallsAndMeetings $true to sign in to Teams on VDI, they shouldn't be able to:

  • Make calls.
  • Join meetings.
  • Do a screen share from chat.

All types of calling should be disabled.

Note

This is only for non-optimized environments.

When users with the VDI Policy setting -DisableAudioVideoInCallsAndMeetings $true sign in to Teams on VDI, they should be able to:

  • Do a screen share from chat.
  • Join a meeting and share a screen. Move their audio to a phone.
  • Users shouldn't be able to do a person-to-person audio and video call from VDI.

Note

This is only for non-optimized environments.

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.
  • Azure Virtual Desktop doesn't support macOS and Linux-based clients at this time.
  • Fast tenant switch can result in calling-related issues on VDI such as screen sharing not available. Restarting the client will mitigate these issues.

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)
  • PSTN call ringback tone
  • Shared system audio/computer sound
  • Media bypass for Direct Routing
  • Call park
  • Zoom control

Note

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.
  • Incoming and outgoing video stream resolution is limited to 720p resolution.
  • 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.
  • Live events are not optimized.
  • 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
    • 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_MACHINE\SOFTWARE\Citrix\CtxHook\AppInit_Dlls\SfrHook\Teams.exe

Then, restart VDA. To learn more, see this Citrix support article, Troubleshooting HDX optimization for Teams.

Related topics

Sours: https://docs.microsoft.com/en-us/microsoftteams/teams-for-vdi
  1. Homebrew launcher switch
  2. Fakaza mp3 download 2020
  3. Foods pizza nantucket

Teams won't launch as a Citrix published app

I previously had Teams installed on my orgs Citrix farm and working on all 8 servers. 

cmd used: 

msiexec /i "\\server\Microsoft\365\Teams\Teams_windows_x64.msi" /l*v c:\temp\TeamsInstall.log> ALLUSER=1 ALLUSERS=1

 

Unfortunately because our IT department was the only one with Teams at the time, no one really used it from Citrix once it was tested successfully (we used the desktop install or mobile). Months went by and we were getting ready to deploy Teams to the rest of the organization, and when we went to test Teams in the Citrix farm and though it would initiate the launch, it never actually opened. First the Citrix progress window would come up, then the Teams splash screen would come up saying it was installing, but then disappeared after about 30 seconds. The version was a little older, so I uninstalled Teams, then the Teams Machine-Wide Installer, then tried the same process I had done before that worked successfully, but I had the same end result.

 

If I log into the Citrix desktop, Teams launches just fine. What am I missing??

Sours: https://techcommunity.microsoft.com/t5/microsoft-teams/teams-won-t-launch-as-a-citrix-published-app/td-p/2594439
Work Your Way: Citrix Workspace + Microsoft Teams Integration

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 AppData\Local\Microsoft the user’s profile. The installation is triggered by Teams.exe process via registry, which can be found here:

For copy/pasting:
HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run

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_USER\Software\Microsoft\Windows\CurrentVersion\Run

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 AppData\Local\Microsoft\Teams\stage 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_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run

We need the data in the value “TeamsMachineUninstallerLocalAppData”, this string will uninstall Teams per-user, in the user’s profile.
For copy/pasting:
%LOCALAPPDATA%\Microsoft\Teams\Update.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%\Microsoft\Teams\current\Teams.exe” exists and another filter condition which is checking to see if “C:\Program Files (x86)\Microsoft\Teams\current\Teams.exe” exists. The “C:\Program Files (x86)\Microsoft\Teams” 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)\Microsoft\Teams” 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_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run

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 AppData\Roaming\Microsoft\Teams\Service Worker\CacheStorage 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 AppData\Roaming\Microsoft\Teams\Service Worker\CacheStorage 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 “AppData\Local\Microsoft\Teams\current\resources\locales” apparently breaks the system tray menu
.
Excluding “AppData\Local\Microsoft\Teams\Current\Locales” apparently breaks SSO to Teams.

Do not add the folders with a strikethrough. If you do, test, test, test!

Exclusions:
AppData\Local\Microsoft\Teams\Packages\SquirrelTemp
A

AppData\Roaming\Microsoft\Teams\Service Worker\CacheStorage
AppData\Roaming\Microsoft\Teams\Application Cache
AppData\Roaming\Microsoft\Teams\Cache
AppData\Roaming\Microsoft\Teams\Logs

AppData\Roaming\Microsoft\Teams\Media-Stack
AppData\Roaming\Microsoft\Teams\*.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 AppData\Roaming\Microsoft\Teams\Media-Stack should be excluded and the same goes with AppData\Roaming\Microsoft\Teams\*.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_USER\Software\Microsoft\Office\Outlook\AddIns\TeamsAddin.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.

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.

Sours: https://virtualwarlock.net/microsoft-teams-in-citrix/

Citrix teams

image

Good news, after a long time coming, Microsoft Teams calling and meetings (audio, video and sharing) are now available on VDI (Virtual Desktop Infrastructure) with Citrix.

Microsoft Teams chat and collaboration has been supported in VDI for a long time, and now with the Citrix platform, calling and meeting functionality are also supported.

Audio, video and sharing are handled via WebRTC on the Citrix platform. VDA-side HDX services use an API to interface with the Microsoft Teams hosted app to receive commands. These components open a control virtual channel (CTXMTOP) to the Citrix Workspace app-side media engine. The VDI endpoint decodes and renders the multimedia locally. The video/sharing is “snapped” to the local Microsoft Teams VDI client.

Citrix Virtual Apps and Desktops requirements

Citrix Virtual Apps and Desktops (formerly known as XenApp and XenDesktop) provide AV optimization for Teams on VDI.

You can download the latest version of Citrix Virtual Apps and Desktops here. (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.

Recommended version – Citrix Workspace app 1911 for Windows and Minimum version – Citrix Workspace app 1907 for Windows:

image

Microsoft Teams Requirements

The minimum version of the Teams desktop app that’s required is version 1.2.00.31357.

Some limitations/considerations

  • Windows Thin clients only, not Mac or Linux.
  • 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.
  • Only one video stream OR screen share stream is supported. When there’s an incoming screen share, that screen share is shown instead of the remote user’s video.
  • Screen sharing from VDI is supported, but you must share the whole screen, sharing only specific application windows is not supported.
  • Give control and take control of screen sharing is not supported. Giving remote control of a PowerPoint is supported.
  • Incoming and outgoing video stream resolution is limited to 720p resolution.
  • With VDI per-machine installation, the Microsoft Teams client app isn’t automatically updated in the way that non-VDI Teams clients are. You have to update the VM image manually with the latest MSI on a regular basis.

These calling and meeting features are not supported:

  • Enhanced emergency services
  • HID buttons and LED controls between the Teams app and devices
  • Background blur and effects
  • Broadcast/live events
  • Location-Based Routing (LBR)
  • Call park
  • Call queue

Microsoft is now working on adding these features.

Be sure to subscribe to my bi-weekly Microsoft Teams email update for the latest news at these features are added.

 

References/more information:

Microsoft Documentation: Microsoft Teams for Virtualized Desktop Infrastructure

Citrix: Optimization for Microsoft Teams

Video Demo here

citrixMicrosoftTeamsvdi

Sours: https://tomtalks.blog/2019/12/microsoft-teams-and-citrix-virtual-desktop-infrastructure-vdi-certified-support-for-calling-and-meetings/
Transform Employee Experience with Citrix Workspace and Microsoft Teams

So, let’s do part #3 of a series on Teams. Mainly, around some actions you can take to help optimize the performance for your user base!

When we are discussing optimizing Teams, what most admins and users are interested in is performance in audio, video, screen sharing, calling and remote control situations. The other features of Teams – chat and document sharing – is generally not a pain point. It’s only when the functions move into audio/visual territory, and the hardware that accompanies this, that the brown stuff really hits the fan.

Free Video Chat and Collaboration | Microsoft Teams

Microsoft Teams

I’m sure we all know what Teams is by now, no introductions required! 🙂

When using Windows Server RDSH instances/Windows 10 Multi-User instances and/or Windows client VDI instances, there are implications for performance and user density given the shared nature of RDSH/Win10 MU platforms, and/or the shared resource nature of Windows client VDI. Ensuring that all users have an optimal experience that does not impact other users on the shared platform and/or shared hypervisor fabric is of paramount importance. The following key points should allow Teams to operate in an optimal mode that provides the best user experience.

Set user expectations

It is important to note that there is a noticeable discrepancy between the traditional “desktop” version of Teams and the “VDI” version of Teams that is commonly used in RDSH or virtual desktop environments. Feature parity lags quite starkly between the two, with the “VDI” version the poorer relation.

Features such as “background blur” and the Gallery View are commonly called out by users who move to the VDI version of Teams and are already familiar with the desktop version. Unawareness of these limitations can often convince the users that Teams is “broken” and lead to helpdesk calls.

Setting the user expectations around what is possible or limited within the VDI version of Teams can help to head off these issues. Citrix publish a roadmap of CVAD features that can sometimes provide an insight into when Teams features will “catch up” with the desktop version. It can be useful to share this either with users or support personnel (https://www.citrix.com/en-gb/support/citrix-virtual-apps-and-desktops-roadmap.html)

Key action #1 – set user expectations as to differences between the desktop and VDI versions of Teams, provide roadmap to support this

User self-help

Many problems that users encounter within Teams can be resolved by learning some basic troubleshooting techniques. Exiting Teams correctly by right-clicking the notification area icon and choosing “Quit” can help with many issues.

Encouraging users to check that their devices are detected correctly is another way you can enable users to head off potential service desk calls. If they are not, exiting Teams correctly in the way described above will often resolve the issue.

Key action #2 – educate users in basic Teams troubleshooting, with supporting documentation as necessary

Session disconnections

It is also worth noting that when users disconnect sessions rather than logging out, the Citrix HDX virtual channel that handles Teams can disconnect and not re-establish properly. Around this, it can be useful to set up robust timeout and disconnection policies to prevent users from experiencing this issue. There are a number of factors to consider when deploying these policies, namely around understanding how users make use of the system, and this understanding will drive the policies that you implement. A thorough discussion of disconnection and timeout policies within RDSH or VDI environments is provided here – https://4sysops.com/archives/securing-timeouts-in-remote-desktop-session-host-rdsh-and-virtual-desktop-infrastructure-vdi-environments/

Key action #3 – implement suitable timeout and disconnection policies within the customer environment

Teams installation and configuration

Installation

We already covered this in part #1 of this series, but lets reiterate that it is crucially important to install Teams correctly for the environment. The deployment command line will vary depending on whether you are using RDSH/non-persistent VDI, or fully persistent VDI.

If the installation is not done correctly and a mix of desktop and VDI versions is allowed to proliferate, or even a mix of individual VDI versions on shared systems, users will experience high levels of Teams instability and errors.

For RDSH or other non-persistent, the following command must be used for installation:-

msiexec /i <path_to_msi> /l*v <install_logfile_name> ALLUSER=1 ALLUSERS=1

For persistent VDI, the following command must be used:-

msiexec /i <path_to_msi> /l*v <install_logfile_name> ALLUSERS=1

The first command, which is the most common one to use, disables the automatic update feature and is crucial to maintaining control within virtual environments with an administrator-managed image.

Key action #4 – ensure that Teams installation is done correctly dependent on the environment

First-run configuration

It is also prudent to disable the automatic first run of Teams to prevent a storm of resource utilization when Teams is initially deployed. However, once it is run user-initiated for the first time, it is also prudent to then allow it to automatically launch for every user session thereafter.

This cannot be configured using GPOs or command-line switches, contrary to what it may say in Microsoft documentation or online guides. The ideal way to configure this is by following these steps:-

  • Delete the HKLM Run key for Teams from the golden or master image
  • Create a Group Policy Preference, WEM config item or other method that creates a conditional Registry value in the user profile (details in next point)
  • Creates a HKCU\Software\Microsoft\Windows\CurrentVersion\Run entry that calls the following command line (C:\Program Files (x86)\Microsoft\Teams\current\Teams.exe” –process-start-args “–system-initiated”) but ONLY when the following folder exists (%APPDATA%\Microsoft\Teams\Cache)

For a full rundown of the installation and first-run config, see part #1 of this series.

Key action #5 – remove auto-start, configure Registry settings to disable first-run storm

Pre-staging options

Again, this was covered in more detail in part #2 of this series, but we’ve put a summary here just for posterity.

Microsoft recommend that the option to “disable GPU acceleration” within Teams is enabled for non-GPU workloads and disabled for GPU workloads. In order to set this appropriately without user intervention, it is recommended to “pre-stage” a JSON file within the default user profile in the master image that matches the requirements of the workload.

This can be done by creating a file within the master image at c:\users\Default\AppData\Roaming\Microsoft\Teams called desktop-config.json which has the following format (changed to match the workload requirement)

disableGPU should be set to true for non-GPU workloads and false for GPU-enabled workloads. Other settings can be pre-configured here as required, although some of them do not take properly (RegisterAsIMProvider is a particularly troublesome setting).

Key action #6 – pre-stage a JSON file into the master image to optimize base user settings as required

Teams HDX optimization

For shared systems (whether sharing the actual VM resource or the underlying hypervisor resource), Teams optimization is the most crucial setting to enable. Citrix HDX optimization allows the Citrix virtual channel to “offload” Teams audio and video traffic to the connecting endpoint, removing the impact to CPU and other VM resources that is commonly observed when using audio and video calling features.

In order to enable Teams optimization, a number of pre-requisites must be checked.

Connecting client specs

The following table details the recommended client specifications:-

Device classSpecifications and notes
Windows clientWindows 7, Windows 8, Windows 8.1 or Windows 10 1607+
4GB RAM+
x86 or x64
2.2Ghx+ dual-core CPU or 1.5Ghz+ quad-core CPU with boost up to 2.4Ghz
Windows thin clientHP t360/t640, t730/740 or mt44/mt45
Dell 5070 or 5470
10Zig 4510 and 5810q
Full list here – filter by Thin Clients and MS Teams Optimized Windows 10 IoT Enterprise 2016 or 2019
MacOSmacOS Catalina (10.15)
Linux clientx64 Linux distribution
2.2Ghx+ dual-core CPU or 1.5Ghz+ quad-core CPU with boost up to 2.4Ghz
GStreamer 1.0 or later or Cairo 2
libcc++9.0 or later
libgdk 3.22 or later
OpenSSL 1.1.1d
Linux thin clientHP t360/t640, t730/740 or mt44/mt45
Dell 5070 or 5470
10Zig 4510 and 5810q
Full list here – filter by Thin Clients and MS Teams Optimized x64 Linux distribution
ChromebookChromeOS v50 or later
AndroidNo optimization currently possible
iOSNo optimization currently possible

Citrix client specifications

In addition to the requirements specified above, there is also a minimum Workspace App (Citrix client) version that must be present for offloading to be possible. The required and recommended versions are detailed below.

Device classVersions
Windows client (Windows 8 and higher)Citrix Workspace App 1907+ (minimum)
Citrix Workspace App latest n-1 (recommended)
Windows client (Windows 7)Citrix Workspace App 1907+ (minimum)
Citrix Workspace App 2002 (recommended – any higher not supported)
Windows thin clientCitrix Workspace App 1907+ (minimum)
Citrix Workspace App latest n-1 (recommended)
MacOSCitrix Workspace App 2009+ (minimum)
Citrix Workspace App latest n-1 (recommended)
Linux clientCitrix Workspace App 2006+ (minimum)
Citrix Workspace App latest n-1 (recommended)
Linux thin clientCitrix Workspace App 2009+ (minimum)
Citrix Workspace App latest n-1 (recommended)
ChromebookCitrix Workspace App 2105+ (minimum)
Citrix Workspace App latest n-1 (recommended)
AndroidNo optimization currently possible
iOSNo optimization currently possible

Teams client version

There is also a required Teams version that must be in use in order for optimization to be possible. The minimum is 1.2.00.31357, but again, it is recommended that the latest possible “VDI Installer” or “Machine Installer” of Teams is applied to the target Citrix devices. This should be updated as regularly as possible.

Key action #7 – ensure Teams client versions, Workspace app versions and connecting client specifications meet the requirements stated

Citrix infrastructure versions

The latest Citrix VDA should be applied to the target devices to take advantage of Teams enhancements that may be incorporated into the VDA itself. There are also requirements around the Citrix DDC versions that must be met. However, these points introduce a further discussion – namely, Current Release (CR) versus Long Term Service Release (LTSR).

Citrix VDA version

The minimum VDA version required is 1906.2 for CR, and 1912 for LTSR. However, it is recommended that the latest possible VDA version is applied (for CR) or the latest possible Cumulative Update (CU) (for LTSR). Additionally, the VDAs must be running Windows 10 1607+, or Windows Server 2012 R2+, in order to support Teams optimization.

DDC version

The Citrix DDCs (Desktop Delivery Controllers) must also be at a version of 1906.2+(CR) or 1912 (LTSR) to support Teams optimization features.

CR or LTSR

Citrix have a CR schedule in which updates to the core infrastructure components appear quite regularly (often quarterly). LTSR, on the other hand, putatively states that these versions can stay in a supported configuration for up to five years.

However, this is somewhat misleading. LTSR versions are supported as long as customers remain two cumulative updates or less behind the current CU release, and CR versions continue to be supported within two releases of the current latest version. In real terms, this means that the support window for LTSR is approximately two years, and that for CR the window of support can extend for approximately 18 months. Given that CR allows easier and quicker deployment of new features as they become available, which is particularly relevant to Teams optimizations, and the achievement of feature parity between the desktop and VDI Teams versions, it is clear that adopting the CR method is more desirable when it comes to a quality Teams experience.

Key action #8 – adopt the CR model where possible (n-1 from latest release recommended), or ensure that LTSR model remains up-to-date with Cumulative Update releases (currently latest CU at time of writing is CU3 which means minimum supported version would be CU1)

Updating client devices

In many environments, updating the Workspace App version on the endpoints can be difficult, particularly where the customer has embraced “Bring Your Own Device” initiatives, or if third parties are connecting to the solution. Ideally, devices should run the Workspace App with the auto-update feature enabled, but this is not always possible in every situation.

To mitigate the risks posed by this, there are a few considerations that are worth thinking about.

Old Citrix infrastructure

It is important to check for old Citrix infrastructure that might mandate an older Citrix client, such as old NetScaler instances, legacy Storefront or Web Interface, and/or older Citrix farms. Often these older instances can force users into having to use an older Citrix client, commonly the 4.9 Receiver version which is still updated by Citrix because of its wide install base.

If these situations exist, there are two choices:-

  1. Accept that these users will have to run without Teams optimization, and either decrease user density to cope, silo these users, or disable resource-intensive Teams functionality (see Teams fallback mode, discussed later)
  2. Apply a workaround to allow users to access multiple Citrix client versions. This can be achieved using FSLogix, but this is an unsupported configuration and will require detailed testing

Key action #9 – validate whether older clients are required, and implement a solution if this is found to be the case

Warning for unoptimized users

It is possible to configure a “nag” alert that will warn users that they are on an older Citrix client version. Scripts are available that will alert the user if they are at a client version older than a certain defined level, and can advise them to download the newer version or contact support.

The script runs via PowerShell so there may be security constraints which could affect the viability of this solution, however there are options such as converting it to an executable which may make it more viable.

CTA Dennis Mohrmann provides the script that can do this which is linked here. We are going to do a separate post running through using this in the very near future. Dennis also has a script to check optimization status but this runs every time a Teams process spawns – we’ll talk more about that too in the dedicated article.

Other options around checking the client version exist, such as using ADC Endpoint Analysis or other contextual posture checking. Dependent on what is available to the customer, this may also be worth investigating.

Key action  #10 – investigate the possibility of a posture check or nag on the connecting client version to reduce unoptimized sessions

HTML5 Receiver

Citrix have an option to use the HTML5 version of the Workspace App which runs embedded in the browser instead of using the full client. Some users find this useful, however it does not support Teams optimization and should be avoided.

Key action #11 – educate users on how to use the full client to launch their resources rather than the HTML5 version

Teams fallback mode

There is an option to disable what is known as “fallback mode”. This means that when optimization is unavailable, the connecting client “falls back” to using the resources on the VM they are connected to.

To reduce the impact that non-optimized users can have on other sessions, it is possible to selectively disable fallback mode so that they cannot launch resource-intensive tasks within Teams (such as audio and video calling). This is done by setting a Registry value either on a computer or user level. The available Registry values are listed below:-

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Teams\DisableFallback

HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\Teams\DisableFallback

Both values should be set as DWORD values and can be either 0 (fallback is enabled), 1 (audio and video are disabled for non-optimized users) or 2 (video is disabled for non-optimized users.

It is recommended that this is set to 1, so that the impact of unoptimized users is reduced, as well as encouraging them to contact support to resolve their problems with optimization failure.

Note – this feature is currently broken! I have a case open with Microsoft to try and allow it to work properly and will update when the case moves forwards.

Key action #12 – implement DisableFallback to reduce the impact of non-optimized users across the estate

Turn off incoming video

There is an option to “turn off incoming video” which can be used in meetings that seems to increase performance by an order of magnitude. We are currently exploring how this can be defaulted to “off” for users – it may be possible on a tenant level but we have not fully investigated this as yet.

Web client

Some people are keen to explore the use of the Teams web client rather than the full fat client, and then leverage Citrix features such as Browser Content Redirection to offload the traffic. This is not desirable on a number of levels. Firstly, the feature set is not complete. Secondly, using Browser Content Redirection to offload Teams is not straightforward and involves a lot of integration with authentication providers and security devices such as internet proxies. Finally, there are many entry points providing web client users with paths to install the “desktop” client version of Teams, and restricting this (because it is a user profile installer) is difficult and means using technologies like AppLocker or FSLogix App Masking. At this moment, it is not advisable to fall back to the web version of Teams in Citrix environments unless no other option is available. There may be a post forthcoming where we discuss how to use it as best as possible.

Profile management

Teams has a sizeable user cache which is written to very regularly. This means that managing the user profile under Citrix can be somewhat challenging.

VHD solutions

In order to manage the Teams cache effectively, it is important to adopt a “virtual hard disk” based method to management. This can be done either by capturing the entire user profile into a VHD, or simply the Teams cache itself.

There are three main solutions that can be used to capture the profile or individual caches into a VHD:-

  • FSLogix Profile Containers or Office Containers
  • Citrix User Profile Management with Profile Container feature
  • Ivanti User Workspace Manager

Dependent on the customer entitlements, any of these will suffice to capture the required data into a VHD and avoid the performance issues associated with older, file-based profile management systems.

FSLogix would be the recommended solution, as the entitlement is free with Microsoft365, Office365, Windows 10 licenses or RDSH CALs. If a different profile management solution is incumbent, the Office Container solution rather than the Profile Container can be used to complement the existing one.

If FSLogix cannot be used or the customer wish to leverage an existing solution, then Citrix User Profile Management and Ivanti User Workspace Manager both offer a method of capturing either the entire profile or the Teams cache folder into a VHD file.

Key action #13 – deploy a container-based VHD solution for profile management when using Teams

Exclusions

Again, this is something we’ve covered in detail in a previous post, but for completeness let’s mention it with the other optimizations. In order to minimize the storage footprint required, it is recommended, if possible, to exclude certain folders from the Teams cache. The most crucial folder to exclude from the capture is the following below:-

%APPDATA%\Microsoft\Teams\Service Worker\Cache Storage

This ensures that a total of 5GB per user is trimmed from the cache storage requirement at the first run of Teams.

I’d also recommend excluding the Teams processes from Citrix WEM CPU spike protection, if you are using this feature.

Key action #14 – configure profile exclusions as above

Maintenance

The trade-off with VHD file solutions is that they add state, rather than removing it. In order to keep the size of the VHDs down, it is recommended to run regular pruning and compaction on the cache stores. This can be configured to run offline using community scripts from a variety of locations. Again, we’re going to have a follow-up post about VHD maintenance – stay tuned!

Antivirus exclusions

Microsoft recommend that AV exclusions for Teams are configured to allow best performance. The following folders should be excluded from reactive AV and other security software suites such as HIPS, DLP, etc.

  • %userprofile%\AppData\Local\Microsoft\Teams\current\teams.exe
  • %userprofile%\AppData\Local\Microsoft\Teams\update.exe
  • %userprofile%\AppData\Local\Microsoft\Teams\stage\squirrel.exe

Key action #15 – configure AV exclusions as above

Network performance

Robust and performant network infrastructure is required to support Teams, particularly when using the audio and video calling features within meetings. The following metrics suggest thresholds for performance on a network level

There is a Microsoft tool called “Advisor for Teams” that will assess the suitability of network links which can be run prior to deployment. Technologies such as Citrix SD-WAN can also be used to increase performance.

Key action #16 – validate and track network routing and performance

Monitoring

It is recommended that monitoring on both a network, hypervisor and session level is put in place to help with continually trending, baselining and assessing Teams performance. Without these metrics, judgements on performance become subjective. The monitoring should encompass the entire “service” provided by the solution and be collated centrally for easy access by operations and executives alike.

Key action #17 – ensure appropriate monitoring is in place from the start

Summary

Microsoft Teams is a difficult piece of software to deploy virtually, given the ever-changing nature of the software and the fast update cadence. Microsoft can make changes on a tenant level which affect the layout and performance of the user interface, without any change being made on the customer end. This makes it a uniquely challenging application.

With good monitoring, solid controls, continuous development and appropriate management buy-in, it can be deployed in a manner which provides a reliable user experience. It must be reiterated, though, that this involves keeping on top of the deployment in a way that is possibly unfamiliar to operations teams.

Given the way that both the Teams client, the Citrix Workspace App, the Citrix VDA and Citrix infrastructure components must be regularly updated to keep pace with Teams feature developments, it is incredibly useful to start exploring the concept of “evergreen” installations and rolling rebuilds rather than maintaining a single golden or master image. When the Teams client is updated, it must be uninstalled fully prior to updating – it cannot be upgraded in place. This makes a rolling rebuild mechanism using technologies such as Terraform, Packer, Ansible, etc. much more desirable for Teams deployment than the traditional ways such as MCS, PVS or SCCM. Whilst it is appreciated that this is a big sea-change and not something many enterprises could undertake lightly, the shift towards infrastructure-as-code and a more devops-style deployment method would reap benefits in the longer term as more Office applications evolve to the same methodology as Teams.

Key action #18 – explore infrastructure-as-code and devops pipeline deployment methods

So there you have it – a whole list of possible things you can do to optimize your Teams experience on Citrix. of course, a lot of this we’ve covered already, but it seems useful to try and bring them together in a guide.

As I said, a lot of spin-off articles are hinted at here – they should be forthcoming pretty soon!

 6,978 total views,  6 views today

Sours: https://james-rankin.com/articles/microsoft-teams-on-citrix-virtual-apps-and-desktops-part-3-18-tips-for-optimizing-performance/

You will also like:

.



340 341 342 343 344