Recently I have been working on some client Windows 10 modern desktop deployments from Intune, including deploying the Microsoft Teams client. During researching and testing of the Teams client deployment, which is now included with new Office Pro Plus installations (but not with all update channels), I came across a couple of things to be aware of which I thought would be worth sharing here.
First off, it is pretty well known now the Teams is included with new Office Pro Plus installs (see this article). If you read this article, you will notice the below information:
As you can see above, inclusive Teams deployment with the Semi-Annual channel (SAC) should be available in July (subject to change). When configuring an Office deployment in Intune, however, the GUI driven configuration displays Office Apps in a different section to the update channel selection, and regardless of which update channel you want to deploy, Teams will appear as an option (as shown below).
Now, of course, armed with the previous knowledge in the article above, you would be awake to the issue here. However, if you are just having an initial look and jumping in and trying things out, like someone I know might have ;-), this is a gotcha to be aware of, i.e. configuring an Office deployment configured with the SAC update channel and selecting Teams in Intune as shown above will not deploy Teams (for the moment). And to test otherwise, from Intune, I tried deploying Office with the monthly update channel and Teams selected, and Teams deployed as expected. Note that this was deploying Office with the ‘Latest Version’ option selected, which at the time of writing installs 1905.
As a brief side-note here, when the Intune Office deployment completes in this latter scenario above (monthly channel), it creates a folder (containing the Teams application) called ‘C:\Program Files (x86)\Teams Installer\’, regardless of the architecture selected (32 or 64 bit). The next time a user logs on after this, this application runs (in the user’s context) and installs Teams to ‘%userprofile%\AppData\Local\Microsoft\Teams’.
During testing I also noticed that Office Pro Plus installed first, and then the installer runs for Teams creating the above directory afterwards.
So as you can see in the above article, hopefully, Teams deployment with Office Pro Plus for SAC should be available by July, but how can you deploy Teams at the moment from Intune if you are using the Office SAC update channel. And even when this does become available with the SAC update channel, what happens if you wanted to install Office and Teams on different platforms, e.g. Office Pro Plus 32-bit and Teams 64-bit (which is supported by the way, see here). Currently, when you deploy Teams with Office Pro Plus from Intune via the above method, with the monthly update channel, for example, Teams will be installed on the same platform as what was selected for Office, they can’t be different in this scenario.
There are already several useful blogs written on this topic and a couple of different ways to go about installing Teams. The method I am using in our testing phase currently is to download the Teams client MSI installer and deploy it as a line-of-business (LOB) app in Intune. You can download the relevant MSIs from either Teams 32-bit MSI or Teams 64-bit MSI.
In one of my client’s situation, the 32-bit Office was required due to other compatibilities and office add-ins, but we decided we wanted 64-bit Teams. In this case, I created a deployment in Intune for Office Pro Plus SAC (with Teams deselected) and created a LOB app deployment by uploading the above installer and configuring the deployment as shown below.
One thing to note from the above screen-grab is that the install context is automatically detected to be ‘user’ and it can’t be changed. And also change the ‘Ignore app version’ to ‘Yes’ as Teams will manage updates itself.
Once this is done, assign the Office Pro Plus and Teams deployments to a user group and test your deployment. As you can see in the below screen-grab, Office (Outlook) and Teams are running on the platform for which they were configured.
Pretty much all of the configuring of Teams is done from settings and policies configured on the backend Microsoft 365 tenant, and when a user logs into Teams, they receive the configuration settings that they are assigned to in the tenant (e.g. meeting, messaging and calling policies, etc.). A few settings that aren’t configurable via this mechanism though are the ones shown below from the Teams client.
Of course, the user can just select the options they want manually. But, for example, you may want to configure the client to not auto-start for your users each time they log in.
After some quick research, I found out that this isn’t straight forward. Microsoft has recently updated the MSI installer to include the ‘OPTIONS=”noAutoStart=true”‘, but this only prevents Teams from automatically starting after the initial install, and once the user manually starts it, it will continue to use the auto-start behaviour from that point forward (refer to this article).
I found some other blogs suggesting deployments to modify the registry or even modify the Teams ‘json’ configuration file located in ‘C:\Program Files (x86)\Teams Installer\'(which contains the above options), but at a quick look these weren’t options I’d be prepared to recommend here without a lot more testing.
There is at least one user voice on this topic also, see here.
In my testing, I am using Autopilot. I noticed that when I was testing this and I had the Enrolment Status Page (ESP) enabled, a couple of times I experienced some inconsistent behaviour with regards to the Office Pro Plus install, for example, it didn’t complete a couple of times successfully, or the install took a lot longer than it usually did. To be fair though, I did have some other deployments and configuration profiles deploying, so there was more than just Office Pro Plus and Teams in play. Without the ESP enabled, though, results have been consistent so far. So the take away there, as always, is to test thoroughly, especially if you want to use the ESP. The ESP is no longer in preview either by the way (see here), and Microsoft is recommending that it should be turned on for all Autopilot deployments.