Security items & baselines

Unexpected autopilot restart

Warning! An unexpected restart during autopilot ESP can happen if you assign a configuration component to a device group. Many enterprise organizations using a Cloud service to manage their workplace. There are a couple of ways to enforce a specific set of workplace configuration settings. For example; via a configuration item, security item, or configuration baseline. The workplace management engineers need to decide which one fits within their needs. Although they are over overlapping as well. You can split the configuration settings from the security configuration via one of the configuration options. This makes sense for me because the responsibility of workplace configuration and security configuration is not always the same person or even department.

The modern workplace configuration pyramid

Modern workplace configuration pyramid
Modern workplace configuration pyramid

The diagram left shows the configuration components in a pyramid hierarchy. At the top, the configuration-items are configured that must be enforced at all times. Followed by security items and the configuration items priority. The configuration items are often less important because they do not contain settings to work securely. However, the configuration settings are needed, so the users are more productive when for example the configuration of OneDrive – KFM is enforced.

Restart during autopilot ESP

The result after autopilot esp restart, the user needs to fill in their user name + password.
Result after ESP is restarted

If the workplace restarts during autopilot ESP and the user needs to fill in their username + password then is it likely caused by a security item or baseline that is assigned to a device group. This restart happens between the ESP device setup and accounts setup. However, the installation will continue and finish successfully, there is still a potential risk that the installation time is reached.

The table below is an overview of Endpoint manager configuration items that can result in a restart if you assign the configuration to a device group.

ComponentDescription
If a…

– Update – Windows 10 update ring
– Baseline – Windows 10 Security Baseline (aug ’20)
– Baseline Microsoft Defender for Endpoint baseline (V5)

– Endpoint security – Device control

and assigned to a device group.
Unfortunately, It’s unknown to me which settings are causing this issue. A workaround is to assign the policy to a user group. Remember if the policy is assigned to a Device group the workplace restarts during the ESP.
If the
Baseline – Microsoft Edge baseline
– Endpoint security – Microsoft Defender Antivirus
– Endpoint security – Windows Security experience
– Endpoint security – Encryption
– Endpoint security – Microsoft Defender Firewall

– Endpoint security – Attack surface reduction rules
– Endpoint security – Application control
– Endpoint Security – Web protection
The policies can be assigned to both the user and device groups. It does not result in a restart during the ESP
if
Endpoint security – Account protection and assigned to a device group.
It looks like the ESP is finalized when the user’s desktop is loaded successfully. However, the configuration and applications are still loaded, which are assigned to a user group. Note notification that the device is ready for use does not show up.

Secondly, you can also recognize this behavior because the Windows Hello enrollment wizard does not pop-up immediately (it does after restart or logoff initiated by the user).
Endpoint manager ESP restart overview (December 2020)

Eventlog EventID 1074

CloudExpierienceHostbroker.exe has initiated the restart to reconfigure the operating system - EventID 1074
Event ID 1074 – Cloudexpoeriencehostbroker.exe

You can find evidence in the System – Windows event log about restart during the autopilot. The process CloudExpierienceHostbroker.exe has initiated the restart to reconfigure the operating system.

2 comments

  1. Hi, the unexpected reboot is directly tied to the “DMA Guard” configuration inside the security basline. Setting it to “not configured” avoid the device to reboot during ESP. Also, the “Device Lock” configurations, if le ft to it’s default configuration will lock the screen during ESP. So setting both the DMA Guard and Device Lock to not configured, will solve the issue.

  2. Hi! I have been looking for this since it’s a deal breaker for going passwordless. If all works as intended, then the user end up in OOBE, which support passwordless through Microsoft Authenticator OR a FIDO2 security key. If this happens, the user is presented with the regular sign-in as shown above. if the user isn’t issues a Temporary Access Pass beforehand AND web sign-in is disabled on the computer there is NO way to sign in to th ecomputer without password. IF this is a 100% reproducable outcome of these policies being targeted to a device group, and there is no way the deployment can finish early, ie within the deployment time, this is an endless loop. If its possible to deploy in time anyway in some scenarios this is an intermittent loop. its not viable in any circumstance. I did not know the reason for this behaviour, so a huge thank you for this partial solution. ( I guess other future policies can create the same behaviour going forward, so partial.)

    I strongly recommend looking at and implementing passwordless strategies asap. this was holding me back for us and a bunch of customers.

Leave a Reply

Your email address will not be published. Required fields are marked *