How Microsoft Teams installer should have looked like from the beginning

21.05.2019 Update: Microsoft changed Teams MSI to be able to install per-machine. Read about it here:


Microsoft Teams is per-user software.

Why would that be undesirable?

Limited users can install and receive updates from Microsoft without administrator rights. Users receive the latest Microsoft Teams updates and that is controlled by Microsoft. Your IT department can sit and drink coffee. It’s a perfect solution.

That may sound like a good thing for some companies. However, there are enterprises for which per-user installations create headaches. We will explain why, but first, let’s see how the Microsoft provided Microsoft Teams MSI works.  

When we open Microsoft Teams MSI with Master Packager to see what’s inside, we find out that there are only two files placed in Program Files: “Teams.exe,” which is actually a main Microsoft Teams installer, and “setup.json,” which is required to make Teams.exe install silently. There is only one registry that actually runs Teams.exe when a user logs in to Windows. Teams.exe is then launched using the following command line:
%ProgramFiles%\Teams Installer\Teams.exe --checkInstall -source=[SOURCE].

Only during EXE installation does Microsoft Teams gets installed and all main files end up in per-user locations.

Teams application:
%LocalAppData%\Microsoft\Teams 
%LocalAppData%\Microsoft\TeamsMeetingsAddin 
%AppData%\Microsoft\Teams 
Update directory:
%LocalAppData%\SquirrelTemp

 

What is the problem with this concept?

There are several.

  • Installing that kind of MSI using deployment systems such as SCCM or Microsoft Intune will make the application available only when users log in to Windows after MSI was installed.
  • Uninstalling this MSI using deployment systems such as SCCM or Microsoft Intune will make the uninstallation unnecessarily complicated as the installed files are in a per-user location and the system account cannot see them there. Instead of one MSI uninstall command line “msiexec /x product code /qn” that removes all the files, Microsoft forces enterprises to use the following solution:
  1. Uninstall Teams App installed from every user profile.  
  2. After uninstall, delete directory recursively under %localappdata%\Microsoft\Teams.  
  3. Redeploy the MSI package to that computer. 
  4. You can use our Microsoft Teams deployment clean up a script to accomplish steps 1 and 2 via SCCM.
  • Some enterprises use AppLocker, Software Restriction Policies or other whitelisting software to block executable files from running in %appdata% and %localappdata% locations. This will prevent users from launching Microsoft Teams as the main executable is in the %localappdata% location. 

     

What kind of MSI do enterprises need? 

 Typical enterprise requirements: 

  • The application can be installed silently
  • All main application installation files are per-machine
  • Automatic updates are turned off so that enterprises have full control over versioning rather than the vendor
  • After installation, there are no pop-ups or automatic application launches so that it can be installed silently during business hours without confusing or interrupting users
  • Users cannot install updates themselves
  • Users cannot uninstall applications themselves from add/remove programs


  In NCSC End User Device Guidance under section Application Whitelisting Instructions:

  • Users should not be allowed to run programs from areas where they are permitted to write files.
  • Care should be taken to ensure that application updates do not conflict with whitelisting rules.
  • Applications should be reviewed before being approved enterprise-wide, to ensure they don’t undermine application whitelisting. This is especially important for scripting languages which have their own execution environment.

On the feedback site for Microsoft Teams, there were 671 votes to enable all-user installation. At first sight, it may look as though this change was completed on July 7th, 2018, but, wait for it…  
Microsoft Teams MSI that we just look inside is the outcome of this “Completed” user story, and the only thing that they did was wrap setup executable into MSI. It doesn’t solve anything.

 

Currently, on the feedback site for Microsoft Teams, there is a new open user story with the same title, but there is no reaction from the Microsoft Teams side yet. 129 people (at moment this article is written) are waiting for a proper per-machine Microsoft Teams application and the installer. 

If you care about this topic, please go to their feedback site and vote so that per-machine Microsoft Teams is created by Microsoft from the start. 

 

Why did Microsoft design Microsoft Teams to be per-user software? 

We found a GitHub issue in which Warren, who is one of the Microsoft Teams feedback site admins, responded to why Microsoft designed Microsoft Teams like this.

