Lock Windows Device

Expected Console Behavior

In Workspace ONE, you have the "Lock" command available in a device's detail view. For MacOS, that lock command will lock out the device entirely and require a code to be input to the device, given from the Workspace ONE console. This effectively will "lock out" a device so it is bricked until that code is input to the device. This is a useful command if a device is lost, stolen, or an employee who possesses the device is terminated. Compare that behavior to Windows, where that "Lock" command effectively locks the screen (Windows Key + L command), and allows the user, if authenticated, to login again. This article aims to recreate the MacOS lock behavior for Windows. 

Update 6/7/24:

In addition to the option below of leveraging bitlocker to lock out a user of a device, you can use a Windows change passcode command to also lock out a device. This is possible for non-directory Windows machines (not AD- or Entra ID-joined). The workflow for this is as follows - 

Details on the Windows password profile can be found here, and information on the "change passcode" option for Windows can be found here. 

How Can We Lock Out a Windows Device? (and key considerations)

The way we can prevent a user from logging back into a device is really one of two ways - (1) make their credentials invalid, or (2) trigger a bitlocker lockout. The former is great with a device joined to Azure AD (or on-prem AD with a line of sight to the domain controller). In this article, I am going to go over the latter, as this will work regardless of device/identity setup. But there are some key considerations with this method - (1) the device must be encrypted via bitlocker for this method to work, and (2) the device must be internet connected to receive the command (which would also be a requirement for an enterprise wipe command from an MDM, anyway)

Now that we've gotten the key considerations out of the way, let's discuss how we are going to trigger the bitlocker lockout on the device. We are going to push a script to the device to require bitlocker to have a recovery screen on next boot. Let's walk through the workflow if we want to lock the device entirely - 

Now that we've walked through how we'll accomplish this, let's set this up in Workspace ONE UEM and test it out on a machine.

🚨Before we begin, even though the below works for me in my environment and my testing, I advise this be tested isolated to one or two virtual machines, in a UAT or non-production environment, before rolling this out in production. This is to ensure that there are no adverse effects, and devices are left in a state that you desire. Note this is a fairly severe action to take, and can result in data loss on the endpoint. Proceed at your own discretion.

Setup

Prerequisite: that you have a Windows encryption profile created and assigned to all applicable devices in WS1 UEM at the top-level OG (or at least a parent OG to the child OG we create below). This will also ensure that encryption keys are escrowed in the console automatically. 

2. Next, go to Resources - Scripts. Add a Windows script.

3. Give it a name and description, such as the below.

4. Next, enter the following for the script: 

Language: PowerShell
 Execution Context & Privileges: System Context
 Execution Architecture: Auto
 Timeout: 30

Code: 

manage-bde -forcerecovery C:

Restart-computer -Force

Note: in the script I am hard-coding a bitlocker recovery on C:\. This can be coded in as a variable instead, though in my environment it's a safe bet that the OS drive is C:

5. Click next, and then click Save (there will be no variables to enter). Next we will need to assign the script. 

6. Give the assignment a name, and assign it to the OG that we created earlier. Then click Next. 

7. For the deployment trigger, check "Run Once Immediately" and click "Add". This way, once a device is moved into this OG, it will be triggered to lock once. 

8. Now that we have completed set up, let's see what happens when we move a device into the OG that this script is assigned to. 

Triggering the Lockout of the Windows device 

Device Behavior

After pushing the script, the device restarted after a few minutes, and prompts for the bitlocker key. This key is already escrowed in the UEM console as part of the Windows Encryption profile, and the user is unable to recover the bitlocker key since their account is disabled from accessing the self service portal in UEM. This would keep the device in a locked state until the bitlocker key is used from the UEM admin console.

Additional Notes