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.
There are several.
Typical enterprise requirements:
In NCSC End User Device Guidance under section Application Whitelisting Instructions:
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.
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.
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:
The test is complete, and we can see that when moving Microsoft Teams to a per-machine location it works as expected.
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.
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.