Microsoft Teams 2.0 Workload

NOTE: This script is written for the New Teams client and will not work for New Teams Web or Classic Teams.

Jump to: Introduction, Prerequisites, Workload Script Considerations, Workload Actions, Best Practices


Also known as New Teams there has been an increase in interest as Microsoft is moving all customers to New Teams from Classic Teams (version 1.0). A driving question from the Login VSI customer base has been: "Are there any performance benefits of New Teams that will change our sizing profiles, or does our use case require more resources when using New Teams?" If you are using New Teams in an optimized mode, with GPUs you may see an improvement in performance, but how much? If you are using New Teams in a non-optimized mode or are forced to use Teams via a browser will it require more resources from your desktop hosts?



Figure 1 - New Teams load test with presenter's camera active.


In order to run the Teams 2.0 workload there are some things that need to be setup prior to running the script in your tests. 

  1. Licensing - In general, just like many Microsoft applications, a license needs to be activated in order to use the application. If the user is not licensed, then it will not be able to log into the Teams application. Teams Exploratory licensing could be one way to enable virtual users. Make sure to know the difference between self-service licensing and assigned. 
  2. For the virtual users to join a meeting in progress, create a new team that all the virtual users can join. (e.g., user0001 - user0023 and user0024 were added to the team)
    Screenshot 2024-04-05 113059.png
  3. For best results it is recommended to start the meeting from an external machine (e.g., laptop or desktop) with a camera. Log into teams with a user dedicated to presenting (e.g., user0024) on the machine and start a meeting, enabling the camera. Note, using the camera will drive the most resource utilization and it has been observed to use more resources than chatting or screen sharing.
  4. When a new meeting is in progress it will be announced to the team and the virtual users will find the "join meeting" button and join it.

Workload Script Considerations

Microsoft Teams may have slight differences in your organization. The script provided can be easily modified to accommodate these differences. See some of the areas below where you may need to make these modifications.

  1. Starting the app with ms-teams.exe: This script uses ms-teams.exe to start the application. If you find that the virtual user can't find the path to this executable, then try to run Teams one time by creating a script to start Teams by having the virtual user click Start and then click Teams. Once New Teams is run the first time it will put ms-teams.exe in the system path and it will work from that point forward.
  2. Control class names: The names of the controls for many Teams application elements can be very long.
    For example,
    (className : "Button:fui-Button r1alrhcs ___1mwntgo f1sl3k7w f136y8j8 f1brlhvm f10xn8zz ftgf7lp f1m4tk7k fre7gi1 f1358rze fqdk4by f1rvrf73 fzki0ko f3swjwz f1hu3pq6 f19f4twv figsok6 fhovq9v f1xqy1su f1sdsnyy ftqa4ok f2hkw1w f8hki3x f1d2448m f1bjia2o ffh67wi f226i61 f13kzufm flujwa2 fsx75g8 f15bsgw9 f14e48fq f18yb2kv fd6o370 fh1cnn4 fy7oxxb fpukqih f184ne2d frrh606 f1v5zibi ful5kiu fo2hd23 f1jqcqds ftffrms f2e7qr6 fsr1zz6 f1dvezut fd0oaoj fjvm52t f1cwg4i8 f1mywlt f1njr18z fiwyskv f1o5h46z f1q3txrk f1o7qkhw fode6gy fsuw20m f1krrbdw f1deotkl f10ostut f1ozlkrg", title : "Teams")
    While these class names appear to be consistent for the controls, the script provided uses wildcards to truncate these long names, in case they change in the future or are too long to manage...
    For example, using the previous example, the script would use the following as the className...
    (className : "Button:fui-Button*", title : "Teams")
  3. Variables: The following variables are used in the script and will likely need to be changed.
    • Usernames: In this script random users are chosen to chat with. You will want to change "int number = rand.Next(1,23)" where 1 is the number of the first user (e.g., user0001) and 23 is the number of the last user (e.g., user0023). This will allow a random user to be chosen from user0001 thru user0023.
    • Leading Zeros in Username: change "string digits - number.ToString("0000")" where the number of zeros is the number of leading zeros you'd like to configure the users with (e.g., user0001).
    • Chat Recipients: Change the base username "bp-avduser" in 
      string chatRecipient = ("bp-avduser" + digits)
      to "myUser" to get "myUser0001".
    • Duration for the user to join the meeting: Change the integer in
      int meetingWait = 360
      where 360 is the number of seconds you want the user to join the meeting. In this case 360 seconds is 6 minutes for the users to join the meeting. We recommend a longer period of time so you have a workload where many users can join the meeting (see below).
    • User logon: This workload will check to see if Teams is running. If Teams is running it will continue with the workload, if it isn't running it will start it. This script does not log the user into Teams as Teams will typically use SSO. 

Workload Actions

In this workload the virtual user will do the following actions. 

  1. If Teams is not running, the virtual user will start Teams and measure how long it took for Teams to start. Teams will normally automatically log in, but it may be possible to disable this through registry settings.
  2. The virtual user will search for a random user in the Chat context (as identified above) to chat with and select that user to chat with. Once selected the virtual user will send two messages which you can change if you'd like.
  3. The virtual user will select the "Teams" navigation item and look for a new meeting with a Join button. If there is an active meeting in progress which will be identified in the "Posts" for that Team, then it will join the meeting for a pre-determined period of time. A time is included in the script to record the amount of time it took for the user to join the meeting.
  4. After the pre-determined period of time the virtual user will leave the meeting.

Best Practices

  1. Resource monitoring- Some recommended resources to monitor when running Teams workloads would be CPU, Memory, Network traffic, and GPU utilization. Also monitor endpoint launchers as well.
  2. Teams Optimizations - If Teams is running in an optimized mode it will use WebRTC or another P2P protocol and offload audio and video traffic from the host or desktop VM to the endpoints. If running in non-optimized modes you will see a lot more resource utilization.
  3. Baseline - Before testing Teams, take a baseline of the environment by running a base Knowledge Worker workload, or any workload that is analogous to your end users. Then, when you run Teams, you can see the overhead Teams adds to your environment. 
  4. Meeting concurrency - If you are trying to identify an impact to scalability as a result of running Teams, make sure to have a percentage of your total users joining a meeting together. This concurrency percentage should be representative of your production workload. The longer the duration for the user to join the meeting (see above) is, the more concurrency your users will have.
  5. Mixing the workload with a login storm - Login storms can be a heavy hitter to desktop or session host resources. It is recommended to let your all of your users log in before you run the Teams workload, unless that is how your production users behave. 
  6. Run the Teams workload by itself to isolate the resource utilization profile, and then run it with other applications to make sure everything plays nicely together. 

Related to