This blog will show you why teams are sometimes installed in the Program data folder and other times in the user’s local app data folder when you deploy the Microsoft 365 Apps from Intune and why the teams update functionality could break.

1.Installations options:

Before we begin, we need to know 2 important differences. You can install Teams:

*Per-User

*Per-Machine

1.Per-Machine

This kind of installation is the type of installation you need when you are working with VDI (Non-persistent environments) Please beware, with a machine-wide installer automatic updates are disabled. You will need to uninstall the old version first before you can install the latest version.

When you want to use the machine-wide installation you need to use the Teams MSI installer. A machine-wide installer is not supported when you are using a Microsoft 365 apps deployment in Intune.
You could install the machine-wide installer with this msiexec command line:
msiexec.exe /i “Teams_windows_x64.msi” ALLUSER=1 ALLUSERS=1

There is a big difference between the ALLUSER and ALLUSERS setting

ALLUSERS=1 parameter. When you set this parameter, Teams Machine-Wide Installer appears in Programs and Features in Control Panel and in Apps & features in Windows Settings for all users of the computer. All users can then uninstall Teams if they have admin credentials on the computer.

ALLUSER=1 parameter is used only in VDI environments to specify a per-machine installation.
Please beware the ALLUSER=1 switch will only work when a VDI environment is detected otherwise it will fail to install

When you don’t have a VDI environment you could fool the teams installer by creating a registry key

”HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\PortICA”

If this key is created, the installer will continue without any errors.

2.Per User Installation

Now we have seen you could use a machine-wide installer when you want to make sure teams is installed in the program files folder we are going to look at the per-user based installations.

When you are going to deploy the Microsoft 365 Apps, you can make sure Teams is a part of the installation.

When Teams is being installed, it will create a folder in the Program Files (x86) folder. Inside this folder, you will find the teams.exe installer and a setup.json file.

Whenever a user signs in to a new Windows User Profile, the installer will auto-launch and the Teams client app will be installed in that user’s AppData folder. .(in a normal situation).

This progress will be done for each user who logs in. So for each user, a Teams folder will be created in the local AppData folder. Of course, you can disable auto-launch, to make sure this won’t happen.

In comparison with the per-machine installation automatic updates are enabled, when using the per-user installation. (again in a normal situation)

2. The problem

Like I was telling earlier, Microsoft tells us the per-user Teams installation, will install teams in the localappdata folder for each user. I couldn’t find any Microsoft Documentation why Teams sometimes is installed in the programdata\%username% folder instead of the user’s local appdata folder.

Let’s take a look at how teams is being installed.

When a new windows user logs in for the first time, the Teams installer inside the program files folder will begin installing the Teams app inside the user’s profile folder…….but when the installer could not run the update.exe in the user context it will skip the userprofile directory as the installation folder. It will try to install into the programdata\%userfolder% instead.

You might ask yourself why wouldn’t the update process have permission to run in the localappdata folder? Applocker!

I will show you the difference between one Applocker setup where the teams executable inside the localappdatafolder and the program data folder is not allowed and of course I will show you the setup when the teams installation is allowed.

In the first attempt, the teams installer will try to launch the update.exe inside the localappdata folder. Please note: The Default Applocker baseline does not block anything inside the program files folder, so the teams installer could be run without any issues.

If the first attempt fails, it will try to install in the programdata folder.

There are many companies working with Applocker path rules instead of publisher condition rules. When you are working with path rules, it could be difficult to open up the localappdata folder to allow some specific teams executables.

A lot of companies just don’t allow executables the be run in the localappdata folder, because most of the malware will also try to download and open executables inside the localappdata folder. That’s definitely a very good reason.

3. Solving the issue

So we need to use the publisher rule instead of a path rule. Microsoft teams installation files are digital signed so they are perfect to use when you need to configure a publisher rule. The only 2 products you need to add are MICROSOFT TEAMS and MICROSOFT TEAMS UPDATE (If you don’t specify this one, you can guess what isn’t going to work). The file name and file version must be configured to * (wildcard)

The XML part you could add to your Applocker configuration in Intune

<FilePublisherRule Id="d98e826d-c310-42a3-a900-879f7eaaf8ad" Name="MICROSOFT TEAMS, van O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="MICROSOFT TEAMS" BinaryName="*">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>
 <FilePublisherRule Id="d98e826d-c319-42a3-a904-879f6eaaf8ad" Name="MICROSOFT TEAMS UPDATE, van O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
      <Conditions>
        <FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US" ProductName="MICROSOFT TEAMS UPDATE" BinaryName="*">
          <BinaryVersionRange LowSection="*" HighSection="*" />
        </FilePublisherCondition>
      </Conditions>
    </FilePublisherRule>

Now we have added the XML configuration let’s take a look at what happens when we are logging in for the first time.

When the applocker rules are not properly configured, there is a very high chance the Teams update functionality is also broken!!

This is because the Applocker rules could also be blocking the update process. When Applocker blocks the update process, users will see an in-app alert encouraging them to manually update to the latest version of Teams. The users might be prompted to contact their IT admin to do the update. This includes users using the Teams desktop client as part of the Microsoft 365 Apps for enterprise bundle.

The first warning, telling you, you need to download the update to keep using teams will be shown if the current user’s version is between one and three months old and if there’s a new version available.

The second warning is a simple blocking page, that tells you, you need to update teams otherwise you could not use it.

Also, beware of the fact, that desktop client versions that are more than three months old upon the first install and/or first run of Teams have a 28-day grace period before encountering the above-mentioned servicing information. During this period, the auto-update process will update the Teams client (If applocker is properly configured).

Conclusion

There is absolutely no discussion of why you need to implement some sort of software restriction. In my opinion, Applocker works fantastic and it’s very easy to use and to maintain. But you need to make sure you use publisher rules where possible to allow applications.

If you are using Applocker file path rules you can end up with the Teams installation path or update problem.