From this response, it is clear that Microsoft created Microsoft Teams per-user only to ensure convenience for their users to install it without admin credentials and to make updates seamless as the updates for Microsoft Teams could happen several times a week. However, it is not an all-for-the best approach for the enterprises. The comments under that GitHub issue and other threads prove that.

Most of the applications are created to be installed in program files. That is the correct way of installing applications for many reasons, including from a security perspective and ease of maintaining that application.
On one thing we agree with Microsoft. If IT admins had to handle the Microsoft Teams installer weekly, it would become frustrating. However, it gets frustrating only if you need to handle the Microsoft Teams current per-user installer. If Microsoft would provide an MSI that installs all files in program files and registries in HKLM, updating MSI in SCCM once a week would take a couple of minutes. Currently, IT admins are getting more frustrated by looking for the solution on the web.

Automation is a good way to deal with vendors that release new installers frequently. As promised, in this blog we will show you how to automate the repackaging process and deploy software from per-user to per-machine with one double click.

 

How to make Microsoft Teams per-machine yourself?

First, you need to make sure that it is even possible and that there is no hidden logic behind the per-user application and installer. From our experience working several years in the packaging industry, we can say that most applications can be moved to a per-machine location, thus allowing the application to be deployed using enterprise deployment systems and be compliant with best practices.

As far as we have discovered and discussed here, it looks like Microsoft made Microsoft Teams per-user only to ensure consistent up-to-date versioning so that Microsoft has full control of it. 

These are the steps needed to make Microsoft Teams per-machine:

1) Capture system changes that the Microsoft Teams installer makes. For this purpose, we will use Microsoft Teams .EXE installer and Master Packager for capturing all the system changes.

2) After cleaning trash from the package, we can see the locations of all the files that were installed.

3) With a bit of testing and the resources from Microsoft, we can see that the main files for installation are stored in the “%LocalAppData%\Microsoft\Teams” and “%LocalAppData%\Microsoft\TeamsMeetingsAddin” folders. Move these folders to the per-machine location. As this is an x64 Microsoft Teams installation, let’s move it to the “C:\Program Files\Microsoft Teams” folder. Microsoft.Teams.AddinLoader.dll must be unregistered from HKCU and registered with an admin command prompt so that it gets registered in HKCR.  

4) Test it: 

  • Install MSI on a clean machine and see if the Microsoft Teams shortcut works.
  • Sign in and test the application by adding files, commenting on something and changing settings.
  • Check if the Microsoft Teams add-in in Outlook shows up and works.
     
  • Download the older version of Microsoft Teams. We found older Microsoft Teams version links in the Chocolatey.org Microsoft Teams Desktop App package. Repackage it the same way and see how the user upgrade works. After testing it, you can see that there is a notification about updates that reads, “To keep using Teams, download the latest update.” So auto-updates are now “disabled” and users have to download a new version manually. 


    Note: Limited users can download new versions themselves and install them if no company policies are set to prevent it. If end-users install a version manually, it will still appear in the per-user location.

Done!
The test is complete, and we can see that when moving Microsoft Teams to a per-machine location it works as expected.

 

How can you make a per-machine Microsoft Teams installer automatically?

We have a solution for that. Automated script downloads the latest Microsoft Teams version, repackages it and configures it to make it ready for enterprise deployment systems as a per-machine MSI and per-machine software. Read how to get the script and how it works in our next article here. 

 

Disclaimer

Please note that this article shows that it is possible to make Microsoft Teams enterprise-ready by moving all the files to a per-machine location, but, of course, this is not preferred as Microsoft could change Microsoft Teams logic over time.
The best solution would be that this kind of MSI comes straight from Microsoft.

We created this article and the next one how to automate repackaging so enterprise could have a solution for this issue, also to point out clear Microsoft's ignorance when hundreds of people are requesting a proper MSI.
We already voted at the Microsoft Teams feedback site to show attention on this topic and we encourage you to do the same.

 

Download per-machine Microsoft Teams MSI

 

References:

Subscribe to our newsletters