This week a short post about enabling Windows Automatic Redeployment form the login screen. It’s a follow up on enabling password reset and PIN reset from the login screen, as it enables another feature on the login screen, and a nice addition in combination with Windows AutoPilot. Windows Automatic Redeployment might be a familiar feature, but I couldn’t find much written information about it yet. In this post I’ll provide a brief introduction to Windows Automatic Redeployment, followed by the required configuration and the end-user experience.
Now let’s start with a brief introduction about Windows Automatic Redeployment. Starting with Windows 10, version 1709, administrators can use Windows Automatic Redeployment to quickly remove personal files, apps, and settings, by resetting Windows 10 devices from the login screen at any time. That reset will apply the original settings and device management enrollment, so the devices are ready to use once the reset is completed. The device management enrollment is related to Azure Active Directory and Microsoft Intune (or other third-party MDM-providers).
In other words, Windows Automatic Redeployment allows administrators to reset devices to a known good managed state while preserving the management enrollment. After Windows Automatic Redeployment is triggered, the devices are ready for use by standard users.
The configuration actually only contains one specific setting. To get that specific setting, the first step explains the location of the setting and the second step explains the usage of the setting.
Step 1: Get the required setting
The first step is to get the required setting. The Policy CSP contains CredentialProvider policies. One of those policies is DisableAutomaticReDeploymentCredentials. That policy is introduced in Windows 10, version 1709, and is used to enable or disable the visibility of the credential provider that triggers the reset on a device. This policy does not actually trigger the reset. This policy enables the administrator to authenticate and trigger the reset on the device. This setting supports the following values:
- 0 – Enable the visibility of the credentials for Windows Automatic Redeployment;
- 1 – Disable visibility of the credentials for Windows Automatic Redeployment.
Step 2: Configure the required setting
The second step is to actually configure the required setting to enable the option to automatically redeploy Windows from the login screen. In other words, the second step is to configure a device configuration profile with at least a custom OMA-URI setting. The following three steps walk through the creation of a new device configuration profile, including the required OMA-URI setting. After that simply assign the created profile to a user group.
|1||Open the Azure portal and navigate to Intune > Device configuration > Profiles;|
|2||On the Devices configuration – Profiles blade, click Create profile to open the Create profile blade;|
On the Create profile blade, provide the following information and click Create;
On the Custom OMA-URI Settings blade, provide the following information and click Add to open the Add row blade. On the Add row blade, provide the following information and click OK (and click OK in the Custom OMA-URI blade);
Let’s end this post by looking at the end-user experience. I’ll do that by showing how to trigger Windows Automatic Redeployment, followed by a screenshot of the start of the process and a screenshot of the end of the process.
To trigger the Windows Automatic Redeployment, press the combination of Ctrl ++ R on the login screen. As shown below, this will provide the user with the option to provide an administrator account to automatically redeploy Windows.
Once administrator credentials are provided the redeployment process will be triggered. As shown below, when the process is finished a success message will be shown.
Now the device is ready to go. Keep in mind that the device is still Azure AD joined and Microsoft Intune managed with the original account. So, the main use case for this reset is for information workers and students.
For more information about Windows Automatic Redeployment, please refer to this article about resetting devices with Windows Automatic Redeployment.
23 thoughts on “Enable Windows Automatic Redeployment from the login screen”
This is more ore less what could be done with a Provisioning Package with CleanPC trigger no ?
It seems that more and more settings are now moved to Autopilot and this is a good news !
CleanPC is not completely the same. Windows Automatic Redeployment removes all personal files, apps, and settings, and reset Windows to original settings and device management enrollment.
You don’t need to use a Custom OMA-URI Setting for this. It’s a setting in Device restrictions for Windows 10 devices under ‘General’. There’s a switch to allow Automatic Redeployment.
You’re correct. I initially missed that setting, but the idea behind that setting should be the same.
We even don’t need the OMA-URI anymore its in the General section of Windows 10 device restriction profile “Automatic re-deployment”. But remember any workstation admin could trigger the reset. Requirement is to have local administrator permissions. If we do not configure it only Intune Admins or the user itself could trigger a PBR reset
You’re correct. I initially missed that setting, but the idea behind that setting should be the same. About the administrator permissions, yes, any local administrator can trigger the redeployment. However, not every user can trigger the reset. Only when that user has administrator privileges. In an AutoPilot scenario a user can be a standard user.
Does anyone know what level of data-wiping Windows Automatic Redeployment uses to remove personal files?
What exactly do you mean? Like if it’s not possible to recover any of the old user data?
I’ve been looking at this feature as well and I can see scenarios for it when using AutoPilot and managing the computer with InTune and so on.
But in many cases we still rely on traditional OSD with CM/MDT.
If a client is deployed with a standard task sequence, say just OS + a few applications and updates, what state will the client be in if we use this function?
What’s the scenario that you’re thinking about? This feature does require a Azure AD joined device.
Does this get applied to devices or users? If users, does it get applied to all users or just a group of users that are permitted this function?
The scope of this setting is device.
When I apply this to a device and proceed with resetting the device, Intune doesn’t apply the policies to this device anymore. Is this by design or am I missing something important?
Automatic Redeployment is also a setting within the device restrictions (general) of Intune now, is this the same thing as you’re explaining here?
I haven’t noticed that specific behavior yet. Also yes that restriction settings is the same as the URI shown in this post.
Perhaps it has something to do with the OS Edition? I’m using Windows 10 Pro in this specific scenario, are you using Windows 10 Enterprise?
According to the docs of the Policy CSP it’s also for the pro edition.
Tested this out and it works quite well. The only issue is that the timezone and region settings are set to US rather than Australia as they were before the redeploy. Would like to be able to preserve those settings if possible.
Thank you, Ivan. Hopefully those options will come with future updates.
Do you know if the “automatic deployment” button can be hidden on the login screen via intune?
I’ve had a user reset their device inadvertently. I know that they received warning messages, before resetting the OS install, but I’d like to minimise that from happening with any other users.
What are you exactly referring to? Automatic redeployment requires a user to press Ctrl + Windows-button + R.
I think Michael was referring to the presence of the Auto Pilot reset button. It can be accessed by our PCs once a user clicks Sign-in Options, then an administrator password and username is required to proceed. Is there a way to hide this button? Our OS version is 1809 or later.
Ah, now I see. It seems that it comes with the configuration now…
PS: This is not required for remote Autopilot reset.