Windows 10 reset and wipe options explained

More and more Workspace ONE UEM features that are obvious to use on IOS and Android are coming to Windows 10 devices.

One of these features is the ability to remotely send a Wipe or Reset command to a device. This might seem like a trivial and easy feature, and is, however there are at least 5 different Wipe or Reset options available, and that number is growing. Depending on the use-case you might want to use a different command. I have created this blogpost to explain what Wipe and Reset command are available for Windows 10 and in what scenario you can use them.

Let us start with a quick overview which Reset and Wipe options are available, and what do they do according the documentation:

• Enterprise Wipe
  • An Enterprise Wipe will unenroll and remove all managed enterprise resources from the selected device, including applications and profiles.
    This action cannot be undone, and re-enrollment will be required for Workspace ONE to manage this device again.
• Enterprise Reset
  • Enterprise Reset restores a device to a ready-to-work state when a device is corrupted or has malfunctioning applications. It re-installs the Windows OS while preserving user data, user accounts and managed applications. The device will re-sync auto-deployed enterprise settings, policies, and apps after the reset while remaining managed by Workspace ONE.
• Device Wipe
  The ‘Device Wipe’ has a few sub options:
  • Wipe (Default)
    A Device Wipe removes all data, email, profiles and MDM capabilities and the device returns to a factory default state. This includes all personal user information if applicable. This action cannot be undone. Please proceed with caution.
  • Wipe Protected
    Wipe Protected performs a Device Wipe that cannot be circumvented by the user, in some device configurations this command may leave the device unable to boot.
  • Wipe and Persist Provisioning Data
    Wipe and Persist Provisioning Data will restore provisioning data (application and configuration PPKGs) after the wipe operation.

Let me add some additional information to consider regarding ‘Enterprise Wipe’:

1. Enterprise Wipe on Windows works different from Android/IOS, since there is no isolated ‘sandbox’ concept on Windows (yet).
   • On a mobile device an Enterprise Wipe will remove all apps and all the corporate data that is stored in the apps (e.g. cached mails)
   • On Windows and Mac an Enterprise Wipe will only uninstall the apps and unencrypt the hard disk. But all corporate data (Outlook cache, synced OneDrive files, local files) are not touched and will stay on the device. Thus, valuable corporate data will be left on the device with an unencrypted hard drive.
2. The default Wipe command in WS1 is ‘Enterprise Wipe’, for instance when a device is untrusted, the device will be ‘Enterprise Wiped’
3. On Windows and Mac only a ‘Device Wipe’ will delete all user profiles and therefore corporate data.

Each Wipe command serves a different use case. I have created this table to map the commands to some of the most popular use cases:

Use-case	action
Device is lost or stolen, and all data needs to be wiped	Wipe Protected
Device needs to be transferred to user B, and all personal data and apps from user A need to be removed	Wipe and Persist Provisioning Data or Enterprise Wipe
External/Contractor is using his own PC (BYOD) to work at customer. The contract is terminated, and all customer data needs to be removed, but personal data needs to stay on the device	Enterprise Wipe
Device is corrupted, i.e. Windows does not boot, or an application no longer works.	Enterprise Reset

This information will probably be enough to understand what wipe action to use for which scenario.

For completeness, here is a KB article that describes the difference between an Enterprise Wipe versus a Device Wipe for Workspace ONE:
https://kb.vmware.com/s/article/50103263

But there are some specific scenario’s and use-cases that require additional explanation. So the next part of this blog will be about those specifics. As you will understand after reading this, there are many options and it’s nearly impossible to be fully complete on covering all scenario’s, but I’ll do my best. Feel free to leave a comment if you have any questions or run into other behavior.

Enterprise Reset – additional info

An Enterprise Reset restores a device to a Ready to Work state when a device is corrupted or has malfunctioning apps. It re-installs the Windows OS while preserving user data, user accounts, managed apps, and MDM enrollment. The device will re-sync auto-deployed enterprise settings, policies, and apps after reset while remaining managed by Workspace ONE.

It does require Windows 10 version 1709+.

My colleague Darren Hirons created a good video that takes you through the whole process: https://youtu.be/M_FCplqCuoQ

An Enterprise Reset can be initiated from either the Workspace ONE console OR can be manually triggered by the user on the device (PC Reset – Keep my files). Note that the end user must be a local administrator on the system for them to initiate this.

