Home » Collaboration » Teams » Deploying the Microsoft Teams Desktop Client

Deploying the Microsoft Teams Desktop Client

Microsoft Teams is now generally available for Office 365 customers, and for those of you who are planning to use it you may be looking for a way to deploy the Teams client to your user's computers.

The Microsoft Teams desktop client installer is available from Microsoft here. It's a .exe package, with basic command-line switches for silent install and uninstall. For example, to silently install Microsoft Teams, the following command line can be used:

To silently uninstall Teams, the following command line can be used:

The Teams installer runs in the context of the logged on user and installs to the %userprofile%\AppData\Local\Microsoft\Teams folder, so any deployment script needs to run in the context of the user. A logon script assigned by Group Policy meets that requirement.

Teams is a self-updating application. It will check for, and download, any available updates each time the user runs the program. 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. So with a little scripting logic you can check for the existence of the Teams application in the user's AppData folder, and run or not run the installer depending on the results.

As a side note, when Teams is uninstalled it leaves the Update.exe file in place. So checking for Update.exe in your script logic will give misleading results. Instead, you can check for the existence of a folder named “.dead”, which is placed in the application folder when Teams is uninstalled. For my deployment script which I'm sharing here, I've checked for “.dead”, and if found, will run the Teams installer again.

Preparing to Deploy Microsoft Teams

Before you deploy the Teams client you should verify that Teams in your Office 365 tenant is configured the way you want it. Teams configuration is demonstrated in my Getting Started with Microsoft Teams article.

Although Teams is included with eligible Office 365 plans, it can be enabled and disabled on a per-user basis. If you have had Teams disabled during the preview phase, now is the time to turn it back on. 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. Helpfully, that also means I have a security group already in place that I can target my Group Policy to.

Download the Microsoft Teams installer and place the file on a network share that can be accessed by your users when the logon script runs. For this demonstration, the installer will be running from the path \\mgmt\installs\MicrosoftTeams.

Using Group Policy to Deploy Microsoft Teams

Download the Install-MicrosoftTeams.ps1 PowerShell script from the TechNet Script Gallery.

Create a Group Policy that assigns a logon script to run the Install-MicrosoftTeams.ps1 PowerShell script, and provide the -SourcePath as a script parameter.

If you are filtering the GPO to a specific security group, remember to also add Authenticated Users to the Delegation tab of the Group Policy and grant them Read (but not Apply) permissions.

At next Group Policy refresh and logon the Teams client will silently install for the user, and place a Microsoft Teams icon on their desktop.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Teams


  1. Dave says:

    How are we supposed to create a desktop icon for users that have a redirected desktop?

    Why in the world does this install to the users profile instead of the program files folder? It makes it impossible to deploy to enterprise users with standard tools

  2. Avi says:

    this is excellent and working just fine! thank you!
    my question is:
    i personally don’t like to distribute software as a user configuration. i much prefer to do it as computer configuration.
    i tried to use this script as a startup script (computer configuration) and it didnt work.
    is there any way to do the same action as this script does a logon script but a startup script?

    • The Teams app installs to the user’s profile \ appdata, so it needs to install as the user.

      It would be nice to pre-install it on the PC just once, but that doesn’t seem to be possible. But once it’s installed for that user, it just self-updates and keeps working on its own, so it is nice a simple in that respect.

      • Avi says:

        Hi Paul
        thanks for your reply.
        we have many users in our company that part of their job requires them to logon to servers as well. this might result in them triggering the install on teams on the servers as well. (at least in our AD structure). isn’t there any way to get the teams installer in an msi format? this way i will be able to deploy it to computer configuration as all other msi installers

  3. Martin says:

    Where does this get logged if it fails to install ?

    Trying to push this out for a group of users and can’t get it to work. Even trying it with my account with domain admin rights doesn’t work.

  4. Mark says:

    Really just echoing Dave’s comment here. Installing anything to appdata instead of Program Files (Clue is in the naming) is a stupid idea and disappointed to see Microsoft engaging in this bad practice (First seen by Google as a way of trying to bypass network administrators well meaning policys). Really keen to engage with this product but its a no go till it installs correctly and removes the user auto-update (Another stupid practice).

  5. Suman says:

    We are trying to deploy MS Teams on Citrix 6.5 Farm with PVS streamed Xenapp Servers.
    Is it possible to deploy on this environment?

  6. Ian says:

    Sadly I agree with many here.

    Installing as a user context isn’t really working for me along with self updating. I cannot get it to work under a user login without making them an Admin. Additionally with SRPs etc its a heap of fun (NOT) to allow it to install to the Appdata folder.

    What happened to the tried and tested MSI installer like nearly everything else so it will push via GPO etc and you can have mapped start menu’s and programs etc.

    MS are not making it easy to use / deploy and I will remain using OfficeChat for now.

  7. Jason says:

    And now we have news that they will start pushing teams even more while this issue with user based installs (appdata) still exists. At least Skype supports a decent install and update method. And Microsoft hasn’t listened to a group of us IT admins that have expressed our complete distaste for this approach. I will refuse to install it into they change this. I will not open my systems to be more vulnerable because of stupid decisions by the teams group.

  8. Jon says:

    I created the group policy to install Teams, but on the client, at login I get a security warning popup:
    “We can’t verify who created this file. Are you sure you want to run this file?”

    I’ve unblocked the .exe, but I still get this popup which would not be a good experience for my users.

    Browsing to the installer on my network share and running the .exe from the client does not produce this warning. Any ideas as to what I’m missing?

Leave a Reply

Your email address will not be published. Required fields are marked *