Bypass “One more step to set up Teams with Office”


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.

HKLM\SOFTWARE\IM Providers\TeamsFriendlyNameREG_SZMicrosoft Teams
HKLM\SOFTWARE\IM Providers\TeamsGUIDREG_SZ{00425F68-FFC1-445F-8EDF-EF78B84BA1C7}
HKLM\SOFTWARE\IM Providers\TeamsProcessNameREG_SZTeams.exe
HKLM\SOFTWARE\WOW6432Node\IM Providers\TeamsFriendlyNameREG_SZMicrosoft Teams
HKLM\SOFTWARE\WOW6432Node\IM Providers\TeamsGUIDREG_SZ{00425F68-FFC1-445F-8EDF-EF78B84BA1C7}
HKLM\SOFTWARE\WOW6432Node\IM Providers\TeamsProcessNameREG_SZTeams.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!

[mailpoet_form id="1"]

Other Recent Blogs

Level 9, 360 Collins Street, 
Melbourne VIC 3000

Level 2, 24 Campbell St,
Sydney NSW 2000

200 Adelaide St,
Brisbane QLD 4000

191 St Georges Terrace
Perth WA 6000

Level 10, 41 Shortland Street

Part of

Arinco trades as Arinco (VIC) Pty Ltd and Arinco (NSW) Pty Ltd. © 2023 All Rights Reserved Arinco™ | Privacy Policy
Arinco acknowledges the Traditional Owners of the land on which our offices are situated, and pay our respects to their Elders past, present and emerging.

Get started on the right path to cloud success today. Our Crew are standing by to answer your questions and get you up and running.