Windows Autopilot

Persistently disabling Shift-F10 in OOBE

A couple of months ago I did a blog post that talked about how to disable Shift-F10 during OOBE by creating a DisableCmdRequest.tag file in the right location.  I mentioned at the time that the file would be removed if you reset the OS, so you’d have to do some more work if you wanted to make sure that file was automatically recreated.  That work sounded simple enough to me, so I left it to the reader to do the rest.  But I guess others don’t agree with my assessment, so let’s revisit.

Attempt #1:  Installing a provisioning package during OOBE

First, we need a provisioning package that can create the file.  Since provisioning packages can run scripts, batch files, executables, etc., it can certainly do that.  The simplest is a batch file, so I created this three-liner (with the reboot needed so that Shift-F10 is indeed disabled):

mkdir %WINDIR%\Setup\Scripts
echo “Turn off Shift-F10” > %WINDIR%\Setup\Scripts\DisableCmdRequest.tag
shutdown.exe /r /t 0

You can then create a new provisioning package using the Windows Configuration Designer, specifying the “advanced” option where we can configure only a two settings, the command line to run a batch file and the batch file itself (added to the PPKG):


With that in place, you can use the “Export” option to create the PPKG, specifying an “OEM” owner when you export/build the PPKG (as you can choose to not reapply corporate PPKGs when you do a reset).  Then you need to test it.  The simplest way to do that is on a VM, and since VMs don’t easily support USB keys, it’s easiest to put the PPKG into an ISO so that you can attach it to the VM.  The command to create an ISO (which you can run from the “Deployment and Imaging Tools Environment” command prompt if you’ve installed the ADK with the deployment tools package):

oscdimg -n -d ISO DisableCmdRequest.iso

The next step is then to copy that ISO to where it can be mounted by the VM (e.g. a folder on the Hyper-V server).  Then mount it on a VM that has booted to the start of OOBE.  From the language/locale screen, press the Windows key five times and choose the option to install a provisioning package:


After you choose the “Install provisioning package” item, it will find the PPKG on the ISO, apply it, and reboot automatically.

After the device boots back up to the start of OOBE, make sure that Shift-F10 doesn’t work.  Then, continue through the OOBE process until you get to the desktop.  (How you do that doesn’t matter.  I chose to do an Azure AD Join.)  Once you get to the desktop, do an OS reset from Settings (or remotely if you want).  After the reset, the PPKG should be reapplied, so Shift-F10 should still be disabled. 

And depending on the reset options you chose, it would work just fine.  If you choose “keep your data” it also keeps the PPKG.  But if you choose to remove everything, the PPKG goes with it.  So that’s not quite what you want.

Attempt #2:  Staging the PPKG

As documented in the Windows 10 manufacturing documentation, you can stage a PPKG in the C:\Recovery\Customizations folder, where it will be automatically reapplied after a reset.  That sounds simple enough to do manually:

  • Boot up the device and go through OOBE in any manner you want (without the PPKG preinstalled – this isn’t to verify whether #1 works, but rather to see if #2 will apply the PPKG after a reset without any user intervention).
  • Create the C:\Recovery\Customizations folder and place the PPKG file from attempt #1 in the folder.
  • Reset the OS from Settings, Intune, etc.

After the reset completes, the device should go back to the start of OOBE.  And again, Shift-F10 doesn’t work because the DisableCmdRequest.tag file is present, reapplied as part of the reset process.  Success.

So you may need to do both (attempt #1 to set it for the current OS and #2 for the reset cases).  But it can be done.  Your OEM or reseller may be able to set something like this up for you so devices arrive preconfigured in this state.

I’ve zipped up all of the files I used (PPKG source files, scripts, ISO, etc.), attached below.


Categories: Windows Autopilot

4 replies »

  1. I am wondering about using option #2 for the Autopilot Branding script. We found recently that if we do an OS Reset Wipe, it will be reinstalled during ESP. However, if we do the Wipe maintaining device enrollment, all our Branding configurations done at ESP are gone (such as Start Menu layout).

    Is there a better way to rerun or maintain the config done in the Branding script when doing the Wipe?


    • Hmm, not sure. I’ve never really liked the “maintain enrollment” option. Did the Win32 app get reinstalled before a user signed in again? While you could package it all up into a PPKG, that’s even more work than setting up a Win32 app…