Microsoft has done an amazing job of detailing how the Microsoft Teams VDI client is installed to the workstations. On the Microsoft Docs page they also detail all of the limitations of the VDI Client. This list of limitations has gotten smaller over time but one of the largest is the lack of updates. From the docs:

“With per-machine installation, automatic updates is disabled. This means that to update the Teams app, you must uninstall the current version to update to a newer version. With per-user installation, automatic updates is enabled. For most VDI deployments, we recommend you deploy Teams using per-machine installation. To update to the latest Teams version, start with the uninstall procedure followed by latest Teams version deployment.”

This makes complete sense for a VDI environment. You don’t want your clients updating and reverting when the VDI is shutdown.

We had a customer at T2M Works that ran into an interesting problem with regards to VDI. They found a series of laptops that would not update to the latest Teams client no matter what they did. The only recourse was to uninstall and reinstall the client.

This credit goes to one our engineers, Jeremy Coleman, who did all of the hard work of tracking down what was happening.

Upon investigation, they found that the diagnostic logs were showing the following:

vdiMode=1

If you are still unsure you are in VDI mode, pull your client logs and search for:

“vdiMode”: “2000”

That entry may also have a value of 1, either case indicates you are in VDI mode. If it does not exist or has the value of 0, you are not in VDI mode. To get to the diagnostic logs, you can follow the steps laid out in the Microsoft Docs.

Now that we knew that our workstation was installing the Microsoft Teams Client in VDI mode, the question was why? That is where Process Monitor comes to the rescue. So they fired up ProcMon during the installation of Teams and found this:

As you can see in the above screenshot, the Teams MSI install is searching for:

HKLM\SOFTWARE\Citrix\PortICA

HKLM\SOFTWARE\VMware, Inc.\VMware VDM

If either of those registry keys are present then the client will go into VDI mode during installation, regardless if you add any specific switches during the install. You can have extra fun, if you try adding this switch:

ALLUSER=1

during the install process, if the above keys are not present, then the error will be thrown.

So the question becomes, what app is putting those register keys on the workstation. After a bunch of hunting, is appears there is a Password Management application laying down the Citrix keys, why? We don’t know. But at least we have the cause figured out.