Decrypting how Microsoft Teams new MSI works

Microsoft has released a windows Installer MSI for Microsoft Teams for deployment through SCCM.You can download it here

As per Microsoft Statement:

"The Teams MSI will place an installer in Program Files. Whenever a user signs into a new Windows User Profile, the installer will be launched and a copy of Teams application will be installed in that user's appdata folder. If a user already has the Teams app installed in the appdata folder, the MSI installer will skip the process for that user."

NOTE: Don't change the install location as it will break the process.

In this blog, I will explain how this happens by opening MSI using Installshield.

1. To Install Microsoft Teams, it first requires .net 4.5 or later to be installed in the machine. This check happens using Launch condition which also does a system search for .net registry to be present in the machine.

2. The MSI has only one file which is Teams.exe that gets installed to [ProgramFilesFolder]Teams Installer location.

3. It also has only one registry file which gets placed in Run key.So whenever a user logs in, the run key will trigger the command present in it. So in this case it triggers the Teams.exe -checkinstall

So after published through SCCM system context, you can find the Teams.exe installed in the following location.

Also a run key is created in the machine registry HKLM which will trigger the Teams.exe to check for files installed in %localappdata% if not present install the files and launch automatically.

User if logged in, needs to logoff/login again. If a new user logs in then the run key will trigger the install process in the background  and place the files in the below location and then launch automatically.

To perform a clean removal of files through SCCM, use the Powershell script from the below link.

Exploring Advanced Installer Express free edition to convert legacy apps to UWP

Earlier back in 2016 when Microsoft released Project centennail, I have blogged about it which you can find here

To know more about Desktop bridge and UWP conversion have a look here

Recently Advanced Installer has released a free express edition which is a GUI based tool to simplify the process of converting legacy exe/msi to appx format.They have also stated to support the new MSIX format in their upcoming release.

You can download the free  Advanced Installer express version here.

Pre-Req: Install windows sdk from here 

After downloading install the windows sdk first and then install  the Advanced Installer express edition in a clean virtual machine.After Installing you will be prompted to register using your mail ID to get the free license .After validating click on new and select the Convert Desktop App as shown below and click next.

Provide the setup path (msi/exe) and add any parameters if you wish to add.In this example I have used google chrome msi package to convert to appx format.

Provide the output path or leave to default location.

After clicking Next, the tool will do pre-capture, install the google chrome msi and then do the post capture during the Installation monitoring phase.

Once done, click next. It will list out what all files,registries,scheduled tasks etc..
You can do cleanup in this section and then click import.

Click build icon to create uwp app.If there are any issues, it will show build failed.

You can see that in the below screen it says that the Appx package must be digitally signed to install.

I have ignored this warning and proceeded next.You can see the output files. Inside Google Chrome-BuildUwpAppx folder you can see the Google Chrome.appx file created.

To install the Google Chrome.appx, open elevated powershell window and run the below command.

Add-AppxPackage "Path to .AppX File"

You can see that the command fails stating that there is no valid digital signature.

For testing purpose, I have created a dummy certificate following the steps provided here

After that in the Advanced Installer project, I scrolled to Digital Signature tab and added the above created google.pfx file and selected enable signing option as shown below.

Click build option to add the certificate inside the output .appx file.Once done run the below command to test the output package.

Testing :Open elevated powershell and run the below command.

Add-AppxPackage "Path to .AppX File"

This will install the package successfully.If you are facing issues during Install because of certificates, follow these steps as mentioned here.

From my testing I found the below Pro's using the Advanced Installer express edition.

1. User Friendly GUI which makes even a beginner to convert legacy apps to UWP easily.
2. No need of docker image and desktop bridge powershell commands to convert anymore. We can install the Advanced Installer application in the virtual machine and use it directly to convert.
3. With the same project we can also create msi/exe output files (makes life easy).
4. Highlights the issues found during build phase which really helps us to easily resolve it.


1. Install Monitoring Phase takes quite some time which can be made faster.

So why wait, go and grab the free Advanced Installer express edition and convert your legacy apps to UWP easily.

Solution: TortoiseSVN Background contextmenu not visible after publishing

After publishing the App-V sequenced TortoiseSVN, all the context menu shortcuts are visible and it works fine. Only the background context menu option is not visible. In this blog, I will demonstrate and provide a solution for it.

First download the TortoiseSVN software from the below link.

Download the Latest windows ADK so that we can use the latest App-V Sequencer from the below link.

Sequence the TortoiseSVN application using default steps.

Even if you use PVAD when sequencing, we can see the same issue that the background context menu is not visible after publishing.
After Publishing the sequenced package, we can see that when we right click file\folder\drive the context menu option is visible as App-V will install those respective registry entries in the local machine and they will be used by the explorer due to dynamic virtualization concept.



But when we right click on empty explorer window or inside any folder empty place, the below options are not visible as seen in the native installed package.

We can see that in the sequencer machine, the following registry responsible for the background context menu is registered in the local machine.

Even in the package editor we can see that those registry keys are captured.

Even in the AppxManifest file we can see those shell entries.

But after publishing and seeing the local HKCR registry, the particular key alone is missing. All other context menu registries are visible.

Windows Registry Editor Version 5.00


To Fix the issue, copy the above registry key and install in native machine.To Add it with the sequenced package, first export the AppxManifest.xml file and edit it using AVME from the below link.

Edit the XML file and add like below in AddPackage and Remove Package tabs.

Once done save the AppxManifest.xml file and import it back to the package using sequencer.

Save the package and publish it to the client machine. Now you can see the context menu when you click on empty explorer window or empty space inside directory.
You can also add the registry using scripts in deploymentconfig/userconfig file too.

As pointed by Roy Essers in a TechNet post, this indeed seems to be App-V sequencer bug and MS needs to fix this soon.

Adobe Illustrator error 16 - Fix

When launching sequenced Adobe illustrator shortcut we see the below issue in the App-V client machine.

Reason: This is due to UAC and the application requires to be run as administrator.

Solution: To test manually Click Start > All Programs. Right click on the Adobe Illustrator shortcut  and click Run As Administrator. The shortcut will launch without any error.

So how to resolve this in the App-V 5.x package? We need to suppress the UAC prompt when run as administrator using RunAsInvoker or other shims.

Check my another blog for more information to solve this issue here

HotFix Released: App-V Applications worked in win 10 1607 fails in win 10 1703

Many packages that completely worked in inbox App-V in windows 10 1607 failed after upgrading to windows 10 1703. The reason for failure is due to Microsoft changed the way to load registries in containers CREG instead of usual virtual registry VREG.

There was a temporary fix which was available and Roy Essers posted it in twitter a long back.
It was adding the below registry entry manually in the 1703/1709 machines.


This issue is fixed in windows 10 1703 with the new hotfix released.

We can clearly see that they have made use of the temporary fix to change the registry virtualization to use the VREG instead of the modern CREG that was mentioned earlier to permanently fix this issue.

Apart from the registry fix, this update also fixes many other App-V issues which can bee seen below.

This update will be downloaded and installed automatically from Windows Update.