Browser Content Redirection (BCR) uses Citrix Workspace app to fetch and render web content, massively reducing CPU, GPU, RAM, and network consumption on the Desktop or Server VDA.
The Internet contains and delivers more multimedia content than ever before, particularly since Covid-19. A real-world example is the car sales industry whereby car dealerships are harnessing social media to sell their stock by way of videos.
Video content itself is also very much part of our daily lives whether it be watching YouTube videos, news clips, training videos, or video conferencing using Microsoft Teams.
Video content is also taxing on CPU first and foremost, so for a Citrix environment that may really impact the overall user experience for video playback amongst all the other activities.
Thankfully there is a solution which allows a business to offload that video to the endpoint itself using what we call Browser Content Redirection, which is available to all Virtual Apps and Desktops licensed customers whether on-premises or using Citrix Cloud. Simply, an extension is installed on to the VDA, and Workspace app as always will be on the client endpoint. When a website is enabled for BCR using an allow list controlled via Studio policies, and the user browses to that website:
A CTXCSB virtual channel informs Workspace app that redirection is required and provides the URL.
The viewport is redirected to the endpoint.
The endpoint fetches the content (optional) and renders it.
Then, the viewport is blended back into the virtual desktop seamlessly. The end-user will not necessarily know that it is their endpoint doing the fetching and rendering of the web content.
The viewport contains the main part of your browser window that shows the web page content itself, as shown below. The address bar etc is not redirected and remains on the VDA.
This is all achieved by the overlay browser (HdxBrowsercef.exe), a Chromium based browser built into Workspace app, and the Browser Content Redirection extension which runs on Chrome or the newer Chromium based Microsoft Edge.
BCR Scenarios
Server fetch and server render
This is basically how things work without BCR, or if you don’t add a site to the allow list. The Citrix VDA fetches and renders the webpage.
This equals to potentially high RAM and CPU consumption on the VDA, as well as network consumption.
Server fetch and client render
In this scenario, the CTXPFWD virtual channel is used by Workspace app to fetch webpage content through the VDA, and then the endpoint renders that content. This can be useful if the endpoint doesn’t have internet access, or if you want to ensure that any security policies/web filtering is still applied to those web resources.
This equals to network consumption on the VDA, but with low RAM and CPU consumption.
Client fetch and client render
Workspace app contacts the web server directly and renders the web content.
This equals to low CPU, RAM, and network consumption on the VDA for a better end-user experience.
Disabling fallback
As mentioned, the option of server fetch and server render is typically what you have whenever BCR is not used at all. However, if you have BCR configured for YouTube for example, and redirection of that URL to the endpoint fails for a reason such as internet not being available on the endpoint, you can disable fallback/prevent the VDA fetching and processing the web content by setting the Windows Media fallback prevention Citrix Studio policy to Play all content only on client or Playonly client-accessible content on client.
BCR Requirements
Windows Endpoints
Windows 10.
Workspace app 1809 for Windows or later. Note that Workspace app 1912 LTSR for Windows does not support BCR.
Linux Endpoints
Thin client terminals must include WebKitGTK+.
Workspace app 1808 for Linux or later.
Citrix
Virtual Apps and Desktops 7 1808 or later for Current Release.
XenApp and XenDesktop 7.15 CU3 or later for Long Term Service Release.
Desktop OS VDA running Windows 10 1607 or newer.
Server OS VDA running 2012 R2, 2016 or 2019.
For Google Chrome: v66 or later running on the VDA.
For Microsoft Edge: v83.0.478.37 or later running on the VDA.
Citrix Virtual Apps and Desktops 7 2109
Starting with VDA 2109, Citrix have changed the way in which JavaScript is injected into a webpage for BCR, resulting in an enhanced and simplified outcome.
BCR used to inject the HdxVideo.js JavaScript into BCR enabled webpages almost on the fly as it detected the need. This could sometimes cause issues and fail redirection if the JavaScript was not being injected quickly enough. Now, when a user visits a BCR enabled URL, that URL is redirected to blank HTML document that contains the running JavaScript, which then performs redirection. With this new approach, redirection is much more successful and has fixed some issues with redirecting certain resources that were having issues in previous releases.
Enabling and configuring BCR
Browser Content Redirection is enabled for YouTube by default. The main policy that enables BCR is Browser Content Redirection.
Further to this policy, the allow list, known as Browser Content Redirection ACL Configuration, is where you specify the URLs that you wish to be redirected.
As shown in the above screenshot, you can use a wildcard but not in the protocol or the domain address part of the URL.
Allowed:
http://domain.com/index.html
http://domain.com/*
http://domani.com/*index*
Not allowed:
http://*.domain.com
There are some additional policies relating to BCR:
Browser Content Redirection Authentication Sites – Not all websites are the same. Some websites redirect you to other URLs, especially when authentication is required. For example, when you visit https://teams.microsoft.com, you are redirected to https://login.microsoftonline.com to authenticate. From there, you could be redirected to an IdP or back to Teams. In such scenarios, we need to tell BCR to remain active (redirected) to allow the authentication (child sites) to be handled correctly by BCR.
Browser Content Redirection Blacklist Configuration – The blacklist takes precedence, and the web content will be fetched and rendered on the server, even if the same URL is added to Browser Content Redirection ACL Configuration. You can also use a wildcard here with the same rules as the ACL Configuration policy.
Browser Content Redirection Proxy Configuration – I mentioned the BCR scenario server fetch and client render earlier in the article. It is this policy you would use to configure the server fetch piece. With this policy you can specify an explicit proxy address, PAC/WPAD file address, or specify Direct/Transparent.
Direct/Transparent example: Type the word DIRECT into the policy text box.
XenApp and XenDesktop 7.15 Customers
Citrix backported BCR for those running with the 7.15 release of XenApp and XenDesktop. To use BCR, the following steps are required:
Install the VDA software using the command line and switch /FEATURE_DISABLE_HTML5.
This removes the HTML5 video redirection feature, which must be done before installing BCR.msi. BCS.msi adds the feature back during installation, along with adding the browser content redirection services.
Install BCR.msi
Confirm that the Citrix HDX HTML5 Video Redirection Service shows under services.msc.
Citrix Studio does not contain the BCR policies. Download the ADMX template for BCR from the Downloads page over at Citrix.
Installing the BCR extension on Google Chrome – Manual
To confirm Browser Content Redirection is working, visit a webpage that should be redirected and right-click within the viewport. If working, you will see a menu containing About HDX Browser Redirection.
Installing the BCR extension on Google Chrome – Group Policy
Firstly, download the Google Chrome ADMX files to your environment.
Open Group Policy and within a GPO browse to Computer Configuration > Policies > Administrative Templates > Google > Google Chrome > Extensions and double-click policy Configure the list of force-installed apps and extensions.
Click Enabled > Show and insert the following value, which makes up the BCR extension ID and auto-update URL:
Once Group Policy processing completes and the user launches Google Chrome, the extension will be installed. Any updates to the extension are automatically installed using the update URL you specified during Group Policy configuration. Extensions also reside in the user profile under %LocalAppData%\Google\Chrome\User Data\Default\Extensions.
Installing the BCR extension on Microsoft Edge – Manual
Click on the horizontal ellipsis and then Extensions.
Click Allow extensions from other stores followed by Allow.
Click on the Chrome Web Store hyperlink.
In the search box type Citrix, click on the Browser Redirection Extension tile > Add to Chrome>Add extension.
Installing the BCR extension on Microsoft Edge – Group Policy
With the Group Policy method, there is no initial requirement to enable the Allow extensions from other stores setting as required when manually installing the BCR extension.
Firstly, download the Microsoft Edge ADMX files to your environment.
Open Group Policy and within a GPO browse to Computer Configuration > Policies > Administrative Templates > Microsoft Edge > Extensions and double-click policy Control which extensions are installed silently.
Click Enabled > Show and insert the following value, which makes up the BCR extension ID and auto-update URL:
Once Group Policy processing completes the extension will be installed and will appear under installed extensions within Edge. Any updates to the extension are automatically installed using the update URL you specified during Group Policy configuration.
Extensions also reside in the user profile under %LocalAppData%\Microsoft\Edge\User Data\Default\Extensions.
Google Chrome Demo
Before
Very high CPU consumption on the VDA whilst playing a 4k video.
After
Low CPU and lower RAM consumption on the VDA whilst playing a 4k video.
On the client, CPU and RAM is being used instead by the Overlay Browser.
The Overlay Browser runs under the HdxBrowserCef.exe process.
Microsoft Edge Demo
Before
Very high CPU consumption on the VDA whilst playing a 4k video.
After
Low CPU and lower RAM consumption on the VDA whilst playing a 4k video.
On the client, CPU and RAM is being used instead by the Overlay Browser.
Final Thoughts
Since you are offloading media now to the endpoint, BCR is dependent on the endpoint being able to fetch (optional) and render that content efficiently.
You cannot turn BCR on for everything, there is no policy option for that.
Some websites will redirect you to other places and you may have to use Debugging Tools (F12) to understand what other URLs you need to configure in the ACL Configuration and Authentication Sites policies.
DPI scaling mismatch e.g. the VDA is set to 100% and endpoint set to 125%, causes the redirected browser screen to display incorrectly. If you can’t match DPI then there is a DWORD you can create on the endpoint which resolves this:
Since early 2020 there has been massive growth in the number of active Teams users and organizations deploying Teams, to now more than 200 million monthly active users across the globe.
With the increase of market share, it’s one of those applications that either you expect an organization to already be using or planning to deploy out to their environment sooner rather than later. This means that a lot of existing and also new Citrix Virtual Apps and Desktops Deployments are under scope for Teams deployment and consumption.
Multimedia processing however can quickly send the end user experience south. Play a simple video on any device and you will notice that CPU first and foremost takes a hit, but times that by multiple users at once across shared Hypervisors and you can start to imagine the impact it may have on your Citrix deployments and the end user experience.
Given that many people are working from home and therefore using Teams to host one-to-one or multi-party calls, we need to make sure that the video and audio quality delivered via Teams is great and VDI or Session Based users do not take a performance hit whenever audio and/or video calls are taking place.
To help achieve that, we can use HDX Optimization for Teams, jointly developed by both Citrix and Microsoft, to offload media processing to the endpoint itself.
If you are familiar with delivering Skype for Business using the HDX RealTime Optimization pack, you’ll be aware of the term Generic delivery. With generic delivery of Teams, the video and audio traffic “hairpins” from the user endpoint to the Citrix VDA and back to the endpoint, which degrades video and audio quality whilst placing high resource consumption load on the VDAs themselves.
Optimized delivery of Teams
HDX Optimization for Teams allows you to deliver 720p high-definition video calls at 30fps through your Virtual Apps and Desktops solution. This is made possible using the WebRTC media stack.
The optimized solution can be thought of as splitting the Teams client in two, with the user interface living inside of the VDA and the media rendering/engine running on the endpoint. This shifts resource consumption to the endpoint, reducing impact on your VDAs, and shapes the Teams audio and video traffic in a much more optimized fashion because now media traffic flows point-to-point between clients or the Teams conferencing service in Microsoft 365.
Other advantages of optimized Teams delivery:
Local peripherals such as your webcam and microphone will be automatically redirected into Teams.
Less HDX traffic will be consumed due to the way traffic is shaped with the optimized approach.
The solution is supported by both Microsoft and Citrix.
There is no modification needed to the Teams back-end, or any additional software pieces required to be installed on the VDA or endpoint, which is an improvement over the Skype for Business RealTime Optimization Pack.
Screen sharing is also possible and mentioned further in detail under section Screen Sharing.
HDX Optimization for Teams diagram and call flow
User launches Microsoft Teams.
Teams authenticates to Microsoft 365 and tenant policies get pushed down to the Teams client.
Relevant TURN and signalling channel information is relayed to the Teams app.
Teams detects that it is running on a VDA and makes API calls to the Citrix JavaScript API.
The Citrix JavaScript in Teams opens a secure WebSocket connection to WebSocketService.exe running on the VDA. WebSocketService.exe runs as a Local System account and listens on 127.0.0.1:9002.
WebSocketService.exe performs TLS termination, user session mapping, and spawns WebSocketAgent.exe which now runs inside the user session.
WebSocketAgent.exe initiates a generic virtual channel by calling into the Citrix HDX Browser Redirection Service (CtxSvcHost.exe).
Citrix Workspace app’s HDX Engine, wfica32.exe, spawns a new process called HdxRtcEngine.exe (or HDXTeams.exe before Workspace app 2009.6) which is the new WebRTC engine used for Teams optimization.
HdxRtcEngine.exe and Teams.exe have a 2-way virtual channel path and can start processing multimedia requests.
User A clicks to call User B. Teams.exe communicates with the Teams services in Azure to establish an end-to-end signalling path with User B.
Teams on the VDA asks HdxTeams (HdxRtcEngine) for a series of supporting call parameters such as codecs and resolutions, which is known as the Session Description Protocol (SDP) offer. These call parameters are than sent, using the established signalling path, to the Teams services in Azure and from there on to User B.
The SDP offer/answer and Interactive Connectivity Establishment (ICE) connectivity checks complete.
ICE connectivity checks (NAT and firewall traversal) complete using Session Traversal Utilities for NAT (STUN).
Secure Real-time Transport Protocol (SRTP) media flows between HdxRtcEngine.exe and User B.
If it is a meeting, SRTP media flows between HdxRtcEngine.exe and the Microsoft 365 conference servers.
Considerations, Known Issues, and Limitations
The advantages of being able to offload media to the endpoint and run Teams on VDI or Session Based VMs comes with some things you need to be aware of. Namely, there may be features and functionality available in Teams that are limited in a virtualized environment, which isn’t specific to Citrix deployments as such, but simply desktop and server virtualization as a whole.
There are also some known issues and limitations affecting Teams when deployed to VDI environments. Some examples are below, as of August 2021:
With Teams running on a Citrix session, if the user disconnects and then reconnects, Teams may be in a non-optimized state. It is recommended that users quit out of Teams before they disconnect from Citrix to avoid this from happening.
You could also help prevent this by logging off disconnected sessions after a period of time.
Incoming and outgoing video stream resolution is limited to 720p.
Application screen sharing is not supported.
Only one video stream for incoming camera or screen share stream is supported. As such, when there is an incoming screen share, that screen share is shown instead of the video of the dominant speaker.
High DPI scaling is not supported.
Note that multi-monitor screen sharing was previously limited in that only the main monitor could be shared. This meant that if you wanted to share the contents of an application screen, you would have had to drag the app to your primary monitor. Now with Workspace app 2106 or newer for Windows, Mac, and Linux, you can select the monitor you want to share if the Workspace app Desktop Viewer is in full-screen mode and spanned across all your monitors.
If Desktop Viewer is disabled or you are using Desktop Lock, you cannot select which monitor to share.
Endpoint software requirements
Citrix Workspace app 1907 for Windows or newer.
Citrix Workspace app 1912 LTSR CU5 for Windows contains Teams enhancements.
Citrix Workspace app 2012 for Mac or newer.
Citrix Workspace app 2006 for Linux or newer.
Citrix Workspace app 2105.5 for ChromeOS.
Screen sharing optimization (incoming and outgoing) is disabled by default but can be enabled by referring to Citrix documentation.
Windows 7, 8, 10 32-bit or 64-bit, including Windows Embedded editions.
Endpoint hardware requirements
1GB RAM and 600MB disk space to run Workspace app.
Quad core CPU running at 1.8-2.0 GHz for 720p HD resolution.
Quad core CPU with 1.5 GHz or lower speeds that is equipped with Intel Turbo Boost or AMD Turbo Core that can boost GHz up to 2.4 are also supported.
Thin Clients
According to Citrix, the following Thin Clients have been verified:
HP: t630/t640, t730/t740, mt44/mt45.
Dell: 5070, 5470 Mobile TC.
10ZiG: 4510 and 5810q.
See the Citrix Ready Marketplace for a full list of verified endpoints.
Citrix VDA software requirements
Microsoft Teams 1.3.00.4461 or newer.
VDA 1906.2 or newer.
Windows 10 1607 64-bit and higher.
Server 2012 R2, 2016, or 2019, 2022 Standard and Datacentre editions.
Citrix VDA hardware requirements
2 vCPU for Desktop OS (VDI).
4, 6, or 8 vCPU for Server OS (SBC) keeping in-line with the underlying NUMA configuration of your Hypervisor host.
4GB RAM for Desktop OS (VDI).
512 to 1024MB RAM per user for Server OS (SBC).
8GB HDD space for Desktop OS (VDI).
40 to 60GB HDD space for Server OS (SBC).
Network requirements
Some recommendations/requirements below:
Ensure endpoints can resolve DNS queries to discover the TURN/STUN services provided by Microsoft 365 and that firewalls do not prevent access.
Bypass proxy servers.
Avoid VPN hairpins.
Bypass network SSL intercept and deep packet inspection services.
From the branch office, route to the Microsoft 365 network as direct as possible.
See here for a full list of things you should do to ensure that your network is ready for Microsoft Teams.
The following network performance characteristics are recommended by Citrix to ensure a great user experience with Teams.
One way latency – < 50ms.
RTT latency – < 100ms.
< 1% packet loss during any 15 second interval.
< 30ms packet interarrival jitter during any 15 second interval.
Split tunneling
Routing traffic outside of the VPN tunnel for key Microsoft 365 services such as Exchange Online, SharePoint Online, and Microsoft Teams is recommended. This will reduce the amount of traffic the VPN has to handle and provide users with the best performance possible against the Microsoft 365 services they use.
You should configure IPv4 and IPv6 ranges to be routed outside of the tunnel. You can read more here.
Firewall requirements
Teams will use UDP 1024-65535 high ports for optimized traffic for peer-to-peer connections if there is nothing blocking them.
Otherwise, Teams uses Transport Relay on UDP 3478-3481 or TCP 443 as fallback.
Allow access to the following address ranges:
13.107.64.0/18
52.112.0.0/14
52.120.0.0/14
Headset / Handset device requirements and Recommendations
It is a recommendation to use Microsoft Teams certified headsets that include built-in echo cancellation, and certified cameras.
If you are using external speakers, place them as far as possible from your microphone to avoid any echo.
Antivirus requirements
Exclude the following processes from on-access type scanning from your antivirus provider:
%LocalAppData%\Microsoft\Teams\current\teams.exe
%LocalAppData%\Microsoft\Teams\update.exe
%LocalAppData%\Microsoft\Teams\stage\squirrel.exe
Profile management requirements
For non-persistent deployments, you will need to use a solution like FSLogix to ensure that the appropriate Teams data stored in the user profile is persisted. Profile inclusion and exclusion recommendations are listed below.
Profile management inclusion
%LocalAppData%\Microsoft\IdentityCache
%AppData%\Microsoft\Teams
Profile management exclusion
.txt files from location %AppData%\Microsoft\Teams
It is preferred to install Teams after installing the VDA software. You should also install Teams using the machine-wide installer (per-machine installation) and appropriate switches, rather than using the per-user installation which won’t work well on a non-persistent setup. Per-machine installation suitable for most VDI deployments.
For persistent VDI: You can use the ALLUSERS=1 switch.
For non-persistent desktops: It is recommended to disable auto-update by additionally using the ALLUSER=1 switch.
Full command example for non-persistent desktops:
msiexec /i <path-to-msi> ALLUSER=1 ALLUSERS=1
Full (optional) command example for persistent desktops:
msiexec /i <path-to-msi> ALLUSERS=1
With the machine-wide installer, Teams will be installed under C:\Program Files (x86) instead of in the %AppData% directory of the user profile.
App Layering
Since with App Layering you will be installing Teams without the VDA present, you can create the following registry key on the Teams layer:
HKLM\SOFTWARE\WOW6432Node\Citrix\PortICA
You should technically also be able to use a Platform layer for packaging.
If Teams was already installed
If the user has already installed Teams using the EXE, have the user uninstall it using Add/Remove Programs.
If an administrator installed Teams using the MSI, uninstall it using Add/Remove programs and get each user to log in to complete the uninstall from their profile.
If an administrator installed Teams using Office Pro Plus media, uninstall it using Add/Remove programs and get each user to log in to complete the uninstall from their profile.
Update of Teams on VDA
To update the per-machine based version of Teams, you simply uninstall the currently installed version in your master image and then install the new version using the command line and switched mentioned above.
You can use the following command to uninstall:
msiexec /passive /x <path-to-msi>
As there are frequent updates to Teams, up to a couple per month, you will want to keep on top of this process right and regularly. Visit the What’s new in Microsoft Teams page for a list of new features and functionality.
Uninstalling Teams
If you uninstall Teams:
Teams shortcut is removed from C:\Users\Public\Desktop.
Teams shortcut is removed from %ProgramData%\Microsoft\Windows\Start Menu\Programs.
Teams string is removed from HKLM\SOTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run.
Teams data (per-machine) is removed from C:\Program Files (x86).
Teams data is not removed from any user profile under %AppData%\Microsoft\Teams, as that data prevents the first-time setup from running again if a user logs on to other machines that has the machine-wide installer.
Post install OS and Profile pieces
Once the per-machine based version of Teams has been installed, the following files, folders, and registry entries are present:
Directory: C:\Program Files (x86)\Teams.
This directory contains the setup.json and Teams.exe files.
Registry: A TeamsMachineInstaller string with value %ProgramFiles%\Teams Installer\Teams.exe –checkinstall –source=defaultunder HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run.
File: A desktop shortcut to C:\Program Files\Microsoft\Teams\current\Teams.exe is created under C:\Users\Public\Desktop.
File: A Start menu shortcut to C:\Program Files\Microsoft\Teams\current\Teams.exe is created under C:\ProgramData\Microsoft\Windows\Start Menu\Programs.
For anyone who then logs on to the machine, Teams starts automatically, and after the user authenticates to Teams, installs into the user profile for the first time under %AppData%\Microsoft\Teams. From my observation this will consume 500~ MB.
During this initial installation period, RAM and CPU spike. On my test machine RAM reached 800 MB and CPU reached 100% for 20-30 seconds roughly. As such, you may want to control a mass rollout of Teams by removing the Run string created under HKLM, and instead create one under HKCU for each user in a more controlled manner, or have users manually launch Teams, for example. Solid communication out to end-users in advance can help.
Citrix Policy
There is a required Citrix Policy named Microsoft Teams redirection which is set to Allowed by default.
Confirming Teams optimization
You can check the Teams UI, by clicking About > Version and confirming that the Citrix HDX Optimised legend displays.
Also, once HDX confirms that the Microsoft Teams redirection policy is allowed and Workspace app is version 1907 or above, it sets a DWORD on the VDA to 1. The MSTeamsRedirSupport DWORD will be set to 1 under HKCU\SOFTWARE\Citrix\HDXMediaStream.
On the endpoint runs HdxRtcEngine.exe, which confirms Teams is running in optimized mode.
On the VDA runs WebSocketAgent.exe, which confirms Teams is running in optimized mode. WebSocketAgent.exe is spawned by WebSocketService.exe, which performs TLS termination and user session mapping.
Additionally, peripherals such as your headset and camera will be obtained by the WebRTC media engine of Workspace app and passed through to Teams (Teams does not access peripherals directly). Peripherals will show like below with Teams is optimized within a Citrix environment.
If Microsoft Teams is not optimized, you will likely see references to Citrix HDX like below, and higher resource consumption will be placed on your VDAs.
HDX Optimization for Teams in Action
The picture below is the resource consumption on a VDA during a Teams audio and video call that is unoptimized. CPU was averaging about 30% and the Send / Receive throughput over 1 Mbps.
To demonstrate the difference in resource consumption, the below picture is after the Teams call was ended. CPU and network throughput drops as expected to low levels.
The final picture below is the same VDA participating in an audio and video call that is this time optimized. Comparing this to the unoptimized scenario, network throughput is much lower, and CPU was averaging no more than 10% due to the audio and video processing being offloaded to the endpoint.
It is also worth noting that the audio quality was much better and a lot of the quieter sounds such as mouse clicks were being picked up on the call as a result of the audio being clearer.
Proxy servers and DNS
Proxy
Whilst Proxy servers will typically be configured on VDAs, you must make sure they do not impact the operations of Teams and HDX Optimization for Teams.
To do this, make sure that the Bypass proxy servers for local address setting in Internet options > Connections > LAN settings > Proxy server and make sure that 127.0.0.1:9002 is bypassed.
If you use a PAC file, the PAC file must return DIRECT for wss://127.0.0.1:9002 otherwise optimization will fail.
For corporate devices that also need to route through a proxy when accessing internet resources, the following versions of Workspace app support proxy servers:
Workspace app 2012 for Windows.
Negotiate/Kerberos, NTLM, Basic, and Digest.
PAC files supported.
Workspace app 1912 LTSR CU5 for Windows.
Negotiate/Kerberos, NTLM, Basic, and Digest.
PAC files supported.
Workspace app 2101 for Linux.
Anonymous authentication/
Workspace app 2104 for Mac.
Anonymous authentication.
DNS
Endpoint clients must be able to resolve the following Microsoft Teams TURN FQDNs:
worldaz.turn.teams.microsoft.com
usaz.turn.teams.microsoft.com
euaz.turn.teams.microsoft.com
Disabling GPU hardware acceleration
Does your underlying hosts have dedicated GPUs? If not, then you should disable GPU hardware acceleration within Teams so that the Teams UI and animations do not attempt to be rendered using GPU emulation which impacts on the CPU.
The problem with doing this for multiple users is that due to how Teams has been developed, there are currently no Group Policy settings or simple registry tweaks we can make to turn this off for all or some users. Instead, we need to manipulate a file called desktop-config.json which is stored in the user profile under %AppData%\Microsoft\Teams. The disablement would then take effect the next time Teams is launched.
If I were to manually browse to Settings within the Teams UI and check Disable GPU hardware acceleration, the disableGpu setting under the appPreferenceSettings section changes from false to true.
You can then attach the script to a Group Policy Object so that is runs at user login.
The below screenshot confirms that GPU hardware acceleration has been disabled without manual intervention.
Controlling Teams first run
Whenever Teams runs for the first time and user sign in occurs, CPU spikes to high levels and RAM in my testing spikes to around 800 MB before dropping down to just below 500 MB.
Obviously for physical desktop deployments this is fine, but a mass rollout of Teams to VDI or SBC workloads should have some consideration as to how and when this rolls out, otherwise you will quickly hit performance issues.
Again, like controlling the GPU hardware acceleration setting, there are different ways to do this. One of the simplest ways is by performing at least two actions initially:
Delete the Teams run string on each VDA from HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run
Create an HKCU based run key that has the following data set: C:\Program Files (x86)\Microsoft\Teams\current\Teams.exe –process-start-args “–system-initiated“
With the creation of the HKCU run string, you can be tactical in how you want to deploy it to end-users using Group Policy Preferences or Workspace Environment Management for example.
Once you are comfortable that Teams has been delivered and configured to most or all of your users, and you want Teams to auto launch when users log in, don’t forget to re-create the HKLM run string to use going forward, and remove the HKCU based string for good measure.
Note on Citrix Workspace app
Since there are minimum Workspace app versions required for Teams optimization, it is important to make sure that all your clients are updated to the minimum levels before end-users can use Teams via Citrix Virtual Apps and Desktops. If not, media processing will fall back to the VDA and impact your compute resources.
This can be challenging for almost all environments since they allow access to resources from personal devices which often run older versions of Workspace app. To account for the challenges there are a couple of things you could think of doing, such as:
Using Citrix Gateway expressions to block certain Workspace app versions.
Having a set of external desktops for users who cannot meet the requirements, and those desktops do not have Microsoft Teams installed, or users use the Teams web app with BCR instead.
Disable fallback, by implementing one of the following registry DWORD values on the VDA:
Like controlling the first run of Teams, you may also want to keep Teams from automatically launching at each user logon. This would help combat high compute usage during logon storms to your Citrix Virtual Apps and Desktops environment.
If this is desirable, simply delete the HKLM run string for Teams under HKLM\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Run and any HKCU equivalent if you created those.
Then, you could leave the Teams shortcut that is created as part of the per-machine based install under C:\Users\Public\Desktop for users to launch when they want to use Teams. Alternatively, you could employ a script that launches Teams for the user after they have logged on for a period of time, if the user has not launched it themselves.
Windows Firewall
When users begin to use Teams optimized for the first time, they may notice a Windows Defender Firewall security alert asking if they want to allow HDX Overlay Teams (HdxTeams.exe or HdxRtcEngine.exe) to communicate on the network. It is important to allow access.
Current Release versus LTSR
If Teams is a critical app for the business and the latest features are a must, or an organisation wants to align Citrix closely with the features available on their physical desktops, organisations may look to adopt Current Release versions of Virtual Apps and Desktops so that any new feature that requires a VDA upgrade is covered.
Not all new features require a VDA upgrade however, so this doesn’t mean that a new Teams feature automatically results in a VDA upgrade for your environment.
Screen Sharing
Incoming screen sharing using HDX Optimization is treated like a video stream, so if the other peer shares their camera and then begins to share their screen, their camera video feed is paused in favour of the sharing video feed. The peer must resume their camera sharing manually afterwards.
Outgoing screen sharing is optimized and offloaded to the endpoint, like video and audio. The media engine captures and transmits the Citrix Desktop Viewer, CDViewer.exe window. If you want to share a local application running on your client machine you can overlay it on the Citrix Desktop Viewer window, and it is also captured.
For multi-monitor sharing, you must run at a minimum Citrix Workspace app 2106 for Windows, Linux, or Mac.
Troubleshooting HDX Optimization for Teams
See here for a list of troubleshooting tips from Citrix.
Check Teams is optimized
When Teams is running optimized, the HdxRtcEngine.exe process runs on the endpoint and the WebSocketAgent.exe process runs on the VDA.
Check status of services
There are a couple of services required to be running on the VDA for successful Teams optimization.
Citrix HDX Teams Redirection Service: Provides establishment of virtual channel used with Microsoft Teams.
Citrix HDX HTML5 Video Redirection Service: Responsible for TLS termination of secure WebSockets and spawning the WebSocketAgent.exe process into user sessions when Teams starts. This service also runs as WebSocketService.exe and needs to be listening on 127.0.0.1:9002. You can confirm this using command netstat -anob -p tcp | findstr 9002 on the VDA.
On successful connection, the state turns to ESTABLISHED.
Using HDX Monitor
The latest versions of HDX Monitor allow you to see some information about active Teams calls.
When viewing session information via HDX Monitor, if the Number of connections under Webrtc is set to 0, either Teams has not been launched within the session or has been launched but is not optimized.
When Teams is running optimized, the Number of connections for the session will change to 1.
When a Teams call is in progress, the Virtual channel state will switch from Idle to Active. HDX Monitor will also show you the maximum Kbps outgoing and incoming bandwidth used for the entire HDX session over all Teams calls.
Logs
There are various logs you can turn to when troubleshooting HDX Optimization for Teams.
Client Endpoint (Windows)
Folder: %LocalAppData%\Temp\HdxRtcEngine
Contains hdxrtcengine.log and webrpc.log.
Additionally, there are log files stores on Mac and Linux endpoints, and you also have the option of enabling CDF tracing using specific trace providers.
VDA Trace Providers
HDX_Multimedia_TeamsService
HDX_Multimedia_WebSocketAgent
HDX_Multimedia_WebSocketPipe
HDX_Multimedia_WebSocketService
Endpoint Trace Providers
IcaClient_Multimedia_HdxRtcEngine_CtlGuid
IcaClient_DriversVd_TeamsRedir_CtlGuid
Basic troubleshooting steps
Confirm you are running a compatible version of Workspace app. Refer to the Endpoint software requirements section.
Confirm that HdxRtcEngine.exe is running on the endpoint and WebSocketAgent.exe is running on the VDA. If not, exit Teams on the VDA.
Start Teams and check again if the aforementioned processes are running.
If the processes are still not running or Teams is not optimized, restart the Citrix HDX Teams Redirection Service (if possible) and disconnect from your ICA session, then reconnect.
If the processes are still not running or Teams is not optimized, completely log off the VDA and back on, or reboot the VDA and/or endpoint.
Known Limitations
The documentation for each Citrix Virtual Apps and Desktops release contains a section containing known limitations that are either Citrix limitations, Microsoft limitations, or both.
The pace of change and complexity surrounding IT has accelerated greatly over the past number of years.
Organizations that I work with tend to be making use of both public cloud and on-premises locations to deliver a range of services from standard traditional thick client applications, to web applications, and SaaS, all of which are delivered to many different endpoint types with the majority running Microsoft Windows operating systems such as Windows 10 and 11, or to Microsoft Windows Server operating systems in the case of application virtualization environments such as those powered by Citrix Virtual Apps and Desktops and DaaS. Throw security and hybrid working into the mix and you have a great deal of change and complexity that organizations have to contend with on a month-to-month basis. If anything, with organizations actively migrating parts or all of their infrastructure to cloud, undergoing transformation, and with the increasing focus on security, businesses are undergoing more change now than ever.
Of course, with that being said, change is typically for the greater good, even things like operational monthly Microsoft Windows patching which more times than not these days closes out security vulnerabilities. But in my experience, change is also the number one reason why things break. This can come down to bad planning, the execution of actions carried out wrongly, new software bugs, or simply not enough testing carried out to prepare for the change before it is rolled out to production.
When it comes to applications specifically which is the focus of this article, carrying out pre-implementation testing on applications after a change has been carried out is often overlooked. This can be due to a number of reasons such as the fact that a lot of the time it is a manual process which increases the amount of effort needed, and time is not readily available within most IT teams. Also, IT teams typically don’t know exactly how the applications work, particularly if they aren’t basic off the shelf commercial applications, so testing is basically skipped and if there are any issues the end-user will find them which doesn’t necessarily look good on IT.
What I also often find is that you can bet that most organizations use at least one, but often more applications that have not been validated or officially rubber stamped to work on the latest operating systems or with the latest virtualization technologies. Touching on experience again, it is very common for applications to have been tested and validated on XenApp 7.1 for example, when in reality that version is years old now, or Windows 10 1909, but what if you are planning to upgrade to Windows 10 22H2 for example? This means that you are left wondering how the applications will perform, if at all, on your newly provisioned shiny Citrix Virtual Apps and Desktop environment, or on Windows 10/11, or on Windows Server 2022, and so on.
And finally, application functionality and performance are clear key success criteria for your transformational projects involving operating system or virtualization upgrades. Whilst you can deploy the latest and greatest operating systems and virtualization software to deliver applications to end-users, if the applications fail to work then the project hits major issues and you are left to find alternative solutions which could result in unforeseen expense to the business, or you could burn allocated project budget and impact heavily on timelines getting applications to work by making tweaks and modifications on a whim.
Thankfully there are less risky approaches and solutions available to aid your business whether it be embarking on a transformational project or simply keeping the existing solution your users leverage today up to date and secure.
The Solution
Ultimately when it comes to application testing as I mentioned previously IT don’t always understand how each and every application works, and they don’t have the time to test. Many large organizations that I work with have hundreds of applications and with the amount of change that happens per month you would really need a dedicated team to sit down and carry out all the testing which is not a very good use of their time not to mention how enjoyable that job would be!
Instead, you could offload that task to a solution such as Rimo3 to give you comfort that IT has performed due diligence ahead of major infrastructure refreshes or even if it’s just to validate if applications continue to work after making operational changes such as an in-place Windows 10 upgrade to continuously improve and secure systems.
Rimo3 at its core is an automated application testing solution that comes in the form of SaaS if you are looking for some generic effort free testing to validate if your applications will work on the latest version of Windows 10, Windows 11, or even technologies like AVD, and modern application formats like App Volumes, and MSIX; or PaaS if you want to test applications against your own custom Microsoft Windows images that are obviously unique to your environment.
The solution accepts customer application uploads in the format of MSI, EXE, MSIX, or it can even pull applications from your Microsoft System Center Configuration Manager environment.
Once you upload an application to Rimo3 Cloud, such as an MSI (in zip format), the Rimo3 engine analyses the package, known as discovery, to figure out how the application works and what executables are associated with it. Then, without any IT manual intervention, the application will be tested not only against your current operating system version, but against the target platform you are aiming to reach.
So, for example, when onboarding to Rimo3 you are asked a couple of questions so that Rimo3 can understand where you are today and where you are looking to get to, essentially.
Here are a couple of scenarios that Rimo3 will support you with:
You want to check if your applications work in a multi-session version of Windows to gauge AVD suitability.
You want to see if your applications are suitable to be used as VMware App Volumes or if they can be converted to MSIX format.
You have a stable operating system deployed already and you simply want to test your application set as and when you make changes to the operating system such as after monthly Microsoft Windows patching.
You are planning to migrate from Windows 10 1909 to Windows 10 22H2, or to Windows 11, etc. You could also be running applications from Microsoft Windows Server 2012 R2 in a Terminal Services or Citrix environment and are planning to upgrade to that environment to 2022.
Note also that the onboarding options can be changed at a later date if your objectives change. In my example below, I’ve told Rimo3 that I am currently running Windows 10 Enterprise 20H2, and my target destination is Windows 10 Enterprise 21H2.
Once an application is uploaded, the Rimo3 Cloud will automatically run two sequences to import and discover the application, and once that is complete, begin to run a smoke test against your current operating system to capture a baseline. This happens by the use of “task runners”, which are virtual machines spun up by Rimo3 using the operating system you have set as your current OS, which could equally be a custom image that you have provisioned.
Once the initial baseline smoke test has been completed, it will be time to perform the same on your target OS, including a validation against a multi-session operating system to check for AVD suitability. Again, this is all automated behind the scenes, which presents one of the main advantages I like about the product in that it is very much effortless to the IT administrator.
As and when smoke tests complete, you can drill into the sequences to get some further information on what was tested and here is where you would find out if there were any errors or problems during a test.
And Rimo3 also captures a baseline of the performance metrics captured during each smoke test, which can be used to compare against future smoke tests to ensure that any change which was made to the target OS isn’t likely to have an impact on application performance.
So as you can see, Rimo3 offers an easy approach to application testing and whilst I demonstrated a single application test, you can upload many applications in one go and have Rimo3 drive the testing of those applications in and automated way to validate if they work in the most recent Microsoft operating systems, or even validate if they are suitable for the likes of Azure Virtual Desktop or to be used as MSIX packages for those organisations looking to modernize their application packaging.
Key Takeaways
The key takeaways for me are that with the amount of transformation that organizations are undergoing, applications are often left on the same versions unable to be upgraded for whatever reason and this poses the risk of those applications breaking whilst organizations work to upgrade everything around them or shift to cloud and so on. This puts application testing front of mind for good reason, but there are challenges with testing applications efficiently not just once during a transformation project but on at least a month-to-month basis because change doesn’t suddenly stop after you have reached your goal of migrating to public cloud or upgrading to Windows 11.
Thus, we can rely on a solution that streamlines application testing, modernization, and migration, giving us confidence that the changes being made to our systems is not likely to affect the functionality or performance of the applications, and this can be done quickly and efficiently by Rimo3 which uses an intelligent automation and analysis engine that is dynamic in nature. What I was impressed with was how quickly you can actually get up and running with the product, and how hands off it can be in that you can effectively upload any number of applications to the Rimo3 Cloud and that’s it, Rimo3 then takes care of everything and produces the testing results in a clear and meaningful way.
