Teams is actually a really good enterprise messaging and collaboration tool and as its in many O365 subscriptions etc then it’s a no-brainer to use it.
However teams also has an unpleasant after taste for SBC/VDI admins (its not the only app that does mind you) in the way that it is installed. By default, running the installer for Microsoft Teams doesn’t actually install the application but it extracts a package and a json file into the c:\program files directory. When a user then logs into a their VDI instance the package is extracted and installed directly into the users profile (around 500mb natively).
For physical devices this doesn’t cause too much of a hassle but for VDI implementations this causes a massive headache. If you consider a typical non-persistent VDI environment which includes some kind of profile solution, Citrix UPM, VMware’s persona manager etc etc you get some highly undesirable effects.
You either have to persist the default locations for the installation files within your profile management solution adding at least 500mb’s to each profile (no thank) or users have to accept that on each logon to a nonpersistent fresh desktop the Teams installer will execute providing a non ideal user experience while the CPU is busy performing the installation actions and whatever else it has to worry about during a logon.
A great solution to this is FSLogix and Office365 or profile containers to containerise the installer reducing the user impact by persisting the data natively within an OS as far as Windows is concerned. This is one of the reasons why Microsoft purchased FSLogix then provided effectively free licences for anyone who purchases RDS,VDA, E3 and above O365 among others. This obviously covers pretty much about everybody. however the problem will still be the same that while Teams is containerised within FSLogix that is still 500mb x No. of users of storage space that could be put to better use.
Despite the great FSLogix option there’s no denying that Teams is a badly written application for any kind of non-perisitent solution and everyone has been commenting on the situation for some time. It appears that Microsoft are now starting to do something about it.
Microsoft have released a version of Teams that is a machine based install which does not install the application into a profile location but with in the correct C:\program files\ location with the caveat that it available for VDI instances only. Sorry SBC people you’ll have to have wait a bit longer I think.
Microsoft have recently released this article which includes download links to the x64 and x86 versions of teams and a specific command line to run in order to install Teams as a VDI friendly product. I wanted to have a look at this executable and see how it installed.
The command line you need to install teams is:
msiexec /i Teams_Windows_x64.MSI /l*v Teams.log ALLUSER=1
The critical difference here which either installs teams in the standard in profile mode or VDI mode is the ALLUSER=1. DO NOT get ALLUSER confused with ALLUSERS=1 its not a typo!
In order to find out a bit more about the teams installer I broke open process monitor and ran the command line without having preinstalled any typical VDI agent packages into a windows 10 instance. Sure enough the installer errors out with an error stating “cannot install for all users when a VDI environment is not detected”.
Looking into the process monitor logs it appears that the teams installer looks for specific VDI agent based registry locations to determine whether it will install or not.
The installer looks specifically looks for the following registry keys
HKLM\SOFTWARE\VMware, Inc\VMware VDM\Agent
These reg keys are obviously associated with the two big VDI vendors however if you are using another vendor again you may be out of luck for now. If a VDI agent is not installed then the installer looks for these keys only and then fails the install however if the VDA is installed it also looks for quite a few other keys so at the moment its not a case of creating a single key to fool the installer.
However once you have a standard VDI agent installed you will then be able to run the installer command and you will see that rather than putting only the package and json file within the program files location it will now install full application into program files with the only exception to the rule being that the Squirell install log file is placed within the user profile and also a folder is created for Teams addin’s within the C:\Users\%username%\appdata\local\Microsoft\TeamsMeetingAddin.
The change to MSI package are certainly welcome and a good initial step in providing a machine based install for Microsoft Teams which hopefully will also migrate across to the other apps that are guilty of the same behaviour(cough OneDrive). I personally would like it be a choice for the customer whether they want to go to the standard version of teams ensuring that they stay up to date with the latest versions automatically across their estate or take a steadier approach by using the machine based install versions
without the VDI technology search behaviour which would require more administrative effort for IT teams but a further degree of control that most companies find comforting.
A couple of things worth noting is that like its non machine based install counterpart Teams is not yet optimised for VDI voice and video capabilities, such as the HDX realtime pack so Microsoft recommend disabling the calling feature within teams.
The machine based installed is also not automatically updated so IT teams will need to manage the update procedure as they would for any other application.
Author: Dale Scriven