Contents

Information protection
BitLocker
Overview of BitLocker Device Encryption in Windows 10
BitLocker frequently asked questions (FAQ)
Overview and requirements
Upgrading
Deployment and administration
Key management
BitLocker To Go
Active Directory Domain Services
Security
BitLocker Network Unlock
General
Prepare your organization for BitLocker: Planning and policies
BitLocker basic deployment
BitLocker: How to deploy on Windows Server 2012 and later
BitLocker: Management for enterprises
BitLocker: How to enable Network Unlock
BitLocker: Use BitLocker Drive Encryption Tools to manage BitLocker
BitLocker: Use BitLocker Recovery Password Viewer
BitLocker Group Policy settings
BCD settings and BitLocker
BitLocker Recovery Guide
BitLocker Countermeasures
Protecting cluster shared volumes and storage area networks with BitLocker
Encrypted Hard Drive
Kernel DMA Protection for Thunderbolt™ 3
Protect your enterprise data using Windows Information Protection (WIP)
Create a WIP policy using Microsoft Intune
 Create a WIP policy using the classic console for Microsoft Intune
Deploy your WIP policy using the classic console for Microsoft Intune
Associate and deploy a VPN policy for WIP using the classic console for
Microsoft Intune
Create a WIP policy with MDM using the Azure portal for Microsoft Intune
Deploy your WIP policy using the Azure portal for Microsoft Intune
Associate and deploy a VPN policy for WIP using the Azure portal for Microsoft
Intune
Create a WIP policy with MAM using the Azure portal for Microsoft Intune
Create a WIP policy using System Center Configuration Manager
Create and deploy a WIP policy using System Center Configuration Manager
Create and verify an EFS Data Recovery Agent (DRA) certificate
Determine the Enterprise Context of an app running in WIP
Mandatory tasks and settings required to turn on WIP
Testing scenarios for WIP
Limitations while using WIP
How to collect WIP audit event logs
General guidance and best practices for WIP
Enlightened apps for use with WIP
Unenlightened and enlightened app behavior while using WIP
Recommended Enterprise Cloud Resources and Neutral Resources network
settings with WIP
Using Outlook Web Access with WIP
Fine-tune WIP Learning
How WIP works with sensitivity labels
Secure the Windows 10 boot process
Trusted Platform Module
Trusted Platform Module Overview
TPM fundamentals
How Windows 10 uses the TPM
TPM Group Policy settings
Back up the TPM recovery information to AD DS
View status, clear, or troubleshoot the TPM
Understanding PCR banks on TPM 2.0 devices
TPM recommendations
 Information protection
10/10/2018 • 2 minutes to read • Edit Online

Learn more about how to secure documents and other data across your organization.

SECTION DESCRIPTION

BitLocker Provides information about BitLocker, which is a data

protection feature that integrates with the operating system
and addresses the threats of data theft or exposure from lost,
stolen, or inappropriately decommissioned computers.

Encrypted Hard Drive Encrypted Hard Drive uses the rapid encryption that is
provided by BitLocker Drive Encryption to enhance data
security and management.

Kernel DMA Protection for Thunderbolt™ 3 Kernel DMA Protection protects PCs against drive-by Direct
Memory Access (DMA) attacks using PCI hot plug devices
connected to Thunderbolt™ 3 ports.

Protect your enterprise data using Windows Information Provides info about how to create a Windows Information
Protection (WIP) Protection policy that can help protect against potential
corporate data leakage.

Secure the Windows 10 boot process Windows 10 supports features to help prevent rootkits and
bootkits from loading during the startup process.

Trusted Platform Module Trusted Platform Module (TPM) technology is designed to

provide hardware-based, security-related functions. A TPM
chip is a secure crypto-processor that helps you with actions
such as generating, storing, and limiting the use of
cryptographic keys.
 BitLocker
1/28/2019 • 6 minutes to read • Edit Online

Applies to
Windows 10
This topic provides a high-level overview of BitLocker, including a list of system requirements, practical
applications, and deprecated features.

BitLocker overview
BitLocker Drive Encryption is a data protection feature that integrates with the operating system and addresses
the threats of data theft or exposure from lost, stolen, or inappropriately decommissioned computers.
BitLocker provides the most protection when used with a Trusted Platform Module (TPM ) version 1.2 or later. The
TPM is a hardware component installed in many newer computers by the computer manufacturers. It works with
BitLocker to help protect user data and to ensure that a computer has not been tampered with while the system
was offline.
On computers that do not have a TPM version 1.2 or later, you can still use BitLocker to encrypt the Windows
operating system drive. However, this implementation will require the user to insert a USB startup key to start
the computer or resume from hibernation. Starting with Windows 8, you can use an operating system volume
password to protect the operating system volume on a computer without TPM. Both options do not provide the
pre-startup system integrity verification offered by BitLocker with a TPM.
In addition to the TPM, BitLocker offers the option to lock the normal startup process until the user supplies a
personal identification number (PIN ) or inserts a removable device, such as a USB flash drive, that contains a
startup key. These additional security measures provide multifactor authentication and assurance that the
computer will not start or resume from hibernation until the correct PIN or startup key is presented.

Practical applications
Data on a lost or stolen computer is vulnerable to unauthorized access, either by running a software-attack tool
against it or by transferring the computer's hard disk to a different computer. BitLocker helps mitigate
unauthorized data access by enhancing file and system protections. BitLocker also helps render data inaccessible
when BitLocker-protected computers are decommissioned or recycled.
There are two additional tools in the Remote Server Administration Tools, which you can use to manage
BitLocker.
BitLocker Recovery Password Viewer. The BitLocker Recovery Password Viewer enables you to locate
and view BitLocker Drive Encryption recovery passwords that have been backed up to Active Directory
Domain Services (AD DS ). You can use this tool to help recover data that is stored on a drive that has been
encrypted by using BitLocker. The BitLocker Recovery Password Viewer tool is an extension for the Active
Directory Users and Computers Microsoft Management Console (MMC ) snap-in. By using this tool, you
can examine a computer object's Properties dialog box to view the corresponding BitLocker recovery
passwords. Additionally, you can right-click a domain container and then search for a BitLocker recovery
password across all the domains in the Active Directory forest. To view recovery passwords, you must be a
domain administrator, or you must have been delegated permissions by a domain administrator.
BitLocker Drive Encryption Tools. BitLocker Drive Encryption Tools include the command-line tools,
 manage-bde and repair-bde, and the BitLocker cmdlets for Windows PowerShell. Both manage-bde and
the BitLocker cmdlets can be used to perform any task that can be accomplished through the BitLocker
control panel, and they are appropriate to use for automated deployments and other scripting scenarios.
Repair-bde is provided for disaster recovery scenarios in which a BitLocker protected drive cannot be
unlocked normally or by using the recovery console.

New and changed functionality

To find out what's new in BitLocker for Windows 10, such as support for the XTS -AES encryption algorithm, see
the BitLocker section in "What's new in Windows 10."

System requirements
BitLocker has the following hardware requirements:
For BitLocker to use the system integrity check provided by a Trusted Platform Module (TPM ), the computer must
have TPM 1.2 or later. If your computer does not have a TPM, enabling BitLocker requires that you save a startup
key on a removable device, such as a USB flash drive.
A computer with a TPM must also have a Trusted Computing Group (TCG )-compliant BIOS or UEFI firmware.
The BIOS or UEFI firmware establishes a chain of trust for the pre-operating system startup, and it must include
support for TCG -specified Static Root of Trust Measurement. A computer without a TPM does not require TCG -
compliant firmware.
The system BIOS or UEFI firmware (for TPM and non-TPM computers) must support the USB mass storage
device class, including reading small files on a USB flash drive in the pre-operating system environment.
The hard disk must be partitioned with at least two drives:
The operating system drive (or boot drive) contains the operating system and its support files. It must be
formatted with the NTFS file system.
The system drive contains the files that are needed to load Windows after the firmware has prepared the
system hardware. BitLocker is not enabled on this drive. For BitLocker to work, the system drive must not be
encrypted, must differ from the operating system drive, and must be formatted with the FAT32 file system on
computers that use UEFI-based firmware or with the NTFS file system on computers that use BIOS firmware.
We recommend that system drive be approximately 350 MB in size. After BitLocker is turned on it should have
approximately 250 MB of free space.
When installed on a new computer, Windows will automatically create the partitions that are required for
BitLocker.
When installing the BitLocker optional component on a server you will also need to install the Enhanced Storage
feature, which is used to support hardware encrypted drives.

In this section
TOPIC DESCRIPTION

Overview of BitLocker Device Encryption in Windows 10 This topic for the IT professional provides an overview of the
ways that BitLocker Device Encryption can help protect data
on devices running Windows 10.

BitLocker frequently asked questions (FAQ) This topic for the IT professional answers frequently asked
questions concerning the requirements to use, upgrade,
deploy and administer, and key management policies for
BitLocker.
TOPIC DESCRIPTION

Prepare your organization for BitLocker: Planning and policies This topic for the IT professional explains how can you plan
your BitLocker deployment.

BitLocker basic deployment This topic for the IT professional explains how BitLocker
features can be used to protect your data through drive
encryption.

BitLocker: How to deploy on Windows Server This topic for the IT professional explains how to deploy
BitLocker on Windows Server.

BitLocker: How to enable Network Unlock This topic for the IT professional describes how BitLocker
Network Unlock works and how to configure it.

BitLocker: Use BitLocker Drive Encryption Tools to manage This topic for the IT professional describes how to use tools to
BitLocker manage BitLocker.

BitLocker: Use BitLocker Recovery Password Viewer This topic for the IT professional describes how to use the
BitLocker Recovery Password Viewer.

BitLocker Group Policy settings This topic for IT professionals describes the function, location,
and effect of each Group Policy setting that is used to
manage BitLocker.

BCD settings and BitLocker This topic for IT professionals describes the BCD settings that
are used by BitLocker.

BitLocker Recovery Guide This topic for IT professionals describes how to recover
BitLocker keys from AD DS.

Protect BitLocker from pre-boot attacks This detailed guide will help you understand the
circumstances under which the use of pre-boot
authentication is recommended for devices running Windows
10, Windows 8.1, Windows 8, or Windows 7; and when it can
be safely omitted from a device’s configuration.

Protecting cluster shared volumes and storage area networks This topic for IT pros describes how to protect CSVs and SANs
with BitLocker with BitLocker.

Enabling Secure Boot and BitLocker Device Encryption on This topic covers how to use BitLocker with Windows 10 IoT
Windows 10 IoT Core Core
 Overview of BitLocker Device Encryption in Windows
10
1/11/2019 • 13 minutes to read • Edit Online

Applies to
Windows 10
This topic explains how BitLocker Device Encryption can help protect data on devices running Windows 10. For an
architectural overview about how BitLocker Device Encryption works with Secure Boot, see Secure boot and
BitLocker Device Encryption overview. For a general overview and list of topics about BitLocker, see BitLocker.
When users travel, their organization’s confidential data goes with them. Wherever confidential data is stored, it
must be protected against unauthorized access. Windows has a long history of providing at-rest data-protection
solutions that guard against nefarious attackers, beginning with the Encrypting File System in the Windows 2000
operating system. More recently, BitLocker has provided encryption for full drives and portable drives. Windows
consistently improves data protection by improving existing options and by providing new strategies.
Table 2 lists specific data-protection concerns and how they are addressed in Windows 10 and Windows 7.
Table 2. Data Protection in Windows 10 and Windows 7

WINDOWS 7 WINDOWS 10

When BitLocker is used with a PIN to protect startup, PCs Modern Windows devices are increasingly protected with
such as kiosks cannot be restarted remotely. BitLocker Device Encryption out of the box and support SSO
to seamlessly protect the BitLocker encryption keys from cold
boot attacks.

Network Unlock allows PCs to start automatically when

connected to the internal network.

When BitLocker is enabled, the provisioning process can take BitLocker pre-provisioning, encrypting hard drives, and Used
several hours. Space Only encryption allow administrators to enable
BitLocker quickly on new computers.

There is no support for using BitLocker with self-encrypting BitLocker supports offloading encryption to encrypted hard
drives (SEDs). drives.

Administrators have to use separate tools to manage BitLocker supports encrypted hard drives with onboard
encrypted hard drives. encryption hardware built in, which allows administrators to
use the familiar BitLocker administrative tools to manage
them.

Encrypting a new flash drive can take more than 20 minutes. Used Space Only encryption in BitLocker To Go allows users
to encrypt removable data drives in seconds.

BitLocker could require users to enter a recovery key when BitLocker requires the user to enter a recovery key only when
system configuration changes occur. disk corruption occurs or when he or she loses the PIN or
password.
 WINDOWS 7 WINDOWS 10

Users need to enter a PIN to start the PC, and then their Modern Windows devices are increasingly protected with
password to sign in to Windows. BitLocker Device Encryption out of the box and support SSO
to help protect the BitLocker encryption keys from cold boot
attacks.

Prepare for drive and file encryption

The best type of security measures are transparent to the user during implementation and use. Every time there is
a possible delay or difficulty because of a security feature, there is strong likelihood that users will try to bypass
security. This situation is especially true for data protection, and that’s a scenario that organizations need to avoid.
Whether you’re planning to encrypt entire volumes, removable devices, or individual files, Windows 10 meets
your needs by providing streamlined, usable solutions. In fact, you can take several steps in advance to prepare for
data encryption and make the deployment quick and smooth.
TPM pre -provisioning
In Windows 7, preparing the TPM for use offered a couple of challenges:
You can turn on the TPM in the BIOS, which requires someone to either go into the BIOS settings to turn it on
or to install a driver to turn it on from within Windows.
When you enable the TPM, it may require one or more restarts.
Basically, it was a big hassle. If IT staff were provisioning new PCs, they could handle all of this, but if you wanted
to add BitLocker to devices that were already in users’ hands, those users would have struggled with the technical
challenges and would either call IT for support or simply leave BitLocker disabled.
Microsoft includes instrumentation in Windows 10 that enables the operating system to fully manage the TPM.
There is no need to go into the BIOS, and all scenarios that required a restart have been eliminated.

Deploy hard drive encryption

BitLocker is capable of encrypting entire hard drives, including both system and data drives. BitLocker pre-
provisioning can drastically reduce the time required to provision new PCs with BitLocker enabled. With Windows
10, administrators can turn on BitLocker and the TPM from within the Windows Preinstallation Environment
before they install Windows or as part of an automated deployment task sequence without any user interaction.
Combined with Used Disk Space Only encryption and a mostly empty drive (because Windows is not yet
installed), it takes only a few seconds to enable BitLocker. With earlier versions of Windows, administrators had to
enable BitLocker after Windows had been installed. Although this process could be automated, BitLocker would
need to encrypt the entire drive, a process that could take anywhere from several hours to more than a day
depending on drive size and performance, which significantly delayed deployment. Microsoft has improved this
process through multiple features in Windows 10.

BitLocker Device Encryption

Beginning in Windows 8.1, Windows automatically enables BitLocker Device Encryption on devices that support
Modern Standby. With Windows 10, Microsoft offers BitLocker Device Encryption support on a much broader
range of devices, including those that are Modern Standby, and devices that run Windows 10 Home edition.
Microsoft expects that most devices in the future will pass the testing requirements, which makes BitLocker Device
Encryption pervasive across modern Windows devices. BitLocker Device Encryption further protects the system
by transparently implementing device-wide data encryption.
Unlike a standard BitLocker implementation, BitLocker Device Encryption is enabled automatically so that the
device is always protected. The following list outlines how this happens:
 When a clean installation of Windows 10 is completed and the out-of-box experience is finished, the computer
is prepared for first use. As part of this preparation, BitLocker Device Encryption is initialized on the operating
system drive and fixed data drives on the computer with a clear key (this is the equivalent of standard BitLocker
suspended state). In this state, the drive is shown with a warning icon in Windows Explorer. The yellow warning
icon is removed after the TPM protector is created and the recovery key is backed up, as explained in the
following bullet points.
If the device is not domain joined, a Microsoft account that has been granted administrative privileges on the
device is required. When the administrator uses a Microsoft account to sign in, the clear key is removed, a
recovery key is uploaded to the online Microsoft account, and a TPM protector is created. Should a device
require the recovery key, the user will be guided to use an alternate device and navigate to a recovery key
access URL to retrieve the recovery key by using his or her Microsoft account credentials.
If the user uses a domain account to sign in, the clear key is not removed until the user joins the device to a
domain and the recovery key is successfully backed up to Active Directory Domain Services (AD DS ). You must
enable the Computer Configuration\Administrative Templates\Windows Components\BitLocker
Drive Encryption\Operating System Drives Group Policy setting, and select the Do not enable BitLocker
until recovery information is stored in AD DS for operating system drives option. With this
configuration, the recovery password is created automatically when the computer joins the domain, and then
the recovery key is backed up to AD DS, the TPM protector is created, and the clear key is removed.
Similar to signing in with a domain account, the clear key is removed when the user logs on to an Azure AD
account on the device. As described in the bullet point above, the recovery password is created automatically
when the user authenticates to Azure AD. Then, the recovery key is backed up to Azure AD, the TPM protector
is created, and the clear key is removed.
Microsoft recommends that BitLocker Device Encryption be enabled on any systems that support it, but the
automatic BitLocker Device Encryption process can be prevented by changing the following registry setting:
Subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BitLocker
Value: PreventDeviceEncryption equal to True (1)
Type: REG_DWORD
Administrators can manage domain-joined devices that have BitLocker Device Encryption enabled through
Microsoft BitLocker Administration and Monitoring (MBAM ). In this case, BitLocker Device Encryption
automatically makes additional BitLocker options available. No conversion or encryption is required, and MBAM
can manage the full BitLocker policy set if any configuration changes are required.

Used Disk Space Only encryption

BitLocker in earlier Windows versions could take a long time to encrypt a drive, because it encrypted every byte
on the volume (including parts that did not have data). That is still the most secure way to encrypt a drive,
especially if a drive has previously contained confidential data that has since been moved or deleted. In that case,
traces of the confidential data could remain on portions of the drive marked as unused. But why encrypt a new
drive when you can simply encrypt the data as it is being written? To reduce encryption time, BitLocker in
Windows 10 lets users choose to encrypt just their data. Depending on the amount of data on the drive, this
option can reduce encryption time by more than 99 percent. Exercise caution when encrypting only used space on
an existing volume on which confidential data may have already been stored in an unencrypted state, however,
because those sectors can be recovered through disk-recovery tools until they are overwritten by new encrypted
data. In contrast, encrypting only used space on a brand-new volume can significantly decrease deployment time
without the security risk because all new data will be encrypted as it is written to the disk.

Encrypted hard drive support

SEDs have been available for years, but Microsoft couldn’t support their use with some earlier versions of
Windows because the drives lacked important key management features. Microsoft worked with storage vendors
to improve the hardware capabilities, and now BitLocker supports the next generation of SEDs, which are called
encrypted hard drives. Encrypted hard drives provide onboard cryptographic capabilities to encrypt data on drives,
which improves both drive and system performance by offloading cryptographic calculations from the PC’s
processor to the drive itself and rapidly encrypting the drive by using dedicated, purpose-built hardware. If you
plan to use whole-drive encryption with Windows 10, Microsoft recommends that you investigate hard drive
manufacturers and models to determine whether any of their encrypted hard drives meet your security and
budget requirements. For more information about encrypted hard drives, see Encrypted Hard Drive.

Preboot information protection

An effective implementation of information protection, like most security controls, considers usability as well as
security. Users typically prefer a simple security experience. In fact, the more transparent a security solution
becomes, the more likely users are to conform to it. It is crucial that organizations protect information on their PCs
regardless of the state of the computer or the intent of users. This protection should not be cumbersome to users.
One undesirable and previously commonplace situation is when the user is prompted for input during preboot,
and then again during Windows logon. Challenging users for input more than once should be avoided. Windows
10 can enable a true SSO experience from the preboot environment on modern devices and in some cases even
on older devices when robust information protection configurations are in place. The TPM in isolation is able to
securely protect the BitLocker encryption key while it is at rest, and it can securely unlock the operating system
drive. When the key is in use and thus in memory, a combination of hardware and Windows capabilities can
secure the key and prevent unauthorized access through cold-boot attacks. Although other countermeasures like
PIN -based unlock are available, they are not as user-friendly; depending on the devices’ configuration they may
not offer additional security when it comes to key protection. For more information, see BitLocker
Countermeasures.

Manage passwords and PINs

When BitLocker is enabled on a system drive and the PC has a TPM, you can choose to require that users type a
PIN before BitLocker will unlock the drive. Such a PIN requirement can prevent an attacker who has physical
access to a PC from even getting to the Windows logon, which makes it virtually impossible for the attacker to
access or modify user data and system files.
Requiring a PIN at startup is a useful security feature because it acts as a second authentication factor (a second
“something you know”). This configuration comes with some costs, however. One of the most significant is the
need to change the PIN regularly. In enterprises that used BitLocker with Windows 7 and the Windows Vista
operating system, users had to contact systems administrators to update their BitLocker PIN or password. This
requirement not only increased management costs but made users less willing to change their BitLocker PIN or
password on a regular basis. Windows 10 users can update their BitLocker PINs and passwords themselves,
without administrator credentials. Not only will this feature reduce support costs, but it could improve security,
too, because it encourages users to change their PINs and passwords more often. In addition, Modern Standby
devices do not require a PIN for startup: They are designed to start infrequently and have other mitigations in
place that further reduce the attack surface of the system. For more information about how startup security works
and the countermeasures that Windows 10 provides, see Protect BitLocker from pre-boot attacks.

Configure Network Unlock

Some organizations have location-specific data security requirements. This is most common in environments
where high-value data is stored on PCs. The network environment may provide crucial data protection and
enforce mandatory authentication; therefore, policy states that those PCs should not leave the building or be
disconnected from the corporate network. Safeguards like physical security locks and geofencing may help
enforce this policy as reactive controls. Beyond these, a proactive security control that grants data access only
when the PC is connected to the corporate network is necessary.
Network Unlock enables BitLocker-protected PCs to start automatically when connected to a wired corporate
network on which Windows Deployment Services runs. Anytime the PC is not connected to the corporate
network, a user must type a PIN to unlock the drive (if PIN -based unlock is enabled). Network Unlock requires the
following infrastructure:
Client PCs that have Unified Extensible Firmware Interface (UEFI) firmware version 2.3.1 or later, which
supports Dynamic Host Configuration Protocol (DHCP )
A server running at least Windows Server 2012 with the Windows Deployment Services role
A server with the DHCP server role installed
For more information about how to configure Network Unlock, see BitLocker: How to enable Network Unlock.

Microsoft BitLocker Administration and Monitoring

Part of the Microsoft Desktop Optimization Pack, MBAM makes it easier to manage and support BitLocker and
BitLocker To Go. MBAM 2.5 with Service Pack 1, the latest version, has the following key features:
Enables administrators to automate the process of encrypting volumes on client computers across the
enterprise.
Enables security officers to quickly determine the compliance state of individual computers or even of the
enterprise itself.
Provides centralized reporting and hardware management with Microsoft System Center Configuration
Manager.
Reduces the workload on the help desk to assist end users with BitLocker recovery requests.
Enables end users to recover encrypted devices independently by using the Self-Service Portal.
Enables security officers to easily audit access to recovery key information.
Empowers Windows Enterprise users to continue working anywhere with the assurance that their corporate
data is protected.
Enforces the BitLocker encryption policy options that you set for your enterprise.
Integrates with existing management tools, such as System Center Configuration Manager.
Offers an IT-customizable recovery user experience.
Supports Windows 10.
For more information about MBAM, including how to obtain it, see Microsoft BitLocker Administration and
Monitoring on the MDOP TechCenter.
 BitLocker frequently asked questions (FAQ)
6/28/2018 • 2 minutes to read • Edit Online

Applies to
Windows 10
This topic links to frequently asked questions about BitLocker. BitLocker is a data protection feature that encrypts
drives on your computer to help prevent data theft or exposure. BitLocker-protected computers can also delete
data more securely when they are decommissioned because it is much more difficult to recover deleted data from
an encrypted drive than from a non-encrypted drive.
Overview and requirements
Upgrading
Deployment and administration
Key management
BitLocker To Go
Active Directory Domain Services (AD DS )
Security
BitLocker Network Unlock
Using BitLocker with other programs and general questions

More information
Prepare your organization for BitLocker: Planning and Policies
BitLocker Group Policy settings
BCD settings and BitLocker
BitLocker: How to enable Network Unlock
BitLocker: How to deploy on Windows Server 2012
BitLocker: Use BitLocker Drive Encryption Tools to manage BitLocker
BitLocker: Use BitLocker Recovery Password Viewer
BitLocker Cmdlets in Windows PowerShell
 BitLocker Overview and Requirements FAQ
6/28/2018 • 3 minutes to read • Edit Online

Applies to
Windows 10

How does BitLocker work?

How BitLocker works with operating system drives
You can use BitLocker to mitigate unauthorized data access on lost or stolen computers by encrypting all user files
and system files on the operating system drive, including the swap files and hibernation files, and checking the
integrity of early boot components and boot configuration data.
How BitLocker works with fixed and removable data drives
You can use BitLocker to encrypt the entire contents of a data drive. You can use Group Policy to require that
BitLocker be enabled on a drive before the computer can write data to the drive. BitLocker can be configured with
a variety of unlock methods for data drives, and a data drive supports multiple unlock methods.

Does BitLocker support multifactor authentication?

Yes, BitLocker supports multifactor authentication for operating system drives. If you enable BitLocker on a
computer that has a TPM version 1.2 or later, you can use additional forms of authentication with the TPM
protection.

What are the BitLocker hardware and software requirements?

For requirements, see System requirements.

NOTE
Dynamic disks are not supported by BitLocker. Dynamic data volumes will not be displayed in the Control Panel. Although
the operating system volume will always be displayed in the Control Panel, regardless of whether it is a Dynamic disk, if it is a
dynamic disk it is cannot be protected by BitLocker.

Why are two partitions required? Why does the system drive have to
be so large?
Two partitions are required to run BitLocker because pre-startup authentication and system integrity verification
must occur on a separate partition from the encrypted operating system drive. This configuration helps protect the
operating system and the information in the encrypted drive.

Which Trusted Platform Modules (TPMs) does BitLocker support?

BitLocker supports TPM version 1.2 or higher.

How can I tell if a TPM is on my computer?

Beginning with Windows 10, version 1803, you can check TPM status in Windows Defender Security Center >
Device Security > Security processor details. In previous versions of Windows, open the TPM MMC console
(tpm.msc) and look under the Status heading.

Can I use BitLocker on an operating system drive without a TPM?

Yes, you can enable BitLocker on an operating system drive without a TPM version 1.2 or higher, if the BIOS or
UEFI firmware has the ability to read from a USB flash drive in the boot environment. This is because BitLocker
will not unlock the protected drive until BitLocker's own volume master key is first released by either the
computer's TPM or by a USB flash drive containing the BitLocker startup key for that computer. However,
computers without TPMs will not be able to use the system integrity verification that BitLocker can also provide. To
help determine whether a computer can read from a USB device during the boot process, use the BitLocker system
check as part of the BitLocker setup process. This system check performs tests to confirm that the computer can
properly read from the USB devices at the appropriate time and that the computer meets other BitLocker
requirements.

How do I obtain BIOS support for the TPM on my computer?

Contact the computer manufacturer to request a Trusted Computing Group (TCG )-compliant BIOS or UEFI boot
firmware that meets the following requirements:
It is compliant with the TCG standards for a client computer.
It has a secure update mechanism to help prevent a malicious BIOS or boot firmware from being installed on
the computer.

What credentials are required to use BitLocker?

To turn on, turn off, or change configurations of BitLocker on operating system and fixed data drives, membership
in the local Administrators group is required. Standard users can turn on, turn off, or change configurations of
BitLocker on removable data drives.

What is the recommended boot order for computers that are going to
be BitLocker-protected?
You should configure the startup options of your computer to have the hard disk drive first in the boot order,
before any other drives such ach as CD/DVD drives or USB drives. If the hard disk is not first and you typically
boot from hard disk, then a boot order change may be detected or assumed when removable media is found
during boot. The boot order typically affects the system measurement that is verified by BitLocker and a change in
boot order will cause you to be prompted for your BitLocker recovery key. For the same reason, if you have a
laptop with a docking station, ensure that the hard disk drive is first in the boot order both when docked and
undocked.
 BitLocker Upgrading FAQ
6/28/2018 • 2 minutes to read • Edit Online

Applies to
Windows 10

Can I upgrade to Windows 10 with BitLocker enabled?

Yes.

What is the difference between suspending and decrypting BitLocker?

Decrypt completely removes BitLocker protection and fully decrypts the drive.
Suspend keeps the data encrypted but encrypts the BitLocker volume master key with a clear key. The clear key is
a cryptographic key stored unencrypted and unprotected on the disk drive. By storing this key unencrypted, the
Suspend option allows for changes or upgrades to the computer without the time and cost of decrypting and re-
encrypting the entire drive. After the changes are made and BitLocker is again enabled, BitLocker will reseal the
encryption key to the new values of the measured components that changed as a part of the upgrade, the volume
master key is changed, the protectors are updated to match and the clear key is erased.

Do I have to decrypt my BitLocker-protected drive to download and

install system updates and upgrades?
No user action is required for BitLocker in order to apply updates from Microsoft, including Windows quality
updates and feature updates. Users need to suspend BitLocker for Non-Microsoft software updates, such as:
Computer manufacturer firmware updates
TPM firmware updates
Non-Microsoft application updates that modify boot components

NOTE
If you have suspended BitLocker, you can resume BitLocker protection after you have installed the upgrade or update. Upon
resuming protection, BitLocker will reseal the encryption key to the new values of the measured components that changed
as a part of the upgrade or update. If these types of upgrades or updates are applied without suspending BitLocker, your
computer will enter recovery mode when restarting and will require a recovery key or password to access the computer.
 BitLocker Deployment and Administration FAQ
6/28/2018 • 5 minutes to read • Edit Online

Applies to
Windows 10

Can BitLocker deployment be automated in an enterprise

environment?
Yes, you can automate the deployment and configuration of BitLocker and the TPM using either WMI or Windows
PowerShell scripts. How you choose to implement the scripts depends on your environment. You can also use
Manage-bde.exe to locally or remotely configure BitLocker. For more info about writing scripts that use the
BitLocker WMI providers, see BitLocker Drive Encryption Provider. For more info about using Windows
PowerShell cmdlets with BitLocker Drive Encryption, see BitLocker Cmdlets in Windows PowerShell.

Can BitLocker encrypt more than just the operating system drive?
Yes.

Is there a noticeable performance impact when BitLocker is enabled on

a computer?
Generally it imposes a single-digit percentage performance overhead.

How long will initial encryption take when BitLocker is turned on?
Although BitLocker encryption occurs in the background while you continue to work, and the system remains
usable, encryption times vary depending on the type of drive that is being encrypted, the size of the drive, and the
speed of the drive. If you are encrypting very large drives, you may want to set encryption to occur during times
when you will not be using the drive.
You can also choose whether or not BitLocker should encrypt the entire drive or just the used space on the drive
when you turn on BitLocker. On a new hard drive, encrypting just the used spaced can be considerably faster than
encrypting the entire drive. When this encryption option is selected, BitLocker automatically encrypts data as it is
saved, ensuring that no data is stored unencrypted.

What happens if the computer is turned off during encryption or

decryption?
If the computer is turned off or goes into hibernation, the BitLocker encryption and decryption process will resume
where it stopped the next time Windows starts. This is true even if the power is suddenly unavailable.

Does BitLocker encrypt and decrypt the entire drive all at once when
reading and writing data?
No, BitLocker does not encrypt and decrypt the entire drive when reading and writing data. The encrypted sectors
in the BitLocker-protected drive are decrypted only as they are requested from system read operations. Blocks that
are written to the drive are encrypted before the system writes them to the physical disk. No unencrypted data is
ever stored on a BitLocker-protected drive.

How can I prevent users on a network from storing data on an

unencrypted drive?
You can configure Group Policy settings to require that data drives be BitLocker-protected before a BitLocker-
protected computer can write data to them. For more info, see BitLocker Group Policy settings. When these policy
settings are enabled, the BitLocker-protected operating system will mount any data drives that are not protected
by BitLocker as read-only.

What is Used Disk Space Only encryption?

BitLocker in Windows 10 lets users choose to encrypt just their data. Although it's not the most secure way to
encrypt a drive, this option can reduce encryption time by more than 99 percent, depending on how much data
that needs to be encrypted. For more information, see Used Disk Space Only encryption.

What system changes would cause the integrity check on my operating

system drive to fail?
The following types of system changes can cause an integrity check failure and prevent the TPM from releasing the
BitLocker key to decrypt the protected operating system drive:
Moving the BitLocker-protected drive into a new computer.
Installing a new motherboard with a new TPM.
Turning off, disabling, or clearing the TPM.
Changing any boot configuration settings.
Changing the BIOS, UEFI firmware, master boot record, boot sector, boot manager, option ROM, or other early
boot components or boot configuration data.

What causes BitLocker to start into recovery mode when attempting to

start the operating system drive?
Because BitLocker is designed to protect your computer from numerous attacks, there are numerous reasons why
BitLocker could start in recovery mode. For example:
Changing the BIOS boot order to boot another drive in advance of the hard drive.
Adding or removing hardware, such as inserting a new card in the computer, including some PCMIA wireless
cards.
Removing, inserting, or completely depleting the charge on a smart battery on a portable computer.
In BitLocker, recovery consists of decrypting a copy of the volume master key using either a recovery key stored
on a USB flash drive or a cryptographic key derived from a recovery password. The TPM is not involved in any
recovery scenarios, so recovery is still possible if the TPM fails boot component validation, malfunctions, or is
removed.

What can prevent BitLocker from binding to PCR 7?

This happens if a non-Windows OS booted prior to Windows, or if Secure Boot is not available to the device,
either because it has been disabled or the hardware does not support it.

Can I swap hard disks on the same computer if BitLocker is enabled on

the operating system drive?
Yes, you can swap multiple hard disks on the same computer if BitLocker is enabled, but only if the hard disks were
BitLocker-protected on the same computer. The BitLocker keys are unique to the TPM and operating system drive,
so if you want to prepare a backup operating system or data drive for use in case of disk failure, you need to make
sure that they were matched with the correct TPM. You can also configure different hard drives for different
operating systems and then enable BitLocker on each one with different authentication methods (such as one with
TPM -only and one with TPM+PIN ) without any conflicts.

Can I access my BitLocker-protected drive if I insert the hard disk into a

different computer?
Yes, if the drive is a data drive, you can unlock it from the BitLocker Drive Encryption Control Panel item just as
you would any other data drive by using a password or smart card. If the data drive was configured for automatic
unlock only, you will have to unlock it by using the recovery key. The encrypted hard disk can be unlocked by a
data recovery agent (if one was configured) or it can be unlocked by using the recovery key.

Why is "Turn BitLocker on" not available when I right-click a drive?

Some drives cannot be encrypted with BitLocker. Reasons a drive cannot be encrypted include insufficient disk
size, an incompatible file system, if the drive is a dynamic disk, or a drive is designated as the system partition. By
default, the system drive (or system partition) is hidden from display. However, if it is not created as a hidden drive
when the operating system was installed due to a custom installation process, that drive might be displayed but
cannot be encrypted.

What type of disk configurations are supported by BitLocker?

Any number of internal, fixed data drives can be protected with BitLocker. On some versions ATA and SATA-based,
direct-attached storage devices are also supported.
 BitLocker Key Management FAQ
6/28/2018 • 6 minutes to read • Edit Online

Applies to
Windows 10

How can I authenticate or unlock my removable data drive?

You can unlock removable data drives by using a password, a smart card, or you can configure a SID protector to
unlock a drive by using your domain credentials. After you've started encryption, the drive can also be
automatically unlocked on a specific computer for a specific user account. System administrators can configure
which options are available for users, as well as password complexity and minimum length requirements. To
unlock by using a SID protector, use Manage-bde:
Manage-bde -protectors -add e: -sid domain\username

What is the difference between a recovery password, recovery key, PIN,

enhanced PIN, and startup key?
For tables that list and describe elements such as a recovery password, recovery key, and PIN, see BitLocker key
protectors and BitLocker authentication methods.

How can the recovery password and recovery key be stored?

The recovery password and recovery key for an operating system drive or a fixed data drive can be saved to a
folder, saved to one or more USB devices, saved to your Microsoft Account, or printed.
For removable data drives, the recovery password and recovery key can be saved to a folder, saved to your
Microsoft Account, or printed. By default, you cannot store a recovery key for a removable drive on a removable
drive.
A domain administrator can additionally configure Group Policy to automatically generate recovery passwords
and store them in Active Directory Domain Services (AD DS ) for any BitLocker-protected drive.

Is it possible to add an additional method of authentication without

decrypting the drive if I only have the TPM authentication method
enabled?
You can use the Manage-bde.exe command-line tool to replace your TPM -only authentication mode with a
multifactor authentication mode. For example, if BitLocker is enabled with TPM authentication only and you want
to add PIN authentication, use the following commands from an elevated command prompt, replacing 4 -20 digit
numeric PIN with the numeric PIN you want to use:
manage-bde –protectors –delete %systemdrive% -type tpm

manage-bde –protectors –add %systemdrive% -tpmandpin 4-20 digit numeric PIN

When should an additional method of authentication be considered?

New hardware that meets Windows Hardware Compatibility Program requirements make a PIN less critical as a
mitigation, and having a TPM -only protector is likely sufficient when combined with policies like device lockout.
For example, Surface Pro and Surface Book do not have external DMA ports to attack. For older hardware, where
a PIN may be needed, it’s recommended to enable enhanced PINs that allow non-numeric characters such as
letters and punctuation marks, and to set the PIN length based on your risk tolerance and the hardware anti-
hammering capabilities available to the TPMs in your computers.

If I lose my recovery information, will the BitLocker-protected data be

unrecoverable?
BitLocker is designed to make the encrypted drive unrecoverable without the required authentication. When in
recovery mode, the user needs the recovery password or recovery key to unlock the encrypted drive.

IMPORTANT
Store the recovery information in AD DS, along with your Microsoft Account, or another safe location.

Can the USB flash drive that is used as the startup key also be used to
store the recovery key?
While this is technically possible, it is not a best practice to use one USB flash drive to store both keys. If the USB
flash drive that contains your startup key is lost or stolen, you also lose access to your recovery key. In addition,
inserting this key would cause your computer to automatically boot from the recovery key even if TPM -measured
files have changed, which circumvents the TPM's system integrity check.

Can I save the startup key on multiple USB flash drives?

Yes, you can save a computer's startup key on multiple USB flash drives. Right-clicking a BitLocker-protected drive
and selecting Manage BitLocker will provide you the options to duplicate the recovery keys as needed.

Can I save multiple (different) startup keys on the same USB flash
drive?
Yes, you can save BitLocker startup keys for different computers on the same USB flash drive.

Can I generate multiple (different) startup keys for the same computer?
You can generate different startup keys for the same computer through scripting. However, for computers that
have a TPM, creating different startup keys prevents BitLocker from using the TPM's system integrity check.

Can I generate multiple PIN combinations?

You cannot generate multiple PIN combinations.

What encryption keys are used in BitLocker? How do they work

together?
Raw data is encrypted with the full volume encryption key, which is then encrypted with the volume master key.
The volume master key is in turn encrypted by one of several possible methods depending on your authentication
(that is, key protectors or TPM ) and recovery scenarios.

Where are the encryption keys stored?

The full volume encryption key is encrypted by the volume master key and stored in the encrypted drive. The
volume master key is encrypted by the appropriate key protector and stored in the encrypted drive. If BitLocker
has been suspended, the clear key that is used to encrypt the volume master key is also stored in the encrypted
drive, along with the encrypted volume master key.
This storage process ensures that the volume master key is never stored unencrypted and is protected unless you
disable BitLocker. The keys are also saved to two additional locations on the drive for redundancy. The keys can be
read and processed by the boot manager.

Why do I have to use the function keys to enter the PIN or the 48-
character recovery password?
The F1 through F10 keys are universally mapped scan codes available in the pre-boot environment on all
computers and in all languages. The numeric keys 0 through 9 are not usable in the pre-boot environment on all
keyboards.
When using an enhanced PIN, users should run the optional system check during the BitLocker setup process to
ensure that the PIN can be entered correctly in the pre-boot environment.

How does BitLocker help prevent an attacker from discovering the PIN
that unlocks my operating system drive?
It is possible that a personal identification number (PIN ) can be discovered by an attacker performing a brute force
attack. A brute force attack occurs when an attacker uses an automated tool to try different PIN combinations until
the correct one is discovered. For BitLocker-protected computers, this type of attack, also known as a dictionary
attack, requires that the attacker have physical access to the computer.
The TPM has the built-in ability to detect and react to these types of attacks. Because different manufacturers'
TPMs may support different PIN and attack mitigations, contact your TPM's manufacturer to determine how your
computer's TPM mitigates PIN brute force attacks. After you have determined your TPM's manufacturer, contact
the manufacturer to gather the TPM's vendor-specific information. Most manufacturers use the PIN authentication
failure count to exponentially increase lockout time to the PIN interface. However, each manufacturer has different
policies regarding when and how the failure counter is decreased or reset.

How can I determine the manufacturer of my TPM?

You can determine your TPM manufacturer in Windows Defender Security Center > Device Security >
Security processor details.

How can I evaluate a TPM's dictionary attack mitigation mechanism?

The following questions can assist you when asking a TPM manufacturer about the design of a dictionary attack
mitigation mechanism:
How many failed authorization attempts can occur before lockout?
What is the algorithm for determining the duration of a lockout based on the number of failed attempts and
any other relevant parameters?
What actions can cause the failure count and lockout duration to be decreased or reset?

Can PIN length and complexity be managed with Group Policy?

Yes and No. You can configure the minimum personal identification number (PIN ) length by using the Configure
minimum PIN length for startup Group Policy setting and allow the use of alphanumeric PINs by enabling the
Allow enhanced PINs for startup Group Policy setting. However, you cannot require PIN complexity by Group
Policy.
For more info, see BitLocker Group Policy settings.
 BitLocker To Go FAQ
7/11/2018 • 2 minutes to read • Edit Online

Applies to
Windows 10

What is BitLocker To Go?

BitLocker To Go is BitLocker Drive Encryption on removable data drives. This includes the encryption of USB flash
drives, SD cards, external hard disk drives, and other drives formatted by using the NTFS, FAT16, FAT32, or exFAT
file systems.
As with BitLocker, drives that are encrypted using BitLocker To Go can be opened with a password or smart card
on another computer by using BitLocker Drive Encryption in Control Panel.
 BitLocker and Active Directory Domain Services (AD
DS) FAQ
6/28/2018 • 4 minutes to read • Edit Online

Applies to
Windows 10

What type of information is stored in AD DS?

STORED INFORMATION DESCRIPTION

Hash of the TPM owner password Beginning with Windows 10, the password hash is not stored
in AD DS by default. The password hash can be stored only if
the TPM is owned and the ownership was taken by using
components of Windows 8.1 or earlier, such as the BitLocker
Setup Wizard or the TPM snap-in.

BitLocker recovery password The recovery password allows you to unlock and access the
drive in the event of a recovery incident. Domain
administrators can view the BitLocker recovery password by
using the BitLocker Recovery Password Viewer. For more
information about this tool, see BitLocker: Use BitLocker
Recovery Password Viewer.

BitLocker key package The key package helps to repair damage to the hard disk that
would otherwise prevent standard recovery. Using the key
package for recovery requires the BitLocker Repair Tool,
Repair-bde.

What if BitLocker is enabled on a computer before the computer has

joined the domain?
If BitLocker is enabled on a drive before Group Policy has been applied to enforce backup, the recovery
information will not be automatically backed up to AD DS when the computer joins the domain or when Group
Policy is subsequently applied. However, you can use the Choose how BitLocker-protected operating system
drives can be recovered, Choose how BitLocker-protected fixed drives can be recovered and Choose how
BitLocker-protected removable drives can be recovered Group Policy settings to require that the computer be
connected to a domain before BitLocker can be enabled to help ensure that recovery information for BitLocker-
protected drives in your organization is backed up to AD DS.
For more info, see BitLocker Group Policy settings.
The BitLocker Windows Management Instrumentation (WMI) interface does allow administrators to write a script
to back up or synchronize an online client's existing recovery information; however, BitLocker does not
automatically manage this process. The manage-bde command-line tool can also be used to manually back up
recovery information to AD DS. For example, to back up all of the recovery information for the C: drive to AD DS,
you would use the following command from an elevated command prompt: manage-bde -protectors -
adbackup C:.
 IMPORTANT
Joining a computer to the domain should be the first step for new computers within an organization. After computers are
joined to a domain, storing the BitLocker recovery key to AD DS is automatic (when enabled in Group Policy).

Is there an event log entry recorded on the client computer to indicate

the success or failure of the Active Directory backup?
Yes, an event log entry that indicates the success or failure of an Active Directory backup is recorded on the client
computer. However, even if an event log entry says "Success," the information could have been subsequently
removed from AD DS, or BitLocker could have been reconfigured in such a way that the Active Directory
information can no longer unlock the drive (such as by removing the recovery password key protector). In
addition, it is also possible that the log entry could be spoofed.
Ultimately, determining whether a legitimate backup exists in AD DS requires querying AD DS with domain
administrator credentials by using the BitLocker password viewer tool.

If I change the BitLocker recovery password on my computer and store

the new password in AD DS, will AD DS overwrite the old password?
No. By design, BitLocker recovery password entries do not get deleted from AD DS; therefore, you might see
multiple passwords for each drive. To identify the latest password, check the date on the object.

What happens if the backup initially fails? Will BitLocker retry the
backup?
If the backup initially fails, such as when a domain controller is unreachable at the time when the BitLocker setup
wizard is run, BitLocker does not try again to back up the recovery information to AD DS.
When an administrator selects the Require BitLocker backup to AD DS check box of the Store BitLocker
recovery information in Active Directory Domain Service (Windows 2008 and Windows Vista) policy
setting, or the equivalent Do not enable BitLocker until recovery information is stored in AD DS for
(operating system | fixed data | removable data) drives check box in any of the Choose how BitLocker-
protected operating system drives can be recovered, Choose how BitLocker-protected fixed data drives
can be recovered, Choose how BitLocker-protected removable data drives can be recovered policy
settings, this prevents users from enabling BitLocker unless the computer is connected to the domain and the
backup of BitLocker recovery information to AD DS succeeds. With these settings configured if the backup fails,
BitLocker cannot be enabled, ensuring that administrators will be able to recover BitLocker-protected drives in the
organization.
For more info, see BitLocker Group Policy settings.
When an administrator clears these check boxes, the administrator is allowing a drive to be BitLocker-protected
without having the recovery information successfully backed up to AD DS; however, BitLocker will not
automatically retry the backup if it fails. Instead, administrators can create a script for the backup, as described
earlier in What if BitLocker is enabled on a computer before the computer has joined the domain? to capture the
information after connectivity is restored.
 BitLocker Security FAQ
6/28/2018 • 2 minutes to read • Edit Online

Applies to
Windows 10

What form of encryption does BitLocker use? Is it configurable?

BitLocker uses Advanced Encryption Standard (AES ) as its encryption algorithm with configurable key lengths of
128 or 256 bits. The default encryption setting is AES -128, but the options are configurable by using Group Policy.

What is the best practice for using BitLocker on an operating system

drive?
The recommended practice for BitLocker configuration on an operating system drive is to implement BitLocker on
a computer with a TPM version 1.2 or higher and a Trusted Computing Group (TCG )-compliant BIOS or UEFI
firmware implementation, plus a PIN. By requiring a PIN that was set by the user in addition to the TPM
validation, a malicious user that has physical access to the computer cannot simply start the computer.

What are the implications of using the sleep or hibernate power

management options?
BitLocker on operating system drives in its basic configuration (with a TPM but without additional startup
authentication) provides additional security for the hibernate mode. However, BitLocker provides greater security
when it is configured to use an additional startup authentication factor (TPM+PIN, TPM+USB, or
TPM+PIN+USB ) with the hibernate mode. This method is more secure because returning from hibernation
requires authentication. For improved security, we recommend that sleep mode be disabled and that you use
TPM+PIN for the authentication method. Startup authentication can be configured by using Group Policy or
Mobile Device Management with the Bitlocker CSP.

What are the advantages of a TPM?

Most operating systems use a shared memory space and rely on the operating system to manage physical
memory. A TPM is a hardware component that uses its own internal firmware and logic circuits for processing
instructions, thus shielding it from external software vulnerabilities. Attacking the TPM requires physical access to
the computer. Additionally, the tools and skills necessary to attack hardware are often more expensive, and usually
are not as available as the ones used to attack software. And because each TPM is unique to the computer that
contains it, attacking multiple TPM computers would be difficult and time-consuming.

NOTE
Configuring BitLocker with an additional factor of authentication provides even more protection against TPM hardware
attacks.
 BitLocker Network Unlock FAQ
6/28/2018 • 2 minutes to read • Edit Online

Applies to
Windows 10
BitLocker Network Unlock enables easier management for BitLocker-enabled desktops and servers that use the
TPM+PIN protection method in a domain environment. When a computer that is connected to a wired corporate
network is rebooted, Network Unlock allows the PIN entry prompt to be bypassed. It automatically unlocks
BitLocker-protected operating system volumes by using a trusted key that is provided by the Windows
Deployment Services server as its secondary authentication method.
To use Network Unlock you must also have a PIN configured for your computer. When your computer is not
connected to the network you will need to provide the PIN to unlock it.
BitLocker Network Unlock has software and hardware requirements for both client computers, Windows
Deployment services, and domain controllers that must be met before you can use it.
Network Unlock uses two protectors, the TPM protector and the one provided by the network or by your PIN,
whereas automatic unlock uses a single protector, the one stored in the TPM. If the computer is joined to a network
without the key protector it will prompt you to enter your PIN. If the PIN is not available you will need to use the
recovery key to unlock the computer if it can ot be connected to the network.
For more info, see BitLocker: How to enable Network Unlock.
 Using BitLocker with other programs FAQ
7/11/2018 • 6 minutes to read • Edit Online

Applies to
Windows 10

Can I use EFS with BitLocker?

Yes, you can use Encrypting File System (EFS ) to encrypt files on a BitLocker-protected drive. BitLocker helps
protect the entire operating system drive against offline attacks, whereas EFS can provide additional user-based
file level encryption for security separation between multiple users of the same computer. You can also use EFS in
Windows to encrypt files on other drives that are not encrypted by BitLocker. The root secrets of EFS are stored by
default on the operating system drive; therefore, if BitLocker is enabled for the operating system drive, data that is
encrypted by EFS on other drives is also indirectly protected by BitLocker.

Can I run a kernel debugger with BitLocker?

Yes. However, the debugger should be turned on before enabling BitLocker. Turning on the debugger ensures that
the correct measurements are calculated when sealing to the TPM, allowing the computer to start properly. If you
need to turn debugging on or off when using BitLocker, be sure to suspend BitLocker first to avoid putting your
computer into recovery mode.

How does BitLocker handle memory dumps?

BitLocker has a storage driver stack that ensures memory dumps are encrypted when BitLocker is enabled.

Can BitLocker support smart cards for pre-boot authentication?

BitLocker does not support smart cards for pre-boot authentication. There is no single industry standard for smart
card support in the firmware, and most computers either do not implement firmware support for smart cards, or
only support specific smart cards and readers. This lack of standardization makes supporting them very difficult.

Can I use a non-Microsoft TPM driver?

Microsoft does not support non-Microsoft TPM drivers and strongly recommends against using them with
BitLocker. Attempting to use a non-Microsoft TPM driver with BitLocker may cause BitLocker to report that a TPM
is not present on the computer and not allow the TPM to be used with BitLocker.

Can other tools that manage or modify the master boot record work
with BitLocker?
We do not recommend modifying the master boot record on computers whose operating system drives are
BitLocker-protected for a number of security, reliability, and product support reasons. Changes to the master boot
record (MBR ) could change the security environment and prevent the computer from starting normally, as well as
complicate any efforts to recover from a corrupted MBR. Changes made to the MBR by anything other than
Windows might force the computer into recovery mode or prevent it from booting entirely.

Why is the system check failing when I am encrypting my operating

system drive?
The system check is designed to ensure your computer's BIOS or UEFI firmware is compatible with BitLocker and
that the TPM is working correctly. The system check can fail for several reasons:
The computer's BIOS or UEFI firmware cannot read USB flash drives.
The computer's BIOS, uEFI firmware, or boot menu does not have reading USB flash drives enabled.
There are multiple USB flash drives inserted into the computer.
The PIN was not entered correctly.
The computer's BIOS or UEFI firmware only supports using the function keys (F1–F10) to enter numerals in
the pre-boot environment.
The startup key was removed before the computer finished rebooting.
The TPM has malfunctioned and fails to unseal the keys.

What can I do if the recovery key on my USB flash drive cannot be

read?
Some computers cannot read USB flash drives in the pre-boot environment. First, check your BIOS or UEFI
firmware and boot settings to ensure that the use of USB drives is enabled. If it is not enabled, enable the use of
USB drives in the BIOS or UEFI firmware and boot settings and then try to read the recovery key from the USB
flash drive again. If it still cannot be read, you will have to mount the hard drive as a data drive on another
computer so that there is an operating system to attempt to read the recovery key from the USB flash drive. If the
USB flash drive has been corrupted or damaged, you may need to supply a recovery password or use the recovery
information that was backed up to AD DS. Also, if you are using the recovery key in the pre-boot environment,
ensure that the drive is formatted by using the NTFS, FAT16, or FAT32 file system.

Why am I unable to save my recovery key to my USB flash drive?

The Save to USB option is not shown by default for removable drives. If the option is unavailable, it means that a
system administrator has disallowed the use of recovery keys.

Why am I unable to automatically unlock my drive?

Automatic unlocking for fixed data drives requires that the operating system drive also be protected by BitLocker.
If you are using a computer that does not have a BitLocker-protected operating system drive, the drive cannot be
automatically unlocked. For removable data drives, you can add automatic unlocking by right-clicking the drive in
Windows Explorer and clicking Manage BitLocker. You will still be able to use the password or smart card
credentials you supplied when you turned on BitLocker to unlock the removable drive on other computers.

Can I use BitLocker in Safe Mode?

Limited BitLocker functionality is available in Safe Mode. BitLocker-protected drives can be unlocked and
decrypted by using the BitLocker Drive Encryption Control Panel item. Right-clicking to access BitLocker
options from Windows Explorer is not available in Safe Mode.

How do I "lock" a data drive?

Both fixed and removable data drives can be locked by using the Manage-bde command-line tool and the –lock
command.
 NOTE
Ensure all data is saved to the drive before locking it. Once locked, the drive will become inaccessible.

The syntax of this command is:

manage-bde driveletter -lock

Outside of using this command, data drives will be locked on shutdown and restart of the operating system. A
removable data drive will also be locked automatically when the drive is removed from the computer.

Can I use BitLocker with the Volume Shadow Copy Service?

Yes. However, shadow copies made prior to enabling BitLocker will be automatically deleted when BitLocker is
enabled on software-encrypted drives. If you are using a hardware encrypted drive, the shadow copies are
retained.

Does BitLocker support virtual hard disks (VHDs)?

BitLocker should work like any specific physical machine within its hardware limitations as long as the
environment (physical or virtual) meets Windows Operating System requirements to run.
With TPM - Yes it is supported
Without TPM - Yes it is supported (with password protector)
BitLocker is also supported on data volume VHDs, such as those used by clusters, if you are running Windows 10,
Windows 8.1, Windows 8, Windows Server 2016, Windows Server 2012 R2, or Windows Server 2012.

Can I use BitLocker with virtual machines (VMs)?

Yes. Password protectors and virtual TPMs can be used with BitLocker to protect virtual machines. VMs can be
domain joined, Azure AD -joined, or workplace-joined (via Settings > Accounts > Access work or school >
Connect) to receive policy. You can enable encryption either while creating the VM or by using other existing
management tools such as the BitLocker CSP, or even by using a startup script or logon script delivered by Group
Policy. Windows Server 2016 also supports Shielded VMs and guarded fabric to protect VMs from malicious
administrators.
 Prepare your organization for BitLocker: Planning
and policies
8/28/2018 • 14 minutes to read • Edit Online

Applies to
Windows 10
This topic for the IT professional explains how can you plan your BitLocker deployment.
When you design your BitLocker deployment strategy, define the appropriate policies and configuration
requirements based on the business requirements of your organization. The following topics will help you collect
information that you can use to frame your decision-making process about deploying and managing BitLocker
systems.
Audit your environment
Encryption keys and authentication
TPM hardware configurations
Non-TPM hardware configurations
Disk configuration considerations
BitLocker provisioning
Used Disk Space Only encryption
Active Directory Domain Services considerations
FIPS support for recovery password protector
BitLocker Group Policy settings

Audit your environment

To plan your enterprise deployment of BitLocker, you must first understand your current environment. Conduct
an informal audit to define your current policies, procedures, and hardware environment. Begin by reviewing your
existing corporate security policies as they relate to disk encryption software. If your organization is not currently
using disk encryption software, none of these policies will exist. If you are using disk encryption software, then
you might need to modify your organization's policies to address the capabilities of BitLocker.
Use the following questions to help you document your organization's current disk encryption security policies:
1. Are there policies to address which computers will use BitLocker and which computers will not use BitLocker?
2. What policies exist to control recovery password and recovery key storage?
3. What are the policies for validating the identity of users that need to perform BitLocker recovery?
4. What policies exist to control who in the organization has access to recovery data?
5. What policies exist to control computer decommissioning or retirement?

Encryption keys and authentication

BitLocker helps prevent unauthorized access to data on lost or stolen computers by:
Encrypting the entire Windows operating system volume on the hard disk.
Verifying the boot process integrity.
The trusted platform module (TPM ) is a hardware component installed in many newer computers by the
computer manufacturers. It works with BitLocker to help protect user data and to ensure that a computer has not
been tampered with while the system was offline.
In addition, BitLocker offers the option to lock the normal startup process until the user supplies a personal
identification number (PIN ) or inserts a removable USB device, such as a flash drive, that contains a startup key.
These additional security measures provide multifactor authentication and assurance that the computer will not
start or resume from hibernation until the correct PIN or startup key is presented.
On computers that do not have a TPM version 1.2 or higher, you can still use BitLocker to encrypt the Windows
operating system volume. However, this implementation will require the user to insert a USB startup key to start
the computer or resume from hibernation, and does not provide the pre-startup system integrity verification
offered by BitLocker working with a TPM.
BitLocker key protectors
KEY PROTECTOR DESCRIPTION

TPM A hardware device used to help establish a secure root-of-

trust. BitLocker only supports TPM version 1.2 or higher.

PIN A user-entered numeric key protector that can only be used

in addition to the TPM.

Enhanced PIN A user-entered alphanumeric key protector that can only be

used in addition to the TPM.

Startup key An encryption key that can be stored on most removable

media. This key protector can be used alone on non-TPM
computers, or in conjunction with a TPM for added security.

Recovery password A 48-digit number used to unlock a volume when it is in

recovery mode. Numbers can often be typed on a regular
keyboard, if the numbers on the normal keyboard are not
responding you can always use the function keys (F1-F10) to
input the numbers.

Recovery key An encryption key stored on removable media that can be

used for recovering data encrypted on a BitLocker volume.

BitLocker authentication methods

AUTHENTICATION METHOD REQUIRES USER INTERACTION DESCRIPTION

TPM only No TPM validates early boot components.

TPM + PIN Yes TPM validates early boot components.

The user must enter the correct PIN
before the start-up process can
continue, and before the drive can be
unlocked. The TPM will enter lockout if
the incorrect PIN is entered repeatedly
to protect the PIN from brute force
attacks. The number of repeated
attempts that will trigger a lockout is
variable.
 AUTHENTICATION METHOD REQUIRES USER INTERACTION DESCRIPTION

TPM + Network key No The TPM successfully validates early

boot components, and a valid
encrypted network key has been
provided from the WDS server. This
authentication method provides
automatic unlock of operating system
volumes at system reboot while still
maintaining multifactor authentication.

TPM + startup key Yes The TPM successfully validates early

boot components, and a USB flash
drive containing the startup key has
been inserted.

Startup key only Yes The user is prompted to insert the USB
flash drive that holds the recovery key
and/or startup key and reboot the
computer.

Will you support computers without TPM version 1.2 or higher?

Determine whether you will support computers that do not have a TPM version 1.2 or higher in your
environment. If you choose to support BitLocker on this type of computer, a user must use a USB startup key to
boot the system. This requires additional support processes similar to multifactor authentication.
What areas of your organization need a baseline level of data protection?
The TPM -only authentication method will provide the most transparent user experience for organizations that
need a baseline level of data protection to meet security policies. It has the lowest total cost of ownership. TPM -
only might also be more appropriate for computers that are unattended or that must reboot unattended.
However, TPM -only authentication method offers the lowest level of data protection. This authentication method
protects against attacks that modify early boot components, but the level of protection can be affected by
potential weaknesses in hardware or in the early boot components. BitLocker’s multifactor authentication
methods significantly increase the overall level of data protection.
What areas of your organization need a more secure level of data protection?
If there are areas of your organization where data residing on user computers is considered highly-sensitive,
consider the best practice of deploying BitLocker with multifactor authentication on those systems. Requiring the
user to input a PIN significantly increases the level of protection for the system. You can also use BitLocker
Network Unlock to allow these computers to automatically unlock when connected to a trusted wired network
that can provide the Network Unlock key.
What multifactor authentication method does your organization prefer?
The protection differences provided by multifactor authentication methods cannot be easily quantified. Consider
each authentication method's impact on Helpdesk support, user education, user productivity, and automated
systems management processes.

TPM hardware configurations

In your deployment plan, identify what TPM -based hardware platforms will be supported. Document the
hardware models from an OEM of your choice, so that their configurations can be tested and supported. TPM
hardware requires special consideration during all aspects of planning and deployment.
TPM 1.2 states and initialization
For TPM 1.2, there are multiple possible states. Windows 10 automatically initializes the TPM, which brings it to
an enabled, activated, and owned state. This is the state that BitLocker requires before it can use the TPM.
Endorsement keys
For a TPM to be usable by BitLocker, it must contain an endorsement key, which is an RSA key pair. The private
half of the key pair is held inside the TPM and is never revealed or accessible outside the TPM. If the TPM does
not contain an endorsement key, BitLocker will force the TPM to generate one automatically as part of BitLocker
setup.
An endorsement key can be created at various points in the TPM’s lifecycle, but needs to be created only once for
the lifetime of the TPM. If an endorsement key does not exist for the TPM, it must be created before TPM
ownership can be taken.
For more information about the TPM and the TCG, see the Trusted Computing Group: Trusted Platform Module
(TPM ) Specifications (https://go.microsoft.com/fwlink/p/?linkid=69584).

Non-TPM hardware configurations

Devices that do not include a TPM can still be protected by drive encryption. Windows To Go workspaces can be
BitLocker protected using a startup password and PCs without a TPM can use a startup key.
Use the following questions to identify issues that might affect your deployment in a non-TPM configuration:
Are password complexity rules in place?
Do you have budget for USB flash drives for each of these computers?
Do your existing non-TPM devices support USB devices at boot time?
Test your individual hardware platforms with the BitLocker system check option while you are enabling BitLocker.
The system check will ensure that BitLocker can read the recovery information from a USB device and encryption
keys correctly before it encrypts the volume. CD and DVD drives cannot act as a block storage device and cannot
be used to store the BitLocker recovery material.

Disk configuration considerations

To function correctly, BitLocker requires a specific disk configuration. BitLocker requires two partitions that meet
the following requirements:
The operating system partition contains the operating system and its support files; it must be formatted with
the NTFS file system
The system partition (or boot partition) contains the files that are needed to load Windows after the BIOS or
UEFI firware has prepared the system hardware. BitLocker is not enabled on this partition. For BitLocker to
work, the system partition must not be encrypted and must be on a different partition than the operating
system. On UEFI platforms the system partition must be formatted with the FAT 32 file system. On BIOS
platforms the system partition must be formatted with the NTFS file system. It should be at least 350 MB in
size
Windows setup will automatically configure the disk drives of your computer to support BitLocker encryption.
Windows Recovery Environment (Windows RE ) is an extensible recovery platform that is based on Windows Pre-
installation Environment (Windows PE ). When the computer fails to start, Windows automatically transitions into
this environment, and the Startup Repair tool in Windows RE automates the diagnosis and repair of an
unbootable Windows installation. Windows RE also contains the drivers and tools that are needed to unlock a
volume protected by BitLocker by providing a recovery key or recovery password. To use Windows RE in
conjunction with BitLocker, the Windows RE boot image must reside on a volume that is not protected by
BitLocker.
Windows RE can also be used from boot media other than the local hard disk. If you choose not to install
Windows RE on the local hard disk of BitLocker-enabled computers, you can use alternate boot methods, such as
Windows Deployment Services, CD -ROM, or USB flash drive, for recovery.

BitLocker provisioning
In Windows Vista and Windows 7, BitLocker was provisioned post installation for system and data volumes
through either the manage-bde command line interface or the Control Panel user interface. With newer operating
systems, BitLocker can be easily provisioned before the operating system is installed. Preprovisioning requires
that the computer have a TPM.
To check the BitLocker status of a particular volume, administrators can look at the status of the drive in the
BitLocker control panel applet or Windows Explorer. A status of "Waiting For Activation" with a yellow
exclamation icon means that the drive was preprovisioned for BitLocker. This status means that there was only a
clear protector used when encrypting the volume. In this case, the volume is not protected and needs to have a
secure key added to the volume before the drive is considered fully protected. Administrators can use the control
panel options, manage-bde tool or WMI APIs to add an appropriate key protector and the volume status will be
updated.
When using the control panel options, administrators can choose to Turn on BitLocker and follow the steps in
the wizard to add a protector, such as a PIN for an operating system volume (or a password if no TPM exists), or a
password or smart card protector to a data volume. Then the drive security window is presented prior to
changing the volume status.
Administrators can enable BitLocker prior to operating system deployment from the Windows Pre-installation
Environment (WinPE ). This is done with a randomly generated clear key protector applied to the formatted
volume and encrypting the volume prior to running the Windows setup process. If the encryption uses the Used
Disk Space Only option this step takes only a few seconds and so incorporates well into regular deployment
processes.

Used Disk Space Only encryption

The BitLocker Setup wizard provides administrators the ability to choose the Used Disk Space Only or Full
encryption method when enabling BitLocker for a volume. Administrators can use the new BitLocker Group
Policy setting to enforce either Used Disk Space Only or Full disk encryption.
Launching the BitLocker Setup wizard prompts for the authentication method to be used (password and smart
card are available for data volumes). Once the method is chosen and the recovery key is saved, you are asked to
choose the drive encryption type, either Used Disk Space Only or Full drive encryption.
Used Disk Space Only means that only the portion of the drive that contains data will be encrypted, unused space
will remain unencrypted. This causes the encryption process to be much faster, especially for new PCs and data
drives. When BitLocker is enabled with this method as data is added to the drive the portion of the drive used will
be encrypted, so there is never unencrypted data stored on the drive.
Full drive encryption means that the entire drive will be encrypted, regardless of whether data is stored on it or
not. This is useful for drives that have been repurposed and may contain data remnants from their previous use.

Active Directory Domain Services considerations

BitLocker integrates with Active Directory Domain Services (AD DS ) to provide centralized key management. By
default, no recovery information is backed up to Active Directory. Administrators can configure the following
Group Policy setting to enable backup of BitLocker recovery information:
Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption\Turn on
BitLocker backup to Active Directory Domain Services
By default, only Domain Admins have access to BitLocker recovery information, but access can be delegated to
others.
The following recovery data is saved for each computer object:
Recovery password
A 48-digit recovery password used to recover a BitLocker-protected volume. Users enter this password to
unlock a volume when BitLocker enters recovery mode.
Key package data
With this key package and the recovery password, you will be able decrypt portions of a BitLocker-
protected volume if the disk is severely damaged. Each key package will only work with the volume it was
created on, which can be identified by the corresponding volume ID.

FIPS support for recovery password protector

Functionality introduced in Windows Server 2012 R2 and Windows 8.1, allows BitLocker to be fully functional in
FIPS mode.

Note: The United States Federal Information Processing Standard (FIPS ) defines security and interoperability
requirements for computer systems that are used by the U.S. federal government. The FIPS 140 standard
defines approved cryptographic algorithms. The FIPS 140 standard also sets forth requirements for key
generation and for key management. The National Institute of Standards and Technology (NIST) uses the
Cryptographic Module Validation Program (CMVP ) to determine whether a particular implementation of a
cryptographic algorithm is compliant with the FIPS 140 standard. An implementation of a cryptographic
algorithm is considered FIPS 140-compliant only if it has been submitted for and has passed NIST validation.
An algorithm that has not been submitted cannot be considered FIPS -compliant even if the implementation
produces identical data as a validated implementation of the same algorithm.

Prior to these supported versions of Windows, when Windows was in FIPS mode, BitLocker prevented the
creation or use of recovery passwords and instead forced the user to use recovery keys. For more information
about these issues, see the support article kb947249.
But on computers running these supported systems with BitLocker enabled:
FIPS -compliant recovery password protectors can be created when Windows is in FIPS mode. These
protectors use the FIPS 140 NIST SP800-132 algorithm.
Recovery passwords created in FIPS mode on Windows 8.1 can be distinguished from recovery passwords
created on other systems.
Recovery unlock using the FIPS -compliant algorithm based recovery password protector work in all cases that
currently work for recovery passwords.
When FIPS -compliant recovery passwords unlock volumes, the volume is unlocked to allow read/write access
even while in FIPS mode.
FIPS -compliant recovery password protectors can be exported and stored in AD a while in FIPS mode.
The BitLocker Group Policy settings for recovery passwords work the same for all Windows versions that support
BitLocker, whether in FIPs mode or not.
However, you cannot use recovery passwords generated on a system in FIPS mode for systems earlier than
Windows Server 2012 R2 and Windows 8.1. Recovery passwords created on Windows Server 2012 R2 and
Windows 8.1 are incompatible with BitLocker on operating systems prior to Windows Server 2012 R2 and
Windows 8.1; so recovery keys should be used instead.
More information
Trusted Platform Module
TPM Group Policy settings
BitLocker frequently asked questions (FAQ )
BitLocker
BitLocker Group Policy settings
BitLocker basic deployment
 BitLocker basic deployment
8/28/2018 • 21 minutes to read • Edit Online

Applies to
Windows 10
This topic for the IT professional explains how BitLocker features can be used to protect your data through drive
encryption.

Using BitLocker to encrypt volumes

BitLocker provides full volume encryption (FVE ) for operating system volumes, as well as fixed and removable
data volumes. To support fully encrypted operating system volumes, BitLocker uses an unencrypted system
volume for the files required to boot, decrypt, and load the operating system. This volume is automatically created
during a new installation of both client and server operating systems.
In the event that the drive was prepared as a single contiguous space, BitLocker requires a new volume to hold the
boot files. BdeHdCfg.exe can create these volumes.

Note: For more info about using this tool, see Bdehdcfg in the Command-Line Reference.

BitLocker encryption can be done using the following methods:

BitLocker control panel
Windows Explorer
manage-bde command line interface
BitLocker Windows PowerShell cmdlets
Encrypting volumes using the BitLocker control panel
Encrypting volumes with the BitLocker control panel (click Start, type bitlocker, click Manage BitLocker) is how
many users will utilize BitLocker. The name of the BitLocker control panel is BitLocker Drive Encryption. The
BitLocker control panel supports encrypting operating system, fixed data and removable data volumes. The
BitLocker control panel will organize available drives in the appropriate category based on how the device reports
itself to Windows. Only formatted volumes with assigned drive letters will appear properly in the BitLocker control
panel applet. To start encryption for a volume, select Turn on BitLocker for the appropriate drive to initialize the
BitLocker Drive Encryption Wizard. BitLocker Drive Encryption Wizard options vary based on volume type
(operating system volume or data volume).
Operating system volume
Upon launch, the BitLocker Drive Encryption Wizard verifies the computer meets the BitLocker system
requirements for encrypting an operating system volume. By default, the system requirements are:

REQUIREMENT DESCRIPTION

Hardware configuration The computer must meet the minimum requirements for
the supported Windows versions.
 REQUIREMENT DESCRIPTION

Operating system BitLocker is an optional feature which can be installed by

Server Manager on Windows Server 2012 and later.

Hardware TPM TPM version 1.2 or 2.0

A TPM is not required for BitLocker; however, only a
computer with a TPM can provide the additional security
of pre-startup system integrity verification and
multifactor authentication.

BIOS configuration A Trusted Computing Group (TCG)-compliant

BIOS or UEFI firmware.
The boot order must be set to start first from the
hard disk, and not the USB or CD drives.
The firmware must be able to read from a USB
flash drive during startup.

File system For computers that boot natively with UEFI firmware, at
least one FAT32 partition for the system drive and one
NTFS partition for the operating system drive.
For computers with legacy BIOS firmware, at least two
NTFS disk partitions, one for the system drive and one for
the operating system drive.
For either firmware, the system drive partition must be at
least 350 megabytes (MB) and set as the active partition.

Hardware encrypted drive prerequisites (optional) To use a hardware encrypted drive as the boot drive, the
drive must be in the uninitialized state and in the security
inactive state. In addition, the system must always boot
with native UEFI version 2.3.1 or higher and the CSM (if
any) disabled.

Upon passing the initial configuration, users are required to enter a password for the volume. If the volume does
not pass the initial configuration for BitLocker, the user is presented with an error dialog describing the
appropriate actions to be taken. Once a strong password has been created for the volume, a recovery key will be
generated. The BitLocker Drive Encryption Wizard will prompt for a location to save this key. A BitLocker recovery
key is a special key that you can create when you turn on BitLocker Drive Encryption for the first time on each
drive that you encrypt. You can use the recovery key to gain access to your computer if the drive that Windows is
installed on (the operating system drive) is encrypted using BitLocker Drive Encryption and BitLocker detects a
condition that prevents it from unlocking the drive when the computer is starting up. A recovery key can also be
used to gain access to your files and folders on a removable data drive (such as an external hard drive or USB
flash drive) that is encrypted using BitLocker To Go, if for some reason you forget the password or your computer
cannot access the drive.
You should store the recovery key by printing it, saving it on removable media, or saving it as a file in a network
folder or on your OneDrive, or on another drive of your computer that you are not encrypting. You cannot save
the recovery key to the root directory of a non-removable drive and cannot be stored on the encrypted volume.
You cannot save the recovery key for a removable data drive (such as a USB flash drive) on removable media.
Ideally, you should store the recovery key separate from your computer. After you create a recovery key, you can
use the BitLocker control panel to make additional copies.
When the recovery key has been properly stored, the BitLocker Drive Encryption Wizard will prompt the user to
choose how to encrypt the drive. There are two options:
Encrypt used disk space only - Encrypts only disk space that contains data
Encrypt entire drive - Encrypts the entire volume including free space
It is recommended that drives with little to no data utilize the used disk space only encryption option and that
drives with data or an operating system utilize the encrypt entire drive option.

Note: Deleted files appear as free space to the file system, which is not encrypted by used disk space only.
Until they are wiped or overwritten, deleted files hold information that could be recovered with common data
forensic tools.

Selecting an encryption type and choosing Next will give the user the option of running a BitLocker system check
(selected by default) which will ensure that BitLocker can properly access the recovery and encryption keys before
the volume encryption begins. It is recommended to run this system check before starting the encryption process.
If the system check is not run and a problem is encountered when the operating system attempts to start, the user
will need to provide the recovery key to start Windows.
After completing the system check (if selected), the BitLocker Drive Encryption Wizard will restart the computer to
begin encryption. Upon reboot, users are required to enter the password chosen to boot into the operating system
volume. Users can check encryption status by checking the system notification area or the BitLocker control panel.
Until encryption is completed, the only available options for managing BitLocker involve manipulation of the
password protecting the operating system volume, backing up the recovery key, and turning BitLocker off.
Data volume
Encrypting data volumes using the BitLocker control panel interface works in a similar fashion to encryption of the
operating system volumes. Users select Turn on BitLocker within the control panel to begin the BitLocker Drive
Encryption wizard. Unlike for operating system volumes, data volumes are not required to pass any configuration
tests for the wizard to proceed. Upon launching the wizard, a choice of authentication methods to unlock the drive
appears. The available options are password and smart card and automatically unlock this drive on this
computer. Disabled by default, the latter option will unlock the data volume without user input when the
operating system volume is unlocked.
After selecting the desired authentication method and choosing Next, the wizard presents options for storage of
the recovery key. These options are the same as for operating system volumes. With the recovery key saved,
selecting Next in the wizard will show available options for encryption. These options are the same as for
operating system volumes; used disk space only and full drive encryption. If the volume being encrypted is
new or empty, it is recommended that used space only encryption is selected.
With an encryption method chosen, a final confirmation screen displays before beginning the encryption process.
Selecting Start encrypting will begin encryption.
Encryption status displays in the notification area or within the BitLocker control panel.
OneDrive option
There is a new option for storing the BitLocker recovery key using the OneDrive. This option requires that
computers are not members of a domain and that the user is using a Microsoft Account. Local accounts do not
give the option to utilize OneDrive. Using the OneDrive option is the default, recommended recovery key storage
method for computers that are not joined to a domain.
Users can verify the recovery key was saved properly by checking their OneDrive for the BitLocker folder which is
created automatically during the save process. The folder will contain two files, a readme.txt and the recovery key.
For users storing more than one recovery password on their OneDrive, they can identify the required recovery
key by looking at the file name. The recovery key ID is appended to the end of the file name.
Using BitLocker within Windows Explorer
Windows Explorer allows users to launch the BitLocker Drive Encryption wizard by right clicking on a volume and
selecting Turn On BitLocker. This option is available on client computers by default. On servers, you must first
install the BitLocker and Desktop-Experience features for this option to be available. After selecting Turn on
BitLocker, the wizard works exactly as it does when launched using the BitLocker control panel.

Down-level compatibility
The following table shows the compatibility matrix for systems that have been BitLocker enabled then presented
to a different version of Windows.
Table 1: Cross compatibility for Windows 10, Windows 8.1, Windows 8, and Windows 7 encrypted volumes

Encryption Type Windows 10 and Windows 8 Windows 7

Windows 8.1

Fully encrypted on Presents as fully N/A Presented as fully

Windows 8 encrypted encrypted

Used Disk Space Only Presents as encrypt on N/A Presented as fully

encrypted on Windows write encrypted
8

Fully encrypted volume Presents as fully Presented as fully N/A

from Windows 7 encrypted encrypted

Partially encrypted Windows 10 and Windows 8 will complete N/A

volume from Windows 7 Windows 8.1 will encryption regardless of
complete encryption policy
regardless of policy

Encrypting volumes using the manage-bde command line interface

Manage-bde is a command-line utility that can be used for scripting BitLocker operations. Manage-bde offers
additional options not displayed in the BitLocker control panel. For a complete list of the options, see Manage-bde.
Manage-bde offers a multitude of wider options for configuring BitLocker. This means that using the command
syntax may require care and possibly later customization by the user. For example, using just the manage-bde -on
command on a data volume will fully encrypt the volume without any authenticating protectors. A volume
encrypted in this manner still requires user interaction to turn on BitLocker protection, even though the command
successfully completed because an authentication method needs to be added to the volume for it to be fully
protected. Command line users need to determine the appropriate syntax for a given situation. The following
section covers general encryption for operating system volumes and data volumes.
Operating system volume
Listed below are examples of basic valid commands for operating system volumes. In general, using only the
manage-bde -on <drive letter> command will encrypt the operating system volume with a TPM -only protector
and no recovery key. However, many environments require more secure protectors such as passwords or PIN and
expect to be able to recover information with a recovery key.
Determining volume status
A good practice when using manage-bde is to determine the volume status on the target system. Use the
following command to determine volume status:
manage-bde -status

This command returns the volumes on the target, current encryption status and volume type (operating system or
data) for each volume. Using this information, users can determine the best encryption method for their
environment.
Enabling BitLocker without a TPM
For example, suppose that you want to enable BitLocker on a computer without a TPM chip. To properly enable
BitLocker for the operating system volume, you will need to use a USB flash drive as a startup key to boot (in this
example, the drive letter E ). You would first create the startup key needed for BitLocker using the –protectors
option and save it to the USB drive on E: and then begin the encryption process. You will need to reboot the
computer when prompted to complete the encryption process.

manage-bde –protectors -add C: -startupkey E:

manage-bde -on C:

Enabling BitLocker with a TPM only

It is possible to encrypt the operating system volume without any defined protectors using manage-bde. The
command to do this is:
manage-bde -on C:

This will encrypt the drive using the TPM as the protector. If a user is unsure of the protector for a volume, they
can use the -protectors option in manage-bde to list this information with the command:
manage-bde -protectors -get <volume>

Provisioning BitLocker with two protectors

Another example is a user on non-TPM hardware who wishes to add a password and SID -based protector to the
operating system volume. In this instance, the user adds the protectors first. This is done with the command:
manage-bde -protectors -add C: -pw -sid <user or group>

This command will require the user to enter and then confirm the password protector before adding them to the
volume. With the protectors enabled on the volume, the user just needs to turn BitLocker on.
Data volume
Data volumes use the same syntax for encryption as operating system volumes but they do not require protectors
for the operation to complete. Encrypting data volumes can be done using the base command:
manage-bde -on <drive letter> or users can choose to add protectors to the volume. It is recommended that at
least one primary protector and a recovery protector be added to a data volume.
Enabling BitLocker with a password
A common protector for a data volume is the password protector. In the example below, we add a password
protector to the volume and turn BitLocker on.

manage-bde -protectors -add -pw C:

manage-bde -on C:

Encrypting volumes using the BitLocker Windows PowerShell cmdlets

Windows PowerShell cmdlets provide an alternative way to work with BitLocker. Using Windows PowerShell's
scripting capabilities, administrators can integrate BitLocker options into existing scripts with ease. The list below
displays the available BitLocker cmdlets.

Name Parameters

Add-BitLockerKeyProtector -ADAccountOrGroup
-ADAccountOrGroupProtector
-Confirm
-MountPoint
-Password
-PasswordProtector
-Pin
-RecoveryKeyPath
-RecoveryKeyProtector
-RecoveryPassword
-RecoveryPasswordProtector
-Service
-StartupKeyPath
-StartupKeyProtector
-TpmAndPinAndStartupKeyProtector
-TpmAndPinProtector
-TpmAndStartupKeyProtector
-TpmProtector
-WhatIf

Backup-BitLockerKeyProtector -Confirm
-KeyProtectorId
-MountPoint
-WhatIf

Disable-BitLocker -Confirm
-MountPoint
-WhatIf

Disable-BitLockerAutoUnlock -Confirm
-MountPoint
-WhatIf
Enable-BitLocker -AdAccountOrGroup
-AdAccountOrGroupProtector
-Confirm
-EncryptionMethod
-HardwareEncryption
-Password
-PasswordProtector
-Pin
-RecoveryKeyPath
-RecoveryKeyProtector
-RecoveryPassword
-RecoveryPasswordProtector
-Service
-SkipHardwareTest
-StartupKeyPath
-StartupKeyProtector
-TpmAndPinAndStartupKeyProtector
-TpmAndPinProtector
-TpmAndStartupKeyProtector
-TpmProtector
-UsedSpaceOnly
-WhatIf

Enable-BitLockerAutoUnlock -Confirm
-MountPoint
-WhatIf

Get-BitLockerVolume -MountPoint

Lock-BitLocker -Confirm
-ForceDismount
-MountPoint
-WhatIf

Remove-BitLockerKeyProtector -Confirm
-KeyProtectorId
-MountPoint
-WhatIf
 Resume-BitLocker -Confirm
-MountPoint
-WhatIf

Suspend-BitLocker -Confirm
-MountPoint
-RebootCount
-WhatIf

Unlock-BitLocker -AdAccountOrGroup
-Confirm
-MountPoint
-Password
-RecoveryKeyPath
-RecoveryPassword
-RecoveryPassword
-WhatIf

Similar to manage-bde, the Windows PowerShell cmdlets allow configuration beyond the options offered in the
control panel. As with manage-bde, users need to consider the specific needs of the volume they are encrypting
prior to running Windows PowerShell cmdlets. A good initial step is to determine the current state of the
volume(s) on the computer. You can do this using the Get-BitLocker volume cmdlet. The output from this cmdlet
displays information on the volume type, protectors, protection status, and other useful information. Occasionally,
all protectors may not be shown when using Get-BitLockerVolume due to lack of space in the output display. If
you do not see all of the protectors for a volume, you can use the Windows PowerShell pipe command (|) to
format a listing of the protectors.

Note: In the event that there are more than four protectors for a volume, the pipe command may run out of
display space. For volumes with more than four protectors, use the method described in the section below to
generate a listing of all protectors with protector ID.

Get-BitLockerVolume C: | fl

If you wanted to remove the existing protectors prior to provisioning BitLocker on the volume, you can utilize the
Remove-BitLockerKeyProtector cmdlet. Accomplishing this requires the GUID associated with the protector to be
removed. A simple script can pipe the values of each Get-BitLockerVolume return out to another variable as
seen below:

$vol = Get-BitLockerVolume
$keyprotectors = $vol.KeyProtector

Using this, we can display the information in the $keyprotectors variable to determine the GUID for each
protector. Using this information, we can then remove the key protector for a specific volume using the command:

Remove-BitLockerKeyProtector <volume>: -KeyProtectorID "{GUID}"

 Note: The BitLocker cmdlet requires the key protector GUID enclosed in quotation marks to execute. Ensure
the entire GUID, with braces, is included in the command.

Operating system volume

Using the BitLocker Windows PowerShell cmdlets is similar to working with the manage-bde tool for encrypting
operating system volumes. Windows PowerShell offers users a lot of flexibility. For example, users can add the
desired protector as part command for encrypting the volume. Below are examples of common user scenarios and
steps to accomplish them using the BitLocker cmdlets for Windows PowerShell. To enable BitLocker with just the
TPM protector. This can be done using the command:

Enable-BitLocker C:

The example below adds one additional protector, the StartupKey protectors, and chooses to skip the BitLocker
hardware test. In this example, encryption starts immediately without the need for a reboot.

Enable-BitLocker C: -StartupKeyProtector -StartupKeyPath <path> -SkipHardwareTest

Data volume
Data volume encryption using Windows PowerShell is the same as for operating system volumes. You should add
the desired protectors prior to encrypting the volume. The following example adds a password protector to the E:
volume using the variable $pw as the password. The $pw variable is held as a SecureString value to store the user
defined password. Last, encryption begins.

$pw = Read-Host -AsSecureString

<user inputs password>
Enable-BitLockerKeyProtector E: -PasswordProtector -Password $pw

Using a SID based protector in Windows PowerShell

The ADAccountOrGroup protector is an Active Directory SID -based protector. This protector can be added to both
operating system and data volumes, although it does not unlock operating system volumes in the pre-boot
environment. The protector requires the SID for the domain account or group to link with the protector. BitLocker
can protect a cluster-aware disk by adding a SID -based protector for the Cluster Name Object (CNO ) that lets the
disk properly failover and be unlocked to any member computer of the cluster.

Warning: The SID -based protector requires the use of an additional protector (such as TPM, PIN, recovery
key, etc.) when used on operating system volumes.

To add an ADAccountOrGroup protector to a volume requires either the actual domain SID or the group name
preceded by the domain and a backslash. In the example below, the CONTOSO\Administrator account is added as
a protector to the data volume G.

Enable-BitLocker G: -AdAccountOrGroupProtector -AdAccountOrGroup CONTOSO\Administrator

For users who wish to use the SID for the account or group, the first step is to determine the SID associated with
the account. To get the specific SID for a user account in Windows PowerShell, use the following command:

get-aduser -filter {samaccountname -eq "administrator"}

Note: Use of this command requires the RSAT-AD -PowerShell feature.

 Tip: In addition to the Windows PowerShell command above, information about the locally logged on user
and group membership can be found using: WHOAMI /ALL. This does not require the use of additional
features.

In the example below, the user wishes to add a domain SID based protector to the previously encrypted operating
system volume. The user knows the SID for the user account or group they wish to add and uses the following
command:

Add-BitLockerKeyProtector C: -ADAccountOrGroupProtector -ADAccountOrGroup "<SID>"

Note: Active Directory-based protectors are normally used to unlock Failover Cluster enabled volumes.

Checking BitLocker status

To check the BitLocker status of a particular volume, administrators can look at the status of the drive in the
BitLocker control panel applet, Windows Explorer, manage-bde command line tool, or Windows PowerShell
cmdlets. Each option offers different levels of detail and ease of use. We will look at each of the available methods
in the following section.
Checking BitLocker status with the control panel
Checking BitLocker status with the control panel is the most common method used by most users. Once opened,
the status for each volume will display next to the volume description and drive letter. Available status return
values with the control panel include:

STATUS DESCRIPTION

On BitLocker is enabled for the volume

Off BitLocker is not enabled for the volume

Suspended BitLocker is suspended and not actively protecting the volume

Waiting for Activation BitLocker is enabled with a clear protector key and requires
further action to be fully protected

If a drive is pre-provisioned with BitLocker, a status of "Waiting for Activation" displays with a yellow exclamation
icon on volume E. This status means that there was only a clear protector used when encrypting the volume. In
this case, the volume is not in a protected state and needs to have a secure key added to the volume before the
drive is fully protected. Administrators can use the control panel, manage-bde tool, or WMI APIs to add an
appropriate key protector. Once complete, the control panel will update to reflect the new status. Using the control
panel, administrators can choose Turn on BitLocker to start the BitLocker Drive Encryption wizard and add a
protector, like PIN for an operating system volume (or password if no TPM exists), or a password or smart card
protector to a data volume. The drive security window displays prior to changing the volume status. Selecting
Activate BitLocker will complete the encryption process.
Once BitLocker protector activation is completed, the completion notice is displayed.
Checking BitLocker status with manage -bde
Administrators who prefer a command line interface can utilize manage-bde to check volume status. Manage-bde
is capable of returning more information about the volume than the graphical user interface tools in the control
panel. For example, manage-bde can display the BitLocker version in use, the encryption type, and the protectors
associated with a volume.
To check the status of a volume using manage-bde, use the following command:

manage-bde -status <volume>

Note: If no volume letter is associated with the -status command, all volumes on the computer display their
status.

Checking BitLocker status with Windows PowerShell

Windows PowerShell commands offer another way to query BitLocker status for volumes. Like manage-bde,
Windows PowerShell includes the advantage of being able to check the status of a volume on a remote computer.
Using the Get-BitLockerVolume cmdlet, each volume on the system will display its current BitLocker status. To get
information that is more detailed on a specific volume, use the following command:

Get-BitLockerVolume <volume> -Verbose | fl

This command will display information about the encryption method, volume type, key protectors, etc.
Provisioning BitLocker during operating system deployment
Administrators can enable BitLocker prior to operating system deployment from the Windows Pre-installation
Environment. This is done with a randomly generated clear key protector applied to the formatted volume and
encrypting the volume prior to running the Windows setup process. If the encryption uses the Used Disk Space
Only option described later in this document, this step takes only a few seconds and incorporates well into regular
deployment processes.
Decrypting BitLocker volumes
Decrypting volumes removes BitLocker and any associated protectors from the volumes. Decryption should occur
when protection is no longer required. BitLocker decryption should not occur as a troubleshooting step. BitLocker
can be removed from a volume using the BitLocker control panel applet, manage-bde, or Windows PowerShell
cmdlets. We will discuss each method further below.
Decrypting volumes using the BitLocker control panel applet
BitLocker decryption using the control panel is done using a Wizard. The control panel can be called from
Windows Explorer or by opening the directly. After opening the BitLocker control panel, users will select the Turn
off BitLocker option to begin the process. Once selected, the user chooses to continue by clicking the confirmation
dialog. With Turn off BitLocker confirmed, the drive decryption process will begin and report status to the control
panel.
The control panel does not report decryption progress but displays it in the notification area of the task bar.
Selecting the notification area icon will open a modal dialog with progress.
Once decryption is complete, the drive will update its status in the control panel and is available for encryption.
Decrypting volumes using the manage -bde command line interface
Decrypting volumes using manage-bde is very straightforward. Decryption with manage-bde offers the
advantage of not requiring user confirmation to start the process. Manage-bde uses the -off command to start the
decryption process. A sample command for decryption is:

manage-bde -off C:

This command disables protectors while it decrypts the volume and removes all protectors when decryption is
complete. If a user wishes to check the status of the decryption, they can use the following command:
 manage-bde -status C:

Decrypting volumes using the BitLocker Windows PowerShell cmdlets

Decryption with Windows PowerShell cmdlets is straightforward, similar to manage-bde. The additional
advantage Windows PowerShell offers is the ability to decrypt multiple drives in one pass. In the example below,
the user has three encrypted volumes, which they wish to decrypt.
Using the Disable-BitLocker command, they can remove all protectors and encryption at the same time without
the need for additional commands. An example of this command is:

Disable-BitLocker

If a user did not want to input each mount point individually, using the -MountPoint parameter in an array can
sequence the same command into one line without requiring additional user input. An example command is:

Disable-BitLocker -MountPoint E:,F:,G:

See also
Prepare your organization for BitLocker: Planning and p\olicies
BitLocker recovery guide
BitLocker: How to enable Network Unlock
BitLocker overview
 BitLocker: How to deploy on Windows Server 2012
and later
2/7/2018 • 5 minutes to read • Edit Online

Applies to
Windows 10
This topic for the IT professional explains how to deploy BitLocker on Windows Server 2012 and later.
For all Windows Server editions, BitLocker must be installed using Server Manager. However, you can still
provision BitLocker before the server operating system is installed as part of your deployment.

Installing BitLocker
BitLocker requires administrator privileges on the server to install. You can install BitLocker either by using Server
Manager or Windows PowerShell cmdlets.
To install BitLocker using Server Manager
To install BitLocker using Windows PowerShell
To install BitLocker using Server Manager
1. Open Server Manager by selecting the Server Manager icon or running servermanager.exe.
2. Select Manage from the Server Manager Navigation bar and select Add Roles and Features to start the
Add Roles and Features Wizard.
3. With the Add Roles and Features Wizard open, select Next at the Before you begin pane (if shown).
4. Select Role-based or feature-based installation on the Installation type pane of the Add Roles and
Features Wizard pane and select Next to continue.
5. Select the Select a server from the server pool option in the Server Selection pane and confirm the
server for the BitLocker feature install.
6. Server roles and features install using the same wizard in Server Manager. Select Next on the Server Roles
pane of the Add Roles and Features wizard to proceed to the Features pane.
7. Select the check box next to BitLocker Drive Encryption within the Features pane of the Add Roles and
Features Wizard. The wizard will show the additional management features available for BitLocker. If you
do not want to install these features, deselect the Include management tools option and select Add
Features. Once optional features selection is complete, select Next to proceed in the wizard.

Note: The Enhanced Storage feature is a required feature for enabling BitLocker. This feature enables
support for Encrypted Hard Drives on capable systems.

8. Select Install on the Confirmation pane of the Add Roles and Features Wizard to begin BitLocker
feature installation. The BitLocker feature requires a restart to complete. Selecting the Restart the
destination server automatically if required option in the Confirmation pane will force a restart of the
computer after installation is complete.
9. If the Restart the destination server automatically if required check box is not selected, the Results pane
of the Add Roles and Features Wizard will display the success or failure of the BitLocker feature installation.
If required, a notification of additional action necessary to complete the feature installation, such as the restart
of the computer, will be displayed in the results text.
To install BitLocker using Windows PowerShell
Windows PowerShell offers administrators another option for BitLocker feature installation. Windows PowerShell
installs features using the servermanager or dism module; however, the servermanager and dism modules do
not always share feature name parity. Because of this, it is advisable to confirm the feature or role name prior to
installation.

Note: You must restart the server to complete the installation of BitLocker.

Using the servermanager module to install BitLocker

The servermanager Windows PowerShell module can use either the Install-WindowsFeature or
Add-WindowsFeature to install the BitLocker feature. The Add-WindowsFeature cmdlet is merely a stub to the
Install-WindowsFeature . This example uses the Install-WindowsFeature cmdlet. The feature name for BitLocker in
the servermanager module is BitLocker . This can be determined using the Get-WindowsFeature cmdlet with a
query such as:

Get-WindowsFeature Bit

The results of this command displays a table of all of the feature names beginning with “Bit” as their prefix. This
allows you to confirm that the feature name is BitLocker for the BitLocker feature.
By default, installation of features in Windows PowerShell does not include optional sub-features or management
tools as part of the install process. This can be seen using the -WhatIf option in Windows PowerShell.

Install-WindowsFeature BitLocker -WhatIf

The results of this command show that only the BitLocker Drive Encryption feature installs using this command.
To see what would be installed with the BitLocker feature including all available management tools and sub-
features, use the following command:

Install-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools -WhatIf | fl

The result of this command displays the following list of all the administration tools for BitLocker that would be
installed along with the feature, including tools for use with Active Directory Domain Services (AD DS ) and Active
Directory Lightweight Directory Services (AD LDS ).
BitLocker Drive Encryption
BitLocker Drive Encryption Tools
BitLocker Drive Encryption Administration Utilities
BitLocker Recovery Password Viewer
AD DS Snap-Ins and Command-Line Tools
AD DS Tools
AD DS and AD LDS Tools
The command to complete a full installation of the BitLocker feature with all available features and then rebooting
the server at completion is:

Install-WindowsFeature BitLocker -IncludeAllSubFeature -IncludeManagementTools -Restart

Important: Installing the BitLocker feature using Windows PowerShell does not install the Enhanced Storage
 feature. Administrators wishing to support Encrypted Hard Drives in their environment will need to install the
Enhanced Storage feature separately.

Using the dism module to install BitLocker

The dism Windows PowerShell module uses the Enable-WindowsOptionalFeature cmdlet to install features. The
BitLocker feature name for BitLocker is BitLocker . The dism module does not support wildcards when searching
for feature names. To list feature names for the dism module, use the Get-WindowsOptionalFeatures cmdlet. The
following command will list all of the optional features in an online (running) operating system.

Get-WindowsOptionalFeature -Online | ft

From this output, we can see that there are three BitLocker related optional feature names: BitLocker, BitLocker-
Utilities and BitLocker-NetworkUnlock. To install the BitLocker feature, the BitLocker and BitLocker-Utilities
features are the only required items.
To install BitLocker using the dism module, use the following command:

Enable-WindowsOptionalFeature -Online -FeatureName BitLocker -All

This command will prompt the user for a reboot. The Enable-WindowsOptionalFeature cmdlet does not offer
support for forcing a reboot of the computer. This command does not include installation of the management
tools for BitLocker. For a complete installation of BitLocker and all available management tools, use the following
command:

Enable-WindowsOptionalFeature -Online -FeatureName BitLocker, BitLocker-Utilities -All

More information
BitLocker overview
BitLocker frequently asked questions (FAQ )
Prepare your organization for BitLocker: Planning and policies
BitLocker: How to enable Network Unlock
 BitLocker Management for Enterprises
1/25/2019 • 5 minutes to read • Edit Online

The ideal for BitLocker management is to eliminate the need for IT admins to set management policies using tools
or other mechanisms by having Windows perform tasks that are more practical to automate. This vision leverages
modern hardware developments. The growth of TPM 2.0, Secure Boot, and other hardware improvements, for
example, has helped to alleviate the support burden on the helpdesk, and we are seeing a consequent decrease in
support call volumes, yielding improved user satisfaction. Windows continues to be the focus for new features and
improvements for built-in encryption management, such as automatically enabling encryption on devices that
support Modern Standby beginning with Windows 8.1.
Though much Windows BitLocker documentation has been published, customers frequently ask for
recommendations and pointers to specific, task-oriented documentation that is both easy to digest and focused on
how to deploy and manage BitLocker. This article links to relevant documentation, products, and services to help
answer this and other related frequently-asked questions, and also provides BitLocker recommendations for
different types of computers.

Managing domain-joined computers and moving to cloud

Companies that image their own computers using Microsoft System Center 2012 Configuration Manager SP1
(SCCM ) or later can use an existing task sequence to pre-provision BitLocker encryption while in Windows
Preinstallation Environment (WinPE ) and can then enable protection. This can help ensure that computers are
encrypted from the start, even before users receive them. As part of the imaging process, a company could also
decide to use SCCM to pre-set any desired BitLocker Group Policy.
Enterprises can use Microsoft BitLocker Administration and Monitoring (MBAM ) to manage client computers with
BitLocker that are domain-joined on-premises until mainstream support ends in July 2019 or they can receive
extended support until July 2024. Thus, over the next few years, a good strategy for enterprises will be to plan and
move to cloud-based management for BitLocker. Refer to the PowerShell examples to see how to store recovery
keys in Azure Active Directory (Azure AD ).

Managing devices joined to Azure Active Directory

Devices joined to Azure AD are managed using Mobile Device Management (MDM ) policy from an MDM solution
such as Microsoft Intune. BitLocker Device Encryption status can be queried from managed machines via the Policy
Configuration Settings Provider (CSP ), which reports on whether BitLocker Device Encryption is enabled on the
device. Compliance with BitLocker Device Encryption policy can be a requirement for Conditional Access to
services like Exchange Online and SharePoint Online.
Starting with Windows 10 version 1703 (also known as the Windows Creators Update), the enablement of
BitLocker can be triggered over MDM either by the Policy CSP or the BitLocker CSP. The BitLocker CSP adds
policy options that go beyond ensuring that encryption has occurred, and is available on computers that run
Windows 10 Business or Enterprise editions and on Windows Phones.
For hardware that is compliant with Modern Standby and HSTI, when using either of these features, BitLocker
Device Encryption is automatically turned on whenever the user joins a device to Azure AD. Azure AD provides a
portal where recovery keys are also backed up, so users can retrieve their own recovery key for self-service, if
required. For older devices that are not yet encrypted, beginning with Windows 10 version 1703 (the Windows 10
Creators Update), admins can use the BitLocker CSP to trigger encryption and store the recovery key in Azure AD.
Managing workplace-joined PCs and phones
For Windows PCs and Windows Phones that enroll using Connect to work or school account, BitLocker Device
Encryption is managed over MDM, the same as devices joined to Azure AD.

Managing servers
Servers are often installed, configured, and deployed using PowerShell, so the recommendation is to also use
PowerShell to enable BitLocker on a server, ideally as part of the initial setup. BitLocker is an Optional Component
(OC ) in Windows Server, so follow the directions in BitLocker: How to deploy on Windows Server 2012 and later
to add the BitLocker OC.
The Minimal Server Interface is a prerequisite for some of the BitLocker administration tools. On a Server Core
installation, you must add the necessary GUI components first. The steps to add shell components to Server Core
are described in Using Features on Demand with Updated Systems and Patched Images and How to update local
source media to add roles and features.
If you are installing a server manually, such as a stand-alone server, then choosing Server with Desktop Experience
is the easiest path because you can avoid performing the steps to add a GUI to Server Core.
Additionally, lights out data centers can take advantage of the enhanced security of a second factor while avoiding
the need for user intervention during reboots by optionally using a combination of BitLocker (TPM+PIN ) and
BitLocker Network Unlock. BitLocker Network Unlock brings together the best of hardware protection, location
dependence, and automatic unlock, while in the trusted location. For the configuration steps, see BitLocker: How to
enable Network Unlock.
For more information, see the Bitlocker FAQs article and other useful links in Related Articles.  

PowerShell examples
For Azure AD -joined computers, including virtual machines, the recovery password should be stored in Azure
Active Directory.
Example: Use PowerShell to add a recovery password and back it up to Azure AD before enabling BitLocker

PS C:\>Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector

PS C:\>$BLV = Get-BitLockerVolume -MountPoint "C:"

PS C:\>BackupToAAD-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $BLV.KeyProtector[0].KeyProtectorId

For domain-joined computers, including servers, the recovery password should be stored in Active Directory
Domain Services (AD DS ).
Example: Use PowerShell to add a recovery password and back it up to AD DS before enabling BitLocker

PS C:\>Add-BitLockerKeyProtector -MountPoint "C:" -RecoveryPasswordProtector

PS C:\>$BLV = Get-BitLockerVolume -MountPoint "C:"

PS C:\>Backup-BitLockerKeyProtector -MountPoint "C:" -KeyProtectorId $BLV.KeyProtector[0].KeyProtectorId

Subsequently, you can use PowerShell to enable BitLocker.

Example: Use PowerShell to enable BitLocker with a TPM protector
 PS C:\>Enable-BitLocker -MountPoint "D:" -EncryptionMethod XtsAes256 -UsedSpaceOnly -TpmProtector

Example: Use PowerShell to enable BitLocker with a TPM+PIN protector, in this case with a PIN set to 123456

PS C:\>$SecureString = ConvertTo-SecureString "123456" -AsPlainText -Force

PS C:\> Enable-BitLocker -MountPoint "C:" -EncryptionMethod XtsAes256 -UsedSpaceOnly -Pin $SecureString -

TPMandPinProtector

Related Articles
BitLocker: FAQs
Microsoft BitLocker Administration and Management (MBAM )
Overview of BitLocker Device Encryption in Windows 10
System Center 2012 Configuration Manager SP1 (Pre-provision BitLocker task sequence)
Enable BitLocker task sequence
BitLocker Group Policy Reference
Microsoft Intune (Overview )
Configuration Settings Providers (Policy CSP: See Security-RequireDeviceEncryption)
BitLocker CSP

Windows Server setup tools

Windows Server Installation Options
How to update local source media to add roles and features
How to add or remove optional components on Server Core (Features on Demand )
BitLocker: How to deploy on Windows Server 2012 and newer
BitLocker: How to enable Network Unlock
Shielded VMs and Guarded Fabric

Powershell
BitLocker cmdlets for Windows PowerShell
Surface Pro Specifications
 BitLocker: How to enable Network Unlock
8/7/2018 • 20 minutes to read • Edit Online

Applies to
Windows 10
This topic for the IT professional describes how BitLocker Network Unlock works and how to configure it.
Network Unlock was introduced in Windows 8 and Windows Server 2012 as a BitLocker protector option for
operating system volumes. Network Unlock enables easier management for BitLocker enabled desktops and
servers in a domain environment by providing automatic unlock of operating system volumes at system reboot
when connected to a wired corporate network. This feature requires the client hardware to have a DHCP driver
implemented in its UEFI firmware. Without Network Unlock, operating system volumes protected by TPM+PIN
protectors require a PIN to be entered when a computer reboots or resumes from hibernation (for example, by
Wake on LAN ). This can make it difficult to enterprises to roll out software patches to unattended desktops and
remotely administered servers.
Network Unlock allows BitLocker-enabled systems with TPM+PIN and that meet the hardware requirements to
boot into Windows without user intervention. Network Unlock works in a similar fashion to the
TPM+StartupKey at boot. Rather than needing to read the StartupKey from USB media, however, the key for
Network Unlock is composed from a key stored in the TPM and an encrypted network key that is sent to the
server, decrypted and returned to the client in a secure session.
This topic contains:
Network Unlock core requirements
Network Unlock sequence
Configure Network Unlock
Create the certificate template for Network Unlock
Turning off Network Unlock
Update Network Unlock certificates
Troubleshoot Network Unlock
Configure Network Unlock on unsupported systems

Network Unlock core requirements

Network Unlock must meet mandatory hardware and software requirements before the feature can
automatically unlock domain joined systems. These requirements include:
You must be running at least Windows 8 or Windows Server 2012.
Any supported operating system with UEFI DHCP drivers can be Network Unlock clients.
A server running the Windows Deployment Services (WDS ) role on any supported server operating system.
BitLocker Network Unlock optional feature installed on any supported server operating system.
A DHCP server, separate from the WDS server.
Properly configured public/private key pairing.
Network Unlock Group Policy settings configured.
The network stack must be enabled to use the Network Unlock feature. Equipment manufacturers deliver their
products in various states and with different BIOS menus, so you need to confirm that the network stack has
been enabled in the BIOS before starting the computer.

Note: To properly support DHCP within UEFI, the UEFI-based system should be in native mode without a
compatibility support module (CSM ) enabled.

For Network Unlock to work reliably on computers running Windows 8 and later, the first network adapter on
the computer, usually the onboard adapter, must be configured to support DHCP and used for Network Unlock.
This is especially worth noting when you have multiple adapters, and you wish to configure one without DHCP,
such as for a lights-out management protocol. This configuration is necessary because Network Unlock will stop
enumerating adapters when it reaches one with a DHCP port failure for any reason. Thus, if the first enumerated
adapter does not support DHCP, is not plugged into the network, or fails to report availability of the DHCP port
for any reason, then Network Unlock will fail.
The Network Unlock server component installs on supported versions of Windows Server 2012 and later as a
Windows feature using Server Manager or Windows PowerShell cmdlets. The feature name is BitLocker
Network Unlock in Server Manager and BitLocker-NetworkUnlock in Windows PowerShell. This feature is a
core requirement.
Network Unlock requires Windows Deployment Services (WDS ) in the environment where the feature will be
utilized. Configuration of the WDS installation is not required; however, the WDS service needs to be running on
the server.
The network key is stored on the system drive along with an AES 256 session key, and encrypted with the 2048-
bit RSA public key of the unlock server's certificate. The network key is decrypted with the help of a provider on
a supported version of Windows Server running WDS, and returned encrypted with its corresponding session
key.

Network Unlock sequence

The unlock sequence starts on the client side, when the Windows boot manager detects the existence of
Network Unlock protector. It leverages the DHCP driver in UEFI to obtain an IP address for IPv4 and then
broadcasts a vendor-specific DHCP request that contains the network key and a session key for the reply, all
encrypted by the server's Network Unlock certificate, as described above. The Network Unlock provider on the
supported WDS server recognizes the vendor-specific request, decrypts it with the RSA private key, and returns
the network key encrypted with the session key via its own vendor-specific DHCP reply.
On the server side, the WDS server role has an optional plugin component, like a PXE provider, which is what
handles the incoming Network Unlock requests. The provider can also be configured with subnet restrictions,
which would require that the IP address provided by the client in the Network Unlock request belong to a
permitted subnet in order to release the network key to the client. In instances where the Network Unlock
provider is unavailable, BitLocker fails over to the next available protector to unlock the drive. In a typical
configuration, this means the standard TPM+PIN unlock screen is presented to unlock the drive.
The server side configuration to enable Network Unlock also requires provisioning a 2048-bit RSA
public/private key pair in the form of an X.509 certificate, and for the public key certificate to be distributed to
the clients. This certificate must be managed and deployed through the Group Policy editor directly on a domain
controller with at least a Domain Functional Level of Windows Server 2012. This certificate is the public key that
encrypts the intermediate network key (which is one of the two secrets required to unlock the drive; the other
secret is stored in the TPM ).
Phases in the Network Unlock process
1. The Windows boot manager detects that a Network Unlock protector exists in the BitLocker configuration.
2. The client computer uses its DHCP driver in the UEFI to obtain a valid IPv4 IP address.
3. The client computer broadcasts a vendor-specific DHCP request that contains the Network Key (a 256-bit
intermediate key) and an AES -256 session key for the reply. Both of these keys are encrypted using the 2048-
bit RSA Public Key of the Network Unlock certificate from the WDS server.
4. The Network Unlock provider on the WDS server recognizes the vendor-specific request.
5. The provider decrypts it with the WDS server’s BitLocker Network Unlock certificate RSA private key.
6. The WDS provider then returns the network key encrypted with the session key using its own vendor-specific
DHCP reply to the client computer. This forms an intermediate key.
7. The returned intermediate key is then combined with another local 256-bit intermediate key that can only be
decrypted by the TPM.
8. This combined key is used to create an AES -256 key that unlocks the volume.
9. Windows continues the boot sequence.

Configure Network Unlock

The following steps allow an administrator to configure Network Unlock in a domain where the Domain
Functional Level is at least Windows Server 2012.
Install the WDS Server role
The BitLocker Network Unlock feature will install the WDS role if it is not already installed. If you want to install
it separately before you install BitLocker Network Unlock you can use Server Manager or Windows PowerShell.
To install the role using Server Manager, select the Windows Deployment Services role in Server Manager.
To install the role using Windows PowerShell, use the following command:

Install-WindowsFeature WDS-Deployment

You must configure the WDS server so that it can communicate with DHCP (and optionally Active Directory
Doman Services) and the client computer. You can do using the WDS management tool, wdsmgmt.msc, which
starts the Windows Deployment Services Configuration Wizard.
Confirm the WDS Service is running
 To confirm the WDS service is running, use the Services Management Console or Windows PowerShell. To
confirm the service is running in Services Management Console, open the console using services.msc and
check the status of the Windows Deployment Services service.
To confirm the service is running using Windows PowerShell, use the following command:

Get-Service WDSServer

Install the Network Unlock feature

To install the Network Unlock feature, use Server Manager or Windows PowerShell. To install the feature using
Server Manager, select the BitLocker Network Unlock feature in the Server Manager console.
To install the feature using Windows PowerShell, use the following command:

Install-WindowsFeature BitLocker-NetworkUnlock

Create the certificate template for Network Unlock

A properly configured Active Directory Services Certification Authority can use this certificate template to create
and issue Network Unlock certificates.
1. Open the Certificates Template snap-in (certtmpl.msc).
2. Locate the User template. Right-click the template name and select Duplicate Template.
3. On the Compatibility tab, change the Certification Authority and Certificate recipient fields to
Windows Server 2012 and Windows 8 respectively. Ensure the Show resulting changes dialog box is
selected.
4. Select the General tab of the template. The Template display name and Template name should clearly
identify that the template will be used for Network Unlock. Clear the checkbox for the Publish certificate in
Active Directory option.
5. Select the Request Handling tab. Select Encryption from the Purpose drop down menu. Ensure the Allow
private key to be exported option is selected.
6. Select the Cryptography tab. Set the Minimum key size to 2048. (Any Microsoft cryptographic provider
that supports RSA can be used for this template, but for simplicity and forward compatibility we recommend
using the Microsoft Software Key Storage Provider.)
7. Select the Requests must use one of the following providers option and clear all options except for the
cryptography provider you selected, such as the Microsoft Software Key Storage Provider.
8. Select the Subject Name tab. Select Supply in the request. Select OK if the certificate templates pop-up
dialog appears.
9. Select the Issuance Requirements tab. Select both CA certificate manager approval and Valid existing
certificate options.
10. Select the Extensions tab. Select Application Policies and choose Edit….
11. In the Edit Application Policies Extension options dialog box, select Client Authentication, Encrypting
File System, and Secure Email and choose Remove.
12. On the Edit Application Policies Extension dialog box, select Add.
13. On the Add Application Policy dialog box, select New. In the New Application Policy dialog box
enter the following information in the space provided and then click OK to create the BitLocker Network
Unlock application policy:
Name: BitLocker Network Unlock
Object Identifier: 1.3.6.1.4.1.311.67.1.1
14. Select the newly created BitLocker Network Unlock application policy and select OK.
15. With the Extensions tab still open, select the Edit Key Usage Extension dialog, select the Allow key
exchange only with key encryption (key encipherment) option. Select the Make this extension
critical option.
16. Select the Security tab. Confirm that the Domain Admins group has been granted Enroll permission.
17. Select OK to complete configuration of the template.
To add the Network Unlock template to the Certification Authority, open the Certification Authority snap-in
(certsrv.msc). Right-click the Certificate Templates item and choose New, Certificate Template to issue.
Select the previously created BitLocker Network Unlock certificate.
After adding the Network Unlock template to the Certification Authority, this certificate can be used to configure
BitLocker Network Unlock.
Create the Network Unlock certificate
Network Unlock can use imported certificates from an existing PKI infrastructure, or you can use a self-signed
certificate.
To enroll a certificate from an existing certification authority (CA), do the following:
1. Open Certificate Manager on the WDS server using certmgr.msc
2. Under the Certificates - Current User item, right-click Personal
3. Select All Tasks, then Request New Certificate
4. Select Next when the Certificate Enrollment wizard opens
5. Select Active Directory Enrollment Policy
6. Choose the certificate template created for Network Unlock on the Domain controller and select Enroll.
When prompted for more information, add the following attribute to the certificate:
Select the Subject Name pane and provide a friendly name value. It is suggested that this friendly
name include information for the domain or organizational unit for the certificate. For example
"BitLocker Network Unlock Certificate for Contoso domain"
7. Create the certificate. Ensure the certificate appears in the Personal folder.
8. Export the public key certificate for Network Unlock
a. Create a .cer file by right-clicking the previously created certificate, choosing All Tasks, then Export.
b. Select No, do not export the private key.
c. Select DER encoded binary X.509 and complete exporting the certificate to a file.
d. Give the file a name such as BitLocker-NetworkUnlock.cer.
9. Export the public key with a private key for Network Unlock
a. Create a .pfx file by right-clicking the previously created certificate, choosing All Tasks, then Export.
b. Select Yes, export the private key.
c. Complete the wizard to create the .pfx file.
To create a self-signed certificate, you can either use the New -SelfSignedCertificate cmdlet in Windows
PowerShell or use Certreq.
Windows PowerShell example:

New-SelfSignedCertificate -CertStoreLocation Cert:\LocalMachine\My -Subject "CN=BitLocker Network Unlock

certificate" -Provider "Microsoft Software Key Storage Provider" -KeyUsage KeyEncipherment -KeyUsageProperty
Decrypt,Sign -KeyLength 2048 -HashAlgorithm sha512 -TextExtension @("1.3.6.1.4.1.311.21.10=
{text}OID=1.3.6.1.4.1.311.67.1.1","2.5.29.37={text}1.3.6.1.4.1.311.67.1.1")

Certreq example:
1. Create a text file with an .inf extension. For example, notepad.exe BitLocker-NetworkUnlock.inf.
2. Add the following contents to the previously created file:

[NewRequest]
Subject="CN=BitLocker Network Unlock certificate"
ProviderType=0
MachineKeySet=True
Exportable=true
RequestType=Cert
KeyUsage="CERT_KEY_ENCIPHERMENT_KEY_USAGE"
KeyUsageProperty="NCRYPT_ALLOW_DECRYPT_FLAG | NCRYPT_ALLOW_SIGNING_FLAG"
KeyLength=2048
SMIME=FALSE
HashAlgorithm=sha512
[Extensions]
1.3.6.1.4.1.311.21.10 = "{text}"
_continue_ = "OID=1.3.6.1.4.1.311.67.1.1"
2.5.29.37 = "{text}"
_continue_ = "1.3.6.1.4.1.311.67.1.1"

3. Open an elevated command prompt and use the certreq tool to create a new certificate using the
following command, specifying the full path to the file created previously, along with the file name:

certreq -new BitLocker-NetworkUnlock.inf BitLocker-NetworkUnlock.cer

4. Verify the previous command properly created the certificate by confirming the .cer file exists.
5. Launch Certificates - Local Machine by running certlm.msc.
6. Create a .pfx file by opening the Certificates – Local Computer\Personal\Certificates path in the
navigation pane, right-clicking the previously imported certificate, selecting All Tasks, then Export. Follow
through the wizard to create the .pfx file.
Deploy the private key and certificate to the WDS server
With the certificate and key created, deploy them to the infrastructure to properly unlock systems. To deploy the
certificates, do the following:
1. On the WDS server, open a new MMC and add the certificates snap-in. Select the computer account and
local computer when given the options.
2. Right-click the Certificates (Local Computer) - BitLocker Drive Encryption Network Unlock item, choose All
Tasks, then Import.
3. In the File to Import dialog, choose the .pfx file created previously.
4. Enter the password used to create the .pfx and complete the wizard.
Configure Group Policy settings for Network Unlock
With certificate and key deployed to the WDS server for Network Unlock, the final step is to use Group Policy
settings to deploy the public key certificate to computers that you want to be able to unlock using the Network
Unlock key. Group Policy settings for BitLocker can be found under \Computer
Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption using the
Local Group Policy Editor or the Microsoft Management Console.
The following steps describe how to enable the Group Policy setting that is a requirement for configuring
Network Unlock.
1. Open Group Policy Management Console (gpmc.msc).
2. Enable the policy Require additional authentication at startup and select the Require startup PIN with
TPM option.
3. Turn on BitLocker with TPM+PIN protectors on all domain-joined computers.
The following steps describe how to deploy the required Group Policy setting:

Note: The Group Policy settings Allow network unlock at startup and Add Network Unlock
Certificate were introduced in Windows Server 2012.

1. Copy the .cer file created for Network Unlock to the domain controller.
2. On the domain controller, launch Group Policy Management Console (gpmc.msc).
3. Create a new Group Policy Object or modify an existing object to enable the Allow network unlock at
startup setting.
4. Deploy the public certificate to clients:
a. Within Group Policy Management Console, navigate to the following location: Computer
Configuration\Policies\Windows Settings\Security Settings\Public Key Policies\BitLocker
Drive Encryption Network Unlock Certificate.
b. Right-click the folder and choose Add Network Unlock Certificate.
c. Follow the wizard steps and import the .cer file that was copied earlier.

Note: Only one network unlock certificate can be available at a time. If a new certificate is required, delete
the current certificate before deploying a new one. The Network Unlock certificate is located in the
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\SystemCertificates\FVE_NKP key on the
client computer.

Require TPM+PIN protectors at startup

An additional step is for enterprises to use TPM+PIN protectors for an extra level of security. To require
TPM+PIN protectors in an environment, do the following:
1. Open Group Policy Management Console (gpmc.msc).
2. Enable the policy Require additional authentication at startup and select the Require startup PIN with
TPM option.
3. Turn on BitLocker with TPM+PIN protectors on all domain-joined computers.
Subnet policy configuration files on WDS Server (Optional)
By default, all clients with the correct Network Unlock Certificate and valid Network Unlock protectors that have
wired access to a Network Unlock-enabled WDS server via DHCP are unlocked by the server. A subnet policy
configuration file on the WDS server can be created to limit which subnet(s) Network Unlock clients can use to
unlock.
The configuration file, called bde-network-unlock.ini, must be located in the same directory as the Network
Unlock provider DLL (%windir%\System32\Nkpprov.dll) and it applies to both IPv6 and IPv4 DHCP
implementations. If the subnet configuration policy becomes corrupted, the provider will fail and stop
responding to requests.
The subnet policy configuration file must use a “[SUBNETS ]” section to identify the specific subnets. The named
subnets may then be used to specify restrictions in certificate subsections. Subnets are defined as simple name-
value pairs, in the common INI format, where each subnet has its own line, with the name on the left of the
equals sign, and the subnet identified on the right of the equal sign as a Classless Inter-Domain Routing (CIDR )
address or range. The key word “ENABLED” is disallowed for subnet names.
 [SUBNETS]
SUBNET1=10.185.250.0/24 ; comment about this subrange could be here, after the semi-colon
SUBNET2=10.185.252.200/28
SUBNET3= 2001:4898:a:2::/64 ; an IPv6 subnet
SUBNET4=2001:4898:a:3::/64; in production, the admin would likely give more useful names, like BUILDING9-
EXCEPT-RECEP.
```
Following the \[SUBNETS\] section, there can be sections for each Network Unlock certificate, identified by
the certificate thumbprint formatted without any spaces, which define subnets clients can be unlocked from
with that certificate.

>**Note:** When specifying the certificate thumbprint, do not include any spaces. If spaces are included in
the thumbprint the subnet configuration will fail because the thumbprint will not be recognized as valid.

Subnet restrictions are defined within each certificate section by denoting the allowed list of permitted
subnets. If any subnet is listed in a certificate section, then only those subnets listed are permitted for
that certificate. If no subnet is listed in a certificate section, then all subnets are permitted for that
certificate. If a certificate does not have a section in the subnet policy configuration file, then no
subnet restrictions are applied for unlocking with that certificate. This means for restrictions to apply to
every certificate, there must be a certificate section for every Network Unlock certificate on the server,
and an explicit allowed list set for each certificate section.
Subnet lists are created by putting the name of a subnet from the \[SUBNETS\] section on its own line below
the certificate section header. Then, the server will only unlock clients with this certificate on the
subnet(s) specified as in the list. For troubleshooting, a subnet can be quickly excluded without deleting
it from the section by simply commenting it out with a prepended semi-colon.
[2158a767e1c14e88e27a4c0aee111d2de2eafe60]
;Comments could be added here to indicate when the cert was issued, which Group Policy should get it, and so
on.
;This list shows this cert is only allowed to unlock clients on SUBNET1 and SUBNET3 subnets. In this
example, SUBNET2 is commented out.
SUBNET1
;SUBNET2
SUBNET3

To disallow the use of a certificate altogether, its subnet list may contain the line “DISABLED".

Turning off Network Unlock

To turn off the unlock server, the PXE provider can be unregistered from the WDS server or uninstalled
altogether. However, to stop clients from creating Network Unlock protectors the Allow Network Unlock at
startup Group Policy setting should be disabled. When this policy setting is updated to disabled on client
computers any Network Unlock key protectors on the computer will be deleted. Alternatively, the BitLocker
Network Unlock certificate policy can be deleted on the domain controller to accomplish the same task for an
entire domain.

Note: Removing the FVENKP certificate store that contains the Network Unlock certificate and key on the
WDS server will also effectively disable the server’s ability to respond to unlock requests for that certificate.
However, this is seen as an error condition and is not a supported or recommended method for turning off
the Network Unlock server.

Update Network Unlock certificates

To update the certificates used by Network Unlock, administrators need to import or generate the new certificate
for the server and then update the Network Unlock certificate Group Policy setting on the domain controller.

Troubleshoot Network Unlock

Troubleshooting Network Unlock issues begins by verifying the environment. Many times, a small configuration
issue will be the root cause of the failure. Items to verify include:
 Verify client hardware is UEFI-based and is on firmware version is 2.3.1 and that the UEFI firmware is in
native mode without a Compatibility Support Module (CSM ) for BIOS mode enabled. Do this by checking
that the firmware does not have an option enabled such as "Legacy mode" or "Compatibility mode" or that
the firmware does not appear to be in a BIOS -like mode.
All required roles and services are installed and started
Public and private certificates have been published and are in the proper certificate containers. The presence
of the Network Unlock certificate can be verified in the Microsoft Management Console (MMC.exe) on the
WDS server with the certificate snap-ins for the local computer enabled. The client certificate can be verified
by checking the registry key
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\SystemCertificates\FVE_NKP on the client
computer.
Group policy for Network Unlock is enabled and linked to the appropriate domains
Verify group policy is reaching the clients properly. This can be done using the GPRESULT.exe or RSOP.msc
utilities.
Verify the Network (Certificate Based) protector is listed on the client. This can be done using either
manage-bde or Windows PowerShell cmdlets. For example the following command will list the key
protectors currently configured on the C: drive of the lcoal computer:

Manage-bde –protectors –get C:

Note: Use the output of manage-bde along with the WDS debug log to determine if the proper
certificate thumbprint is being used for Network Unlock

Files to gather when troubleshooting BitLocker Network Unlock include:

1. The Windows event logs. Specifically the BitLocker event logs and the Microsoft-Windows-Deployment-
Services-Diagnostics-Debug log
Debug logging is turned off by default for the WDS server role, so you will need to enable it first. You can
use either of the following two methods to turn on WDS debug logging.
a. Start an elevated command prompt and run the following command:

wevtutil sl Microsoft-Windows-Deployment-Services-Diagnostics/Debug /e:true

b. Open Event Viewer on the WDS server.

In the left pane, click Applications and Services Logs, click Microsoft, click Windows, click
Deployment-Services-Diagnostics, and then click Debug.
In the right pane, click Enable Log.
2. The DHCP subnet configuration file (if one exists).
3. The output of the BitLocker status on the volume, this can be gathered into a text file using manage-bde -
status or Get-BitLockerVolume in Windows PowerShell.
4. Network Monitor capture on the server hosting the WDS role, filtered by client IP address.

Configure Network Unlock Group Policy settings on earlier versions

Network Unlock and the accompanying Group Policy settings were introduced in Windows Server 2012 but can
be deployed using operating systems running Windows Server 2008 R2 and Windows Server 2008.
Requirements
 The server hosting WDS must be running any of the server operating systems designated in the Applies To
list at the beginning of this topic.
Client computers must be running any of the client operating systems designated in the Applies To list at the
beginning of this topic.
The following steps can be used to configure Network Unlock on these older systems.
1. Step One: Install the WDS Server role
2. Step Two: Confirm the WDS Service is running
3. Step Three: Install the Network Unlock feature
4. Step Four: Create the Network Unlock certificate
5. Step Five: Deploy the private key and certificate to the WDS server
6. Step Six: Configure registry settings for Network Unlock
Apply the registry settings by running the following certutil script on each computer running any of the
client operating systems designated in the Applies To list at the beginning of this topic.

certutil -f -grouppolicy -addstore FVE_NKP BitLocker-NetworkUnlock.cer

reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v OSManageNKP /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseAdvancedStartup /t REG_DWORD /d 1 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UsePIN /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseTPMPIN /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseTPM /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseTPMKey /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Policies\Microsoft\FVE" /v UseTPMKeyPIN /t REG_DWORD /d 2 /f

7. Create the Network Unlock certificate

8. Deploy the private key and certificate to the WDS server
9. Create the certificate template for Network Unlock
10. Require TPM+PIN protectors at startup

See also
BitLocker overview
BitLocker frequently asked questions (FAQ )
Prepare your organization for BitLocker: Planning and policies
 BitLocker: Use BitLocker Drive Encryption Tools to
manage BitLocker
8/28/2018 • 10 minutes to read • Edit Online

Applies to
Windows 10
This topic for the IT professional describes how to use tools to manage BitLocker.
BitLocker Drive Encryption Tools include the command line tools manage-bde and repair-bde and the BitLocker
cmdlets for Windows PowerShell.
Both manage-bde and the BitLocker cmdlets can be used to perform any task that can be accomplished through
the BitLocker control panel and are appropriate to use for automated deployments and other scripting scenarios.
Repair-bde is a special circumstance tool that is provided for disaster recovery scenarios in which a BitLocker
protected drive cannot be unlocked normally or using the recovery console.
1. Manage-bde
2. Repair-bde
3. BitLocker cmdlets for Windows PowerShell

Manage-bde
Manage-bde is a command-line tool that can be used for scripting BitLocker operations. Manage-bde offers
additional options not displayed in the BitLocker control panel. For a complete list of the manage-bde options, see
the Manage-bde command-line reference.
Manage-bde includes less default settings and requires greater customization for configuring BitLocker. For
example, using just the manage-bde -on command on a data volume will fully encrypt the volume without any
authenticating protectors. A volume encrypted in this manner still requires user interaction to turn on BitLocker
protection, even though the command successfully completed because an authentication method needs to be
added to the volume for it to be fully protected. The following sections provide examples of common usage
scenarios for manage-bde.
Using manage -bde with operating system volumes
Listed below are examples of basic valid commands for operating system volumes. In general, using only the
manage-bde -on <drive letter> command will encrypt the operating system volume with a TPM -only protector
and no recovery key. However, many environments require more secure protectors such as passwords or PIN and
expect to be able to recover information with a recovery key. It is recommended that at least one primary
protector and a recovery protector be added to an operating system volume.
A good practice when using manage-bde is to determine the volume status on the target system. Use the
following command to determine volume status:

manage-bde -status

This command returns the volumes on the target, current encryption status, encryption method, and volume type
(operating system or data) for each volume:
The following example illustrates enabling BitLocker on a computer without a TPM chip. Before beginning the
encryption process you must create the startup key needed for BitLocker and save it to the USB drive. When
BitLocker is enabled for the operating system volume, the BitLocker will need to access the USB flash drive to
obtain the encryption key (in this example, the drive letter E represents the USB drive). You will be prompted to
reboot to complete the encryption process.

manage-bde –protectors -add C: -startupkey E:

manage-bde -on C:

Note: After the encryption is completed, the USB startup key must be inserted before the operating system
can be started.

An alternative to the startup key protector on non-TPM hardware is to use a password and an
ADaccountorgroup protector to protect the operating system volume. In this scenario, you would add the
protectors first. This is done with the command:

manage-bde -protectors -add C: -pw -sid <user or group>

This command will require you to enter and then confirm the password protector before adding them to the
volume. With the protectors enabled on the volume, you can then turn BitLocker on.
On computers with a TPM it is possible to encrypt the operating system volume without any defined protectors
using manage-bde. The command to do this is:

manage-bde -on C:

This will encrypt the drive using the TPM as the default protector. If you are not sure if a TPM protector is
available, to list the protectors available for a volume, run the following command:

manage-bde -protectors -get <volume>

Using manage -bde with data volumes

Data volumes use the same syntax for encryption as operating system volumes but they do not require protectors
for the operation to complete. Encrypting data volumes can be done using the base command:
manage-bde -on <drive letter> or you can choose to add additional protectors to the volume first. It is
recommended that at least one primary protector and a recovery protector be added to a data volume.
A common protector for a data volume is the password protector. In the example below, we add a password
protector to the volume and turn BitLocker on.

manage-bde -protectors -add -pw C:

manage-bde -on C:

Repair-bde
You may experience a problem that damages an area of a hard disk on which BitLocker stores critical information.
This kind of problem may be caused by a hard disk failure or if Windows exits unexpectedly.
The BitLocker Repair Tool (Repair-bde) can be used to access encrypted data on a severely damaged hard disk if
the drive was encrypted by using BitLocker. Repair-bde can reconstruct critical parts of the drive and salvage
recoverable data as long as a valid recovery password or recovery key is used to decrypt the data. If the BitLocker
metadata data on the drive has become corrupt, you must be able to supply a backup key package in addition to
the recovery password or recovery key. This key package is backed up in Active Directory Domain Services (AD
DS ) if you used the default setting for AD DS backup. With this key package and either the recovery password or
recovery key, you can decrypt portions of a BitLocker-protected drive if the disk is corrupted. Each key package
will work only for a drive that has the corresponding drive identifier. You can use the BitLocker Recovery Password
Viewer to obtain this key package from AD DS.

Tip: If you are not backing up recovery information to AD DS or if you want to save key packages
alternatively, you can use the command manage-bde -KeyPackage to generate a key package for a volume.

The Repair-bde command-line tool is intended for use when the operating system does not start or when you
cannot start the BitLocker Recovery Console. You should use Repair-bde if the following conditions are true:
1. You have encrypted the drive by using BitLocker Drive Encryption.
2. Windows does not start, or you cannot start the BitLocker recovery console.
3. You do not have a copy of the data that is contained on the encrypted drive.

Note: Damage to the drive may not be related to BitLocker. Therefore, we recommend that you try other tools
to help diagnose and resolve the problem with the drive before you use the BitLocker Repair Tool. The
Windows Recovery Environment (Windows RE ) provides additional options to repair computers.

The following limitations exist for Repair-bde:

The Repair-bde command-line tool cannot repair a drive that failed during the encryption or decryption
process.
The Repair-bde command-line tool assumes that if the drive has any encryption, then the drive has been fully
encrypted.
For more information about using repair-bde, see Repair-bde.

BitLocker cmdlets for Windows PowerShell

Windows PowerShell cmdlets provide a new way for administrators to use when working with BitLocker. Using
Windows PowerShell's scripting capabilities, administrators can integrate BitLocker options into existing scripts
with ease. The list below displays the available BitLocker cmdlets.
Name Parameters

Add-BitLockerKeyProtector -ADAccountOrGroup
-ADAccountOrGroupProtector
-Confirm
-MountPoint
-Password
-PasswordProtector
-Pin
-RecoveryKeyPath
-RecoveryKeyProtector
-RecoveryPassword
-RecoveryPasswordProtector
-Service
-StartupKeyPath
-StartupKeyProtector
-TpmAndPinAndStartupKeyProtector
-TpmAndPinProtector
-TpmAndStartupKeyProtector
-TpmProtector
-WhatIf

Backup-BitLockerKeyProtector -Confirm
-KeyProtectorId
-MountPoint
-WhatIf

Disable-BitLocker -Confirm
-MountPoint
-WhatIf

Disable-BitLockerAutoUnlock -Confirm
-MountPoint
-WhatIf
Enable-BitLocker -AdAccountOrGroup
-AdAccountOrGroupProtector
-Confirm
-EncryptionMethod
-HardwareEncryption
-Password
-PasswordProtector
-Pin
-RecoveryKeyPath
-RecoveryKeyProtector
-RecoveryPassword
-RecoveryPasswordProtector
-Service
-SkipHardwareTest
-StartupKeyPath
-StartupKeyProtector
-TpmAndPinAndStartupKeyProtector
-TpmAndPinProtector
-TpmAndStartupKeyProtector
-TpmProtector
-UsedSpaceOnly
-WhatIf

Enable-BitLockerAutoUnlock -Confirm
-MountPoint
-WhatIf

Get-BitLockerVolume -MountPoint

Lock-BitLocker -Confirm
-ForceDismount
-MountPoint
-WhatIf

Remove-BitLockerKeyProtector -Confirm
-KeyProtectorId
-MountPoint
-WhatIf
 Resume-BitLocker -Confirm
-MountPoint
-WhatIf

Suspend-BitLocker -Confirm
-MountPoint
-RebootCount
-WhatIf

Unlock-BitLocker -AdAccountOrGroup
-Confirm
-MountPoint
-Password
-RecoveryKeyPath
-RecoveryPassword
-RecoveryPassword
-WhatIf

Similar to manage-bde, the Windows PowerShell cmdlets allow configuration beyond the options offered in the
control panel. As with manage-bde, users need to consider the specific needs of the volume they are encrypting
prior to running Windows PowerShell cmdlets. A good initial step is to determine the current state of the
volume(s) on the computer. You can do this using the Get-BitLockerVolume cmdlet. The Get-BitLockerVolume
cmdlet output gives information on the volume type, protectors, protection status and other details.

Tip: Occasionally, all protectors may not be shown when using Get-BitLockerVolume due to lack of space in
the output display. If you do not see all of the protectors for a volume, you can use the Windows PowerShell
pipe command (|) to format a full listing of the protectors. Get-BitLockerVolume C: | fl

If you want to remove the existing protectors prior to provisioning BitLocker on the volume, you could use the
Remove-BitLockerKeyProtector cmdlet. Accomplishing this requires the GUID associated with the protector to be
removed.
A simple script can pipe the values of each Get-BitLockerVolume return out to another variable as seen below:

$vol = Get-BitLockerVolume
$keyprotectors = $vol.KeyProtector

Using this, you can display the information in the $keyprotectors variable to determine the GUID for each
protector.
Using this information, you can then remove the key protector for a specific volume using the command:

Remove-BitLockerKeyProtector <volume>: -KeyProtectorID "{GUID}"

Note: The BitLocker cmdlet requires the key protector GUID enclosed in quotation marks to execute. Ensure
the entire GUID, with braces, is included in the command.
Using the BitLocker Windows PowerShell cmdlets with operating system volumes
Using the BitLocker Windows PowerShell cmdlets is similar to working with the manage-bde tool for encrypting
operating system volumes. Windows PowerShell offers users a lot of flexibility. For example, users can add the
desired protector as part command for encrypting the volume. Below are examples of common user scenarios and
steps to accomplish them in BitLocker Windows PowerShell.
The following example shows how to enable BitLocker on an operating system drive using only the TPM
protector:

Enable-BitLocker C:

In the example below, adds one additional protector, the StartupKey protector and chooses to skip the BitLocker
hardware test. In this example, encryption starts immediately without the need for a reboot.

Enable-BitLocker C: -StartupKeyProtector -StartupKeyPath <path> -SkipHardwareTest

Using the BitLocker Windows PowerShell cmdlets with data volumes

Data volume encryption using Windows PowerShell is the same as for operating system volumes. You should add
the desired protectors prior to encrypting the volume. The following example adds a password protector to the E:
volume using the variable $pw as the password. The $pw variable is held as a SecureString value to store the user
defined password.

$pw = Read-Host -AsSecureString

<user inputs password>
Enable-BitLockerKeyProtector E: -PasswordProtector -Password $pw

Using an AD Account or Group protector in Windows PowerShell

The ADAccountOrGroup protector, introduced in Windows 8 and Windows Server 2012, is an Active Directory
SID -based protector. This protector can be added to both operating system and data volumes, although it does not
unlock operating system volumes in the pre-boot environment. The protector requires the SID for the domain
account or group to link with the protector. BitLocker can protect a cluster-aware disk by adding a SID -based
protector for the Cluster Name Object (CNO ) that lets the disk properly failover to and be unlocked by any
member computer of the cluster.

Warning: The ADAccountOrGroup protector requires the use of an additional protector for use (such as
TPM, PIN, or recovery key) when used on operating system volumes

To add an ADAccountOrGroup protector to a volume requires either the actual domain SID or the group name
preceded by the domain and a backslash. In the example below, the CONTOSO\Administrator account is added as
a protector to the data volume G.

Enable-BitLocker G: -AdAccountOrGroupProtector -AdAccountOrGroup CONTOSO\Administrator

For users who wish to use the SID for the account or group, the first step is to determine the SID associated with
the account. To get the specific SID for a user account in Windows PowerShell, use the following command:

Note: Use of this command requires the RSAT-AD -PowerShell feature.

get-aduser -filter {samaccountname -eq "administrator"}

 Tip: In addition to the PowerShell command above, information about the locally logged on user and group
membership can be found using: WHOAMI /ALL. This does not require the use of additional features.

The following example adds an ADAccountOrGroup protector to the previously encrypted operating system
volume using the SID of the account:

Add-BitLockerKeyProtector C: -ADAccountOrGroupProtector -ADAccountOrGroup S-1-5-21-3651336348-8937238915-

291003330-500

Note: Active Directory-based protectors are normally used to unlock Failover Cluster enabled volumes.

More information
BitLocker overview
BitLocker frequently asked questions (FAQ )
Prepare your organization for BitLocker: Planning and policies
BitLocker: How to enable Network Unlock
BitLocker: How to deploy on Windows Server 2012
 BitLocker: Use BitLocker Recovery Password Viewer
2/7/2018 • 2 minutes to read • Edit Online

Applies to
Windows 10
This topic for the IT professional describes how to use the BitLocker Recovery Password Viewer.
The BitLocker Recovery Password Viewer tool is an optional tool included with the Remote Server Administration
Tools (RSAT). It lets you locate and view BitLocker recovery passwords that are stored in Active Directory Domain
Services (AD DS ). You can use this tool to help recover data that is stored on a drive that has been encrypted by
using BitLocker. The BitLocker Active Directory Recovery Password Viewer tool is an extension for the Active
Directory Users and Computers Microsoft Management Console (MMC ) snap-in. Using this tool, you can
examine a computer object's Properties dialog box to view the corresponding BitLocker recovery passwords.
Additionally, you can right-click a domain container and then search for a BitLocker recovery password across all
the domains in the Active Directory forest. You can also search for a password by password identifier (ID ).

Before you start

To complete the procedures in this scenario:
You must have domain administrator credentials.
Your test computers must be joined to the domain.
On the test computers, BitLocker must have been turned on after joining the domain.
The following procedures describe the most common tasks performed by using the BitLocker Recovery Password
Viewer.
To view the recovery passwords for a computer
1. In Active Directory Users and Computers, locate and then click the container in which the computer is
located.
2. Right-click the computer object, and then click Properties.
3. In the Properties dialog box, click the BitLocker Recovery tab to view the BitLocker recovery passwords that
are associated with the computer.
To copy the recovery passwords for a computer
1. Follow the steps in the previous procedure to view the BitLocker recovery passwords.
2. On the BitLocker Recovery tab of the Properties dialog box, right-click the BitLocker recovery password that
you want to copy, and then click Copy Details.
3. Press CTRL+V to paste the copied text to a destination location, such as a text file or spreadsheet.
To locate a recovery password by using a password ID
1. In Active Directory Users and Computers, right-click the domain container, and then click Find BitLocker
Recovery Password.
2. In the Find BitLocker Recovery Password dialog box, type the first eight characters of the recovery
password in the Password ID (first 8 characters) box, and then click Search. By completing the procedures in
this scenario, you have viewed and copied the recovery passwords for a computer and used a password ID to
locate a recovery password.
More information
BitLocker Overview
BitLocker frequently asked questions (FAQ )
Prepare your organization for BitLocker: Planning and policies
BitLocker: How to deploy on Windows Server 2012
BitLocker: Use BitLocker Drive Encryption Tools to manage BitLocker
 BitLocker Group Policy settings
8/28/2018 • 80 minutes to read • Edit Online

Applies to
Windows 10
This topic for IT professionals describes the function, location, and effect of each Group Policy setting that is used
to manage BitLocker Drive Encryption.
To control what drive encryption tasks the user can perform from the Windows Control Panel or to modify other
configuration options, you can use Group Policy administrative templates or local computer policy settings. How
you configure these policy settings depends on how you implement BitLocker and what level of user interaction
will be allowed.

Note: A separate set of Group Policy settings supports the use of the Trusted Platform Module (TPM ). For
details about those settings, see Trusted Platform Module Group Policy settings.

BitLocker Group Policy settings can be accessed using the Local Group Policy Editor and the Group Policy
Management Console (GPMC ) under Computer Configuration\Administrative Templates\Windows
Components\BitLocker Drive Encryption. Most of the BitLocker Group Policy settings are applied when
BitLocker is initially turned on for a drive. If a computer is not compliant with existing Group Policy settings,
BitLocker may not be turned on or modified until the computer is in a compliant state. When a drive is out of
compliance with Group Policy settings (for example, if a Group Policy setting was changed after the initial
BitLocker deployment in your organization, and then the setting was applied to previously encrypted drives), no
change can be made to the BitLocker configuration of that drive except a change that will bring it into
compliance.
If multiple changes are necessary to bring the drive into compliance, you must suspend BitLocker protection,
make the necessary changes, and then resume protection. This situation could occur, for example, if a removable
drive was initially configured to be unlocked with a password and then Group Policy settings are changed to
disallow passwords and require smart cards. In this situation, you need to suspend BitLocker protection by using
the Manage-bde command-line tool, delete the password unlock method, and add the smart card method. After
this is complete, BitLocker is compliant with the Group Policy setting and BitLocker protection on the drive can
be resumed.

BitLocker Group Policy settings

The following sections provide a comprehensive list of BitLocker Group Policy settings that are organized by
usage. BitLocker Group Policy settings include settings for specific drive types (operating system drives, fixed
data drives, and removable data drives) and settings that are applied to all drives.
The following policy settings can be used to determine how a BitLocker-protected drive can be unlocked.
Allow devices with Secure Boot and protected DMA ports to opt out of preboot PIN
Allow network unlock at startup
Require additional authentication at startup
Allow enhanced PINs for startup
Configure minimum PIN length for startup
Disable new DMA devices when this computer is locked
 Disallow standard users from changing the PIN or password
Configure use of passwords for operating system drives
Require additional authentication at startup (Windows Server 2008 and Windows Vista)
Configure use of smart cards on fixed data drives
Configure use of passwords on fixed data drives
Configure use of smart cards on removable data drives
Configure use of passwords on removable data drives
Validate smart card certificate usage rule compliance
Enable use of BitLocker authentication requiring preboot keyboard input on slates
The following policy settings are used to control how users can access drives and how they can use BitLocker on
their computers.
Deny write access to fixed drives not protected by BitLocker
Deny write access to removable drives not protected by BitLocker
Control use of BitLocker on removable drives
The following policy settings determine the encryption methods and encryption types that are used with
BitLocker.
Choose drive encryption method and cipher strength
Configure use of hardware-based encryption for fixed data drives
Configure use of hardware-based encryption for operating system drives
Configure use of hardware-based encryption for removable data drives
Enforce drive encryption type on fixed data drives
Enforce drive encryption type on operating system drives
Enforce drive encryption type on removable data drives
The following policy settings define the recovery methods that can be used to restore access to a BitLocker-
protected drive if an authentication method fails or is unable to be used.
Choose how BitLocker-protected operating system drives can be recovered
Choose how users can recover BitLocker-protected drives (Windows Server 2008 and Windows Vista)
Store BitLocker recovery information in Active Directory Domain Services (Windows Server 2008 and
Windows Vista)
Choose default folder for recovery password
Choose how BitLocker-protected fixed drives can be recovered
Choose how BitLocker-protected removable drives can be recovered
Configure the pre-boot recovery message and URL
The following policies are used to support customized deployment scenarios in your organization.
Allow Secure Boot for integrity validation
Provide the unique identifiers for your organization
Prevent memory overwrite on restart
Configure TPM platform validation profile for BIOS -based firmware configurations
Configure TPM platform validation profile (Windows Vista, Windows Server 2008, Windows 7, Windows
Server 2008 R2)
Configure TPM platform validation profile for native UEFI firmware configurations
Reset platform validation data after BitLocker recovery
Use enhanced Boot Configuration Data validation profile
 Allow access to BitLocker-protected fixed data drives from earlier versions of Windows
Allow access to BitLocker-protected removable data drives from earlier versions of Windows
Allow devices with Secure Boot and protected DMA ports to opt out of preboot PIN
This policy setting allows users on devices that are compliant with Modern Standby or the Microsoft Hardware
Security Test Interface (HSTI) to not have a PIN for preboot authentication.

Policy description With this policy setting, you can allow TPM-only
protection for newer, more secure devices, such as
devices that support Modern Standby or HSTI, while
requiring PIN on older devices.

Introduced Windows 10, version 1703

Drive type Operating system drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Operating System Drives

Conflicts This setting overrides the Require startup PIN with

TPM option of the Require additional authentication at
startup policy on compliant hardware.

When enabled Users on Modern Standby and HSTI compliant devices

will have the choice to turn on BitLocker without preboot
authentication.

When disabled or not configured The options of the Require additional authentication at
startup policy apply.

Reference
The preboot authentication option Require startup PIN with TPM of the Require additional authentication at
startup policy is often enabled to help ensure security for older devices that do not support Modern Standby. But
visually impaired users have no audible way to know when to enter a PIN. This setting enables an exception to
the PIN -required policy on secure hardware.
Allow network unlock at startup
This policy controls a portion of the behavior of the Network Unlock feature in BitLocker. This policy is required
to enable BitLocker Network Unlock on a network because it allows clients running BitLocker to create the
necessary network key protector during encryption. This policy is used in addition to the BitLocker Drive
Encryption Network Unlock Certificate security policy (located in the Public Key Policies folder of Local
Computer Policy) to allow systems that are connected to a trusted network to properly utilize the Network
Unlock feature.
 Policy description With this policy setting, you can control whether a
BitLocker-protected computer that is connected to a
trusted local area network and joined to a domain can
create and use network key protectors on TPM-enabled
computers to automatically unlock the operating system
drive when the computer is started.

Introduced Windows Server 2012 and Windows 8

Drive type Operating system drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Operating System Drives

Conflicts None

When enabled Clients configured with a BitLocker Network Unlock

certificate can create and use Network Key Protectors.

When disabled or not configured Clients cannot create and use Network Key Protectors

Reference
To use a network key protector to unlock the computer, the computer and the server that hosts BitLocker Drive
Encryption Network Unlock must be provisioned with a Network Unlock certificate. The Network Unlock
certificate is used to create a network key protector and to protect the information exchange with the server to
unlock the computer. You can use the Group Policy setting Computer Configuration\Windows
Settings\Security Settings\Public Key Policies\BitLocker Drive Encryption Network Unlock Certificate
on the domain controller to distribute this certificate to computers in your organization. This unlock method uses
the TPM on the computer, so computers that do not have a TPM cannot create network key protectors to
automatically unlock by using Network Unlock.

Note: For reliability and security, computers should also have a TPM startup PIN that can be used when the
computer is disconnected from the wired network or cannot connect to the domain controller at startup.

For more information about Network Unlock, see BitLocker: How to enable Network Unlock.
Require additional authentication at startup
This policy setting is used to control which unlock options are available for operating system drives.

Policy description With this policy setting, you can configure whether
BitLocker requires additional authentication each time
the computer starts and whether you are using BitLocker
with a Trusted Platform Module (TPM). This policy setting
is applied when you turn on BitLocker.

Introduced Windows Server 2008 R2 and Windows 7

 Drive type Operating system drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Operating System Drives

Conflicts If one authentication method is required, the other

methods cannot be allowed.
Use of BitLocker with a TPM startup key or with a TPM
startup key and a PIN must be disallowed if the Deny
write access to removable drives not protected by
BitLocker policy setting is enabled.

When enabled Users can configure advanced startup options in the

BitLocker Setup Wizard.

When disabled or not configured Users can configure only basic options on computers
with a TPM.
Only one of the additional authentication options can be
required at startup; otherwise, a policy error occurs.

Reference
If you want to use BitLocker on a computer without a TPM, select the Allow BitLocker without a compatible
TPM check box. In this mode, a USB drive is required for startup. Key information that is used to encrypt the
drive is stored on the USB drive, which creates a USB key. When the USB key is inserted, access to the drive is
authenticated and the drive is accessible. If the USB key is lost or unavailable, you need to use one of the
BitLocker recovery options to access the drive.
On a computer with a compatible TPM, four types of authentication methods can be used at startup to provide
added protection for encrypted data. When the computer starts, it can use:
only the TPM for authentication
insertion of a USB flash drive containing the startup key
the entry of a 4-digit to 20-digit personal identification number (PIN )
a combination of the PIN and the USB flash drive
There are four options for TPM -enabled computers or devices:
Configure TPM startup
Allow TPM
Require TPM
Do not allow TPM
Configure TPM startup PIN
Allow startup PIN with TPM
Require startup PIN with TPM
Do not allow startup PIN with TPM
Configure TPM startup key
Allow startup key with TPM
 Require startup key with TPM
Do not allow startup key with TPM
Configure TPM startup key and PIN
Allow TPM startup key with PIN
Require startup key and PIN with TPM
Do not allow TPM startup key with PIN
Allow enhanced PINs for startup
This policy setting permits the use of enhanced PINs when you use an unlock method that includes a PIN.

Policy description With this policy setting, you can configure whether
enhanced startup PINs are used with BitLocker.

Introduced Windows Server 2008 R2 and Windows 7

Drive type Operating system drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Operating System Drives

Conflicts None

When enabled All new BitLocker startup PINs that are set will be
enhanced PINs. Existing drives that were protected by
using standard startup PINs are not affected.

When disabled or not configured Enhanced PINs will not be used.

Reference
Enhanced startup PINs permit the use of characters (including uppercase and lowercase letters, symbols,
numbers, and spaces). This policy setting is applied when you turn on BitLocker.

Important: Not all computers support enhanced PIN characters in the preboot environment. It is strongly
recommended that users perform a system check during the BitLocker setup to verify that enhanced PIN
characters can be used.

Configure minimum PIN length for startup

This policy setting is used to set a minimum PIN length when you use an unlock method that includes a PIN.

Policy description With this policy setting, you can configure a minimum
length for a TPM startup PIN. This policy setting is
applied when you turn on BitLocker. The startup PIN
must have a minimum length of 4 digits, and it can have
a maximum length of 20 digits. By default, the minimum
PIN length is 6.
 Introduced Windows Server 2008 R2 and Windows 7

Drive type Operating system drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Operating System Drives

Conflicts None

When enabled You can require that startup PINs set by users must have
a minimum length you choose that is between 4 and 20
digits.

When disabled or not configured Users can configure a startup PIN of any length between
6 and 20 digits.

Reference
This policy setting is applied when you turn on BitLocker. The startup PIN must have a minimum length of 4
digits and can have a maximum length of 20 digits.
Originally, BitLocker allowed from 4 to 20 characters for a PIN. Windows Hello has its own PIN for logon, which
can be 4 to 127 characters. Both BitLocker and Windows Hello use the TPM to prevent PIN brute-force attacks.
The TPM can be configured to use Dictionary Attack Prevention parameters (lockout threshold and lockout
duration) to control how many failed authorizations attempts are allowed before the TPM is locked out, and how
much time must elapse before another attempt can be made.
The Dictionary Attack Prevention Parameters provide a way to balance security needs with usability. For
example, when BitLocker is used with a TPM + PIN configuration, the number of PIN guesses is limited over
time. A TPM 2.0 in this example could be configured to allow only 32 PIN guesses immediately, and then only
one more guess every two hours. This totals a maximum of about 4415 guesses per year. If the PIN is 4 digits, all
9999 possible PIN combinations could be attempted in a little over two years.
Increasing the PIN length requires a greater number of guesses for an attacker. In that case, the lockout duration
between each guess can be shortened to allow legitimate users to retry a failed attempt sooner, while
maintaining a similar level of protection.
Beginning with Windows 10, version 1703, the minimum length for the BitLocker PIN was increased to 6
characters to better align with other Windows features that leverage TPM 2.0, including Windows Hello. To help
organizations with the transition, beginning with Windows 10, version 1709 and Windows 10, version 1703 with
the October 2017 cumulative update installed, the BitLocker PIN length is 6 characters by default, but it can be
reduced to 4 characters. If the minimum PIN length is reduced from the default of six characters, then the TPM
2.0 lockout period will be extended.
Disable new DMA devices when this computer is locked
This policy setting allows you to block direct memory access (DMA) for all hot pluggable PCI ports until a user
signs in to Windows.
 Policy description This setting helps prevent attacks that use external PCI-
based devices to access BitLocker keys.

Introduced Windows 10, version 1703

Drive type Operating system drives

Policy path Computer Configuration\Administrative Templates\Windows

Components\BitLocker Drive Encryption\Operating System
Drives

Conflicts None

When enabled Every time the user locks the screen, DMA will be blocked on
hot pluggable PCI ports until the user signs in again.

When disabled or not configured DMA is available on hot pluggable PCI devices if the device is
turned on, regardless of whether a user is signed in.

Reference
This policy setting is only enforced when BitLocker or device encyption is enabled. As explained in the Microoft
Security Guidance blog, in some cases when this setting is enabled, internal, PCI-based peripherals can fail,
including wireless network drivers and input and audio peripherals. This problem is fixed in the April 2018
quality update.
Disallow standard users from changing the PIN or password
This policy setting allows you to configure whether standard users are allowed to change the PIN or password
that is used to protect the operating system drive.

Policy description With this policy setting, you can configure whether
standard users are allowed to change the PIN or
password used to protect the operating system drive.

Introduced Windows Server 2012 and Windows 8

Drive type Operating system drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Operating System Drives

Conflicts None

When enabled Standard users are not allowed to change BitLocker PINs
or passwords.

When disabled or not configured Standard users are permitted to change BitLocker PINs
or passwords.
Reference
To change the PIN or password, the user must be able to provide the current PIN or password. This policy
setting is applied when you turn on BitLocker.
Configure use of passwords for operating system drives
This policy controls how non-TPM based systems utilize the password protector. Used in conjunction with the
Password must meet complexity requirements policy, this policy allows administrators to require password
length and complexity for using the password protector. By default, passwords must be eight characters in
length. Complexity configuration options determine how important domain connectivity is for the client. For the
strongest password security, administrators should choose Require password complexity because it requires
domain connectivity, and it requires that the BitLocker password meets the same password complexity
requirements as domain sign-in passwords.

Policy description With this policy setting, you can specify the constraints
for passwords that are used to unlock operating system
drives that are protected with BitLocker.

Introduced Windows Server 2012 and Windows 8

Drive type Operating system drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Operating System Drives

Conflicts Passwords cannot be used if FIPS-compliance is enabled.

Note
The System cryptography: Use FIPS-compliant
algorithms for encryption, hashing, and signing
policy setting, which is located at Computer
Configuration\Windows Settings\Security
Settings\Local Policies\Security Options specifies
whether FIPS-compliance is enabled.

When enabled Users can configure a password that meets the

requirements you define. To enforce complexity
requirements for the password, select Require
complexity.

When disabled or not configured The default length constraint of 8 characters will apply to
operating system drive passwords and no complexity
checks will occur.

Reference
If non-TPM protectors are allowed on operating system drives, you can provision a password, enforce
complexity requirements on the password, and configure a minimum length for the password. For the
complexity requirement setting to be effective, the Group Policy setting Password must meet complexity
requirements, which is located at Computer Configuration\Windows Settings\Security
Settings\Account Policies\Password Policy\ must be also enabled.

Note: These settings are enforced when turning on BitLocker, not when unlocking a volume. BitLocker
allows unlocking a drive with any of the protectors that are available on the drive.

When set to Require complexity, a connection to a domain controller is necessary when BitLocker is enabled
to validate the complexity the password. When set to Allow complexity, a connection to a domain controller is
attempted to validate that the complexity adheres to the rules set by the policy. If no domain controllers are
found, the password will be accepted regardless of actual password complexity, and the drive will be encrypted
by using that password as a protector. When set to Do not allow complexity, there is no password complexity
validation. Passwords must be at least 8 characters. To configure a greater minimum length for the password,
enter the desired number of characters in the Minimum password length box.
When this policy setting is enabled, you can set the option Configure password complexity for operating
system drives to:
Allow password complexity
Do not allow password complexity
Require password complexity
Require additional authentication at startup (Windows Server 2008 and Windows Vista)
This policy setting is used to control what unlock options are available for computers running Windows Server
2008 or Windows Vista.

Policy description With this policy setting, you can control whether the
BitLocker Setup Wizard on computers running Windows
Vista or Windows Server 2008 can set up an additional
authentication method that is required each time the
computer starts.

Introduced Windows Server 2008 and Windows Vista

Drive type Operating system drives (Windows Server 2008 and

Windows Vista)

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Operating System Drives

Conflicts If you choose to require an additional authentication

method, other authentication methods cannot be
allowed.

When enabled The BitLocker Setup Wizard displays the page that allows
the user to configure advanced startup options for
BitLocker. You can further configure setting options for
computers with or without a TPM.
 When disabled or not configured The BitLocker Setup Wizard displays basic steps that
allow users to enable BitLocker on computers with a
TPM. In this basic wizard, no additional startup key or
startup PIN can be configured.

Reference
On a computer with a compatible TPM, two authentication methods can be used at startup to provide added
protection for encrypted data. When the computer starts, it can require users to insert a USB drive that contains
a startup key. It can also require users to enter a 6-digit to 20-digit startup PIN.
A USB drive that contains a startup key is needed on computers without a compatible TPM. Without a TPM,
BitLocker-encrypted data is protected solely by the key material that is on this USB drive.
There are two options for TPM -enabled computers or devices:
Configure TPM startup PIN
Allow startup PIN with TPM
Require startup PIN with TPM
Do not allow startup PIN with TPM
Configure TPM startup key
Allow startup key with TPM
Require startup key with TPM
Do not allow startup key with TPM
These options are mutually exclusive. If you require the startup key, you must not allow the startup PIN. If you
require the startup PIN, you must not allow the startup key. Otherwise, a policy error will occur.
To hide the advanced page on a TPM -enabled computer or device, set these options to Do not allow for the
startup key and for the startup PIN.
Configure use of smart cards on fixed data drives
This policy setting is used to require, allow, or deny the use of smart cards with fixed data drives.

Policy description With this policy setting, you can specify whether smart
cards can be used to authenticate user access to the
BitLocker-protected fixed data drives on a computer.

Introduced Windows Server 2008 R2 and Windows 7

Drive type Fixed data drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Fixed Data Drives
 Conflicts To use smart cards with BitLocker, you may also need to
modify the object identifier setting in the Computer
Configuration\Administrative Templates\BitLocker
Drive Encryption\Validate smart card certificate
usage rule compliance policy setting to match the
object identifier of your smart card certificates.

When enabled Smart cards can be used to authenticate user access to

the drive. You can require smart card authentication by
selecting the Require use of smart cards on fixed
data drives check box.

When disabled Users cannot use smart cards to authenticate their

access to BitLocker-protected fixed data drives.

When not configured Smart cards can be used to authenticate user access to a
BitLocker-protected drive.

Reference

Note: These settings are enforced when turning on BitLocker, not when unlocking a drive. BitLocker allows
unlocking a drive by using any of the protectors that are available on the drive.

Configure use of passwords on fixed data drives

This policy setting is used to require, allow, or deny the use of passwords with fixed data drives.

Policy description With this policy setting, you can specify whether a
password is required to unlock BitLocker-protected fixed
data drives.

Introduced Windows Server 2008 R2 and Windows 7

Drive type Fixed data drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Fixed Data Drives

Conflicts To use password complexity, the Computer

Configuration\Windows Settings\Security
Settings\Account Policies\Password
Policy\Password must meet complexity
requirements policy setting must also be enabled.

When enabled Users can configure a password that meets the

requirements you define. To require the use of a
password, select Require password for fixed data
drive. To enforce complexity requirements on the
password, select Require complexity.
 When disabled The user is not allowed to use a password.

When not configured Passwords are supported with the default settings, which
do not include password complexity requirements and
require only 8 characters.

Reference
When set to Require complexity, a connection to a domain controller is necessary to validate the complexity of
the password when BitLocker is enabled.
When set to Allow complexity, a connection to a domain controller is attempted to validate that the complexity
adheres to the rules set by the policy. However, if no domain controllers are found, the password is accepted
regardless of the actual password complexity, and the drive is encrypted by using that password as a protector.
When set to Do not allow complexity, no password complexity validation is performed.
Passwords must be at least 8 characters. To configure a greater minimum length for the password, enter the
desired number of characters in the Minimum password length box.

Note: These settings are enforced when turning on BitLocker, not when unlocking a drive. BitLocker allows
unlocking a drive with any of the protectors that are available on the drive.

For the complexity requirement setting to be effective, the Group Policy setting Computer
Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\Password must
meet complexity requirements must also be enabled. This policy setting is configured on a per-computer
basis. This means that it applies to local user accounts and domain user accounts. Because the password filter
that is used to validate password complexity is located on the domain controllers, local user accounts cannot
access the password filter because they are not authenticated for domain access. When this policy setting is
enabled, if you sign in with a local user account, and you attempt to encrypt a drive or change a password on an
existing BitLocker-protected drive, an "Access denied" error message is displayed. In this situation, the password
key protector cannot be added to the drive.
Enabling this policy setting requires that connectivity to a domain be established before adding a password key
protector to a BitLocker-protected drive. Users who work remotely and have periods of time in which they
cannot connect to the domain should be made aware of this requirement so that they can schedule a time when
they will be connected to the domain to turn on BitLocker or to change a password on a BitLocker-protected
data drive.

Important: Passwords cannot be used if FIPS compliance is enabled. The System cryptography: Use
FIPS -compliant algorithms for encryption, hashing, and signing policy setting in Computer
Configuration\Windows Settings\Security Settings\Local Policies\Security Options specifies
whether FIPS compliance is enabled.

Configure use of smart cards on removable data drives

This policy setting is used to require, allow, or deny the use of smart cards with removable data drives.

Policy description With this policy setting, you can specify whether smart
cards can be used to authenticate user access to
BitLocker-protected removable data drives on a
computer.
 Introduced Windows Server 2008 R2 and Windows 7

Drive type Removable data drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Removable Data Drives

Conflicts To use smart cards with BitLocker, you may also need to
modify the object identifier setting in the Computer
Configuration\Administrative Templates\BitLocker
Drive Encryption\Validate smart card certificate
usage rule compliance policy setting to match the
object identifier of your smart card certificates.

When enabled Smart cards can be used to authenticate user access to

the drive. You can require smart card authentication by
selecting the Require use of smart cards on
removable data drives check box.

When disabled or not configured Users are not allowed to use smart cards to authenticate
their access to BitLocker-protected removable data
drives.

When not configured Smart cards are available to authenticate user access to a
BitLocker-protected removable data drive.

Reference

Note: These settings are enforced when turning on BitLocker, not when unlocking a drive. BitLocker allows
unlocking a drive with any of the protectors that are available on the drive.

Configure use of passwords on removable data drives

This policy setting is used to require, allow, or deny the use of passwords with removable data drives.

Policy description With this policy setting, you can specify whether a
password is required to unlock BitLocker-protected
removable data drives.

Introduced Windows Server 2008 R2 and Windows 7

Drive type Removable data drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Removable Data Drives
 Conflicts To use password complexity, the Password must meet
complexity requirements policy setting, which is
located at Computer Configuration\Windows
Settings\Security Settings\Account
Policies\Password Policy must also be enabled.

When enabled Users can configure a password that meets the

requirements you define. To require the use of a
password, select Require password for removable
data drive. To enforce complexity requirements on the
password, select Require complexity.

When disabled The user is not allowed to use a password.

When not configured Passwords are supported with the default settings, which
do not include password complexity requirements and
require only 8 characters.

Reference
If you choose to allow the use of a password, you can require a password to be used, enforce complexity
requirements, and configure a minimum length. For the complexity requirement setting to be effective, the
Group Policy setting Password must meet complexity requirements, which is located at Computer
Configuration\Windows Settings\Security Settings\Account Policies\Password Policy must also be
enabled.

Note: These settings are enforced when turning on BitLocker, not when unlocking a drive. BitLocker allows
unlocking a drive with any of the protectors that are available on the drive.

Passwords must be at least 8 characters. To configure a greater minimum length for the password, enter the
desired number of characters in the Minimum password length box.
When set to Require complexity, a connection to a domain controller is necessary when BitLocker is enabled
to validate the complexity the password.
When set to Allow complexity, a connection to a domain controller will be attempted to validate that the
complexity adheres to the rules set by the policy. However, if no domain controllers are found, the password will
still be accepted regardless of actual password complexity and the drive will be encrypted by using that
password as a protector.
When set to Do not allow complexity, no password complexity validation will be done.

Note: Passwords cannot be used if FIPS compliance is enabled. The System cryptography: Use FIPS -
compliant algorithms for encryption, hashing, and signing policy setting in Computer
Configuration\Windows Settings\Security Settings\Local Policies\Security Options specifies
whether FIPS compliance is enabled.

For information about this setting, see System cryptography: Use FIPS -compliant algorithms for encryption,
hashing, and signing.
Validate smart card certificate usage rule compliance
This policy setting is used to determine what certificate to use with BitLocker.
 Policy description With this policy setting, you can associate an object
identifier from a smart card certificate to a BitLocker-
protected drive.

Introduced Windows Server 2008 R2 and Windows 7

Drive type Fixed and removable data drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption

Conflicts None

When enabled The object identifier that is specified in the Object

identifier setting must match the object identifier in the
smart card certificate.

When disabled or not configured The default object identifier is used.

Reference
This policy setting is applied when you turn on BitLocker.
The object identifier is specified in the enhanced key usage (EKU ) of a certificate. BitLocker can identify which
certificates can be used to authenticate a user certificate to a BitLocker-protected drive by matching the object
identifier in the certificate with the object identifier that is defined by this policy setting.
The default object identifier is 1.3.6.1.4.1.311.67.1.1.

Note: BitLocker does not require that a certificate have an EKU attribute; however, if one is configured for
the certificate, it must be set to an object identifier that matches the object identifier configured for BitLocker.

Enable use of BitLocker authentication requiring preboot keyboard input on slates

This policy setting allows users to enable authentication options that require user input from the preboot
environment even if the platform indicates a lack of preboot input capability.

Policy description With this policy setting, you can allow users to enable
authentication options that require user input from the
preboot environment, even if the platform indicates a
lack of preboot input capability.

Introduced Windows Server 2012 and Windows 8

Drive type Operating system drive

 Policy path Computer Configuration\Administrative
Templates\Windows Components\BitLocker Drive
Encryption\Operating System Drive

Conflicts None

When enabled Devices must have an alternative means of preboot input

(such as an attached USB keyboard).

When disabled or not configured The Windows Recovery Environment must be enabled on
tablets to support entering the BitLocker recovery
password.

Reference
The Windows touch keyboard (such as used by tablets) is not available in the preboot environment where
BitLocker requires additional information, such as a PIN or password.
It is recommended that administrators enable this policy only for devices that are verified to have an alternative
means of preboot input, such as attaching a USB keyboard.
When the Windows Recovery Environment is not enabled and this policy is not enabled, you cannot turn on
BitLocker on a device that uses the Windows touch keyboard.
If you do not enable this policy setting, the following options in the Require additional authentication at
startup policy might not be available:
Configure TPM startup PIN: Required and Allowed
Configure TPM startup key and PIN: Required and Allowed
Configure use of passwords for operating system drives
Deny write access to fixed drives not protected by BitLocker
This policy setting is used to require encryption of fixed drives prior to granting Write access.

Policy description With this policy setting, you can set whether BitLocker
protection is required for fixed data drives to be writable
on a computer.

Introduced Windows Server 2008 R2 and Windows 7

Drive type Fixed data drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Fixed Data Drives

Conflicts See the Reference section for a description of conflicts.

 When enabled All fixed data drives that are not BitLocker-protected are
mounted as Read-only. If the drive is protected by
BitLocker, it is mounted with Read and Write access.

When disabled or not configured All fixed data drives on the computer are mounted with
Read and Write access.

Reference
This policy setting is applied when you turn on BitLocker.
Conflict considerations include:
1. When this policy setting is enabled, users receive "Access denied" error messages when they try to save data
to unencrypted fixed data drives. See the Reference section for additional conflicts.
2. If BdeHdCfg.exe is run on a computer when this policy setting is enabled, you could encounter the
following issues:
If you attempted to shrink the drive and create the system drive, the drive size is successfully reduced
and a raw partition is created. However, the raw partition is not formatted. The following error
message is displayed: "The new active drive cannot be formatted. You may need to manually prepare
your drive for BitLocker."
If you attempt to use unallocated space to create the system drive, a raw partition will be created.
However, the raw partition will not be formatted. The following error message is displayed: "The new
active drive cannot be formatted. You may need to manually prepare your drive for BitLocker."
If you attempt to merge an existing drive into the system drive, the tool fails to copy the required boot
file onto the target drive to create the system drive. The following error message is displayed:
"BitLocker setup failed to copy boot files. You may need to manually prepare your drive for BitLocker."
3. If this policy setting is enforced, a hard drive cannot be repartitioned because the drive is protected. If you are
upgrading computers in your organization from a previous version of Windows, and those computers were
configured with a single partition, you should create the required BitLocker system partition before you apply
this policy setting to the computers.
Deny write access to removable drives not protected by BitLocker
This policy setting is used to require that removable drives are encrypted prior to granting Write access, and to
control whether BitLocker-protected removable drives that were configured in another organization can be
opened with Write access.

Policy description With this policy setting, you can configure whether
BitLocker protection is required for a computer to be
able to write data to a removable data drive.

Introduced Windows Server 2008 R2 and Windows 7

Drive type Removable data drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Removable Data Drives
 Conflicts See the Reference section for a description of conflicts.

When enabled All removable data drives that are not BitLocker-
protected are mounted as Read-only. If the drive is
protected by BitLocker, it is mounted with Read and
Write access.

When disabled or not configured All removable data drives on the computer are mounted
with Read and Write access.

Reference
If the Deny write access to devices configured in another organization option is selected, only drives with
identification fields that match the computer's identification fields are given Write access. When a removable
data drive is accessed, it is checked for a valid identification field and allowed identification fields. These fields are
defined by the Provide the unique identifiers for your organization policy setting.

Note: You can override this policy setting with the policy settings under User
Configuration\Administrative Templates\System\Removable Storage Access. If the Removable
Disks: Deny write access policy setting is enabled, this policy setting will be ignored.

Conflict considerations include:

1. Use of BitLocker with the TPM plus a startup key or with the TPM plus a PIN and startup key must be
disallowed if the Deny write access to removable drives not protected by BitLocker policy setting is
enabled.
2. Use of recovery keys must be disallowed if the Deny write access to removable drives not protected by
BitLocker policy setting is enabled.
3. You must enable the Provide the unique identifiers for your organization policy setting if you want to
deny Write access to drives that were configured in another organization.
Control use of BitLocker on removable drives
This policy setting is used to prevent users from turning BitLocker on or off on removable data drives.

Policy description With this policy setting, you can control the use of
BitLocker on removable data drives.

Introduced Windows Server 2008 R2 and Windows 7

Drive type Removable data drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Removable Data Drives

Conflicts None
 When enabled You can select property settings that control how users
can configure BitLocker.

When disabled Users cannot use BitLocker on removable data drives.

When not configured Users can use BitLocker on removable data drives.

Reference
This policy setting is applied when you turn on BitLocker.
For information about suspending BitLocker protection, see BitLocker Basic Deployment.
The options for choosing property settings that control how users can configure BitLocker are:
Allow users to apply BitLocker protection on removable data drives Enables the user to run the
BitLocker Setup Wizard on a removable data drive.
Allow users to suspend and decrypt BitLocker on removable data drives Enables the user to remove
BitLocker from the drive or to suspend the encryption while performing maintenance.
Choose drive encryption method and cipher strength
This policy setting is used to control the encryption method and cipher strength.

Policy description With this policy setting, you can control the encryption
method and strength for drives.

Introduced Windows Server 2012 and Windows 8

Drive type All drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption

Conflicts None

When enabled You can choose an encryption algorithm and key cipher
strength for BitLocker to use to encrypt drives.

When disabled or not configured Beginning with Windows 10, version 1511, BitLocker
uses the default encryption method of XTS-AES 128-bit
or the encryption method that is specified by the setup
script. Windows Phone does not support XTS; it uses
AES-CBC 128-bit by default and supports AES-CBC 256-
bit by policy.

Reference
The values of this policy determine the strength of the cipher that BitLocker uses for encryption. Enterprises may
want to control the encryption level for increased security (AES -256 is stronger than AES -128).
If you enable this setting, you will be able to configure an encryption algorithm and key cipher strength for fixed
data drives, operating system drives, and removable data drives individually. For fixed and operating system
drives, we recommend that you use the XTS -AES algorithm. For removable drives, you should use AES -CBC
128-bit or AES -CBC 256-bit if the drive will be used in other devices that are not running Windows 10, version
1511 or later.
Changing the encryption method has no effect if the drive is already encrypted or if encryption is in progress. In
these cases, this policy setting is ignored.

Warning: This policy does not apply to encrypted drives. Encrypted drives utilize their own algorithm, which
is set by the drive during partitioning.

When this policy setting is disabled or not configured, BitLocker will use the default encryption method of XTS -
AES 128-bit or the encryption method that is specified in the setup script.
Configure use of hardware -based encryption for fixed data drives
This policy controls how BitLocker reacts to systems that are equipped with encrypted drives when they are used
as fixed data volumes. Using hardware-based encryption can improve the performance of drive operations that
involve frequent reading or writing of data to the drive.

Policy description With this policy setting, you can manage BitLocker’s use
of hardware-based encryption on fixed data drives and
to specify which encryption algorithms BitLocker can use
with hardware-based encryption.

Introduced Windows Server 2012 and Windows 8

Drive type Fixed data drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Fixed Data Drives

Conflicts None

When enabled You can specify additional options that control whether
BitLocker software-based encryption is used instead of
hardware-based encryption on computers that do not
support hardware-based encryption. You can also specify
whether you want to restrict the encryption algorithms
and cipher suites that are used with hardware-based
encryption.

When disabled BitLocker cannot use hardware-based encryption with

fixed data drives, and BitLocker software-based
encryption is used by default when the drive in
encrypted.
 When not configured BitLocker uses hardware-based encryption with the
encryption algorithm that is set for the drive. If
hardware-based encryption is not available, BitLocker
software-based encryption is used instead.

Reference

Note: The Choose drive encryption method and cipher strength policy setting does not apply to
hardware-based encryption.

The encryption algorithm that is used by hardware-based encryption is set when the drive is partitioned. By
default, BitLocker uses the algorithm that is configured on the drive to encrypt the drive. The Restrict
encryption algorithms and cipher suites allowed for hardware-based encryption option of this setting
enables you to restrict the encryption algorithms that BitLocker can use with hardware encryption. If the
algorithm that is set for the drive is not available, BitLocker disables the use of hardware-based encryption.
Encryption algorithms are specified by object identifiers (OID ), for example:
Advanced Encryption Standard (AES ) 128 in Cipher Block Chaining (CBC ) mode OID: 2.16.840.1.101.3.4.1.2
AES 256 in CBC mode OID: 2.16.840.1.101.3.4.1.42
Configure use of hardware -based encryption for operating system drives
This policy controls how BitLocker reacts when encrypted drives are used as operating system drives. Using
hardware-based encryption can improve the performance of drive operations that involve frequent reading or
writing of data to the drive.

Policy description With this policy setting, you can manage BitLocker’s use
of hardware-based encryption on operating system
drives and specify which encryption algorithms it can use
with hardware-based encryption.

Introduced Windows Server 2012 and Windows 8

Drive type Operating system drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Operating System Drives

Conflicts None

When enabled You can specify additional options that control whether
BitLocker software-based encryption is used instead of
hardware-based encryption on computers that do not
support hardware-based encryption. You can also specify
whether you want to restrict the encryption algorithms
and cipher suites that are used with hardware-based
encryption.
 When disabled BitLocker cannot use hardware-based encryption with
operating system drives, and BitLocker software-based
encryption is used by default when the drive in
encrypted.

When not configured BitLocker uses hardware-based encryption with the

encryption algorithm that is set for the drive. If
hardware-based encryption is not available, BitLocker
software-based encryption is used instead.

Reference
If hardware-based encryption is not available, BitLocker software-based encryption is used instead.

Note: The Choose drive encryption method and cipher strength policy setting does not apply to
hardware-based encryption.

The encryption algorithm that is used by hardware-based encryption is set when the drive is partitioned. By
default, BitLocker uses the algorithm that is configured on the drive to encrypt the drive. The Restrict
encryption algorithms and cipher suites allowed for hardware-based encryption option of this setting
enables you to restrict the encryption algorithms that BitLocker can use with hardware encryption. If the
algorithm that is set for the drive is not available, BitLocker disables the use of hardware-based encryption.
Encryption algorithms are specified by object identifiers (OID ), for example:
Advanced Encryption Standard (AES ) 128 in Cipher Block Chaining (CBC ) mode OID: 2.16.840.1.101.3.4.1.2
AES 256 in CBC mode OID: 2.16.840.1.101.3.4.1.42
Configure use of hardware -based encryption for removable data drives
This policy controls how BitLocker reacts to encrypted drives when they are used as removable data drives.
Using hardware-based encryption can improve the performance of drive operations that involve frequent
reading or writing of data to the drive.

Policy description With this policy setting, you can manage BitLocker’s use
of hardware-based encryption on removable data drives
and specify which encryption algorithms it can use with
hardware-based encryption.

Introduced Windows Server 2012 and Windows 8

Drive type Removable data drive

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Removable Data Drives

Conflicts None
 When enabled You can specify additional options that control whether
BitLocker software-based encryption is used instead of
hardware-based encryption on computers that do not
support hardware-based encryption. You can also specify
whether you want to restrict the encryption algorithms
and cipher suites that are used with hardware-based
encryption.

When disabled BitLocker cannot use hardware-based encryption with

removable data drives, and BitLocker software-based
encryption is used by default when the drive in
encrypted.

When not configured BitLocker uses hardware-based encryption with the

encryption algorithm that is set for the drive. If
hardware-based encryption is not available, BitLocker
software-based encryption is used instead.

Reference
If hardware-based encryption is not available, BitLocker software-based encryption is used instead.

Note: The Choose drive encryption method and cipher strength policy setting does not apply to
hardware-based encryption.

The encryption algorithm that is used by hardware-based encryption is set when the drive is partitioned. By
default, BitLocker uses the algorithm that is configured on the drive to encrypt the drive. The Restrict
encryption algorithms and cipher suites allowed for hardware-based encryption option of this setting
enables you to restrict the encryption algorithms that BitLocker can use with hardware encryption. If the
algorithm that is set for the drive is not available, BitLocker disables the use of hardware-based encryption.
Encryption algorithms are specified by object identifiers (OID ), for example:
Advanced Encryption Standard (AES ) 128 in Cipher Block Chaining (CBC ) mode OID: 2.16.840.1.101.3.4.1.2
AES 256 in CBC mode OID: 2.16.840.1.101.3.4.1.42
Enforce drive encryption type on fixed data drives
This policy controls whether fixed data drives utilize Used Space Only encryption or Full encryption. Setting this
policy also causes the BitLocker Setup Wizard to skip the encryption options page so no encryption selection
displays to the user.

Policy description With this policy setting, you can configure the encryption
type that is used by BitLocker.

Introduced Windows Server 2012 and Windows 8

Drive type Fixed data drive

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Fixed Data Drives
 Conflicts None

When enabled This policy defines the encryption type that BitLocker
uses to encrypt drives, and the encryption type option is
not presented in the BitLocker Setup Wizard.

When disabled or not configured The BitLocker Setup Wizard asks the user to select the
encryption type before turning on BitLocker.

Reference
This policy setting is applied when you turn on BitLocker. Changing the encryption type has no effect if the drive
is already encrypted or if encryption is in progress. Choose Full encryption to require that the entire drive be
encrypted when BitLocker is turned on. Choose Used Space Only encryption to require that only the portion of
the drive that is used to store data is encrypted when BitLocker is turned on.

Note: This policy is ignored when you are shrinking or expanding a volume and the BitLocker driver uses
the current encryption method. For example, when a drive that is using Used Space Only encryption is
expanded, the new free space is not wiped as it would be for a drive that is using Full encryption. The user
could wipe the free space on a Used Space Only drive by using the following command: manage-bde -w. If
the volume is shrunk, no action is taken for the new free space.

For more information about the tool to manage BitLocker, see Manage-bde.
Enforce drive encryption type on operating system drives
This policy controls whether operating system drives utilize Full encryption or Used Space Only encryption.
Setting this policy also causes the BitLocker Setup Wizard to skip the encryption options page, so no encryption
selection displays to the user.

Policy description With this policy setting, you can configure the encryption
type that is used by BitLocker.

Introduced Windows Server 2012 and Windows 8

Drive type Operating system drive

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Operating System Drives

Conflicts None

When enabled The encryption type that BitLocker uses to encrypt

drives is defined by this policy, and the encryption type
option is not presented in the BitLocker Setup Wizard.
 When disabled or not configured The BitLocker Setup Wizard asks the user to select the
encryption type before turning on BitLocker.

Reference
This policy setting is applied when you turn on BitLocker. Changing the encryption type has no effect if the drive
is already encrypted or if encryption is in progress. Choose Full encryption to require that the entire drive be
encrypted when BitLocker is turned on. Choose Used Space Only encryption to require that only the portion of
the drive that is used to store data is encrypted when BitLocker is turned on.

Note: This policy is ignored when shrinking or expanding a volume, and the BitLocker driver uses the
current encryption method. For example, when a drive that is using Used Space Only encryption is
expanded, the new free space is not wiped as it would be for a drive that uses Full encryption. The user could
wipe the free space on a Used Space Only drive by using the following command: manage-bde -w. If the
volume is shrunk, no action is taken for the new free space.

For more information about the tool to manage BitLocker, see Manage-bde.
Enforce drive encryption type on removable data drives
This policy controls whether fixed data drives utilize Full encryption or Used Space Only encryption. Setting this
policy also causes the BitLocker Setup Wizard to skip the encryption options page, so no encryption selection
displays to the user.

Policy description With this policy setting, you can configure the encryption
type that is used by BitLocker.

Introduced Windows Server 2012 and Windows 8

Drive type Removable data drive

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Removable Data Drives

Conflicts None

When enabled The encryption type that BitLocker uses to encrypt

drives is defined by this policy, and the encryption type
option is not presented in the BitLocker Setup Wizard.

When disabled or not configured The BitLocker Setup Wizard asks the user to select the
encryption type before turning on BitLocker.

Reference
This policy setting is applied when you turn on BitLocker. Changing the encryption type has no effect if the drive
is already encrypted or if encryption is in progress. Choose Full encryption to require that the entire drive be
encrypted when BitLocker is turned on. Choose Used Space Only encryption to require that only the portion of
the drive that is used to store data is encrypted when BitLocker is turned on.
 Note: This policy is ignored when shrinking or expanding a volume, and the BitLocker driver uses the
current encryption method. For example, when a drive that is using Used Space Only encryption is
expanded, the new free space is not wiped as it would be for a drive that is using Full Encryption. The user
could wipe the free space on a Used Space Only drive by using the following command: manage-bde -w. If
the volume is shrunk, no action is taken for the new free space.

For more information about the tool to manage BitLocker, see Manage-bde.
Choose how BitLocker-protected operating system drives can be recovered
This policy setting is used to configure recovery methods for operating system drives.

Policy description With this policy setting, you can control how BitLocker-
protected operating system drives are recovered in the
absence of the required startup key information.

Introduced Windows Server 2008 R2 and Windows 7

Drive type Operating system drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Operating System Drives

Conflicts You must disallow the use of recovery keys if the Deny
write access to removable drives not protected by
BitLocker policy setting is enabled.
When using data recovery agents, you must enable the
Provide the unique identifiers for your organization
policy setting.

When enabled You can control the methods that are available to users
to recover data from BitLocker-protected operating
system drives.

When disabled or not configured The default recovery options are supported for BitLocker
recovery. By default, a data recovery agent is allowed,
the recovery options can be specified by the user
(including the recovery password and recovery key), and
recovery information is not backed up to AD DS.

Reference
This policy setting is applied when you turn on BitLocker.
The Allow data recovery agent check box is used to specify whether a data recovery agent can be used with
BitLocker-protected operating system drives. Before a data recovery agent can be used, it must be added from
Public Key Policies, which is located in the Group Policy Management Console (GPMC ) or in the Local Group
Policy Editor.
For more information about adding data recovery agents, see BitLocker basic deployment.
In Configure user storage of BitLocker recovery information, select whether users are allowed, required, or
not allowed to generate a 48-digit recovery password.
Select Omit recovery options from the BitLocker setup wizard to prevent users from specifying recovery
options when they enable BitLocker on a drive. This means that you will not be able to specify which recovery
option to use when you enable BitLocker. Instead, BitLocker recovery options for the drive are determined by the
policy setting.
In Save BitLocker recovery information to Active Directory Domain Services, choose which BitLocker
recovery information to store in Active Directory Domain Services (AD DS ) for operating system drives. If you
select Store recovery password and key packages, the BitLocker recovery password and the key package are
stored in AD DS. Storing the key package supports recovering data from a drive that is physically corrupted. If
you select Store recovery password only, only the recovery password is stored in AD DS.
Select the Do not enable BitLocker until recovery information is stored in AD DS for operating system
drives check box if you want to prevent users from enabling BitLocker unless the computer is connected to the
domain and the backup of BitLocker recovery information to AD DS succeeds.

Note: If the Do not enable BitLocker until recovery information is stored in AD DS for operating
system drives check box is selected, a recovery password is automatically generated.

Choose how users can recover BitLocker-protected drives (Windows Server 2008 and Windows Vista)
This policy setting is used to configure recovery methods for BitLocker-protected drives on computers running
Windows Server 2008 or Windows Vista.

Policy description With this policy setting, you can control whether the
BitLocker Setup Wizard can display and specify BitLocker
recovery options.

Introduced Windows Server 2008 and Windows Vista

Drive type Operating system drives and fixed data drives on

computers running Windows Server 2008 and Windows
Vista

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption

Conflicts This policy setting provides an administrative method of

recovering data that is encrypted by BitLocker to prevent
data loss due to lack of key information. If you choose
the Do not allow option for both user recovery options,
you must enable the Store BitLocker recovery
information in Active Directory Domain Services
(Windows Server 2008 and Windows Vista) policy
setting to prevent a policy error.

When enabled You can configure the options that the Bitlocker Setup
Wizard displays to users for recovering BitLocker
encrypted data.
 When disabled or not configured The BitLocker Setup Wizard presents users with ways to
store recovery options.

Reference
This policy is only applicable to computers running Windows Server 2008 or Windows Vista. This policy setting
is applied when you turn on BitLocker.
Two recovery options can be used to unlock BitLocker-encrypted data in the absence of the required startup key
information. Users can type a 48-digit numerical recovery password, or they can insert a USB drive that contains
a 256-bit recovery key.
Saving the recovery password to a USB drive stores the 48-digit recovery password as a text file and the 256-bit
recovery key as a hidden file. Saving it to a folder stores the 48-digit recovery password as a text file. Printing it
sends the 48-digit recovery password to the default printer. For example, not allowing the 48-digit recovery
password prevents users from printing or saving recovery information to a folder.

Important: If TPM initialization is performed during the BitLocker setup, TPM owner information is saved
or printed with the BitLocker recovery information. The 48-digit recovery password is not available in FIPS -
compliance mode.
Important: To prevent data loss, you must have a way to recover BitLocker encryption keys. If you do not
allow both recovery options, you must enable the backup of BitLocker recovery information to AD DS.
Otherwise, a policy error occurs.

Store BitLocker recovery information in Active Directory Domain Services (Windows Server 2008 and
Windows Vista)
This policy setting is used to configure the storage of BitLocker recovery information in AD DS. This provides an
administrative method of recovering data that is encrypted by BitLocker to prevent data loss due to lack of key
information.

Policy description With this policy setting, you can manage the AD DS
backup of BitLocker Drive Encryption recovery
information.

Introduced Windows Server 2008 and Windows Vista

Drive type Operating system drives and fixed data drives on

computers running Windows Server 2008 and Windows
Vista.

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption

Conflicts None

When enabled BitLocker recovery information is automatically and

silently backed up to AD DS when BitLocker is turned on
for a computer.
 When disabled or not configured BitLocker recovery information is not backed up to AD
DS.

Reference
This policy is only applicable to computers running Windows Server 2008 or Windows Vista.
This policy setting is applied when you turn on BitLocker.
BitLocker recovery information includes the recovery password and unique identifier data. You can also include a
package that contains an encryption key for a BitLocker-protected drive. This key package is secured by one or
more recovery passwords, and it can help perform specialized recovery when the disk is damaged or corrupted.
If you select Require BitLocker backup to AD DS, BitLocker cannot be turned on unless the computer is
connected to the domain and the backup of BitLocker recovery information to AD DS succeeds. This option is
selected by default to help ensure that BitLocker recovery is possible.
A recovery password is a 48-digit number that unlocks access to a BitLocker-protected drive. A key package
contains a drive’s BitLocker encryption key, which is secured by one or more recovery passwords. Key packages
may help perform specialized recovery when the disk is damaged or corrupted.
If the Require BitLocker backup to AD DS option is not selected, AD DS backup is attempted, but network or
other backup failures do not prevent the BitLocker setup. The Backup process is not automatically retried, and
the recovery password might not be stored in AD DS during BitLocker setup. TPM initialization might be needed
during the BitLocker setup. Enable the Turn on TPM backup to Active Directory Domain Services policy
setting in Computer Configuration\Administrative Templates\System\Trusted Platform Module
Services to ensure that TPM information is also backed up.
For more information about this setting, see TPM Group Policy settings.
Choose default folder for recovery password
This policy setting is used to configure the default folder for recovery passwords.

Policy description With this policy setting, you can specify the default path
that is displayed when the BitLocker Setup Wizard
prompts the user to enter the location of a folder in
which to save the recovery password.

Introduced Windows Vista

Drive type All drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption

Conflicts None
 When enabled You can specify the path that will be used as the default
folder location when the user chooses the option to save
the recovery password in a folder. You can specify a fully
qualified path or include the target computer's
environment variables in the path. If the path is not valid,
the BitLocker Setup Wizard displays the computer's top-
level folder view.

When disabled or not configured The BitLocker Setup Wizard displays the computer's top-
level folder view when the user chooses the option to
save the recovery password in a folder.

Reference
This policy setting is applied when you turn on BitLocker.

Note: This policy setting does not prevent the user from saving the recovery password in another folder.

Choose how BitLocker-protected fixed drives can be recovered

This policy setting is used to configure recovery methods for fixed data drives.

Policy description With this policy setting, you can control how BitLocker-
protected fixed data drives are recovered in the absence
of the required credentials.

Introduced Windows Server 2008 R2 and Windows 7

Drive type Fixed data drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Fixed Data Drives

Conflicts You must disallow the use of recovery keys if the Deny
write access to removable drives not protected by
BitLocker policy setting is enabled.
When using data recovery agents, you must enable and
configure the Provide the unique identifiers for your
organization policy setting.

When enabled You can control the methods that are available to users
to recover data from BitLocker-protected fixed data
drives.

When disabled or not configured The default recovery options are supported for BitLocker
recovery. By default, a data recovery agent is allowed,
the recovery options can be specified by the user
(including the recovery password and recovery key), and
recovery information is not backed up to AD DS.
Reference
This policy setting is applied when you turn on BitLocker.
The Allow data recovery agent check box is used to specify whether a data recovery agent can be used with
BitLocker-protected fixed data drives. Before a data recovery agent can be used, it must be added from Public
Key Policies, which is located in the Group Policy Management Console (GPMC ) or in the Local Group Policy
Editor.
In Configure user storage of BitLocker recovery information, select whether users are allowed, required, or
not allowed to generate a 48-digit recovery password or a 256-bit recovery key.
Select Omit recovery options from the BitLocker setup wizard to prevent users from specifying recovery
options when they enable BitLocker on a drive. This means that you cannot specify which recovery option to use
when you enable BitLocker. Instead, BitLocker recovery options for the drive are determined by the policy
setting.
In Save BitLocker recovery information to Active Directory Doman Services, choose which BitLocker
recovery information to store in AD DS for fixed data drives. If you select Backup recovery password and key
package, the BitLocker recovery password and the key package are stored in AD DS. Storing the key package
supports recovering data from a drive that has been physically corrupted. To recover this data, you can use the
Repair-bde command-line tool. If you select Backup recovery password only, only the recovery password is
stored in AD DS.
For more information about the BitLocker repair tool, see Repair-bde.
Select the Do not enable BitLocker until recovery information is stored in AD DS for fixed data drives
check box if you want to prevent users from enabling BitLocker unless the computer is connected to the domain
and the backup of BitLocker recovery information to AD DS succeeds.

Note: If the Do not enable BitLocker until recovery information is stored in AD DS for fixed data
drives check box is selected, a recovery password is automatically generated.

Choose how BitLocker-protected removable drives can be recovered

This policy setting is used to configure recovery methods for removable data drives.

Policy description With this policy setting, you can control how BitLocker-
protected removable data drives are recovered in the
absence of the required credentials.

Introduced Windows Server 2008 R2 and Windows 7

Drive type Removable data drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Removable Data Drives
 Conflicts You must disallow the use of recovery keys if the Deny
write access to removable drives not protected by
BitLocker policy setting is enabled.
When using data recovery agents, you must enable and
configure the Provide the unique identifiers for your
organization policy setting.

When enabled You can control the methods that are available to users
to recover data from BitLocker-protected removable data
drives.

When disabled or not configured The default recovery options are supported for BitLocker
recovery. By default, a data recovery agent is allowed,
the recovery options can be specified by the user
(including the recovery password and recovery key), and
recovery information is not backed up to AD DS.

Reference
This policy setting is applied when you turn on BitLocker.
The Allow data recovery agent check box is used to specify whether a data recovery agent can be used with
BitLocker-protected removable data drives. Before a data recovery agent can be used, it must be added from
Public Key Policies , which is accessed using the GPMC or the Local Group Policy Editor.
In Configure user storage of BitLocker recovery information, select whether users are allowed, required, or
not allowed to generate a 48-digit recovery password.
Select Omit recovery options from the BitLocker setup wizard to prevent users from specifying recovery
options when they enable BitLocker on a drive. This means that you cannot specify which recovery option to use
when you enable BitLocker. Instead, BitLocker recovery options for the drive are determined by the policy
setting.
In Save BitLocker recovery information to Active Directory Domain Services, choose which BitLocker
recovery information to store in AD DS for removable data drives. If you select Backup recovery password
and key package, the BitLocker recovery password and the key package are stored in AD DS. If you select
Backup recovery password only, only the recovery password is stored in AD DS.
Select the Do not enable BitLocker until recovery information is stored in AD DS for removable data
drives check box if you want to prevent users from enabling BitLocker unless the computer is connected to the
domain and the backup of BitLocker recovery information to AD DS succeeds.

Note: If the Do not enable BitLocker until recovery information is stored in AD DS for fixed data
drives check box is selected, a recovery password is automatically generated.

Configure the pre -boot recovery message and URL

This policy setting is used to configure the entire recovery message and to replace the existing URL that is
displayed on the pre-boot recovery screen when the operating system drive is locked.

Policy description With this policy setting, you can configure the BitLocker
recovery screen to display a customized message and
URL.
 Introduced Windows 10

Drive type Operating system drives

Policy path Computer Configuration \ Administrative Templates \

Windows Components \ BitLocker Drive Encryption \
Operating System Drives \ Configure pre-boot recovery
message and URL

Conflicts None

When enabled The customized message and URL are displayed on the
pre-boot recovery screen. If you have previously enabled
a custom recovery message and URL and want to revert
to the default message and URL, you must keep the
policy setting enabled and select the Use default
recovery message and URL option.

When disabled or not configured If the setting has not been previously enabled the default
pre-boot recovery screen is displayed for BitLocker
recovery. If the setting previously was enabled and is
subsequently disabled the last message in Boot
Configuration Data (BCD) is displayed whether it was the
default recovery message or the custom message.

Reference
Enabling the Configure the pre-boot recovery message and URL policy setting allows you to customize the
default recovery screen message and URL to assist customers in recovering their key.
Once you enable the setting you have three options:
If you select the Use default recovery message and URL option, the default BitLocker recovery message
and URL will be displayed on the pre-boot recovery screen.
If you select the Use custom recovery message option, type the custom message in the Custom recovery
message option text box. The message that you type in the Custom recovery message option text box
will be displayed on the pre-boot recovery screen. If a recovery URL is available, include it in the message.
If you select the Use custom recovery URL option, type the custom message URL in the Custom recovery
URL option text box. The URL that you type in the Custom recovery URL option text box replaces the
default URL in the default recovery message, which will be displayed on the pre-boot recovery screen.

Important: Not all characters and languages are supported in the pre-boot environment. We strongly
recommended that you verify the correct appearance of the characters that you use for the custom message
and URL on the pre-boot recovery screen.
Important: Because you can alter the BCDEdit commands manually before you have set Group Policy
settings, you cannot return the policy setting to the default setting by selecting the Not Configured option
after you have configured this policy setting. To return to the default pre-boot recovery screen leave the
policy setting enabled and select the Use default message options from the Choose an option for the
pre-boot recovery message drop-down list box.

Allow Secure Boot for integrity validation

This policy controls how BitLocker-enabled system volumes are handled in conjunction with the Secure Boot
feature. Enabling this feature forces Secure Boot validation during the boot process and verifies Boot
Configuration Data (BCD ) settings according to the Secure Boot policy.

Policy description With this policy setting, you can configure whether
Secure Boot will be allowed as the platform integrity
provider for BitLocker operating system drives.

Introduced Windows Server 2012 and Windows 8

Drive type All drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Operating System Drives

Conflicts If you enable Allow Secure Boot for integrity

validation, make sure the Configure TPM platform
validation profile for native UEFI firmware
configurations Group Policy setting is not enabled or
include PCR 7 to allow BitLocker to use Secure Boot for
platform or BCD integrity validation.
For more information about PCR 7, see Platform
Configuration Register (PCR) in this topic.

When enabled or not configured BitLocker uses Secure Boot for platform integrity if the
platform is capable of Secure Boot-based integrity
validation.

When disabled BitLocker uses legacy platform integrity validation, even

on systems that are capable of Secure Boot-based
integrity validation.

Reference
Secure Boot ensures that the computer's preboot environment loads only firmware that is digitally signed by
authorized software publishers. Secure Boot also provides more flexibility for managing preboot configurations
than BitLocker integrity checks prior to Windows Server 2012 and Windows 8. When this policy is enabled and
the hardware is capable of using Secure Boot for BitLocker scenarios, the Use enhanced Boot Configuration
Data validation profile Group Policy setting is ignored, and Secure Boot verifies BCD settings according to the
Secure Boot policy setting, which is configured separately from BitLocker.

Warning: Enabling this policy might result in BitLocker recovery when manufacturer-specific firmware is
updated. If you disable this policy, suspend BitLocker prior to applying firmware updates.

Provide the unique identifiers for your organization

This policy setting is used to establish an identifier that is applied to all drives that are encrypted in your
organization.
 Policy description With this policy setting, you can associate unique
organizational identifiers to a new drive that is enabled
with BitLocker.

Introduced Windows Server 2008 R2 and Windows 7

Drive type All drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption

Conflicts Identification fields are required to manage certificate-

based data recovery agents on BitLocker-protected
drives. BitLocker manages and updates certificate-based
data recovery agents only when the identification field is
present on a drive and it is identical to the value that is
configured on the computer.

When enabled You can configure the identification field on the

BitLocker-protected drive and any allowed identification
field that is used by your organization.

When disabled or not configured The identification field is not required.

Reference
These identifiers are stored as the identification field and the allowed identification field. The identification field
allows you to associate a unique organizational identifier to BitLocker-protected drives. This identifier is
automatically added to new BitLocker-protected drives, and it can be updated on existing BitLocker-protected
drives by using the Manage-bde command-line tool.
An identification field is required to manage certificate-based data recovery agents on BitLocker-protected drives
and for potential updates to the BitLocker To Go Reader. BitLocker manages and updates data recovery agents
only when the identification field on the drive matches the value that is configured in the identification field. In a
similar manner, BitLocker updates the BitLocker To Go Reader only when the identification field on the drive
matches the value that is configured for the identification field.
For more information about the tool to manage BitLocker, see Manage-bde.
The allowed identification field is used in combination with the Deny write access to removable drives not
protected by BitLocker policy setting to help control the use of removable drives in your organization. It is a
comma-separated list of identification fields from your organization or external organizations.
You can configure the identification fields on existing drives by using the Manage-bde command-line tool.
When a BitLocker-protected drive is mounted on another BitLocker-enabled computer, the identification field
and the allowed identification field are used to determine whether the drive is from an outside organization.
Multiple values separated by commas can be entered in the identification and allowed identification fields. The
identification field can be any value up to 260 characters.
Prevent memory overwrite on restart
This policy setting is used to control whether the computer's memory will be overwritten the next time the
computer is restarted.

Policy description With this policy setting, you can control computer restart
performance at the risk of exposing BitLocker secrets.

Introduced Windows Vista

Drive type All drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption

Conflicts None

When enabled The computer will not overwrite memory when it

restarts. Preventing memory overwrite may improve
restart performance, but it increases the risk of exposing
BitLocker secrets.

When disabled or not configured BitLocker secrets are removed from memory when the
computer restarts.

Reference
This policy setting is applied when you turn on BitLocker. BitLocker secrets include key material that is used to
encrypt data. This policy setting applies only when BitLocker protection is enabled.
Configure TPM platform validation profile for BIOS -based firmware configurations
This policy setting determines what values the TPM measures when it validates early boot components before it
unlocks an operating system drive on a computer with a BIOS configuration or with UEFI firmware that has the
Compatibility Support Module (CSM ) enabled.

Policy description With this policy setting, you can configure how the
computer's TPM security hardware secures the BitLocker
encryption key.

Introduced Windows Server 2012 and Windows 8

Drive type Operating system drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Operating System Drives

Conflicts None
 When enabled You can configure the boot components that the TPM
validates before unlocking access to the BitLocker-
encrypted operating system drive. If any of these
components change while BitLocker protection is in
effect, the TPM does not release the encryption key to
unlock the drive. Instead, the computer displays the
BitLocker Recovery console and requires that the
recovery password or the recovery key is provided to
unlock the drive.

When disabled or not configured The TPM uses the default platform validation profile or
the platform validation profile that is specified by the
setup script.

Reference
This policy setting does not apply if the computer does not have a compatible TPM or if BitLocker has already
been turned on with TPM protection.

Important: This Group Policy setting only applies to computers with BIOS configurations or to computers
with UEFI firmware with the CSM enabled. Computers that use a native UEFI firmware configuration store
different values in the Platform Configuration Registers (PCRs). Use the Configure TPM platform
validation profile for native UEFI firmware configurations Group Policy setting to configure the TPM
PCR profile for computers that use native UEFI firmware.

A platform validation profile consists of a set of PCR indices that range from 0 to 23. The default platform
validation profile secures the encryption key against changes to the following:
Core Root of Trust of Measurement (CRTM ), BIOS, and Platform Extensions (PCR 0)
Option ROM Code (PCR 2)
Master Boot Record (MBR ) Code (PCR 4)
NTFS Boot Sector (PCR 8)
NTFS Boot Block (PCR 9)
Boot Manager (PCR 10)
BitLocker Access Control (PCR 11)

Note: Changing from the default platform validation profile affects the security and manageability of your
computer. BitLocker’s sensitivity to platform modifications (malicious or authorized) is increased or
decreased depending on inclusion or exclusion (respectively) of the PCRs.

The following list identifies all of the PCRs available:

PCR 0: Core root-of-trust for measurement, BIOS, and Platform extensions
PCR 1: Platform and motherboard configuration and data.
PCR 2: Option ROM code
PCR 3: Option ROM data and configuration
PCR 4: Master Boot Record (MBR ) code
PCR 5: Master Boot Record (MBR ) partition table
PCR 6: State transition and wake events
PCR 7: Computer manufacturer-specific
PCR 8: NTFS boot sector
PCR 9: NTFS boot block
 PCR 10: Boot manager
PCR 11: BitLocker access control
PCR 12-23: Reserved for future use
Configure TPM platform validation profile (Windows Vista, Windows Server 2008, Windows 7, Windows
Server 2008 R2)
This policy setting determines what values the TPM measures when it validates early boot components before
unlocking a drive on a computer running Windows Vista, Windows Server 2008, or Windows 7.

Policy description With this policy setting, you can configure how the
computer's TPM security hardware secures the BitLocker
encryption key.

Introduced Windows Server 2008 and Windows Vista

Drive type Operating system drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Operating System Drives

Conflicts None

When enabled You can configure the boot components that the TPM
validates before unlocking access to the BitLocker-
encrypted operating system drive. If any of these
components change while BitLocker protection is in
effect, the TPM does not release the encryption key to
unlock the drive. Instead, the computer displays the
BitLocker Recovery console and requires that the
recovery password or the recovery key is provided to
unlock the drive.

When disabled or not configured The TPM uses the default platform validation profile or
the platform validation profile that is specified by the
setup script.

Reference
This policy setting does not apply if the computer does not have a compatible TPM or if BitLocker is already
turned on with TPM protection.
A platform validation profile consists of a set of PCR indices that range from 0 to 23. The default platform
validation profile secures the encryption key against changes to the following:
Core Root of Trust of Measurement (CRTM ), BIOS, and Platform Extensions (PCR 0)
Option ROM Code (PCR 2)
Master Boot Record (MBR ) Code (PCR 4)
NTFS Boot Sector (PCR 8)
NTFS Boot Block (PCR 9)
Boot Manager (PCR 10)
 BitLocker Access Control (PCR 11)

Note: The default TPM validation profile PCR settings for computers that use an Extensible Firmware
Interface (EFI) are the PCRs 0, 2, 4, and 11 only.

The following list identifies all of the PCRs available:

PCR 0: Core root-of-trust for measurement, EFI boot and run-time services, EFI drivers embedded in system
ROM, ACPI static tables, embedded SMM code, and BIOS code
PCR 1: Platform and motherboard configuration and data. Hand-off tables and EFI variables that affect
system configuration
PCR 2: Option ROM code
PCR 3: Option ROM data and configuration
PCR 4: Master Boot Record (MBR ) code or code from other boot devices
PCR 5: Master Boot Record (MBR ) partition table. Various EFI variables and the GPT table
PCR 6: State transition and wake events
PCR 7: Computer manufacturer-specific
PCR 8: NTFS boot sector
PCR 9: NTFS boot block
PCR 10: Boot manager
PCR 11: BitLocker access control
PCR 12 - 23: Reserved for future use

Warning: Changing from the default platform validation profile affects the security and manageability of
your computer. BitLocker's sensitivity to platform modifications (malicious or authorized) is increased or
decreased depending on inclusion or exclusion (respectively) of the PCRs.

Configure TPM platform validation profile for native UEFI firmware configurations
This policy setting determines what values the TPM measures when it validates early boot components before
unlocking an operating system drive on a computer with native UEFI firmware configurations.

Policy description With this policy setting, you can configure how the
computer's Trusted Platform Module (TPM) security
hardware secures the BitLocker encryption key.

Introduced Windows Server 2012 and Windows 8

Drive type Operating system drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Operating System Drives
 Conflicts Setting this policy with PCR 7 omitted, overrides the
Allow Secure Boot for integrity validation Group
Policy setting, and it prevents BitLocker from using
Secure Boot for platform or Boot Configuration Data
(BCD) integrity validation.
If your environments use TPM and Secure Boot for
platform integrity checks, this policy should not be
configured.
For more information about PCR 7, see Platform
Configuration Register (PCR) in this topic.

When enabled Before you turn on BitLocker, you can configure the boot
components that the TPM validates before it unlocks
access to the BitLocker-encrypted operating system
drive. If any of these components change while BitLocker
protection is in effect, the TPM does not release the
encryption key to unlock the drive. Instead, the
computer displays the BitLocker Recovery console and
requires that the recovery password or the recovery key
is provided to unlock the drive.

When disabled or not configured BitLocker uses the default platform validation profile or
the platform validation profile that is specified by the
setup script.

Reference
This policy setting does not apply if the computer does not have a compatible TPM or if BitLocker is already
turned on with TPM protection.

Important: This Group Policy setting only applies to computers with a native UEFI firmware configuration.
Computers with BIOS or UEFI firmware with a Compatibility Support Module (CSM ) enabled store different
values in the Platform Configuration Registers (PCRs). Use the Configure TPM platform validation
profile for BIOS -based firmware configurations Group Policy setting to configure the TPM PCR profile
for computers with BIOS configurations or for computers with UEFI firmware with a CSM enabled.

A platform validation profile consists of a set of Platform Configuration Register (PCR ) indices ranging from 0 to
23. The default platform validation profile secures the encryption key against changes to the core system
firmware executable code (PCR 0), extended or pluggable executable code (PCR 2), boot manager (PCR 4), and
the BitLocker access control (PCR 11).
The following list identifies all of the PCRs available:
PCR 0: Core System Firmware executable code
PCR 1: Core System Firmware data
PCR 2: Extended or pluggable executable code
PCR 3: Extended or pluggable firmware data
PCR 4: Boot Manager
PCR 5: GPT/Partition Table
PCR 6: Resume from S4 and S5 Power State Events
PCR 7: Secure Boot State
For more information about this PCR, see Platform Configuration Register (PCR ) in this topic.
 PCR 8: Initialized to 0 with no Extends (reserved for future use)
PCR 9: Initialized to 0 with no Extends (reserved for future use)
PCR 10: Initialized to 0 with no Extends (reserved for future use)
PCR 11: BitLocker access control
PCR 12: Data events and highly volatile events
PCR 13: Boot Module Details
PCR 14: Boot Authorities
PCR 15 – 23: Reserved for future use

Warning: Changing from the default platform validation profile affects the security and manageability of
your computer. BitLocker's sensitivity to platform modifications (malicious or authorized) is increased or
decreased depending on inclusion or exclusion (respectively) of the PCRs.

Reset platform validation data after BitLocker recovery

This policy setting determines if you want platform validation data to refresh when Windows is started following
a BitLocker recovery. A platform validation data profile consists of the values in a set of Platform Configuration
Register (PCR ) indices that range from 0 to 23.

Policy description With this policy setting, you can control whether
platform validation data is refreshed when Windows is
started following a BitLocker recovery.

Introduced Windows Server 2012 and Windows 8

Drive type Operating system drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Operating System Drives

Conflicts None

When enabled Platform validation data is refreshed when Windows is

started following a BitLocker recovery.

When disabled Platform validation data is not refreshed when Windows

is started following a BitLocker recovery.

When not configured Platform validation data is refreshed when Windows is

started following a BitLocker recovery.

Reference
For more information about the recovery process, see the BitLocker recovery guide.
Use enhanced Boot Configuration Data validation profile
This policy setting determines specific Boot Configuration Data (BCD ) settings to verify during platform
validation. A platform validation uses the data in the platform validation profile, which consists of a set of
Platform Configuration Register (PCR ) indices that range from 0 to 23.

Policy description With this policy setting, you can specify Boot
Configuration Data (BCD) settings to verify during
platform validation.

Introduced Windows Server 2012 and Windows 8

Drive type Operating system drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Operating System Drives

Conflicts When BitLocker is using Secure Boot for platform and

Boot Configuration Data integrity validation, the Use
enhanced Boot Configuration Data validation
profile Group Policy setting is ignored (as defined by the
Allow Secure Boot for integrity validation Group
Policy setting).

When enabled You can add additional BCD settings, exclude the BCD
settings you specify, or combine inclusion and exclusion
lists to create a customized BCD validation profile, which
gives you the ability to verify those BCD settings.

When disabled The computer reverts to a BCD profile validation similar

to the default BCD profile that is used by Windows 7.

When not configured The computer verifies the default BCD settings in
Windows.

Reference

Note: The setting that controls boot debugging (0x16000010) is always validated, and it has no effect if it is
included in the inclusion or the exclusion list.

Allow access to BitLocker-protected fixed data drives from earlier versions of Windows
This policy setting is used to control whether access to drives is allowed by using the BitLocker To Go Reader,
and if the application is installed on the drive.

Policy description With this policy setting, you can configure whether fixed
data drives that are formatted with the FAT file system
can be unlocked and viewed on computers running
Windows Vista, Windows XP with Service Pack 3 (SP3), or
Windows XP with Service Pack 2 (SP2).

Introduced Windows Server 2008 R2 and Windows 7

 Drive type Fixed data drives

Policy path Computer Configuration\Administrative

Templates\Windows Components\BitLocker Drive
Encryption\Fixed Data Drives

Conflicts None

When enabled and When not configured Fixed data drives that are formatted with the FAT file
system can be unlocked on computers running Windows
Server 2008, Windows Vista, Windows XP with SP3, or
Windows XP with SP2, and their content can be viewed.
These operating systems have Read-only access to
BitLocker-protected drives.

When disabled Fixed data drives that are formatted with the FAT file
system and are BitLocker-protected cannot be unlocked
on computers running Windows Vista, Windows XP with
SP3, or Windows XP with SP2. BitLocker To Go Reader
(bitlockertogo.exe) is not installed.

Reference

Note: This policy setting does not apply to drives that are formatted with the NTFS file system.

When this policy setting is enabled, select the Do not install BitLocker To Go Reader on FAT formatted
fixed drives check box to help prevent users from running BitLocker To Go Reader from their fixed drives. If
BitLocker To Go Reader (bitlockertogo.exe) is present on a drive that does not have an identification field
specified, or if the drive has the same identification field as specified in the Provide unique identifiers for your
organization policy setting, the user is prompted to update BitLocker, and BitLocker To Go Reader is deleted
from the drive. In this situation, for the fixed drive to be unlocked on computers running Windows Vista,
Windows XP with SP3, or Windows XP with SP2, BitLocker To Go Reader must be installed on the computer. If
this check box is not selected, BitLocker To Go Reader will be installed on the fixed drive to enable users to
unlock the drive on computers running Windows Vista, Windows XP with SP3, or Windows XP with SP2.
Allow access to BitLocker-protected removable data drives from earlier versions of Windows
This policy setting controls access to removable data drives that are using the BitLocker To Go Reader and
whether the BitLocker To Go Reader can be installed on the drive.

Policy description With this policy setting, you can configure whether
removable data drives that are formatted with the FAT
file system can be unlocked and viewed on computers
running Windows Vista, Windows XP with SP3, or
Windows XP with SP2.

Introduced Windows Server 2008 R2 and Windows 7

Drive type Removable data drives

 Policy path Computer Configuration\Administrative
Templates\Windows Components\BitLocker Drive
Encryption\Removable Data Drives

Conflicts None

When enabled and When not configured Removable data drives that are formatted with the FAT
file system can be unlocked on computers running
Windows Vista, Windows XP with SP3, or Windows XP
with SP2, and their content can be viewed. These
operating systems have Read-only access to BitLocker-
protected drives.

When disabled Removable data drives that are formatted with the FAT
file system that are BitLocker-protected cannot be
unlocked on computers running Windows Vista,
Windows XP with SP3, or Windows XP with SP2.
BitLocker To Go Reader (bitlockertogo.exe) is not
installed.

Reference

Note: This policy setting does not apply to drives that are formatted with the NTFS file system.

When this policy setting is enabled, select the Do not install BitLocker To Go Reader on FAT formatted
removable drives check box to help prevent users from running BitLocker To Go Reader from their removable
drives. If BitLocker To Go Reader (bitlockertogo.exe) is present on a drive that does not have an identification
field specified, or if the drive has the same identification field as specified in the Provide unique identifiers for
your organization policy setting, the user will be prompted to update BitLocker, and BitLocker To Go Reader is
deleted from the drive. In this situation, for the removable drive to be unlocked on computers running Windows
Vista, Windows XP with SP3, or Windows XP with SP2, BitLocker To Go Reader must be installed on the
computer. If this check box is not selected, BitLocker To Go Reader will be installed on the removable drive to
enable users to unlock the drive on computers running Windows Vista, Windows XP with SP3, or Windows XP
with SP2 that do not have BitLocker To Go Reader installed.

FIPS setting
You can configure the Federal Information Processing Standard (FIPS ) setting for FIPS compliance. As an effect
of FIPS compliance, users cannot create or save a BitLocker password for recovery or as a key protector. The use
of a recovery key is permitted.

Policy description Notes

Introduced Windows Server 2003 with SP1

Drive type System-wide

 Policy path Local Policies\Security Options\System cryptography:
Use FIPS compliant algorithms for encryption,
hashing, and signing

Conflicts Some applications, such as Terminal Services, do not

support FIPS-140 on all operating systems.

When enabled Users will be unable to save a recovery password to any

location. This includes AD DS and network folders. In
addition, you cannot use WMI or the BitLocker Drive
Encryption Setup izard to create a recovery password.

When disabled or not configured No BitLocker encryption key is generated

Reference
This policy needs to be enabled before any encryption key is generated for BitLocker. Note that when this policy
is enabled, BitLocker prevents creating or using recovery passwords, so recovery keys should be used instead.
You can save the optional recovery key to a USB drive. Because recovery passwords cannot be saved to AD DS
when FIPS is enabled, an error is caused if AD DS backup is required by Group Policy.
You can edit the FIPS setting by using the Security Policy Editor (Secpol.msc) or by editing the Windows registry.
You must be an administrator to perform these procedures.
For more information about setting this policy, see System cryptography: Use FIPS compliant algorithms for
encryption, hashing, and signing.

Power management Group Policy settings: Sleep and Hibernate

PCs default power settings for a computer will cause the computer to enter Sleep mode frequently to conserve
power when idle and to help extend the system’s battery life. When a computer transitions to Sleep, open
programs and documents are persisted in memory. When a computer resumes from Sleep, users are not
required to re-authenticate with a PIN or USB startup key to access encrypted data. This might lead to
conditions where data security is compromised.
However, when a computer hibernates the drive is locked, and when it resumes from hibernation the drive is
unlocked, which means that users will need to provide a PIN or a startup key if using multifactor authentication
with BitLocker. Therefore, organizations that use BitLocker may want to use Hibernate instead of Sleep for
improved security. This setting does not have an impact on TPM -only mode, because it provides a transparent
user experience at startup and when resuming from the Hibernate states.
You can use disable the following Group Policy settings, which are located in Computer
Configuration\Administrative Templates\System\Power Management to disable all available sleep states:
Allow Standby States (S1-S3) When Sleeping (Plugged In)
Allow Standby States (S1-S3) When Sleeping (Battery)

About the Platform Configuration Register (PCR)

A platform validation profile consists of a set of PCR indices that range from 0 to 23. The scope of the values can
be specific to the version of the operating system.
Changing from the default platform validation profile affects the security and manageability of your computer.
BitLocker’s sensitivity to platform modifications (malicious or authorized) is increased or decreased depending
on inclusion or exclusion (respectively) of the PCRs.
About PCR 7
PCR 7 measures the state of Secure Boot. With PCR 7, BitLocker can leverage Secure Boot for integrity
validation. Secure Boot ensures that the computer's preboot environment loads only firmware that is digitally
signed by authorized software publishers. PCR 7 measurements indicate whether Secure Boot is on and which
keys are trusted on the platform. If Secure Boot is on and the firmware measures PCR 7 correctly per the UEFI
specification, BitLocker can bind to this information rather than to PCRs 0, 2, and 4 which have the
measurements of the exact firmware and Bootmgr images loaded. This reduces the likelihood of BitLocker
starting in recovery mode as a result of firmware and image updates, and it provides you with greater flexibility
to manage the preboot configuration.
PCR 7 measurements must follow the guidance that is described in Appendix A Trusted Execution Environment
EFI Protocol.
PCR 7 measurements are a mandatory logo requirement for systems that support Modern Standby (also known
as Always On, Always Connected PCs), such as the Microsoft Surface RT. On such systems, if the TPM with PCR
7 measurement and Secure Boot are correctly configured, BitLocker binds to PCR 7 and PCR 11 by default.

See also
Trusted Platform Module
TPM Group Policy settings
BitLocker frequently asked questions (FAQ )
BitLocker overview
Prepare your organization for BitLocker: Planning and policies
 BCD settings and BitLocker
2/7/2018 • 6 minutes to read • Edit Online

Applies to
Windows 10
This topic for IT professionals describes the BCD settings that are used by BitLocker.
When protecting data at rest on an operating system volume, during the boot process BitLocker verifies that the
security sensitive boot configuration data (BCD ) settings have not changed since BitLocker was last enabled,
resumed, or recovered.

BitLocker and BCD Settings

In Windows 7 and Windows Server 2008 R2, BitLocker validated nearly all BCD settings with the winload,
winresume, and memtest prefixes. However, this high degree of validation caused BitLocker to go into recovery
mode for benign setting changes, for example, when applying a language pack BitLocker would enter recovery.
In Windows 8, Windows Server 2012, and later operating systems BitLocker narrows the set of BCD settings
validated to reduce the chance of benign changes causing a BCD validation problem. If you believe that there is a
risk in excluding a particular BCD setting from the validation profile, you can increase BCD validation coverage to
suit your validation preferences. Alternatively, if a default BCD setting is persistently triggering recovery for
benign changes, then you can exclude that BCD setting from the validation profile.
When secure boot is enabled
Computers with UEFI firmware can use Secure Boot to provide enhanced boot security. When BitLocker is able to
use Secure Boot for platform and BCD integrity validation, as defined by the Allow Secure Boot for integrity
validation group policy setting, the Use enhanced Boot Configuration Data validation profile group policy
is ignored.
One of the benefits of using Secure Boot is that it can correct BCD settings during boot without triggering
recovery events. Secure Boot enforces the same BCD settings as BitLocker. Secure Boot BCD enforcement is not
configurable from within the operating system.

Customizing BCD validation settings

To modify the BCD settings BitLocker validates the IT Pro will add or exclude BCD settings from the platform
validation profile by enabling and configuring the Use enhanced Boot Configuration Data validation profile
Group Policy setting.
For the purposes of BitLocker validation, BCD settings are associated with a specific set of Microsoft boot
applications. BCD settings are either associated with a specific boot application or can apply to all boot
applications by associating a prefix to the BCD setting entered in the Group Policy setting. Prefix values include:
winload
winresume
memtest
all
All BCD settings are specified by combining the prefix value with either a hexadecimal (hex) value or a “friendly
name.”
The BCD setting hex value is reported when BitLocker enters recovery mode and is stored in the event log (event
ID 523). The hex value uniquely identifies which BCD setting caused the recovery event.
You can quickly obtain the friendly name for the BCD settings on your computer by using the command “
bcdedit.exe /enum all ”.

Not all BCD settings have friendly names, for those settings the hex value is the only way to configure an exclusion
policy.
When specifying BCD values in the Use enhanced Boot Configuration Data validation profile Group Policy
setting, use the following syntax:
Prefix the setting with the boot application prefix
Append a colon ‘:’
Append either the hex value or the friendly name
If entering more than one BCD setting, you will need to enter each BCD setting on a new line
For example, either “ winload:hypervisordebugport ” or “ winload:0x250000f4 ” yield the same value.
Setting that applies to all boot applications may be applied only to an individual application, however the reverse is
not true. For example, one can specify either: “ all:locale ” or “ winresume:locale ”, but as the bcd setting “ win-pe ”
does not apply to all boot applications, “ winload:winpe ” is valid, but “ all:winpe ” is not valid. The setting that
controls boot debugging (“ bootdebug ” or 0x16000010) will always be validated and will have no effect if it is
included in the provided fields.

Note: Take care when configuring BCD entries in the Group Policy setting. The Local Group Policy Editor does
not validate the correctness of the BCD entry. BitLocker will fail to be enabled if the Group Policy setting
specified is invalid.

Default BCD validation profile

The following table contains the default BCD validation profile used by BitLocker in Windows 8, Windows Server
2012, and later operating systems:

HEX VALUE PREFIX FRIENDLY NAME

0x11000001 all device

0x12000002 all path

0x12000030 all loadoptions

0x16000010 all bootdebug

0x16000040 all advancedoptions

0x16000041 all optionsedit

0x16000048 all nointegritychecks

0x16000049 all testsigning

0x16000060 all isolatedcontext

0x1600007b all forcefipscrypto

 HEX VALUE PREFIX FRIENDLY NAME

0x22000002 winload systemroot

0x22000011 winload kernel

0x22000012 winload hal

0x22000053 winload evstore

0x25000020 winload nx

0x25000052 winload restrictapiccluster

0x26000022 winload winpe

0x26000025 winload lastknowngood

0x26000081 winload safebootalternateshell

0x260000a0 winload debug

0x260000f2 winload hypervisordebug

0x26000116 winload hypervisorusevapic

0x21000001 winresume filedevice

0x22000002 winresume filepath

0x26000006 winresume debugoptionenabled

Full list of friendly names for ignored BCD settings

This following is a full list of BCD settings with friendly names which are ignored by default. These settings are not
part of the default BitLocker validation profile, but can be added if you see a need to validate any of these settings
before allowing a BitLocker–protected operating system drive to be unlocked.

Note: Additional BCD settings exist that have hex values but do not have friendly names. These settings are
not included in this list.

HEX VALUE PREFIX FRIENDLY NAME

0x12000004 all description

0x12000005 all locale

0x12000016 all targetname

0x12000019 all busparams

0x1200001d all key

HEX VALUE PREFIX FRIENDLY NAME

0x1200004a all fontpath

0x14000006 all inherit

0x14000008 all recoverysequence

0x15000007 all truncatememory

0x1500000c all firstmegabytepolicy

0x1500000d all relocatephysical

0x1500000e all avoidlowmemory

0x15000011 all debugtype

0x15000012 all debugaddress

0x15000013 all debugport

0x15000014 all baudrate

0x15000015 all channel

0x15000018 all debugstart

0x1500001a all hostip

0x1500001b all port

0x15000022 all emsport

0x15000023 all emsbaudrate

0x15000042 all keyringaddress

0x15000047 all configaccesspolicy

0x1500004b all integrityservices

0x1500004c all volumebandid

0x15000051 all initialconsoleinput

0x15000052 all graphicsresolution

0x15000065 all displaymessage

0x15000066 all displaymessageoverride

HEX VALUE PREFIX FRIENDLY NAME

0x15000081 all logcontrol

0x16000009 all recoveryenabled

0x1600000b all badmemoryaccess

0x1600000f all traditionalkseg

0x16000017 all noumex

0x1600001c all dhcp

0x1600001e all vm

0x16000020 all bootems

0x16000046 all graphicsmodedisabled

0x16000050 all extendedinput

0x16000053 all restartonfailure

0x16000054 all highestmode

0x1600006c all bootuxdisabled

0x16000072 all nokeyboard

0x16000074 all bootshutdowndisabled

0x1700000a all badmemorylist

0x17000077 all allowedinmemorysettings

0x22000040 all fverecoveryurl

0x22000041 all fverecoverymessage

0x31000003 all ramdisksdidevice

0x32000004 all ramdisksdipath

0x35000001 all ramdiskimageoffset

0x35000002 all ramdisktftpclientport

0x35000005 all ramdiskimagelength

0x35000007 all ramdisktftpblocksize

HEX VALUE PREFIX FRIENDLY NAME

0x35000008 all ramdisktftpwindowsize

0x36000006 all exportascd

0x36000009 all ramdiskmcenabled

0x3600000a all ramdiskmctftpfallback

0x3600000b all ramdisktftpvarwindow

0x21000001 winload osdevice

0x22000013 winload dbgtransport

0x220000f9 winload hypervisorbusparams

0x22000110 winload hypervisorusekey

0x23000003 winload resumeobject

0x25000021 winload pae

0x25000031 winload removememory

0x25000032 winload increaseuserva

0x25000033 winload perfmem

0x25000050 winload clustermodeaddressing

0x25000055 winload x2apicpolicy

0x25000061 winload numproc

0x25000063 winload configflags

0x25000066 winload groupsize

0x25000071 winload msi

0x25000072 winload pciexpress

0x25000080 winload safeboot

0x250000a6 winload tscsyncpolicy

0x250000c1 winload driverloadfailurepolicy

0x250000c2 winload bootmenupolicy

HEX VALUE PREFIX FRIENDLY NAME

0x250000e0 winload bootstatuspolicy

0x250000f0 winload hypervisorlaunchtype

0x250000f3 winload hypervisordebugtype

0x250000f4 winload hypervisordebugport

0x250000f5 winload hypervisorbaudrate

0x250000f6 winload hypervisorchannel

0x250000f7 winload bootux

0x250000fa winload hypervisornumproc

0x250000fb winload hypervisorrootprocpernode

0x250000fd winload hypervisorhostip

0x250000fe winload hypervisorhostport

0x25000100 winload tpmbootentropy

0x25000113 winload hypervisorrootproc

0x25000115 winload hypervisoriommupolicy

0x25000120 winload xsavepolicy

0x25000121 winload xsaveaddfeature0

0x25000122 winload xsaveaddfeature1

0x25000123 winload xsaveaddfeature2

0x25000124 winload xsaveaddfeature3

0x25000125 winload xsaveaddfeature4

0x25000126 winload xsaveaddfeature5

0x25000127 winload xsaveaddfeature6

0x25000128 winload xsaveaddfeature7

0x25000129 winload xsaveremovefeature

0x2500012a winload xsaveprocessorsmask

HEX VALUE PREFIX FRIENDLY NAME

0x2500012b winload xsavedisable

0x25000130 winload claimedtpmcounter

0x26000004 winload stampdisks

0x26000010 winload detecthal

0x26000024 winload nocrashautoreboot

0x26000030 winload nolowmem

0x26000040 winload vga

0x26000041 winload quietboot

0x26000042 winload novesa

0x26000043 winload novga

0x26000051 winload usephysicaldestination

0x26000054 winload uselegacyapicmode

0x26000060 winload onecpu

0x26000062 winload maxproc

0x26000064 winload maxgroup

0x26000065 winload groupaware

0x26000070 winload usefirmwarepcisettings

0x26000090 winload bootlog

0x26000091 winload sos

0x260000a1 winload halbreakpoint

0x260000a2 winload useplatformclock

0x260000a3 winload forcelegacyplatform

0x260000a4 winload useplatformtick

0x260000a5 winload disabledynamictick

0x260000b0 winload ems

HEX VALUE PREFIX FRIENDLY NAME

0x260000c3 winload onetimeadvancedoptions

0x260000c4 winload onetimeoptionsedit

0x260000e1 winload disableelamdrivers

0x260000f8 winload hypervisordisableslat

0x260000fc winload hypervisoruselargevtlb

0x26000114 winload hypervisordhcp

0x21000005 winresume associatedosdevice

0x25000007 winresume bootux

0x25000008 winresume bootmenupolicy

0x26000003 winresume customsettings

0x26000004 winresume pae

0x25000001 memtest passcount

0x25000002 memtest testmix

0x25000005 memtest stridefailcount

0x25000006 memtest invcfailcount

0x25000007 memtest matsfailcount

0x25000008 memtest randfailcount

0x25000009 memtest chckrfailcount

0x26000003 memtest cacheenable

0x26000004 memtest failuresenabled

 BitLocker recovery guide
1/28/2019 • 32 minutes to read • Edit Online

Applies to
Windows 10
This topic for IT professionals describes how to recover BitLocker keys from AD DS.
Organizations can use BitLocker recovery information saved in Active Directory Domain Services (AD DS ) to
access BitLocker-protected data. Creating a recovery model for BitLocker while you are planning your BitLocker
deployment is recommended.
This article assumes that you understand how to set up AD DS to back up BitLocker recovery information
automatically, and what types of recovery information are saved to AD DS.
This article does not detail how to configure AD DS to store the BitLocker recovery information.

What is BitLocker recovery?

BitLocker recovery is the process by which you can restore access to a BitLocker-protected drive in the event that
you cannot unlock the drive normally. In a recovery scenario, you have the following options to restore access to
the drive:
The user can supply the recovery password. If your organization allows users to print or store recovery
passwords, the user can type in the 48-digit recovery password that they printed or stored on a USB drive or
with your Microsoft Account online. (Saving a recovery password with your Microsoft Account online is only
allowed when BitLocker is used on a PC that is not a member of a domain).
A data recovery agent can use their credentials to unlock the drive. If the drive is an operating system drive, the
drive must be mounted as a data drive on another computer for the data recovery agent to unlock it.
A domain administrator can obtain the recovery password from AD DS and use it to unlock the drive. Storing
recovery passwords in AD DS is recommended to provide a way for IT professionals to be able to obtain
recovery passwords for drives in their organization if needed. This method requires that you have enabled this
recovery method in the BitLocker Group Policy setting Choose how BitLocker-protected operating system
drives can be recovered located at Computer Configuration\Administrative Templates\Windows
Components\BitLocker Drive Encryption\Operating System Drives in the Local Group Policy Editor. For
more information, see BitLocker Group Policy settings.
What causes BitLocker recovery?
The following list provides examples of specific events that will cause BitLocker to enter recovery mode when
attempting to start the operating system drive:
On PCs that use BitLocker Drive Encryption, or on devices such as tablets or phones that use BitLocker Device
Encryption only, when an attack is detected, the device will immediately reboot and enter into BitLocker
recovery mode. To take advantage of this functionality Administrators can set the Interactive logon:
Machine account lockout threshold Group Policy setting located in \Computer Configuration\Windows
Settings\Security Settings\Local Policies\Security Options in the Local Group Policy Editor, or use the
MaxFailedPasswordAttempts policy of Exchange ActiveSync (also configurable through Windows Intune), to
limit the number of failed password attempts before the device goes into Device Lockout.
On devices with TPM 1.2, changing the BIOS or firmware boot device order causes BitLocker recovery.
However, devices with TPM 2.0 do not start BitLocker recovery in this case. TPM 2.0 does not consider a
firmware change of boot device order as a security threat because the OS Boot Loader is not compromised.
Having the CD or DVD drive before the hard drive in the BIOS boot order and then inserting or removing a
CD or DVD.
Failing to boot from a network drive before booting from the hard drive.
Docking or undocking a portable computer. In some instances (depending on the computer manufacturer and
the BIOS ), the docking condition of the portable computer is part of the system measurement and must be
consistent to validate the system status and unlock BitLocker. This means that if a portable computer is
connected to its docking station when BitLocker is turned on, then it might also need to be connected to the
docking station when it is unlocked. Conversely, if a portable computer is not connected to its docking station
when BitLocker is turned on, then it might need to be disconnected from the docking station when it is
unlocked.
Changes to the NTFS partition table on the disk including creating, deleting, or resizing a primary partition.
Entering the personal identification number (PIN ) incorrectly too many times so that the anti-hammering logic
of the TPM is activated. Anti-hammering logic is software or hardware methods that increase the difficulty and
cost of a brute force attack on a PIN by not accepting PIN entries until after a certain amount of time has
passed.
Turning off the support for reading the USB device in the pre-boot environment from the BIOS or UEFI
firmware if you are using USB -based keys instead of a TPM.
Turning off, disabling, deactivating, or clearing the TPM.
Upgrading critical early startup components, such as a BIOS or UEFI firmware upgrade, causing the related
boot measurements to change.
Forgetting the PIN when PIN authentication has been enabled.
Updating option ROM firmware.
Upgrading TPM firmware.
Adding or removing hardware; for example, inserting a new card in the computer, including some PCMIA
wireless cards.
Removing, inserting, or completely depleting the charge on a smart battery on a portable computer.
Changes to the master boot record on the disk.
Changes to the boot manager on the disk.
Hiding the TPM from the operating system. Some BIOS or UEFI settings can be used to prevent the
enumeration of the TPM to the operating system. When implemented, this option can make the TPM hidden
from the operating system. When the TPM is hidden, BIOS and UEFI secure startup are disabled, and the TPM
does not respond to commands from any software.
Using a different keyboard that does not correctly enter the PIN or whose keyboard map does not match the
keyboard map assumed by the pre-boot environment. This can prevent the entry of enhanced PINs.
Modifying the Platform Configuration Registers (PCRs) used by the TPM validation profile. For example,
including PCR[1] would result in BitLocker measuring most changes to BIOS settings, causing BitLocker to
enter recovery mode even when non-boot critical BIOS settings change.

Note: Some computers have BIOS settings that skip measurements to certain PCRs, such as PCR[2].
Changing this setting in the BIOS would cause BitLocker to enter recovery mode because the PCR
measurement will be different.

Moving the BitLocker-protected drive into a new computer.

Upgrading the motherboard to a new one with a new TPM.
Losing the USB flash drive containing the startup key when startup key authentication has been enabled.
Failing the TPM self-test.
Having a BIOS, UEFI firmware, or an option ROM component that is not compliant with the relevant Trusted
Computing Group standards for a client computer. For example, a non-compliant implementation may record
 volatile data (such as time) in the TPM measurements, causing different measurements on each startup and
causing BitLocker to start in recovery mode.
Changing the usage authorization for the storage root key of the TPM to a non-zero value.

Note: The BitLocker TPM initialization process sets the usage authorization value to zero, so another
user or process must explicitly have changed this value.

Disabling the code integrity check or enabling test signing on Windows Boot Manager (Bootmgr).
Pressing the F8 or F10 key during the boot process.
Adding or removing add-in cards (such as video or network cards), or upgrading firmware on add-in cards.
Using a BIOS hot key during the boot process to change the boot order to something other than the hard
drive.

Note: Before you begin recovery, we recommend that you determine what caused recovery. This might help
prevent the problem from occurring again in the future. For instance, if you determine that an attacker has
modified your computer by obtaining physical access, you can create new security policies for tracking who
has physical presence. After the recovery password has been used to recover access to the PC, BitLocker will
reseal the encryption key to the current values of the measured components.

For planned scenarios, such as a known hardware or firmware upgrades, you can avoid initiating recovery by
temporarily suspending BitLocker protection. Because suspending BitLocker leaves the drive fully encrypted, the
administrator can quickly resume BitLocker protection after the planned task has been completed. Using suspend
and resume also reseals the encryption key without requiring the entry of the recovery key.

Note: If suspended BitLocker will automatically resume protection when the PC is rebooted, unless a reboot
count is specified using the manage-bde command line tool.

If software maintenance requires the computer be restarted and you are using two-factor authentication, you can
enable BitLocker Network Unlock to provide the secondary authentication factor when the computers do not have
an on-premises user to provide the additional authentication method.
Recovery has been described within the context of unplanned or undesired behavior, but you can also cause
recovery as an intended production scenario, in order to manage access control. For example, when you redeploy
desktop or laptop computers to other departments or employees in your enterprise, you can force BitLocker into
recovery before the computer is given to a new user.

Testing recovery
Before you create a thorough BitLocker recovery process, we recommend that you test how the recovery process
works for both end users (people who call your helpdesk for the recovery password) and administrators (people
who help the end user get the recovery password). The –forcerecovery command of manage-bde is an easy way
for you to step through the recovery process before your users encounter a recovery situation.
To force a recovery for the local computer
1. Click the Start button, type cmd in the Start Search box, right-click cmd.exe, and then click Run as
administrator.
2. At the command prompt, type the following command and then press ENTER:
manage-bde -forcerecovery <BitLockerVolume>

To force recovery for a remote computer

1. On the Start screen, type cmd.exe, and then click Run as administrator.
2. At the command prompt, type the following command and then press ENTER:
manage-bde. -ComputerName <RemoteComputerName> -forcerecovery <BitLockerVolume>

Note: Recovery triggered by -forcerecovery persists for multiple restarts until a TPM protector is added or
protection is suspended by the user. When using Modern Standby devices (such as Surface devices), the
-forcerecovery option is not recommended because BitLocker will have to be unlocked and disabled
manually from the WinRE environment before the OS can boot up again. For more information, see BitLocker
Troubleshooting: Continuous reboot loop with BitLocker recovery on a slate device.

Planning your recovery process

When planning the BitLocker recovery process, first consult your organization's current best practices for
recovering sensitive information. For example: How does your enterprise handle lost Windows passwords? How
does your organization perform smart card PIN resets? You can use these best practices and related resources
(people and tools) to help formulate a BitLocker recovery model.
Organizations that rely on BitLocker Drive Encryption and BitLocker To Go to protect data on a large number of
computers and removable drives running the Windows 10, Windows 8, or Windows 7 operating systems and
Windows to Go should consider using the Microsoft BitLocker Administration and Monitoring (MBAM ) Tool
version 2.0, which is included in the Microsoft Desktop Optimization Pack (MDOP ) for Microsoft Software
Assurance. MBAM makes BitLocker implementations easier to deploy and manage and allows administrators to
provision and monitor encryption for operating system and fixed drives. MBAM prompts the user before
encrypting fixed drives. MBAM also manages recovery keys for fixed and removable drives, making recovery
easier to manage. MBAM can be used as part of a Microsoft System Center deployment or as a stand-alone
solution. For more info, see Microsoft BitLocker Administration and Monitoring.
After a BitLocker recovery has been initiated, users can use a recovery password to unlock access to encrypted
data. You must consider both self-recovery and recovery password retrieval methods for your organization.
When you determine your recovery process, you should:
Become familiar with how you can retrieve the recovery password. See:
Self-recovery
Recovery password retrieval
Determine a series of steps for post-recovery, including analyzing why the recovery occurred and resetting
the recovery password. See:
Post-recovery analysis
Self-recovery
In some cases, users might have the recovery password in a printout or a USB flash drive and can perform self-
recovery. We recommend that your organization create a policy for self-recovery. If self-recovery includes using a
password or recovery key stored on a USB flash drive, the users should be warned not to store the USB flash
drive in the same place as the PC, especially during travel, for example if both the PC and the recovery items are in
the same bag it would be very easy for access to be gained to the PC by an unauthorized user. Another policy to
consider is having users contact the Helpdesk before or after performing self-recovery so that the root cause can
be identified.
Recovery password retrieval
If the user does not have a recovery password in a printout or on a USB flash drive, the user will need to be able
to retrieve the recovery password from an online source. If the PC is a member of a domain the recovery
password can be backed up to AD DS. However, this does not happen by default, you must have configured the
appropriate Group Policy settings before BitLocker was enabled on the PC. BitLocker Group Policy settings can be
found in the Local Group Policy Editor or the Group Policy Management Console (GPMC ) under Computer
Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption. The
following policy settings define the recovery methods that can be used to restore access to a BitLocker-protected
drive if an authentication method fails or is unable to be used.
Choose how BitLocker-protected operating system drives can be recovered
Choose how BitLocker-protected fixed drives can be recovered
Choose how BitLocker-protected removable drives can be recovered In each of these policies, select
Save BitLocker recovery information to Active Directory Domain Services and then choose which
BitLocker recovery information to store in Active Directory Domain Services (AD DS ). Select the Do not
enable BitLocker until recovery information is stored in AD DS check box if you want to prevent users
from enabling BitLocker unless the computer is connected to the domain and the backup of BitLocker recovery
information for the drive to AD DS succeeds.

Note: If the PCs are part of a workgroup, users should be advised to save their BitLocker recovery password
with their Microsoft Account online. Having an online copy of your BitLocker recovery password is
recommended to help ensure that you do not lose access to your data in the event that recovery is required.

The BitLocker Recovery Password Viewer for Active Directory Users and Computers tool allows domain
administrators to view BitLocker recovery passwords for specific computer objects in Active Directory.
You can use the following list as a template for creating your own recovery process for recovery password
retrieval. This sample process uses the BitLocker Recovery Password Viewer for Active Directory Users and
Computers tool.
Record the name of the user's computer
Verify the user's identity
Locate the recovery password in AD DS
Gather information to determine why recovery occurred
Give the user the recovery password
Record the name of the user's computer
You can use the name of the user's computer to locate the recovery password in AD DS. If the user does not know
the name of the computer, ask the user to read the first word of the Drive Label in the BitLocker Drive
Encryption Password Entry user interface. This is the computer name when BitLocker was enabled and is
probably the current name of the computer.
Verify the user's identity
You should verify that the person that is asking for the recovery password is truly the authorized user of that
computer. You may also wish to verify that the computer with the name the user provided belongs to the user.
Locate the recovery password in AD DS
Locate the Computer object with the matching name in AD DS. Because Computer object names are listed in the
AD DS global catalog, you should be able to locate the object even if you have a multi-domain forest.
Multiple recovery passwords
If multiple recovery passwords are stored under a computer object in AD DS, the name of the BitLocker recovery
information object includes the date that the password was created.
If at any time you are unsure what password to provide, or if you think you might be providing the incorrect
password, ask the user to read the eight character password ID that is displayed in the recovery console.
Since the password ID is a unique value that is associated with each recovery password stored in AD DS, running
a query using this ID will find the correct password to unlock the encrypted volume.
Gather information to determine why recovery occurred
Before you give the user the recovery password, you should gather any information that will help determine why
the recovery was needed, in order to analyze the root cause during the post-recovery analysis. For more info
about post-recovery analysis, see Post-recovery analysis.
Give the user the recovery password
Because the recovery password is 48 digits long the user may need to record the password by writing it down or
typing it on a different computer. If you are using MBAM, the recovery password will be regenerated after it is
recovered from the MBAM database to avoid the security risks associated with an uncontrolled password.

Note: Because the 48-digit recovery password is long and contains a combination of digits, the user might
mishear or mistype the password. The boot-time recovery console uses built-in checksum numbers to detect
input errors in each 6-digit block of the 48-digit recovery password, and offers the user the opportunity to
correct such errors.

Post-recovery analysis
When a volume is unlocked using a recovery password, an event is written to the event log and the platform
validation measurements are reset in the TPM to match the current configuration. Unlocking the volume means
that the encryption key has been released and is ready for on-the-fly encryption when data is written to the
volume, and on-the-fly decryption when data is read from the volume. After the volume is unlocked, BitLocker
behaves the same way, regardless of how the access was granted.
If you notice that a computer is having repeated recovery password unlocks, you might want to have an
administrator can perform post-recovery analysis to determine the root cause of the recovery and refresh
BitLocker platform validation so that the user no longer needs to enter a recovery password each time that the
computer starts up. See:
Determine the root cause of the recovery
Refresh BitLocker protection
Determine the root cause of the recovery
If a user needed to recover the drive, it is important to determine the root cause that initiated the recovery as soon
as possible. Properly analyzing the state of the computer and detecting tampering may reveal threats that have
broader implications for enterprise security.
While an administrator can remotely investigate the cause of recovery in some cases, the end user might need to
bring the computer that contains the recovered drive on site to analyze the root cause further.
Review and answer the following questions for your organization:
1. What BitLocker protection mode is in effect (TPM, TPM + PIN, TPM + startup key, startup key only)? Which
PCR profile is in use on the PC?
2. Did the user merely forget the PIN or lose the startup key? If a token was lost, where might the token be?
3. If TPM mode was in effect, was recovery caused by a boot file change?
4. If recovery was caused by a boot file change, is this due to an intended user action (for example, BIOS
upgrade), or to malicious software?
5. When was the user last able to start the computer successfully, and what might have happened to the
computer since then?
6. Might the user have encountered malicious software or left the computer unattended since the last successful
startup?
To help you answer these questions, use the BitLocker command-line tool to view the current configuration and
protection mode (for example, manage-bde -status). Scan the event log to find events that help indicate why
recovery was initiated (for example, if boot file change occurred). Both of these capabilities can be performed
remotely.
Resolve the root cause
After you have identified what caused recovery, you can reset BitLocker protection and avoid recovery on every
startup.
The details of this reset can vary according to the root cause of the recovery. If you cannot determine the root
cause, or if malicious software or a rootkit might have infected the computer, Helpdesk should apply best-practice
virus policies to react appropriately.

Note: You can perform a BitLocker validation profile reset by suspending and resuming BitLocker.

Unknown PIN
Lost startup key
Changes to boot files ### Unknown PIN
If a user has forgotten the PIN, you must reset the PIN while you are logged on to the computer in order to
prevent BitLocker from initiating recovery each time the computer is restarted.
To prevent continued recovery due to an unknown PIN
1. Unlock the computer using the recovery password.
2. Reset the PIN:
a. Right-click the drive and then click Change PIN
b. In the BitLocker Drive Encryption dialog, click Reset a forgotten PIN. If you are not logged in with an
administrator account you must provide administrative credentials at this time.
c. In the PIN reset dialog, provide and confirm the new PIN to use and then click Finish.
3. You will use the new PIN the next time you unlock the drive.
Lost startup key
If you have lost the USB flash drive that contains the startup key, then you must unlock the drive by using the
recovery key and then create a new startup key.
To prevent continued recovery due to a lost startup key
1. Log on as an administrator to the computer that has the lost startup key.
2. Open Manage BitLocker.
3. Click Duplicate start up key, insert the clean USB drive on which you are going to write the key and then
click Save.
Changes to boot files
This error might occur if you updated the firmware. As a best practice you should suspend BitLocker before
making changes the firmware and then resume protection after the update has completed. This prevents the
computer from going into recovery mode. However if changes were made when BitLocker protection was on you
can simply log on to the computer using the recovery password and the platform validation profile will be
updated so that recovery will not occur the next time.

Windows RE and BitLocker Device Encryption

Windows Recovery Environment (RE ) can be used to recover access to a drive protected by BitLocker Device
Encryption. If a PC is unable to boot after two failures, Startup Repair will automatically start. When Startup Repair
is launched automatically due to boot failures, it will only execute operating system and driver file repairs,
provided that the boot logs or any available crash dump point to a specific corrupted file. In Windows 8.1 and later,
devices that include firmware to support specific TPM measurements for PCR [7] the TPM can validate that
Windows RE is a trusted operating environment and will unlock any BitLocker-protected drives if Windows RE
has not been modified. If the Windows RE environment has been modified, for example the TPM has been
disabled, the drives will stay locked until the BitLocker recovery key is provided. If Startup Repair is not able to be
run automatically from the PC and instead Windows RE is manually started from a repair disk, the BitLocker
recovery key must be provided to unlock the BitLocker–protected drives.

Using additional recovery information

Besides the 48-digit BitLocker recovery password, other types of recovery information are stored in Active
Directory. This section describes how this additional information can be used.
BitLocker key package
If the recovery methods discussed earlier in this document do not unlock the volume, you can use the BitLocker
Repair tool to decrypt the volume at the block level. The tool uses the BitLocker key package to help recover
encrypted data from severely damaged drives. You can then use this recovered data to salvage encrypted data,
even after the correct recovery password has failed to unlock the damaged volume. We recommend that you still
save the recovery password. A key package cannot be used without the corresponding recovery password.

Note: You must use the BitLocker Repair tool repair-bde to use the BitLocker key package.

The BitLocker key package is not saved by default. To save the package along with the recovery password in AD
DS you must select the Backup recovery password and key package option in the Group Policy settings that
control the recovery method. You can also export the key package from a working volume. For more details on
how to export key packages, see Retrieving the BitLocker Key Package.

Resetting recovery passwords

You should invalidate a recovery password after it has been provided and used. It should also be done when you
intentionally want to invalidate an existing recovery password for any reason.
You can reset the recovery password in two ways:
Use manage-bde You can use manage-bde to remove the old recovery password and add a new recovery
password. The procedure identifies the command and the syntax for this method.
Run a script You can run a script to reset the password without decrypting the volume. The sample script in
the procedure illustrates this functionality. The sample script creates a new recovery password and invalidates
all other passwords.
To reset a recovery password using manage-bde
1. Remove the previous recovery password

Manage-bde –protectors –delete C: –type RecoveryPassword

2. Add the new recovery password

Manage-bde –protectors –add C: -RecoveryPassword

3. Get the ID of the new recovery password. From the screen copy the ID of the recovery password.

Manage-bde –protectors –get C: -Type RecoveryPassword

4. Backup the new recovery password to AD DS

 Manage-bde –protectors –adbackup C: -id {EXAMPLE6-5507-4924-AA9E-AFB2EB003692}

Warning: You must include the braces in the ID string.

To run the sample recovery password script

1. Save the following sample script in a VBScript file. For example: ResetPassword.vbs.
2. At the command prompt, type a command similar to the following:
cscript ResetPassword.vbs

Important: This sample script is configured to work only for the C volume. You must customize the script to
match the volume where you want to test password reset.
Note: To manage a remote computer, you can specify the remote computer name rather than the local
computer name.

You can use the following sample script to create a VBScript file to reset the recovery passwords.

' Target drive letter

strDriveLetter = "c:"
' Target computer name
' Use "." to connect to the local computer
strComputerName = "."
' --------------------------------------------------------------------------------
' Connect to the BitLocker WMI provider class
' --------------------------------------------------------------------------------
strConnectionStr = "winmgmts:" _
& "{impersonationLevel=impersonate,authenticationLevel=pktPrivacy}!\\" _
& strComputerName _
& "\root\cimv2\Security\MicrosoftVolumeEncryption"

On Error Resume Next 'handle permission errors

Set objWMIService = GetObject(strConnectionStr)
If Err.Number <> 0 Then
WScript.Echo "Failed to connect to the BitLocker interface (Error 0x" & Hex(Err.Number) & ")."
Wscript.Echo "Ensure that you are running with administrative privileges."
WScript.Quit -1
End If
On Error GoTo 0
strQuery = "Select * from Win32_EncryptableVolume where DriveLetter='" & strDriveLetter & "'"
Set colTargetVolumes = objWMIService.ExecQuery(strQuery)
If colTargetVolumes.Count = 0 Then
WScript.Echo "FAILURE: Unable to find BitLocker-capable drive " & strDriveLetter & " on computer " &
strComputerName & "."
WScript.Quit -1
End If
' there should only be one volume found
For Each objFoundVolume in colTargetVolumes
set objVolume = objFoundVolume
Next
' objVolume is now our found BitLocker-capable disk volume
' --------------------------------------------------------------------------------
' Perform BitLocker WMI provider functionality
' --------------------------------------------------------------------------------
' Add a new recovery password, keeping the ID around so it doesn't get deleted later
' ----------------------------------------------------------------------------------
nRC = objVolume.ProtectKeyWithNumericalPassword("Recovery Password Refreshed By Script", , sNewKeyProtectorID)
If nRC <> 0 Then
WScript.Echo "FAILURE: ProtectKeyWithNumericalPassword failed with return code 0x" & Hex(nRC)
WScript.Quit -1
 End If
' Removes the other, "stale", recovery passwords
' ----------------------------------------------------------------------------------
nKeyProtectorTypeIn = 3 ' type associated with "Numerical Password" protector
nRC = objVolume.GetKeyProtectors(nKeyProtectorTypeIn, aKeyProtectorIDs)
If nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyProtectors failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
' Delete those key protectors other than the one we just added.
For Each sKeyProtectorID In aKeyProtectorIDs
If sKeyProtectorID <> sNewKeyProtectorID Then
nRC = objVolume.DeleteKeyProtector(sKeyProtectorID)
If nRC <> 0 Then
WScript.Echo "FAILURE: DeleteKeyProtector on ID " & sKeyProtectorID & " failed with return code 0x" & Hex(nRC)
WScript.Quit -1
Else
' no output
'WScript.Echo "SUCCESS: Key protector with ID " & sKeyProtectorID & " deleted"
End If
End If
Next
WScript.Echo "A new recovery password has been added. Old passwords have been removed."
' - some advanced output (hidden)
'WScript.Echo ""
'WScript.Echo "Type ""manage-bde -protectors -get " & strDriveLetter & " -type recoverypassword"" to view
existing passwords."

Retrieving the BitLocker key package

You can use two methods to retrieve the key package, as described in Using Additional Recovery Information:
Export a previously-saved key package from AD DS. You must have Read access to BitLocker recovery
passwords that are stored in AD DS.
Export a new key package from an unlocked, BitLocker-protected volume. You must have local
administrator access to the working volume, before any damage has occurred.
The following sample script exports all previously-saved key packages from AD DS.
To run the sample key package retrieval script
1. Save the following sample script in a VBScript file. For example: GetBitLockerKeyPackageADDS.vbs.
2. At the command prompt, type a command similar to the following:
cscript GetBitLockerKeyPackageADDS.vbs -?
You can use the following sample script to create a VBScript file to retrieve the BitLocker key package from AD
DS.

' --------------------------------------------------------------------------------
' Usage
' --------------------------------------------------------------------------------
Sub ShowUsage
Wscript.Echo "USAGE: GetBitLockerKeyPackageADDS [Path To Save Key Package] [Optional Computer Name]"
Wscript.Echo "If no computer name is specified, the local computer is assumed."
Wscript.Echo
Wscript.Echo "Example: GetBitLockerKeyPackageADDS E:\bitlocker-ad-key-package mycomputer"
WScript.Quit
End Sub
' --------------------------------------------------------------------------------
' Parse Arguments
' --------------------------------------------------------------------------------
Set args = WScript.Arguments
Select Case args.Count
Select Case args.Count
Case 1
If args(0) = "/?" Or args(0) = "-?" Then
ShowUsage
Else
strFilePath = args(0)
' Get the name of the local computer
Set objNetwork = CreateObject("WScript.Network")
strComputerName = objNetwork.ComputerName
End If

Case 2
If args(0) = "/?" Or args(0) = "-?" Then
ShowUsage
Else
strFilePath = args(0)
strComputerName = args(1)
End If
Case Else
ShowUsage
End Select
' --------------------------------------------------------------------------------
' Get path to Active Directory computer object associated with the computer name
' --------------------------------------------------------------------------------
Function GetStrPathToComputer(strComputerName)
' Uses the global catalog to find the computer in the forest
' Search also includes deleted computers in the tombstone
Set objRootLDAP = GetObject("LDAP://rootDSE")
namingContext = objRootLDAP.Get("defaultNamingContext") ' e.g. string dc=fabrikam,dc=com
strBase = "<GC://" & namingContext & ">"

Set objConnection = CreateObject("ADODB.Connection")

Set objCommand = CreateObject("ADODB.Command")
objConnection.Provider = "ADsDSOOBject"
objConnection.Open "Active Directory Provider"
Set objCommand.ActiveConnection = objConnection
strFilter = "(&(objectCategory=Computer)(cn=" & strComputerName & "))"
strQuery = strBase & ";" & strFilter & ";distinguishedName;subtree"
objCommand.CommandText = strQuery
objCommand.Properties("Page Size") = 100
objCommand.Properties("Timeout") = 100
objCommand.Properties("Cache Results") = False
' Enumerate all objects found.
Set objRecordSet = objCommand.Execute
If objRecordSet.EOF Then
WScript.echo "The computer name '" & strComputerName & "' cannot be found."
WScript.Quit 1
End If
' Found object matching name
Do Until objRecordSet.EOF
dnFound = objRecordSet.Fields("distinguishedName")
GetStrPathToComputer = "LDAP://" & dnFound
objRecordSet.MoveNext
Loop
' Clean up.
Set objConnection = Nothing
Set objCommand = Nothing
Set objRecordSet = Nothing
End Function
' --------------------------------------------------------------------------------
' Securely access the Active Directory computer object using Kerberos
' --------------------------------------------------------------------------------
Set objDSO = GetObject("LDAP:")
strPathToComputer = GetStrPathToComputer(strComputerName)
WScript.Echo "Accessing object: " + strPathToComputer
Const ADS_SECURE_AUTHENTICATION = 1
Const ADS_USE_SEALING = 64 '0x40
Const ADS_USE_SIGNING = 128 '0x80
' --------------------------------------------------------------------------------
' Get all BitLocker recovery information from the Active Directory computer object
 ' Get all BitLocker recovery information from the Active Directory computer object
' --------------------------------------------------------------------------------
' Get all the recovery information child objects of the computer object
Set objFveInfos = objDSO.OpenDSObject(strPathToComputer, vbNullString, vbNullString, _
ADS_SECURE_AUTHENTICATION + ADS_USE_SEALING + ADS_USE_SIGNING)
objFveInfos.Filter = Array("msFVE-RecoveryInformation")
' Iterate through each recovery information object and saves any existing key packages
nCount = 1
strFilePathCurrent = strFilePath & nCount
For Each objFveInfo in objFveInfos
strName = objFveInfo.Get("name")
strRecoveryPassword = objFveInfo.Get("msFVE-RecoveryPassword")
strKeyPackage = objFveInfo.Get("msFVE-KeyPackage")
WScript.echo
WScript.echo "Recovery Object Name: " + strName
WScript.echo "Recovery Password: " + strRecoveryPassword
' Validate file path
Set fso = CreateObject("Scripting.FileSystemObject")
If (fso.FileExists(strFilePathCurrent)) Then
WScript.Echo "The file " & strFilePathCurrent & " already exists. Please use a different path."
WScript.Quit -1
End If
' Save binary data to the file
SaveBinaryDataText strFilePathCurrent, strKeyPackage

WScript.echo "Related key package successfully saved to " + strFilePathCurrent

' Update next file path using base name
nCount = nCount + 1
strFilePathCurrent = strFilePath & nCount
Next
'----------------------------------------------------------------------------------------
' Utility functions to save binary data
'----------------------------------------------------------------------------------------
Function SaveBinaryDataText(FileName, ByteArray)
'Create FileSystemObject object
Dim FS: Set FS = CreateObject("Scripting.FileSystemObject")

'Create text stream object

Dim TextStream
Set TextStream = FS.CreateTextFile(FileName)

'Convert binary data To text And write them To the file

TextStream.Write BinaryToString(ByteArray)
End Function
Function BinaryToString(Binary)
Dim I, S
For I = 1 To LenB(Binary)
S = S & Chr(AscB(MidB(Binary, I, 1)))
Next
BinaryToString = S
End Function
WScript.Quit

The following sample script exports a new key package from an unlocked, encrypted volume.
To run the sample key package retrieval script
1. Save the following sample script in a VBScript file. For example: GetBitLockerKeyPackage.vbs
2. Open an administrator command prompt, type a command similar to the following:
cscript GetBitLockerKeyPackage.vbs -?

' --------------------------------------------------------------------------------
' Usage
' --------------------------------------------------------------------------------
Sub ShowUsage
Wscript.Echo "USAGE: GetBitLockerKeyPackage [VolumeLetter/DriveLetter:] [Path To Save Key Package]"
 Wscript.Echo "USAGE: GetBitLockerKeyPackage [VolumeLetter/DriveLetter:] [Path To Save Key Package]"
Wscript.Echo
Wscript.Echo "Example: GetBitLockerKeyPackage C: E:\bitlocker-backup-key-package"
WScript.Quit
End Sub
' --------------------------------------------------------------------------------
' Parse Arguments
' --------------------------------------------------------------------------------
Set args = WScript.Arguments
Select Case args.Count
Case 2
If args(0) = "/?" Or args(0) = "-?" Then
ShowUsage
Else
strDriveLetter = args(0)
strFilePath = args(1)
End If
Case Else
ShowUsage
End Select
' --------------------------------------------------------------------------------
' Other Inputs
' --------------------------------------------------------------------------------
' Target computer name
' Use "." to connect to the local computer
strComputerName = "."
' Default key protector ID to use. Specify "" to let the script choose.
strDefaultKeyProtectorID = ""
' strDefaultKeyProtectorID = "{001298E0-870E-4BA0-A2FF-FC74758D5720}" ' sample
' --------------------------------------------------------------------------------
' Connect to the BitLocker WMI provider class
' --------------------------------------------------------------------------------
strConnectionStr = "winmgmts:" _
& "{impersonationLevel=impersonate,authenticationLevel=pktPrivacy}!\\" _
& strComputerName _
& "\root\cimv2\Security\MicrosoftVolumeEncryption"

On Error Resume Next 'handle permission errors

Set objWMIService = GetObject(strConnectionStr)
If Err.Number <> 0 Then
WScript.Echo "Failed to connect to the BitLocker interface (Error 0x" & Hex(Err.Number) & ")."
Wscript.Echo "Ensure that you are running with administrative privileges."
WScript.Quit -1
End If
On Error GoTo 0
strQuery = "Select * from Win32_EncryptableVolume where DriveLetter='" & strDriveLetter & "'"
Set colTargetVolumes = objWMIService.ExecQuery(strQuery)
If colTargetVolumes.Count = 0 Then
WScript.Echo "FAILURE: Unable to find BitLocker-capable drive " & strDriveLetter & " on computer " &
strComputerName & "."
WScript.Quit -1
End If
' there should only be one volume found
For Each objFoundVolume in colTargetVolumes
set objVolume = objFoundVolume
Next
' objVolume is now our found BitLocker-capable disk volume
' --------------------------------------------------------------------------------
' Perform BitLocker WMI provider functionality
' --------------------------------------------------------------------------------
' Collect all possible valid key protector ID's that can be used to get the package
' ----------------------------------------------------------------------------------
nNumericalKeyProtectorType = 3 ' type associated with "Numerical Password" protector
nRC = objVolume.GetKeyProtectors(nNumericalKeyProtectorType, aNumericalKeyProtectorIDs)
If nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyProtectors failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
nExternalKeyProtectorType = 2 ' type associated with "External Key" protector
nExternalKeyProtectorType = 2 ' type associated with "External Key" protector
nRC = objVolume.GetKeyProtectors(nExternalKeyProtectorType, aExternalKeyProtectorIDs)
If nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyProtectors failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
' Get first key protector of the type "Numerical Password" or "External Key", if any
' ----------------------------------------------------------------------------------
if strDefaultKeyProtectorID = "" Then
' Save first numerical password, if exists
If UBound(aNumericalKeyProtectorIDs) <> -1 Then
strDefaultKeyProtectorID = aNumericalKeyProtectorIDs(0)
End If
' No numerical passwords exist, save the first external key
If strDefaultKeyProtectorID = "" and UBound(aExternalKeyProtectorIDs) <> -1 Then
strDefaultKeyProtectorID = aExternalKeyProtectorIDs(0)
End If
' Fail case: no recovery key protectors exist.
If strDefaultKeyProtectorID = "" Then
WScript.Echo "FAILURE: Cannot create backup key package because no recovery passwords or recovery keys exist.
Check that BitLocker protection is on for this drive."
WScript.Echo "For help adding recovery passwords or recovery keys, type ""manage-bde -protectors -add -?""."
WScript.Quit -1
End If
End If
' Get some information about the chosen key protector ID
' ----------------------------------------------------------------------------------
' is the type valid?
nRC = objVolume.GetKeyProtectorType(strDefaultKeyProtectorID, nDefaultKeyProtectorType)
If Hex(nRC) = "80070057" Then
WScript.Echo "The key protector ID " & strDefaultKeyProtectorID & " is not valid."
WScript.Echo "This ID value may have been provided by the script writer."
ElseIf nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyProtectorType failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
' what's a string that can be used to describe it?
strDefaultKeyProtectorType = ""
Select Case nDefaultKeyProtectorType
Case nNumericalKeyProtectorType
strDefaultKeyProtectorType = "recovery password"
Case nExternalKeyProtectorType
strDefaultKeyProtectorType = "recovery key"
Case Else
WScript.Echo "The key protector ID " & strDefaultKeyProtectorID & " does not refer to a valid recovery
password or recovery key."
WScript.Echo "This ID value may have been provided by the script writer."
End Select
' Save the backup key package using the chosen key protector ID
' ----------------------------------------------------------------------------------
nRC = objVolume.GetKeyPackage(strDefaultKeyProtectorID, oKeyPackage)
If nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyPackage failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
' Validate file path
Set fso = CreateObject("Scripting.FileSystemObject")
If (fso.FileExists(strFilePath)) Then
WScript.Echo "The file " & strFilePath & " already exists. Please use a different path."
WScript.Quit -1
End If
Dim oKeyPackageByte, bKeyPackage
For Each oKeyPackageByte in oKeyPackage
'WScript.echo "key package byte: " & oKeyPackageByte
bKeyPackage = bKeyPackage & ChrB(oKeyPackageByte)
Next
' Save binary data to the file
SaveBinaryDataText strFilePath, bKeyPackage
' Display helpful information
' ----------------------------------------------------------------------------------
 ' ----------------------------------------------------------------------------------
WScript.Echo "The backup key package has been saved to " & strFilePath & "."
WScript.Echo "IMPORTANT: To use this key package, the " & strDefaultKeyProtectorType & " must also be saved."
' Display the recovery password or a note about saving the recovery key file
If nDefaultKeyProtectorType = nNumericalKeyProtectorType Then
nRC = objVolume.GetKeyProtectorNumericalPassword(strDefaultKeyProtectorID, sNumericalPassword)
If nRC <> 0 Then
WScript.Echo "FAILURE: GetKeyProtectorNumericalPassword failed with return code 0x" & Hex(nRC)
WScript.Quit -1
End If
WScript.Echo "Save this recovery password: " & sNumericalPassword
ElseIf nDefaultKeyProtectorType = nExternalKeyProtectorType Then
WScript.Echo "The saved key file is named " & strDefaultKeyProtectorID & ".BEK"
WScript.Echo "For help re-saving this external key file, type ""manage-bde -protectors -get -?"""
End If
'----------------------------------------------------------------------------------------
' Utility functions to save binary data
'----------------------------------------------------------------------------------------
Function SaveBinaryDataText(FileName, ByteArray)
'Create FileSystemObject object
Dim FS: Set FS = CreateObject("Scripting.FileSystemObject")

'Create text stream object

Dim TextStream
Set TextStream = FS.CreateTextFile(FileName)

'Convert binary data To text And write them To the file

TextStream.Write BinaryToString(ByteArray)
End Function
Function BinaryToString(Binary)
Dim I, S
For I = 1 To LenB(Binary)
S = S & Chr(AscB(MidB(Binary, I, 1)))
Next
BinaryToString = S
End Function

See also
BitLocker overview
 BitLocker Countermeasures
10/24/2018 • 9 minutes to read • Edit Online

Applies to
Windows 10
Windows uses technologies including Trusted Platform Module (TPM ), Secure Boot, and Measured Boot to help
protect BitLocker encryption keys against attacks. BitLocker is part of a strategic approach to securing data against
offline attacks through encryption technology. Data on a lost or stolen computer is vulnerable. For example, there
could be unauthorized access, either by running a software attack tool against it or by transferring the computer’s
hard disk to a different computer.
BitLocker helps mitigate unauthorized data access on lost or stolen computers before the authorized operating
system is started by:
Encrypting volumes on your computer. For example, you can turn on BitLocker for your operating system
volume, or a volume on a fixed or removable data drive (such as a USB flash drive, SD card, and so on).
Turning on BitLocker for your operating system volume encrypts all system files on the volume, including the
paging files and hibernation files. The only exception is for the System partition, which includes the Windows
Boot Manager and minimal boot collateral required for decryption of the operating system volume after the
key is unsealed.
Ensuring the integrity of early boot components and boot configuration data. On devices that have a
TPM version 1.2 or higher, BitLocker uses the enhanced security capabilities of the TPM to make data
accessible only if the computer’s BIOS firmware code and configuration, original boot sequence, boot
components, and BCD configuration all appear unaltered and the encrypted disk is located in the original
computer. On systems that leverage TPM PCR [7], BCD setting changes deemed safe are permitted to improve
usability.
The next sections provide more details about how Windows protects against various attacks on the BitLocker
encryption keys in Windows 10, Windows 8.1, and Windows 8.
For more information about how to enable the best overall security configuration for devices beginning with
Windows 10 version 1803, see Standards for a highly secure Windows 10 device.

Protection before startup

Before Windows starts, you must rely on security features implemented as part of the device hardware and
firmware, including TPM and Secure Boot. Fortunately, many modern computers feature a TPM and Secure Boot.
Trusted Platform Module
A TPM is a microchip designed to provide basic security-related functions, primarily involving encryption keys. On
some platforms, TPM can alternatively be implemented as a part of secure firmware. BitLocker binds encryption
keys with the TPM to ensure that a computer has not been tampered with while the system was offline. For more
info about TPM, see Trusted Platform Module.
UEFI and Secure Boot
Unified Extensible Firmware Interface (UEFI) is a programmable boot environment that initializes devices and
starts the operating system’s bootloader.
The UEFI specification defines a firmware execution authentication process called Secure Boot. Secure Boot blocks
untrusted firmware and bootloaders (signed or unsigned) from being able to start on the system.
By default, BitLocker provides integrity protection for Secure Boot by utilizing the TPM PCR [7] measurement. An
unauthorized EFI firmware, EFI boot application, or bootloader cannot run and acquire the BitLocker key.
BitLocker and reset attacks
To defend against malicious reset attacks, BitLocker leverages the TCG Reset Attack Mitigation, also known as
MOR bit (Memory Overwrite Request), before extracting keys into memory.

NOTE
This does not protect against physical attacks where an attacker opens the case and attacks the hardware.

Security policies
The next sections cover pre-boot authentication and DMA policies that can provide additional protection for
BitLocker.
Pre -boot authentication
Pre-boot authentication with BitLocker is a policy setting that requires the use of either user input, such as a PIN, a
startup key, or both to authenticate prior to making the contents of the system drive accessible. The Group Policy
setting is Require additional authentication at startup and the corresponding setting in the BitLocker CSP is
SystemDrivesRequireStartupAuthentication.
BitLocker accesses and stores the encryption keys in memory only after pre-boot authentication is completed. If
Windows can’t access the encryption keys, the device can’t read or edit the files on the system drive. The only
option for bypassing pre-boot authentication is entering the recovery key.
Pre-boot authentication is designed to prevent the encryption keys from being loaded to system memory without
the trusted user supplying another authentication factor such as a PIN or startup key. This helps mitigate DMA
and memory remanence attacks.
On computers with a compatible TPM, operating system drives that are BitLocker-protected can be unlocked in
four ways:
TPM -only. Using TPM -only validation does not require any interaction with the user to unlock and provide
access to the drive. If the TPM validation succeeds, the user sign in experience is the same as a standard logon.
If the TPM is missing or changed or if BitLocker detects changes to the BIOS or UEFI code or configuration,
critical operating system startup files, or the boot configuration, BitLocker enters recovery mode, and the user
must enter a recovery password to regain access to the data. This option is more convenient for sign-in but less
secure than the other options, which require an additional authentication factor.
TPM with startup key. In addition to the protection that the TPM -only provides, part of the encryption key is
stored on a USB flash drive, referred to as a startup key. Data on the encrypted volume cannot be accessed
without the startup key.
TPM with PIN. In addition to the protection that the TPM provides, BitLocker requires that the user enter a
PIN. Data on the encrypted volume cannot be accessed without entering the PIN. TPMs also have anti-
hammering protection that is designed to prevent brute force attacks that attempt to determine the PIN.
TPM with startup key and PIN. In addition to the core component protection that the TPM -only provides,
part of the encryption key is stored on a USB flash drive, and a PIN is required to authenticate the user to the
TPM. This configuration provides multifactor authentication so that if the USB key is lost or stolen, it cannot be
used for access to the drive, because the correct PIN is also required.
In the following Group Policy example, TPM + PIN is required to unlock an operating system drive:
Pre-boot authentication with a PIN can mitigate an attack vector for devices that use a bootable eDrive because an
exposed eDrive bus can allow an attacker to capture the BitLocker encryption key during startup. Pre-boot
authentication with a PIN can also mitigate DMA port attacks during the window of time between when BitLocker
unlocks the drive and Windows boots to the point that Windows can set any port-related policies that have been
configured.
On the other hand, Pre-boot authentication prompts can be inconvenient to users. In addition, users who forget
their PIN or lose their startup key are denied access to their data until they can contact their organization’s
support team to obtain a recovery key. Pre-boot authentication can also make it more difficult to update
unattended desktops and remotely administered servers because a PIN needs to be entered when a computer
reboots or resumes from hibernation.
To address these issues, you can deploy BitLocker Network Unlock. Network Unlock allows systems within the
physical enterprise security perimeter that meet the hardware requirements and have BitLocker enabled with
TPM+PIN to boot into Windows without user intervention. It requires direct ethernet connectivity to an enterprise
Windows Deployment Services (WDS ) server.
Protecting Thunderbolt and other DMA ports
There are a few different options to protect DMA ports, such as Thunderbolt™3. Beginning with Windows 10
version 1803, new Intel-based devices have kernel protection against DMA attacks via Thunderbolt™ 3 ports
enabled by default. This Kernel DMA Protection is available only for new systems beginning with Windows 10
version 1803, as it requires changes in the system firmware and/or BIOS.
You can use the System Information desktop app (MSINFO32) to check if a device has kernel DMA protection
enabled:
If kernel DMA protection not enabled, follow these steps to protect Thunderbolt™ 3 enabled ports:
1. Require a password for BIOS changes
2. Intel Thunderbolt Security must be set to User Authorization in BIOS settings. Please refer to Intel
Thunderbolt™ 3 and Security on Microsoft Windows® 10 Operating System documentation
3. Additional DMA security may be added by deploying policy (beginning with Windows 10 version 1607):
MDM: DataProtection/AllowDirectMemoryAccess policy
Group Policy: Disable new DMA devices when this computer is locked (This setting is not configured by
default.)
For Thunderbolt v1 and v2 (DisplayPort Connector), refer to the “Thunderbolt Mitigation” section in KB 2516445.
For SBP -2 and 1394 (a.k.a. Firewire), refer to the “SBP -2 Mitigation” section in KB 2516445.

Attack countermeasures
This section covers countermeasures for specific types attacks.
Bootkits and rootkits
A physically-present attacker might attempt to install a bootkit or rootkit-like piece of software into the boot chain
in an attempt to steal the BitLocker keys. The TPM should observe this installation via PCR measurements, and
the BitLocker key will not be released. This is the default configuration.
A BIOS password is recommended for defense-in-depth in case a BIOS exposes settings that may weaken the
BitLocker security promise. Intel Boot Guard and AMD Hardware Verified Boot support stronger implementations
of Secure Boot that provide additional resilience against malware and physical attacks. Intel Boot Guard and AMD
Hardware Verified Boot are part of platform boot verification standards for a highly secure Windows 10 device.
Brute force attacks against a PIN
Require TPM + PIN for anti-hammering protection.
DMA attacks
See Protecting Thunderbolt and other DMA ports earlier in this topic.
Paging file, crash dump, and Hyberfil.sys attacks
These files are secured on an encrypted volume by default when BitLocker is enabled on OS drives. It also blocks
automatic or manual attempts to move the paging file.
Memory remanence
Enable Secure Boot and require a password to change BIOS settings. For customers requiring protection against
these advanced attacks, configure a TPM+PIN protector, disable Standby power management, and shut down or
hibernate the device before it leaves the control of an authorized user.

Attacker countermeasures
The following sections cover mitigations for different types of attackers.
Attacker without much skill or with limited physical access
Physical access may be limited by a form factor that does not expose buses and memory. For example, there are
no external DMA-capable ports, no exposed screws to open the chassis, and memory is soldered to the
mainboard. This attacker of opportunity does not use destructive methods or sophisticated forensics
hardware/software.
Mitigation:
Pre-boot authentication set to TPM only (the default)
Attacker with skill and lengthy physical access
Targeted attack with plenty of time; this attacker will open the case, will solder, and will use sophisticated hardware
or software.
Mitigation:
Pre-boot authentication set to TPM with a PIN protector (with a sophisticated alphanumeric PIN to help
the TPM anti-hammering mitigation).
-And-
Disable Standby power management and shut down or hibernate the device before it leaves the control of
an authorized user. This can be set using Group Policy:
Computer Configuration|Policies|Administrative Templates|Windows Components|File Explorer|Show
hibernate in the power options menu
Computer Configuration|Policies|Administrative Templates|System|Power Management|Sleep
Settings|Allow standby states (S1-S3) when sleeping (plugged in)
Computer Configuration|Policies|Administrative Templates|System|Power Management|Sleep
Settings|Allow standby states (S1-S3) when sleeping (on battery)
These settings are Not configured by default.
For some systems, bypassing TPM -only may require opening the case, and may require soldering, but could
possibly be done for a reasonable cost. Bypassing a TPM with a PIN protector would cost much more, and require
brute forcing the PIN. With a sophisticated enhanced PIN, it could be nearly impossible. The Group Policy setting
for enhanced PIN is:
Computer Configuration|Administrative Templates|Windows Components|BitLocker Drive Encryption|Operating
System Drives|Allow enhanced PINs for startup
This setting is Not configured by default.
For secure administrative workstations, Microsoft recommends TPM with PIN protector and disable Standby
power management and shut down or hibernate the device.

See also
Blocking the SBP -2 driver and Thunderbolt controllers to reduce 1394 DMA and Thunderbolt DMA threats to
BitLocker
BitLocker Group Policy settings
BitLocker CSP
 Protecting cluster shared volumes and storage area
networks with BitLocker
2/7/2018 • 8 minutes to read • Edit Online

Applies to
Windows Server 2016
This topic for IT pros describes how to protect CSVs and SANs with BitLocker.
BitLocker can protect both physical disk resources and cluster shared volumes version 2.0 (CSV2.0). BitLocker on
clustered volumes allows for an additional layer of protection for administrators wishing to protect sensitive, highly
available data. By adding additional protectors to the clustered volume, administrators can also add an additional
barrier of security to resources within an organization by allowing only certain user accounts access to unlock the
BitLocker volume.

Configuring BitLocker on Cluster Shared Volumes

Using BitLocker with Clustered Volumes
BitLocker on volumes within a cluster are managed based on how the cluster service "views" the volume to be
protected. The volume can be a physical disk resource such as a logical unit number (LUN ) on a storage area
network (SAN ) or network attached storage (NAS ).

Important SANs used with BitLocker must have obtained Windows Hardware Certification. For more info,
see Windows Hardware Lab Kit.

Alternatively, the volume can be a cluster-shared volume, a shared namespace, within the cluster. Windows Server
2012 expanded the CSV architecture, now known as CSV2.0, to enable support for BitLocker. When using
BitLocker with volumes designated for a cluster, the volume will need to turn on BitLocker before its addition to the
storage pool within cluster or put the resource into maintenance mode before BitLocker operations will complete.
Windows PowerShell or the manage-bde command line interface is the preferred method to manage BitLocker on
CSV2.0 volumes. This is recommended over the BitLocker Control Panel item because CSV2.0 volumes are mount
points. Mount points are an NTFS object that is used to provide an entry point to other volumes. Mount points do
not require the use of a drive letter. Volumes that lack drive letters do not appear in the BitLocker Control Panel
item. Additionally, the new Active Directory-based protector option required for cluster disk resource or CSV2.0
resources is not available in the Control Panel item.

Note: Mount points can be used to support remote mount points on SMB based network shares. This type of
share is not supported for BitLocker encryption.

For thinly provisioned storage, such as a Dynamic Virtual Hard Disk (VHD ), BitLocker runs in Used Disk Space
Only encryption mode. You cannot use the manage-bde -WipeFreeSpace command to transition the volume to
full-volume encryption on these types of volumes. This is blocked in order to avoid expanding thinly provisioned
volumes to occupy the entire backing store while wiping the unoccupied (free) space.
Active Directory-based protector
You can also use an Active Directory Domain Services (AD DS ) protector for protecting clustered volumes held
within your AD DS infrastructure. The ADAccountOrGroup protector is a domain security identifier (SID )-based
protector that can be bound to a user account, machine account or group. When an unlock request is made for a
protected volume, the BitLocker service interrupts the request and uses the BitLocker protect/unprotect APIs to
unlock or deny the request. BitLocker will unlock protected volumes without user intervention by attempting
protectors in the following order:
1. Clear key
2. Driver-based auto-unlock key
3. ADAccountOrGroup protector
a. Service context protector
b. User protector
4. Registry-based auto-unlock key

Note: A Windows Server 2012 or later domain controller is required for this feature to work properly.

Turning on BitLocker before adding disks to a cluster using Windows PowerShell

BitLocker encryption is available for disks before or after addition to a cluster storage pool. The advantage of
encrypting volumes prior to adding them to a cluster is that the disk resource does not require suspending the
resource to complete the operation. To turn on BitLocker for a disk before adding it to a cluster, do the following:
1. Install the BitLocker Drive Encryption feature if it is not already installed.
2. Ensure the disk is formatted NTFS and has a drive letter assigned to it.
3. Identify the name of the cluster with Windows PowerShell.

Get-Cluster

4. Enable BitLocker on the volume of your choice with an ADAccountOrGroup protector, using the cluster
name. For example, use a command such as:

Enable-BitLocker E: -ADAccountOrGroupProtector -ADAccountOrGroup CLUSTER$

Warning: You must configure an ADAccountOrGroup protector using the cluster CNO for a
BitLocker enabled volume to either be shared in a Cluster Shared Volume or to fail over properly in a
traditional failover cluster.

5. Repeat the preceding steps for each disk in the cluster.

6. Add the volume(s) to the cluster.
Turning on BitLocker for a clustered disk using Windows PowerShell
When the cluster service owns a disk resource already, it needs to be set into maintenance mode before BitLocker
can be enabled. Use the following steps for turning BitLocker on for a clustered disk:
1. Install the BitLocker Drive Encryption feature if it is not already installed.
2. Check the status of the cluster disk using Windows PowerShell.

Get-ClusterResource "Cluster Disk 1"

3. Put the physical disk resource into maintenance mode using Windows PowerShell.

Get-ClusterResource "Cluster Disk 1" | Suspend-ClusterResource

4. Identify the name of the cluster with Windows PowerShell.

Get-Cluster

5. Enable BitLocker on the volume of your choice with an ADAccountOrGroup protector, using the cluster
name. For example, use a command such as:

Enable-BitLocker E: -ADAccountOrGroupProtector -ADAccountOrGroup CLUSTER$

Warning: You must configure an ADAccountOrGroup protector using the cluster CNO for a
BitLocker enabled volume to either be shared in a Cluster Shared Volume or to fail over properly in a
traditional failover cluster.

6. Use Resume-ClusterResource to take the physical disk resource back out of maintenance mode:

Get-ClusterResource "Cluster Disk 1" | Resume-ClusterResource

7. Repeat the preceding steps for each disk in the cluster.

Adding BitLocker encrypted volumes to a cluster using manage -bde
You can also use manage-bde to enable BitLocker on clustered volumes. The steps needed to add a physical disk
resource or CSV2.0 volume to an existing cluster includes the following:
1. Verify the BitLocker Drive Encryption feature is installed on the computer.
2. Ensure new storage is formatted as NTFS.
3. Encrypt the volume, add a recovery key and add the cluster administrator as a protector key using the
manage-bde command line interface (see example):
Manage-bde -on -used <drive letter> -RP -sid domain\CNO$ -sync

a. BitLocker will check to see if the disk is already part of a cluster. If it is, administrators will
encounter a hard block. Otherwise, the encryption will continue.
b. Using the -sync parameter is optional. Using it ensures the command waits until the encryption
for the volume is completed before releasing the volume for use in the cluster storage pool.
4. Open the Failover Cluster Manager snap-in or cluster PowerShell cmdlets to enable the disk to be clustered
Once the disk is clustered it can also be enabled for CSV.
5. During the resource online operation, cluster will check to see if the disk is BitLocker encrypted.
a. If the volume is not BitLocker enabled, traditional cluster online operations occur.
b. If the volume is BitLocker enabled, the following check occurs:
If volume is locked, BitLocker will impersonate the CNO and unlock the volume using the CNO
protector. If this operation fails an event will be logged that the volume could not be unlocked and
the online operation will fail.
6. Once the disk is online in the storage pool, it can be added to a CSV by right clicking on the disk resource
and choosing "Add to cluster shared volumes". CSVs can include both encrypted and unencrypted
volumes. To check the status of a particular volume for BitLocker encryption, administrators can utilize the
manage-bde -status command with a path to the volume inside the CSV namespace as seen in the example
command line below.
 manage-bde -status "C:\ClusterStorage\volume1"

Physical Disk Resources

Unlike CSV2.0 volumes, physical disk resources can only be accessed by one cluster node at a time. This means
that operations such as encrypting, decrypting, locking or unlocking volumes require context to perform. For
example, you cannot unlock or decrypt a physical disk resource if you are not administering the cluster node that
owns the disk resource because the disk resource is not available.
Restrictions on BitLocker actions with cluster volumes
The following table contains information about both Physical Disk Resources (i.e. traditional failover cluster
volumes) and Cluster Shared Volumes (CSV ) and the actions that are allowed by BitLocker in each situation.

Action On owner node On Metadata On (Data Maintenance

of failover Server (MDS) of Server) DS of Mode
volume CSV CSV

Manage-bde – Blocked Blocked Blocked Allowed

on

Manage-bde – Blocked Blocked Blocked Allowed

off

Manage-bde Blocked Blocked** Blocked Allowed

Pause/Resume

Manage-bde – Blocked Blocked Blocked Allowed

lock

manage-bde – Blocked Blocked Blocked Allowed

wipe

Unlock Automatic via Automatic via Automatic via Allowed

cluster service cluster service cluster service

manage-bde – Allowed Allowed Blocked Allowed

protector –add

manage-bde - Allowed Allowed Blocked Allowed

protector -
delete

manage-bde – Allowed (not Allowed (not Blocked Allowed (not

autounlock recommended) recommended) recommended)

Manage-bde - Allowed Allowed Blocked Allowed

upgrade
 Shrink Allowed Allowed Blocked Allowed

Extend Allowed Allowed Blocked Allowed

Note: Although the manage-bde -pause command is Blocked in clusters, the cluster service will automatically
resume a paused encryption or decryption from the MDS node

In the case where a physical disk resource experiences a failover event during conversion, the new owning node
will detect the conversion is not complete and will complete the conversion process.
Other considerations when using BitLocker on CSV2.0
Some other considerations to take into account for BitLocker on clustered storage include the following:
BitLocker volumes have to be initialized and beginning encryption before they are available to add to a CSV2.0
volume.
If an administrator needs to decrypt a CSV volume, remove the volume from the cluster or put into disk
maintenance mode. You can add the CSV back to the cluster while waiting for decryption to complete.
If an administrator needs to start encrypting a CSV volume, remove the volume from the cluster or put it in
maintenance mode.
If conversion is paused with encryption in progress and the CSV volume is offline from the cluster, the cluster
thread (health check) will automatically resume conversion when the volume is online to the cluster.
If conversion is paused with encryption in progress and a physical disk resource volume is offline from the
cluster, the BitLocker driver will automatically resume conversion when the volume is online to the cluster.
If conversion is paused with encryption in progress, while the CSV volume is in maintenance mode, the cluster
thread (health check) will automatically resume conversion when moving the volume back from maintenance.
If conversion is paused with encryption in progress, while the disk resource volume is in maintenance mode,
the BitLocker driver will automatically resume conversion when the volume is moved back from maintenance
mode.
 Encrypted Hard Drive
8/28/2018 • 6 minutes to read • Edit Online

Applies to
Windows 10
Windows Server 2016
Encrypted Hard Drive uses the rapid encryption that is provided by BitLocker Drive Encryption to enhance data
security and management.
By offloading the cryptographic operations to hardware, Encrypted Hard Drives increase BitLocker performance
and reduce CPU usage and power consumption. Because Encrypted Hard Drives encrypt data quickly, enterprise
devices can expand BitLocker deployment with minimal impact on productivity.
Encrypted Hard Drives are a new class of hard drives that are self-encrypting at a hardware level and allow for full
disk hardware encryption. In Windows 8, Windows Server 2012, and later you can install to these devices without
additional modification.
Some of the benefits of Encrypted Hard Drives include:
Better performance: Encryption hardware, integrated into the drive controller, allows the drive to operate at
full data rate with no performance degradation.
Strong security based in hardware: Encryption is always "on" and the keys for encryption never leave the
hard drive. User authentication is performed by the drive before it will unlock, independently of the operating
system
Ease of use: Encryption is transparent to the user because it is on by default. There is no user interaction
needed to enable encryption. Encrypted Hard Drives are easily erased using on-board encryption key; there is
no need to re-encrypt data on the drive.
Lower cost of ownership: There is no need for new infrastructure to manage encryption keys, since BitLocker
leverages your Active Directory Domain Services infrastructure to store recovery information. Your device
operates more efficiently because processor cycles do not need to be used for the encryption process.
Encrypted Hard Drives are supported natively in the operating system through the following mechanisms:
Identification: The operating system can identify that the drive is an Encrypted Hard Drive device type
Activation: The operating system disk management utility can activate, create and map volumes to
ranges/bands as appropriate
Configuration: The operating system can create and map volumes to ranges/bands as appropriate
API: API support for applications to manage Encrypted Hard Drives independently of BitLocker Drive
Encryption (BDE )
BitLocker support: Integration with the BitLocker Control Panel provides a seamless BitLocker end user
experience.

Warning: Self-Encrypting Hard Drives and Encrypted Hard Drives for Windows are not the same type of
device. Encrypted Hard Drives for Windows require compliance for specific TCG protocols as well as IEEE 1667
compliance; Self-Encrypting Hard Drives do not have these requirements. It is important to confirm the device
type is an Encrypted Hard Drive for Windows when planning for deployment.

If you are a storage device vendor who is looking for more info on how to implement Encrypted Hard Drive, see
the Encrypted Hard Drive Device Guide.
System Requirements
To use Encrypted Hard Drive, the following system requirements apply:
For Encrypted Hard Drives used as data drives:
The drive must be in an uninitialized state.
The drive must be in a security inactive state.
For Encrypted Hard Drives used as startup drives:
The drive must be in an uninitialized state.
The drive must be in a security inactive state.
The computer must be UEFI 2.3.1 based and have the EFI_STORAGE_SECURITY_COMMAND_PROTOCOL
defined. (This protocol is used to allow programs running in the EFI boot services environment to send security
protocol commands to the drive).
The computer must have the Compatibility Support Module (CSM ) disabled in UEFI.
The computer must always boot natively from UEFI.

Warning: All Encrypted Hard Drives must be attached to non-RAID controllers to function properly.

Technical overview
Rapid encryption in BitLocker directly addresses the security needs of enterprises while offering significantly
improved performance. In versions of Windows earlier than Windows Server 2012, BitLocker required a two-step
process to complete read/write requests. In Windows Server 2012, Windows 8, or later, Encrypted Hard Drives
offload the cryptographic operations to the drive controller for much greater efficiency. When the operating
system an Encrypted Hard Drive, it activates the security mode. This activation lets the drive controller generate a
media key for every volume that the host computer creates. This media key, which is never exposed outside the
disk, is used to rapidly encrypt or decrypt every byte of data that is sent or received from the disk.

Configuring Encrypted Hard Drives as Startup drives

Configuration of Encrypted Hard Drives as startup drives is done using the same methods as standard hard drives.
These methods include:
Deploy from media: Configuration of Encrypted Hard Drives happens automatically through the installation
process.
Deploy from network: This deployment method involves booting a Windows PE environment and using
imaging tools to apply a Windows image from a network share. Using this method, the Enhanced Storage
optional component needs to be included in the Windows PE image. You can enable this component using
Server Manager, Windows PowerShell, or the DISM command line tool. If this component is not present,
configuration of Encrypted Hard Drives will not work.
Deploy from server: This deployment method involves PXE booting a client with Encrypted Hard Drives
present. Configuration of Encrypted Hard Drives happens automatically in this environment when the
Enhanced Storage component is added to the PXE boot image. During deployment, the
TCGSecurityActivationDisabled setting in unattend.xml controls the encryption behavior of Encrypted Hard
Drives.
Disk Duplication: This deployment method involves use of a previously configured device and disk
duplication tools to apply a Windows image to an Encrypted Hard Drive. Disks must be partitioned using at
least Windows 8 or Windows Server 2012 for this configuration to work. Images made using disk duplicators
will not work.
Encrypted Hard Drive Architecture
Encrypted Hard Drives utilize two encryption keys on the device to control the locking and unlocking of data on
the drive. These are the Data Encryption Key (DEK) and the Authentication Key (AK).
The Data Encryption Key is the key used to encrypt all of the data on the drive. The drive generates the DEK and it
never leaves the device. It is stored in an encrypted format at a random location on the drive. If the DEK is changed
or erased, data encrypted using the DEK is irrecoverable.
The Authentication Key is the key used to unlock data on the drive. A hash of the key is stored on drive and
requires confirmation to decrypt the DEK.
When a computer with an Encrypted Hard Drive is in a powered off state, the drive locks automatically. As a
computer powers on, the device remains in a locked state and is only unlocked after the Authentication Key
decrypts the Data Encryption Key. Once the Authentication Key decrypts the Data Encryption Key, read-write
operations can take place on the device.
When writing data to the drive, it passes through an encryption engine before the write operation completes.
Likewise, reading data from the drive requires the encryption engine to decrypt the data before passing that data
back to the user. In the event that the DEK needs to be changed or erased, the data on the drive does not need to
be re-encrypted. A new Authentication Key needs to be created and it will re-encrypt the DEK. Once completed, the
DEK can now be unlocked using the new AK and read-writes to the volume can continue.

Re-configuring Encrypted Hard Drives

Many Encrypted Hard Drive devices come pre-configured for use. If reconfiguration of the drive is required, use
the following procedure after removing all available volumes and reverting the drive to an uninitialized state:
1. Open Disk Management (diskmgmt.msc)
2. Initialize the disk and select the appropriate partition style (MBR or GPT)
3. Create one or more volumes on the disk.
4. Use the BitLocker setup wizard to enable BitLocker on the volume.
 Kernel DMA Protection for Thunderbolt™ 3
12/20/2018 • 6 minutes to read • Edit Online

Applies to
Windows 10
In Windows 10 version 1803, Microsoft introduced a new feature called Kernel DMA Protection to protect PCs
against drive-by Direct Memory Access (DMA) attacks using PCI hot plug devices connected to Thunderbolt™ 3
ports. Drive-by DMA attacks can lead to disclosure of sensitive information residing on a PC, or even injection of
malware that allows attackers to bypass the lock screen or control PCs remotely.
This feature does not protect against DMA attacks via 1394/FireWire, PCMCIA, CardBus, ExpressCard, and so on.
For Thunderbolt DMA protection on earlier Windows versions and other platforms that lack support for Kernel
DMA Protection, please refer to Intel Thunderbolt™ 3 Security documentation.

Background
PCI devices are DMA-capable, which allows them to read and write to system memory at will, without having to
engage the system processor in these operations. The DMA capability is what makes PCI devices the highest
performing devices available today. These devices have historically existed only inside the PC chassis, either
connected as a card or soldered on the motherboard. Access to these devices required the user to turn off power to
the system and disassemble the chassis. Today, this is no longer the case with Thunderbolt™.
Thunderbolt™ technology has provided modern PCs with extensibility that was not available before for PCs. It
allows users to attach new classes of external peripherals, such as graphics cards or other PCI devices, to their PCs
with a hot plug experience identical to USB. Having PCI hot plug ports externally and easily accessible makes PCs
susceptible to drive-by DMA attacks.
Drive-by DMA attacks are attacks that occur while the owner of the system is not present and usually take less than
10 minutes, with simple to moderate attacking tools (affordable, off-the-shelf hardware and software) that do not
require the disassembly of the PC. A simple example would be a PC owner leaves the PC for a quick coffee break,
and within the break, and attacker steps in, plugs in a USB -like device and walks away with all the secrets on the
machine, or injects a malware that allows them to have full control over the PC remotely.

How Windows protects against DMA drive-by attacks

Windows leverages the system Input/Output Memory Management Unit (IOMMU ) to block external peripherals
from starting and performing DMA unless the drivers for these peripherals support memory isolation (such as
DMA-remapping). Peripherals with compatible drivers will be automatically enumerated, started and allowed to
perform DMA to their assigned memory regions. By default, peripherals with incompatible drivers will be blocked
from starting and performing DMA until an authorized user signs into the system or unlocks the screen.

User experience
A peripheral that is incompatible with DMA-remapping will be blocked from starting if the peripheral was plugged
in before an authorized user logs in, or while the screen is locked. Once the system is unlocked, the peripheral
driver will be started by the OS, and the peripheral will continue to function normally until the system is rebooted,
or the peripheral is unplugged. The peripheral will continue to function normally if the user locks the screen or logs
out of the system.

System compatibility
Kernel DMA Protection requires new UEFI firmware support. This support is anticipated only on newly-introduced,
Intel-based systems shipping with Windows 10 version 1803 (not all systems). Virtualization-based Security (VBS )
is not required.
To see if a system supports Kernel DMA Protection, check the System Information desktop app (MSINFO32).
Systems released prior to Windows 10 version 1803 do not support Kernel DMA Protection, but they can leverage
other DMA attack mitigations as described in BitLocker countermeasures.

NOTE
Kernel DMA Protection is not compatible with other BitLocker DMA attacks countermeasures. It is recommended to disable
the BitLocker DMA attacks countermeasures if the system supports Kernel DMA Protection. Kernel DMA Protection provides
higher security bar for the system over the BitLocker DMA attack countermeasures, while maintaining usability of external
peripherals.

How to check if Kernel DMA Protection is enabled

Systems running Windows 10 version 1803 that do support Kernel DMA Protection do have this security feature
enabled automatically by the OS with no user or IT admin configuration required.
Using Security Center
Beginning with Wndows 10 version 1809, you can use Security Center to check if Kernel DMA Protection is
enabled. Click Start > Settings > Update & Security > Windows Security > Open Windows Security >
Device security > Core isolation details > Memory access protection.
Using System information
1. Launch MSINFO32.exe in a command prompt, or in the Windows search bar.
2. Check the value of Kernel DMA Protection.

3. If the current state of Kernel DMA Protection is OFF and Virtualization Technology in Firmware is NO:
Reboot into BIOS settings
Turn on Intel Virtualization Technology.
Turn on Intel Virtualization Technology for I/O (VT-d). In Windows 10 version 1803, only Intel VT-d is
supported. Other platforms can use DMA attack mitigations described in BitLocker countermeasures.
Reboot system into Windows 10.
4. If the state of Kernel DMA Protection remains Off, then the system does not support this feature.
For systems that do not support Kernel DMA Protection, please refer to the BitLocker countermeasures or
Thunderbolt™ 3 and Security on Microsoft Windows® 10 Operating system for other means of DMA protection.
Frequently asked questions
Do in-market systems support Kernel DMA Protection for Thunderbolt™ 3?
In-market systems, released with Windows 10 version 1709 or earlier, will not support Kernel DMA Protection for
Thunderbolt™ 3 after upgrading to Windows 10 version 1803, as this feature requires the BIOS/platform firmware
changes and guarantees that cannot be backported to previously released devices. For these systems, please refer
to the BitLocker countermeasures or Thunderbolt™ 3 and Security on Microsoft Windows® 10 Operating system
for other means of DMA protection.
Does Kernel DMA Protection prevent drive -by DMA attacks during Boot?
No, Kernel DMA Protection only protects against drive-by DMA attacks after the OS is loaded. It is the
responsibility of the system firmware/BIOS to protect against attacks via the Thunderbolt™ 3 ports during boot.
How can I check if a certain driver supports DMA -remapping?
DMA-remapping is supported for specific device drivers, and is not universally supported by all devices and
drivers on a platform. To check if a specific driver is opted into DMA-remapping, check the values corresponding to
the following Property GUID (highlighted in red in the image below ) in the Details tab of a device in Device
Manager. A value of 0 or 1 means that the device driver does not support DMA-remapping. A value of 2 means
that the device driver supports DMA-remapping. Please check the driver instance for the device you are testing.
Some drivers may have varying values depending on the location of the device (internal vs. external).

What should I do if the drivers for my Thunderbolt™ 3 peripherals do not support DMA -remapping?
If the peripherals do have class drivers provided by Windows 10, please use these drivers on your systems. If there
are no class drivers provided by Windows for your peripherals, please contact your peripheral vendor/driver
vendor to update the driver to support this functionality. Details for driver compatibility requirements can be found
here (add link to OEM documentation).
Do Microsoft drivers support DMA -remapping?
In Windows 10 1803 and beyond, the Microsoft inbox drivers for USB XHCI (3.x) Controllers, Storage AHCI/SATA
Controllers and Storage NVMe Controllers support DMA-remapping.
Do drivers for non-PCI devices need to be compatible with DMA -remapping?
No. Devices for non-PCI peripherals, such as USB devices, do not perform DMA, thus no need for the driver to be
compatible with DMA-remapping.
How can an enterprise enable the External device enumeration policy?
The External device enumeration policy controls whether to enumerate external peripherals that are not compatible
with DMA-remapping. Peripherals that are compatible with DMA-remapping are always enumerated. Peripherals
that don't can be blocked, allowed, or allowed only after the user signs in (default).
The policy can be enabled by using:
Group Policy: Administrative Templates\System\Kernel DMA Protection\Enumeration policy for external
devices incompatible with Kernel DMA Protection
Mobile Device Management (MDM ): DmaGuard policies

Related topics
BitLocker countermeasures
DmaGuard MDM policies
 Protect your enterprise data using Windows
Information Protection (WIP)
11/9/2018 • 13 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later

Learn more about what features and functionality are supported in each Windows edition at Compare
Windows 10 Editions.

With the increase of employee-owned devices in the enterprise, there’s also an increasing risk of accidental data
leak through apps and services, like email, social media, and the public cloud, which are outside of the enterprise’s
control. For example, when an employee sends the latest engineering pictures from their personal email account,
copies and pastes product info into a tweet, or saves an in-progress sales report to their public cloud storage.
Windows Information Protection (WIP ), previously known as enterprise data protection (EDP ), helps to protect
against this potential data leakage without otherwise interfering with the employee experience. WIP also helps to
protect enterprise apps and data against accidental data leak on enterprise-owned devices and personal devices
that employees bring to work without requiring changes to your environment or other apps. Finally, another data
protection technology, Azure Rights Management also works alongside WIP to extend data protection for data that
leaves the device, such as when email attachments are sent from an enterprise aware version of a rights
management mail client.

Video: Protect enterprise data from being accidentally copied to the

wrong place

Prerequisites
You’ll need this software to run WIP in your enterprise:

OPERATING SYSTEM MANAGEMENT SOLUTION

Windows 10, version 1607 or later Microsoft Intune

-OR-

System Center Configuration Manager

-OR-

Your current company-wide 3rd party mobile device

management (MDM) solution. For info about 3rd party MDM
solutions, see the documentation that came with your
product. If your 3rd party MDM does not have UI support for
the policies, refer to the EnterpriseDataProtection CSP
documentation.
What is enterprise data control?
Effective collaboration means that you need to share data with others in your enterprise. This sharing can be from
one extreme where everyone has access to everything without any security, all the way to the other extreme where
people can’t share anything and it’s all highly secured. Most enterprises fall somewhere in between the two
extremes, where success is balanced between providing the necessary access with the potential for improper data
disclosure.
As an admin, you can address the question of who gets access to your data by using access controls, such as
employee credentials. However, just because someone has the right to access your data doesn’t guarantee that the
data will remain within the secured locations of the enterprise. This means that while access controls are a great
start, they’re not enough.
In the end, all of these security measures have one thing in common: employees will tolerate only so much
inconvenience before looking for ways around the security restrictions. For example, if you don’t allow employees
to share files through a protected system, employees will turn to an outside app that more than likely lacks security
controls.
Using data loss prevention systems
To help address this security insufficiency, companies developed data loss prevention (also known as DLP ) systems.
Data loss prevention systems require:
A set of rules about how the system can identify and categorize the data that needs to be
protected. For example, a rule set might contain a rule that identifies credit card numbers and another rule
that identifies Social Security numbers.
A way to scan company data to see whether it matches any of your defined rules. Currently,
Microsoft Exchange Server and Exchange Online provide this service for email in transit, while Microsoft
SharePoint and SharePoint Online provide this service for content stored in document libraries.
The ability to specify what happens when data matches a rule, including whether employees can
bypass enforcement. For example, in Microsoft SharePoint and SharePoint Online, the Microsoft data loss
prevention system lets you warn your employees that shared data includes sensitive info, and to share it
anyway (with an optional audit log entry).
Unfortunately, data loss prevention systems have their own problems. For example, the more detailed the rule set,
the more false positives are created, leading employees to believe that the rules slow down their work and need to
be bypassed in order to remain productive, potentially leading to data being incorrectly blocked or improperly
released. Another major problem is that data loss prevention systems must be widely implemented to be effective.
For example, if your company uses a data loss prevention system for email, but not for file shares or document
storage, you might find that your data leaks through the unprotected channels. But perhaps the biggest problem
with data loss preventions systems is that it provides a jarring experience that interrupts the employees’ natural
workflow by stopping some operations (such as sending a message with an attachment that the system tags as
sensitive) while allowing others, often according to subtle rules that the employee doesn’t see and can’t
understand.
Using information rights management systems
To help address the potential data loss prevention system problems, companies developed information rights
management (also known as IRM ) systems. Information rights management systems embed protection directly
into documents, so that when an employee creates a document, he or she determines what kind of protection to
apply. For example, an employee can choose to stop the document from being forwarded, printed, shared outside
of the organization, and so on.
After the type of protection is set, the creating app encrypts the document so that only authorized people can open
it, and even then, only in compatible apps. After an employee opens the document, the app becomes responsible
for enforcing the specified protections. Because protection travels with the document, if an authorized person
sends it to an unauthorized person, the unauthorized person won’t be able to read or change it. However, for this
to work effectively information rights management systems require you to deploy and set up both a server and
client environment. And, because only compatible clients can work with protected documents, an employees’ work
might be unexpectedly interrupted if he or she attempts to use a non-compatible app.
And what about when an employee leaves the company or unenrolls a device?
Finally, there’s the risk of data leaking from your company when an employee leaves or unenrolls a device.
Previously, you would simply erase all of the corporate data from the device, along with any other personal data on
the device.

Benefits of WIP
WIP provides:
Obvious separation between personal and corporate data, without requiring employees to switch
environments or apps.
Additional data protection for existing line-of-business apps without a need to update the apps.
Ability to wipe corporate data from Intune MDM enrolled devices while leaving personal data alone.
Use of audit reports for tracking issues and remedial actions.
Integration with your existing management system (Microsoft Intune, System Center Configuration
Manager, or your current mobile device management (MDM ) system) to configure, deploy, and manage
WIP for your company.

Why use WIP?

WIP gives you a new way to manage data policy enforcement for apps and documents, along with the ability to
remove access to enterprise data from both enterprise and personal devices (after enrollment in an enterprise
management solution, like Intune).
Change the way you think about data policy enforcement. As an enterprise admin, you need to
maintain compliance in your data policy and data access. WIP helps make sure that your enterprise data is
protected on both corporate and employee-owned devices, even when the employee isn’t using the device.
When employees create content on an enterprise-protected device, they can choose to save it as a work
document. If it's a work document, it becomes locally-maintained as enterprise data.
Manage your enterprise documents, apps, and encryption modes.
Copying or downloading enterprise data. When an employee or an app downloads content from
a location like SharePoint, a network share, or an enterprise web location, while using a WIP -
protected device, WIP encrypts the data on the device.
Using allowed apps. Managed apps (apps that you've included on the Protected apps list in your
WIP policy) are allowed to access your enterprise data and will interact differently when used with
unallowed, non-enterprise aware, or personal-only apps. For example, if WIP management is set to
Block, your employees can copy and paste from one protected app to another allowed app, but not
to personal apps. Imagine an HR person wants to copy a job description from an allowed app to the
internal career website, an enterprise-protected location, but goofs and tries to paste into a personal
app instead. The paste action fails and a notification pops up, saying that the app couldn’t paste
because of a policy restriction. The HR person then correctly pastes to the career website without a
problem.
Managed apps and restrictions. With WIP you can control which apps can access and use your
enterprise data. After adding an app to your allowed apps list, the app is trusted with enterprise data.
 All apps not on this list are stopped from accessing your enterprise data, depending on your WIP
management-mode.
You don’t have to modify line-of-business apps that never touch personal data to list them as allowed
apps; just include them in the allowed apps list.
Deciding your level of data access. WIP lets you block, allow overrides, or audit employees' data
sharing actions. Hiding overrides stops the action immediately. Allowing overrides lets the employee
know there's a risk, but lets him or her continue to share the data while recording and auditing the
action. Silent just logs the action without stopping anything that the employee could've overridden
while using that setting; collecting info that can help you to see patterns of inappropriate sharing so
you can take educative action or find apps that should be added to your allowed apps list. For info
about how to collect your audit log files, see How to collect Windows Information Protection (WIP )
audit event logs.
Data encryption at rest. WIP helps protect enterprise data on local files and on removable media.
Apps such as Microsoft Word work with WIP to help continue your data protection across local files
and removable media. These apps are being referred to as, enterprise aware. For example, if an
employee opens WIP -encrypted content from Word, edits the content, and then tries to save the
edited version with a different name, Word automatically applies WIP to the new document.
Helping prevent accidental data disclosure to public spaces. WIP helps protect your enterprise
data from being accidentally shared to public spaces, such as public cloud storage. For example, if
Dropbox™ isn’t on your allowed apps list, employees won’t be able to sync encrypted files to their
personal cloud storage. Instead, if the employee stores the content to an app on your allowed apps
list, like Microsoft OneDrive for Business, the encrypted files can sync freely to the business cloud,
while maintaining the encryption locally.
Helping prevent accidental data disclosure to removable media. WIP helps prevent enterprise
data from leaking when it's copied or transferred to removable media. For example, if an employee
puts enterprise data on a Universal Serial Bus (USB ) drive that also has personal data, the enterprise
data remains encrypted while the personal data doesn’t.
Remove access to enterprise data from enterprise-protected devices. WIP gives admins the ability to
revoke enterprise data from one or many MDM -enrolled devices, while leaving personal data alone. This is
a benefit when an employee leaves your company, or in the case of a stolen device. After determining that
the data access needs to be removed, you can use Microsoft Intune to unenroll the device so when it
connects to the network, the user's encryption key for the device is revoked and the enterprise data
becomes unreadable.

NOTE
For management of Surface devices it is recommended that you use the Current Branch of System Center
Configuration Manager.
System Center Configuration Manager also allows you to revoke enterprise data. However, it does it by performing a
factory reset of the device.

How WIP works

WIP helps address your everyday challenges in the enterprise. Including:
Helping to prevent enterprise data leaks, even on employee-owned devices that can't be locked down.
Reducing employee frustrations because of restrictive data management policies on enterprise-owned
devices.
 Helping to maintain the ownership and control of your enterprise data.
Helping control the network and data access and data sharing for apps that aren’t enterprise aware
Enterprise scenarios
WIP currently addresses these enterprise scenarios:
You can encrypt enterprise data on employee-owned and corporate-owned devices.
You can remotely wipe enterprise data off managed computers, including employee-owned computers,
without affecting the personal data.
You can select specific apps that can access enterprise data, called "allowed apps" that are clearly
recognizable to employees. You can also stop non-protected apps from accessing enterprise data.
Your employees won't have their work otherwise interrupted while switching between personal and
enterprise apps while the enterprise policies are in place. Switching environments or signing in multiple
times isn’t required.
WIP-protection modes
Enterprise data is automatically encrypted after it’s loaded on a device from an enterprise source or if an employee
marks the data as corporate. Then, when the enterprise data is written to disk, WIP uses the Windows-provided
Encrypting File System (EFS ) to protect it and associate it with your enterprise identity.
Your WIP policy includes a list of trusted apps that are allowed to access and process corporate data. This list of
apps is implemented through the AppLocker functionality, controlling what apps are allowed to run and letting the
Windows operating system know that the apps can edit corporate data. Apps included on this list don’t have to be
modified to open corporate data because their presence on the list allows Windows to determine whether to grant
them access. However, new for Windows 10, app developers can use a new set of application programming
interfaces (APIs) to create enlightened apps that can use and edit both enterprise and personal data. A huge benefit
to working with enlightened apps is that dual-use apps, like Microsoft Word, can be used with less concern about
encrypting personal data by mistake because the APIs allow the app to determine whether data is owned by the
enterprise or if it’s personally owned.

NOTE
For info about how to collect your audit log files, see How to collect Windows Information Protection (WIP) audit event logs.

You can set your WIP policy to use 1 of 4 protection and management modes:

MODE DESCRIPTION

Block WIP looks for inappropriate data sharing practices and stops
the employee from completing the action. This can include
sharing enterprise data to non-enterprise-protected apps in
addition to sharing enterprise data between apps or
attempting to share outside of your organization’s network.

Allow overrides WIP looks for inappropriate data sharing, warning employees
if they do something deemed potentially unsafe. However, this
management mode lets the employee override the policy and
share the data, logging the action to your audit log.
 MODE DESCRIPTION

Silent WIP runs silently, logging inappropriate data sharing, without

stopping anything that would’ve been prompted for employee
interaction while in Allow overrides mode. Unallowed actions,
like apps inappropriately trying to access a network resource
or WIP-protected data, are still stopped.

Off WIP is turned off and doesn't help to protect or audit your
data.
After you turn off WIP, an attempt is made to decrypt any
WIP-tagged files on the locally attached drives. Be aware
that your previous decryption and policy info isn’t
automatically reapplied if you turn WIP protection back
on.
Note
For more info about setting your WIP-protection modes,
see either Create a Windows Information Protection (WIP)
policy using Intune or Create and deploy a Windows
Information Protection (WIP) policy using Configuration
Manager, depending on your management solution.

Turn off WIP

You can turn off all Windows Information Protection and restrictions, decrypting all devices managed by WIP and
reverting to where you were pre-WIP, with no data loss. However, this isn’t recommended. If you choose to turn
WIP off, you can always turn it back on, but your decryption and policy info won’t be automatically reapplied.

Next steps
After deciding to use WIP in your enterprise, you need to:
Create a Windows Information Protection (WIP ) policy

NOTE
Help to make this topic better by providing us with edits, additions, and feedback. For info about how to contribute to this
topic, see Editing Windows IT professional documentation.
 Create a Windows Information Protection (WIP)
policy using Microsoft Intune
1/10/2019 • 2 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later
Microsoft Intune helps you create and deploy your enterprise data protection (WIP ) policy, including letting you
choose your protected apps, your WIP -protection level, and how to find enterprise data on the network.

In this section
TOPIC DESCRIPTION

Create a Windows Information Protection (WIP) policy with Details about how to use the Azure portal for Microsoft
MDM using the Azure portal for Microsoft Intune Intune to create and deploy your WIP policy with MDM
(Mobile Device Management), including letting you choose
your protected apps, your WIP-protection level, and how to
find enterprise data on the network.

Create a Windows Information Protection (WIP) policy with Details about how to use the Azure portal for Microsoft
MAM using the Azure portal for Microsoft Intune Intune to create your WIP policy with MAM (Mobile
Application Management), including letting you choose your
protected apps, your WIP-protection level, and how to find
enterprise data on the network.

Create a Windows Information Protection (WIP) policy using Details about how to use the classic console for Microsoft
the classic console for Microsoft Intune Intune to create and deploy your WIP policy, including letting
you choose your protected apps, your WIP-protection level,
and how to find enterprise data on the network.

Create and verify an Encrypting File System (EFS) Data Steps to create, verify, and perform a quick recovery using a
Recovery Agent (DRA) certificate Encrypting File System (EFS) Data Recovery Agent (DRA)
certificate.

Determine the Enterprise Context of an app running in Use the Task Manager to determine whether an app is
Windows Information Protection (WIP) considered work, personal or exempt by Windows Information
Protection (WIP).
 Create a Windows Information Protection (WIP)
policy using the classic console for Microsoft Intune
10/15/2018 • 21 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later
Microsoft Intune helps you create and deploy your Windows Information Protection (WIP ) policy, including
letting you choose your allowed apps, your WIP -protection level, and how to find enterprise data on the network.

Add a WIP policy

After you’ve set up Intune for your organization, you must create a WIP -specific policy.
To add a WIP policy
1. Open the Intune administration console, and go to the Policy node, and then click Add Policy from the
Tasks area.
2. Go to Windows, click the Windows Information Protection (Windows 10 Desktop and Mobile and
later) policy, click Create and Deploy a Custom Policy, and then click Create Policy.

3. Type a name (required) and an optional description for your policy into the Name and Description boxes.
Add app rules to your policy
During the policy-creation process in Intune, you can choose the apps you want to give access to your enterprise
data through WIP. Apps included in this list can protect data on behalf of the enterprise and are restricted from
copying or moving enterprise data to unprotected apps.
The steps to add your app rules are based on the type of rule template being applied. You can add a store app
(also known as a Universal Windows Platform (UWP ) app), a signed Windows desktop app, or an AppLocker
policy file.

IMPORTANT
Enlightened apps are expected to prevent enterprise data from going to unprotected network locations and to avoid
encrypting personal data. On the other hand, WIP-unaware apps might not respect the corporate network boundary, and
WIP-unaware apps will encrypt all files they create or modify. This means that they could encrypt personal data and cause
data loss during the revocation process.
Care must be taken to get a support statement from the software provider that their app is safe with WIP before adding it
to your App Rules list. If you don’t get this statement, it’s possible that you could experience app compat issues due to an
app losing the ability to access a necessary file after revocation.

Add a store app rule to your policy

For this example, we’re going to add Microsoft OneNote, a store app, to the App Rules list.
To add a store app
1. From the App Rules area, click Add.
The Add App Rule box appears.
2. Add a friendly name for your app into the Title box. In this example, it’s Microsoft OneNote.
3. Click Allow from the Windows Information Protection mode drop-down list.
Allow turns on WIP, helping to protect that app’s corporate data through the enforcement of WIP
restrictions. Instructions for exempting an app are included in the Exempt apps from WIP restrictions
section of this topic.
4. Pick Store App from the Rule template drop-down list.
The box changes to show the store app rule options.
5. Type the name of the app and the name of its publisher, and then click OK. For this UWP app example, the
Publisher is CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US and the
Product name is Microsoft.Office.OneNote .
If you don't know the publisher or product name, you can find them for both desktop devices and Windows 10
Mobile phones by following these steps.
To find the Publisher and Product Name values for Store apps without installing them
1. Go to the Microsoft Store for Business website, and find your app. For example, Microsoft OneNote.
2. Copy the ID value from the app URL. For example, Microsoft OneNote's ID URL is
https://www.microsoft.com/store/apps/onenote/9wzdncrfhvjl, and you'd copy the ID value, 9wzdncrfhvjl .
3. In a browser, run the Store for Business portal web API, to return a JavaScript Object Notation (JSON ) file
that includes the publisher and product name values. For example, run
https://bspmts.mp.microsoft.com/v1/public/catalog/Retail/Products/9wzdncrfhvjl/applockerdata, where
9wzdncrfhvjl is replaced with your ID value.

The API runs and opens a text editor with the app details.
 {
"packageIdentityName": "Microsoft.Office.OneNote",
"publisherCertificateName": "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond,
S=Washington, C=US"
}

4. Copy the publisherCertificateName value into the Publisher Name box and copy the
packageIdentityName value into the Product Name box of Intune.

IMPORTANT
The JSON file might also return a windowsPhoneLegacyId value for both the Publisher Name and Product Name
boxes. This means that you have an app that’s using a XAP package and that you must set the Product Name as
windowsPhoneLegacyId , and set the Publisher Name as CN= followed by the windowsPhoneLegacyId .

For example:

{
"windowsPhoneLegacyId": "ca05b3ab-f157-450c-8c49-a1f127f5e71d",
}

To find the Publisher and Product Name values for apps installed on Windows 10 mobile phones
1. If you need to add mobile apps that aren't distributed through the Store for Business, you must use the
Windows Device Portal feature.

Note
Your PC and phone must be on the same wireless network.

2. On the Windows Phone, go to Settings, choose Update & security, and then choose For developers.
3. In the For developers screen, turn on Developer mode, turn on Device Discovery, and then turn on
Device Portal.
4. Copy the URL in the Device Portal area into your device's browser, and then accept the SSL certificate.
5. In the Device discovery area, press Pair, and then enter the PIN into the website from the previous step.
6. On the Apps tab of the website, you can see details for the running apps, including the publisher and
product names.
7. Start the app for which you're looking for the publisher and product name values.
8. Copy the publisherCertificateName value and paste it into the Publisher Name box and the
packageIdentityName value into the Product Name box of Intune.
 IMPORTANT
The JSON file might also return a windowsPhoneLegacyId value for both the Publisher Name and Product Name
boxes. This means that you have an app that’s using a XAP package and that you must set the Product Name as
windowsPhoneLegacyId , and set the Publisher Name as CN= followed by the windowsPhoneLegacyId .

For example:

{
"windowsPhoneLegacyId": "ca05b3ab-f157-450c-8c49-a1f127f5e71d",
}

Add a desktop app rule to your policy

For this example, we’re going to add Internet Explorer, a desktop app, to the App Rules list.
To add a desktop app
1. From the App Rules area, click Add.
The Add App Rule box appears.

2. Add a friendly name for your app into the Title box. In this example, it’s Internet Explorer.
3. Click Allow from the Windows Information Protection mode drop-down list.
Allow turns on WIP, helping to protect that app’s corporate data through the enforcement of WIP
restrictions. Instructions for exempting an app are included in the Exempt apps from WIP restrictions
section of this topic.
4. Pick Desktop App from the Rule template drop-down list.
The box changes to show the store app rule options.
5. Pick the options you want to include for the app rule (see table), and then click OK.

OPTION MANAGES

All fields left as “*” All files signed by any publisher. (Not recommended)

Publisher selected All files signed by the named publisher.

This might be useful if your company is the publisher
and signer of internal line-of-business apps.

Publisher and Product Name selected All files for the specified product, signed by the named
publisher.

Publisher, Product Name, and Binary name selected Any version of the named file or package for the specified
product, signed by the named publisher.

Publisher, Product Name, Binary name, and File Specified version or newer releases of the named file or
Version, and above, selected package for the specified product, signed by the named
publisher.
This option is recommended for enlightened apps
that weren't previously enlightened.

Publisher, Product Name, Binary name, and File Specified version or older releases of the named file or
Version, And below selected package for the specified product, signed by the named
publisher.

Publisher, Product Name, Binary name, and File Specified version of the named file or package for the
Version, Exactly selected specified product, signed by the named publisher.

If you’re unsure about what to include for the publisher, you can run this PowerShell command:

Get-AppLockerFileInformation -Path "<path of the exe>"

Where "<path of the exe>"goes to the location of the app on the device. For example,
Get-AppLockerFileInformation -Path "C:\Program Files\Internet Explorer\iexplore.exe" .

In this example, you'd get the following info:

Path Publisher
---- ---------
%PROGRAMFILES%\INTERNET EXPLORER\IEXPLORE.EXE O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON,
C=US\INTERNET EXPLOR...

Where the text, O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US is the publisher name to enter in the
Publisher Name box.
Add an AppLocker policy file
Now we’re going to add an AppLocker XML file to the App Rules list. You’ll use this option if you want to add
multiple apps at the same time. For more info, see AppLocker.
To create a Packaged App rule and xml file
1. Open the Local Security Policy snap-in (SecPol.msc).
2. In the left pane, click Application Control Policies > AppLocker > Packaged App Rules.
3. Right-click Packaged App Rules > Create New Rule.
4. On the Before You Begin page, click Next.

5. On the Permissions page, make sure the Action is set to Allow and the User or group is set to
 Everyone, and then click Next.

6. On the Publisher page, click Select from the Use an installed packaged app as a reference area.
7. In the Select applications box, pick the app that you want to use as the reference for your rule, and then
click OK. For this example, we’re using Microsoft Photos.

8. On the updated Publisher page, click Create.

 9. Review the Local Security Policy snap-in to make sure your rule is correct.

10. In the left pane, right-click on AppLocker, and then click Export policy.
The Export policy box opens, letting you export and save your new policy as XML.
11. In the Export policy box, browse to where the policy should be stored, give the policy a name, and then
click Save.
The policy is saved and you’ll see a message that says 1 rule was exported from the policy.
Example XML file
This is the XML file that AppLocker creates for Microsoft Photos.

<AppLockerPolicy Version="1">
<RuleCollection Type="Exe" EnforcementMode="NotConfigured" />
<RuleCollection Type ="Msi" EnforcementMode="NotConfigured" />
<RuleCollection Type ="Script" EnforcementMode="NotConfigured" />
<RuleCollection Type ="Dll" EnforcementMode="NotConfigured" />
<RuleCollection Type ="Appx" EnforcementMode="NotConfigured">
<FilePublisherRule Id="5e0c752b-5921-4f72-8146-80ad5f582110" Name="Microsoft.Windows.Photos,
version 16.526.0.0 and above, from Microsoft Corporation" Description="" UserOrGroupSid="S-1-1-0"
Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="CN=Microsoft Corporation, O=Microsoft
Corporation, L=Redmond, S=Washington, C=US" ProductName="Microsoft.Windows.Photos" BinaryName="*">
<BinaryVersionRange LowSection="16.526.0.0" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
</RuleCollection>
</AppLockerPolicy>

12. After you’ve created your XML file, you need to import it by using Microsoft Intune.
To import your Applocker policy file app rule using Microsoft Intune
1. From the App Rules area, click Add.
The Add App Rule box appears.
2. Add a friendly name for your app into the Title box. In this example, it’s Allowed app list.
3. Click Allow from the Windows Information Protection mode drop-down list.
Allow turns on WIP, helping to protect that app’s corporate data through the enforcement of WIP
restrictions. Instructions for exempting an app are included in the Exempt apps from WIP restrictions
section of this topic.
4. Pick AppLocker policy file from the Rule template drop-down list.
The box changes to let you import your AppLocker XML policy file.
5. Click Import, browse to your AppLocker XML file, click Open, and then click OK to close the Add App
Rule box.
The file is imported and the apps are added to your App Rules list.
Exempt apps from WIP restrictions
If you're running into compatibility issues where your app is incompatible with WIP, but still needs to be used
with enterprise data, you can exempt the app from the WIP restrictions. This means that your apps won't include
auto-encryption or tagging and won't honor your network restrictions. It also means that your exempted apps
might leak.
To exempt a store app, a desktop app, or an AppLocker policy file app rule
1. From the App Rules area, click Add.
The Add App Rule box appears.
2. Add a friendly name for your app into the Title box. In this example, it’s Exempt apps list.
3. Click Exempt from the Windows Information Protection mode drop-down list.
Be aware that when you exempt apps, they’re allowed to bypass the WIP restrictions and access your
corporate data. To allow apps, see the Add app rules to your policy section of this topic.
4. Fill out the rest of the app rule info, based on the type of rule you’re adding:
Store app. Follow the Publisher and Product name instructions in the Add a store app rule to
your policy section of this topic.
Desktop app. Follow the Publisher, Product name, Binary name, and Version instructions in
the Add a desktop app rule to your policy section of this topic.
AppLocker policy file. Follow the Import instructions in the Add an AppLocker policy file section
of this topic, using a list of exempted apps.
5. Click OK.

Manage the WIP protection mode for your enterprise data

After you've added the apps you want to protect with WIP, you'll need to apply a management and protection
mode.
We recommend that you start with Silent or Allow Overrides while verifying with a small group that you have
the right apps on your protected apps list. After you're done, you can change to your final enforcement policy,
either Allow Overrides or Block.

MODE DESCRIPTION

Block WIP looks for inappropriate data sharing practices and stops
the employee from completing the action. This can include
sharing info across non-enterprise-protected apps in addition
to sharing enterprise data between other people and devices
outside of your enterprise.

Allow Overrides WIP looks for inappropriate data sharing, warning employees
if they do something deemed potentially unsafe. However,
this management mode lets the employee override the policy
and share the data, logging the action to your audit log,
accessible through the Reporting CSP.

Silent WIP runs silently, logging inappropriate data sharing, without

blocking anything that would’ve been prompted for employee
interaction while in Allow Overrides mode. Unallowed actions,
like apps inappropriately trying to access a network resource
or WIP-protected data, are still blocked.

Off (not recommended) WIP is turned off and doesn't help to protect or audit your
data.
After you turn off WIP, an attempt is made to decrypt
any WIP-tagged files on the locally attached drives. Be
aware that your previous decryption and policy info isn’t
automatically reapplied if you turn WIP protection back
on.
Define your enterprise-managed corporate identity
Corporate identity, usually expressed as your primary Internet domain (for example, contoso.com), helps to
identify and tag your corporate data from apps you’ve marked as protected by WIP. For example, emails using
contoso.com are identified as being corporate and are restricted by your Windows Information Protection
policies.
You can specify multiple domains owned by your enterprise by separating them with the "|" character. For
example, ( contoso.com|newcontoso.com ). With multiple domains, the first one is designated as your corporate
identity and all of the additional ones as being owned by the first one. We strongly recommend that you include
all of your email address domains in this list.
To add your corporate identity
Type the name of your corporate identity into the Corporate identity field. For example, contoso.com or
contoso.com|newcontoso.com .

Choose where apps can access enterprise data

After you've added a protection mode to your apps, you'll need to decide where those apps can access enterprise
data on your network.
There are no default locations included with WIP, you must add each of your network locations. This area applies
to any network endpoint device that gets an IP address in your enterprise’s range and is also bound to one of
your enterprise domains, including SMB shares. Local file system locations should just maintain encryption (for
example, on local NTFS, FAT, ExFAT).

IMPORTANT
Every WIP policy should include policy that defines your enterprise network locations.
Classless Inter-Domain Routing (CIDR) notation isn’t supported for WIP configurations.

To define where your protected apps can find and send enterprise data on you network
1. Add additional network locations your apps can access by clicking Add.
The Add or edit corporate network definition box appears.
2. Type a name for your corporate network element into the Name box, and then pick what type of network
element it is, from the Network element drop-down box. This can include any of the options in the
following table.
NETWORK LOCATION TYPE FORMAT DESCRIPTION
Enterprise Cloud Resources With proxy: Specify the cloud resources to be
contoso.sharepoint.com,contoso.inte treated as corporate and protected
rnalproxy1.com| by WIP.
contoso.visualstudio.com,contoso.int For each cloud resource, you
ernalproxy2.com may also optionally specify a
Without proxy: proxy server from your
contoso.sharepoint.com|contoso. Enterprise Internal Proxy Servers
visualstudio.com list to route traffic for this cloud
resource. Be aware that all traffic
routed through your Enterprise
Internal Proxy Servers is
considered enterprise.
If you have multiple resources,
you must separate them using
the "|" delimiter. If you don’t use
proxy servers, you must also
include the "," delimiter just
before the "|". For example:
URL <,proxy>|URL <,proxy> .

Important
In some cases, such as when an
app connects directly to a cloud
resource through an IP address,
Windows can’t tell whether it’s
attempting to connect to an
enterprise cloud resource or to a
personal site. In this case,
Windows blocks the connection
by default. To stop Windows
from automatically blocking
these connections, you can add
the /*AppCompat*/ string to
the setting. For example:
URL <,proxy>|URL
<,proxy>|/*AppCompat*/
.
When using this string, we
recommend that you also turn
on Azure Active Directory
Conditional Access, using the
Domain joined or marked as
compliant option, which blocks
apps from accessing any
enterprise cloud resources that
are protected by conditional
access.

Enterprise Network Domain Names corp.contoso.com,region.contoso.co Specify the DNS suffixes used in your
(Required) m environment. All traffic to the fully-
qualified domains appearing in this
list will be protected.
This setting works with the IP
ranges settings to detect
whether a network endpoint is
enterprise or personal on private
networks.
If you have multiple resources,
you must separate them using
the "," delimiter.
Enterprise Proxy Servers proxy.contoso.com:80;proxy2.contos Specify your externally-facing proxy
o.com:443 server addresses, along with the port
through which traffic accesses the
Internet.
This list must not include any
servers listed in the Enterprise
Internal Proxy Servers list,
because they’re used for WIP-
protected traffic.
This setting is also required if
there’s a chance you could end
up behind a proxy server on
another network. In this
situation, if you don't have a
proxy server pre-defined, you
might find that enterprise
resources are unavailable to your
client device, such as when
you’re visiting another company
and not on the guest network.
To make sure this doesn’t
happen, the client device also
needs to be able to reach the
pre-defined proxy server
through the VPN network.
If you have multiple resources,
you must separate them using
the ";" delimiter.

Enterprise Internal Proxy Servers contoso.internalproxy1.com;contoso.i Specify the proxy servers your
nternalproxy2.com devices will go through to reach your
cloud resources.
Using this server type indicates
that the cloud resources you’re
connecting to are enterprise
resources.
This list shouldn’t include any
servers listed in the Enterprise
Proxy Servers list, which are used
for non-WIP-protected traffic.
If you have multiple resources,
you must separate them using
the ";" delimiter.

Enterprise IPv4 Range (Required, if Starting IPv4 Address: 3.4.0.1 Specify the addresses for a valid IPv4
not using IPv6) Ending IPv4 Address: 3.4.255.254 value range within your intranet.
Custom URI: 3.4.0.1-3.4.255.254, These addresses, used with your
10.0.0.1-10.255.255.254 Enterprise Network Domain Names,
define your corporate network
boundaries.
If you have multiple ranges, you
must separate them using the ","
delimiter.
 Enterprise IPv6 Range (Required, if Starting IPv6 Address: 2a01:110:: Specify the addresses for a valid IPv6
not using IPv4) Ending IPv6 Address: value range within your intranet.
2a01:110:7fff:ffff:ffff:ffff:ffff:ffff These addresses, used with your
Custom URI: Enterprise Network Domain Names,
2a01:110:7fff:ffff:ffff:ffff:ffff:ffff, define your corporate network
fd00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff boundaries.
If you have multiple ranges, you
must separate them using the ","
delimiter.

Neutral Resources sts.contoso.com,sts.contoso2.com Specify your authentication

redirection endpoints for your
company.
These locations are considered
enterprise or personal, based on
the context of the connection
before the redirection.
If you have multiple resources,
you must separate them using
the "," delimiter.

3. Add as many locations as you need, and then click OK.

The Add corporate network definition box closes.
4. Decide if you want to Windows to look for additional network settings:

Enterprise Proxy Servers list is authoritative (do not auto-detect). Click this box if you want
Windows to treat the proxy servers you specified in the network boundary definition as the
complete list of proxy servers available on your network. If you clear this box, Windows will search
for additional proxy servers in your immediate network.
Enterprise IP Ranges list is authoritative (do not auto-detect). Click this box if you want
Windows to treat the IP ranges you specified in the network boundary definition as the complete list
of IP ranges available on your network. If you clear this box, Windows will search for additional IP
ranges on any domain-joined devices connected to your network.
5. In the required Upload a Data Recovery Agent (DRA ) certificate to allow recovery of encrypted
data box, click Browse to add a data recovery certificate for your policy.

After you create and deploy your WIP policy to your employees, Windows will begin to encrypt your
corporate data on the employees’ local device drive. If somehow the employees’ local encryption keys get
lost or revoked, the encrypted data can become unrecoverable. To help avoid this possibility, the DRA
certificate lets Windows use an included public key to encrypt the local data, while you maintain the private
key that can unencrypt the data.
For more info about how to find and export your data recovery certificate, see the Data Recovery and
Encrypting File System (EFS ) topic. For more info about creating and verifying your EFS DRA certificate,
see the Create and verify an Encrypting File System (EFS ) Data Recovery Agent (DRA) certificate.
Choose to set up Azure Rights Management with WIP
WIP can integrate with Microsoft Azure Rights Management to enable secure sharing of files via removable
drives such as USB drives. For more info about Azure Rights Management, see Microsoft Azure Rights
Management. To integrate Azure Rights Management with WIP, you must already have Azure Rights
Management set up.
To configure WIP to use Azure Rights Management, you must set the AllowAzureRMSForEDP MDM setting to
1 in Microsoft Intune. This setting tells WIP to encrypt files copied to removable drives with Azure Rights
Management, so they can be shared amongst your employees on computers running at least Windows 10,
version 1703.
Optionally, if you don’t want everyone in your organization to be able to share your enterprise data, you can set
the RMSTemplateIDForEDP MDM setting to the TemplateID of the Azure Rights Management template used
to encrypt the data. You must make sure to mark the template with the EditRightsData option.

IMPORTANT
Curly braces -- {} -- are required around the RMS Template ID.

NOTE
For more info about setting the AllowAzureRMSForEDP and the RMSTemplateIDForEDP MDM settings, see the
EnterpriseDataProtection CSP topic. For more info about setting up and using a custom template, see Configuring custom
templates for the Azure Rights Management service topic.

Choose your optional WIP-related settings

After you've decided where your protected apps can access enterprise data on your network, you’ll be asked to
decide if you want to add any optional WIP settings.

To set your optional settings

1. Choose to set any or all of the optional settings:
Show the Personal option in the File ownership menus of File Explorer and the Save As
dialog box. Determines whether users can see the Personal option for files within File Explorer and
the Save As dialog box. The options are:
 Yes, or not configured (recommended). Employees can choose whether a file is Work or
Personal in File Explorer and the Save As dialog box.
No. Hides the Personal option from employees. Be aware that if you pick this option, apps
that use the Save As dialog box might encrypt new files as corporate data unless a different
file path is given during the original file creation. After this happens, decryption of work files
becomes more difficult.
Prevent corporate data from being accessed by apps when the device is locked. Applies
only to Windows 10 Mobile. Determines whether to encrypt enterprise data using a key that's
protected by an employee's PIN code on a locked device. Apps won't be able to read corporate data
when the device is locked. The options are:
Yes (recommended). Turns on the feature and provides the additional protection.
No, or not configured. Doesn't enable this feature.
Revoke encryption keys on unenroll. Determines whether to revoke a user’s local encryption
keys from a device when it’s unenrolled from Windows Information Protection. If the encryption
keys are revoked, a user no longer has access to encrypted corporate data. The options are:
Yes, or not configured (recommended). Revokes local encryption keys from a device
during unenrollment.
No. Stop local encryption keys from being revoked from a device during unenrollment. For
example, if you’re migrating between Mobile Device Management (MDM ) solutions.
Allow Windows Search to search encrypted corporate data and Store apps. Determines
whether Windows Search can search and index encrypted corporate data and Store apps. The
options are:
Yes. Allows Windows Search to search and index encrypted corporate data and Store apps.
No, or not configured (recommended). Stops Windows Search from searching and
indexing encrypted corporate data and Store apps.
Show the Windows Information Protection icon overlay. Determines whether the Windows
Information Protection icon overlay appears on corporate files in the Save As and File Explorer
views. The options are:
Yes. Allows the Windows Information Protection icon overlay to appear on corporate files in
the Save As and File Explorer views. Additionally, for unenlightened but allowed apps, the
icon overlay also appears on the app tile and with Managed text on the app name in the Start
menu.
No, or not configured (recommended). Stops the Windows Information Protection icon
overlay from appearing on corporate files or unenlightened, but allowed apps. Not
configured is the default option.
2. Click Save Policy.

Related topics
Deploy your Windows Information Protection (WIP ) policy
Create and deploy a VPN policy for Windows Information Protection (WIP ) using Microsoft Intune
General guidance and best practices for Windows Information Protection (WIP )
Azure RMS Documentation Update for May 2016
 What is Azure Rights Management?

NOTE
Help to make this topic better by providing us with edits, additions, and feedback. For info about how to contribute to this
topic, see Editing Windows IT professional documentation.
 Deploy your Windows Information Protection (WIP)
policy using the classic console for Microsoft Intune
10/15/2018 • 2 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later
After you’ve created your Windows Information Protection (WIP ) policy, you'll need to deploy it to your
organization's enrolled devices. Enrollment can be done for business or personal devices, allowing the devices to
use your managed apps and to sync with your managed content and information.
To deploy your WIP policy
1. On the Configuration policies page, locate your newly-created policy, click to select it, and then click the
Manage Deployment button.

2. In the left pane of the Manage Deployment box, click the employees or groups that should get the policy,
and then click Add.
The added people move to the Selected Groups list on the right-hand pane.
3. After you've picked all of the employees and groups that should get the policy, click OK.
The policy is deployed to the selected users' devices.

NOTE
Help to make this topic better by providing us with edits, additions, and feedback. For info about how to contribute to this
topic, see Editing Windows IT professional documentation.

Related topics
Create a Windows Information Protection (WIP ) policy using Microsoft Intune
Create and deploy a VPN policy for Windows Information Protection (WIP ) using Microsoft Intune
General guidance and best practices for Windows Information Protection (WIP )
 Associate and deploy a VPN policy for Windows
Information Protection (WIP) using the classic
console for Microsoft Intune
10/15/2018 • 3 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later
After you've created and deployed your Windows Information Protection (WIP ) policy, you can use Microsoft
Intune to create and deploy your Virtual Private Network (VPN ) policy, linking it to your WIP policy.

Create your VPN policy using Microsoft Intune

Follow these steps to create the VPN policy you want to use with WIP.
To create your VPN policy
1. Open the Intune administration console, and go to the Policy node, and then click Add Policy.
2. Go to Windows, click the VPN Profile (Windows 10 Desktop and Mobile and later), click Create and
Deploy a Custom Policy, and then click Create Policy.

3. Type Contoso_VPN_Win10 into the Name box, along with an optional description for your policy into the
Description box.
4. In the VPN Settings area, type the following info:
VPN connection name. This name is also what appears to your employees, so it's important that it
be clear and understandable.
Connection type. Pick the connection type that matches your infrastructure. The options are Pulse
Secure, F5 Edge Client, Dell SonicWALL Mobile Connect, or Check Point Capsule VPN.
VPN server description. A descriptive name for this connection. Only you will see it, but it should
be unique and readable.
Server IP address or FQDN. The server's IP address or fully-qualified domain name (FQDN ).

5. In the Authentication area, choose the authentication method that matches your VPN infrastructure,
either Username and Password or Certificates.
It's your choice whether you check the box to Remember the user credentials at each logon.
6. You can leave the rest of the default or blank settings, and then click Save Policy.

Deploy your VPN policy using Microsoft Intune

After you’ve created your VPN policy, you'll need to deploy it to the same group you deployed your Windows
Information Protection (WIP ) policy.
To deploy your VPN policy
1. On the Configuration policies page, locate your newly-created policy, click to select it, and then click the
Manage Deployment button.
2. In the left pane of the Manage Deployment box, click the employees or groups that should get the policy,
and then click Add.
The added people move to the Selected Groups list on the right-hand pane.

3. After you've picked all of the employees and groups that should get the policy, click OK.
The policy is deployed to the selected users' devices.

Link your WIP and VPN policies and deploy the custom configuration
policy
The final step to making your VPN configuration work with WIP, is to link your two policies together. To do this,
you must first create a custom configuration policy, setting it to use your EDPModeID setting, and then
deploying the policy to the same group you deployed your WIP and VPN policies
To link your VPN policy
1. Open the Intune administration console, and go to the Policy node, and then click Add Policy.
2. Go to Windows, click the Custom Configuration (Windows 10 Desktop and Mobile and later), click
Create and Deploy a Custom Policy, and then click Create Policy.
3. Type a name (required) and an optional description for your policy into the Name and Description boxes.

4. In the OMA -URI Settings area, click Add to add your EDPModeID info.
5. In the OMA -URI Settings area, type the following info:
Setting name. Type EDPModeID as the name.
Data type. Pick the String data type.
OMA -URI. Type ./Vendor/MSFT/VPNv2/<VPNProfileName>/EDPModeId , replacing <VPNProfileName>
with the name you gave to your VPN policy. For example,
./Vendor/MSFT/VPNv2/W10-Checkpoint-VPN1/EDPModeId .

Value. Your fully-qualified domain that should be used by the OMA-URI setting.
6. Click OK to save your new OMA-URI setting, and then click Save Policy.
To deploy your linked policy
1. On the Configuration policies page, locate your newly-created policy, click to select it, and then click the
Manage Deployment button.
2. In the left pane of the Manage Deployment box, click the employees or groups that should get the policy,
and then click Add. The added people move to the Selected Groups list on the right-hand pane.

3. After you've picked all of the employees and groups that should get the policy, click OK. The policy is
deployed to the selected users' devices.
NOTE
Help to make this topic better by providing us with edits, additions, and feedback. For info about how to contribute to this
topic, see Editing Windows IT professional documentation.
 Create a Windows Information Protection (WIP)
policy with MDM using the Azure portal for
Microsoft Intune
10/18/2018 • 21 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later (except Microsoft Azure Rights Management, which is only
available on the desktop)
Microsoft Intune helps you create and deploy your Windows Information Protection (WIP ) policy, including letting
you choose your protected apps, your WIP -protection level, and how to find enterprise data on the network.

Alternative steps if you use MAM only (without device enrollment)

This topic covers creating a Windows Information Protection (WIP ) policy for organizations already managing
devices by using Mobile Device Management (MDM ) solutions. If your organization uses a mobile application
management (MAM ) solution to deploy your WIP policy to Intune apps without managing devices, see Create a
Windows Information Protection (WIP ) policy with MAM using the Azure portal for Microsoft Intune.
If the same user and device are targeted for both MDM policy and MAM -only (without device enrollment) policy,
the MDM policy will be applied to devices joined to Azure AD. For personal devices that are workplace-joined
(that is, added by using Settings > Email & accounts > Add a work or school account), the MAM -only policy
will be preferred but it's possible to upgrade the device management to MDM in Settings.
Windows Home edition only supports WIP for MAM -only; upgrading to MDM policy on Home edition will
revoke WIP -protected data access.

Add a WIP policy

Follow these steps to add a WIP policy using Intune.
To add a WIP policy
1. Open Microsoft Intune and click Client apps.
2. In Client apps, click App protection policies.

3. In the App policy screen, click Add a policy, and then fill out the fields:
Name. Type a name (required) for your new policy.
Description. Type an optional description.
Platform. Choose Windows 10.
Enrollment state. Choose With enrollment.
 IMPORTANT
Choosing With enrollment only applies for organizations using MDM. If you're using MAM only (without
device enrollment), see Create a Windows Information Protection (WIP) policy with MAM using the Azure
portal for Microsoft Intune.

4. Click Protected apps and then click Add apps.

You can add these types of apps:

Recommended apps
Store apps
Desktop apps
Add recommended apps
To add Recommended apps, select each app you want to access your enterprise data, and then click OK.
The Protected apps blade updates to show you your selected apps.
Add Store apps
To add Store apps, type the app product name and publisher and click OK. For example, to add the Power BI
Mobile App from the Store, type the following:
Name: Microsoft Power BI
Publisher: CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US
Product Name: Microsoft.MicrosoftPowerBIForWindows

To add multiple Store apps, click the elipsis ….

If you don't know the Store app publisher or product name, you can find them for both desktop devices and
Windows 10 Mobile phones by following these steps.
1. Go to the Microsoft Store for Business website, and find your app. For example, Power BI Mobile App.
2. Copy the ID value from the app URL. For example, the Power BI Mobile App ID URL is
https://www.microsoft.com/store/p/microsoft-power-bi/9nblgggzlxn1, and you'd copy the ID value,
9nblgggzlxn1 .

3. In a browser, run the Store for Business portal web API, to return a JavaScript Object Notation (JSON ) file
that includes the publisher and product name values. For example, run
https://bspmts.mp.microsoft.com/v1/public/catalog/Retail/Products/9nblgggzlxn1/applockerdata, where
9nblgggzlxn1 is replaced with your ID value.

The API runs and opens a text editor with the app details.

{
"packageIdentityName": "Microsoft.MicrosoftPowerBIForWindows",
"publisherCertificateName": "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond,
S=Washington, C=US"
}

4. Copy the publisherCertificateName value into the Publisher box and copy the packageIdentityName value
into the Name box of Intune.

IMPORTANT
The JSON file might also return a windowsPhoneLegacyId value for both the Publisher Name and Product Name
boxes. This means that you have an app that’s using a XAP package and that you must set the Product Name as
windowsPhoneLegacyId , and set the Publisher Name as CN= followed by the windowsPhoneLegacyId .

For example:
{
"windowsPhoneLegacyId": "ca05b3ab-f157-450c-8c49-a1f127f5e71d",
}

If you need to add Windows 10 mobile apps that aren't distributed through the Store for Business, you must use
the Windows Device Portal feature.

Note
Your PC and phone must be on the same wireless network.

1. On the Windows Phone, go to Settings, choose Update & security, and then choose For developers.
2. In the For developers screen, turn on Developer mode, turn on Device Discovery, and then turn on
Device Portal.
3. Copy the URL in the Device Portal area into your device's browser, and then accept the SSL certificate.
4. In the Device discovery area, press Pair, and then enter the PIN into the website from the previous step.
5. On the Apps tab of the website, you can see details for the running apps, including the publisher and
product names.
6. Start the app for which you're looking for the publisher and product name values.
7. Copy the publisherCertificateName value and paste it into the Publisher Name box and the
packageIdentityName value into the Product Name box of Intune.
 IMPORTANT
The JSON file might also return a windowsPhoneLegacyId value for both the Publisher Name and Product Name
boxes. This means that you have an app that’s using a XAP package and that you must set the Product Name as
windowsPhoneLegacyId , and set the Publisher Name as CN= followed by the windowsPhoneLegacyId .

For example:
{
"windowsPhoneLegacyId": "ca05b3ab-f157-450c-8c49-a1f127f5e71d",
}

Add Desktop apps

To add Desktop apps, complete the following fields, based on what results you want returned.

FIELD MANAGES

All fields marked as “*” All files signed by any publisher. (Not recommended)

Publisher only If you only fill out this field, you’ll get all files signed by the
named publisher.

This might be useful if your company is the publisher and

signer of internal line-of-business apps.

Publisher and Name only If you only fill out these fields, you’ll get all files for the
specified product, signed by the named publisher.

Publisher, Name, and File only If you only fill out these fields, you’ll get any version of the
named file or package for the specified product, signed by the
named publisher.

Publisher, Name, File, and Min version only If you only fill out these fields, you’ll get the specified version
or newer releases of the named file or package for the
specified product, signed by the named publisher.

This option is recommended for enlightened apps that weren't

previously enlightened.

Publisher, Name, File, and Max version only If you only fill out these fields, you’ll get the specified version
or older releases of the named file or package for the specified
product, signed by the named publisher.

All fields completed If you fill out all fields, you’ll get the specified version of the
named file or package for the specified product, signed by the
named publisher.

After you’ve entered the info into the fields, click OK.

NOTE
To add multiple Desktop apps, click the elipsis …. When you’re done, click OK.
If you’re unsure about what to include for the publisher, you can run this PowerShell command:

Get-AppLockerFileInformation -Path "<path_of_the_exe>"

Where "<path_of_the_exe>" goes to the location of the app on the device. For example:

Get-AppLockerFileInformation -Path "C:\Program Files\Windows NT\Accessories\wordpad.exe"

In this example, you'd get the following info:

Path Publisher
---- ---------
%PROGRAMFILES%\WINDOWS NT\ACCESSORIES\WORDPAD.EXE O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US

Where O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US is the Publisher name and WORDPAD.EXE is the
File name.
Import a list of apps
For this example, we’re going to add an AppLocker XML file to the Protected apps list. You’ll use this option if
you want to add multiple apps at the same time. The first example shows how to create a Packaged App rule for
Store apps. The second example shows how to create an Executable rule by using a path for unsigned apps. For
more info about AppLocker, see the AppLocker content.
To create a list of protected apps using the AppLocker tool
1. Open the Local Security Policy snap-in (SecPol.msc).
2. In the left blade, expand Application Control Policies, expand AppLocker, and then click Packaged App
Rules.
3. Right-click in the right-hand blade, and then click Create New Rule.
The Create Packaged app Rules wizard appears.
4. On the Before You Begin page, click Next.

5. On the Permissions page, make sure the Action is set to Allow and the User or group is set to
Everyone, and then click Next.
6. On the Publisher page, click Select from the Use an installed packaged app as a reference area.

7. In the Select applications box, pick the app that you want to use as the reference for your rule, and then
click OK. For this example, we’re using Microsoft Dynamics 365.
 8. On the updated Publisher page, click Create.

9. Click No in the dialog box that appears, asking if you want to create the default rules. You must not create
default rules for your WIP policy.

10. Review the Local Security Policy snap-in to make sure your rule is correct.
11. In the left blade, right-click on AppLocker, and then click Export policy.
The Export policy box opens, letting you export and save your new policy as XML.

12. In the Export policy box, browse to where the policy should be stored, give the policy a name, and then
click Save.
The policy is saved and you’ll see a message that says 1 rule was exported from the policy.
Example XML file
This is the XML file that AppLocker creates for Microsoft Dynamics 365.
 <?xml version="1.0"?>
<AppLockerPolicy Version="1">
<RuleCollection EnforcementMode="NotConfigured" Type="Appx">
<FilePublisherRule Action="Allow" UserOrGroupSid="S-1-1-0" Description=""
Name="Microsoft.MicrosoftDynamicsCRMforWindows10, version 3.2.0.0 and above, from Microsoft
Corporation" Id="3da34ed9-aec6-4239-88ba-0afdce252ab4">
<Conditions>
<FilePublisherCondition BinaryName="*"
ProductName="Microsoft.MicrosoftDynamicsCRMforWindows10" PublisherName="CN=Microsoft Corporation,
O=Microsoft Corporation, L=Redmond, S=Washington, C=US">
<BinaryVersionRange HighSection="*" LowSection="3.2.0.0"/>
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
</RuleCollection>
<RuleCollection EnforcementMode="NotConfigured" Type="Dll"/>
<RuleCollection EnforcementMode="NotConfigured" Type="Exe"/>
<RuleCollection EnforcementMode="NotConfigured" Type="Msi"/>
<RuleCollection EnforcementMode="NotConfigured" Type="Script"/>
</AppLockerPolicy>

13. After you’ve created your XML file, you need to import it by using Microsoft Intune.
To create an Executable rule and xml file for unsigned apps
1. Open the Local Security Policy snap-in (SecPol.msc).
2. In the left pane, click Application Control Policies > AppLocker > Executable Rules.
3. Right-click Executable Rules > Create New Rule.

4. On the Before You Begin page, click Next.

5. On the Permissions page, make sure the Action is set to Allow and the User or group is set to
Everyone, and then click Next.
6. On the Conditions page, click Path and then click Next.
7. Click Browse Folders... and select the path for the unsigned apps. For this example, we’re using
"C:\Program Files".
 8. On the Exceptions page, add any exceptions and then click Next.
9. On the Name page, type a name and description for the rule and then click Create.
10. In the left pane, right-click AppLocker > Export policy.
11. In the Export policy box, browse to where the policy should be stored, give the policy a name, and then
click Save.
The policy is saved and you’ll see a message that says 1 rule was exported from the policy.
12. After you’ve created your XML file, you need to import it by using Microsoft Intune.
To import a list of protected apps using Microsoft Intune
1. In Protected apps, click Import apps.

Then import your file.

2. Browse to your exported AppLocker policy file, and then click Open.
The file imports and the apps are added to your Protected apps list.
Exempt apps from a WIP policy
If you're running into compatibility issues where your app is incompatible with WIP, but still needs to be used with
enterprise data, you can exempt the app from the WIP restrictions. This means that your apps won't include auto-
encryption or tagging and won't honor your network restrictions. It also means that your exempted apps might
leak.
To exempt a Store app, a Desktop app, or an AppLocker policy file from the Protected apps list
1. In Client apps - App protection policies, click Exempt apps.

2. In Exempt apps, click Add apps.

Be aware that when you exempt apps, they’re allowed to bypass the WIP restrictions and access your
corporate data.
3. Fill out the rest of the app info, based on the type of app you’re adding:
Add Recommended apps
Add Store apps
Add Desktop apps
Import apps
4. Click OK.

Manage the WIP protection mode for your enterprise data

After you've added the apps you want to protect with WIP, you'll need to apply a management and protection
mode.
We recommend that you start with Silent or Allow Overrides while verifying with a small group that you have
the right apps on your protected apps list. After you're done, you can change to your final enforcement policy,
Block.

NOTE
For info about how to collect your audit log files, see How to collect Windows Information Protection (WIP) audit event logs.

To add your protection mode

1. From the App protection policy blade, click the name of your policy, and then click Required settings
from the menu that appears.
The Required settings blade appears.

MODE DESCRIPTION

Block WIP looks for inappropriate data sharing practices and

stops the employee from completing the action. This can
include sharing info across non-enterprise-protected apps
in addition to sharing enterprise data between other
people and devices outside of your enterprise.

Allow Overrides WIP looks for inappropriate data sharing, warning

employees if they do something deemed potentially
unsafe. However, this management mode lets the
employee override the policy and share the data, logging
the action to your audit log. For info about how to collect
your audit log files, see How to collect Windows
Information Protection (WIP) audit event logs.

Silent WIP runs silently, logging inappropriate data sharing,

without blocking anything that would’ve been prompted
for employee interaction while in Allow Override mode.
Unallowed actions, like apps inappropriately trying to
access a network resource or WIP-protected data, are still
stopped.
 MODE DESCRIPTION

Off (not recommended) WIP is turned off and doesn't help to protect or audit your
data.

After you turn off WIP, an attempt is made to decrypt any

WIP-tagged files on the locally attached drives. Be aware
that your previous decryption and policy info isn’t
automatically reapplied if you turn WIP protection back
on.

2. Click Save.

Define your enterprise-managed corporate identity

Corporate identity, usually expressed as your primary Internet domain (for example, contoso.com), helps to
identify and tag your corporate data from apps you’ve marked as protected by WIP. For example, emails using
contoso.com are identified as being corporate and are restricted by your Windows Information Protection policies.
Starting with Windows 10, version 1703, Intune automatically determines your corporate identity and adds it to
the Corporate identity field.
To change your corporate identity
1. From the App policy blade, click the name of your policy, and then click Required settings.
2. If the auto-defined identity isn’t correct, you can change the info in the Corporate identity field. If you
need to add domains, for example your email domains, you can do it in the Advanced settings area.

Choose where apps can access enterprise data

After you've added a protection mode to your apps, you'll need to decide where those apps can access enterprise
data on your network.
There are no default locations included with WIP, you must add each of your network locations. This area applies
to any network endpoint device that gets an IP address in your enterprise’s range and is also bound to one of your
enterprise domains, including SMB shares. Local file system locations should just maintain encryption (for
example, on local NTFS, FAT, ExFAT).
 IMPORTANT
Every WIP policy should include policy that defines your enterprise network locations.
Classless Inter-Domain Routing (CIDR) notation isn’t supported for WIP configurations.

To define where your protected apps can find and send enterprise data on you network
1. From the App policy blade, click the name of your policy, and then click Advanced settings.
2. Click Add network boundary from the Network perimeter area.

3. Select the type of network boundary to add from the Boundary type box.
4. Type a name for your boundary into the Name box, add your values to the Value box, based on the
following options, and then click OK.

BOUNDARY TYPE VALUE FORMAT DESCRIPTION

Cloud Resources With proxy: Specify the cloud resources to be
contoso.sharepoint.com,contoso.inter treated as corporate and protected
nalproxy1.com| by WIP.
contoso.visualstudio.com,contoso.int
ernalproxy2.com For each cloud resource, you may
also optionally specify a proxy server
Without proxy: from your Internal proxy servers list
contoso.sharepoint.com|contoso.visu to route traffic for this cloud
alstudio.com resource. Be aware that all traffic
routed through your Internal proxy
servers is considered enterprise.

If you have multiple resources, you

must separate them using the "|"
delimiter. If you don’t use proxy
servers, you must also include the ","
delimiter just before the "|". For
example:
URL <,proxy>|URL <,proxy> .

Important
In some cases, such as when an app
connects directly to a cloud resource
through an IP address, Windows
can’t tell whether it’s attempting to
connect to an enterprise cloud
resource or to a personal site. In this
case, Windows blocks the connection
by default. To stop Windows from
automatically blocking these
connections, you can add the
/*AppCompat*/ string to the
setting. For example:
URL <,proxy>|URL
<,proxy>|/*AppCompat*/
.

When using this string, we

recommend that you also turn on
Azure Active Directory Conditional
Access, using the Domain joined or
marked as compliant option, which
blocks apps from accessing any
enterprise cloud resources that are
protected by conditional access.

Protected domains exchange.contoso.com,contoso.com,r Specify the domains used for

egion.contoso.com identities in your environment. All
traffic to the fully-qualified domains
appearing in this list will be
protected.

If you have multiple domains, you

must separate them using the ","
delimiter.
Network domains corp.contoso.com,region.contoso.co Specify the DNS suffixes used in your
m environment. All traffic to the fully-
qualified domains appearing in this
list will be protected.

If you have multiple resources, you

must separate them using the ","
delimiter.

Proxy servers proxy.contoso.com:80;proxy2.contos Specify the proxy servers your

o.com:443 devices will go through to reach your
cloud resources. Using this server
type indicates that the cloud
resources you’re connecting to are
enterprise resources.

This list shouldn’t include any servers

listed in your Internal proxy servers
list. Internal proxy servers must be
used only for WIP-protected
(enterprise) traffic.

If you have multiple resources, you

must separate them using the ";"
delimiter.

Internal proxy servers contoso.internalproxy1.com;contoso.i Specify the internal proxy servers

nternalproxy2.com your devices will go through to reach
your cloud resources. Using this
server type indicates that the cloud
resources you’re connecting to are
enterprise resources.

This list shouldn’t include any servers

listed in your Proxy servers list. Proxy
servers must be used only for non-
WIP-protected (non-enterprise)
traffic.

If you have multiple resources, you

must separate them using the ";"
delimiter.

IPv4 ranges Starting IPv4 Address: 3.4.0.1 Starting with Windows 10, version
Ending IPv4 Address: 3.4.255.254 1703, this field is optional.
Custom URI: 3.4.0.1-3.4.255.254,
10.0.0.1-10.255.255.254 Specify the addresses for a valid IPv4
value range within your intranet.
These addresses, used with your
Network domain names, define your
corporate network boundaries.

If you have multiple ranges, you

must separate them using the ","
delimiter.
 IPv6 ranges Starting IPv6 Address: 2a01:110:: Starting with Windows 10, version
Ending IPv6 Address: 1703, this field is optional.
2a01:110:7fff:ffff:ffff:ffff:ffff:ffff
Custom URI: Specify the addresses for a valid IPv6
2a01:110:7fff:ffff:ffff:ffff:ffff:ffff, value range within your intranet.
fd00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff These addresses, used with your
Network domain names, define your
corporate network boundaries.

If you have multiple ranges, you

must separate them using the ","
delimiter.

Neutral resources sts.contoso.com,sts.contoso2.com Specify your authentication

redirection endpoints for your
company.

These locations are considered

enterprise or personal, based on the
context of the connection before the
redirection.

If you have multiple resources, you

must separate them using the ","
delimiter.

5. Repeat steps 1-4 to add any additional network boundaries.

6. Decide if you want to Windows to look for additional network settings:

Enterprise Proxy Servers list is authoritative (do not auto-detect). Click this box if you want
Windows to treat the proxy servers you specified in the network boundary definition as the complete
list of proxy servers available on your network. If you clear this box, Windows will search for
additional proxy servers in your immediate network.
Enterprise IP Ranges list is authoritative (do not auto-detect). Click this box if you want
Windows to treat the IP ranges you specified in the network boundary definition as the complete list
of IP ranges available on your network. If you clear this box, Windows will search for additional IP
ranges on any domain-joined devices connected to your network.

Upload your Data Recovery Agent (DRA) certificate

After you create and deploy your WIP policy to your employees, Windows begins to encrypt your corporate data
on the employees’ local device drive. If somehow the employees’ local encryption keys get lost or revoked, the
encrypted data can become unrecoverable. To help avoid this possibility, the Data Recovery Agent (DRA)
certificate lets Windows use an included public key to encrypt the local data while you maintain the private key
that can unencrypt the data.
 IMPORTANT
Using a DRA certificate isn’t mandatory. However, we strongly recommend it. For more info about how to find and export
your data recovery certificate, see the Data Recovery and Encrypting File System (EFS) topic. For more info about creating
and verifying your EFS DRA certificate, see the Create and verify an Encrypting File System (EFS) Data Recovery Agent (DRA)
certificate topic.

To upload your DRA certificate

1. From the App policy blade, click the name of your policy, and then click Advanced settings from the
menu that appears.
The Advanced settings blade appears.
2. In the Upload a Data Recovery Agent (DRA ) certificate to allow recovery of encrypted data box,
click Browse to add a data recovery certificate for your policy.

Choose your optional WIP-related settings

After you've decided where your protected apps can access enterprise data on your network, you’ll be asked to
decide if you want to add any optional WIP settings.
To set your optional settings
1. Choose to set any or all optional settings:

Prevent corporate data from being accessed by apps when the device is locked. Applies
only to Windows 10 Mobile. Determines whether to encrypt enterprise data using a key that's
protected by an employee's PIN code on a locked device. Apps won't be able to read corporate data
when the device is locked. The options are:
On. Turns on the feature and provides the additional protection.
Off, or not configured. Doesn't enable this feature.
Revoke encryption keys on unenroll. Determines whether to revoke a user’s local encryption
 keys from a device when it’s unenrolled from Windows Information Protection. If the encryption
keys are revoked, a user no longer has access to encrypted corporate data. The options are:
On, or not configured (recommended). Revokes local encryption keys from a device
during unenrollment.
Off. Stop local encryption keys from being revoked from a device during unenrollment. For
example if you’re migrating between Mobile Device Management (MDM ) solutions.
Show the enterprise data protection icon. Determines whether the Windows Information
Protection icon overlay appears on corporate files in the Save As and File Explorer views. The
options are:
On. Allows the Windows Information Protection icon overlay to appear on corporate files in
the Save As and File Explorer views. Additionally, for unenlightened but protected apps, the
icon overlay also appears on the app tile and with Managed text on the app name in the Start
menu.
Off, or not configured (recommended). Stops the Windows Information Protection icon
overlay from appearing on corporate files or unenlightened, but protected apps. Not
configured is the default option.
Use Azure RMS for WIP. Determines whether to use Azure Rights Management encryption with
Windows Information Protection.
On. Starts using Azure Rights Management encryption with WIP. By turning this option on,
you can also add a TemplateID GUID to specify who can access the Azure Rights
Management protected files, and for how long. For more info about setting up Azure Rights
management and using a template ID with WIP, see the Choose to set up Azure Rights
Management with WIP section of this topic.
Off, or not configured. Stops using Azure Rights Management encryption with WIP.
Allow Windows Search Indexer to search encrypted files. Determines whether to allow the
Windows Search Indexer to index items that are encrypted, such as WIP protected files.
On. Starts Windows Search Indexer to index encrypted files.
Off, or not configured. Stops Windows Search Indexer from indexing encrypted files.

Choose to set up Azure Rights Management with WIP

WIP can integrate with Microsoft Azure Rights Management to enable secure sharing of files by using removable
drives such as USB drives. For more info about Azure Rights Management, see Microsoft Azure Rights
Management. To integrate Azure Rights Management with WIP, you must already have Azure Rights
Management set up.
To configure WIP to use Azure Rights Management, you must set the AllowAzureRMSForEDP MDM setting to
1 in Microsoft Intune. This setting tells WIP to encrypt files copied to removable drives with Azure Rights
Management, so they can be shared amongst your employees on computers running at least Windows 10, version
1703.
Optionally, if you don’t want everyone in your organization to be able to share your enterprise data, you can set
the RMSTemplateIDForEDP MDM setting to the TemplateID of the Azure Rights Management template used
to encrypt the data. You must make sure to mark the template with the EditRightsData option.
 IMPORTANT
Curly braces -- {} -- are required around the RMS Template ID.

NOTE
For more info about setting the AllowAzureRMSForEDP and the RMSTemplateIDForEDP MDM settings, see the
EnterpriseDataProtection CSP topic. For more info about setting up and using a custom template, see Configuring custom
templates for the Azure Rights Management service topic.

Related topics
How to collect Windows Information Protection (WIP ) audit event logs
Deploy your Windows Information Protection (WIP ) policy
Associate and deploy your Windows Information Protection (WIP ) and VPN policies by using Microsoft
Intune
General guidance and best practices for Windows Information Protection (WIP )
What is Azure Rights Management?
Create and deploy Windows Information Protection (WIP ) app protection policy with Intune and MAM
Intune MAM Without Enrollment
Azure RMS Documentation Update for May 2016

NOTE
Help to make this topic better by providing us with edits, additions, and feedback. For info about how to contribute to this
topic, see Editing Windows IT professional documentation.
 Deploy your Windows Information Protection (WIP)
policy using the Azure portal for Microsoft Intune
10/15/2018 • 2 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later (except Microsoft Azure Rights Management, which is only
available on the desktop)
After you’ve created your Windows Information Protection (WIP ) policy, you'll need to deploy it to your
organization's enrolled devices. Enrollment can be done for business or personal devices, allowing the devices to
use your managed apps and to sync with your managed content and information.
To deploy your WIP policy
1. On the App protection policies pane, click your newly-created policy, click Assignments, and then select
groups to include or exclude from the policy.
2. Choose the group you want your policy to apply to, and then click Select to deploy the policy.
The policy is deployed to the selected users' devices.

NOTE
Help to make this topic better by providing us with edits, additions, and feedback. For info about how to contribute to this
topic, see Editing Windows IT professional documentation.

Related topics
Create a Windows Information Protection (WIP ) policy using Microsoft Intune
Associate and deploy your Windows Information Protection (WIP ) and VPN policies by using Microsoft
Intune
General guidance and best practices for Windows Information Protection (WIP )
 Associate and deploy a VPN policy for Windows
Information Protection (WIP) using the Azure portal
for Microsoft Intune
10/15/2018 • 2 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later (except Microsoft Azure Rights Management, which is only
available on the desktop)
After you've created and deployed your Windows Information Protection (WIP ) policy, you can use Microsoft
Intune to associate and deploy your Virtual Private Network (VPN ) policy, linking it to your WIP policy.

Associate your WIP policy to your VPN policy by using Microsoft

Intune
Follow these steps to associate your WIP policy with your organization's existing VPN policy.
To associate your policies
1. Create your VPN profile. For info about how to do this, see How to configure VPN settings in Microsoft
Intune and How to create custom VPN profiles in Microsoft Intune.
2. Open the Microsoft Intune mobile application management console, click Device configuration, and then
click Create Profile.

3. In the Create Profile blade, type a name for your profile, such as Contoso_VPN_Win10, into the Name
box, add an optional description for your policy into the Description box, select Windows 10 and later
from the Platform dropdown box, select Custom from the Profile type dropdown box, and then click
Configure.
4. In the Custom OMA -URI Settings blade, click Add.
5. In the Add Row blade, type:
Name. Type a name for your setting, such as EDPModeID.
Description. Type an optional description for your setting.
OMA -URI. Type ./Vendor/MSFT/VPNv2/<VPNProfileName>/EDPModeId into the box.
Data type. Select String from the dropdown box
Value. Type your fully-qualified domain that should be used by the OMA-URI setting. For example,
corp.contoso.com.

6. Click OK to save your setting info in the Add Row blade, and then click OK in the Custom OMA -URI
Settings blade to save the setting with your policy.
7. Click Create to create the policy, including your OMA_URI info.

Deploy your VPN policy using Microsoft Intune

After you’ve created your VPN policy, you'll need to deploy it to the same group you deployed your Windows
Information Protection (WIP ) policy.
To deploy your Custom VPN policy
1. On the App policy blade, click your newly-created policy, click User groups from the menu that appears,
and then click Add user group.
A list of user groups, made up of all of the security groups in your Azure Active Directory, appear in the Add
user group blade.
2. Choose the group you want your policy to apply to, and then click Select to deploy the policy.
The policy is deployed to the selected users' devices.

NOTE
Help to make this topic better by providing us with edits, additions, and feedback. For info about how to contribute to this
topic, see Editing Windows IT professional documentation.
 Create a Windows Information Protection (WIP)
policy with MAM using the Azure portal for
Microsoft Intune
10/18/2018 • 30 minutes to read • Edit Online

Applies to:
Windows 10, version 1703 and later
Windows 10 Mobile, version 1703 and later (except Microsoft Azure Rights Management, which is only
available on the desktop)
By using Microsoft Intune with Mobile application management (MAM ), organizations can take advantage of
Azure Active Directory (Azure AD ) and the app protection policy feature to keep employees from logging in with
personal credentials and accessing corporate data. Additionally, MAM solutions can help your enterprise do the
following for mobile apps:
Configure, update, and deploy mobile apps to employees
Control what your employees can do with enterprise data, such as copying, pasting, and saving
Keep enterprise data separate from your employee's personal data
Remove enterprise data from employee's devices
Report on mobile app inventory and track usage

Alternative steps if you already manage devices with MDM

This topic covers creating a Windows Information Protection (WIP ) policy for organizations using a mobile
application management (MAM ) solution to deploy your WIP policy to Intune apps without device enrollment. If
you are already managing devices by using a Mobile Device Management (MDM ) solution, see Create a Windows
Information Protection (WIP ) with enrollment policy using the Azure portal for Microsoft Intune.
If the same user and device are targeted for both MAM -only (without device enrollment) policy and MDM policy,
the MDM policy (with device enrollement) will be applied to devices joined to Azure AD. For personal devices that
are workplace-joined (that is, added by using Settings > Email & accounts > Add a work or school account),
the MAM -only policy will be preferred but it's possible to upgrade the device management to MDM in Settings.
Windows Home edition only supports WIP for MAM -only; upgrading to MDM policy on Home edition will
revoke WIP -protected data access.

Prerequisites to using MAM with Windows Information Protection

(WIP)
Before you can create your WIP policy with MAM, you need to set up your MAM provider.
Additionally, you must have an Azure AD Premium license and be running at least Windows 10, version 1703 on
your device.

IMPORTANT
WIP doesn't support multi-identity. Only one managed identity can exist at a time.
Add a WIP policy
After you’ve set up Intune for your organization, you must create a WIP -specific policy.
To add a WIP policy
1. Open the Azure portal and click the Intune service from the sidebar.
The Microsoft Intune Overview blade appears.
2. Click Client apps, click App protection policies, and then click Add a policy.

3. In the Add a policy blade, fill out the fields:

Name. Type a name (required) for your new policy.
Description. Type an optional description.
Platform. Choose Windows 10 to create your MAM policy for desktop client devices.
Enrollment state. Choose Without enrollment as the enrollment state for your policy.
 IMPORTANT
Choosing Without enrollment only applies for organizations using MAM. If you're using MDM, see Create a
Windows Information Protection (WIP) policy with MDM using the Azure portal for Microsoft Intune.

4. Click Create.
The policy is created and appears in the table on the Client apps - App protection policies blade.

NOTE
Optionally, you can also add your apps and set your settings from the Add a policy blade, but for the purposes of
this documentation, we recommend instead that you create the policy first, and then use the subsequent menus
that become available.

Add apps to your Protected apps list

During the policy-creation process in Intune, you can choose the apps you want to allow, as well as deny, access to
your enterprise data through WIP. Apps included in this list can protect data on behalf of the enterprise and are
restricted from copying or moving enterprise data to unprotected apps.
The steps to add your apps are based on the type of template being applied. You can add a recommended app, a
store app (also known as a Universal Windows Platform (UWP ) app), or a signed Windows desktop app. You can
also import a list of approved apps or add exempt apps.
In addition, you can create an app deny list related to the policy based on an action value. The action can be either
Allow or Deny. When you specify the deny action for an app using the policy, corporate access is denied to the
app.

IMPORTANT
Enlightened apps are expected to prevent enterprise data from going to unprotected network locations and to avoid
encrypting personal data. On the other hand, WIP-unaware apps might not respect the corporate network boundary, and
WIP-unaware apps will encrypt all files they create or modify. This means that they could encrypt personal data and cause
data loss during the revocation process.

Care must be taken to get a support statement from the software provider that their app is safe with WIP before adding it
to your Protected apps list. If you don’t get this statement, it’s possible that you could experience app compatibility issues
due to an app losing the ability to access a necessary file after revocation.

Add a Recommended app to your Protected apps list

For this example, we’re going to add a few recommended apps to the Protected apps list.
To add a recommended app
1. From the Client apps - App protection policies blade, click the name of your policy, and then click
Protected apps from the menu that appears.
The Protected apps blade appears, showing you any apps that are already included in the list for this
policy.

2. From the Protected apps blade, click Add apps.

The Add apps blade appears, showing you all Recommended apps.
3. Select each app you want to access your enterprise data, and then click OK.
The Protected apps blade updates to show you your selected apps.
4. Click Save to save the Protected apps list to your policy.
Add a Store app to your Protected apps list
For this example, we’re going to add Microsoft Power BI, a Windows store app, to the Protected apps list.
To add a Store app
1. From the Client apps - App protection policies blade, click the name of your policy, and then click
Protected apps from the menu that appears.
The Protected apps blade appears, showing you any apps that are already included in the list for this
policy.
2. From the Protected apps blade, click Add apps.
3. On the Add apps blade, click Store apps from the dropdown list.
4. Type the friendly name of the app, the publisher info, and the product name. For this example, the
Publisher is CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US and the
Product name is Microsoft.MicrosoftPowerBIForWindows .
5. After you’ve entered the info into the fields, click OK to add the app to your Protected apps list, and then
click Save to save the Protected apps list to your policy.

NOTE
To add multiple Store apps at the same time, you can click the menu (…) at the end of the app row, and continue to
add more apps. When you’re done, click OK.

Find the Name, Publisher, and Product name for Store apps
If you don't know the publisher or product name for your Store app, you can find them for both desktop devices
and Windows 10 Mobile phones by following these steps.
To find the publisher and product name values for Store apps without installing them
1. Go to the Microsoft Store for Business website, and find your app. For example, Microsoft Power BI.
2. Copy the ID value from the app URL. For example, Microsoft Power BI ID URL is
https://www.microsoft.com/store/p/microsoft-power-bi/9nblgggzlxn1, and you'd copy the ID value,
9nblgggzlxn1 .

3. In a browser, run the Microsoft Store for Business portal web API, to return a JavaScript Object Notation
(JSON ) file that includes the publisher and product name values. For example, run
 https://bspmts.mp.microsoft.com/v1/public/catalog/Retail/Products/9nblgggzlxn1/applockerdata, where
9nblgggzlxn1 is replaced with your ID value.

The API runs and opens a text editor with the app details.

{
"packageIdentityName": "Microsoft.MicrosoftPowerBIForWindows",
"publisherCertificateName": "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond,
S=Washington, C=US"
}

4. Copy the publisherCertificateName value into the Publisher box and copy the packageIdentityName value
into the Name box of the Add apps blade.

IMPORTANT
The JSON file might also return a windowsPhoneLegacyId value for both the Publisher Name and Product Name
boxes. This means that you have an app that’s using a XAP package and that you must set the Product Name as
windowsPhoneLegacyId, and set the Publisher Name as CN= followed by the windowsPhoneLegacyId.

For example:
{
"windowsPhoneLegacyId": "ca05b3ab-f157-450c-8c49-a1f127f5e71d",
}

To find the publisher and product name values for apps installed on Windows 10 mobile phones
1. If you need to add mobile apps that aren't distributed through the Microsoft Store for Business, you must
use the Windows Device Portal feature.

NOTE
Your PC and phone must be on the same wireless network.

2. On the Windows Phone, go to Settings, choose Update & security, and then choose For developers.
3. In the For developers screen, turn on Developer mode, turn on Device Discovery, and then turn on
Device Portal.
4. Copy the URL in the Device Portal area into your device's browser, and then accept the SSL certificate.
5. In the Device discovery area, press Pair, and then enter the PIN into the website from the previous step.
6. On the Apps tab of the website, you can see details for the running apps, including the publisher and
product names.
7. Start the app for which you're looking for the publisher and product name values.
8. Copy the publisherCertificateName value and paste it into the Publisher Name box and the
packageIdentityName value into the Product Name box of Intune.
 IMPORTANT
The JSON file might also return a windowsPhoneLegacyId value for both the Publisher Name and Product Name
boxes. This means that you have an app that’s using a XAP package and that you must set the Product Name as
windowsPhoneLegacyId, and set the Publisher Name as CN= followed by the windowsPhoneLegacyId.

For example:
{
"windowsPhoneLegacyId": "ca05b3ab-f157-450c-8c49-a1f127f5e71d",
}

Add a Desktop app to your Protected apps list

For this example, we’re going to add WordPad, a Desktop app, to the Protected apps list.
To add a Desktop app
1. From the Client apps - App protection policies blade, click the name of your policy, and then click
Protected apps from the menu that appears.
The Protected apps blade appears, showing you any apps that are already included in the list for this
policy.
2. From the Protected apps blade, click Add apps.
3. On the Add apps blade, click Desktop apps from the dropdown list.
The blade changes to show boxes for you to add the following, based on the results you want returned:

FIELD MANAGES

All fields marked as “*” All files signed by any publisher. (Not recommended)

Name A friendly name for your app. You can't use this field by
itself. However, you can use it in conjunction with any of
the other fields.

Publisher (required) only Filling out this field, gives you all files signed by the named
publisher. This might be useful if your company is the
publisher and signer of internal line-of-business apps.

This is a required field and must be filled out whether by

itself or in conjunction with other fields.

Publisher (required) and Product name only If you only fill out these fields, you’ll get all files for the
specified product, signed by the named publisher.

Publisher (required), Product name, and File only If you only fill out these fields, you’ll get any version of the
named file or package for the specified product, signed by
the named publisher.

Publisher (required), Product name, File, and Min version If you only fill out these fields, you’ll get the specified
only version or newer releases of the named file or package for
the specified product, signed by the named publisher.

This option is recommended for enlightened apps that

weren't previously enlightened.
 Publisher (required), Product name, File, and Max version If you only fill out these fields, you’ll get the specified
only version or older releases of the named file or package for
the specified product, signed by the named publisher.

All fields completed If you fill out all fields, you’ll get the specified version of
the named file or package for the specified product,
signed by the named publisher.

4. After you’ve entered the info into the fields, click OK to add the app to your Protected apps list, and then
click Save to save the Protected apps list to your policy.

NOTE
To add multiple Desktop apps at the same time, you can click the menu (…) at the end of the app row, and then
continue to add more apps. When you’re done, click OK.

Find the Publisher and File name for Desktop apps

If you’re unsure about what to include for the publisher, you can run this PowerShell command:

Get-AppLockerFileInformation -Path "<path_of_the_exe>"

Where "<path_of_the_exe>" goes to the location of the app on the device. For example,
Get-AppLockerFileInformation -Path "C:\Program Files\Windows NT\Accessories\wordpad.exe" .
In this example, you'd get the following info:

Path Publisher
---- ---------
%PROGRAMFILES%\WINDOWS NT\ACCESSORIES\WORDPAD.EXE O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US

Where the text, O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US is the publisher name to enter into the
Publisher box and WORDPAD.EXE is the text to enter into the File box.
Import a list of apps to your Protected apps list
For this example, we’re going to add an AppLocker XML file to the Protected apps list. You’ll use this option if
you want to add multiple apps at the same time. For more info about AppLocker, see the AppLocker content.
To create a list of Protected apps using the AppLocker tool
1. Open the Local Security Policy snap-in (SecPol.msc).
2. In the left blade, expand Application Control Policies, expand AppLocker, and then click Packaged App
Rules.

3. Right-click in the right-hand blade, and then click Create New Rule.
The Create Packaged app Rules wizard appears.
4. On the Before You Begin page, click Next.

5. On the Permissions page, make sure the Action is set to Allow and the User or group is set to
Everyone, and then click Next.
6. On the Publisher page, click Select from the Use an installed packaged app as a reference area.

7. In the Select applications box, pick the app that you want to use as the reference for your rule, and then
click OK. For this example, we’re using Microsoft Dynamics 365.
 8. On the updated Publisher page, click Create.

9. Click No in the dialog box that appears, asking if you want to create the default rules. You must not create
default rules for your WIP policy.

10. Review the Local Security Policy snap-in to make sure your rule is correct.
11. In the left blade, right-click on AppLocker, and then click Export policy.
The Export policy box opens, letting you export and save your new policy as XML.

12. In the Export policy box, browse to where the policy should be stored, give the policy a name, and then
click Save.
The policy is saved and you’ll see a message that says 1 rule was exported from the policy.
Example XML file
This is the XML file that AppLocker creates for Microsoft Dynamics 365.
 <?xml version="1.0"?>
<AppLockerPolicy Version="1">
<RuleCollection EnforcementMode="NotConfigured" Type="Appx">
<FilePublisherRule Action="Allow" UserOrGroupSid="S-1-1-0" Description=""
Name="Microsoft.MicrosoftDynamicsCRMforWindows10, version 3.2.0.0 and above, from Microsoft
Corporation" Id="3da34ed9-aec6-4239-88ba-0afdce252ab4">
<Conditions>
<FilePublisherCondition BinaryName="*"
ProductName="Microsoft.MicrosoftDynamicsCRMforWindows10" PublisherName="CN=Microsoft Corporation,
O=Microsoft Corporation, L=Redmond, S=Washington, C=US">
<BinaryVersionRange HighSection="*" LowSection="3.2.0.0"/>
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
</RuleCollection>
<RuleCollection EnforcementMode="NotConfigured" Type="Dll"/>
<RuleCollection EnforcementMode="NotConfigured" Type="Exe"/>
<RuleCollection EnforcementMode="NotConfigured" Type="Msi"/>
<RuleCollection EnforcementMode="NotConfigured" Type="Script"/>
</AppLockerPolicy>

13. After you’ve created your XML file, you need to import it by using Microsoft Intune.
To import your list of Protected apps using Microsoft Intune
1. From the Protected apps area, click Import apps.
The blade changes to let you add your import file.

2. Browse to your exported AppLocker policy file, and then click Open.
The file imports and the apps are added to your Allowed app list.
Add exempt apps to your policy
If you're running into compatibility issues where your app is incompatible with WIP, but still needs to be used with
enterprise data, you can exempt the app from the WIP restrictions. This means that your apps won't include auto-
encryption or tagging and won't honor your network restrictions. It also means that your exempted apps might
leak.
To exempt a Store app, a Desktop app, or an AppLocker policy file from the Protected apps list
1. From the App policy blade, click the name of your policy, and then click Exempt apps from the menu that
appears.
The Exempt apps blade appears, showing you any apps that are already included in the list for this policy.
2. From the Exempt apps blade, click Add apps.
Be aware that when you exempt apps, they’re allowed to bypass the WIP restrictions and access your
corporate data. To allow apps, see the Add app rules to your policy section of this topic.
3. Fill out the rest of the app info, based on the type of app you’re adding:
Recommended app. Follow the instructions in the Add a Recommended app to your Protected
 apps list section of this topic.
Store app. Follow the instructions in the Add a Store app to your Protected apps list section of this
topic.
Desktop app. Follow the instructions in the Add a Desktop app to your Protected apps list section
of this topic.
AppLocker policy file. Follow the instructions to create your app list in the Import a list of apps to
your Protected apps list section of this topic, using a list of exempted apps.
4. Click OK.

Manage your Required settings

In the Required settings blade you must pick your Windows Information Protection mode and you can review or
change your Corporate identity.
Manage the WIP protection mode for your enterprise data
After you've added the apps you want to protect with WIP, you'll need to apply a management and protection
mode.
We recommend that you start with Silent or Allow Overrides while verifying with a small group that you have
the right apps on your allowed apps list. After you're done, you can change to your final enforcement policy,
Block.

NOTE
For info about how to collect your audit log files, see How to collect Windows Information Protection (WIP) audit event logs.

To add your protection mode

1. From the Client apps - App protection policies blade, click the name of your policy, and then click
Required settings from the menu that appears.
The Required settings blade appears.

MODE DESCRIPTION
 MODE DESCRIPTION

Block WIP looks for inappropriate data sharing practices and

stops the employee from completing the action. This can
include sharing info across non-enterprise-protected apps
in addition to sharing enterprise data between other
people and devices outside of your enterprise.

Allow Overrides WIP looks for inappropriate data sharing, warning

employees if they do something deemed potentially
unsafe. However, this management mode lets the
employee override the policy and share the data, logging
the action to your audit log. For info about how to collect
your audit log files, see How to collect Windows
Information Protection (WIP) audit event logs.

Silent WIP runs silently, logging inappropriate data sharing,

without blocking anything that would’ve been prompted
for employee interaction while in Allow Override mode.
Unallowed actions, like apps inappropriately trying to
access a network resource or WIP-protected data, are still
stopped.

Off (not recommended) WIP is turned off and doesn't help to protect or audit your
data.

After you turn off WIP, an attempt is made to decrypt any

WIP-tagged files on the locally attached drives. Be aware
that your previous decryption and policy info isn’t
automatically reapplied if you turn WIP protection back
on.

2. Click Save.
Define your enterprise -managed corporate identity
Corporate identity, usually expressed as your primary Internet domain (for example, contoso.com), helps to
identify and tag your corporate data from apps you’ve marked as protected by WIP. For example, emails using
contoso.com are identified as being corporate and are restricted by your Windows Information Protection policies.
Starting with Windows 10, version 1703, Intune automatically determines your corporate identity and adds it to
the Corporate identity field.
To change your corporate identity
1. From the Client apps - App protection policies blade, click the name of your policy, and then click
Required settings from the menu that appears.
The Required settings blade appears.
2. If the auto-defined identity isn’t correct, you can change the info in the Corporate identity field. If you
need to add additional domains, for example your email domains, you can do it in the Advanced settings
area.
Manage your Advanced settings
In the Advanced settings blade you must specify where apps can access your corporate data, upload a Data
Recovery Agent (DRA) certificate, and set several optional data protection and access settings.
Choose where apps can access enterprise data
After you've added a protection mode to your apps, you'll need to decide where those apps can access enterprise
data on your network.
Intune will add SharePoint sites that are discovered through the Graph API. You must add other network
locations. This area applies to any network endpoint device that gets an IP address in your enterprise’s range and
is also bound to one of your enterprise domains, including SMB shares. Local file system locations should just
maintain encryption (for example, on local NTFS, FAT, ExFAT).

IMPORTANT
Every WIP policy should include policy that defines your enterprise network locations.
Classless Inter-Domain Routing (CIDR) notation isn’t supported for WIP configurations.

To define where your allowed apps can find and send enterprise data on you network
1. From the Client apps - App protection policies blade, click the name of your policy, and then click
Advanced settings from the menu that appears.
The Advanced settings blade appears.
2. Click Add network boundary from the Network perimeter area.
The Add network boundary blade appears.
3. Select the type of network boundary to add from the Boundary type box.
4. Type a name for your boundary into the Name box, add your values to the Value box, based on the
following options, and then click OK.

BOUNDARY TYPE VALUE FORMAT DESCRIPTION

Cloud Resources With proxy: Specify the cloud resources to be
contoso.sharepoint.com,contoso.inte treated as corporate and protected
rnalproxy1.com| by WIP.
contoso.visualstudio.com,contoso.int
ernalproxy2.com For each cloud resource, you may
also optionally specify a proxy server
Without proxy: from your Internal proxy servers list
contoso.sharepoint.com|contoso.visu to route traffic for this cloud
alstudio.com resource. Be aware that all traffic
routed through your Internal proxy
servers is considered enterprise.

If you have multiple resources, you

must separate them using the "|"
delimiter. If you don’t use proxy
servers, you must also include the ","
delimiter just before the "|". For
example:
URL <,proxy>|URL <,proxy> .

Important
In some cases, such as when an app
connects directly to a cloud resource
through an IP address, Windows
can’t tell whether it’s attempting to
connect to an enterprise cloud
resource or to a personal site. In this
case, Windows blocks the connection
by default. To stop Windows from
automatically blocking these
connections, you can add the
/*AppCompat*/ string to the
setting. For example:
URL <,proxy>|URL
<,proxy>|/*AppCompat*/
.

When using this string, we

recommend that you also turn on
Azure Active Directory Conditional
Access, using the Domain joined or
marked as compliant option, which
blocks apps from accessing any
enterprise cloud resources that are
protected by conditional access.

Network domain names corp.contoso.com,region.contoso.co Starting with Windows 10, version

m 1703, this field is optional.

Specify the DNS suffixes used in your

environment. All traffic to the fully-
qualified domains appearing in this
list will be protected.

If you have multiple resources, you

must separate them using the ","
delimiter.
Proxy servers proxy.contoso.com:80;proxy2.contos Specify the proxy servers your
o.com:443 devices will go through to reach your
cloud resources. Using this server
type indicates that the cloud
resources you’re connecting to are
enterprise resources.

This list shouldn’t include any servers

listed in your Internal proxy servers
list. Internal proxy servers must be
used only for WIP-protected
(enterprise) traffic.

If you have multiple resources, you

must separate them using the ";"
delimiter.

Internal proxy servers contoso.internalproxy1.com;contoso.i Specify the internal proxy servers

nternalproxy2.com your devices will go through to reach
your cloud resources. Using this
server type indicates that the cloud
resources you’re connecting to are
enterprise resources.

This list shouldn’t include any servers

listed in your Proxy servers list. Proxy
servers must be used only for non-
WIP-protected (non-enterprise)
traffic.

If you have multiple resources, you

must separate them using the ";"
delimiter.

IPv4 ranges Starting IPv4 Address: 3.4.0.1 Starting with Windows 10, version
Ending IPv4 Address: 3.4.255.254 1703, this field is optional.
Custom URI: 3.4.0.1-3.4.255.254,
10.0.0.1-10.255.255.254 Specify the addresses for a valid IPv4
value range within your intranet.
These addresses, used with your
Network domain names, define your
corporate network boundaries.

If you have multiple ranges, you

must separate them using the ","
delimiter.

IPv6 ranges Starting IPv6 Address: 2a01:110:: Starting with Windows 10, version
Ending IPv6 Address: 1703, this field is optional.
2a01:110:7fff:ffff:ffff:ffff:ffff:ffff
Custom URI: Specify the addresses for a valid IPv6
2a01:110:7fff:ffff:ffff:ffff:ffff:ffff, value range within your intranet.
fd00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff These addresses, used with your
Network domain names, define your
corporate network boundaries.

If you have multiple ranges, you

must separate them using the ","
delimiter.
 Neutral resources sts.contoso.com,sts.contoso2.com Specify your authentication
redirection endpoints for your
company.

These locations are considered

enterprise or personal, based on the
context of the connection before the
redirection.

If you have multiple resources, you

must separate them using the ","
delimiter.

5. Repeat steps 1-4 to add any additional network boundaries.

6. Decide if you want to Windows to look for additional network settings:

Enterprise Proxy Servers list is authoritative (do not auto-detect). Click On for Windows to
treat the proxy servers you specified in the network boundary definition as the complete list of proxy
servers available on your network.Click Off and Windows searches for additional proxy servers in
your immediate network.
Enterprise IP Ranges list is authoritative (do not auto-detect). Click On for Windows to treat
the IP ranges you specified in the network boundary definition as the complete list of IP ranges
available on your network. Click Off and Windows searches for additional IP ranges on any domain-
joined devices connected to your network.
Upload your Data Recovery Agent (DRA ) certificate
After you create and deploy your WIP policy to your employees, Windows begins to encrypt your corporate data
on the employees’ local device drive. If somehow the employees’ local encryption keys get lost or revoked, the
encrypted data can become unrecoverable. To help avoid this possibility, the Data Recovery Agent (DRA)
certificate lets Windows use an included public key to encrypt the local data while you maintain the private key
that can unencrypt the data.

IMPORTANT
Using a DRA certificate isn’t mandatory. However, we strongly recommend it. For more info about how to find and export
your data recovery certificate, see the Data Recovery and Encrypting File System (EFS) topic. For more info about creating
and verifying your EFS DRA certificate, see the Create and verify an Encrypting File System (EFS) Data Recovery Agent (DRA)
certificate topic.

To upload your DRA certificate

1. From the Client apps - App protection policies blade, click the name of your policy, and then click
Advanced settings from the menu that appears.
The Advanced settings blade appears.
2. In the Upload a Data Recovery Agent (DRA ) certificate to allow recovery of encrypted data box,
click Browse to add a data recovery certificate for your policy.
Choose your optional WIP-related settings
After you've decided where your protected apps can access enterprise data on your network, you’ll be asked to
decide if you want to add any optional WIP settings.
To set your optional settings
1. From the Client apps - App protection policies blade, click the name of your policy, and then click
Advanced settings from the menu that appears.
The Advanced settings blade appears.
2. Choose to set any or all optional settings:

Prevent corporate data from being accessed by apps when the device is locked. Applies
only to Windows 10 Mobile. Determines whether to encrypt enterprise data using a key that's
protected by an employee's PIN code on a locked device. Apps won't be able to read corporate data
when the device is locked. The options are:
On (recommended). Turns on the feature and provides the additional protection.
Off Doesn't enable this feature.
Revoke encryption keys on unenroll. Determines whether to revoke a user’s local encryption
keys from a device when it’s unenrolled from Windows Information Protection. If the encryption
keys are revoked, a user no longer has access to encrypted corporate data. The options are:
On (recommended). Revokes local encryption keys from a device during unenrollment.
Off. Stop local encryption keys from being revoked from a device during unenrollment. For
example if you’re migrating between Mobile Device Management (MDM ) solutions.
Revoke access to protected data when the device enrolls to MDM. Determines whether to
revoke a user's WIP keys when a device is upgraded from MAM to a higher-security MDM solution.
The options are:
On. Revokes the encryption keys from a device when it's upgraded from MAM to MDM.
Off. Encryption keys aren't removed and the user can continue to access protected files. This
 is the recommended setting if the MDM service uses the same WIP EnterpriseID value as the
MAM service.
Show the enterprise data protection icon. Determines whether an icon appears on corporate
files in the Save As and File Explorer views. The options are:
On. Allows an icon to appear on corporate files in the Save As and File Explorer views.
Additionally, for unenlightened but allowed apps, the icon also appears on the app tile and
with Managed text on the app name in the Start menu.
Off (recommended). Stops the icon from appearing on corporate files or unenlightened, but
allowed apps. By default, this is turned off.
Use Azure RMS for WIP. Determines whether to use Azure Rights Management encryption with
Windows Information Protection. The options are:
On. Starts using Azure Rights Management encryption with WIP. By turning this option on,
you can also add a TemplateID GUID to specify who can access the Azure Rights
Management protected files, and for how long. For more info about setting up Azure Rights
management and using a template ID with WIP, see the Choose to set up Azure Rights
Management with WIP section of this topic.
Off. Stops using Azure Rights Management encryption with WIP.
MDM discovery URL. Lets the Windows Settings > Accounts > Access work or school sign-in
offer an Upgrade to MDM link. Additionally, this lets you switch to another MDM provider, so that
Microsoft Intune can manage MAM, while the new MDM provider manages the MDM devices. By
default, this is specified to use Microsoft Intune.
Choose to set up Azure Rights Management with WIP
WIP can integrate with Microsoft Azure Rights Management to enable secure sharing of files by using removable
drives such as USB drives. For more info about Azure Rights Management, see Microsoft Azure Rights
Management. To integrate Azure Rights Management with WIP, you must already have Azure Rights
Management set up.
To configure WIP to use Azure Rights Management, you must set the AllowAzureRMSForEDP MDM setting to
1 in Microsoft Intune. This setting tells WIP to encrypt files copied to removable drives with Azure Rights
Management, so they can be shared amongst your employees on computers running at least Windows 10,
version 1703.
Optionally, if you don’t want everyone in your organization to be able to share your enterprise data, you can set
the RMSTemplateIDForEDP MDM setting to the TemplateID of the Azure Rights Management template used
to encrypt the data. You must make sure to mark the template with the EditRightsData option.

IMPORTANT
Curly braces -- {} -- are required around the RMS Template ID.

NOTE
For more info about setting the AllowAzureRMSForEDP and the RMSTemplateIDForEDP MDM settings, see the
EnterpriseDataProtection CSP topic. For more info about setting up and using a custom template, see Configuring custom
templates for the Azure Rights Management service topic.

Choose whether to use and configure Windows Hello for Business

You can turn on Windows Hello for Business, letting your employees use it as a sign-in method for their devices.
To turn on and configure Windows Hello for Business
1. From the Client apps - App protection policies blade, click the name of your policy, and then click
Advanced settings from the menu that appears.
The Advanced settings blade appears.
2. Choose to turn on and configure the Windows Hello for Business settings:

Use Windows Hello for Business as a method for signing into Windows. Turns on Windows
Hello for Business. The options are:
On. Turns on Windows Hello For Business for anyone assigned to this policy.
Off. Turns off Windows Hello for Business.
Set the minimum number of characters required for the PIN. Enter a numerical value (4-127
characters) for how many characters must be used to create a valid PIN. Default is 4 characters.
Configure the use of uppercase letters in the Windows Hello for Business PIN. Lets you
decide whether uppercase letters can be used in a valid PIN. The options are:
Allow the use of uppercase letters in PIN. Lets an employee use uppercase letters in a
valid PIN.
Require the use of at least one uppercase letter in PIN. Requires an employee to use at
least 1 uppercase letter in a valid PIN.
Do not allow the use of uppercase letters in PIN. Prevents an employee from using
uppercase letters in a valid PIN.
Configure the use of lowercase letters in the Windows Hello for Business PIN. Lets you
decide whether lowercase letters can be used in a valid PIN. The options are:
Allow the use of lowercase letters in PIN. Lets an employee use lowercase letters in a
valid PIN.
Require the use of at least one lowercase letter in PIN. Requires an employee to use at
least 1 lowercase letter in a valid PIN.
Do not allow the use of lowercase letters in PIN. Prevents an employee from using
lowercase letters in a valid PIN.
Configure the use of special characters in the Windows Hello for Business PIN. Lets you
decide whether special characters can be used in a valid PIN. The options are:
Allow the use of special characters in PIN. Lets an employee use special characters in a
valid PIN.
Require the use of at least one special character in PIN. Requires an employee to use at
least 1 special character in a valid PIN.
Do not allow the use of special characters in PIN. Prevents an employee from using
special characters in a valid PIN.
Specify the period of time (in days) that a PIN can be used before the system requires the
user to change it. Enter a numerical value (0-730 days) for how many days can pass before a PIN
must be changed. If you enter a value of 0, the PIN never expires.
Specify the number of past PINs that can be associated to a user account that can't be
reused. Enter a numerical value (0-50 days) for how many days can pass before an employee can
reuse a previous PIN. If you enter a value of 0, a PINs can be reused immediately and past PINs
aren't stored.

NOTE
PIN history is not preserved through a PIN reset.

Number of authentication failures allowed before the device will be wiped. Enter a
numerical value for how many times the PIN can be incorrectly entered before wiping the device of
corporate data. If you enter a value of 0, the device is never wiped, regardless of the number of
incorrect PIN entries.
This setting has different behavior for mobile devices and desktops.
On mobile devices. When an employee reaches the value set here, the device is wiped of
corporate data.
On desktop devices. When an employee reaches the value set here, the desktop is put into
BitLocker recovery mode, instead of being wiped. You must have BitLocker installed on the
device or this setting is ignored.
Maximum amount of time (in minutes) allowed after the device is idle that will cause the
device to become PIN or password locked. Enter a numerical value for how many days can pass
before a PIN must be changed. If you enter a value of 0, the device never becomes PIN or password
locked while idle.
 NOTE
You can set this value to be anything; however, it can't be longer than the time specified by the Settings app.
If you exceed the maximum timeout value, this setting is ignored.

Deploy your policy

After you’ve created your policy, you'll need to deploy it to your employees. MAM is deployed to users and not
devices.
To deploy your policy
1. On the Client apps - App protection policies pane, click your newly-created policy, click Assignments
from the menu that appears, and then click Select groups.
A list of user groups, made up of all of the security groups in your Azure Active Directory, appear in the
Add user group pane.
2. Choose the group you want your policy to apply to, and then click Select to deploy the policy.
The policy is deployed to the selected group.

Related topics
Implement server-side support for mobile application management on Windows
Microsoft Intune - Mobile Application Management (MAM ) standalone blog post
MAM -supported apps
General guidance and best practices for Windows Information Protection (WIP )
Deploy your Windows Information Protection (WIP ) policy
How to collect Windows Information Protection (WIP ) audit event logs
 Create a Windows Information Protection (WIP)
policy using System Center Configuration Manager
7/9/2018 • 2 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later
System Center Configuration Manager helps you create and deploy your enterprise data protection (WIP ) policy,
including letting you choose your protected apps, your WIP -protection level, and how to find enterprise data on
the network.

In this section
TOPIC DESCRIPTION

Create and deploy a Windows Information Protection (WIP) System Center Configuration Manager helps you create and
policy using System Center Configuration Manager deploy your WIP policy, including letting you choose your
protected apps, your WIP-protection level, and how to find
enterprise data on the network.

Create and verify an Encrypting File System (EFS) Data Steps to create, verify, and perform a quick recovery using a
Recovery Agent (DRA) certificate Encrypting File System (EFS) Data Recovery Agent (DRA)
certificate.

Determine the Enterprise Context of an app running in Use the Task Manager to determine whether an app is
Windows Information Protection (WIP) considered work, personal or exempt by Windows Information
Protection (WIP).
 Create and deploy a Windows Information
Protection (WIP) policy using System Center
Configuration Manager
8/8/2018 • 21 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later
System Center Configuration Manager
System Center Configuration Manager helps you create and deploy your Windows Information Protection (WIP )
policy, including letting you choose your protected apps, your WIP -protection mode, and how to find enterprise
data on the network.

Add a WIP policy

After you’ve installed and set up System Center Configuration Manager for your organization, you must create a
configuration item for WIP, which in turn becomes your WIP policy.
To create a configuration item for WIP
1. Open the System Center Configuration Manager console, click the Assets and Compliance node, expand
the Overview node, expand the Compliance Settings node, and then expand the Configuration Items
node.

2. Click the Create Configuration Item button.

 The Create Configuration Item Wizard starts.

3. On the General Information screen, type a name (required) and an optional description for your policy
into the Name and Description boxes.
4. In the Specify the type of configuration item you want to create area, pick the option that represents
whether you use System Center Configuration Manager for device management, and then click Next.
Settings for devices managed with the Configuration Manager client: Windows 10
-OR -
Settings for devices managed without the Configuration Manager client: Windows 8.1 and
Windows 10
5. On the Supported Platforms screen, click the Windows 10 box, and then click Next.
6. On the Device Settings screen, click Windows Information Protection, and then click Next.
The Configure Windows Information Protection settings page appears, where you'll configure your policy
for your organization.

Add app rules to your policy

During the policy-creation process in System Center Configuration Manager, you can choose the apps you want
to give access to your enterprise data through WIP. Apps included in this list can protect data on behalf of the
enterprise and are restricted from copying or moving enterprise data to unprotected apps.
The steps to add your app rules are based on the type of rule template being applied. You can add a store app
(also known as a Universal Windows Platform (UWP ) app), a signed Windows desktop app, or an AppLocker
policy file.

IMPORTANT
Enlightened apps are expected to prevent enterprise data from going to unprotected network locations and to avoid
encrypting personal data. On the other hand, WIP-unaware apps might not respect the corporate network boundary, and
WIP-unaware apps will encrypt all files they create or modify. This means that they could encrypt personal data and cause
data loss during the revocation process.
Care must be taken to get a support statement from the software provider that their app is safe with WIP before adding it
to your App rules list. If you don’t get this statement, it’s possible that you could experience app compat issues due to an
app losing the ability to access a necessary file after revocation.

Add a store app rule to your policy

For this example, we’re going to add Microsoft OneNote, a store app, to the App Rules list.
To add a store app
1. From the App rules area, click Add.
The Add app rule box appears.

2. Add a friendly name for your app into the Title box. In this example, it’s Microsoft OneNote.
3. Click Allow from the Windows Information Protection mode drop-down list.
Allow turns on WIP, helping to protect that app’s corporate data through the enforcement of WIP
restrictions. If you want to exempt an app, you can follow the steps in the Exempt apps from WIP
restrictions section.
4. Pick Store App from the Rule template drop-down list.
The box changes to show the store app rule options.
5. Type the name of the app and the name of its publisher, and then click OK. For this UWP app example, the
Publisher is CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US and the
Product name is Microsoft.Office.OneNote .

If you don't know the publisher or product name, you can find them for both desktop devices and Windows 10
Mobile phones by following these steps.
To find the Publisher and Product Name values for Store apps without installing them
1. Go to the Microsoft Store for Business website, and find your app. For example, Microsoft OneNote.

NOTE
If your app is already installed on desktop devices, you can use the AppLocker local security policy MMC snap-in to
gather the info for adding the app to the protected apps list. For info about how to do this, see the steps in the Add
an AppLocker policy file section.

2. Copy the ID value from the app URL. For example, Microsoft OneNote's ID URL is
https://www.microsoft.com/store/apps/onenote/9wzdncrfhvjl, and you'd copy the ID value, 9wzdncrfhvjl .
3. In a browser, run the Store for Business portal web API, to return a JavaScript Object Notation (JSON ) file
that includes the publisher and product name values. For example, run
https://bspmts.mp.microsoft.com/v1/public/catalog/Retail/Products/9wzdncrfhvjl/applockerdata, where
9wzdncrfhvjl is replaced with your ID value.

The API runs and opens a text editor with the app details.

{
"packageIdentityName": "Microsoft.Office.OneNote",
"publisherCertificateName": "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond,
S=Washington, C=US"
}

4. Copy the publisherCertificateName value and paste them into the Publisher Name box, copy the
packageIdentityName value into the Product Name box of Intune.

IMPORTANT
The JSON file might also return a windowsPhoneLegacyId value for both the Publisher Name and Product Name
boxes. This means that you have an app that’s using a XAP package and that you must set the Product Name as
windowsPhoneLegacyId , and set the Publisher Name as “CN=” followed by the windowsPhoneLegacyId .

For example:

{
"windowsPhoneLegacyId": "ca05b3ab-f157-450c-8c49-a1f127f5e71d",
}

To find the Publisher and Product Name values for apps installed on Windows 10 mobile phones
1. If you need to add mobile apps that aren't distributed through the Store for Business, you must use the
Windows Device Portal feature.

NOTE
Your PC and phone must be on the same wireless network.

2. On the Windows Phone, go to Settings, choose Update & security, and then choose For developers.
3. On the For developers screen, turn on Developer mode, turn on Device Discovery, and then turn on
Device Portal.
4. Copy the URL in the Device Portal area into your device's browser, and then accept the SSL certificate.
5. In the Device discovery area, press Pair, and then enter the PIN into the website from the previous step.
6. On the Apps tab of the website, you can see details for the running apps, including the publisher and
product names.
7. Start the app for which you're looking for the publisher and product name values.
8. Copy the publisherCertificateName value and paste it into the Publisher Name box and the
packageIdentityName value into the Product Name box of Intune.

IMPORTANT
The JSON file might also return a windowsPhoneLegacyId value for both the Publisher Name and Product Name
boxes. This means that you have an app that’s using a XAP package and that you must set the Product Name as
windowsPhoneLegacyId , and set the Publisher Name as “CN=” followed by the windowsPhoneLegacyId . For
example:

{
"windowsPhoneLegacyId": "ca05b3ab-f157-450c-8c49-a1f127f5e71d",
}

Add a desktop app rule to your policy

For this example, we’re going to add Internet Explorer, a desktop app, to the App Rules list.
To add a desktop app to your policy
1. From the App rules area, click Add.
The Add app rule box appears.
2. Add a friendly name for your app into the Title box. In this example, it’s Internet Explorer.
3. Click Allow from the Windows Information Protection mode drop-down list.
Allow turns on WIP, helping to protect that app’s corporate data through the enforcement of WIP
restrictions. If you want to exempt an app, you can follow the steps in the Exempt apps from WIP
restrictions section.
4. Pick Desktop App from the Rule template drop-down list.
The box changes to show the desktop app rule options.
5. Pick the options you want to include for the app rule (see table), and then click OK.

OPTION MANAGES

All fields left as “*” All files signed by any publisher. (Not recommended.)

Publisher selected All files signed by the named publisher.

This might be useful if your company is the publisher
and signer of internal line-of-business apps.

Publisher and Product Name selected All files for the specified product, signed by the named
publisher.
 Publisher, Product Name, and Binary name selected Any version of the named file or package for the specified
product, signed by the named publisher.

Publisher, Product Name, Binary name, and File Specified version or newer releases of the named file or
Version, and above, selected package for the specified product, signed by the named
publisher.
This option is recommended for enlightened apps
that weren't previously enlightened.

Publisher, Product Name, Binary name, and File Specified version or older releases of the named file or
Version, And below selected package for the specified product, signed by the named
publisher.

Publisher, Product Name, Binary name, and File Specified version of the named file or package for the
Version, Exactly selected specified product, signed by the named publisher.

If you’re unsure about what to include for the publisher, you can run this PowerShell command:

Get-AppLockerFileInformation -Path "<path of the exe>"

Where "<path of the exe>" goes to the location of the app on the device. For example,
Get-AppLockerFileInformation -Path "C:\Program Files\Internet Explorer\iexplore.exe" .

In this example, you'd get the following info:

Path Publisher
---- ---------
%PROGRAMFILES%\INTERNET EXPLORER\IEXPLORE.EXE O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\INTERNET
EXPLOR...

Where the text, O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US is the publisher name to enter in the
Publisher Name box.
Add an AppLocker policy file
For this example, we’re going to add an AppLocker XML file to the App Rules list. You’ll use this option if you
want to add multiple apps at the same time. For more info about AppLocker, see the AppLocker content.
To create an app rule and xml file using the AppLocker tool
1. Open the Local Security Policy snap-in (SecPol.msc).
2. In the left pane, expand Application Control Policies, expand AppLocker, and then click Packaged App
Rules.
3. Right-click in the right-hand pane, and then click Create New Rule.
The Create Packaged app Rules wizard appears.
4. On the Before You Begin page, click Next.
5. On the Permissions page, make sure the Action is set to Allow and the User or group is set to
Everyone, and then click Next.

6. On the Publisher page, click Select from the Use an installed packaged app as a reference area.
7. In the Select applications box, pick the app that you want to use as the reference for your rule, and then
click OK. For this example, we’re using Microsoft Photos.

8. On the updated Publisher page, click Create.

 9. Review the Local Security Policy snap-in to make sure your rule is correct.

10. In the left pane, right-click on AppLocker, and then click Export policy.
The Export policy box opens, letting you export and save your new policy as XML.
11. In the Export policy box, browse to where the policy should be stored, give the policy a name, and then
click Save.
The policy is saved and you’ll see a message that says 1 rule was exported from the policy.
Example XML file
This is the XML file that AppLocker creates for Microsoft Photos.

<AppLockerPolicy Version="1">
<RuleCollection Type="Exe" EnforcementMode="NotConfigured" />
<RuleCollection Type ="Msi" EnforcementMode="NotConfigured" />
<RuleCollection Type ="Script" EnforcementMode="NotConfigured" />
<RuleCollection Type ="Dll" EnforcementMode="NotConfigured" />
<RuleCollection Type ="Appx" EnforcementMode="NotConfigured">
<FilePublisherRule Id="5e0c752b-5921-4f72-8146-80ad5f582110" Name="Microsoft.Windows.Photos,
version 16.526.0.0 and above, from Microsoft Corporation" Description="" UserOrGroupSid="S-1-1-0"
Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="CN=Microsoft Corporation, O=Microsoft
Corporation, L=Redmond, S=Washington, C=US" ProductName="Microsoft.Windows.Photos" BinaryName="*">
<BinaryVersionRange LowSection="16.526.0.0" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
</RuleCollection>
</AppLockerPolicy>

12. After you’ve created your XML file, you need to import it by using System Center Configuration Manager.
To import your Applocker policy file app rule using System Center Configuration Manager
1. From the App rules area, click Add.
The Add app rule box appears.
2. Add a friendly name for your app into the Title box. In this example, it’s Allowed app list.
3. Click Allow from the Windows Information Protection mode drop-down list.
Allow turns on WIP, helping to protect that app’s corporate data through the enforcement of WIP
restrictions. If you want to exempt an app, you can follow the steps in the Exempt apps from WIP
restrictions section.
4. Pick the AppLocker policy file from the Rule template drop-down list.
The box changes to let you import your AppLocker XML policy file.
5. Click the ellipsis (...) to browse for your AppLocker XML file, click Open, and then click OK to close the Add
app rule box.
The file is imported and the apps are added to your App Rules list.
Exempt apps from WIP restrictions
If you're running into compatibility issues where your app is incompatible with WIP, but still needs to be used with
enterprise data, you can exempt the app from the WIP restrictions. This means that your apps won't include auto-
encryption or tagging and won't honor your network restrictions. It also means that your exempted apps might
leak.
To exempt a store app, a desktop app, or an AppLocker policy file app rule
1. From the App rules area, click Add.
The Add app rule box appears.
2. Add a friendly name for your app into the Title box. In this example, it’s Exempt apps list.
3. Click Exempt from the Windows Information Protection mode drop-down list.
Be aware that when you exempt apps, they’re allowed to bypass the WIP restrictions and access your
corporate data. To allow apps, see the Add app rules to your policy section of this topic.
4. Fill out the rest of the app rule info, based on the type of rule you’re adding:
Store app. Follow the Publisher and Product name instructions in the Add a store app rule to
your policy section of this topic.
Desktop app. Follow the Publisher, Product name, Binary name, and Version instructions in
the Add a desktop app rule to your policy section of this topic.
AppLocker policy file. Follow the Import instructions in the Add an AppLocker policy file section
of this topic, using a list of exempted apps.
5. Click OK.

Manage the WIP-protection level for your enterprise data

After you've added the apps you want to protect with WIP, you'll need to apply a management and protection
mode.
We recommend that you start with Silent or Override while verifying with a small group that you have the right
apps on your protected apps list. After you're done, you can change to your final enforcement policy, either
Override or Block.

NOTE
For info about how to collect your audit log files, see How to collect Windows Information Protection (WIP) audit event logs.

MODE DESCRIPTION

Block WIP looks for inappropriate data sharing practices and stops
the employee from completing the action. This can include
sharing info across non-enterprise-protected apps in addition
to sharing enterprise data between other people and devices
outside of your enterprise.

Override WIP looks for inappropriate data sharing, warning employees

if they do something deemed potentially unsafe. However,
this management mode lets the employee override the policy
and share the data, logging the action to your audit log.

Silent WIP runs silently, logging inappropriate data sharing, without

blocking anything that would’ve been prompted for employee
interaction while in Override mode. Unallowed actions, like
apps inappropriately trying to access a network resource or
WIP-protected data, are still blocked.
 MODE DESCRIPTION

Off (not recommended) WIP is turned off and doesn't help to protect or audit your
data.
After you turn off WIP, an attempt is made to decrypt
any WIP-tagged files on the locally attached drives. Be
aware that your previous decryption and policy info isn’t
automatically reapplied if you turn WIP protection back
on.

Define your enterprise-managed identity domains

Corporate identity, usually expressed as your primary internet domain (for example, contoso.com), helps to
identify and tag your corporate data from apps you’ve marked as protected by WIP. For example, emails using
contoso.com are identified as being corporate and are restricted by your Windows Information Protection policies.
You can specify multiple domains owned by your enterprise by separating them with the "|" character. For
example, (contoso.com|newcontoso.com). With multiple domains, the first one is designated as your corporate
identity and all of the additional ones as being owned by the first one. We strongly recommend that you include
all of your email address domains in this list.
To add your corporate identity
Type the name of your corporate identity into the Corporate identity field. For example, contoso.com or
 contoso.com|newcontoso.com .

Choose where apps can access enterprise data

After you've added a protection mode to your apps, you'll need to decide where those apps can access enterprise
data on your network.
There are no default locations included with WIP, you must add each of your network locations. This area applies
to any network endpoint device that gets an IP address in your enterprise’s range and is also bound to one of your
enterprise domains, including SMB shares. Local file system locations should just maintain encryption (for
example, on local NTFS, FAT, ExFAT).

IMPORTANT
Every WIP policy should include policy that defines your enterprise network locations.
Classless Inter-Domain Routing (CIDR) notation isn’t supported for WIP configurations.

To define where your protected apps can find and send enterprise data on you network
1. Add additional network locations your apps can access by clicking Add.
The Add or edit corporate network definition box appears.
2. Type a name for your corporate network element into the Name box, and then pick what type of network
element it is, from the Network element drop-down box. This can include any of the options in the
following table.

NETWORK LOCATION TYPE FORMAT DESCRIPTION

Enterprise Cloud Resources With proxy: Specify the cloud resources to be
contoso.sharepoint.com,contoso.inte treated as corporate and protected
rnalproxy1.com| by WIP.
contoso.visualstudio.com,contoso.int For each cloud resource, you
ernalproxy2.com may also optionally specify a
Without proxy: proxy server from your Internal
contoso.sharepoint.com|contoso. proxy servers list to route traffic
visualstudio.com for this cloud resource. Be aware
that all traffic routed through
your Internal proxy servers is
considered enterprise.
If you have multiple resources,
you must separate them using
the "|" delimiter. If you don’t use
proxy servers, you must also
include the "," delimiter just
before the "|". For example:
URL <,proxy>|URL <,proxy> .

Important
In some cases, such as when an
app connects directly to a cloud
resource through an IP address,
Windows can’t tell whether it’s
attempting to connect to an
enterprise cloud resource or to a
personal site. In this case,
Windows blocks the connection
by default. To stop Windows
from automatically blocking
these connections, you can add
the /*AppCompat*/ string to
the setting. For example:
URL <,proxy>|URL
<,proxy>|/*AppCompat*/
.

Enterprise Network Domain Names corp.contoso.com,region.contoso.co Specify the DNS suffixes used in your
(Required) m environment. All traffic to the fully-
qualified domains appearing in this
list will be protected.
This setting works with the IP
ranges settings to detect
whether a network endpoint is
enterprise or personal on private
networks.
If you have multiple resources,
you must separate them using
the "," delimiter.
Proxy servers proxy.contoso.com:80;proxy2.contos Specify the proxy servers your
o.com:443 devices will go through to reach your
cloud resources. Using this server
type indicates that the cloud
resources you’re connecting to are
enterprise resources.

This list shouldn’t include any servers

listed in your Internal proxy servers
list. Internal proxy servers must be
used only for WIP-protected
(enterprise) traffic.

If you have multiple resources, you

must separate them using the ";"
delimiter.

Internal proxy servers contoso.internalproxy1.com;contoso.i Specify the internal proxy servers

nternalproxy2.com your devices will go through to reach
your cloud resources. Using this
server type indicates that the cloud
resources you’re connecting to are
enterprise resources.

This list shouldn’t include any servers

listed in your Proxy servers list. Proxy
servers must be used only for non-
WIP-protected (non-enterprise)
traffic.

If you have multiple resources, you

must separate them using the ";"
delimiter.

Enterprise IPv4 Range (Required) Starting IPv4 Address: 3.4.0.1 Specify the addresses for a valid IPv4
Ending IPv4 Address: 3.4.255.254 value range within your intranet.
Custom URI: 3.4.0.1-3.4.255.254, These addresses, used with your
10.0.0.1-10.255.255.254 Enterprise Network Domain Names,
define your corporate network
boundaries.
If you have multiple ranges, you
must separate them using the ","
delimiter.

Enterprise IPv6 Range Starting IPv6 Address: 2a01:110:: Specify the addresses for a valid IPv6
Ending IPv6 Address: value range within your intranet.
2a01:110:7fff:ffff:ffff:ffff:ffff:ffff These addresses, used with your
Custom URI: Enterprise Network Domain Names,
2a01:110:7fff:ffff:ffff:ffff:ffff:ffff, define your corporate network
fd00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff boundaries.
If you have multiple ranges, you
must separate them using the ","
delimiter.
 Neutral Resources sts.contoso.com,sts.contoso2.com Specify your authentication
redirection endpoints for your
company.
These locations are considered
enterprise or personal, based on
the context of the connection
before the redirection.
If you have multiple resources,
you must separate them using
the "," delimiter.

3. Add as many locations as you need, and then click OK.

The Add or edit corporate network definition box closes.
4. Decide if you want to Windows to look for additional network settings and if you want to show the WIP
icon on your corporate files while in File Explorer.

Enterprise Proxy Servers list is authoritative (do not auto-detect). Click this box if you want
Windows to treat the proxy servers you specified in the network boundary definition as the
complete list of proxy servers available on your network. If you clear this box, Windows will search
for additional proxy servers in your immediate network. Not configured is the default option.
Enterprise IP Ranges list is authoritative (do not auto-detect). Click this box if you want
Windows to treat the IP ranges you specified in the network boundary definition as the complete list
of IP ranges available on your network. If you clear this box, Windows will search for additional IP
ranges on any domain-joined devices connected to your network. Not configured is the default
option.
 Show the Windows Information Protection icon overlay on your allowed apps that are
WIP -unaware on corporate files in the File Explorer. Click this box if you want the Windows
Information Protection icon overlay to appear on corporate files in the Save As and File Explorer
views. Additionally, for unenlightened but allowed apps, the icon overlay also appears on the app tile
and with Managed text on the app name in the Start menu. Not configured is the default option.
5. In the required Upload a Data Recovery Agent (DRA ) certificate to allow recovery of encrypted
data box, click Browse to add a data recovery certificate for your policy.

After you create and deploy your WIP policy to your employees, Windows will begin to encrypt your
corporate data on the employees’ local device drive. If somehow the employees’ local encryption keys get
lost or revoked, the encrypted data can become unrecoverable. To help avoid this possibility, the DRA
certificate lets Windows use an included public key to encrypt the local data, while you maintain the private
key that can unencrypt the data.
For more info about how to find and export your data recovery certificate, see the Data Recovery and
Encrypting File System (EFS ) topic. For more info about creating and verifying your EFS DRA certificate,
see the Create and verify an Encrypting File System (EFS ) Data Recovery Agent (DRA) certificate.

Choose your optional WIP-related settings

After you've decided where your protected apps can access enterprise data on your network, you’ll be asked to
decide if you want to add any optional WIP settings.
To set your optional settings
1. Choose to set any or all of the optional settings:
Show the Personal option in the File ownership menus of File Explorer and the Save As
dialog box. Determines whether users can see the Personal option for files within File Explorer and
the Save As dialog box. The options are:
Yes, or not configured (recommended). Employees can choose whether a file is Work or
Personal in File Explorer and the Save As dialog box.
No. Hides the Personal option from employees. Be aware that if you pick this option, apps
that use the Save As dialog box might encrypt new files as corporate data unless a different
file path is given during the original file creation. After this happens, decryption of work files
becomes more difficult.

IMPORTANT
The Show the Personal option in the File ownership menus of File Explorer and the Save As
dialog box option is only available for Configuration Manager versions 1610 and below.

Prevent corporate data from being accessed by apps when the device is locked. Applies
only to Windows 10 Mobile. Determines whether to encrypt enterprise data using a key that's
protected by an employee's PIN code on a locked device. Apps won't be able to read corporate data
 when the device is locked. The options are:
Yes (recommended). Turns on the feature and provides the additional protection.
No, or not configured. Doesn't enable this feature.
Allow Windows Search to search encrypted corporate data and Store apps. Determines
whether Windows Search can search and index encrypted corporate data and Store apps. The
options are:
Yes. Allows Windows Search to search and index encrypted corporate data and Store apps.
No, or not configured (recommended). Stops Windows Search from searching and
indexing encrypted corporate data and Store apps.
Revoke local encryption keys during the unerollment process. Determines whether to revoke
a user’s local encryption keys from a device when it’s unenrolled from Windows Information
Protection. If the encryption keys are revoked, a user no longer has access to encrypted corporate
data. The options are:
Yes, or not configured (recommended). Revokes local encryption keys from a device
during unenrollment.
No. Stop local encryption keys from being revoked from a device during unenrollment. For
example, if you’re migrating between Mobile Device Management (MDM ) solutions.
2. After you pick all of the settings you want to include, click Summary.

Review your configuration choices in the Summary screen

After you've finished configuring your policy, you can review all of your info on the Summary screen.
To view the Summary screen
Click the Summary button to review your policy choices, and then click Next to finish and to save your
policy.
 A progress bar appears, showing you progress for your policy. After it's done, click Close to return to the
Configuration Items page.

Deploy the WIP policy

After you’ve created your WIP policy, you'll need to deploy it to your organization's devices. For info about your
deployment options, see these topics:
Operations and Maintenance for Compliance Settings in Configuration Manager
How to Create Configuration Baselines for Compliance Settings in Configuration Manager
How to Deploy Configuration Baselines in Configuration Manager

Related topics
System Center Configuration Manager and Endpoint Protection (Version 1606)
TechNet documentation for Configuration Manager
Manage mobile devices with Configuration Manager and Microsoft Intune
How to collect Windows Information Protection (WIP ) audit event logs
General guidance and best practices for Windows Information Protection (WIP )
 Create and verify an Encrypting File System (EFS)
Data Recovery Agent (DRA) certificate
7/11/2018 • 5 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later
If you don’t already have an EFS DRA certificate, you’ll need to create and extract one from your system before
you can use Windows Information Protection (WIP ), formerly known as enterprise data protection (EDP ), in your
organization. For the purposes of this section, we’ll use the file name EFSDRA; however, this name can be
replaced with anything that makes sense to you.
The recovery process included in this topic only works for desktop devices. WIP deletes the data on Windows 10
Mobile devices.

IMPORTANT
If you already have an EFS DRA certificate for your organization, you can skip creating a new one. Just use your current EFS
DRA certificate in your policy. For more info about when to use a PKI and the general strategy you should use to deploy
DRA certificates, see the Security Watch Deploying EFS: Part 1 article on TechNet. For more general info about EFS
protection, see Protecting Data by Using EFS to Encrypt Hard Drives.

If your DRA certificate has expired, you won’t be able to encrypt your files with it. To fix this, you'll need to create a new
certificate, using the steps in this topic, and then deploy it through policy.

Manually create an EFS DRA certificate

1. On a computer without an EFS DRA certificate installed, open a command prompt with elevated rights,
and then navigate to where you want to store the certificate.
2. Run this command:
cipher /r:EFSRA

Where EFSRA is the name of the .cer and .pfx files that you want to create.
3. When prompted, type and confirm a password to help protect your new Personal Information Exchange
(.pfx) file.
The EFSDRA.cer and EFSDRA.pfx files are created in the location you specified in Step 1.

IMPORTANT
Because the private keys in your DRA .pfx files can be used to decrypt any WIP file, you must protect them
accordingly. We highly recommend storing these files offline, keeping copies on a smart card with strong protection
for normal use and master copies in a secured physical location.

4. Add your EFS DRA certificate to your WIP policy using a deployment tool, such as Microsoft Intune or
System Center Configuration Manager.
Verify your data recovery certificate is correctly set up on a WIP client
computer
1. Find or create a file that's encrypted using Windows Information Protection. For example, you could open
an app on your allowed app list, and then create and save a file so it’s encrypted by WIP.
2. Open an app on your protected app list, and then create and save a file so that it’s encrypted by WIP.
3. Open a command prompt with elevated rights, navigate to where you stored the file you just created, and
then run this command:
cipher /c filename

Where filename is the name of the file you created in Step 1.

4. Make sure that your data recovery certificate is listed in the Recovery Certificates list.

Recover your data using the EFS DRA certificate in a test environment
1. Copy your WIP -encrypted file to a location where you have admin access.
2. Install the EFSDRA.pfx file, using its password.
3. Open a command prompt with elevated rights, navigate to the encrypted file, and then run this command:
cipher /d encryptedfile.extension

Where encryptedfile.extension is the name of your encrypted file. For example, corporatedata.docx.

Recover WIP-protected after unenrollment

It's possible that you might revoke data from an unenrolled device only to later want to restore it all. This can
happen in the case of a missing device being returned or if an unenrolled employee enrolls again. If the employee
enrolls again using the original user profile, and the revoked key store is still on the device, all of the revoked data
can be restored at once.

IMPORTANT
To maintain control over your enterprise data, and to be able to revoke again in the future, you must only perform this
process after the employee has re-enrolled the device.

1. Have the employee sign in to the unenrolled device, open an elevated command prompt, and type:
Robocopy "%localappdata%\Microsoft\EDP\Recovery" "new_location" * /EFSRAW

Where "new_location" is in a different directory. This can be on the employee’s device or on a shared folder
on a computer that runs Windows 8 or Windows Server 2012 or newer and can be accessed while you're
logged in as a data recovery agent.
To start Robocopy in S mode, open Task Manager. Click File > Run new task, type the command, and
click Create this task with administrative privileges.
 If the employee performed a clean installation and there is no user profile, you need to recover the keys
from the System Volume folder in each drive. Type:
Robocopy "drive_letter:\System Volume Information\EDP\Recovery" "new_location" * /EFSRAW

2. Sign in to a different device with administrator credentials that have access to your organization's DRA
certificate, and perform the file decryption and recovery by typing:
cipher.exe /D "new_location"

3. Have your employee sign in to the unenrolled device, and type:

Robocopy "new_location" "%localappdata%\Microsoft\EDP\Recovery\Input"

4. Ask the employee to lock and unlock the device.

The Windows Credential service automatically recovers the employee’s previously revoked keys from the
Recovery\Input location.

Auto-recovery of encryption keys

Starting with Windows 10, version 1709, WIP includes a data recovery feature that lets your employees auto-
recover access to work files if the encryption key is lost and the files are no longer accessible. This typically
happens if an employee reimages the operating system partition, removing the WIP key info, or if a device is
reported as lost and you mistakenly target the wrong device for unenrollment.
To help make sure employees can always access files, WIP creates an auto-recovery key that’s backed up to their
Azure Active Directory (Azure AD ) identity.
The employee experience is based on sign in with an Azure AD work account. The employee can either:
Add a work account through the Windows Settings > Accounts > Access work or school > Connect
menu.
-OR -
Open Windows Settings > Accounts > Access work or school > Connect and choose the Join this
device to Azure Active Directory link, under Alternate actions.

NOTE
To perform an Azure AD Domain Join from the Settings page, the employee must have administrator privileges to
the device.

After signing in, the necessary WIP key info is automatically downloaded and employees are able to access the
files again.
To test what the employee sees during the WIP key recovery process
1. Attempt to open a work file on an unenrolled device.
The Connect to Work to access work files box appears.
2. Click Connect.
The Access work or school settings page appears.
3. Sign-in to Azure AD as the employee and verify that the files now open

Related topics
Security Watch Deploying EFS: Part 1
Protecting Data by Using EFS to Encrypt Hard Drives
Create a Windows Information Protection (WIP ) policy using Microsoft Intune
Create a Windows Information Protection (WIP ) policy using System Center Configuration Manager
Creating a Domain-Based Recovery Agent

NOTE
Help to make this topic better by providing us with edits, additions, and feedback. For info about how to contribute to this
topic, see Contributing to this article.
 Determine the Enterprise Context of an app running
in Windows Information Protection (WIP)
5/30/2018 • 2 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later

Learn more about what features and functionality are supported in each Windows edition at Compare
Windows 10 Editions.

Use Task Manager to check the context of your apps while running in Windows Information Protection (WIP ) to
make sure that your organization's policies are applied and running correctly.

Viewing the Enterprise Context column in Task Manager

You need to add the Enterprise Context column to the Details tab of the Task Manager.
1. Make sure that you have an active WIP policy deployed and turned on in your organization.
2. Open the Task Manager (taskmgr.exe), click the Details tab, right-click in the column heading area, and click
Select columns.
The Select columns box appears.

3. Scroll down and check the Enterprise Context option, and then click OK to close the box.
The Enterprise Context column should now be available in Task Manager.
Review the Enterprise Context
The Enterprise Context column shows you what each app can do with your enterprise data:
Domain. Shows the employee's work domain (such as, corp.contoso.com). This app is considered work-
related and can freely touch and open work data and resources.
Personal. Shows the text, Personal. This app is considered non-work-related and can't touch any work data
or resources.
Exempt. Shows the text, Exempt. WIP policies don't apply to these apps (such as, system components).

Important
Enlightened apps can change between Work and Personal, depending on the data being touched. For
example, Microsoft Word 2016 shows as Personal when an employee opens a personal letter, but
changes to Work when that same employee opens the company financials.
 Mandatory tasks and settings required to turn on
Windows Information Protection (WIP)
10/18/2018 • 2 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later
This list provides all of the tasks and settings that are required for the operating system to turn on Windows
Information Protection (WIP ), formerly known as enterprise data protection (EDP ), in your enterprise.

IMPORTANT
All sections provided for more info appear in either the Create a Windows Information Protection (WIP) policy using Microsoft
Intune or Create a Windows Information Protection (WIP) policy using System Center Configuration Manager, based on the
tool you're using in your organization.

TASK DESCRIPTION

Add at least one app to the Protected apps list in your WIP You must have at least one app added to your Protected
policy. apps list. For more info about where this area is and how to
add apps, see the Add apps to your Protected apps list
section of the policy creation topics.

Choose your WIP protection level. You must choose the level of protection you want to apply to
your WIP-protected content, including Allow Overrides,
Silent, or Hide Overrides. For more info about where this
area is and how to decide on your protection level, see the
Manage the WIP protection mode for your enterprise
data section of the policy creation topics. For info about how
to collect your audit log files, see How to collect Windows
Information Protection (WIP) audit event logs.

Specify your corporate identity. This field is automatically filled out for you by Microsoft
Intune. However, you must manually correct it if it’s incorrect
or if you need to add additional domains. For more info about
where this area is and what it means, see the Define your
enterprise-managed corporate identity section of the
policy creation topics.

Specify your network domain names. Starting with Windows 10, version 1703, this field is optional.

Specify the DNS suffixes used in your environment. All traffic

to the fully-qualified domains appearing in this list will be
protected. For more info about where this area is and how to
add your suffixes, see the table that appears in the Choose
where apps can access enterprise data section of the policy
creation topics.
TASK DESCRIPTION

Specify your enterprise IPv4 or IPv6 ranges. Starting with Windows 10, version 1703, this field is optional.

Specify the addresses for a valid IPv4 or IPv6 value range

within your intranet. These addresses, used with your Network
domain names, define your corporate network boundaries. For
more info about where this area is and what it means, see the
table that appears in the Define your enterprise-managed
corporate identity section of the policy creation topics.

Include your Data Recovery Agent (DRA) certificate. Starting with Windows 10, version 1703, this field is optional.
But we strongly recommend that you add a certificate.

This certificate makes sure that any of your WIP-encrypted

data can be decrypted, even if the security keys are lost. For
more info about where this area is and what it means, see the
Create and verify an Encrypting File System (EFS) Data
Recovery Agent (DRA) certificate topic.

NOTE
Help to make this topic better by providing us with edits, additions, and feedback. For info about how to contribute to this
topic, see Editing Windows IT professional documentation.
 Testing scenarios for Windows Information Protection
(WIP)
10/15/2018 • 7 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later
We've come up with a list of suggested testing scenarios that you can use to test Windows Information Protection
(WIP ) in your company.

Testing scenarios
You can try any of the processes included in these scenarios, but you should focus on the ones that you might
encounter in your organization.

IMPORTANT
If any of these scenarios does not work, first take note of whether WIP has been revoked. If it has, unenlightened apps will
have to be uninstalled and re-installed since their settings files will remain encrypted.

SCENARIO PROCESSES
Encrypt and decrypt files using File Explorer. For desktop:

1. Open File Explorer, right-click a work document, and

then click Work from the File Ownership menu.
Make sure the file is encrypted by right-clicking the file
again, clicking Advanced from the General tab, and
then clicking Details from the Compress or Encrypt
attributes area. The file should show up under the
heading, This enterprise domain can remove or
revoke access: <your_enterprise_identity>. For
example, contoso.com.
2. In File Explorer, right-click the same document, and
then click Personal from the File Ownership menu.
Make sure the file is decrypted by right-clicking the file
again, clicking Advanced from the General tab, and
then verifying that the Details button is unavailable.
For mobile:

1. Open the File Explorer app, browse to a file location,

click the elipsis (...), and then click Select to mark at
least one file as work-related.
2. Click the elipsis (...) again, click File ownership from
the drop down menu, and then click Work.
Make sure the file is encrypted, by locating the
Briefcase icon next to the file name.
3. Select the same file, click File ownership from the drop
down menu, and then click Personal.
Make sure the file is decrypted and that you're no
longer seeing the Briefcase icon next to file name.
Create work documents in enterprise-allowed apps. For desktop:

Start an unenlightened but allowed app, such as a line-

of-business app, and then create a new document,
saving your changes.
Make sure the document is encrypted to your
Enterprise Identity. This might take a few minutes and
require you to close and re-open the file.

Important
Certain file types like .exe and .dll , along with
certain file paths, such as %windir% and
%programfiles% are excluded from automatic
encryption.

For more info about your Enterprise Identity and

adding apps to your allowed apps list, see either Create
a Windows Information Protection (WIP) policy using
Microsoft Intune or Create a Windows Information
Protection (WIP) policy using Microsoft System Center
Configuration Manager, based on your deployment
system.
For mobile:

1. Start an allowed mobile app, such as Word Mobile,

create a new document, and then save your changes
as Work to a local, work-related location.
Make sure the document is encrypted, by locating the
Briefcase icon next to the file name.
2. Open the same document and attempt to save it to a
non-work-related location.
WIP should stop you from saving the file to this
location.
3. Open the same document one last time, make a
change to the contents, and then save it again using
the Personal option.
Make sure the file is decrypted and that you're no
longer seeing the Briefcase icon next to file name.

Block enterprise data from non-enterprise apps. 1. Start an app that doesn't appear on your allowed apps
list, and then try to open a work-encrypted file.
The app shouldn't be able to access the file.
2. Try double-clicking or tapping on the work-encrypted
file.
If your default app association is an app not on your
allowed apps list, you should get an Access Denied
error message.
Copy and paste from enterprise apps to non-enterprise apps. 1. Copy (CTRL+C) content from an app on your allowed
apps list, and then try to paste (CTRL+V) the content
into an app that doesn't appear on your allowed apps
list.
You should see a WIP-related warning box, asking you
to click either Change to personal or Keep at work.
2. Click Keep at work.
The content isn't pasted into the non-enterprise app.
3. Repeat Step 1, but this time click Change to personal,
and try to paste the content again.
The content is pasted into the non-enterprise app.
4. Try copying and pasting content between apps on your
allowed apps list.
The content should copy and paste between apps
without any warning messages.

Drag and drop from enterprise apps to non-enterprise apps. 1. Drag content from an app on your allowed apps list,
and then try to drop the content into an app that
doesn't appear on your allowed apps list.
You should see a WIP-related warning box, asking you
to click either Keep at work or Change to personal.
2. Click Keep at work.
The content isn't dropped into the non-enterprise app.
3. Repeat Step 1, but this time click Change to personal,
and try to drop the content again.
The content is dropped into the non-enterprise app.
4. Try dragging and dropping content between apps on
your allowed apps list.
The content should move between the apps without
any warning messages.

Share between enterprise apps and non-enterprise apps. 1. Open an app on your allowed apps list, like Microsoft
Photos, and try to share content with an app that
doesn't appear on your allowed apps list, like Facebook.
You should see a WIP-related warning box, asking you
to click either Keep at work or Change to personal.
2. Click Keep at work.
The content isn't shared into Facebook.
3. Repeat Step 1, but this time click Change to personal,
and try to share the content again.
The content is shared into Facebook.
4. Try sharing content between apps on your allowed
apps list.
The content should share between the apps without
any warning messages.
Verify that Windows system components can use WIP. 1. Start Windows Journal and Internet Explorer 11,
creating, editing, and saving files in both apps.
Make sure that all of the files you worked with are
encrypted to your configured Enterprise Identity. In
some cases, you might need to close the file and wait a
few moments for it to be automatically encrypted.
2. Open File Explorer and make sure your modified files
are appearing with a Lock icon.
3. Try copying and pasting, dragging and dropping, and
sharing using these apps with other apps that appear
both on and off the allowed apps list.

Note
Most Windows-signed components like File Explorer
(when running in the user’s context), should have
access to enterprise data.

A few notable exceptions include some of the user-

facing in-box apps, like Wordpad, Notepad, and
Microsoft Paint. These apps don't have access by
default, but can be added to your allowed apps list.

Use WIP on NTFS, FAT, and exFAT systems. 1. Start an app that uses the FAT or exFAT file system (for
example a SD card or USB flash drive), and appears on
your allowed apps list.
2. Create, edit, write, save, copy, and move files.
Basic file and folder operations like copy, move,
rename, delete, and so on, should work properly on
encrypted files.

Verify your shared files can use WIP. 1. Download a file from a protected file share, making
sure the file is encrypted by locating the Briefcase
icon next to the file name.
2. Open the same file, make a change, save it and then
try to upload it back to the file share. Again, this
should work without any warnings.
3. Open an app that doesn't appear on your allowed apps
list and attempt to access a file on the WIP-enabled file
share.
The app shouldn't be able to access the file share.

Verify your cloud resources can use WIP. 1. Add both Internet Explorer 11 and Microsoft Edge to
your allowed apps list.
2. Open SharePoint (or another cloud resource that's part
of your policy) and access a WIP-enabled resource by
using both IE11 and Microsoft Edge.
Both browsers should respect the enterprise and
personal boundary.
3. Remove Internet Explorer 11 from your allowed app list
and then try to access an intranet site or enterprise-
related cloud resource.
IE11 shouldn't be able to access the sites.

Note
Any file downloaded from your work SharePoint site, or
any other WIP-enabled cloud resource, is automatically
marked as Work.
Verify your Virtual Private Network (VPN) can be auto- 1. Set up your VPN network to start based on the
triggered. WIPModeID setting.
For specific info about how to do this, see the Create
and deploy a VPN policy for Windows Information
Protection (WIP) using Microsoft Intune topic.
2. Start an app from your allowed apps list.
The VPN network should automatically start.
3. Disconnect from your network and then start an app
that isn't on your allowed apps list.
The VPN shouldn't start and the app shouldn't be able
to access your enterprise network.

Unenroll client devices from WIP. Unenroll a device from WIP by going to Settings, click
Accounts, click Work, click the name of the device you
want to unenroll, and then click Remove.
The device should be removed and all of the enterprise
content for that managed account should be gone.

Important
On desktop devices, the data isn't removed and can be
recovered, so you must make sure the content is
marked as Revoked and that access is denied for the
employee. On mobile devices, the data is removed.

Verify that app content is protected when a Windows 10 Check that protected app data doesn't appear on the
Mobile phone is locked. Lock screen of a Windows 10 Mobile phone.

NOTE
Help to make this topic better by providing us with edits, additions, and feedback. For info about how to contribute to this
topic, see Editing Windows IT professional documentation.
 Limitations while using Windows Information
Protection (WIP)
12/18/2018 • 5 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later
This table provides info about the most common problems you might encounter while running WIP in your
organization.

LIMITATION HOW IT APPEARS WORKAROUND

Your enterprise data on USB drives If you’re using Azure RMS: Share files with fellow employees
might be tied to the device it was Authenticated users can open through enterprise file servers or
protected on, based on your Azure RMS enterprise data on USB drives, on enterprise cloud locations. If data must
configuration. computers running Windows 10, be shared via USB, employees can
version 1703. decrypt protected files, but it will be
audited.
If you’re not using Azure RMS: Data
in the new location remains encrypted, We strongly recommend educating
but becomes inaccessible on other employees about how to limit or
devices and for other users. For eliminate the need for this decryption.
example, the file won't open or the file
opens, but doesn't contain readable
text.

Direct Access is incompatible with WIP. Direct Access might experience We recommend that you use VPN for
problems with how WIP enforces app client access to your intranet resources.
behavior and data movement because
of how WIP determines what is and isn’t Note
a corporate network resource. VPN is optional and isn’t required by
WIP.

NetworkIsolation Group Policy setting The NetworkIsolation Group Policy If you use both Group Policy and MDM
takes precedence over MDM Policy setting can configure network settings to configure your NetworkIsolation
settings. that can also be configured by using settings, you must make sure that
MDM. WIP relies on these policies being those same settings are deployed to
correctly configured. your organization using both Group
Policy and MDM.

Cortana can potentially allow data If Cortana is on the allowed list, some We don’t recommend adding Cortana
leakage if it’s on the allowed apps list. files might become unexpectedly to your allowed apps list. However, if
encrypted after an employee performs a you wish to use Cortana and don't mind
search using Cortana. Your employees whether the results potentially go to
will still be able to use Cortana to search Microsoft, you can make Cortana an
and provide results on enterprise Exempt app.
documents and locations, but results
might be sent to Microsoft.
WIP is designed for use by a single user A secondary user on a device might We recommend only having one user
per device. experience app compat issues when per managed device.
unenlightened apps start to
automatically encrypt for all users.
Additionally, only the initial, enrolled
user’s content can be revoked during
the unenrollment process.

Installers copied from an enterprise An app might fail to properly install To fix this, you can:
network file share might not work because it can’t read a necessary Start the installer directly from
properly. configuration or data file, such as a .cab the file share.
or .xml file needed for installation, which
was protected by the copy action. -OR-

Decrypt the locally copied files

needed by the installer.

-OR-

Mark the file share with the

installation media as “personal”.
To do this, you’ll need to set the
Enterprise IP ranges as
Authoritative and then exclude
the IP address of the file server,
or you’ll need to put the file
server on the Enterprise Proxy
Server list.

Changing your primary Corporate You might experience various Turn off WIP for all devices before
Identity isn’t supported. instabilities, including but not limited to changing the primary Corporate
network and file access failures, and Identity (first entry in the list),
potentially granting incorrect access. restarting, and finally redeploying.

Redirected folders with Client Side Apps might encounter access errors Migrate to use another file
Caching are not compatible with WIP. while attempting to read a cached, synchronization method, such as Work
offline file. Folders or OneDrive for Business.

Note
For more info about Work Folders and
Offline Files, see the blog, Work Folders
and Offline Files support for Windows
Information Protection. If you're having
trouble opening files offline while using
Offline Files and WIP, see the support
article, Can't open files offline when you
use Offline Files and Windows
Information Protection.

You can't upload an enterprise file to a A message appears stating that the Open File Explorer and change the file
personal location using Microsoft Edge content is marked as Work and the ownership to Personal before you
or Internet Explorer. user isn't given an option to override to upload.
Personal.
ActiveX controls should be used with Webpages that use ActiveX controls can We recommend that you switch to
caution. potentially communicate with other using Microsoft Edge, the more secure
outside processes that aren’t protected and safer browser that prevents the use
by using WIP. of ActiveX controls. We also recommend
that you limit the usage of Internet
Explorer 11 to only those line-of-
business apps that require legacy
technology.

For more info, see Out-of-date ActiveX

control blocking.

Resilient File System (ReFS) isn't Trying to save or transfer WIP files to Format drive for NTFS, or use a different
currently supported with WIP. ReFS will fail. drive.

WIP isn’t turned on if any of the WIP isn’t turned on for employees in Don’t set the
following folders have the your organization. Error code MakeFolderAvailableOfflineDisabled
MakeFolderAvailableOfflineDisabled 0x807c0008 will result if WIP is option to False for any of the specified
option set to False: deployed by using System Center folders.
AppDataRoaming Configuration Manager.
Desktop If you currently use redirected folders,
StartMenu we recommend that you migrate to a
Documents file synchronization solution that
supports WIP, such as Work Folders or
Pictures
OneDrive for Business. Additionally, if
Music you apply redirected folders after WIP is
Videos already in place, you might be unable to
Favorites open your files offline. For more info
Contacts about these potential access errors, see
Downloads Can't open files offline when you use
Links Offline Files and Windows Information
Searches Protection.
SavedGames

NOTE
Help to make this topic better by providing us with edits, additions, and feedback. For info about how to contribute to this
topic, see Contributing to our content.
 How to collect Windows Information Protection
(WIP) audit event logs
10/4/2018 • 4 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later
Windows Information Protection (WIP ) creates audit events in the following situations:
If an employee changes the File ownership for a file from Work to Personal.
If data is marked as Work, but shared to a personal app or webpage. For example, through copying and
pasting, dragging and dropping, sharing a contact, uploading to a personal webpage, or if the user grants
a personal app provides temporary access to a work file.
If an app has custom audit events.

Collect WIP audit logs by using the Reporting configuration service

provider (CSP)
Collect the WIP audit logs from your employee’s devices by following the guidance provided by the Reporting
configuration service provider (CSP ) documentation. This topic provides info about the actual audit events.

NOTE
The Data element in the response includes the requested audit logs in an XML-encoded format.

User element and attributes

This table includes all available attributes for the User element.

ATTRIBUTE VALUE TYPE DESCRIPTION

UserID String The security identifier (SID) of the user

corresponding to this audit report.

EnterpriseID String The enterprise ID corresponding to this

audit report.

Log element and attributes

This table includes all available attributes/elements for the Log element. The response can contain zero (0) or
more Log elements.

ATTRIBUTE/ELEMENT VALUE TYPE DESCRIPTION

ProviderType String This is always EDPAudit.

ATTRIBUTE/ELEMENT VALUE TYPE DESCRIPTION

LogType String Includes:

DataCopied. Work data is
copied or shared to a personal
location.
ProtectionRemoved. WIP
protection is removed from a
Work-defined file.
ApplicationGenerated. A
custom audit log provided by
an app.

TimeStamp Int Uses the FILETIME structure to

represent the time that the event
happened.

Policy String How the work data was shared to the

personal location:
CopyPaste. Work data was
pasted into a personal location
or app.
ProtectionRemoved. Work
data was changed to be
unprotected.
DragDrop. Work data was
dropped into a personal
location or app.
Share. Work data was shared
with a personal location or app.
NULL. Any other way work
data could be made personal
beyond the options above. For
example, when a work file is
opened using a personal
application (also known as,
temporary access).

Justification String Not implemented. This will always be

either blank or NULL.

Note
Reserved for future use to collect the
user justification for changing from
Work to Personal.

Object String A description of the shared work data.

For example, if an employee opens a
work file by using a personal app, this
would be the file path.
ATTRIBUTE/ELEMENT VALUE TYPE DESCRIPTION

DataInfo String Any additional info about how the

work file changed:
A file path. If an employee
uploads a work file to a
personal website by using
Microsoft Edge or Internet
Explorer, the file path is
included here.
Clipboard data types. If an
employee pastes work data into
a personal app, the list of
clipboard data types provided
by the work app are included
here. For more info, see the
Examples section of this topic.

Action Int Provides info about what happened

when the work data was shared to
personal, including:
1. File decrypt.
2. Copy to location.
3. Send to recipient.
4. Other.

FilePath String The file path to the file specified in the

audit event. For example, the location
of a file that’s been decrypted by an
employee or uploaded to a personal
website.

SourceApplicationName String The source app or website. For the

source app, this is the AppLocker
identity. For the source website, this is
the hostname.

SourceName String A string provided by the app that’s

logging the event. It’s intended to
describe the source of the work data.

DestinationEnterpriseID String The enterprise ID value for the app or

website where the employee is sharing
the data.

NULL, Personal, or blank means

there’s no enterprise ID because the
work data was shared to a personal
location. Because we don’t currently
support multiple enrollments, you’ll
always see one of these values.

DestinationApplicationName String The destination app or website. For the

destination app, this is the AppLocker
identity. For the destination website,
this is the hostname.
 ATTRIBUTE/ELEMENT VALUE TYPE DESCRIPTION

DestinationName String A string provided by the app that’s

logging the event. It’s intended to
describe the destination of the work
data.

Application String The AppLocker identity for the app

where the audit event happened.

Examples
Here are a few examples of responses from the Reporting CSP.
File ownership on a file is changed from work to personal

<SyncML><SyncHdr/><SyncBody><Status><CmdID>1</CmdID><MsgRef>1</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd>
<Data>200</Data></Status><Status><CmdID>2</CmdID><MsgRef>1</MsgRef><CmdRef>2</CmdRef><Cmd>Replace</Cmd>
<Data>200</Data></Status><Status><CmdID>3</CmdID><MsgRef>1</MsgRef><CmdRef>4</CmdRef><Cmd>Get</Cmd>
<Data>200</Data></Status><Results><CmdID>4</CmdID><MsgRef>1</MsgRef><CmdRef>4</CmdRef><Item><Source>
<LocURI>./Vendor/MSFT/Reporting/EnterpriseDataProtection/RetrieveByTimeRange/Logs</LocURI></Source><Meta>
<Format xmlns="syncml:metinf">xml</Format></Meta><Data><?xml version="1.0" encoding="utf-8"?>
<Reporting Version="com.contoso/2.0/MDM/Reporting">
<User UserID="S-1-12-1-1111111111-1111111111-1111111111-1111111111" EnterpriseID="corp.contoso.com">
<Log ProviderType="EDPAudit" LogType="ProtectionRemoved" TimeStamp="131357166318347527">
<Policy>Protection removed</Policy>
<Justification>NULL</Justification>
<FilePath>C:\Users\TestUser\Desktop\tmp\demo\Work document.docx</FilePath>
</Log>
</User>
</Reporting></Data></Item></Results><Final/></SyncBody></SyncML>

A work file is uploaded to a personal webpage in Edge

<SyncML><SyncHdr/><SyncBody><Status><CmdID>1</CmdID><MsgRef>1</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd>
<Data>200</Data></Status><Status><CmdID>2</CmdID><MsgRef>1</MsgRef><CmdRef>2</CmdRef><Cmd>Replace</Cmd>
<Data>200</Data></Status><Status><CmdID>3</CmdID><MsgRef>1</MsgRef><CmdRef>4</CmdRef><Cmd>Get</Cmd>
<Data>200</Data></Status><Results><CmdID>4</CmdID><MsgRef>1</MsgRef><CmdRef>4</CmdRef><Item><Source>
<LocURI>./Vendor/MSFT/Reporting/EnterpriseDataProtection/RetrieveByTimeRange/Logs</LocURI></Source><Meta>
<Format xmlns="syncml:metinf">xml</Format></Meta><Data><?xml version="1.0" encoding="utf-8"?>
<Reporting Version="com.contoso/2.0/MDM/Reporting">
<User UserID="S-1-12-1-1111111111-1111111111-1111111111-1111111111" EnterpriseID="corp.contoso.com">
<Log ProviderType="EDPAudit" LogType="DataCopied" TimeStamp="131357192409318534">
<Policy>CopyPaste</Policy>
<Justification>NULL</Justification>
<SourceApplicationName>NULL</SourceApplicationName>
<DestinationEnterpriseID>NULL</DestinationEnterpriseID>
<DestinationApplicationName>mail.contoso.com</DestinationApplicationName>
<DataInfo>C:\Users\TestUser\Desktop\tmp\demo\Work document.docx</DataInfo>
</Log>
</User>
</Reporting></Data></Item></Results><Final/></SyncBody></SyncML>

Work data is pasted into a personal webpage

 <SyncML><SyncHdr/><SyncBody><Status><CmdID>1</CmdID><MsgRef>1</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd>
<Data>200</Data></Status><Status><CmdID>2</CmdID><MsgRef>1</MsgRef><CmdRef>2</CmdRef><Cmd>Replace</Cmd>
<Data>200</Data></Status><Status><CmdID>3</CmdID><MsgRef>1</MsgRef><CmdRef>4</CmdRef><Cmd>Get</Cmd>
<Data>200</Data></Status><Results><CmdID>4</CmdID><MsgRef>1</MsgRef><CmdRef>4</CmdRef><Item><Source>
<LocURI>./Vendor/MSFT/Reporting/EnterpriseDataProtection/RetrieveByTimeRange/Logs</LocURI></Source><Meta>
<Format xmlns="syncml:metinf">xml</Format></Meta><Data><?xml version="1.0" encoding="utf-8"?>
<Reporting Version="com.contoso/2.0/MDM/Reporting">
<User UserID="S-1-12-1-1111111111-1111111111-1111111111-1111111111" EnterpriseID="corp.contoso.com">
<Log ProviderType="EDPAudit" LogType="DataCopied" TimeStamp="131357193734179782">
<Policy>CopyPaste</Policy>
<Justification>NULL</Justification>
<SourceApplicationName>O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT OFFICE
2016\WINWORD.EXE\16.0.8027.1000</SourceApplicationName>
<DestinationEnterpriseID>NULL</DestinationEnterpriseID>
<DestinationApplicationName>mail.contoso.com</DestinationApplicationName>
<DataInfo>EnterpriseDataProtectionId|Object Descriptor|Rich Text Format|HTML
Format|AnsiText|Text|EnhancedMetafile|Embed Source|Link Source|Link Source
Descriptor|ObjectLink|Hyperlink</DataInfo>
</Log>
</User>
</Reporting></Data></Item></Results><Final/></SyncBody></SyncML>

A work file is opened with a personal application

<SyncML><SyncHdr/><SyncBody><Status><CmdID>1</CmdID><MsgRef>1</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd>
<Data>200</Data></Status><Status><CmdID>2</CmdID><MsgRef>1</MsgRef><CmdRef>2</CmdRef><Cmd>Replace</Cmd>
<Data>200</Data></Status><Status><CmdID>3</CmdID><MsgRef>1</MsgRef><CmdRef>4</CmdRef><Cmd>Get</Cmd>
<Data>200</Data></Status><Results><CmdID>4</CmdID><MsgRef>1</MsgRef><CmdRef>4</CmdRef><Item><Source>
<LocURI>./Vendor/MSFT/Reporting/EnterpriseDataProtection/RetrieveByTimeRange/Logs</LocURI></Source><Meta>
<Format xmlns="syncml:metinf">xml</Format></Meta><Data><?xml version="1.0" encoding="utf-8"?>
<Reporting Version="com.contoso/2.0/MDM/Reporting">
<User UserID="S-1-12-1-1111111111-1111111111-1111111111-1111111111" EnterpriseID="corp.contoso.com">
<Log ProviderType="EDPAudit" LogType="ApplicationGenerated" TimeStamp="131357194991209469">
<Policy>NULL</Policy>
<Justification></Justification>
<Object>C:\Users\TestUser\Desktop\tmp\demo\Work document.docx</Object>
<Action>1</Action>
<SourceName>O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT® WINDOWS® OPERATING
SYSTEM\WORDPAD.EXE\10.0.15063.2</SourceName>
<DestinationEnterpriseID>Personal</DestinationEnterpriseID>
<DestinationName>O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT® WINDOWS® OPERATING
SYSTEM\WORDPAD.EXE\10.0.15063.2</DestinationName>
<Application>O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT® WINDOWS® OPERATING
SYSTEM\WORDPAD.EXE\10.0.15063.2</Application>
</Log>
</User>
</Reporting></Data></Item></Results><Final/></SyncBody></SyncML>

Work data is pasted into a personal application

 <SyncML><SyncHdr/><SyncBody><Status><CmdID>1</CmdID><MsgRef>1</MsgRef><CmdRef>0</CmdRef><Cmd>SyncHdr</Cmd>
<Data>200</Data></Status><Status><CmdID>2</CmdID><MsgRef>1</MsgRef><CmdRef>2</CmdRef><Cmd>Replace</Cmd>
<Data>200</Data></Status><Status><CmdID>3</CmdID><MsgRef>1</MsgRef><CmdRef>4</CmdRef><Cmd>Get</Cmd>
<Data>200</Data></Status><Results><CmdID>4</CmdID><MsgRef>1</MsgRef><CmdRef>4</CmdRef><Item><Source>
<LocURI>./Vendor/MSFT/Reporting/EnterpriseDataProtection/RetrieveByTimeRange/Logs</LocURI></Source><Meta>
<Format xmlns="syncml:metinf">xml</Format></Meta><Data><?xml version="1.0" encoding="utf-8"?>
<Reporting Version="com.contoso/2.0/MDM/Reporting">
<User UserID="S-1-12-1-1111111111-1111111111-1111111111-1111111111" EnterpriseID="corp.contoso.com">
<Log ProviderType="EDPAudit" LogType="DataCopied" TimeStamp="131357196076537270">
<Policy>CopyPaste</Policy>
<Justification>NULL</Justification>
<SourceApplicationName>O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\MICROSOFT OFFICE
2016\WINWORD.EXE\16.0.8027.1000</SourceApplicationName>
<DestinationEnterpriseID>NULL</DestinationEnterpriseID>
<DestinationApplicationName></DestinationApplicationName>
<DataInfo>EnterpriseDataProtectionId|Object Descriptor|Rich Text Format|HTML
Format|AnsiText|Text|EnhancedMetafile|Embed Source|Link Source|Link Source
Descriptor|ObjectLink|Hyperlink</DataInfo>
</Log>
</User>
</Reporting></Data></Item></Results><Final/></SyncBody></SyncML>

Collect WIP audit logs by using Windows Event Forwarding (for

Windows desktop domain-joined devices only)
Use Windows Event Forwarding to collect and aggregate your WIP audit events. You can view your audit events
in the Event Viewer.

NOTE
Windows 10 Mobile requires you to use the Reporting CSP process instead.

To view the WIP events in the Event Viewer

1. Open Event Viewer.
2. In the console tree under Application and Services Logs\Microsoft\Windows, click EDP -Audit-
Regular and EDP -Audit-TCB.
 General guidance and best practices for Windows
Information Protection (WIP)
10/15/2018 • 2 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later
This section includes info about the enlightened Microsoft apps, including how to add them to your allowed apps
list in Microsoft Intune. It also includes some testing scenarios that we recommend running through with
Windows Information Protection (WIP ).

In this section
TOPIC DESCRIPTION

Enlightened apps for use with Windows Information Learn the difference between enlightened and unenlightened
Protection (WIP) apps, and then review the list of enlightened apps provided
by Microsoft along with the text you will need to use to add
them to your allowed apps list.

Unenlightened and enlightened app behavior while using Learn the difference between enlightened and unenlightened
Windows Information Protection (WIP) app behaviors.

Recommended Enterprise Cloud Resources and Neutral Recommended additions for the Enterprise Cloud Resources
Resources network settings with Windows Information and Neutral Resources network settings, when used with
Protection (WIP) Windows Information Protection (WIP).

Using Outlook on the web with Windows Information Options for using Outlook on the web with Windows
Protection (WIP) Information Protection (WIP).

NOTE
Help to make this topic better by providing us with edits, additions, and feedback. For info about how to contribute to this
topic, see Editing Windows IT professional documentation.
 List of enlightened Microsoft apps for use with
Windows Information Protection (WIP)
10/15/2018 • 3 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later
Learn the difference between enlightened and unenlightened apps, and then review the list of enlightened apps
provided by Microsoft along with the text you will need to use to add them to your allowed apps list.

Enlightened versus unenlightened apps

Apps can be enlightened or unenlightened:
Enlightened apps can differentiate between corporate and personal data, correctly determining which to
protect, based on your policies.
Unenlightened apps consider all data corporate and encrypt everything. Typically, you can tell an
unenlightened app because:
Windows Desktop shows it as always running in enterprise mode.
Windows Save As experiences only allow you to save your files as enterprise.
WIP -work only apps are unenlightened line-of-business apps that have been tested and deemed safe for
use in an enterprise with WIP and Mobile App Management (MAM ) solutions without device enrollment.
Unenlightened apps that are targeted by WIP without enrollment run under personal mode.

List of enlightened Microsoft apps

Microsoft has made a concerted effort to enlighten several of our more popular apps, including the following:
Microsoft Edge
Internet Explorer 11
Microsoft People
Mobile Office apps, including Word, Excel, PowerPoint, OneNote, and Outlook Mail and Calendar
Office 365 ProPlus apps, including Word, Excel, PowerPoint, OneNote, and Outlook
OneDrive app
OneDrive sync client (OneDrive.exe, the next generation sync client)
Microsoft Photos
Groove Music
Notepad
Microsoft Paint
 Microsoft Movies & TV
Microsoft Messaging
Microsoft Remote Desktop

List of WIP-work only apps from Microsoft

Microsoft still has apps that are unenlightened, but which have been tested and deemed safe for use in an
enterprise with WIP and MAM solutions.
Skype for Business

Adding enlightened Microsoft apps to the allowed apps list

You can add any or all of the enlightened Microsoft apps to your allowed apps list. Included here is the Publisher
name, Product or File name, and App Type info for both Microsoft Intune and System Center Configuration
Manager.

PRODUCT NAME APP INFO

Microsoft Edge Publisher:

CN=Microsoft Corporation, O=Microsoft Corporation,
L=Redmond, S=Washington, C=US
Product Name: Microsoft.MicrosoftEdge
App Type: Universal app

Microsoft People Publisher:

CN=Microsoft Corporation, O=Microsoft Corporation,
L=Redmond, S=Washington, C=US
Product Name: Microsoft.People
App Type: Universal app

Word Mobile Publisher:

CN=Microsoft Corporation, O=Microsoft Corporation,
L=Redmond, S=Washington, C=US
Product Name: Microsoft.Office.Word
App Type: Universal app

Excel Mobile Publisher:

CN=Microsoft Corporation, O=Microsoft Corporation,
L=Redmond, S=Washington, C=US
Product Name: Microsoft.Office.Excel
App Type: Universal app

PowerPoint Mobile Publisher:

CN=Microsoft Corporation, O=Microsoft Corporation,
L=Redmond, S=Washington, C=US
Product Name: Microsoft.Office.PowerPoint
App Type: Universal app

OneNote Publisher:
CN=Microsoft Corporation, O=Microsoft Corporation,
L=Redmond, S=Washington, C=US
Product Name: Microsoft.Office.OneNote
App Type: Universal app
PRODUCT NAME APP INFO

Outlook Mail and Calendar Publisher:

CN=Microsoft Corporation, O=Microsoft Corporation,
L=Redmond, S=Washington, C=US
Product Name: microsoft.windowscommunicationsapps
App Type: Universal app

Office 365 ProPlus and Office 2019 Professional Plus Office 365 ProPlus and Office 2019 Professional Plus apps are
set up as a suite. You must use the O365 ProPlus - Allow and
Exempt AppLocker policy files (.zip files) to turn the suite on
for WIP.
We don't recommend setting up Office by using individual
paths or publisher rules.

Microsoft Photos Publisher:

CN=Microsoft Corporation, O=Microsoft Corporation,
L=Redmond, S=Washington, C=US
Product Name: Microsoft.Windows.Photos
App Type: Universal app

Groove Music Publisher:

CN=Microsoft Corporation, O=Microsoft Corporation,
L=Redmond, S=Washington, C=US
Product Name: Microsoft.ZuneMusic
App Type: Universal app

Microsoft Movies & TV Publisher:

CN=Microsoft Corporation, O=Microsoft Corporation,
L=Redmond, S=Washington, C=US
Product Name: Microsoft.ZuneVideo
App Type: Universal app

Microsoft Messaging Publisher:

CN=Microsoft Corporation, O=Microsoft Corporation,
L=Redmond, S=Washington, C=US
Product Name: Microsoft.Messaging
App Type: Universal app

IE11 Publisher:
O=Microsoft Corporation, L=Redmond, S=Washington,
C=US
Binary Name: iexplore.exe
App Type: Desktop app

OneDrive Sync Client Publisher:

O=Microsoft Corporation, L=Redmond, S=Washington,
C=US
Binary Name: onedrive.exe
App Type: Desktop app

OneDrive app Publisher:

CN=Microsoft Corporation, O=Microsoft Corporation,
L=Redmond, S=Washington, C=US
Product Name: Microsoft.Microsoftskydrive
Product Version:Product version: 17.21.0.0 (and later)
App Type: Universal app
PRODUCT NAME APP INFO

Notepad Publisher:
O=Microsoft Corporation, L=Redmond, S=Washington,
C=US
Binary Name: notepad.exe
App Type: Desktop app

Microsoft Paint Publisher:

O=Microsoft Corporation, L=Redmond, S=Washington,
C=US
Binary Name: mspaint.exe
App Type: Desktop app

Microsoft Remote Desktop Publisher:

O=Microsoft Corporation, L=Redmond, S=Washington,
C=US
Binary Name: mstsc.exe
App Type: Desktop app

Microsoft MAPI Repair Tool Publisher:

O=Microsoft Corporation, L=Redmond, S=Washington,
C=US
Binary Name: fixmapi.exe
App Type: Desktop app

NOTE
Help to make this topic better by providing us with edits, additions, and feedback. For info about how to contribute to this
topic, see Editing Windows IT professional documentation.
 Unenlightened and enlightened app behavior while
using Windows Information Protection (WIP)
10/15/2018 • 3 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later
Windows Information Protection (WIP ) classifies apps into two categories: enlightened and unenlightened.
Enlighted apps can differentiate between corporate and personal data, correctly determining which to protect
based on internal policies. Corporate data is encrypted on the managed device and attempts to copy/paste or
share this information with non-corporate apps or people will fail. Unenlightened apps, when marked as
corporate-managed, consider all data corporate and encrypt everything by default.
To avoid the automatic encryption of data, developers can enlighten apps by adding and compiling code using the
Windows Information Protection application programming interfaces. The most likely candidates for
enlightenment are apps that:
Don’t use common controls for saving files.
Don’t use common controls for text boxes.
Simultaneously work on personal and corporate data (for example, contact apps that display personal and
corporate data in a single view or a browser that displays personal and corporate web pages on tabs within a
single instance).
We strongly suggest that the only unenlightened apps you add to your allowed apps list are Line-of-Business
(LOB ) apps.

IMPORTANT
After revoking WIP, unenlightened apps will have to be uninstalled and re-installed since their settings files will remain
encrypted.

NOTE
For more info about creating enlightened apps, see the Windows Information Protection (WIP) topic in the Windows Dev
Center.

Unenlightened app behavior

This table includes info about how unenlightened apps might behave, based on your Windows Information
Protection (WIP ) networking policies, your app configuration, and potentially whether the app connects to network
resources directly by using IP addresses or by using hostnames.

APP RULE SETTING NETWORKING POLICY CONFIGURATION

NAME-BASED POLICIES, WITHOUT THE NAME-BASED POLICIES, USING THE

/*APPCOMPAT*/ STRING /*APPCOMPAT*/ STRING OR PROXY-BASED
POLICIES
 Not required. App connects to App is entirely blocked from App can access both personal
enterprise cloud resources directly, both personal and enterprise and enterprise cloud resources.
using an IP address. cloud resources. However, you might encounter
No encryption is applied. apps using policies that restrict
App can’t access local Work files. access to enterprise cloud
resources.
No encryption is applied.
App can’t access local Work files.

Not required. App connects to App is blocked from accessing enterprise cloud resources, but can access
enterprise cloud resources, using a other network resources.
hostname. No encryption is applied.
App can’t access local Work files.

Allow. App connects to enterprise App can access both personal and enterprise cloud resources.
cloud resources, using an IP address or Auto-encryption is applied.
a hostname. App can access local Work files.

Exempt. App connects to enterprise App can access both personal and enterprise cloud resources.
cloud resources, using an IP address or No encryption is applied.
a hostname. App can access local Work files.

Enlightened app behavior

This table includes info about how enlightened apps might behave, based on your Windows Information
Protection (WIP ) networking policies, your app configuration, and potentially whether the app connects to network
resources directly by using IP addresses or by using hostnames.

APP RULE SETTING NETWORKING POLICY CONFIGURATION FOR NAME-BASED

POLICIES, POSSIBLY USING THE /*APPCOMPAT*/ STRING, OR PROXY-
BASED POLICIES

Not required. App connects to enterprise cloud resources, App is blocked from accessing enterprise cloud
using an IP address or a hostname. resources, but can access other network resources.
No encryption is applied.
App can't access local Work files.

Allow. App connects to enterprise cloud resources, using an App can access both personal and enterprise cloud
IP address or a hostname. resources.
App protects work data and leaves personal data
unprotected.
App can access local Work files.

Exempt. App connects to enterprise cloud resources, using an App can access both personal and enterprise cloud
IP address or a hostname. resources.
App protects work data and leaves personal data
unprotected.
App can access local Work files.
NOTE
Help to make this topic better by providing us with edits, additions, and feedback. For info about how to contribute to this
topic, see Editing Windows IT professional documentation.
 Recommended Enterprise Cloud Resources and
Neutral Resources network settings with Windows
Information Protection (WIP)
10/18/2018 • 2 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later

Learn more about what features and functionality are supported in each Windows edition at Compare
Windows 10 Editions.

We recommend that you add the following URLs to the Enterprise Cloud Resources and Neutral Resources
network settings when you create a WIP policy. If you are using Intune, the SharePoint entries may be added
automatically.

Recommended Enterprise Cloud Resources

This table includes the recommended URLs to add to your Enterprise Cloud Resources network setting, based on
the apps you use in your organization.

ADD THESE ENTRIES TO YOUR ENTERPRISE CLOUD RESOURCES

NETWORK SETTING
IF YOUR ORGANIZATION USES... (REPLACE "CONTOSO" WITH YOUR DOMAIN NAME(S)

Office 365 for Business contoso.sharepoint.com

contoso-my.sharepoint.com
contoso-files.sharepoint.com
tasks.office.com
protection.office.com
meet.lync.com
teams.microsoft.com

Yammer www.yammer.com
yammer.com
persona.yammer.com

Microsoft Dynamics contoso.crm.dynamics.com

Visual Studio Online contoso.visualstudio.com

Power BI contoso.powerbi.com

Recommended Neutral Resources

We recommended adding these URLs if you use the Neutral Resources network setting with Windows
Information Protection (WIP ).
login.microsoftonline.com
login.windows.net
 Using Outlook on the web with Windows Information
Protection (WIP)
5/30/2018 • 2 minutes to read • Edit Online

Applies to:
Windows 10, version 1607 and later
Windows 10 Mobile, version 1607 and later

Learn more about what features and functionality are supported in each Windows edition at Compare
Windows 10 Editions.

Because Outlook on the web can be used both personally and as part of your organization, you have the following
options to configure it with Windows Information Protection (WIP ):

OPTION OUTLOOK ON THE WEB BEHAVIOR

Disable Outlook on the web. Employees can only use Disabled.

Microsoft Outlook 2016 or the Mail for Windows 10 app.

Don't configure outlook.office.com in any of your networking All mailboxes are automatically marked as personal. This
settings. means employees attempting to copy work content into
Outlook on the web receive prompts and that files
downloaded from Outlook on the web aren't automatically
protected as corporate data.

Add outlook.office.com to the Cloud resources network All mailboxes are automatically marked as corporate. This
element in your WIP policy. means any personal inboxes hosted on Office 365 are also
automatically marked as corporate data.

NOTE
These limitations don’t apply to Outlook 2016, the Mail for Windows 10 app, or the Calendar for Windows 10 app. These
apps will work properly, marking an employee’s mailbox as corporate data, regardless of how you’ve configured
outlook.office.com in your network settings.
 Fine-tune Windows Information Protection (WIP) with
WIP Learning
11/5/2018 • 4 minutes to read • Edit Online

Applies to:
Windows 10, version 1703 and later
Windows 10 Mobile, version 1703 and later
With WIP Learning, you can intelligently tune which apps and websites are included in your WIP policy to help
reduce disruptive prompts and keep it accurate and relevant. WIP Learning generates two reports: The App
learning report and the Website learning report. Both reports are accessed from Microsoft Azure Intune, and
you can alternately access the App learning report from Microsoft Operations Management Suite (OMS ).
The App learning report monitors your apps, not in policy, that attempt to access work data. You can identify
these apps using the report and add them to your WIP policies to avoid productivity disruption before fully
enforcing WIP with “Block” mode. Frequent monitoring of the report will help you continuously identify access
attempts so you can update your policy accordingly.
In the Website learning report, you can view a summary of the devices that have shared work data with websites.
You can use this information to determine which websites should be added to group and user WIP policies. The
summary shows which website URLs are accessed by WIP -enabled apps so you can decide which ones are cloud
or personal, and add them to the resource list.

Access the WIP Learning reports

1. Open the Azure portal.
2. Click All services, type Intune in the text box filter, and click the star to add it to Favorites.
3. Click Intune > Client apps > App protection status > Reports.
4. Select either App learning report for Windows Information Protection or Website learning report
for Windows Information Protection.

Once you have the apps and websites showing up in the WIP Learning logging reports, you can decide whether to
add them to your app protection policies. Next, we'll look at how to do that in Operations Management Suite
(OMS ).

View the WIP app learning report in Microsoft Operations

Management Suite
From Intune, you can open OMS by choosing WIP in the OMS console. Then you can view the WIP App
learning blade to monitor access events per app, and devices that have reported WIP access events:
If you don't have OMS linked to your Microsoft Azure Account, and want to configure your environment for
Windows Analytics: Device Health, see Get Started with Device Health for more information.

NOTE
Intune has a 14 day data retention capacity, while OMS offers better querying capabilities and longer data retention.

Once you have WIP policies in place, by using the WIP section of Device Health, you can:
Reduce disruptive prompts by adding rules to allow data sharing from approved apps.
Tune WIP rules by confirming that certain apps are allowed or denied by current policy.
The APP LEARNING tile shows details of app statistics that you can use to evaluate each incident and update app
policies by using WIP AppIDs.

In this chart view, you can see apps that have been used on connected devices which, when clicked on, will open
additional details on the app, including details you need to adjust your WIP Policy:

Here, you can copy the WipAppid and use it to adjust your WIP protection policies.

Use OMS and Intune to adjust WIP protection policy

1. Click the APP LEARNING tile in OMS, as described above, to determine which apps are being used for
 work so you can add those you choose to your WIP policy.
2. Click the app you want to add to your policy and copy the publisher information from the app details screen.
3. Back in Intune, click App protection policies and then choose the app policy you want to add an
application to.
4. Click Protected apps, and then click Add Apps.
5. In the Recommended apps drop down menu, choose either Store apps or Desktop apps, depending on
the app you've chosen (for example, an executable (EXE ) is a desktop app).

6. In NAME (optional), type the name of the app, and then in PUBLISHER (required), paste the publisher
information that you copied in step 2 above.

7. Type the name of the product in PRODUCT NAME (required) (this will probably be the same as what you
typed for NAME ).
8. Back in OMS, copy the name of the executable (for example, snippingtool.exe) and then go back to Intune
and paste it in FILE (required).
9. Go back to OMS one more time and note the version number of the app and type it in MIN VERSION in
Intune (alternately, you can specify the max version, but one or the other is required), and then select the
ACTION: Allow or Deny
When working with WIP -enabled apps and WIP -unknown apps, it is recommended that you start with Silent or
Allow overrides while verifying with a small group that you have the right apps on your allowed apps list. After
you're done, you can change to your final enforcement policy, Block. For more information about WIP modes, see:
Protect enterprise data using WIP: WIP -modes
NOTE
Help to make this topic better by providing us with edits, additions, and feedback. For info about how to contribute to this
topic, see Editing Windows IT professional documentation.
 How Windows Information Protection protects files
with a sensitivity label
11/27/2018 • 3 minutes to read • Edit Online

Applies to:
Windows 10, version 1809
This topic explains how Windows Information Protection works with other Microsoft information protection
technologies to protect files that have a sensitivity label. Microsoft information protection technologies work
together as an integrated solution to help enterprises:
Discover corporate data on endpoint devices
Classify and label information based on its content and context
Protect corporate data from unintentionally leaving to non-business environments
Enable audit reports of user interactions with corporate data on endpoint devices
Microsoft information protection technologies include:
Windows Information Protection (WIP ) is built in to Windows 10 and protects local data at rest on endpoint
devices, and manages apps to protect local data in use. Data that leaves the endpoint device, such as email
attachment, is not protected by WIP.
Office 365 Information Protection is a solution to classify, protect, and monitor personal data in Office 365
and other first-party or third-party Software-as-a-Service (SaaS ) apps.
Azure Information Protection is a cloud-based solution that can be purchased either standalone or as part of
Microsoft 365 Enterprise. It helps an organization classify and protect its documents and emails by applying
labels. Azure Information Protection is applied directly to content, and roams with the content as it's moved
between locations and cloud services.
End users can choose and apply sensitivity labels from a bar that appears below the ribbon in Office apps:

Default WIP behaviors for a sensitivity label

Enterprises can create and manage sensitivity labels on the Labels page in the Office 365 Security & Compliance
Center. When you create a sensitivity label, you can specify that endpoint protection should apply to content with
that label. WIP enforces default endpoint protection depending on how the sensitivity label is configured:
When the sensitivity label is configured for endpoint protection of content that includes business data, the
device enforces work protection for documents with the label
When the sensitivity label is not configured for endpoint protection, the device reverts to whatever WIP policy
has been defined in Intune or System Center Configuration Manager (SCCM ):
If the document is downloaded from a work site, the device enforces work protection
If the document is downloaded from a personal site, no work protection is applied
For more information about labels, see Overview of labels.

Use cases
This section covers how WIP works with sensitivity labels in specific use cases.
User downloads from or creates a document on a work site
If WIP policy is deployed, any document that is downloaded from a work site, or created on a work site, will have
WIP protection regradless of whether the document has a sensitivity label.
If the document also has a sensitivity label, which can be Office or PDF files, WIP protection is applied according to
the label.
User downloads a confidential Office or PDF document from a personal site
Windows Defender Advanced Threat Protection (Windows Defender ATP ) scans for any file that gets modified or
created, including files that were created on a personal site. If the file has a sensitivity label, the corresponding WIP
protection gets applied even though the file came from a personal site. For example:
1. Sara creates a PDF file on a Mac and labels it as Confidential.
2. She emails the PDF from her Gmail account to Laura.
3. Laura opens the PDF file on her Windows 10 device.
4. WIP policy gets applied and the file is protected.
The PDF file doesn't need any work context beyond the sensitivity label.

Prerequisites
Windows 10, version 1809
Windows Defender ATP scans content for a label and applies corresponding WIP protection
Sensitivity labels need to be configured in the Office 365 Security & Compliance Center
WIP policy needs to be applied to endpoint devices by using Intune or System Center Configuration Manager
(SCCM ).
 Secure the Windows 10 boot process
11/15/2018 • 9 minutes to read • Edit Online

Applies to:
Windows 10
Windows 8.1
The Windows operating system has many features to help protect you from malware, and it does an amazingly
good job. Except for apps that businesses develop and use internally, all Microsoft Store apps must meet a series of
requirements to be certified and included in the Microsoft Store. This certification process examines several criteria,
including security, and is an effective means of preventing malware from entering the Microsoft Store. Even if a
malicious app does get through, the Windows 10 operating system includes a series of security features that can
mitigate the impact. For instance, Microsoft Store apps are sandboxed and lack the privileges necessary to access
user data or change system settings.
Windows 10 has multiple levels of protection for desktop apps and data, too. Windows Defender uses signatures
to detect and quarantine apps that are known to be malicious. The SmartScreen Filter warns users before allowing
them to run an untrustworthy app, even if it’s recognized as malware. Before an app can change system settings,
the user would have to grant the app administrative privileges by using User Account Control.
Those are just some of the ways that Windows 10 protects you from malware. However, those security features
protect you only after Windows 10 starts. Modern malware—and bootkits specifically—are capable of starting
before Windows, completely bypassing operating system security, and remaining completely hidden.
When you run Windows 10 on a PC or any PC that supports Unified Extensible Firmware Interface (UEFI), Trusted
Boot protects your PC from malware from the moment you power on your PC until your anti-malware starts. In
the unlikely event that malware does infect a PC, it can’t remain hidden; Trusted Boot can prove the system’s
integrity to your infrastructure in a way that malware can’t disguise. Even on PCs without UEFI, Windows 10
provides even better startup security than previous versions of Windows.
First, let’s examine what rootkits are and how they work. Then, we’ll show you how Windows 10 can protect you.

The threat: rootkits

Rootkits are a sophisticated and dangerous type of malware that run in kernel mode, using the same privileges as
the operating system. Because rootkits have the same rights as the operating system and start before it, they can
completely hide themselves and other applications. Often, rootkits are part of an entire suite of malware that can
bypass local logins, record passwords and keystrokes, transfer private files, and capture cryptographic data.
Different types of rootkits load during different phases of the startup process:
Firmware rootkits. These kits overwrite the firmware of the PC’s basic input/output system or other hardware
so the rootkit can start before Windows.
Bootkits. These kits replace the operating system’s bootloader (the small piece of software that starts the
operating system) so that the PC loads the bootkit before the operating system.
Kernel rootkits. These kits replace a portion of the operating system kernel so the rootkit can start
automatically when the operating system loads.
Driver rootkits. These kits pretend to be one of the trusted drivers that Windows uses to communicate with
the PC hardware.
The countermeasures
Windows 10 supports four features to help prevent rootkits and bootkits from loading during the startup process:
Secure Boot. PCs with UEFI firmware and a Trusted Platform Module (TPM ) can be configured to load only
trusted operating system bootloaders.
Trusted Boot. Windows checks the integrity of every component of the startup process before loading it.
Early Launch Anti-Malware (ELAM ). ELAM tests all drivers before they load and prevents unapproved
drivers from loading.
Measured Boot. The PC’s firmware logs the boot process, and Windows can send it to a trusted server that
can objectively assess the PC’s health.
Figure 1 shows the Windows 10 startup process.

Figure 1. Secure Boot, Trusted Boot, and Measured Boot block malware at every stage
Secure Boot and Measured Boot are only possible on PCs with UEFI 2.3.1 and a TPM chip. Fortunately, all
Windows 10 PCs that meet Windows Hardware Compatibility Program requirements have these components, and
many PCs designed for earlier versions of Windows have them as well.
The sections that follow describe Secure Boot, Trusted Boot, ELAM, and Measured Boot.
Secure Boot
When a PC starts, it first finds the operating system bootloader. PCs without Secure Boot simply run whatever
bootloader is on the PC’s hard drive. There’s no way for the PC to tell whether it’s a trusted operating system or a
rootkit.
When a PC equipped with UEFI starts, the PC first verifies that the firmware is digitally signed, reducing the risk of
firmware rootkits. If Secure Boot is enabled, the firmware examines the bootloader’s digital signature to verify that
it hasn’t been modified. If the bootloader is intact, the firmware starts the bootloader only if one of the following
conditions is true:
The bootloader was signed using a trusted certificate. In the case of PCs certified for Windows 10, the
Microsoft® certificate is trusted.
The user has manually approved the bootloader’s digital signature. This allows the user to load non-
Microsoft operating systems.
All x86-based Certified For Windows 10 PCs must meet several requirements related to Secure Boot:
They must have Secure Boot enabled by default.
They must trust Microsoft’s certificate (and thus any bootloader Microsoft has signed).
They must allow the user to configure Secure Boot to trust other bootloaders.
They must allow the user to completely disable Secure Boot.
These requirements help protect you from rootkits while allowing you to run any operating system you want. You
have three options for running non-Microsoft operating systems:
Use an operating system with a certified bootloader. Because all Certified For Windows 10 PCs must trust
Microsoft’s certificate, Microsoft offers a service to analyze and sign any non-Microsoft bootloader so that it will
be trusted by all Certified For Windows 10 PCs. In fact, an open source bootloader capable of loading Linux is
already available. To begin the process of obtaining a certificate, go to http://sysdev.microsoft.com.
Configure UEFI to trust your custom bootloader. All Certified For Windows 10 PCs allow you to trust a
non-certified bootloader by adding a signature to the UEFI database, allowing you to run any operating system,
including homemade operating systems.
Turn off Secure Boot. All Certified For Windows 10 PCs allow you to turn off Secure Boot so that you can run
any software. This does not help protect you from bootkits, however.
To prevent malware from abusing these options, the user must manually configure the UEFI firmware to trust a
non-certified bootloader or to turn off Secure Boot. Software cannot change the Secure Boot settings. For more
information about Secure Boot, read the blog, Protecting the pre-OS environment with UEFI.
Like most mobile devices, ARM -based Certified For Windows RT devices, such as the Microsoft Surface RT device,
are designed to run only Windows 8.1. Therefore, Secure Boot cannot be turned off, and you cannot load a
different operating system. Fortunately, there is a large market of ARM devices designed to run other operating
systems.

Trusted Boot
Trusted Boot takes over where Secure Boot leaves off. The bootloader verifies the digital signature of the Windows
10 kernel before loading it. The Windows 10 kernel, in turn, verifies every other component of the Windows
startup process, including the boot drivers, startup files, and ELAM. If a file has been modified, the bootloader
detects the problem and refuses to load the corrupted component. Often, Windows 10 can automatically repair the
corrupted component, restoring the integrity of Windows and allowing the PC to start normally.

Early Launch Anti-Malware

Because Secure Boot has protected the bootloader and Trusted Boot has protected the Windows kernel, the next
opportunity for malware to start is by infecting a non-Microsoft boot driver. Traditional anti-malware apps don’t
start until after the boot drivers have been loaded, giving a rootkit disguised as a driver the opportunity to work.
Early Launch Anti-Malware (ELAM ) can load a Microsoft or non-Microsoft anti-malware driver before all non-
Microsoft boot drivers and applications, thus continuing the chain of trust established by Secure Boot and Trusted
Boot. Because the operating system hasn’t started yet, and because Windows needs to boot as quickly as possible,
ELAM has a simple task: examine every boot driver and determine whether it is on the list of trusted drivers. If it’s
not trusted, Windows won’t load it.
An ELAM driver isn’t a full-featured anti-malware solution; that loads later in the boot process. Windows Defender
(included with Windows 10) supports ELAM, as does Microsoft System Center 2012 Endpoint Protection and
several non-Microsoft anti-malware apps.

Measured Boot
If a PC in your organization does become infected with a rootkit, you need to know about it. Enterprise anti-
malware apps can report malware infections to the IT department, but that doesn’t work with rootkits that hide
their presence. In other words, you can’t trust the client to tell you whether it’s healthy.
As a result, PCs infected with rootkits appear to be healthy, even with anti-malware running. Infected PCs continue
to connect to the enterprise network, giving the rootkit access to vast amounts of confidential data and potentially
allowing the rootkit to spread across the internal network.
Working with the TPM and non-Microsoft software, Measured Boot in Windows 10 allows a trusted server on the
network to verify the integrity of the Windows startup process. Measured Boot uses the following process:
1. The PC’s UEFI firmware stores in the TPM a hash of the firmware, bootloader, boot drivers, and everything that
will be loaded before the anti-malware app.
2. At the end of the startup process, Windows starts the non-Microsoft remote attestation client. The trusted
attestation server sends the client a unique key.
3. The TPM uses the unique key to digitally sign the log recorded by the UEFI.
4. The client sends the log to the server, possibly with other security information.
Depending on the implementation and configuration, the server can now determine whether the client is healthy
and grant the client access to either a limited quarantine network or to the full network.
Figure 2 illustrates the Measured Boot and remote attestation process.
Figure 2. Measured Boot proves the PC’s health to a remote server
Windows 10 includes the application programming interfaces to support Measured Boot, but you’ll need non-
Microsoft tools to implement a remote attestation client and trusted attestation server to take advantage of it. For
an example of such a tool, download the TPM Platform Crypto-Provider Toolkit from Microsoft Research or
Microsoft Enterprise Security MVP Dan Griffin’s Measured Boot Tool.
Measured Boot uses the power of UEFI, TPM, and Windows 10 to give you a way to confidently assess the
trustworthiness of a client PC across the network.

Summary
Secure Boot, Trusted Boot, and Measured Boot create an architecture that is fundamentally resistant to bootkits
and rootkits. In Windows 10, these features have the potential to eliminate kernel-level malware from your
network. This is the most ground-breaking anti-malware solution that Windows has ever had; it’s leaps and bounds
ahead of everything else. With Windows 10, you can truly trust the integrity of your operating system.

Additional resources
Windows 10 Enterprise Evaluation
 Trusted Platform Module
9/12/2018 • 2 minutes to read • Edit Online

Applies to
Windows 10
Windows Server 2016
Trusted Platform Module (TPM ) technology is designed to provide hardware-based, security-related functions. A
TPM chip is a secure crypto-processor that helps you with actions such as generating, storing, and limiting the use
of cryptographic keys. The following topics provide details.

TOPIC DESCRIPTION

Trusted Platform Module Overview Provides an overview of the Trusted Platform Module (TPM)
and how Windows uses it for access control and
authentication.

TPM fundamentals Provides background about how a TPM can work with
cryptographic keys. Also describes technologies that work
with the TPM, such as TPM-based virtual smart cards.

TPM Group Policy settings Describes TPM services that can be controlled centrally by
using Group Policy settings.

Back up the TPM recovery information to AD DS For Windows 10, version 1511 and Windows 10, version
1507 only, describes how to back up a computer’s TPM
information to Active Directory Domain Services.

Troubleshoot the TPM Describes actions you can take through the TPM snap-in,
TPM.msc: view TPM status, troubleshoot TPM initialization,
and clear keys from the TPM. Also, for TPM 1.2 and Windows
10, version 1507 or 1511, describes how to turn the TPM on
or off.

Understanding PCR banks on TPM 2.0 devices Provides background about what happens when you switch
PCR banks on TPM 2.0 devices.

TPM recommendations Discusses aspects of TPMs such as the difference between

TPM 1.2 and 2.0, and the Windows 10 features for which a
TPM is required or recommended.
 Trusted Platform Module Technology Overview
1/7/2019 • 4 minutes to read • Edit Online

Applies to
Windows 10
Windows Server 2016
Windows Server 2019
This topic for the IT professional describes the Trusted Platform Module (TPM ) and how Windows uses it for
access control and authentication.

Feature description
Trusted Platform Module (TPM ) technology is designed to provide hardware-based, security-related functions. A
TPM chip is a secure crypto-processor that is designed to carry out cryptographic operations. The chip includes
multiple physical security mechanisms to make it tamper resistant, and malicious software is unable to tamper
with the security functions of the TPM. Some of the key advantages of using TPM technology are that you can:
Generate, store, and limit the use of cryptographic keys.
Use TPM technology for platform device authentication by using the TPM’s unique RSA key, which is
burned into itself.
Help ensure platform integrity by taking and storing security measurements.
The most common TPM functions are used for system integrity measurements and for key creation and use.
During the boot process of a system, the boot code that is loaded (including firmware and the operating system
components) can be measured and recorded in the TPM. The integrity measurements can be used as evidence for
how a system started and to make sure that a TPM -based key was used only when the correct software was used
to boot the system.
TPM -based keys can be configured in a variety of ways. One option is to make a TPM -based key unavailable
outside the TPM. This is good to mitigate phishing attacks because it prevents the key from being copied and used
without the TPM. TPM -based keys can also be configured to require an authorization value to use them. If too
many incorrect authorization guesses occur, the TPM will activate its dictionary attack logic and prevent further
authorization value guesses.
Different versions of the TPM are defined in specifications by the Trusted Computing Group (TCG ). For more
information, consult the TCG Web site.
Automatic initialization of the TPM with Windows 10
Starting with Windows 10, the operating system automatically initializes and takes ownership of the TPM. This
means that in most cases, we recommend that you avoid configuring the TPM through the TPM management
console, TPM.msc. There are a few exceptions, mostly related to resetting or performing a clean installation on a
PC. For more information, see Clear all the keys from the TPM. We're no longer actively developing the TPM
management console beginning with Windows Server 2019 and Windows 10, version 1809.
In certain specific enterprise scenarios limited to Windows 10, versions 1507 and 1511, Group Policy might be
used to back up the TPM owner authorization value in Active Directory. Because the TPM state persists across
operating system installations, this TPM information is stored in a location in Active Directory that is separate
from computer objects.
Practical applications
Certificates can be installed or created on computers that are using the TPM. After a computer is provisioned, the
RSA private key for a certificate is bound to the TPM and cannot be exported. The TPM can also be used as a
replacement for smart cards, which reduces the costs associated with creating and disbursing smart cards.
Automated provisioning in the TPM reduces the cost of TPM deployment in an enterprise. New APIs for TPM
management can determine if TPM provisioning actions require physical presence of a service technician to
approve TPM state change requests during the boot process.
Antimalware software can use the boot measurements of the operating system start state to prove the integrity of
a computer running Windows 10 or Windows Server 2016. These measurements include the launch of Hyper-V
to test that datacenters using virtualization are not running untrusted hypervisors. With BitLocker Network
Unlock, IT administrators can push an update without concerns that a computer is waiting for PIN entry.
The TPM has several Group Policy settings that might be useful in certain enterprise scenarios. For more info, see
TPM Group Policy Settings.

New and changed functionality

For more info on new and changed functionality for Trusted Platform Module in Windows 10, see What's new in
Trusted Platform Module?.

Device health attestation

Device health attestation enables enterprises to establish trust based on hardware and software components of a
managed device. With device heath attestation, you can configure an MDM server to query a health attestation
service that will allow or deny a managed device access to a secure resource.
Some things that you can check on the device are:
Is Data Execution Prevention supported and enabled?
Is BitLocker Drive Encryption supported and enabled?
Is SecureBoot supported and enabled?

NOTE
Windows 10, Windows Server 2016 and Windows Server 2019 support Device Health Attestation with TPM 2.0. Support for
TPM 1.2 was added beginning with Windows version 1607 (RS1). TPM 2.0 requires UEFI firmware. A computer with legacy
BIOS and TPM 2.0 won't work as expected.

Supported versions for device health attestation

TPM VERSION WINDOWS 10 WINDOWS SERVER 2016 WINDOWS SERVER 2019

TPM 1.2 >= ver 1607 >= ver 1607 Yes

TPM 2.0 Yes Yes Yes

Related topics
Trusted Platform Module (list of topics)
TPM Cmdlets in Windows PowerShell
Prepare your organization for BitLocker: Planning and Policies - TPM configurations
 TPM fundamentals
10/29/2018 • 11 minutes to read • Edit Online

Applies to
Windows 10
Windows Server 2016
This topic for the IT professional provides a description of the components of the Trusted Platform Module (TPM
1.2 and TPM 2.0) and explains how they are used to mitigate dictionary attacks.
A Trusted Platform Module (TPM ) is a microchip designed to provide basic security-related functions, primarily
involving encryption keys. The TPM is usually installed on the motherboard of a computer, and it communicates
with the remainder of the system by using a hardware bus.
Computers that incorporate a TPM can create cryptographic keys and encrypt them so that they can only be
decrypted by the TPM. This process, often called wrapping or binding a key, can help protect the key from
disclosure. Each TPM has a master wrapping key, called the storage root key, which is stored within the TPM itself.
The private portion of a storage root key or endorsement key that is created in a TPM is never exposed to any
other component, software, process, or user.
You can specify whether encryption keys that are created by the TPM can be migrated or not. If you specify that
they can be migrated, the public and private portions of the key can be exposed to other components, software,
processes, or users. If you specify that encryption keys cannot be migrated, the private portion of the key is never
exposed outside the TPM.
Computers that incorporate a TPM can also create a key that has not only been wrapped, but is also tied to certain
platform measurements. This type of key can be unwrapped only when those platform measurements have the
same values that they had when the key was created. This process is referred to as “sealing the key to the TPM.”
Decrypting the key is called unsealing. The TPM can also seal and unseal data that is generated outside the TPM.
With this sealed key and software, such as BitLocker Drive Encryption, you can lock data until specific hardware or
software conditions are met.
With a TPM, private portions of key pairs are kept separate from the memory that is controlled by the operating
system. Keys can be sealed to the TPM, and certain assurances about the state of a system (assurances that define
the trustworthiness of a system) can be made before the keys are unsealed and released for use. Because the TPM
uses its own internal firmware and logic circuits to process instructions, it does not rely on the operating system,
and it is not exposed to vulnerabilities that might exist in the operating system or application software.
For info about which versions of Windows support which versions of the TPM, see Trusted Platform Module
technology overview. The features that are available in the versions are defined in specifications by the Trusted
Computing Group (TCG ). For more info, see the Trusted Platform Module page on the Trusted Computing Group
website: Trusted Platform Module.
The following sections provide an overview of the technologies that support the TPM:
Measured Boot with support for attestation
TPM -based Virtual Smart Card
TPM -based certificate storage
TPM Cmdlets
 Physical presence interface
TPM 1.2 states and initialization
Endorsement keys
TPM Key Attestation
Anti-hammering
The following topic describes the TPM Services that can be controlled centrally by using Group Policy settings:
TPM Group Policy Settings.

Measured Boot with support for attestation

The Measured Boot feature provides antimalware software with a trusted (resistant to spoofing and tampering)
log of all boot components. Antimalware software can use the log to determine whether components that ran
before it are trustworthy versus infected with malware. It can also send the Measured Boot logs to a remote server
for evaluation. The remote server can initiate remediation actions by interacting with software on the client or
through out-of-band mechanisms, as appropriate.

TPM-based Virtual Smart Card

The Virtual Smart Card emulates the functionality of traditional smart cards, but Virtual Smart Cards use the TPM
chip that is available on an organization’s computers, rather than requiring the use of a separate physical smart
card and reader. This greatly reduces the management and deployment cost of smart cards in an enterprise. To the
end user, the Virtual Smart Card is always available on the computer. If a user needs to use more than one
computer, a Virtual Smart Card must be issued to the user for each computer. A computer that is shared among
multiple users can host multiple Virtual Smart Cards, one for each user.

TPM-based certificate storage

The TPM can be used to protect certificates and RSA keys. The TPM key storage provider (KSP ) provides easy,
convenient use of the TPM as a way of strongly protecting private keys. The TPM KSP can be used to generate
keys when an organization enrolls for certificates, and the KSP is managed by templates in the UI. The TPM can
also be used to protect certificates that are imported from an outside source. TPM -based certificates can be used
exactly as standard certificates with the added functionality that the certificate can never leave the TPM from which
the keys were generated. The TPM can now be used for crypto-operations through Cryptography API: Next
Generation (CNG ). For more info, see Cryptography API: Next Generation.

TPM Cmdlets
You can manage the TPM using Windows PowerShell. For details, see TPM Cmdlets in Windows PowerShell.

Physical presence interface

For TPM 1.2, the TCG specifications for TPMs require physical presence (typically, pressing a key) for turning the
TPM on, turning it off, or clearing it. These actions typically cannot be automated with scripts or other automation
tools unless the individual OEM supplies them.

TPM 1.2 states and initialization

For TPM 1.2, there are multiple possible states. Windows 10 automatically initializes the TPM, which brings it to an
enabled, activated, and owned state.

Endorsement keys
Endorsement keys
For a TPM to be usable by a trusted application, it must contain an endorsement key, which is an RSA key pair. The
private half of the key pair is held inside the TPM, and it is never revealed or accessible outside the TPM.

Key attestation
TPM key attestation allows a certification authority to verify that a private key is actually protected by a TPM and
that the TPM is one that the certification authority trusts. Endorsement keys which have been proven valid can be
used to bind the user identity to a device. Moreover, the user certificate with a TPM attested key provides higher
security assurance backed up by the non-exportability, anti-hammering, and isolation of keys provided by a TPM.

Anti-hammering
When a TPM processes a command, it does so in a protected environment, for example, a dedicated
microcontroller on a discrete chip or a special hardware-protected mode on the main CPU. A TPM can be used to
create a cryptographic key that is not disclosed outside the TPM, but is able to be used in the TPM after the correct
authorization value is provided.
TPMs have anti-hammering protection that is designed to prevent brute force attacks, or more complex dictionary
attacks, that attempt to determine authorization values for using a key. The basic approach is for the TPM to allow
only a limited number of authorization failures before it prevents more attempts to use keys and locks. Providing a
failure count for individual keys is not technically practical, so TPMs have a global lockout when too many
authorization failures occur.
Because many entities can use the TPM, a single authorization success cannot reset the TPM’s anti-hammering
protection. This prevents an attacker from creating a key with a known authorization value and then using it to
reset the TPM’s protection. Generally, TPMs are designed to forget about authorization failures after a period of
time so the TPM does not enter a lockout state unnecessarily. A TPM owner password can be used to reset the
TPM’s lockout logic.
TPM 2.0 anti-hammering
TPM 2.0 has well defined anti-hammering behavior. This is in contrast to TPM 1.2 for which the anti-hammering
protection was implemented by the manufacturer, and the logic varied widely throughout the industry.
For systems with TPM 2.0, the TPM is configured by Windows to lock after 32 authorization failures and to forget
one authorization failure every two hours. This means that a user could quickly attempt to use a key with the
wrong authorization value 32 times. For each of the 32 attempts, the TPM records if the authorization value was
correct or not. This inadvertently causes the TPM to enter a locked state after 32 failed attempts.
Attempts to use a key with an authorization value for the next two hours would not return success or failure;
instead the response indicates that the TPM is locked. After two hours, one authorization failure is forgotten and
the number of authorization failures remembered by the TPM drops to 31, so the TPM leaves the locked state and
returns to normal operation. With the correct authorization value, keys could be used normally if no authorization
failures occur during the next two hours. If a period of 64 hours elapses with no authorization failures, the TPM
does not remember any authorization failures, and 32 failed attempts could occur again.
Windows 8 Certification does not require TPM 2.0 systems to forget about authorization failures when the system
is fully powered off or when the system has hibernated. Windows does require that authorization failures are
forgotten when the system is running normally, in a sleep mode, or in low power states other than off. If a
Windows system with TPM 2.0 is locked, the TPM leaves lockout mode if the system is left on for two hours.
The anti-hammering protection for TPM 2.0 can be fully reset immediately by sending a reset lockout command to
the TPM and providing the TPM owner password. By default, Windows automatically provisions TPM 2.0 and
stores the TPM owner password for use by system administrators.
In some enterprise situations, the TPM owner authorization value is configured to be stored centrally in Active
Directory, and it is not stored on the local system. An administrator can launch the TPM MMC and choose to reset
the TPM lockout time. If the TPM owner password is stored locally, it is used to reset the lockout time. If the TPM
owner password is not available on the local system, the administrator needs to provide it. If an administrator
attempts to reset the TPM lockout state with the wrong TPM owner password, the TPM does not allow another
attempt to reset the lockout state for 24 hours.
TPM 2.0 allows some keys to be created without an authorization value associated with them. These keys can be
used when the TPM is locked. For example, BitLocker with a default TPM -only configuration is able to use a key in
the TPM to start Windows, even when the TPM is locked.
Rationale behind the defaults
Originally, BitLocker allowed from 4 to 20 characters for a PIN. Windows Hello has its own PIN for logon, which
can be 4 to 127 characters. Both BitLocker and Windows Hello use the TPM to prevent PIN brute-force attacks.
The TPM can be configured to use Dictionary Attack Prevention parameters (lockout threshold and lockout
duration) to control how many failed authorizations attempts are allowed before the TPM is locked out, and how
much time must elapse before another attempt can be made.
The Dictionary Attack Prevention Parameters provide a way to balance security needs with usability. For example,
when BitLocker is used with a TPM + PIN configuration, the number of PIN guesses is limited over time. A TPM
2.0 in this example could be configured to allow only 32 PIN guesses immediately, and then only one more guess
every two hours. This totals a maximum of about 4415 guesses per year. If the PIN is 4 digits, all 9999 possible
PIN combinations could be attempted in a little over two years.
Increasing the PIN length requires a greater number of guesses for an attacker. In that case, the lockout duration
between each guess can be shortened to allow legitimate users to retry a failed attempt sooner, while maintaining
a similar level of protection.
Beginning with Windows 10, version 1703, the minimum length for the BitLocker PIN was increased to 6
characters to better align with other Windows features that leverage TPM 2.0, including Windows Hello. To help
organizations with the transition, beginning with Windows 10, version 1709 and Windows 10, version 1703 with
the October 2017 cumulative update installed, the BitLocker PIN length is 6 characters by default, but it can be
reduced to 4 characters. If the minimum PIN length is reduced from the default of six characters, then the TPM 2.0
lockout period will be extended.
TPM -based smart cards
The Windows TPM -based smart card, which is a virtual smart card, can be configured to allow sign in to the
system. In contrast with physical smart cards, the sign-in process uses a TPM -based key with an authorization
value. The following list shows the advantages of virtual smart cards:
Physical smart cards can enforce lockout for only the physical smart card PIN, and they can reset the
lockout after the correct PIN is entered. With a virtual smart card, the TPM’s anti-hammering protection is
not reset after a successful authentication. The allowed number of authorization failures before the TPM
enters lockout includes many factors.
Hardware manufacturers and software developers have the option to use the security features of the TPM
to meet their requirements.
The intent of selecting 32 failures as the lock-out threshold is so users rarely lock the TPM (even when
learning to type new passwords or if they frequently lock and unlock their computers). If users lock the
TPM, they must to wait two hours or use some other credential to sign in, such as a user name and
password.

Related topics
Trusted Platform Module (list of topics)
TPM Cmdlets in Windows PowerShell
TPM WMI providers
Prepare your organization for BitLocker: Planning and Policies - TPM configurations
 How Windows 10 uses the Trusted Platform Module
10/10/2018 • 23 minutes to read • Edit Online

The Windows 10 operating system improves most existing security features in the operating system and adds
groundbreaking new security features such as Device Guard and Windows Hello for Business. It places hardware-
based security deeper inside the operating system than previous Windows versions had done, maximizing platform
security while increasing usability. To achieve many of these security enhancements, Windows 10 makes extensive
use of the Trusted Platform Module (TPM ). This article offers a brief overview of the TPM, describes how it works,
and discusses the benefits that TPM brings to Windows 10—as well as the cumulative security impact of running
Windows 10 on a PC that contains a TPM.
See also:
Windows 10 Specifications
TPM Fundamentals
TPM Recommendations 

TPM Overview
The TPM is a cryptographic module that enhances computer security and privacy. Protecting data through
encryption and decryption, protecting authentication credentials, and proving which software is running on a
system are basic functionalities associated with computer security. The TPM helps with all these scenarios and
more.
Historically, TPMs have been discrete chips soldered to a computer’s motherboard. Such implementations allow
the computer’s original equipment manufacturer (OEM ) to evaluate and certify the TPM separate from the rest of
the system. Although discrete TPM implementations are still common, they can be problematic for integrated
devices that are small or have low power consumption. Some newer TPM implementations integrate TPM
functionality into the same chipset as other platform components while still providing logical separation similar to
discrete TPM chips.
TPMs are passive: they receive commands and return responses. To realize the full benefit of a TPM, the OEM must
carefully integrate system hardware and firmware with the TPM to send it commands and react to its responses.
TPMs were originally designed to provide security and privacy benefits to a platform’s owner and users, but newer
versions can provide security and privacy benefits to the system hardware itself. Before it can be used for advanced
scenarios, a TPM must be provisioned. Windows 10 automatically provisions a TPM, but if the user reinstalls the
operating system, he or she may need to tell the operating system to explicitly provision the TPM again before it
can use all the TPM’s features.
The Trusted Computing Group (TCG ) is the nonprofit organization that publishes and maintains the TPM
specification. The TCG exists to develop, define, and promote vendor-neutral, global industry standards that
support a hardware-based root of trust for interoperable trusted computing platforms. The TCG also publishes the
TPM specification as the international standard ISO/IEC 11889, using the Publicly Available Specification
Submission Process that the Joint Technical Committee 1 defines between the International Organization for
Standardization (ISO ) and the International Electrotechnical Commission (IEC ).
OEMs implement the TPM as a component in a trusted computing platform, such as a PC, tablet, or phone. Trusted
computing platforms use the TPM to support privacy and security scenarios that software alone cannot achieve.
For example, software alone cannot reliably report whether malware is present during the system startup process.
The close integration between TPM and platform increases the transparency of the startup process and supports
evaluating device health by enabling reliable measuring and reporting of the software that starts the device.
Implementation of a TPM as part of a trusted computing platform provides a hardware root of trust—that is, it
behaves in a trusted way. For example, if a key stored in a TPM has properties that disallow exporting the key, that
key truly cannot leave the TPM.
The TCG designed the TPM as a low -cost, mass-market security solution that addresses the requirements of
different customer segments. There are variations in the security properties of different TPM implementations just
as there are variations in customer and regulatory requirements for different sectors. In public-sector procurement,
for example, some governments have clearly defined security requirements for TPMs, whereas others do not.
Certification programs for TPMs—and technology in general—continue to evolve as the speed of innovation
increases. Although having a TPM is clearly better than not having a TPM, Microsoft’s best advice is to determine
your organization’s security needs and research any regulatory requirements associated with procurement for your
industry. The result is a balance between scenarios used, assurance level, cost, convenience, and availability.

TPM in Windows 10
The security features of Windows 10 combined with the benefits of a TPM offer practical security and privacy
benefits. The following sections start with major TPM -related security features in Windows 10 and go on to
describe how key technologies use the TPM to enable or increase security.

Platform Crypto Provider

Windows includes a cryptography framework called Cryptographic API: Next Generation (CNG ), the basic
approach of which is to implement cryptographic algorithms in different ways but with a common application
programming interface (API). Applications that use cryptography can use the common API without knowing the
details of how an algorithm is implemented much less the algorithm itself.
Although CNG sounds like a mundane starting point, it illustrates some of the advantages that a TPM provides.
Underneath the CNG interface, Windows or third parties supply a cryptographic provider (that is, an
implementation of an algorithm) implemented as software libraries alone or in a combination of software and
available system hardware or third-party hardware. If implemented through hardware, the cryptographic provider
communicates with the hardware behind the software interface of CNG.
The Platform Crypto Provider, introduced in the Windows 8 operating system, exposes the following special TPM
properties, which software-only CNG providers cannot offer or cannot offer as effectively:
• Key protection. The Platform Crypto Provider can create keys in the TPM with restrictions on their use. The
operating system can load and use the keys in the TPM without copying the keys to system memory, where they
are vulnerable to malware. The Platform Crypto Provider can also configure keys that a TPM protects so that they
are not removable. If a TPM creates a key, the key is unique and resides only in that TPM. If the TPM imports a key,
the Platform Crypto Provider can use the key in that TPM, but that TPM is not a source for making additional
copies of the key or enabling the use of copies elsewhere. In sharp contrast, software solutions that protect keys
from copying are subject to reverse-engineering attacks, in which someone figures out how the solution stores
keys or makes copies of keys while they are in memory during use.
• Dictionary attack protection. Keys that a TPM protects can require an authorization value such as a PIN. With
dictionary attack protection, the TPM can prevent attacks that attempt a large number of guesses to determine the
PIN. After too many guesses, the TPM simply returns an error saying no more guesses are allowed for a period of
time. Software solutions might provide similar features, but they cannot provide the same level of protection,
especially if the system restarts, the system clock changes, or files on the hard disk that count failed guesses are
rolled back. In addition, with dictionary attack protection, authorization values such as PINs can be shorter and
easier to remember while still providing the same level of protection as more complex values when using software
solutions.
These TPM features give Platform Crypto Provider distinct advantages over software-based solutions. A practical
way to see these benefits in action is when using certificates on a Windows 10 device. On platforms that include a
TPM, Windows can use the Platform Crypto Provider to provide certificate storage. Certificate templates can
specify that a TPM use the Platform Crypto Provider to protect the key associated with a certificate. In mixed
environments, where some computers might not have a TPM, the certificate template could simply prefer the
Platform Crypto Provider over the standard Windows software provider. If a certificate is configured as not able to
be exported, the private key for the certificate is restricted and cannot be exported from the TPM. If the certificate
requires a PIN, the PIN gains the TPM’s dictionary attack protection automatically.

Virtual Smart Card

Smart cards are highly secure physical devices that typically store a single certificate and the corresponding private
key. Users insert a smart card into a built-in or USB card reader and enter a PIN to unlock it. Windows can then
access the card’s certificate and use the private key for authentication or to unlock BitLocker protected data
volumes. Smart cards are popular because they provide two-factor authentication that requires both something the
user has (that is, the smart card) and something the user knows (such as the smart card PIN ). Smart cards are
difficult to use, however, because they require purchase and deployment of both smart cards and smart card
readers.
In Windows, the Virtual Smart Card feature allows the TPM to mimic a permanently inserted smart card. The TPM
becomes “something the user has” but still requires a PIN. Although physical smart cards limit the number of PIN
attempts before locking the card and requiring a reset, a virtual smart card relies on the TPM’s dictionary attack
protection to prevent too many PIN guesses.
For TPM -based virtual smart cards, the TPM protects the use and storage of the certificate private key so that it
cannot be copied when it is in use or stored and used elsewhere. Using a component that is part of the system
rather than a separate physical smart card can reduce total cost of ownership because it eliminates “lost card” and
“card left at home” scenarios while still delivering the benefits of smart card–based multifactor authentication. For
users, virtual smart cards are simple to use, requiring only a PIN to unlock. Virtual smart cards support the same
scenarios that physical smart cards support, including signing in to Windows or authenticating for resource access.

Windows Hello for Business

Windows Hello for Business provides authentication methods intended to replace passwords, which can be difficult
to remember and easily compromised. In addition, user name - password solutions for authentication often reuse
the same user name – password combinations on multiple devices and services; if those credentials are
compromised, they are compromised in many places. Windows Hello for Business provisions devices one by one
and combines the information provisioned on each device (i.e., the cryptographic key) with additional information
to authenticate users. On a system that has a TPM, the TPM can protect the key. If a system does not have a TPM,
software-based techniques protect the key. The additional information the user supplies can be a PIN value or, if
the system has the necessary hardware, biometric information, such as fingerprint or facial recognition. To protect
privacy, the biometric information is used only on the provisioned device to access the provisioned key: it is not
shared across devices.
The adoption of new authentication technology requires that identity providers and organizations deploy and use
that technology. Windows Hello for Business lets users authenticate with their existing Microsoft account, an Active
Directory account, a Microsoft Azure Active Directory account, or even non-Microsoft Identity Provider Services or
Relying Party Services that support Fast ID Online V2.0 authentication.
Identity providers have flexibility in how they provision credentials on client devices. For example, an organization
might provision only those devices that have a TPM so that the organization knows that a TPM protects the
credentials. The ability to distinguish a TPM from malware acting like a TPM requires the following TPM
capabilities (see Figure 1):
• Endorsement key. The TPM manufacturer can create a special key in the TPM called an endorsement key. An
endorsement key certificate, signed by the manufacturer, says that the endorsement key is present in a TPM that
the manufacturer made. Solutions can use the certificate with the TPM containing the endorsement key to confirm
a scenario really involves a TPM from a specific TPM manufacturer (instead of malware acting like a TPM.
• Attestation identity key. To protect privacy, most TPM scenarios do not directly use an actual endorsement key.
Instead, they use attestation identity keys, and an identity certificate authority (CA) uses the endorsement key and
its certificate to prove that one or more attestation identity keys actually exist in a real TPM. The identity CA issues
attestation identity key certificates. More than one identity CA will generally see the same endorsement key
certificate that can uniquely identify the TPM, but any number of attestation identity key certificates can be created
to limit the information shared in other scenarios.

Figure 1: TPM Cryptographic Key Management

For Windows Hello for Business, Microsoft can fill the role of the identity CA. Microsoft services can issue an
attestation identity key certificate for each device, user, and identify provider to ensure that privacy is protected and
to help identity providers ensure that device TPM requirements are met before Windows Hello for Business
credentials are provisioned.

BitLocker Drive Encryption

BitLocker provides full-volume encryption to protect data at rest. The most common device configuration splits the
hard drive into several volumes. The operating system and user data reside on one volume that holds confidential
information, and other volumes hold public information such as boot components, system information and
recovery tools. (These other volumes are used infrequently enough that they do not need to be visible to users.)
Without additional protections in place, if the volume containing the operating system and user data is not
encrypted, someone can boot another operating system and easily bypass the intended operating system’s
enforcement of file permissions to read any user data.
In the most common configuration, BitLocker encrypts the operating system volume so that if the computer or
hard disk is lost or stolen when powered off, the data on the volume remains confidential. When the computer is
turned on, starts normally, and proceeds to the Windows logon prompt, the only path forward is for the user to log
on with his or her credentials, allowing the operating system to enforce its normal file permissions. If something
about the boot process changes, however—for example, a different operating system is booted from a USB device
—the operating system volume and user data cannot be read and are not accessible. The TPM and system
firmware collaborate to record measurements of how the system started, including loaded software and
configuration details such as whether boot occurred from the hard drive or a USB device. BitLocker relies on the
TPM to allow the use of a key only when startup occurs in an expected way. The system firmware and TPM are
carefully designed to work together to provide the following capabilities:
• Hardware root of trust for measurement. A TPM allows software to send it commands that record
measurements of software or configuration information. This information can be calculated using a hash algorithm
that essentially transforms a lot of data into a small, statistically unique hash value. The system firmware has a
component called the Core Root of Trust for Measurement (CRTM ) that is implicitly trusted. The CRTM
unconditionally hashes the next software component and records the measurement value by sending a command
to the TPM. Successive components, whether system firmware or operating system loaders, continue the process
by measuring any software components they load before running them. Because each component’s measurement
is sent to the TPM before it runs, a component cannot erase its measurement from the TPM. (However,
measurements are erased when the system is restarted.) The result is that at each step of the system startup
process, the TPM holds measurements of boot software and configuration information. Any changes in boot
software or configuration yield different TPM measurements at that step and later steps. Because the system
firmware unconditionally starts the measurement chain, it provides a hardware-based root of trust for the TPM
measurements. At some point in the startup process, the value of recording all loaded software and configuration
information diminishes and the chain of measurements stops. The TPM allows for the creation of keys that can be
used only when the platform configuration registers that hold the measurements have specific values.
• Key used only when boot measurements are accurate. BitLocker creates a key in the TPM that can be used
only when the boot measurements match an expected value. The expected value is calculated for the step in the
startup process when Windows Boot Manager runs from the operating system volume on the system hard drive.
Windows Boot Manager, which is stored unencrypted on the boot volume, needs to use the TPM key so that it can
decrypt data read into memory from the operating system volume and startup can proceed using the encrypted
operating system volume. If a different operating system is booted or the configuration is changed, the
measurement values in the TPM will be different, the TPM will not let Windows Boot Manager use the key, and the
startup process cannot proceed normally because the data on the operating system cannot be decrypted. If
someone tries to boot the system with a different operating system or a different device, the software or
configuration measurements in the TPM will be wrong and the TPM will not allow use of the key needed to
decrypt the operating system volume. As a failsafe, if measurement values change unexpectedly, the user can
always use the BitLocker recovery key to access volume data. Organizations can configure BitLocker to store the
recovery key in Active Directory Domain Services (AD DS ).
Device hardware characteristics are important to BitLocker and its ability to protect data. One consideration is
whether the device provides attack vectors when the system is at the logon screen. For example, if the Windows
device has a port that allows direct memory access so that someone can plug in hardware and read memory, an
attacker can read the operating system volume’s decryption key from memory while at the Windows logon screen.
To mitigate this risk, organizations can configure BitLocker so that the TPM key requires both the correct software
measurements and an authorization value. The system startup process stops at Windows Boot Manager, and the
user is prompted to enter the authorization value for the TPM key or insert a USB device with the value. This
process stops BitLocker from automatically loading the key into memory where it might be vulnerable, but has a
less desirable user experience.
Newer hardware and Windows 10 work better together to disable direct memory access through ports and reduce
attack vectors. The result is that organizations can deploy more systems without requiring users to enter additional
authorization information during the startup process. The right hardware allows BitLocker to be used with the
“TPM -only” configuration giving users a single sign-on experience without having to enter a PIN or USB key
during boot.

Device Encryption
Device Encryption is the consumer version of BitLocker, and it uses the same underlying technology. How it works
is if a customer logs on with a Microsoft account and the system meets Modern Standby hardware requirements,
BitLocker Drive Encryption is enabled automatically in Windows 10. The recovery key is backed up in the Microsoft
cloud and is accessible to the consumer through his or her Microsoft account. The Modern Standby hardware
requirements inform Windows 10 that the hardware is appropriate for deploying Device Encryption and allows use
of the “TPM -only” configuration for a simple consumer experience. In addition, Modern Standby hardware is
designed to reduce the likelihood that measurement values change and prompt the customer for the recovery key.
For software measurements, Device Encryption relies on measurements of the authority providing software
components (based on code signing from manufacturers such as OEMs or Microsoft) instead of the precise hashes
of the software components themselves. This permits servicing of components without changing the resulting
measurement values. For configuration measurements, the values used are based on the boot security policy
instead of the numerous other configuration settings recorded during startup. These values also change less
frequently. The result is that Device Encryption is enabled on appropriate hardware in a user-friendly way while
also protecting data.

Measured Boot
Windows 8 introduced Measured Boot as a way for the operating system to record the chain of measurements of
software components and configuration information in the TPM through the initialization of the Windows
operating system. In previous Windows versions, the measurement chain stopped at the Windows Boot Manager
component itself, and the measurements in the TPM were not helpful for understanding the starting state of
Windows.
The Windows boot process happens in stages and often involves third-party drivers to communicate with vendor-
specific hardware or implement antimalware solutions. For software, Measured Boot records measurements of the
Windows kernel, Early-Launch Anti-Malware drivers, and boot drivers in the TPM. For configuration settings,
Measured Boot records security-relevant information such as signature data that antimalware drivers use and
configuration data about Windows security features (e.g., whether BitLocker is on or off).
Measured Boot ensures that TPM measurements fully reflect the starting state of Windows software and
configuration settings. If security settings and other protections are set up correctly, they can be trusted to maintain
the security of the running operating system thereafter. Other scenarios can use the operating system’s starting
state to determine whether the running operating system should be trusted.
TPM measurements are designed to avoid recording any privacy-sensitive information as a measurement. As an
additional privacy protection, Measured Boot stops the measurement chain at the initial starting state of Windows.
Therefore, the set of measurements does not include details about which applications are in use or how Windows
is being used. Measurement information can be shared with external entities to show that the device is enforcing
adequate security policies and did not start with malware.
The TPM provides the following way for scenarios to use the measurements recorded in the TPM during boot:
• Remote Attestation. Using an attestation identity key, the TPM can generate and cryptographically sign a
statement (orquote) of the current measurements in the TPM. Windows 10 can create unique attestation identity
keys for various scenarios to prevent separate evaluators from collaborating to track the same device. Additional
information in the quote is cryptographically scrambled to limit information sharing and better protect privacy. By
sending the quote to a remote entity, a device can attest which software and configuration settings were used to
boot the device and initialize the operating system. An attestation identity key certificate can provide further
assurance that the quote is coming from a real TPM. Remote attestation is the process of recording measurements
in the TPM, generating a quote, and sending the quote information to another system that evaluates the
measurements to establish trust in a device. Figure 2 illustrates this process.
When new security features are added to Windows, Measured Boot adds security-relevant configuration
information to the measurements recorded in the TPM. Measured Boot enables remote attestation scenarios that
reflect the system firmware and the Windows initialization state.
Figure 2: Process used to create evidence of boot software and configuration using a TPM

Health Attestation
Some Windows 10 improvements help security solutions implement remote attestation scenarios. Microsoft
provides a Health Attestation service, which can create attestation identity key certificates for TPMs from different
manufacturers as well as parse measured boot information to extract simple security assertions, such as whether
BitLocker is on or off. The simple security assertions can be used to evaluate device health.
Mobile device management (MDM ) solutions can receive simple security assertions from the Microsoft Health
Attestation service for a client without having to deal with the complexity of the quote or the detailed TPM
measurements. MDM solutions can act on the security information by quarantining unhealthy devices or blocking
access to cloud services such as Microsoft Office 365.

Credential Guard
Credential Guard is a new feature in Windows 10 that helps protect Windows credentials in organizations that
have deployed AD DS. Historically, a user’s credentials (e.g., logon password) were hashed to generate an
authorization token. The user employed the token to access resources that he or she was permitted to use. One
weakness of the token model is that malware that had access to the operating system kernel could look through
the computer’s memory and harvest all the access tokens currently in use. The attacker could then use harvested
tokens to log on to other machines and collect more credentials. This kind of attack is called a “pass the hash”
attack, a malware technique that infects one machine to infect many machines across an organization.
Similar to the way Microsoft Hyper-V keeps virtual machines (VMs) separate from one another, Credential Guard
uses virtualization to isolate the process that hashes credentials in a memory area that the operating system kernel
cannot access. This isolated memory area is initialized and protected during the boot process so that components
in the larger operating system environment cannot tamper with it. Credential Guard uses the TPM to protect its
keys with TPM measurements, so they are accessible only during the boot process step when the separate region is
initialized; they are not available for the normal operating system kernel. The local security authority code in the
Windows kernel interacts with the isolated memory area by passing in credentials and receiving single-use
authorization tokens in return.
The resulting solution provides defense in depth, because even if malware runs in the operating system kernel, it
cannot access the secrets inside the isolated memory area that actually generates authorization tokens. The
solution does not solve the problem of key loggers because the passwords such loggers capture actually pass
through the normal Windows kernel, but when combined with other solutions, such as smart cards for
authentication, Credential Guard greatly enhances the protection of credentials in Windows 10.

Conclusion
The TPM adds hardware-based security benefits to Windows 10. When installed on hardware that includes a TPM,
Window 10 delivers remarkably improved security benefits. The following table summarizes the key benefits of the
TPM’s major features.

FEATURE BENEFITS WHEN USED ON A SYSTEM WITH A TPM

Platform Crypto Provider • If the machine is compromised, the private key associated
with the certificate cannot be copied off the device.
• The TPM’s dictionary attack mechanism protects PIN
values to use a certificate.

Virtual Smart Card • Achieve security similar to that of physical smart cards
without deploying physical smart cards or card readers.

Windows Hello for Business • Credentials provisioned on a device cannot be copied

elsewhere.
• Confirm a device’s TPM before credentials are provisioned.

BitLocker Drive Encryption • Multiple options are available for enterprises to protect
data at rest while balancing security requirements with
different device hardware.

Device Encryption • With a Microsoft account and the right hardware,

consumers’ devices seamlessly benefit from data-at-rest
protection.

Measured Boot • A hardware root of trust contains boot measurements

that help detect malware during remote attestation.

Health Attestation • MDM solutions can easily perform remote attestation and
evaluate client health before granting access to resources or
cloud services such as Office 365.

Credential Guard • Defense in depth increases so that even if malware has

administrative rights on one machine, it is significantly more
difficult to compromise additional machines in an organization.

Although some of the aforementioned features have additional hardware requirements (e.g., virtualization
support), the TPM is a cornerstone of Windows 10 security. Microsoft and other industry stakeholders continue to
improve the global standards associated with TPM and find more and more applications that use it to provide
tangible benefits to customers. Microsoft has included support for most TPM features in its version of Windows
for the Internet of Things (IoT) called Windows 10 IoT Core. IoT devices that might be deployed in insecure
physical locations and connected to cloud services like Azure IoT Hub for management can use the TPM in
innovative ways to address their emerging security requirements.
 TPM Group Policy settings
10/2/2018 • 9 minutes to read • Edit Online

Applies to
Windows 10
Windows Server 2016 and later
This topic describes the Trusted Platform Module (TPM ) Services that can be controlled centrally by using Group
Policy settings.
The Group Policy settings for TPM services are located at:
Computer Configuration\Administrative Templates\System\Trusted Platform Module Services\
The following Group Policy settings were introduced in Windows 10.

Configure the level of TPM owner authorization information available

to the operating system
IMPORTANT
Beginning with Windows 10 version 1607 and Windows Server 2016, this policy setting is no longer used by Windows, but
it continues to appear in GPEdit.msc for compatibility with previous versions. Beginning with Windows 10 version 1703, the
default value is 5. This value is implemented during provisioning so that another Windows component can either delete it or
take ownership of it, depending on the system configuration. For TPM 2.0, a value of 5 means keep the lockout
authorization. For TPM 1.2, it means discard the Full TPM owner authorization and retain only the Delegated authorization.

This policy setting configured which TPM authorization values are stored in the registry of the local computer.
Certain authorization values are required in order to allow Windows to perform certain actions.

TPM 1.2 VALUE TPM 2.0 VALUE PURPOSE KEPT AT LEVEL 0? KEPT AT LEVEL 2? KEPT AT LEVEL 4?

OwnerAuthAdmi StorageOwnerAu Create SRK No Yes Yes

n th

OwnerAuthEndor EndorsementAut Create or use EK No Yes Yes

sement h (1.2 only: Create
AIK)

OwnerAuthFull LockoutAuth Reset/change No No No

Dictionary Attack
Protection

There are three TPM owner authentication settings that are managed by the Windows operating system. You can
choose a value of Full, Delegate, or None.
Full This setting stores the full TPM owner authorization, the TPM administrative delegation blob, and the
TPM user delegation blob in the local registry. With this setting, you can use the TPM without requiring
remote or external storage of the TPM owner authorization value. This setting is appropriate for scenarios
that do not require you to reset the TPM anti-hammering logic or change the TPM owner authorization
value. Some TPM -based applications may require that this setting is changed before features that depend
 on the TPM anti-hammering logic can be used. Full owner authorization in TPM 1.2 is similar to lockout
authorization in TPM 2.0. Owner authorization has a different meaning for TPM 2.0.
Delegated This setting stores only the TPM administrative delegation blob and the TPM user delegation
blob in the local registry. This setting is appropriate for use with TPM -based applications that depend on
the TPM antihammering logic. This is the default setting in Windows prior to version 1703.
None This setting provides compatibility with previous operating systems and applications. You can also
use it for scenarios when TPM owner authorization cannot be stored locally. Using this setting might cause
issues with some TPM -based applications.

NOTE
If the operating system managed TPM authentication setting is changed from Full to Delegated, the full TPM owner
authorization value will be regenerated, and any copies of the previously set TPM owner authorization value will be invalid.

Registry information
Registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\TPM
DWORD: OSManagedAuthLevel
The following table shows the TPM owner authorization values in the registry.

VALUE DATA SETTING

0 None

2 Delegated

4 Full

If you enable this policy setting, the Windows operating system will store the TPM owner authorization in the
registry of the local computer according to the TPM authentication setting you choose.
On Windows 10 prior to version 1607, if you disable or do not configure this policy setting, and the Turn on TPM
backup to Active Directory Domain Services policy setting is also disabled or not configured, the default
setting is to store the full TPM authorization value in the local registry. If this policy is disabled or not configured,
and the Turn on TPM backup to Active Directory Domain Services policy setting is enabled, only the
administrative delegation and the user delegation blobs are stored in the local registry.

Standard User Lockout Duration

This policy setting allows you to manage the duration in minutes for counting standard user authorization failures
for Trusted Platform Module (TPM ) commands requiring authorization. An authorization failure occurs each time
a standard user sends a command to the TPM and receives an error response that indicates an authorization
failure occurred. Authorization failures that are older than the duration you set are ignored. If the number of TPM
commands with an authorization failure within the lockout duration equals a threshold, a standard user is
prevented from sending commands that require authorization to the TPM.
The TPM is designed to protect itself against password guessing attacks by entering a hardware lockout mode
when it receives too many commands with an incorrect authorization value. When the TPM enters a lockout
mode, it is global for all users (including administrators) and for Windows features such as BitLocker Drive
Encryption.
This setting helps administrators prevent the TPM hardware from entering a lockout mode by slowing the speed
at which standard users can send commands that require authorization to the TPM.
For each standard user, two thresholds apply. Exceeding either threshold prevents the user from sending a
command that requires authorization to the TPM. Use the following policy settings to set the lockout duration:
Standard User Individual Lockout Threshold This value is the maximum number of authorization failures
that each standard user can have before the user is not allowed to send commands that require
authorization to the TPM.
Standard User Total Lockout Threshold This value is the maximum total number of authorization failures
that all standard users can have before all standard users are not allowed to send commands that require
authorization to the TPM.
An administrator with the TPM owner password can fully reset the TPM's hardware lockout logic by using the
Windows Defender Security Center. Each time an administrator resets the TPM's hardware lockout logic, all prior
standard user TPM authorization failures are ignored. This allows standard users to immediately use the TPM
normally.
If you do not configure this policy setting, a default value of 480 minutes (8 hours) is used.

Standard User Individual Lockout Threshold

This policy setting allows you to manage the maximum number of authorization failures for each standard user
for the Trusted Platform Module (TPM ). This value is the maximum number of authorization failures that each
standard user can have before the user is not allowed to send commands that require authorization to the TPM. If
the number of authorization failures for the user within the duration that is set for the Standard User Lockout
Duration policy setting equals this value, the standard user is prevented from sending commands that require
authorization to the Trusted Platform Module (TPM ).
This setting helps administrators prevent the TPM hardware from entering a lockout mode by slowing the speed
at which standard users can send commands that require authorization to the TPM.
An authorization failure occurs each time a standard user sends a command to the TPM and receives an error
response indicating an authorization failure occurred. Authorization failures older than the duration are ignored.
An administrator with the TPM owner password can fully reset the TPM's hardware lockout logic by using the
Windows Defender Security Center. Each time an administrator resets the TPM's hardware lockout logic, all prior
standard user TPM authorization failures are ignored. This allows standard users to immediately use the TPM
normally.
If you do not configure this policy setting, a default value of 4 is used. A value of zero means that the operating
system will not allow standard users to send commands to the TPM, which might cause an authorization failure.

Standard User Total Lockout Threshold

This policy setting allows you to manage the maximum number of authorization failures for all standard users for
the Trusted Platform Module (TPM ). If the total number of authorization failures for all standard users within the
duration that is set for the Standard User Lockout Duration policy equals this value, all standard users are
prevented from sending commands that require authorization to the Trusted Platform Module (TPM ).
This setting helps administrators prevent the TPM hardware from entering a lockout mode because it slows the
speed standard users can send commands requiring authorization to the TPM.
An authorization failure occurs each time a standard user sends a command to the TPM and receives an error
response indicating an authorization failure occurred. Authorization failures older than the duration are ignored.
An administrator with the TPM owner password can fully reset the TPM's hardware lockout logic by using the
Windows Defender Security Center. Each time an administrator resets the TPM's hardware lockout logic, all prior
standard user TPM authorization failures are ignored. This allows standard users to immediately use the TPM
normally.
If you do not configure this policy setting, a default value of 9 is used. A value of zero means that the operating
system will not allow standard users to send commands to the TPM, which might cause an authorization failure.

Configure the system to use legacy Dictionary Attack Prevention

Parameters setting for TPM 2.0
Introduced in Windows 10, version 1703, this policy setting configures the TPM to use the Dictionary Attack
Prevention Parameters (lockout threshold and recovery time) to the values that were used for Windows 10
Version 1607 and below.

IMPORTANT
Setting this policy will take effect only if:
The TPM was originally prepared using a version of Windows after Windows 10 Version 1607
The system has a TPM 2.0.

NOTE
Enabling this policy will only take effect after the TPM maintenance task runs (which typically happens after a system
restart). Once this policy has been enabled on a system and has taken effect (after a system restart), disabling it will have no
impact and the system's TPM will remain configured using the legacy Dictionary Attack Prevention parameters, regardless of
the value of this group policy. The only ways for the disabled setting of this policy to take effect on a system where it was
once enabled are to either:
Disable it from group policy
Clear the TPM on the system

TPM Group Policy settings in the Windows Security app

You can change what users see about TPM in the Windows Security app. The Group Policy settings for the TPM
area in the Windows Security app are located at:
Computer Configuration\Administrative Templates\Windows Components\Windows Security\Device
security

Disable the Clear TPM button

If you don't want users to be able to click the Clear TPM button in the Windows Security app, you can disable it
with this Group Policy setting. Select Enabled to make the Clear TPM button unavailable for use.

Hide the TPM Firmware Update recommendation

If you don't want users to see the recommendation to update TPM firmware, you can disable it with this setting.
Select Enabled to prevent users from seeing a recommendation to update their TPM firmware when a vulnerable
firmware is detected.

Related topics
Trusted Platform Module
TPM Cmdlets in Windows PowerShell
Prepare your organization for BitLocker: Planning and Policies - TPM configurations
 Back up the TPM recovery information to AD DS
9/12/2018 • 2 minutes to read • Edit Online

Applies to
Windows 10, version 1511
Windows 10, version 1507
Does not apply to
Windows 10, version 1607 or later
With Windows 10, versions 1511 and 1507, you can back up a computer’s Trusted Platform Module (TPM )
information to Active Directory Domain Services (AD DS ). By doing this, you can use AD DS to administer the
TPM from a remote computer. The procedure is the same as it was for Windows 8.1. For more information, see
Backup the TPM Recovery Information to AD DS.

Related topics
Trusted Platform Module (list of topics)
TPM Group Policy settings
 Troubleshoot the TPM
9/12/2018 • 7 minutes to read • Edit Online

Applies to
Windows 10
Windows Server 2016
This topic provides information for the IT professional to troubleshoot the Trusted Platform Module (TPM ):
Troubleshoot TPM initialization
Clear all the keys from the TPM
With TPM 1.2 and Windows 10, version 1507 or 1511, you can also take the following actions:
Turn on or turn off the TPM
For information about the TPM cmdlets, see TPM Cmdlets in Windows PowerShell.

About TPM initialization and ownership

Starting with Windows 10, the operating system automatically initializes and takes ownership of the TPM. This is a
change from previous operating systems, where you would initialize the TPM and create an owner password.

Troubleshoot TPM initialization

If you find that Windows is not able to initialize the TPM automatically, review the following information:
You can try clearing the TPM to the factory default values and allowing Windows to re-initialize it. For
important precautions for this process, and instructions for completing it, see Clear all the keys from the
TPM, later in this topic.
If the TPM is a TPM 2.0 and is not detected by Windows, verify that your computer hardware contains a
Unified Extensible Firmware Interface (UEFI) that is Trusted Computing Group-compliant. Also, ensure that
in the UEFI settings, the TPM has not been disabled or hidden from the operating system.
If you have TPM 1.2 with Windows 10, version 1507 or 1511, the TPM might be turned off, and need to be
turned back on, as described in Turn on the TPM. When it is turned back on, Windows will re-initialize it.
If you are attempting to set up BitLocker with the TPM, check which TPM driver is installed on the
computer. We recommend always using one of the TPM drivers that is provided by Microsoft and is
protected with BitLocker. If a non-Microsoft TPM driver is installed, it may prevent the default TPM driver
from loading and cause BitLocker to report that a TPM is not present on the computer. If you have a non-
Microsoft driver installed, remove it and then allow the operating system to initialize the TPM.
Troubleshoot network connection issues for Windows 10, versions 1507 and 1511
If you have Windows 10, version 1507 or 1511, the initialization of the TPM cannot complete when your computer
has network connection issues and both of the following conditions exist:
An administrator has configured your computer to require that TPM recovery information be saved in
Active Directory Domain Services (AD DS ). This requirement can be configured through Group Policy.
A domain controller cannot be reached. This can occur on a computer that is currently disconnected from
 the network, separated from the domain by a firewall, or experiencing a network component failure (such as
an unplugged cable or a faulty network adapter).
If these issues occur, an error message appears, and you cannot complete the initialization process. To avoid this
issue, allow Windows to initialize the TPM while you are connected to the corporate network and you can contact a
domain controller.
Troubleshoot systems with multiple TPMs
Some systems may have multiple TPMs and the active TPM may be toggled in UEFI. Windows 10 does not
support this behavior. If you switch TPMs, Windows might not properly detect or interact with the new TPM. If you
plan to switch TPMs you should toggle to the new TPM, clear it, and reinstall Windows. For more information, see
Clear all the keys from the TPM, later in this topic.
For example, toggling TPMs will cause BitLocker to enter recovery mode. We strongly recommend that, on
systems with two TPMs, one TPM is selected to be used and the selection is not changed.

Clear all the keys from the TPM

You can use the Windows Defender Security Center app to clear the TPM as a troubleshooting step, or as a final
preparation before a clean installation of a new operating system. Preparing for a clean installation in this way
helps ensure that the new operating system can fully deploy any TPM -based functionality that it includes, such as
attestation. However, even if the TPM is not cleared before a new operating system is installed, most TPM
functionality will probably work correctly.
Clearing the TPM resets it to an unowned state. After you clear the TPM, the Windows 10 operating system will
automatically re-initialize it and take ownership again.

WARNING
Clearing the TPM can result in data loss. For more information, see the next section, “Precautions to take before clearing the
TPM.”

Precautions to take before clearing the TPM

Clearing the TPM can result in data loss. To protect against such loss, review the following precautions:
Clearing the TPM causes you to lose all created keys associated with the TPM, and data protected by those
keys, such as a virtual smart card or a login PIN. Make sure that you have a backup and recovery method
for any data that is protected or encrypted by the TPM.
Do not clear the TPM on a device you do not own, such as a work or school PC, without being instructed to
do so by your IT administrator.
If you want to temporarily suspend TPM operations and you have TPM 1.2 with Windows 10, version 1507
or 1511, you can turn off the TPM. For more information, see Turn off the TPM, later in this topic.
Always use functionality in the operating system (such as TPM.msc) to the clear the TPM. Do not clear the
TPM directly from UEFI.
Because your TPM security hardware is a physical part of your computer, before clearing the TPM, you
might want to read the manuals or instructions that came with your computer, or search the manufacturer's
website.
Membership in the local Administrators group, or equivalent, is the minimum required to complete this procedure.
To clear the TPM
1. Open the Windows Defender Security Center app.
2. Click Device security.
3. Click Security processor details.
4. Click Security processor troubleshooting.
5. Click Clear TPM.
6. You will be prompted to restart the computer. During the restart, you might be prompted by the UEFI to
press a button to confirm that you wish to clear the TPM.
7. After the PC restarts, your TPM will be automatically prepared for use by Windows 10.

Turn on or turn off the TPM (available only with TPM 1.2 with Windows
10, version 1507 or 1511)
Normally, the TPM is turned on as part of the TPM initialization process. You do not normally need to turn the
TPM on or off. However, if necessary you can do so by using the TPM MMC.
Turn on the TPM
If you want to use the TPM after you have turned it off, you can use the following procedure to turn on the TPM.
To turn on the TPM (TPM 1.2 with Windows 10, version 1507 or 1511 only)
1. Open the TPM MMC (tpm.msc).
2. In the Action pane, click Turn TPM On to display the Turn on the TPM Security Hardware page. Read
the instructions on this page.
3. Click Shutdown (or Restart), and then follow the UEFI screen prompts.
After the computer restarts, but before you sign in to Windows, you will be prompted to accept the
reconfiguration of the TPM. This ensures that the user has physical access to the computer and that
malicious software is not attempting to make changes to the TPM.
Turn off the TPM
If you want to stop using the services that are provided by the TPM, you can use the TPM MMC to turn off the
TPM.
To turn off the TPM (TPM 1.2 with Windows 10, version 1507 or 1511 only)
1. Open the TPM MMC (tpm.msc).
2. In the Action pane, click Turn TPM Off to display the Turn off the TPM security hardware page.
3. In the Turn off the TPM security hardware dialog box, select a method to enter your owner password
and turning off the TPM:
If you saved your TPM owner password on a removable storage device, insert it, and then click I
have the owner password file. In the Select backup file with the TPM owner password dialog
box, click Browse to locate the .tpm file that is saved on your removable storage device, click Open,
and then click Turn TPM Off.
If you do not have the removable storage device with your saved TPM owner password, click I want
to enter the password. In the Type your TPM owner password dialog box, type your password
(including hyphens), and then click Turn TPM Off.
If you did not save your TPM owner password or no longer know it, click I do not have the TPM
owner password, and follow the instructions that are provided in the dialog box and subsequent
UEFI screens to turn off the TPM without entering the password.
Use the TPM cmdlets
You can manage the TPM using Windows PowerShell. For details, see TPM Cmdlets in Windows PowerShell.

Related topics
Trusted Platform Module (list of topics)
 Understanding PCR banks on TPM 2.0 devices
9/12/2018 • 3 minutes to read • Edit Online

Applies to
Windows 10
Windows Server 2016
For steps on how to switch PCR banks on TPM 2.0 devices on your PC, you should contact your OEM or UEFI
vendor. This topic provides background about what happens when you switch PCR banks on TPM 2.0 devices.
A Platform Configuration Register (PCR ) is a memory location in the TPM that has some unique properties. The
size of the value that can be stored in a PCR is determined by the size of a digest generated by an associated
hashing algorithm. A SHA-1 PCR can store 20 bytes – the size of a SHA-1 digest. Multiple PCRs associated with
the same hashing algorithm are referred to as a PCR bank.
To store a new value in a PCR, the existing value is extended with a new value as follows: PCR [N ] = HASHalg(
PCR [N ] || ArgumentOfExtend )
The existing value is concatenated with the argument of the TPM Extend operation. The resulting concatenation is
then used as input to the associated hashing algorithm, which computes a digest of the input. This computed
digest becomes the new value of the PCR.
The TCG PC Client Platform TPM Profile Specification defines the inclusion of at least one PCR bank with 24
registers. The only way to reset the first 16 PCRs is to reset the TPM itself. This restriction helps ensure that the
value of those PCRs can only be modified via the TPM Extend operation.
Some TPM PCRs are used as checksums of log events. The log events are extended in the TPM as the events
occur. Later, an auditor can validate the logs by computing the expected PCR values from the log and comparing
them to the PCR values of the TPM. Since the first 16 TPM PCRs cannot be modified arbitrarily, a match between
an expected PCR value in that range and the actual TPM PCR value provides assurance of an unmodified log.

How does Windows 10 use PCRs?

To bind the use of a TPM based key to a certain state of the PC, the key can be sealed to an expected set of PCR
values. For instance, PCRs 0 through 7 have a well-defined value after the boot process – when the OS is loaded.
When the hardware, firmware, or boot loader of the machine changes, the change can be detected in the PCR
values. Windows 10 uses this capability to make certain cryptographic keys only available at certain times during
the boot process. For instance, the BitLocker key can be used at a certain point in the boot, but not before or after.
It is important to note that this binding to PCR values also includes the hashing algorithm used for the PCR. For
instance, a key can be bound to a specific value of the SHA-1 PCR [12], if using SHA-256 PCR banks, even with the
same system configuration. Otherwise, the PCR values will not match.

What happens when PCR banks are switched?

When the PCR banks are switched, the algorithm used to compute the hashed values stored in the PCRs during
extend operations is changed. For the same input, each hash algorithm will return a different cryptographic
signature for the same inputs.
As a result, if the currently used PCR bank is switched all keys that have been bound to the previous PCR values
will no longer work. For example, if you had a key bound to the SHA-1 value of PCR [12] and subsequently
changed the PCR banks to SHA-256, the banks wouldn’t match, and you would be unable to use that key. The
BitLocker key is secured using the PCR banks and Windows 10 will not be able to unseal it if the PCR banks are
switched while BitLocker is enabled.

What can I do to switch PCRs when BitLocker is already active?

Before switching PCR banks you should suspend or disable BitLocker – or have your recovery key ready. For steps
on how to switch PCR banks on your PC, you should contact your OEM or UEFI vendor.

Related topics
Trusted Platform Module (list of topics)
 TPM recommendations
1/28/2019 • 7 minutes to read • Edit Online

Applies to
Windows 10
Windows Server 2016
This topic provides recommendations for Trusted Platform Module (TPM ) technology for Windows 10.
For a basic feature description of TPM, see the Trusted Platform Module Technology Overview.

TPM design and implementation

Traditionally, TPMs have been discrete chips soldered to a computer’s motherboard. Such implementations allow
the computer’s original equipment manufacturer (OEM ) to evaluate and certify the TPM separate from the rest of
the system. Although discrete TPM implementations are still common, they can be problematic for integrated
devices that are small or have low power consumption. Some newer TPM implementations integrate TPM
functionality into the same chipset as other platform components while still providing logical separation similar to
discrete TPM chips.
TPMs are passive: they receive commands and return responses. To realize the full benefit of a TPM, the OEM
must carefully integrate system hardware and firmware with the TPM to send it commands and react to its
responses. TPMs were originally designed to provide security and privacy benefits to a platform’s owner and
users, but newer versions can provide security and privacy benefits to the system hardware itself. Before it can be
used for advanced scenarios, however, a TPM must be provisioned. Windows 10 automatically provisions a TPM,
but if the user is planning to reinstall the operating system, he or she may need to clear the TPM before
reinstalling so that Windows can take full advantage of the TPM.
The Trusted Computing Group (TCG ) is the nonprofit organization that publishes and maintains the TPM
specification. The TCG exists to develop, define, and promote vendor-neutral, global industry standards that
support a hardware-based root of trust for interoperable trusted computing platforms. The TCG also publishes the
TPM specification as the international standard ISO/IEC 11889, using the Publicly Available Specification
Submission Process that the Joint Technical Committee 1 defines between the International Organization for
Standardization (ISO ) and the International Electrotechnical Commission (IEC ).
OEMs implement the TPM as a component in a trusted computing platform, such as a PC, tablet, or phone.
Trusted computing platforms use the TPM to support privacy and security scenarios that software alone cannot
achieve. For example, software alone cannot reliably report whether malware is present during the system startup
process. The close integration between TPM and platform increases the transparency of the startup process and
supports evaluating device health by enabling reliable measuring and reporting of the software that starts the
device. Implementation of a TPM as part of a trusted computing platform provides a hardware root of trust—that
is, it behaves in a trusted way. For example, if a key stored in a TPM has properties that disallow exporting the key,
that key truly cannot leave the TPM.
The TCG designed the TPM as a low -cost, mass-market security solution that addresses the requirements of
different customer segments. There are variations in the security properties of different TPM implementations just
as there are variations in customer and regulatory requirements for different sectors. In public-sector
procurement, for example, some governments have clearly defined security requirements for TPMs whereas
others do not.
TPM 1.2 vs. 2.0 comparison
From an industry standard, Microsoft has been an industry leader in moving and standardizing on TPM 2.0, which
has many key realized benefits across algorithms, crypto, hierarchy, root keys, authorization and NV RAM.

Why TPM 2.0?

TPM 2.0 products and systems have important security advantages over TPM 1.2, including:
The TPM 1.2 spec only allows for the use of RSA and the SHA-1 hashing algorithm.
For security reasons, some entities are moving away from SHA-1. Notably, NIST has required many federal
agencies to move to SHA-256 as of 2014, and technology leaders, including Microsoft and Google have
announced they will remove support for SHA-1 based signing or certificates in 2017.
TPM 2.0 enables greater crypto agility by being more flexible with respect to cryptographic algorithms.
TPM 2.0 supports newer algorithms, which can improve drive signing and key generation
performance. For the full list of supported algorithms, see the TCG Algorithm Registry. Some TPMs
do not support all algorithms.
For the list of algorithms that Windows supports in the platform cryptographic storage provider, see
CNG Cryptographic Algorithm Providers.
TPM 2.0 achieved ISO standardization (ISO/IEC 11889:2015).
Use of TPM 2.0 may help eliminate the need for OEMs to make exception to standard configurations
for certain countries and regions.
TPM 2.0 offers a more consistent experience across different implementations.
TPM 1.2 implementations vary in policy settings. This may result in support issues as lockout
policies vary.
TPM 2.0 lockout policy is configured by Windows, ensuring a consistent dictionary attack protection
guarantee.
While TPM 1.2 parts are discrete silicon components which are typically soldered on the motherboard,
TPM 2.0 is available as a discrete (dTPM ) silicon component in a single semiconductor package, an
integrated component incorporated in one or more semiconductor packages - alongside other logic units
in the same package(s) - and as a firmware (fTPM ) based component running in a trusted execution
environment (TEE ) on a general purpose SoC.

NOTE
TPM 2.0 requires UEFI firmware. A computer with legacy BIOS and TPM 2.0 won't work as expected.

Discrete, Integrated or Firmware TPM?

There are three implementation options for TPMs:
Discrete TPM chip as a separate component in its own semiconductor package
Integrated TPM solution, using dedicated hardware integrated into one or more semiconductor packages
alongside, but logically separate from, other components
Firmware TPM solution, running the TPM in firmware in a Trusted Execution mode of a general purpose
computation unit
Windows uses any compatible TPM in the same way. Microsoft does not take a position on which way a TPM
should be implemented and there is a wide ecosystem of available TPM solutions which should suit all needs.

Is there any importance for TPM for consumers?

For end consumers, TPM is behind the scenes but is still very relevant. TPM is used for Windows Hello, Windows
Hello for Business and in the future, will be a component of many other key security features in Windows. TPM
secures the PIN, helps encrypt passwords, and builds on our overall Windows 10 experience story for security as a
critical pillar. Using Windows on a system with a TPM enables a deeper and broader level of security coverage.

TPM 2.0 Compliance for Windows 10

Windows 10 for desktop editions (Home, Pro, Enterprise, and Education)
Since July 28, 2016, all new device models, lines or series (or if you are updating the hardware configuration of
a existing model, line or series with a major update, such as CPU, graphic cards) must implement and enable by
default TPM 2.0 (details in section 3.7 of the Minimum hardware requirements page). The requirement to
enable TPM 2.0 only applies to the manufacturing of new devices. For TPM recommendations for specific
Windows features, see TPM and Windows Features.
IoT Core
TPM is optional on IoT Core.
Windows Server 2016
TPM is optional for Windows Server SKUs unless the SKU meets the additional qualification (AQ ) criteria for
the Host Guardian Services scenario in which case TPM 2.0 is required.

TPM and Windows Features

The following table defines which Windows features require TPM support.

WINDOWS FEATURES TPM REQUIRED SUPPORTS TPM 1.2 SUPPORTS TPM 2.0 DETAILS

Measured Boot Yes Yes Yes Measured Boot

requires TPM 1.2 or
2.0 and UEFI Secure
Boot

BitLocker Yes Yes Yes TPM 1.2 or 2.0 is

required, but
Automatic Device
Encryption requires
Modern Standby
including TPM 2.0
support

Device Encryption Yes N/A Yes Device Encryption

requires Modern
Standby/Connected
Standby certification,
which requires TPM
2.0.

Windows Defender No Yes Yes

Application Control
(Device Guard)
 WINDOWS FEATURES TPM REQUIRED SUPPORTS TPM 1.2 SUPPORTS TPM 2.0 DETAILS

Windows Defender No N/A N/A

Exploit Guard

Windows Defender Yes No Yes

System Guard

Credential Guard No Yes Yes Windows 10, version

1507 (End of Life as
of May 2017) only
supported TPM 2.0
for Credential Guard.
Beginning with
Windows 10, version
1511, TPM 1.2 and
2.0 are supported.

Device Health Yes Yes Yes

Attestation

Windows No Yes Yes Azure AD join

Hello/Windows Hello supports both
for Business versions of TPM, but
requires TPM with
keyed-hash message
authentication code
(HMAC) and
Endorsement Key (EK)
certificate for key
attestation support.

UEFI Secure Boot No Yes Yes

TPM Platform Crypto Yes Yes Yes

Provider Key Storage
Provider

Virtual Smart Card Yes Yes Yes

Certificate storage No Yes Yes TPM is only required

when the certificate is
stored in the TPM.

Autopilot Yes No Yes TPM 2.0 and UEFI

firmware is required.

SecureBIO Yes No Yes TPM 2.0 and UEFI

firmware is required.

DRTM Yes No Yes TPM 2.0 and UEFI

firmware is required.

OEM Status on TPM 2.0 system availability and certified parts

Government customers and enterprise customers in regulated industries may have acquisition standards that
require use of common certified TPM parts. As a result, OEMs, who provide the devices, may be required to use
only certified TPM components on their commercial class systems. For more information, contact your OEM or
hardware vendor.

Related topics
Trusted Platform Module (list of topics)