After being on a nice vacation for 2 weeks now, I felt the urge to write this simple blog to show you how to deal with a not responding Microsoft Edge when the first user logs in after an Autopilot enrollment.

1. Introduction

After the “preparing your device for mobile management” 0x800705b4 time-out issue was resolved that started happening with the 2022-07 preview update. I was wondering what else this update would fix!

Some time ago, I also wrote a blog about the broken Windows Store apps when you wiped your device and enrolled it with Autopilot again.

Microsoft Store Apps not working after performing a Wipe (call4cloud.nl)

In this Microsoft Store Apps blog above, I showed you that the required frameworks for those Store apps were missing after a wipe. They were missing when they were still available in the WindowsApps folder.

As always, I am keeping my blogs up to date. After installing the 2022-07 preview update and performing a successful wipe and an Autopilot enrollment those issues were gone!

I was hoping some other “bug” was also fixed, but unfortunately, it wasn’t! Shall we take a look at the bug/issue?

2. The Issue

Let’s start with a video first… even when it seems like there is nothing happening let’s check it out

Edge not responding after Autopilot enrollment – YouTube

When you have taken a look at the youtube video you have probably noticed that, nothing happens when clicking on the Microsoft Edge icon. That’s odd right as you should expect that after a successful Autopilot enrollment, Edge should be working

3. Troubleshooting it

At first, I hoped the 2022-07 preview update should also have solved it but unfortunately it wasn’t, so what’s left?

In one of my older blogs I was mentioning the own created Edge security baseline

Deploying a Microsoft Edge security Baseline with Intune (call4cloud.nl)

In that same baseline, I was making sure the user will always automatically sign in with their work and school account and also we force synchronization of browser data to make sure the user his browser data is always synchronized

We are also making sure we are forcing the users to sign-in to the browser as shown below

I was wondering, what if Conditional Access and “Requiring a compliant device” could be interfering with the Automatic sign-on and synchronization?

It could definitely be an issue because Conditional Access could also interfere with the deployment of Microsoft Store apps and Windows licensing. But that wasn’t the case…. As the device was pretty much compliant and was having NO issues signing in to other Office 365 apps once I was signed in.

So I decided to check out my Edge user data in my local AppData. Hopefully, there were any crash reports available in the Crashpad folder

But as shown above, no reports for me to check out.. so Edge didn’t crash? Microsoft Edge just couldn’t be opened. Looking in that same folder I spotted a “lockfile“. Mmm, a lockfile… seems that file is created because it locks something? When trying to delete that file, it told me the lockfile was already opened by Microsoft Edge

As shown above, MSEdge.exe was already opened even when I didn’t do anything! Let’s try it again! After reinstalling the device again, I decided to take a look, if msedge.exe was also opened at the Account ESP Phase

After the device finished the ESP Account phase, I made sure I added the Command Line column first. After adding the additional column I immediately spotted that the 6 instances from Edge were still running.

It showed me the parameter —no-startup-window. Stupid as I am I just opened Regedit and started searching for that specific line.

After one minute of waiting and staring at my screen, it showed me something nice. Please remember, remember the on-logon-startup-boost and AutoRunOnlogon set to 1 for now.

Before closing Edge (as closing Edge from the Taskmgr should also solve it ) I was also curious about what process explorer has to say about the process

As shown above, I first checked out the “Threads” tab. It was showing me that the process state was waiting for a UserRequest (wait:userrequest)

I also tried to bring the msedge.exe process to the front but I guess as we can’t see it, process explorer also can’t bring this process to the front

But enough with this fun stuff. I closed Edge and immediately I could open Edge again.

4. Solving it

Our solution! Just tell people to reboot their device when they first log in and everything will be fine…! problem solved!

Of course not!!! That’s bad for user experience, right? But after closing Edge, we now have a working Edge again. Did you remember the ” on-logon-startup-boost ” I showed you earlier? Let’s say it out loud again! On Logon “Startup Boost”

I remembered a blog from Michael Niehaus, mentioning this….

The overhead of Edge on Windows 11 (and 10) – Out of Office Hours (oofhours.com)

After reading that blog, I was curious if Startup Boost got enabled. As shown below, somehow Startup Boost is active by default….

Okay, that’s odd, as I never noticed any release notes mentioning that this would be on by default. After spending a couple of minutes on Internet I noticed this Startup Boost FAQ

It shows me that if the device matches some hardware requirements, Startup Boost will be enabled by default! Screw that!! I opened Intune and added a nice additional setting to that same Edge Security baseline I created earlier

As shown above, I added the “Enable Startup Boost” and configured it to “Disabled”. I wiped and reenrolled my device again with Autopilot and guess what was working again! I could open Edge immediately, without having to close it first.

So for now… If you are also experiencing this behavior and you prefer a good user experience instead of asking the user to reboot you could disable “Startup Boost”. But let’s continue because there is still something I needed to check.

5. Always Require MFA?

While writing this blog, I was also trying to write my upcoming TPM blog, after finishing that one, I had a brainfart. When troubleshooting this issue, I was looking at the Conditional Access sign-in logs but I had too much focus on the “Require Compliant Devices” conditional access rule. By doing so, I forgot about another important Conditional Access Rule!

The above non-interactive sign-in log showed me the Microsoft Edge application was a failure? That’s odd because it was working. When taking a better look, it showed me it was failing upon “Always require MFA”

I guess I am now just thinking out loud… but as I was telling you in this blog, Windows Hello satisfies the MFA Requirement!

MFA, WHfB, Azure Ad Joined devices and the Sign-In reports (call4cloud.nl)

Guess what didn’t happen when MSedge.exe was launched during the account ESP Phase

As shown above, Edge was already launched in the background before showing me the Windows Hello screen. I decided to open Microsoft Edge again and was expecting an MFA prompt but as shown below it didn’t! It had an SSO to portal.office.com!

I guess we can also rule out the MFA Conditional Access Rule for now! So I guess we need to stick to the Disable Startup Boost option for now?

6. Microsoft Edge Updates

Just before posting this blog, I decided to do another rerun but this time with the “Windows Performance Recorder” configured to record (hopefully) the Microsoft Edge Browser

But, this time I noticed some behavior that I wasn’t expecting. As shown below, out of a sudden instead of doing nothing when I clicked on Edge, it showed me a message to sign in

That’s odd… because I didn’t change anything and this specific setting in the Edge Device Configuration Profile was still configured.

I didn’t change anything!!! So it needs to be a new Microsoft Edge Update that I wasn’t expecting. I opened the Microsoft Edge Program Files folder during OOBE and I noticed this new Edge version : 104.0.129.54

And of course, Microsoft Edge is also telling us, it’s up to and version 104.0.1293.54

When enrolling your device with Autopilot, in a normal situation the “MicrosoftEdgeUpdateTaskMachineCore” task will be launched

When taking a better look at this task, it will run “MicrosoftEdgeUpdate.exe” with the /c parameter

This task made sure my Microsoft Edge browser was updated to the latest Edge Version. As shown below, this version was released on 11-08-2022. This update fixed various bugs…. I guess that’s why the test I run on 08-08-2022 was still showing the issue!

Conclusion

Of course, I reached out to the product team to get more information about why this “Turbo Boost” was causing issues because disabling this option forever is also not a good option.

Luckily Microsoft Edge will be updated automatically during Autopilot! When Edge is updated to the latest version, this issue will be gone!