So you want to use Microsoft Teams in your organisation, huh? Are you prepared for the pain? The lack of documentation? The feeling of utter exasperation at a company unable to properly consider the needs of enterprise customers in their new “modern” approach? Well, I’m here to share my experiences with you so that hopefully you can avoid some of the pain I had to go through in getting this all ready for our upcoming rollout.
Like many of you, my organisation utilises Microsoft’s powerhouse deployment tool: SCCM. Initially, when Teams was released it was only available as an executable, which is fine. A little jiggery-pokery with detection methods yielded a usable application which could easily be deployed and self-served by users. Unfortunately, deploying the .exe and then trying to switch to the .msi requires the use of a cleanup script, so we were lucky that Microsoft – in their infinite wisdom – decided to release the .msi “machine-wide installer” before we started deploying. Saves us a bit of work.
The .msi installer, as you might imagine, works perfectly as an application. The only caveate is that the installer is per-user no matter what you specify in your application settings. The program installs to the users’ AppData folder, so it can cause headaches in environments which make use of redirected AppData.
This is where things got a lot more complicated. Intune is at once a product with a great deal of documentation and one with absolutely no useful information. So when my co-worker and I initially uploaded the .msi to Intune we expected it to… work. Nobody else had complained of any issues with the deployment via Intune, so we were surprised when every attempt at installation came back as having failed.
So here’s the thing: Intune HATES deployments based on devices. Nearly every device configuration profile, compliance profile, and application deployment is expected to be done per-user. This does not fit our use-case, as users need to interact with many different devices in different contexts (e.g. shared user devices and personal devices). For that reason, we’ve had a lot of problems getting policies to work and are currently trying to get M$ to fix the issue.
But what about Teams? After all, the Chrome Enterprise installer worked fine targeting devices. The error message from Intune was that devices could not be targeted with user-based installers. But Teams is a “machine-wide installer”, right? Well, no. Not exactly. The installer basically just sets up a base downloader that is initiated by a user logging in. So how do you get Intune to recognise it as a device installer? You edit the .msi of course.
I personally use SuperOrca to do this, but there are other tools available which can do the same job. Basically you just load up the .msi and add the following value to a new row:
This will set the default installation target to “machine”, and will enable deployment of the .msi to device collections within Intune. ### Stopping AutoStart The single most annoying thing about Microsoft Teams is its inability to shut up. By default, the application is set to launch in the foreground at login. It’s not a small app, either, so on older machines it increases load up time substantially. When you’re trying to get non-techie users to use new tech (teachers, for example) the LAST thing you want to do is annoy them with clunky, slow applications. So, I started poring over the documentation looking for an enterprise kill switch for this behaviour. An ADMX template, maybe? Doesn’t look like it. A native GPO for Teams behaviour? Nope. Hmm. Okay then. Let’s brush off [Procmon](https://docs.microsoft.com/en-us/sysinternals/downloads/procmon) and look at what this is doing. So it looks like when you enable/disable the autostart from within the Teams desktop application it writes and verifies a bunch of regkeys. The one we’re interested in is this one:
HKCU\Software\Microsoft\Windows\CurrentVersion\Run com.squirrel.Teams.Teams C:\Users\%currentuser%\AppData\Local\Microsoft\Teams\Update.exe --processStart "Teams.exe" --process-start-args "--system-initiated"
So, by creating a login script using group policy which searches for and removes this key, we effectively wipe out the autostart behaviour. Now, we have a working Teams deployment on SCCM. As for Intune, it remains to be seen whether or not creating a CSP and installing local GPOs will consistently suppress autostart. To be tested next week.