This issue has been plaguing our client for a while now, so I thought I’d write a quick blog post on the Microsoft Teams Machine-Wide Installer and Breakout Rooms.
One of our clients uses Teams on their non-persistent virtual desktops. As such, we deployed the machine-wide installer to the image since we couldn’t have the Teams client automatically updating each time a user logged in!
Microsoft Teams Machine-Wide Installer Downloads
Firstly, you need to download the machine-wide installer for Teams using one of these links:
We installed the x86 version on an x64 operating system, and the MSI version is 220.127.116.11564. By default if you run:
msiexec /i Teams_windows.msi
You’ll notice that there are no shortcuts created and that the installer just installs….an installer (smile) to C:\Program Files (x86)\Teams Installer called Teams.exe.
Having a quick scan through the InstallExecuteSequence I can see that in order for the installer (MSI) to initiate the installed installer (Teams.exe) we need to make sure the public property ALLUSER is set to anything other than blank/zero (and yes, i meant ALLUSER and not the standard ALLUSERS, because Microsoft are confusing the process). So if we instead install as follows:
msiexec /i Teams_windows.msi ALLUSER=1
We will now see a desktop shortcut and an machine-wide installation under C:\Program Files (x86)\Microsoft\Teams\current. Progress.
One thing to note is that in previous versions of Teams, users had reported seeing the following error when installing Teams on a VDI environment using ALLUSER=1:
Cannot install for all users when a VDI environment is not detected.
and their fix for was to make sure the following registry key was present on the machine:
This apparently fixed the issue and Teams installed successfully! But wait…
Missing Breakout Rooms in Microsoft Teams
Recently our client found that users couldn’t access a relatively new feature of Teams called ‘breakout rooms’. I thought this was strange since they were running a version of Teams which supposedly supported breakout rooms!? But after some Process Monitoring, it turns out that this (and potentially other) functionality will NOT work if the machine has either of the following registry entries present on the machine:
HKEY_LOCAL_MACHINE\SOFTWARE\VMware, Inc.\VMware VDM AgentInstallPath
So at the moment we’re currently investigating whether we really DO need the PortICA key during install of the latest version, and if we do, what the implications are of removing it straight after the installation has completed!
Of course, removing the AgentInstallPath value from our VMWare VDI platform looks a bit murky indeed. And upon some pilot testing we did see the occasional user experience the following error when viewing Teams chats: