Contents

Surface
Deploy Surface devices
Windows Autopilot and Surface devices
Surface device compatibility with Windows 10 Long-Term Servicing Branch
Long-Term Servicing Branch for Surface devices
Deploy Windows 10 to Surface devices with MDT
Upgrade Surface devices to Windows 10 with MDT
Customize the OOBE for Surface deployments
Ethernet adapters and Surface deployment
Surface Deployment Accelerator
Step by step: Surface Deployment Accelerator
Using the Surface Deployment Accelerator deployment share
Battery Limit setting
Surface firmware and driver updates
Download the latest firmware and drivers for Surface devices
Manage Surface driver and firmware updates
Surface Dock Updater
Wake On LAN for Surface devices
Considerations for Surface and System Center Configuration Manager
Deploy Surface app with Microsoft Store for Business
Enable PEAP, EAP-FAST, and Cisco LEAP on Surface devices
Manage Surface UEFI settings
Advanced UEFI security features for Surface Pro 3
Surface Enterprise Management Mode
Enroll and configure Surface devices with SEMM
Unenroll Surface devices from SEMM
Use System Center Configuration Manager to manage devices with SEMM
Surface Diagnostic Toolkit for Business
Use Surface Diagnostic Toolkit for Business in desktop mode
 Run Surface Diagnostic Toolkit for Business using commands
Surface Data Eraser
Top support solutions for Surface devices
Change history for Surface documentation
 Surface
10/29/2018 • 2 minutes to read • Edit Online

This library provides guidance to help you deploy Windows on Microsoft Surface devices, keep those devices up to
date, and easily manage and support Surface devices in your organization.
For more information on planning for, deploying, and managing Surface devices in your organization, see the
Surface TechCenter.

In this section
TOPIC DESCRIPTION

Deploy Surface devices Get deployment guidance for your Surface devices including
information about MDT, OOBE customization, Ethernet
adaptors, and Surface Deployment Accelerator.

Surface firmware and driver updates Find out how to download and manage the latest firmware
and driver updates for your Surface device.

Considerations for Surface and System Center Configuration Get guidance on how to deploy and manage Surface devices
Manager with System Center Configuration Manager.

Deploy Surface app with Microsoft Store for Business Find out how to add and download Surface app with Microsoft
Store for Business, as well as install Surface app with
PowerShell and MDT.

Enable PEAP, EAP-FAST, and Cisco LEAP on Surface devices Find out how to enable support for PEAP, EAP-FAST, or Cisco
LEAP protocols on your Surface device.

Manage Surface UEFI settings Use Surface UEFI settings to enable or disable devices,
configure security settings, and adjust Surface device boot
settings.

Surface Enterprise Management Mode See how this feature of Surface devices with Surface UEFI
allows you to secure and manage firmware settings within
your organization.

Surface Data Eraser Find out how the Microsoft Surface Data Eraser tool can help
you securely wipe data from your Surface devices.

Top support solutions for Surface devices These are the top Microsoft Support solutions for common
issues experienced using Surface devices in an enterprise.

Change history for Surface documentation This topic lists new and updated topics in the Surface
documentation library.

Learn more
Certifying Surface Pro 4 and Surface Book as standard devices at Microsoft
Related topics
Surface TechCenter
Surface for IT pros blog
 Deploy Surface devices
10/3/2018 • 2 minutes to read • Edit Online

Get deployment guidance for your Surface devices including information about Microsoft Deployment Toolkit
(MDT), out-of-box-experience (OOBE ) customization, Ethernet adaptors, Surface Deployment Accelerator, and the
Battery Limit setting.

In this section
TOPIC DESCRIPTION

Windows Autopilot and Surface devices Find out how to remotely deploy and configure devices with
Windows Autopilot.

Surface device compatibility with Windows 10 Long-Term Find out about compatibility and limitations of Surface devices
Servicing Channel running Windows 10 Enterprise LTSC edition.

Deploy Windows 10 to Surface devices with MDT Walk through the recommended process of how to deploy
Windows 10 to your Surface devices with the Microsoft
Deployment Toolkit.

Upgrade Surface devices to Windows 10 with MDT Find out how to perform a Windows 10 upgrade deployment
to your Surface devices.

Customize the OOBE for Surface deployments Walk through the process of customizing the Surface out-of-
box experience for end users in your organization.

Ethernet adapters and Surface deployment Get guidance and answers to help you perform a network
deployment to Surface devices.

Surface Deployment Accelerator See how Microsoft Surface Deployment Accelerator provides a
quick and simple deployment mechanism for organizations to
reimage Surface devices.

Battery Limit setting Learn how to use Battery Limit, a UEFI setting that changes
how the Surface device battery is charged and may prolong its
longevity.

Related topics
Surface TechCenter
Surface for IT pros blog
 Windows Autopilot and Surface devices
10/29/2018 • 3 minutes to read • Edit Online

Windows Autopilot is a cloud-based deployment technology available in Windows 10. Using Windows Autopilot,
you can remotely deploy and configure devices in a truly zero-touch process right out of the box. Windows
Autopilot registered devices are identified over the internet at first boot using a unique device signature, known as
the hardware hash, and automatically enrolled and configured using modern management solutions such as Azure
Active Directory (AAD ) and Mobile Device Management (MDM ).
With Surface devices, you can choose to register your devices at the time of purchase when purchasing from a
Surface partner enabled for Windows Autopilot. New devices can be shipped directly to your end-users and will
be automatically enrolled and configured when the units are unboxed and turned on for the first time. This process
can eliminate need to reimage your devices as part of your deployment process, reducing the work required of
your deployment staff and opening up new, agile methods for device management and distribution.
In this article learn how to enroll your Surface devices in Windows Autopilot with a Surface partner and the
options and considerations you will need to know along the way. This article focuses specifically on Surface
devices, for more information about using Windows Autopilot with other devices, or to read more about Windows
Autopilot and its capabilities, see Overview of Windows Autopilot in the Windows Docs Library.

Prerequisites
Enrollment of Surface devices in Windows Autopilot with a Surface partner enabled for Windows Autopilot has
the following licensing requirements for each enrolled Surface device:
Azure Active Directory Premium – Required to enroll your devices in your organization and to automatically
enroll devices in your organization’s mobile management solution.
Mobile Device Management (such as Microsoft Intune) – Required to remotely deploy applications,
configure, and manage your enrolled devices.
Office 365 ProPlus – Required to deploy Microsoft Office to your enrolled devices.
These requirements are also met by the following solutions:
Microsoft 365 E3 or E5 (includes Azure Active Directory Premium, Microsoft Intune, and Office 365 ProPlus)
Or
Enterprise Mobility + Security E3 or E5 (includes Azure Active Directory Premium and Microsoft Intune)
Office 365 ProPlus, E3, or E5 (includes Office 365 ProPlus)

NOTE
Deployment of devices using Windows Autopilot to complete the Out-of-Box Experience (OOBE) is supported without these
prerequisites, however will yield deployed devices without applications, configuration, or enrollment in a management
solution and is highly discouraged.

Windows version considerations

Support for broad deployments of Surface devices using Windows Autopilot, including enrollment performed by
Surface partners at the time of purchase, requires devices manufactured with or otherwise installed with Windows
10 Version 1709 (Fall Creators Update). Windows 10 Version 1709 uses a secure 4096-bit (4k) hash value to
uniquely identify devices for Windows Autopilot that is necessary for deployments at scale.
Surface device support
Surface devices with support for out-of-box deployment with Windows Autopilot, enrolled during the purchase
process with a Surface partner, include the following devices, where the devices ship from the factory with
Windows 10 Version 1709:
Surface Pro (Model 1796)
Surface Book 2
Surface Laptop
Surface Studio
Surface Go

Surface partners enabled for Windows Autopilot

Enrolling Surface devices in Windows Autopilot at the time of purchase is a capability provided by select Surface
partners that are enabled with the capability to identify individual Surface devices during the purchase process and
perform enrollment on an organization’s behalf. Devices enrolled by a Surface partner at time of purchase can be
shipped directly to users and configured entirely through the zero-touch process of Windows Autopilot, Azure
Active Directory, and Mobile Device Management.
When you purchase Surface devices from a Surface partner enabled for Windows Autopilot, your new devices can
be enrolled in your Windows Autopilot deployment for you by the partner. Surface partners enabled for Windows
Autopilot include:
SHI
Insight
Atea
 Surface device compatibility with Windows 10 Long-
Term Servicing Channel (LTSC)
5/18/2018 • 3 minutes to read • Edit Online

Surface devices are designed to provide best-in-class experiences in productivity and general-purpose scenarios.
Regular updates enable Surface devices to bring to life new innovations and to evolve with the new capabilities
delivered by Windows 10 Feature Updates. Feature Updates are available only in Windows 10 Pro or Windows
10 Enterprise editions that receive continuous updates through the Semi-Annual Channel (SAC ).
In contrast to the SAC servicing option, formerly known as the Current Branch (CB ) or Current Branch for
Business (CBB ) servicing options, you cannot select the Long-Term Servicing Channel (LTSC ) option in Windows
10 settings. To use the LTSC servicing option, you must install a separate edition of Windows 10 Enterprise,
known as Windows 10 Enterprise LTSC, formerly known as Windows 10 Enterprise LTSB (Long-Term Servicing
Branch. In addition to providing an extended servicing model, the Windows 10 Enterprise LTSC edition also
provides an environment with several Windows components removed. The core Surface experiences that are
impacted by LTSC include:
Windows Feature Updates, including enhancements such as:
Improvements to Direct Ink and palm rejection provided in Windows 10, version 1607 (also referred to
as the Anniversary Update)
Improved support for high DPI applications provided in Windows 10, version 1703 (also referred to as
the Creators Update)
Pressure sensitivity settings provided by the Surface app
The Windows Ink Workspace
Key touch-optimized in-box applications including Microsoft Edge, OneNote, Calendar, and Camera
The use of the Windows 10 Enterprise LTSC environment on Surface devices results in sub-optimal end-user
experiences and you should avoid using it in environments where users want and expect a premium, up-to-date
user experience.
The LTSC servicing option is designed for device types and scenarios where the key attribute is for features or
functionality to never change. Examples include systems that power manufacturing or medical equipment, or
embedded systems in kiosks, such as ATMs or airport ticketing systems.

NOTE
For general information about Windows servicing branches, including LTSC, see Overview of Windows as a service.

As a general guideline, devices that fulfill the following criteria are considered general-purpose devices and should
be paired with Windows 10 Pro or Windows 10 Enterprise using the Semi-Annual Channel servicing option:
Devices that run productivity software such as Microsoft Office
Devices that use Microsoft Store applications
Devices that are used for general Internet browsing (for example, research or access to social media)
Before you choose to use Windows 10 Enterprise LTSC edition on Surface devices, consider the following
limitations:
 Driver and firmware updates are not explicitly tested against releases of Windows 10 Enterprise LTSC.
If you encounter problems, Microsoft Support will provide troubleshooting assistance. However, due to the
servicing nature of the Windows LTSC, issue resolution may require that devices be upgraded to a more
recent version of Windows 10 Enterprise LTSC, or to Windows 10 Pro or Enterprise with the SAC servicing
option.
Surface device replacements (for example, devices replaced under warranty) may contain subtle variations
in hardware components that require updated device drivers and firmware. Compatibility with these
updates may require the installation of a more recent version of Windows 10 Enterprise LTSC or Windows
10 Pro or Enterprise with the SAC servicing option.

NOTE
Organizations that standardize on a specific version of Windows 10 Enterprise LTSC may be unable to adopt new
generations of Surface hardware without also updating to a later version of Windows 10 Enterprise LTSC or Windows 10 Pro
or Enterprise. For more information, see the How will Windows 10 LTSBs be supported? topic in the Supporting the
latest processor and chipsets on Windows section of Lifecycle Policy FAQ—Windows products.

Surface devices running Windows 10 Enterprise LTSC edition will not receive new features. In many cases these
features are requested by customers to improve the usability and capabilities of Surface hardware. For example,
new improvements for High DPI applications in Windows 10, version 1703. Customers that use Surface devices
in the LTSC configuration will not see the improvements until they either update to a new Windows 10 Enterprise
LTSC release or upgrade to a version of Windows 10 with support for the SAC servicing option.
Devices can be changed from Windows 10 Enterprise LTSC to a more recent version of Windows 10 Enterprise,
with support for the SAC servicing option, without the loss of user data by performing an upgrade installation.
You can also perform an upgrade installation on multiple devices by leveraging the Upgrade Task Sequence
Templates available in the Microsoft Deployment Toolkit (MDT) and System Center Configuration Manager. For
more information, see Upgrade Surface devices to Windows 10 with Microsoft Deployment Toolkit.
 Long-Term Servicing Branch (LTSB) for Surface
devices
5/10/2018 • 2 minutes to read • Edit Online

WARNING
For updated information on this topic, see Surface device compatibility with Windows 10 Long-Term Servicing Channel. For
additional information on this update, see the Documentation Updates for Surface and Windows 10 LTSB Compatibility post
on the Surface Blog for IT Pros.

General-purpose Surface devices running Long-Term Servicing Branch (LTSB ) are not supported. As a general
guideline, if a Surface device runs productivity software, such as Microsoft Office, it is a general-purpose device
that does not qualify for LTSB and should instead run Current Branch (CB ) or Current Branch for Business (CBB ).

NOTE
For more information about the servicing branches, see Overview of Windows as a service.

LTSB prevents Surface devices from receiving critical Windows 10 feature updates and certain non-security
servicing updates. Customers with poor experiences using Surface devices in the LTSB configuration will be
instructed to upgrade to CB or CBB. Furthermore, the Windows 10 Enterprise LTSB edition removes core features
of Surface devices, including seamless inking and touch-friendly applications. It does not contain key in-box
applications including Microsoft Edge, OneNote, Calendar or Camera. Therefore, productivity is impacted and
functionality is limited. LTSB is not supported as a suitable servicing solution for general-purpose Surface devices.
General-purpose Surface devices are intended to run CB or CBB to receive full servicing and firmware updates
and forward compatibility with the introduction of new Surface features. With CB, feature updates are available as
soon as Microsoft releases them. Customers in the CBB servicing model receive the same build of Windows 10 as
those in CB, at a later date.
Surface devices in specialized scenarios–such as PCs that control medical equipment, point-of-sale systems, and
ATMs–may consider the use of LTSB. These special-purpose systems typically perform a single task and do not
require feature updates as frequently as other devices in the organization.

Related topics
Surface TechCenter
Surface for IT pros blog
 Deploy Windows 10 to Surface devices with Microsoft
Deployment Toolkit
5/10/2018 • 54 minutes to read • Edit Online

Applies to
Surface Studio
Surface Pro 4
Surface Book
Surface 3
Windows 10
This article walks you through the recommended process to deploy Windows 10 to Surface devices with
Microsoft deployment technologies. The process described in this article yields a complete Windows 10
environment including updated firmware and drivers for your Surface device along with applications like
Microsoft Office 365 and the Surface app. When the process is complete, the Surface device will be ready for use
by the end user. You can customize this process to include your own applications and configuration to meet the
needs of your organization. You can also follow the guidance provided in this article to integrate deployment to
Surface devices into existing deployment strategies.
By following the procedures in this article, you can create an up-to-date reference image and deploy this image to
your Surface devices, a process known as reimaging. Reimaging will erase and overwrite the existing environment
on your Surface devices. This process allows you to rapidly configure your Surface devices with identical
environments that can be configured to precisely fit your organization’s requirements.
An alternative to the reimaging process is an upgrade process. The upgrade process is non-destructive and
instead of erasing the existing environment on your Surface device, it allows you to install Windows 10 while
retaining your user data, applications, and settings. You can read about how to manage and automate the upgrade
process of Surface devices to Windows 10 at Upgrade Surface devices to Windows 10 with MDT.
The goal of the deployment process presented in this article is automation. By leveraging the many technologies
and tools available from Microsoft, you can create a process that requires only a single touch on the devices being
deployed. The automation can load the deployment environment; format the device; prepare an updated Windows
image with the drivers required for the device; apply that image to the device; configure the Windows
environment with licensing, membership in a domain, and user accounts; install applications; apply any Windows
updates that were not included in the reference image; and log out.
By automating each aspect of the deployment process, you not only greatly decrease the effort involved, but you
create a process that can be easily repeated and where human error becomes less of a factor. Take for example a
scenario where you create a reference image for the device manually, but you accidentally install conflicting
applications and cause the image to become unstable. In this scenario you have no choice but to begin again the
manual process of creating your image. If in this same scenario you had automated the reference image creation
process, you could repair the conflict by simply editing a step in the task sequence and then re-running the task
sequence.

Deployment tools
The deployment process described in this article leverages a number of Microsoft deployment tools and
technologies. Some of these tools and technologies are included in Windows client and Windows Server, such as
Hyper-V and Windows Deployment Services (WDS ), while others are available as free downloads from the
Microsoft Download Center.
Microsoft Deployment Toolkit
The Microsoft Deployment Toolkit (MDT) is the primary component of a Windows deployment. It serves as a
unified interface for most of the Microsoft deployment tools and technologies, such as the Windows Assessment
and Deployment Kit (Windows ADK), Windows System Image Manager (Windows SIM ), Deployment Image
Servicing and Management (DISM ), User State Migration Tool (USMT), and many other tools and technologies.
Each of these is discussed throughout this article. The unified interface, called the Deployment Workbench,
facilitates automation of the deployment process through a series of stored deployment procedures, known as a
task sequence. Along with these task sequences and the many scripts and tools that MDT provides, the resources
for a Windows deployment (driver files, application installation files, and image files) are stored in a network share
known as the deployment share.
You can download and find out more about MDT at Microsoft Deployment Toolkit.
Windows Assessment and Deployment Kit
Although MDT is the tool you will interact with most during the deployment process, the deployment tools found
in the Windows ADK perform most of the deployment tasks during the deployment process. The resources for
deployment are held within the MDT deployment share, but it is the collection of tools included in Windows ADK
that access the image files, stage drivers and Windows updates, run the deployment experience, provide
instructions to Windows Setup, and back up and restore user data.
You can download and find out more about the Windows ADK at Download the Windows ADK.
Windows 10 installation media
Before you can perform a deployment with MDT, you must first supply a set of operating system installation files
and an operating system image. These files and image can be found on the physical installation media (DVD ) for
Windows 10. You can also find these files in the disk image (ISO file) for Windows 10, which you can download
from the Volume Licensing Service Center (VLSC ).

NOTE
The installation media generated from the Get Windows 10 page differs from physical media or media downloaded from the
VLSC, in that it contains an image file in Electronic Software Download (ESD) format rather than in the Windows Imaging
(WIM) format. Installation media with an image file in WIM format is required for use with MDT. Installation media from the
Get Windows 10 page cannot be used for Windows deployment with MDT.

Windows Server
Although MDT can be installed on a Windows client, to take full advantage of Windows Deployment Services’
ability to network boot, a full Windows Server environment is recommended. To provide network boot for UEFI
devices like Surface with WDS, you will need Windows Server 2008 R2 or later.

NOTE
To evaluate the deployment process for Surface devices or to test the deployment process described in this article with the
upcoming release of Windows Server 2016, you can download evaluation and preview versions from the TechNet Evaluation
Center.

Windows Deployment Services

Windows Deployment Services (WDS ) is leveraged to facilitate network boot capabilities provided by the Preboot
Execution Environment (PXE ) server. The boot media generated by MDT is loaded onto the Surface device simply
by pressing Enter at the prompt when the device attempts to boot from the attached network adapter or Surface
Dock.
Hyper-V virtualization platform
The process of creating a reference image should always be performed in a virtual environment. When you use a
virtual machine as the platform to build your reference image, you eliminate the need for installation of additional
drivers. The drivers for a Hyper-V virtual machine are included by default in the factory Windows 10 image. When
you avoid the installation of additional drivers – especially complex drivers that include application components
like control panel applications – you ensure that the image created by your reference image process will be as
universally compatible as possible.

NOTE
A Generation 1 virtual machine is recommended for the preparation of a reference image in a Hyper-V virtual environment.

Because customizations are performed by MDT at the time of deployment, the goal of reference image creation is
not to perform customization but to increase performance during deployment by reducing the number of actions
that need to occur on each deployed device. The biggest action that can slow down an MDT deployment is the
installation of Windows updates. When MDT performs this step during the deployment process, it downloads the
updates on each deployed device and installs them. By installing Windows updates in your reference image, the
updates are already installed when the image is deployed to the device and the MDT update process only needs to
install updates that are new since the image was created or are applicable to products other than Windows (for
example, Microsoft Office updates).

NOTE
Hyper-V is available not only on Windows Server, but also on Windows clients, including Professional and Enterprise editions
of Windows 8, Windows 8.1, and Windows 10. Find out more at Client Hyper-V on Windows 10 and Client Hyper-V on
Windows 8 and Windows 8.1 in the TechNet Library. Hyper-V is also available as a standalone product, Microsoft Hyper-V
Server, at no cost. You can download Microsoft Hyper-V Server 2012 R2 or Microsoft Hyper-V Server 2016 Technical
Preview from the TechNet Evaluation Center.

Surface firmware and drivers

For your deployed Windows environment to function correctly on your Surface devices, you will need to install
the drivers used by Windows to communicate with the components of your device. These drivers are available for
download in the Microsoft Download Center for each Surface device. You can find the correct Microsoft
Download Center page for your device at Download the latest firmware and drivers for Surface devices.
When you browse to the specific Microsoft Download Center page for your device, you will notice that there are
two files available for download. One file is a Windows Installer (.msi) file. This file is used to update drivers on
devices that are already running Windows or that have device management solutions. The other file is an archive
(.zip) file. This file contains the individual driver files that are used during deployment, or for manual installation
with Device Manager. The file that you will need to download is the .zip archive file. You can read more about the
difference between the firmware and driver pack file types at Manage Surface driver and firmware updates.
In addition to the driver files that help Windows communicate with the hardware components of the Surface
device, the .zip file you download will also contain firmware updates. These firmware updates will update the
instructions used by the device hardware to communicate between components and Windows. The firmware of
Surface device components is updated by installation of specific driver files and thus is installed along with the
other drivers during deployment. The firmware of an out-of-date Surface device is thus updated when the device
reboots during and after the Windows deployment process.

NOTE
Beginning in Windows 10, the drivers for Surface devices are included in the Windows Preinstallation Environment (WinPE).
In earlier versions of Windows, specific drivers (like network drivers) had to be imported and configured in MDT for use in
WinPE to successfully deploy to Surface devices.
Application installation files
In addition to the drivers that are used by Windows to communicate with the Surface device’s hardware and
components, you will also need to provide the installation files for any applications that you want to install on your
deployed Surface devices. To automate the deployment of an application, you will also need to determine the
command-line instructions for that application to perform a silent installation. In this article, the Surface app and
Microsoft Office 365 will be installed as examples of application installation. The application installation process
can be used with any application with installation files that can be launched from command line.

NOTE
If the application files for your application are stored on your organization’s network and will be accessible from your Surface
devices during the deployment process, you can deploy that application directly from that network location. To use
installation files from a network location, use the Install Application Without Source Files or Elsewhere on the Network
option in the MDT New Application Wizard, which is described in the Import applications section later in this article.

Microsoft Surface Deployment Accelerator

If you want to deploy only to Surface devices or you want an accelerated method to perform deployment to
Surface devices, you can use the Microsoft Surface Deployment Accelerator to generate an MDT deployment
share complete with Surface device drivers, Surface apps, and pre-configured task sequences to create a reference
image and perform deployment to Surface devices. Microsoft Surface Deployment Accelerator can automatically
import boot images into WDS and prepare WDS for network boot (PXE ). You can download the Microsoft
Surface Deployment Accelerator from the Surface Tools for IT page in the Microsoft Download Center.
Install the deployment tools
Before you can configure the deployment environment with Windows images, drivers, and applications, you must
first install the deployment tools that will be used throughout the deployment process. The three main tools to be
installed are WDS, Windows ADK, and MDT. WDS provides the capacity for network boot, Windows ADK
provides several deployment tools that perform specific deployment tasks, and MDT provides automation and a
central interface from which to manage and control the deployment process.
To boot from the network with either your reference virtual machines or your Surface devices, your deployment
environment must include a Windows Server environment. The Windows Server environment is required to
install WDS and the WDS PXE server. Without PXE support, you will be required to create physical boot media,
such as a USB stick to perform your deployment – MDT and Windows ADK will still be required, but Windows
Server is not required. Both MDT and Windows ADK can be installed on a Windows client and perform a
Windows deployment.

NOTE
To download deployment tools directly to Windows Server, you must disable Internet Explorer Enhanced Security
Configuration. On Windows Server 2012 R2, this can be performed directly through the Server Manager option on the
Local Server tab. In the Properties section, IE Enhanced Security Configuration can be found on the right side. You may
also need to enable the File Download option for the Internet zone through the Security tab of Internet Options.

Install Windows Deployment Services

Windows Deployment Services (WDS ) is a Windows Server role. To add the WDS role to a Windows Server 2012
R2 environment, use the Add Roles and Features Wizard, as shown in Figure 1. Start the Add Roles and Features
Wizard from the Manage button of Server Manager. Install both the Deployment Server and Transport Server
role services.
Figure 1. Install the Windows Deployment Services server role
After the WDS role is installed, you need to configure WDS. You can begin the configuration process from the
WDS node of Server Manager by right-clicking your server’s name and then clicking Windows Deployment
Services Management Console. In the Windows Deployment Services window, expand the Servers node to
find your server, right-click your server, and then click Configure in the menu to start the Windows Deployment
Services Configuration Wizard, as shown in Figure 2.

Figure 2. Configure PXE response for Windows Deployment Services

 NOTE
Before you configure WDS make sure you have a local NTFS volume that is not your system drive (C:) available for use with
WDS. This volume is used to store WDS boot images, deployment images, and configuration.

Using the Windows Deployment Services Configuration Wizard, configure WDS to fit the needs of your
organization. You can find detailed instructions for the installation and configuration of WDS at Windows
Deployment Services Getting Started Guide for Windows Server 2012. On the PXE Server Initial Settings page,
be sure to configure WDS so that it will respond to your Surface devices when they attempt to boot from the
network. If you have already installed WDS or need to change your PXE server response settings, you can do so
on the PXE Response tab of the Properties of your server in the Windows Deployment Services Management
Console.

NOTE
You will add boot images to WDS when you update your boot images in MDT. You do not need to add boot images or
Windows images to WDS when you configure the role.

Install Windows Assessment and Deployment Kit

To install Windows ADK, run the Adksetup.exe file that you downloaded from Download the Windows ADK.
Windows ADK must be installed before MDT. You should always download and use the most recent version of
Windows ADK. A new version is usually released corresponding with each new version of Windows.

NOTE
You can also use the Adksetup.exe file to download the Windows ADK installation files locally for use on other devices.

When you get to the Select the features you want to install page, you only need to select the Deployment
Tools and Windows Preinstallation Environment (Windows PE ) check boxes to deploy Windows 10 using
MDT, as shown in Figure 3.
Figure 3. Only Deployment Tools and Windows PE options are required for deployment with MDT
Install Microsoft Deployment Toolkit
After the Windows ADK installation completes successfully, you can install MDT. When you download MDT,
ensure that you download the version that matches the architecture of your deployment server environment. For
Windows Server the architecture is 64-bit. Download the MDT installation file that ends in x64. When MDT is
installed you can use the default options during the installation wizard, as shown in Figure 4.

Figure 4. Install the Microsoft Deployment Toolkit with default options

Before you can open the MDT Deployment Workbench, you must enable execution of scripts in PowerShell. If you
do not do this, the following error message may be displayed: "Initialization Error PowerShell is required to use
the Deployment Workbench. Please install PowerShell then relaunch Deployment Workbench."
To enable the execution of scripts, run the following cmdlet in PowerShell as an Administrator:
Set-ExecutionPolicy RemoteSigned -Scope CurrentUser

Create a reference image

Now that you have installed the required tools, you can begin the first step of customizing your deployment
environment to your needs – create a reference image. Because the reference image should be created in a virtual
machine where there is no need for drivers to be installed, and because the reference image will not include
applications, you can use the MDT deployment environment almost entirely with default settings.
Create a deployment share
Now that you have the tools installed, the next step is to configure MDT for the creation of a reference image.
Before you can perform the process of creating a reference image, MDT needs to be set up with a repository for
scripts, images, and other deployment resources. This repository is known as the deployment share. After the
deployment share is created, you must supply MDT with a complete set of Windows 10 installation files, the last
set of tools required before MDT can perform reference image creation.
To create the deployment share, follow these steps:
1. Open the Deployment Workbench from your Start menu or Start screen, as shown in Figure 5.

Figure 5. The MDT Deployment Workbench

2. Right-click the Deployment Shares folder, and then click New Deployment Share to start the New
Deployment Share Wizard, as shown in Figure 6.
 Figure 6. The Summary page of the New Deployment Share Wizard
3. Create a new deployment share with New Deployment Share Wizard with the following steps:
Path – Specify a local folder where the deployment share will reside, and then click Next.

NOTE
Like the WDS remote installation folder, it is recommended that you put this folder on an NTFS volume that
is not your system volume.

Share – Specify a name for the network share under which the local folder specified on the Path
page will be shared, and then click Next.

NOTE
The share name cannot contain spaces.

NOTE
You can use a Dollar Sign ($) to hide your network share so that it will not be displayed when users browse
the available network shares on the server in File Explorer.

Descriptive Name – Enter a descriptive name for the network share (this descriptive name can
contain spaces), and then click Next. The descriptive name will be the name of the folder as it
appears in the Deployment Workbench.
 Options – You can accept the default options on this page. Click Next.
Summary – Review the specified configuration on this page before you click Next to begin creation of
the deployment share.
Progress – While the deployment share is being created, a progress bar is displayed on this page to
indicate the status of the deployment share creation process.
Confirmation – When the deployment share creation process completes, the success of the process is
displayed on this page. Click Finish to complete the New Deployment Share Wizard.
4. When the New Deployment Share Wizard is complete, you can expand the Deployment Shares folder to
find your newly created deployment share.
5. You can expand your deployment share, where you will find several folders for the resources, scripts, and
components of your MDT deployment environment are stored.
To secure the deployment share and prevent unauthorized access to the deployment resources, you can create a
local user on the deployment share host and configure permissions for that user to have read-only access to the
deployment share only. It is especially important to secure access to the deployment share if you intend to
automate the logon to the deployment share during the deployment boot process. By automating the logon to the
deployment share during the boot of deployment media, the credentials for that logon are stored in plaintext in
the bootstrap.ini file on the boot media.

NOTE
If you intend to capture images (such as the reference image) with this user, the user must also have write permission on the
Captures folder in the MDT deployment share.

You now have an empty deployment share that is ready for you to add the resources that will be required for
reference image creation and deployment to Surface devices.
Import Windows installation files
The first resources that are required to perform a deployment of Windows are the installation files from Windows
10 installation media. Even if you have an already prepared reference image, you still need to supply the unaltered
installation files from your installation media. The source of these files can be a physical disk, or it can be an ISO
file like the download from the Volume Licensing Service Center (VLSC ).

NOTE
A 64-bit operating system is required for compatibility with Surface Studio, Surface Pro 4, Surface Book, Surface Pro 3, and
Surface 3.

To import Windows 10 installation files, follow these steps:

1. Right-click the Operating Systems folder under your deployment share in the Deployment Workbench,
and then click New Folder to open the New Folder page, as shown in Figure 7.
 Figure 7. Create a new folder on the New Folder page
2. On the New Folder page a series of steps is displayed, as follows:
General Settings – Enter a name for the folder in the Folder Name field (for example, Windows 10
Enterprise), add any comments you want in the Comments field, and then click Next.
Summary – Review the specified configuration of the new folder on this page, and then click Next.
Progress – A progress bar will be displayed on this page while the folder is created. This page will likely
pass very quickly.
Confirmation – When the new folder has been created, a Confirmation page displays the success of
the operation. Click Finish to close the New Folder page.
3. Expand the Operating Systems folder to see the newly created folder.
4. Right-click the newly created folder, and then click Import Operating System to launch the Import
Operating System Wizard, as shown in Figure 8.
 Figure 8. Import source files with the Import Operating System Wizard
5. The Import Operating System Wizard walks you through the import of your operating system files, as
follows:
OS Type – Click Full Set of Source Files to specify that you are importing the Windows source files
from installation media, and then click Next.
Source – Click Browse, move to and select the folder or drive where your installation files are found,
and then click Next.
Destination – Enter a name for the new folder that will be created to hold the installation files, and then
click Next.
Summary – Review the specified configuration on this page before you click Next to begin the import
process.
Progress – While the installation files are imported, a progress bar is displayed on this page.
Confirmation – When the operating system import process completes, the success of the process is
displayed on this page. Click Finish to complete Import Operating System Wizard.
6. Expand the folder you created in Step 1 to see the entry for your newly imported installation files for Windows
10.
Now that you’ve imported the installation files from the installation media, you have the files that MDT needs to
create the reference image and you are ready to instruct MDT how to create the reference image to your
specifications.
Create reference image task sequence
As described in the Deployment tools section of this article, the goal of creating a reference image is to keep the
Windows environment as simple as possible while performing tasks that would be common to all devices being
deployed. You should now have a basic MDT deployment share configured with default options and a set of
unaltered, factory installation files for Windows 10. This simple configuration is perfect for reference image
creation because the deployment share contains no applications or drivers to interfere with the process.

NOTE
For some organizations keeping a simple deployment share without applications or drivers is the simplest solution for
creation of reference images. You can easily connect to more than one deployment share from a single Deployment
Workbench and copy images from a simple, reference-image-only deployment share to a production deployment share
complete with drivers and applications.

To create the reference image task sequence, follow these steps:

1. Right-click the Task Sequences folder under your deployment share in the Deployment Workbench, and
then click New Task Sequence to start the New Task Sequence Wizard, as shown in Figure 9.

Figure 9. Create a new task sequence to deploy and update a Windows 10 reference environment
2. The New Task Sequence Wizard presents a series of steps, as follows:
General Settings – Enter an identifier for the reference image task sequence in the Task Sequence ID
field, a name for the reference image task sequence in the Task Sequence Name field, and any
comments for the reference image task sequence in the Task Sequence Comments field, and then click
Next. >[!NOTE ] >The Task Sequence ID field cannot contain spaces and can be a maximum of 16
characters.
Select Template – Select Standard Client Task Sequence from the drop-down menu, and then click
Next.
Select OS – Navigate to and select the Windows 10 image you imported with the Windows 10
installation files, and then click Next.
 Specify Product Key – Click Do Not Specify a Product Key at This Time, and then click Next.
OS Settings – Enter a name, organization, and home page URL in the Full Name, Organization, and
Internet Explorer Home Page fields, and then click Next.
Admin Password – Click Use the Specified Local Administrator Password, enter a password in the
provided field, and then click Next. >[!NOTE ] >During creation of a reference image, any specified
Administrator password will be automatically removed when the image is prepared for capture with
Sysprep. During reference image creation, a password is not necessary, but is recommended to remain
in line with best practices for production deployment environments.
Summary – Review the specified configuration on this page before you click Next to begin creation of
the task sequence.
Progress – While the task sequence is created, a progress bar is displayed on this page.
Confirmation – When the task sequence creation completes, the success of the process is displayed on
this page. Click Finish to complete the New Task Sequence Wizard.
3. Select the Task Sequences folder, right-click the new task sequence you created, and then click Properties.
4. Select the Task Sequence tab to view the steps that are included in the Standard Client Task Sequence
template, as shown in Figure 10.

Figure 10. Enable Windows Update in the reference image task sequence
5. Select the Windows Update (Pre-Application Installation) option, located under the State Restore
folder.
6. Click the Options tab, and then clear the Disable This Step check box.
7. Repeat Step 4 and Step 5 for the Windows Update (Post-Application Installation) option.
8. Click OK to apply changes to the task sequence, and then close the task sequence properties window.
Generate and import MDT boot media
To boot the reference virtual machine from the network, the MDT deployment share first must be updated to
generate boot media with the resources that have been added in the previous sections.
To update the MDT boot media, follow these steps:
1. Right-click the deployment share in the Deployment Workbench, and then click Update Deployment
Share to start the Update Deployment Share Wizard, as shown in Figure 11.

Figure 11. Generate boot images with the Update Deployment Share Wizard
2. Use the Update Deployment Share Wizard to create boot images with the following process:
Options – Click Completely Regenerate the Boot Images, and then click Next. >[!NOTE ] >Because
this is the first time the newly created deployment share has been updated, new boot images will be
generated regardless of which option you select on the Options page.
Summary – Review the specified options on this page before you click Next to begin generation of
boot images.
Progress – While the boot images are being generated, a progress bar is displayed on this page.
Confirmation – When the boot images have been generated, the success of the process is displayed on
this page. Click Finish to complete the Update Deployment Share Wizard.
3. Confirm that boot images have been generated by navigating to the deployment share in File Explorer and
opening the Boot folder. The following files should be displayed, as shown in Figure 12:
LiteTouchPE_x86.iso
LiteTouchPE_x86.wim
LiteTouchPE_x64.iso
LiteTouchPE_x64.wim
Figure 12. Boot images displayed in the Boot folder after completion of the Update Deployment Share Wizard
To import the MDT boot media into WDS for PXE boot, follow these steps:
1. Open Windows Deployment Services from the Start menu or Start screen.
2. Expand Servers and your deployment server.
3. Click the Boot Images folder, as shown in Figure 13.
 Figure 13. Start the Add Image Wizard from the Boot Images folder
4. Right-click the Boot Images folder, and then click Add Boot Image to open the Add Image Wizard, as
shown in Figure 14.

Figure 14. Import the LiteTouchPE_x86.wim MDT boot image

5. The Add Image Wizard displays a series of steps, as follows:
Image File – Click Browse and navigate to the Boot folder in your deployment share, click
LiteTouchPE_x86.wim, click Open, and then click Next.
Image Metadata – Enter a name and description for the MDT boot media, or click Next to accept the
default options.
Summary – Review your selections to import a boot image into WDS, and then click Next.
Task Progress – A progress bar is displayed as the selected image file is copied into the WDS remote
installation folder. Click Finish when the task is complete to close the Add Image Wizard.

NOTE
Only the 32-bit boot image, LiteTouchPE_x86.wim, is required to boot from BIOS devices, including Generation 1 Hyper-V
virtual machines like the reference virtual machine.

If your WDS configuration is properly set up to respond to PXE clients, you should now be able to boot from the
network with any device with a network adapter properly configured for network boot (PXE ).

NOTE
If your WDS server resides on the same server as DHCP or in a different subnet than the devices you are attempting to
boot, additional configuration may be required. For more information, see Managing Network Boot Programs.

Deploy and capture a reference image

Your deployment environment is now set up to create a reference image for Windows 10 complete with Windows
Updates.
 NOTE
You cannot install version updates (such as Windows 10, Version 1511) in a reference image. To create a reference image
with a new version of Windows, you must use installation files from that version of Windows. When you install a version
update in Windows, it effectively performs an upgrade to a new version of Windows, and upgraded installations of Windows
cannot be prepared for deployment with Sysprep.

By using a fully automated task sequence in an MDT deployment share dedicated to reference image creation, you can
greatly reduce the time and effort required to create new reference images and it is the best way to ensure that your
organization is ready for feature updates and new versions of Windows 10.

You can now boot from the network with a virtual machine to run the prepared task sequence and generate a
reference image. When you prepare your virtual machine in Hyper-V for reference image creation, consider the
following:
Use a Generation 1 virtual machine for the simplicity of drivers and to ensure maximum compatibility with
both BIOS and UEFI devices.
Ensure your virtual machine has at least 1 GB of system memory at boot. You can ensure that the virtual
machine has at least 1 GB of memory at boot but allow the memory to adjust after boot by using Dynamic
Memory. You can read more about Dynamic Memory in the Hyper-V Dynamic Memory Overview.
Ensure your virtual machine uses a legacy network adapter to support network boot (PXE ); that network
adapter should be connected to the same network as your deployment server, and that network adapter should
receive an IP address automatically via DHCP.
Configure your boot order such that PXE Boot is the first option.
When your virtual machine (VM ) is properly configured and ready, start or boot the VM and be prepared to press
the F12 key when prompted to boot via PXE from the WDS server.
Perform the reference image deployment and capture using the following steps:
1. Start your virtual machine and press the F12 key when prompted to boot to the WDS server via PXE, as
shown in Figure 15.

Figure 15. Start network boot by pressing the F12 key

2. Click Run the Deployment Wizard to Install a New Operating System to begin the MDT deployment
process.
3. Enter your MDT username and password, a user with rights to access the MDT deployment share over the
network and with rights to write to the Captures folder in the deployment share.
4. After your credentials are validated, the Windows Deployment Wizard will start and process the boot and
deployment share rules.
5. The Windows Deployment Wizard displays a series of steps, as follows:
Task Sequence – Select the task sequence you created for reference image creation (it should be the
only task sequence available), and then click Next.
Computer Details – Leave the default computer name, workgroup name, and the Join a Workgroup
option selected, and then click Next. The computer name and workgroup will be reset when the image
is prepared by Sysprep and captured.
Move Data and Settings – Leave the default option of Do Not Move User Data and Settings
selected, and then click Next.
User Data (Restore) – Leave the default option of Do Not Restore User Data and Settings selected,
and then click Next.
Locale and Time – Leave the default options for language and time settings selected. The locale and
time settings will be specified during deployment of the image to other devices. Click Next.
Capture Image – Click the Capture an Image of this Reference Computer option, as shown in
Figure 16. In the Location field, keep the default location of the Captures folder. You can keep or change
the name of the image file in the File Name field. When you are finished, click Next.

Figure 16. Use the Capture Image page to capture an image of the reference machine after deployment
Ready – You can review your selections by expanding Details on the Ready page. Click Begin when
you are ready to perform the deployment and capture of your reference image.
6. Your reference task sequence will run with the specified options.
As the task sequence processes the deployment, it will automatically perform the following tasks:
Install the Windows 10 image from the installation files you supplied
Reboot into Windows 10
 Run Windows updates until all Windows updates have been installed and the Windows environment is fully up
to date
Run Sysprep and prepare the Windows 10 environment for deployment
Reboot into WinPE
Capture an image of the Windows 10 environment and store it in the Captures folder in the MDT deployment
share

NOTE
The Windows Update process can take some time to complete as it searches the Internet for updates, downloads those
updates, and then installs them. By performing this process now, in the reference environment, you eliminate the need to
perform these tasks on each deployed device and significantly reduce the amount of time and bandwidth required to
perform your deployment.

When the task sequence completes, your virtual machine will be off and a new reference image complete with
updates will be ready in your MDT deployment share for you to import it and prepare your deployment
environment for deployment to Surface devices.

Deploy Windows 10 to Surface devices

With a freshly prepared reference image, you are now ready to configure the deployment process for deployment
to the Surface devices. Use the steps detailed in this section to produce a deployment process that requires
minimal effort on each Surface device to produce a complete and ready-to-use Windows 10 environment.
Import reference image
After the reference image has been created and stored in the Captures folder, you need to add it to your MDT
deployment share as an image for deployment. You perform this task by using the same process that you used to
import the installation files for Windows 10.
To import the reference image for deployment, use the following steps:
1. Right-click the Operating Systems folder under your deployment share in the Deployment Workbench or the
folder you created in when you imported Windows 10 installation files, and then click Import Operating
System to start the Import Operating System Wizard.
2. Import the custom image with the Import Operating System Wizard by using the following steps:
OS Type – Select Custom Image File to specify that you are importing the Windows source files from
installation media, and then click Next.
Image – Click Browse, and then navigate to and select the image file in the Captures folder in your
deployment share. Select the Move the Files to the Deployment Share Instead of Copying Them
checkbox if desired. Click Next.
Setup – Click Setup Files are not Neededf, and then click Next.
Destination – Enter a name for the new folder that will be created to hold the image file, and then click
Next.
Summary – Review the specified configuration on this page before you click Next to begin the import
process.
Progress – While the image is imported, a progress bar is displayed on this page.
Confirmation – When the import process completes, the success of the process is displayed on this
page. Click Finish to complete the Import Operating System Wizard.
3. Expand the folder in which you imported the image to verify that the import completed successfully.
 NOTE
You can import the reference image into the same deployment share that you used to create your reference image, or you
could import the reference image into a new deployment share for deployment to your Surface devices. If you chose to
create a new deployment share for deployment of your reference image, remember that you still need to import a full set of
installation files from installation media.

Now that your updated reference image is imported, it is time to prepare your deployment environment for
deployment to Surface devices complete with drivers, applications, and automation.
Import Surface drivers
Before you can deploy your updated reference image to Surface devices, or any physical environment, you need to
supply MDT with the drivers that Windows will use to communicate with that physical environment. For Surface
devices you can download all of the drivers required by Windows in a single archive (.zip) file in a format that is
ready for deployment. In addition to the drivers that are used by Windows to communicate with the hardware and
components, Surface firmware and driver packs also include updates for the firmware of those components. By
installing the Surface firmware and driver pack, you will also bring your device’s firmware up to date. If you have
not done so already, download the drivers for your Surface device listed at Download the latest firmware and
drivers for Surface devices.
Many devices require that you import drivers specifically for WinPE in order for the MDT boot media to
communicate with the deployment share and to boot properly on that device. Even Surface Pro 3 required that
network drivers be imported specifically for WinPE for deployment of Windows 8.1. Fortunately, for Windows 10
deployments to Surface devices, all of the required drivers for operation of WinPE are contained within the out-of-
box drivers that are built into Windows 10. It is still a good idea to prepare your environment with folder structure
and selection profiles that allow you to specify drivers for use in WinPE. You can read more about that folder
structure in Step 5: Prepare the drivers repository in Deploy a Windows 10 image using MDT 2013 Update 2.
To import the Surface drivers (in this example, Surface Pro 4) into MDT, follow these steps:
1. Extract the downloaded archive (.zip) file to a folder that you can easily locate. Keep the driver files separate
from other drivers or files.
2. Open the Deployment Workbench and expand the Deployment Shares node and your deployment share.
3. If you have not already created a folder structure by operating system version, you should do so now and
create under the Windows 10 x64 folder a new folder for Surface Pro 4 drivers named Surface Pro 4. Your
Out-of-Box Drivers folder should resemble the following structure, as shown in Figure 17:
WinPE x86
WinPE x64
Windows 10 x64
Microsoft Corporation
Surface Pro 4
 Figure 17. The recommended folder structure for drivers
4. Right-click the Surface Pro 4 folder, and then click Import Drivers to start the Import Drivers Wizard, as
shown in Figure 18.
 Figure 18. The Progress page during drivers import
5. The Import Driver Wizard displays a series of steps, as follows:
Specify Directory – Click Browse and navigate to the folder where you extracted the Surface Pro 4
firmware and drivers in Step 1.
Summary – Review the specified configuration on this page before you click Next to begin the import
process.
Progress – While the drivers are imported, a progress bar is displayed on this page.
Confirmation – When the import process completes, the success of the process is displayed on this
page. Click Finish to complete the Import Drivers Wizard.
6. Click the Surface Pro 4 folder and verify that the folder now contains the drivers that were imported, as
shown in Figure 19.
 Figure 19. Drivers for Surface Pro 4 imported and organized in the MDT deployment share
Import applications
You can import any number of applications into MDT for installation on your devices during the deployment
process. You can configure your applications and task sequences to prompt you during deployment to pick and
choose which applications are installed, or you can use your task sequence to explicitly define which applications
are installed. For more information, see Step 4: Add an application in Deploy a Windows 10 image using MDT
2013 Update 2.
Import Microsoft Office 365 Installer
The Office Deployment Tool is a free download available in the Microsoft Download Center that allows IT
professionals and system administrators to download and prepare Office installation packages for Office Click-to-
Run. You can find the Office Deployment Tool and instructions to download Click-to-Run for Office 365
installation source files at Download Click-to-Run for Office 365 products by using the Office Deployment Tool.
Download and install the version of Office Deployment Tool (ODT), for Office 2013 or Office 2016, that fits your
organization’s needs and use the steps provided by that page to download the Office installation files for use with
MDT.
After you have downloaded the source files for your version of Office Click-to-Run, you need to edit the
Configuration.xml file with instructions to install Office Click-to-Run silently. To configure the Office Deployment
Tool for silent installation, follow these steps:
1. Right-click the existing Configuration.xml file, and then click Edit.
2. This action opens the file in Notepad. Replace the existing text with the following:

<Configuration>
<Add OfficeClientEdition="32">
<Product ID="O365ProPlusRetail" >
<Language ID="en-us" />
</Product>
</Add>
<Display Level="None" AcceptEULA="TRUE" /> </Configuration>
3. Save the file.
The default behavior of Setup.exe is to look for the source files in the path that contains Setup.exe. If the
installation files are not found in this folder, the Office Deployment Tool will default to online source files from an
Internet connection.
For MDT to perform an automated installation of office, it is important to configure the Display Level option to a
value of None. This setting is used to suppress the installation dialog box for silent installation. It is required that
the AcceptEULA option is set to True to accept the license agreement when the Display Level option is set to
None. With both of these options configured, the installation of Office will occur without the display of dialog
boxes which could potentially cause the installation to pause until a user can address an open dialog box.
Now that the installation and configuration files are prepared, the application can be imported into the
deployment share by following these steps:
1. Open the Deployment Workbench.
2. Expand the deployment share, right-click the Applications folder, and then click New Application to start
the New Application Wizard, as shown in Figure 20.

Figure 20. Enter the command and directory for Office 2016 Click-to -Run
3. The New Application Wizard walks you through importing the Office 2016 Click-to-Run files, as follows:
Application Type – Click Application with Source Files, and then click Next.
Details – Enter a name for the application (for example, Office 2016 Click-to-Run) in the Application
Name field. Enter publisher, version, and language information in the Publisher, Version, and
Language fields if desired. Click Next.
Source – Click Browse to navigate to and select the folder where you downloaded the Office
installation files with the Office Deployment Tool, and then click Next.
 Destination – Enter a name for the folder where the application files will be stored in the Specify the
Name of the Directory that Should Be Created field or click Next to accept the default name.
Command Details – Enter the Office Deployment Tool installation command line:
Setup.exe /configure configuration.xml

Summary – Review the specified configuration on this page before you click Next to begin the
import process.
Progress – While the installation files are imported, a progress bar is displayed on this page.
Confirmation – When the import process completes, the success of the process is displayed on this
page. Click Finish to complete the New Application Wizard.
4. You should now see the Office 2016 Click-to-Run item under the Applications folder in the Deployment
Workbench.
Import Surface app installer
The Surface app is a Microsoft Store app that provides the user with greater control over specific Surface device
functions and capabilities (for example, control over the sensitivity of the Surface Pen). It is a highly recommended
app for Surface devices to provide end users with the best experience and greatest control over their device. Find
out more about the Surface app at Install and use the Surface app.
To perform a deployment of the Surface app, you will need to download the app files through Microsoft Store for
Business. You can find detailed instructions on how to download the Surface app through Microsoft Store for
Business at Deploy Surface app with Microsoft Store for Business.
After you have downloaded the installation files for Surface app, including the AppxBundle and license files, you
can import these files into the deployment share through the same process as a desktop application like Microsoft
Office. Both the AppxBundle and license files must be together in the same folder for the import process to
complete successfully. Use the following command on the Command Details page to install the Surface app:

DISM.exe /Online /Add-ProvisionedAppxPackage /PackagePath:

Microsoft.SurfaceHub_10.0.342.0_neutral_~_8wekyb3d8bbwe.AppxBundle /LicensePath:
Microsoft.SurfaceHub_8wekyb3d8bbwe_a53ef8ab-9dbd-dec1-46c5-7b664d4dd003.xml

Create deployment task sequence

The next step in the process is to create the deployment task sequence. This task sequence will be configured to
completely automate the deployment process and will work along with customized deployment share rules to
reduce the need for user interaction down to a single touch. Before you can make customizations to include all of
this automation, the new task sequence has to be created from a template.
To create the deployment task sequence, follow these steps:
1. In the Deployment Workbench, under your Deployment Share, right-click the Task Sequences folder, and then
click New Task Sequence to start the New Task Sequence Wizard.
2. Use these steps to create the deployment task sequence with the New Task Sequence Wizard:
General Settings – Enter an identifier for the deployment task sequence in the Task Sequence ID
field, a name for the deployment task sequence in the Task Sequence Name field, and any comments
for the deployment task sequence in the Task Sequence Comments field, then click Next. >[!NOTE ]
>The Task Sequence ID field cannot contain spaces and can be a maximum of 16 characters.
Select Template – Click Standard Client Task Sequence from the drop-down menu, and then click
Next.
Select OS – Navigate to and select the reference image that you imported, and then click Next.
Specify Product Key – Select the product key entry that fits your organization's licensing system. The
Do Not Specify a Product Key at This Time option can be used for systems that will be activated via
 Key Management Services (KMS ) or Active Directory Based Activation (ADBA). A product key can be
specified specifically if your organization uses Multiple Activation Keys (MAK). Click Next.
OS Settings – Enter a name and organization for registration of Windows, and a home page URL for
users when they browse the Internet in the Full Name, Organization, and Internet Explorer Home
Page fields, and then click Next.
Admin Password – Click Use the Specified Local Administrator Password, enter a password in the
provided field, and then click Next.
Summary – Review the specified configuration on this page before you click Next to begin creation of
the task sequence.
Progress – While the task sequence is being created, a progress bar is displayed on this page.
Confirmation – When the task sequence creation completes, the success of the process is displayed on
this page. Click Finish to complete the New Task Sequence Wizard.
After the task sequence is created it can be modified for increased automation, such as the installation of
applications without user interaction, the selection of drivers, and the installation of Windows updates.
1. Click the Task Sequences folder, right-click the new task sequence you created, and then click Properties.
2. Click the Task Sequence tab to view the steps that are included in the new task sequence.
3. Click the Windows Update (Pre-Application Installation) step, located under the State Restore folder.
4. Click the Options tab, and then clear the Disable This Step check box.
5. Repeat Step 4 and Step 5 for the Windows Update (Post-Application Installation) option.
6. Between the two Windows Update steps is the Install Applications step. Click the Install Applications
step, and then click Add.
7. Hover the mouse over General under the Add menu, and then click Install Application. This will add a
new step after the selected step for the installation of a specific application as shown in Figure 21.

Figure 21. A new Install Application step in the deployment task sequence
8. On the Properties tab of the new Install Application step, enter Install Microsoft Office 2016 Click-
to-Run in the Name field.
9. Click Install a Single Application, and then click Browse to view available applications that have been
 imported into the deployment share.
10. Select Office 2016 Click-to-Run from the list of applications, and then click OK.
11. Repeat Steps 6 through 10 for the Surface app.
12. Expand the Preinstall folder, and then click the Enable BitLocker (Offline) step.
13. Open the Add menu again and choose Set Task Sequence Variable from under the General menu.
14. On the Properties tab of the new Set Task Sequence Variable step (as shown in Figure 22), configure
the following options:
Name – Set DriverGroup001
Task Sequence Variable – DriverGroup001
Value – Windows 10 x64%Make%%Model%

Figure 22. Configure a new Set Task Sequence Variable step in the deployment task sequence
15. Select the Inject Drivers step, the next step in the task sequence.
16. On the Properties tab of the Inject Drivers step (as shown in Figure 23), configure the following options:
In the Choose a selection profile drop-down menu, select Nothing.
Click the Install all drivers from the selection profile button.
 Figure 23. Configure the deployment task sequence not to choose the drivers to inject into Windows
17. Click OK to apply changes to the task sequence and close the task sequence properties window.
Configure deployment share rules
The experience of users during a Windows deployment is largely governed by a set of rules that control how the
MDT and Windows Deployment Wizard experience should proceed. These rules are stored in two configuration
files. Boot media rules are stored in the Bootstrap.ini file that is processed when the MDT boot media is first run.
Deployment share rules are stored in the Customsettings.ini file and tell the Windows Deployment Wizard how to
operate (for example, what screens to show and what questions to ask). By using these the rules stored in these
two files, you can completely automate the process of deployment to where you will not be asked to supply the
answer to any questions during deployment and the deployment will perform all tasks completely on its own.
Configure Bootstrap.ini
Bootstrap.ini is the simpler of the two rule files. The purpose it serves is to provide instructions from when the
MDT boot media starts on a device until the Windows Deployment Wizard is started. The primary use of this file
is to provide the credentials that will be used to log on to the deployment share and start the Windows
Deployment Wizard.
To automate the boot media rules, follow these steps:
1. Right-click your deployment share in the Deployment Workbench, and then click Properties.
2. Click the Rules tab, and then click Edit Bootstrap.ini to open Bootstrap.ini in Notepad.
3. Replace the text of the Bootstrap.ini file with the following text:
 [Settings]
Priority=Model,Default

[Surface Pro 4]
DeployRoot=\\STNDeployServer\DeploymentShare$
UserDomain=STNDeployServer
UserID=MDTUser
UserPassword=P@ssw0rd
SkipBDDWelcome=YES

[Surface Pro 4]
DeployRoot=\\STNDeployServer\DeploymentShare$

4. Press Ctrl+S to save Bootstrap.ini, and then close Notepad.

You can use a number of variables in both boot media and deployment share rules to apply rules only when
certain conditions are met. For example, you can use MAC addresses to identify specific machines where MDT will
run fully automated, but will run with required user interaction on all other devices. You can also use the model of
the device to instruct the MDT boot media to perform different actions based on computer model, much as the
way [Surface Pro 4] is listed in Step 3. You can use the following cmdlet in a PowerShell session to see what the
Model variable would be on a device:
wmic csproduct get name

Rules used in the text shown in Step 3 include:

DeployRoot – Used to specify the deployment share that the MDT boot media will connect to.
UserDomain – Used to specify the domain or computer where the MDT user account is located.
UserID – Used to specify the MDT user account for automatic logon to the deployment share.
UserPassword – Used to specify the MDT user password for automatic logon to the deployment share.
SkipBDDWelcome – Used to skip the Welcome page and to start the Windows Deployment Wizard
immediately using the specified credentials and deployment share.
Configure CustomSettings.ini
The bulk of the rules used to automate the MDT deployment process are stored in the deployment share rules, or
the Customsettings.ini file. In this file you can answer and hide all of the prompts from the Windows Deployment
Wizard, which yields a deployment experience that mostly consists of a progress bar that displays the automated
actions occurring on the device. The deployment share rules are shown directly in the Rules tab of the
deployment share properties, as shown in Figure 24.
Figure 24. Deployment share rules configured for automation of the Windows Deployment Wizard
To configure automation for the production deployment, copy and paste the following text into the text box on the
Rules tab of your deployment share properties:
 [Settings]
Priority=Model,Default
Properties=MyCustomProperty

[Surface Pro 4]
SkipTaskSequence=YES
TaskSequenceID=Win10SP4

[Default]
OSInstall=Y
SkipCapture=YES
SkipAdminPassword=YES
SkipProductKey=YES
SkipComputerBackup=YES
SkipBitLocker=YES
SkipBDDWelcome=YES
SkipUserData=YES
UserDataLocation=AUTO
SkipApplications=YES
SkipPackageDisplay=YES
SkipComputerName=YES
SkipDomainMembership=YES
JoinDomain=contoso.com
DomainAdmin=MDT
DomainAdminDomain=contoso
DomainAdminPassword=P@ssw0rd
SkipLocaleSelection=YES
KeyboardLocale=en-US
UserLocale=en-US
UILanguage=en-US
SkipTimeZone=YES
TimeZoneName=Pacific Standard Time
UserID=MDTUser
UserDomain=STNDeployServer
UserPassword=P@ssw0rd
SkipSummary=YES
SkipFinalSummary=YES
FinishAction=LOGOFF

Rules used in this example include:

SkipTaskSequence – This rule is used to skip the Task Sequence page where the user would have to select
between available task sequences.
TaskSequenceID – This rule is used to instruct the Windows Deployment Wizard to run a specific task
sequence. In this scenario the task sequence ID should match the deployment task sequence you created in the
previous section.
OSInstall – This rule indicates that the Windows Deployment Wizard will be performing an operating system
deployment.
SkipCapture – This rule prevents the Capture Image page from being displayed, prompting the user to
create an image of this device after deployment.
SkipAdminPassword – This rule prevents the Admin Password page from being displayed. The
Administrator password specified in the task sequence will still be applied.
SkipProductKey – This rule prevents the Specify Product Key page from being displayed. The product key
specified in the task sequence will still be applied.
SkipComputerBackup – This rule prevents the Move Data and Settings page from being displayed, where
the user is asked if they would like to make a backup of the computer before performing deployment.
SkipBitLocker – This rule prevents the BitLocker page from being displayed, where the user is asked if
BitLocker Drive Encryption should be used to encrypt the device.
SkipBDDWelcome – This rule prevents the Welcome page from being displayed, where the user is
 prompted to begin Windows deployment.
SkipUserData – This rule prevents the User Data (Restore) page from being displayed, where the user is
asked to restore previously backed up user data in the new environment.
UserDataLocation – This rule prevents the user from being prompted to supply a location on the User Data
(Restore) page.
SkipApplications – This rule prevents the Applications page from being displayed, where the user is
prompted to select from available applications to be installed in the new environment.
SkipPackageDisplay – This rule prevents the Packages page from being displayed, where the user is
prompted to select from available packages to be installed in the new environment.
SkipComputerName – This rule, when combined with the SkipDomainMembership rule, prevents the
Computer Details page from being displayed, where the user is asked to supply computer name and join a
domain or workgroup.
SkipDomainMembership – This rule, when combined with the SkipComputerName rule, prevents the
Computer Details page from being displayed, where the user is asked to supply computer name and join a
domain or workgroup.
JoinDomain – This rule instructs the Windows Deployment Wizard to have the computer join the specified
domain using the specified credentials.
DomainAdmin – This rule specifies the username for the domain join operation.
DomainAdminDomain – This rule specifies the domain for the username for the domain join operation.
DomainAdminPassword – This rule specifies the password for the username for the domain join operation.
SkipLocaleSelection – This rule, along with the SkipTimeZone rule, prevents the Locale and Time page
from being displayed.
KeyboardLocale – This rule is used to specify the keyboard layout for the deployed Windows environment.
UserLocale – This rule is used to specify the geographical locale for the deployed Windows environment.
UILanguage – This rule is used to specify the language to be used in the deployed Windows environment.
SkipTimeZone – This rule, along with the SkipLocaleSelection rule, prevents the Locale and Time page
from being displayed.
TimeZoneName – This rule is used to specify the time zone for the deployed Windows environment.
UserID – This rule is used to supply the username under which the MDT actions and task sequence steps are
performed.
UserDomain – This rule is used to supply the domain for the username under which the MDT actions and task
sequence steps are performed.
UserPassword – This rule is used to supply the password for the username under which the MDT actions and
task sequence steps are performed.
SkipSummary – This rule prevents the Summary page from being displayed before the task sequence is run,
where the user is prompted to confirm the selections before beginning the task sequence.
SkipFinalSummary – This rule prevents the Summary page from being displayed when the task sequence
has completed.
FinishAction – This rule specifies whether to log out, reboot, or shut down the device after the task sequence
has completed.
You can read about all of the possible deployment share and boot media rules in the Microsoft Deployment
Toolkit Reference.
Update and import updated MDT boot media
The process to update MDT boot media with these new rules and changes to the deployment share is very similar
to the process to generate boot media from scratch.
To update the MDT boot media, follow these steps:
1. Right-click the deployment share in the Deployment Workbench, and then click Update Deployment Share
 to start the Update Deployment Share Wizard.
2. The Update Deployment Share Wizard displays a series of steps, as follows:
Options – Choose between the Completely Regenerate the Boot Images or Optimize the Boot
Image Updating Process options. Completely regenerating the boot images will take more time, but
produces boot media that is not fragmented and does not contain out of date components. Optimizing
the boot image updating process will proceed more quickly, but may result in longer load times when
booting via PXE. Click Next.
Summary – Review the specified options on this page before you click Next to begin the update of
boot images.
Progress – While the boot images are being updated a progress bar is displayed on this page.
Confirmation – When the boot images have been updated, the success of the process is displayed on
this page. Click Finish to complete the Update Deployment Share Wizard.
To import the updated MDT boot media into WDS for PXE boot, follow these steps:
1. Open Windows Deployment Services from the Start menu or Start screen.
2. Expand Servers and your deployment server.
3. Click the Boot Images folder.
4. Right-click the existing MDT boot image, and then click Replace Image to open the Replace Boot Image
Wizard.
5. Replace the previously imported MDT boot image with the updated version by using these steps in the Replace
Boot Image Wizard:
Image File – Click Browse and navigate to the Boot folder in your deployment share, click
LiteTouchPE_x86.wim, and then click Open. Click Next.
Available Images – Only one image should be listed and selected LiteTouch Windows PE (x86), click
Next.
Image Metadata – Enter a name and description for the MDT boot media, or click Next to accept the
default options.
Summary – Review your selections for importing a boot image into WDS, and then click Next.
Task Progress – A progress bar is displayed as the selected image file is copied into the WDS remote
installation folder. Click Finish when the task is complete to close the Replace Boot Image Wizard.
6. Right-click the Boot Images folder, and then click Add Image to open the Add Image Wizard.
7. Add the new 64-bit boot image for 64-bit UEFI device compatibility with the Add Image Wizard , as follows:
Image File – Click Browse and navigate to the Boot folder in your deployment share, select
LiteTouchPE_x64.wim, and then click Open. Click Next.
Image Metadata – Enter a name and description for the MDT boot media, or click Next to accept the
default options.
Summary – Review your selections to import a boot image into WDS, and then click Next.
Task Progress – A progress bar is displayed as the selected image file is copied into the WDS remote
installation folder. Click Finish when the task is complete to close the Add Image Wizard.

NOTE
Although it is a best practice to replace and update the boot images in WDS whenever the MDT deployment share is
updated, for deployment to Surface devices the 32-bit boot image, LiteTouchPE_x86.wim, is not required. Only the 64-bit
boot image is required for 64-bit UEFI devices.

Deploy Windows to Surface

With all of the automation provided by the deployment share rules and task sequence, performing the
deployment on each Surface device becomes as easy as a single touch.
 NOTE
For the deployment to require only a single touch, the Surface devices must be connected to a keyboard, connected to the
network with a Microsoft Surface USB Ethernet Adapter or Surface Dock, and configured with PXE boot as the first boot
option, as shown in Figure 25.

Figure 25. Setting boot priority for PXE boot

On a properly configured Surface device, simply turn on the device and press Enter when you are prompted to
boot from the network. The fully automated MDT deployment process will then take over and perform the
following tasks:
The MDT boot media will be loaded to your Surface device via the network
The MDT boot media will use the provided credentials and rules to connect to the MDT deployment share
The task sequence and drivers will be automatically selected for your device via make and model information
The task sequence will deploy your updated Windows 10 image to the device complete with the selected
drivers
The task sequence will join your device to the domain
The task sequence will install the applications you specified, Microsoft Office and Surface app
Windows Update will run, installing any new Windows Updates or updates for installed applications, like
Microsoft Office
The task sequence will complete silently and log out of the device

NOTE
For Surface devices not configured to boot to the network as the first boot option, you can hold Volume Down and press
Power to boot the system immediately to a USB or network device.

The resulting configuration is a Surface device that is logged out and ready for an end user to enter their
credentials, log on, and get right to work. The applications and drivers they need are already installed and up to
date.
 Upgrade Surface devices to Windows 10 with
Microsoft Deployment Toolkit
10/29/2018 • 12 minutes to read • Edit Online

Applies to
Surface Pro 3
Surface 3
Surface Pro 2
Surface Pro
Windows 10
In addition to the traditional deployment method of reimaging devices, administrators that want to upgrade
Surface devices that are running Windows 8.1 or Windows 10 have the option of deploying upgrades. By
performing an upgrade deployment, Windows 10 can be applied to devices without removing users, apps, or
configuration. The users of the deployed devices can simply continue using the devices with the same apps and
settings that they used prior to the upgrade. The process described in this article shows how to perform a
Windows 10 upgrade deployment to Surface devices.
If you are not already familiar with the deployment of Windows or the Microsoft deployment tools and
technologies, you should read Deploy Windows 10 to Surface devices with MDT and familiarize yourself with the
traditional deployment method before you proceed.
The upgrade concept
When you use the factory installation media to install Windows on a device, you are presented with two options or
installation paths to install Windows on that device. The first of these installation paths – clean installation – allows
you to apply a factory image of Windows to that device, including all default settings. The second of these
installation paths – upgrade – allows you to apply Windows to the device but retains the device’s users, apps, and
settings.
When you perform a Windows deployment using traditional deployment methods, you follow an installation path
that is very similar to a clean installation. The primary difference between the clean installation and the traditional
deployment method of reimaging is that with reimaging, you can apply an image that includes customizations.
Microsoft deployment technologies, such as the Microsoft Deployment Toolkit (MDT), expand the capabilities of
the reimaging process by modifying the image during deployment. For example, MDT is able to inject drivers for a
specific hardware configuration during deployment, and with pre and post imaging scripts to perform a number of
tasks, such as the installation of applications.
For versions of Windows prior to Windows 10, if you wanted to install a new version of Windows on your devices
and preserve the configuration of those systems, you had to perform additional steps during your deployment. For
example, if you wanted to keep the data of users on the device, you had to back up user data with the User State
Migration Tool (USMT) prior to the deployment and restore that data after the deployment had completed.
Introduced with Windows 10 and MDT 2013 Update 1, you can use the upgrade installation path directly with
Microsoft deployment technologies such as the Microsoft Deployment Toolkit (MDT). With an upgrade
deployment you can use the same deployment technologies and process, but you can preserve users settings, and
applications of the existing environment on the device.

Deployment tools and resources

Performing an upgrade deployment of Windows 10 requires the same tools and resources that are required for a
traditional reimaging deployment. You can read about the tools required, including detailed explanations and
installation instructions, in Deploy Windows 10 to Surface devices with MDT. To proceed with the upgrade
deployment described in this article, you will need the following tools installed and configured:
Microsoft Deployment Toolkit (MDT)
Windows Assessment and Deployment Kit (Windows ADK), which includes:
Deployment Image Servicing and Management (DISM )
Windows Preinstallation Environment (Windows PE )
Windows System Image Manager (Windows SIM )
You will also need to have available the following resources:
Windows 10 installation files, such as the installation media downloaded from the Volume Licensing
Service Center

NOTE
Installation media for use with MDT must contain a Windows image in Windows Imaging Format (.wim). Installation
media produced by the Get Windows 10 page does not use a .wim file, instead using an Electronic Software
Download (.esd) file, which is not compatible with MDT.

Surface firmware and drivers for Windows 10

Application installation files for any applications you want to install, such as the Surface app

Prepare the upgrade deployment

Before you begin the process described in this section, you need to have installed and configured the deployment
tools outlined in the previous Deployment tools and resources section. For instructions on how to install and
configure the deployment tools, see the Install the deployment tools section in the Deploy Windows 10 to
Surface devices with MDT article. You will also have needed to create a deployment share with MDT, described in
the section Create a Deployment Share in the aforementioned article.
Import Windows 10 installation files
Windows 10 installation files only need to be imported if you have not already done so in the deployment share.
To import Windows 10 installation files, follow the steps described in the Import Windows installation files
section in the Deploy Windows 10 to Surface devices with MDT article.
Import Surface drivers
In the import process example shown in the Deploy Windows 10 to Surface devices with MDT article, drivers for
Surface Pro 4 were imported for Windows 10. To perform an upgrade deployment of Windows 10 to Surface Pro
3, drivers for Surface Pro 3 must also be imported. To import the Surface drivers for Surface Pro 3, follow these
steps:
1. Download the Surface Pro 3 firmware and driver pack for Windows 10 archive file (.zip),
SurfacePro3_Win10_xxxxxx.zip, from the Surface Pro 3 download page in the Microsoft Download Center.
2. Extract the contents of the Surface Pro 3 firmware and driver pack archive file to a temporary folder. Keep the
driver files separate from other drivers or files.
3. Open the Deployment Workbench and expand the Deployment Shares node and your deployment share.
4. If you have not already created a folder structure by operating system version, you should do so next. Under
the Windows 10 x64 folder, create a new folder for Surface Pro 3 drivers named Surface Pro 3. Your Out-of-
Box Drivers folder should resemble the following structure:
WinPE x86
WinPE x64
 Windows 10 x64
Microsoft Corporation
Surface Pro 4
Surface Pro 3
5. Right-click the Surface Pro 3 folder, and then click Import Drivers to start the Import Drivers Wizard, as
shown in Figure 1.

Figure 1. Import Surface Pro 3 drivers for Windows 10

6. The Import Driver Wizard displays a series of steps, as follows:
Specify Directory – Click Browse and navigate to the folder where you extracted the Surface Pro 3
firmware and drivers in Step 1.
Summary – Review the specified configuration on this page before you click Next to begin the import
process.
Progress – While the drivers are imported, a progress bar is displayed on this page.
Confirmation – When the import process completes, the success of the process is displayed on this
page. Click Finish to complete Import Drivers Wizard.
7. Select the Surface Pro 3 folder and verify that the folder now contains the drivers that were imported, as
shown in Figure 2.
 Figure 2. Drivers for Surface Pro 3 imported and organized in the MDT deployment share
Import applications
Installation of applications in an upgrade deployment is not always necessary because the applications from the
previous environment will remain on the device. (For example, in the Deploy Windows 10 to Surface devices with
MDT article, the deployment includes Office 365 which is not required in an upgrade deployment where the user
is already using Office 365 on the device.)
There are still some circumstances where you will want to deploy an application, even during an upgrade
deployment. For example, you may have Surface Pro 3 devices on which you would like to add the Surface app. To
deploy the Surface app in an upgrade scenario use the same process as you would for a traditional deployment.
See the Deploy Surface app with Microsoft Store for Business article for instructions on how to add the Surface
app to an MDT task sequence.
Create the upgrade task sequence
After you have all of the resources in place to perform the deployment (including the installation files, Surface
drivers, and application files), the next step is to create the upgrade task sequence. This task sequence is a series of
steps that will be performed on the device being upgraded that applies the new Windows environment,
compatible drivers, and any applications you have specified.
Create the upgrade task sequence with the following process:
1. In the Deployment Workbench under your Deployment Share, right-click the Task Sequences folder, and then
click New Task Sequence to start the New Task Sequence Wizard.
2. Use these steps to create the deployment task sequence with the New Task Sequence Wizard:
General Settings – Enter an identifier for the deployment task sequence in the Task Sequence ID field, a
name for the deployment task sequence in the Task Sequence Name field, and any comments for the
deployment task sequence in the Task Sequence Comments field, and then click Next. >[!NOTE ]
>The Task Sequence ID field cannot contain spaces and can be a maximum of 16 characters.
Select Template – Select Standard Client Upgrade Task Sequence from the drop-down menu, and
 then click Next.
Select OS – Navigate to and select the Windows image that you imported, and then click Next.
Specify Product Key – Select the product key entry that fits your organization’s licensing system. The
Do Not Specify a Product Key at This Time option can be used for systems that will be activated via
Key Management Services (KMS ) or Active Directory Based Activation (ADBA). A product key can be
specified specifically if your organization uses Multiple Activation Keys (MAK). Click Next.
OS Settings – Enter a name and organization for registration of Windows, and a home page URL for
users when they browse the Internet in the Full Name, Organization, and Internet Explorer Home
Page fields, and then click Next.
Admin Password – Select Use the Specified Local Administrator Password and enter a password
in the provided fields, and then click Next.
Summary – Review the specified configuration on this page before you click Next to begin creation of
the task sequence.
Progress – While the task sequence is being created, a progress bar is displayed on this page.
Confirmation – When the task sequence creation completes, the success of the process is displayed on
this page. Click Finish to complete New Task Sequence Wizard.
After the task sequence is created, you can modify some additional settings to provide additional automation of
the task sequence and require less interaction during deployment. Follow these steps to modify the task sequence:
1. Select the Task Sequences folder, right-click the new task sequence you created, and then click Properties.
2. Select the Task Sequence tab to view the steps that are included in the new task sequence.
3. Select the Windows Update (Pre-Application Installation) step, located under the State Restore folder.
4. Click the Options tab, and then clear the Disable This Step check box.
5. Repeat Step 3 and Step 4 for the Windows Update (Post-Application Installation) step.
6. Between the two Windows Update steps is an Install Applications step. Select that step and then click Add.
7. Hover the mouse over General under the Add menu, and then choose Install Application. This will add a
new step after the selected step for the installation of a specific application as shown in Figure 3.

Figure 3. A new Install Application step in the deployment task sequence

8. On the Properties tab of the new Install Application step, enter Install Surface App in the Name field.
 9. Select Install a Single Application, and then click Browse to view available applications that have been
imported into the deployment share.
10. Select Surface App from the list of applications, and then click OK.
11. Expand the Preinstall folder and select the Enable BitLocker (Offline) step.
12. Open the Add menu again and choose Set Task Sequence Variable from under the General menu.
13. On the Properties tab of the new Set Task Sequence Variable step (as shown in Figure 4) configure the
following options:
Name – Set DriverGroup001
Task Sequence Variable – DriverGroup001
Value – Windows 10 x64%Make%%Model%

Figure 4. Configure a new Set Task Sequence Variable step in the deployment task sequence
14. Select the Inject Drivers step, the next step in the task sequence.
15. On the Properties tab of the Inject Drivers step (as shown in Figure 5) configure the following options:
In the Choose a selection profile drop-down menu, select Nothing.
Click the Install all drivers from the selection profile button.
 Figure 5. Configure the deployment task sequence to not install drivers
16. Click OK to apply changes to the task sequence and close the task sequence properties window.
Steps 11 through 15 are very important to the deployment of Surface devices. These steps instruct the task
sequence to install only drivers that are organized into the correct folder using the organization for drivers from
the Import Surface drivers section.
Deployment share rules
To automate the upgrade process, the rules of the MDT deployment share need to be modified to suppress
prompts for information from the user. Unlike a traditional deployment, Bootstrap.ini does not need to be modified
because the deployment process is not started from boot media. Similarly, boot media does not need to be
imported into WDS because it will not be booted over the network with PXE.
To modify the deployment share rules and suppress the Windows Deployment Wizard prompts for information,
copy and paste the following text into the text box on the Rules tab of your deployment share properties:
 [Settings]
Priority=Model,Default
Properties=MyCustomProperty

[Surface Pro 4]
SkipTaskSequence=YES
TaskSequenceID=Win10SP4

[Surface Pro 3]
SkipTaskSequence=YES
TaskSequenceID=Win10SP3Up

[Default]
OSInstall=Y
SkipCapture=YES
SkipAdminPassword=YES
SkipProductKey=YES
SkipComputerBackup=YES
SkipBitLocker=YES
SkipBDDWelcome=YES
SkipUserData=YES
UserDataLocation=AUTO
SkipApplications=YES
SkipPackageDisplay=YES
SkipComputerName=YES
SkipDomainMembership=YES
JoinDomain=contoso.com
DomainAdmin=MDT
DomainAdminDomain=contoso
DomainAdminPassword=P@ssw0rd
SkipLocaleSelection=YES
KeyboardLocale=en-US
UserLocale=en-US
UILanguage=en-US
SkipTimeZone=YES
TimeZoneName=Pacific Standard Time
UserID=MDTUser
UserDomain=STNDeployServer
UserPassword=P@ssw0rd
SkipSummary=YES
SkipFinalSummary=YES
FinishAction=LOGOFF

For more information about the rules configured by this text, see the Configure deployment share rules section
in the Deploy Windows 10 to Surface devices with MDT article.
Update deployment share
To update the deployment share, right-click the deployment share in the Deployment Workbench and click
Update Deployment Share, then proceed through the Update Deployment Share Wizard. See the Update and
import updated MDT boot media section of the Deploy Windows 10 to Surface devices with MDT article for
detailed steps.
Run the upgrade deployment
Unlike a traditional deployment, the upgrade task sequence must be launched from within the Windows
environment that will be upgraded. This requires that a user on the device to be upgraded navigate to the
deployment share over the network and launch a script, LiteTouch.vbs. This script is the same script that displays
the Windows Deployment Wizard in Windows PE in a traditional deployment. In this scenario, Litetouch.vbs will
run within Windows. To perform the upgrade task sequence and deploy the upgrade to Windows 10 follow these
steps:
1. Browse to the network location of your deployment share in File Explorer.
2. Navigate to the Scripts folder, locate LiteTouch.vbs, and then double-click LiteTouch.vbs to start the
 Windows Deployment Wizard.
3. Enter your credentials when prompted.
4. The upgrade task sequence for Surface Pro 3 devices will automatically start when the model of the device is
detected and determined to match the deployment share rules.
5. The upgrade process will occur automatically and without user interaction.
The task sequence will automatically install the drivers for Surface Pro 3 and the Surface app, and will perform any
outstanding Windows Updates. When it completes, it will log out and be ready for the user to log on with the
credentials they have always used for this device.
 Customize the OOBE for Surface deployments
8/28/2018 • 3 minutes to read • Edit Online

This article walks you through the process of customizing the Surface out-of-box experience for end users in your
organization.
It is common practice in a Windows deployment to customize the user experience for the first startup of deployed
computers — the out-of-box experience, or OOBE.

NOTE
OOBE is also often used to describe the phase, or configuration pass, of Windows setup during which the user experience is
displayed. For more information about the OOBE phase of setup, see How Configuration Passes Work.

In some scenarios, you may want to provide complete automation to ensure that at the end of a deployment,
computers are ready for use without any interaction from the user. In other scenarios, you may want to leave key
elements of the experience for users to perform necessary actions or select between important choices. For
administrators deploying to Surface devices, each of these scenarios presents a unique challenge to overcome.
This article provides a summary of the scenarios where a deployment might require additional steps. It also
provides the required information to ensure that the desired experience is achieved on any newly deployed Surface
device. This article is intended for administrators who are familiar with the deployment process, as well as concepts
such as answer files and reference images.

NOTE
Although the OOBE phase of setup is still run during a deployment with an automated deployment solution such as the
Microsoft Deployment Toolkit (MDT) or System Center Configuration Manager Operating System Deployment (OSD), it is
automated by the settings supplied in the Deployment Wizard and task sequence. For more information see:
Deploy Windows 10 with the Microsoft Deployment Toolkit
Deploy Windows 10 with System Center 2012 R2 Configuration Manager

Scenario 1: Wireless networking in OOBE with MDT 2013

When a wireless network adapter is present during OOBE, the Join a wireless network page is displayed, which
prompts a user to connect to a wireless network. This page is not automatically hidden by deployment
technologies, including MDT 2013, and therefore will be displayed even when a deployment is configured for
complete automation.
To ensure that an automated deployment is not stopped by this page, the page must be hidden by configuring an
additional setting in the answer file, HideWirelessSetupInOOBE. You can find additional information about the
HideWirelessSetupInOOBE setting in Unattended Windows Setup Reference.

Scenario 2: Surface Pen pairing in OOBE

When you first take a Surface Pro 3, Surface Pro 4, Surface Book, or Surface Studio out of the package and start it
up, the first-run experience of the factory image includes a prompt that asks you to pair the included Surface Pen
to the device. This prompt is only provided by the factory image that ships with the device and is not included in
other images used for deployment, such as the Windows Enterprise installation media downloaded from the
Volume Licensing Service Center. Because pairing the Bluetooth Surface Pen outside of this experience requires
that you enter the Control Panel or PC Settings and manually pair a Bluetooth device, you may want to have users
or a technician use this prompt to perform the pairing operation.
To provide the factory Surface Pen pairing experience in OOBE, you must copy four files from the factory Surface
image into the reference image. You can copy these files into the reference environment before you capture the
reference image, or you can add them later by using Deployment Image Servicing and Management (DISM ) to
mount the image. The four required files are:
%windir%\system32\oobe\info\default\1033\oobe.xml
%windir%\system32\oobe\info\default\1033\PenPairing_en-US.png
%windir%\system32\oobe\info\default\1033\PenError_en-US.png
%windir%\system32\oobe\info\default\1033\PenSuccess_en-US.png

NOTE
You should copy the files from a factory image for the same model Surface device that you intend to deploy to. For example,
you should use the files from a Surface Pro 3 to deploy to Surface Pro 3, and the files from Surface Book to deploy Surface
Book, but you should not use the files from a Surface Pro 3 to deploy Surface Book or Surface Pro 4.

The step-by-step process for adding these required files to an image is described in Deploying Surface Pro 3 Pen
and OneNote Tips. This blog post also includes tips to ensure that the necessary updates for the Surface Pen Quick
Note-Taking Experience are installed, which allows users to send notes to OneNote with a single click.
 Ethernet adapters and Surface deployment
6/27/2018 • 5 minutes to read • Edit Online

This article provides guidance and answers to help you perform a network deployment to Surface devices.
Network deployment to Surface devices can pose some unique challenges for system administrators. Due to the
lack of a native wired Ethernet adapter, administrators must provide connectivity through a removable Ethernet
adapter.

Select an Ethernet adapter for Surface devices

Before you can address the concerns of how you will boot to your deployment environment or how devices will be
recognized by your deployment solution, you have to use a wired network adapter.
The primary concern when selecting an Ethernet adapter is how that adapter will boot your Surface device from
the network. If you are pre-staging clients with Windows Deployment Services (WDS ) or if you are using System
Center Configuration Manager, you may also want to consider whether the removable Ethernet adapters will be
dedicated to a specific Surface device or shared among multiple devices. See the Manage MAC addresses with
removable Ethernet adapters section of this article for more information on potential conflicts with shared
adapters.
Booting from the network (PXE boot) is only supported when you use an Ethernet adapter or docking station from
Microsoft. To boot from the network, the chipset in the Ethernet adapter or dock must be detected and configured
as a boot device in the firmware of the Surface device. Microsoft Ethernet adapters, such as the Surface Ethernet
Adapter and the Surface Dock use a chipset that is compatible with the Surface firmware.
The following Ethernet devices are supported for network boot with Surface devices:
Surface USB to Ethernet adapter
Surface USB 3.0 Ethernet adapter
Surface Dock
Surface 3 Docking Station
Surface Pro 3 Docking Station
Docking Station for Surface Pro and Surface Pro 2
Third-party Ethernet adapters are also supported for network deployment, although they do not support PXE boot.
To use a third-party Ethernet adapter, you must load the drivers into the deployment boot image and you must
launch that boot image from a separate storage device, such as a USB stick.

Boot Surface devices from the network

To boot from the network or a connected USB stick, you must instruct the Surface device to boot from an alternate
boot device. You can alter the boot order in the system firmware to prioritize USB boot devices, or you can instruct
it to boot from an alternate boot device during the boot up process.
To boot a Surface device from an alternative boot device, follow these steps:
1. Ensure the Surface device is powered off.
2. Press and hold the Volume Down button.
3. Press and release the Power button.
4. After the system begins to boot from the USB stick or Ethernet adapter, release the Volume Down button.

NOTE
In addition to an Ethernet adapter, a keyboard must also be connected to the Surface device to enter the preinstallation
environment and navigate the deployment wizard.

For Windows 10, version 1511 and later – including the Windows Assessment and Deployment Kit (Windows
ADK) for Windows 10, version 1511 – the drivers for Microsoft Surface Ethernet Adapters are present by default.
If you are using a deployment solution that uses Windows Preinstallation Environment (WinPE ), like the Microsoft
Deployment Toolkit, and booting from the network with PXE, ensure that your deployment solution is using the
latest version of the Windows ADK.

Manage MAC addresses with removable Ethernet adapters

Another consideration for administrators performing Windows deployment over the network is how you will
identify computers when you use the same Ethernet adapter to deploy to more than one computer. A common
identifier used by deployment technologies is the Media Access Control (MAC ) address that is associated with
each Ethernet adapter. However, when you use the same Ethernet adapter to deploy to multiple computers, you
cannot use a deployment technology that inspects MAC addresses because there is no way to differentiate the
MAC address of the removable adapter when used on the different computers.
The simplest solution to avoid MAC address conflicts is to provide a dedicated removable Ethernet adapter for
each Surface device. This can make sense in many scenarios where the Ethernet adapter or the additional
functionality of the docking station will be used regularly. However, not all scenarios call for the additional
connectivity of a docking station or support for wired networks.
Another potential solution to avoid conflict when adapters are shared is to use the Microsoft Deployment Toolkit
(MDT) to perform deployment to Surface devices. MDT does not use the MAC address to identify individual
computers and thus is not subject to this limitation. However, MDT does use Windows Deployment Services to
provide PXE boot functionality, and is subject to the limitations regarding pre-staged clients which is covered later
in this section.
When you use a shared adapter for deployment, the solution for affected deployment technologies is to use
another means to identify unique systems. For Configuration Manager and WDS, both of which can be affected by
this issue, the solution is to use the System Universal Unique Identifier (System UUID ) that is embedded in the
computer firmware by the computer manufacturer. For Surface devices, you can see this entry in the computer
firmware under Device Information.
To access the firmware of a Surface device, follow these steps:
1. Ensure the Surface device is powered off.
2. Press and hold the Volume Up button.
3. Press and release the Power button.
4. After the device begins to boot, release the Volume Up button.
When deploying with WDS, the MAC address is only used to identify a computer when the deployment server is
configured to respond only to known, pre-staged clients. When pre-staging a client, an administrator creates a
computer account in Active Directory and defines that computer by the MAC address or the System UUID. To
avoid the identity conflicts caused by shared Ethernet adapters, you should use System UUID to define pre-staged
clients. Alternatively, you can configure WDS to respond to unknown clients that do not require definition by either
MAC address or System UUID by selecting the Respond to all client computers (known and unknown)
option on the PXE Response tab in Windows Deployment Server Properties.
The potential for conflicts with shared Ethernet adapters is much higher with Configuration Manager. Where WDS
only uses MAC addresses to define individual systems when configured to do so, Configuration Manager uses the
MAC address to define individual systems whenever performing a deployment to new or unknown computers.
This can result in improperly configured devices or even the inability to deploy more than one system with a
shared Ethernet adapter. There are several potential solutions for this situation that are described in detail in the
How to Use The Same External Ethernet Adapter For Multiple SCCM OSD blog post on the Ask Premier Field
Engineering (PFE ) Platforms TechNet blog.
 Microsoft Surface Deployment Accelerator
9/28/2018 • 5 minutes to read • Edit Online

Microsoft Surface Deployment Accelerator (SDA) provides a quick and simple deployment mechanism for
organizations to reimage Surface devices.
SDA includes a wizard that automates the creation and configuration of a Microsoft recommended deployment
experience by using free Microsoft deployment tools. The resulting deployment solution is complete with
everything you need to immediately begin the deployment of Windows to a Surface device. You can also use SDA
to create and capture a Windows reference image and then deploy it with the latest Windows updates.
SDA is built on the powerful suite of deployment tools available from Microsoft including the Windows
Assessment and Deployment Kit (ADK), the Microsoft Deployment Toolkit (MDT), and Windows Deployment
Services (WDS ). The resulting deployment share encompasses the recommended best practices for managing
drivers during deployment and automating image creation and can serve as a starting point upon which you build
your own customized deployment solution.
You can find more information about how to deploy to Surface devices, including step-by-step walkthroughs of
customized deployment solution implementation, on the Deploy page of the Surface TechCenter.
Download Microsoft Surface Deployment Accelerator
You can download the installation files for SDA from the Microsoft Download Center. To download the installation
files:
1. Go to the Surface Tools for IT page on the Microsoft Download Center.
2. Click the Download button, select the Surface_Deployment_Accelerator_xxxx.msi file, and then click
Next.

Microsoft Surface Deployment Accelerator prerequisites

Before you install SDA, your environment must meet the following prerequisites:
SDA must be installed on Windows Server 2012 R2 or later
PowerShell Script Execution Policy must be set to Unrestricted
DHCP and DNS must be enabled on the network where the Windows Server 2012 R2 environment is
connected
To download Surface drivers and apps automatically the Windows Server 2012 R2 environment must have
Internet access and Internet Explorer Enhanced Security Configuration must be disabled
To support network boot, the Windows Server 2012 R2 environment must have Windows Deployment
Services installed and configured to respond to PXE requests
Access to Windows source files or installation media is required when you prepare a deployment with SDA
At least 6 GB of free space for each version of Windows you intend to deploy

How Microsoft Surface Deployment Accelerator works

As you progress through the SDA wizard, you will be asked some basic questions about how your deployment
solution should be configured. As you select the desired Surface models to be supported and apps to be installed
(see Figure 1), the wizard will prepare scripts that download, install, and configure everything needed to perform a
complete deployment and capture of a reference image. By using the network boot (PXE ) capabilities of Windows
Deployment Services (WDS ), the resulting solution enables you to boot a Surface device from the network and
perform a clean deployment of Windows.

Figure 1. Select desired apps and drivers

When the SDA completes, you can use the deployment share to deploy over the network immediately. Simply
boot your Surface device from the network using a Surface Ethernet Adapter and select the Surface deployment
share you created with the SDA wizard. Select the 1- Deploy Microsoft Surface task sequence and the wizard
will walk you through an automated deployment of Windows to your Surface device.
You can modify the task sequence in the MDT Deployment Workbench to include your own apps, or to pause the
automated installation routine. While the installation is paused, you can make changes to customize your reference
image. After the image is captured, you can configure a deployment task sequence and distribute this custom
configuration by using the same network boot capabilities as before.

NOTE
With SDA v1.9.0258, Surface Pro 3, Surface Pro 4, and Surface Book are supported for Windows 10 deployment, and Surface
Pro 3 is supported for Windows 8.1 deployment.

Use Microsoft Surface Deployment Accelerator without an Internet

connection
For environments where the SDA server will not be able to connect to the Internet, the required Surface files can
be downloaded separately. To specify a local source for Surface driver and app files, select the Copy from a local
directory option and specify the location of your downloaded files (see Figure 2). All of the driver and app files for
your selected choices must be placed in the specified folder.
Figure 2. Specify a local source for Surface driver and app files
You can find a full list of available driver downloads at Download the latest firmware and drivers for Surface
devices

NOTE
Downloaded files do not need to be extracted. The downloaded files can be left as .zip files as long as they are stored in one
folder.

NOTE
Using files from a local directory is not supported when including Office 365 in your deployment share. To include Office 365
in your deployment share, select the Download from the Internet check box.

Changes and updates

SDA is periodically updated by Microsoft. For instructions on how these features are used, see Step-by-Step:
Microsoft Surface Deployment Accelerator.

NOTE
To install a newer version of SDA on a server with a previous version of SDA installed, you only need to run the installation
file for the new version of SDA. The installer will handle the upgrade process automatically. If you used SDA to create a
deployment share prior to the upgrade and want to use new features of the new version of SDA, you will need to create a
new deployment share. SDA does not support upgrades of an existing deployment share.

Version 2.8.136.0
This version of SDA supports deployment of the following:
 Surface Book 2
Surface Laptop
Surface Pro LTE
Version 2.0.8.0
This version of SDA supports deployment of the following:
Surface Pro

NOTE
SDA version 2.0.8.0 includes support only for Surface Pro, and does not support other Surface devices such as Surface Pro 4
or Surface Book. To deploy these devices, please continue to use SDA version 1.96.0405.

Version 1.96.0405
This version of SDA adds support for the following:
Microsoft Deployment Toolkit (MDT) 2013 Update 2
Office 365 Click-to-Run
Surface 3 and Surface 3 LTE
Reduced Windows Assessment and Deployment Kit (Windows ADK) footprint, only the following Windows
ADK components are installed:
Deployment tools
Windows Preinstallation Environment (WinPE )
User State Migration Tool (USMT)
Version 1.90.0258
This version of SDA adds support for the following:
Surface Book
Surface Pro 4
Windows 10
Version 1.90.0000
This version of SDA adds support for the following:
Local driver and app files can be used to create a deployment share without access to the Internet
Version 1.70.0000
This version is the original release of SDA. This version of SDA includes support for:
MDT 2013 Update 1
Windows ADK
Surface Pro 3
Windows 8.1

Related topics
Step by step: Surface Deployment Accelerator
Using the Surface Deployment Accelerator deployment share
 Step by step: Surface Deployment Accelerator
10/1/2018 • 20 minutes to read • Edit Online

This article shows you how to install Microsoft Surface Deployment Accelerator (SDA), configure a deployment
share for the deployment of Windows to Surface devices, and perform a deployment to Surface devices. This
article also contains instructions on how to perform these tasks without an Internet connection or without support
for Windows Deployment Services network boot (PXE ).

How to install Surface Deployment Accelerator

For information about prerequisites and instructions for how to download and install SDA, see Microsoft Surface
Deployment Accelerator.
1. Download SDA, which is included in Surface Tools for IT on the Microsoft Download Center.
2. Run the SDA installation file, named Surface_Deployment_Accelerator_xxxx.msi, where xxxx is the
current version number.
3. Accept the End User License Agreement (EULA) by selecting the check box, and then click Install, as shown
in Figure 1.

Figure 1. SDA setup

4. Click Finish to complete the installation of SDA.
The tool installs in the SDA program group, as shown in Figure 2.

Figure 2. The SDA program group and icon

 NOTE
At this point, the tool has not yet prepared any deployment environment or downloaded any materials from the Internet.

Create a deployment share

The following steps show you how to create a deployment share for Windows 10 that supports Surface 3, Surface
Pro 3, Surface Pro 4, Surface Book, the Surface Firmware Tool, the Surface Asset Tag Tool, and Office 365. As you
follow the steps below, make the selections that are applicable for your organization. For example, you could
choose to deploy Windows 10 to Surface Book only, without any of the Surface apps.

NOTE
SDA lets you create deployment shares for both Windows 8.1 and Windows 10 deployments, but you can only create a
single deployment share at a time. Therefore, to create both Windows 8.1 and Windows 10 deployment shares, you will need
to run the tool twice.

1. Open the SDA wizard by double-clicking the icon in the Surface Deployment Accelerator program
group on the Start screen.
2. On the Welcome page, click Next to continue.
3. On the Verify System page, the SDA wizard verifies the prerequisites required for an SDA deployment
share. This process also checks for the presence of the Windows Assessment and Deployment Kit (Windows
ADK) for Windows 10 and the Microsoft Deployment Toolkit (MDT) 2013 Update 2. If these tools are not
detected, they are downloaded and installed automatically. Click Next to continue.

NOTE
As of SDA version 1.96.0405, SDA will install only the components of the Windows ADK that are required for
deployment, as follows:
Deployment tools
User State Migration Tool (USMT)
Windows Preinstallation Environment (WinPE)

NOTE
As of SDA version 1.96.0405, SDA will install and use MDT 2013 Update 2. Earlier versions of SDA are compatible
only with MDT 2013 Update 1.

4. On the Windows 8.1 page, to create a Windows 10 deployment share, do not select the Would you like
to support Windows 8.1 check box. Click Next to continue.
5. On the Windows 10 page, to create a Windows 10 deployment share, select the Would you like to
support Windows 10 check box. Supply the following information before you click Next to continue:
Configure Deployment Share for Windows 10
Local Path – Specify or browse to a location on the local storage device where you would like
to store the deployment share files for the Windows 10 SDA deployment share. For example,
E:\SDAWin10\ is the location specified in Figure 3.
Share Name – Specify a name for the file share that will be used to access the deployment
 share on this server from the network. For example, SDAWin10 is the deployment share
name shown in Figure 3. The local path folder is automatically shared by the SDA scripts
under this name to the group Everyone with a permission level of Full Control.
Windows 10 Deployment Services
Select the Import boot media into the local Windows Deployment Service check box if you
would like to boot your Surface devices from the network to perform the Windows deployment.
Windows Deployment Services must be installed and configured to respond to PXE boot
requests. See Windows Deployment Services Getting Started Guide for Windows Server 2012 for
more information about how to configure Windows Deployment Services for PXE boot.
Windows 10 Source Files
Local Path – Specify or browse to the root directory of Windows 10 installation files. If you have
an ISO file, mount it and browse to the root of the mounted drive. You must have a full set of
source files, not just Install.wim.

Figure 3. Specify Windows 10 deployment share options

6. On the Configure page, select the check box next to each device or app that you want to include in your
deployment share. Note that Surface Pro 4 and Surface Book only support Windows 10 and are not
available for the deployment of Windows 8.1. The Surface Firmware Tool is only applicable to Surface 3 and
Surface Pro 3 and cannot be selected unless Surface 3 or Surface Pro 3 drivers are selected, as shown in
Figure 4. Click Next to continue.
 Figure 4. Selecting Surface Firmware Tool requires Surface Pro 3 drivers

NOTE
You cannot select both Surface 3 and Surface 3 LTE models at the same time.

7. On the Summary page confirm your selections and click Finish to begin the creation of your deployment
share. The process can take several minutes as files are downloaded, the tools are installed, and the
deployment share is created. While the SDA scripts are creating your deployment share, an Installation
Progress window will be displayed, as shown in Figure 5. A typical SDA process includes:
Download of Windows ADK
Installation of Windows ADK
Download of MDT
Installation of MDT
Download of Surface apps and drivers
Creation of the deployment share
Import of Windows installation files into the deployment share
Import of the apps and drivers into the deployment share
Creation of rules and task sequences for Windows deployment
 Figure 5. The Installation Progress window

NOTE
The following error message may be hit while Installing the latest ADK or MDT: "An exception occurred during a
WebClient request.". This is due to incompatibility between SDA and BITS. Here is the workaround for this:

In the following two PowerShell scripts:

%ProgramFiles%\Microsoft\Surface\Deployment Accelerator\Data\PowerShell\Install-MDT.ps1
%ProgramFiles%\Microsoft\Surface\Deployment Accelerator\Data\PowerShell\INSTALL-WindowsADK.ps1

Edit the $BITSTransfer variable in the input parameters to $False as shown below:
Param( [Parameter( Position=0, Mandatory=$False, HelpMessage="Download via BITS bool true/false" )]
[string]$BITSTransfer = $False )

8. When the SDA process completes the creation of your deployment share, a **Success** window is displayed.
Click **Finish** to close the window. At this point your deployment share is now ready to perform a Windows
deployment to Surface devices.

### Optional: Create a deployment share without an Internet connection

If you are unable to connect to the Internet with your deployment server, or if you want to download the
Surface drivers and apps separately, you can specify a local source for the driver an app files at the time of
deployment share creation. On the **Configure** page of the SDA wizard, select the **Copy from a Local
Directory** check box, as shown in Figure 6. The **Download from the Internet** check box will be
automatically deselected. Enter the folder location where you have placed the driver and app files in the
**Local Path** field, as shown in Figure 6.

>[!NOTE]
>All of the downloaded driver and applications files must be located in the same folder. If a required driver
or application file is missing from the selected folder when you click **Next**, a warning is displayed and
the wizard will not proceed to the next step.

>[!NOTE]
>The driver and app files do not need to be extracted from the downloaded .zip files.

>[!NOTE]
>Including Office 365 in your deployment share requires an Internet connection and cannot be performed if you
use local files.

![Specify Surface driver and app files](images/sdasteps-fig6-specify-driver-app-files.png "Specify Surface

driver and app files")

*Figure 6. Specify the Surface driver and app files from a local path*

>[!NOTE]
>The **Copy from a Local Directory** check box is only available in SDA version 1.90.0221 or later.
### <a href="" id="optional"></a>Optional: Prepare offline USB media

You can use USB media to perform an SDA deployment if your Surface device is unable to boot from the network.
For example, if you do not have a Microsoft Surface Ethernet Adapter or Microsoft Surface dock to facilitate
network boot (PXE boot). The USB drive produced by following these steps includes a complete copy of the SDA
deployment share and can be run on a Surface device without a network connection.

>[!NOTE]
>The offline media files for the complete SDA deployment share are approximately 9 GB in size. Your USB drive
must be at least 9 GB in size. A 16 GB USB drive is recommended.

Before you can create bootable media files within the MDT Deployment Workbench or copy those files to a USB
drive, you must first configure that USB drive to be bootable. Using [DiskPart]
(https://go.microsoft.com/fwlink/p/?LinkId=761073), create a partition, format the partition as FAT32, and set
the partition to be active. To run DiskPart, open an administrative PowerShell or Command Prompt window, and
then run the following sequence of commands, as shown in Figure 7:

1. **diskpart** – Opens DiskPart to manage disks and partitions.

2. **list disk** – Displays a list of the disks available in your system; use this list to identify the disk
number that corresponds with your USB drive.

3. **sel disk 2** – Selects your USB drive; use the number that corresponds with the disk in your system.

4. **clean** – Removes all configuration from your USB drive.

>[!WARNING]
>This step will remove all information from your drive. Verify that your USB drive does not contain any
needed data before you perform the **clean** command.

5. **create part pri** – Creates a primary partition on the USB drive.

6. **format fs=fat32 quick** – Formats the partition with the FAT32 file system, performing a quick format.
FAT32 is required to boot the device from UEFI systems like Surface devices.

7. **assign** – Assigns the next available drive letter to the newly created FAT32 volume.

8. **active** – Sets the partition to be active, which is required to boot the volume.

9. **exit** – Exits DiskPart, after which you can close the PowerShell or Command Prompt window.

![Use DiskPart to prepare a USB drive for boot](images/sdasteps-fig7-diskpart.png "Use DiskPart to prepare
a USB drive for boot")

*Figure 7. Use DiskPart to prepare a USB drive for boot*

>[!NOTE]
>You can format your USB drive with FAT32 from Disk Management, but you must still use DiskPart to set the
partition as active for the drive to boot properly.

After you have prepared the USB drive for boot, the next step is to generate offline media from the SDA
deployment share. To create this media, follow these steps:

1. Open the **Deployment Workbench** from the **Microsoft Deployment Toolkit** group on your Start screen.

2. Expand the **Deployment Shares** node and the **Microsoft Surface Deployment Accelerator** deployment
share.

3. Expand the folder **Advanced Configuration** and select the **Media** folder.

4. Right-click the **Media** folder and click **New Media** as shown in Figure 8 to start the New Media
Wizard.

![The Media folder of the SDA deployment share](images/sdasteps-fig8-mediafolder.png "The Media folder of
the SDA deployment share")
the SDA deployment share")

*Figure 8. The Media folder of the SDA deployment share*

5. On the **General Settings** page in the **Media path** field, enter or browse to a folder where you will
create the files for the new offline media. See the example **E:\\SDAMedia** in Figure 9. Leave the default
profile **Everything** selected in the **Selection profile** drop-down menu, and then click **Next**.

![Specify a location and selection profile for your offline media](images/sdasteps-fig9-location.png

"Specify a location and selection profile for your offline media")

*Figure 9. Specify a location and selection profile for your offline media*

6. On the **Summary** page verify your selections, and then click **Next** to begin creation of the media.

7. A **Progress** page is displayed while the media is created.

8. On the **Confirmation** page, click **Finish** to complete creation of the media.

9. Right-click the **Microsoft Surface Deployment Accelerator** deployment share folder, click
**Properties**, and then click the **Rules** tab as shown in Figure 10.


*Figure 10. Rules of the SDA deployment share*

10. Use your mouse to highlight all of the text displayed in the text box of the **Rules** tab, and then press
**Ctrl+C** to copy the text.

11. Click **OK** to close the **Microsoft Surface Deployment Accelerator** deployment share properties.

12. Right-click the newly created **MEDIA001** item in the **Media** folder, click **Properties**, and then
click the **Rules** tab.

13. Use your mouse to highlight all of the text displayed in the text box of the **Rules** tab, and then press
**Ctrl+V** to paste the text you copied from the **Microsoft Surface Deployment Accelerator** deployment share
rules.

14. Right-click the **Microsoft Surface Deployment Accelerator** deployment share folder, click
**Properties**, and then click the **Rules** tab again. Click the **Bootstrap.ini** button to open
Bootstrap.ini in Notepad.

15. Press **Ctrl+A** to select all of the text in the window, and then press **Ctrl+C** to copy the text.

16. Close Bootstrap.ini and click **OK** in **Microsoft Surface Deployment Accelerator** deployment share
properties to close the window.

17. Right-click the newly created **MEDIA001** item in the **Media** folder, click **Properties**, and then
click the **Rules** tab again. Click the **Bootstrap.ini** button to open Bootstrap.ini in Notepad.

18. Press **Ctrl+A** to select all of the text in the window, then press **Ctrl+V** to paste the text from the
SDA deployment share Bootstrap.ini file.

19. Delete the following lines from the Bootstrap.ini as shown in Figure 11, and then save the file:

```
UserID=
UserDomain=
UserPassword=
DeployRoot=\\SDASERVER\SDAWin10
UserID=
UserDomain=
UserPassword=
```


*Figure 11. The Bootstrap.ini file of MEDIA001*

20. Close Bootstrap.ini and click **OK** in **MEDIA001** deployment share properties to close the window.

21. In the **Deployment Workbench** under the **Media** folder, right-click the newly created **MEDIA001** and
click **Update Media Content**, as shown in Figure 12. This will update the media files with the content of
the **Microsoft Surface Deployment Accelerator** deployment share.

![Select the Update Media Content option](images/sdasteps-fig12-updatemedia.png "Select the Update Media
Content option")

*Figure 12. Select the Update Media Content option*

22. The **Update Media Content** window is displayed and shows the progress as the media files are created.
When the process completes, click **Finish.**

The final step is to copy the offline media files to your USB drive.

1. In File Explorer, open the path you specified in Step 5, for example **E:\\SDAMedia**.

2. Copy all of the files from the Content folder to the root of the USB drive.

Your USB drive is now configured as bootable offline media that contains all of the resources required to
perform a deployment to a Surface device.

## SDA task sequences

The SDA deployment share is configured with all of the resources required to perform a Windows deployment to a
Surface device. These resources include Windows source files, image, Surface drivers, and Surface apps. The
deployment share also contains two pre-configured task sequences, as shown in Figure 13. These task sequences
contain the steps required to perform a deployment to a Surface device using the default Windows image from
the installation media or to create a reference image complete with Windows updates and applications. To learn
more about task sequences, see [MDT 2013 Update 2 Lite Touch components]
(https://technet.microsoft.com/itpro/windows/deploy/mdt-2013-lite-touch-components).

![Task sequences in the Deployment Workbench](images/sdasteps-fig13-taskseq.png "Task sequences in the

Deployment Workbench")

*Figure 13. Task sequences in the Deployment Workbench*

### Deploy Microsoft Surface

The **1 – Deploy Microsoft Surface** task sequence is used to perform a complete deployment of Windows to a
Surface device. This task sequence is pre-configured by the SDA wizard and is ready to perform a deployment as
soon as the wizard completes. Running this task sequence on a Surface device deploys the unaltered Windows
image copied directly from the Windows installation media you specified in the SDA wizard, along with the
Surface drivers for your device. The drivers for your Surface device will be automatically selected through
the pre-configured deployment share rules.

When you run the task sequence, you will be prompted to provide the following information:

- A computer name

- Your domain information and the credentials required to join the domain

- A product key, if one is required

>[!NOTE]
>If you are deploying the same version of Windows as the version that came on your device, no product key
is required.

- A time zone

- An Administrator password

The Surface apps you specified on the **Configure** page of the SDA wizard are automatically installed when
you run this task sequence on a Surface device.

### Create Windows reference image

The **2 – Create Windows Reference Image** task sequence is used to perform a deployment to a virtual machine
for the purpose of capturing an image complete with Windows Updates for use in a deployment to Surface
devices. By installing Windows Updates in your reference image, you eliminate the need to download and install
those updates on each deployed Surface device. The deployment process with an up-to-date image is
significantly faster and more efficient than performing a deployment first and then installing Windows Updates
on each device.

Like the **1 – Deploy Microsoft Surface** task sequence, the **2 – Create Windows Reference Image** task
sequence performs a deployment of the unaltered Windows image directly from the installation media. Creation
of a reference image should always be performed on a virtual machine. Using a virtual machine as your
reference system helps to ensure that the resulting image is compatible with different hardware
configurations.

>[!NOTE]
>Using a virtual machine when you create a reference image for Windows deployment is a recommended practice
for performing Windows deployments with Microsoft deployment tools including the Microsoft Deployment Toolkit
and System Center Configuration Manager. These Microsoft deployment technologies use the hardware agnostic
images produced from a virtual machine and a collection of managed drivers to deploy to different
configurations of hardware. For more information, see [Deploy a Windows 10 image using MDT 2013 Update 2]
(https://technet.microsoft.com/itpro/windows/deploy/deploy-a-windows-10-image-using-mdt).

In addition to the information required by the **1 – Deploy Microsoft Surface** task sequence, you will also
be prompted to capture an image when you run this task sequence on your reference virtual machine. The
**Location** and **File name** fields are automatically populated with the proper information for your
deployment share. All that you need to do is select the **Capture an image of this reference computer** option
when you are prompted on the **Capture Image** page of the Windows Deployment Wizard.

## Deployment to Surface devices

To perform a deployment from the SDA deployment share, follow this process on the Surface device:

1. Boot the Surface device to MDT boot media for the SDA deployment share. You can do this over the network
by using PXE boot, or from a USB drive as described in the [Optional: Prepare offline USB media](#optional)
section of this article.

2. Select the deployment share for the version of Windows you intend to deploy and enter your credentials
when you are prompted.

3. Select the task sequence you want to run, usually the **1 – Deploy Microsoft Surface** task sequence.

4. Address the task sequence prompts to pick applications, supply a password, and so on.

5. The task sequence performs the automated deployment using the options specified.

### Boot the Surface device from the network

To boot the Surface device from the network, the Microsoft Surface Deployment Accelerator wizard must have
been run on a Windows Server 2012 R2 or later environment that was configured with the Windows Deployment
Services (WDS). WDS must have been configured to respond to network boot (PXE boot) requests and the boot
files must have been imported into WDS. The SDA wizard will import these file automatically if the **Import
boot media into the local Windows Deployment Service** check box was selected on the page for the version of
Windows you intend to deploy.

To boot the Surface device from the network, you must also use a Microsoft Surface Ethernet Adapter or the
Ethernet port on a Microsoft Surface Dock. Third-party Ethernet adapters are not supported for network boot
(PXE boot). A keyboard is also required. Both the Microsoft Surface Type Cover and keyboards connected via USB
to the device or dock are supported.

To instruct your Surface device to boot from the network, start with the device powered off and follow these
steps:

1. Press and hold the **Volume Down** button, press and release the **Power** button. Continue holding the
**Volume Down** button until the device has begun to boot from the network.

2. Press **Enter** when prompted by the dialog on the screen. This prompt indicates that your device has
found the WDS PXE server over the network.
3. If you have configured more than one deployment share on this device, you will be prompted to select
between the boot images for each deployment share. For example, if you created both a Windows 10 and a Windows
8.1 deployment share, you will be prompted to choose between these two options.

4. Enter the domain credentials that you use to log on to the server where SDA is installed when you are
prompted, as shown in Figure 14.

![Prompt for credentials to the deployment share](images/sdasteps-fig14-credentials.png "Prompt for

credentials to the deployment share")

*Figure 14. The prompt for credentials to the deployment share*

5. The Windows Deployment Wizard will start from the deployment share to walk you through the deployment
process.

### Alternatively boot the devices from the USB stick

To boot a device from the USB stick:

1. Press and hold the **Volume Down** button, press and release the **Power** button. Continue holding the
**Volume Down** button until the device has begun to boot from the USB drive.

2. The Windows Deployment Wizard will start from the deployment share to walk you through the deployment
process.

### Run the Deploy Microsoft Surface task sequence

To run the Deploy Microsoft Surface task sequence:

1. On the **Task Sequence** page, select the **1 – Deploy Microsoft Surface** task sequence as shown in
Figure 15, and then click **Next.**


*Figure 15. Select the 1 – Deploy Microsoft Surface task sequence*

2. On the **Computer Details** page, type a name for the Surface device in the **Computer Name** box. In the
**Join a domain** section, type your domain name and credentials as shown in Figure 16, and then click
**Next**.

![Computer name and domain credentials](images/sdasteps-fig16-computername.png "Computer name and domain

credentials")

*Figure 16. Enter the computer name and domain information*

3. On the **Product Key** page, keep the **No product key is required** check box selected if you are
deploying the same version and edition of Windows to your Surface devices as they came with from the factory.
If you are deploying a different version or edition of Windows to the device, such as Windows Enterprise,
select the licensing option that is applicable to your scenario.

4. On the **Locale and Time** page, select your desired **Language Settings** and **Time Zone**, and then
click **Next.**

5. On the **Administrator Password** page, type a password for the local Administrator account on the Surface
device, and then click **Next.**

6. On the **BitLocker** page, select the **Enable BitLocker** option along with your desired configuration of
BitLocker protectors if you want to encrypt the device. Otherwise, keep the **Do not enable BitLocker for this
computer** check box selected, and then click **Next.**

7. On the **Ready** page, verify your selections and then click **Begin** to start the automated deployment
to this device. The deployment will not require user interaction again. The Windows Deployment Wizard will
close and an **Installation Progress** window is displayed to show progress of the task sequence as the image
is applied and applications are installed (Figure 17).

![Installation progress window](images/sdasteps-fig17-installprogresswindow.png "Installation progress

window")

*Figure 17. The Installation Progress window*

 *Figure 17. The Installation Progress window*

8. When the deployment task sequence completes, a **Success** window is displayed. Click **Finish** to
complete the deployment and begin using your Surface device.
 Using the Microsoft Surface Deployment Accelerator
deployment share
5/10/2018 • 11 minutes to read • Edit Online

With Microsoft Surface Deployment Accelerator (SDA), you can quickly and easily set up a deployment solution
that is ready to deploy Windows to Surface devices. The prepared environment is built on powerful deployment
technologies available from Microsoft, such as the Microsoft Deployment Toolkit (MDT), and is capable of
immediately performing a deployment after configuration. See Step-by-Step: Surface Deployment Accelerator for
a comprehensive walkthrough of using the SDA wizard to set up a deployment share and perform a deployment.
For more information about SDA and information on how to download SDA, see Microsoft Surface Deployment
Accelerator (SDA).
Using SDA provides these primary benefits:
With SDA, you can create a ready-to-deploy environment that can deploy to target devices as fast as your
download speeds allow. The wizard experience enables you to check a few boxes and then the automated
process builds your deployment environment for you.
With SDA, you prepare a deployment environment built on the industry leading deployment solution of
MDT. With MDT you can scale from a relatively basic deployment of a few Surface devices to a solution
capable of deploying to thousands of devices including all of the different makes and models in your
organization and all of the applications required by each device and user.
This article explores four scenarios where you can use SDA to meet the needs of your organization. See Deploy
Windows 10 to explore the capabilities of MDT and the Windows deployment technologies available from
Microsoft in greater detail.

Perform a Proof of Concept deployment

One of the primary scenarios for use of SDA is as a Proof of Concept. A Proof of Concept (PoC ) enables you to
test or evaluate the capabilities of a solution or technology. A PoC is often used to illustrate the benefits of the
solution or technology to decision makers. For example, if you want to recommend Surface devices as a
replacement of older point of sale (POS ) systems, you could perform a PoC to demonstrate how Surface devices
provide superior computing power, flexibility, and connectivity when compared to alternate options.
Using SDA to prepare a PoC of Surface devices enables you to very quickly prepare a demonstration of Surface
device or devices, which gives you more time for customization or preparation. The flexibility of SDA even lets you
import resources, like applications and drivers, from existing MDT deployment infrastructure. See the Work with
existing deployment shares section later in this article for more information.
SDA is also an excellent PoC of the capabilities of MDT. SDA demonstrates just how quickly an MDT deployment
environment can be prepared and made ready for deployment to devices. It also shows just how flexible and
customizable the MDT solution can be, with support for Windows 10 and Windows 8.1, for Microsoft Store and
desktop applications, and several models of Surface devices.
Some recommendations for a successful PoC with SDA are:
Keep your SDA deployment environment separate from your production network. This ensures optimal
performance and reduces potential for conflicts during your PoC deployment.
Use a fresh and updated instance of Windows Server to house your SDA deployment share to maintain the
 simplicity and performance of the demonstration environment.
Test the deployment process before you demonstrate your PoC. This reduces the potential for unexpected
situations and keeps the demonstration focused on the deployment process and Surface devices.
Use offline files with SDA to further reduce installation times.
For help with your PoC, contact Surface Support.

Perform a pilot deployment

A pilot deployment differs from a PoC. Where a PoC is usually a closed demonstration that is performed prior to
the deployment process in order to get approval for the use of certain technologies or solutions, a pilot
deployment is performed during the deployment process as a limited scope deployment for testing and validation.
The focus of a pilot deployment can be as narrow as only a handful of devices, or wide enough to include a
significant portion of your organization.

NOTE
A pilot deployment should not replace the testing process that should be performed regularly in the lab as the deployment
environment is built and developed. A deployment solution should be tested in virtual and physical environments as new
applications and drivers are added and when task sequences are modified and before a pilot deployment is performed.

For example, you are tasked with deploying Surface devices to mobile workers and you want to test the
organization’s MDT deployment process by providing a small number of devices to executives. You can use SDA to
create an isolated Surface deployment environment and then copy the task sequence, applications, and drivers
needed from the production deployment share. This not only enables you to quickly create a Surface deployment,
but it also minimizes the risk to the production deployment process used for other types of devices.
For small organizations, the pilot deployment environment of SDA may suffice as a complete deployment solution.
Even if you do not have an existing deployment environment, you can import drivers and applications (covered
later in this article) to provide a complete deployment solution based on MDT. Even without previous knowledge
of MDT or Windows deployment, you can follow the Step-by-Step: Surface Deployment Accelerator article to get
started with a deployment to Surface devices.

Import additional drivers

The SDA deployment share includes all of the drivers needed for Surface devices. This includes the drivers for the
components inside the Surface device, such as the wireless network adapter and the main chipset, as well as
drivers for Surface accessories, such as the Surface Dock or Surface USB Ethernet adapters. The SDA deployment
share does not, however, include drivers for third-party devices or peripherals.
For example, you may intend to use your Surface device with a thermal printer, credit card reader, and barcode
scanner as a POS terminal. In this scenario, the thermal printer, credit card reader, and barcode scanner will very
likely require installation of drivers to operate properly. You could potentially download and install these drivers
from Windows Update when each peripheral is connected, or you could install the driver package from the
manufacturer manually on each Surface device, but the ideal solution is to have these drivers already present in
Windows so that when the peripheral is connected, it will just work.
Because SDA is built on MDT, adding the drivers to the SDA deployment share is easy and simple.
 NOTE
The drivers must be in the Setup Information File (.inf) format. If the drivers for your device come as an executable file (.exe),
they may need to be extracted or installed to procure the .inf file. Some device drivers come packaged with applications, for
example an all-in-one printer bundled with scan software. These applications will need to be installed separately from the
drivers.

To import drivers for a peripheral device:

1. Download the drivers for your device from the manufacturer web site.
2. Open the MDT Deployment Workbench.
3. Expand the Deployment Shares node and expand the SDA deployment share.
4. Expand the Out-of-Box Drivers folder.
5. Select the folder of the Surface model for which you would like to include this driver.
6. Click Import Drivers to start the Import Drivers Wizard, as shown in Figure 1.

Figure 1. Provide the location of your driver files

7. The Import Drivers Wizard presents a series of steps:
Specify Directory – Click Browse and navigate to the folder where you stored the drivers in Step 1.
Summary – Review the specified configuration on this page before you click Next to begin the import
process.
Progress – While the drivers are imported, a progress bar is displayed on this page.
Confirmation – When the import process completes, the success of the process is displayed on this
 page. Click Finish to complete the Import Drivers Wizard.
8. Repeat Steps 5-7 for each Surface model on which you would like to include this driver.
9. Close the Deployment Workbench.
After the drivers are imported for the Surface model, the deployment task sequence will automatically select the
drivers during the deployment process and include them in the Windows environment. When you connect your
device, such as the barcode scanner in the example, Windows should automatically detect the device and you
should be able to use it immediately.

NOTE
You can even import drivers for other computer makes and models to support other devices. See Step 5: Prepare the
drivers repository in Deploy a Windows 10 image using MDT 2013 Update 2 for more information about how to import
drivers for other makes and models.

Import additional applications

As with drivers, the SDA deployment share can be pre-configured with apps like the Surface App and Microsoft
Office 365. You can also add applications to the SDA deployment share and configure them to be installed on your
Surface devices during deployment of Windows. In the ideal scenario, your Surface devices deployed with the SDA
deployment share will include all of the applications needed to be ready for your end users.
In the previous example for including drivers for a POS system, you would also need to include POS software for
processing transactions and recording the input from the barcode scanner and credit card reader. To import an
application and prepare it for installation on your Surface devices during Windows deployment:
1. Download the application installation files or locate the installation media for your application.
2. Determine the command line instruction for silent installation, usually provided by the developer of the
application. For Windows Installer files (.msi), see Standard Installer Command-Line Options in the
Windows Dev Center.
3. Open the MDT Deployment Workbench.
4. Expand the Deployment Shares node and expand the SDA deployment share.
5. Expand the Applications folder.
6. Click New Application to start the New Application Wizard, as shown in Figure 2.
 Figure 2: Provide the command to install your application
7. Follow the steps of the New Application Wizard:
Application Type – Click Application with Source Files, and then click Next.
Details – Enter a name for the application in the Application Name field. Enter publisher, version, and
language information in the Publisher, Version, and Language fields if desired. Click Next.
Source – Click Browse to navigate to and select the folder with the application installation files procured
in Step 1, and then click Next.
Destination – Enter a name for the folder where the application files will be stored in the Specify the
Name of the Directory that Should Be Created field or click Next to accept the default name.
Command Details – Enter the silent command-line instruction, for example
setup.msi /quiet /norestart
Summary – Review the specified configuration on this page before you click Next to begin the import
process.
Progress – While the installation files are imported, a progress bar is displayed on this page.
Confirmation – When the import process completes, the success of the process is displayed on this
page. Click Finish to complete the New Application Wizard.
8. Click the Task Sequences folder, right-click 1 - Deploy Microsoft Surface, and then click Properties.
9. Click the Task Sequence tab to view the steps that are included in the new task sequence.
10. Select the Windows Update (Pre-Application Installation) step, and then click Add.
11. Hover the mouse over General under the Add menu, and then click Install Application. This will add a
new step after the selected step for the installation of a specific application as shown in Figure 3.
 Figure 3. A new Install Application step for Sample POS App
12. On the Properties tab of the new Install Application step, enter Install - Sample POS App in the Name
field, where Sample POS App is the name of your app.
13. Click Install a Single Application, and then click Browse to view available applications that have been
imported into the deployment share.
14. Select your app from the list of applications, and then click OK.
15. Click OK to close the task sequence properties.
16. Close the Deployment Workbench.

Work with existing deployment shares

One of the many benefits of an MDT deployment share is the simplicity of how deployment resources are stored.
The MDT deployment share is, at its core, just a standard network file share. All deployment resources, such as
Windows images, application installation files, and drivers, are stored in a share that can be browsed with File
Explorer, copied and pasted, and moved just like any other file share, provided that you have the necessary
permissions. This makes working with deployment resources extremely easy. MDT even allows you to make it
easier by allowing you to open multiple deployment shares from the Deployment Workbench and to transfer or
copy resources between them.
This ability gives SDA some extra capabilities when used in an environment with an existing MDT infrastructure.
For example, if you install SDA on an isolated server to prepare a PoC and then log on to your production MDT
deployment share from the Deployment Workbench on your SDA server, you can copy applications, drivers, task
sequences, and other components into the SDA deployment share that is prepared with Surface apps and drivers.
With this process, in a very short amount time, you can have a deployment environment ready to deploy your
organization’s precise requirements to Surface devices.
You can also use this capability in reverse. For example, you can copy the Surface drivers, deployment task
sequences, and apps directly into a lab or testing environment following a successful PoC. Using these resources,
you can immediately begin to integrate Surface deployment into your existing deployment infrastructure.
 Battery Limit settings
10/29/2018 • 2 minutes to read • Edit Online

Battery Limit option is a UEFI setting that changes how the Surface device battery is charged and may prolong its
longevity. This setting is recommended in cases in which the device is continuously connected to power, for
example when devices are integrated into kiosk solutions.

Battery Limit information

Setting the device on Battery Limit changes the protocol for charging the device battery. When Battery Limit is
enabled, the battery charge will be limited to 50% of its maximum capacity. The charge level reported in Windows
will reflect this limit. Therefore, it will show that the battery is charged up to 50% and will not charge beyond this
limit. If you enable Battery Limit while the device is above 50% charge, the Battery icon will show that the device is
plugged in but discharging until the device reaches 50% of its maximum charge capacity.
Adding the Battery Limit option to Surface UEFI will require a Surface UEFI firmware update, which will be made
available through Windows Update or via the MSI driver and firmware packages on the Microsoft Download
Center. Check Enable "Battery Limit" for Surface devices that have to be plugged in for extended periods of time
for the specific Surface UEFI version required for each device and supported devices. Currently, Battery Limit is
only supported on Surface Pro 4 and Surface Pro 3. However, the setting will be available in the future on other
Surface device models.

Enabling Battery Limit in Surface UEFI (Surface Pro 4 and later)

The Surface UEFI Battery Limit setting can be configured by booting into Surface UEFI (Power + Vol Up when
turning on the device). Choose boot configuration, and then, under Advanced Options, toggle Enable Battery
Limit Mode to On.

Enabling Battery Limit in Surface UEFI (Surface Pro 3)

The Surface UEFI Battery Limit setting can be configured by booting into Surface UEFI (Power + Vol Up when
turning on the device). Choose Kiosk Mode, select Battery Limit, and then choose Enabled.
Enabling Battery Limit using Surface Enterprise Management Mode
(SEMM) or Surface Pro 3 firmware PowerShell scripts
The Surface UEFI battery limit is also available for configuration via the following methods:
Surface Pro 4 and later
Microsoft Surface UEFI Configurator
Surface UEFI Manager Powershell scripts (SEMM_Powershell.zip) in the Surface Tools for IT downloads
Surface Pro 3
SP3_Firmware_Powershell_Scripts.zip
Using Microsoft Surface UEFI Configurator
To configure Battery Limit mode, set the Kiosk Overrides setting on the Advanced Settings configuration page
in SEMM (Surface Pro 4 and later).

Using Surface UEFI Manager PowerShell scripts

The battery limit feature is controlled via the following setting:
407 = Battery Profile

Description: Active management scheme for battery usage pattern

Default: 0

Set this to 1 to enable Battery Limit.

Using Surface Pro 3 firmware tools
The battery limit feature is controlled via the following setting:
Name: BatteryLimitEnable
Description: BatteryLimit
Current Value: 0

Default Value: 0

Proposed Value: 0

Set this to 1 to enable Battery Limit.

NOTE
To configure this setting, you must use SP3_Firmware_Powershell_Scripts.zip.
 Surface firmware and driver updates
11/14/2018 • 2 minutes to read • Edit Online

Find out how to download and manage the latest firmware and driver updates for your Surface device.

In this section
TOPIC DESCRIPTION

Wake On LAN for Surface devices See how you can use Wake On LAN to remotely wake up
devices to perform management or maintenance tasks, or to
enable management solutions automatically.

Download the latest firmware and drivers for Surface devices Get a list of the available downloads for Surface devices and
links to download the drivers and firmware for your device.

Manage Surface driver and firmware updates Explore the available options to manage firmware and driver
updates for Surface devices.

Surface Dock Updater Get a detailed walkthrough of Microsoft Surface Dock

Updater.

Related topics
Surface TechCenter
Surface for IT pros blog
 Download the latest firmware and drivers for Surface
devices
11/15/2018 • 7 minutes to read • Edit Online

This article provides a list of the available downloads for Surface devices and links to download the drivers and
firmware for your device.
As easy as it is to keep Surface device drivers and firmware up to date automatically with Windows Update, it is
sometimes necessary to download and install updates manually, such as during a Windows deployment. For any
situation where you need to install drivers and firmware separately from Windows Update, you can find the files
available for download at the Microsoft Download Center.
On the Microsoft Download Center page for your device, you will find several files available. These files allow you
to deploy drivers and firmware in various ways. You can read more about the different deployment methods for
Surface drivers and firmware in Manage Surface driver and firmware updates.
Driver and firmware updates for Surface devices are cumulative updates which provide comprehensive
roundups of all of the latest files for the Surface device running that version of Windows.
Installation files for administrative tools, drivers for accessories, and updates for Windows are also available for
some devices and are detailed here in this article.

NOTE
To simplify the process of locating drivers for your device, downloads for Surface devices have been reorganized to separate
pages for each model. Bookmark the Microsoft Download Center page for your device from the links provided on this page.
Many of the filenames contain a placeholder denoted with xxxxxx, which identifies the current version number or date of the
file.

Recent additions to the downloads for Surface devices provide you with options to install Windows 10 on your
Surface devices and update LTE devices with the latest Windows 10 drivers and firmware.

NOTE
A battery charge of 40% or greater is required before you install firmware to a Surface device. See Microsoft Support article
KB2909710 for more information.

Surface GO
Download the following updates for Surface GO from the Microsoft Download Center.
SurfaceGO_Win10_17134_1802010_6.msi - Cumulative firmware and driver update package for Windows 10

Surface Book 2
Download the following updates for Surface Book 2 from the Microsoft Download Center.
SurfaceBook2_Win10_xxxxx_xxxxxx.msi – Cumulative firmware and driver update package for Windows 10

Surface Laptop
Download the following updates for Surface Laptop from the Microsoft Download Center.
SurfaceLaptop_Win10_xxxxx_xxxxxx.msi – Cumulative firmware and driver update package for Windows 10

Surface Pro
Download the following updates for Surface Pro (Model 1796) from the Microsoft Download Center.
SurfacePro_Win10_xxxxx_xxxxxx.msi – Cumulative firmware and driver update package for Windows 10

Surface Pro with LTE Advanced

Download the following updates for Surface Pro with LTE Advanced from the Microsoft Download Center.
SurfacePro_LTE_Win10_xxxxx_xxxxxx.msi – Cumulative firmware and driver update package for Windows 10

Surface Pro 6
Download the following updates for Surface Pro 6 from the Microsoft Download Center.
SurfacePro6_Win10_17134_xxxxx_xxxxxx.msi

Surface Studio
Download the following updates for Surface Studio from the Microsoft Download Center.
SurfaceStudio_Win10_xxxxx_xxxxxx.msi – Cumulative firmware and driver update package for Windows 10

Surface Book
Download the following updates for Surface Book from the Microsoft Download Center.
SurfaceBook_Win10_xxxxx_xxxxxx.msi – Cumulative firmware and driver update package for Windows 10
SurfaceBook_Win10_xxxxx_xxxxxx.zip – Cumulative firmware and driver update package for Windows 10
Wintab-xxxxx-64-bit.zip – Tablet driver update for all supported x64-based versions of Windows 8.1

Surface Pro 4
Download the following updates for Surface Pro 4 from the Microsoft Download Center.
SurfacePro4_Win10_xxxxx_xxxxxx.msi – Cumulative firmware and driver update package for Windows 10
SurfacePro4_Win10_xxxxx_xxxxxx.zip – Cumulative firmware and driver update package for Windows 10
Wintab-xxxxx-64-bit.zip – Tablet driver update for all supported x64-based versions of Windows 8.1

Surface Pro 3
Download the following updates for Surface Pro 3 from the Microsoft Download Center.
SurfacePro3_Win10_xxxxx_xxxxxx.msi – Cumulative firmware and driver update package for Windows 10
SurfacePro3_Win10_xxxxx_xxxxxx.zip – Cumulative firmware and driver update package for Windows 10
SurfacePro3_Win8x_xxxxx_xxxxxx.msi – Cumulative firmware and driver update package for Windows 8.1
Pro
SurfacePro3_Win8x_xxxxx_xxxxxx.zip – Cumulative firmware and driver update package for Windows 8.1
 Pro
Surface Firmware Tool.msi – Firmware tools for UEFI management
Surface Pro 3 AssetTag.zip – UEFI Asset Tag management tool
Surface Pro 3 KB2978002.zip – Update for Quick Note-Taking Experience feature in Windows 8.1
Windows8.1-KB2969817-x64.msu – Fixes an issue that causes Surface devices to reboot twice after
firmware updates are installed on all supported x64-based versions of Windows 8.1
Wintab-xxxxx-64-bit.zip – Tablet driver update for all supported x64-based versions of Windows 8.1

Surface 3
Download the following updates for Surface 3 from the Microsoft Download Center.
Surface3_WiFi_Win10_xxxxx_xxxxxx.msi – Cumulative firmware and driver update package for Windows 10
Surface3_WiFi_Win10_xxxxx_xxxxxx.zip – Cumulative firmware and driver update package for Windows 10
Surface3_WiFi_Win8x_xxxxx_xxxxxx.msi – Cumulative firmware and driver update package for Windows
8.1 Pro
Surface3_WiFi_Win8x_xxxxx_xxxxxx.zip – Cumulative firmware and driver update package for Windows 8.1
Pro
Surface 3 AssetTag.zip – UEFI Asset Tag management tool
Wintab-xxxxx-64-bit.zip – Tablet driver update for all supported x64-based versions of Windows 8.1

Surface 3 LTE
Download the following updates for AT&T 4G LTE versions of Surface 3 from the Microsoft Download Center.
Surface3_4GLTE -ATT_Win10_xxxxx_xxxxxx.msi – Surface 3 LTE AT&T - Cumulative firmware and driver
update for locked carrier dependent AT&T devices in the US, running Windows 10
Surface3_4GLTE -ATT_Win10_xxxxx_xxxxxx.zip – Surface 3 LTE AT&T - Cumulative firmware and driver
update for locked carrier dependent AT&T devices in the US, running Windows 10
Surface3_4GLTE -ATT_Win8x_xxxxx_xxxxxx.msi – Surface 3 LTE AT&T - Cumulative firmware and driver
update for locked carrier dependent AT&T devices in the US, running Windows 8.1 Pro
Surface3_4GLTE -ATT_Win8x_xxxxx_xxxxxx.zip – Surface 3 LTE AT&T - Cumulative firmware and driver
update for locked carrier dependent AT&T devices in the US, running Windows 8.1 Pro
Surface 3 AssetTag.zip – UEFI Asset Tag management tool
Wintab-xxxxx-64-bit.zip – Tablet driver update for all supported x64-based versions of Windows 8.1
Download the following updates for non-AT&T 4G LTE versions of Surface 3 from the Microsoft Download
Center.
Surface3_4GLTE -NorthAmericaUnlocked_Win10_xxxxx_xxxxxx.msi – Surface 3 LTE North America -
Cumulative firmware and driver update for unlocked carrier independent devices in the US, running
Windows 10
Surface3_4GLTE -NorthAmericaUnlocked_Win10_xxxxx_xxxxxx.zip – Surface 3 LTE North America -
Cumulative firmware and driver update for unlocked carrier independent devices in the US, running
Windows 10
 Surface3_4GLTE -NorthAmericaUnlocked_Win8x_xxxxx_xxxxxx.msi – Surface 3 LTE North America -
Cumulative firmware and driver update for unlocked carrier independent devices in the US, running
Windows 8.1 Pro
Surface3_4GLTE -NorthAmericaUnlocked_Win8x_xxxxx_xxxxxx.zip – Surface 3 LTE North America -
Cumulative firmware and driver update for unlocked carrier independent devices in the US, running
Windows 8.1 Pro
Surface 3 AssetTag.zip – UEFI Asset Tag management tool
Wintab-xxxxx-64-bit.zip – Tablet driver update for all supported x64-based versions of Windows 8.1
Download the following updates for 4G LTE Surface 3 versions for regions outside North America from the
Microsoft Download Center.
Surface3_4GLTE -RestOfTheWorld_Win10_xxxxx_xxxxxx.msi – Surface 3 LTE rest of the world cumulative -
Cumulative firmware and driver update for carrier independent devices outside of the US, as well as for
Japan, running Windows 10
Surface3_4GLTE -RestOfTheWorld_Win10_xxxxx_xxxxxx.zip – Surface 3 LTE rest of the world cumulative -
Cumulative firmware and driver update for carrier independent devices outside of the US, as well as for
Japan, running Windows 10
Surface3_4GLTE -RestOfTheWorld_Win8x_xxxxx_xxxxxx.msi – Surface 3 LTE rest of the world cumulative -
Cumulative firmware and driver update for carrier independent devices outside of the US, as well as for
Japan, running Windows 8.1 Pro
Surface3_4GLTE -RestOfTheWorld_Win8x_xxxxx_xxxxxx.zip – Surface 3 LTE rest of the world cumulative -
Cumulative firmware and driver update for carrier independent devices outside of the US, as well as for
Japan, running Windows 8.1 Pro
Surface 3 AssetTag.zip – UEFI Asset Tag management tool
Wintab-xxxxx-64-bit.zip – Tablet driver update for all supported x64-based versions of Windows 8.1

Surface Pro 2
Download the following updates for Surface Pro 2 from the Microsoft Download Center.
SurfacePro2_Win10_xxxxxx.zip – Cumulative firmware and driver update package for Windows 10
SurfacePro2_Win8x_xxxxxx.zip – Cumulative firmware and driver update package for Windows 8.1 Pro
Surface Ethernet Adapter.zip – x64 Ethernet adapter drivers
Surface Gigabit Ethernet Adapter.zip – x64 Ethernet adapter drivers
Windows8.1-KB2969817-x64.msu – Fixes an issue that causes Surface devices to reboot twice after
firmware updates are installed on all supported x64-based versions of Windows 8.1

Surface Pro
Download the following updates for Surface Pro (Model 1514) from the Microsoft Download Center.
SurfacePro_Win10_xxxxxx.zip – Cumulative firmware and driver update package for Windows 10
Surface Pro 1 - xxxxxx.zip – Cumulative firmware and driver update package for Windows 8.1 Pro
Surface Ethernet Adapter.zip – x64 Ethernet adapter drivers
Surface Gigabit Ethernet Adapter.zip – x64 Ethernet adapter drivers
 Windows8.1-KB2969817-x64.msu – Fixes an issue that causes Surface devices to reboot twice after
firmware updates are installed on all supported x64-based versions of Windows 8.1

Surface devices with Windows RT

There are no downloadable firmware or driver updates available for Surface devices with Windows RT, including
Surface RT and Surface 2. Updates can only be applied using Windows Update.
If you have additional questions on the driver pack and updates, please contact Microsoft Surface support for
business.
 Manage Surface driver and firmware updates
6/27/2018 • 5 minutes to read • Edit Online

This article describes the available options to manage firmware and driver updates for Surface devices.
For a list of the available downloads for Surface devices and links to download the drivers and firmware for your
device, see Download the latest firmware and drivers for Surface devices.
On Surface devices, the firmware is exposed to the operating system as a driver and is visible in Device Manager.
This allows a Surface device firmware to be automatically updated along with all drivers through Windows
Update. This mechanism provides a seamless, automatic experience to receive the latest firmware and driver
updates. Although automatic updating is easy for end users, updating firmware and drivers automatically may not
always apply to organizations and businesses. Automatic updates with Windows Update may not be applicable
where updates are carefully managed, or when you deploy a new operating system to a Surface device.

Methods for firmware deployment

Although firmware is provided automatically by Windows Update for computers that receive updates directly
from Microsoft, in environments where updates are carefully managed by using Windows Server Update Services
(WSUS ), updating the firmware through Windows Update is not supported. For managed environments, there are
a number of options you can use to deploy firmware updates.
Windows Update
The simplest solution to ensure that firmware on Surface devices in your organization is kept up to date is to allow
Surface devices to receive updates directly from Microsoft. You can implement this solution easily by excluding
Surface devices from Group Policy that directs computers to receive updates from WSUS.
Although this solution ensures that firmware will be updated as new releases are made available to Windows
Update, it does present potential drawbacks. Each Surface device that receives Windows Updates directly will
separately download each update rather than accessing a central location, which increases demand on Internet
connectivity and bandwidth. Updates are also provided automatically to devices, without being subjected to testing
or review by administrators.
For details about Group Policy for client configuration of WSUS or Windows Update, see Step 5: Configure Group
Policy Settings for Automatic Updates.
Windows Installer Package
The firmware and driver downloads for Surface devices now include Windows Installer files for firmware and
driver updates. These Windows Installer packages can be deployed with utilities that support application
deployment, including the Microsoft Deployment Toolkit (MDT) and System Center Configuration Manager. This
solution allows for centralized deployment and for administrators to test and review firmware updates before they
are deployed. For more information about the Windows Installer package delivery method for firmware and driver
updates, including details on what drivers are updated by the package and why certain drivers and firmware are
not updated by the Windows Installer package, see the Surface Pro 3 MSI Now Available blog post.
For instructions on how to deploy with System Center Configuration Manager, refer to How to Deploy
Applications in Configuration Manager. For deployment of applications with MDT, see Step 4: Add an application
in the Deploy a Windows 8.1 Image Using MDT 2013. Note that you can deploy applications separately from an
operating system deployment through MDT by using a Post OS Installation task sequence.
Provisioning packages
New in Windows 10, provisioning packages (PPKG files) provide a simple method to apply a configuration to a
destination device. You can find out more about provisioning packages, including instructions for how to create
your own, in Provisioning packages. For easy application of a complete set of drivers and firmware to devices
running Windows 10, a provisioning package is supplied for Surface Pro 3 devices. This file contains all of the
instructions and required assets to update a Surface Pro 3 device with Windows 10 to the latest drivers and
firmware.
Windows PowerShell
Another method you can use to update the firmware when Windows Updates are managed in the organization is
to install the firmware from the firmware and driver pack by using PowerShell. This method allows for a similar
deployment experience to the Windows Installer package and can similarly be deployed as a package by using
System Center Configuration Manager. You can find the PowerShell script and details on how to perform the
firmware deployment in the Deploying Drivers and Firmware to Surface Pro blog post.

Operating system deployment considerations

The deployment of firmware updates during an operating system deployment is a straightforward process. The
firmware and driver pack can be imported into either System Center Configuration Manager or MDT, and are
used to deploy a fully updated environment, complete with firmware, to a target Surface device. For a complete
step-by-step guide for deployment to Surface Pro 3 using either Configuration Manager or MDT, download the
Deployment and Administration Guide for Surface Pro 3 from the Microsoft Download Center.
The individual driver files are also made available in the Microsoft Download Center if you are using deployment
tools. The driver files are available in the ZIP archive file in the list of available downloads for your device.
Windows PE and Surface firmware and drivers
A best practice for deployment with any solution that uses the Windows Preinstallation Environment (WinPE ),
such as System Center Configuration Manager or MDT, is to configure WinPE with only the drivers that are
required during the WinPE stage of deployment. These usually include drivers for network adapters and storage
controllers. This best practice helps to prevent errors with more complex drivers that rely on components that are
not present in WinPE. For Surface Pro 3 devices, this is especially true of the Touch Firmware. The Touch Firmware
should never be loaded in a WinPE environment on Surface Pro 3.
Update Surface Pro 3 firmware offline through USB
In some early versions of Surface Pro 3 firmware, PXE boot performance can be quite slow. This has been resolved
with updated firmware, but for organizations where firmware will be updated through operating system
deployment, this issue is encountered before the updates can be deployed to the device. In this scenario, you can
deploy updated firmware through a USB drive to ensure that when the operating system deployment is initiated,
the network boot is quick, and deployment can complete in a timely fashion. To create a USB drive to update
Surface Pro 3 firmware, see How to Update the Surface Pro 3 Firmware Offline using a USB Drive on the Ask
Premier Field Engineering (PFE ) Platforms TechNet Blog.
 Microsoft Surface Dock Updater
11/13/2018 • 6 minutes to read • Edit Online

This article provides a detailed walkthrough of Microsoft Surface Dock Updater.

The Microsoft Surface Dock Updater tool allows you to check the firmware status of a Surface Dock and to
manually update the firmware of Surface Dock devices. It is most often used to update Surface Docks prior to
deployment of those Surface Docks to end users or as a troubleshooting tool. Microsoft Surface Dock Updater
walks you through the process of updating the firmware on one or more Surface Docks, including the required
connect and disconnect steps to perform the complete firmware installation.
When you run the Microsoft Surface Dock Updater installer you will be prompted to accept an End User License
Agreement (EULA).

NOTE
Updating Surface Dock firmware requires connectivity to the Surface Dock via the Surface Connect™ port. Installation of the
Microsoft Surface Dock Updater is only supported on devices that feature the Surface Connect™ port.

NOTE
The Surface Dock Updater tool is unable to run on Windows 10 S. Surface Dock devices used with Surface Laptop with
Windows 10 S will receive updates natively through Windows Update. To manually update a Surface Dock for use with
Surface Laptop and Windows 10 S, connect the Surface Dock to another Surface device with a Windows 10 Pro or Windows
10 Enterprise environment.

Update a Surface Dock with Microsoft Surface Dock Updater

After you install the Microsoft Surface Dock Updater tool, you can find Microsoft Surface Dock Updater under All
Apps in your Start menu. Click Microsoft Surface Dock Updater to start the application.
To update a Surface Dock with Microsoft Surface Dock Updater, follow these steps:
1. Click Start to begin the firmware update process. If you do not have a Surface Dock connected, you will be
prompted to connect a Surface Dock.
2. Microsoft Surface Dock Updater checks the status of your Surface Dock firmware.
If the tool determines that the firmware of your Surface Dock is up to date, a You have the latest
firmware for this Surface Dock message is displayed, as shown in Figure 1.
 Figure 1. Your Surface Dock firmware is up to date
If Microsoft Surface Dock Updater determines that the firmware of your Surface Dock is not up to
date, a This Surface Dock is not running the latest firmware message is displayed, as shown in
Figure 2.

Figure 2. Your Surface Dock firmware needs to be updated

3. To begin the firmware update process, click Update on the Surface Dock Firmware page.
4. Before the firmware update process begins, you will be prompted for confirmation. Click OK to proceed or
Cancel to return to the Surface Dock Firmware page displaying the status of your Surface Dock
firmware.
5. As the firmware update is uploaded to the Surface Dock, a Progress page is displayed, as shown in Figure
3. Do not disconnect the Surface Dock while firmware is being uploaded.

Figure 3. Progress of firmware update upload to Surface Dock

6. After the firmware update has successfully uploaded to the Surface Dock, you are prompted to disconnect
and then reconnect the Surface Dock from the Surface device, as shown in Figure 4. The main chipset
firmware update will be applied while the Surface Dock is disconnected.

Figure 4. Disconnect and reconnect Surface Dock when prompted

7. When the main chipset firmware update is verified, the DisplayPort chipset firmware update will be
 uploaded to the Surface Dock. Upon completion, a Success page is displayed and you will again be
prompted to disconnect the Surface Dock, as shown in Figure 5.

Figure 5. Successful upload of Surface Dock firmware

8. After you disconnect the Surface Dock the DisplayPort firmware update will be installed. This process
occurs on the Surface Dock hardware while it is disconnected. The Surface Dock must remain powered for
up to 3 minutes after it has been disconnected for the firmware update to successfully install. An Update in
Progress page is displayed (as shown in Figure 6), with a countdown timer to show the estimated time
remaining to complete the firmware update installation.

Figure 6. Countdown timer to complete firmware installation on Surface Dock

9. If you want to update multiple Surface Docks in one sitting, you can click the Update another Surface
Dock button to begin the process on the next Surface Dock.

NOTE
The LED in the Ethernet port of the dock will blink while the update is in progress. Please wait until the LED stops
blinking before you unplug your Surface Dock from power.

Troubleshooting Microsoft Surface Dock Updater

If the Surface Dock firmware update process encounters an installation error with either firmware update, the
Encountered an unexpected error page may be displayed, as shown in Figure 7.

Figure 7. Firmware update installation has encountered an error

Microsoft Surface Dock Updater logs its progress into the Event Log, as shown in Figure 8. If you need to
troubleshoot an update through this tool, you will find Surface Dock events recorded with the following event IDs:

EVENT ID EVENT TYPE

12100 Up-to-date confirmation

12101 Event in the main chipset firmware update process

12102 Event in the DisplayPort chipset firmware update process

12105 Error
Figure 8. Surface Dock Updater events in Event Viewer

Changes and updates

Microsoft periodically updates Surface Dock Updater.

NOTE
Each update to Surface Dock firmware is included in a new version of Surface Dock Updater. To update a Surface Dock to the
latest firmware, you must use the latest version of Surface Dock Updater.

Version 2.23.139.0
Release Date: 10 October 2018
This version of Surface Dock Updater adds support for the following:
Add support for Surface Pro 6
Add support for Surface Laptop 2
Version 2.22.139.0
Release Date: 26 July 2018
This version of Surface Dock Updater adds support for the following:
Increase update reliability
Add support for Surface Go
Version 2.12.136.0
Release Date: 29 January 2018
This version of Surface Dock Updater adds support for the following:
Update for Surface Dock Main Chipset Firmware
Update for Surface Dock DisplayPort Firmware
 Improved display stability for external displays when used with Surface Book or Surface Book 2
Additionally, installation of this version of Surface Dock Updater on Surface Book devices includes the following:
Update for Surface Book Base Firmware
Added support for Surface Dock firmware updates with improvements targeted to Surface Book devices

NOTE
Before the Surface Dock firmware update applied by Surface Dock Updater v2.12.136.0 will take effect on a Surface Book
device, a firmware update for the Surface Book Base is required. If you install Surface Dock Updater v2.12.136.0 on a Surface
Book and update an attached Surface Dock from that same device, the firmware of the Surface Book Base will automatically
be updated when installing the Surface Dock Updater. However, if you update a Surface Dock using Surface Dock Updater
v2.12.136.0 on different device, and then connect that Surface Dock to a Surface Book where Surface Dock Updater
v2.12.136.0 has not been installed, the benefits of the updated Surface Dock will not be enabled. To enable the benefits of
the updated Surface Dock on a Surface Book device, Surface Book Base firmware must also be updated by installing Surface
Dock Updater v2.12.136.0 on the Surface Book device. Surface Book Base firmware update is not required on a Surface Book
2 device.

Version 2.9.136.0
Release date: November 3, 2017
This version of Surface Dock Updater adds support for the following:
Update for Surface Dock DisplayPort Firmware
Resolves an issue with audio over passive display port adapters
Version 2.1.15.0
Release date: June 19, 2017
This version of Surface Dock Updater adds support for the following:
Surface Laptop
Surface Pro
Version 2.1.6.0
Release date: April 7, 2017
This version of Surface Dock Updater adds support for the following:
Update for Surface Dock DisplayPort firmware
Requires Windows 10
Version 2.0.22.0
Release date: October 21, 2016
This version of Surface Dock Updater adds support for the following:
Update for Surface Dock USB firmware
Improved reliability of Ethernet, audio, and USB ports
Version 1.0.8.0
Release date: April 26, 2016
This version of Surface Dock Updater adds support for the following:
Update for Surface Dock Main Chipset firmware
Update for Surface Dock DisplayPort firmware
 Wake On LAN for Surface devices
5/10/2018 • 3 minutes to read • Edit Online

Surface devices that run Windows 10, version 1607 (also known as Windows 10 Anniversary Update) or later and
use a Surface Ethernet adapter to connect to a wired network, are capable of Wake On LAN (WOL ) from
Connected Standby. With WOL, you can remotely wake up devices to perform management or maintenance tasks
or enable management solutions (such as System Center Configuration Manager) automatically. For example, you
can deploy applications to Surface devices left docked with a Surface Dock or Surface Pro 3 Docking Station by
using System Center Configuration Manager during a window in the middle of the night, when the office is empty.

NOTE
Surface devices must be connected to AC power and in Connected Standby (Sleep) to support WOL. WOL is not possible
from devices that are in hibernation or powered off.

Supported devices
The following devices are supported for WOL:
Surface Book 2
Surface Pro with LTE Advanced (Model 1807)
Surface Pro (Model 1796)
Surface Laptop
Surface Book
Surface Pro 4
Surface 3
Surface Pro 3
Surface Ethernet adapter
Surface Dock
Surface Docking Station for Surface Pro 3

WOL driver
To enable WOL support on Surface devices, a specific driver for the Surface Ethernet adapter is required. This
driver is not included in the standard driver and firmware pack for Surface devices – you must download and
install it separately. You can download the Surface WOL driver (SurfaceWOL.msi) from the Surface Tools for IT
page in the Microsoft Download Center.
You can run this Microsoft Windows Installer (.msi) file on a Surface device to install the Surface WOL driver, or
you can distribute it to Surface devices with an application deployment solution, such as System Center
Configuration Manager. To include the Surface WOL driver during deployment, you can install the .msi file as an
application during the deployment process. You can also extract the Surface WOL driver files to include them in
the deployment process. For example, you can include them in your Microsoft Deployment Toolkit (MDT)
deployment share. You can read more about Surface deployment with MDT in Deploy Windows 10 to Surface
devices with Microsoft Deployment Toolkit.
 NOTE
During the installation of SurfaceWOL.msi, the following registry key is set to a value of 1, which allows easy identification of
systems where the WOL driver has been installed. If you chose to extract and install these drivers separately during
deployment, this registry key will not be configured and must be configured manually or with a script.
HKLM\SYSTEM\CurrentControlSet\Control\Power AllowSystemRequiredPowerRequests

To extract the contents of SurfaceWOL.msi, use the MSIExec administrative installation option (/a), as shown in
the following example, to extract the contents to the C:\WOL\ folder:
msiexec /a surfacewol.msi targetdir=C:\WOL /qn

Using Surface WOL

The Surface WOL driver conforms to the WOL standard, whereby the device is woken by a special network
communication known as a magic packet. The magic packet consists of 6 bytes of 255 (or FF in hexadecimal)
followed by 16 repetitions of the target computer’s MAC address. You can read more about the magic packet and
the WOL standard on Wikipedia.

NOTE
To send a magic packet and wake up a device by using WOL, you must know the MAC address of the target device and
Ethernet adapter. Because the magic packet does not use the IP network protocol, it is not possible to use the IP address or
DNS name of the device.

Many management solutions, such as System Center Configuration Manager, provide built-in support for WOL.
There are also many solutions, including Microsoft Store apps, PowerShell modules, third-party applications, and
third-party management solutions that allow you to send a magic packet to wake up a device. For example, you
can use the Wake On LAN PowerShell module from the TechNet Script Center.

NOTE
After a device has been woken up with a magic packet, the device will return to sleep if an application is not actively
preventing sleep on the system or if the AllowSystemRequiredPowerRequests registry key is not configured to 1, which
allows applications to prevent sleep. See the WOL driver section of this article for more information about this registry key.
 Considerations for Surface and System Center
Configuration Manager
5/10/2018 • 8 minutes to read • Edit Online

Fundamentally, management and deployment of Surface devices with System Center Configuration Manager is
the same as the management and deployment of any other PC. Like any other PC, a deployment to Surface
devices includes importing drivers, importing a Windows image, preparing a deployment task sequence, and then
deploying the task sequence to a collection. After deployment, Surface devices are like any other Windows client –
to publish apps, settings, and policies, you use the same process that you would use for any other device.
You can find more information about how to use Configuration Manager to deploy and manage devices in the
Documentation for System Center Configuration Manager.
Although the deployment and management of Surface devices is fundamentally the same as any other PC, there
are some scenarios that may require additional considerations or steps. This article provides descriptions and
guidance for these scenarios; the solutions documented in this article may apply to other devices and
manufacturers as well.

NOTE
For management of Surface devices it is recommended that you use the Current Branch of System Center Configuration
Manager.

Updating Surface device drivers and firmware

For devices that receive updates through Windows Update, drivers for Surface components – and even firmware
updates – are applied automatically as part of the Windows Update process. For devices with managed updates,
such as those updated through Windows Server Update Services (WSUS ), the option to install drivers and
firmware through Windows Update is not available. For these managed devices, the recommended driver
management process is the deployment of driver and firmware updates using the Windows Installer (.msi) files,
which are provided through the Microsoft Download Center. You can find a list of these downloads at Download
the latest firmware and drivers for Surface devices.
As .msi files, deployment of driver and firmware updates is performed in the same manner as deployment of an
application. Instead of installing an application as would normally happen when an .msi file is run, the Surface
driver and firmware .msi will apply the driver and firmware updates to the device. The single .msi file contains the
driver and firmware updates required by each component of the Surface device. The updates for firmware are
applied the next time the device reboots. You can read more about the .msi installation method for Surface drivers
and firmware in Manage Surface driver and firmware updates. For more information about how to deploy
applications with Configuration Manager, see Packages and programs in System Center Configuration Manager.

NOTE
Surface device drivers and firmware are signed with SHA-256, which is not natively supported by Windows Server 2008 R2. A
workaround is available for Configuration Manager environments running on Windows Server 2008 R2 – for more
information see Can't import drivers into System Center Configuration Manager (KB3025419) .

Surface Ethernet adapters and Configuration Manager deployment

The default mechanism that Configuration Manager uses to identify devices during deployment is the Media
Access Control (MAC ) address. Because the MAC address is associated with the Ethernet controller, an Ethernet
adapter shared among multiple devices will cause Configuration Manager to identify each of the devices as only a
single device. This can cause a Configuration Manager deployment of Windows to not be applied to intended
devices.
To ensure that Surface devices using the same Ethernet adapter are identified as unique devices during
deployment, you can instruct Configuration Manager to identify devices using another method. This other method
could be the MAC address of the wireless network adapter or the System Universal Unique Identifier (System
UUID ). You can specify that Configuration Manager use other identification methods with the following options:
Add an exclusion for the MAC addresses of Surface Ethernet adapters, which forces Configuration Manager
to overlook the MAC address in preference of the System UUID, as documented in the Reusing the same
NIC for multiple PXE initiated deployments in System Center Configuration Manager OSD blog post.
Prestage devices by System UUID as documented in the Reusing the same NIC for multiple PXE initiated
deployments in System Center Configuration Manager OSD blog post.
Use a script to identify a newly deployed Surface device by the MAC address of its wireless adapter, as
documented in the How to Use The Same External Ethernet Adapter For Multiple SCCM OSD blog post.
Another consideration for the Surface Ethernet adapter during deployments with Configuration Manager is the
driver for the Ethernet controller. Beginning in Windows 10, version 1511, the driver for the Surface Ethernet
adapter is included by default in Windows. For organizations that want to deploy the latest version of Windows 10
and use the latest version of WinPE, use of the Surface Ethernet adapter requires no additional actions.
For versions of Windows prior to Windows 10, version 1511 (including Windows 10 RTM and Windows 8.1), you
may still need to install the Surface Ethernet adapter driver and include the driver in your WinPE boot media. With
its inclusion in Windows 10, the driver is no longer available for download from the Microsoft Download Center.
To download the Surface Ethernet adapter driver, download it from the Microsoft Update Catalog as documented
in the Surface Ethernet Drivers blog post from the Ask The Core Team blog.

Deploy Surface app with Configuration Manager

With the release of Microsoft Store for Business, Surface app is no longer available as a driver and firmware
download. Organizations that want to deploy Surface app to managed Surface devices or during deployment with
the use of Configuration Manager, must acquire Surface app through Microsoft Store for Business and then
deploy Surface app with PowerShell. You can find the PowerShell commands for deployment of Surface app,
instructions to download Surface app, and prerequisite frameworks from Microsoft Store for Business in the
Deploy Surface app with Microsoft Store for Business article in the TechNet Library.

Use prestaged media with Surface clients

If your organization uses prestaged media to pre-load deployment resources on to machines prior to deployment
with Configuration Manager, the nature of Surface devices as UEFI devices may require you to take additional
steps. Specifically, a native UEFI environment requires that you create multiple partitions on the boot disk of the
system. If you are following along with the documentation for prestaged media, the instructions provide for only
single partition boot disks and therefore will fail when applied to Surface devices.
Instructions for applying prestaged media to UEFI devices, such as Surface devices, can be found in the How to
apply Task Sequence Prestaged Media on multi-partitioned disks for BIOS or UEFI PCs in System Center
Configuration Manager blog post.

Licensing conflicts with OEM Activation 3.0

Surface devices come preinstalled with a licensed copy of Windows. For example, Surface Pro 4 is preinstalled
with Windows 10 Professional. The license key for this preinstalled copy of Windows is embedded in the firmware
of the device with OEM Activation 3.0 (OA 3.0). When you run Windows installation media on a device with an OA
3.0 key, Windows setup automatically reads the license key and uses it to install and activate Windows. In most
situations, this simplifies the reinstallation of Windows, because the user does not have to find or enter a license
key.
When you reimage a device by using Windows Enterprise, this embedded license key does not cause a conflict.
This is because the installation media for Windows Enterprise is configured to install only an Enterprise edition of
Windows and therefore is incompatible with the license key embedded in the system firmware. If a product key is
not specified (such as when you intend to activate with Key Management Services (KMS ) or Active Directory
Based Activation), a Generic Volume License Key (GVLK) is used until Windows is activated by one of those
technologies.
However, issues may arise when organizations intend to use versions of Windows that are compatible with the
firmware embedded key. For example, an organization that wants to install Windows 10 Professional on a Surface
3 device that originally shipped with Windows 10 Home edition may encounter difficulty when Windows setup
automatically reads the Home edition key during installation and installs as Home edition rather than Professional.
To avoid this conflict, you can use the Ei.cfg or Pid.txt file (see Windows Setup Edition Configuration and Product
ID Files) to explicitly instruct Windows setup to prompt for a product key, or you can enter a specific product key in
the deployment task sequence. If you do not have a specific key, you can use the default product keys for Windows,
which you can find in Customize and deploy a Windows 10 operating system on the Device Partner Center.

Apply an asset tag during deployment

Surface Studio, Surface Book, Surface Pro 4, Surface Pro 3, and Surface 3 devices all support the application of an
asset tag in UEFI. This asset tag can be used to identify the device from UEFI even if the operating system fails, and
it can also be queried from within the operating system. To read more about the Surface Asset Tag function, see
the Asset Tag Tool for Surface Pro 3 blog post.
To apply an asset tag using the Surface Asset Tag CLI Utility during a Configuration Manager deployment task
sequence, use the script and instructions found in the Set Surface Asset Tag During a Configuration Manager Task
Sequence blog post.

Configure push-button reset

When you deploy Windows to a Surface device, the push-button reset functionality of Windows is configured by
default to revert the system back to a state where the environment is not yet configured. When the reset function
is used, the system discards any installed applications and settings. Although in some situations it can be beneficial
to restore the system to a state without applications and settings, in a professional environment this effectively
renders the system unusable to the end user.
Push-button reset can be configured, however, to restore the system configuration to a state where it is ready for
use by the end user. Follow the process outlined in Deploy push-button reset features to customize the push-
button reset experience for your devices.
 Deploy Surface app with Microsoft Store for Business
and Education
5/10/2018 • 7 minutes to read • Edit Online

Applies to
Surface Pro 4
Surface Book
Surface 3

NOTE
The Surface app ships in Surface Studio.

The Surface app is a lightweight Microsoft Store app that provides control of many Surface-specific settings and
options, including:
Enable or disable the Windows button on the Surface device
Adjust the sensitivity of a Surface Pen
Customize Surface Pen button actions
Enable or disable Surface audio enhancements
Quick access to support documentation and information for your device
If your organization is preparing images that will be deployed to your Surface devices, you may want to include the
Surface app (formerly called the Surface Hub) in your imaging and deployment process instead of requiring users
of each individual device to download and install the app from the Microsoft Store or your Microsoft Store for
Business.

Surface app overview

The Surface app is available as a free download from the Microsoft Store. Users can download and install it from
the Microsoft Store, but if your organization uses Microsoft Store for Business instead, you will need to add it to
your store’s inventory and possibly include the app as part of your Windows deployment process. These processes
are discussed throughout this article. For more information about Microsoft Store for Business, see Microsoft
Store for Business in the Windows TechCenter.

Add Surface app to a Microsoft Store for Business account

Before users can install or deploy an app from a company’s Microsoft Store for Business account, the desired
app(s) must first be made available and licensed to the users of a business.
1. If you have not already done so, create a Microsoft Store for Business account.
2. Log on to the portal.
3. Enable offline licensing: click Manage->Store settings, and then select the Show offline licensed apps
to people shopping in the store checkbox, as shown in Figure 1. For more information about Microsoft
Store for Business app licensing models, see Apps in Microsoft Store for Business and Education.
 Figure 1. Enable apps for offline use
4. Add Surface app to your Microsoft Store for Business account by following this procedure:
Click the Shop menu.
In the search box, type Surface app, and then click the search icon.
After the Surface app is presented in the search results, click the app’s icon.
You are presented with a choice (select Online or Offline), as shown in Figure 2.

Figure 2. Select the Offline licensing mode and add the app to your inventory
Click Offline to select the Offline licensing mode.
Click Get the app to add the app to your Microsoft Store for Business inventory. As shown in Figure 3,
you’ll see a dialog box that prompts you to acknowledge that offline apps can be deployed using a
management tool or downloaded from the company’s inventory page in their private store.
 Figure 3. Offline-licensed app acknowledgement
Click OK.

Download Surface app from a Microsoft Store for Business account

After you add an app to the Microsoft Store for Business account in Offline mode, you can download and add the
app as an AppxBundle to a deployment share.
1. Log on to the Microsoft Store for Business account at https://businessstore.microsoft.com.
2. Click Manage->Apps & software. A list of all of your company’s apps is displayed, including the Surface app
you added in the Add Surface app to a Microsoft Store for Business account section of this article.
3. Under Actions, click the ellipsis (… ), and then click Download for offline use for the Surface app.
4. Select the desired Platform and Architecture options from the available selections for the selected app, as
shown in Figure 4.

Figure 4. Download the AppxBundle package for an app

5. Click Download. The AppxBundle package will be downloaded. Make sure you note the path of the
downloaded file because you’ll need that later in this article.
6. Click either the Encoded license or Unencoded license option. Use the Encoded license option with
management tools like System Center Configuration Manager or when you use Windows Configuration
Designer to create a provisioning package. Select the Unencoded license option when you use Deployment
Image Servicing and Management (DISM ) or deployment solutions based on imaging, including the Microsoft
Deployment Toolkit (MDT).
7. Click Generate to generate and download the license for the app. Make sure you note the path of the license
file because you’ll need that later in this article.
 NOTE
When you download an app for offline use, such as the Surface app, you may notice a section at the bottom of the page
labeled Required frameworks. Your target computers must have the frameworks installed for the app to run, so you may
need to repeat the download process for each of the required frameworks for your architecture (either x86 or x64) and also
include them as part of your Windows deployment discussed later in this article.

Figure 5 shows the required frameworks for the Surface app.

Figure 5. Required frameworks for the Surface app

NOTE
The version numbers of the Surface app and required frameworks will change as the apps are updated. Check for the latest
version of Surface app and each framework in Microsoft Store for Business. Always use the Surface app and recommended
framework versions as provided by Microsoft Store for Business. Using outdated frameworks or the incorrect versions may
result in errors or application crashes.

To download the required frameworks for the Surface app, follow these steps:
1. Click the Download button under Microsoft.VCLibs.140.00_14.0.23816.0_x64__8wekyb3d8bbwe. This
downloads the Microsoft.VCLibs.140.00_14.0.23816.0_x64__8wekyb3d8bbwe.Appx file to your specified folder.
2. Click the Download button under
Microsoft.NET.Native.Runtime.1.1_1.1.23406.0_x64__8wekyb3d8bbwe. This downloads the
Microsoft.NET.Native.Runtime.1.1_1.1.23406.0_x64__8wekyb3d8bbwe.Appx file to your specified folder.

NOTE
Only the 64-bit (x64) version of each framework is required for Surface devices. Surface devices are native 64-bit UEFI devices
and are not compatible with 32-bit (x86) versions of Windows that would require 32-bit frameworks.

Install Surface app on your computer with PowerShell

The following procedure provisions the Surface app onto your computer and makes it available for any user
accounts created on the computer afterwards.
1. Using the procedure described in the How to download Surface app from a Microsoft Store for Business
account section of this article, download the Surface app AppxBundle and license file.
2. Begin an elevated PowerShell session.
 NOTE
If you don’t run PowerShell as an Administrator, the session won’t have the required permissions to install the app.

3. In the elevated PowerShell session, copy and paste the following command:

Add-AppxProvisionedPackage –Online –PackagePath <DownloadPath>\

Microsoft.SurfaceHub_10.0.342.0_neutral_~_8wekyb3d8bbwe.AppxBundle –LicensePath <DownloadPath>\
Microsoft.SurfaceHub_8wekyb3d8bbwe_a53ef8ab-9dbd-dec1-46c5-7b664d4dd003.xml

Where <DownloadPath> is the folder where you downloaded the AppxBundle and license file from the
Microsoft Store for Business account.
For example, if you downloaded the files to c:\Temp, the command you run is:

Add-AppxProvisionedPackage –Online –PackagePath c:\Temp\

Microsoft.SurfaceHub_10.0.342.0_neutral_~_8wekyb3d8bbwe.AppxBundle –LicensePath c:\Temp\
Microsoft.SurfaceHub_8wekyb3d8bbwe_a53ef8ab-9dbd-dec1-46c5-7b664d4dd003.xml
```

4. The Surface app will now be available on your current Windows computer.
Before the Surface app is functional on the computer where it has been provisioned, you must also provision the
frameworks described earlier in this article. To provision these frameworks, use the following procedure in the
elevated PowerShell session you used to provision the Surface app.
1. In the elevated PowerShell session, copy and paste the following command:
Add-AppxProvisionedPackage –Online –SkipLicense –PackagePath
<DownloadPath>\Microsoft.VCLibs.140.00_14.0.23816.0_x64__8wekyb3d8bbwe.Appx
2. In the elevated PowerShell session, copy and paste the following command:
Add-AppxProvisionedPackage –Online –SkipLicense –PackagePath
<DownloadPath>\Microsoft.NET.Native.Runtime.1.1_1.1.23406.0_x64__8wekyb3d8bbwe.Appx

Install Surface app with MDT

The following procedure uses MDT to automate installation of the Surface app at the time of deployment. The
application is provisioned automatically by MDT during deployment and thus you can use this process with
existing images. This is the recommended process to deploy the Surface app as part of a Windows deployment to
Surface devices because it does not reduce the cross platform compatibility of the Windows image.
1. Using the procedure described earlier in this article, download the Surface app AppxBundle and license file.
2. Using the New Application Wizard in the MDT Deployment Workbench, import the downloaded files as a new
Application with source files.
3. On the Command Details page of the New Application Wizard, specify the default Working Directory
and for the Command specify the file name of the AppxBundle, as follows:
Command: Microsoft.SurfaceHub_10.0.342.0_neutral_~_8wekyb3d8bbwe.AppxBundle
Working Directory: %DEPLOYROOT%\Applications\SurfaceApp
For the Surface app to function on the target computer, it will also require the frameworks described earlier in this
article. Use the following procedure to import the frameworks required for the Surface app into MDT and to
configure them as dependencies.
1. Using the procedure described earlier in this article, download the framework files. Store each framework in a
separate folder.
2. Using the New Application Wizard in the MDT Deployment Workbench, import the downloaded files as a new
Application with source files.
3. On the Command Details page, type the file name of each application you downloaded in the Command
field and the default Working Directory.
To configure the frameworks as dependencies of the Surface app, use this process:
1. Open the properties of the Surface app in the MDT Deployment Workbench.
2. Click the Dependencies tab, and then click Add.
3. Select the check box for each framework using the name you provided in the New Application Wizard.
After import, the Surface app will be available for selection in the Applications step of the Windows Deployment
Wizard. You can also install the application automatically by specifying the application in the deployment task
sequence by following this process:
1. Open your deployment task sequence in the MDT Deployment Workbench.
2. Add a new Install Application task in the State Restore section of deployment.
3. Select Install a single application and specify the Surface App as the Application to be installed.
For more information about including apps into your Windows deployments, see Deploy Windows 10 with the
Microsoft Deployment Toolkit.
 Enable PEAP, EAP-FAST, and Cisco LEAP on Surface
devices
6/27/2018 • 3 minutes to read • Edit Online

Find out how to enable support for PEAP, EAP -FAST, or Cisco LEAP protocols on your Surface device.
If you use PEAP, EAP -FAST, or Cisco LEAP in your enterprise network, you probably already know that these
three wireless authentication protocols are not supported by Surface devices out of the box. Some users may
discover this when they attempt to connect to your wireless network; others may discover it when they are unable
to gain access to resources inside the network, like file shares and internal sites. For more information, see
Extensible Authentication Protocol.
You can add support for each protocol by executing a small MSI package from a USB stick or from a file share. For
organizations that want to enable EAP support on their Surface devices, the MSI package format supports
deployment with many management and deployment tools, like the Microsoft Deployment Toolkit (MDT) and
System Center Configuration Manager.

Download PEAP, EAP-FAST, or Cisco LEAP installation files

You can download the MSI installation files for PEAP, EAP -FAST, or Cisco LEAP in a single zip archive file from
the Microsoft Download Center. To download this file, go to the Surface Tools for IT page on the Microsoft
Download Center, click Download, and then select the Cisco EAP -Supplicant Installer.zip file.

Deploy PEAP, EAP-FAST, or Cisco LEAP with MDT

If you are already performing a Windows deployment to Surface devices in your organization, it is quick and easy
to add the installation files for each protocol to your deployment share and configure automatic installation during
deployment. You can even configure a task sequence that updates previously deployed Surface devices to provide
support for these protocols using the same process.
To enable support for PEAP, EAP -FAST, or Cisco LEAP on newly deployed Surface devices, follow these steps:
1. Download and extract the installation files for each protocol to separate folders in an easily accessible
location.
2. Open the MDT Deployment Workbench and expand your deployment share to the Applications folder.
3. Select New Application from the Action pane.
4. Choose Application with source files to copy the MSI files into the Deployment Share.
5. Select the folder you created in step 1 for the desired protocol.
6. Name the folder in the deployment share where the installation files will be stored.
7. Specify the command line to deploy the application:
For PEAP use EAP -PEAP.msi /qn /norestart.
For LEAP use EAP -LEAP.msi /qn /norestart.
For EAP -FAST use EAP -FAST.msi /qn /norestart.
8. Use the default options to complete the New Application Wizard.
9. Repeat steps 3 through 8 for each desired protocol.
After you’ve performed these steps to import the three MSI packages as applications into MDT, they will be
available for selection in the Applications page of the Windows Deployment Wizard. Although in some simple
deployment scenarios it might be sufficient to have technicians select each package at the time of deployment, it is
not recommended. This practice introduces the possibility that a technician could attempt to apply these packages
to computers other than Surface devices, or that a Surface device could be deployed without EAP support due to
human error.
To hide these applications from the Install Applications page, select the Hide this application in the
Deployment Wizard checkbox in the properties of each application. After the applications are hidden, they will
not be displayed as optional applications during deployment. To deploy them in your Surface deployment task
sequence, they must be explicitly defined for installation through a separate step in the task sequence.
To specify the protocol(s) explicitly, follow these steps:
1. Open your Surface deployment task sequence properties from the MDT Deployment Workbench.
2. On the Task Sequence tab, select the Install Applications step under State Restore. This is typically
found between the pre-application and post-application Windows Update steps.
3. Use the Add button to create a new Install Application step from the General category.
4. Select Install a single application in the step Properties tab.
5. Select the desired EAP protocol from the list.
6. Repeat steps 2 through 5 for each desired protocol.

Deploy PEAP, EAP-FAST, or Cisco LEAP with Configuration Manager

For organizations that manage Surface devices with Configuration Manager, it is even easier to deploy PEAP,
EAP -FAST, or Cisco LEAP support to Surface devices. Simply import each MSI file as an application from the
Software Library and configure a deployment to your Surface device collection.
For more information on how to deploy applications with Configuration Manager see How to Create Applications
in Configuration Manager and How to Deploy Applications in Configuration Manager.
 Manage Surface UEFI settings
6/27/2018 • 5 minutes to read • Edit Online

Current and future generations of Surface devices, including Surface Pro 4, Surface Book, and Surface Studio, use
a unique UEFI firmware engineered by Microsoft specifically for these devices. This firmware allows for
significantly greater control of the device’s operation over firmware versions in earlier generation Surface devices,
including the support for touch, mouse, and keyboard operation. By using the Surface UEFI settings you can easily
enable or disable internal devices or components, configure security to protect UEFI settings from being changed,
and adjust the Surface device boot settings.

NOTE
Surface Pro 3, Surface 3, Surface Pro 2, Surface 2, Surface Pro, and Surface do not use the Surface UEFI and instead use
firmware provided by third-party manufacturers, such as AMI.

You can enter the Surface UEFI settings on your Surface device 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.

PC information
On the PC information page, detailed information about your Surface device is provided:
Model – Your Surface device’s model will be displayed here, such as Surface Book or Surface Pro 4. The exact
configuration of your device is not shown, (such as processor, disk size, or memory size).
UUID – This Universally Unique Identification number is specific to your device and is used to identify the
device during deployment or management.
Serial Number – This number is used to identify this specific Surface device for asset tagging and support
scenarios.
Asset Tag – The asset tag is assigned to the Surface device with the Asset Tag Tool.
You will also find detailed information about the firmware of your Surface device. Surface devices have several
internal components that each run different versions of firmware. The firmware version of each of the following
devices is displayed on the PC information page (as shown in Figure 1):
System UEFI
SAM Controller
Intel Management Engine
System Embedded Controller
Touch Firmware
Figure 1. System information and firmware version information
You can find up-to-date information about the latest firmware version for your Surface device in the Surface
Update History for your device.

Security
On the Security page of Surface UEFI settings, you can set a password to protect UEFI settings. This password
must be entered when you boot the Surface device to UEFI. The password can contain the following characters (as
shown in Figure 2):
Uppercase letters: A-Z
Lowercase letters: a-z
Numbers: 1-0
Special characters: !@#$%^&*()?<>{}[]-_=+|.,;:’`”
The password must be at least 6 characters and is case sensitive.
Figure 2. Add a password to protect Surface UEFI settings
On the Security page you can also change the configuration of Secure Boot on your Surface device. Secure Boot
technology prevents unauthorized boot code from booting on your Surface device, which protects against bootkit
and rootkit-type malware infections. You can disable Secure Boot to allow your Surface device to boot third-party
operating systems or bootable media. You can also configure Secure Boot to work with third-party certificates, as
shown in Figure 3. Read more about Secure Boot in the TechNet Library.

Figure 3. Configure Secure Boot

You can also enable or disable the Trusted Platform Module (TPM ) device on the Security page, as shown in
Figure 4. The TPM is used to authenticate encryption for your device’s data with BitLocker. Read more about
BitLocker in the TechNet Library.
Figure 4. Configure Surface UEFI security settings

Devices
On the Devices page you can enable or disable specific devices and components of your Surface device. Devices
that you can enable or disable on this page include:
Docking and USB Ports
MicroSD or SD Card Slot
Rear Camera
Front Camera
Infrared (IR ) Camera
Wi-Fi and Bluetooth
Onboard Audio (Speakers and Microphone)
Each device is listed with a slider button that you can move to On (enabled) or Off (disabled) position, as shown in
Figure 5.
Figure 5. Enable and disable specific devices

Boot configuration
On the Boot Configuration page, you can change the order of your boot devices and/or enable or disable boot of
the following devices:
Windows Boot Manager
USB Storage
PXE Network
Internal Storage
You can boot from a specific device immediately, or you can swipe left on that device’s entry in the list using the
touchscreen. You can also boot immediately to a USB device or USB Ethernet adapter when the Surface device is
powered off by pressing the Volume Down button and the Power button simultaneously.
For the specified boot order to take effect, you must set the Enable Alternate Boot Sequence option to On, as
shown in Figure 6.
Figure 6. Configure the boot order for your Surface device
You can also turn on and off IPv6 support for PXE with the Enable IPv6 for PXE Network Boot option, for
example when performing a Windows deployment using PXE where the PXE server is configured for IPv4 only.

About
The About page displays regulatory information, such as compliance with FCC rules, as shown in Figure 7.

Figure 7. Regulatory information displayed on the About page

Exit
Use the Restart Now button on the Exit page to exit UEFI settings, as shown in Figure 8.
Figure 8. Click Restart Now to exit Surface UEFI and restart the device

Surface UEFI boot screens

When you update Surface device firmware, by using either Windows Update or manual installation, the updates
are not applied immediately to the device, but instead during the next reboot cycle. You can find out more about
the Surface firmware update process in Manage Surface driver and firmware updates. The progress of the
firmware update is displayed on a screen with progress bars of differing colors to indicate the firmware for each
component. Each component’s progress bar is shown in Figures 9 through 13.

Figure 9. The Surface UEFI firmware update displays a blue progress bar
Figure 10. The System Embedded Controller firmware update displays a green progress bar

Figure 11. The SAM Controller firmware update displays an orange progress bar
Figure 12. The Intel Management Engine firmware update displays a red progress bar

Figure 13. The Surface touch firmware update displays a gray progress bar

NOTE
An additional warning message that indicates Secure Boot is disabled is displayed, as shown in Figure 14.
Figure 14. Surface boot screen that indicates Secure Boot has been disabled in Surface UEFI settings

Related topics
Advanced UEFI security features for Surface Pro 3
 Advanced UEFI security features for Surface Pro 3
10/29/2018 • 4 minutes to read • Edit Online

This article describes how to install and configure the v3.11.760.0 UEFI update to enable additional security
options for Surface Pro 3 devices.
To address more granular control over the security of Surface devices, the v3.11.760.0 UEFI update provides
additional security options that allow you to disable specific hardware devices or to prevent starting from those
devices. After the UEFI update is installed on a device, you can configure it manually or automatically by running a
script.

Manually install the UEFI update

Before you can configure the advanced security features of your Surface device, you must first install the
v3.11.760.0 UEFI update. This update is installed automatically if you receive your updates from Windows Update.
For more information about how to configure Windows to update automatically by using Windows Update, see
How to configure and use Automatic Updates in Windows.
To update the UEFI on Surface Pro 3, you can download and install the Surface UEFI updates as part of the
Surface Pro 3 Firmware and Driver Pack. These firmware and driver packs are available from the Surface Pro 3
page on the Microsoft Download Center. You can find out more about the firmware and driver packs at Download
the latest firmware and drivers for Surface devices. The firmware and driver packs are available as both self-
contained Windows Installer (.msi) and archive (.zip) formats. You can find out more about these two formats and
how you can use them to update your drivers at Manage Surface driver and firmware updates.

Manually configure additional security settings

NOTE
To enter firmware setup on a Surface device, begin with the device powered off, press and hold the Volume Up button, then
press and release the Power button, then release the Volume Up button after the device has begun to boot.

After the v3.11.760.0 UEFI update is installed on a Surface device, an additional UEFI menu named Advanced
Device Security becomes available. If you click this menu, the following options are displayed:

AVAILABLE SETTINGS (DEFAULT LISTED IN

OPTION DESCRIPTION BOLD)

Network Boot Enables or disables the ability of your Enabled, Not Bootable
Surface device to boot from the
network (also known as PXE boot).

Side USB Enables or disables the USB port on the Enabled, Not Bootable, Disabled
side of the Surface device. Additionally,
the USB port can be enabled, but not
allow booting.
 AVAILABLE SETTINGS (DEFAULT LISTED IN
OPTION DESCRIPTION BOLD)

Docking Port Enables or disables the ports on the Enabled, Not Bootable, Disabled
Surface docking station. Additionally,
the docking port can be enabled, but
block booting from any USB or Ethernet
port in the docking station.

Front Camera Enables or disables the camera on the Enabled, Disabled

front of the Surface device.

Rear Camera Enables or disables the camera on the Enabled, Disabled

rear of the Surface device.

On Board Audio Enables or disables audio on the Surface Enabled, Disabled

device.

microSD Enables or disables the microSD slot on Enabled, Disabled

the Surface device.

WiFi Enables or disables the built-in Wi-Fi Enabled, Disabled

transceiver in the Surface device. This
also disables Bluetooth.

Bluetooth Enables or disables the built-in Enabled, Disabled

Bluetooth transceiver in the Surface
device.

Automate additional security settings

As an IT professional with administrative privileges, you can automate the configuration of UEFI settings by
leveraging Surface Pro 3 Firmware Tools (476 KB ) available from the Microsoft Download Center. These tools
install a .NET assembly that can be called from any custom application or script.
Prerequisites
The sample scripts below leverage the previously mentioned extension and therefore assume that the tool has
been installed on the device being managed.
The scripts must be run with administrative privilege.
The Windows PowerShell command Set-ExecutionPolicy Unrestricted must be called prior to running
sample scripts if they are not digitally signed.
Sample scripts

Note: The UEFI password used in the sample scripts below is presented in clear text. We strongly recommend
saving the scripts in a protected location and running them in a controlled environment.

Show all configurable options:

 # Load the extension
[System.Reflection.Assembly]::Load("SurfaceUefiManager, Version=1.0.5483.22783, Culture=neutral,
PublicKeyToken=20606f4b5276c705")

# Get the collection of all configurable settings

$uefiOptions = [Microsoft.Surface.FirmwareOption]::All()

foreach ($uefiOption in $uefiOptions)

{
Write-Host "Name:" $uefiOption.Name
Write-Host " Description =" $uefiOption.Description
Write-Host " Current Value =" $uefiOption.CurrentValue
Write-Host " Default Value =" $uefiOption.DefaultValue
Write-Host " Proposed Value =" $uefiOption.ProposedValue

# This gives usage and validation information

Write-Host " Allowed Values =" $uefiOption.FriendlyRegEx
Write-Host " Regular Expression =" $uefiOption.RegEx

Write-Host
}

Set or change UEFI password:

# Load the extension

[System.Reflection.Assembly]::Load("SurfaceUefiManager, Version=1.0.5483.22783, Culture=neutral,
PublicKeyToken=20606f4b5276c705")

# Must supply UEFI administrator Password if set

# If it is not currently set this is ignored
[Microsoft.Surface.FirmwareOption]::Unlock("1234")

$Password = [Microsoft.Surface.FirmwareOption]::Find("Password")

# Set New value to 12345

$Password.ProposedValue = "12345"

Check status of proposed changes:

# Load the extension

[System.Reflection.Assembly]::Load("SurfaceUefiManager, Version=1.0.5483.22783, Culture=neutral,
PublicKeyToken=20606f4b5276c705")

# Check update status

$updateStatus = [Microsoft.Surface.FirmwareOption]::UpdateStatus
$updateIteration = [Microsoft.Surface.FirmwareOption]::UpdateIteration
Write-Host "Last Update Status =" $updateStatus
Write-Host "Last Update Iteration =" $updateIteration

# Get the individual results for the last proposed update

# If the device has never had an update attempt this will be an empty list
$details = [Microsoft.Surface.FirmwareOption]::UpdateStatusDetails
Write-Host $details.Count "Settings were proposed"
if ($details.Count -gt 0)
{
Write-Host "Result Details"
foreach ($detail in $details.GetEnumerator())
{
Write-Host " " $detail.Key "=" $detail.Value
}
}

Revert UEFI to default values:

 # Load the extension
[System.Reflection.Assembly]::Load("SurfaceUefiManager, Version=1.0.5483.22783, Culture=neutral,
PublicKeyToken=20606f4b5276c705")

# Must supply UEFI administrator Password if set

# If it is not currently set this is ignored
[Microsoft.Surface.FirmwareOption]::Unlock("1234")

# Get the collection of all configurable settings

$uefiOptions = [Microsoft.Surface.FirmwareOption]::All()

# Reset all options to the factory default

foreach ($uefiOption in $uefiOptions)
{
$uefiOption.ProposedValue = $uefiOption.DefaultValue
}

Status code interpretation

00 - The proposed update was a success
02 - One of the proposed values had an invalid value
03 - There was a proposed value set that was not recognized
0F - The unlock password did not match currently set password
 Microsoft Surface Enterprise Management Mode
10/29/2018 • 9 minutes to read • Edit Online

Microsoft Surface Enterprise Management Mode (SEMM ) is a feature of Surface devices with Surface UEFI that
allows you to secure and manage firmware settings within your organization. With SEMM, IT professionals can
prepare configurations of UEFI settings and install them on a Surface device. In addition to the ability to configure
UEFI settings, SEMM also uses a certificate to protect the configuration from unauthorized tampering or removal.

NOTE
SEMM is only available on devices with Surface UEFI firmware, such as Surface Pro 4, Surface Book, and Surface Studio. For
more information about Surface UEFI, see Manage Surface UEFI Settings.

When Surface devices are configured by SEMM and secured with the SEMM certificate, they are considered
enrolled in SEMM. When the SEMM certificate is removed and control of UEFI settings is returned to the user of
the device, the Surface device is considered unenrolled in SEMM.
There are two administrative options you can use to manage SEMM and enrolled Surface devices – a standalone
tool or integration with System Center Configuration Manager. The SEMM standalone tool, called the Microsoft
Surface UEFI Configurator, is described in this article. For more information about how to manage SEMM with
System Center Configuration Manager, see Use System Center Configuration Manager to manage devices with
SEMM.

Microsoft Surface UEFI Configurator

The primary workspace of SEMM is Microsoft Surface UEFI Configurator, as shown in Figure 1. Microsoft Surface
UEFI Configurator is a tool that is used to create Windows Installer (.msi) packages that are used to enroll,
configure, and unenroll SEMM on a Surface device. These packages contain a configuration file where the settings
for UEFI are specified. SEMM packages also contain a certificate that is installed and stored in firmware and used
to verify the signature of configuration files before UEFI settings are applied.
Figure 1. Microsoft Surface UEFI Configurator

NOTE
Windows 10 is required to run Microsoft Surface UEFI Configurator

You can use the Microsoft Surface UEFI Configurator tool in three modes:
Surface UEFI Configuration Package. Use this mode to create a Surface UEFI configuration package to enroll a
Surface device in SEMM and to configure UEFI settings on enrolled devices.
Surface UEFI Reset Package. Use this mode to unenroll a Surface device from SEMM.
Surface UEFI Recovery Request. Use this mode to respond to a recovery request to unenroll a Surface device
from SEMM where a Reset Package operation is not successful.
Download Microsoft Surface UEFI Configurator
You can download Microsoft Surface UEFI Configurator from the Surface Tools for IT page in the Microsoft
Download Center.
Configuration package
Surface UEFI configuration packages are the primary mechanism to implement and manage SEMM on Surface
devices. These packages contain a configuration file of UEFI settings specified during creation of the package in
Microsoft Surface UEFI Configurator and a certificate file, as shown in Figure 2. When a configuration package is
run for the first time on a Surface device that is not already enrolled in SEMM, it provisions the certificate file in
the device’s firmware and enrolls the device in SEMM. When enrolling a device in SEMM, you will be prompted to
confirm the operation by providing the last two digits of the SEMM certificate thumbprint before the certificate file
is stored and the enrollment can complete. This confirmation requires that a user be present at the device at the
time of enrollment to perform the confirmation.

Figure 2. Secure a SEMM configuration package with a certificate

See the Surface Enterprise Management Mode certificate requirements section of this article for more information
about the requirements for the SEMM certificate.

NOTE
You can also specify a UEFI password with SEMM that is required to view the Security, Devices, Boot Configuration, or
Enterprise Management pages of Surface UEFI.

After a device is enrolled in SEMM, the configuration file is read and the settings specified in the file are applied to
UEFI. When you run a configuration package on a device that is already enrolled in SEMM, the signature of the
configuration file is checked against the certificate that is stored in the device firmware. If the signature does not
match, no changes are applied to the device.
You can use Surface UEFI settings to enable or disable the operation of individual components, such as cameras,
wireless communication, or docking USB port (as shown in Figure 3), and configure advanced settings (as shown
in Figure 4).
Figure 3. Enable or disable devices in Surface UEFI with SEMM
Figure 4. Configure advanced settings with SEMM
You can enable or disable the following devices with SEMM:
Docking USB Port
On-board Audio
Type Cover
Micro SD or SD Card Slots
Front Camera
Rear Camera
Infrared Camera, for Windows Hello
Bluetooth Only
Wi-Fi and Bluetooth
Trusted Platform Module (TPM )
You can configure the following advanced settings with SEMM:
IPv6 support for PXE boot
Alternate boot order, where the Volume Down button and Power button can be pressed together during boot,
to boot directly to a USB or Ethernet device
Lock the boot order to prevent changes
Support for booting to USB devices
Display of the Surface UEFI Security page
Display of the Surface UEFI Devices page
Display of the Surface UEFI Boot page
 NOTE
When you create a SEMM configuration package, two characters are shown on the Successful page, as shown in Figure 5.

Figure 5. Display of the last two characters of the certificate thumbprint on the Successful page
These characters are the last two characters of the certificate thumbprint and should be written down or recorded.
The characters are required to confirm enrollment in SEMM on a Surface device, as shown in Figure 6.
Figure 6. Enrollment confirmation in SEMM with the SEMM certificate thumbprint

NOTE
Administrators with access to the certificate file (.pfx) can read the thumbprint at any time by opening the .pfx file in CertMgr.
To view the thumbprint with CertMgr, follow this process:
1. Right-click the .pfx file, and then click Open.
2. Expand the folder in the navigation pane.
3. Click Certificates.
4. Right-click your certificate in the main pane, and then click Open.
5. Click the Details tab.
6. All or Properties Only must be selected in the Show drop-down menu.
7. Select the field Thumbprint.

To enroll a Surface device in SEMM or to apply the UEFI configuration from a configuration package, all you need
to do is run the .msi file on the intended Surface device. You can use application deployment or operating system
deployment technologies such as System Center Configuration Manager or the Microsoft Deployment Toolkit.
When you enroll a device in SEMM you must be present to confirm the enrollment on the device. User interaction
is not required when you apply a configuration to devices that are already enrolled in SEMM.
For a step-by-step walkthrough of how to enroll a Surface device in SEMM or apply a Surface UEFI configuration
with SEMM, see Enroll and configure Surface devices with SEMM.
Reset package
A Surface UEFI reset package is used to perform only one task — to unenroll a Surface device from SEMM. The
reset package contains signed instructions to remove the SEMM certificate from the device’s firmware and to reset
UEFI settings to factory default. Like a Surface UEFI configuration package, a reset package must be signed with
the same SEMM certificate that is provisioned on the Surface device. When you create a SEMM reset package,
you are required to supply the serial number of the Surface device you intend to reset. SEMM reset packages are
not universal and are specific to one device.
Recovery request
In some scenarios, it may be impossible to use a Surface UEFI reset package. (For example, if Windows becomes
unusable on the Surface device.) In these scenarios you can unenroll the Surface device from SEMM through the
Enterprise Management page of Surface UEFI (shown in Figure 7) with a Recovery Request operation.

Figure 7. Initiate a SEMM recovery request on the Enterprise Management page

When you use the process on the Enterprise Management page to reset SEMM on a Surface device, you are
provided with a Reset Request. This Reset Request can be saved as a file to a USB drive, copied as text, or read as a
QR Code with a mobile device to be easily emailed or messaged. Use the Microsoft Surface UEFI Configurator
Reset Request option to load a Reset Request file or enter the Reset Request text or QR Code. Microsoft Surface
UEFI Configurator will generate a verification code that can be entered on the Surface device. If you enter the code
on the Surface device and click Restart, the device will be unenrolled from SEMM.

NOTE
A Reset Request expires two hours after it is created.

For a step-by-step walkthrough of how to unenroll Surface devices from SEMM, see Unenroll Surface devices
from SEMM.

Surface Enterprise Management Mode certificate requirements

NOTE
The SEMM certificate is required to perform any modification to SEMM or Surface UEFI settings on enrolled Surface devices.
If the SEMM certificate is corrupted or lost, SEMM cannot be removed or reset. Manage your SEMM certificate accordingly
with an appropriate solution for backup and recovery.

Packages created with the Microsoft Surface UEFI Configurator tool are signed with a certificate. This certificate
ensures that after a device is enrolled in SEMM, only packages created with the approved certificate can be used to
modify the settings of UEFI. The following settings are recommended for the SEMM certificate:
Key Algorithm – RSA
Key Length – 2048
Hash Algorithm – SHA-256
 Type – SSL Server Authentication
Key Usage – Key Encipherment
Provider – Microsoft Enhanced RSA and AES Cryptographic Provider
Expiration Date – 15 Months from certificate creation
Key Export Policy – Exportable
It is also recommended that the SEMM certificate be authenticated in a two-tier public key infrastructure (PKI)
architecture where the intermediate certification authority (CA) is dedicated to SEMM, enabling certificate
revocation. For more information about a two-tier PKI configuration, see Test Lab Guide: Deploying an AD CS
Two-Tier PKI Hierarchy.

NOTE
You can use the following PowerShell script to create a self-signed certificate for use in proof-of-concept scenarios. To use
this script, copy the following text into Notepad and save the file as a PowerShell script (.ps1). This script creates a certificate
with a password of 12345678 .

The certificate generated by this script is not recommended for production environments.

if (-not (Test-Path "Demo Certificate")) { New-Item -ItemType Directory -Force -Path "Demo Certificate" }
if (Test-Path "Demo Certificate\TempOwner.pfx") { Remove-Item "Demo Certificate\TempOwner.pfx" }

# Generate the Ownership private signing key with password 12345678

$pw = ConvertTo-SecureString "12345678" -AsPlainText -Force

$TestUefiV2 = New-SelfSignedCertificate `
-Subject "CN=Surface Demo Kit, O=Contoso Corporation, C=US" `
-Type SSLServerAuthentication `
-HashAlgorithm sha256 `
-KeyAlgorithm RSA `
-KeyLength 2048 `
-KeyUsage KeyEncipherment `
-KeyUsageProperty All `
-Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" `
-NotAfter (Get-Date).AddYears(25) `
-TextExtension @("2.5.29.37={text}1.2.840.113549.1.1.1") `
-KeyExportPolicy Exportable

$TestUefiV2 | Export-PfxCertificate -Password $pw -FilePath "Demo Certificate\TempOwner.pfx"

For use with SEMM and Microsoft Surface UEFI Configurator, the certificate must be exported with the private
key and with password protection. Microsoft Surface UEFI Configurator will prompt you to select the SEMM
certificate file (.pfx) and certificate password when it is required.

NOTE
For organizations that use an offline root in their PKI infrastructure, Microsoft Surface UEFI Configurator must be run in an
environment connected to the root CA to authenticate the SEMM certificate. The packages generated by Microsoft Surface
UEFI Configurator can be transferred as files and therefore can be transferred outside the offline network environment with
removable storage, such as a USB stick.

Version History
Version 2.21.136.9
Add support to Surface Pro 6
 Add support to Surface Laptop 2
Version 2.14.136.0
Add support to Surface Go
Version 2.9.136.0
Add support to Surface Book 2
Add support to Surface Pro LTE
Accessibility improvements
Version 1.0.74.0
Add support to Surface Laptop
Add support to Surface Pro
Bug fixes and general improvement

Related topics
Enroll and configure Surface devices with SEMM
Unenroll Surface devices from SEMM
 Enroll and configure Surface devices with SEMM
5/10/2018 • 7 minutes to read • Edit Online

With Microsoft Surface Enterprise Management Mode (SEMM ), you can securely configure the settings of Surface
UEFI on a Surface device and manage those settings on Surface devices in your organization. When a Surface
device is managed by SEMM, that device is considered to be enrolled (sometimes referred to as activated). This
article shows you how to create a Surface UEFI configuration package that will not only control the settings of
Surface UEFI, but will also enroll a Surface device in SEMM.
For a more high-level overview of SEMM, see Microsoft Surface Enterprise Management Mode.
Download and install Microsoft Surface UEFI Configurator
The tool used to create SEMM packages is Microsoft Surface UEFI Configurator. You can download Microsoft
Surface UEFI Configurator from the Surface Tools for IT page in the Microsoft Download Center. Run the
Microsoft Surface UEFI Configurator Windows Installer (.msi) file to start the installation of the tool. When the
installer completes, find Microsoft Surface UEFI Configurator in the All Apps section of your Start menu.

NOTE
Microsoft Surface UEFI Configurator is supported only on Windows 10.

Create a Surface UEFI configuration package

The Surface UEFI configuration package performs both the role of applying a new configuration of Surface UEFI
settings to a Surface device managed with SEMM and the role of enrolling Surface devices in SEMM. The creation
of a configuration package requires you to have a signing certificate to be used with SEMM to secure the
configuration of UEFI settings on each Surface device. For more information about the requirements for the
SEMM certificate, see Microsoft Surface Enterprise Management Mode.
To create a Surface UEFI configuration package, follow these steps:
1. Open Microsoft Surface UEFI Configurator from the Start menu.
2. Click Start.
3. Click Configuration Package, as shown in Figure 1.
 Figure 1. Select Configuration Package to create a package for SEMM enrollment and configuration
4. Click Certificate Protection to add your exported certificate file with private key (.pfx), as shown in Figure
2. Browse to the location of your certificate file, select the file, and then click OK.
 Figure 2. Add the SEMM certificate and Surface UEFI password to a Surface UEFI configuration package
5. When you are prompted to confirm the certificate password, enter and confirm the password for your
certificate file, and then click OK.
6. Click Password Protection to add a password to Surface UEFI. This password will be required whenever you
boot to UEFI. If this password is not entered, only the PC information, About, Enterprise management, and
Exit pages will be displayed. This step is optional.
7. When you are prompted, enter and confirm your chosen password for Surface UEFI, and then click OK. If you
want to clear an existing Surface UEFI password, leave the password field blank.
8. If you do not want the Surface UEFI package to apply to a particular device, on the Choose which Surface
type you want to target page, click the slider beneath the corresponding Surface Book or Surface Pro 4
image so that it is in the Off position. (As shown in Figure 3.)
 Figure 3. Choose the devices for package compatibility
9. Click Next.
10. If you want to deactivate a component on managed Surface devices, on the Choose which components
you want to activate or deactivate page, click the slider next to any device or group of devices you want
to deactivate so that the slider is in the Off position. (Shown in Figure 4.) The default configuration for each
device is On. Click the Reset button if you want to return all sliders to the default position.
 Figure 4. Disable or enable individual Surface components
11. Click Next.
12. To enable or disable advanced options in Surface UEFI or the display of Surface UEFI pages, on the Choose
the advanced settings for your devices page, click the slider beside the desired setting to configure that
option to On or Off (shown in Figure 5). In the UEFI Front Page section, you can use the sliders for
Security, Devices, and Boot to control what pages are available to users who boot into Surface UEFI. (For
more information about Surface UEFI settings, see Manage Surface UEFI settings.) Click Build when you
have finished selecting options to generate and save the package.
 Figure 5. Control advanced Surface UEFI settings and Surface UEFI pages with SEMM
13. In the Save As dialog box, specify a name for the Surface UEFI configuration package, browse to the
location where you would like to save the file, and then click Save.
14. When the package is created and saved, the Successful page is displayed.

NOTE
Record the certificate thumbprint characters that are displayed on this page, as shown in Figure 6. You will need these
characters to confirm enrollment of new Surface devices in SEMM. Click End to complete package creation and close
Microsoft Surface UEFI Configurator.
Figure 6. The last two characters of the certificate thumbprint are displayed on the Successful page
Now that you have created your Surface UEFI configuration package, you can enroll or configure Surface devices.

NOTE
When a Surface UEFI configuration package is created, a log file is created on the desktop with details of the configuration
package settings and options.

Enroll a Surface device in SEMM

When the Surface UEFI configuration package is executed, the SEMM certificate and Surface UEFI configuration
files are staged in the firmware storage of the Surface device. When the Surface device reboots, Surface UEFI
processes these files and begins the process of applying the Surface UEFI configuration or enrolling the Surface
device in SEMM, as shown in Figure 7.
Figure 7. The SEMM process for configuration of Surface UEFI or enrollment of a Surface device
Before you begin the process to enroll a Surface device in SEMM, ensure that you have the last two characters of
the certificate thumbprint on hand. You will need these characters to confirm the device’s enrollment (see Figure 6).
To enroll a Surface device in SEMM with a Surface UEFI configuration package, follow these steps:
1. Run the Surface UEFI configuration package .msi file on the Surface device you want to enroll in SEMM. This
will provision the Surface UEFI configuration file in the device’s firmware.
2. Select the I accept the terms in the License Agreement check box to accept the End User License
Agreement (EULA), and then click Install to begin the installation process.
3. Click Finish to complete the Surface UEFI configuration package installation and restart the Surface device
when you are prompted to do so.
4. Surface UEFI will load the configuration file and determine that SEMM is not enabled on the device. Surface
UEFI will then begin the SEMM enrollment process, as follows:
Surface UEFI will verify that the SEMM configuration file contains a SEMM certificate.
Surface UEFI will prompt you to enter to enter the last two characters of the certificate thumbprint to
confirm enrollment of the Surface device in SEMM, as shown in Figure 8.
 Figure 8. Enrollment in SEMM requires the last two characters of the certificate thumbprint
Surface UEFI will store the SEMM certificate in firmware and apply the configuration settings that are
specified in the Surface UEFI configuration file.
5. The Surface device is now enrolled in SEMM and will boot to Windows.
You can verify that a Surface device has been successfully enrolled in SEMM by looking for Microsoft Surface
Configuration Package in Programs and Features (as shown in Figure 9), or in the events stored in the
Microsoft Surface UEFI Configurator log, found under Applications and Services Logs in Event Viewer (as
shown in Figure 10).

Figure 9. Verify the enrollment of a Surface device in SEMM in Programs and Features
Figure 10. Verify the enrollment of a Surface device in SEMM in Event Viewer
You can also verify that the device is enrolled in SEMM in Surface UEFI – while the device is enrolled, Surface UEFI
will contain the Enterprise management page (as shown in Figure 11).

Figure 11. The Surface UEFI Enterprise management page

Configure Surface UEFI settings with SEMM

After a device is enrolled in SEMM, you can run Surface UEFI configuration packages signed with the same SEMM
certificate to apply new Surface UEFI settings. These settings are applied automatically the next time the device
boots, without any interaction from the user. You can use application deployment solutions like System Center
Configuration Manager to deploy Surface UEFI configuration packages to Surface devices to change or manage
the settings in Surface UEFI.
For more information about how to deploy Windows Installer (.msi) files with Configuration Manager, see Deploy
and manage applications with System Center Configuration Manager.
If you have secured Surface UEFI with a password, users without the password who attempt to boot to Surface
UEFI will only have the PC information, About, Enterprise management, and Exit pages displayed to them.
If you have not secured Surface UEFI with a password or a user enters the password correctly, settings that are
configured with SEMM will be dimmed (unavailable) and the text Some settings are managed by your
organization will be displayed at the top of the page, as shown in Figure 12.

Figure 12. Settings managed by SEMM will be disabled in Surface UEFI

 Unenroll Surface devices from SEMM
5/10/2018 • 7 minutes to read • Edit Online

When a Surface device is enrolled in Surface Enterprise Management Mode (SEMM ), a certificate is stored in the
firmware of that device. The presence of that certificate and the enrollment in SEMM prevent any unauthorized
changes to Surface UEFI settings or options while the device is enrolled in SEMM. To restore control of Surface
UEFI settings to the user, the Surface device must be unenrolled from SEMM, a process sometimes described as
reset or recovery. There are two methods you can use to unenroll a device from SEMM —a Surface UEFI reset
package and a Recovery Request.

WARNING
To unenroll a device from SEMM and restore user control of Surface UEFI settings, you must have the SEMM certificate that
was used to enroll the device in SEMM. If this certificate becomes lost or corrupted, it is not possible to unenroll from SEMM.
Back up and protect your SEMM certificate accordingly.

For more information about SEMM, see Microsoft Surface Enterprise Management Mode.

Unenroll a Surface device from SEMM with a Surface UEFI reset

package
The Surface UEFI reset package is the primary method you use to unenroll a Surface device from SEMM. Like a
Surface UEFI configuration package, the reset package is a Windows Installer (.msi) file that configures SEMM on
the device. Unlike the configuration package, the reset package will reset the Surface UEFI configuration on a
Surface device to its default settings, remove the SEMM certificate, and unenroll the device from SEMM.
Reset packages are created specifically for an individual Surface device. To begin the process of creating a reset
package, you will need the serial number of the device you want to unenroll, as well as the SEMM certificate used
to enroll the device. You can find the serial number of your Surface device on the PC information page of Surface
UEFI, as shown in Figure 1. This page is displayed even if Surface UEFI is password protected and the incorrect
password is entered.
Figure 1. The serial number of the Surface device is displayed on the Surface UEFI PC information page

NOTE
To boot to Surface UEFI, press Volume Up and Power simultaneously while the device is off. Hold Volume Up until the
Surface logo is displayed and the device begins to boot.

To create a Surface UEFI reset package, follow these steps:

1. Open Microsoft Surface UEFI Configurator from the Start menu.
2. Click Start.
3. Click Reset Package, as shown in Figure 2.
 Figure 2. Click Reset Package to create a package to unenroll a Surface device from SEMM
4. Click Certificate Protection to add your SEMM certificate file with private key (.pfx), as shown in Figure 3.
Browse to the location of your certificate file, select the file, and then click OK.
 Figure 3. Add the SEMM certificate to a Surface UEFI reset package
5. Click Next.
6. Type the serial number of the device you want to unenroll from SEMM (as shown in Figure 4), and then
click Build to generate the Surface UEFI reset package.
 Figure 4. Use the serial number of your Surface device to create a Surface UEFI reset package
7. In the Save As dialog box, specify a name for the Surface UEFI reset package, browse to the location where
you would like to save the file, and then click Save.
8. When the package generation has completed, the Successful page is displayed. Click End to complete package
creation and close Microsoft Surface UEFI Configurator.
Run the Surface UEFI reset package Windows Installer (.msi) file on the Surface device to unenroll the device from
SEMM. The reset package will require a reboot to perform the unenroll operation. After the device has been
unenrolled, you can verify the successful removal by ensuring that the Microsoft Surface Configuration
Package item in Programs and Features (shown in Figure 5) is no longer present.

Figure 5. The presence of the Microsoft Surface Configuration Package item in Programs and Features indicates
that the device is enrolled in SEMM

Unenroll a Surface device from SEMM with a Recovery Request

In some scenarios, a Surface UEFI reset package may not be a viable option to unenroll a Surface device from
SEMM (for example, where Windows has become unusable). In these scenarios you can unenroll the device by
using a Recovery Request generated from within Surface UEFI. The Recovery Request process can be initiated
even on devices where you do not have the Surface UEFI password.
The Recovery Request process is initiated from Surface UEFI on the Surface device, approved with Microsoft
Surface UEFI Configurator on another computer, and then completed in Surface UEFI. Like the reset package,
approving a Recovery Request with Microsoft Surface UEFI Configurator requires access to the SEMM certificate
that was used to enroll the Surface device.
To initiate a Recovery Request, follow these steps:
1. Boot the Surface device that is to be unenrolled from SEMM to Surface UEFI.
2. Type the Surface UEFI password if you are prompted to do so.
3. Click the Enterprise management page, as shown in Figure 6.
 Figure 6. The Enterprise management page is displayed in Surface UEFI on devices enrolled in SEMM
4. Click or press Get Started.
5. Click or press Next to begin the Recovery Request process. >[!NOTE ] >A Recovery Request expires two hours
after it is created. If a Recovery Request is not completed in this time, you will have to restart the Recovery
Request process.
6. Select SEMM Certificate from the list of certificates displayed on the Choose a SEMM reset key page
(shown in Figure 7), and then click or press Next.

Figure 7. Choose SEMM Certificate for your Recovery Request (Reset Request)
7. On the Enter SEMM reset verification code page you can click the QR Code or Text buttons to display
your Recovery Request (Reset Request) as shown in Figure 8, or the USB button to save your Recovery
Request (Reset Request) as a file to a USB drive, as shown in Figure 9.
 Figure 8. A Recovery Request (Reset Request) displayed as a QR Code

Figure 9. Save a Recovery Request (Reset Request) to a USB drive

To use a QR Code Recovery Request (Reset Request), use a QR reader app on a mobile device to read
the code. The QR reader app will translate the QR code into an alphanumeric string. You can then email
or message that string to the administrator that will produce the reset verification code with Microsoft
Surface UEFI Configurator.
To use a Recovery Request (Reset Request) saved to a USB drive as a file, use the USB drive to transfer
the file to the computer where Microsoft Surface UEFI Configurator will be used to produce the Reset
Verification Code. The file can also be copied from the USB drive on another device to be emailed or
transferred over the network.
To use the Recovery Request (Reset Request) as text, simply type the text directly into Microsoft Surface
UEFI Configurator.
8. Open Microsoft Surface UEFI Configurator from the Start menu on another computer.
 NOTE
Microsoft Surface UEFI Configurator must run in an environment that is able to authenticate the certificate chain for
the SEMM certificate.

9. Click Start.
10. Click Recovery Request, as shown in Figure 10.

Figure 10. Click Recovery Request to begin the process to approve a Recovery Request
11. Click Certificate Protection to authenticate the Recovery Request with the SEMM certificate.
12. Browse to and select your SEMM certificate file, and then click OK.
13. When you are prompted to enter the certificate password as shown in Figure 11, type and confirm the
password for the certificate file, and then click OK.
 Figure 11. Type the password for the SEMM certificate
14. Click Next.
15. Enter the Recovery Request (Reset Request), and then click Generate to create a reset verification code (as
shown in Figure 12).
 Figure 12. Enter the Recovery Request (Reset Request)
If you displayed the Recovery Request (Reset Request) as text on the Surface device being reset, use the
keyboard to type the Recovery Request (Reset Request) in the provided field.
If you displayed the Recovery Request (Reset Request) as a QR Code and then used a messaging or
email application to send the code to the computer with Microsoft Surface UEFI Configurator, copy and
paste the code into the provided field.
If you saved the Recovery Request (Reset Request) as a file to a USB drive, click the Import button,
browse to and select the Recovery Request (Reset Request) file, and then click OK.
16. The reset verification code is displayed in Microsoft Surface UEFI Configurator, as shown in Figure 13.
 Figure 13. The reset verification code displayed in Microsoft Surface UEFI Configurator
Click the Share button to send the reset verification code by email.
17. Enter the reset verification code in the provided field on the Surface device (shown in Figure 8), and then
click or press Verify to reset the device and unenroll the device from SEMM.
18. Click or press Restart now on the SEMM reset successful page to complete the unenrollment from
SEMM, as shown in Figure 14.
 Figure 14. Successful unenrollment from SEMM
19. Click End in Microsoft Surface UEFI Configurator to complete the Recovery Request (Reset Request)
process and close Microsoft Surface UEFI Configurator.
 Use System Center Configuration Manager to
manage devices with SEMM
10/26/2018 • 23 minutes to read • Edit Online

The Surface Enterprise Management Mode (SEMM ) feature of Surface UEFI devices allows administrators to both
manage and secure the configuration of Surface UEFI settings. For most organizations, this process is
accomplished by creating Windows Installer (.msi) packages with the Microsoft Surface UEFI Configurator tool.
These packages are then run or deployed to the client Surface devices to enroll the devices in SEMM and to update
the Surface UEFI settings configuration.
For organizations with System Center Configuration Manager, there is an alternative to using the Microsoft
Surface UEFI Configurator .msi process to deploy and administer SEMM. Microsoft Surface UEFI Manager is a
lightweight installer that makes required assemblies for SEMM management available on a device. By installing
these assemblies with Microsoft Surface UEFI Manager on a managed client, SEMM can be administered by
Configuration Manager with PowerShell scripts, deployed as applications. With this process, SEMM management
is performed within Configuration Manager, which eliminates the need for the external Microsoft Surface UEFI
Configurator tool.

NOTE
Although the process described in this article may work with earlier versions of System Center Configuration Manager or
with other third-party management solutions, management of SEMM with Microsoft Surface UEFI Manager and PowerShell
is supported only with the Current Branch of System Center Configuration Manager.

Prerequisites
Before you begin the process outlined in this article, it is expected that you are familiar with the following
technologies and tools:
Surface UEFI
Surface Enterprise Management Mode (SEMM )
PowerShell scripting
System Center Configuration Manager application deployment
Certificate management

NOTE
You will also need access to the certificate that you intend to use to secure SEMM. For details about the requirements for this
certificate, see Surface Enterprise Management Mode certificate requirements.
It is very important that this certificate be kept in a safe location and properly backed up. If this certificate becomes lost or
unusable, it is not possible to reset Surface UEFI, change managed Surface UEFI settings, or remove SEMM from an enrolled
Surface device.

Download Microsoft Surface UEFI Manager

Management of SEMM with Configuration Manager requires the installation of Microsoft Surface UEFI Manager
on each client Surface device. You can download Microsoft Surface UEFI Manager (SurfaceUEFIManager.msi)
from the Surface Tools for IT page on the Microsoft Download Center.
Download SEMM scripts for Configuration Manager
After Microsoft Surface UEFI Manager is installed on the client Surface device, SEMM is deployed and managed
with PowerShell scripts. You can download samples of the SEMM management scripts from the Download Center.

Deploy Microsoft Surface UEFI Manager

Deployment of Microsoft Surface UEFI Manager is a typical application deployment. The Microsoft Surface UEFI
Manager installer file is a standard Windows Installer file that you can install with the standard quiet option.
The command to install Microsoft Surface UEFI Manager is:
msiexec /i "SurfaceUEFIManagerSetup.msi" /q

The command to uninstall Microsoft Surface UEFI Manager is:

msiexec /x {541DA890-1AEB-446D-B3FD-D5B3BB18F9AF} /q

To create a new application and deploy it to a collection that contains your Surface devices, perform the following
steps:
1. Open Configuration Manager Console from the Start screen or Start menu.
2. Click Software Library in the bottom left corner of the window.
3. Expand the Application Management node of the Software Library, and then click Applications.
4. Click the Create Application button under the Home tab at the top of the window. This starts the Create
Application Wizard.
5. The Create Application Wizard presents a series of steps:
General – The Automatically detect information about this application from installation
files option is selected by default. In the Type field, Windows Installer (*.msi file) is also selected
by default. Click Browse to navigate to and select SurfaceUEFIManagerSetup.msi, and then click
Next.

NOTE
The location of SurfaceUEFIManagerSetup.msi must be on a network share and located in a folder that
contains no other files. A local file location cannot be used.

Import Information – The Create Application Wizard will parse the .msi file and read the
Application Name and Product Code. SurfaceUEFIManagerSetup.msi should be listed as the only
file under the line Content Files, as shown in Figure 1. Click Next to proceed.
Figure 1. Information from Microsoft Surface UEFI Manager setup is automatically parsed
General Information – You can modify the name of the application and information about the publisher and
version, or add comments on this page. The installation command for Microsoft Surface UEFI Manager is
displayed in the Installation Program field. The default installation behavior of Install for system will allow
Microsoft Surface UEFI Manager to install the required assemblies for SEMM even if a user is not logged on to
the Surface device. Click Next to proceed.
Summary – The information that was parsed in the Import Information step and your selections from the
General Information step is displayed on this page. Click Next to confirm your selections and create the
application.
Progress – Displays a progress bar and status as the application is imported and added to the Software Library.
Completion – Confirmation of the successful application creation is displayed when the application creation
process is complete. Click Close to finish the Create Application Wizard.
After the application is created in Configuration Manager, you can distribute it to your distribution points and
deploy it to the collections including your Surface devices. This application will not install or enable SEMM on the
Surface device – it only provides the assemblies required for SEMM to be enabled via PowerShell script.
If you do not want to install the Microsoft Surface UEFI Manager assemblies on devices that will not be managed
with SEMM, you can configure Microsoft Surface UEFI Manager as a dependency of the SEMM Configuration
Manager scripts. This scenario is covered in the Deploy SEMM Configuration Manager Scripts section later in this
article.

Create or modify the SEMM Configuration Manager scripts

After the required assemblies have been installed on the devices, the process of enrolling the devices in SEMM and
configuring Surface UEFI is done with PowerShell scripts and deployed as a script application with Configuration
Manager. These scripts can be modified to fit the needs of your organization and environment. For example, you
can create multiple configurations for managed Surface devices in different departments or roles. You can
download samples of the scripts for SEMM and Configuration Manager at the link in the Prerequisites section at
the beginning of this article.
There are two primary scripts you will need to perform a SEMM deployment with Configuration Manager:
ConfigureSEMM.ps1 – Use this script to create configuration packages for your Surface devices with your
desired Surface UEFI settings, to apply the specified settings to a Surface device, to enroll the device in SEMM,
and to set a registry key used to identify the enrollment of the device in SEMM.
ResetSEMM.ps1 – Use this script to reset SEMM on a Surface device, which unenrolls it from SEMM and
removes the control over Surface UEFI settings.
The sample scripts include examples of how to set Surface UEFI settings and how to control permissions to those
settings. These settings can be modified to secure Surface UEFI and set Surface UEFI settings according to the
needs of your environment. The following sections of this article explain the ConfigureSEMM.ps1 script and
explore the modifications you need to make to the script to fit your requirements.

NOTE
The SEMM Configuration Manager scripts and the exported SEMM certificate file (.pfx) should be placed in the same folder
with no other files before they are added to Configuration Manager.

Specify certificate and package names

The first region of the script that you need to modify is the portion that specifies and loads the SEMM certificate,
and also indicates the names for the SEMM configuration package and SEMM reset package. The certificate and
package names are specified on lines 56 through 67 in the ConfigureSEMM.ps1 script:

56 $WorkingDirPath = split-path -parent $MyInvocation.MyCommand.Definition

57 $packageRoot = "$WorkingDirPath\Config"
58
59 if (-not (Test-Path $packageRoot)) { New-Item -ItemType Directory -Force -Path $packageRoot }
60 Copy-Item "$WorkingDirPath\FabrikamOwnerSigner.pfx" $packageRoot
61
62 $privateOwnerKey = Join-Path -Path $packageRoot -ChildPath "FabrikamOwnerSigner.pfx"
63 $ownerPackageName = Join-Path -Path $packageRoot -ChildPath "FabrikamSignerProvisioningPackage.pkg"
64 $resetPackageName = Join-Path -Path $packageRoot -ChildPath "FabrikamUniversalResetPackage.pkg"
65
66 # If your PFX file requires a password then it can be set here, otherwise use a blank string.
67 $password = "1234"

Replace the FabrikamOwnerSigner.pfx value for the $privateOwnerKey variable with the name of your SEMM
Certificate file on both lines 60 and 62. The script will create a working directory (named Config) in the folder
where your scripts are located, and will then copy the certificate file to this working directory.
Replace the FabrikamSignerProvisioningPackage.pkg and FabrikamUniversalResetPackage.pkg values on
lines 63 and 64 to define the $ownerPackageName and $resetPackageName variables with your desired
names for the SEMM configuration and reset packages. These packages will also be created in the Config directory
and hold the configuration for Surface UEFI settings and permissions generated by the script.
On line 67, replace the value of the $password variable, from 1234, to the password for your certificate file. If a
password is not required, delete the 1234 text.
 NOTE
The last two characters of the certificate thumbprint are required to enroll a device in SEMM. This script will display these
digits to the user, which allows the user or technician to record these digits before the system reboots to enroll the device in
SEMM. The script uses the following code, found on lines 144-149, to accomplish this:

144 # Device owners will need the last two characters of the thumbprint to accept SEMM ownership.
145 # For convenience we get the thumbprint here and present to the user.
146 $pw = ConvertTo-SecureString $password -AsPlainText -Force
147 $certPrint = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2
148 $certPrint.Import($privateOwnerKey, $pw,
[System.Security.Cryptography.X509Certificates.X509KeyStorageFlags]::DefaultKeySet)
149 Write-Host "Thumbprint =" $certPrint.Thumbprint

Administrators with access to the certificate file (.pfx) can read the thumbprint at any time by opening the .pfx file in
CertMgr. To view the thumbprint with CertMgr, follow this process:
1. Right-click the .pfx file, and then click Open.
2. Expand the folder in the navigation pane.
3. Click Certificates.
4. Right-click your certificate in the main pane, and then click Open.
5. Click the Details tab.
6. All or Properties Only must be selected in the Show drop-down menu.
7. Select the field Thumbprint.

NOTE
The SEMM certificate name and password must also be entered in this section of the ResetSEMM.ps1 script to enable
Configuration Manager to remove SEMM from the device with the uninstall action.

Configure permissions
The first region of the script where you will specify the configuration for Surface UEFI is the Configure
Permissions region. This region begins at line 202 in the sample script with the comment # Configure
Permissions and continues to line 238. The following code fragment first sets permissions to all Surface UEFI
settings so that they may be modified by SEMM only, then adds explicit permissions to allow the local user to
modify the Surface UEFI password, TPM, and front and rear cameras:
 202 # Configure Permissions
203 foreach ($uefiV2 IN $surfaceDevices.Values) {
204 # Here we define which "identities" will be allowed to modify which settings
205 # PermissionSignerOwner = The primary SEMM enterprise owner identity
206 # PermissionLocal = The user when booting to the UEFI pre-boot GUI
207 # PermissionSignerUser, PermissionSignerUser1, PermissionSignerUser2 =
208 # Additional user identities created so that the signer owner
209 # can delegate permission control for some settings.
210 $ownerOnly = [Microsoft.Surface.IUefiSetting]::PermissionSignerOwner
211 $ownerAndLocalUser = ([Microsoft.Surface.IUefiSetting]::PermissionSignerOwner -bor
[Microsoft.Surface.IUefiSetting]::PermissionLocal)
212
213 # Make all permissions owner only by default
214 foreach ($setting IN $uefiV2.Settings.Values) {
215 $setting.ConfiguredPermissionFlags = $ownerOnly
216 }
217 # Allow the local user to change their own password
218 $uefiV2.SettingsById[501].ConfiguredPermissionFlags = $ownerAndLocalUser
219
220 # Allow the local user to change the state of the TPM
221 $uefiV2.Settings["Trusted Platform Module (TPM)"].ConfiguredPermissionFlags = $ownerAndLocalUser
222
223 # Allow the local user to change the state of the Front and Rear cameras
224 $uefiV2.SettingsById[302].ConfiguredPermissionFlags = $ownerAndLocalUser
225 $uefiV2.SettingsById[304].ConfiguredPermissionFlags = $ownerAndLocalUser
226
227
228 # Create a unique package name based on family and LSV.
229 # We will choose a name that can be parsed by later scripts.
230 $packageName = $uefiV2.SurfaceUefiFamily + "^Permissions^" + $lsv + ".pkg"
231 $fullPackageName = Join-Path -Path $packageRoot -ChildPath $packageName
232
233 # Build and sign the Permission package then save it to a file.
234 $permissionPackageStream = $uefiV2.BuildAndSignPermissionPackage($privateOwnerKey, $password, "", $null,
$lsv)
235 $permissionPackage = New-Object System.IO.Filestream($fullPackageName, [System.IO.FileMode]::CreateNew,
[System.IO.FileAccess]::Write)
236 $permissionPackageStream.CopyTo($permissionPackage)
237 $permissionPackage.Close()
238 }

Each $uefiV2 variable identifies a Surface UEFI setting by setting name or ID, and then configures the permissions
to one of the following values:
$ownerOnly – Permission to modify this setting is granted only to SEMM.
$ownerAndLocalUser – Permission to modify this setting is granted to a local user booting to Surface UEFI,
as well as to SEMM.
You can find information about the available settings names and IDs for Surface UEFI in the Settings Names and
IDs section of this article.
Configure settings
The second region of the script where you will specify the configuration for Surface UEFI is the Configure
Settings region of the ConfigureSEMM.ps1 script, which configures whether each setting is enabled or disabled.
The sample script includes instructions to set all settings to their default values. The script then provides explicit
instructions to disable IPv6 for PXE Boot and to leave the Surface UEFI Administrator password unchanged. You
can find this region beginning with the # Configure Settings comment at line 282 through line 312 in the sample
script. The region appears as follows:
 282 # Configure Settings
283 foreach ($uefiV2 IN $surfaceDevices.Values) {
284 # In this demo, we will start by setting every setting to the default factory setting.
285 # You may want to start by doing this in your scripts
286 # so that every setting gets set to a known state.
287 foreach ($setting IN $uefiV2.Settings.Values) {
288 $setting.ConfiguredValue = $setting.DefaultValue
289 }
290
291 # If you want to set something to a different value from the default,
292 # here are examples of how to accomplish this.
293 $uefiV2.Settings["IPv6 for PXE Boot"].ConfiguredValue = "Disabled"
294
295 # If you want to leave the setting unmodified, set it to $null
296 # PowerShell has issues setting things to $null so ClearConfiguredValue()
297 # is supplied to do this explicitly.
298 # Here is an example of leaving the UEFI administrator password as-is,
299 # even after we initially set it to factory default above.
300 $uefiV2.SettingsById[501].ClearConfiguredValue()
301
302 # Create a unique package name based on family and LSV.
303 # We will choose a name that can be parsed by later scripts.
304 $packageName = $uefiV2.SurfaceUefiFamily + "^Settings^" + $lsv + ".pkg"
305 $fullPackageName = Join-Path -Path $packageRoot -ChildPath $packageName
306
307 # Build and sign the Settings package then save it to a file.
308 $settingsPackageStream = $uefiV2.BuildAndSignSecuredSettingsPackage($privateOwnerKey, $password, "",
$null, $lsv)
309 $settingsPackage = New-Object System.IO.Filestream($fullPackageName, [System.IO.FileMode]::CreateNew,
[System.IO.FileAccess]::Write)
310 $settingsPackageStream.CopyTo($settingsPackage)
311 $settingsPackage.Close()
312 }

Like the permissions set in the Configure Permissions section of the script, the configuration of each Surface
UEFI setting is performed by defining the $uefiV2 variable. For each line defining the $uefiV2 variable, a Surface
UEFI setting is identified by setting name or ID and the configured value is set to Enabled or Disabled.
If you do not want to alter the configuration of a Surface UEFI setting, for example to ensure that the Surface UEFI
administrator password is not cleared by the action of resetting all Surface UEFI settings to their default, you can
use ClearConfiguredValue() to enforce that this setting will not be altered. In the sample script, this is used on
line 300 to prevent the clearing of the Surface UEFI Administrator password, identified in the sample script by its
setting ID, 501.
You can find information about the available settings names and IDs for Surface UEFI in the Settings Names and
IDs section later in this article.
Settings registry key
To identify enrolled systems for Configuration Manager, the ConfigureSEMM.ps1 script writes a registry key that
can be used to identify enrolled systems as having been installed with the SEMM configuration script. This key can
be found at the following location:
HKLM\SOFTWARE\Microsoft\Surface\SEMM\Enabled_Version1000

The following code fragment, found on lines 352-363, is used to write this registry key:
 352 $SurfaceRegKey = "HKLM:\SOFTWARE\Microsoft\Surface\SEMM"
353 New-RegKey $SurfaceRegKey
354 $SurfaceRegValue = Get-ItemProperty $SurfaceRegKey Enabled_Version1000 -ErrorAction SilentlyContinue
355
356 If ($SurfaceRegValue -eq $null)
357 {
358 New-ItemProperty -Path $SurfaceRegKey -Name Enabled_Version1000 -PropertyType String -Value 1 | Out-Null
359 }
360 Else
361 {
362 Set-ItemProperty -Path $SurfaceRegKey -Name Enabled_Version1000 -Value 1
363 }

Settings names and IDs

To configure Surface UEFI settings or permissions for Surface UEFI settings, you must refer to each setting by
either its setting name or setting ID. With each new update for Surface UEFI, new settings may be added. The best
way to get a complete list of the settings available on a Surface device, along with the settings name and settings
IDs, is to use the ShowSettingsOptions.ps1 script from SEMM_Powershell.zip in Surface Tools for IT Downloads
The computer where ShowSettingsOptions.ps1 is run must have Microsoft Surface UEFI Manager installed, but
the script does not require a Surface device.
The following tables show the available settings for Surface Pro 4 and Surface Book:
Table 1. Surface UEFI settings for Surface Pro 4

SETTING ID SETTING NAME DESCRIPTION DEFAULT SETTING

501 Password UEFI System Password

200 Secure Boot Keys Secure Boot signing keys to MsPlus3rdParty

enable for EFI applications

300 Trusted Platform Module TPM device enabled or Enabled

(TPM) disabled

301 Docking USB Port Docking USB Port enabled Enabled

or disabled

302 Front Camera Front Camera enabled or Enabled

disabled

303 Bluetooth Bluetooth radio enabled or Enabled

disabled

304 Rear Camera Rear Camera enabled or Enabled

disabled

305 IR Camera InfraRed Camera enabled or Enabled

disabled

308 Wi-Fi and Bluetooth Wi-Fi and Bluetooth enabled Enabled

or disabled

310 Type Cover Surface Type Cover Enabled

connector
 SETTING ID SETTING NAME DESCRIPTION DEFAULT SETTING

320 On-board Audio On-board audio enabled or Enabled

disabled

330 Micro SD Card Micro SD Card enabled or Enabled

disabled

370 USB Port 1 Side USB Port (1) UsbPortEnabled

400 IPv6 for PXE Boot Enable IPv6 PXE boot before Disabled
IPv4 PXE boot

401 Alternate Boot Alternate Boot allows users Enabled

to override the boot order
by holding the volume down
button when powering up
the device

402 Boot Order Lock Boot Order variable lock Disabled

enabled or disabled

403 USB Boot Enable booting from USB Enabled

devices

500 TPM clear EFI protocol Enable EFI protocol for Disabled
invoking TPM clear

600 Security UEFI Security Page Display Enabled

enabled or disabled

601 Devices UEFI Devices Page Display Enabled

enabled or disabled

602 Boot UEFI Boot Manager Page Enabled

Display enabled or disabled

Table 2. Surface UEFI settings for Surface Book

SETTING ID SETTING NAME DESCRIPTION DEFAULT SETTING

501 Password UEFI System Password

200 Secure Boot Keys Secure Boot signing keys to MsPlus3rdParty

enable for EFI applications

300 Trusted Platform Module TPM device enabled or Enabled

(TPM) disabled

301 Docking USB Port Docking USB Port enabled Enabled

or disabled

302 Front Camera Front Camera enabled or Enabled

disabled
 SETTING ID SETTING NAME DESCRIPTION DEFAULT SETTING

303 Bluetooth Bluetooth radio enabled or Enabled

disabled

304 Rear Camera Rear Camera enabled or Enabled

disabled

305 IR Camera InfraRed Camera enabled or Enabled

disabled

308 Wi-Fi and Bluetooth Wi-Fi and Bluetooth enabled Enabled

or disabled

320 On-board Audio On-board audio enabled or Enabled

disabled

400 IPv6 for PXE Boot Enable IPv6 PXE boot before IPv4 Disabled
PXE boot

401 Alternate Boot Alternate Boot allows users Enabled

to override the boot order
by holding the volume down
button when powering up
the device

402 Boot Order Lock Boot Order variable lock Disabled

enabled or disabled

403 USB Boot Enable booting from USB Enabled

devices

500 TPM clear EFI protocol Enable EFI protocol for Disabled
invoking TPM clear

600 Security UEFI Security Page Display Enabled

enabled or disabled

601 Devices UEFI Devices Page Display Enabled

enabled or disabled

602 Boot UEFI Boot Manager Page Enabled

Display enabled or disabled

Deploy SEMM Configuration Manager scripts

After your scripts are prepared to configure and enable SEMM on the client device, the next step is to add these
scripts as an application in Configuration Manager. Before you open Configuration Manager, ensure that the
following files are in a shared folder that does not include other files:
ConfigureSEMM.ps1
ResetSEMM.ps1
Your SEMM certificate (for example SEMMCertificate.pfx)
The SEMM Configuration Manager scripts will be added to Configuration Manager as a script application. The
command to install SEMM with ConfigureSEMM.ps1 is:
Powershell.exe -file ".\ConfigureSEMM.ps1"

The command to uninstall SEMM with ResetSEMM.ps1 is:

Powershell.exe -file ".\ResetSEMM.ps1"

To add the SEMM Configuration Manager scripts to Configuration Manager as an application, use the following
process:
1. Start the Create Application Wizard using Step 1 through Step 5 from the Deploy Microsoft Surface UEFI
Manager section earlier in this article.
2. Proceed through The Create Application Wizard as follows:
General – Select Manually specify the application information, and then click Next.
General Information – Enter a name for the application (for example SEMM ) and any other
information you want such as publisher, version, or comments on this page. Click Next to proceed.
Application Catalog – The fields on this page can be left with their default values. Click Next.
Deployment Types – Click Add to start the Create Deployment Type Wizard.
Proceed through the steps of the Create Deployment Type Wizard, as follows:
General – Click Script Installer from the Type drop-down menu. The Manually specify the
deployment type information option will automatically be selected. Click Next to proceed.
General Information – Enter a name for the deployment type (for example SEMM
Configuration Scripts), and then click Next to continue.
Content – Click Browse next to the Content Location field, and then click the folder where your
SEMM Configuration Manager scripts are located. In the Installation Program field, type the
installation command found earlier in this article. In the Uninstall Program field, enter the
uninstallation command found earlier in this article (shown in Figure 2). Click Next to move to
the next page.
Figure 2. Set the SEMM Configuration Manager scripts as the install and uninstall commands
Detection Method – Click Add Clause to add the SEMM Configuration Manager script
registry key detection rule. The Detection Rule window is displayed, as shown in Figure 3.
Use the following settings:
Click Registry from the Setting Type drop-down menu.
Click HKEY_LOCAL_MACHINE from the Hive drop-down menu.
Enter SOFTWARE\Microsoft\Surface\SEMM in the Key field.
Enter Enabled_Version1000 in the Value field.
Click String from the Data Type drop-down menu.
Click the This registry setting must satisfy the following rule to indicate the
presence of this application button.
Enter 1 in the Value field.
Click OK to close the Detection Rule window.
Figure 3. Use a registry key to identify devices enrolled in SEMM
Click Next to proceed to the next page.
User Experience – Click Install for system from the Installation Behavior drop-down
menu. If you want your users to record and enter the certificate thumbprint themselves, leave
the logon requirement set to Only when a user is logged on. If you want your
administrators to enter the thumbprint for users and the users do not need to see the
thumbprint, click Whether or not a user is logged on from the Logon Requirement drop-
down menu.
Requirements – The ConfigureSEMM.ps1 script automatically verifies that the device is a
Surface device before attempting to enable SEMM. However, if you intend to deploy this script
application to a collection with devices other than those to be managed with SEMM, you could
add requirements here to ensure this application would run only on Surface devices or devices
you intend to manage with SEMM. Click Next to continue.
Dependencies – Click Add to open the Add Dependency window.
Click Add to open the Specify Required Application window.
Enter a name for the SEMM dependencies in the Dependency Group Name
field (for example, SEMM Assemblies).
Click Microsoft Surface UEFI Manager from the list of Available
Applications and the MSI deployment type, and then click OK to close the
Specify Required Application window.
Keep the Auto Install check box selected if you want Microsoft Surface UEFI
Manager installed automatically on devices when you attempt to enable SEMM with
 the Configuration Manager scripts. Click OK to close the Add Dependency
window.
Click Next to proceed.
Summary – The information you have entered throughout the Create Deployment Type
wizard is displayed on this page. Click Next to confirm your selections.
Progress – A progress bar and status as the deployment type is added for the SEMM script
application is displayed on this page.
Completion – Confirmation of the deployment type creation is displayed when the process is
complete. Click Close to finish the Create Deployment Type Wizard.
Summary – The information that you entered throughout the Create Application Wizard is
displayed. Click Next to create the application.
Progress – A progress bar and status as the application is added to the Software Library is displayed
on this page.
Completion – Confirmation of the successful application creation is displayed when the application
creation process is complete. Click Close to finish the Create Application Wizard.
After the script application is available in the Software Library of Configuration Manager, you can distribute and
deploy SEMM using the scripts you prepared to devices or collections. If you have configured the Microsoft
Surface UEFI Manager assemblies as a dependency that will be automatically installed, you can deploy SEMM in a
single step. If you have not configured the assemblies as a dependency, they must be installed on the devices you
intend to manage before you enable SEMM.
When you deploy SEMM using this script application and with a configuration that is visible to the end user, the
PowerShell script will start and the thumbprint for the certificate will be displayed by the PowerShell window. You
can have your users record this thumbprint and enter it when prompted by Surface UEFI after the device reboots.
Alternatively, you can configure the application installation to reboot automatically and to install invisibly to the
user – in this scenario, a technician will be required to enter the thumbprint on each device as it reboots. Any
technician with access to the certificate file can read the thumbprint by viewing the certificate with CertMgr.
Instructions for viewing the thumbprint with CertMgr are in the Create or modify the SEMM Configuration
Manager scripts section of this article.
Removal of SEMM from a device deployed with Configuration Manager using these scripts is as easy as
uninstalling the application with Configuration Manager. This action starts the ResetSEMM.ps1 script and properly
unenrolls the device with the same certificate file that was used during the deployment of SEMM.

NOTE
Microsoft Surface recommends that you create reset packages only when you need to unenroll a device. These reset
packages are typically valid for only one device, identified by its serial number. You can, however, create a universal reset
package that would work for any device enrolled in SEMM with this certificate.
We strongly recommend that you protect your universal reset package as carefully as the certificate you used to enroll
devices in SEMM. Please remember that – just like the certificate itself – this universal reset package can be used to unenroll
any of your organization’s Surface devices from SEMM.
When you install a reset package, the Lowest Supported Value (LSV) is reset to a value of 1. You can reenroll a device by
using an existing configuration package – the device will prompt for the certificate thumbprint before ownership is taken.
For this reason, the reenrollment of a device in SEMM would require a new package to be created and installed on that
device. Because this action is a new enrollment and not a change in configuration on a device already enrolled in SEMM, the
device will prompt for the certificate thumbprint before ownership is taken.
 Surface Diagnostic Toolkit for Business
11/19/2018 • 4 minutes to read • Edit Online

The Microsoft Surface Diagnostic Toolkit for Business (SDT) enables IT administrators to quickly investigate,
troubleshoot, and resolve hardware, software, and firmware issues with Surface devices. You can run a range of
diagnostic tests and software repairs in addition to obtaining device health insights and guidance for resolving
issues.
Specifically, SDT for Business enables you to:
Customize the package.
Run the app using commands.
Run multiple hardware tests to troubleshoot issues.
Generate logs for analyzing issues.
Obtain detailed report comparing device vs optimal configuration.

Primary scenarios and download resources

To run SDT for Business, download the components listed in the following table.

NOTE
In contrast to the way you typically install MSI packages, the SDT distributable MSI package can only be created by running
Windows Installer (MSI.exe) at a command prompt and setting the custom flag ADMINMODE = 1 . For details, see Run Surface
Diagnostic Toolkit using commands.

MODE PRIMARY SCENARIOS DOWNLOAD LEARN MORE

Desktop mode Assist users in running SDT SDT distributable MSI Use Surface Diagnostic
on their Surface devices to package Toolkit in desktop mode
troubleshoot issues. Microsoft Surface Diagnostic
Create a custom package to Toolkit for Business
deploy on one or more Installer.MSI
Surface devices allowing Surface Tools for IT
users to select specific logs
to collect and analyze.
 MODE PRIMARY SCENARIOS DOWNLOAD LEARN MORE

Command line Directly troubleshoot Surface SDT console app Run Surface Diagnostic
devices remotely without Microsoft Surface Toolkit using commands
user interaction, using Diagnostics App Console.exe
standard tools such as Surface Tools for IT
Configuration Manager. It
includes the following
commands:
-DataCollector collects all
log files
-bpa runs health
diagnostics using Best
Practice Analyzer.
-windowsupdate checks
Windows update for missing
firmware or driver updates.

Note: Support for the ability

to confirm warranty
information will be available
via the command
-warranty

Supported devices
SDT for Business is supported on Surface 3 and later devices, including:
Surface Pro 6
Surface Laptop 2
Surface Go
Surface Go with LTE
Surface Book 2
Surface Pro with LTE Advanced (Model 1807)
Surface Pro (Model 1796)
Surface Laptop
Surface Studio
Surface Studio 2
Surface Book
Surface Pro 4
Surface 3 LTE
Surface 3
Surface Pro 3

Installing Surface Diagnostic Toolkit for Business

To create an SDT package that you can distribute to users in your organization, you first need to install SDT at a
command prompt and set a custom flag to install the tool in admin mode. SDT contains the following install option
flags:
SENDTELEMETRY sends telemetry data to Microsoft. The flag accepts 0 for disabled or 1 for enabled. The
default value is 1 to send telemetry.
ADMINMODE configures the tool to be installed in admin mode. The flag accepts 0 for Business client mode or
1 for Business Administrator mode. The default value is 0 .
To install SDT in ADMINMODE:
1. Sign into your Surface device using the Administrator account.
2. Download SDT Windows Installer Package (.msi) from the Surface Tools for IT download page and copy it to a
preferred location on your Surface device, such as Desktop.
3. Open a command prompt and enter:

msiexec.exe /i <the path of installer> ADMINMODE=1.

Example:

C:\Users\Administrator>
msiexec.exe/I"C:\Users\Administrator\Desktop\Microsoft_Surface_Diagnostic_Toolkit_for_Business_Installer
.msi" ADMINMODE=1

4. The SDT setup wizard appears, as shown in figure 1. Click Next.

NOTE
If the setup wizard does not appear, ensure that you are signed into the Administrator account on your computer.

Figure 1. Surface Diagnostic Toolkit setup wizard

5. When the SDT setup wizard appears, click Next, accept the End User License Agreement (EULA), and select
a location to install the package.
6. Click Next and then click Install.

Locating SDT on your Surface device

Both SDT and the SDT app console are installed at
C:\Program Files\Microsoft\Surface\Microsoft Surface Diagnostic Toolkit for Business .
In addition to the .exe file, SDT installs a JSON file and an admin.dll file (modules\admin.dll), as shown in figure 2.
Figure 2. Files installed by SDT

Preparing the SDT package for distribution

Creating a custom package allows you to target the tool to specific known issues.
1. Click Start > Run, enter Surface and then click Surface Diagnostic Toolkit for Business.
2. When the tool opens, click Create Custom Package, as shown in figure 3.

Figure 3. Create custom package

Language and telemetry page
When you start creating the custom package, you’re asked whether you agree to send data to Microsoft to help
improve the application. For more information,see the Microsoft Privacy Statement. Sharing is on by default, so
uncheck the box if you wish to decline.

NOTE
This setting is limited to only sharing data generated while running packages.
Figure 4. Select language and telemetry settings
Windows Update page
Select the option appropriate for your organization. Most organizations with multiple users will typically select to
receive updates via Windows Server Update Services (WSUS ), as shown in figure 5. If using local Windows update
packages or WSUS, enter the path as appropriate.

Figure 5. Windows Update option

Software repair page
This allows you to select or remove the option to run software repair updates.
Figure 6. Software repair option
Collecting logs and saving package page
You can select to run a wide range of logs across applications, drivers, hardware, and the operating system. Click
the appropriate area and select from the menu of available logs. You can then save the package to a software
distribution point or equivalent location that users can access.

Figure 7. Log option and save package

Next steps
Use Surface Diagnostic Toolkit for Business in desktop mode
Use Surface Diagnostic Toolkit for Business using commands
 Use Surface Diagnostic Toolkit for Business in desktop
mode
11/19/2018 • 2 minutes to read • Edit Online

This topic explains how to use the Surface Diagnostic Toolkit (SDT) to help users in your organization run the tool
to identify and diagnose issues with the Surface device. Successfully running SDT can quickly determine if a
reported issue is caused by failed hardware or user error.
1. Direct the user to install the SDT package from a software distribution point or network share. After it is
installed, you’re ready to guide the user through a series of tests.
2. Begin at the home page, which allows users to enter a description of the issue, and click Continue, as
shown in figure 1.

Figure 1. SDT in desktop mode

3. When SDT indicates the device has the latest updates, click Continue to advance to the catalog of available
tests, as shown in figure 2.
 Figure 2. Select from SDT options
4. You can choose to run all the diagnostic tests. Or, if you already suspect a particular issue such as a faulty
display or a power supply problem, click Select to choose from the available tests and click Run Selected,
as shown in figure 3. See the following table for details of each test.

Figure 3. Select hardware tests

HARDWARE TEST DESCRIPTION

Power Supply and Battery Checks Power supply is functioning optimally

Display and Sound Checks brightness, stuck or dead pixels, speaker and
microphone functioning
 HARDWARE TEST DESCRIPTION

Ports and Accessories Checks accessories, screen attach and USB functioning

Connectivity Checks Bluetooth, wireless and LTE connectivity

Security Checks security related issues

Touch Checks touch related issues

Keyboard and touch Checks integrated keyboard connection and type cover

Sensors Checks functioning of different sensors in the device

Hardware Checks issues with different hardware components such

as graphics card and camera

Running multiple hardware tests to troubleshoot issues

SDT is designed as an interactive tool that runs a series of tests. For each test, SDT provides instructions
summarizing the nature of the test and what users should expect or look for in order for the test to be successful.
For example, to diagnose if the display brightness is working properly, SDT starts at zero and increases the
brightness to 100 percent, asking users to confirm – by answering Yes or No -- that brightness is functioning as
expected, as shown in figure 4.
For each test, if functionality does not work as expected and the user clicks No, SDT generates a report of the
possible causes and ways to troubleshoot it.

Figure 4. Running hardware diagnostics

1. If the brightness successfully adjusts from 0-100 percent as expected, direct the user to click Yes and then click
Continue.
2. If the brightness fails to adjust from 0-100 percent as expected, direct the user to click No and then click
Continue.
3. Guide users through remaining tests as appropriate. When finished, SDT automatically provides a high-level
summary of the report of the possible causes of any hardware issues along with guidance for resolution.
Repairing applications
SDT enables you to diagnose and repair applications that may be causing issues, as shown in figure 5.

Figure 5. Running repairs

Generating logs for analyzing issues
SDT provides extensive log-enabled diagnosis support across applications, drivers, hardware, and operating
system issues, as shown in figure 6.

Figure 6. Generating logs

Generating detailed report comparing device vs. optimal configuration
Based on the logs, SDT generates a report for software- and firmware-based issues that you can save to a
preferred location.

Related topics
Run Surface Diagnostic Toolkit for Business using commands
 Run Surface Diagnostic Toolkit for Business using
commands
11/19/2018 • 3 minutes to read • Edit Online

Running the Surface Diagnostic Toolkit (SDT) at a command prompt requires downloading the STD app console.
After it's installed, you can run SDT at a command prompt via the Windows command console (cmd.exe) or using
Windows PowerShell, including PowerShell Integrated Scripting Environment (ISE ), which provides support for
autocompletion of commands, copy/paste, and other features.

NOTE
To run SDT using commands, you must be signed in to the Administrator account or signed in to an account that is a
member of the Administrator group on your Surface device.

Running SDT app console

Download and install SDT app console from the Surface Tools for IT download page. You can use the Windows
command prompt (cmd.exe) or Windows PowerShell to:
Collect all log files.
Run health diagnostics using Best Practice Analyzer.
Check update for missing firmware or driver updates.
By default, output files are saved to C:\Administrator\user. Refer to the following table for a complete list of
commands.

COMMAND NOTES

-DataCollector "output file" Collects system details into a zip file. "output file" is the file
path to create system details zip file.

Example:
Microsoft.Surface.Diagnostics.App.Console.exe -
DataCollector SDT_DataCollection.zip

-bpa "output file" Checks several settings and health indicators in the device.
“output file" is the file path to create the HTML report.

Example:
Microsoft.Surface.Diagnostics.App.Console.exe -bpa
BPA.html

-windowsupdate Checks Windows Update online servers for missing firmware

and/or driver updates.

Example:
Microsoft.Surface.Diagnostics.App.Console.exe -
windowsupdate
 NOTE
To run the SDT app console remotely on target devices, you can use a configuration management tool such as System
Center Configuration Manager. Alternatively, you can create a .zip file containing the console app and appropriate console
commands and deploy per your organization’s software distribution processes.

Running Best Practice Analyzer

You can run BPA tests across key components such as BitLocker, Secure Boot, and Trusted Platform Module
(TPM ) and then output the results to a shareable file. The tool generates a series of tables with color-coded
headings and condition descriptors along with guidance about how to approach resolving the issue.
Green indicates the component is running in an optimal condition (optimal).
Orange indicates the component is not running in an optimal condition (not optimal).
Red indicates the component is in an abnormal state.
Sample BPA results output
BITLOCKER

Description: Checks if BitLocker is enabled on the system drive.

Value: Protection On

Condition: Optimal

Guidance: It is highly recommended to enable BitLocker to protect your

data.

SECURE BOOT

Description: Checks if Secure Boot is enabled.

Value: True

Condition: Optimal

Guidance: It is highly recommended to enable Secure Boot to protect

your PC.

TRUSTED PLATFORM MODULE

Description: Ensures that the TPM is functional.

Value: True

Condition: Optimal

Guidance: Without a functional TPM, security-based functions such as

BitLocker may not work properly.

CONNECTED STANDBY
Description: Checks if Connected Standby is enabled.

Value: True

Condition: Optimal

Guidance: Connected Standby allows a Surface device to receive updates

and notifications while not being used. For best experience,
Connected Standby should be enabled.

BLUETOOTH

Description: Checks if Bluetooth is enabled.

Value: Enabled

Condition: Optimal

Guidance:

DEBUG MODE

Description: Checks if the operating system is in Debug mode.

Value: Normal

Condition: Optimal

Guidance: The debug boot option enables or disables kernel debugging

of the Windows operating system. Enabling this option can
cause system instability and can prevent DRM (digital rights
managemend) protected media from playing.

TEST SIGNING

Description: Checks if Test Signing is enabled.

Value: Normal

Condition: Optimal

Guidance: Test Signing is a Windows startup setting that should only be

used to test pre-release drivers.

ACTIVE POWER PLAN

Description: Checks that the correct power plan is active.

Value: Balanced

Condition: Optimal
Guidance: It is highly recommended to use the "Balanced" power plan to
maximize productivity and battery life.

WINDOWS UPDATE

Description: Checks if the device is up to date with Windows updates.

Value: Microsoft Silverlight (KB4023307), Definition Update for

Windows Defender Antivirus - KB2267602 (Definition
1.279.1433.0)

Condition: Not Optimal

Guidance: Updating to the latest windows makes sure you are on the
latest firmware and drivers. It is recommended to always keep
your device up to date

FREE HARD DRIVE SPACE

Description: Checks for low free hard drive space.

Value: 66%

Condition: Optimal

Guidance: For best performance, your hard drive should have at least
10% of its capacity as free space.

NON-FUNCTIONING DEVICES

Description: List of non-functioning devices in Device Manager.

Value:

Condition: Optimal

Guidance: Non-functioning devices in Device Manager may cause

unpredictable problems with Surface devices such as, but not
limited to, no power savings for the respective hardware
component.

EX TERNAL MONITOR

Description: Checks for an external monitor that may have compatibility

issues.

Value:

Condition: Optimal

Guidance: Check with the original equipment manufacturer for

compatibility with your Surface device.
 Microsoft Surface Data Eraser
10/29/2018 • 6 minutes to read • Edit Online

Find out how the Microsoft Surface Data Eraser tool can help you securely wipe data from your Surface devices.
Microsoft Surface Data Eraser is a tool that boots from a USB stick and allows you to perform a secure wipe of all
data from a compatible Surface device. A Microsoft Surface Data Eraser USB stick requires only the ability to boot
from USB. The USB stick is easy to create by using the provided wizard, the Microsoft Surface Data Eraser
wrapper, and is easy to use with a simple graphic interface, no command line needed. To learn more about the data
wiping capabilities and practices Microsoft uses during the service process for Surface, see Protecting your data if
you send your Surface in for service.

IMPORTANT
Microsoft Surface Data Eraser uses the NVM Express (NVMe) format command to erase data as authorized in NIST Special
Publication 800-88 Revision 1.

Compatible Surface devices include:

Surface Pro 6
Surface Laptop 2
Surface Go
Surface Book 2
Surface Pro with LTE Advanced (Model 1807)
Surface Pro (Model 1796)
Surface Laptop
Surface Studio
Surface Book
Surface Pro 4
Surface 3 LTE
Surface 3
Surface Pro 3
Surface Pro 2
Some scenarios where Microsoft Surface Data Eraser can be helpful include:
Prepare a Surface device to be sent for repair
Decommission a Surface device to be removed from corporate or organizational use
Repurpose a Surface device for use in a new department or for use by a new user
Standard practice when performing reimaging for devices used with sensitive data

NOTE
Third-party devices, Surface devices running Windows RT (including Surface and Surface 2), and Surface Pro are not
compatible with Microsoft Surface Data Eraser.
 NOTE
Because the ability to boot to USB is required to run Microsoft Surface Data Eraser, if the device is not configured to boot
from USB or if the device is unable to boot or POST successfully, the Microsoft Surface Data Eraser tool will not function.

How to create a Microsoft Surface Data Eraser USB stick

To create a Microsoft Surface Data Eraser USB stick, first install the Microsoft Surface Data Eraser setup tool from
the Microsoft Download Center using the link provided at the beginning of this article. You do not need a Surface
device to create the USB stick. After you have downloaded the installation file to your computer, follow these steps
to install the Microsoft Surface Data Eraser creation tool:
1. Run the DataEraserSetup.msi installation file that you downloaded from the Microsoft Download Center.
2. Select the check box to accept the terms of the license agreement, and then click Install.
3. Click Finish to close the Microsoft Surface Data Eraser setup window.
After the creation tool is installed, follow these steps to create a Microsoft Surface Data Eraser USB stick. Before
you begin these steps, ensure that you have a USB 3.0 stick that is 4 GB or larger connected to the computer.
1. Start Microsoft Surface Data Eraser from the Start menu or Start screen.
2. Click Build to begin the Microsoft Surface Data Eraser USB creation process.
3. Click Start to acknowledge that you have a USB stick of at least 4 GB connected, as shown in Figure 1.

Figure 1. Start the Microsoft Surface Data Eraser tool

4. Select the USB drive of your choice from the USB Thumb Drive Selection page as shown in Figure 2,
and then click Start to begin the USB creation process. The drive you select will be formatted and any
existing data on this drive will be lost.
 NOTE
If the Start button is disabled, check that your removable drive has a total capacity of at least 4 GB.

Figure 2. USB thumb drive selection

5. After the creation process is finished, the USB drive has been formatted and all binaries are copied to the
USB drive. Click Success.
6. When the Congratulations screen is displayed, you can eject and remove the thumb drive. This thumb
drive is now ready to be inserted into a Surface device, booted from, and wipe any data on the device. Click
Complete to finish the USB creation process, as shown in Figure 3.
 Figure 3. Complete the Microsoft Surface Data Eraser USB creation process
7. Click X to close Microsoft Surface Data Eraser.

How to use a Microsoft Surface Data Eraser USB stick

After you create a Microsoft Surface Data Eraser USB stick, you can boot a supported Surface device from the
USB stick by following this procedure:
1. Insert the bootable Microsoft Surface Data Eraser USB stick into the supported Surface device.
2. Boot your Surface device from the Microsoft Surface Data Eraser USB stick. To boot your device from the
USB stick follow these steps:
a. Turn off your Surface device.
b. Press and hold the Volume Down button.
c. Press and release the Power button.
d. Release the Volume Down button.

NOTE
If your device does not boot to USB using these steps, you may need to turn on the Enable Alternate Boot
Sequence option in Surface UEFI. You can read more about Surface UEFI boot configuration in Manage Surface UEFI
Settings.

3. When the Surface device boots, a SoftwareLicenseTerms text file is displayed, as shown in Figure 4.
 Figure 4. Booting the Microsoft Surface Data Eraser USB stick
4. Read the software license terms, and then close the Notepad file.
5. Accept or decline the software license terms by typing Accept or Decline. You must accept the license
terms to continue.
6. The Microsoft Surface Data Eraser script detects the storage devices that are present in your Surface device
and displays the details of the native storage device. To continue, press Y (this action runs Microsoft Surface
Data Eraser and removes all data from the storage device) or press N (this action shuts down the device
without removing data).

NOTE
The Microsoft Surface Data Eraser tool will delete all data, including Windows operating system files required to boot
the device, in a secure and unrecoverable way. To boot a Surface device that has been wiped with Microsoft Surface
Data Eraser, you will first need to reinstall the Windows operating system. To remove data from a Surface device
without removing the Windows operating system, you can use the Reset your PC function. However, this does not
prevent your data from being recovered with forensic or data recovery capabilities. See Recovery options in Windows
10 for more information.
 Figure 5. Partition to be erased is displayed in Microsoft Surface Data Eraser
7. If you pressed Y in step 6, due to the destructive nature of the data erasure process, an additional dialog
box is displayed to confirm your choice.
8. Click the Yes button to continue erasing data on the Surface device.

NOTE
When you run Surface Data Eraser on the Surface Data Eraser USB drive, a log file is generated in the
SurfaceDataEraserLogs folder.

Changes and updates

Microsoft Surface Data Eraser is periodically updated by Microsoft. For information about the changes provided
in each new version, see the following:
Version 3.2.69.0
Release Date: 12 October 2018
This version of Surface Data Eraser adds support for the following:
Surface Pro 6
Surface Laptop 2
Version 3.2.68.0
This version of Microsoft Surface Data Eraser adds support for the following:
Surface Go
Version 3.2.58.0
This version of Microsoft Surface Data Eraser adds support for the following:
Additional storage devices (drives) for Surface Pro and Surface Laptop devices
Version 3.2.46.0
This version of Microsoft Surface Data Eraser adds support for the following:
 Surface Pro with LTE Advanced
Version 3.2.45.0
This version of Microsoft Surface Data Eraser adds support for the following:
Surface Book 2
Surface Pro 1TB

NOTE
Surface Data Eraser v3.2.45.0 and above can be used to restore Surface Pro or Surface Laptop devices with the 1TB storage
option in the scenario that the device shows two separate 512GB volumes or encounters errors when attempting to deploy
or install Windows 10. See Surface Pro Model 1796 and Surface Laptop 1TB display two drives for more information.

Version 3.2.36.0
This version of Microsoft Surface Data Eraser adds support for the following:
Surface Pro
Surface Laptop

NOTE
The Microsoft Surface Data Eraser USB drive creation tool is unable to run on Windows 10 S. To wipe a Surface Laptop
running Windows 10 S, you must first create the Microsoft Surface Data Eraser USB drive on another computer with
Windows 10 Pro or Windows 10 Enterprise.
 Top support solutions for Surface devices
5/10/2018 • 2 minutes to read • Edit Online

Microsoft regularly releases both updates and solutions for Surface devices. To ensure your devices can receive
future updates, including security updates, it's important to keep your Surface devices updated. For a complete
listing of the update history, see Surface update history and Install Surface and Windows updates.
These are the top Microsoft Support solutions for common issues experienced when using Surface devices in an
enterprise.

Screen cracked or scratched issues

Cracked screen and physical damage

Device cover or keyboard issues

Troubleshoot your Surface Type Cover or keyboard
Troubleshoot problems with Surface Keyboard, Surface Ergonomic Keyboard, and Microsoft Modern Keyboard
with Fingerprint ID
Set up Microsoft Modern Keyboard with Fingerprint ID
Enabling Surface Laptop keyboard during MDT deployment

Device won't wake from sleep or hibernation issues

Surface won’t turn on or wake from sleep
Surface Pro 4 or Surface Book doesn't hibernate in Windows 10
Surface Pro 3 doesn't hibernate after four hours in connected standby
Surface Pro 3 Hibernation Doesn’t Occur on Enterprise Install

Other common issues

Trouble installing Surface updates
Troubleshooting common Surface Pro 3 issues post-deployment
Surface Pro 3 hibernation doesn't occur on enterprise install
Reusing the same NIC for multiple PXE initiated deployments in System Center Configuration Manger OSD
Troubleshoot docking stations for Surface Pro and Surface 3
What to do if Surface is running slower
 Change history for Surface documentation
11/19/2018 • 2 minutes to read • Edit Online

This topic lists new and updated topics in the Surface documentation library.

November 2018
NEW OR CHANGED TOPIC DESCRIPTION

Download the latest firmware and drivers for Surface devices Added Surface Pro 6

Surface Diagnostic Toolkit for Business New

Use Surface Diagnostic Toolkit for Business in desktop mode New

Run Surface Diagnostic Toolkit for Business using commands New

October 2018
NEW OR CHANGED TOPIC DESCRIPTION

Battery Limit setting New

Download the latest firmware and drivers for Surface devices Added Surface GO

May 2018
NEW OR CHANGED TOPIC DESCRIPTION

Microsoft Surface Data Eraser Added version 3.2.58.0 information

Surface device compatibility with Windows 10 Long-Term Removed note box around content
Servicing Channel (LTSC)

February 2018
NEW OR CHANGED TOPIC DESCRIPTION

Surface Dock Updater Added version 2.12.136.0 information

Microsoft Surface Data Eraser Added version 3.2.46.0 information

January 2018
 NEW OR CHANGED TOPIC DESCRIPTION

Windows Autopilot and Surface devices New article

Microsoft Surface Data Eraser Added version 3.2.45.0 information

Surface device compatibility with Windows 10 Long-Term Updated Current Branch (CB) or Current Branch for Business
Servicing Channel (LTSC) (CBB) servicing options with Semi-Annual Channel (SAC)
information

Wake On LAN for Surface devices Added Surface Book 2, Surface Laptop, Surface Pro, Surface
Pro with LTE Advanced, and Surface Pro information

December 2017
NEW OR CHANGED TOPIC DESCRIPTION

Download the latest firmware and drivers for Surface devices Added Surface Book 2, Surface Laptop, Surface Pro, and
Surface Pro with LTE Advanced information

November 2017
NEW OR CHANGED TOPIC DESCRIPTION

Surface Dock Updater Added version 2.7.136.0 information

October 2017
NEW OR CHANGED TOPICS DESCRIPTION

Microsoft Surface Diagnostic Toolkit Topic removed. The Microsoft Surface Diagnostic Toolkit is no
longer available for download.

September 2017
NEW OR CHANGED TOPIC DESCRIPTION

Top support solutions for Surface devices New

June 2017
NEW OR CHANGED TOPIC DESCRIPTION

Surface Data Eraser Update compatible devices, added version 3.2.36 information

Surface Deployment Accelerator Added version 2.0.8.0 information

Surface Dock Updater Added version 2.1.15.0 information

April 2017
NEW OR CHANGED TOPIC DESCRIPTION

Surface device compatibility with Windows 10 Long-Term New (supersedes Long-Term Servicing Branch for Surface
Servicing Branch devices)

January 2017
NEW OR CHANGED TOPIC DESCRIPTION

Wake On LAN for Surface devices New

December 2016
NEW OR CHANGED TOPIC DESCRIPTION

Download the latest firmware and drivers for Surface devices Added driver info for Surface Studio; updated info for Surface
Book and Surface Pro 4 (Windows 10 .zip cumulative update),
Surface Pro 3 (Windows8.1-KB2969817-x64.msu), and Surface
3 (UEFI Asset Tag management tool)

November 2016
NEW OR CHANGED TOPIC DESCRIPTION

Surface Enterprise Management Mode Added procedure for viewing certificate thumbprint.

Use System Center Configuration Manager to manage devices New

with SEMM

October 2016
NEW OR CHANGED TOPIC DESCRIPTION

Considerations for Surface and System Center Configuration New

Manager

Long-term servicing branch for Surface devices New