Enterprise reset uses the C:\Recovery\OEM folder to store pre-reset and post-reset scripts, batch files to invoke agent reinstallation and reinitialization and the application data with the app deployment cache. This allows the device to be restored to the previous enrolled state.

Device Wipe – additional info

For Device Wipe, I do have a nice video: If you want to see how a Device Wipe works, please have a look at this video from Matt Evans: https://youtu.be/2gn2PT5U2X4

What about devices that are pre-registered or configured in the factory?

It’s pretty common to pre-configure devices before sending them to the end users, for instance there is Autopilot and also the option to use Factory Provisioning from Dell, HP and Lenovo. But what happens when you Wipe or Reset one of those devices, how do you get them back to a factory state?

Let’s cover Autopilot first, because that is an easy one. Autopilot is similar to Apple DEP; you pre-register the device centrally, so that the device will be guided through the OOBE (Out of the Box Experience) flow and automatically enrolls at the correct organization. Since this registration happens centrally, this will persist any Wipe or Reset command, and the device will simply go through the same process after the Wipe or Reset is completed.

If you haven’t configured Autopilot, but you do have AzureAD P1/2 licenses and have configured MDM Integration with Workspace ONE, then upon first logon at the OOBE screen, the device will join AzureAD and automatically enroll into Workspace ONE. Auto-deployed enterprise settings, policies, and apps will then download and install.

Factory Provisioning from Dell, HP or Lenovo is also a process to help users with OOBE, but adds more functions, like preloading applications, doing an on-prem AD join and running scripts. This will save a lot of time, and users can be up and running in minutes with all applications installed. This process uses 2 files: a .PPKG file that contains the applications installers and an unattend.xml that contains all the configuration. You can use the WS1 UEM console to create these 2 files and send them to the OEM. The PPKG is stored in the C:|\Recovery\Customization folder and reapplies post reset, however by default the unattend.xml is not stored on the local device, because it could contain sensitive information. That means it’s not possible to restore these Factory Provisioned devices back to their factory state.

However, my colleague Phil Helmling created a tool that can solve this. This tool reapplies the Workspace ONE Factory Provisioning unattend.xml as well as the PPKG when you perform a ‘Device Wipe and Persist Provisioning Data’. The tool is pretty straightforward; it copies the unattend.xml file, along with two scripts to C:\Recovery\OEM folder and can be installed using WS1 UEM.
https://github.com/helmlingp/apps_DeviceWipewProvisioning

Now for the last part of this blog, let’s go to an important exception: BitLocker.

What you need to know about Bitlocker

I’m working with a lot of customers and hear different use-cases every day. Each company has a different security policy, and some can be pretty strict. The default BitLocker CSP does not offer enough options to cover all these use-cases. Luckily Workspace ONE UEM works with an agent (Intelligent Hub) and therefore can offer more features and flexibility. Many features have been added to expand the BitLocker management capabilities, and two of those need some explanation, since they could cause conflicts with Wipe and Reset commands.

Force Encryption – Enabling this setting will force encryption on the device and immediately re-encrypt the device if BitLocker is manually turned off. Without this setting a regular user can suspend BitLocker temporarily, i.e. to make changes to the system, which could compromise the protection level. This setting is intended to prevent BitLocker from being suspended, so that the protection level is ensured.

Keep System Encrypted at All Times – Choose this option to retain encryption if the profile is removed, device is wiped, removed from Azure AD, disconnected from Work/School account, deleted from the console or Hub is uninstalled. This does not apply to Employee Owned devices.

As you can understand, those two settings could collide with a Wipe or Reset command, because who should win? Should the device stay encrypted, or should the Bitlocker profile be removed by the Wipe or Reset command?

These are the expected results of the two settings:

• Force Encryption – should allow a Wipe or Reset, even if that means Bitlocker should be suspended prior to initiating the wipe. Device will be un-encrypted after the Wipe or Reset command executed successfully.
• Keep System Encrypted at All Times – the device should stay encrypted, even after a Wipe or Reset action.

In most cases this works as expected, but not in all cases. It depends on what Wipe or Reset command you use, if you use static BitLocker recovery keys and some other variables. This could result in sometimes the Wipe or Reset command not executing correctly or the device ending up in a non-usable state. The product team is aware of this and will come with improvements. Just be aware of this and test in your own environment so you are prepared.

That’s it for now. I think I covered most scenario’s, but please let me know if you need more clarification on any of the topics.