Introduction

Recently when installing the Teams Machine Wide Installer, I came up against an issue post-build where the users would be presented with the “One more step to set up Teams with Office” dialogue box post-install of Teams in their user context. Clicking on the ever-so-enthusiastic “Let’s do it” box would present them with a login dialogue asking them to authenticate as an administrator to allow the app to make changes to the device. This presents a problem when the users are not actually admins.

The actual fix presented in this post is very simple. The reason I am writing it up at all is because I (and probably you) spent some time searching for the best way to solve the problem and found a load of posts on the internet from people with the same problem, but not many people coming forth with the solution.

What’s This Thing Trying To Do?

It seems odd to me that an installer for Teams which is designed to install in the user context to a user profile when triggered by a RunOnce in a user registry setting would be trying to perform an action that requires administrator access to the machine. I can’t speak to why the installer is doing this, but we can look at what it actually does.

This one additional piece of UI exists just to set Teams as the default IM app for the rest of the Office 365 suite. The configuration for this is not part of the initial Teams installation probably because this could technically be set to a different IM app. It probably won’t be, but it could be. All this is doing is setting some registry keys to which the user doesn’t have access.

OK Fine, Give Me The Keys

OK, so you probably get it. If you just pre-stage the keys in your build before your first user logs on to the machine, you solve this problem. In my case, I did this as part of a build process using PowerShell DSC at the same time as I install the Teams Machine Wide Installer and the Teams Optimisations for AVD. I know this works, but I have not tested using other build processes, so I cannot say for certain it will survive something like a Sysprep or further generalisation.

Key	Value	Type	Data
HKLM\SOFTWARE\IM Providers\Teams	FriendlyName	REG_SZ	Microsoft Teams
HKLM\SOFTWARE\IM Providers\Teams	GUID	REG_SZ	{00425F68-FFC1-445F-8EDF-EF78B84BA1C7}
HKLM\SOFTWARE\IM Providers\Teams	ProcessName	REG_SZ	Teams.exe
HKLM\SOFTWARE\WOW6432Node\IM Providers\Teams	FriendlyName	REG_SZ	Microsoft Teams
HKLM\SOFTWARE\WOW6432Node\IM Providers\Teams	GUID	REG_SZ	{00425F68-FFC1-445F-8EDF-EF78B84BA1C7}
HKLM\SOFTWARE\WOW6432Node\IM Providers\Teams	ProcessName	REG_SZ	Teams.exe

That’s All

That’s it. Do that, problem gone. As mentioned in the introduction, the reason I wrote this up at all is that when I first searched for the resolution to the problem, I found the Reddit post which peters out, I found the 6-page blog post from the MVP where it’s mentioned in the comments that this one thing isn’t addressed with their solution, I found the user registry key which appears to be largely decorative, and then I found the solution. I hope you found the solution here too!