Working on pre-provisioning recently and, after booting up from a reseal, I was presented with the Windows login screen and the defaultuser0 account as the only available account to authenticate with. The device did not go back to OOBE ready for the user to enter their credentials and continue the onboarding process.

Security hardening was in place, so I dug into the policies and through testing and re-testing, I was able to discover that the following policy impacted pre-prov.
MSS: (AutoAdminLogon) Enable Automatic Logon – which was set to Disabled.
This is actually one of the CIS recommended policies for security hardening for Windows 10, so be aware.
From the CIS docs:
‘18.4.1 (L1) Ensure ‘MSS: (AutoAdminLogon) Enable Automatic Logon
(not recommended)’ is set to ‘Disabled’ (Automated)
Profile Applicability:
Level 1 (L1) – Corporate/Enterprise Environment (general use)
Description:
This setting is separate from the Welcome screen feature in Windows XP and Windows
Vista; if that feature is disabled, this setting is not disabled. If you configure a computer for
automatic logon, anyone who can physically gain access to the computer can also gain
access to everything that is on the computer, including any network or networks to which
the computer is connected. Also, if you enable automatic logon, the password is stored in
the registry in plaintext, and the specific registry key that stores this value is remotely
readable by the Authenticated Users group.
For additional information, see Microsoft Knowledge Base article 324737: How to turn on
automatic logon in Windows.
The recommended state for this setting is: Disabled.
Rationale:
If you configure a computer for automatic logon, anyone who can physically gain access to
the computer can also gain access to everything that is on the computer, including any
network or networks that the computer is connected to. Also, if you enable automatic
logon, the password is stored in the registry in plaintext. The specific registry key that
stores this setting is remotely readable by the Authenticated Users group. As a result, this
entry is appropriate only if the computer is physically secured and if you ensure that
untrusted users cannot remotely see the registry.’
Checking on this particular setting, Microsoft advises that this breaks Autopilot pre-provisioning. They don’t state the experience when using this, but here it is in all its glory!
Windows Autopilot – Policy Conflicts
Registry keys that affect Windows Autopilot for pre-provisioned deployment Registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\Automatic logon | Registry key: If the AutoAdminLogon registry key is set to 0 (disabled), this breaks Windows Autopilot pre-provisioning. |
Hope that helps someone trying to track down the defaultuser0 problem in Autopilot pre-provisioning.
Hey Paul, there is also an addition, if you set the User Fastlogin, it will also create a defaulUser100000 or defaulUser0.
CSP: Authentication/EnableFastFirstSignIn
Defaultuser100000 lol!
Hi Paul,
Thank you for this Blog. You have mentioned about security hardning. So, may I know what all things should be in place from security hardning perspective?
You should look at CIS or NCSC guidance to harden devices