Managing UEFI settings on Surface Pro 4

Back in April 2015 I wrote about how to manage UEFI Firmware settings on the Surface Pro 3 from Powershell. This option has not been available on Surface Pro 4 or Surface Book. I have been looking and waiting for a way to manage this on the Surface Pro 4, and the solution that has come is quite different from what I thought.

It is not possible to manage Surface Pro 4 or Book through Powershell.

Current and future generations of Surface devices, including Surface Pro 4 and Surface Book, use a unique UEFI firmware engineered by Microsoft specifically for these devices. You can change the settings manually on each device by entering the Surface UEFI settings during boot by pressing the Volume Up button and the Power button simultaneously. Hold the Volume Up button until the Surface logo is displayed, which indicates that the device has begun to boot. But this is not a good way to do this if you have more than 2-3 devices in your company and that is why Microsoft has launched Surface Enterprise Management mode (SEMM) and the Microsoft Surface UEFI Configurator Tool.

This tool will allow you to create configuration packages and protect the UEFI setup from tampering with a certificate. This also brings some requirements like having a running PKI in your environment.

The Microsoft Surface UEFI Configurator: 

This is where you create your different packages for managing your Surface UEFI settings in your environment. You can do 3 types of management from this tool.

  1. Create Configuration Packages
    • This is the package that enrolls into SEMM and configures the UEFI settings on your devices.
  2. Reset Package
    • This is a specific package created to reset/unenroll one devices from SEMM.
  3. Recovery Request
    • This is to respond to a recovery request to unenroll a Surface device from SEMM where a Reset Package operation is not an option.

So lets dig a little bit into each of these actions  in the tool.

Create the Configuration Package

Configuration packages are the main packages created to enroll and manage SEMM on your Surface Devices. You will need a certificate to be able to do this. For testing purpose you can manually generate a self-signed certificate in powershell.

For more information about this script and the requirements of the certificate, read this official post from Microsoft:

I will not repeat more about what is in the official post, but will show my experiences when testing this. Download the tool here: Surface Tools for IT

First look at the tool – click on Start to move on:



First we need to choose what kind of Surface Devices we want to support. I am chosing both. The next page will show the 3 different management options:


I started with creating a configuration package, which requires me to add the certificate to the tool.

We can also now add a password to block users from entering UEFI

After adding the certificate we go into the actual configuration of the package.

Here you see all options available and at the final page you get a number that you must remember when you should apply this package to a computer.

Install the Configuration Package

When you are installing this package you might also make Bitlocker go into recovery mode as you are reconfiguring boot settings. To make sure this does not happen you can temporary suspend Bitlocker when applying the package.

You will need to run the MSI package from a Admin-CMD prompt or do an unnatended installation. Clicking the MSI is not working:


And when you do this from CMD and bitlocker is enabled you will get this message telling you to disable bitlocker. I did a temporary suspend of bitlocker and it worked nicely.


After this package is installed you need to reboot the machine. And this cannot be done unnatended as you need to be physically present to input the certificate number provided when you build the package.


This is how this look at reboot, and this is why you need to be present physically to enroll devices into SEMM.


As you can see after enrollment into SEMM, the settings are locked down and the user is not able to change this.


I have blocked usage of MicroSD cards.


Reset and Unenrollment

To unenroll a device we have to options to do this. One way is to create a reset package for the device we want to reset, the other way is to request a reset from the device itself.

If the device does not have a functional OS and you want to unenroll it, you can enter UEFI manually and then go into the Enterprise Management tab and request  a reset by clicking Get started:


Choose the key for resetting SEMM on your device



Now you have 3 options on how to get your request delivered to your IT Admin. IT Admin then need to go into the UEFI Configurator tool and respond to your request and give you back the validaton.


The user enters the validation phrase and the device gets unenrolled from SEMM and reset back to it default settings in UEFI.

But if you have a running OS and want to do this a bit simpler, you can just get the serial number of the device, create a reset package (MSI) and run it on the device.


This will create a MSI package specifically for the Surface Device with that serial number. The serial number is easiest to find in the Surface App:


So is this useful? I do believe that for large enterprises who needs to control the UEFI settings on their Surface devices that this gives good control for IT. But the requirements around having a PKI and not be able to choose to run this without a certificate to just make initial settings on your devices makes this not so sweet for smaller companies or companies looking into cloud based management with Intune and Azure AD Join.

And I do miss the opportunity to do simple setting changes through Powershell.

What do you guys think?

4 Replies to “Managing UEFI settings on Surface Pro 4

  1. So there is currently no way of deploying UEFI settings to many Surface Pro 4 without implementing a PKI and using the certificates on the deployment package??? The only other way would it be manually changing the settings??

      1. The certificate is not the problem here, is having to be in front of the device on the Enroll process.
        To deploy 500 devices with 0 Touch, that generates a little bit of an Overhead.

        And if we do not want to enroll with this method and keep Pxe and Usb Boots disabled all the time after every build i have to manually go to the UEFI and disable them (since i need to enable to be able to build in the first place).

        Really dont like this solution.
        (thanks for the discussion tough)

        1. I agree that it is a real pain to have to be in front of the machine for initial enrollment, but based on my experience most enterprises have their devices go through IT anyways for initial OS Setup/Deployment. And if you do that, you can have MSI for all kind of settings and change it back and forth with this solution.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.