
For my demonstration environment I’m using Azure AD group-based license management, and have an Active Directory group that is configured to enable the Teams option for users’ licenses. If you have had Teams disabled during the preview phase, now is the time to turn it back on. Teams configuration is demonstrated in my Getting Started with Microsoft Teams article.Īlthough Teams is included with eligible Office 365 plans, it can be enabled and disabled on a per-user basis.

If you block Teams from self-updating, Microsoft warns that your Teams experience will likely degrade and you’ll miss out on new features and performance improvements that are released. That makes it simple to maintain (as long as you allow it to self-update), and means that deploying Teams is basically a task of running the installer once, and then not running it again.

It will check for, and download, any available updates each time the user runs the program. As you’ll see in the comments on this blog post below, this isn’t ideal for some environments for a variety of reasons. Whichever method you use to deploy Teams, the installer runs in the context of the logged on user, and installs to the %userprofile%\AppData\Local\Microsoft\Teams folder. This package is suitable for GPO and SCCM deployment, but works a little differently than the setup.exe package, as you’ll see in the demonstration below. An MSI package for Windows is also available in x86 and 圆4 versions.You can script the install and use GPO to deploy the package, which I’ll demonstrate later in this article.

The Windows setup.exe package has basic command-line switches for silent install and uninstall.

