The purpose of this blog post is to share my preliminary testing comparing classic Teams with the new Teams. It’s important to note that these findings are not suitable for production environments, and my testing has been limited to basic assessments. I did not employ any automated tools or use LoginVSI. Instead, I relied on fundamental tools like procmon and process explorer.
My goal was to observe the differences and assess the backward compatibility of Hdxengine, Webrtc, and other components present in classic teams. In summary, the new Teams feels lighter, and I am optimistic that Microsoft and Citrix are moving in the right direction. Building something substantial takes time, and, as the saying goes, Rome was not built overnight. Great things require patience and careful development.
With the public preview release of the “new Teams,” I was very curious to see how it performed in a VDI setup. During my testing, I installed both Classic (electron-based) and New (webview2-based). There is nothing fancy here; I will be using Process Explorer and Process Monitor. Here are my specs on the VDI I was testing.
OS | Windows 10 Enterprise |
CPU | 1 socket, 2 Cores |
Ram | 4GB |
WEM | None |
VDA | 2308 |
Optimizer | Base 22H2 |
vGPU | None |
- A recent post from Microsoft
- “Announcing general availability of the new Microsoft Teams app for Windows and Mac”
- System Requirements
- New Microsoft Teams for Virtualized Desktop Infrastructure (VDI) – Microsoft Teams | Microsoft Learn
- Note: “Currently, the new Teams client in VDI is not compatible with FSLogix Profile containers and ODFC containers. Microsoft is working on a solution and plan to remove these limitations soon.”
- Classic vs new installers
Installer format | Install location | Auto update |
Classic Teams MSI with the ALLUSERS=1 flag | C:\Program Files (x86)\Microsoft\Teams | Disabled |
Classic Teams .EXE | %localappdata%/Microsoft/Teams | Enabled |
New Teams .EXE bootstrapper | Teamsbootstrapper.exe is a lightweight wrapper online installer with a headless command-line interface. It allows admins to ‘provision’ (install) the app for all users on a given target computer/. | Enabled (and can be disabled via regkey, coming soon |
It installs the Teams MSIX package on a target computer, making sure that Teams can interoperate correctly with Office and other Microsoft software. | ||
C:\Program\Files\WindowsApps\PublisherName.AppName_AppVersion_architecture_PublisherID | ||
Example | ||
C:\Program\Files\WindowsApps\MSTeams.23125.600.2069.5679_x64_8wekyb3d8bbwe |
- Install the Citrix VDA first; this was a legacy Microsoft Teams requirement for Citrix, and at this time, I am still following the mindset.
- On your persistent or non-persistent VM, run the following command as an administrator: teamsbootstrapper.exe -p
- You can see the installer options as well, to understand what it offers at this time.
- Profile and Cache location for new Teams Client
- All the user settings and configurations are now stored in:
- C:\Users\usernameAppData\Local\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\Microsoft\MSTeams
- C:\Users\davis\AppData\Local\Packages\MSTeams_8wekyb3d8bbwe\LocalCache\Microsoft\MSTeams
- Make sure this folder is persisted for proper Teams functioning.
- Installer location for all users with the “-p” option.
- In the Microsoft document, it states the following:
- In addition, you must deploy the following registry key on the VDA for the new Teams client to be optimized:
- Location: HKLM\SOFTWARE\WOW6432Node\Citrix\WebSocketService
- Key (REG_Multi_SZ): ProcessWhitelist
- Value: msedgewebview2.exe
- In addition, you must deploy the following registry key on the VDA for the new Teams client to be optimized:
- If this registry key is missing, the new Teams client functions in nonoptimized mode (server-side rendering).
- Note: it’s a REG_MULTI_SZ key not a REG_SZ key.
- Classic Teams resource consumption at launch.
- Starting with an Idle CPU base
- Teams opened on the session. This is the default with GPU hardware acceleration on.
- CPU handles from the launch.
- Teams HDX Optimized
- Turn off GPU hardware acceleration to see if there were any differences on Classic Teams.
- CPU handles from the launch. Compared to number 13, it does seem somewhat better.
- Allowing it to go Idle before jumping on a call/meeting
- Tested a call and used Process Explorer to watch the CPU go up and down.
- Now, I am going to repeat the process with the New Teams
- HDX optimized for new Teams using the same Webrtc and HDXEngine
- USB device Devices came through okay.
- CPU handles from the launch.
- It does seem lighter and balanced out faster than the classic teams.
- Upon Opening the new teams, and within 5-7 seconds, this happens below. You can see the CPU go up, then go back down in time.
- Test call on the new Teams.
- Test meeting with the new teams in a meeting from my VDI to a Windows 10 PC at home on a Tmobile HotSpot
- On W10 VDI, the Camera is on, screen sharing is enabled, and the background is defined.
- I tried to capture what process explorer was doing during this time.
- This shows the CPU cycles during the testing for “the Camera is on, screen sharing is enabled, and the background is defined.”
- What I saw on the W10 PC (non-VDI) on my T-Mobile hotspot. Outside the network. This would represent what the other people see. I am just testing in a meeting with myself on two different devices.
- Citrix Monitor in DaaS, and showing the WebSocketAgent on the VDA is still being used.
- The is the PC where I am running the Workspace App. You can see that the HDX RTC Engine is still used.
- The next test I wanted to see if Citrix Monitor (Director) would still pick up the Webrtc channel. I added this to the VDA to see if I can pick up the meeting stats from HDX Monitor
- HKLM\SOFTWARE\WOW6432Node\Citrix\HdxMediaStream
- reg key value:
- name: WebrtcDirectorIntegration
- type: DWORD
- value: enable(1), disable(0)
- Reversed Sharing, Meeting from the Non-VDI device, to see how the Webrtc looked on the receiving end of the new Teams.
- Test meeting with Classic Teams. Running a meeting from my VDI to a iPhone running Teams
- On W10 VDI, Camera on, screensharing on, and background on.
- This shows the CPU cycles during the testing for “the Camera is on, screen sharing is enabled, and the background is defined.”
- Reverse sharing from iPhone to VDI session
- This shows the CPU cycles on reverse sharing etc, testing for “the Camera is on, screen sharing is enabled, and the background is defined.”
Microsoft Team Process while in use.
- The user initiates the Microsoft Teams application.
- Microsoft Teams undergoes authentication with Microsoft 365, which results in the enforcement of tenant policies within the Teams client.
- Relevant TURN and signaling channel details are communicated to the Teams application.
- Microsoft Teams recognizes its operation on a Virtual Desktop Infrastructure (VDA) and initiates API calls to the Citrix JavaScript API.
- Within Microsoft Teams, the Citrix JavaScript component establishes a secure WebSocket connection to WebSocketService.exe, running on the VDA. WebSocketService.exe operates under the Local System account and listens on 127.0.0.1:9002.
- WebSocketService.exe is responsible for TLS termination, user session mapping, and the initiation of WebSocketAgent.exe, which now operates within the user’s session.
- WebSocketAgent.exe establishes a generic virtual channel by interfacing with the Citrix HDX Browser Redirection Service (CtxSvcHost.exe).
- The HDX Engine of Citrix Workspace app, wfica32.exe, spawns a new process known as HdxRtcEngine.exe (or HDXTeams.exe in versions prior to Workspace app 2009.6). This new process serves as the WebRTC engine for Teams optimization.
- HdxRtcEngine.exe and Teams.exe establish a bidirectional virtual channel, enabling the processing of multimedia requests.
- User A initiates a call to User B. Teams.exe communicates with the Teams services in Azure to establish an end-to-end signaling pathway with User B.
- Teams running on the VDA consults HdxTeams (HdxRtcEngine) to acquire a set of supplementary call parameters, including codecs and resolutions, referred to as the Session Description Protocol (SDP) offer. These call parameters are then transmitted through the established signaling path to Teams services in Azure and onward to User B.
- The SDP offer/answer exchange and Interactive Connectivity Establishment (ICE) checks are successfully completed.
- ICE checks for NAT and firewall traversal are accomplished through Session Traversal Utilities for NAT (STUN).
- Secure Real-time Transport Protocol (SRTP) is used for the transmission of media between HdxRtcEngine.exe and User B.
- In the case of a meeting, SRTP is used for media transmission between HdxRtcEngine.exe and the Microsoft 365 conference servers
Resources for references
Optimization for Microsoft Teams
Troubleshooting HDX Optimization for Microsoft Teams (updated frequently)
Quick comparison.
Classic Team launched CPU handles from the launch. Test call and used Process Explorer to watch the CPU go up and down. In a meeting | New Teams launched CPU handles from the launch. Test call and used Process Explorer to watch the CPU go up and down. In a meeting |
This wraps up my initial testing for now. As I mentioned, it was basic testing, and I anticipate that this will evolve into a more extensive and detailed discussion over time. In general, the new Teams exhibits a lighter feel and consumes less RAM. While the CPU does experience an impact compared to classic Teams, the duration of this impact is significantly shorter. I’ve noticed that the interface is much more responsive. It’s important to note that this testing focused specifically on meetings, calls, backgrounds, and sharing. It did not encompass tasks such as using Outlook, scheduling meetings, and engaging with Teams in a day-to-day context. Additionally, I want to emphasize that this is solely testing, and I strongly discourage using it in a production environment. There are still too many uncertainties in the VDI space.