Appwhitelisting With Intune

Contents
Application Control for Windows

WDAC and AppLocker Overview
WDAC and AppLocker Feature Availability
Virtualization-based code integrity
WDAC design guide
Plan for WDAC policy lifecycle management
Design your initial WDAC policy
Understand WDAC policy design decisions
Understand WDAC policy rules and file rules
Authorize apps deployed with a WDAC managed installer
Configure a WDAC managed installer
Authorize reputable apps with Intelligent Security Graph (ISG)
Use multiple WDAC policies
Microsoft recommended block rules
Microsoft recommended driver block rules
Create your initial WDAC policy
Example WDAC base policies
Policy creation for common WDAC usage scenarios
Create a WDAC policy for lightly-managed devices
Create a WDAC policy for fully-managed devices
Create a WDAC policy for fixed-workload devices
Using the WDAC Wizard tool
Create a base WDAC policy with the Wizard
Create a supplemental WDAC policy with the Wizard
Editing a WDAC policy with the Wizard
Merging multiple WDAC policies with the Wizard
Windows Defender Application Control deployment guide
Audit WDAC policies
Merge WDAC policies
Enforce WDAC policies
Deploy WDAC policies using Group Policy
Deploy WDAC policies using Intune
Allow COM object registration
Use WDAC with .NET hardening
Manage packaged apps with WDAC
Use a Windows Defender Application Control policy to control specific plug-ins,
add-ins, and modules
Use code signing to simplify application control for classic Windows applications
Optional: Use the WDAC Signing Portal in the Microsoft Store for Business
Optional: Create a code signing cert for WDAC
Deploy catalog files to support WDAC
Use signed policies to protect Windows Defender Application Control against
tampering
Disable WDAC policies
LOB Win32 Apps on S Mode
Windows Defender Application Control operational guide
Understanding Application Control event IDs
Understanding Application Control event tags
Query WDAC events with Advanced hunting
AppLocker
Administer AppLocker
Maintain AppLocker policies
Edit an AppLocker policy
Test and update an AppLocker policy
Deploy AppLocker policies by using the enforce rules setting
Use the AppLocker Windows PowerShell cmdlets
Use AppLocker and Software Restriction Policies in the same domain
Optimize AppLocker performance
Monitor app usage with AppLocker
Manage packaged apps with AppLocker
Working with AppLocker rules
Create a rule that uses a file hash condition
Create a rule that uses a path condition
Create a rule that uses a publisher condition
Create AppLocker default rules
Add exceptions for an AppLocker rule
Create a rule for packaged apps
Delete an AppLocker rule
Edit AppLocker rules
Enable the DLL rule collection
Enforce AppLocker rules
Run the Automatically Generate Rules wizard
Working with AppLocker policies
Configure the Application Identity service
Configure an AppLocker policy for audit only
Configure an AppLocker policy for enforce rules
Display a custom URL message when users try to run a blocked app
Export an AppLocker policy from a GPO
Export an AppLocker policy to an XML file
Import an AppLocker policy from another computer
Import an AppLocker policy into a GPO
Add rules for packaged apps to existing AppLocker rule-set
Merge AppLocker policies by using Set-ApplockerPolicy
Merge AppLocker policies manually
Refresh an AppLocker policy
Test an AppLocker policy by using Test-AppLockerPolicy
AppLocker design guide
Understand AppLocker policy design decisions
Determine your application control objectives
Create a list of apps deployed to each business group
Document your app list
Select the types of rules to create
Document your AppLocker rules
Determine the Group Policy structure and rule enforcement
Understand AppLocker enforcement settings
Understand AppLocker rules and enforcement setting inheritance in Group Policy
Document the Group Policy structure and AppLocker rule enforcement
Plan for AppLocker policy management
AppLocker deployment guide
Understand the AppLocker policy deployment process
Requirements for Deploying AppLocker Policies
Use Software Restriction Policies and AppLocker policies
Create Your AppLocker policies
Create Your AppLocker rules
Deploy the AppLocker policy into production
Use a reference device to create and maintain AppLocker policies
Determine which apps are digitally signed on a reference device
Configure the AppLocker reference device
AppLocker technical reference
What Is AppLocker?
Requirements to use AppLocker
AppLocker policy use scenarios
How AppLocker works
Understanding AppLocker rule behavior
Understanding AppLocker rule exceptions
Understanding AppLocker rule collections
Understanding AppLocker allow and deny actions on rules
Understanding AppLocker rule condition types
Understanding the publisher rule condition in AppLocker
Understanding the path rule condition in AppLocker
Understanding the file hash rule condition in AppLocker
Understanding AppLocker default rules
Executable rules in AppLocker
Windows Installer rules in AppLocker
Script rules in AppLocker
DLL rules in AppLocker
Packaged apps and packaged app installer rules in AppLocker
AppLocker architecture and components
AppLocker processes and interactions
AppLocker functions
Security considerations for AppLocker
Tools to Use with AppLocker
Using Event Viewer with AppLocker
AppLocker Settings
Application Control for Windows
2/18/2021 • 2 minutes to read • Edit Online
Applies to:
Windows 10
Windows Server 2016 and above
With thousands of new malicious files created every day, using traditional methods like antivirus solutions—
signature-based detection to fight against malware—provides an inadequate defense against new attacks.
In most organizations, information is the most valuable asset, and ensuring that only approved users have
access to that information is imperative. However, when a user runs a process, that process has the same level of
access to data that the user has. As a result, sensitive information could easily be deleted or transmitted out of
the organization if a user knowingly or unknowingly runs malicious software.
Application control can help mitigate these types of security threats by restricting the applications that users are
allowed to run and the code that runs in the System Core (kernel). Application control policies can also block
unsigned scripts and MSIs, and restrict Windows PowerShell to run in Constrained Language Mode.
Application control is a crucial line of defense for protecting enterprises given today’s threat landscape, and it
has an inherent advantage over traditional antivirus solutions. Specifically, application control moves away from
an application trust model where all applications are assumed trustworthy to one where applications must earn
trust in order to run. Many organizations, like the Australian Signals Directorate, understand this and frequently
cite application control as one of the most effective means for addressing the threat of executable file-based
malware (.exe, .dll, etc.).
NOTE
Although application control can significantly harden your computers against malicious code, we recommend that you
continue to maintain an enterprise antivirus solution for a well-rounded enterprise security portfolio.
Windows 10 includes two technologies that can be used for application control depending on your
organization's specific scenarios and requirements:
Windows Defender Application Control ; and
AppLocker
In this section
A RT IC L E DESC RIP T IO N
WDAC and AppLocker Overview This article describes the decisions you need to make to
establish the processes for managing and maintaining
WDAC policies.
WDAC and AppLocker Feature Availability This article lists the design questions, possible answers, and
ramifications of the decisions when you plan a deployment
of application control policies.
Related articles
WDAC design guide
WDAC deployment guide
AppLocker overview
Windows Defender Application Control and
AppLocker Overview
Applies to:
Windows 10
Windows 10 includes two technologies that can be used for application control depending on your
organization's specific scenarios and requirements: Windows Defender Application Control (WDAC) and
AppLocker.
Windows Defender Application Control

WDAC was introduced with Windows 10 and allows organizations to control which drivers and applications are
allowed to run on their Windows 10 clients. WDAC was designed as a security feature under the servicing
criteria defined by the Microsoft Security Response Center (MSRC).
WDAC policies apply to the managed computer as a whole and affects all users of the device. WDAC rules can
be defined based on:
Attributes of the codesigning certificate(s) used to sign an app and its binaries
Attributes of the app's binaries that come from the signed metadata for the files, such as Original Filename
and version, or the hash of the file
The reputation of the app as determined by Microsoft's Intelligent Security Graph
The identity of the process that initiated the installation of the app and its binaries (managed installer)
The path from which the app or file is launched (beginning with Windows 10 version 1903)
The process that launched the app or binary
Note that prior to Windows 10, version 1709, Windows Defender Application Control was known as
configurable code integrity (CCI). WDAC was also one of the features which comprised the now-defunct term
'Device Guard'.
WDAC System Requirements
WDAC policies can be created on any client edition of Windows 10 build 1903+ or on Windows Server 2016
and above.
WDAC policies can be applied to devices running any edition of Windows 10 or Windows Server 2016 and
above via a Mobile Device Management (MDM) solution like Intune, a management interface like Configuration
Manager, or a script host like PowerShell. Group Policy can also be used to deploy WDAC policies to Windows
10 Enterprise edition or Windows Server 2016 and above, but cannot deploy policies to devices running non-
Enterprise SKUs of Windows 10.
For more information on which individual WDAC features are available on which WDAC builds, see WDAC
feature availability.
AppLocker
AppLocker was introduced with Windows 7 and allows organizations to control which applications are allowed
to run on their Windows clients. AppLocker helps to prevent end users from running unapproved software on
their computers, but it does not meet the servicing criteria for being a security feature.
AppLocker policies can apply to all users on a computer or to individual users and groups. AppLocker rules can
be defined based on:
Attributes of the codesigning certificate(s) used to sign an app and its binaries
Attributes of the app's binaries that come from the signed metadata for the files, such as Original Filename
and version, or the hash of the file
The path from which the app or file is launched
AppLocker System Requirements
AppLocker policies can only be configured on and applied to devices that are running on the supported versions
and editions of the Windows operating system. For more info, see Requirements to Use AppLocker. AppLocker
policies can be deployed using Group Policy or MDM.
Choose when to use WDAC or AppLocker

Generally, it is recommended that customers who are able to implement application control using WDAC rather
than AppLocker do so. WDAC is undergoing continual improvements and will be getting added support from
Microsoft management platforms. Although AppLocker will continue to receive security fixes, it will not undergo
new feature improvements.
In some cases, however, AppLocker may be the more appropriate technology for your organization. AppLocker
is best when:
You have a mixed Windows operating system (OS) environment and need to apply the same policy controls
to Windows 10 and earlier versions of the OS.
You need to apply different policies for different users or groups on shared computers.
You do not want to enforce application control on application files such as DLLs or drivers.
AppLocker can also be deployed as a complement to WDAC to add user- or group-specific rules for shared
device scenarios where it is important to prevent some users from running specific apps. As a best practice, you
should enforce WDAC at the most restrictive level possible for your organization, and then you can use
AppLocker to further fine-tune the restrictions.
WDAC and AppLocker feature availability
Applies to:
Windows 10
C A PA B IL IT Y W DA C A P P LO C K ER
Platform support Available on Windows 10 Available on Windows 8+
SKU availability Cmdlets are available on all SKUs on Policies deployed through GP are only
1909+ builds. effective on Enterprise devices.
For pre-1909 builds, cmdlets are only Policies deployed through MDM are
available on Enterprise but policies are effective on all SKUs.
effective on all SKUs.
Management solutions Intune (limited built-in policies Intune (custom policy

or custom policy deployment deployment via OMA-URI only)
via OMA-URI) MEMCM (custom policy
Microsoft Endpoint Manager deployment via Software
Configuration Manager Distribution only)
(MEMCM) (limited built-in Group Policy
policies or custom policy PowerShell
deployment via Software
Distribution)
Group Policy
PowerShell
Per-User and Per-User group rules Not available (policies are device-wide) Available on Windows 8+
Kernel mode policies Available on all Windows 10 versions Not available
Per-app rules Available on 1703+ Not available
Managed Installer (MI) Available on 1703+ Not available
Reputation-Based intelligence Available on 1709+ Not available
Multiple policy support Available on 1903+ Not available
Path-based rules Available on 1903+. Exclusions are not Available on Windows 8+. Exclusions
supported. Runtime user-writeability are supported. No runtime user-
check enforced by default. writeability check.
COM object configurability Available on 1903+ Not available
Packaged app rules Available on RS5+ Available on Windows 8+

C A PA B IL IT Y W DA C A P P LO C K ER
Enforceable file types Driver files: .sys Executable files: .exe and .com
Executable files: .exe and .com [Optional] DLLs: .dll and .ocx
DLLs: .dll and .ocx Windows Installer files: .msi,
Windows Installer files: .msi, .mst, and .msp
.mst, and .msp Scripts: .ps1, .bat, .cmd, .vbs,
Scripts: .ps1, .vbs, and .js and .js
Packaged apps and packaged Packaged apps and packaged
app installers: .appx app installers: .appx
Windows Defender Application Control and
virtualization-based protection of code integrity
Applies to
Windows 10
Windows Server 2016
Windows 10 includes a set of hardware and OS technologies that, when configured together, allow enterprises
to "lock down" Windows 10 systems so they operate with many of the properties of mobile devices. In this
configuration, specific technologies work together to restrict devices to only run authorized apps by using a
feature called configurable code integrity, while simultaneously hardening the OS against kernel memory
attacks by using virtualization-based protection of code integrity (more specifically, HVCI).
Configurable code integrity policies and HVCI are powerful protections that can be used separately. However,
when these two technologies are configured to work together, they present a strong protection capability for
Windows 10 devices.
Using configurable code integrity to restrict devices to only authorized apps has these advantages over other
solutions:
1. Configurable code integrity policy is enforced by the Windows kernel itself. As such, the policy takes effect
early in the boot sequence before nearly all other OS code and before traditional antivirus solutions run.
2. Configurable code integrity allows customers to set application control policy not only over code running in
user mode, but also kernel mode hardware and software drivers and even code that runs as part of
Windows.
3. Customers can protect the configurable code integrity policy even from local administrator tampering by
digitally signing the policy. This would mean that changing the policy would require both administrative
privilege and access to the organization’s digital signing process, making it difficult for an attacker with
administrative privilege, or malicious software that managed to gain administrative privilege, to alter the
application control policy.
4. The entire configurable code integrity enforcement mechanism can be protected by HVCI, where even if a
vulnerability exists in kernel mode code, the likelihood that an attacker could successfully exploit it is
diminished. Why is this relevant? That’s because an attacker that compromises the kernel would otherwise
have enough privilege to disable most system defenses and override the application control policies
enforced by configurable code integrity or any other application control solution.

When we originally designed this configuration state, we did so with a specific security promise in mind.
Although there were no direct dependencies between configurable code integrity and HVCI, we intentionally
focused our discussion around the lockdown state you achieve when deploying them together. However, given
that HVCI relies on Windows virtualization-based security, it comes with more hardware, firmware, and kernel
driver compatibility requirements that some older systems can’t meet. As a result, many IT Professionals
assumed that because some systems couldn't use HVCI, they couldn’t use configurable code integrity either.
Configurable code integrity carries no specific hardware or software requirements other than running Windows
10, which means many IT professionals were wrongly denied the benefits of this powerful application control
capability.
Since the initial release of Windows 10, the world has witnessed numerous hacking and malware attacks where
application control alone could have prevented the attack altogether. With this in mind, we are discussing and
documenting configurable code integrity as an independent technology within our security stack and giving it a
name of its own: Windows Defender Application Control. We hope this change will help us better communicate
options for adopting application control within an organization.
Related articles
Dropping the Hammer Down on Malware Threats with Windows 10’s Windows Defender
Driver compatibility with Windows Defender in Windows 10
Code integrity
Windows Defender Application Control design
guide
Applies to
Windows 10
This guide covers design and planning for Windows Defender Application Control (WDAC). It is intended to help
security architects, security administrators, and system administrators create a plan that addresses specific
application control requirements for different departments or business groups within an organization.
Plan for success

A common refrain you may hear about application control is that it is "too hard". While it is true that application
control is not as simple as flipping a switch, organizations can be very successful if they take a methodical
approach and carefully plan their approach. In reality, the issues that lead to failure with application control often
arise from business issues rather than technology challenges. Organizations that have successfully deployed
application control have ensured the following before starting their planning:
Executive sponsorship and organizational buy-in is in place.
There is a clear business objective for using application control and it is not being planned as a purely
technical problem from IT.
The organization has a plan to handle potential helpdesk support requests for users who are blocked from
running some apps.
The organization has considered where application control can be most useful (e.g. securing sensitive
workloads or business functions) and also where it may be difficult to achieve (e.g. developer workstations).
Once these business factors are in place, you are ready to begin planning your WDAC deployment. The
following topics can help guide you through your planning process.
In this section
TO P IC DESC RIP T IO N
Plan for WDAC policy management This topic describes the decisions you need to make to
WDAC policies.
Understand WDAC policy design decisions This topic lists the design questions, possible answers, and
ramifications of the decisions when you plan a deployment
of application control policies.
Understand WDAC policy rules and file rules This topic lists resources you can use when selecting your
application control policy rules by using WDAC.
Policy creation for common WDAC usage scenarios This set of topics outlines common use case scenarios and
helps you begin to develop a plan for deploying WDAC in
your organization.
Policy creation using the WDAC Wizard tool This set of topics describes how to use the WDAC Wizard
desktop app to easily create, edit and merge WDAC policies.
After planning is complete, the next step is to deploy WDAC. The Windows Defender Application Control
Deployment Guide covers the creation and testing of policies, deploying the enforcement setting, and managing
and maintaining the policies.
Plan for Windows Defender Application Control
lifecycle policy management
Applies to:
Windows 10
This topic describes the decisions you need to make to establish the processes for managing and maintaining
Windows Defender Application Control (WDAC) policies.
Policy XML lifecycle management

The first step in implementing application control is to consider how your policies will be managed and
maintained over time. Developing a process for managing WDAC policies helps assure that WDAC continues to
effectively control how applications are allowed to run in your organization.
Most WDAC policies will evolve over time and proceed through a set of identifiable phases during their lifetime.
Typically, these phases include:
1. Define (or refine) the "circle-of-trust" for the policy and build an audit mode version of the policy XML. In
audit mode, block events are generated but files are not prevented from executing.
2. Deploy the audit mode policy to intended devices.
3. Monitor audit block events from the intended devices and add/edit/delete rules as needed to address
unexpected/unwanted blocks.
4. Repeat steps 2-3 until the remaining block events meet expectations.
5. Generate the enforced mode version of the policy. In enforced mode, files that are not allowed by the policy
are prevented from executing and corresponding block events are generated.
6. Deploy the enforced mode policy to intended devices. We recommend using staged rollouts for enforced
policies to detect and respond to issues before deploying the policy broadly.
7. Repeat steps 1-6 anytime the desired "circle-of-trust" changes.
Keep WDAC policies in a source control or document management solution
To effectively manage WDAC policies, you should store and maintain your policy XML documents in a central
repository that is accessible to everyone responsible for WDAC policy management. We recommend a source
control solution such as GitHub or a document management solution such as Office 365 SharePoint, which
provide version control and allow you to specify metadata about the XML documents.
Set PolicyName, PolicyID, and Version metadata for each policy
Use the Set-CIPolicyIDInfo cmdlet to give each policy a descriptive name and set a unique ID in order to
differentiate each policy when reviewing WDAC events or when viewing the policy XML document. Although
you can specify a string value for PolicyId, for policies using the multiple policy format we recommend using the
-ResetPolicyId switch to let the system auto-generate a unique ID for the policy.
NOTE
PolicyID only applies to policies using the multiple policy format on computers running Windows 10, version 1903 and
above. Running -ResetPolicyId on a policy created for pre-1903 computers will convert it to multiple policy format and
prevent it from running on those earlier versions of Windows 10. PolicyID should be set only once per policy and use
different PolicyID's for the audit and enforced mode versions of each policy.
In addition, we recommend using the Set-CIPolicyVersion cmdlet to increment the policy's internal version
number when you make changes to the policy. The version must be defined as a standard four-part version
string (e.g. "1.0.0.0").
Policy rule updates
As new apps are deployed or existing apps are updated by the software publisher, you may need to make
revisions to your rules to ensure that these apps run correctly. Whether policy rule updates are required will
depend significantly on the types of rules your policy includes. Rules based on codesigning certificates provide
the most resiliency against app changes while rules based on file attributes or hash are most likely to require
updates when apps change. Alternatively, if you leverage WDAC managed installer functionality and consistently
deploy all apps and their updates through your managed installer, then you are less likely to need policy
updates.
WDAC event management

Each time that a process is blocked by WDAC, events will be written to either the CodeIntegrity\Operational or
the AppLocker\MSI and Script Windows event logs. The event details which file tried to run, the attributes of that
file and its signatures, and the process that attempted to run the blocked file.
Collecting these events in a central location can help you maintain your WDAC policy and troubleshoot rule
configuration problems. Event collection technologies such as those available in Windows allow administrators
to subscribe to specific event channels and have the events from source computers aggregated into a forwarded
event log on a Windows Server operating system collector. For more info about setting up an event
subscription, see Configure Computers to Collect and Forward Events.
Additionally, WDAC events are collected by Microsoft Defender for Endpoint and can be queried using the
advanced hunting feature.
Application and user support policy

Considerations include:
What type of end-user support is provided for blocked applications?
How are new rules added to the policy?
How are existing rules updated?
Are events forwarded for review?
Help desk support
If your organization has an established help desk support department in place, consider the following when
deploying WDAC policies:
What documentation does your support department require for new policy deployments?
What are the critical processes in each business group both in work flow and timing that will be affected by
application control policies and how could they affect your support department's workload?
Who are the contacts in the support department?
How will the support department resolve application control issues between the end user and those who
maintain the WDAC rules?
End-user support
Because WDAC is preventing unapproved apps from running, it is important that your organization carefully
plan how to provide end-user support. Considerations include:
Do you want to use an intranet site as a first line of support for users who have tried to run a blocked app?
How do you want to support exceptions to the policy? Will you allow users to run a script to temporarily
allow access to a blocked app?
Document your plan

After deciding how your organization will manage your WDAC policy, record your findings.
End-user suppor t policy. Document the process that you will use for handling calls from users who have
attempted to run a blocked app, and ensure that support personnel have clear escalation steps so that the
administrator can update the WDAC policy, if necessary.
Event processing. Document whether events will be collected in a central location called a store, how that
store will be archived, and whether the events will be processed for analysis.
Policy management. Detail what policies are planned, how they will be managed, and how rules will be
maintained over time.
Understand Windows Defender Application Control
policy design decisions
Applies to:
Windows 10
This topic is for the IT professional and lists the design questions, possible answers, and ramifications of the
decisions when you plan a deployment of application control policies by using Windows Defender Application
Control (WDAC) within a Windows operating system environment.
When you begin the design and planning process, you should consider the ramifications of your design choices.
The resulting decisions will affect your policy deployment scheme and subsequent application control policy
maintenance.
You should consider using WDAC as part of your organization's application control policies if the following are
true:
You have deployed or plan to deploy the supported versions of Windows in your organization.
You need improved control over the access to your organization's applications and the data your users
access.
Your organization has a well-defined process for application management and deployment.
You have resources to test policies against the organization's requirements.
You have resources to involve Help Desk or to build a self-help process for end-user application access
issues.
The group's requirements for productivity, manageability, and security can be controlled by restrictive
policies.
Decide what policies to create

Beginning with Windows 10, version 1903, WDAC allows multiple simultaneous policies to be applied to each
device. While this opens up many new use cases for organizations, your policy management can easily become
unwieldy without a well-thought-out plan for the number and types of policies to create.
The first step is to define the desired "circle-of-trust" for your WDAC policies. By "circle-of-trust", we mean a
description of the business intent of the policy expressed in natural language. This "circle-of-trust" definition will
guide you as you create the actual policy rules for your policy XML.
For example, the DefaultWindows policy, which can be found under
%OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies, establishes a "circle-of-trust" that allows
Windows, 3rd-party hardware and software kernel drivers, and applications from the Microsoft Store.
Microsoft Endpoint Configuration Manager, previously known as System Center Configuration Manager, uses
the DefaultWindows policy as the basis for its policy but then modifies the policy rules to allow Configuration
Manager and its dependencies, sets the managed installer policy rule, and additionally configures Configuration
Manager as a managed installer. It also can optionally authorize apps with positive reputation and perform a
one-time scan of folder paths specified by the Configuration Manager administrator which adds rules for any
apps found in the specified paths on the managed endpoint. This establishes the "circle-of-trust" for
Configuration Manager's native WDAC integration.
The following questions can help you plan your WDAC deployment and determine the right "circle-of-trust" for
your policies. They are not in priority or sequential order and are not meant to be an exhaustive set of design
considerations.
WDAC design considerations

How are apps managed and deployed in your organization?
Organizations with well-defined, centrally-managed app management and deployment processes can create
more restrictive, more secure policies. Other organizations may be able to deploy WDAC with more relaxed
rules or may choose to deploy WDAC in audit mode to gain better visibility to the apps being used in their
organization.
P O SSIB L E A N SW ERS DESIGN C O N SIDERAT IO N S
All apps are centrally managed and deployed using endpoint Organizations that centrally manage all apps are best-suited
management tools like Microsoft Endpoint Manager. for application control. WDAC options like managed installer
can make it easy to authorize apps that are deployed by the
organization's app distribution management solution.
Some apps are centrally managed and deployed, but teams Supplemental policies can be used to allow team-specific
can install additional apps for their members. exceptions to your core organization-wide WDAC policy.
Alternatively, teams can leverage managed installers to
install their team-specific apps or admin-only file path rules
can be used to allow apps installed by admin users.
Users and teams are free to download and install apps but WDAC can integrate with Microsoft's Intelligent Security
the organization wants to restrict that right to prevalent and Graph (the same source of intelligence that powers
reputable apps only. Microsoft Defender Antivirus and Windows Defender
SmartScreen) to allow only apps and binaries that have
positive reputation.
Users and teams are free to download and install apps WDAC policies can be deployed in audit mode to gain
without restriction. insight into the apps and binaries running in your
organization without impacting user and team productivity.
Are internally-developed line -of-business (LOB ) apps and apps developed by 3rd parties digitally signed?
Traditional Win32 apps on Windows can run without being digitally signed. This practice can expose Windows
devices to malicious or tampered code and presents a security vulnerability to your Windows devices. Adopting
code-signing as part of your organization's app development practices or augmenting apps with signed catalog
files as part of your app ingestion and distribution can greatly improve the integrity and security of apps used.
All apps used in your organization must be signed. Organizations that enforce codesigning for all executable
code are best-positioned to protect their Windows
computers from malicious code execution. WDAC rules can
be created to authorize apps and binaries from the
organization's internal development teams and from trusted
independent software vendors (ISV).
Apps used in your organization do not need to meet any Organizations can use built-in Windows 10 tools to add
codesigning requirements. organization-specific App Catalog signatures to existing apps
as a part of the app deployment process which can be used
to authorize code execution. Solutions like Microsoft
Endpoint Manager offer multiple ways to distribute signed
App Catalogs.
Are there specific groups in your organization that need customized application control policies?
Most business teams or departments have specific security requirements that pertain to data access and the
applications used to access that data. You should consider the scope of the project for each group and the
group’s priorities before you deploy application control policies for the entire organization. There is overhead in
managing policies which may lead you to choose between broad, organization-wide policies and multiple team-
specific policies.
Yes WDAC policies can be created unique per team, or team-

specific supplemental policies can be used to expand what is
allowed by a common, centrally-defined base policy.
No WDAC policies can be applied globally to applications that

are installed on PCs running Windows 10. Depending on the
number of apps you need to control, managing all the rules
and exceptions might be challenging.
Does your IT department have resources to analyze application usage, and to design and manage the
policies?
The time and resources that are available to you to perform the research and analysis can affect the detail of
your plan and processes for continuing policy management and maintenance.
Yes Invest the time to analyze your organization's application

control requirements, and plan a complete deployment that
uses rules that are as simply constructed as possible.
No Consider a focused and phased deployment for specific

groups by using a small number of rules. As you apply
controls to applications in a specific group, learn from that
deployment to plan your next deployment. Alternatively, you
can create a policy with a broad trust profile to authorize as
many apps as possible.
Does your organization have Help Desk support?

Preventing your users from accessing known, deployed, or personal applications will initially cause an increase
in end-user support. It will be necessary to address the various support issues in your organization so security
policies are followed and business workflow is not hampered.
Yes Involve the support department early in the planning phase

because your users may inadvertently be blocked from using
their applications, or they may seek exceptions to use
specific applications.
No Invest time in developing online support processes and

documentation before deployment.
Understand WDAC policy rules and file rules
Applies to:
Windows 10
Windows Defender Application Control (WDAC) provides control over a computer running Windows 10 by
using policies that specify whether a driver or application is trusted and can be run. A policy includes policy rules
that control options such as audit mode or whether user mode code integrity (UMCI) is enabled in a WDAC
policy, and file rules (or file rule levels) that specify the level at which applications will be identified and trusted.
Windows Defender Application Control policy rules

To modify the policy rule options of an existing WDAC policy XML, use Set-RuleOption. The following examples
show how to use this cmdlet to add and remove a rule option on an existing WDAC policy:
To ensure that UMCI is enabled for a WDAC policy that was created with the -UserPEs (user mode)
option, add rule option 0 to an existing policy by running the following command:
Set-RuleOption -FilePath <Path to policy XML> -Option 0
Note that a policy that was created without the -UserPEs option is empty of user mode executables, that
is, applications. If you enable UMCI (Option 0) for such a policy and then attempt to run an application,
Windows Defender Application Control will see that the application is not on its list (which is empty of
applications), and respond. In audit mode, the response is logging an event, and in enforced mode, the
response is blocking the application. To create a policy that includes user mode executables (applications),
when you run New-CIPolicy , include the -UserPEs option.
To disable UMCI on an existing WDAC policy, delete rule option 0 by running the following command:
Set-RuleOption -FilePath <Path to policy XML> -Option 0 -Delete
You can set several rule options within a WDAC policy. Table 1 describes each rule option.
NOTE
We recommend that you use Enabled:Audit Mode initially because it allows you to test new WDAC policies before you
enforce them. With audit mode, no application is blocked—instead the policy logs an event whenever an application
outside the policy is started. To allow these applications, you can capture the policy information from the event log, and
then merge that information into the existing policy. When the Enabled:Audit Mode is deleted, the policy runs in
enforced mode.
Table 1. Windows Defender Application Control policy - policy rule options
RUL E O P T IO N DESC RIP T IO N
0 Enabled:UMCI WDAC policies restrict both kernel-mode and user-mode

binaries. By default, only kernel-mode binaries are restricted.
Enabling this rule option validates user mode executables
and scripts.
1 Enabled:Boot Menu Protection This option is not currently supported.
2 Required:WHQL By default, legacy drivers that are not Windows Hardware

Quality Labs (WHQL) signed are allowed to execute. Enabling
this rule requires that every executed driver is WHQL signed
and removes legacy driver support. Going forward, every
new Windows 10–compatible driver must be WHQL
certified.
3 Enabled:Audit Mode (Default) Enables the execution of binaries outside of the WDAC policy
but logs each occurrence in the CodeIntegrity event log,
which can be used to update the existing policy before
enforcement. To begin enforcing a WDAC policy, delete this
option.
4 Disabled:Flight Signing If enabled, WDAC policies will not trust flightroot-signed

binaries. This would be used in the scenario in which
organizations only want to run released binaries, not flighted
builds.
5 Enabled:Inherit Default Policy This option is reserved for future use and currently has no
effect.
6 Enabled:Unsigned System Integrity Policy (Default) Allows the policy to remain unsigned. When this option is
removed, the policy must be signed and have
UpdatePolicySigners added to the policy to enable future
policy modifications.
7 Allowed:Debug Policy Augmented This option is not currently supported.
8 Required:EV Signers In addition to being WHQL signed, this rule requires that
drivers must have been submitted by a partner that has an
Extended Verification (EV) certificate. All future Windows 10
and later drivers will meet this requirement.
9 Enabled:Advanced Boot Options Menu The F8 preboot menu is disabled by default for all WDAC
policies. Setting this rule option allows the F8 menu to
appear to physically present users.
10 Enabled:Boot Audit on Failure Used when the WDAC policy is in enforcement mode. When
a driver fails during startup, the WDAC policy will be placed
in audit mode so that Windows will load. Administrators can
validate the reason for the failure in the CodeIntegrity event
log.
11 Disabled:Script Enforcement This option disables script enforcement options. Unsigned

PowerShell scripts and interactive PowerShell are no longer
restricted to Constrained Language Mode. NOTE: This option
is supported on 1709, 1803, and 1809 builds with the 2019
10C LCU or higher, as well as on devices with the Windows
10 May 2019 Update (1903) and higher. Using it on pre-
1903 versions of Windows 10 without the 10C or later LCU
is not supported and may have unintended results.
12 Required:Enforce Store Applications If this rule option is enabled, WDAC policies will also apply to
Universal Windows applications.
13 Enabled:Managed Installer Use this option to automatically allow applications installed

by a software distribution solution, such as Microsoft
Endpoint Configuration Manager, that has been defined as a
managed installer.
14 Enabled:Intelligent Security Graph Authorization Use this option to automatically allow applications with
"known good" reputation as defined by Microsoft’s
Intelligent Security Graph (ISG).
15 Enabled:Invalidate EAs on Reboot When the Intelligent Security Graph option (14) is used,
WDAC sets an extended file attribute that indicates that the
file was authorized to run. This option will cause WDAC to
periodically re-validate the reputation for files that were
authorized by the ISG.
16 Enabled:Update Policy No Reboot Use this option to allow future WDAC policy updates to
apply without requiring a system reboot. NOTE: This option
is only supported on Windows 10, version 1709, and above.
17 Enabled:Allow Supplemental Policies Use this option on a base policy to allow supplemental
policies to expand it. NOTE: This option is only supported on
Windows 10, version 1903, and above.
18 Disabled:Runtime FilePath Rule Protection Disable default FilePath rule protection (apps and
executables allowed based on file path rules must come from
a file path that’s only writable by an administrator) for any
FileRule that allows a file based on FilePath. NOTE: This
option is only supported on Windows 10, version 1903, and
above.
19 Enabled:Dynamic Code Security Enables policy enforcement for .NET applications and
dynamically-loaded libraries. NOTE: This option is only
supported on Windows 10, version 1803, and above.
Windows Defender Application Control file rule levels

File rule levels allow administrators to specify the level at which they want to trust their applications. This level
of trust could be as fine-tuned as the hash of each binary or as general as a CA certificate. You specify file rule
levels both when you create a new WDAC policy from a scan and when you create a policy from audit events. In
addition, to combine rule levels found in multiple policies, you can merge the policies. When merged, WDAC
policies combine their file rules, so that any application that would be allowed by either of the original policies
will be allowed by the combined policy.
Each file rule level has its benefit and disadvantage. Use Table 2 to select the appropriate protection level for
your available administrative resources and Windows Defender Application Control deployment scenario.
Table 2. Windows Defender Application Control policy - file rule levels
RUL E L EVEL DESC RIP T IO N
Hash Specifies individual hash values for each discovered binary.

Although this level is specific, it can cause additional
administrative overhead to maintain the current product
versions’ hash values. Each time a binary is updated, the
hash value changes, therefore requiring a policy update.
FileName Specifies individual binary file names. Although the hash

values for an application are modified when updated, the file
names are typically not. This offers less specific security than
the hash level but does not typically require a policy update
when any binary is modified.
FilePath Beginning with Windows 10 version 1903, this specifies rules

that allow execution of binaries contained under specific file
path locations. Additional information about FilePath level
rules can be found below.
SignedVersion This combines the publisher rule with a version number. This
option allows anything from the specified publisher, with a
version at or above the specified version number, to run.
Publisher This is a combination of the PcaCertificate level (typically one

certificate below the root) and the common name (CN) of
the leaf certificate. This rule level allows organizations to
trust a certificate from a major CA (such as Symantec), but
only if the leaf certificate is from a specific company (such as
Intel, for device drivers).
FilePublisher This is a combination of the “FileName” attribute of the

signed file, plus “Publisher” (PCA certificate with CN of leaf),
plus a minimum version number. This option trusts specific
files from the specified publisher, with a version at or above
the specified version number.
LeafCer tificate Adds trusted signers at the individual signing certificate

level. The benefit of using this level versus the individual
hash level is that new versions of the product will have
different hash values but typically the same signing
certificate. Using this level, no policy update would be
needed to run the new version of the application. However,
leaf certificates have much shorter validity periods than CA
certificates, so additional administrative overhead is
associated with updating the WDAC policy when these
certificates expire.
PcaCer tificate Adds the highest available certificate in the provided

certificate chain to signers. This is typically one certificate
below the root certificate, because the scan does not
validate anything beyond the certificates included in the
provided signature (it does not go online or check local root
stores).
RootCer tificate Currently unsupported.
WHQL Trusts binaries if they have been validated and signed by

WHQL. This is primarily for kernel binaries.
WHQLPublisher This is a combination of the WHQL and the CN on the leaf

certificate and is primarily for kernel binaries.
WHQLFilePublisher Specifies that the binaries are validated and signed by

WHQL, with a specific publisher (WHQLPublisher), and that
the binary is the specified version or newer. This is primarily
for kernel binaries.
NOTE
When you create WDAC policies with New-CIPolicy, you can specify a primary file rule level by including the -Level
parameter. For discovered binaries that cannot be trusted based on the primary file rule criteria, use the -Fallback
parameter. For example, if the primary file rule level is PCACertificate but you would like to trust the unsigned applications
as well, using the Hash rule level as a fallback adds the hash values of binaries that did not have a signing certificate.
NOTE
WDAC only supports signer rules for RSA certificate signing keys with a maximum of 4096 bits.
Example of file rule levels in use

For example, consider some IT professionals in a department that runs many servers. They decide they want
their servers to run only software signed by the providers of their software and drivers, that is, the companies
that provide their hardware, operating system, antivirus, and other important software. They know that their
servers also run an internally written application that is unsigned but is rarely updated. They want to allow this
application to run.
To create the WDAC policy, they build a reference server on their standard hardware, and install all of the
software that their servers are known to run. Then they run New-CIPolicy with -Level Publisher (to allow
software from their software providers, the "Publishers") and -Fallback Hash (to allow the internal, unsigned
application). They enable the policy in auditing mode and gather information about any necessary software that
was not included on the reference server. They merge WDAC policies into the original policy to allow that
additional software to run. Then they enable the WDAC policy in enforced mode for their servers.
As part of normal operations, they will eventually install software updates, or perhaps add software from the
same software providers. Because the "Publisher" remains the same on those updates and software, they will
not need to update their WDAC policy. If they come to a time when the internally-written, unsigned application
must be updated, they must also update the WDAC policy so that the hash in the policy matches the hash of the
updated internal application.
They could also choose to create a catalog that captures information about the unsigned internal application,
then sign and distribute the catalog. Then the internal application could be handled by WDAC policies in the
same way as any other signed application. An update to the internal application would only require that the
catalog be regenerated, signed, and distributed (no restarts would be required).
More information about filepath rules

Filepath rules do not provide the same security guarantees that explicit signer rules do, as they are based on
mutable access permissions. Filepath rules are best suited for environments where most users are running as
standard rather than admin. IT Pros should take care while crafting path rules to allow paths that they know are
likely to remain to be admin-writeable only and deny execution from sub-directories where standard users can
modify ACLs on the folder.
By default, WDAC performs a user-writeability check at runtime which ensures that the current permissions on
the specified filepath and its parent directories (recursively) do not allow standard users write access.
There is a defined list of SIDs which WDAC recognizes as admins. If a filepath allows write permissions for any
SID not in this list, the filepath is considered to be user-writeable even if the additional SID is associated to a
custom admin user. To handle these special cases, you can override WDAC's runtime admin-writeable check with
the Disabled:Runtime FilePath Rule Protection option described above.
WDAC's list of well-known admin SIDs are:
S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-
577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-
4069167804-1277922394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-
444378811-2746676523.
When generating filepath rules using New-CIPolicy, a unique, fully-qualified path rule is generated for every file
discovered in the scanned path(s). To create rules that instead allow all files under a specified folder path, use
New-CIPolicyRule to define rules containing wildcards using the -FilePathRules switch.
Wildcards can be used at the beginning or end of a path rule; only one wildcard is allowed per path rule.
Wildcards placed at the end of a path authorize all files in that path and its subdirectories recursively (ex. C:\\*
would include C:\foo\\* ). Wildcards placed at the beginning of a path will allow the exact specified filename
under any path (ex. *\bar.exe would allow C:\bar.exe and C:\foo\bar.exe ). Wildcards in the middle of a path
are not supported (ex. C:\\*\foo.exe ). Without a wildcard, the rule will allow only a specific file (ex.
C:\foo\bar.exe ).
The use of macros is also supported and useful in scenarios where the system drive is different from the C:\
drive. Supported macros: %OSDRIVE% , %WINDIR% , %SYSTEM32% .
NOTE
Due to an existing bug, you can not combine Path-based ALLOW rules with any DENY rules in a single policy. Instead,
either separate DENY rules into a separate Base policy or move the Path-based ALLOW rules into a supplemental policy as
described in Deploy multiple WDAC policies.
Windows Defender Application Control filename rules

File name rule levels provide administrators to specify the file attributes off which to base a file name rule. File
name rules provide the same security guarantees that explicit signer rules do, as they are based on non-mutable
file attributes. Specification of the file name level occurs when creating new policy rules. In addition, to combine
file name levels found in multiple policies, you can merge multiple policies.
Use Table 3 to select the appropriate file name level for your available administrative resources and Windows
Defender Application Control deployment scenario. For instance, an LOB or production application and its
binaries (eg. DLLs) may all share the same product name. This allows users to easily create targeted policies
based on the Product Name filename rule level.
Table 3. Windows Defender Application Control policy - filename levels
File Description Specifies the file description provided by the developer of the
binary.
Internal Name Specifies the internal name of the binary.

Original File Name Specifies the original file name, or the name with which the
file was first created, of the binary.
Package Family Name Specifies the package family name of the binary. The package
family name consists of two parts: the name of the file and
the publisher ID.
Product Name Specifies the name of the product with which the binary
ships.
Authorize apps deployed with a WDAC managed
installer
Applies to:
Windows 10
Windows Server 2019
Windows 10, version 1703 (also known as the Windows 10 Creators Update) provides a new option, known as a
managed installer, that allows IT administrators to automatically authorize applications deployed and installed
by a designated software distribution solution such as Microsoft Endpoint Configuration Manager. A managed
installer helps an IT admin balance security and manageability requirements when employing application
execution control policies by providing an option that does not require specifying explicit rules for software that
is being managed through a software distribution solution.
How does a managed installer work?

A managed installer uses a new rule collection in AppLocker to specify one or more executables that are trusted
by the organization as an authorized source for application deployment.
Specifying an executable as a managed installer will cause Windows to tag files that are written from the
executable's process (or processes it launches) as having originated from a trusted installation authority. The
Managed Installer rule collection is currently supported for AppLocker rules in Group Policy and in
Configuration Manager, but not in the AppLocker CSP for OMA-URI policies.
Once the IT administrator adds the Allow: Managed Installer option to a WDAC policy, the WDAC component
will subsequently check for the presence of the origin information when evaluating other application execution
control rules specified in the policy. If there are no deny rules present for the file, it will be authorized based on
the managed installer origin information.
Admins needs to ensure that there is a WDAC policy in place to allow the system to boot and run any other
authorized applications that may not be deployed through a managed installer. An example managed installer
use-case can be seen in the guidance for creating a WDAC policy for fully-managed devices.
Note that a WDAC policy with managed installer configured will begin to tag files which originated from that
managed installer, regardless of whether the policy is in audit or enforced mode.
Security considerations with managed installer

Since managed installer is a heuristic-based mechanism, it does not provide the same security guarantees that
explicit allow or deny rules do. It is best suited for deployment to systems where each user is configured as a
standard user and where all software is deployed and installed by a software distribution solution, such as
Microsoft Endpoint Configuration Manager.
Users with administrator privileges or malware running as an administrator user on the system may be able to
circumvent the intent of Windows Defender Application Control when the managed installer option is allowed. If
the authorized managed installer process performs installations in the context of a user with standard privileges,
then it is possible that standard users or malware running as standard user may be able to circumvent the intent
of Windows Defender Application Control. Some application installers include an option to automatically run the
application at the end of the installation process. If this happens when the installer is run by a managed installer,
then the managed installer's heuristic tracking and authorization may continue to apply to all files created
during the first run of the application. This could result in over-authorization for executables that were not
intended. To avoid this, ensure that the application deployment solution being used as a managed installer limits
running applications as part of installation.
Known limitations with managed installer

Application execution control based on managed installer does not support applications that self-
update/auto-update. If an application deployed by a managed installer subsequently updates itself, the
updated application files will no longer include the managed installer origin information and will not be
authorized to run. Enterprises should deploy and install all application updates using the managed
installer. In some cases, it may be possible to also designate an application binary that performs the self-
updates as a managed installer. Proper review for functionality and security should be performed for the
application before using this method.
Modern apps deployed through a managed installer will not be tracked by the managed installer
heuristic and will need to be separately authorized in your WDAC policy.
Executables that extract files and then attempt to execute may not be allowed by the managed installer
heuristic. In some cases, it may be possible to also designate an application binary that performs such an
operation as a managed installer. Proper review for functionality and security should be performed for
the application before using this method.
The managed installer heuristic does not authorize drivers. The WDAC policy must have rules that allow
the necessary drivers to run.
In some cases, the code integrity logs where WDAC errors and warnings are written will contain error
events for native images generated for .NET assemblies. Typically, the error is functionally benign as a
blocked native image will result in the corresponding assembly being re-interpreted. Review for
functionality and performance for the related applications using the native images maybe necessary in
some cases.
Configuring a managed installer with AppLocker
and Windows Defender Application Control
Applies to:
Windows 10
Windows Server 2019
Setting up managed installer tracking and application execution enforcement requires applying both an
AppLocker and WDAC policy with specific rules and options enabled. There are three primary steps to keep in
mind:
Specify managed installers by using the Managed Installer rule collection in AppLocker policy.
Enable service enforcement in AppLocker policy.
Enable the managed installer option in a WDAC policy.
Specify managed installers using the Managed Installer rule collection

in AppLocker policy
The identity of the managed installer executable(s) is specified in an AppLocker policy in a Managed Installer
rule collection.
Create Managed Installer rule collection
Currently, neither the AppLocker policy creation UI in GPO Editor nor the PowerShell cmdlets allow for directly
specifying rules for the Managed Installer rule collection. However, a text editor can be used to make the simple
changes needed to an EXE or DLL rule collection policy to specify Type="ManagedInstaller", so that the new rule
can be imported into a GPO.
1. Use New-AppLockerPolicy to make an EXE rule for the file you are designating as a managed installer.
Note that only EXE file types can be designated as managed installers. Below is an example using the rule
type Publisher with a hash fallback, but other rule types can be used as well. You may need to reformat
the output for readability.
Get-ChildItem <exe filepath> | Get-AppLockerFileInformation | New-AppLockerPolicy -RuleType

Publisher, Hash -User Everyone -Xml > AppLocker_MI_PS_ISE.xml
2. Manually rename the rule collection to ManagedInstaller

Change
<RuleCollection Type="Exe" EnforcementMode="NotConfigured">
to
<RuleCollection Type="ManagedInstaller" EnforcementMode="AuditOnly">
An example of a valid Managed Installer rule collection using Microsoft Endpoint Config Manager (MEMCM) is
shown below.
<RuleCollection Type="ManagedInstaller" EnforcementMode="AuditOnly">

<FilePublisherRule Id="6cc9a840-b0fd-4f86-aca7-8424a22b4b93" Name="MEMCM - CCMEXEC.EXE, 5.0.0.0+,
Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US"
ProductName="*" BinaryName="CCMEXEC.EXE">
<BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
<FilePublisherRule Id="780ae2d3-5047-4240-8a57-767c251cbb12" Name="MEMCM - CCMSETUP.EXE, 5.0.0.0+,
Microsoft signed" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
<Conditions>
<FilePublisherCondition PublisherName="O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US"
ProductName="*" BinaryName="CCMSETUP.EXE">
<BinaryVersionRange LowSection="5.0.0.0" HighSection="*" />
</FilePublisherCondition>
</Conditions>
</FilePublisherRule>
</RuleCollection>
Enable service enforcement in AppLocker policy

Since many installation processes rely on services, it is typically necessary to enable tracking of services. Correct
tracking of services requires the presence of at least one rule in the rule collection, so a simple audit only rule
will suffice. This can be added to the policy created above which specifies your managed installer rule collection.
For example:
<RuleCollection Type="Dll" EnforcementMode="AuditOnly" >

<FilePathRule Id="86f235ad-3f7b-4121-bc95-ea8bde3a5db5" Name="Dummy Rule" Description=""
UserOrGroupSid="S-1-1-0" Action="Deny">
<Conditions>
<FilePathCondition Path="%OSDRIVE%\ThisWillBeBlocked.dll" />
</Conditions>
</FilePathRule>
<RuleCollectionExtensions>
<ThresholdExtensions>
<Services EnforcementMode="Enabled" />
</ThresholdExtensions>
<RedstoneExtensions>
<SystemApps Allow="Enabled"/>
</RedstoneExtensions>
</RuleCollectionExtensions>
</RuleCollection>
<RuleCollection Type="Exe" EnforcementMode="AuditOnly">
<FilePathRule Id="9420c496-046d-45ab-bd0e-455b2649e41e" Name="Dummy Rule" Description=""
UserOrGroupSid="S-1-1-0" Action="Deny">
<Conditions>
<FilePathCondition Path="%OSDRIVE%\ThisWillBeBlocked.exe" />
</Conditions>
</FilePathRule>
<RuleCollectionExtensions>
<ThresholdExtensions>
<Services EnforcementMode="Enabled" />
</ThresholdExtensions>
<RedstoneExtensions>
<SystemApps Allow="Enabled"/>
</RedstoneExtensions>
</RuleCollectionExtensions>
</RuleCollection>
Enable the managed installer option in WDAC policy
In order to enable trust for the binaries laid down by managed installers, the Enabled: Managed Installer option
must be specified in your WDAC policy. This can be done by using the Set-RuleOption cmdlet with Option 13.
Below are steps to create a WDAC policy which allows Windows to boot and enables the managed installer
option.
1. Copy the DefaultWindows_Audit policy into your working folder from
C:\Windows\schemas\CodeIntegrity\ExamplePolicies\DefaultWindows_Audit.xml
2. Reset the policy ID to ensure it is in multiple policy format and give it a different GUID from the example
policies. Also give it a friendly name to help with identification.
Ex.
Set-CIPolicyIdInfo -FilePath <XML filepath> -PolicyName "<friendly name>" -ResetPolicyID
3. Set Option 13 (Enabled:Managed Installer)
Set-RuleOption -FilePath <XML filepath> -Option 13
Set the AppLocker filter driver to autostart

To enable the managed installer, you need to set the AppLocker filter driver to autostart and start it.
To do so, run the following command as an Administrator:
appidtel.exe start [-mionly]
Specify -mionly if you will not use the Intelligent Security Graph (ISG).
Enabling managed installer logging events

Refer to Understanding Application Control Events for information on enabling optional managed installer
diagnostic events.
Authorize reputable apps with the Intelligent
Security Graph (ISG)
Applies to:
Windows 10
Application execution control can be difficult to implement in enterprises that do not have processes to
effectively control the deployment of applications centrally through an IT managed system. In such
environments, users are empowered to acquire the applications they need for work, making accounting for all
the applications that would need to be authorized for execution control a daunting task.
Windows 10, version 1709 (also known as the Windows 10 Fall Creators Update) provides a new option, known
as the Microsoft Intelligent Security Graph authorization, that allows IT administrators to automatically authorize
applications that the Microsoft Intelligent Security Graph recognizes as having known good reputation. The
Microsoft Intelligent Security Graph option helps IT organizations take a significant first step towards going
from having no application control at all to a simple means of preventing the execution of unknown and known
bad software. To learn more about the Microsoft Intelligent Security Graph, see the Security section in Major
services and features in Microsoft Graph.
How does the integration between WDAC and the Intelligent Security
Graph work?
The Microsoft Intelligent Security Graph relies on the same vast security intelligence and machine learning
analytics which power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify
applications as having known good, known bad, or unknown reputation. When an unevaluated file is run on a
system with WDAC enabled with the Microsoft Intelligent Security Graph authorization option specified, WDAC
queries the file's reputation by sending its hash and signing information to the cloud. If the Microsoft Intelligent
Security Graph determines that the file has a known good reputation, the
$KERNEL.SMARTLOCKER.ORIGINCLAIM kernel Extended Attribute (EA) is written to the file. Every time the file
tries to execute, if there are no explicit deny rules present for the file, it will be allowed to run based on its
positive reputation. Conversely, a file that has unknown or known bad reputation will still be allowed to run in
the presence of a rule that explicitly allows the file.
Additionally, an application installer which is determined to have known good reputation will pass along that
positive reputation to any files that it writes. This way, all the files needed to install and run an app are granted
positive reputation data.
WDAC periodically re-queries the reputation data on a file. Additionally, enterprises can specify that any cached
reputation results are flushed on reboot by using the Enabled:Invalidate EAs on Reboot option.
NOTE
Admins should make sure there is a WDAC policy in place to allow the system to boot and run any other authorized
applications that may not be classified as being known good by the Intelligent Security Graph, such as custom line-of-
business (LOB) apps. Since the Intelligent Security Graph is powered by global prevalence data, internal LOB apps may not
be recognized as being known good. Other mechanisms like managed installer and explicit rules will help cover internal
applications. Both Microsoft Endpoint Manager Configuration Manager (MEMCM) and Microsoft Endpoint Manager
Intune (MEM Intune) can be used to create and push a WDAC policy to your client machines.
Other examples of WDAC policies are available in C:\Windows\schemas\CodeIntegrity\ExamplePolicies and can

help authorize Windows OS components, WHQL signed drivers and all Store apps. Admins can reference and
customize them as needed for their Windows Defender Application Control deployment or create a custom
WDAC policy.
Configuring Intelligent Security Graph authorization for Windows

Defender Application Control
Setting up the Microsoft Intelligent Security Graph authorization is easy regardless of what management
solution you use. Configuring the Microsoft Intelligent Security Graph option involves these basic steps:
Ensure that the Microsoft Intelligent Security Graph option is enabled in the WDAC policy XML
Enable the necessary services to allow WDAC to use the Microsoft Intelligent Security Graph correctly on the
client
Ensure that the Intelligent Security Graph option is enabled in the WDAC policy XML
In order to enable trust for executables based on classifications in the Microsoft Intelligent Security Graph, the
Enabled:Intelligent Security Graph authorization option must be specified in the WDAC policy. This can be
done with the Set-RuleOption cmdlet. In addition, it is recommended from a security perspective to also enable
the Enabled:Invalidate EAs on Reboot option to invalidate the cached Intelligent Security Graph results on
reboot to force rechecking of applications against the Microsoft Intelligent Security Graph. Caution is advised if
devices will regularly transition to and from environments that may not be able to access the Microsoft
Intelligent Security Graph. The following example shows both options being set.
<Rules>
<Rule>
<Option>Enabled:Unsigned System Integrity Policy</Option>
</Rule>
<Rule>
<Option>Enabled:Advanced Boot Options Menu</Option>
</Rule>
<Rule>
<Option>Required:Enforce Store Applications</Option>
</Rule>
<Rule>
<Option>Enabled:UMCI</Option>
</Rule>
<Rule>
<Option>Enabled:Managed Installer</Option>
</Rule>
<Rule>
<Option>Enabled:Intelligent Security Graph Authorization</Option>
</Rule>
<Rule>
<Option>Enabled:Invalidate EAs on Reboot</Option>
</Rule>
</Rules>
Enable the necessary services to allow WDAC to use the ISG correctly on the client
In order for the heuristics used by the Microsoft Intelligent Security Graph to function properly, a number of
component in Windows must be enabled. The easiest way to do this is to run the appidtel executable in
c:\windows\system32 .
appidtel start
This step is not required for WDAC policies deployed over MDM using the AppLocker CSP, as the CSP will enable
the necessary components. This step is also not required when enabling the Microsoft Intelligent Security Graph
through the MEMCM WDAC UX. However, if custom policies are being deployed outside of the WDAC UX
through MEMCM, then this step is required.
Security considerations with the Intelligent Security Graph

Since the Microsoft Intelligent Security Graph is a heuristic-based mechanism, it does not provide the same
security guarantees that explicit allow or deny rules do. It is best suited for deployment to systems where each
user is configured as a standard user and there are other monitoring systems in place like Microsoft Defender
for Endpoint to help provide optics into what users are doing.
Users with administrator privileges or malware running as an administrator user on the system may be able to
circumvent the intent of WDAC when the Microsoft Intelligent Security Graph option is allowed by
circumventing or corrupting the heuristics used to assign reputation to application executables. The Microsoft
Intelligent Security Graph option uses the same heuristic tracking as managed installer and so for application
installers that include an option to automatically run the application at the end of the installation process the
heuristic may over-authorize.
Known limitations with using the Intelligent Security Graph

Since the Microsoft Intelligent Security Graph relies on identifying executables as being known good, there are
cases where it may classify legitimate executables as unknown, leading to blocks that need to be resolved either
with a rule in the WDAC policy, a catalog signed by a certificate trusted in the WDAC policy or by deployment
through a WDAC managed installer. Typically, this is due to an installer or application using a dynamic file as
part of execution. These files do not tend to build up known good reputation. Auto-updating applications have
also been observed using this mechanism and may be flagged by the ISG.
Modern apps are not supported with the Microsoft Intelligent Security Graph heuristics and will need to be
separately authorized in your WDAC policy. As modern apps are signed by the Microsoft Store and Microsoft
Store for Business, it is straightforward to authorize modern apps with signer rules in the WDAC policy.
The Microsoft Intelligent Security Graph heuristics do not authorize kernel mode drivers. The WDAC policy must
have rules that allow the necessary drivers to run.
In some cases, the code integrity logs where WDAC errors and warnings are written will contain error events for
native images generated for .NET assemblies. Typically, the error is functionally benign as a blocked native
image will result in the corresponding assembly being re-interpreted. Review for functionality and performance
for the related applications using the native images maybe necessary in some cases.
NOTE
A rule that explicitly denies or allows a file will take precedence over that file's reputation data. MEM Intune's built-in
WDAC support includes the option to trust apps with good reputation via the Microsoft Intelligent Security Graph, but it
has no option to add explicit allow or deny rules. In most circumstances, customers enforcing application control need to
deploy a custom WDAC policy (which can include the Microsoft Intelligent Security Graph option if desired) using Intune's
OMA-URI functionality.
Use multiple Windows Defender Application
Control Policies
Applies to:
Windows 10
Windows Server 2016
The restriction of only having a single code integrity policy active on a system at any given time has felt limiting
for customers in situations where multiple policies with different intents would be useful. Beginning with
Windows 10 version 1903, WDAC supports up to 32 active policies on a device at once in order to enable the
following scenarios:
1. Enforce and Audit Side-by-Side
To validate policy changes before deploying in enforcement mode, users can now deploy an audit-
mode base policy side by side with an existing enforcement-mode base policy
2. Multiple Base Policies
Users can enforce two or more base policies simultaneously in order to allow simpler policy targeting
for policies with different scope/intent
If two base policies exist on a device, an application has to be allowed by both to run
3. Supplemental Policies
Users can deploy one or more supplemental policies to expand a base policy
A supplemental policy expands a single base policy, and multiple supplemental policies can expand
the same base policy
For supplemental policies, applications that are allowed by either the base policy or its supplemental
policy/policies are allowed to run
NOTE
Pre-1903 systems do not support the use of Multiple Policy Format WDAC policies.
Base and supplemental policy interaction

Multiple base policies: intersection
Only applications allowed by both policies run without generating block events
Base + supplemental policy: union
Files that are allowed by either the base policy or the supplemental policy are not blocked
Creating WDAC policies in Multiple Policy Format

In order to allow multiple policies to exist and take effect on a single system, policies must be created using the
new Multiple Policy Format. The "MultiplePolicyFormat" switch in New-CIPolicy results in 1) random GUIDs
being generated for the policy ID and 2) the policy type being specified as base. The below is an example of
creating a new policy in the multiple policy format.
New-CIPolicy -MultiplePolicyFormat -ScanPath "<path>" -UserPEs -FilePath ".\policy.xml" -Level Publisher -
Fallback Hash
Optionally, you can choose to make the new base policy allow for supplemental policies.
Set-RuleOption -FilePath <string> -Option 17
For signed base policies to allow for supplemental policies, make sure that supplemental signers are defined.
Use the Supplemental switch in Add-SignerRule to provide supplemental signers.
Add-SignerRule -FilePath <string> -CertificatePath <string> [-Kernel] [-User] [-Update] [-Supplemental] [-

Deny] [<CommonParameters>]
Supplemental policy creation

In order to create a supplemental policy, begin by creating a new policy in the Multiple Policy Format as shown
above. From there, use Set-CIPolicyIdInfo to convert it to a supplemental policy and specify which base policy it
expands. You can use either SupplementsBasePolicyID or BasePolicyToSupplementPath to specify the base policy.
"SupplementsBasePolicyID": GUID of base policy that the supplemental policy applies to
"BasePolicyToSupplementPath": path to base policy file that the supplemental policy applies to
Set-CIPolicyIdInfo [-FilePath] <string> [-PolicyName <string>] [-SupplementsBasePolicyID <guid>] [-

BasePolicyToSupplementPath <string>] [-ResetPolicyID] [-PolicyId <string>] [<CommonParameters>]
NOTE
ResetPolicyId reverts a supplemental policy to a base policy, and resets the policy GUIDs back to a random GUID.
Merging policies
When merging, the policy type and ID of the leftmost/first policy specified is used. If the leftmost is a base policy
with ID <ID>, then regardless of what the GUIDs and types are for any subsequent policies, the merged policy
will be a base policy with ID <ID>.
Deploying multiple policies

In order to deploy multiple WDAC policies, you must either deploy them locally by copying the *.cip policy
files into the proper folder or by using the ApplicationControl CSP, which is supported by MEM Intune's Custom
OMA-URI feature.
Deploying multiple policies locally
To deploy policies locally using the new multiple policy format, follow these steps:
1. Ensure binary policy files have the correct naming format of {PolicyGUID}.cip .
Ensure that the name of the binary policy file is exactly the same as the PolicyID GUID in the policy
For example, if the policy XML had the ID as
<PolicyID>{A6D7FBBF-9F6B-4072-BF37-693741E1D745}</PolicyID> , then the correct name for the binary
policy file would be {A6D7FBBF-9F6B-4072-BF37-693741E1D745}.cip .
2. Copy binary policies to C:\Windows\System32\CodeIntegrity\CiPolicies\Active .
3. Reboot the system.
Deploying multiple policies via ApplicationControl CSP
Multiple WDAC policies can be managed from an MDM server through ApplicationControl configuration service
provider (CSP). The CSP also provides support for rebootless policy deployment. See ApplicationControl CSP for
more information on deploying multiple policies, optionally using MEM Intune's Custom OMA-URI capability.
NOTE
WMI and GP do not currently support multiple policies. Instead, customers who cannot directly access the MDM stack
should use the ApplicationControl CSP via the MDM Bridge WMI Provider to manage Multiple Policy Format WDAC
policies.
Applies to:
Windows 10
Members of the security community* continuously collaborate with Microsoft to help protect customers. With
the help of their valuable reports, Microsoft has identified a list of valid applications that an attacker could also
potentially use to bypass Windows Defender Application Control.
Unless your use scenarios explicitly require them, Microsoft recommends that you block the following
applications. These applications or files can be used by an attacker to circumvent application allow policies,
including Windows Defender Application Control:
addinprocess.exe
addinprocess32.exe
addinutil.exe
aspnet_compiler.exe
bash.exe
bginfo.exe1
cdb.exe
csi.exe
dbghost.exe
dbgsvc.exe
dnx.exe
dotnet.exe
fsi.exe
fsiAnyCpu.exe
infdefaultinstall.exe
kd.exe
kill.exe
lxssmanager.dll
lxrun.exe
Microsoft.Build.dll
Microsoft.Build.Framework.dll
Microsoft.Workflow.Compiler.exe
msbuild.exe2
msbuild.dll
mshta.exe
ntkd.exe
ntsd.exe
powershellcustomhost.exe
rcsi.exe
runscripthelper.exe
texttransform.exe
visualuiaverifynative.exe
system.management.automation.dll
wfc.exe
windbg.exe
wmic.exe
wsl.exe
wslconfig.exe
wslhost.exe
1 A vulnerability in bginfo.exe has been fixed in the latest version 4.22. If you use BGInfo, for
security, make sure
to download and run the latest version here BGInfo 4.22. Note that BGInfo versions earlier than 4.22 are still
vulnerable and should be blocked.
2 If you are using yourreference system in a development context and use msbuild.exe to build managed
applications, we recommend that you allow msbuild.exe in your code integrity policies. However, if your
reference system is an end user device that is not being used in a development context, we recommend that you
block msbuild.exe.
* Microsoft recognizes the efforts of those in the security community who help us protect customers through
responsible vulnerability disclosure, and extends thanks to the following people:
NAME T W IT T ER
Casey Smith @subTee
Matt Graeber @mattifestation
Matt Nelson @enigma0x3
Oddvar Moe @Oddvarmoe
Alex Ionescu @aionescu
Lee Christensen @tifkin_
Vladas Bulavas Kaspersky Lab
Lasse Trolle Borup Langkjaer Cyber Defence
Jimmy Bayne @bohops
Philip Tsukerman @PhilipTsukerman
Brock Mammen
NOTE
This application list will be updated with the latest vendor information as application vulnerabilities are resolved and new
issues are discovered.
Certain software applications may allow additional code to run by design. These types of applications should be
blocked by your Windows Defender Application Control policy. In addition, when an application version is
upgraded to fix a security vulnerability or potential Windows Defender Application Control bypass, you should
add deny rules to your WDAC policies for that application’s previous, less secure versions.
Microsoft recommends that you install the latest security updates. The June 2017 Windows updates resolve
several issues in PowerShell modules that allowed an attacker to bypass Windows Defender Application Control.
These modules cannot be blocked by name or version, and therefore must be blocked by their corresponding
hashes.
For October 2017, we are announcing an update to system.management.automation.dll in which we are
revoking older versions by hash values, instead of version rules.
Microsoft recommends that you block the following Microsoft-signed applications and PowerShell files by
merging the following policy into your existing policy to add these deny rules using the Merge-CIPolicy cmdlet.
Beginning with the March 2019 quality update, each version of Windows requires blocking a specific version of
the following files:
msxml3.dll
msxml6.dll
jscript9.dll
Pick the correct version of each .dll for the Windows release you plan to support, and remove the other versions.
Ensure that you also uncomment them in the signing scenarios section.
<?xml version="1.0" encoding="utf-8" ?>

<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy">
<VersionEx>10.0.0.0</VersionEx>
<PolicyTypeID>{A244370E-44C9-4C06-B551-F6016E563076}</PolicyTypeID>
<PlatformID>{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}</PlatformID>
<Rules>
<Rule>
</Rule>
<Rule>
<Option>Enabled:Audit Mode</Option>
</Rule>
<Rule>
</Rule>
<Rule>
</Rule>
</Rules>

<EKUs />

<FileRules>
<Deny ID="ID_DENY_ADDINPROCESS" FriendlyName="AddInProcess.exe" FileName="AddInProcess.exe"
MinimumFileVersion="65535.65535.65535.65535"/>
<Deny ID="ID_DENY_ADDINPROCESS32" FriendlyName="AddInProcess32.exe" FileName="AddInProcess32.exe"
<Deny ID="ID_DENY_ADDINUTIL" FriendlyName="AddInUtil.exe" FileName="AddInUtil.exe"
<Deny ID="ID_DENY_ASPNET" FriendlyName="aspnet_compiler.exe" FileName="aspnet_compiler.exe"
<Deny ID="ID_DENY_BASH" FriendlyName="bash.exe" FileName="bash.exe"
<Deny ID="ID_DENY_BGINFO" FriendlyName="bginfo.exe" FileName="BGINFO.Exe" MinimumFileVersion="4.21.0.0"/>
<Deny ID="ID_DENY_CBD" FriendlyName="cdb.exe" FileName="CDB.Exe"
<Deny ID="ID_DENY_CSI" FriendlyName="csi.exe" FileName="csi.Exe"
<Deny ID="ID_DENY_DBGHOST" FriendlyName="dbghost.exe" FileName="DBGHOST.Exe"
<Deny ID="ID_DENY_DBGSVC" FriendlyName="dbgsvc.exe" FileName="DBGSVC.Exe" MinimumFileVersion="2.3.0.0"/>
<Deny ID="ID_DENY_DNX" FriendlyName="dnx.exe" FileName="dnx.Exe"
<Deny ID="ID_DENY_DOTNET" FriendlyName="dotnet.exe" FileName="dotnet.exe"
MinimumFileVersion="65535.65535.65535.65535" />
<Deny ID="ID_DENY_FSI" FriendlyName="fsi.exe" FileName="fsi.exe"
<Deny ID="ID_DENY_FSI_ANYCPU" FriendlyName="fsiAnyCpu.exe" FileName="fsiAnyCpu.exe"
<Deny ID="ID_DENY_INFINSTALL" FriendlyName="infdefaultinstall.exe" FileName="infdefaultinstall.exe"
<Deny ID="ID_DENY_KD" FriendlyName="kd.exe" FileName="kd.Exe"
<Deny ID="ID_DENY_KD_KMCI" FriendlyName="kd.exe" FileName="kd.Exe"
<Deny ID="ID_DENY_KILL" FriendlyName="kill.exe" FileName="kill.exe"
<Deny ID="ID_DENY_LXRUN" FriendlyName="lxrun.exe" FileName="lxrun.exe"
<Deny ID="ID_DENY_LXSS" FriendlyName="LxssManager.dll" FileName="LxssManager.dll"
<Deny ID="ID_DENY_MFC40" FriendlyName="mfc40.dll" FileName="mfc40.dll"
<Deny ID="ID_DENY_MS_BUILD" FriendlyName="Microsoft.Build.dll" FileName="Microsoft.Build.dll"
<Deny ID="ID_DENY_MS_BUILD_FMWK" FriendlyName="Microsoft.Build.Framework.dll"
FileName="Microsoft.Build.Framework.dll" MinimumFileVersion="65535.65535.65535.65535" />
<Deny ID="ID_DENY_MWFC" FriendlyName="Microsoft.Workflow.Compiler.exe"
FileName="Microsoft.Workflow.Compiler.exe" MinimumFileVersion="65535.65535.65535.65535" />
<Deny ID="ID_DENY_MSBUILD" FriendlyName="MSBuild.exe" FileName="MSBuild.Exe"
<Deny ID="ID_DENY_MSBUILD_DLL" FriendlyName="MSBuild.dll" FileName="MSBuild.dll"
<Deny ID="ID_DENY_MSHTA" FriendlyName="mshta.exe" FileName="mshta.exe"
<Deny ID="ID_DENY_NTKD" FriendlyName="ntkd.exe" FileName="ntkd.Exe"
<Deny ID="ID_DENY_NTSD" FriendlyName="ntsd.exe" FileName="ntsd.Exe"
<Deny ID="ID_DENY_PWRSHLCUSTOMHOST" FriendlyName="powershellcustomhost.exe"
FileName="powershellcustomhost.exe" MinimumFileVersion="65535.65535.65535.65535"/>
<Deny ID="ID_DENY_RCSI" FriendlyName="rcsi.exe" FileName="rcsi.Exe"
<Deny ID="ID_DENY_RUNSCRIPTHELPER" FriendlyName="runscripthelper.exe" FileName="runscripthelper.exe"
<Deny ID="ID_DENY_TEXTTRANSFORM" FriendlyName="texttransform.exe" FileName="texttransform.exe"
<Deny ID="ID_DENY_VISUALUIAVERIFY" FriendlyName="visualuiaverifynative.exe"
FileName="visualuiaverifynative.exe" MinimumFileVersion="65535.65535.65535.65535"/>
<Deny ID="ID_DENY_WFC" FriendlyName="WFC.exe" FileName="wfc.exe"
<Deny ID="ID_DENY_WINDBG" FriendlyName="windbg.exe" FileName="windbg.Exe"
<Deny ID="ID_DENY_WMIC" FriendlyName="wmic.exe" FileName="wmic.exe"
<Deny ID="ID_DENY_WSL" FriendlyName="wsl.exe" FileName="wsl.exe"
<Deny ID="ID_DENY_WSLCONFIG" FriendlyName="wslconfig.exe" FileName="wslconfig.exe"
<Deny ID="ID_DENY_WSLHOST" FriendlyName="wslhost.exe" FileName="wslhost.exe"



-->
-->
-->
-->
<Deny ID="ID_DENY_D_1" FriendlyName="Powershell 1" Hash="02BE82F63EE962BCD4B8303E60F806F6613759C6"/>
<Deny ID="ID_DENY_D_2" FriendlyName="Powershell 2" Hash="13765D9A16CC46B2113766822627F026A68431DF"/>
<Deny ID="ID_DENY_D_3" FriendlyName="Powershell 3"
Hash="148972F670E18790D62D753E01ED8D22B351A57E45544D88ACE380FEDAF24A40"/>
<Deny ID="ID_DENY_D_4" FriendlyName="Powershell 4" Hash="29DF1D593D0D7AB365F02645E7EF4BCCA060763A"/>
<Deny ID="ID_DENY_D_5" FriendlyName="Powershell 5" Hash="2E3C47BBE1BA99842EE187F756CA616EFED61B94"/>
Hash="38DC1956313B160696A172074C6F5DA9852BF508F55AFB7FA079B98F2849AFB5"/>
<Deny ID="ID_DENY_D_7" FriendlyName="Powershell 7" Hash="513B625EA507ED9CE83E2FB2ED4F3D586C2AA379"/>
Hash="71FC552E66327EDAA72D72C362846BD80CB65EECFAE95C4D790C9A2330D95EE6"/>
Hash="72E4EC687CFE357F3E681A7500B6FF009717A2E9538956908D3B52B9C865C189"/>
Hash="74E207F539C4EAC648A5507EB158AEE9F6EA401E51808E83E73709CFA0820FDD"/>
Hash="75288A0CF0806A68D8DA721538E64038D755BBE74B52F4B63FEE5049AE868AC0"/>
<Deny ID="ID_DENY_D_12" FriendlyName="Powershell 12" Hash="7DB3AD53985C455990DD9847DE15BDB271E0C8D1"/>
Hash="84BB081141DA50B3839CD275FF34854F53AECB96CA9AEB8BCD24355C33C1E73E"/>
<Deny ID="ID_DENY_D_14" FriendlyName="Powershell 14" Hash="86DADE56A1DBAB6DDC2769839F89244693D319C6"/>
Hash="BD3139CE7553AC7003C96304F08EAEC2CDB2CC6A869D36D6F1E478DA02D3AA16"/>
Hash="BE3FFE10CDE8B62C3E8FD4D8198F272B6BD15364A33362BB07A0AFF6731DABA1"/>
<Deny ID="ID_DENY_D_17" FriendlyName="Powershell 17" Hash="C1196433541B87D22CE2DD19AAAF133C9C13037A"/>
Hash="C6C073A80A8E76DC13E724B5E66FE4035A19CCA0C1AF3FABBC18E5185D1B66CB"/>
<Deny ID="ID_DENY_D_19" FriendlyName="Powershell 19" Hash="CE5EA2D29F9DD3F15CF3682564B0E765ED3A8FE1"/>
<Deny ID="ID_DENY_D_20" FriendlyName="Powershell 20" Hash="D027E09D9D9828A87701288EFC91D240C0DEC2C3"/>
<Deny ID="ID_DENY_D_21" FriendlyName="Powershell 21" Hash="D2CFC8F6729E510AE5BA9BECCF37E0B49DDF5E31"/>
<Deny ID="ID_DENY_D_22" FriendlyName="Powershell 22" Hash="DED853481A176999723413685A79B36DD0F120F9"/>
<Deny ID="ID_DENY_D_23" FriendlyName="Powershell 23" Hash="DFCD10EAA2A22884E0A41C4D9E6E8DA265321870"/>
Hash="F16E605B55774CDFFDB0EB99FAFF43A40622ED2AB1C011D1195878F4B20030BC"/>
Hash="F29A958287788A6EEDE6035D49EF5CB85EEC40D214FDDE5A0C6CAA65AFC00EEC"/>
Hash="F875E43E12685ECE0BA2D42D55A13798CE9F1FFDE3CAE253D2529F4304811A52"/>

<Deny ID="ID_DENY_D_27" FriendlyName="PowerShell 27" Hash="720D826A84284E18E0003526A0CD9B7FF0C4A98A"/>
<Deny ID="ID_DENY_D_28" FriendlyName="PowerShell 28"
Hash="CB5DF9D0D25571948C3D257882E07C7FA5E768448E0DEBF637E110F9FF575808"/>
<Deny ID="ID_DENY_D_29" FriendlyName="PowerShell 29" Hash="3C7265C3393C585D32E509B2D2EC048C73AC5EE6"/>
Hash="7F1E03E956CA38CC0C491CB958D6E61A52491269CDB363BC488B525F80C56424"/>
<Deny ID="ID_DENY_D_31" FriendlyName="PowerShell 31" Hash="27D86C9B54E1A97399A6DC9C9DF9AE030CB734C8"/>
Hash="917BD10E82C6E932F9C63B9BDCCC1D9BF04510CD8491B005CFFD273B48B5CD1E"/>
<Deny ID="ID_DENY_D_33" FriendlyName="PowerShell 33" Hash="B3BB2D75AECB34ED316CE54C6D513420186E4950"/>
Hash="B734F6269A6738861E1DF98EE0E4E7377FAED10B82AAA9731DA0BB1CB366FCCE"/>
<Deny ID="ID_DENY_D_35" FriendlyName="PowerShell 35" Hash="FF378B465F2C8A87B4092F7C1F96399C0156CEEB"/>
Hash="9B884CFE78F921042B003574AE30D9E86EE3DCC11E7110A1C92927F13C3F47E6"/>
<Deny ID="ID_DENY_D_37" FriendlyName="PowerShell 37" Hash="C7B99E8B59182112A3A14BD39880BDCDDD5C724F"/>
Hash="6E585890C7369D6D8DA85C8B6B7411463BAA1ACAE9CE4197E033A46C897B35E5"/>
<Deny ID="ID_DENY_D_39" FriendlyName="PowerShell 39" Hash="BA4B3A92123FBCE66398020AFBCC0BCA1D1AAAD7"/>
Hash="D8D361E3690676C7FDC483003BFC5C0C39FB16B42DFC881FB8D42A1064740B0B"/>
<Deny ID="ID_DENY_D_41" FriendlyName="PowerShell 41" Hash="1EA5104AE1A7A53F9421E0193B749F310B9261D1"/>
Hash="66C1B8569019512ACDDC145DA6D348A68DE008BE7C05930AD0EC6927C26061AD"/>
<Deny ID="ID_DENY_D_43" FriendlyName="PowerShell 43" Hash="4EB2C3A4B551FC028E00F2E7DA9D0F1E38728571"/>
Hash="30EAC589069FB79D540080B04B7FDBB8A9B1DF4E96B9D7C98519E49A1ED56851"/>
<Deny ID="ID_DENY_D_45" FriendlyName="PowerShell 45" Hash="E55505B609DD7A22F55C4BA9EDAD5627ECA6A8E8"/>
Hash="ABDDA9C1EDA9F2344FB5B79890B7FD854D0E3D28BEC26AE33AAD196948AB642D"/>
<Deny ID="ID_DENY_D_47" FriendlyName="PowerShell 47" Hash="A15964475D213FB752B42E7DCDDBF4B14D623D14"/>
Hash="61A68B436D828193E0C7B44D2AF83D22A9CB557B90186E4E6AC998CE5E3BFE8A"/>
<Deny ID="ID_DENY_D_49" FriendlyName="PowerShell 49" Hash="DB0C4B5CA1CBC3B117AB0439C5937B6A263DFD87"/>
Hash="6D4FB385328CA01700092E1CDF75A97123A95120D5F8A9877FFB4D5A8531380B"/>
<Deny ID="ID_DENY_D_51" FriendlyName="PowerShell 51" Hash="72F9DCDA6ECDD6906A2538DFE795A2E2CA787BBC"/>
Hash="F98FEC4A0306BD398F7FB7F611679B7797D32D54D1F2B35D728C0C7A058153ED"/>
<Deny ID="ID_DENY_D_53" FriendlyName="PowerShell 53" Hash="C980B65B86F780AC93B9458E9657291083CFEDA8"/>
Hash="F9473493FF53274B8E75EC7E517F324AA0C5644C6F8045D3EF3A1B9A669ECF78"/>
<Deny ID="ID_DENY_D_55" FriendlyName="PowerShell 55" Hash="C30355B5E6FA3F793A3CC0A649945829723DD85C"/>
Hash="4EB14099165177F0F3A1FACE32E72CF2DD221DB44155E73AFF94CB7DA195EF22"/>
<Deny ID="ID_DENY_D_57" FriendlyName="PowerShell 57" Hash="5C6CC1903D3DA2054ECD9A295EEE26F5561E152A"/>
Hash="0BF8CAB75DAB712FC848DE7CC7DC5C8A10D666515E7535F89146F45AAAF9EF54"/>
<Deny ID="ID_DENY_D_59" FriendlyName="PowerShell 59" Hash="1443E8F56DEE11EEF5B746E3657C2F953FD4F6EA"/>
Hash="487CB42795046E885303FC96EA54C3234E1B2072DAEB4F9218C21CC6C39A3223"/>
<Deny ID="ID_DENY_D_61" FriendlyName="PowerShell 61" Hash="072D4E33D1478C863DBAB20BF5DFF1A0FB5A9D53"/>
Hash="631E091AE7AD2C543EE5755BC9D8DB34683C41E20D9A6CD41C8F07827156D6DB"/>
<Deny ID="ID_DENY_D_63" FriendlyName="PowerShell 63" Hash="FD15A313B890369B7D8E26C13B2070AE044FB4D8"/>
Hash="AB9886A0993F87C2A39BC7822EE44FD4B4751C530ACF292ACD0319C967FB4F3B"/>
<Deny ID="ID_DENY_D_65" FriendlyName="PowerShell 65" Hash="4BAFD867B59328E7BB853148FE6D16B9411D7A12"/>
Hash="D1F22B37902C2DD53FA27438436D9D236A196C10C8E492A8F4A14768644592D3"/>
<Deny ID="ID_DENY_D_67" FriendlyName="PowerShell 67" Hash="AC53AE4C8AB56D84393D67D820BEBDC3218739D3"/>
Hash="49580C9459C3917E6F982C8E0D753D293DFA2E4FD1152F78FF7C73CF8B422507"/>
<Deny ID="ID_DENY_D_69" FriendlyName="PowerShell 69" Hash="333678A44D4BEBE9BEA3041FFDA9E2B55B58F1B5"/>
Hash="94CBBC3970F01280D98C951BD0C4158D4B09A2BE21B8A27790D9F127B78C6F3F"/>
<Deny ID="ID_DENY_D_71" FriendlyName="PowerShell 71" Hash="5F5620DC049FE1F1C2DBAC077A59BA69CF2FF72C"/>
Hash="A32C0769F36CAE0B6A7A1B8CCB6B7A75AA8BEB7F49815E96B4E120BFD7527E0A"/>
<Deny ID="ID_DENY_D_73" FriendlyName="PowerShell 73" Hash="BDBE541D269EC8235563842D024F9E37883DFB57"/>
Hash="441076C7FD0AD481E6AC3198F08BE80EA9EB2926CA81D733F798D03DBEFD683E"/>
<Deny ID="ID_DENY_D_75" FriendlyName="PowerShell 75" Hash="FD6FE9143A46F4EBB46E6B46332FA7171002EBF0"/>
Hash="85399D84601207AB92C8CA4D7D6E58CB1B0B0B57ED94FA7E5A1191FA1810E223"/>
<Deny ID="ID_DENY_D_77" FriendlyName="PowerShell 77" Hash="98FD94A89DCF92A7BEDB51C72BAD1A67650DD6E5"/>
Hash="5CE4B042E986DAFEB7E2D2ABFB80376C4DEC325DB23B584B76039EEA6E1A74B1"/>
<Deny ID="ID_DENY_D_79" FriendlyName="PowerShell 79" Hash="6BC1E70F0EA84E88AC28BEAF74C10F3ABDF99209"/>
Hash="93CB3907D1A9473E8A90593250C4A95EAE3A7066E9D8A57535CBDF82AA4AD4C2"/>
<Deny ID="ID_DENY_D_81" FriendlyName="PowerShell 81" Hash="7FCE82DBBC0FE45AFBE3927C323349C32D5A463A"/>
Hash="2EDA8CA129E30CB5522C4DCD1E5AFDCA1E9C6447DD7053DACEF18DCDCCF3E2BC"/>
<Deny ID="ID_DENY_D_83" FriendlyName="PowerShell 83" Hash="BDB3DAC80667A0B931835D5D658C08F236B413D1"/>
Hash="51287BACB692AAC5A8659774D982B304DC0C0B4A4D8F41CBCCD47D69796786DE"/>
<Deny ID="ID_DENY_D_85" FriendlyName="PowerShell 85" Hash="9633529CACE25ACCB29EBC5941DE1874903C0297"/>
Hash="483A3997D5DA69A51DC7EA368A36C3CA4A5BD56CB08BFD9912BE799005156C18"/>
<Deny ID="ID_DENY_D_87" FriendlyName="PowerShell 87" Hash="B3493E30A2C347B550331C86529BDC288EAF8186"/>
Hash="9371E2333906441715DE15FEE8A9AA03C4D076CA3C04D9A7AB0CC32189DA66ED"/>
<Deny ID="ID_DENY_D_89" FriendlyName="PowerShell 89" Hash="5D4B0794EB973D61CF74A700F11BE84E527E0E51"/>
Hash="537DE34A1F4B3F8345D02F5BBA2B063F070A42FC1581AAC2AA91C1D071B14521"/>
<Deny ID="ID_DENY_D_91" FriendlyName="PowerShell 91" Hash="F3C75F35F42C1C5B3B4ED888187D6AB4035F994C"/>
Hash="AD5678ED0734281973465DD728281A6C0EA146620FF2106A4EEFC7E94622B92F"/>
<Deny ID="ID_DENY_D_93" FriendlyName="PowerShell 93" Hash="91C0F76798A9679188C7D93FDEBAF797BDBE41B2"/>
Hash="1D9244EAFEDFBFC02E13822E24A476C36FFD362B9D18F6CD195B654A34F946FF"/>
<Deny ID="ID_DENY_D_95" FriendlyName="PowerShell 95" Hash="7FCB424E67DDAC49413B45D7DCD636AD70E23B41"/>
Hash="7E6F9A738520F78D1E9D0D0883FB07DD9188408CBE7C2937BDE1590F90C61753"/>
<Deny ID="ID_DENY_D_97" FriendlyName="PowerShell 97" Hash="A9745E20419EC1C90B23FE965D3C2DF028AF39DC"/>
Hash="71B5B58EAA0C90397BC9546BCCA8C657500499CD2087CD7D7E1753D54C07E71D"/>
<Deny ID="ID_DENY_D_99" FriendlyName="PowerShell 99" Hash="3E5294910C59394DA93962128968E6C23016A028"/>
Hash="DA700D4F58BCEA1D5A9CAD4F20AC725C6A354F9DA40E4F8F95E1C3DC7B84F550"/>
<Deny ID="ID_DENY_D_101" FriendlyName="PowerShell 101" Hash="266896FD257AD8EE9FC73B3A50306A573714EA8A"/>
Hash="8E36BD08084C73AF674F2DAD568EE3BA2C85769FA7B3400CB62F7A7BD028BE9A"/>
<Deny ID="ID_DENY_D_103" FriendlyName="PowerShell 103" Hash="2CB781B3BD79FD277D92332ACA22C04430F9D692"/>
Hash="92AE03F0090C0A5DF329B4B3FFEDBA622B0521BA699FA303C24120A30ED4C9E6"/>
<Deny ID="ID_DENY_D_105" FriendlyName="PowerShell 105" Hash="D82583F7D5EA477C94630AC5AAEB771C85BD4B0A"/>
Hash="9B0F39AB233628A971ACEC53029C9B608CAB99868F1A1C5ABE20BC1BD1C2B70E"/>
<Deny ID="ID_DENY_D_107" FriendlyName="PowerShell 107" Hash="2DF4350DE3C97C9D4FD2973F8C5EA8AE621D22A8"/>
Hash="015CE571E8503A353E2250D4D0DA19493B3311F3437527E6DDD2D2B6439FA2EB"/>
<Deny ID="ID_DENY_D_109" FriendlyName="PowerShell 109" Hash="080DEC3B15AD5AFE9BF3B0943A36285E92BAF469"/>
Hash="F1391E78F17EA6097906B99C6F4F0AE8DD2E519856F837A3BCC58FBB87DAAE62"/>
<Deny ID="ID_DENY_D_111" FriendlyName="PowerShell 111" Hash="F87C726CCB5E64C6F363C21255935D5FEA9E4A0E"/>
Hash="B7B42C3C8C61FD2616C16BBCF36EA15EC26A67536E94764D72A91CE04B89AAA4"/>
<Deny ID="ID_DENY_D_113" FriendlyName="PowerShell 113" Hash="25F52340199A0EA352C8B1A7014BCB610B232523"/>
Hash="64D6D1F3A053908C5635BD6BDA36BC8E72D518C7ECE8DA761C0DDE70C50BB632"/>
<Deny ID="ID_DENY_D_115" FriendlyName="PowerShell 115" Hash="029198F05598109037A0E9E332EC052317E834DA"/>
Hash="70B4BB6C2B7E9237FB14ABBC94955012285E2CAA74F91455EE52809CDAD4E7FC"/>
<Deny ID="ID_DENY_D_117" FriendlyName="PowerShell 117" Hash="A4390EF2D77F76DC4EFE55FF74EE1D06C303FDAE"/>
Hash="3246A0CB329B030DA104E04B1A0728DE83724B08C724FD0238CE4578A0245576"/>
<Deny ID="ID_DENY_D_119" FriendlyName="PowerShell 119" Hash="89CEAB6518DA4E7F75B3C75BC04A112D3637B737"/>
Hash="6581E491FBFF954A1A4B9CEA69B63951D67EB56DF871ED8B055193595F042B0D"/>
<Deny ID="ID_DENY_D_121" FriendlyName="PowerShell 121" Hash="00419E981EDC8613E600C939677F7B460855BF7E"/>
Hash="61B724BCFC3DA1CC1583DB0BC42EFE166E92D8D3CE91E58A29F7AEBEFAE2149F"/>
<Deny ID="ID_DENY_D_123" FriendlyName="PowerShell 123" Hash="272EF88BBA9B4B54D242FFE1E96D07DBF53497A0"/>
Hash="AFC0968EDCE9E5FC1BC392382833EBEF3265B32D3ECBB529D89A1DF33A31E9BD"/>
<Deny ID="ID_DENY_D_125" FriendlyName="PowerShell 125" Hash="CD9D9789B3B31562C4BE44B6BEEA8815C5EDAE1F"/>
Hash="FCAF8DC3C7A5D3B29B19A9C5F89324BF65B50C440AC0316B08532CEA2F1FF9B0"/>
<Deny ID="ID_DENY_D_127" FriendlyName="PowerShell 127" Hash="941D0FD47887035A04E17F46DE6C4004D7FD8871"/>
Hash="4AD6DC7FF0A2E776CE7F27B4E3D3C1C380CA3548DFED565429D88C3BBE61DD0F"/>
<Deny ID="ID_DENY_D_129" FriendlyName="PowerShell 129" Hash="421D1142105358B8360454E43FD15767DA111DBA"/>
Hash="692CABD40C1EDFCB6DC50591F31FAE30848E579D6EF4D2CA0811D06B086CF8BE"/>
<Deny ID="ID_DENY_D_131" FriendlyName="PowerShell 131" Hash="AC9F095DD4AE80B124F55541761AA1F35E49A575"/>
Hash="0D8A0FB3BF3CF80D44ED20D9F1E7292E9EE5A49ABCE68592DED55A71B0ACAECE"/>
<Deny ID="ID_DENY_D_133" FriendlyName="PowerShell 133" Hash="B1CF2A18B281F73FE6685B5CE74D1BA50BE9AFE5"/>
Hash="095B79953F9E3E2FB721693FBFAD5841112D592B6CA7EB2055B262DEB7C7008A"/>
<Deny ID="ID_DENY_D_135" FriendlyName="PowerShell 135" Hash="128D7D03E4B85DBF95427D72EFF833DAB5E92C33"/>
Hash="EACFC615FDE29BD858088AF42E0917E4B4CA5991EFB4394FB3129735D7299235"/>
<Deny ID="ID_DENY_D_137" FriendlyName="PowerShell 137" Hash="47D2F87F2D2D516D712A156421F0C2BD285200E9"/>
Hash="8CACA1828E7770DADF21D558976D415AC7BDA16D58926308FD5E9D5087F4B0E6"/>
<Deny ID="ID_DENY_D_139" FriendlyName="PowerShell 139" Hash="CD9D70B0107801567EEADC4ECD74511A1A6FF4FE"/>
Hash="9C96396EFCC9DC09F119DE8695CB3372F82DB46D23A1B7A88BD86CBE814233E1"/>
<Deny ID="ID_DENY_D_141" FriendlyName="PowerShell 141" Hash="233E3B5108A43239C6C13292043DED0567281AF9"/>
Hash="6EDF19CC53EA2064CE108957343EB3505359CF05BD6955C7502AF565BD761702"/>
<Deny ID="ID_DENY_D_143" FriendlyName="PowerShell 143" Hash="CD725B606888E5C5426FEAB44E2CC7722DFE5411"/>
Hash="B20C4F36AE6A3AC323759C81173FACE1B1C112FA5B701C65DCD7313D7CE59907"/>
<Deny ID="ID_DENY_D_145" FriendlyName="PowerShell 145" Hash="E5212F1081B5777B88F5C41174ADEDB35B4258CF"/>
Hash="F4DE5B5395701F8C94D65D732E4D212E1879C9C84345B46A941965B094F75017"/>
<Deny ID="ID_DENY_D_147" FriendlyName="PowerShell 147" Hash="EC41A3FB8D6E3B0F55F6583C14C45B6238753019"/>
Hash="76CA6B396796351685198D6189E865AFD7FB9E6C5CEFA9EA0B5F0A9F1FC98D57"/>
<Deny ID="ID_DENY_D_149" FriendlyName="PowerShell 149" Hash="3B2B7042A84033CA846AFE472912524F7BAD57E5"/>
Hash="2DF95ABEB23DAA0377DFA6360976B69D3CEE7325A9B7571F331D569809FAED8B"/>
<Deny ID="ID_DENY_D_151" FriendlyName="PowerShell 151" Hash="7BED2F9C0ADF1597C7EBB79163BDA21D8D7D28CA"/>
Hash="44BDD2DADB13E7A8FF6AFCF4AE3E2CC830506D9475B4C2C71D319E169977998F"/>
<Deny ID="ID_DENY_D_153" FriendlyName="PowerShell 153" Hash="A1251FA30162B13456A4687495726FF793D511BE"/>
Hash="9C15E4DE10DE47ACD393359D523211AD8596C61FE54F2C0664D48E1D249231CE"/>
<Deny ID="ID_DENY_D_155" FriendlyName="PowerShell 155" Hash="D835947C84CFBA652B553A77A90475E02291AA5F"/>
Hash="B4D6DAA10398D5DA192DFDD75010F428D24762D432934F0E2030D39610D43E12"/>
<Deny ID="ID_DENY_D_157" FriendlyName="PowerShell 157" Hash="1F85BBEC1DFC5785B91735A7C561E664F7FE1E94"/>
Hash="828F05BFF829019EC0F3082323FEA859C0D71CCE14B5B75C07E7D418EF354269"/>
<Deny ID="ID_DENY_D_159" FriendlyName="PowerShell 159" Hash="FC0E23771620B41E6920F2463F49B84307D8BA91"/>
Hash="C4FA568C852A46316308A660B80D83A11D41071F1CF4A79847A3F56714CC47AF"/>
<Deny ID="ID_DENY_D_161" FriendlyName="PowerShell 161" Hash="D18240AEE8B9B964F6B9CDFC5AFB6C343C286636"/>
Hash="7B4C39285569F14AA9799332C542A0796717C5EF9D636BD11B2841450BC6399D"/>
<Deny ID="ID_DENY_D_163" FriendlyName="PowerShell 163" Hash="1A16008D330330182AA555B1D3E9BE0B2D6BECBF"/>
Hash="D7685E259D0328937487856A3AB68B6D9D420DD4E02541F4D71164DFA65B4644"/>
<Deny ID="ID_DENY_D_165" FriendlyName="PowerShell 165" Hash="FBA274406B503B464B349805149E6AA722909CC9"/>
Hash="FEBC97ED819C79E54157895457DBA755F182D6330A5103E0663AFA07E01E5CF8"/>
<Deny ID="ID_DENY_D_167" FriendlyName="PowerShell 167" Hash="293AF426A39282770387F5EE25CA719A91419A18"/>
Hash="A9E655A96A124BC361D9CC5C7663FC033AA6F6609916EFAA76B6A6E9713A0D32"/>
<Deny ID="ID_DENY_D_169" FriendlyName="PowerShell 169" Hash="AEBFE7497F4A1947B5CB32650843CA0F85BD56D0"/>
Hash="8C385B2C16136C097C96701D2140E014BF454CFA7297BE0C28431DED15339C0F"/>
<Deny ID="ID_DENY_D_171" FriendlyName="PowerShell 171" Hash="8FB604CD72701B83BC265D87F52B36C6F14E5DBE"/>
Hash="B35AFBA7A897CB882C14A08AFB36A8EC938BDA14DF070234A2CCBDBA8F7DF91C"/>
<Deny ID="ID_DENY_D_173" FriendlyName="PowerShell 173" Hash="CE70309DB83C9202F45028EBEC252747F4936E6F"/>
Hash="1F6D74FDA1F9EE6BBAC72E7E717A01B9FFC29822561D11175F6809D12215B4ED"/>
<Deny ID="ID_DENY_D_175" FriendlyName="PowerShell 175" Hash="9D71AD914DBB2FDF793742AA63AEEF4E4A430790"/>
Hash="8CC1B5FA9A9609AC811F6505FA9B68E85A87BAE1EF676EFFE1BE438EACBDF3E1"/>
<Deny ID="ID_DENY_D_177" FriendlyName="PowerShell 177" Hash="7484FD78A9298DBA24AC5C882D16DB6146E53712"/>
Hash="A79A74BFB768312E8EE089060C5C3238D59EF0C044A450FEB97DCA26815ECB34"/>
<Deny ID="ID_DENY_D_179" FriendlyName="PowerShell 179" Hash="78C3C6AEF52A6A5392C55F1EC98AF18053B3087D"/>
Hash="493B620FCAD8A91D1FD7C726697E09358CA90822E8D6E021DF56E70B46F7C346"/>
<Deny ID="ID_DENY_D_181" FriendlyName="PowerShell 181" Hash="783FFB771F08BCF55C2EA474B5460EB65EA9444C"/>
Hash="09DA1592B8457F860297821EB7FAA7F3BB71FC1916ED5DEE6D85044953640D5C"/>
<Deny ID="ID_DENY_D_183" FriendlyName="PowerShell 183" Hash="B303D1689ED99613E4F52CE6E5F96AAEBC3A45C3"/>
Hash="82AB406FD78DCF58F65DC14D6FDDD72840015F3FE5B554428969BECA0325CD9C"/>
<Deny ID="ID_DENY_D_185" FriendlyName="PowerShell 185" Hash="DB5C6CB23C23BA6A3CD4FD4EC0A4DAEE3FC66500"/>
Hash="9A46C16C5151D97A0EFA3EA503249E31A6D5D8D25E4F07CD4E5E077A574713FB"/>
<Deny ID="ID_DENY_D_187" FriendlyName="PowerShell 187" Hash="C1E08AD32F680100C51F138C6C095139E7230C3B"/>
Hash="A5D5C1F79CD26216194D4C72DBAA3E48CB4A143D9E1F78819E52E9FEB2AD0AE3"/>
<Deny ID="ID_DENY_D_189" FriendlyName="PowerShell 189" Hash="BACA825D0852E2D8F3D92381D112B99B5DD56D9F"/>
Hash="ABA28E0FC251E1D7FE5E264E1B36EC5E482D70AA434E75A756356F23F0C1F2F4"/>
<Deny ID="ID_DENY_D_191" FriendlyName="PowerShell 191" Hash="E89C29D38F554F6CB73B5FD3D0A783CC12FFEBC3"/>
Hash="4C93CBDCF4328D27681453D8DFD7495955A07EE6A0EFB9A593853A86990CF528"/>
<Deny ID="ID_DENY_D_193" FriendlyName="PowerShell 193" Hash="5B5E7942233D7C8A325A429FC4F4AE281325E8F9"/>
Hash="40DA20086ED76A5EA5F62901D110216EE206E7EEB2F2BFF02F61D0BE85B0BB5A"/>
<Deny ID="ID_DENY_D_195" FriendlyName="PowerShell 195" Hash="926DCACC6983F85A8ABBCB5EE13F3C756705A1D5"/>
Hash="A22761E2BF18F02BB630962E3C5E32738770AAEA77F8EDA233E77792EB480072"/>
<Deny ID="ID_DENY_D_197" FriendlyName="PowerShell 197" Hash="6FE6723A355DEB4BC6B8637A634D1B43AFA64112"/>
Hash="9BCC55A97A275F7D81110877F1BB5B41F86A848EA02B4EE1E1E6A44D927A488F"/>
<Deny ID="ID_DENY_D_199" FriendlyName="PowerShell 199" Hash="8D5599B34BED4A660DACC0922F6C2F112F264758"/>
Hash="F375014915E5E027F697B29201362B56F2D9E598247C96F86ABADCC6FF42F034"/>
<Deny ID="ID_DENY_D_201" FriendlyName="PowerShell 201" Hash="CCFB247A3BCA9C64D82F647F3D30A3172E645F13"/>
Hash="5E52ABBC051368315F078D31F01B0C1B904C1DDB6D1C1E4A91BE276BDF44C66F"/>
<Deny ID="ID_DENY_D_203" FriendlyName="PowerShell 203" Hash="E8EB859531F426CC45A3CB9118F399C92054563E"/>
Hash="CD9E1D41F8D982F4AA6C610A2EFEAEBA5B0CDD883DF4A86FA0180ACD333CAA86"/>
<Deny ID="ID_DENY_D_205" FriendlyName="PowerShell 205" Hash="C92D4EAC917EE4842A437C54F96D87F003199DE8"/>
Hash="3A270242EB49E06405FD654FA4954B166297BBC886891C64B4424134C39872DB"/>
<Deny ID="ID_DENY_D_207" FriendlyName="PowerShell 207" Hash="66681D9171981216B31996429695931DA2A638B9"/>
Hash="7A2DF7D56912CB4EB5B36D071496EDC97661086B0E4C9CC5D9C61779A5A7DAAA"/>
<Deny ID="ID_DENY_D_209" FriendlyName="PowerShell 209" Hash="9DCA54C85E4C645CB296FE3055E90255B6506A95"/>
Hash="8C9C58AD12FE61CBF021634EC6A4B3094750FC002DA224423E0BCEB01ECF292A"/>
<Deny ID="ID_DENY_D_211" FriendlyName="PowerShell 211" Hash="3AF2587E8B62F88DC363D7F5308EE4C1A6147338"/>
Hash="D32D88F158FD341E32708CCADD48C426D227D0EC8465FF4304C7B7EAC2C6A93E"/>
<Deny ID="ID_DENY_D_213" FriendlyName="PowerShell 213" Hash="D3D453EBC368DF7CC2200474035E5898B58D93F1"/>
Hash="BBE569BCC282B3AF682C1528D4E3BC53C1A0C6B5905FA34ADB4305160967B64A"/>
<Deny ID="ID_DENY_D_215" FriendlyName="PowerShell 215" Hash="D147CE5C7E7037D1BE3C0AF67EDB6F528C77DB0A"/>
Hash="11F936112832738AD9B3A1C67537D5542DE8E86856CF2A5893C4D26CF3A2C558"/>
<Deny ID="ID_DENY_D_217" FriendlyName="PowerShell 217" Hash="7DBB41B87FAA887DE456C8E6A72E09D2839FA1E7"/>
Hash="3741F3D2F264E047339C95A66085599A49766DEF1C5BD0C32237CE87FA0B41FB"/>
<Deny ID="ID_DENY_D_219" FriendlyName="PowerShell 219" Hash="5F3AECC89BAF094EAFA3C25E6B883EE68A6F00B0"/>
Hash="AA085BE6498D2E3F527F3D72A5D1C604508133F0CDC05AD404BB49E8E3FB1A1B"/>
<Deny ID="ID_DENY_D_221" FriendlyName="PowerShell 221" Hash="DDE4D9A08514347CDE706C42920F43523FC74DEA"/>
Hash="81835C6294B96282A4D7D70383BBF797C2E4E7CEF99648F85DDA50F7F41B02F6"/>
<Deny ID="ID_DENY_D_223" FriendlyName="PowerShell 223" Hash="48092864C96C4BF9B68B5006EAEDAB8B57B3738C"/>
Hash="36EF3BED9A5D0D563BCB354BFDD2931F6256759D1D905BA5DC21CDA496F2FEB7"/>
<Deny ID="ID_DENY_D_225" FriendlyName="PowerShell 225" Hash="7F6725BA8CCD2DAEEFD0C9590A5DF9D98642CCEA"/>
Hash="DB68DB3AE32A8A662AA6EE16CF459124D2701719D019B614CE9BF115F5F9C904"/>
<Deny ID="ID_DENY_D_227" FriendlyName="PowerShell 227" Hash="FF205856A3209227D571EAD4B8C1E611E7FF9924"/>
Hash="A63B38CE17DA60C4C431FC42C4507A0B7C19B384AC9E121E2988AD026E71ED63"/>
<Deny ID="ID_DENY_D_229" FriendlyName="PowerShell 229" Hash="479C9429691314D3E21E4F4CA8B95D5BD2BDDEDA"/>
Hash="2BA4E369D267A9ABDEBA50DA2CB5FC56A8EE4382C5BCFCFFD121350B88A6F0E1"/>
<Deny ID="ID_DENY_D_231" FriendlyName="PowerShell 231" Hash="C7D70B96440D215173F35412D56CF9329886D8D3"/>
Hash="B00C54F1AA77D88335675EAF07ED834E68FD96DD7606914C2867F9C506AB0A56"/>
<Deny ID="ID_DENY_D_233" FriendlyName="PowerShell 233" Hash="2AB804E1FF982AE0EDB591BC61AA909CF32E99C5"/>
Hash="253120422B0DD987C293CAF5928FA820414C0A01622FD0EAF304A750FC5AEEFE"/>
<Deny ID="ID_DENY_D_235" FriendlyName="PowerShell 235" Hash="8DAB1D74CAEDBAA8D17805CF00D64A44F5831C12"/>
Hash="AC1CE3AA9023E23F2F63D5A3536294B914686057336402E059DEF6559D1CE723"/>
<Deny ID="ID_DENY_D_237" FriendlyName="PowerShell 237" Hash="993425279D204D1D14C3EB989DEB4805ADC558CF"/>
Hash="BDADDD710E47EB8D24B78E542F3996B0EA2CA577ABD515785819302DB15839DD"/>
<Deny ID="ID_DENY_D_239" FriendlyName="PowerShell 239" Hash="F4DB0CDF3A3FD163A9B90789CC6D14D326AD609C"/>
Hash="5D249D8366077713024552CA8D08F164E975AFF89E8909E35A43F02B0DC66F70"/>
<Deny ID="ID_DENY_D_241" FriendlyName="PowerShell 241" Hash="5B8E45EECA32C2F0968C2252229D768B0DB796A0"/>
Hash="B4D336B32C27E3D3FEBE4B06252DDE9683814E7E903C98448972AAB7389DFC02"/>
<Deny ID="ID_DENY_D_243" FriendlyName="PowerShell 243" Hash="4F5D66B449C4D2FDEA532F9B5DBECA5ACA8195EF"/>
Hash="39F2F19A5C6708CE8CE4E1ABBEBA8D3D1A6220391CA86B2D319E347B46005C97"/>
<Deny ID="ID_DENY_D_245" FriendlyName="PowerShell 245" Hash="4BFB3F95CA1B79DA3C6B0A2ECB432059E686F967"/>
Hash="0C4688AACD02829850DE0F792AC06D3C87895412A910EA76F7F9BF31B3B4A3E9"/>
<Deny ID="ID_DENY_D_247" FriendlyName="PowerShell 247" Hash="6DC048AFA50B5B1B0AD7DD3125AC83D46FED730A"/>
Hash="432F666CCE8CD222484E263AE02F63E0038143DD6AD07B3EB1633CD3C498C13D"/>
<Deny ID="ID_DENY_D_287" FriendlyName="PowerShellShell 287"
Hash="2B45C165F5E0BFD932397B18980BA680E2E82BD1"/>
Hash="1DD0AD6B85DAEBAE7555DC37EA6C160EA38F75E3D4847176F77562A59025660A"/>
Hash="A8C9E28F25C9C5F479691F2F49339F4448747638"/>
Hash="F8FA17038CD532BF5D0D6D3AC55CE34E45EB690637D38D399CAB14B09807EB6C"/>
Hash="4BAFD867B59328E7BB853148FE6D16B9411D7A12"/>
Hash="3BA0605C08935B340BEFDC83C0D92B1CE52B8348"/>
Hash="B794B01CE561F2791D4ED3EADE523D03D2BE7B4CEFE9AAFC685ECE8ACF515ED2"/>
Hash="8B74A22710A532A71532E4F0B1C60AABDCAA29AB"/>
Hash="EB335007DF9897BCD2ED5C647BA724F07658E8597E73E353479201000CF2EF79"/>
Hash="10E2CD3A2CFA0549590F740139F464626DEE2092"/>
Hash="61DEC96B91F3F152DFDA84B28EBB184808A21C4C183CC0584C66AC7E20F0DDB6"/>
Hash="98E84F46B3EB3AD7420C9715722145AFB0C065A7"/>
Hash="67398990D42DFF84F8BE33B486BF492EBAF61671820BB9DCF039D1F8738EC5A4"/>
Hash="58F399EC75708720E722FBD038F0EC089BF5A8C0"/>
Hash="C523FFF884C44251337470870E0B158230961845FC1E953F877D515668524F2E"/>
Hash="41EE8E9559FC0E772FC26EBA87ED4D77E60DC76C"/>
Hash="219AD97976987C614B00C0CD1229B4245F2F1453F5AF90B907664D0BF6ADFE78"/>
Hash="7F7E646892FCEB8D6A19647F00C1153014955C45"/>
Hash="5825FF16398F12B4999B9A12849A757DD0884F9908220FB33E720F170DA288D5"/>
Hash="7EA8A590583008446583F0AE7D66537FAD63619D"/>
Hash="26DD094717B15B3D39600D909A9CAEBCF5C616C6277933BCC01326E8C475A128"/>
Hash="5F6CDF52C1E184B080B89EB234DE179C19F110BA"/>
Hash="41FB90606E3C66D21C703D84C943F8CB35772030B689D9A9895CB3EF7C863FB2"/>
Hash="91C1DACBD6773BFC7F9305418A6683B8311949CF"/>
Hash="EB678387D01938D88E6F2F46712269D54D845EB6A8AAC3FCA256DC2160D42975"/>
Hash="A05294D23A4A7DC91692013C0EC4373598A28B21"/>
Hash="ABEEA4903403D2C07489436E59955ECFEEF893C63D1FDBED234343F6A6D472B1"/>
Hash="B155C278617845EC6318E4009E4CED6639FAB951"/>
Hash="59549FEEB4D64BA3AF50F925FECC8107422D3F54AF6106E5B0152B2F50912980"/>
Hash="465D848F11CECE4452E831D248D326360B73A319"/>
Hash="B9C9F208C6E50AABF91D234227D09D7C6CAB2FDB229163103E7C1F541F71C213"/>
Hash="F0B9D75B53A268C0AC30584738C3A5EC33420A2E"/>
Hash="365A7812DFC448B1FE9CEA83CF55BC62189C4E72BAD84276BD5F1DAB47CB3EFF"/>
Hash="8ADCDD18EB178B6A43CF5E11EC73212C90B91988"/>
Hash="51BD119BE2FBEFEC560F618DBBBB8203A251F455B1DF825F37B1DFFDBE120DF2"/>
Hash="D2011097B6038D8507B26B7618FF07DA0FF01234"/>
Hash="BA3D20A577F355612E53428D573767C48A091AE965FCB30CC348619F1CB85A02"/>
Hash="57ABBC8E2FE88E04C57CDDD13D58C9CE03455D25"/>
Hash="0280C4714BC806BFC1863BE9E84D38F203942DD35C6AF2EB96958FD011E4D23D"/>
Hash="DEB07053D6059B56109DFF885720D5721EB0F55C"/>
Hash="E374A14871C35DB57D6D67281C16F5F9EF77ABE248DE92C1A937C6526133FA36"/>
Hash="AC33BA432B35A662E2D9D015D6283308FD046251"/>
Hash="93B22B0D5369327247DF491AABD3CE78421D0D68FE8A3931E0CDDF5F858D3AA7"/>
Hash="05126413310F4A1BA2F7D2AD3305E2E3B6A1B00D"/>
Hash="108A73F4AE78786C9955ED71EFD916465A36175F8DC85FD82DDA6410FBFCDB52"/>
Hash="B976F316FB5EE6E5A325320E7EE5FBF487DA9CE5"/>
Hash="D54CCD405D3E904CAECA3A6F7BE1737A9ACE20F7593D0F6192B811EF17744DD6"/>
Hash="F3471DBF534995307AEA230D228BADFDCA9E4021"/>
Hash="2048F33CCD924D224154307C28DDC6AC1C35A1859F118AB2B6536FB954FC44EF"/>
Hash="1FAC9087885C2FEBD7F57CC9AACE8AF94294C8FB"/>
Hash="942E0D0BA5ECBF64A3B2D0EA1E08C793712A4C89BC1BC3B6C32A419AE38FACC1"/>
Hash="5B67EE19AA7E4B42E58127A63520D44A0679C6CE"/>
Hash="2B6A59053953737D345B97FA1AFB23C379809D1532BAF31E710E48ED7FA2D735"/>
Hash="1ABC67650B169E7C437853922805706D488EEEA2"/>
Hash="754CA97A95464F1A1687C83AE3ECC6670B80A50503067DEBF6135077C886BCF4"/>
Hash="0E280FF775F406836985ECA66BAA9BA17D12E38B"/>
Hash="19C9A6D1AE90AEA163E35930FAB1B57D3EC78CA5FE192D6E510CED2DAB5DD03B"/>
Hash="4E6081C3BBB2809C417E2D03412E29FF7317DA54"/>
Hash="3AE4505A552EA04C7664C610E81172CA329981BF53ECC6758C03357EB653F5D1"/>
Hash="61BED1C7CD54B2F60923D26CD2F6E48C063AFED5"/>
Hash="9405CBE91B7519290F90577DCCF5796C514746DE6390322C1624BA258D284EE9"/>
Hash="63AA55C3B46EFAFC8625F8D5562AB504E4CBB78F"/>
Hash="FF54885D30A13008D60F6D0B96CE802209C89A2A7D9D86A85804E66B6DE29A5D"/>
Hash="20845E4440DA2D9AB3559D4B6890691CACD0E93E"/>
Hash="3C9098C4BFD818CE8CFA130F6E6C90876B97D57ABBEAFABB565C487F1DD33ECC"/>
Hash="4A473F14012EB9BF7DCEA80B86C2612A6D9D914E"/>
Hash="1C6914B58F70A9860F67311C32258CD9072A367BF30203DA9D8C48188D888E65"/>
Hash="641871FD5D9875DB75BFC58B7B53672D2C645F01"/>
Hash="C115A974DD2C56574E93A4800247A23B98B9495F6EF41460D1EC139266A2484D"/>
Hash="A21E254C18D3D53B832AD381FF58B36E6737FFB6"/>
Hash="D214AF2AD9204118EB670D08D80D4CB9FFD74A978726240360C35AD5A57F8E7D"/>
Hash="102B072F29122BC3A89B924987A7BF1AC3C598DB"/>
Hash="DA444773FE7AD8309FA9A0ABCDD63B302E6FC91E750903843FBA2A7F370DB0C0"/>
Hash="EAD58EBB00001E678B9698A209308CC7406E1BCC"/>
Hash="34A5F48629F9FDAEBAB9468EF7F1683EFA856AAD32E3C0CC0F92B5641D722EDC"/>
Hash="727EDB00C15DC5D3C14368D88023FDD5A74C0B06"/>
Hash="5720BEE5CBE7D724B67E07C53E22FB869F8F9B1EB95C4F71D61D240A1ED8D8AD"/>
Hash="A43137EC82721A81C3E05DC5DE74F0549DE6A130"/>
Hash="1731118D97F278C18E2C6922A016DA7C55970C6C4C5441710D1B0464EED6EAEB"/>
Hash="17EC94CB9BF98E605F9352987CA33DCE8F5733CD"/>
Hash="AFE0CC143108BBDBE60771B6894406785C471BA5730F06EE8185D0A71617B583"/>
Hash="F6E9C098737F0905E53B92D4AD49C199EC76D24B"/>
Hash="50A57BFCD20380DDEFD2A717D7937D49380D4D5931CC6CC403C904139546CB1D"/>
Hash="2118ACC512464EE95946F064560C15C58341B80C"/>
Hash="005990EE785C1CA7EAEC82DA29F5B363049DC117A18823D83C10B86B5E8D0A5F"/>
Hash="54FAE3A389FDD2F5C21293D2317E87766AF0473D"/>
Hash="70F4E503D7484DF5B5F73D9A753E585BFADB8B8EBA42EB482B6A66DB17C87881"/>
Hash="B4831AF4B25527EF0C172DAA5E4CA26DE105D30B"/>
Hash="D410A37042A2DC53AD1801EBB2EF507B4AE475870522A298567B79DA61C3E9C8"/>
Hash="85BBC0CDC34BD5A56113B0DCB6795BCEBADE63FA"/>
Hash="C6F8E3A3F2C513CEDD2F21D486BF0116BAF2E2EE4D631A9BE4760860B1161848"/>
Hash="46105ACE7ABEC3A6E6226183F2F7F8E90E3639A5"/>
Hash="F60BE088F226CA1E2308099C3B1C2A54DB4C41D2BE678504D03547B9E1E023F6"/>
Hash="C9478352ACE4BE6D6B70BBE710C2E2128FEFC7FE"/>
Hash="F4A81E7D4BD3B8762FAED760047877E06E40EC991D968BD6A6929B848804C1A4"/>
Hash="9E56E910919FF65BCCF5D60A8F9D3EBE27EF1381"/>
Hash="34887B225444A18158B632CAEA4FEF6E7D691FEA3E36C12D4152AFAB260668EB"/>
Hash="1FD04D4BD5F9E41FA8278F3F9B05FE8702ADB4C8"/>
Hash="6586176AEBE8307829A1E03D878EF6F500E8C5032E50198DF66F54D3B56EA718"/>
Hash="DEBC3DE2AD99FC5E885A358A6994E6BD39DABCB0"/>
Hash="FDF54A4A3089062FFFA4A41FEBF38F0ABC9D502B57749348DF6E78EA2A33DDEA"/>
Hash="6AA06D07D9DE8FE7E13B66EDFA07232B56F7E21D"/>
Hash="DD3E74CFB8ED64FA5BE9136C305584CD2E529D92B360651DD06A6DC629E23449"/>
Hash="5C858042246FDDDB281C1BFD2FEFC9BAABC3F7AD"/>
Hash="20E65B1BE06A99507412FC0E75D158EE1D9D43AE5F492BE4A87E3AA29A148310"/>
Hash="2ABCD0525D31D4BB2D0131364FBE1D94A02A3E2A"/>
Hash="806EC87F1EFA428627989318C882CD695F55F60A1E865C621C9F2B14E4E1FC2E"/>
Hash="E2967D755D0F79FA8EA7A8585106926CA87F89CB"/>
Hash="07382BE9D8ACBAFDA953C842BAAE600A82A69183D6B63F91B061671C4AF9434B"/>
Hash="75EF6F0B78098FB1766DCC853E004476033499CF"/>
Hash="699A9D17E1247F05767E82BFAFBD96DBE07AE521E23D39613D4A39C3F8CF4971"/>
Hash="E73178C487AF6B9F182B2CCA25774127B0303093"/>
Hash="0BD1FE62BE97032ADDAAB41B445D00103302D3CE8A03A798A36FEAA0F89939FF"/>
Hash="EBF20FEECA95F83B9F5C22B97EB44DD7EB2C7B5F"/>
Hash="B5AE0EAA5AF4245AD9B37C8C1FC5220081B92A13950C54D82E824D2D3B840A7C"/>
Hash="5E53A4235DC549D0195A9DDF607288CEDE7BF115"/>
Hash="FE57195757977E4485BF5E5D72A24EA65E33F8EAA7245381453960D5646FAF58"/>
Hash="014BC30E1FC12F270824F01DC7C934497A573124"/>
Hash="65B3B357C356DAE26E5B036820C193989C0F9E8E08131B3186F9443FF9A511E4"/>
Hash="128D7D03E4B85DBF95427D72EFF833DAB5E92C33"/>
Hash="C7D70B96440D215173F35412D56CF9329886D8D3"/>
Hash="8287B536E8E63F024DE1248D0FE3E6A759E9ACEE"/>
Hash="B714D4A700A56BC1D4B3F59DFC1F5835CB97CBEF3927523BF71AF96B00F0FFA4"/>
Hash="6BC1E70F0EA84E88AC28BEAF74C10F3ABDF99209"/>
Hash="AC9F095DD4AE80B124F55541761AA1F35E49A575"/>
Hash="3C7265C3393C585D32E509B2D2EC048C73AC5EE6"/>
Hash="89CEAB6518DA4E7F75B3C75BC04A112D3637B737"/>
Hash="4BFB3F95CA1B79DA3C6B0A2ECB432059E686F967"/>
Hash="BDBE541D269EC8235563842D024F9E37883DFB57"/>
Hash="BDB3DAC80667A0B931835D5D658C08F236B413D1"/>
Hash="EA157E01147629D1F59503D8335FB6EBC688B2C1"/>
Hash="14C160DF95736EC1D7C6C55B9D0F81832E8FE0DB6C5931B23E45A559995A1000"/>
Hash="272EF88BBA9B4B54D242FFE1E96D07DBF53497A0"/>
Hash="029198F05598109037A0E9E332EC052317E834DA"/>
Hash="5B8E45EECA32C2F0968C2252229D768B0DB796A0"/>
Hash="6792915D3C837A39BD04AD169488009BB1EA372C"/>
Hash="23B10EC5FC7EAEB9F8D147163463299328FAED4B973BB862ECD3F28D6794DA9D"/>
Hash="EC41A3FB8D6E3B0F55F6583C14C45B6238753019"/>
Hash="A15964475D213FB752B42E7DCDDBF4B14D623D14"/>
Hash="24F9CF6C5E9671A295AD0DEED74737FB6E9146DE"/>
Hash="C2E862CC578F54A53496EEE2DCB534A106AFD55C7288362AF6499B45F8D8755E"/>
Hash="F87C726CCB5E64C6F363C21255935D5FEA9E4A0E"/>
Hash="4EB2C3A4B551FC028E00F2E7DA9D0F1E38728571"/>
Hash="2DF4350DE3C97C9D4FD2973F8C5EA8AE621D22A8"/>
Hash="993425279D204D1D14C3EB989DEB4805ADC558CF"/>
Hash="1A16008D330330182AA555B1D3E9BE0B2D6BECBF"/>
Hash="2CB781B3BD79FD277D92332ACA22C04430F9D692"/>
Hash="BA4B3A92123FBCE66398020AFBCC0BCA1D1AAAD7"/>
Hash="D5A9460A941FB5B49EAFDD57575CFB23F27779D3"/>
Hash="4BDAAC1654328E4D37B6ED89DA351155438E558F51458F2129AFFAC5B596CD61"/>
Hash="3E5294910C59394DA93962128968E6C23016A028"/>
Hash="C30355B5E6FA3F793A3CC0A649945829723DD85C"/>
Hash="C647D17850941CFB5B9C8AF49A48569B52230274"/>
Hash="0BCBDE8791E3D6D7A7C8FC6F25E14383014E6B43D9720A04AF0BD4BDC37F79E0"/>
Hash="CA6E0BAB6B28E1592D0FC5940023C7A81E2568F8"/>
Hash="366E00E2F517D4D404133AEFEF6F917DFA156E3E46D350A8CBBE59BE1FB877A2"/>
Hash="7D9FFFA86DDCD227A3B4863D995456308BAC2403"/>
Hash="4439BBF61DC012AFC8190199AF5722C3AE26F365DEE618D0D945D75FD1AABF3C"/>
Hash="8FFDD4576F2B6D4999326CFAF67727BFB471FA21"/>
Hash="94630AB6F60A7193A6E27E312AF9B71DA265D42AD49465F4EEA11EBF134BA54A"/>
Hash="78B8454F78E216B629E43B4E40765F73BFE0D6C6"/>
Hash="498BB1688410EE243D61FB5C7B37457FA6C0A9A32D136AF70FAD43D5F37D7A81"/>
Hash="B1CF2A18B281F73FE6685B5CE74D1BA50BE9AFE5"/>
Hash="8AF579DE1D7E590A13BD1DAE5BFDB39476068A05"/>
Hash="9917A3055D194F47AB295FA3F917E4BD2F08DDF45C04C65C591A020E1507A573"/>
Hash="DD64046BAB221CF4110FF230FA5060310A4D9610"/>
Hash="A55AF37229D7E249C8CAFED3432E595AA77FAF8B62990C07938220E957679081"/>
Hash="421D1142105358B8360454E43FD15767DA111DBA"/>
Hash="720D826A84284E18E0003526A0CD9B7FF0C4A98A"/>
Hash="2F587293F16DFCD06F3BF8B8348FF68827ECD307"/>
Hash="B2F4A5FE21D5961F464CAB3E88C0ED88154B0C1A422629474AD5C9EDC11880B6"/>
Hash="6DC048AFA50B5B1B0AD7DD3125AC83D46FED730A"/>
Hash="CD9D9789B3B31562C4BE44B6BEEA8815C5EDAE1F"/>
Hash="4F5D66B449C4D2FDEA532F9B5DBECA5ACA8195EF"/>
Hash="A4390EF2D77F76DC4EFE55FF74EE1D06C303FDAE"/>
Hash="E180486F0CC90AF4FB8283ADCF571884894513C8"/>
Hash="3800E38275E6BB3B4645CDAD14CD756239BB9A87EF261DC1B68072B6DB2850C0"/>
Hash="AC53AE4C8AB56D84393D67D820BEBDC3218739D3"/>
Hash="00419E981EDC8613E600C939677F7B460855BF7E"/>
Hash="25F52340199A0EA352C8B1A7014BCB610B232523"/>
Hash="F4DB0CDF3A3FD163A9B90789CC6D14D326AD609C"/>
Hash="231A02EAB7EB192638BC89AB61A5077346FF22B9"/>
Hash="4D544170DE5D9916678EA43A7C6F796FC02EFA9197C6E0C01A1D832BF554F748"/>
Hash="A9745E20419EC1C90B23FE965D3C2DF028AF39DC"/>
Hash="15EF1F7DBC474732E122A0147640ACBD9DA1775C"/>
Hash="04724BF232D5F169FBB0DB6821E35D772619FB4F24069BE0EC571BA622ACC4D2"/>
Hash="7959AB2B34A5F490AD54782D135BF155592DF13F"/>
Hash="DD03CD6B5655B4EB9DD259F26E1585389804C23DB39C10122B6BC0E8886B4C2A"/>
Hash="CCA8C8FB699496BD50AE296B20CC9ADC3496DECE"/>
Hash="75E6C2DD81FE2664DF466C9C2EB0F923B0C6D992FF653B673793A896D8860957"/>
Hash="080DEC3B15AD5AFE9BF3B0943A36285E92BAF469"/>
Hash="B3B7A653DD1A10EE9A3D35C818D227E2E3C3B5FB"/>
Hash="43E2D91C0C6A8473BE178F1793E5E34966D700F71362297ECF4B5D46239603E3"/>
Hash="D82583F7D5EA477C94630AC5AAEB771C85BD4B0A"/>
Hash="AAE22FD137E8B7217222974DCE60B9AD4AF2A512"/>
Hash="DAC9E963A3897D7F7AB2B4FEBBD4894A15441246639CE3E8EE74B0228F312742"/>
Hash="8DAB1D74CAEDBAA8D17805CF00D64A44F5831C12"/>
Hash="266896FD257AD8EE9FC73B3A50306A573714EA8A"/>
Hash="2AB804E1FF982AE0EDB591BC61AA909CF32E99C5"/>
Hash="25CA971D7EDFAA7A48FA19B8399301853809D7CC"/>
Hash="0A10C71CB5CC8A801F84F2CCD8041D13DB55711435388D9500C53D122688D4E5"/>
Hash="46E05FD4D62451C1DCB0287B32B3D77AD41544EA"/>
Hash="D86F930445F0715D0D7E4C3B089399280FBA2ACE0E4125BA5D3DAB9FAC1A6D3A"/>
Hash="479C9429691314D3E21E4F4CA8B95D5BD2BDDEDA"/>
Hash="FF205856A3209227D571EAD4B8C1E611E7FF9924"/>
Hash="7FCB424E67DDAC49413B45D7DCD636AD70E23B41"/>
Hash="46936F4F0AFE4C87D2E55595F74DDDFFC9AD94EE"/>
Hash="9843DC862BC7491A279A09EFD8FF122EB23C57CA"/>
Hash="11F11FB1E57F299383A615D6A28436E02A1C1A83"/>
Hash="C593ABE79DFFB1504CFCDB1A6AD65D24996E7B97"/>
Hash="93E22F2BA6C8B1C09F100F9C0E3B06FAF2D1DDB6"/>
Hash="5A8D9712CF7893C335FFB7414748625D524227FE"/>
Hash="B5FFFEE20F25691A59F3894644AEF088B4845761"/>
Hash="3334059FF4484C43A5D08CEC3E43E2D27EDB927B"/>
Hash="00B6993F59990C3DFEA33584BDB050F91313B17A"/>
Hash="7518F60A0B33011D19873908559961F96A9B4FC0"/>
Hash="A1D1AF7675C2596D0DF977F57B54372298A56EE0F3E1FF2D974D387D7F69DD4E"/>
Hash="3C1743CBC43B80F5AF5B17239B03A8727B4BE81F14052BDE37685E2D54214071"/>
Hash="C7DC8B00F0BDA000D1F3CF0FBC7AB32D443C377C0130BB5153A0390E712DDDE5"/>
Hash="ED5A4747C8AEEB1AC2F4FDB8EB0B9BFC240F2B3C00BF7C6CDB372BFFEC0F8ABE"/>
Hash="939C291D4A2592209EC7664EC832670FA0AC1009F974F47489D866751F4B862F"/>
Hash="497A2D4207B2AE6EF09424591624A86A64A2C8E451389ED9A3256E6274556A7B"/>
Hash="732BC385B191C8436B42CD1441DC234FFDD5EC1BD18A32894F093EECA3DD8FBC"/>
Hash="CBD19FDB6338DB02299A3F3FFBBEBF216B18013B3377D1D31E51491C0C5F074C"/>
Hash="3A316A0A470744EB7D18339B76E786564D1E96130766A9895B2222C4066CE820"/>
Hash="68A4A1E8F4E1B903408ECD24608659B390B9E7154EB380D94ADE7FEB5EA470E7"/>
Hash="45F948AF27F4E698A8546027717901B5F70368EE"/>
Hash="45F948AF27F4E698A8546027717901B5F70368EE"/>
Hash="2D63C337961C6CF2660C5DB906D9070CA38BCE828584874680EC4F5097B82E30"/>
Hash="DA4CD4B0158B774CE55721718F77ED91E3A42EB3"/>
Hash="7D181BB7A4A0755FF687CCE34949FC6BD6FBC377E6D4883698E8B45DCCBEA140"/>
Hash="C67D7B12BBFFD5FBD15FBD892955EA48E6F4B408"/>
Hash="1DCAD0BBCC036B85875CC0BAF1B65027933624C1A29BE336C79BCDB00FD5467A"/>
Hash="7D8CAB8D9663926E29CB810B42C5152E8A1E947E"/>
Hash="2E0203370E6E5437CE2CE1C20895919F806B4E5FEBCBE31F16CB06FC5934F010"/>
Hash="20E7156E348912C20D35BD4BE2D52C996BF5535E"/>
Hash="EB26078544BDAA34733AA660A1A2ADE98523DAFD9D58B3995919C0E524F2FFC3"/>
Hash="B9DD16FC0D02EA34613B086307C9DBEAC30546AF"/>
Hash="DE5B012C4DC3FE3DD432AF9339C36EFB8D54E8864493EA2BA151F0ADBF3E338C"/>
Hash="6397AB5D664CDB84A867BC7E22ED0789060C6276"/>
Hash="B660F6CA0788DA18375602537095C378990E8229B11B57B092AC8A550E9C61E8"/>
Hash="3BF717645AC3986AAD0B4EA9D196B18D05199DA9"/>
Hash="364C227F9E57C72F9BFA652B8C1DE738AB4747D0DB68A7B899CA3EE51D802439"/>
Hash="3A1B06680F119C03C60D12BAC682853ABE430D21"/>
Hash="850759BCE4B66997CF84E84683A2C1980D4B498821A8AB9C3568EB298B824AE3"/>
Hash="654C54AA3F2C74FBEB55B961FB1924A7B2737E61"/>
Hash="B7EA81960C6EECFD2FF385890F158F5B1CB3D1E100C7157AB161B3D23DCA0389"/>
Hash="496F793112B6BCF4B6EA16E8B2F8C3F5C1FEEB52"/>
Hash="E430485B577774825CEF53E5125B618A2608F7BE3657BB28383E9A34FCA162FA"/>
Hash="6EA8CEEA0D2879989854E8C86CECA26EF79F7B19"/>
Hash="8838FE3D8E2505F3D3D8B98C64739115838A0B443BBBBFB487342F1EE7801360"/>
Hash="28C5E53DE197E872F7E4772BF40F728F56FE3ACC"/>
Hash="3493DAEC6EC03E56ECC4A15432C750735F75F9CB38D8779C7783B4DA956BF037"/>
Hash="DBB5A6F5388C574A3B5B63E65F7810AB271E9A77"/>
Hash="6DB24D174CCF06C9138B5A9320AE4261CA0CF305357DEF1B7054DD84758E92AB"/>
Hash="757626CF5D444F5A4AF79EDE38E9EF65FA2C9802"/>
Hash="1E17D036EBB5E82BF2FD5BDC3ABAB08B5EA9E4504D989D2BAAAA0B6047988996"/>
Hash="2965DC840B8F5F7ED2AEC979F21EADA664E3CB70"/>
Hash="5449560095D020687C268BD34D9425E7A2739E1B9BFBC0886142519293E02B9D"/>
Hash="BB47C1251866F87723A7EDEC9A01D3B955BAB846"/>
Hash="B05F3BE23DE6AE2557D6661C6FE35E114E8A69B326A3C855023B7AC5CE9FC31B"/>
Hash="2F3D30827E02D5FEF051E54C74ECA6AD4CC4BAD2"/>
Hash="F074589A1FAA76A751B05AD61B968683134F3FFC10DE3077FBCEE4E263EAEB0D"/>
Hash="10096BD0A359142A13F2B8023A341C79A4A97975"/>
Hash="A271D72CDE48F69EB694B753BF9417CD6A72F7DA06C52E47BAB40EC2BD9DD819"/>
Hash="F8E803E1623BA66EA2EE0751A648834130B8BE5D"/>
Hash="E70DB033B773FE01B1D4464CAC112AF41C09E75D25FEA25AE8DAE67ED941E797"/>
Hash="665BE52329F9CECEC1CD548A1B4924C9B1F79BD8"/>
Hash="24CC5B946D9469A39CF892DD4E92117E0E144DC7C6FAA65E71643DEAB87B2A91"/>
Hash="C4627F2CF69A8575D7BF7065ADF5354D96707DFD"/>
Hash="7F1DF759C050E0EF4F9F96FF43904B418C674D4830FE61818B60CC68629F5ABA"/>
Hash="4126DD5947E63DB50AD5C135AC39856B6ED4BF33"/>
Hash="B38E1198F82E7C2B3123984C017417F2A48BDFF5B6DBAD20B2438D7B65F6E39F"/>
Hash="DE16A6B93178B6C6FC33FBF3E9A86CFF070DA6D3"/>
Hash="A3EF9A95D1E859958DEBE44C033B4562EBB9B4C6E32005CA5C07B2E07A42E2BE"/>


<Deny ID="ID_DENY_D_249" FriendlyName="PubPrn 249" Hash="68E96BE23748AA680D5E1E557778901F332ED5D3"/>
<Deny ID="ID_DENY_D_250" FriendlyName="PubPrn 250"
Hash="8FA30B5931806565C2058E565C06AD5F1C5A48CDBE609975EB31207C25214063"/>

<Deny ID="ID_DENY_D_251" FriendlyName="PubPrn 251" Hash="32C4B29FE428B1DF473F3F4FECF519D285E93521"/>
Hash="D44FB563198D60DFDC91608949FE2FADAD6161854D084EB1968C558AA36513C7"/>

<Deny ID="ID_DENY_D_253" FriendlyName="PubPrn 253" Hash="9EDBEF086D350863F29175F5AB5178B88B142C75"/>
Hash="9B22C98351F2B6DEDDCED0D805C65F5B166FF519A8DF41EB242CB909471892EB"/>

<Deny ID="ID_DENY_D_255" FriendlyName="PubPrn 255" Hash="8A3B30F345C43246B3500721CFEEADBAC6B9D9C6"/>
Hash="37C20BF20A2BBACE50957F8D0AB3FD16174BC005E79D47E51E899AFD9E4B7724"/>

<Deny ID="ID_DENY_D_257" FriendlyName="PubPrn 257" Hash="C659DAD2B37375781E2D584E16AAE2A10B5A1156"/>
<Deny ID="ID_DENY_D_258" FriendlyName="PubPRn 258"
Hash="EBDACA86F10AC0446D60CC75628EC7A370B1E2236E6D20F22372F91033B6D429"/>

<Deny ID="ID_DENY_D_259" FriendlyName="PubPrn 259" Hash="C9D6394BBFF8CD9C6590F08C54EC6AFDEB5CFFB4"/>
Hash="518E4EA7A2B70713E1AEC6E7E75A488C39384B625C5F2779073E9294CBF2BD9F"/>


<Deny ID="ID_DENY_D_263" FriendlyName="PubPrn 263" Hash="763A652217A1E30F2D288B7F44E08346949A02CD"/>
Hash="FCDDA212B06602F642B29FC05316EF75E4EE9975E6E8A9526E842BE2EA237C5D"/>


<Deny ID="ID_DENY_D_267" FriendlyName="PubPrn 267" Hash="60FD28D770B23A0477679311D247DA4D5C61074C"/>
Hash="D09A4B2EA611CDFDC6DCA44314289B622B2A5EDA09716EF4A16B91EC90BFBA8F"/>


<Deny ID="ID_DENY_D_271" FriendlyName="PubPrn 271" Hash="47CBE201ED224BF3F5C322F7A49EF64469AF2E1A"/>
Hash="24855B9CC420719D5AB93F4F1589CE09E4063E4FC98681BD91A1D18A3C8ACB43"/>


<Deny ID="ID_DENY_D_275" FriendlyName="PubPrn 275" Hash="663D8E25BAE20510A882F6692BE2620FBABFB94E"/>
Hash="649A9E5A4867A28C7D0934793F33B545F9441EA23872715C84826D80CC8EC576"/>

<Deny ID="ID_DENY_D_277" FriendlyName="PubPrn 277" Hash="226ABB2FBAEFC5A7E2A819D9D708F826C00FD215"/>
Hash="AC6B35C904D388FD12C07C2F6A1A07F337D31895713BF01DCCE7A7F187D7F4D9"/>

<Deny ID="ID_DENY_D_279" FriendlyName="PubPrn 279" Hash="071D7849941E43144839988971255FE34690A747"/>
Hash="5AF75895BDC11A6B68C816A8677D7CF9692BF25A95C4378A43FBDE740B18EEB1"/>

<Deny ID="ID_DENY_D_281" FriendlyName="PubPrn 281" Hash="9FBFF074C201BFEBE37710CB453EFF9A14AE3BFF"/>
Hash="A0C71A925850D2D481C7E520F5D5A83305EC169EEA4C5B8DC20C8D8AFCD8A512"/>


<Deny ID="ID_DENY_D_283" FriendlyName="PSWorkflowUtility 283"
Hash="4FBC9A72C5D5246F34994F13076A5AD98A1A844E"/>
Hash="7BF44433D3A606104778F64B11B92C52FC99C4BA570C50B70438275D0B587B8E"/>

Hash="99382ED8FA3577DFD903C01478A79D6D90681406"/>
Hash="C3A5DAB20947CA8FD092E75C25177E7BAE7884CA58710F14827144C09EA1F94B"/>

<Deny ID="ID_DENY_D_583" FriendlyName="Winrm 583" Hash="3FA2D2963CBF47FFD5F7F5A9B4576F34ED42E552"/>
<Deny ID="ID_DENY_D_584" FriendlyName="Winrm 584"
Hash="6C96E976DC47E0C99B77814E560E0DC63161C463C75FA15B7A7CA83C11720E82"/>
</FileRules>

-->
<Signers />

<SigningScenarios>
<SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS_1" FriendlyName="Driver Signing Scenarios">
<ProductSigners>
<FileRulesRef>
<FileRuleRef RuleID="ID_DENY_KD_KMCI"/>
</FileRulesRef>
</ProductSigners>
</SigningScenario>
<SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="User Mode Signing Scenarios">
<ProductSigners>
<FileRulesRef>
<FileRuleRef RuleID="ID_DENY_ADDINPROCESS"/>
<FileRuleRef RuleID="ID_DENY_ADDINPROCESS32"/>
<FileRuleRef RuleID="ID_DENY_ADDINUTIL"/>
<FileRuleRef RuleID="ID_DENY_ASPNET"/>
<FileRuleRef RuleID="ID_DENY_BASH"/>
<FileRuleRef RuleID="ID_DENY_BGINFO"/>
<FileRuleRef RuleID="ID_DENY_CBD"/>
<FileRuleRef RuleID="ID_DENY_CSI"/>
<FileRuleRef RuleID="ID_DENY_DBGHOST"/>
<FileRuleRef RuleID="ID_DENY_DBGSVC"/>
<FileRuleRef RuleID="ID_DENY_DNX"/>
<FileRuleRef RuleID="ID_DENY_DOTNET" />
<FileRuleRef RuleID="ID_DENY_FSI"/>
<FileRuleRef RuleID="ID_DENY_FSI_ANYCPU"/>
<FileRuleRef RuleID="ID_DENY_INFINSTALL"/>
<FileRuleRef RuleID="ID_DENY_KD"/>
<FileRuleRef RuleID="ID_DENY_KILL"/>
<FileRuleRef RuleID="ID_DENY_LXSS"/>
<FileRuleRef RuleID="ID_DENY_LXRUN"/>
<FileRuleRef RuleID="ID_DENY_MFC40"/>
<FileRuleRef RuleID="ID_DENY_MS_BUILD" />
<FileRuleRef RuleID="ID_DENY_MS_BUILD_FMWK" />
<FileRuleRef RuleID="ID_DENY_MWFC" />
<FileRuleRef RuleID="ID_DENY_MSBUILD"/>
<FileRuleRef RuleID="ID_DENY_MSBUILD_DLL" />
<FileRuleRef RuleID="ID_DENY_MSHTA"/>
<FileRuleRef RuleID="ID_DENY_NTKD"/>
<FileRuleRef RuleID="ID_DENY_NTSD"/>
<FileRuleRef RuleID="ID_DENY_PWRSHLCUSTOMHOST"/>
<FileRuleRef RuleID="ID_DENY_RCSI"/>
<FileRuleRef RuleID="ID_DENY_RUNSCRIPTHELPER"/>
<FileRuleRef RuleID="ID_DENY_TEXTTRANSFORM"/>
<FileRuleRef RuleID="ID_DENY_VISUALUIAVERIFY"/>
<FileRuleRef RuleID="ID_DENY_WFC" />
<FileRuleRef RuleID="ID_DENY_WINDBG"/>
<FileRuleRef RuleID="ID_DENY_WMIC"/>
<FileRuleRef RuleID="ID_DENY_WSL"/>
<FileRuleRef RuleID="ID_DENY_WSLCONFIG"/>
<FileRuleRef RuleID="ID_DENY_WSLHOST"/>

<FileRuleRef RuleID="ID_DENY_D_1"/>
</FileRulesRef>
</ProductSigners>
</SigningScenario>
</SigningScenarios>
<UpdatePolicySigners />
<CiSigners />
<HvciOptions>0</HvciOptions>
</SiPolicy>
NOTE
To create a policy that works on both Windows 10, version 1803 and version 1809, you can create two different policies,
or merge them into one broader policy.
More information
Merge Windows Defender Application Control policies
Microsoft recommended driver block rules
Applies to:
Windows 10
Microsoft has strict requirements for code running in kernel. Consequently, malicious actors are turning to
exploit vulnerabilities in legitimate and signed kernel drivers to run malware in kernel. One of the many
strengths of the Windows platform is our strong collaboration with independent hardware vendors (IHVs) and
OEMs. Microsoft works closely with our IHVs and security community to ensure the highest level of driver
security for our customers and when vulnerabilities in drivers do arise, that they are patched and rolled out to
the ecosystem in an expedited manner. Microsoft then adds the vulnerable versions of the drivers to our
ecosystem block policy which is applied to the following sets of devices:
Hypervisor-protected code integrity (HVCI) enabled devices
Windows 10 in S mode (S mode) devices
Microsoft recommends enabling HVCI or S mode to protect your devices against security threats. If this is not
possible, Microsoft recommends blocking the following list of drivers by merging this policy with your existing
Windows Defender Application Control policy. Blocking kernel drivers without sufficient testing can result in
devices or software to malfunction, and in rare cases, blue screen. It is recommended to first validate this policy
in audit mode and review the audit block events.
NOTE
issues are discovered. It is recommended that this policy be first validated in audit mode before rolling the rules into
enforcement mode.
<?xml version="1.0" encoding="utf-8"?>

<PolicyTypeID>{D2BDA982-CCF6-4344-AC5B-0B44427B6816}</PolicyTypeID>
<Rules>
<Rule>
</Rule>
<Rule>
</Rule>
<Rule>
</Rule>
</Rules>

<EKUs />

<FileRules>
<Allow ID="ID_ALLOW_ALL_1" FriendlyName="" FileName="*" />
<Allow ID="ID_ALLOW_ALL_2" FriendlyName="" FileName="*" />
<Deny ID="ID_DENY_BANDAI_SHA1" FriendlyName="bandai.sys Hash Sha1"
Hash="0F780B7ADA5DD8464D9F2CC537D973F5AC804E9C" />
Hash="7FD788358585E0B863328475898BB4400ED8D478466D1B7F5CC0252671456CC8" />
<Deny ID="ID_DENY_BANDAI_SHA1_PAGE" FriendlyName="bandai.sys Hash Page Sha1"
Hash="EA360A9F23BB7CF67F08B88E6A185A699F0C5410" />
<Deny ID="ID_DENY_BANDAI_SHA256_PAGE" FriendlyName="bandai.sys Hash Page Sha256"
Hash="BB83738210650E09307CE869ACA9BFA251024D3C47B1006B94FCE2846313F56E" />
<Deny ID="ID_DENY_CAPCOM_SHA1" FriendlyName="capcom.sys Hash Sha1"
Hash="1D1CAFC73C97C6BCD2331F8777D90FDCA57125A3" />
<Deny ID="ID_DENY_CAPCOM_SHA256" FriendlyName="capcom.sys Hash Sha256"
Hash="FAA08CB609A5B7BE6BFDB61F1E4A5E8ADF2F5A1D2492F262483DF7326934F5D4" />
<Deny ID="ID_DENY_CAPCOM_SHA1_PAGE" FriendlyName="capcom.sys Hash Page Sha1"
Hash="69006FBBD1B150FB9404867A5BCDC04FE0FC1BAD" />
<Deny ID="ID_DENY_CAPCOM_SHA256_PAGE" FriendlyName="capcom.sys Hash Page Sha256"
Hash="42589C7CE89941060465096C4661654B43E38C1F9D05D66239825E8FCCF52705" />
<Deny ID="ID_DENY_FIDDRV_SHA1" FriendlyName="fiddrv.sys Hash Sha1"
Hash="8CC8974A05E81678E3D28ACFE434E7804ABD019C" />
<Deny ID="ID_DENY_FIDDRV_SHA256" FriendlyName="fiddrv.sys Hash Sha256"
Hash="97B976F7E7E5DF7AF0781BBBB33CB5F3F7A59EFDD07995253B31DE8123352A67" />
<Deny ID="ID_DENY_FIDDRV_SHA1_PAGE" FriendlyName="fiddrv.sys Hash Page Sha1"
Hash="282BB241BDA5C4C1B8EB9BF56D018896649CA0E1" />
<Deny ID="ID_DENY_FIDDRV_SHA256_PAGE" FriendlyName="fiddrv.sys Hash Page Sha256"
Hash="1ED9DA2DA2539284404E0701E6BA3C9EB37BE10353E826F425A194D247B8B7CE" />
<Deny ID="ID_DENY_FIDDRV64_SHA1" FriendlyName="fiddrv64.sys Hash Sha1"
Hash="10E15BA8FF8ED926DDD3636CEC66A0F08C9860A4" />
<Deny ID="ID_DENY_FIDDRV64_SHA256" FriendlyName="fiddrv64.sys Hash Sha256"
Hash="FEEF191064D18B6FB63B7299415D1B1E2EC8FCDD742854AA96268D0EC4A0F7B6" />
<Deny ID="ID_DENY_FIDDRV64_SHA1_PAGE" FriendlyName="fiddrv64.sys Hash Page Sha1"
Hash="E4436C8C42BA5FFABD58A3B2256F6E86CCC907AB" />
<Deny ID="ID_DENY_FIDDRV64_SHA256_PAGE" FriendlyName="fiddrv64.sys Hash Page Sha256"
Hash="2D48414647A7F9DEA30F19074EBF8F17E55E9031B8604794CEB88369C8C52532" />
<Deny ID="ID_DENY_FIDPCIDRV_SHA1" FriendlyName="fidpcidrv.sys Hash Sha1"
Hash="08596732304351B311970FF96B21F451F23B1E25" />
<Deny ID="ID_DENY_FIDPCIDRV_SHA256" FriendlyName="fidpcidrv.sys Hash Sha256"
Hash="7B7E0E1453E733050B586A6FAC91883DBB85AE0775C84C4CEB967CFC9B4EFD10" />
<Deny ID="ID_DENY_FIDPCIDRV_SHA1_PAGE" FriendlyName="fidpcidrv.sys Hash Page Sha1"
Hash="7838FB56FDAB816BC1900A4720EEA2FC9972EF7A" />
<Deny ID="ID_DENY_FIDPCIDRV_SHA256_PAGE" FriendlyName="fidpcidrv.sys Hash Page Sha256"
Hash="0893E186E236315FE78A7EF41ED71617E75D90D2D14FE93911E0D9344BEAF69F" />
<Deny ID="ID_DENY_FIDPCIDRV64_SHA1" FriendlyName="fidpcidrv64.sys Hash Sha1"
Hash="4789B910023A667BEE70FF1F1A8F369CFFB10FE8" />
<Deny ID="ID_DENY_FIDPCIDRV64_SHA256" FriendlyName="fidpcidrv64.sys Hash Sha256"
Hash="7FB0F6FC5BDD22D53F8532CB19DA666A77A66FFB1CF3919A2E22B66C13B415B7" />
<Deny ID="ID_DENY_FIDPCIDRV64_SHA1_PAGE" FriendlyName="fidpcidrv64.sys Hash Page Sha1"
Hash="EEFF4EC4EBC12C6ACD2C930DC2EAAF877CFEC7EC" />
<Deny ID="ID_DENY_FIDPCIDRV64_SHA256_PAGE" FriendlyName="fidpcidrv64.sys Hash Page Sha256"
Hash="B98E008DFEA10EC74C89D08F12F31C12F52234BE6FFFF06B6B9E749BFEA6CBED" />
<Deny ID="ID_DENY_GDRV" FriendlyName="gdrv.sys" FileName="gdrv.sys" />
<Deny ID="ID_DENY_GLCKIO2_SHA1" FriendlyName="GLCKIO2.sys Hash Sha1"
Hash="D99B80B3269D735CAC43AF5E43483E64CA7961C3" />
<Deny ID="ID_DENY_GLCKIO2_SHA256" FriendlyName="GLCKIO2.sys Hash Sha256"
Hash="47DBA240967FD0088BE618163672DFBDDF0138178CCCD45B54037F622B221220" />
<Deny ID="ID_DENY_GLCKIO2_SHA1_PAGE" FriendlyName="GLCKIO2.sys Hash Page Sha1"
Hash="51E0740AAEE5AE76B0095C92908C97B817DB8BEA" />
<Deny ID="ID_DENY_GLCKIO2_SHA256_PAGE" FriendlyName="GLCKIO2.sys Hash Page Sha256"
Hash="E7F011E9857C7DB5AACBD424612CD7E3D12C363FDC8F072DDFAF9E2E5C85F5F3" />
<Deny ID="ID_DENY_GVCIDRV64_SHA1" FriendlyName="GVCIDrv64.sys Hash Sha1"
Hash="4EAE38E9DC262EB7B6EDE4B3D3F4AD068933845E" />
<Deny ID="ID_DENY_GVCIDRV64_SHA256" FriendlyName="GVCIDrv64.sys Hash Sha256"
Hash="2FF09BB919A9909068166C30322C4E904BEFEBA5429E9A11D011297FB8A73C07" />
<Deny ID="ID_DENY_GVCIDRV64_SHA1_PAGE" FriendlyName="GVCIDrv64.sys Hash Page Sha1"
Hash="6980122AEF4E2D5D7A6DDDB6DA76A166C460E0A1" />
<Deny ID="ID_DENY_GVCIDRV64_SHA256_PAGE" FriendlyName="GVCIDrv64.sys Hash Page Sha256"
Hash="A69247025DD32DC15E06FEE362B494BCC6105D34B8D7091F7EC3D9000BD71501" />
<Deny ID="ID_DENY_WINFLASH64_SHA1" FriendlyName="WinFlash64.sys Hash Sha1"
Hash="DA21F5889F8374C3961856D681ADEC3D663D2964" />
<Deny ID="ID_DENY_WINFLASH64_SHA256" FriendlyName="WinFlash64.sys Hash Sha256"
Hash="F2B51FBEEAD17F5EE34D5B4A3A83C848FB76F8F0E80769212E137A7AA539A3BC" />
<Deny ID="ID_DENY_WINFLASH64_SHA1_PAGE" FriendlyName="WinFlash64.sys Hash Page Sha1"
Hash="C5057A4FD3C9B58F4C9AB9FE356081DF8804BF98" />
<Deny ID="ID_DENY_WINFLASH64_SHA256_PAGE" FriendlyName="WinFlash64.sys Hash Page Sha256"
Hash="C8FA1EC3D03050FBC1AA677F2C0348690521291219E8D2E94F0EA9E9174B9156" />
<Deny ID="ID_DENY_AMIFLDRV64_SHA1" FriendlyName="amifldrv64.sys Hash Sha1"
Hash="B0EC7D971DA8AE84C0ED8F88A5D46B23996E636C" />
<Deny ID="ID_DENY_AMIFLDRV64_SHA256C" FriendlyName="amifldrv64.sys Hash Sha256"
Hash="038F39558035292F1D794B7CF49F8E751E8633DAEC31454FE85CCCBEA83BA3FB" />
<Deny ID="ID_DENY_AMIFLDRV64_SHA1_PAGE" FriendlyName="amifldrv64.sys Hash Page Sha1"
Hash="C9CC3779ED67755220DBF9592EC2AC0E1DE363DC" />
<Deny ID="ID_DENY_AMIFLDRV64_SHA256_PAGE" FriendlyName="amifldrv64.sys Hash Page Sha256"
Hash="AA594D977312A944B14351C075634E7C59B42687928FBCDA8E2C4CEA46686DD9" />
<Deny ID="ID_DENY_ASUPIO64_SHA1F" FriendlyName="AsUpIO64.sys Hash Sha1"
Hash="2A95F882DD9BAFCC57F144A2708A7EC67DD7844C" />
<Deny ID="ID_DENY_ASUPIO64_SHA256" FriendlyName="AsUpIO64.sys Hash Sha256"
Hash="7F75D91844B0C162EEB24D14BCF63B7F230E111DAA7B0A26EAA489EEB22D9057" />
<Deny ID="ID_DENY_ASUPIO64_SHA1_PAGE" FriendlyName="AsUpIO64.sys Hash Page Sha1"
Hash="316E7872A227F0EAD483D244805E9FF4D3569F6F" />
<Deny ID="ID_DENY_ASUPIO64_SHA256_PAGE" FriendlyName="AsUpIO64.sys Hash Page Sha256"
Hash="5958CBE6CF7170C4B66893777BDE66343F5536A98610BD188E10D47DB84BC04C" />
<Deny ID="ID_DENY_BSFLASH64_SHA1" FriendlyName="BS_Flash64.sys Hash Sha1"
Hash="5107438A02164E1BCEDD556A786F37F59CD04231" />
<Deny ID="ID_DENY_BSFLASH64_SHA256" FriendlyName="BS_Flash64.sys Hash Sha256"
Hash="543C3F024E4AFFD0AAFA3A229FA19DBE7A70972BB18ED6347D3492DD174EDAC5" />
<Deny ID="ID_DENY_BSFLASH64_SHA1_PAGE" FriendlyName="BS_Flash64.sys Hash Page Sha1"
Hash="26C398B86FD33B3E6C4348F780C4CF758C99C8FD" />
<Deny ID="ID_DENY_BSFLASH64_SHA256_PAGE" FriendlyName="BS_Flash64.sys Hash Page Sha256"
Hash="8BF958AFA751D7AB66EBB1FAE25679E6F0FDE72078AEFC09F1824EEFA526005E" />
<Deny ID="ID_DENY_BSHWMIO64_SHA1" FriendlyName="BS_HWMIo64.sys Hash Sha1"
Hash="3281135748C9C7A9DDACE55C648C720AF810475F" />
<Deny ID="ID_DENY_BSHWMIO64_SHA256" FriendlyName="BS_HWMIo64.sys Hash Sha256"
Hash="3DE51A3102DB7297D96B4DE5B60ACA5F3A07E8577BBBED7F755F1DE9A9C38E75" />
<Deny ID="ID_DENY_BSHWMIO64_SHA1_PAGE" FriendlyName="BS_HWMIo64.sys Hash Page Sha1"
Hash="FC5F231383FE72E298893010A9A3714B205C4110" />
<Deny ID="ID_DENY_BSHWMIO64_SHA256_PAGE" FriendlyName="BS_HWMIo64.sys Hash Page Sha256"
Hash="6AD3624CA1DC38ECEEC75234E50934B1BAD7C72621DC57DEAB09044D0135877D" />
<Deny ID="ID_DENY_MSIO64_SHA1" FriendlyName="MsIo64.sys Hash Sha1"
Hash="7E732ACB7CFAD9BA043A9350CDEFF25D742BECB8" />
<Deny ID="ID_DENY_MSIO64_SHA256" FriendlyName="MsIo64.sys Hash Sha256"
Hash="7018D515A6C781EA6097CA71D0F0603AD0D689F7EC99DB27FCACD492A9E86027" />
<Deny ID="ID_DENY_MSIO64_SHA1_PAGE" FriendlyName="MsIo64.sys Hash Page Sha1"
Hash="CDE1A50E1DF7870F8E4AFD8631E45A847C714C0A" />
<Deny ID="ID_DENY_MSIO64_SHA256_PAGE" FriendlyName="MsIo64.sys Hash Page Sha256"
Hash="05736AB8B48DF84D81CB2CC0FBDC9D3DA34C22DB67A3E71C6F4B6B3923740DD5" />
<Deny ID="ID_DENY_PIDDRV_SHA1" FriendlyName="piddrv.sys Hash Sha1"
Hash="877C6C36A155109888FE1F9797B93CB30B4957EF" />
<Deny ID="ID_DENY_PIDDRV_SHA256" FriendlyName="piddrv.sys Hash Sha256"
Hash="4E19D4CE649C28DD947424483796BEACE3656284FB0379D97DDDD320AA602BBC" />
<Deny ID="ID_DENY_PIDDRV_SHA1_PAGE" FriendlyName="piddrv.sys Hash Page Sha1"
Hash="A7D827A41B2C4B7638495CD1D77926F1BA902978" />
<Deny ID="ID_DENY_PIDDRV_SHA256_PAGE" FriendlyName="piddrv.sys Hash Page Sha256"
Hash="EAC7316089DBAF7DF79A531355547BBDA22FA0921E31BBA0D27BCC88234E9ED3" />
<Deny ID="ID_DENY_PIDDRV64_SHA1" FriendlyName="piddrv64.sys Hash Sha1"
Hash="0C2599D738D01A82EC91725F499ACEBBCFB47CC9" />
<Deny ID="ID_DENY_PIDDRV64_SHA256" FriendlyName="piddrv64.sys Hash Sha256"
Hash="B97F870C501714FA453CF18AE8A30C87D08FF1E6D784AFDBB0121AEA3DA2DC28" />
<Deny ID="ID_DENY_PIDDRV64_SHA1_PAGE" FriendlyName="piddrv64.sys Hash Page Sha1"
Hash="C978063E678233C5EFB8F002FEF000FD479CC632" />
<Deny ID="ID_DENY_PIDDRV64_SHA256_PAGE" FriendlyName="piddrv64.sys Hash Page Sha256"
Hash="1081CCD57FD35998634103AE1E736638D82351092ACD30FE75084EA6A08CA0F7" />
<Deny ID="ID_DENY_SEMAV6MSR64_SHA1" FriendlyName="semav6msr64.sys Hash Sha1"
Hash="E3DBE2AA03847DF621591A4CAD69A5609DE5C237" />
<Deny ID="ID_DENY_SEMAV6MSR64_SHA256" FriendlyName="semav6msr64.sys Hash Sha256"
Hash="EB71A8ECEF692E74AE356E8CB734029B233185EE5C2CCB6CC87CC6B36BEA65CF" />
<Deny ID="ID_DENY_SEMAV6MSR64_SHA1_PAGE" FriendlyName="semav6msr64.sys Hash Page Sha1"
Hash="F3821EC0AEF270F749DF9F44FBA91AFA5C8C38E8" />
<Deny ID="ID_DENY_SEMAV6MSR64_SHA256_PAGE" FriendlyName="semav6msr64.sys Hash Page Sha256"
Hash="4F12EE563E7496E7105D67BF64AF6B436902BE4332033AF0B5A242B206372CB7" />
<FileAttrib ID="ID_FILEATTRIB_CPUZ_DRIVER" FriendlyName="" FileName="cpuz.sys"
MinimumFileVersion="0.0.0.0" MaximumFileVersion="1.0.4.3" />
<FileAttrib ID="ID_FILEATTRIB_ELBY_DRIVER" FriendlyName="" FileName="ElbyCDIO.sys"
<FileAttrib ID="ID_FILEATTRIB_ELBY_DRIVER" FriendlyName="" FileName="ElbyCDIO.sys"
<FileAttrib ID="ID_FILEATTRIB_LIBNICM_DRIVER" FriendlyName="" FileName="libnicm.sys"
<FileAttrib ID="ID_FILEATTRIB_MTCBSV64" FriendlyName="mtcBSv64.sys FileAttribute"
FileName="mtcBSv64.sys" MinimumFileVersion="0.0.0.0" MaximumFileVersion="21.2.0.0" />
<FileAttrib ID="ID_FILEATTRIB_NICM_DRIVER" FriendlyName="" FileName="NICM.SYS"
<FileAttrib ID="ID_FILEATTRIB_NSCM_DRIVER" FriendlyName="" FileName="nscm.sys"
<FileAttrib ID="ID_FILEATTRIB_SANDRA_DRIVER" FriendlyName="" FileName="sandra.sys"
<FileAttrib ID="ID_FILEATTRIB_RTKIO64_DRIVER" FriendlyName="" FileName="rtkio64.sys "
<FileAttrib ID="ID_FILEATTRIB_RTKIOW10X64_DRIVER" FriendlyName="" FileName="rtkiow10x64.sys "
<FileAttrib ID="ID_FILEATTRIB_RTKIOW8X64_DRIVER" FriendlyName="" FileName="rtkiow8x64.sys "
<FileAttrib ID="ID_FILEATTRIB_BSMI" FriendlyName="" FileName="BSMI.sys" MinimumFileVersion="0.0.0.0"
MaximumFileVersion="1.0.0.3" />
<FileAttrib ID="ID_FILEATTRIB_BS_HWMIO64" FriendlyName="" FileName="BS_HWMIO64_W10.sys"
<FileAttrib ID="ID_FILEATTRIB_BS_I2CIO" FriendlyName="" FileName="BS_I2cIo.sys"
<FileAttrib ID="ID_FILEATTRIB_NTIOLIB" FriendlyName="" FileName="NTIOLib.sys"
<FileAttrib ID="ID_FILEATTRIB_NCHGBIOS2X64" FriendlyName="" FileName="NCHGBIOS2x64.SYS"
<FileAttrib ID="ID_FILEATTRIB_SEGWINDRVX64" FriendlyName="segwindrvx64.sys FileAttribute"
FileName="segwindrvx64.sys" MinimumFileVersion="0.0.0.0" MaximumFileVersion="100.0.7.2" />
</FileRules>

<Signers>
<Signer ID="ID_SIGNER_F_1" Name="VeriSign Class 3 Code Signing 2010 CA">
<CertRoot Type="TBS" Value="4843A82ED3B1F2BFBEE9671960E1940C942F688D" />
<CertPublisher Value="CPUID" />
<FileAttribRef RuleID="ID_FILEATTRIB_CPUZ_DRIVER" />
</Signer>
<Signer ID="ID_SIGNER_F_2" Name="Microsoft Windows Third Party Component CA 2014">
<CertRoot Type="TBS" Value="D8BE9E4D9074088EF818BC6F6FB64955E90378B2754155126FEEBBBD969CF0AE" />
<CertPublisher Value="Microsoft Windows Hardware Compatibility Publisher" />
</Signer>
<Signer ID="ID_SIGNER_CPUZ" Name="DigiCert EV Code Signing CA (SHA2)">
<CertRoot Type="TBS" Value="EEC58131DC11CD7F512501B15FDBC6074C603B68CA91F7162D5A042054EDB0CF" />
<CertPublisher Value="CPUID" />
</Signer>
<Signer ID="ID_SIGNER_ELBY" Name="GlobalSign Primary Object Publishing CA">
<CertRoot Type="TBS" Value="041750993D7C9E063F02DFE74699598640911AAB" />
<CertPublisher Value="Elaborate Bytes AG" />
<FileAttribRef RuleID="ID_FILEATTRIB_ELBY_DRIVER" />
</Signer>
<Signer ID="ID_SIGNER_NOVELL" Name="VeriSign Class 3 Code Signing 2009-2 CA">
<CertRoot Type="TBS" Value="4CDC38C800761463749C3CBD94A12F32E49877BF" />
<CertPublisher Value="Novell, Inc." />
<FileAttribRef RuleID="ID_FILEATTRIB_LIBNICM_DRIVER" />
<FileAttribRef RuleID="ID_FILEATTRIB_NICM_DRIVER" />
<FileAttribRef RuleID="ID_FILEATTRIB_NSCM_DRIVER" />
</Signer>
<Signer ID="ID_SIGNER_SANDRA" Name="GeoTrust TrustCenter CodeSigning CA I">
<CertRoot Type="TBS" Value="172F39BCA3DDA7C6D5169C96B34A5FE7E96FF0BD" />
<CertPublisher Value="SiSoftware Ltd" />
<FileAttribRef RuleID="ID_FILEATTRIB_SANDRA_DRIVER" />
</Signer>
<Signer ID="ID_SIGNER_MIMIKATZ_KERNEL" Name="GlobalSign CodeSigning CA - G2">
<CertRoot Type="TBS" Value="589A7D4DF869395601BA7538A65AFAE8C4616385" />
<CertPublisher Value="Benjamin Delpy" />
</Signer>
<Signer ID="ID_SIGNER_MIMIKATZ_USER" Name="Certum Code Signing CA SHA2">
<Signer ID="ID_SIGNER_MIMIKATZ_USER" Name="Certum Code Signing CA SHA2">
<CertRoot Type="TBS" Value="F7B6EEB3A567223000A61F68C53B458193557C17E5D512D2825BCB13E5FC9BE5" />
<CertPublisher Value="Open Source Developer, Benjamin Delpy" />
</Signer>
<Signer ID="ID_SIGNER_SPEEDFAN" Name="VeriSign Class 3 Code Signing 2004 CA">
<CertRoot Type="TBS" Value="C7FC1727F5B75A6421A1F95C73BBDB23580C48E5" />
<CertPublisher Value="Sokno S.R.L." />
</Signer>
<Signer ID="ID_SIGNER_RWEVERY" Name="GlobalSign CodeSigning CA - G2">
<CertPublisher Value="ChongKim Chan" />
</Signer>
<Signer ID="ID_SIGNER_VBOX" Name="GlobalSign Primary Object Publishing CA">
<CertPublisher Value="innotek GmbH" />
</Signer>
<Signer ID="ID_SIGNER_REALTEK" Name="DigiCert EV Code Signing CA">
<CertRoot Type="TBS" Value="2D54C16A8F8B69CCDEA48D0603C132F547A5CF75" />
<CertPublisher Value="Realtek Semiconductor Corp." />
<FileAttribRef RuleID="ID_FILEATTRIB_RTKIO64_DRIVER" />
<FileAttribRef RuleID="ID_FILEATTRIB_RTKIOW10X64_DRIVER" />
</Signer>
<Signer ID="ID_SIGNER_REALTEK_2" Name="DigiCert EV Code Signing CA (SHA2)">
<CertRoot Type="TBS" Value="EEC58131DC11CD7F512501B15FDBC6074C603B68CA91F7162D5A042054EDB0CF" />
<CertPublisher Value="Realtek Semiconductor Corp." />
<FileAttribRef RuleID="ID_FILEATTRIB_RTKIO64_DRIVER" />
</Signer>
<Signer ID="ID_SIGNER_WINDOWS_3RD_PARTY_2014" Name="Microsoft Windows Third Party Component CA 2014">
<CertRoot Type="TBS" Value="D8BE9E4D9074088EF818BC6F6FB64955E90378B2754155126FEEBBBD969CF0AE" />
<CertPublisher Value="Microsoft Windows Hardware Compatibility Publisher" />
<FileAttribRef RuleID="ID_FILEATTRIB_BS_HWMIO64" />
</Signer>
<Signer ID="ID_SIGNER_VERISIGN_2004" Name="VeriSign Class 3 Code Signing 2004 CA">
<CertPublisher Value="Mitac Technology Corporation" />
<FileAttribRef RuleID="ID_FILEATTRIB_MTCBSV64" />
</Signer>
<Signer ID="ID_SIGNER_VERISIGN_2009" Name="VeriSign Class 3 Code Signing 2009-2 CA">
<CertRoot Type="TBS" Value="4CDC38C800761463749C3CBD94A12F32E49877BF" />
<CertPublisher Value="BIOSTAR MICROTECH INT'L CORP" />
<FileAttribRef RuleID="ID_FILEATTRIB_BSMI" />
</Signer>
<Signer ID="ID_SIGNER_VERISIGN_BIOSTAR" Name="VeriSign Class 3 Code Signing 2004 CA">
<CertPublisher Value="BIOSTAR MICROTECH INT'L CORP" />
<FileAttribRef RuleID="ID_FILEATTRIB_BS_I2CIO" />
</Signer>
<Signer ID="ID_SIGNER_GLOBALSIGN_G2_MICROSTAR" Name="GlobalSign CodeSigning CA - G2">
<CertPublisher Value="MICRO-STAR INTERNATIONAL CO., LTD." />
<FileAttribRef RuleID="ID_FILEATTRIB_NTIOLIB" />
</Signer>
<Signer ID="ID_SIGNER_VERISIGN_TOSHIBA" Name="VeriSign Class 3 Code Signing 2010 CA">
<CertPublisher Value="TOSHIBA CORPORATION" />
<FileAttribRef RuleID="ID_FILEATTRIB_NCHGBIOS2X64" />
</Signer>
<Signer ID="ID_SIGNER_GLOBALSIGN_MICROSTAR" Name="GlobalSign Primary Object Publishing CA">
<CertPublisher Value="Micro-Star Int'l Co. Ltd." />
<FileAttribRef RuleID="ID_FILEATTRIB_NTIOLIB" />
</Signer>
<Signer ID="ID_SIGNER_VERISIGN_INSYDE" Name="VeriSign Class 3 Code Signing 2010 CA">
<CertPublisher Value="Insyde Software Corp." />
<FileAttribRef RuleID="ID_FILEATTRIB_SEGWINDRVX64" />
<FileAttribRef RuleID="ID_FILEATTRIB_SEGWINDRVX64" />
</Signer>
</Signers>

<SigningScenarios>
<SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DENIED_VULN_MAL_SIGNERS" FriendlyName="Signers of
known vulnerable or malicious drivers">
<ProductSigners>
<DeniedSigners>
<DeniedSigner SignerId="ID_SIGNER_MIMIKATZ_KERNEL" />
<DeniedSigner SignerId="ID_SIGNER_MIMIKATZ_USER" />
<DeniedSigner SignerId="ID_SIGNER_NOVELL" />
<DeniedSigner SignerId="ID_SIGNER_RWEVERY" />
<DeniedSigner SignerId="ID_SIGNER_SANDRA" />
<DeniedSigner SignerId="ID_SIGNER_SPEEDFAN" />
<DeniedSigner SignerId="ID_SIGNER_VBOX" />
<DeniedSigner SignerId="ID_SIGNER_CPUZ" />
<DeniedSigner SignerId="ID_SIGNER_ELBY" />
<DeniedSigner SignerId="ID_SIGNER_F_1" />
<DeniedSigner SignerId="ID_SIGNER_F_2" />
<DeniedSigner SignerId="ID_SIGNER_REALTEK" />
<DeniedSigner SignerId="ID_SIGNER_REALTEK_2" />
<DeniedSigner SignerId="ID_SIGNER_VERISIGN_2004" />
<DeniedSigner SignerId="ID_SIGNER_WINDOWS_3RD_PARTY_2014" />
<DeniedSigner SignerId="ID_SIGNER_VERISIGN_2009" />
<DeniedSigner SignerId="ID_SIGNER_VERISIGN_BIOSTAR" />
<DeniedSigner SignerId="ID_SIGNER_GLOBALSIGN_G2_MICROSTAR" />
<DeniedSigner SignerId="ID_SIGNER_VERISIGN_TOSHIBA" />
<DeniedSigner SignerId="ID_SIGNER_GLOBALSIGN_MICROSTAR" />
<DeniedSigner SignerId="ID_SIGNER_VERISIGN_INSYDE" />
</DeniedSigners>
<FileRulesRef>
<FileRuleRef RuleID="ID_ALLOW_ALL_1"/>
<FileRuleRef RuleID="ID_DENY_BANDAI_SHA1" />
<FileRuleRef RuleID="ID_DENY_BANDAI_SHA256" />
<FileRuleRef RuleID="ID_DENY_BANDAI_SHA1_PAGE" />
<FileRuleRef RuleID="ID_DENY_BANDAI_SHA256_PAGE" />
<FileRuleRef RuleID="ID_DENY_CAPCOM_SHA1" />
<FileRuleRef RuleID="ID_DENY_CAPCOM_SHA256" />
<FileRuleRef RuleID="ID_DENY_CAPCOM_SHA1_PAGE" />
<FileRuleRef RuleID="ID_DENY_CAPCOM_SHA256_PAGE" />
<FileRuleRef RuleID="ID_DENY_FIDDRV_SHA1"/>
<FileRuleRef RuleID="ID_DENY_FIDDRV_SHA256"/>
<FileRuleRef RuleID="ID_DENY_FIDDRV_SHA1_PAGE"/>
<FileRuleRef RuleID="ID_DENY_FIDDRV_SHA256_PAGE"/>
<FileRuleRef RuleID="ID_DENY_FIDDRV64_SHA1"/>
<FileRuleRef RuleID="ID_DENY_FIDDRV64_SHA256"/>
<FileRuleRef RuleID="ID_DENY_FIDDRV64_SHA1_PAGE"/>
<FileRuleRef RuleID="ID_DENY_FIDDRV64_SHA256_PAGE"/>
<FileRuleRef RuleID="ID_DENY_FIDPCIDRV_SHA1"/>
<FileRuleRef RuleID="ID_DENY_FIDPCIDRV_SHA256"/>
<FileRuleRef RuleID="ID_DENY_FIDPCIDRV_SHA1_PAGE"/>
<FileRuleRef RuleID="ID_DENY_FIDPCIDRV_SHA256_PAGE"/>
<FileRuleRef RuleID="ID_DENY_FIDPCIDRV64_SHA1"/>
<FileRuleRef RuleID="ID_DENY_FIDPCIDRV64_SHA256"/>
<FileRuleRef RuleID="ID_DENY_FIDPCIDRV64_SHA1_PAGE"/>
<FileRuleRef RuleID="ID_DENY_FIDPCIDRV64_SHA256_PAGE"/>
<FileRuleRef RuleID="ID_DENY_GDRV" />
<FileRuleRef RuleID="ID_DENY_GLCKIO2_SHA1"/>
<FileRuleRef RuleID="ID_DENY_GLCKIO2_SHA256"/>
<FileRuleRef RuleID="ID_DENY_GLCKIO2_SHA1_PAGE"/>
<FileRuleRef RuleID="ID_DENY_GLCKIO2_SHA256_PAGE"/>
<FileRuleRef RuleID="ID_DENY_GVCIDRV64_SHA1"/>
<FileRuleRef RuleID="ID_DENY_GVCIDRV64_SHA256"/>
<FileRuleRef RuleID="ID_DENY_GVCIDRV64_SHA1_PAGE"/>
<FileRuleRef RuleID="ID_DENY_GVCIDRV64_SHA256_PAGE"/>
<FileRuleRef RuleID="ID_DENY_WINFLASH64_SHA1"/>
<FileRuleRef RuleID="ID_DENY_WINFLASH64_SHA256"/>
<FileRuleRef RuleID="ID_DENY_WINFLASH64_SHA1_PAGE"/>
<FileRuleRef RuleID="ID_DENY_AMIFLDRV64_SHA1"/>
<FileRuleRef RuleID="ID_DENY_AMIFLDRV64_SHA256C"/>
<FileRuleRef RuleID="ID_DENY_AMIFLDRV64_SHA1_PAGE"/>
<FileRuleRef RuleID="ID_DENY_AMIFLDRV64_SHA256_PAGE"/>
<FileRuleRef RuleID="ID_DENY_ASUPIO64_SHA1F" />
<FileRuleRef RuleID="ID_DENY_ASUPIO64_SHA256" />
<FileRuleRef RuleID="ID_DENY_ASUPIO64_SHA1_PAGE"/>
<FileRuleRef RuleID="ID_DENY_ASUPIO64_SHA256_PAGE"/>
<FileRuleRef RuleID="ID_DENY_BSFLASH64_SHA1"/>
<FileRuleRef RuleID="ID_DENY_BSFLASH64_SHA256"/>
<FileRuleRef RuleID="ID_DENY_BSFLASH64_SHA1_PAGE"/>
<FileRuleRef RuleID="ID_DENY_BSFLASH64_SHA256_PAGE"/>
<FileRuleRef RuleID="ID_DENY_BSHWMIO64_SHA1" />
<FileRuleRef RuleID="ID_DENY_BSHWMIO64_SHA256"/>
<FileRuleRef RuleID="ID_DENY_BSHWMIO64_SHA1_PAGE"/>
<FileRuleRef RuleID="ID_DENY_BSHWMIO64_SHA256_PAGE"/>
<FileRuleRef RuleID="ID_DENY_MSIO64_SHA1"/>
<FileRuleRef RuleID="ID_DENY_MSIO64_SHA256"/>
<FileRuleRef RuleID="ID_DENY_MSIO64_SHA1_PAGE"/>
<FileRuleRef RuleID="ID_DENY_MSIO64_SHA256_PAGE"/>
<FileRuleRef RuleID="ID_DENY_PIDDRV_SHA1"/>
<FileRuleRef RuleID="ID_DENY_PIDDRV_SHA256"/>
<FileRuleRef RuleID="ID_DENY_PIDDRV_SHA1_PAGE"/>
<FileRuleRef RuleID="ID_DENY_PIDDRV_SHA256_PAGE"/>
<FileRuleRef RuleID="ID_DENY_PIDDRV64_SHA1"/>
<FileRuleRef RuleID="ID_DENY_PIDDRV64_SHA256"/>
<FileRuleRef RuleID="ID_DENY_PIDDRV64_SHA1_PAGE"/>
<FileRuleRef RuleID="ID_DENY_PIDDRV64_SHA256_PAGE"/>
<FileRuleRef RuleID="ID_DENY_SEMAV6MSR64_SHA1"/>
<FileRuleRef RuleID="ID_DENY_SEMAV6MSR64_SHA256"/>
<FileRuleRef RuleID="ID_DENY_SEMAV6MSR64_SHA1_PAGE"/>
<FileRuleRef RuleID="ID_DENY_SEMAV6MSR64_SHA256_PAGE"/>
</FileRulesRef>
</ProductSigners>
</SigningScenario>
<SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="">
<ProductSigners>
<FileRulesRef>
<FileRuleRef RuleID="ID_ALLOW_ALL_2" />
</FileRulesRef>
</ProductSigners>
</SigningScenario>
</SigningScenarios>
<CiSigners />
<Settings>
<Setting Provider="PolicyInfo" Key="Information" ValueName="Name">
<Value>
<String>Microsoft Windows Driver Policy</String>
</Value>
</Setting>
<Setting Provider="PolicyInfo" Key="Information" ValueName="Id">
<Value>
<String>10.0.19565.0</String>
</Value>
</Setting>
</Settings>
</SiPolicy>
More information
Windows Defender Application Control example
base policies
Applies to:
Windows 10
When creating policies for use with Windows Defender Application Control (WDAC), it is recommended to start
from an existing base policy and then add or remove rules to build your own custom policy XML files. Windows
includes several example policies which can be used, or organizations which use the Device Guard Signing
Service can download a starter policy from that service.
Example Base Policies

EXA M P L E B A SE P O L IC Y DESC RIP T IO N W H ERE IT C A N B E F O UN D
DefaultWindows.xml This example policy is available in %OSDrive%\Windows\schemas\CodeIn

either audit or enforce mode. It tegrity\ExamplePolicies
includes the rules necessary to ensure
that Windows, 3rd party hardware and
software kernel drivers, and Windows
Store apps will run. Used as the basis
for all Microsoft Endpoint
Manager(MEM) policies.
AllowMicrosoft.xml This example policy is available in audit %OSDrive%\Windows\schemas\CodeIn

mode. It includes the rules from tegrity\ExamplePolicies
DefaultWindows and adds rules to
trust apps signed by the Microsoft
product root certificate.
AllowAll.xml This example policy is useful when %OSDrive%\Windows\schemas\CodeIn

creating a block list policy. All block tegrity\ExamplePolicies
policies should include rules allowing
all other code to run and then add the
DENY rules for your organization's
needs.
AllowAll_EnableHVCI.xml This example policy can be used to %OSDrive%\Windows\schemas\CodeIn

enable memory integrity (also known tegrity\ExamplePolicies
as hypervisor-protected code integrity)
using WDAC.
DenyAllAudit.xml This example policy should only be %OSDrive%\Windows\schemas\CodeIn

deployed in audit mode and can be tegrity\ExamplePolicies
used to audit all binaries running on
critical systems or to comply with
regulatory requirements.
EXA M P L E B A SE P O L IC Y DESC RIP T IO N W H ERE IT C A N B E F O UN D
Device Guard Signing Ser vice This example policy is available in audit DGSS in the Microsoft Store for
(DGSS) DefaultPolicy.xml mode. It includes the rules from Business
DefaultWindows and adds rules to
trust apps signed with your
organization-specific certificates issued
by the DGSS.
MEM Configuration Manager Customers who use MEM %OSDrive%\Windows\CCM\DeviceGua

Configuration Manager (MEMCM), rd on a managed endpoint
formerly known as System Center
Configuration Manager, can deploy a
policy to a device using MEMCM's
built-in integration with WDAC and
then copy the resulting policy XML to
use as a custom base policy.
Windows Defender Application Control deployment
in different scenarios: types of devices
Applies to
Windows 10
Typically, deployment of Windows Defender Application Control (WDAC) happens best in phases, rather than
being a feature that you simply “turn on.” The choice and sequence of phases depends on the way various
computers and other devices are used in your organization, and to what degree IT manages those devices. The
following table can help you begin to develop a plan for deploying WDAC in your organization. It is very
common for organizations to have device use cases across each of the categories described.
Types of devices
T Y P E O F DEVIC E H O W W DA C REL AT ES TO T H IS T Y P E O F DEVIC E
Lightly managed devices : Company-owned, but users WDAC can be used to help protect the kernel, and to
are free to install software. monitor (audit) for problem applications rather than limiting
Devices are required to run organization's antivirus solution the applications that can be run.
and client management tools.
Fully managed devices : Allowed software is restricted by An initial baseline WDAC policy can be established and
IT department. enforced. Whenever the IT department approves additional
Users can request additional software, or install from a list of applications, it will update the WDAC policy and (for
applications provided by IT department. unsigned LOB applications) the catalog.
Examples: locked-down, company-owned desktops and WDAC policies are supported by the HVCI service.
laptops.
Fixed-workload devices : Perform same tasks every day. WDAC can be deployed fully, and deployment and ongoing
Lists of approved applications rarely change. administration are relatively straightforward.
Examples: kiosks, point-of-sale systems, call center After WDAC deployment, only approved applications can
computers. run. This is because of protections offered by WDAC.
Bring Your Own Device : Employees are allowed to bring In most cases, WDAC does not apply. Instead, you can
their own devices, and also use those devices away from explore other hardening and security features with MDM-
work. based conditional access solutions, such as Microsoft Intune.
However, you may choose to deploy an audit-mode policy to
these devices or employ a block-list only policy to prevent
specific apps or binaries that are considered malicious or
vulnerable by your organization.
An introduction to Lamna Healthcare Company

In the next set of topics, we will explore each of the above scenarios using a fictional organization called Lamna
Healthcare Company.
Lamna Healthcare Company (Lamna) is a large healthcare provider operating in the United States. Lamna
employs thousands of people, from doctors and nurses to accountants, in-house lawyers, and IT technicians.
Their device use cases are varied and include single-user workstations for their professional staff, shared kiosks
used by doctors and nurses to access patient records, dedicated medical devices such as MRI scanners, and
many others. Additionally, Lamna has a relaxed, bring-your-own-device policy for many of their professional
staff.
Lamna uses Microsoft Endpoint Manager (MEM) in hybrid mode with both Configuration Manager (MEMCM)
and Intune. Although they use MEM to deploy many applications, Lamna has always had very relaxed
application usage practices: individual teams and employees have been able to install and use any applications
they deem necessary for their role on their own workstations. Lamna also recently started to use Microsoft
Defender for Endpoint for better endpoint detection and response.
NOTE
Microsoft Endpoint Configuration Manager was previously known as System Center Configuration Manager.
Recently, Lamna experienced a ransomware event that required an expensive recovery process and may have
included data exfiltration by the unknown attacker. Part of the attack included installing and running malicious
binaries that evaded detection by Lamna's antivirus solution but would have been blocked by an application
control policy. In response, Lamna's executive board has authorized a number of new security IT responses,
including tightening policies for application use and introducing application control.
Up next
Applies to:
Windows 10
This section outlines the process to create a WDAC policy for lightly-managed devices within an
organization. Typically, organizations that are new to application control will be most successful if they start with
a permissive policy like the one described in this topic. Organizations can choose to harden the policy over time
to achieve a stronger overall security posture on their WDAC managed devices as described in later topics.
NOTE
Some of the WDAC options described in this topic are only available on Windows 10 version 1903 and above. When
using this topic to plan your own organization's WDAC policies, consider whether your managed clients can use all or
some of these features and assess the impact for any features that may be unavailable on your clients. You may need to
adapt this guidance to meet your specific organization's needs.
As in the previous topic, we will use the example of Lamna Healthcare Company (Lamna) to illustrate this
scenario. Lamna is attempting to adopt stronger application policies, including the use of application control to
prevent unwanted or unauthorized applications from running on their managed devices.
Alice Pena is the IT team lead tasked with the rollout of WDAC. Recognizing where Lamna is starting from, with
very loose application usage policies and a culture of maximum app flexibility for users, Alice knows that she
will need to take an incremental approach to application control and use different policies for different
workloads.
For the majority of users and devices, Alice wants to create an initial policy that is as relaxed as possible in order
to minimize user productivity impact, while still providing security value.
Define the "circle-of-trust" for lightly-managed devices

Alice identifies the following key factors to arrive at the "circle-of-trust" for Lamna's lightly-managed devices,
which currently includes most end-user devices:
All clients are running Windows 10 version 1903 or above;
All clients are managed by Microsoft Endpoint Manager (MEM) either with Configuration Manager
(MEMCM) standalone or hybrid mode with Intune;
NOTE
Microsoft Endpoint Configuration Manager was previously known as System Center Configuration Manager
(SCCM).
Some, but not all, apps are deployed using MEMCM;

Most users are local administrators on their devices;
Some teams may need additional rules to authorize specific apps that don't apply generally to all other
users.
Based on the above, Alice defines the pseudo-rules for the policy:
1. “Windows works” rules which authorizes:
Windows
WHQL (3rd party kernel drivers)
Windows Store signed apps
2. "MEMCM works” rules which includes signer and hash rules for MEMCM components to properly
function
3. Allow Managed Installer (MEMCM configured as a managed installer)
4. Allow Intelligent Security Graph (ISG) (reputation-based authorization)
5. Admin-only path rules for the following locations:
C:\Program Files*
C:\Program Files (x86)*
%windir%*
Create a custom base policy using an example WDAC base policy

Having defined the "circle-of-trust", Alice is ready to generate the initial policy for Lamna's lightly-managed
devices. She decides to use MEMCM to create the initial base policy and then customize it to meet Lamna's
needs.
Alice follows these steps to complete this task:
NOTE
If you do not use MEMCM or prefer to use a different example WDAC base policy for your own policy, skip to step 2 and
substitute the MEMCM policy path with your preferred example base policy.
1. Use MEMCM to create and deploy an audit policy to a client device running Windows 10 version 1903 or
above.
2. On the client device, run the following commands in an elevated Windows PowerShell session to initialize
variables:
$PolicyName= "Lamna_LightlyManagedClients_Audit"
$LamnaPolicy=$env:userprofile+"\Desktop\"+$PolicyName+".xml"
$MEMCMPolicy=$env:windir+"\CCM\DeviceGuard\MergedPolicy_Audit_ISG.xml"
3. Copy the policy created by MEMCM to the desktop:
cp $MEMCMPolicy $LamnaPolicy
4. Give the new policy a unique ID, descriptive name, and initial version number:
Set-CIPolicyIdInfo -FilePath $LamnaPolicy -PolicyName $PolicyName -ResetPolicyID

Set-CIPolicyVersion -FilePath $LamnaPolicy -Version "1.0.0.0"
5. Modify the copied policy to set policy rules:

Set-RuleOption -FilePath $LamnaPolicy -Option 3 # Audit Mode
Set-RuleOption -FilePath $LamnaPolicy -Option 6 # Unsigned Policy
Set-RuleOption -FilePath $LamnaPolicy -Option 9 # Advanced Boot Menu
Set-RuleOption -FilePath $LamnaPolicy -Option 12 # Enforce Store Apps
Set-RuleOption -FilePath $LamnaPolicy -Option 13 # Managed Installer
Set-RuleOption -FilePath $LamnaPolicy -Option 14 # ISG
Set-RuleOption -FilePath $LamnaPolicy -Option 16 # No Reboot
Set-RuleOption -FilePath $LamnaPolicy -Option 17 # Allow Supplemental
Set-RuleOption -FilePath $LamnaPolicy -Option 19 # Dynamic Code Security
6. Add rules to allow windir and Program Files directories:
$PathRules += New-CIPolicyRule -FilePathRule "%windir%\*"

$PathRules += New-CIPolicyRule -FilePathRule "%OSDrive%\Program Files\*"
$PathRules += New-CIPolicyRule -FilePathRule "%OSDrive%\Program Files (x86)\*"
Merge-CIPolicy -OutputFilePath $LamnaPolicy -PolicyPaths $LamnaPolicy -Rules $PathRules
7. If appropriate, add additional signer or file rules to further customize the policy for your organization.
8. Use ConvertFrom-CIPolicy to convert the WDAC policy to a binary format:
NOTE
In the sample commands below, replace the string "{InsertPolicyID}" with the actual PolicyID GUID (including
braces { } ) found in your policy XML file.
$WDACPolicyBin=$env:userprofile+"\Desktop\"+$PolicyName+"_{InsertPolicyID}.bin"
ConvertFrom-CIPolicy $LamnaPolicy $WDACPolicyBin
9. Upload your base policy XML and the associated binary to a source control solution such as GitHub or a
document management solution such as Office 365 SharePoint.
At this point, Alice now has an initial policy that is ready to deploy in audit mode to the managed clients within
Lamna.
Security considerations of this lightly-managed policy

In order to minimize user productivity impact, Alice has defined a policy that makes several trade-offs between
security and user app flexibility. Some of the trade-offs include:
Users with administrative access
By far the most impactful security trade-off, this allows the device user (or malware running with the
user's privileges) to modify or remove altogether the WDAC policy applied on the device. Additionally,
administrators can configure any app they wish to operate as a managed installer which would allow
them to gain persistent app authorization for whatever apps or binaries they wish.
Possible mitigations:
Use signed WDAC policies and UEFI BIOS access protection to prevent tampering of WDAC policies.
Create and deploy signed catalog files as part of the app deployment process in order to remove the
requirement for managed installer.
Use device attestation to detect the configuration state of WDAC at boot time and use that information
to condition access to sensitive corporate resources.
Unsigned policies
Unsigned policies can be replaced or removed without consequence by any process running as
administrator. Unsigned base policies that also enable supplemental policies can have their "circle-of-
trust" altered by any unsigned supplemental policy.
Limit who can elevate to administrator on the device.
Managed installer
See security considerations with managed installer
Intelligent Security Graph (ISG)
See security considerations with the Intelligent Security Graph
Implement policies requiring apps are managed by IT; audit existing app usage and deploy authorized
apps using a software distribution solution such as Microsoft Endpoint Manager; move from ISG to
managed installer or signature based rules.
Use a restrictive audit mode policy to audit app usage and augment vulnerability detection.
Supplemental policies
Supplemental policies are designed to relax the associated base policy. Additionally allowing unsigned
policies allows any administrator process to expand the "circle-of-trust" defined by the base policy
without restriction.
Use signed WDAC policies which allow authorized signed supplemental policies only.
FilePath rules
See more information about filepath rules
Migrate from filepath rules to managed installer or signature-based rules.
Up next
Prepare to deploy WDAC policies
Applies to:
Windows 10
This section outlines the process to create a WDAC policy for fully-managed devices within an organization.
The key difference between this scenario and lightly-managed devices is that all software deployed to a fully-
managed device is managed by IT and users of the device cannot install arbitrary apps. Ideally, all apps are
deployed using a software distribution solution, such as Microsoft Endpoint Manager (MEM). Additionally, users
on fully-managed devices should ideally run as standard user and only authorized IT pros have administrative
access.
NOTE
Some of the WDAC options described in this topic are only available on Windows 10 version 1903 and above. When
using this topic to plan your own organization's WDAC policies, consider whether your managed clients can use all or
some of these features and assess the impact for any features that may be unavailable on your clients. You may need to
adapt this guidance to meet your specific organization's needs.
As described in common WDAC deployment scenarios, we will use the example of Lamna Healthcare
Company (Lamna) to illustrate this scenario. Lamna is attempting to adopt stronger application policies,
including the use of application control to prevent unwanted or unauthorized applications from running on their
managed devices.
Alice Pena is the IT team lead tasked with the rollout of WDAC.
Alice previously created a policy for the organization's lightly-managed devices. Some devices, however, are
more tightly managed and can benefit from a more constrained policy. In particular, certain job functions such
as administrative staff and task-workers are not granted administrator level access to their devices. Similarly,
shared kiosks are configured only with a managed set of apps and all users of the device except IT run as
standard user. On these devices, all apps are deployed and installed by IT.
Define the "circle-of-trust" for fully-managed devices

Alice identifies the following key factors to arrive at the "circle-of-trust" for Lamna's fully-managed devices:
All clients are running Windows 10 version 1903 or above;
All clients are managed by Microsoft Endpoint Manager (MEM) either with Configuration Manager (MEMCM)
standalone or hybrid mode with Intune;
NOTE
Microsoft Endpoint Configuration Manager was previously known as System Center Configuration Manager (SCCM)
Most, but not all, apps are deployed using MEMCM;

Sometimes, IT staff install apps directly to these devices without using MEMCM;
All users except IT are standard users on these devices.
Alice's team develops a simple console application, called LamnaITInstaller.exe, which will become the authorized
way for IT staff to install apps directly to devices. LamnaITInstaller.exe allows the IT pro to launch another
process, such as an app installer. Alice will configure LamnaITInstaller.exe as an additional managed installer for
WDAC and allows her to remove the need for filepath rules.
Based on the above, Alice defines the pseudo-rules for the policy:
1. “Windows works” rules which authorizes:
Windows
WHQL (3rd party kernel drivers)
Windows Store signed apps
2. "MEMCM works” rules which includes signer and hash rules for MEMCM components to properly
function
3. Allow Managed Installer (MEMCM and LamnaITInstaller.exe configured as a managed installer)
The critical differences between this set of pseudo-rules and those defined for Lamna's lightly-managed devices
are:
Removal of the Intelligent Security Graph (ISG) option; and
Removal of filepath rules.
Create a custom base policy using an example WDAC base policy

Having defined the "circle-of-trust", Alice is ready to generate the initial policy for Lamna's fully-managed
devices. She decides to use MEMCM to create the initial base policy and then customize it to meet Lamna's
needs.
Alice follows these steps to complete this task:
NOTE
If you do not use MEMCM or prefer to use a different example WDAC base policy for your own policy, skip to step 2 and
substitute the MEMCM policy path with your preferred example base policy.
1. Use MEMCM to create and deploy an audit policy to a client device running Windows 10 version 1903 or
above.
2. On the client device, run the following commands in an elevated Windows PowerShell session to initialize
variables:
$PolicyName= "Lamna_FullyManagedClients_Audit"
$LamnaPolicy=$env:userprofile+"\Desktop\"+$PolicyName+".xml"
$MEMCMPolicy=$env:windir+"\CCM\DeviceGuard\MergedPolicy_Audit_ISG.xml"
3. Copy the policy created by MEMCM to the desktop:
cp $MEMCMPolicy $LamnaPolicy
4. Give the new policy a unique ID, descriptive name, and initial version number:
Set-CIPolicyIdInfo -FilePath $LamnaPolicy -PolicyName $PolicyName -ResetPolicyID

Set-CIPolicyVersion -FilePath $LamnaPolicy -Version "1.0.0.0"
5. Modify the copied policy to set policy rules:
Set-RuleOption -FilePath $LamnaPolicy -Option 3 # Audit Mode

Set-RuleOption -FilePath $LamnaPolicy -Option 6 # Unsigned Policy
Set-RuleOption -FilePath $LamnaPolicy -Option 9 # Advanced Boot Menu
Set-RuleOption -FilePath $LamnaPolicy -Option 12 # Enforce Store Apps
Set-RuleOption -FilePath $LamnaPolicy -Option 13 # Managed Installer
Set-RuleOption -FilePath $LamnaPolicy -Option 16 # No Reboot
Set-RuleOption -FilePath $LamnaPolicy -Option 17 # Allow Supplemental
Set-RuleOption -FilePath $LamnaPolicy -Option 19 # Dynamic Code Security
6. If appropriate, add additional signer or file rules to further customize the policy for your organization.
NOTE
In the sample commands below, replace the string "{InsertPolicyID}" with the actual PolicyID GUID (including
braces { } ) found in your policy XML file.
$WDACPolicyBin=$env:userprofile+"\Desktop\"+$PolicyName+"_{InsertPolicyID}.bin"
ConvertFrom-CIPolicy $LamnaPolicy $WDACPolicyBin
8. Upload your base policy XML and the associated binary to a source control solution such as GitHub or a
document management solution such as Office 365 SharePoint.
At this point, Alice now has an initial policy that is ready to deploy in audit mode to the managed clients within
Lamna.
Security considerations of this fully-managed policy

Alice has defined a policy for Lamna's fully-managed devices that makes some trade-offs between security and
manageability for apps. Some of the trade-offs include:
Users with administrative access
Although applying to fewer users, Lamna still allows some IT staff to log in to its fully-managed devices
as administrator. This allows these admin users (or malware running with the user's privileges) to modify
or remove altogether the WDAC policy applied on the device. Additionally, administrators can configure
any app they wish to operate as a managed installer which would allow them to gain persistent app
authorization for whatever apps or binaries they wish.
Use device attestation to detect the configuration state of WDAC at boot time and use that information
to condition access to sensitive corporate resources.
Unsigned policies
Unsigned policies can be replaced or removed without consequence by any process running as
administrator. Unsigned base policies that also enable supplemental policies can have their "circle-of-
trust" altered by any unsigned supplemental policy.
Existing mitigations applied:
Managed installer
See security considerations with managed installer
Existing mitigations applied:
Supplemental policies
Supplemental policies are designed to relax the associated base policy. Additionally allowing unsigned
policies allows any administrator process to expand the "circle-of-trust" defined by the base policy
without restriction.
Use signed WDAC policies which allow authorized signed supplemental policies only.
Up next
Create a WDAC policy for fixed-workload devices using a reference computer
Prepare to deploy WDAC policies
Create a WDAC policy for fixed-workload devices
using a reference computer
Applies to:
Windows 10
This section outlines the process to create a WDAC policy for fixed-workload devices within an organization.
Fixed-workload devices tend to be dedicated to a specific functional purpose and share common configuration
attributes with other devices servicing the same functional role. Examples of fixed-workload devices may include
Active Directory Domain Controllers, Secure Admin Workstations, pharmaceutical drug-mixing equipment,
manufacturing devices, cash registers, ATMs, etc...
For this example, you must initiate variables to be used during the creation process or use the full file paths in
the command. Then create the WDAC policy by scanning the system for installed applications. The policy file is
converted to binary format when it gets created so that Windows can interpret it.
Overview of the process of creating Windows Defender Application

Control policies
A common system imaging practice in today’s IT organization is to establish a “golden” image as a reference for
what an ideal system should look like, and then use that image to clone additional company assets. WDAC
policies follow a similar methodology, that begins with the establishment of a golden computer. As with
imaging, you can have multiple golden computers based on model, department, application set, and so on.
Although the thought process around the creation of WDAC policies is similar to imaging, these policies should
be maintained independently. Assess the necessity of additional WDAC policies based on what should be
allowed to be installed and run and for whom. For more details on doing this assessment, see the WDAC Design
Guide.
Optionally, WDAC can align with your software catalog as well as any IT department–approved applications.
One straightforward method to implement WDAC is to use existing images to create one master WDAC policy.
You do so by creating a WDAC policy from each image, and then by merging the policies. This way, what is
installed on all of those images will be allowed to run, if the applications are installed on a computer based on a
different image. Alternatively, you may choose to create a base applications policy and add policies based on the
computer’s role or department. Organizations have a choice of how their policies are created, merged or
serviced, and managed.
If you plan to use an internal CA to sign catalog files or WDAC policies, see the steps in Optional: Create a code
signing certificate for Windows Defender Application Control.
NOTE
Make sure the reference computer is virus and malware-free, and install any software you want to be scanned before
creating the WDAC policy.
Each installed software application should be validated as trustworthy before you create a policy. We
recommend that you review the reference computer for software that can load arbitrary DLLs and run code or
scripts that could render the PC more vulnerable. Examples include software aimed at development or scripting
such as msbuild.exe (part of Visual Studio and the .NET Framework) which can be removed if you do not want to
run scripts. You can remove or disable such software on the reference computer.
To create a WDAC policy, copy each of the following commands into an elevated Windows PowerShell session,
in order:
1. Initialize variables that you will use.
$PolicyPath=$env:userprofile+"\Desktop\"
$PolicyName="FixedWorkloadPolicy_Audit"
$WDACPolicy=$PolicyPath+$PolicyName+".xml"
$WDACPolicyBin=$PolicyPath+$PolicyName+".bin"
2. Use New-CIPolicy to create a new WDAC policy by scanning the system for installed applications:
New-CIPolicy -Level PcaCertificate -FilePath $WDACPolicy –UserPEs 3> CIPolicyLog.txt
NOTE
When you specify the -UserPEs parameter (to include user mode executables in the scan), rule option 0
Enabled:UMCI is automatically added to the WDAC policy. In contrast, if you do not specify -UserPEs ,
the policy will be empty of user mode executables and will only have rules for kernel mode binaries like
drivers, in other words, the allow list will not include applications. If you create such a policy and later add
rule option 0 Enabled:UMCI , all attempts to start applications will cause a response from Windows
Defender Application Control. In audit mode, the response is logging an event, and in enforced mode, the
response is blocking the application.
You can add the -MultiplePolicyFormat parameter when creating policies which will be deployed to
computers which are running Windows build 1903+. For more information about multiple policies, see
Deploy multiple Windows Defender Application Control policies.
You can add the -Fallback parameter to catch any applications not discovered using the primary file rule
level specified by the -Level parameter. For more information about file rule level options, see Windows
Defender Application Control file rule levels.
To specify that the WDAC policy scan only a specific drive, include the -ScanPath parameter followed by a
path. Without this parameter, the tool will scan the C-drive by default.
The preceding example includes 3> CIPolicylog.txt , which redirects warning messages to a text file,
CIPolicylog.txt .
ConvertFrom-CIPolicy $WDACPolicy $WDACPolicyBin
After you complete these steps, the WDAC binary file ($WDACPolicyBin) and original .xml file ($WDACPolicy)
will be available on your desktop. You can use the binary file as a WDAC policy or sign it for additional security.
NOTE
We recommend that you keep the original .xml file of the policy for use when you need to merge the WDAC policy with
another policy or update its rule options. Alternatively, you would have to create a new policy from a new scan for
servicing. For more information about how to merge WDAC policies, see Merge Windows Defender Application Control
policies.
We recommend that every WDAC policy be run in audit mode before being enforced. Doing so allows
administrators to discover any issues with the policy without receiving error messages. For information about
how to audit a WDAC policy, see Audit Windows Defender Application Control policies.
Applies to:
Windows 10
Members of the security community* continuously collaborate with Microsoft to help protect customers. With
the help of their valuable reports, Microsoft has identified a list of valid applications that an attacker could also
potentially use to bypass Windows Defender Application Control.
Unless your use scenarios explicitly require them, Microsoft recommends that you block the following
applications. These applications or files can be used by an attacker to circumvent application allow policies,
including Windows Defender Application Control:
addinprocess.exe
addinprocess32.exe
addinutil.exe
aspnet_compiler.exe
bash.exe
bginfo.exe1
cdb.exe
csi.exe
dbghost.exe
dbgsvc.exe
dnx.exe
dotnet.exe
fsi.exe
fsiAnyCpu.exe
infdefaultinstall.exe
kd.exe
kill.exe
lxssmanager.dll
lxrun.exe
Microsoft.Build.dll
Microsoft.Build.Framework.dll
Microsoft.Workflow.Compiler.exe
msbuild.exe2
msbuild.dll
mshta.exe
ntkd.exe
ntsd.exe
powershellcustomhost.exe
rcsi.exe
runscripthelper.exe
texttransform.exe
visualuiaverifynative.exe
system.management.automation.dll
wfc.exe
windbg.exe
wmic.exe
wsl.exe
wslconfig.exe
wslhost.exe
1 A vulnerability in bginfo.exe has been fixed in the latest version 4.22. If you use BGInfo, for
security, make sure
to download and run the latest version here BGInfo 4.22. Note that BGInfo versions earlier than 4.22 are still
vulnerable and should be blocked.
2 If you are using yourreference system in a development context and use msbuild.exe to build managed
applications, we recommend that you allow msbuild.exe in your code integrity policies. However, if your
reference system is an end user device that is not being used in a development context, we recommend that you
block msbuild.exe.
* Microsoft recognizes the efforts of those in the security community who help us protect customers through
responsible vulnerability disclosure, and extends thanks to the following people:
NAME T W IT T ER
Casey Smith @subTee
Matt Graeber @mattifestation
Matt Nelson @enigma0x3
Oddvar Moe @Oddvarmoe
Alex Ionescu @aionescu
Lee Christensen @tifkin_
Vladas Bulavas Kaspersky Lab
Lasse Trolle Borup Langkjaer Cyber Defence
Jimmy Bayne @bohops
Philip Tsukerman @PhilipTsukerman
Brock Mammen
NOTE
issues are discovered.
Certain software applications may allow additional code to run by design. These types of applications should be
blocked by your Windows Defender Application Control policy. In addition, when an application version is
upgraded to fix a security vulnerability or potential Windows Defender Application Control bypass, you should
add deny rules to your WDAC policies for that application’s previous, less secure versions.
Microsoft recommends that you install the latest security updates. The June 2017 Windows updates resolve
several issues in PowerShell modules that allowed an attacker to bypass Windows Defender Application Control.
These modules cannot be blocked by name or version, and therefore must be blocked by their corresponding
hashes.
For October 2017, we are announcing an update to system.management.automation.dll in which we are
revoking older versions by hash values, instead of version rules.
Microsoft recommends that you block the following Microsoft-signed applications and PowerShell files by
merging the following policy into your existing policy to add these deny rules using the Merge-CIPolicy cmdlet.
Beginning with the March 2019 quality update, each version of Windows requires blocking a specific version of
the following files:
msxml3.dll
msxml6.dll
jscript9.dll
Pick the correct version of each .dll for the Windows release you plan to support, and remove the other versions.
Ensure that you also uncomment them in the signing scenarios section.
<?xml version="1.0" encoding="utf-8" ?>

<PolicyTypeID>{A244370E-44C9-4C06-B551-F6016E563076}</PolicyTypeID>
<Rules>
<Rule>
</Rule>
<Rule>
</Rule>
<Rule>
</Rule>
<Rule>
</Rule>
</Rules>

<EKUs />

<FileRules>
<Deny ID="ID_DENY_ADDINPROCESS" FriendlyName="AddInProcess.exe" FileName="AddInProcess.exe"
<Deny ID="ID_DENY_ADDINPROCESS32" FriendlyName="AddInProcess32.exe" FileName="AddInProcess32.exe"
<Deny ID="ID_DENY_ADDINUTIL" FriendlyName="AddInUtil.exe" FileName="AddInUtil.exe"
<Deny ID="ID_DENY_ASPNET" FriendlyName="aspnet_compiler.exe" FileName="aspnet_compiler.exe"
<Deny ID="ID_DENY_BASH" FriendlyName="bash.exe" FileName="bash.exe"
<Deny ID="ID_DENY_BGINFO" FriendlyName="bginfo.exe" FileName="BGINFO.Exe" MinimumFileVersion="4.21.0.0"/>
<Deny ID="ID_DENY_CBD" FriendlyName="cdb.exe" FileName="CDB.Exe"
<Deny ID="ID_DENY_CSI" FriendlyName="csi.exe" FileName="csi.Exe"
<Deny ID="ID_DENY_DBGHOST" FriendlyName="dbghost.exe" FileName="DBGHOST.Exe"
<Deny ID="ID_DENY_DBGSVC" FriendlyName="dbgsvc.exe" FileName="DBGSVC.Exe" MinimumFileVersion="2.3.0.0"/>
<Deny ID="ID_DENY_DNX" FriendlyName="dnx.exe" FileName="dnx.Exe"
<Deny ID="ID_DENY_DOTNET" FriendlyName="dotnet.exe" FileName="dotnet.exe"
<Deny ID="ID_DENY_FSI" FriendlyName="fsi.exe" FileName="fsi.exe"
<Deny ID="ID_DENY_FSI_ANYCPU" FriendlyName="fsiAnyCpu.exe" FileName="fsiAnyCpu.exe"
<Deny ID="ID_DENY_INFINSTALL" FriendlyName="infdefaultinstall.exe" FileName="infdefaultinstall.exe"
<Deny ID="ID_DENY_KD" FriendlyName="kd.exe" FileName="kd.Exe"
<Deny ID="ID_DENY_KD_KMCI" FriendlyName="kd.exe" FileName="kd.Exe"
<Deny ID="ID_DENY_KILL" FriendlyName="kill.exe" FileName="kill.exe"
<Deny ID="ID_DENY_LXRUN" FriendlyName="lxrun.exe" FileName="lxrun.exe"
<Deny ID="ID_DENY_LXSS" FriendlyName="LxssManager.dll" FileName="LxssManager.dll"
<Deny ID="ID_DENY_MFC40" FriendlyName="mfc40.dll" FileName="mfc40.dll"
<Deny ID="ID_DENY_MS_BUILD" FriendlyName="Microsoft.Build.dll" FileName="Microsoft.Build.dll"
<Deny ID="ID_DENY_MS_BUILD_FMWK" FriendlyName="Microsoft.Build.Framework.dll"
FileName="Microsoft.Build.Framework.dll" MinimumFileVersion="65535.65535.65535.65535" />
<Deny ID="ID_DENY_MWFC" FriendlyName="Microsoft.Workflow.Compiler.exe"
FileName="Microsoft.Workflow.Compiler.exe" MinimumFileVersion="65535.65535.65535.65535" />
<Deny ID="ID_DENY_MSBUILD" FriendlyName="MSBuild.exe" FileName="MSBuild.Exe"
<Deny ID="ID_DENY_MSBUILD_DLL" FriendlyName="MSBuild.dll" FileName="MSBuild.dll"
<Deny ID="ID_DENY_MSHTA" FriendlyName="mshta.exe" FileName="mshta.exe"
<Deny ID="ID_DENY_NTKD" FriendlyName="ntkd.exe" FileName="ntkd.Exe"
<Deny ID="ID_DENY_NTSD" FriendlyName="ntsd.exe" FileName="ntsd.Exe"
<Deny ID="ID_DENY_PWRSHLCUSTOMHOST" FriendlyName="powershellcustomhost.exe"
FileName="powershellcustomhost.exe" MinimumFileVersion="65535.65535.65535.65535"/>
<Deny ID="ID_DENY_RCSI" FriendlyName="rcsi.exe" FileName="rcsi.Exe"
<Deny ID="ID_DENY_RUNSCRIPTHELPER" FriendlyName="runscripthelper.exe" FileName="runscripthelper.exe"
<Deny ID="ID_DENY_TEXTTRANSFORM" FriendlyName="texttransform.exe" FileName="texttransform.exe"
<Deny ID="ID_DENY_VISUALUIAVERIFY" FriendlyName="visualuiaverifynative.exe"
FileName="visualuiaverifynative.exe" MinimumFileVersion="65535.65535.65535.65535"/>
<Deny ID="ID_DENY_WFC" FriendlyName="WFC.exe" FileName="wfc.exe"
<Deny ID="ID_DENY_WINDBG" FriendlyName="windbg.exe" FileName="windbg.Exe"
<Deny ID="ID_DENY_WMIC" FriendlyName="wmic.exe" FileName="wmic.exe"
<Deny ID="ID_DENY_WSL" FriendlyName="wsl.exe" FileName="wsl.exe"
<Deny ID="ID_DENY_WSLHOST" FriendlyName="wslhost.exe" FileName="wslhost.exe"


-->
-->
-->
-->
-->
<Deny ID="ID_DENY_D_1" FriendlyName="Powershell 1" Hash="02BE82F63EE962BCD4B8303E60F806F6613759C6"/>
<Deny ID="ID_DENY_D_2" FriendlyName="Powershell 2" Hash="13765D9A16CC46B2113766822627F026A68431DF"/>
Hash="148972F670E18790D62D753E01ED8D22B351A57E45544D88ACE380FEDAF24A40"/>
<Deny ID="ID_DENY_D_4" FriendlyName="Powershell 4" Hash="29DF1D593D0D7AB365F02645E7EF4BCCA060763A"/>
<Deny ID="ID_DENY_D_5" FriendlyName="Powershell 5" Hash="2E3C47BBE1BA99842EE187F756CA616EFED61B94"/>
Hash="38DC1956313B160696A172074C6F5DA9852BF508F55AFB7FA079B98F2849AFB5"/>
<Deny ID="ID_DENY_D_7" FriendlyName="Powershell 7" Hash="513B625EA507ED9CE83E2FB2ED4F3D586C2AA379"/>
Hash="71FC552E66327EDAA72D72C362846BD80CB65EECFAE95C4D790C9A2330D95EE6"/>
Hash="72E4EC687CFE357F3E681A7500B6FF009717A2E9538956908D3B52B9C865C189"/>
Hash="74E207F539C4EAC648A5507EB158AEE9F6EA401E51808E83E73709CFA0820FDD"/>
Hash="75288A0CF0806A68D8DA721538E64038D755BBE74B52F4B63FEE5049AE868AC0"/>
<Deny ID="ID_DENY_D_12" FriendlyName="Powershell 12" Hash="7DB3AD53985C455990DD9847DE15BDB271E0C8D1"/>
Hash="84BB081141DA50B3839CD275FF34854F53AECB96CA9AEB8BCD24355C33C1E73E"/>
Hash="BD3139CE7553AC7003C96304F08EAEC2CDB2CC6A869D36D6F1E478DA02D3AA16"/>
Hash="BE3FFE10CDE8B62C3E8FD4D8198F272B6BD15364A33362BB07A0AFF6731DABA1"/>
<Deny ID="ID_DENY_D_17" FriendlyName="Powershell 17" Hash="C1196433541B87D22CE2DD19AAAF133C9C13037A"/>
Hash="C6C073A80A8E76DC13E724B5E66FE4035A19CCA0C1AF3FABBC18E5185D1B66CB"/>
<Deny ID="ID_DENY_D_19" FriendlyName="Powershell 19" Hash="CE5EA2D29F9DD3F15CF3682564B0E765ED3A8FE1"/>
<Deny ID="ID_DENY_D_20" FriendlyName="Powershell 20" Hash="D027E09D9D9828A87701288EFC91D240C0DEC2C3"/>
<Deny ID="ID_DENY_D_21" FriendlyName="Powershell 21" Hash="D2CFC8F6729E510AE5BA9BECCF37E0B49DDF5E31"/>
<Deny ID="ID_DENY_D_22" FriendlyName="Powershell 22" Hash="DED853481A176999723413685A79B36DD0F120F9"/>
<Deny ID="ID_DENY_D_23" FriendlyName="Powershell 23" Hash="DFCD10EAA2A22884E0A41C4D9E6E8DA265321870"/>
Hash="F16E605B55774CDFFDB0EB99FAFF43A40622ED2AB1C011D1195878F4B20030BC"/>
Hash="F29A958287788A6EEDE6035D49EF5CB85EEC40D214FDDE5A0C6CAA65AFC00EEC"/>
Hash="F875E43E12685ECE0BA2D42D55A13798CE9F1FFDE3CAE253D2529F4304811A52"/>

<Deny ID="ID_DENY_D_27" FriendlyName="PowerShell 27" Hash="720D826A84284E18E0003526A0CD9B7FF0C4A98A"/>
<Deny ID="ID_DENY_D_29" FriendlyName="PowerShell 29" Hash="3C7265C3393C585D32E509B2D2EC048C73AC5EE6"/>
<Deny ID="ID_DENY_D_31" FriendlyName="PowerShell 31" Hash="27D86C9B54E1A97399A6DC9C9DF9AE030CB734C8"/>
Hash="917BD10E82C6E932F9C63B9BDCCC1D9BF04510CD8491B005CFFD273B48B5CD1E"/>
<Deny ID="ID_DENY_D_33" FriendlyName="PowerShell 33" Hash="B3BB2D75AECB34ED316CE54C6D513420186E4950"/>
Hash="B734F6269A6738861E1DF98EE0E4E7377FAED10B82AAA9731DA0BB1CB366FCCE"/>
<Deny ID="ID_DENY_D_35" FriendlyName="PowerShell 35" Hash="FF378B465F2C8A87B4092F7C1F96399C0156CEEB"/>
Hash="9B884CFE78F921042B003574AE30D9E86EE3DCC11E7110A1C92927F13C3F47E6"/>
<Deny ID="ID_DENY_D_37" FriendlyName="PowerShell 37" Hash="C7B99E8B59182112A3A14BD39880BDCDDD5C724F"/>
Hash="6E585890C7369D6D8DA85C8B6B7411463BAA1ACAE9CE4197E033A46C897B35E5"/>
<Deny ID="ID_DENY_D_39" FriendlyName="PowerShell 39" Hash="BA4B3A92123FBCE66398020AFBCC0BCA1D1AAAD7"/>
<Deny ID="ID_DENY_D_41" FriendlyName="PowerShell 41" Hash="1EA5104AE1A7A53F9421E0193B749F310B9261D1"/>
Hash="66C1B8569019512ACDDC145DA6D348A68DE008BE7C05930AD0EC6927C26061AD"/>
<Deny ID="ID_DENY_D_43" FriendlyName="PowerShell 43" Hash="4EB2C3A4B551FC028E00F2E7DA9D0F1E38728571"/>
<Deny ID="ID_DENY_D_45" FriendlyName="PowerShell 45" Hash="E55505B609DD7A22F55C4BA9EDAD5627ECA6A8E8"/>
Hash="ABDDA9C1EDA9F2344FB5B79890B7FD854D0E3D28BEC26AE33AAD196948AB642D"/>
<Deny ID="ID_DENY_D_47" FriendlyName="PowerShell 47" Hash="A15964475D213FB752B42E7DCDDBF4B14D623D14"/>
<Deny ID="ID_DENY_D_49" FriendlyName="PowerShell 49" Hash="DB0C4B5CA1CBC3B117AB0439C5937B6A263DFD87"/>
Hash="6D4FB385328CA01700092E1CDF75A97123A95120D5F8A9877FFB4D5A8531380B"/>
<Deny ID="ID_DENY_D_51" FriendlyName="PowerShell 51" Hash="72F9DCDA6ECDD6906A2538DFE795A2E2CA787BBC"/>
Hash="F98FEC4A0306BD398F7FB7F611679B7797D32D54D1F2B35D728C0C7A058153ED"/>
<Deny ID="ID_DENY_D_53" FriendlyName="PowerShell 53" Hash="C980B65B86F780AC93B9458E9657291083CFEDA8"/>
Hash="F9473493FF53274B8E75EC7E517F324AA0C5644C6F8045D3EF3A1B9A669ECF78"/>
<Deny ID="ID_DENY_D_55" FriendlyName="PowerShell 55" Hash="C30355B5E6FA3F793A3CC0A649945829723DD85C"/>
<Deny ID="ID_DENY_D_57" FriendlyName="PowerShell 57" Hash="5C6CC1903D3DA2054ECD9A295EEE26F5561E152A"/>
Hash="0BF8CAB75DAB712FC848DE7CC7DC5C8A10D666515E7535F89146F45AAAF9EF54"/>
Hash="487CB42795046E885303FC96EA54C3234E1B2072DAEB4F9218C21CC6C39A3223"/>
<Deny ID="ID_DENY_D_61" FriendlyName="PowerShell 61" Hash="072D4E33D1478C863DBAB20BF5DFF1A0FB5A9D53"/>
Hash="631E091AE7AD2C543EE5755BC9D8DB34683C41E20D9A6CD41C8F07827156D6DB"/>
<Deny ID="ID_DENY_D_63" FriendlyName="PowerShell 63" Hash="FD15A313B890369B7D8E26C13B2070AE044FB4D8"/>
Hash="AB9886A0993F87C2A39BC7822EE44FD4B4751C530ACF292ACD0319C967FB4F3B"/>
<Deny ID="ID_DENY_D_65" FriendlyName="PowerShell 65" Hash="4BAFD867B59328E7BB853148FE6D16B9411D7A12"/>
<Deny ID="ID_DENY_D_67" FriendlyName="PowerShell 67" Hash="AC53AE4C8AB56D84393D67D820BEBDC3218739D3"/>
<Deny ID="ID_DENY_D_69" FriendlyName="PowerShell 69" Hash="333678A44D4BEBE9BEA3041FFDA9E2B55B58F1B5"/>
Hash="94CBBC3970F01280D98C951BD0C4158D4B09A2BE21B8A27790D9F127B78C6F3F"/>
<Deny ID="ID_DENY_D_71" FriendlyName="PowerShell 71" Hash="5F5620DC049FE1F1C2DBAC077A59BA69CF2FF72C"/>
Hash="A32C0769F36CAE0B6A7A1B8CCB6B7A75AA8BEB7F49815E96B4E120BFD7527E0A"/>
<Deny ID="ID_DENY_D_73" FriendlyName="PowerShell 73" Hash="BDBE541D269EC8235563842D024F9E37883DFB57"/>
<Deny ID="ID_DENY_D_75" FriendlyName="PowerShell 75" Hash="FD6FE9143A46F4EBB46E6B46332FA7171002EBF0"/>
Hash="85399D84601207AB92C8CA4D7D6E58CB1B0B0B57ED94FA7E5A1191FA1810E223"/>
<Deny ID="ID_DENY_D_77" FriendlyName="PowerShell 77" Hash="98FD94A89DCF92A7BEDB51C72BAD1A67650DD6E5"/>
Hash="5CE4B042E986DAFEB7E2D2ABFB80376C4DEC325DB23B584B76039EEA6E1A74B1"/>
<Deny ID="ID_DENY_D_79" FriendlyName="PowerShell 79" Hash="6BC1E70F0EA84E88AC28BEAF74C10F3ABDF99209"/>
<Deny ID="ID_DENY_D_81" FriendlyName="PowerShell 81" Hash="7FCE82DBBC0FE45AFBE3927C323349C32D5A463A"/>
Hash="2EDA8CA129E30CB5522C4DCD1E5AFDCA1E9C6447DD7053DACEF18DCDCCF3E2BC"/>
<Deny ID="ID_DENY_D_83" FriendlyName="PowerShell 83" Hash="BDB3DAC80667A0B931835D5D658C08F236B413D1"/>
<Deny ID="ID_DENY_D_85" FriendlyName="PowerShell 85" Hash="9633529CACE25ACCB29EBC5941DE1874903C0297"/>
Hash="483A3997D5DA69A51DC7EA368A36C3CA4A5BD56CB08BFD9912BE799005156C18"/>
<Deny ID="ID_DENY_D_87" FriendlyName="PowerShell 87" Hash="B3493E30A2C347B550331C86529BDC288EAF8186"/>
Hash="9371E2333906441715DE15FEE8A9AA03C4D076CA3C04D9A7AB0CC32189DA66ED"/>
<Deny ID="ID_DENY_D_89" FriendlyName="PowerShell 89" Hash="5D4B0794EB973D61CF74A700F11BE84E527E0E51"/>
Hash="537DE34A1F4B3F8345D02F5BBA2B063F070A42FC1581AAC2AA91C1D071B14521"/>
<Deny ID="ID_DENY_D_91" FriendlyName="PowerShell 91" Hash="F3C75F35F42C1C5B3B4ED888187D6AB4035F994C"/>
Hash="AD5678ED0734281973465DD728281A6C0EA146620FF2106A4EEFC7E94622B92F"/>
<Deny ID="ID_DENY_D_93" FriendlyName="PowerShell 93" Hash="91C0F76798A9679188C7D93FDEBAF797BDBE41B2"/>
Hash="1D9244EAFEDFBFC02E13822E24A476C36FFD362B9D18F6CD195B654A34F946FF"/>
<Deny ID="ID_DENY_D_95" FriendlyName="PowerShell 95" Hash="7FCB424E67DDAC49413B45D7DCD636AD70E23B41"/>
<Deny ID="ID_DENY_D_97" FriendlyName="PowerShell 97" Hash="A9745E20419EC1C90B23FE965D3C2DF028AF39DC"/>
<Deny ID="ID_DENY_D_99" FriendlyName="PowerShell 99" Hash="3E5294910C59394DA93962128968E6C23016A028"/>
<Deny ID="ID_DENY_D_101" FriendlyName="PowerShell 101" Hash="266896FD257AD8EE9FC73B3A50306A573714EA8A"/>
<Deny ID="ID_DENY_D_103" FriendlyName="PowerShell 103" Hash="2CB781B3BD79FD277D92332ACA22C04430F9D692"/>
<Deny ID="ID_DENY_D_105" FriendlyName="PowerShell 105" Hash="D82583F7D5EA477C94630AC5AAEB771C85BD4B0A"/>
<Deny ID="ID_DENY_D_107" FriendlyName="PowerShell 107" Hash="2DF4350DE3C97C9D4FD2973F8C5EA8AE621D22A8"/>
<Deny ID="ID_DENY_D_109" FriendlyName="PowerShell 109" Hash="080DEC3B15AD5AFE9BF3B0943A36285E92BAF469"/>
<Deny ID="ID_DENY_D_111" FriendlyName="PowerShell 111" Hash="F87C726CCB5E64C6F363C21255935D5FEA9E4A0E"/>
<Deny ID="ID_DENY_D_113" FriendlyName="PowerShell 113" Hash="25F52340199A0EA352C8B1A7014BCB610B232523"/>
<Deny ID="ID_DENY_D_115" FriendlyName="PowerShell 115" Hash="029198F05598109037A0E9E332EC052317E834DA"/>
<Deny ID="ID_DENY_D_117" FriendlyName="PowerShell 117" Hash="A4390EF2D77F76DC4EFE55FF74EE1D06C303FDAE"/>
<Deny ID="ID_DENY_D_119" FriendlyName="PowerShell 119" Hash="89CEAB6518DA4E7F75B3C75BC04A112D3637B737"/>
<Deny ID="ID_DENY_D_121" FriendlyName="PowerShell 121" Hash="00419E981EDC8613E600C939677F7B460855BF7E"/>
<Deny ID="ID_DENY_D_123" FriendlyName="PowerShell 123" Hash="272EF88BBA9B4B54D242FFE1E96D07DBF53497A0"/>
<Deny ID="ID_DENY_D_125" FriendlyName="PowerShell 125" Hash="CD9D9789B3B31562C4BE44B6BEEA8815C5EDAE1F"/>
<Deny ID="ID_DENY_D_127" FriendlyName="PowerShell 127" Hash="941D0FD47887035A04E17F46DE6C4004D7FD8871"/>
Hash="4AD6DC7FF0A2E776CE7F27B4E3D3C1C380CA3548DFED565429D88C3BBE61DD0F"/>
<Deny ID="ID_DENY_D_129" FriendlyName="PowerShell 129" Hash="421D1142105358B8360454E43FD15767DA111DBA"/>
<Deny ID="ID_DENY_D_131" FriendlyName="PowerShell 131" Hash="AC9F095DD4AE80B124F55541761AA1F35E49A575"/>
<Deny ID="ID_DENY_D_133" FriendlyName="PowerShell 133" Hash="B1CF2A18B281F73FE6685B5CE74D1BA50BE9AFE5"/>
<Deny ID="ID_DENY_D_135" FriendlyName="PowerShell 135" Hash="128D7D03E4B85DBF95427D72EFF833DAB5E92C33"/>
<Deny ID="ID_DENY_D_137" FriendlyName="PowerShell 137" Hash="47D2F87F2D2D516D712A156421F0C2BD285200E9"/>
Hash="8CACA1828E7770DADF21D558976D415AC7BDA16D58926308FD5E9D5087F4B0E6"/>
<Deny ID="ID_DENY_D_139" FriendlyName="PowerShell 139" Hash="CD9D70B0107801567EEADC4ECD74511A1A6FF4FE"/>
Hash="9C96396EFCC9DC09F119DE8695CB3372F82DB46D23A1B7A88BD86CBE814233E1"/>
<Deny ID="ID_DENY_D_141" FriendlyName="PowerShell 141" Hash="233E3B5108A43239C6C13292043DED0567281AF9"/>
Hash="6EDF19CC53EA2064CE108957343EB3505359CF05BD6955C7502AF565BD761702"/>
<Deny ID="ID_DENY_D_143" FriendlyName="PowerShell 143" Hash="CD725B606888E5C5426FEAB44E2CC7722DFE5411"/>
Hash="B20C4F36AE6A3AC323759C81173FACE1B1C112FA5B701C65DCD7313D7CE59907"/>
<Deny ID="ID_DENY_D_145" FriendlyName="PowerShell 145" Hash="E5212F1081B5777B88F5C41174ADEDB35B4258CF"/>
Hash="F4DE5B5395701F8C94D65D732E4D212E1879C9C84345B46A941965B094F75017"/>
<Deny ID="ID_DENY_D_147" FriendlyName="PowerShell 147" Hash="EC41A3FB8D6E3B0F55F6583C14C45B6238753019"/>
<Deny ID="ID_DENY_D_149" FriendlyName="PowerShell 149" Hash="3B2B7042A84033CA846AFE472912524F7BAD57E5"/>
Hash="2DF95ABEB23DAA0377DFA6360976B69D3CEE7325A9B7571F331D569809FAED8B"/>
<Deny ID="ID_DENY_D_151" FriendlyName="PowerShell 151" Hash="7BED2F9C0ADF1597C7EBB79163BDA21D8D7D28CA"/>
Hash="44BDD2DADB13E7A8FF6AFCF4AE3E2CC830506D9475B4C2C71D319E169977998F"/>
<Deny ID="ID_DENY_D_153" FriendlyName="PowerShell 153" Hash="A1251FA30162B13456A4687495726FF793D511BE"/>
Hash="9C15E4DE10DE47ACD393359D523211AD8596C61FE54F2C0664D48E1D249231CE"/>
<Deny ID="ID_DENY_D_155" FriendlyName="PowerShell 155" Hash="D835947C84CFBA652B553A77A90475E02291AA5F"/>
Hash="B4D6DAA10398D5DA192DFDD75010F428D24762D432934F0E2030D39610D43E12"/>
<Deny ID="ID_DENY_D_157" FriendlyName="PowerShell 157" Hash="1F85BBEC1DFC5785B91735A7C561E664F7FE1E94"/>
Hash="828F05BFF829019EC0F3082323FEA859C0D71CCE14B5B75C07E7D418EF354269"/>
<Deny ID="ID_DENY_D_159" FriendlyName="PowerShell 159" Hash="FC0E23771620B41E6920F2463F49B84307D8BA91"/>
Hash="C4FA568C852A46316308A660B80D83A11D41071F1CF4A79847A3F56714CC47AF"/>
<Deny ID="ID_DENY_D_161" FriendlyName="PowerShell 161" Hash="D18240AEE8B9B964F6B9CDFC5AFB6C343C286636"/>
Hash="7B4C39285569F14AA9799332C542A0796717C5EF9D636BD11B2841450BC6399D"/>
<Deny ID="ID_DENY_D_163" FriendlyName="PowerShell 163" Hash="1A16008D330330182AA555B1D3E9BE0B2D6BECBF"/>
<Deny ID="ID_DENY_D_165" FriendlyName="PowerShell 165" Hash="FBA274406B503B464B349805149E6AA722909CC9"/>
Hash="FEBC97ED819C79E54157895457DBA755F182D6330A5103E0663AFA07E01E5CF8"/>
<Deny ID="ID_DENY_D_167" FriendlyName="PowerShell 167" Hash="293AF426A39282770387F5EE25CA719A91419A18"/>
Hash="A9E655A96A124BC361D9CC5C7663FC033AA6F6609916EFAA76B6A6E9713A0D32"/>
<Deny ID="ID_DENY_D_169" FriendlyName="PowerShell 169" Hash="AEBFE7497F4A1947B5CB32650843CA0F85BD56D0"/>
Hash="8C385B2C16136C097C96701D2140E014BF454CFA7297BE0C28431DED15339C0F"/>
<Deny ID="ID_DENY_D_171" FriendlyName="PowerShell 171" Hash="8FB604CD72701B83BC265D87F52B36C6F14E5DBE"/>
Hash="B35AFBA7A897CB882C14A08AFB36A8EC938BDA14DF070234A2CCBDBA8F7DF91C"/>
<Deny ID="ID_DENY_D_173" FriendlyName="PowerShell 173" Hash="CE70309DB83C9202F45028EBEC252747F4936E6F"/>
Hash="1F6D74FDA1F9EE6BBAC72E7E717A01B9FFC29822561D11175F6809D12215B4ED"/>
<Deny ID="ID_DENY_D_175" FriendlyName="PowerShell 175" Hash="9D71AD914DBB2FDF793742AA63AEEF4E4A430790"/>
Hash="8CC1B5FA9A9609AC811F6505FA9B68E85A87BAE1EF676EFFE1BE438EACBDF3E1"/>
<Deny ID="ID_DENY_D_177" FriendlyName="PowerShell 177" Hash="7484FD78A9298DBA24AC5C882D16DB6146E53712"/>
Hash="A79A74BFB768312E8EE089060C5C3238D59EF0C044A450FEB97DCA26815ECB34"/>
<Deny ID="ID_DENY_D_179" FriendlyName="PowerShell 179" Hash="78C3C6AEF52A6A5392C55F1EC98AF18053B3087D"/>
Hash="493B620FCAD8A91D1FD7C726697E09358CA90822E8D6E021DF56E70B46F7C346"/>
<Deny ID="ID_DENY_D_181" FriendlyName="PowerShell 181" Hash="783FFB771F08BCF55C2EA474B5460EB65EA9444C"/>
Hash="09DA1592B8457F860297821EB7FAA7F3BB71FC1916ED5DEE6D85044953640D5C"/>
<Deny ID="ID_DENY_D_183" FriendlyName="PowerShell 183" Hash="B303D1689ED99613E4F52CE6E5F96AAEBC3A45C3"/>
Hash="82AB406FD78DCF58F65DC14D6FDDD72840015F3FE5B554428969BECA0325CD9C"/>
<Deny ID="ID_DENY_D_185" FriendlyName="PowerShell 185" Hash="DB5C6CB23C23BA6A3CD4FD4EC0A4DAEE3FC66500"/>
Hash="9A46C16C5151D97A0EFA3EA503249E31A6D5D8D25E4F07CD4E5E077A574713FB"/>
<Deny ID="ID_DENY_D_187" FriendlyName="PowerShell 187" Hash="C1E08AD32F680100C51F138C6C095139E7230C3B"/>
Hash="A5D5C1F79CD26216194D4C72DBAA3E48CB4A143D9E1F78819E52E9FEB2AD0AE3"/>
<Deny ID="ID_DENY_D_189" FriendlyName="PowerShell 189" Hash="BACA825D0852E2D8F3D92381D112B99B5DD56D9F"/>
Hash="ABA28E0FC251E1D7FE5E264E1B36EC5E482D70AA434E75A756356F23F0C1F2F4"/>
<Deny ID="ID_DENY_D_191" FriendlyName="PowerShell 191" Hash="E89C29D38F554F6CB73B5FD3D0A783CC12FFEBC3"/>
Hash="4C93CBDCF4328D27681453D8DFD7495955A07EE6A0EFB9A593853A86990CF528"/>
<Deny ID="ID_DENY_D_193" FriendlyName="PowerShell 193" Hash="5B5E7942233D7C8A325A429FC4F4AE281325E8F9"/>
Hash="40DA20086ED76A5EA5F62901D110216EE206E7EEB2F2BFF02F61D0BE85B0BB5A"/>
<Deny ID="ID_DENY_D_195" FriendlyName="PowerShell 195" Hash="926DCACC6983F85A8ABBCB5EE13F3C756705A1D5"/>
<Deny ID="ID_DENY_D_197" FriendlyName="PowerShell 197" Hash="6FE6723A355DEB4BC6B8637A634D1B43AFA64112"/>
Hash="9BCC55A97A275F7D81110877F1BB5B41F86A848EA02B4EE1E1E6A44D927A488F"/>
<Deny ID="ID_DENY_D_199" FriendlyName="PowerShell 199" Hash="8D5599B34BED4A660DACC0922F6C2F112F264758"/>
Hash="F375014915E5E027F697B29201362B56F2D9E598247C96F86ABADCC6FF42F034"/>
<Deny ID="ID_DENY_D_201" FriendlyName="PowerShell 201" Hash="CCFB247A3BCA9C64D82F647F3D30A3172E645F13"/>
Hash="5E52ABBC051368315F078D31F01B0C1B904C1DDB6D1C1E4A91BE276BDF44C66F"/>
<Deny ID="ID_DENY_D_203" FriendlyName="PowerShell 203" Hash="E8EB859531F426CC45A3CB9118F399C92054563E"/>
Hash="CD9E1D41F8D982F4AA6C610A2EFEAEBA5B0CDD883DF4A86FA0180ACD333CAA86"/>
<Deny ID="ID_DENY_D_205" FriendlyName="PowerShell 205" Hash="C92D4EAC917EE4842A437C54F96D87F003199DE8"/>
Hash="3A270242EB49E06405FD654FA4954B166297BBC886891C64B4424134C39872DB"/>
<Deny ID="ID_DENY_D_207" FriendlyName="PowerShell 207" Hash="66681D9171981216B31996429695931DA2A638B9"/>
Hash="7A2DF7D56912CB4EB5B36D071496EDC97661086B0E4C9CC5D9C61779A5A7DAAA"/>
<Deny ID="ID_DENY_D_209" FriendlyName="PowerShell 209" Hash="9DCA54C85E4C645CB296FE3055E90255B6506A95"/>
Hash="8C9C58AD12FE61CBF021634EC6A4B3094750FC002DA224423E0BCEB01ECF292A"/>
<Deny ID="ID_DENY_D_211" FriendlyName="PowerShell 211" Hash="3AF2587E8B62F88DC363D7F5308EE4C1A6147338"/>
Hash="D32D88F158FD341E32708CCADD48C426D227D0EC8465FF4304C7B7EAC2C6A93E"/>
<Deny ID="ID_DENY_D_213" FriendlyName="PowerShell 213" Hash="D3D453EBC368DF7CC2200474035E5898B58D93F1"/>
Hash="BBE569BCC282B3AF682C1528D4E3BC53C1A0C6B5905FA34ADB4305160967B64A"/>
<Deny ID="ID_DENY_D_215" FriendlyName="PowerShell 215" Hash="D147CE5C7E7037D1BE3C0AF67EDB6F528C77DB0A"/>
Hash="11F936112832738AD9B3A1C67537D5542DE8E86856CF2A5893C4D26CF3A2C558"/>
<Deny ID="ID_DENY_D_217" FriendlyName="PowerShell 217" Hash="7DBB41B87FAA887DE456C8E6A72E09D2839FA1E7"/>
Hash="3741F3D2F264E047339C95A66085599A49766DEF1C5BD0C32237CE87FA0B41FB"/>
<Deny ID="ID_DENY_D_219" FriendlyName="PowerShell 219" Hash="5F3AECC89BAF094EAFA3C25E6B883EE68A6F00B0"/>
Hash="AA085BE6498D2E3F527F3D72A5D1C604508133F0CDC05AD404BB49E8E3FB1A1B"/>
<Deny ID="ID_DENY_D_221" FriendlyName="PowerShell 221" Hash="DDE4D9A08514347CDE706C42920F43523FC74DEA"/>
Hash="81835C6294B96282A4D7D70383BBF797C2E4E7CEF99648F85DDA50F7F41B02F6"/>
<Deny ID="ID_DENY_D_223" FriendlyName="PowerShell 223" Hash="48092864C96C4BF9B68B5006EAEDAB8B57B3738C"/>
Hash="36EF3BED9A5D0D563BCB354BFDD2931F6256759D1D905BA5DC21CDA496F2FEB7"/>
<Deny ID="ID_DENY_D_225" FriendlyName="PowerShell 225" Hash="7F6725BA8CCD2DAEEFD0C9590A5DF9D98642CCEA"/>
Hash="DB68DB3AE32A8A662AA6EE16CF459124D2701719D019B614CE9BF115F5F9C904"/>
<Deny ID="ID_DENY_D_227" FriendlyName="PowerShell 227" Hash="FF205856A3209227D571EAD4B8C1E611E7FF9924"/>
<Deny ID="ID_DENY_D_229" FriendlyName="PowerShell 229" Hash="479C9429691314D3E21E4F4CA8B95D5BD2BDDEDA"/>
<Deny ID="ID_DENY_D_231" FriendlyName="PowerShell 231" Hash="C7D70B96440D215173F35412D56CF9329886D8D3"/>
<Deny ID="ID_DENY_D_233" FriendlyName="PowerShell 233" Hash="2AB804E1FF982AE0EDB591BC61AA909CF32E99C5"/>
<Deny ID="ID_DENY_D_235" FriendlyName="PowerShell 235" Hash="8DAB1D74CAEDBAA8D17805CF00D64A44F5831C12"/>
<Deny ID="ID_DENY_D_237" FriendlyName="PowerShell 237" Hash="993425279D204D1D14C3EB989DEB4805ADC558CF"/>
<Deny ID="ID_DENY_D_239" FriendlyName="PowerShell 239" Hash="F4DB0CDF3A3FD163A9B90789CC6D14D326AD609C"/>
<Deny ID="ID_DENY_D_241" FriendlyName="PowerShell 241" Hash="5B8E45EECA32C2F0968C2252229D768B0DB796A0"/>
<Deny ID="ID_DENY_D_243" FriendlyName="PowerShell 243" Hash="4F5D66B449C4D2FDEA532F9B5DBECA5ACA8195EF"/>
<Deny ID="ID_DENY_D_245" FriendlyName="PowerShell 245" Hash="4BFB3F95CA1B79DA3C6B0A2ECB432059E686F967"/>
<Deny ID="ID_DENY_D_247" FriendlyName="PowerShell 247" Hash="6DC048AFA50B5B1B0AD7DD3125AC83D46FED730A"/>
Hash="2B45C165F5E0BFD932397B18980BA680E2E82BD1"/>
Hash="1DD0AD6B85DAEBAE7555DC37EA6C160EA38F75E3D4847176F77562A59025660A"/>
Hash="A8C9E28F25C9C5F479691F2F49339F4448747638"/>
Hash="F8FA17038CD532BF5D0D6D3AC55CE34E45EB690637D38D399CAB14B09807EB6C"/>
Hash="4BAFD867B59328E7BB853148FE6D16B9411D7A12"/>
Hash="3BA0605C08935B340BEFDC83C0D92B1CE52B8348"/>
Hash="B794B01CE561F2791D4ED3EADE523D03D2BE7B4CEFE9AAFC685ECE8ACF515ED2"/>
Hash="8B74A22710A532A71532E4F0B1C60AABDCAA29AB"/>
Hash="EB335007DF9897BCD2ED5C647BA724F07658E8597E73E353479201000CF2EF79"/>
Hash="10E2CD3A2CFA0549590F740139F464626DEE2092"/>
Hash="61DEC96B91F3F152DFDA84B28EBB184808A21C4C183CC0584C66AC7E20F0DDB6"/>
Hash="98E84F46B3EB3AD7420C9715722145AFB0C065A7"/>
Hash="67398990D42DFF84F8BE33B486BF492EBAF61671820BB9DCF039D1F8738EC5A4"/>
Hash="58F399EC75708720E722FBD038F0EC089BF5A8C0"/>
Hash="C523FFF884C44251337470870E0B158230961845FC1E953F877D515668524F2E"/>
Hash="41EE8E9559FC0E772FC26EBA87ED4D77E60DC76C"/>
Hash="219AD97976987C614B00C0CD1229B4245F2F1453F5AF90B907664D0BF6ADFE78"/>
Hash="7F7E646892FCEB8D6A19647F00C1153014955C45"/>
Hash="5825FF16398F12B4999B9A12849A757DD0884F9908220FB33E720F170DA288D5"/>
Hash="7EA8A590583008446583F0AE7D66537FAD63619D"/>
Hash="26DD094717B15B3D39600D909A9CAEBCF5C616C6277933BCC01326E8C475A128"/>
Hash="5F6CDF52C1E184B080B89EB234DE179C19F110BA"/>
Hash="41FB90606E3C66D21C703D84C943F8CB35772030B689D9A9895CB3EF7C863FB2"/>
Hash="91C1DACBD6773BFC7F9305418A6683B8311949CF"/>
Hash="EB678387D01938D88E6F2F46712269D54D845EB6A8AAC3FCA256DC2160D42975"/>
Hash="A05294D23A4A7DC91692013C0EC4373598A28B21"/>
Hash="ABEEA4903403D2C07489436E59955ECFEEF893C63D1FDBED234343F6A6D472B1"/>
Hash="B155C278617845EC6318E4009E4CED6639FAB951"/>
Hash="465D848F11CECE4452E831D248D326360B73A319"/>
Hash="B9C9F208C6E50AABF91D234227D09D7C6CAB2FDB229163103E7C1F541F71C213"/>
Hash="F0B9D75B53A268C0AC30584738C3A5EC33420A2E"/>
Hash="365A7812DFC448B1FE9CEA83CF55BC62189C4E72BAD84276BD5F1DAB47CB3EFF"/>
Hash="8ADCDD18EB178B6A43CF5E11EC73212C90B91988"/>
Hash="51BD119BE2FBEFEC560F618DBBBB8203A251F455B1DF825F37B1DFFDBE120DF2"/>
Hash="D2011097B6038D8507B26B7618FF07DA0FF01234"/>
Hash="BA3D20A577F355612E53428D573767C48A091AE965FCB30CC348619F1CB85A02"/>
Hash="57ABBC8E2FE88E04C57CDDD13D58C9CE03455D25"/>
Hash="0280C4714BC806BFC1863BE9E84D38F203942DD35C6AF2EB96958FD011E4D23D"/>
Hash="DEB07053D6059B56109DFF885720D5721EB0F55C"/>
Hash="E374A14871C35DB57D6D67281C16F5F9EF77ABE248DE92C1A937C6526133FA36"/>
Hash="AC33BA432B35A662E2D9D015D6283308FD046251"/>
Hash="93B22B0D5369327247DF491AABD3CE78421D0D68FE8A3931E0CDDF5F858D3AA7"/>
Hash="05126413310F4A1BA2F7D2AD3305E2E3B6A1B00D"/>
Hash="108A73F4AE78786C9955ED71EFD916465A36175F8DC85FD82DDA6410FBFCDB52"/>
Hash="B976F316FB5EE6E5A325320E7EE5FBF487DA9CE5"/>
Hash="D54CCD405D3E904CAECA3A6F7BE1737A9ACE20F7593D0F6192B811EF17744DD6"/>
Hash="F3471DBF534995307AEA230D228BADFDCA9E4021"/>
Hash="2048F33CCD924D224154307C28DDC6AC1C35A1859F118AB2B6536FB954FC44EF"/>
Hash="1FAC9087885C2FEBD7F57CC9AACE8AF94294C8FB"/>
Hash="942E0D0BA5ECBF64A3B2D0EA1E08C793712A4C89BC1BC3B6C32A419AE38FACC1"/>
Hash="5B67EE19AA7E4B42E58127A63520D44A0679C6CE"/>
Hash="2B6A59053953737D345B97FA1AFB23C379809D1532BAF31E710E48ED7FA2D735"/>
Hash="1ABC67650B169E7C437853922805706D488EEEA2"/>
Hash="754CA97A95464F1A1687C83AE3ECC6670B80A50503067DEBF6135077C886BCF4"/>
Hash="0E280FF775F406836985ECA66BAA9BA17D12E38B"/>
Hash="19C9A6D1AE90AEA163E35930FAB1B57D3EC78CA5FE192D6E510CED2DAB5DD03B"/>
Hash="4E6081C3BBB2809C417E2D03412E29FF7317DA54"/>
Hash="3AE4505A552EA04C7664C610E81172CA329981BF53ECC6758C03357EB653F5D1"/>
Hash="61BED1C7CD54B2F60923D26CD2F6E48C063AFED5"/>
Hash="9405CBE91B7519290F90577DCCF5796C514746DE6390322C1624BA258D284EE9"/>
Hash="63AA55C3B46EFAFC8625F8D5562AB504E4CBB78F"/>
Hash="FF54885D30A13008D60F6D0B96CE802209C89A2A7D9D86A85804E66B6DE29A5D"/>
Hash="20845E4440DA2D9AB3559D4B6890691CACD0E93E"/>
Hash="3C9098C4BFD818CE8CFA130F6E6C90876B97D57ABBEAFABB565C487F1DD33ECC"/>
Hash="4A473F14012EB9BF7DCEA80B86C2612A6D9D914E"/>
Hash="1C6914B58F70A9860F67311C32258CD9072A367BF30203DA9D8C48188D888E65"/>
Hash="641871FD5D9875DB75BFC58B7B53672D2C645F01"/>
Hash="C115A974DD2C56574E93A4800247A23B98B9495F6EF41460D1EC139266A2484D"/>
Hash="A21E254C18D3D53B832AD381FF58B36E6737FFB6"/>
Hash="D214AF2AD9204118EB670D08D80D4CB9FFD74A978726240360C35AD5A57F8E7D"/>
Hash="102B072F29122BC3A89B924987A7BF1AC3C598DB"/>
Hash="DA444773FE7AD8309FA9A0ABCDD63B302E6FC91E750903843FBA2A7F370DB0C0"/>
Hash="EAD58EBB00001E678B9698A209308CC7406E1BCC"/>
Hash="34A5F48629F9FDAEBAB9468EF7F1683EFA856AAD32E3C0CC0F92B5641D722EDC"/>
Hash="727EDB00C15DC5D3C14368D88023FDD5A74C0B06"/>
Hash="5720BEE5CBE7D724B67E07C53E22FB869F8F9B1EB95C4F71D61D240A1ED8D8AD"/>
Hash="A43137EC82721A81C3E05DC5DE74F0549DE6A130"/>
Hash="1731118D97F278C18E2C6922A016DA7C55970C6C4C5441710D1B0464EED6EAEB"/>
Hash="17EC94CB9BF98E605F9352987CA33DCE8F5733CD"/>
Hash="AFE0CC143108BBDBE60771B6894406785C471BA5730F06EE8185D0A71617B583"/>
Hash="F6E9C098737F0905E53B92D4AD49C199EC76D24B"/>
Hash="50A57BFCD20380DDEFD2A717D7937D49380D4D5931CC6CC403C904139546CB1D"/>
Hash="2118ACC512464EE95946F064560C15C58341B80C"/>
Hash="005990EE785C1CA7EAEC82DA29F5B363049DC117A18823D83C10B86B5E8D0A5F"/>
Hash="54FAE3A389FDD2F5C21293D2317E87766AF0473D"/>
Hash="70F4E503D7484DF5B5F73D9A753E585BFADB8B8EBA42EB482B6A66DB17C87881"/>
Hash="B4831AF4B25527EF0C172DAA5E4CA26DE105D30B"/>
Hash="D410A37042A2DC53AD1801EBB2EF507B4AE475870522A298567B79DA61C3E9C8"/>
Hash="85BBC0CDC34BD5A56113B0DCB6795BCEBADE63FA"/>
Hash="C6F8E3A3F2C513CEDD2F21D486BF0116BAF2E2EE4D631A9BE4760860B1161848"/>
Hash="46105ACE7ABEC3A6E6226183F2F7F8E90E3639A5"/>
Hash="F60BE088F226CA1E2308099C3B1C2A54DB4C41D2BE678504D03547B9E1E023F6"/>
Hash="C9478352ACE4BE6D6B70BBE710C2E2128FEFC7FE"/>
Hash="F4A81E7D4BD3B8762FAED760047877E06E40EC991D968BD6A6929B848804C1A4"/>
Hash="9E56E910919FF65BCCF5D60A8F9D3EBE27EF1381"/>
Hash="34887B225444A18158B632CAEA4FEF6E7D691FEA3E36C12D4152AFAB260668EB"/>
Hash="1FD04D4BD5F9E41FA8278F3F9B05FE8702ADB4C8"/>
Hash="6586176AEBE8307829A1E03D878EF6F500E8C5032E50198DF66F54D3B56EA718"/>
Hash="DEBC3DE2AD99FC5E885A358A6994E6BD39DABCB0"/>
Hash="FDF54A4A3089062FFFA4A41FEBF38F0ABC9D502B57749348DF6E78EA2A33DDEA"/>
Hash="6AA06D07D9DE8FE7E13B66EDFA07232B56F7E21D"/>
Hash="DD3E74CFB8ED64FA5BE9136C305584CD2E529D92B360651DD06A6DC629E23449"/>
Hash="5C858042246FDDDB281C1BFD2FEFC9BAABC3F7AD"/>
Hash="20E65B1BE06A99507412FC0E75D158EE1D9D43AE5F492BE4A87E3AA29A148310"/>
Hash="2ABCD0525D31D4BB2D0131364FBE1D94A02A3E2A"/>
Hash="806EC87F1EFA428627989318C882CD695F55F60A1E865C621C9F2B14E4E1FC2E"/>
Hash="E2967D755D0F79FA8EA7A8585106926CA87F89CB"/>
Hash="07382BE9D8ACBAFDA953C842BAAE600A82A69183D6B63F91B061671C4AF9434B"/>
Hash="75EF6F0B78098FB1766DCC853E004476033499CF"/>
Hash="699A9D17E1247F05767E82BFAFBD96DBE07AE521E23D39613D4A39C3F8CF4971"/>
Hash="E73178C487AF6B9F182B2CCA25774127B0303093"/>
Hash="0BD1FE62BE97032ADDAAB41B445D00103302D3CE8A03A798A36FEAA0F89939FF"/>
Hash="EBF20FEECA95F83B9F5C22B97EB44DD7EB2C7B5F"/>
Hash="B5AE0EAA5AF4245AD9B37C8C1FC5220081B92A13950C54D82E824D2D3B840A7C"/>
Hash="5E53A4235DC549D0195A9DDF607288CEDE7BF115"/>
Hash="FE57195757977E4485BF5E5D72A24EA65E33F8EAA7245381453960D5646FAF58"/>
Hash="014BC30E1FC12F270824F01DC7C934497A573124"/>
Hash="65B3B357C356DAE26E5B036820C193989C0F9E8E08131B3186F9443FF9A511E4"/>
Hash="128D7D03E4B85DBF95427D72EFF833DAB5E92C33"/>
Hash="C7D70B96440D215173F35412D56CF9329886D8D3"/>
Hash="8287B536E8E63F024DE1248D0FE3E6A759E9ACEE"/>
Hash="B714D4A700A56BC1D4B3F59DFC1F5835CB97CBEF3927523BF71AF96B00F0FFA4"/>
Hash="6BC1E70F0EA84E88AC28BEAF74C10F3ABDF99209"/>
Hash="AC9F095DD4AE80B124F55541761AA1F35E49A575"/>
Hash="3C7265C3393C585D32E509B2D2EC048C73AC5EE6"/>
Hash="89CEAB6518DA4E7F75B3C75BC04A112D3637B737"/>
Hash="4BFB3F95CA1B79DA3C6B0A2ECB432059E686F967"/>
Hash="BDBE541D269EC8235563842D024F9E37883DFB57"/>
Hash="BDB3DAC80667A0B931835D5D658C08F236B413D1"/>
Hash="EA157E01147629D1F59503D8335FB6EBC688B2C1"/>
Hash="14C160DF95736EC1D7C6C55B9D0F81832E8FE0DB6C5931B23E45A559995A1000"/>
Hash="272EF88BBA9B4B54D242FFE1E96D07DBF53497A0"/>
Hash="029198F05598109037A0E9E332EC052317E834DA"/>
Hash="5B8E45EECA32C2F0968C2252229D768B0DB796A0"/>
Hash="6792915D3C837A39BD04AD169488009BB1EA372C"/>
Hash="23B10EC5FC7EAEB9F8D147163463299328FAED4B973BB862ECD3F28D6794DA9D"/>
Hash="EC41A3FB8D6E3B0F55F6583C14C45B6238753019"/>
Hash="A15964475D213FB752B42E7DCDDBF4B14D623D14"/>
Hash="24F9CF6C5E9671A295AD0DEED74737FB6E9146DE"/>
Hash="C2E862CC578F54A53496EEE2DCB534A106AFD55C7288362AF6499B45F8D8755E"/>
Hash="F87C726CCB5E64C6F363C21255935D5FEA9E4A0E"/>
Hash="4EB2C3A4B551FC028E00F2E7DA9D0F1E38728571"/>
Hash="2DF4350DE3C97C9D4FD2973F8C5EA8AE621D22A8"/>
Hash="993425279D204D1D14C3EB989DEB4805ADC558CF"/>
Hash="1A16008D330330182AA555B1D3E9BE0B2D6BECBF"/>
Hash="2CB781B3BD79FD277D92332ACA22C04430F9D692"/>
Hash="BA4B3A92123FBCE66398020AFBCC0BCA1D1AAAD7"/>
Hash="D5A9460A941FB5B49EAFDD57575CFB23F27779D3"/>
Hash="4BDAAC1654328E4D37B6ED89DA351155438E558F51458F2129AFFAC5B596CD61"/>
Hash="3E5294910C59394DA93962128968E6C23016A028"/>
Hash="C30355B5E6FA3F793A3CC0A649945829723DD85C"/>
Hash="C647D17850941CFB5B9C8AF49A48569B52230274"/>
Hash="0BCBDE8791E3D6D7A7C8FC6F25E14383014E6B43D9720A04AF0BD4BDC37F79E0"/>
Hash="CA6E0BAB6B28E1592D0FC5940023C7A81E2568F8"/>
Hash="366E00E2F517D4D404133AEFEF6F917DFA156E3E46D350A8CBBE59BE1FB877A2"/>
Hash="7D9FFFA86DDCD227A3B4863D995456308BAC2403"/>
Hash="4439BBF61DC012AFC8190199AF5722C3AE26F365DEE618D0D945D75FD1AABF3C"/>
Hash="8FFDD4576F2B6D4999326CFAF67727BFB471FA21"/>
Hash="94630AB6F60A7193A6E27E312AF9B71DA265D42AD49465F4EEA11EBF134BA54A"/>
Hash="78B8454F78E216B629E43B4E40765F73BFE0D6C6"/>
Hash="498BB1688410EE243D61FB5C7B37457FA6C0A9A32D136AF70FAD43D5F37D7A81"/>
Hash="B1CF2A18B281F73FE6685B5CE74D1BA50BE9AFE5"/>
Hash="8AF579DE1D7E590A13BD1DAE5BFDB39476068A05"/>
Hash="9917A3055D194F47AB295FA3F917E4BD2F08DDF45C04C65C591A020E1507A573"/>
Hash="DD64046BAB221CF4110FF230FA5060310A4D9610"/>
Hash="A55AF37229D7E249C8CAFED3432E595AA77FAF8B62990C07938220E957679081"/>
Hash="421D1142105358B8360454E43FD15767DA111DBA"/>
Hash="720D826A84284E18E0003526A0CD9B7FF0C4A98A"/>
Hash="2F587293F16DFCD06F3BF8B8348FF68827ECD307"/>
Hash="B2F4A5FE21D5961F464CAB3E88C0ED88154B0C1A422629474AD5C9EDC11880B6"/>
Hash="6DC048AFA50B5B1B0AD7DD3125AC83D46FED730A"/>
Hash="CD9D9789B3B31562C4BE44B6BEEA8815C5EDAE1F"/>
Hash="4F5D66B449C4D2FDEA532F9B5DBECA5ACA8195EF"/>
Hash="A4390EF2D77F76DC4EFE55FF74EE1D06C303FDAE"/>
Hash="E180486F0CC90AF4FB8283ADCF571884894513C8"/>
Hash="3800E38275E6BB3B4645CDAD14CD756239BB9A87EF261DC1B68072B6DB2850C0"/>
Hash="AC53AE4C8AB56D84393D67D820BEBDC3218739D3"/>
Hash="00419E981EDC8613E600C939677F7B460855BF7E"/>
Hash="25F52340199A0EA352C8B1A7014BCB610B232523"/>
Hash="F4DB0CDF3A3FD163A9B90789CC6D14D326AD609C"/>
Hash="231A02EAB7EB192638BC89AB61A5077346FF22B9"/>
Hash="4D544170DE5D9916678EA43A7C6F796FC02EFA9197C6E0C01A1D832BF554F748"/>
Hash="A9745E20419EC1C90B23FE965D3C2DF028AF39DC"/>
Hash="15EF1F7DBC474732E122A0147640ACBD9DA1775C"/>
Hash="04724BF232D5F169FBB0DB6821E35D772619FB4F24069BE0EC571BA622ACC4D2"/>
Hash="7959AB2B34A5F490AD54782D135BF155592DF13F"/>
Hash="DD03CD6B5655B4EB9DD259F26E1585389804C23DB39C10122B6BC0E8886B4C2A"/>
Hash="CCA8C8FB699496BD50AE296B20CC9ADC3496DECE"/>
Hash="75E6C2DD81FE2664DF466C9C2EB0F923B0C6D992FF653B673793A896D8860957"/>
Hash="080DEC3B15AD5AFE9BF3B0943A36285E92BAF469"/>
Hash="B3B7A653DD1A10EE9A3D35C818D227E2E3C3B5FB"/>
Hash="43E2D91C0C6A8473BE178F1793E5E34966D700F71362297ECF4B5D46239603E3"/>
Hash="D82583F7D5EA477C94630AC5AAEB771C85BD4B0A"/>
Hash="AAE22FD137E8B7217222974DCE60B9AD4AF2A512"/>
Hash="DAC9E963A3897D7F7AB2B4FEBBD4894A15441246639CE3E8EE74B0228F312742"/>
Hash="8DAB1D74CAEDBAA8D17805CF00D64A44F5831C12"/>
Hash="266896FD257AD8EE9FC73B3A50306A573714EA8A"/>
Hash="2AB804E1FF982AE0EDB591BC61AA909CF32E99C5"/>
Hash="25CA971D7EDFAA7A48FA19B8399301853809D7CC"/>
Hash="0A10C71CB5CC8A801F84F2CCD8041D13DB55711435388D9500C53D122688D4E5"/>
Hash="46E05FD4D62451C1DCB0287B32B3D77AD41544EA"/>
Hash="D86F930445F0715D0D7E4C3B089399280FBA2ACE0E4125BA5D3DAB9FAC1A6D3A"/>
Hash="479C9429691314D3E21E4F4CA8B95D5BD2BDDEDA"/>
Hash="FF205856A3209227D571EAD4B8C1E611E7FF9924"/>
Hash="7FCB424E67DDAC49413B45D7DCD636AD70E23B41"/>
Hash="46936F4F0AFE4C87D2E55595F74DDDFFC9AD94EE"/>
Hash="9843DC862BC7491A279A09EFD8FF122EB23C57CA"/>
Hash="11F11FB1E57F299383A615D6A28436E02A1C1A83"/>
Hash="C593ABE79DFFB1504CFCDB1A6AD65D24996E7B97"/>
Hash="93E22F2BA6C8B1C09F100F9C0E3B06FAF2D1DDB6"/>
Hash="5A8D9712CF7893C335FFB7414748625D524227FE"/>
Hash="B5FFFEE20F25691A59F3894644AEF088B4845761"/>
Hash="3334059FF4484C43A5D08CEC3E43E2D27EDB927B"/>
Hash="00B6993F59990C3DFEA33584BDB050F91313B17A"/>
Hash="7518F60A0B33011D19873908559961F96A9B4FC0"/>
Hash="A1D1AF7675C2596D0DF977F57B54372298A56EE0F3E1FF2D974D387D7F69DD4E"/>
Hash="3C1743CBC43B80F5AF5B17239B03A8727B4BE81F14052BDE37685E2D54214071"/>
Hash="C7DC8B00F0BDA000D1F3CF0FBC7AB32D443C377C0130BB5153A0390E712DDDE5"/>
Hash="ED5A4747C8AEEB1AC2F4FDB8EB0B9BFC240F2B3C00BF7C6CDB372BFFEC0F8ABE"/>
Hash="939C291D4A2592209EC7664EC832670FA0AC1009F974F47489D866751F4B862F"/>
Hash="497A2D4207B2AE6EF09424591624A86A64A2C8E451389ED9A3256E6274556A7B"/>
Hash="732BC385B191C8436B42CD1441DC234FFDD5EC1BD18A32894F093EECA3DD8FBC"/>
Hash="CBD19FDB6338DB02299A3F3FFBBEBF216B18013B3377D1D31E51491C0C5F074C"/>
Hash="3A316A0A470744EB7D18339B76E786564D1E96130766A9895B2222C4066CE820"/>
Hash="68A4A1E8F4E1B903408ECD24608659B390B9E7154EB380D94ADE7FEB5EA470E7"/>
Hash="45F948AF27F4E698A8546027717901B5F70368EE"/>
Hash="45F948AF27F4E698A8546027717901B5F70368EE"/>
Hash="2D63C337961C6CF2660C5DB906D9070CA38BCE828584874680EC4F5097B82E30"/>
Hash="DA4CD4B0158B774CE55721718F77ED91E3A42EB3"/>
Hash="7D181BB7A4A0755FF687CCE34949FC6BD6FBC377E6D4883698E8B45DCCBEA140"/>
Hash="C67D7B12BBFFD5FBD15FBD892955EA48E6F4B408"/>
Hash="1DCAD0BBCC036B85875CC0BAF1B65027933624C1A29BE336C79BCDB00FD5467A"/>
Hash="7D8CAB8D9663926E29CB810B42C5152E8A1E947E"/>
Hash="2E0203370E6E5437CE2CE1C20895919F806B4E5FEBCBE31F16CB06FC5934F010"/>
Hash="20E7156E348912C20D35BD4BE2D52C996BF5535E"/>
Hash="EB26078544BDAA34733AA660A1A2ADE98523DAFD9D58B3995919C0E524F2FFC3"/>
Hash="B9DD16FC0D02EA34613B086307C9DBEAC30546AF"/>
Hash="DE5B012C4DC3FE3DD432AF9339C36EFB8D54E8864493EA2BA151F0ADBF3E338C"/>
Hash="6397AB5D664CDB84A867BC7E22ED0789060C6276"/>
Hash="B660F6CA0788DA18375602537095C378990E8229B11B57B092AC8A550E9C61E8"/>
Hash="3BF717645AC3986AAD0B4EA9D196B18D05199DA9"/>
Hash="364C227F9E57C72F9BFA652B8C1DE738AB4747D0DB68A7B899CA3EE51D802439"/>
Hash="3A1B06680F119C03C60D12BAC682853ABE430D21"/>
Hash="850759BCE4B66997CF84E84683A2C1980D4B498821A8AB9C3568EB298B824AE3"/>
Hash="654C54AA3F2C74FBEB55B961FB1924A7B2737E61"/>
Hash="B7EA81960C6EECFD2FF385890F158F5B1CB3D1E100C7157AB161B3D23DCA0389"/>
Hash="496F793112B6BCF4B6EA16E8B2F8C3F5C1FEEB52"/>
Hash="E430485B577774825CEF53E5125B618A2608F7BE3657BB28383E9A34FCA162FA"/>
Hash="6EA8CEEA0D2879989854E8C86CECA26EF79F7B19"/>
Hash="8838FE3D8E2505F3D3D8B98C64739115838A0B443BBBBFB487342F1EE7801360"/>
Hash="28C5E53DE197E872F7E4772BF40F728F56FE3ACC"/>
Hash="3493DAEC6EC03E56ECC4A15432C750735F75F9CB38D8779C7783B4DA956BF037"/>
Hash="DBB5A6F5388C574A3B5B63E65F7810AB271E9A77"/>
Hash="6DB24D174CCF06C9138B5A9320AE4261CA0CF305357DEF1B7054DD84758E92AB"/>
Hash="757626CF5D444F5A4AF79EDE38E9EF65FA2C9802"/>
Hash="1E17D036EBB5E82BF2FD5BDC3ABAB08B5EA9E4504D989D2BAAAA0B6047988996"/>
Hash="2965DC840B8F5F7ED2AEC979F21EADA664E3CB70"/>
Hash="5449560095D020687C268BD34D9425E7A2739E1B9BFBC0886142519293E02B9D"/>
Hash="BB47C1251866F87723A7EDEC9A01D3B955BAB846"/>
Hash="B05F3BE23DE6AE2557D6661C6FE35E114E8A69B326A3C855023B7AC5CE9FC31B"/>
Hash="2F3D30827E02D5FEF051E54C74ECA6AD4CC4BAD2"/>
Hash="F074589A1FAA76A751B05AD61B968683134F3FFC10DE3077FBCEE4E263EAEB0D"/>
Hash="10096BD0A359142A13F2B8023A341C79A4A97975"/>
Hash="A271D72CDE48F69EB694B753BF9417CD6A72F7DA06C52E47BAB40EC2BD9DD819"/>
Hash="F8E803E1623BA66EA2EE0751A648834130B8BE5D"/>
Hash="E70DB033B773FE01B1D4464CAC112AF41C09E75D25FEA25AE8DAE67ED941E797"/>
Hash="665BE52329F9CECEC1CD548A1B4924C9B1F79BD8"/>
Hash="24CC5B946D9469A39CF892DD4E92117E0E144DC7C6FAA65E71643DEAB87B2A91"/>
Hash="C4627F2CF69A8575D7BF7065ADF5354D96707DFD"/>
Hash="7F1DF759C050E0EF4F9F96FF43904B418C674D4830FE61818B60CC68629F5ABA"/>
Hash="4126DD5947E63DB50AD5C135AC39856B6ED4BF33"/>
Hash="B38E1198F82E7C2B3123984C017417F2A48BDFF5B6DBAD20B2438D7B65F6E39F"/>
Hash="DE16A6B93178B6C6FC33FBF3E9A86CFF070DA6D3"/>
Hash="A3EF9A95D1E859958DEBE44C033B4562EBB9B4C6E32005CA5C07B2E07A42E2BE"/>


<Deny ID="ID_DENY_D_249" FriendlyName="PubPrn 249" Hash="68E96BE23748AA680D5E1E557778901F332ED5D3"/>
Hash="8FA30B5931806565C2058E565C06AD5F1C5A48CDBE609975EB31207C25214063"/>

<Deny ID="ID_DENY_D_251" FriendlyName="PubPrn 251" Hash="32C4B29FE428B1DF473F3F4FECF519D285E93521"/>
Hash="D44FB563198D60DFDC91608949FE2FADAD6161854D084EB1968C558AA36513C7"/>

<Deny ID="ID_DENY_D_253" FriendlyName="PubPrn 253" Hash="9EDBEF086D350863F29175F5AB5178B88B142C75"/>
Hash="9B22C98351F2B6DEDDCED0D805C65F5B166FF519A8DF41EB242CB909471892EB"/>

<Deny ID="ID_DENY_D_255" FriendlyName="PubPrn 255" Hash="8A3B30F345C43246B3500721CFEEADBAC6B9D9C6"/>
Hash="37C20BF20A2BBACE50957F8D0AB3FD16174BC005E79D47E51E899AFD9E4B7724"/>

<Deny ID="ID_DENY_D_257" FriendlyName="PubPrn 257" Hash="C659DAD2B37375781E2D584E16AAE2A10B5A1156"/>
<Deny ID="ID_DENY_D_258" FriendlyName="PubPRn 258"
Hash="EBDACA86F10AC0446D60CC75628EC7A370B1E2236E6D20F22372F91033B6D429"/>









<Deny ID="ID_DENY_D_275" FriendlyName="PubPrn 275" Hash="663D8E25BAE20510A882F6692BE2620FBABFB94E"/>
Hash="649A9E5A4867A28C7D0934793F33B545F9441EA23872715C84826D80CC8EC576"/>

<Deny ID="ID_DENY_D_277" FriendlyName="PubPrn 277" Hash="226ABB2FBAEFC5A7E2A819D9D708F826C00FD215"/>
Hash="AC6B35C904D388FD12C07C2F6A1A07F337D31895713BF01DCCE7A7F187D7F4D9"/>

<Deny ID="ID_DENY_D_279" FriendlyName="PubPrn 279" Hash="071D7849941E43144839988971255FE34690A747"/>
Hash="5AF75895BDC11A6B68C816A8677D7CF9692BF25A95C4378A43FBDE740B18EEB1"/>

<Deny ID="ID_DENY_D_281" FriendlyName="PubPrn 281" Hash="9FBFF074C201BFEBE37710CB453EFF9A14AE3BFF"/>
Hash="A0C71A925850D2D481C7E520F5D5A83305EC169EEA4C5B8DC20C8D8AFCD8A512"/>


Hash="4FBC9A72C5D5246F34994F13076A5AD98A1A844E"/>
Hash="7BF44433D3A606104778F64B11B92C52FC99C4BA570C50B70438275D0B587B8E"/>

Hash="99382ED8FA3577DFD903C01478A79D6D90681406"/>
Hash="C3A5DAB20947CA8FD092E75C25177E7BAE7884CA58710F14827144C09EA1F94B"/>

<Deny ID="ID_DENY_D_583" FriendlyName="Winrm 583" Hash="3FA2D2963CBF47FFD5F7F5A9B4576F34ED42E552"/>
<Deny ID="ID_DENY_D_584" FriendlyName="Winrm 584"
Hash="6C96E976DC47E0C99B77814E560E0DC63161C463C75FA15B7A7CA83C11720E82"/>
</FileRules>

-->
<Signers />

<SigningScenarios>
<SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_DRIVERS_1" FriendlyName="Driver Signing Scenarios">
<ProductSigners>
<FileRulesRef>
<FileRuleRef RuleID="ID_DENY_KD_KMCI"/>
</FileRulesRef>
</ProductSigners>
</SigningScenario>
<SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_WINDOWS" FriendlyName="User Mode Signing Scenarios">
<ProductSigners>
<FileRulesRef>
<FileRuleRef RuleID="ID_DENY_ADDINPROCESS"/>
<FileRuleRef RuleID="ID_DENY_ADDINPROCESS32"/>
<FileRuleRef RuleID="ID_DENY_ADDINUTIL"/>
<FileRuleRef RuleID="ID_DENY_ASPNET"/>
<FileRuleRef RuleID="ID_DENY_BASH"/>
<FileRuleRef RuleID="ID_DENY_BGINFO"/>
<FileRuleRef RuleID="ID_DENY_CBD"/>
<FileRuleRef RuleID="ID_DENY_CSI"/>
<FileRuleRef RuleID="ID_DENY_DBGHOST"/>
<FileRuleRef RuleID="ID_DENY_DBGSVC"/>
<FileRuleRef RuleID="ID_DENY_DNX"/>
<FileRuleRef RuleID="ID_DENY_DOTNET" />
<FileRuleRef RuleID="ID_DENY_FSI"/>
<FileRuleRef RuleID="ID_DENY_FSI_ANYCPU"/>
<FileRuleRef RuleID="ID_DENY_INFINSTALL"/>
<FileRuleRef RuleID="ID_DENY_KD"/>
<FileRuleRef RuleID="ID_DENY_KILL"/>
<FileRuleRef RuleID="ID_DENY_LXSS"/>
<FileRuleRef RuleID="ID_DENY_LXRUN"/>
<FileRuleRef RuleID="ID_DENY_MFC40"/>
<FileRuleRef RuleID="ID_DENY_MS_BUILD" />
<FileRuleRef RuleID="ID_DENY_MS_BUILD_FMWK" />
<FileRuleRef RuleID="ID_DENY_MWFC" />
<FileRuleRef RuleID="ID_DENY_MSBUILD"/>
<FileRuleRef RuleID="ID_DENY_MSBUILD_DLL" />
<FileRuleRef RuleID="ID_DENY_MSHTA"/>
<FileRuleRef RuleID="ID_DENY_NTKD"/>
<FileRuleRef RuleID="ID_DENY_NTSD"/>
<FileRuleRef RuleID="ID_DENY_PWRSHLCUSTOMHOST"/>
<FileRuleRef RuleID="ID_DENY_RCSI"/>
<FileRuleRef RuleID="ID_DENY_RUNSCRIPTHELPER"/>
<FileRuleRef RuleID="ID_DENY_TEXTTRANSFORM"/>
<FileRuleRef RuleID="ID_DENY_VISUALUIAVERIFY"/>
<FileRuleRef RuleID="ID_DENY_WFC" />
<FileRuleRef RuleID="ID_DENY_WINDBG"/>
<FileRuleRef RuleID="ID_DENY_WMIC"/>
<FileRuleRef RuleID="ID_DENY_WSL"/>
<FileRuleRef RuleID="ID_DENY_WSLCONFIG"/>
<FileRuleRef RuleID="ID_DENY_WSLHOST"/>

</FileRulesRef>
</ProductSigners>
</SigningScenario>
</SigningScenarios>
<CiSigners />
</SiPolicy>
NOTE
To create a policy that works on both Windows 10, version 1803 and version 1809, you can create two different policies,
or merge them into one broader policy.
More information
Windows Defender Application Control Wizard
Applies to:
Windows 10
The Windows Defender Application Control (WDAC) policy Wizard is an open source Windows desktop
application written in C# and bundled as an MSIX package. The Wizard was built to provide security architects,
security and system administrators with a more user-friendly means to create, edit, and merge WDAC policies.
The Wizard desktop application uses the ConfigCI PowerShell Cmdlets in the backend so the output policy of the
Wizard and PowerShell cmdlets is identical.
Downloading the application

The WDAC Wizard can be downloaded from the official Wizard installer website as an MSIX packaged
application. The Wizard's source code is available as part of Microsoft's Open Source Software offerings on
GitHub at the WDAC Wizard Repo.
Suppor ted Clients
As the WDAC Wizard uses the cmdlets in the background, the Wizard is functional on clients only where the
cmdlets are supported as outlined in WDAC feature availability. Specifically, the tool will verify that the client
meets one of the following requirements:
Windows builds 1909+
For pre-1909 builds, the Enterprise SKU of Windows is installed
If neither requirement is satisfied, the Wizard will throw an error as the cmdlets are not available.
In this section
Creating a new base policy This article describes how to create a new base policy using
one of the supplied policy templates.
Creating a new supplemental policy This article describes the steps necessary to create a
supplemental policy, from one of the supplied templates, for
an existing base policy.
Editing a base or supplemental policy This article demonstrates how to modify an existing policy
and the Wizard's editing capabilities.
Merging policies This article describes how to merge policies into a single
application control policy.
Creating a new Base Policy with the Wizard
Applies to
Windows 10
When creating policies for use with Windows Defender Application Control (WDAC), it is recommended to start
with a template policy and then add or remove rules to suit your application control scenario. For this reason,
the WDAC Wizard offers three template policies to start from and customize during the base policy creation
workflow. Prerequisite information about application control can be accessed through the WDAC design guide.
This page outlines the steps to create a new application control policy from a template, configure the policy
options, and the signer and file rules.
Template Base Policies

Each of the template policies has a unique set of policy allow list rules that will affect the circle-of-trust and
security model of the policy. The following table lists the policies in increasing order of trust and freedom. For
instance, the Default Windows mode policy trusts fewer application publishers and signers than the Signed and
Reputable mode policy. The Default Windows policy will have a smaller circle-of-trust with better security than
the Signed and Reputable policy, but at the expense of compatibility.
T EM P L AT E B A SE P O L IC Y DESC RIP T IO N
Default Windows Mode Default Windows mode will authorize the following
components:
Windows operating components - any binary
installed by a fresh install of Windows
Apps installed from the Microsoft Store
Microsoft Office365 apps, OneDrive, and Microsoft
Teams
Third-party Windows Hardware Compatible drivers
Allow Microsoft Mode Allow mode will authorize the following components:
Teams
All Microsoft-signed software
T EM P L AT E B A SE P O L IC Y DESC RIP T IO N
Signed and Reputable Mode Signed and Reputable mode will authorize the following
components:
Teams
All Microsoft-signed software
Files with good reputation per Microsoft Defender's
Intelligent Security Graph technology
Italicized content denotes the changes in the current policy with respect to the policy prior.
More information about the Default Windows Mode and Allow Microsoft Mode policies can be accessed
through the Example WDAC base policies article.
Once the base template is selected, give the policy a name and choose where to save the application control
policy on disk.
Configuring Policy Rules

Upon page launch, policy rules will be automatically enabled/disabled depending on the chosen template from
the previous page. Choose to enable or disable the desired policy rule options by pressing the slider button next
to the policy rule titles. A short description of each rule will appear at the bottom of the page when the mouse
hovers over the rule title.
Policy Rules Description
A description of each policy rule, beginning with the left-most column, is provided below. The Policy rules article
provides a full description of each policy rule.
Advanced Boot Options Menu The F8 preboot menu is disabled by default for all WDAC
policies. Setting this rule option allows the F8 menu to
appear to physically present users.
Allow Supplemental Policies Use this option on a base policy to allow supplemental
policies to expand it.
Disable Script Enforcement This option disables script enforcement options. Unsigned
PowerShell scripts and interactive PowerShell are no longer
restricted to Constrained Language Mode. NOTE: This option
is only supported with the Windows 10 May 2019 Update
(1903) and higher. Using it on earlier versions of Windows
10 is not supported and may have unintended results.
Hyper visor-protected code integrity (HVCI) When enabled, policy enforcement uses virtualization-based
security to run the code integrity service inside a secure
environment. HVCI provides stronger protections against
kernel malware.
Intelligent Security Graph Authorization Use this option to automatically allow applications with
Managed Installer Use this option to automatically allow applications installed

managed installer.
Require WHQL By default, legacy drivers that are not Windows Hardware
Quality Labs (WHQL) signed are allowed to execute. Enabling
this rule requires that every executed driver is WHQL signed
and removes legacy driver support. Going forward, every
new Windows 10–compatible driver must be WHQL
certified.
Update Policy without Rebooting Use this option to allow future WDAC policy updates to
apply without requiring a system reboot.
Unsigned System Integrity Policy Allows the policy to remain unsigned. When this option is
removed, the policy must be signed and have
UpdatePolicySigners added to the policy to enable future
policy modifications.
User Mode Code Integrity WDAC policies restrict both kernel-mode and user-mode
binaries. By default, only kernel-mode binaries are restricted.
Enabling this rule option validates user mode executables
and scripts.
Advanced Policy Rules Description
Selecting the + Advanced Options label will show another column of policy rules; advanced policy rules. A
description of each policy rule is provided below.
Boot Audit on Failure Used when the WDAC policy is in enforcement mode. When
a driver fails during startup, the WDAC policy will be placed
in audit mode so that Windows will load. Administrators can
validate the reason for the failure in the CodeIntegrity event
log.
Disable Flight Signing If enabled, WDAC policies will not trust flightroot-signed
binaries. This would be used in the scenario in which
organizations only want to run released binaries, not
flight/preview-signed builds.
Disable Runtime FilePath Rule Protection Disable default FilePath rule protection (apps and
FileRule that allows a file based on FilePath.
Dynamic Code Security Enables policy enforcement for .NET applications and
dynamically loaded libraries (DLLs).
Invalidate EAs on Reboot When the Intelligent Security Graph option (14) is used,
WDAC sets an extended file attribute that indicates that the
file was authorized to run. This option will cause WDAC to
periodically revalidate the reputation for files that were
authorized by the ISG.
Require EV Signers In addition to being WHQL signed, this rule requires that
drivers must have been submitted by a partner that has an
Extended Verification (EV) certificate. All Windows 10 and
later drivers will meet this requirement.
NOTE
We recommend that you enable Audit Mode initially because it allows you to test new WDAC policies before you
enforce them. With audit mode, no application is blocked—instead the policy logs an event whenever an application
outside the policy is started. For this reason, all templates have Audit Mode enabled by default.
Creating custom file rules

File rules in an application control policy will specify the level at which applications will be identified and trusted.
File rules are the main mechanism for defining trust in the application control policy. Selecting the + Custom
Rules will open the custom file rule conditions panel to create custom file rules for your policy. The Wizard
supports four types of file rules:
Publisher Rules
The Publisher file rule type uses properties in the code signing certificate chain to base file rules. Once the file to
base the rule off of, called the reference file, is selected, use the slider to indicate the specificity of the rule. The
table below shows the relationship between the slider placement, the corresponding WDAC rule level and its
description. The lower the placement on the table and the UI slider, the greater the specificity of the rule.
RUL E C O N DIT IO N W DA C RUL E L EVEL DESC RIP T IO N
Issuing CA PCACertificate Highest available certificate is added to

the signers. This is typically the PCA
certificate, one level below the root
certificate. Any file signed by this
certificate will be affected.
Publisher Publisher This rule is a combination of the

PCACertificate rule and the common
name (CN) of the leaf certificate. Any
file signed by a major CA but with a
leaf from a specific company, for
example a device driver corp, is
affected.
File version SignedVersion This rule is a combination of

PCACertificate, publisher, and a version
number. Anything from the specified
publisher with a version at or above
the one specified is affected.
File name FilePublisher Most specific. Combination of the file

name, publisher, and PCA certificate as
well as a minimum version number.
Files from the publisher with the
specified name and greater or equal to
the specified version are affected.
Filepath Rules
mutable access permissions. To create a filepath rule, select the file using the Browse button.
File Attribute Rules
The Wizard supports the creation of file name rules based on authenticated file attributes. File name rules are
useful when an application and its dependencies (for example, DLLs) may all share the same product name, for
instance. This rule level allows users to easily create targeted policies based on the Product Name file name
parameter. To select the file attribute to create the rule, move the slider on the Wizard to the desired attribute.
The table below describes each of the supported file attributes off which to create a rule.
Original Filename Specifies the original file name, or the name with which the
File description Specifies the file description provided by the developer of the
binary.
Product name Specifies the name of the product with which the binary
ships.
Internal name Specifies the internal name of the binary.
File Hash Rules

Lastly, the Wizard supports creating file rules using the hash of the file. Although this level is specific, it can
cause additional administrative overhead to maintain the current product versions’ hash values. Each time a
binary is updated, the hash value changes, therefore requiring a policy update. By default, the Wizard will use
file hash as the fallback in case a file rule cannot be created using the specified file rule level.
Deleting Signing Rules
The policy signing rules list table on the left of the page will document the allow and deny rules in the template,
as well as any custom rules you create. Template signing rules and custom rules can be deleted from the policy
by selecting the rule from the rules list table. Once the rule is highlighted, press the delete button underneath
the table. you will be prompted for additional confirmation. Select Yes to remove the rule from the policy and
the rules table.
Up next
Editing a WDAC policy using the Wizard
Creating a new Supplemental Policy with the
Wizard
Applies to
Windows 10
Beginning in Windows 10 version 1903, WDAC supports the creation of multiple active policies on a device. One
or more supplemental policies allow customers to expand a WDAC base policy to increase the circle of trust of
the policy. A supplemental policy can expand only one base policy, but multiple supplementals can expand the
same base policy. When using supplemental policies, applications allowed by the base or its supplemental
policy/policies will be allowed to execute.
Prerequisite information about application control can be accessed through the WDAC design guide. This page
outlines the steps to create a supplemental application control policy, configure the policy options, and the
signer and file rules.
Expanding a Base Policy

Once the Supplemental Policy type is chosen on the New Policy page, policy name and file dialog fields can be
used to name and save the supplemental policy. The next step requires selecting a base policy to expand. To
expand a base policy, the base must allow supplemental policies. The WDAC Wizard will verify if the base policy
allows supplementals and will show the following confirmation.
If the base policy is not configured for supplemental policies, the Wizard will attempt to convert the policy to
one that can be supplemented. Once successful, the Wizard will show a dialog demonstrating that the addition
of the Allow Supplemental Policy rule was completed.
Policies that cannot be supplemented, for instance, a supplemental policy, will be detected by the Wizard and will
show the following error. Only a base policy can be supplemented. More information on supplemental policies
can be found on our Multiple Policies article.

Upon page launch, policy rules will be automatically enabled/disabled depending on the chosen base policy
from the previous page. Most of the supplemental policy rules must be inherited from the base policy. The
Wizard will automatically parse the base policy and set the required supplemental policy rules to match the base
policy rules. Inherited policy rules will be grayed out and will not be modifiable in the user interface.
A short description of the rule will be shown at the bottom of the page when the cursor is placed on the rule
title.
Configurable Supplemental Policy Rules Description
There are only three policy rules that can be configured by the supplemental policy. A description of each policy
rule, beginning with the left-most column, is provided below. Selecting the + Advanced Options label will
show another column of policy rules; advanced policy rules.
Intelligent Security Graph Authorization Use this option to automatically allow applications with
Managed Installer Use this option to automatically allow applications installed

managed installer.
Disable Runtime FilePath Rule Protection Disable default FilePath rule protection (apps and
FileRule that allows a file based on FilePath.
Creating custom file rules

File rules in an application control policy will specify the level at which applications will be identified and trusted.
File rules are the main mechanism for defining trust in the application control policy. Selecting the + Custom
Rules will open the custom file rule conditions panel to create and customize targeted file rules for your policy.
The Wizard supports four types of file rules:
Publisher Rules
The Publisher file rule type uses properties in the code signing certificate chain to base file rules. Once the file to
base the rule off of, called the reference file, is selected, use the slider to indicate the specificity of the rule. The
table below shows the relationship between the slider placement, the corresponding WDAC rule level, and its
description. The lower the placement on the table and the UI slider, the greater the specificity of the rule.
Issuing CA PCACertificate Highest available certificate is added to

the signers. This certificate is typically
the PCA certificate, one level below the
root certificate. Any file signed by this
certificate will be affected.
Publisher Publisher This rule is a combination of the

PCACertificate rule and the common
name (CN) of the leaf certificate. Any
file signed by a major CA but with a
leaf from a specific company, for
example a device driver publisher, is
affected.
File version SignedVersion This rule is a combination of the

PCACertificate and Publisher rule, and
a version number. Anything from the
specified publisher with a version at or
above the one specified is affected.
File name FilePublisher Most specific. Combination of the file

name, publisher, and PCA certificate
and a minimum version number. Files
from the publisher with the specified
name and greater or equal to the
specified version are affected.
Filepath Rules
mutable access permissions. To create a filepath rule, select the file using the Browse button.
File Attribute Rules
The Wizard supports the creation of file name rules based on authenticated file attributes. File name rules are
useful when an application and its dependencies (for example, DLLs) may all share the same product name, for
instance. This rule level allows users to easily create targeted policies based on the Product Name file name. To
select the file attribute to create the rule, move the slider on the Wizard to the desired attribute. The table below
describes each of the supported file attributes off which to create a rule.
Original Filename Specifies the original file name, or the name with which the
File description Specifies the file description provided by the developer of the
binary.
Product name Specifies the name of the product with which the binary
ships.
Internal name Specifies the internal name of the binary.
File Hash Rules

Lastly, the Wizard supports creating file rules using the hash of the file. Although this level is specific, it can
cause extra administrative overhead to maintain the current product versions’ hash values. Each time a binary is
updated, the hash value changes, therefore requiring a policy update. By default, the Wizard will use file hash as
the fallback in case a file rule cannot be created using the specified file rule level.
Deleting Signing Rules
The table on the left of the page will document the allow and deny rules in the template, and any custom rules
you create. Rules can be deleted from the policy by selecting the rule from the rules list table. Once the rule is
highlighted, press the delete button underneath the table. you will be prompted for additional confirmation.
Select Yes to remove the rule from the policy and the rules table.
Up next
Editing a WDAC policy using the Wizard
Editing existing base and supplemental WDAC
policies with the Wizard
Applies to
Windows 10
The WDAC Wizard makes editing and viewing WDAC policies easier than the PowerShell cmdlets or manually.
The Wizard currently supports the following editing capabilities:
[Configuring policy rules](#configuring-policy-rules)
[Adding new allow or block file rules to existing policies](#adding-file-rules)
[Removing allow or block file rules on existing policies](#removing-file-rules)

The Policy Rules page will load with the in-edit policy rules configured per the set rules. Selecting the
+ Advanced Options button will reveal the advanced policy rule options panel. This grouping of rules contains
additional policy rule options that are less common to the majority of users. To edit any of the rules, flip the
corresponding policy rule state. For instance, to disable Audit Mode and enable Enforcement Mode in the figure
below, the button beside the Audit Mode label needs only to be pressed. Once the policy rules are configured,
select the Next button to continue the next stage of editing: Adding File Rules.
A description of the policy rule is shown at the bottom of the page when the cursor is placed over the rule title.
For a complete list of the policy rules and their capabilities, see the Windows Defender Application Control
policy rules table.
Adding File Rules

The WDAC Wizard allows users to add rules to their existing policy seamlessly. Previously, this would have
involved creating a new policy with the new rules and merging it with the existing policy.
Selecting the + Custom Rules button will open the Custom Rules panel. For more information on creating new
policy file rules, see the guidelines provided in the creating policy file rules section.
Removing File Rules

The WDAC Wizard makes deleting file rules from an existing policy quick and easy. To remove any type of file
rule: publisher rule, path rule, filename rule, or a hash rule, select the rule in the Policy Signing Rules List table
on the left-hand side of the page. Selecting the rule will highlight the entire row. Once the row is highlighted,
select the remove icon underneath the table. The Wizard will prompt for user confirmation before removing the
file rule. Once removed, the rule will no longer appear in the policy or the table.
Note: removing a publisher rule will also remove the associated File Attribute rules. For instance, in the xml
block below, removing ID_SIGNER_CONTOSO_PUBLISHER would also remove the rules
ID_FILEATTRIB_LOB_APP_1 and ID_FILEATTRIB_LOB_APP_2.
<Signer ID="ID_SIGNER_CONTOSO_PUBLISHER" Name="Contoso LOB Publisher CA">

<CertRoot Type="TBS" Value="0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF" />
<CertPublisher Value="Contoso IT Dept App Publisher" />
<FileAttribRef RuleID="ID_FILEATTRIB_LOB_APP_1" />
<FileAttribRef RuleID="ID_FILEATTRIB_LOB_APP_2" />
Policy Creation
Once the policy is created, the new policy will be written to the same path as the in-edit policy. The new policy
file name will have the policy version appended to the end of the file name. For instance, if the in-edit policy is
saved at MyDocuments\BasePolicy.xml, after edit, the new policy will be saved at
MyDocuments\BasePolicy_v10.0.0.1.xml.
Up next
Merging WDAC policies using the Wizard
Merging existing policies with the WDAC Wizard
Beginning in Windows 10 version 1903, WDAC supports multiple policies. Before version 1903, however,
Windows 10 could only have one WDAC policy. Consequently, users were required to merge multiple WDAC
policies into one. The WDAC Wizard has a simple to use user interface to allow users to merge multiple WDAC
policies. The Wizard can support up to 15 policy files as input during the merge workflow.
Select the policies you wish to merge into one policy using the + Add Policy button under the table. Once
added, policies will be enumerated within the table. To remove a policy from the table, if accidentally added,
highlight the policy row and select the - Remove Policy button. Confirmation will be required before the policy
is withdrawn from the table.
NOTE
The policy type and ID of the final output policy will be determined based on the type and ID of the first policy in the
policy list table. For instance, if a legacy policy format policy and a multi-policy format policy are merged together, the
output format of the policy will be whichever policy is specified first in the table. For more information on policy formats,
visit the Multiple WDAC Policies page.
Lastly, select a filepath save location for the final merged policy using the Browse button. If a minimum of two
policies are selected, and the save location is specified, select the Next button to build the policy.
Planning and getting started on the Windows
Defender Application Control deployment process
Applies to
Windows 10
Windows Server 2016
This topic provides a roadmap for planning and getting started on the Windows Defender Application Control
(WDAC) deployment process, with links to topics that provide additional detail. Planning for WDAC deployment
involves looking at both the end-user and the IT pro impact of your choices.
Planning
1. Review requirements, especially hardware requirements for VBS.
2. Group devices by degree of control needed. Do most devices fit neatly into a few categories, or are they
scattered across all categories? Are users allowed to install any application or must they choose from a
list? Are users allowed to use their own peripheral devices?
Deployment is simpler if everything is locked down in the same way, but meeting individual
departments' needs, and working with a wide variety of devices, may require a more complicated and
flexible deployment.
3. Review how much variety in software and hardware is needed by roles or departments. The following
questions can help you clarify how many WDAC policies to create:
How standardized is the hardware?
This can be relevant because of drivers. You could create a WDAC policy on hardware that uses a
particular set of drivers, and if other drivers in your environment use the same signature, they
would also be allowed to run. However, you might need to create several WDAC policies on
different "reference" hardware, then merge the policies together, to ensure that the resulting policy
recognizes all the drivers in your environment.
What software does each department or role need? Should they be able to install and run other
departments' software?
If multiple departments are allowed to run the same list of software, you might be able to merge
several WDAC policies to simplify management.
Are there departments or roles where unique, restricted software is used?
If one department needs to run an application that no other department is allowed, it might
require a separate WDAC policy. Similarly, if only one department must run an old version of an
application (while other departments allow only the newer version), it might require a separate
WDAC policy.
Is there already a list of accepted applications?
A list of accepted applications can be used to help create a baseline WDAC policy.
As of Windows 10, version 1703, it might also be useful to have a list of plug-ins, add-ins, or
modules that you want to allow only in a specific app (such as a line-of-business app). Similarly, it
might be useful to have a list of plug-ins, add-ins, or modules that you want to block in a specific
app (such as a browser).
As part of a threat review process, have you reviewed systems for software that can load arbitrary
DLLs or run code or scripts? In day-to-day operations, your organization's security policy may
allow certain applications, code, or scripts to run on your systems depending on their role and the
context. However, if your security policy requires that you run only trusted applications, code, and
scripts on your systems, you may decide to lock these systems down securely with Windows
Defender Application Control policies.
Legitimate applications from trusted vendors provide valid functionality. However, an attacker
could also potentially use that same functionality to run malicious executable code that could
bypass WDAC.
For operational scenarios that require elevated security, certain applications with known Code
Integrity bypasses may represent a security risk if you allow them in your WDAC policies. Other
applications, where older versions of the application had vulnerabilities, also represent a risk.
Therefore, you may want to deny or block such applications from your WDAC policies. For
applications with vulnerabilities, once the vulnerabilities are fixed you can create a rule that only
allows the fixed or newer versions of that application. The decision to allow or block applications
depends on the context and on how the reference system is being used.
Security professionals collaborate with Microsoft continuously to help protect customers. With the
help of their valuable reports, Microsoft has identified a list of known applications that an attacker
could potentially use to bypass Windows Defender Application Control. Depending on the context,
you may want to block these applications. To view this list of applications and for use case
examples, such as disabling msbuild.exe, see Microsoft recommended block rules.
4. Identify LOB applications that are currently unsigned. Although requiring signed code (through WDAC)
protects against many threats, your organization might use unsigned LOB applications, for which the
process of signing might be difficult. You might also have applications that are signed, but you want to
add a secondary signature to them. If so, identify these applications, because you will need to create a
catalog file for them.
Getting started on the deployment process

1. Optionally, create a signing certificate for Windows Defender Application Control. As you deploy WDAC,
you might need to sign catalog files or WDAC policies internally. To do this, you will either need a publicly
issued code signing certificate (that you purchase) or an internal CA. If you choose to use an internal CA,
you will need to create a code signing certificate.
2. Create WDAC policies from reference computers. In this respect, creating and managing WDAC policies
to align with the needs of roles or departments can be similar to managing corporate images. From each
reference computer, you can create a WDAC policy, and decide how to manage that policy. You can merge
WDAC policies to create a broader policy or a master policy, or you can manage and deploy each policy
individually.
3. Audit the WDAC policy and capture information about applications that are outside the policy. We
recommend that you use audit mode to carefully test each WDAC policy before you enforce it. With audit
mode, no application is blocked—the policy just logs an event whenever an application outside the policy
is started. Later, you can expand the policy to allow these applications, as needed.
4. Create a catalog file for unsigned LOB applications. Use the Package Inspector tool to create and sign a
catalog file for your unsigned LOB applications. In later steps, you can merge the catalog file's signature
into your WDAC policy, so that applications in the catalog will be allowed by the policy.
5. Capture needed policy information from the event log, and merge information into the existing policy as
needed. After a WDAC policy has been running for a time in audit mode, the event log will contain
information about applications that are outside the policy. To expand the policy so that it allows for these
applications, use Windows PowerShell commands to capture the needed policy information from the
event log, and then merge that information into the existing policy. You can merge WDAC policies from
other sources also, for flexibility in how you create your final WDAC policies.
6. Deploy WDAC policies and catalog files. After you confirm that you have completed all the preceding
steps, you can begin deploying catalog files and taking WDAC policies out of auditing mode. We strongly
recommend that you begin this process with a test group of users. This provides a final quality-control
validation before you deploy the catalog files and WDAC policies more broadly.
7. Enable desired virtualization-based security (VBS) features. Hardware-based security features—also
called virtualization-based security (VBS) features—strengthen the protections offered by Windows
Defender Application Control.
Known issues
This section covers known issues with WDAC. Virtualization-based protection of code integrity may be
incompatible with some devices and applications, which might cause unexpected failures, data loss, or a blue
screen error (also called a stop error). Test this configuration in your lab before enabling it in production.
MSI Installations are blocked by WDAC
Installing .msi files directly from the internet to a computer protected by WDAC will fail. For example, this
command will not work:
msiexec –i https://download.microsoft.com/download/2/E/3/2E3A1E42-8F50-4396-9E7E-
76209EA4F429/Windows10_Version_1511_ADMX.msi
As a workaround, download the MSI file and run it locally:
msiexec –i c:\temp\Windows10_Version_1511_ADMX.msi
Audit Windows Defender Application Control
policies
Applies to:
Windows 10
Windows Server 2016
Running Application Control in audit mode allows administrators to discover any applications that were
missed during an initial policy scan and to identify any new applications that have been installed and run since
the original policy was created. While a WDAC policy is running in audit mode, any binary that runs and would
have been denied had the policy been enforced is logged in the Applications and Ser vices
Logs\Microsoft\Windows\CodeIntegrity\Operational event log. When these logged binaries have been
validated, they can easily be added to a new WDAC policy. When the new exception policy is created, you can
merge it with your existing WDAC policies.
Before you begin this process, you need to create a WDAC policy binary file. If you have not already done so, see
Create an initial Windows Defender Application Control policy from a reference computer.
To audit a Windows Defender Application Control policy with local policy:
1. Before you begin, find the *.bin policy file , for example, the DeviceGuardPolicy.bin. Copy the file to
C:\Windows\System32\CodeIntegrity.
2. On the computer you want to run in audit mode, open the Local Group Policy Editor by running
GPEdit.msc .
NOTE
The computer that you will run in audit mode must be clean of viruses or malware. Otherwise, in the
process that you follow after auditing the system, you might unintentionally merge in a policy that allows
viruses or malware to run.
An alternative method to test a policy is to rename the test file to SIPolicy.p7b and drop it into
C:\Windows\System32\CodeIntegrity, rather than deploy it by using the Local Group Policy Editor.
3. Navigate to Computer Configuration\Administrative Templates\System\Device Guard , and then

select Deploy Windows Defender Application Control . Enable this setting by using the appropriate
file path, for example, C:\Windows\System32\CodeIntegrity\DeviceGuardPolicy.bin, as shown in Figure 1.
NOTE
You can copy the WDAC policies to a file share to which all computer accounts have access rather than
copy them to every system.
You might have noticed that the GPO setting references a .p7b file and this policy uses a .bin file.
Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when
dropped onto the computers running Windows 10. We recommend that you make your WDAC policy
names friendly and allow the system to convert the policy names for you. By doing this, it ensures that the
policies are easily distinguishable when viewed in a share or any other central repository.
Figure 1. Deploy your Windows Defender Application Control policy
4. Restart the reference system for the WDAC policy to take effect.
5. Use the system as you normally would, and monitor code integrity events in the event log. While in audit
mode, any exception to the deployed WDAC policy will be logged in the Applications and Ser vices
Logs\Microsoft\Windows\CodeIntegrity\Operational event log, as shown in Figure 2.
Figure 2. Exceptions to the deployed WDAC policy
You will be reviewing the exceptions that appear in the event log, and making a list of any applications
that should be allowed to run in your environment.
6. If you want to create a catalog file to simplify the process of including unsigned LOB applications in your
WDAC policy, this is a good time to create it. For information, see Deploy catalog files to support
Windows Defender Application Control.
Now that you have a WDAC policy deployed in audit mode, you can capture any audit information that appears
in the event log. This is described in the next section.
Create a Windows Defender Application Control policy that captures

audit information from the event log
Use the following procedure after you have been running a computer with a WDAC policy in audit mode for a
period of time. When you are ready to capture the needed policy information from the event log (so that you
can later merge that information into the original WDAC policy), complete the following steps.
1. Review the audit information in the event log. From the WDAC policy exceptions that you see, make a list
of any applications that should be allowed to run in your environment, and decide on the file rule level
that should be used to trust these applications.
Although the Hash file rule level will catch all of these exceptions, it may not be the best way to trust all of
them. For information about file rule levels, see Windows Defender Application Control file rule levels in
"Deploy Windows Defender Application Control: policy rules and file rules."
Your event log might also contain exceptions for applications that you eventually want your WDAC policy
to block. If these appear, make a list of these also, for a later step in this procedure.
2. In an elevated Windows PowerShell session, initialize the variables that will be used. The example
filename shown here is DeviceGuardAuditPolicy.xml :
$CIPolicyPath=$env:userprofile+"\Desktop\"
$CIAuditPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"
3. Use New-CIPolicy to generate a new WDAC policy from logged audit events. This example uses a file rule
level of Hash and includes 3> CIPolicylog.txt , which redirects warning messages to a text file,
CIPolicylog.txt .
New-CIPolicy -Audit -Level Hash -FilePath $CIAuditPolicy –UserPEs 3> CIPolicylog.txt
NOTE
When you create policies from audit events, you should carefully consider the file rule level that you select to trust.
The preceding example uses the Hash rule level, which is the most specific. Any change to the file (such as
replacing the file with a newer version of the same file) will change the Hash value, and require an update to the
policy.
4. Find and review the WDAC audit policy .xml file that you created. If you used the example variables as
shown, the filename will be DeviceGuardAuditPolicy.xml , and it will be on your desktop. Look for the
following:
Any applications that were caught as exceptions, but should be allowed to run in your
environment. These are applications that should be in the .xml file. Leave these as-is in the file.
Any applications that actually should not be allowed to run in your environment. Edit these out of
the .xml file. If they remain in the .xml file, and the information in the file is merged into your
existing WDAC policy, the policy will treat the applications as trusted, and allow them to run.
You can now use this file to update the existing WDAC policy that you ran in audit mode by merging the two
policies. For instructions on how to merge this audit policy with the existing WDAC policy, see the next section,
Merge Windows Defender Application Control policies.
NOTE
You may have noticed that you did not generate a binary version of this policy as you did in Create a Windows Defender
Application Control policy from a reference computer. This is because WDAC policies created from an audit log are not
intended to run as stand-alone policies but rather to update existing WDAC policies.
Merge Windows Defender Application Control
policies
Applies to:
Windows 10
Windows Server 2016
Because each computer running Windows 10 can have only one WDAC policy, you will occasionally need to
merge two or more policies. For example, after a WDAC policy is created and audited, you might want to merge
audit events from another WDAC policy.
NOTE
Because only one SiPolicy.p7b file can be active on a system, the last management authority to write the policy wins. If
there was already a policy deployed by using Group Policy and then a managed installer using Microsoft Endpoint
Configuration Manager targeted the same device, the Configuration Manager policy would overwrite the SiPolicy.p7b file.
To merge two WDAC policies, complete the following steps in an elevated Windows PowerShell session:
1. Initialize the variables that will be used:
$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"
$AuditCIPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"
$MergedCIPolicy=$CIPolicyPath+"MergedPolicy.xml"
$CIPolicyBin=$CIPolicyPath+"NewDeviceGuardPolicy.bin"
NOTE
The variables in this section specifically expect to find an initial policy on your desktop called InitialScan.xml and
an audit WDAC policy called DeviceGuardAuditPolicy.xml. If you want to merge other WDAC policies, update
the variables accordingly.
2. Use Merge-CIPolicy to merge two policies and create a new WDAC policy:
Merge-CIPolicy -PolicyPaths $InitialCIPolicy,$AuditCIPolicy -OutputFilePath $MergedCIPolicy
3. Use ConvertFrom-CIPolicy to convert the merged WDAC policy to binary format:

ConvertFrom-CIPolicy $MergedCIPolicy $CIPolicyBin
Now that you have created a new WDAC policy, you can deploy the policy binary to systems manually or by
using Group Policy or Microsoft client management solutions. For information about how to deploy this new
policy with Group Policy, see Deploy and manage Windows Defender Application Control with Group Policy.
Enforce Windows Defender Application Control
policies
Applies to:
Windows 10
Windows Server 2016
Every WDAC policy is created with audit mode enabled. After you have successfully deployed and tested a
WDAC policy in audit mode and are ready to test the policy in enforced mode, complete the following steps in
an elevated Windows PowerShell session:
NOTE
Every WDAC policy should be tested in audit mode first. For information about how to audit WDAC policies, see Audit
Windows Defender Application Control policies, earlier in this topic.

$EnforcedCIPolicy=$CIPolicyPath+"EnforcedPolicy.xml"
$CIPolicyBin=$CIPolicyPath+"EnforcedDeviceGuardPolicy.bin"
NOTE
The initial WDAC policy that this section refers to was created in the Create a Windows Defender Application
Control policy from a reference computer section. If you are using a different WDAC policy, update the
CIPolicyPath and InitialCIPolicy variables.
2. Ensure that rule options 9 (“Advanced Boot Options Menu”) and 10 (“Boot Audit on Failure”) are set the
way that you intend for this policy. We strongly recommend that you enable these rule options before
you run any enforced policy for the first time. Enabling these options provides administrators with a pre-
boot command prompt, and allows Windows to start even if the WDAC policy blocks a kernel-mode
driver from running. When ready for enterprise deployment, you can remove these options.
To ensure that these options are enabled in a policy, use Set-RuleOption as shown in the following
commands. You can run these commands even if you're not sure whether options 9 and 10 are already
enabled—if so, the commands have no effect.
Set-RuleOption -FilePath $InitialCIPolicy -Option 9
Set-RuleOption -FilePath $InitialCIPolicy -Option 10
3. Copy the initial file to maintain an original copy:

copy $InitialCIPolicy $EnforcedCIPolicy
4. Use Set-RuleOption to delete the audit mode rule option:
Set-RuleOption -FilePath $EnforcedCIPolicy -Option 3 -Delete
NOTE
To enforce a WDAC policy, you delete option 3, the Audit Mode Enabled option. There is no “enforced” option
that can be placed in a WDAC policy.
5. Use ConvertFrom-CIPolicy to convert the new WDAC policy to binary format:

ConvertFrom-CIPolicy $EnforcedCIPolicy $CIPolicyBin
Now that this policy is in enforced mode, you can deploy it to your test computers. Rename the policy to
SIPolicy.p7b and copy it to C:\Windows\System32\CodeIntegrity for testing, or deploy the policy through Group
Policy by following the instructions in Deploy and manage Windows Defender Application Control with Group
Policy. You can also use other client management software to deploy and manage the policy.
Deploy Windows Defender Application Control
policies by using Group Policy
Applies to:
Windows 10
Windows Server 2016
WDAC policies can easily be deployed and managed with Group Policy. Windows Defender allows you to
simplify deployment Windows Defender hardware-based security features and Windows Defender Application
Control policies. The following procedure walks you through how to deploy a WDAC policy called
DeviceGuardPolicy.bin to a test OU called DG Enabled PCs by using a GPO called Contoso GPO Test .
NOTE
This walkthrough requires that you have previously created a WDAC policy and have a computer running Windows 10 on
which to test a Group Policy deployment. For more information about how to create a WDAC policy, see Create a
Windows Defender Application Control policy from a reference computer, earlier in this topic.
NOTE
Signed WDAC policies can cause boot failures when deployed. We recommend that signed WDAC policies be thoroughly
tested on each hardware platform before enterprise deployment.
To deploy and manage a WDAC policy with Group Policy:

1. On a client computer on which RSAT is installed, open the GPMC by running GPMC.MSC
2. Create a new GPO: right-click an OU and then click Create a GPO in this domain, and Link it here .
NOTE
You can use any OU name. Also, security group filtering is an option when you consider different ways of
combining WDAC policies (or keeping them separate), as discussed in Plan for Windows Defender Application
Control policy management.
3. Name the new GPO. You can choose any name.
4. Open the Group Policy Management Editor: right-click the new GPO, and then click Edit .
5. In the selected GPO, navigate to Computer Configuration\Administrative Templates\System\Device
Guard. Right-click Deploy Windows Defender Application Control and then click Edit .
6. In the Deploy Windows Defender Application Control dialog box, select the Enabled option, and
then specify the code integrity policy deployment path.
In this policy setting, you specify either the local path in which the policy will exist on the client computer
or a Universal Naming Convention (UNC) path that the client computers will look to retrieve the latest
version of the policy. For example, with DeviceGuardPolicy.bin on the test computer, the example file path
would be C:\Windows\System32\CodeIntegrity\DeviceGuardPolicy.bin.
NOTE
This policy file does not need to be copied to every computer. You can instead copy the WDAC policies to a file
share to which all computer accounts have access. Any policy selected here is converted to SIPolicy.p7b when it is
deployed to the individual client computers.
NOTE
You may have noticed that the GPO setting references a .p7b file and this example uses a .bin file for the policy.
Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped
on the client computer running Windows 10. Make your WDAC policies friendly and allow the system to convert
the policy names for you to ensure that the policies are easily distinguishable when viewed in a share or any other
central repository.
7. Close the Group Policy Management Editor, and then restart the Windows 10 test computer. Restarting
the computer updates the WDAC policy. For information about how to audit WDAC policies, see Audit
Windows Defender Application Control policies.
Deploy Windows Defender Application Control
policies by using Microsoft Intune
Applies to:
Windows 10
You can use Microsoft Endpoint Manager (MEM) Intune to configure Windows Defender Application Control
(WDAC) on client machines. Intune includes native support for WDAC, which allows you to configure Windows
10 client computers to only run Windows components and Microsoft Store apps, or to also allow reputable apps
as defined by the Intelligent Security Graph (ISG). Using the built-in policies can be a helpful starting point, but
many customers may find the available circle-of-trust options to be too limited. In order to deploy a custom
policy through Intune and define your own circle of trust, you can configure a profile using Custom OMA-URI.
Using Intune's Built-In Policies

Intune's built-in WDAC support enables you to deploy a policy which only allows Windows components and
Microsoft Store apps to run. This policy is the non-Multiple Policy Format version of the DefaultWindows policy;
the Multiple Policy Format version can be found at C:\Windows\schemas\CodeIntegrity\ExamplePolicies.
Setting "Trust apps with good reputation" to enabled is equivalent to adding Option 14 (Enabled: Intelligent
Security Graph Authorization) to the DefaultWindows policy.
1. Open the Microsoft Intune portal and click Device configuration > Profiles > Create profile .
2. Type a name for the new profile, select Windows 10 and later as the Platform and Endpoint
protection as the Profile type .
3. Click Configure > Windows Defender Application Control , choose from the following settings and
then click OK :
Application control code integrity policies : Select Audit only to log events but not block any
apps from running or select Enforce to allow only Windows components and Store apps to run.
Trust apps with good reputation : Select Enable to allow reputable apps as defined by the
Intelligent Security Graph to run in addition to Windows components and Store apps.
Using a Custom OMA-URI Profile
NOTE
Policies deployed through Intune Custom OMA-URI are subject to a 350,000 byte limit. Customers whose devices are
running 1903+ builds of Windows are encouraged to use multiple policies which are more streamlined and less than
350K bytes in size.
For 1903+ systems

Beginning in 1903, Custom OMA-URI policy deployment leverages the ApplicationControl CSP, which has
support for multiple policies and rebootless policies.
Deploying policies
The steps to use Intune's Custom OMA-URI functionality are:
1. Know a generated policy's GUID, which can be found in the policy xml as <PolicyID>
2. Convert the policy XML to binary format using the ConvertFrom-CIPolicy cmdlet in order to be deployed.
The binary policy may be signed or unsigned.
4. Type a name for the new profile, select Windows 10 and later as the Platform and Custom as the
Profile type .
5. Add a row, then give your policy a name and use the following settings:
OMA-URI : ./Vendor/MSFT/ApplicationControl/Policies/Policy GUID/Policy
Data type : Base64
Cer tificate file : upload your binary format policy file. You do not need to upload a Base64 file, as
Intune will convert the uploaded .bin file to Base64 on your behalf.
Removing policies
Upon deletion, policies deployed through Intune via the ApplicationControl CSP are removed from the system
but stay in effect until the next reboot. In order to functionally do a rebootless delete, first replace the existing
policy with an Allow All policy (found at C:\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml) and
then delete the updated policy. This will immediately prevent anything from being blocked and fully deactive the
policy on the next reboot.
For pre -1903 systems
Deploying policies
The steps to use Intune's Custom OMA-URI functionality to leverage the AppLocker CSP and deploy a custom
WDAC policy to pre-1903 systems are:
1. Convert the policy XML to binary format using the ConvertFrom-CIPolicy cmdlet in order to be deployed.
The binary policy may be signed or unsigned.
3. Type a name for the new profile, select Windows 10 and later as the Platform and Custom as the
Profile type .
4. Add a row, then give your policy a name and use the following settings:
OMA-URI : ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/Grouping/CodeIntegrity/Policy)
Data type : Base64
Cer tificate file : upload your binary format policy file
NOTE
Deploying policies via the AppLocker CSP will force a reboot during OOBE.
Removing policies
Policies deployed through Intune via the AppLocker CSP cannot be deleted through the Intune console. In order
to disable WDAC policy enforcement, either deploy an audit-mode policy and/or use a script to delete the
existing policy.
Allow COM object registration in a Windows
Defender Application Control policy
Applies to:
Windows 10
Windows Server 2016
Windows Server 2019
IMPORTANT
Some information relates to prereleased product which may be substantially modified before it's commercially released.
Microsoft makes no warranties, express or implied, with respect to the information provided here.
The Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system
for creating binary software components that can interact. COM specifies an object model and programming
requirements that enable COM objects to interact with other objects.
COM object configurability in WDAC policy
Prior to the Windows 10 1903 update, Windows Defender Application Control (WDAC) enforced a built-in allow
list for COM object registration. While this mechanism works for most common application usage scenarios,
customers have provided feedback that there are cases where additional COM objects need to be allowed. The
1903 update to Windows 10 introduces the ability to specify allowed COM objects via their GUID in the WDAC
policy.
NOTE : To add this functionality to other versions of Windows 10, you can install the following or later updates:
Windows 10, 1809 June 18, 2019—KB4501371 (OS Build 17763.592)
(https://support.microsoft.com/help/4501371/windows-10-update-kb4501371)
(https://support.microsoft.com/help/4503289/windows-10-update-kb4503289
Get COM object GUID
Get GUID of application to allow in one of the following ways:
Finding block event in Event Viewer (Application and Service Logs > Microsoft > Windows > AppLocker >
MSI and Script) and extracting GUID
Creating audit policy (using New-CIPolicy –Audit), potentially with specific provider, and use info from block
events to get GUID
Author policy setting to allow or deny COM object GUID
Three elements:
Provider: platform on which code is running (values are Powershell, WSH, IE, VBA, MSI, or a wildcard
“AllHostIds”)
Key: GUID for the program you with to run, in the format Key="{33333333-4444-4444-1616-
161616161616}"
ValueName: needs to be set to "EnterpriseDefinedClsId"
One attribute:
Value: needs to be “true” for allow and “false” for deny
Note that deny only works in base policies, not supplemental
The setting needs to be placed in the order of ASCII values (first by Provider, then Key, then ValueName)
Examples
Example 1: Allows registration of all COM object GUIDs in any provider
<Setting Provider="AllHostIds" Key="AllKeys" ValueName="EnterpriseDefinedClsId">

<Value>
<Boolean>true</Boolean>
</Value>
</Setting>
Example 2: Blocks a specific COM object from being registered via Internet Explorer (IE)
<Setting Provider="IE" Key="{00000000-4444-4444-1616-161616161616}" ValueName="EnterpriseDefinedClsId">

<Value>
<Boolean>false</Boolean>
</Value>
</Setting>
Example 3: Allows a specific COM object to register in PowerShell
<Setting Provider="PowerShell" Key="{33333333-4444-4444-1616-161616161616}"

ValueName="EnterpriseDefinedClsId">
<Value>
<Boolean>true</Boolean>
</Value>
</Setting>
Windows Defender Application Control and .NET
hardening
Historically, Windows Defender Application Control (WDAC) has restricted the set of applications, libraries, and
scripts that are allowed to run to those approved by an organization. Security researchers have found that some
.NET applications may be used to circumvent those controls by using .NET’s capabilities to load libraries from
external sources or generate new code on the fly. Beginning with Windows 10, version 1803, WDAC features a
new capability, called Dynamic Code Security to verify code loaded by .NET at runtime.
When the Dynamic Code Security option is enabled, WDAC policy is applied to libraries that .NET loads from
external sources. Additionally, it detects tampering in code generated to disk by .NET and blocks loading code
that has been tampered with.
Dynamic Code Security is not enabled by default because existing policies may not account for externally loaded
libraries. Additionally, a small number of .NET loading features, including loading unsigned assemblies built with
System.Reflection.Emit, are not currently supported with Dynamic Code Security enabled. Microsoft
recommends testing Dynamic Code Security in audit mode before enforcing it to discover whether any new
libraries should be included in the policy.
To enable Dynamic Code Security, add the following option to the <Rules> section of your policy:
<Rule>
<Option>Enabled:Dynamic Code Security</Option>
</Rule>
Manage Packaged Apps with Windows Defender
Application Control
Applies to:
Windows 10
Windows Server 2016
This topic for IT professionals describes concepts and lists procedures to help you manage packaged apps with
Windows Defender Application Control (WDAC) as part of your overall application control strategy.
Understanding Packaged Apps and Packaged App Installers

Packaged apps, also known as Universal Windows apps, are based on a model that ensures all the files within an
app package share the same identity. With classic Windows apps, each file within the app could have a unique
identity. With packaged apps, it is possible to control the entire app by using a single WDAC rule.
Typically, an app consists of multiple components: the installer that is used to install the app, and one or more
exes, dlls, or scripts. With classic Windows apps, these components don't always share common attributes such
as the software’s publisher name, product name, and product version. Therefore, WDAC controls each of these
components separately through different rule collections, such as exe, dll, script, and Windows Installer rules. In
contrast, all the components of a packaged app share the same publisher name, package name, and package
version attributes. Therefore, you can control an entire app with a single rule.
Comparing classic Windows Apps and Packaged Apps
WDAC policies for packaged apps can only be applied to apps installed on computers running at least Windows
Server 2012 or Windows 8, but classic Windows apps can be controlled on devices running at least
Windows Server 2008 R2 or Windows 7. The rules for classic Windows apps and packaged apps can be
enforced in tandem. The differences between packaged apps and classic Windows apps that you should
consider include:
Installing the apps All packaged apps can be installed by a standard user, whereas a number of classic
Windows apps require administrative privileges to install. In an environment where most of the users are
standard users, you might not have numerous exe rules (because classic Windows apps require
administrative privileges to install), but you might want to have more explicit policies for packaged apps.
Changing the system state Classic Windows apps can be written to change the system state if they are
run with administrative privileges. Most packaged apps cannot change the system state because they run
with limited privileges. When you design your WDAC policies, it is important to understand whether an app
that you are allowing can make system-wide changes.
Acquiring the apps Packaged apps can be acquired through the Store, or by loading using Windows
PowerShell cmdlets (which requires a special enterprise license). Classic Windows apps can be acquired
through traditional means.
WDAC uses different rule collections to control packaged apps and classic Windows apps. You have the choice to
control one type, the other type, or both.
Using WDAC to Manage Packaged Apps

Just as there are differences in managing each rule collection, you need to manage the packaged apps with the
following strategy:
1. Gather information about which packaged apps are running in your environment.
2. Create WDAC rules for specific packaged apps based on your policy strategies. For more information, see
Deploy WDAC policy rules and file rules.
3. Continue to update the WDAC policies as new package apps are introduced into your environment. To do
this, see Merge WDAC policies.
Blocking Packaged Apps

You can now use New-CIPolicyRule -Package $Package -Deny to block packaged apps.
Blocking Packaged Apps Which Are Installed on the System
Below are the list of steps you can follow to block one or more packaged apps in the case that the apps are on
the system you are using the WDAC PowerShell cmdlets on:
1. Get the app identifier for an installed package
$package = Get-AppxPackage -name *<example_app>*
Where the name of the app is surrounded by asterisks, for example *windowsstore*
2. Make a rule by using the New-CIPolicyRule cmdlet
$Rule = New-CIPolicyRule -Package $package -deny
3. Repeat for other packages you want to block using $rule +=…
4. Make a policy for just the blocks you created for packages
New-CIpolicy -rules $rule -f .\policy.xml -u
5. Merge with an existing policy that authorizes the other applications and system components required for
your scenario. Here we use the sample Allow Windows policy
Merge-CIPolicy -PolicyPaths
.\policy.xml,C:\windows\Schemas\codeintegrity\examplepolicies\DefaultWindows_Audit.xml -o
allowWindowsDenyPackages.xml
6. Disable audit mode if needed
Set-RuleOption -o 3 -Delete .\allowWindowsDenyPackages.xml
7. Enable invalidate EAs on reboot
Set-RuleOption -o 15 .\allowWindowsDenyPackages.xml
8. Compile the policy
ConvertFrom-CIPolicy .\AllowWindowsDenyPackages.xml C:\compiledpolicy.bin

9. Install the policy without restarting
Invoke-CimMethod -Namespace root\Microsoft\Windows\CI -ClassName PS_UpdateAndCompareCIPolicy -

MethodName Update -Arguments @{FilePath = "C:\compiledpolicy.bin"}
Blocking Packaged Apps Which Are Not Installed on the System

If the app you intend to block is not installed on the system you are using the WDAC PowerShell cmdlets on,
then follow the steps below:
1. Create a dummy rule using Steps 1-5 in the Blocking Packaged Apps Which Are Installed on the System
section above
2. Navigate to the app you want to block on the Store website
3. Copy the GUID in the URL for the app
Example: the GUID for the Microsoft To-Do app is 9nblggh5r558
https://www.microsoft.com/p/microsoft-to-do-list-task-reminder/9nblggh5r558?
activetab=pivot:overviewtab
4. Use the GUID in the following REST query URL to retrieve the identifiers for the app
Example: for the Microsoft To-Do app, the URL would be
https://bspmts.mp.microsoft.com/v1/public/catalog/Retail/Products/9nblggh5r558/applockerdata
The URL will return:
{ "packageFamilyName": "Microsoft.Todos_8wekyb3d8bbwe",
"packageIdentityName": "Microsoft.Todos",
"windowsPhoneLegacyId": "6088f001-776c-462e-984d-25b6399c6607",
"publisherCertificateName": "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond,
S=Washington, C=US"
}
5. Use the value returned by the query URL for the packageFamilyName to replace the package name
generated earlier in the dummy rule from Step 1.
Allowing Packaged Apps

The method for allowing specific packaged apps is similar to the method outlined above for blocking packaged
apps, with the only difference being the parameter to the New-CIPolicyRule cmdlet.
$Rule = New-CIPolicyRule -Package $package -allow
Since a lot of system apps are packaged apps, it is generally advised that customers rely on the sample policies
in C:\Windows\schemas\CodeIntegrity\ExamplePolicies to help allow all inbox apps by the Store signature already
included in the policies and control apps with deny rules.
Use a Windows Defender Application Control policy
to control specific plug-ins, add-ins, and modules
Applies to:
Windows 10
Windows Server 2016
As of Windows 10, version 1703, you can use WDAC policies not only to control applications, but also to control
whether specific plug-ins, add-ins, and modules can run from specific apps (such as a line-of-business
application or a browser):
A P P RO A C H ( A S O F W IN DO W S 10, VERSIO N 1703) GUIDEL IN E
You can work from a list of plug-ins, add-ins, or modules Use New-CIPolicyRule with the -AppID option.
that you want only a specific application to be able to run.
Other applications would be blocked from running them.
In addition, you can work from a list of plug-ins, add-ins, or Use New-CIPolicyRule with the -AppID and -Deny
modules that you want to block in a specific application. options.
Other applications would be allowed to run them.
To work with these options, the typical method is to create a policy that only affects plug-ins, add-ins, and
modules, then merge it into your 'master' policy (merging is described in the next section).
For example, to create a WDAC policy allowing addin1.dll and addin2.dll to run in ERP1.exe , your
organization's enterprise resource planning (ERP) application, run the following commands. Note that in the
second command, += is used to add a second rule to the $rule variable:
$rule = New-CIPolicyRule -DriverFilePath '.\temp\addin1.dll' -Level FileName -AppID '.\ERP1.exe'

$rule += New-CIPolicyRule -DriverFilePath '.\temp\addin1.dll' -Level FileName -AppID '.\ERP1.exe'
New-CIPolicy -Rules $rule -FilePath ".\AllowERPAddins.xml" -UserPEs
As another example, to create a WDAC policy that blocks addin3.dll from running in Microsoft Word, run the
following command. You must include the -Deny option to block the specified add-ins in the specified
application:
$rule = New-CIPolicyRule -DriverFilePath '.\temp\addin3.dll' -Level FileName -Deny -AppID '.\winword.exe'

New-CIPolicy -Rules $rule -FilePath ".\BlockAddins.xml" -UserPEs
Use code signing to simplify application control for
classic Windows applications
Applies to:
Windows 10
Windows Server 2016
This topic covers guidelines for using code signing control classic Windows apps.
Reviewing your applications: application signing and catalog files

Typically, WDAC policies are configured to use the application's signing certificate as part or all of what identifies
the application as trusted. This means that applications must either use embedded signing—where the signature
is part of the binary—or catalog signing, where you generate a "catalog file" from the applications, sign it, and
through the signed catalog file, configure the WDAC policy to recognize the applications as signed.
Catalog files can be very useful for unsigned LOB applications that cannot easily be given an embedded
signature. However, catalogs need to be updated each time an application is updated. In contrast, with
embedded signing, your WDAC policies typically do not have to be updated when an application is updated. For
this reason, if code-signing is or can be included in your in-house application development process, it can
simplify the management of WDAC (compared to using catalog signing).
To obtain signed applications or embed signatures in your in-house applications, you can choose from a variety
of methods:
Using the Microsoft Store publishing process. All apps that come out of the Microsoft Store are
automatically signed with special signatures that can roll-up to our certificate authority (CA) or to your
own.
Using your own digital certificate or public key infrastructure (PKI). ISV's and enterprises can sign their
own Classic Windows applications themselves, adding themselves to the trusted list of signers.
Using a non-Microsoft signing authority. ISV's and enterprises can use a trusted non-Microsoft signing
authority to sign all of their own Classic Windows applications.
To use catalog signing, you can choose from the following options:
Use the Windows Defender signing portal available in the Microsoft Store for Business and Education.
The portal is a Microsoft web service that you can use to sign your Classic Windows applications.
Create your own catalog files, which are described in the next section.
Catalog files
Catalog files (which you can create in Windows 10 with a tool called Package Inspector) contain information
about all deployed and executed binary files associated with your trusted but unsigned applications. When you
create catalog files, you can also include signed applications for which you do not want to trust the signer but
rather the specific application. After creating a catalog, you must sign the catalog file itself by using enterprise
public key infrastructure (PKI), or a purchased code signing certificate. Then you can distribute the catalog, so
that your trusted applications can be handled by WDAC in the same way as any other signed application.
Catalog files are simply Secure Hash Algorithm 2 (SHA2) hash lists of discovered binaries. These binaries' hash
values are updated each time an application is updated, which requires the catalog file to be updated also.
After you have created and signed your catalog files, you can configure your WDAC policies to trust the signer
or signing certificate of those files.
NOTE
Package Inspector only works on operating systems that support Windows Defender, such as Windows 10 Enterprise,
Windows 10 Education, Windows 2016 Server, or Windows Enterprise IoT.
For procedures for working with catalog files, see Deploy catalog files to support Windows Defender Application
Control.
Windows Defender Application Control policy formats and signing

When you generate a WDAC policy, you are generating a binary-encoded XML document that includes
configuration settings for both the User and Kernel-modes of Windows 10 Enterprise, along with restrictions on
Windows 10 script hosts. You can view your original XML document in a text editor, for example if you want to
check the rule options that are present in the <Rules> section of the file.
We recommend that you keep the original XML file for use when you need to merge the WDAC policy with
another policy or update its rule options. For deployment purposes, the file is converted to a binary format,
which can be done using a simple Windows PowerShell command.
When the WDAC policy is deployed, it restricts the software that can run on a device. The XML document can be
signed, helping to add additional protection against administrative users changing or removing the policy.
Optional: Use the Device Guard Signing Portal in
the Microsoft Store for Business
Applies to:
Windows 10
Windows Server 2019
Windows Server 2016
You can sign code integrity policies with the Device Guard signing portal to prevent them from being tampered
with after they're deployed.
Sign your code integrity policy

Before you get started, be sure to review these best practices:
Best practices
Test your code integrity policies on a pilot group of devices before deploying them to production.
Use rule options 9 and 10 during testing. For more information, see the section Code integrity policy rules in
the Deploy Windows Defender Application Control policy rules and file rules.
To sign a code integrity policy
1. Sign in to the Microsoft Store for Business or Microsoft Store for Education.
2. Click Manage , click Store settings , and then click Device Guard .
3. Click Upload to upload your code integrity policy.
4. After the files are uploaded, click Sign to sign the code integrity policy.
5. Click Download to download the signed code integrity policy.
When you sign a code integrity policy with the Device Guard signing portal, the signing certificate is
added to the policy. This means you can't modify this policy. If you need to make changes, make them to
an unsigned version of the policy, and then sign the policy again.
Optional: Create a code signing cert for Windows
Defender Application Control
Applies to:
Windows 10
Windows Server 2016
As you deploy Windows Defender Application Control (WDAC), you might need to sign catalog files or WDAC
policies internally. To do this, you will either need a publicly issued code signing certificate or an internal CA. If
you have purchased a code signing certificate, you can skip this topic and instead follow other topics listed in
the Windows Defender Application Control Deployment Guide.
If you have an internal CA, complete these steps to create a code signing certificate. Only RSA algorithm is
supported for the code signing certificate, and signatures must be PKCS 1.5 padded. ECDSA is not supported.
1. Open the Certification Authority Microsoft Management Console (MMC) snap-in, and then select your
issuing CA.
2. When connected, right-click Cer tificate Templates , and then click Manage to open the Certification
Templates Console.
Figure 1. Manage the certificate templates

3. In the navigation pane, right-click the Code Signing certificate, and then click Duplicate Template .
4. On the Compatibility tab, clear the Show resulting changes check box. Select Windows Ser ver
2012 from the Cer tification Authority list, and then select Windows 8 / Windows Ser ver 2012
from the Cer tificate recipient list.
5. On the General tab, specify the Template display name and Template name . This example uses the
name WDAC Catalog Signing Cer tificate .
6. On the Request Handling tab, select the Allow private key to be expor ted check box.
7. On the Extensions tab, select the Basic Constraints check box, and then click Edit .
8. In the Edit Basic Constraints Extension dialog box, select Enable this extension , as shown in Figure
2.
Figure 2. Select constraints on the new template

9. If a certificate manager is required to approve any issued certificates, on the Issuance Requirements
tab, select CA cer tificate manager approval .
10. On the Subject Name tab, select Supply in the request .
11. On the Security tab, verify that whatever account will be used to request the certificate has the right to
enroll the certificate.
12. Click OK to create the template, and then close the Certificate Template Console.
When this certificate template has been created, you must publish it to the CA published template store. To do
so, complete the following steps:
1. In the Certification Authority MMC snap-in, right-click Cer tification Templates , point to New , and then
click Cer tificate Template to Issue , as shown in Figure 3.
Figure 3. Select the new certificate template to issue
A list of available templates to issue appears, including the template you just created.
2. Select the WDAC Catalog signing certificate, and then click OK .
Now that the template is available to be issued, you must request one from the computer running Windows 10
on which you create and sign catalog files. To begin, open the MMC, and then complete the following steps:
1. In MMC, from the File menu, click Add/Remove Snap-in . Double-click Cer tificates , and then select
My user account .
2. In the Certificates snap-in, right-click the Personal store folder, point to All Tasks , and then click Request
New Cer tificate .
3. Click Next twice to get to the certificate selection list.
4. In the Request Cer tificate list, select your newly created code signing certificate, and then select the
blue text that requests additional information, as shown in Figure 4.
Figure 4. Get more information for your code signing certificate
5. In the Cer tificate Proper ties dialog box, for Type , select Common name . For Value , select
ContosoDGSigningCer t , and then click Add . When added, click OK.
6. Enroll and finish.
NOTE
If a certificate manager is required to approve any issued certificates and you selected to require management approval
on the template, the request will need to be approved in the CA before it will be issued to the client.
This certificate must be installed in the user's personal store on the computer that will be signing the catalog
files and code integrity policies. If the signing is going to be taking place on the computer on which you just
requested the certificate, exporting the certificate to a .pfx file will not be required because it already exists in
your personal store. If you are signing on another computer, you will need to export the .pfx certificate with the
necessary keys and properties. To do so, complete the following steps:
1. Right-click the certificate, point to All Tasks , and then click Expor t .
2. Click Next , and then select Yes, expor t the private key .
3. Choose the default settings, and then select Expor t all extended proper ties .
4. Set a password, select an export path, and then select WDACCatSigningCer t.pfx as the file name.
When the certificate has been exported, import it into the personal store for the user who will be signing the
catalog files or code integrity policies on the specific computer that will be signing them.
Related topics
Windows Defender Application Control Deployment Guide
Deploy catalog files to support Windows Defender
Application Control
Applies to:
Windows 10
Windows Server 2016
Catalog files can be important in your deployment of Windows Defender Application Control (WDAC) if you
have unsigned line-of-business (LOB) applications for which the process of signing is difficult. To prepare to
create WDAC policies that allow these trusted applications but block unsigned code (most malware is unsigned),
you create a catalog file that contains information about the trusted applications. After you sign and distribute
the catalog, your trusted applications can be handled by WDAC in the same way as any other signed application.
With this foundation, you can more easily block all unsigned applications, allowing only signed applications to
run.
Create catalog files

The creation of a catalog file simplifies the steps to run unsigned applications in the presence of a WDAC policy.
To create a catalog file, you use a tool called Package Inspector . You must also have a WDAC policy deployed
in audit mode on the computer on which you run Package Inspector, so that Package Inspector can include any
temporary installation files that are added and then removed from the computer during the installation process.
NOTE
When you establish a naming convention it makes it easier to detect deployed catalog files in the future. In this guide, *-
Contoso.cat is used as the example naming convention.
1. Be sure that a WDAC policy is currently deployed in audit mode on the computer on which you will run
Package Inspector.
Package Inspector does not always detect temporary installation files that are added and then removed
from the computer during the installation process. To ensure that these binaries are also included in your
catalog file, deploy a WDAC policy in audit mode.
NOTE
This process should not be performed on a system with an enforced Windows Defender Application Control
policy, only with a policy in audit mode. If a policy is currently being enforced, you will not be able to install and
run the application unless the policy already allows it.
2. Start Package Inspector, and then start scanning a local drive, for example, drive C:
PackageInspector.exe Start C:
NOTE
Package inspector can monitor installations on any local drive. Specify the appropriate drive on the local computer.
3. Copy the installation media to the local drive (typically drive C).
By copying the installation media to the local drive, you ensure that Package Inspector detects and
catalogs the actual installer. If you skip this step, the future WDAC policy may allow the application to run
but not to be installed.
4. Install the application. Install it to the same drive that the application installer is located on (the drive you
are scanning). Also, while Package Inspector is running, do not run any installations or updates that you
don't want to capture in the catalog.
IMPORTANT
Every binary that is run while Package Inspector is running will be captured in the catalog. Ensure that only
trusted applications are run during this time.
5. Start the application.

6. Ensure that product updates are installed, and downloadable content associated with the application is
downloaded.
7. Close and reopen the application.
This step is necessary to ensure that the scan has captured all binaries.
8. As appropriate, with Package Inspector still running, repeat the process for another application that you
want in the catalog. Copy the installation media to the local drive, install the application, ensure it is
updated, and then close and reopen the application.
9. When you have confirmed that the previous steps are complete, use the following commands to generate
the catalog and definition files on your computer's desktop. The filenames used in these example
commands are LOBApp-Contoso.cat (catalog file) and LOBApp.cdf (definition file)—substitute
different filenames as appropriate.
For the last command, which stops Package Inspector, be sure to type the drive letter of the drive you
have been scanning, for example, C:.
$ExamplePath=$env:userprofile+"\Desktop"
$CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"
$CatDefName=$ExamplePath+"\LOBApp.cdf"
PackageInspector.exe Stop C: -Name $CatFileName -cdfpath $CatDefName
NOTE
Package Inspector catalogs the hash values for each discovered binary file. If the applications that were scanned are
updated, complete this process again to trust the new binaries' hash values.
When finished, the files will be saved to your desktop. You can double-click the *.cat file to see its contents, and
you can view the *.cdf file with a text editor.
To trust the contents of the catalog file within a WDAC policy, the catalog must first be signed. Then, the signing
certificate can be added to the WDAC policy, and the catalog file can be distributed to the individual client
computers.
Resolving package failures
Packages can fail for the following reasons:
Package is too large for default USN Journal or Event Log sizes
To diagnose whether USN journal size is the issue, after running through Package Inspector, click Start
> install app > PackageInspector stop
Get the value of the reg key at HKEY_CURRENT_USER/PackageInspectorRegistryKey/c: (this was
the most recent USN when you ran PackageInspector start)
fsutil usn readjournal C: startusn=RegKeyValue > inspectedusn.txt
ReadJournal command should throw an error if the older USNs don't exist anymore due to
overflow
For USN Journal, log size can be expanded using: fsutil usn createjournal command with a new size
and alloc delta. Fsutil usn queryjournal will give the current size and allocation delta, so using a
multiple of that may help
To diagnose whether Eventlog size is the issue, look at the
Microsoft/Windows/CodeIntegrity/Operational log under Applications and Services logs in Event
Viewer and ensure that there are entries present from when you began Package Inspector (You can
use write time as a justification; if you started the install 2 hours ago and there are only entries from
30 minutes prior, the log is definitely too small)
To increase Eventlog size, in Event Viewer you can right click the operational log, click properties, and
then set new values (some multiple of what it was previously)
Package files that change hash each time the package is installed
Package Inspector is completely incompatible if files in the package (temporary or otherwise) change
hash each time the package is installed. You can diagnose this by looking at the hash field in the 3077
block events when the package is failing in enforcement. If each time you attempt to run the package
you get a new block event with a different hash, the package will not work with Package Inspector
Files with an invalid signature blob or otherwise "unhashable" files
This issue arises when a file that has been signed is modified post signing in a way that invalidates the
PE header and renders the file unable to be hashed by the Authenticode Spec.
WDAC uses Authenticode Hashes to validate files when they are running. If the file is unhashable via
the authenticode SIP, there is no way to identify the file to allow it, regardless of if you attempt to add
the file to the policy directly, or re-sign the file with a Package Inspector catalog (the signature is
invalidated due to file being edited, file can't be allowed by hash due to authenticode hashing
algorithm rejecting it)
Recent versions of InstallShield packages that use custom actions can hit this. If the DLL input to the
custom action was signed before being put through InstallShield, InstallShield adds tracking markers
to the file (editing it post signature) which leaves the file in this "unhashable" state and renders the file
unable to be allowed by Windows Defender (regardless of if you try to allow directly by policy or
resign with Package Inspector)
Catalog signing with SignTool.exe

To sign a catalog file you generated by using PackageInspector.exe, you need the following:
SignTool.exe, found in the Windows software development kit (SDK—Windows 7 or later)
The catalog file that you generated previously
An internal certification authority (CA) code signing certificate or purchased code signing certificate
To sign the existing catalog file, copy each of the following commands into an elevated Windows PowerShell
session.
1. Initialize the variables that will be used. Replace the $ExamplePath and $CatFileName variables as needed:
$ExamplePath=$env:userprofile+"\Desktop"
$CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"
2. Import the code signing certificate that will be used to sign the catalog file. Import it to the signing user's
personal store.
3. Sign the catalog file with Signtool.exe:
<path to signtool.exe> sign /n "ContosoDGSigningCert" /fd sha256 /v $CatFileName
NOTE
The <Path to signtool.exe> variable should be the full path to the Signtool.exe utility. ContosoDGSigningCert
represents the subject name of the certificate that you will use to sign the catalog file. This certificate should be
imported to your personal certificate store on the computer on which you are attempting to sign the catalog file.
For additional information about Signtool.exe and all additional switches, visit the Sign Tool page.
4. Verify the catalog file digital signature. Right-click the catalog file, and then click Proper ties . On the
Digital Signatures tab, verify that your signing certificate exists with a sha256 algorithm, as shown in
Figure 1.
Figure 1. Verify that the signing certificate exists

5. Copy the catalog file to C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}.
For testing purposes, you can manually copy signed catalog files to their intended folder. For large-scale
implementations, to copy the appropriate catalog files to all desired computers, we recommend that you
use Group Policy File Preferences or an enterprise systems management product such as Microsoft
Endpoint Configuration Manager. Doing this also simplifies the management of catalog versions.
Add a catalog signing certificate to a Windows Defender Application

Control policy
After the catalog file is signed, add the signing certificate to a WDAC policy, as described in the following steps.
1. If you have not already verified the catalog file digital signature, right-click the catalog file, and then click
Proper ties . On the Digital Signatures tab, verify that your signing certificate exists with the algorithm
you expect.
2. If you already have an XML policy file that you want to add the signing certificate to, skip to the next step.
Otherwise, use New-CIPolicy to create a WDAC policy that you will later merge into another policy (not
deploy as-is). This example creates a policy called CatalogSignatureOnly.xml in the location
C:\PolicyFolder :
New-CIPolicy -Level PcaCertificate -FilePath C:\PolicyFolder\CatalogSignatureOnly.xml –UserPEs
NOTE
Include the -UserPEs parameter to ensure that the policy includes user mode code integrity.
3. Use Add-SignerRule to add the signing certificate to the WDAC policy, filling in the correct path and
filenames for <policypath> and <certpath> :
Add-SignerRule -FilePath <policypath> -CertificatePath <certpath> -User
If you used step 2 to create a new WDAC policy, and want information about merging policies together, see
Merge Windows Defender Application Control policies.
Deploy catalog files with Group Policy

To simplify the management of catalog files, you can use Group Policy preferences to deploy catalog files to the
appropriate computers in your organization. The following process walks you through the deployment of a
signed catalog file called LOBApp-Contoso.cat to a test OU called DG Enabled PCs with a GPO called Contoso
DG Catalog File GPO Test .
To deploy a catalog file with Group Policy:
1. From either a domain controller or a client computer that has Remote Server Administration Tools (RSAT)
installed, open the Group Policy Management Console (GPMC) by running GPMC.MSC or by searching
for Group Policy Management.
2. Create a new GPO: right-click an OU, for example, the DG Enabled PCs OU , and then click Create a
GPO in this domain, and Link it here , as shown in Figure 2.
NOTE
You can use any OU name. Also, security group filtering is an option when you consider different ways of
combining WDAC policies (or keeping them separate).
Figure 2. Create a new GPO
3. Give the new GPO a name, for example, Contoso DG Catalog File GPO Test , or any name you prefer.
4. Open the Group Policy Management Editor: right-click the new GPO, and then click Edit .
5. Within the selected GPO, navigate to Computer Configuration\Preferences\Windows Settings\Files.
Right-click Files , point to New , and then click File , as shown in Figure 3.
Figure 3. Create a new file

6. Configure the catalog file share.
To use this setting to provide consistent deployment of your catalog file (in this example, LOBApp-
Contoso.cat), the source file should be on a share that is accessible to the computer account of every
deployed computer. This example uses a share (on a computer running Windows 10) called \\Contoso-
Win10\Share. The catalog file being deployed is copied to this share.
7. To keep versions consistent, in the New File Proper ties dialog box (Figure 4), select Replace from the
Action list so that the newest version is always used.
Figure 4. Set the new file properties
8. In the Source file(s) box, type the name of your accessible share, with the catalog file name included (for
example, \\Contoso-Win10\share\LOBApp-Contoso.cat).
9. In the Destination File box, type a path and file name, for example:
C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\LOBApp-
Contoso.cat
For the catalog file name, use the name of the catalog you are deploying.
10. On the Common tab of the New File Proper ties dialog box, select the Remove this item when it is
no longer applied option. Doing this ensures that the catalog file is removed from every system, in
case you ever need to stop trusting this application.
11. Click OK to complete file creation.
12. Close the Group Policy Management Editor, and then update the policy on the test computer running
Windows 10, by running GPUpdate.exe. When the policy has been updated, verify that the catalog file
exists in C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} on the computer
running Windows 10.
Before you begin testing the deployed catalog file, make sure that the catalog signing certificate has been added
to an appropriate WDAC policy.
Deploy catalog files with Microsoft Endpoint Configuration Manager

As an alternative to Group Policy, you can use Configuration Manager to deploy catalog files to the managed
computers in your environment. This approach can simplify the deployment and management of multiple
catalog files as well as provide reporting around which catalog each client or collection has deployed. In addition
to the deployment of these files, Configuration Manager can also be used to inventory the currently deployed
catalog files for reporting and compliance purposes. Complete the following steps to create a new deployment
package for catalog files:
NOTE
The following example uses a network share named \\Shares\CatalogShare as a source for the catalog files. If you have
collection specific catalog files, or prefer to deploy them individually, use whichever folder structure works best for your
organization.
1. Open the Configuration Manager console, and select the Software Library workspace.
2. Navigate to Overview\Application Management, right-click Packages , and then click Create Package .
3. Name the package, set your organization as the manufacturer, and select an appropriate version number.
Figure 5. Specify information about the new package

4. Click Next , and then select Standard program as the program type.
5. On the Standard Program page, select a name, and then set the Command Line property to XCopy
\\Shares\CatalogShare C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-
00C04FC295EE} /H /K /E /Y .
6. On the Standard Program page, select the following options (Figure 6):
In Name , type a name such as Contoso Catalog File Copy Program .
In Command line , browse to the program location.
In Star tup folder , type C:\Windows\System32 .
From the Run list, select Hidden .
From the Program can run list, select Whether or not a user is logged on .
From the Drive mode list, select Runs with UNC name .
Figure 6. Specify information about the standard program

7. Accept the defaults for the rest of the wizard, and then close the wizard.
After you create the deployment package, deploy it to a collection so that the clients will receive the catalog files.
In this example, you deploy the package you just created to a test collection:
1. In the Software Library workspace, navigate to Overview\Application Management\Packages, right-click
the catalog file package, and then click Deploy .
2. On the General page, select the test collection to which the catalog files will be deployed, and then click
Next .
3. On the Content page, click Add to select the distribution point that will serve content to the selected
collection, and then click Next .
4. On the Deployment Settings page, select Required in the Purpose box.
5. On the Scheduling page, click New .
6. In the Assignment Schedule dialog box, select Assign immediately after this event , set the value to
As soon as possible , and then click OK .
7. On the Scheduling page, click Next .
8. On the User Experience page (Figure 7), set the following options, and then click Next :
Select the Software installation check box.
Select the Commit changes at deadline or during a maintenance window (requires
restar ts) check box.
Figure 7. Specify the user experience
9. On the Distribution Points page, in the Deployment options box, select Run program from
distribution point , and then click Next .
10. On the Summar y page, review the selections, and then click Next .
11. Close the wizard.
Before you begin testing the deployed catalog file, make sure that the catalog signing certificate has been added
to an appropriate WDAC policy,.
Inventory catalog files with Microsoft Endpoint Configuration

Manager
When catalog files have been deployed to the computers within your environment, whether by using Group
Policy or Configuration Manager, you can inventory them with the software inventory feature of Configuration
Manager. The following process walks you through the enablement of software inventory to discover catalog
files on your managed systems through the creation and deployment of a new client settings policy.
NOTE
A standard naming convention for your catalog files will significantly simplify the catalog file software inventory process.
In this example, -Contoso has been added to all catalog file names.
1. Open the Configuration Manager console, and select the Administration workspace.
2. Navigate to Over view\Client Settings , right-click Client Settings , and then click Create Custom
Client Device Settings .
3. Name the new policy, and under Select and then configure the custom settings for client
devices , select the Software Inventor y check box, as shown in Figure 8.
Figure 8. Select custom settings

4. In the navigation pane, click Software Inventor y , and then click Set Types , as shown in Figure 9.
Figure 9. Set the software inventory

5. In the Configure Client Setting dialog box, click the Star t button to open the Inventories File
Proper ties dialog box.
6. In the Name box, type a name such as *Contoso.cat , and then click Set .
NOTE
When typing the name, follow your naming convention for catalog files.
7. In the Path Proper ties dialog box, select Variable or path name , and then type
C:\Windows\System32\catroot\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} in the box, as
shown in Figure 10.
Figure 10. Set the path properties

8. Click OK .
9. Now that you have created the client settings policy, right-click the new policy, click Deploy , and then
choose the collection on which you would like to inventory the catalog files.
At the time of the next software inventory cycle, when the targeted clients receive the new client settings policy,
you will be able to view the inventoried files in the built-in Configuration Manager reports or Resource Explorer.
To view the inventoried files on a client within Resource Explorer, complete the following steps:
1. Open the Configuration Manager console, and select the Assets and Compliance workspace.
2. Navigate to Overview\Devices, and search for the device on which you want to view the inventoried files.
3. Right-click the computer, point to Star t , and then click Resource Explorer .
4. In Resource Explorer, navigate to Software\File Details to view the inventoried catalog files.
NOTE
If nothing is displayed in this view, navigate to Software\Last Software Scan in Resource Explorer to verify that the client
has recently completed a software inventory scan.
Related topics
Windows Defender Application Control Design Guide
Windows Defender Application Control Deployment Guide
Use signed policies to protect Windows Defender
Application Control against tampering
Applies to:
Windows 10
Windows Server 2016
Signed WDAC policies give organizations the highest level of malware protection available in Windows 10. In
addition to their enforced policy rules, signed policies cannot be modified or deleted by a user or administrator
on the computer. These policies are designed to prevent administrative tampering and kernel mode exploit
access. With this in mind, it is much more difficult to remove signed WDAC policies. Note that SecureBoot must
be enabled in order to restrict users from updating or removing signed WDAC policies.
Before you sign and deploy a signed WDAC policy, we recommend that you audit the policy to discover any
blocked applications that should be allowed to run.
Signing WDAC policies by using an on-premises CA-generated certificate or a purchased code signing
certificate is straightforward. If you do not currently have a code signing certificate exported in .pfx format
(containing private keys, extensions, and root certificates), see Optional: Create a code signing certificate for
Windows Defender Application Control to create one with your on-premises CA.
Before signing WDAC policies for the first time, be sure to enable rule options 9 (“Advanced Boot Options
Menu”) and 10 (“Boot Audit on Failure”) to leave troubleshooting options available to administrators. To ensure
that a rule option is enabled, you can run a command such as
Set-RuleOption -FilePath <PathAndFilename> -Option 9 even if you're not sure whether the option is already
enabled—if so, the command has no effect. When validated and ready for enterprise deployment, you can
remove these options. For more information about rule options, see Windows Defender Application Control
policy rules.
To sign a WDAC policy with SignTool.exe, you need the following components:
SignTool.exe, found in the Windows SDK (Windows 7 or later)
The binary format of the WDAC policy that you generated in Create a Windows Defender Application
Control policy from a reference computer or another WDAC policy that you have created
An internal CA code signing certificate or a purchased code signing certificate
If you do not have a code signing certificate, see Optional: Create a code signing certificate for Windows
Defender Application Control for instructions on how to create one. If you use an alternate certificate or WDAC
policy, be sure to update the following steps with the appropriate variables and certificate so that the commands
will function properly. To sign the existing WDAC policy, copy each of the following commands into an elevated
Windows PowerShell session:
$CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"
NOTE
This example uses the WDAC policy that you created in the Create a Windows Defender Application Control policy
from a reference computer section. If you are signing another policy, be sure to update the $CIPolicyPath and
$CIPolicyBin variables with the correct information.
2. Import the .pfx code signing certificate. Import the code signing certificate that you will use to sign the
WDAC policy into the signing user’s personal store on the computer that will be doing the signing. In this
example, you use the certificate that was created in Optional: Create a code signing certificate for
Windows Defender Application Control.
3. Export the .cer code signing certificate. After the code signing certificate has been imported, export the
.cer version to your desktop. This version will be added to the policy so that it can be updated later.
4. Navigate to your desktop as the working directory:
cd $env:USERPROFILE\Desktop
5. Use Add-SignerRule to add an update signer certificate to the WDAC policy:

Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath <Path to exported .cer certificate> -Kernel
-User –Update
NOTE
<Path to exported .cer certificate> should be the full path to the certificate that you exported in step 3. Also,
adding update signers is crucial to being able to modify or disable this policy in the future. For more information
about how to disable signed WDAC policies, see Disable signed Windows Defender Application Control policies
within Windows.
6. Use Set-RuleOption to remove the unsigned policy rule option:

Set-RuleOption -FilePath $InitialCIPolicy -Option 6 -Delete
7. Use ConvertFrom-CIPolicy to convert the policy to binary format:

ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin
8. Sign the WDAC policy by using SignTool.exe:

<Path to signtool.exe> sign -v /n "ContosoDGSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256
$CIPolicyBin
NOTE
The <Path to signtool.exe> variable should be the full path to the SignTool.exe utility. ContosoDGSigningCer t is
the subject name of the certificate that will be used to sign the WDAC policy. You should import this certificate to
your personal certificate store on the computer you use to sign the policy.
9. Validate the signed file. When complete, the commands should output a signed policy file called
DeviceGuardPolicy.bin.p7 to your desktop. You can deploy this file the same way you deploy an enforced
or non-enforced policy. For information about how to deploy WDAC policies, see Deploy and manage
Windows Defender Application Control with Group Policy.
Disable Windows Defender Application Control
policies
Applies to:
Windows 10
Windows Server 2016
This topic covers how to disable unsigned or signed WDAC policies.
Disable unsigned Windows Defender Application Control policies

There may come a time when an administrator wants to disable a WDAC policy. For unsigned WDAC policies,
this process is simple. The method used to deploy the policy (such as Group Policy) must first be disabled, then
simply delete the SIPolicy.p7b policy file from the following locations, and the WDAC policy will be disabled on
the next computer restart:
<EFI System Partition>\Microsoft\Boot\
<OS Volume>\Windows\System32\CodeIntegrity\
Note that as of the Windows 10 May 2019 Update (1903), WDAC allows multiple policies to be deployed to a
device. To fully disable WDAC when multiple policies are in effect, you must first disable each method being
used to deploy a policy. Then delete the {Policy GUID}.cip policy files found in the \CIPolicies\Active subfolder
under each of the paths listed above in addition to any SIPolicy.p7b file found in the root directory.
Disable signed Windows Defender Application Control policies within

Windows
Signed policies protect Windows from administrative manipulation as well as malware that has gained
administrative-level access to the system. For this reason, signed WDAC policies are intentionally more difficult
to remove than unsigned policies. They inherently protect themselves from modification or removal and
therefore are difficult even for administrators to remove successfully. If the signed WDAC policy is manually
enabled and copied to the CodeIntegrity folder, to remove the policy, you must complete the following steps.
NOTE
For reference, signed WDAC policies should be replaced and removed from the following locations:

1. Replace the existing policy with another signed policy that has the 6 Enabled: Unsigned System
Integrity Policy rule option enabled.
Note To take effect, this policy must be signed with a certificate previously added to the
UpdatePolicySigners section of the original signed policy you want to replace.
2. Restart the client computer.
3. Verify that the new signed policy exists on the client.
Note If the signed policy that contains rule option 6 has not been processed on the client, the
addition of an unsigned policy may cause boot failures.
4. Delete the new policy.

If the signed WDAC policy has been deployed using by using Group Policy, you must complete the following
steps:
1. Replace the existing policy in the GPO with another signed policy that has the 6 Enabled: Unsigned
System Integrity Policy rule option enabled.
Note To take effect, this policy must be signed with a certificate previously added to the
UpdatePolicySigners section of the original signed policy you want to replace.

3. Verify that the new signed policy exists on the client.
Note If the signed policy that contains rule option 6 has not been processed on the client, the
addition of an unsigned policy may cause boot failures.
4. Set the GPO to disabled.

5. Delete the new policy.
Disable signed Windows Defender Application Control policies within

the BIOS
There may be a time when signed WDAC policies cause a boot failure. Because WDAC policies enforce kernel
mode drivers, it is important that they be thoroughly tested on each software and hardware configuration
before being enforced and signed. Signed WDAC policies are validated in the pre-boot sequence by using
Secure Boot. When you disable the Secure Boot feature in the BIOS, and then delete the file from the following
locations on the operating system disk, it allows the system to boot into Windows:
Allow Line-of-Business Win32 Apps on Intune-
Managed S Mode Devices
Applies to:
Windows 10
Beginning with the Windows 10 November 2019 update (build 18363), Microsoft Intune enables customers to
deploy and run business critical Win32 applications as well as Windows components that are normally blocked
in S mode (ex. PowerShell.exe) on their Intune-managed Windows 10 in S mode devices.
With Intune, IT Pros can now configure their managed S mode devices using a Windows Defender Application
Control (WDAC) supplemental policy that expands the S mode base policy to authorize the apps their business
uses. This feature changes the S mode security posture from "every app is Microsoft-verified" to "every app is
verified by Microsoft or your organization".
Refer to the below video for an overview and brief demo.
Policy Authorization Process
The general steps for expanding the S mode base policy on your Intune-managed devices are to generate a
supplemental policy, sign that policy, and then upload the signed policy to Intune and assign it to user or device
groups. Because you need access to WDAC PowerShell cmdlets to generate your supplemental policy, you
should create and manage your policies on a non-S mode device. Once the policy has been uploaded to Intune,
we recommend assigning it to a single test S-mode device to verify expected functioning before deploying the
policy more broadly.
1. Generate a supplemental policy with WDAC tooling
This policy will expand the S mode base policy to authorize additional applications. Anything authorized
by either the S mode base policy or your supplemental policy will be allowed to run. Your supplemental
policies can specify filepath rules, trusted publishers, and more.
Refer to Deploy multiple Windows Defender Application Control Policies for guidance on creating
supplemental policies and Deploy Windows Defender Application Control policy rules and file rules to
choose the right type of rules to create for your policy.
Below are a basic set of instructions for creating an S mode supplemental policy:
Create a new base policy using New-CIPolicy
New-CIPolicy -MultiplePolicyFormat -ScanPath <path> -UserPEs -FilePath "
<path>\SupplementalPolicy.xml" -Level Publisher -Fallback Hash
Change it to a supplemental policy using Set-CIPolicyIdInfo
Set-CIPolicyIdInfo -SupplementsBasePolicyID 5951A96A-E0B5-4D3D-8FB8-3E5B61030784 -FilePath "

<path>\SupplementalPolicy.xml"
Policies which are supplementing the S mode base policy must use -SupplementsBasePolicyID
5951A96A-E0B5-4D3D-8FB8-3E5B61030784 , as this is the S mode policy ID.
Put the policy in enforce mode using Set-RuleOption
Set-RuleOption -FilePath "<path>\SupplementalPolicy.xml>" -Option 3 –Delete
This deletes the 'audit mode' qualifier.

Since you'll be signing your policy, you must authorize the signing certificate you will use to sign
the policy and optionally one or more additional signers that can be used to sign updates to the
policy in the future. For more information, refer to Section 2, Sign policy. Use Add-SignerRule to
add the signing certificate to the WDAC policy:
Add-SignerRule -FilePath <policypath> -CertificatePath <certpath> -User -Update
Convert to .bin using ConvertFrom-CIPolicy
ConvertFrom-CIPolicy -XmlFilePath "<path>\SupplementalPolicy.xml" -BinaryFilePath "

<path>\SupplementalPolicy.bin>
2. Sign policy
Supplemental S mode policies must be digitally signed. To sign your policy, you can choose to use the
Device Guard Signing Service (DGSS) or your organization's custom Public Key Infrastructure (PKI). Refer
to Use the Device Guard Signing Portal in the Microsoft Store for Business for guidance on using DGSS
and Create a code signing cert for WDAC for guidance on signing using an internal CA.
Rename your policy to "{PolicyID}.p7b" after you've signed it. PolicyID can be found by inspecting the
Supplemental Policy XML.
3. Deploy the signed supplemental policy using Microsoft Intune
Go to the Azure portal online and navigate to the Microsoft Intune page, then go to the Client apps blade
and select 'S mode supplemental policies'. Upload the signed policy to Intune and assign it to user or
device groups. Intune will generate tenant- and device- specific authorization tokens. Intune then deploys
the corresponding authorization token and supplemental policy to each device in the assigned group.
Together, these expand the S mode base policy on the device.
NOTE
When updating your supplemental policy, ensure that the new version number is strictly greater than the previous one.
Using the same version number is not allowed by Intune. Refer to Set-CIPolicyVersion for information on setting the
version number.
Standard Process for Deploying Apps through Intune
Refer to Intune Standalone - Win32 app management for guidance on the existing procedure of packaging
signed catalogs and app deployment.
Optional: Process for Deploying Apps using Catalogs
Your supplemental policy can be used to significantly relax the S mode base policy, but there are security trade-
offs you must consider in doing so. For example, you can use a signer rule to trust an external signer, but that
will authorize all apps signed by that certificate, which may include apps you don't want to allow as well.
Instead of authorizing signers external to your organization, Intune has added new functionality to make it
easier to authorize existing applications (without requiring repackaging or access to the source code) through
the use of signed catalogs. This works for apps which may be unsigned or even signed apps when you don't
want to trust all apps that may share the same signing certificate.
The basic process is to generate a catalog file for each app using Package Inspector, then sign the catalog files
using the DGSS or a custom PKI. Use the Add-SignerRule PowerShell cmdlet as shown above to authorize the
catalog signing certificate in the supplemental policy. After that, IT Pros can use the standard Intune app
deployment process outlined above. Refer to Deploy catalog files to support Windows Defender Application
Control for more in-depth guidance on generating catalogs.
NOTE
Every time an app updates, you will need to deploy an updated catalog. Because of this, IT Pros should try to avoid using
catalog files for applications that auto-update and direct users not to update applications on their own.
Sample policy
Below is a sample policy that allows kernel debuggers, PowerShell ISE, and Registry Editor. It also demonstrates
how to specify your organization's code signing and policy signing certificates.

<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy" PolicyType="Supplemental Policy">

<BasePolicyID>{5951A96A-E0B5-4D3D-8FB8-3E5B61030784}</BasePolicyID>

<PolicyID>{52671094-ACC6-43CF-AAF1-096DC69C1345}</PolicyID>

<EKUs />

<FileRules>

<Allow ID="ID_ALLOW_CBD_0" FriendlyName="cdb.exe" FileName="CDB.Exe" />
<Allow ID="ID_ALLOW_KD_0" FriendlyName="kd.exe" FileName="kd.Exe" />
<Allow ID="ID_ALLOW_WINDBG_0" FriendlyName="windbg.exe" FileName="windbg.Exe" />
<Allow ID="ID_ALLOW_MSBUILD_0" FriendlyName="MSBuild.exe" FileName="MSBuild.Exe" />
<Allow ID="ID_ALLOW_NTSD_0" FriendlyName="ntsd.exe" FileName="ntsd.Exe" />

<Allow ID="ID_ALLOW_POWERSHELLISE_0" FriendlyName="powershell_ise.exe" FileName="powershell_ise.exe" />
<Allow ID="ID_ALLOW_REGEDIT_0" FriendlyName="regedit.exe" FileName="regedit.exe" />
</FileRules>

<Signers>

<Signer ID="EXAMPLE_ID_SIGNER_CODE" Name="Example Code Signing Certificate Friendly Name">
<CertRoot Type="TBS" Value="<value>" />
</Signer>


<Signer ID="EXAMPLE_ID_SIGNER_POLICY" Name="Example Policy Signing Certificate Friendly Name">
</Signer>
</Signers>
<SigningScenarios>
<SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_KMCI" FriendlyName="Example Name">
<ProductSigners />
</SigningScenario>
<SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_UMCI" FriendlyName="Example Name">
<ProductSigners>
<AllowedSigners>
<AllowedSigner SignerId="EXAMPLE_ID_SIGNER_CODE" />
</AllowedSigners>
<FileRulesRef>
<FileRuleRef RuleID="ID_ALLOW_CBD_0" />
<FileRuleRef RuleID="ID_ALLOW_KD_0" />
<FileRuleRef RuleID="ID_ALLOW_WINDBG_0" />
<FileRuleRef RuleID="ID_ALLOW_MSBUILD_0" />
<FileRuleRef RuleID="ID_ALLOW_NTSD_0" />
<FileRuleRef RuleID="ID_ALLOW_POWERSHELLISE_0" />
<FileRuleRef RuleID="ID_ALLOW_REGEDIT_0" />
</FileRulesRef>
</ProductSigners>
</SigningScenario>
</SigningScenarios>

<UpdatePolicySigners>
<UpdatePolicySigner SignerId="EXAMPLE_ID_SIGNER_POLICY" />
</UpdatePolicySigners>

<CiSigners>
<CiSigner SignerId="EXAMPLE_ID_SIGNER_CODE" />
</CiSigners>

<Settings>
<Value>
<String>Example Policy Name</String>
</Value>
</Setting>
<Value>
<String>Example-Policy-10.0.0.0</String>
</Value>
</Setting>
</Settings>
</SiPolicy>
Policy removal
In order to revert users to an unmodified S mode policy, an IT Pro can remove a user or users from the targeted
Intune group which received the policy, which will trigger a removal of both the policy and the authorization
token from the device.
IT Pros also have the choice of deleting a supplemental policy through Intune.

<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy" PolicyType="Supplemental Policy">
<PolicyID>{52671094-ACC6-43CF-AAF1-096DC69C1345}</PolicyID>
<Rules>
</Rules>

<EKUs />


<Signers>

<Signer ID="EXAMPLE_ID_SIGNER_POLICY" Name="Example Policy Signing Certificate Friendly Name">
</Signer>
</Signers>
<SigningScenarios>
<SigningScenario Value="131" ID="ID_SIGNINGSCENARIO_KMCI" FriendlyName="KMCI">
<ProductSigners>
</ProductSigners>
</SigningScenario>
<SigningScenario Value="12" ID="ID_SIGNINGSCENARIO_UMCI" FriendlyName="UMCI">
<ProductSigners>
</ProductSigners>
</SigningScenario>
</SigningScenarios>
<UpdatePolicySigners>
<UpdatePolicySigner SignerId="EXAMPLE_ID_SIGNER_POLICY" />
</UpdatePolicySigners>

<Settings>
<Value>
<String>Example Policy Name - Empty</String>
</Value>
</Setting>
<Value>
<String>Example-Policy-Empty-10.0.0.1</String>
</Value>
</Setting>
</Settings>
</SiPolicy>
Errata
If an S-mode device with a policy authorization token and supplemental policy is rolled back from the 1909
update to the 1903 build, it will not revert to locked-down S mode until the next policy refresh. To achieve an
immediate change to a locked-down S mode state, IT Pros should delete any tokens in
%SystemRoot%\System32\CI\Tokens\Active.
Windows Defender Application Control operational
guide
Applies to
Windows 10
After designing and deploying your Windows Defender Application Control (WDAC) policies, this guide covers
understanding the effects your policies are having and troubleshooting when they are not behaving as expected.
It contains information on where to find events and what they mean, and also querying these events with
Microsoft Defender for Endpoint Advanced Hunting feature.
WDAC Events Overview

WDAC generates and logs events when a policy is loaded as well as when a binary attempts to execute and is
blocked. These events include information that identifies the policy and gives more details about the block.
Generally, WDAC does not generate events when a binary is allowed; however, there is the option to enable
events when Managed Installer and/or the Intelligent Security Graph (ISG) is configured.
WDAC events are generated under two locations:
Applications and Services logs – Microsoft – Windows – CodeIntegrity – Operational
Applications and Services logs – Microsoft – Windows – AppLocker – MSI and Script
In this section
Understanding Application Control event IDs This topic explains the meaning of different WDAC event IDs.
Understanding Application Control event tags This topic explains the meaning of different WDAC event
tags.
Query WDAC events with Advanced hunting This topic covers how to view WDAC events centrally from
all systems that are connected to Microsoft Defender for
Endpoint.
Understanding Application Control events
A Windows Defender Application Control (WDAC) policy logs events locally in Windows Event Viewer in either
enforced or audit mode. These events are generated under two locations:
Event IDs beginning with 30 appear in Applications and Services logs – Microsoft – Windows –
CodeIntegrity – Operational
Event IDs beginning with 80 appear in Applications and Services logs – Microsoft – Windows –
AppLocker – MSI and Script
Microsoft Windows CodeIntegrity Operational log event IDs

EVEN T ID EXP L A N AT IO N
3076 Audit executable/dll file
3077 Block executable/dll file
3089 Signing information event correlated with either a 3076 or

3077 event. One 3089 event is generated for each signature
of a file. Contains the total number of signatures on a file
and an index as to which signature it is.
Unsigned files will generate a single 3089 event with
TotalSignatureCount 0. Correlated in the "System" portion of
the event data under "Correlation ActivityID".
3099 Indicates that a policy has been loaded
Microsoft Windows Applocker MSI and Script log event IDs

8028 Audit script/MSI file generated by

Windows LockDown Policy (WLDP)
being called by the scripthosts
themselves. Note: there is no WDAC
enforcement on 3rd party scripthosts.
8029 Block script/MSI file

8038 Signing information event correlated

with either a 8028 or 8029 event. One
8038 event is generated for each
signature of a script file. Contains the
total number of signatures on a script
file and an index as to which signature
it is. Unsigned script files will generate
a single 8038 event with
TotalSignatureCount 0. Correlated in
the "System" portion of the event data
under "Correlation ActivityID".
Optional Intelligent Security Graph (ISG) or Managed Installer (MI)

diagnostic events
If either the ISG or MI is enabled in a WDAC policy, you can optionally choose to enable 3090, 3091, and 3092
events to provide additional diagnostic information.
3090 Allow executable/dll file
3091 Audit executable/dll file
3092 Block executable/dll file
3090, 3091, and 3092 events are generated based on the status code of whether a binary passed the policy,
regardless of what reputation it was given or whether it was allowed by a designated MI. The SmartLocker
template which appears in the event should indicate why the binary passed/failed. Only one event is generated
per binary pass/fail. If both ISG and MI are disabled, 3090, 3091, and 3092 events will not be generated.
SmartLocker template
Below are the fields which help to diagnose what a 3090, 3091, or 3092 event indicates.
NAME EXP L A N AT IO N
StatusCode STATUS_SUCCESS indicates a binary passed the active WDAC

policies. If so, a 3090 event is generated. If not, a 3091 event
is generated if the blocking policy is in audit mode, and a
3092 event is generated if the policy is in enforce mode.
ManagedInstallerEnabled Policy trusts a MI
PassesManagedInstaller File originated from a trusted MI
SmartlockerEnabled Policy trusts the ISG
PassesSmartlocker File had positive reputation
AuditEnabled True if the policy is in audit mode, otherwise it is in enforce

mode
Enabling ISG and MI diagnostic events

In order to enable 3091 audit events and 3092 block events, you must create a TestFlags regkey with a value of
0x100. You can do so using the following PowerShell command:
reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x100
In order to enable 3090 allow events as well as 3091 and 3092 events, you must instead create a TestFlags
regkey with a value of 0x300. You can do so using the following PowerShell command:
reg add hklm\system\currentcontrolset\control\ci -v TestFlags -t REG_DWORD -d 0x300

Understanding Application Control event tags
Windows Defender Application Control (WDAC) events include a number of fields which provide helpful
troubleshooting information to figure out exactly what an event means. Below, we have documented the values
and meanings for a few useful event tags.
SignatureType
Represents the type of signature which verified the image.
SIGN AT URET Y P E VA L UE EXP L A N AT IO N
0 Unsigned or verification has not been attempted
1 Embedded signature
2 Cached signature; presence of CI EA shows that file had

been previously verified
4 Un-cached catalog verified via Catalog Database or

searching catalog directly
5 Successfully verified using an EA that informs CI which

catalog to try first
6 AppX / MSIX package catalog verified
7 File was verified
ValidatedSigningLevel
Represents the signature level at which the code was verified.
VA L IDAT EDSIGN IN GL EVEL VA L UE EXP L A N AT IO N
0 Signing level has not yet been checked
1 File is unsigned
2 Trusted by WDAC policy
3 Developer signed code
4 Authenticode signed
5 Microsoft Store signed app PPL (Protected Process Light)
6 Microsoft Store-signed
VA L IDAT EDSIGN IN GL EVEL VA L UE EXP L A N AT IO N
7 Signed by an Antimalware vendor whose product is using

AMPPL
8 Microsoft signed
11 Only used for signing of the .NET NGEN compiler
12 Windows signed
14 Windows Trusted Computing Base signed
VerificationError
Represents why verification failed, or if it succeeded.
VERIF IC AT IO N ERRO R VA L UE EXP L A N AT IO N
0 Successfully verified signature
2 File contains shared writable sections
4 Revoked signature
5 Expired signature
7 Invalid root certificate
8 Signature was unable to be validated; generic error
9 Signing time not trusted
12 Not valid for a PPL (Protected Process Light)
13 Not valid for a PP (Protected Process)
15 Failed WHQL check
16 Default policy signing level not met
17 Custom policy signing level not met; returned when

signature doesn't validate against an SBCP-defined set of
certs
18 Custom signing level not met; returned if signature fails to

match CISigners in UMCI
19 Binary is revoked by file hash
20 SHA1 cert hash's timestamp is missing or after valid cutoff as

defined by Weak Crypto Policy
VERIF IC AT IO N ERRO R VA L UE EXP L A N AT IO N
21 Failed to pass WDAC policy
22 Not IUM (Isolated User Mode) signed; indicates trying to

load a non-trustlet binary into a trustlet
23 Invalid image hash
24 Flight root not allowed; indicates trying to run flight-signed

code on production OS
26 Explicitly denied by WADC policy
28 Resource page hash mismatch

Querying Application Control events centrally using
Advanced hunting
A Windows Defender Application Control (WDAC) policy logs events locally in Windows Event Viewer in either
enforced or audit mode. While Event Viewer helps to see the impact on a single system, IT Pros want to gauge
the impact across many systems.
In November 2018, we added functionality in Microsoft Defender for Endpoint that makes it easy to view WDAC
events centrally from all systems that are connected to Defender for Endpoint.
Advanced hunting in Microsoft Defender for Endpoint allows customers to query data using a rich set of
capabilities. WDAC events can be queried with using an ActionType that starts with “AppControl”. This capability
is supported beginning with Windows version 1607.
Here is a simple example query that shows all the WDAC events generated in the last seven days from machines
being monitored by Microsoft Defender for Endpoint:
DeviceEvents
| where Timestamp > ago(7d) and
ActionType startswith "AppControl"
| summarize Machines=dcount(DeviceName) by ActionType
| order by Machines desc
The query results can be used for several important functions related to managing WDAC including:
Assessing the impact of deploying policies in audit mode Since applications still run in audit mode, it is an
ideal way to see the impact and correctness of the rules included in the policy. Integrating the generated
events with Advanced hunting makes it much easier to have broad deployments of audit mode policies and
see how the included rules would impact those systems in real world usage. This audit mode data will help
streamline the transition to using policies in enforced mode.
Monitoring blocks from policies in enforced mode Policies deployed in enforced mode may block
executables or scripts that fail to meet any of the included allow rules. Legitimate new applications and
updates or potentially unwanted or malicious software could be blocked. In either case, the Advanced
hunting queries report the blocks for further investigation.
AppLocker
Applies to
Windows 10
Windows Server
This topic provides a description of AppLocker and can help you decide if your organization can benefit from
deploying AppLocker application control policies. AppLocker helps you control which apps and files users can
run. These include executable files, scripts, Windows Installer files, dynamic-link libraries (DLLs), packaged apps,
and packaged app installers.
NOTE
AppLocker is unable to control processes running under the system account on any operating system.
AppLocker can help you:

Define rules based on file attributes that persist across app updates, such as the publisher name (derived
from the digital signature), product name, file name, and file version. You can also create rules based on the
file path and hash.
Assign a rule to a security group or an individual user.
Create exceptions to rules. For example, you can create a rule that allows all users to run all Windows
binaries, except the Registry Editor (regedit.exe).
Use audit-only mode to deploy the policy and understand its impact before enforcing it.
Create rules on a staging server, test them, then export them to your production environment and import
them into a Group Policy Object.
Simplify creating and managing AppLocker rules by using Windows PowerShell.
AppLocker helps reduce administrative overhead and helps reduce the organization's cost of managing
computing resources by decreasing the number of Help Desk calls that result from users running unapproved
apps. AppLocker addresses the following app security scenarios:
Application inventor y
AppLocker has the ability to enforce its policy in an audit-only mode where all app access activity is
registered in event logs. These events can be collected for further analysis. Windows PowerShell cmdlets
also help you analyze this data programmatically.
Protection against unwanted software
AppLocker has the ability to deny apps from running when you exclude them from the list of allowed
apps. When AppLocker rules are enforced in the production environment, any apps that are not included
in the allowed rules are blocked from running.
Licensing conformance
AppLocker can help you create rules that preclude unlicensed software from running and restrict licensed
software to authorized users.
Software standardization
AppLocker policies can be configured to allow only supported or approved apps to run on computers
within a business group. This permits a more uniform app deployment.
Manageability improvement
AppLocker includes a number of improvements in manageability as compared to its predecessor
Software Restriction Policies. Importing and exporting policies, automatic generation of rules from
multiple files, audit-only mode deployment, and Windows PowerShell cmdlets are a few of the
improvements over Software Restriction Policies.
When to use AppLocker

In many organizations, information is the most valuable asset, and ensuring that only approved users have
access to that information is imperative. Access control technologies, such as Active Directory Rights
Management Services (AD RMS) and access control lists (ACLs), help control what users are allowed to access.
However, when a user runs a process, that process has the same level of access to data that the user has. As a
result, sensitive information could easily be deleted or transmitted out of the organization if a user knowingly or
unknowingly runs malicious software. AppLocker can help mitigate these types of security breaches by
restricting the files that users or groups are allowed to run. Software publishers are beginning to create more
apps that can be installed by non-administrative users. This could jeopardize an organization's written security
policy and circumvent traditional app control solutions that rely on the inability of users to install apps. By
creating an allowed list of approved files and apps, AppLocker helps prevent such per-user apps from running.
Because AppLocker can control DLLs, it is also useful to control who can install and run ActiveX controls.
AppLocker is ideal for organizations that currently use Group Policy to manage their PCs.
The following are examples of scenarios in which AppLocker can be used:
Your organization's security policy dictates the use of only licensed software, so you need to prevent users
from running unlicensed software and also restrict the use of licensed software to authorized users.
An app is no longer supported by your organization, so you need to prevent it from being used by everyone.
The potential that unwanted software can be introduced in your environment is high, so you need to reduce
this threat.
The license to an app has been revoked or it is expired in your organization, so you need to prevent it from
being used by everyone.
A new app or a new version of an app is deployed, and you need to prevent users from running the old
version.
Specific software tools are not allowed within the organization, or only specific users should have access to
those tools.
A single user or small group of users needs to use a specific app that is denied for all others.
Some computers in your organization are shared by people who have different software usage needs, and
you need to protect specific apps.
In addition to other measures, you need to control the access to sensitive data through app usage.
NOTE
AppLocker is a defense-in-depth security feature and not a security boundary. Windows Defender Application Control
should be used when the goal is to provide robust protection against a threat and there are expected to be no by-design
limitations that would prevent the security feature from achieving this goal.
AppLocker can help you protect the digital assets within your organization, reduce the threat of malicious
software being introduced into your environment, and improve the management of application control and the
maintenance of application control policies.
Installing AppLocker
AppLocker is included with enterprise-level editions of Windows. You can author AppLocker rules for a single
computer or for a group of computers. For a single computer, you can author the rules by using the Local
Security Policy editor (secpol.msc). For a group of computers, you can author the rules within a Group Policy
Object by using the Group Policy Management Console (GPMC).
NOTE
The GPMC is available in client computers running Windows only by installing the Remote Server Administration Tools. On
computer running Windows Server, you must install the Group Policy Management feature.
Using AppLocker on Server Core

AppLocker on Server Core installations is not supported.
Virtualization considerations
You can administer AppLocker policies by using a virtualized instance of Windows provided it meets all the
system requirements listed previously. You can also run Group Policy in a virtualized instance. However, you do
risk losing the policies that you created and maintain if the virtualized instance is removed or fails.
Security considerations
Application control policies specify which apps are allowed to run on the local computer.
The variety of forms that malicious software can take make it difficult for users to know what is safe to run.
When activated, malicious software can damage content on a hard disk drive, flood a network with requests to
cause a denial-of-service (DoS) attack, send confidential information to the Internet, or compromise the security
of a computer.
The countermeasure is to create a sound design for your application control policies on PCs in your
organization, and then thoroughly test the policies in a lab environment before you deploy them in a production
environment. AppLocker can be part of your app control strategy because you can control what software is
allowed to run on your computers.
A flawed application control policy implementation can disable necessary applications or allow malicious or
unintended software to run. Therefore, it is important that organizations dedicate sufficient resources to manage
and troubleshoot the implementation of such policies.
For additional information about specific security issues, see Security considerations for AppLocker.
When you use AppLocker to create application control policies, you should be aware of the following security
considerations:
Who has the rights to set AppLocker policies?
How do you validate that the policies are enforced?
What events should you audit?
For reference in your security planning, the following table identifies the baseline settings for a PC with
AppLocker installed:
SET T IN G DEFA ULT VA L UE
Accounts created None
Authentication method Not applicable

SET T IN G DEFA ULT VA L UE
Management interfaces AppLocker can be managed by using a Microsoft

Management Console snap-in, Group Policy Management,
and Windows PowerShell
Ports opened None
Minimum privileges required Administrator on the local computer; Domain Admin, or any
set of rights that allow you to create, edit and distribute
Group Policy Objects.
Protocols used Not applicable
Scheduled Tasks Appidpolicyconverter.exe is put in a scheduled task to be run

on demand.
Security Policies None required. AppLocker creates security policies.
System Services required Application Identity service (appidsvc) runs under

LocalServiceAndNoImpersonation.
Storage of credentials None
In this section
Administer AppLocker This topic for IT professionals provides links to specific

procedures to use when administering AppLocker policies.
AppLocker design guide This topic for the IT professional introduces the design and
planning steps required to deploy application control policies
by using AppLocker.
AppLocker deployment guide This topic for IT professionals introduces the concepts and
describes the steps required to deploy AppLocker policies.
AppLocker technical reference This overview topic for IT professionals provides links to the
topics in the technical reference.
Applies to
Windows 10
Windows Server
This topic for IT professionals provides links to specific procedures to use when administering AppLocker
policies.
AppLocker helps administrators control how users can access and use files, such as executable files, packaged
apps, scripts, Windows Installer files, and DLLs. Using AppLocker, you can:
Define rules based on file attributes derived from the digital signature, including the publisher, product name,
file name, and file version. For example, you can create rules based on the publisher attribute that is
persistent through updates, or you can create rules for a specific version of a file.
Create exceptions to rules. For example, you can create a rule that allows all Windows processes to run,
except Registry Editor (regedit.exe).
Import and export rules. The import and export affects the entire policy. For example, if you export a policy,
all of the rules from all of the rule collections are exported, including the enforcement settings for the rule
collections. If you import a policy, the existing policy is overwritten.
Simplify creating and managing AppLocker rules by using AppLocker PowerShell cmdlets.
Note For more info about enhanced capabilities of AppLocker to control Windows apps, see
Packaged apps and packaged app installer rules in AppLocker.
In this section
Maintain AppLocker policies This topic describes how to maintain rules within AppLocker
policies.
Edit an AppLocker policy This topic for IT professionals describes the steps required to
modify an AppLocker policy.
Test and update an AppLocker policy This topic discusses the steps required to test an AppLocker
policy prior to deployment.
Deploy AppLocker policies by using the enforce rules setting This topic for IT professionals describes the steps to deploy
AppLocker policies by using the enforcement setting
method.
Use the AppLocker Windows PowerShell cmdlets This topic for IT professionals describes how each AppLocker
Windows PowerShell cmdlet can help you administer your
AppLocker application control policies.
Use AppLocker and Software Restriction Policies in the same This topic for IT professionals describes concepts and
domain procedures to help you manage your application control
strategy using Software Restriction Policies and AppLocker.
Optimize AppLocker performance This topic for IT professionals describes how to optimize
AppLocker policy enforcement.
Monitor app usage with AppLocker This topic for IT professionals describes how to monitor app
usage when AppLocker policies are applied.
Manage packaged apps with AppLocker This topic for IT professionals describes concepts and lists
procedures to help you manage Packaged apps with
AppLocker as part of your overall application control
strategy.
Working with AppLocker rules This topic for IT professionals describes AppLocker rule types
and how to work with them for your application control
policies.
Working with AppLocker policies This topic for IT professionals provides links to procedural
topics about creating, maintaining, and testing AppLocker
policies.
Using the MMC snap-ins to administer AppLocker

You can administer AppLocker policies by using the Group Policy Management Console to create or edit a Group
Policy Object (GPO), or to create or edit an AppLocker policy on a local computer by using the Local Group
Policy Editor snap-in or the Local Security Policy snap-in (secpol.msc).
Administer AppLocker using Group Policy
You must have Edit Setting permission to edit a GPO. By default, members of the Domain Admins group, the
Enterprise Admins group, and the Group Policy Creator Owners group have this permission. Also, the
Group Policy Management feature must be installed on the computer.
1. Open the Group Policy Management Console (GPMC).
2. Locate the GPO that contains the AppLocker policy to modify, right-click the GPO, and then click Edit .
3. In the console tree, double-click Application Control Policies , double-click AppLocker , and then click the
rule collection that you want to create the rule for.
Administer AppLocker on the local PC
1. Click Star t , type local security policy , and then click Local Security Policy .
2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and
then click Yes .
3. In the console tree of the snap-in, double-click Application Control Policies , double-click AppLocker , and
then click the rule collection that you want to create the rule for.
Using Windows PowerShell to administer AppLocker

For how-to info about administering AppLocker with Windows PowerShell, see Use the AppLocker Windows
PowerShell Cmdlets. For reference info and examples how to administer AppLocker with Windows PowerShell,
see the AppLocker cmdlets.
Maintain AppLocker policies
Applies to
Windows 10
Windows Server
This topic describes how to maintain rules within AppLocker policies.
Common AppLocker maintenance scenarios include:
A new app is deployed, and you need to update an AppLocker policy.
A new version of an app is deployed, and you need to either update an AppLocker policy or create a new rule
to update the policy.
An app is no longer supported by your organization, so you need to prevent it from being used.
An app appears to be blocked but should be allowed.
An app appears to be allowed but should be blocked.
A single user or small subset of users needs to use a specific app that is blocked.
There are three methods you can use to maintain AppLocker policies:
Maintaining AppLocker policies by using Mobile Device Management (MDM)
Maintaining AppLocker policies by using Group Policy
Maintaining AppLocker policies on the local computer
Maintaining AppLocker policies by using Mobile Device Management

(MDM)
Using the AppLocker configuration service provider, you can select which apps are allowed or blocked from
running. Using the CSP, you can configure app restrictions based on grouping (such as EXE, MSI, DLL, Store apps
and more) and then chose how to enforce different policies for different apps.
For more information, see the AppLocker CSP.
Maintaining AppLocker policies by using Group Policy

For every scenario, the steps to maintain an AppLocker policy distributed by Group Policy include the following
tasks.
As new apps are deployed or existing apps are removed by your organization or updated by the software
publisher, you might need to make revisions to your rules and update the Group Policy Object (GPO) to ensure
that your policy is current.
You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot specify a version
for the AppLocker policy by importing additional rules. To ensure version control when modifying an AppLocker
policy, use Group Policy management software that allows you to create versions of GPOs.
Caution: You should not edit an AppLocker rule collection while it is being enforced in Group Policy.
Because AppLocker controls what files are allowed to run, making changes to a live policy can create
unexpected behavior.
Step 1: Understand the current behavior of the policy
Before modifying a policy, evaluate how the policy is currently implemented. For example, if a new version of the
application is deployed, you can use Test-AppLockerPolicy to verify the effectiveness of your current policy for
that app.
Step 2: Export the AppLocker policy from the GPO
Updating an AppLocker policy that is currently enforced in your production environment can have unintended
results. Therefore, export the policy from the GPO and update the rule or rules by using AppLocker on your
AppLocker reference or test computer. To prepare an AppLocker policy for modification, see Export an
AppLocker policy from a GPO.
Step 3: Update the AppLocker policy by editing the appropriate AppLocker rule
After the AppLocker policy has been exported from the GPO into the AppLocker reference or test computer, or
has been accessed on the local computer, the specific rules can be modified as required.
To modify AppLocker rules, see the following:
Merge AppLocker policies by using Set-ApplockerPolicy or Merge AppLocker policies manually
Step 4: Test the AppLocker policy
You should test each collection of rules to ensure that the rules perform as intended. (Because AppLocker rules
are inherited from linked GPOs, you should deploy all rules for simultaneous testing in all test GPOs.) For steps
to perform this testing, see Test and update an AppLocker policy.
Step 5: Import the AppLocker policy into the GPO
After testing, import the AppLocker policy back into the GPO for implementation. To update the GPO with a
modified AppLocker policy, see Import an AppLocker policy into a GPO.
Step 6: Monitor the resulting policy behavior
After deploying a policy, evaluate the policy's effectiveness.
Maintaining AppLocker policies by using the Local Security Policy

snap-in
For every scenario, the steps to maintain an AppLocker policy by using the Local Group Policy Editor or the Local
Security Policy snap-in include the following tasks.
Step 1: Understand the current behavior of the policy
Before modifying a policy, evaluate how the policy is currently implemented.
Step 2: Update the AppLocker policy by modifying the appropriate AppLocker rule
Rules are grouped into a collection, which can have the policy enforcement setting applied to it. By default,
AppLocker rules do not allow users to open or run any files that are not specifically allowed.
To modify AppLocker rules, see the appropriate topic listed on Administer AppLocker.
Step 3: Test the AppLocker policy
You should test each collection of rules to ensure that the rules perform as intended. For steps to perform this
testing, see Test and update an AppLocker policy.
Step 4: Deploy the policy with the modified rule
You can export and then import AppLocker policies to deploy the policy to other computers running Windows 8
or later. To perform this task, see Export an AppLocker policy to an XML file and Import an AppLocker policy
from another computer.
Step 5: Monitor the resulting policy behavior
After deploying a policy, evaluate the policy's effectiveness.
Additional resources
For steps to perform other AppLocker policy tasks, see Administer AppLocker.
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps required to modify an AppLocker policy.
You can edit an AppLocker policy by adding, changing, or removing rules. However, you cannot create a new
version of the policy by importing additional rules. To modify an AppLocker policy that is in production, you
should use Group Policy management software that allows you to version Group Policy Objects (GPOs). If you
have created multiple AppLocker policies and need to merge them to create one AppLocker policy, you can
either manually merge the policies or use the Windows PowerShell cmdlets for AppLocker. You cannot
automatically merge policies by using the AppLocker snap-in. You must create one rule collection from two or
more policies. The AppLocker policy is saved in XML format, and the exported policy can be edited with any text
or XML editor. For info about merging policies, see Merge AppLocker policies manually or Merge AppLocker
policies by using Set-ApplockerPolicy.
There are three methods you can use to edit an AppLocker policy:
Editing an AppLocker policy by using Mobile Device Management (MDM)
Editing an AppLocker policy by using Group Policy
Editing an AppLocker policy by using the Local Security Policy snap-in
Editing an AppLocker policy by using Mobile Device Management

(MDM)
Editing an AppLocker policy by using Group Policy
The steps to edit an AppLocker policy distributed by Group Policy include the following:
Step 1: Use Group Policy management software to export the AppLocker policy from the GPO
AppLocker provides a feature to export and import AppLocker policies as an XML file. This allows you to modify
an AppLocker policy outside your production environment. Because updating an AppLocker policy in a deployed
GPO could have unintended consequences, you should first export the AppLocker policy to an XML file. For the
procedure to do this, see Export an AppLocker policy from a GPO.
Step 2: Import the AppLocker policy into the AppLocker reference PC or the PC you use for policy
maintenance
After exporting the AppLocker policy to an XML file, you should import the XML file onto a reference PC so that
you can edit the policy. For the procedure to import an AppLocker policy, see Import an AppLocker policy from
another computer.
Caution: Importing a policy onto another PC will overwrite the existing policy on that PC.
Step 3: Use AppLocker to modify and test the rule

AppLocker provides ways to modify, delete, or add rules to a policy by modifying the rules within the collection.
For the procedure to modify a rule, see Edit AppLocker rules.
For the procedure to delete a rule, see Delete an AppLocker rule.
For procedures to create rules, see:
For steps to test an AppLocker policy, see Test and update an AppLocker policy.
For procedures to export the updated policy from the reference computer back into the GPO, see Export
an AppLocker policy to an XML file and Import an AppLocker policy into a GPO.
Step 4: Use AppLocker and Group Policy to import the AppLocker policy back into the GPO
For procedures to export the updated policy from the reference computer back into the GPO, see Export an
AppLocker policy to an XML file and Import an AppLocker policy into a GPO.
Caution: You should never edit an AppLocker rule collection while it is being enforced in Group Policy.
Because AppLocker controls what files are allowed run, making changes to a live policy can create
unexpected behavior. For info about testing policies, see Test and update an AppLocker policy. Note: If you
are performing these steps by using Microsoft Advanced Group Policy Management (AGPM), check out the
GPO before exporting the policy.
Editing an AppLocker policy by using the Local Security Policy snap-in

The steps to edit an AppLocker policy distributed by using the Local Security Policy snap-in (secpol.msc) include
the following tasks.
Step 1: Import the AppLocker policy
On the PC where you maintain policies, open the AppLocker snap-in from the Local Security Policy snap-in
(secpol.msc). If you exported the AppLocker policy from another PC, use AppLocker to import it onto the PC.
After exporting the AppLocker policy to an XML file, you should import the XML file onto a reference PC so that
you can edit the policy. For the procedure to import an AppLocker policy, see Import an AppLocker policy from
another computer.
Caution: Importing a policy onto another PC will overwrite the existing policy on that PC.
Step 2: Identify and modify the rule to change, delete, or add

AppLocker provides ways to modify, delete, or add rules to a policy by modifying the rules within the collection.
For the procedure to modify a rule, see Edit AppLocker rules.
For the procedure to delete a rule, see Delete an AppLocker rule.
For procedures to create rules, see:
Step 3: Test the effect of the policy
For steps to test an AppLocker policy, see Test and update an AppLocker policy.
Step 4: Export the policy to an XML file and propagate it to all targeted computers
For procedures to export the updated policy from the reference computer to targeted computers, see Export an
AppLocker policy to an XML file and Import an AppLocker policy from another computer.
Test and update an AppLocker policy
Applies to
Windows 10
Windows Server
This topic discusses the steps required to test an AppLocker policy prior to deployment.
You should test each set of rules to ensure that the rules perform as intended. If you use Group Policy to manage
AppLocker policies, complete the following steps for each Group Policy Object (GPO) where you have created
AppLocker rules. Because AppLocker rules are inherited from linked GPOs, you should deploy all of the rules for
simultaneous testing in all of your test GPOs.
Step 1: Enable the Audit only enforcement setting

By using the Audit only enforcement setting, you can ensure that the AppLocker rules that you have created
are properly configured for your organization. This setting can be enabled on the Enforcement tab of the
AppLocker Proper ties dialog box. For the procedure to do this, see Configure an AppLocker policy for audit
only.
Step 2: Configure the Application Identity service to start

automatically
Because AppLocker uses the Application Identity service to verify the attributes of a file, you must configure it to
start automatically in any one GPO that applies AppLocker rules. For the procedure to do this, see Configure the
Application Identity Service. For AppLocker policies that are not managed by a GPO, you must ensure that the
service is running on each PC in order for the policies to be applied.
Step 3: Test the policy

Test the AppLocker policy to determine if your rule collection needs to be modified. Because you have created
AppLocker rules, enabled the Application Identity service, and enabled the Audit only enforcement setting, the
AppLocker policy should be present on all client PC that are configured to receive your AppLocker policy.
The Test-AppLockerPolicy Windows PowerShell cmdlet can be used to determine whether any of the rules in
your rule collection will be blocked on your reference PCs. For the procedure to do this, see Test an AppLocker
policy by using Test-AppLockerPolicy.
Step 4: Analyze AppLocker events

You can either manually analyze AppLocker events or use the Get-AppLockerFileInformation Windows
PowerShell cmdlet to automate the analysis.
To manually analyze AppLocker events
You can view the events either in Event Viewer or a text editor and then sort those events to perform an analysis,
such as looking for patterns in application usage events, access frequencies, or access by user groups. If you
have not configured an event subscription, then you will have to review the logs on a sampling of computers in
your organization. For more information about using Event Viewer, see Monitor application usage with
AppLocker.
To analyze AppLocker events by using Get-AppLockerFileInformation
You can use the Get-AppLockerFileInformation Windows PowerShell cmdlet to analyze AppLocker events
from a remote computer. If an app is being blocked and should be allowed, you can use the AppLocker cmdlets
to help troubleshoot the problem.
For both event subscriptions and local events, you can use the Get-AppLockerFileInformation cmdlet to
determine which files have been blocked or would have been blocked (if you are using the Audit only
enforcement mode) and how many times the event has occurred for each file. For the procedure to do this, see
Monitor Application Usage with AppLocker.
After using Get-AppLockerFileInformation to determine how many times that a file would have been
blocked from running, you should review your rule list to determine whether a new rule should be created for
the blocked file or whether an existing rule is too strictly defined. Ensure that you check which GPO is currently
preventing the file from running. To determine this, you can use the Group Policy Results Wizard to view rule
names.
Step 5: Modify the AppLocker policy

After you have identified which rules need to be edited or added to the policy, you can use the Group Policy
Management Console to modify the AppLocker rules in the relevant GPOs. For AppLocker policies that are not
managed by a GPO, you can use the Local Security Policy snap-in (secpol.msc). For info how to modify an
AppLocker policy, see, Edit an AppLocker policy.
Step 6: Repeat policy testing, analysis, and policy modification

Repeat the previous steps 3–5 until all the rules perform as intended before applying enforcement.
Deploy AppLocker policies by using the enforce
rules setting
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to deploy AppLocker policies by using the enforcement setting
method.
Background and prerequisites

These procedures assume that you have already deployed AppLocker policies with the enforcement set to Audit
only , and you have been collecting data through the AppLocker event logs and other channels to determine
what effect these policies have on your environment and the policy's adherence to your application control
design.
For info about the AppLocker policy enforcement setting, see Understand AppLocker enforcement settings.
For info about how to plan an AppLocker policy deployment, see AppLocker Design Guide.
Step 1: Retrieve the AppLocker policy

results. Using Group Policy, you can export the policy from the Group Policy Object (GPO) and then update the
rule or rules by using AppLocker on your AppLocker reference or test PC. For the procedure to do this, see
Export an AppLocker policy from a GPO and Import an AppLocker policy into a GPO. For local AppLocker
policies, you can update the rule or rules by using the Local Security policy snap-in (secpol.msc) on your
AppLocker reference or test PC. For the procedures to do this, see Export an AppLocker policy to an XML file and
Import an AppLocker policy from another computer.
Step 2: Alter the enforcement setting

Rule enforcement is applied only to a collection of rules, not to individual rules. AppLocker divides the rules into
collections: executable files, Windows Installer files, packaged apps, scripts, and DLL files. By default, if
enforcement is not configured and rules are present in a rule collection, those rules are enforced. For
information about the enforcement setting, see Understand AppLocker Enforcement Settings. For the procedure
to alter the enforcement setting, see Configure an AppLocker policy for audit only.
Step 3: Update the policy

for the AppLocker policy by importing additional rules. To ensure version control when modifying an AppLocker
policy, use Group Policy management software that allows you to create versions of GPOs. An example of this
type of software is the Advanced Group Policy Management feature from the Microsoft Desktop Optimization
Pack.
For the procedure to update the GPO, see Import an AppLocker policy into a GPO.
For the procedures to distribute policies for local PCs by using the Local Security Policy snap-in (secpol.msc), see
Export an AppLocker policy to an XML file and Import an AppLocker policy from another computer.
Step 4: Monitor the effect of the policy

When a policy is deployed, it is important to monitor the actual implementation of that policy. You can do this by
monitoring your support organization's app access request activity and reviewing the AppLocker event logs. To
monitor the effect of the policy, see Monitor Application Usage with AppLocker.
Use the AppLocker Windows PowerShell cmdlets
Applies to
Windows 10
Windows Server
This topic for IT professionals describes how each AppLocker Windows PowerShell cmdlet can help you
administer your AppLocker application control policies.
AppLocker Windows PowerShell cmdlets

The five AppLocker cmdlets are designed to streamline the administration of an AppLocker policy. They can be
used to help create, test, maintain, and troubleshoot an AppLocker policy. The cmdlets are intended to be used in
conjunction with the AppLocker user interface that is accessed through the Microsoft Management Console
(MMC) snap-in extension to the Local Security Policy snap-in and Group Policy Management Console.
To edit or update a Group Policy Object (GPO) by using the AppLocker cmdlets, you must have Edit Setting
permission. By default, members of the Domain Admins group, the Enterprise Admins group, and the
Group Policy Creator Owners group have this permission. To perform tasks by using the Local Security
policy snap-in, you must be a member of the local Administrators group, or equivalent, on the computer.
Retrieve application information
The Get-AppLockerFileInformation cmdlet retrieves the AppLocker file information from a list of files or from an
event log. File information that is retrieved can include publisher information, file hash information, and file path
information.
File information from an event log may not contain all of these fields. Files that are not signed do not have any
publisher information.
Set AppLocker policy
The Set-AppLockerPolicy cmdlet sets the specified GPO to contain the specified AppLocker policy. If no
Lightweight Directory Access Protocol (LDAP) is specified, the local GPO is the default.
Retrieve an AppLocker policy
The Get-AppLockerPolicy cmdlet gets the AppLocker policy from the local GPO, from a specified GPO, or from
the effective AppLocker policy on the device. The output of the AppLocker policy is an AppLockerPolicy object or
an XML-formatted string.
Generate rules for a given user or group
The New-AppLockerPolicy cmdlet uses a list of file information to automatically generate rules for a given user
or group. It can generate rules based on publisher, hash, or path information. Use Get-
AppLockerFileInformation to create the list of file information.
Test the AppLocker Policy against a file set
The Test-AppLockerPolicy cmdlet uses the specified AppLocker policy to test whether a specified list of files are
allowed to run or not on the local device for a specific user.
Use AppLocker and Software Restriction Policies in
the same domain
Applies to
Windows 10
Windows Server
This topic for IT professionals describes concepts and procedures to help you manage your application control
strategy using Software Restriction Policies and AppLocker.
Using AppLocker and Software Restriction Policies in the same

domain
AppLocker is supported on systems running Windows 7 and above. Software Restriction Policies (SRP) is
supported on systems running Windows Vista or earlier. You can continue to use SRP for application control on
your pre-Windows 7 computers, but use AppLocker for computers running Windows Server 2008 R2,
Windows 7 and later. It is recommended that you author AppLocker and SRP rules in separate GPOs and target
the GPO with SRP policies to systems running Windows Vista or earlier. When both SRP and AppLocker policies
are applied to computers running Windows Server 2008 R2, Windows 7 and later, the SRP policies are ignored.
The following table compares the features and functions of Software Restriction Policies (SRP) and AppLocker.
A P P L IC AT IO N C O N T RO L F UN C T IO N SRP A P P LO C K ER
Scope SRP policies can be applied to all AppLocker policies apply only to
Windows operating systems Windows Server 2008 R2,
beginning with Windows XP and Windows 7, and later.
Windows Server 2003.
Policy creation SRP policies are maintained AppLocker policies are maintained
through Group Policy and only the through Group Policy and only the
administrator of the GPO can administrator of the GPO can
update the SRP policy. The update the policy. The
administrator on the local administrator on the local
computer can modify the SRP computer can modify the
policies defined in the local GPO. AppLocker policies defined in the
local GPO.
AppLocker permits customization
of error messages to direct users
to a Web page for help.
Policy maintenance SRP policies must be updated by AppLocker policies can be updated
using the Local Security Policy by using the Local Security Policy
snap-in (if the policies are created snap-in (if the policies are created
locally) or the Group Policy locally), or the GPMC, or the
Management Console (GPMC). Windows PowerShell AppLocker
cmdlets.
Policy application SRP policies are distributed AppLocker policies are distributed
through Group Policy. through Group Policy.
Enforcement mode SRP works in the “deny list mode” AppLocker by default works in the
where administrators can create “allow list mode” where only those
rules for files that they do not files are allowed to run for which
want to allow in this Enterprise there is a matching allow rule.
whereas the rest of the file is
allowed to run by default.
SRP can also be configured in the
“allow list mode” so that by default
all files are blocked and
administrators need to create
allow rules for files that they want
to allow.
File types that can be controlled SRP can control the following file AppLocker can control the
types: following file types:
Executables Executables
Dlls Dlls
Scripts Scripts
Windows Installers Windows Installers
SRP cannot control each file type Packaged apps and
separately. All SRP rules are in a installers
single rule collection.
AppLocker maintains a separate
rule collection for each of the five
file types.
Designated file types SRP supports an extensible list of AppLocker currently supports the
file types that are considered following file extensions:
executable. Administrators can add
extensions for files that should be Executables (.exe, .com)
considered executable. Dlls (.ocx, .dll)
Scripts (.vbs, .js, .ps1, .cmd,
.bat)
Windows Installers (.msi,
.mst, .msp)
Packaged app installers
(.appx)
Rule types SRP supports four types of rules: AppLocker supports three types of
rules:
Hash
File hash
Path
Path
Signature
Publisher
Internet zone
Editing the hash value In Windows XP, you could use SRP AppLocker computes the hash
to provide custom hash values. value itself. Internally, it uses the
SHA2 Authenticode hash for
Beginning with Windows 7 and Portable Executables (exe and dll)
Windows Server 2008 R2, you can and Windows Installers and a
only select the file to hash, not SHA2 flat file hash for the rest.
provide the hash value.
Support for different security levels With SRP, you can specify the AppLocker does not support
permissions with which an app can security levels.
run. So, you can configure a rule
such that Notepad always runs
with restricted permissions and
never with administrative
privileges.
SRP on Windows Vista and earlier
supported multiple security levels.
On Windows 7, that list was
restricted to just two levels:
Disallowed and Unrestricted (Basic
User translates to Disallowed).
Manage Packaged apps and Not supported .appx is a valid file type which
Packaged app installers. AppLocker can manage.
Targeting a rule to a user or a SRP rules apply to all users on a AppLocker rules can be targeted
group of users particular computer. to a specific user or a group of
users.
Support for rule exceptions SRP does not support rule AppLocker rules can have
exceptions. exceptions, which allow you to
create rules such as “Allow
everything from Windows except
for regedit.exe”.
Support for audit mode SRP does not support audit mode. AppLocker supports audit mode,
The only way to test SRP policies is which allows you to test the effect
to set up a test environment and of their policy in the real
run a few experiments. production environment without
impacting the user experience.
Once you are satisfied with the
results, you can start enforcing the
policy.
Support for exporting and SRP does not support policy AppLocker supports the importing
importing policies import/export. and exporting of policies. This
allows you to create AppLocker
policy on a sample device, test it
out and then export that policy
and import it back into the desired
GPO.
Rule enforcement Internally, SRP rules enforcement Internally, AppLocker rules for .exe
happens in the user-mode, which and .dll files are enforced in the
is less secure. kernel-mode, which is more secure
than enforcing them in the user-
mode.
Applies to
Windows 10
Windows Server
This topic for IT professionals describes how to optimize AppLocker policy enforcement.
Optimization of Group Policy

AppLocker policies can be implemented by organization unit (OU) using Group Policy. If so, your Group Policy
infrastructure should be optimized and retested for performance when AppLocker policies are added to existing
Group Policy Objects (GPOs) or new GPOs are created, as you do with adding any policies to your GPOs.
For more info, see the Optimizing Group Policy Performance article in TechNet Magazine.
AppLocker rule limitations
The more rules per GPO, the longer AppLocker requires for evaluation. There is no set limitation on the number
of rules per GPO, but the number of rules that can fit into a 100 MB GPO varies based on the complexity of the
rule, such as the number of file hashes included in a single file hash condition.
Using the DLL rule collection
When the DLL rule collection is enabled, AppLocker must check each DLL that an application loads. The more
DLLs, the longer AppLocker requires to complete the evaluation.
Applies to
Windows 10
Windows Server
This topic for IT professionals describes how to monitor app usage when AppLocker policies are applied.
Once you set rules and deploy the AppLocker policies, it is good practice to determine if the policy
implementation is what you expected.
Discover the effect of an AppLocker policy
You can evaluate how the AppLocker policy is currently implemented for documentation or audit purposes, or
before you modify the policy. Updating your AppLocker Policy Deployment Planning document will help you
track your findings. You can perform one or more of the following steps to understand what application controls
are currently enforced through AppLocker rules.
Analyze the AppLocker logs in Event Viewer
When AppLocker policy enforcement is set to Enforce rules , rules are enforced for the rule collection
and all events are audited. When AppLocker policy enforcement is set to Audit only , rules are not
enforced but are still evaluated to generate audit event data that is written to the AppLocker logs.
For the procedure to access the log, see View the AppLocker Log in Event Viewer.
Enable the Audit only AppLocker enforcement setting
By using the Audit only enforcement setting, you can ensure that the AppLocker rules are properly
configured for your organization. When AppLocker policy enforcement is set to Audit only , rules are
only evaluated but all events generated from that evaluation are written to the AppLocker log.
For the procedure to do this, see Configure an AppLocker policy for audit only.
Review AppLocker events with Get-AppLockerFileInformation
For both event subscriptions and local events, you can use the Get-AppLockerFileInformation
Windows PowerShell cmdlet to determine which files have been blocked or would have been blocked (if
you are using the audit-only enforcement mode) and how many times the event has occurred for each
file.
For the procedure to do this, see Review AppLocker Events with Get-AppLockerFileInformation.
Review AppLocker events with Test-AppLockerPolicy
You can use the Test-AppLockerPolicy Windows PowerShell cmdlet to determine whether any of the
rules in your rule collections will be blocked on your reference device or the device on which you
maintain policies.
For the procedure to do this, see Test an AppLocker policy by using Test-AppLockerPolicy.
Review AppLocker events with Get-AppLockerFileInformation
For both event subscriptions and local events, you can use the Get-AppLockerFileInformation Windows
PowerShell cmdlet to determine which files have been blocked or would have been blocked (if the Audit only
enforcement setting is applied) and how many times the event has occurred for each file.
Membership in the local Administrators group, or equivalent, is the minimum required to complete this
procedure.
NOTE
If the AppLocker logs are not on your local device, you will need permission to view the logs. If the output is saved to a
file, you will need permission to read that file.
To review AppLocker events with Get-AppLockerFileInformation

1. At the command prompt, type PowerShell , and then press ENTER.
2. Run the following command to review how many times a file would have been blocked from running if
rules were enforced:
Get-AppLockerFileInformation –EventLog –EventType Audited –Statistics
3. Run the following command to review how many times a file has been allowed to run or prevented from
running:
Get-AppLockerFileInformation –EventLog –EventType Allowed –Statistics
View the AppLocker Log in Event Viewer

When AppLocker policy enforcement is set to Enforce rules , rules are enforced for the rule collection and all
events are audited. When AppLocker policy enforcement is set to Audit only , rules are only evaluated but all
events generated from that evaluation are written to the AppLocker log.
procedure.
To view events in the AppLocker log by using Event Viewer
1. Open Event Viewer. To do this, click Star t , type eventvwr.msc , and then press ENTER.
2. In the console tree under Application and Ser vices Logs\Microsoft\Windows , double-click
AppLocker .
AppLocker events are listed in either the EXE and DLL log, the MSI and Script log, or the Packaged app-
Deployment or Packaged app-Execution log. Event information includes the enforcement setting, file name,
date and time, and user name. The logs can be exported to other file formats for further analysis.
Related topics
AppLocker
Applies to
Windows 10
Windows Server
This topic for IT professionals describes concepts and lists procedures to help you manage Packaged apps with
AppLocker as part of your overall application control strategy.
Understanding Packaged apps and Packaged app installers for

AppLocker
Packaged apps, also known as Universal Windows apps, are based on a model that ensures all the files within an
app package share the same identity. With classic Windows apps, each file within the app could have a unique
identity. With packaged apps, it is possible to control the entire app by using a single AppLocker rule.
NOTE
AppLocker supports only publisher rules for packaged apps. All packaged apps must be signed by the software publisher
because Windows does not support unsigned packaged apps.
Typically, an app consists of multiple components: the installer that is used to install the app, and one or more
exes, dlls, or scripts. With classic Windows apps, not all these components always share common attributes such
as the software’s publisher name, product name, and product version. Therefore, AppLocker controls each of
these components separately through different rule collections, such as exe, dll, script, and Windows Installer
rules. In contrast, all the components of a packaged app share the same publisher name, package name, and
package version attributes. Therefore, you can control an entire app with a single rule.
Comparing classic Windows apps and packaged apps
AppLocker policies for packaged apps can only be applied to apps installed on computers running at least
Windows Server 2012 or Windows 8, but classic Windows apps can be controlled on devices running at least
Windows Server 2008 R2 or Windows 7. The rules for classic Windows apps and packaged apps can be
enforced in tandem. The differences between packaged apps and classic Windows apps that you should
consider include:
Installing the apps All packaged apps can be installed by a standard user, whereas a number of classic
Windows apps require administrative privileges to install. In an environment where most of the users are
standard users, you might not have numerous exe rules (because classic Windows apps require
administrative privileges to install), but you might want to have more explicit policies for packaged apps.
Changing the system state Classic Windows apps can be written to change the system state if they are
run with administrative privileges. Most packaged apps cannot change the system state because they run
with limited privileges. When you design your AppLocker policies, it is important to understand whether an
app that you are allowing can make system-wide changes.
Acquiring the apps Packaged apps can be acquired through the Store, or by loading using Windows
PowerShell cmdlets (which requires a special enterprise license). Classic Windows apps can be acquired
through traditional means.
AppLocker uses different rule collections to control packaged apps and classic Windows apps. You have the
choice to control one type, the other type, or both.
For info about controlling classic Windows apps, see Administer AppLocker.
For more info about packaged apps, see Packaged apps and packaged app installer rules in AppLocker.
Design and deployment decisions

You can use two methods to create an inventory of packaged apps on a computer: the AppLocker console or the
Get-AppxPackage Windows PowerShell cmdlet.
NOTE
Not all packaged apps are listed in AppLocker’s application inventory wizard. Certain app packages are framework
packages that are leveraged by other apps. By themselves, these packages cannot do anything, but blocking such
packages can inadvertently cause failure for apps that you want to allow. Instead, you can create Allow or Deny rules for
the packaged apps that use these framework packages. The AppLocker user interface deliberately filters out all the
packages that are registered as framework packages. For info about how to create an inventory list, see Create list of apps
deployed to each business group.
For info about how to use the Get-AppxPackage Windows PowerShell cmdlet, see the AppLocker PowerShell
Command Reference.
For info about creating rules for Packaged apps, see Create a rule for packaged apps.
Consider the following info when you are designing and deploying apps:
Because AppLocker supports only publisher rules for packaged apps, collecting the installation path
information for packaged apps is not necessary.
You cannot create hash- or path-based rules for packaged apps because all packaged apps and packaged
app installers are signed by the software publisher of the package. Classic Windows apps were not
always consistently signed; therefore, AppLocker has to support hash- or path-based rules.
By default, if there are no rules in a particular rule collection, AppLocker allows every file that is included
in that rule collection. For example, if there are no Windows Installer rules, AppLocker allows all .msi,
.msp, and .mst files to run. An existing AppLocker policy that was targeted at computers running
Windows Server 2008 R2 and Windows 7 would not have rules for Packaged apps. Therefore, when a
computer running at least Windows Server 2012 or Windows 8 joins a domain where an AppLocker
policy is already configured, users would be allowed to run any packaged app. This might be contrary to
your design.
To prevent all packaged apps from running on a newly domain-joined computer, by default AppLocker
blocks all packaged apps on a computer running at least Windows Server 2012 or Windows 8 if the
existing domain policy has rules configured in the exe rule collection. You must take explicit action to
allow packaged apps in your enterprise. You can allow only a select set of packaged apps. Or if you want
to allow all packaged apps, you can create a default rule for the packaged apps collection.
Using AppLocker to manage packaged apps

Just as there are differences in managing each rule collection, you need to manage the packaged apps with the
following strategy:
1. Gather information about which Packaged apps are running in your environment. For information about
how to do this, see Create list of apps deployed to each business group.
2. Create AppLocker rules for specific packaged apps based on your policy strategies. For more information,
see Create a rule for packaged apps and Understanding AppLocker default rules.
3. Continue to update the AppLocker policies as new package apps are introduced into your environment.
To do this, see Add rules for packaged apps to existing AppLocker rule-set.
4. Continue to monitor your environment to verify the effectiveness of the rules that are deployed in
AppLocker policies. To do this, see Monitor app usage with AppLocker.
Working with AppLocker rules
Applies to
Windows 10
Windows Server
This topic for IT professionals describes AppLocker rule types and how to work with them for your application
control policies.
In this section
Create a rule that uses a file hash condition This topic for IT professionals shows how to create an
AppLocker rule with a file hash condition.
Create a rule that uses a path condition This topic for IT professionals shows how to create an
AppLocker rule with a path condition.
Create a rule that uses a publisher condition This topic for IT professionals shows how to create an
AppLocker rule with a publisher condition.
Create AppLocker default rules This topic for IT professionals describes the steps to create a
standard set of AppLocker rules that will allow Windows
system files to run.
Add exceptions for an AppLocker rule This topic for IT professionals describes the steps to specify
which apps can or cannot run as exceptions to an AppLocker
rule.
Create a rule for packaged apps This topic for IT professionals shows how to create an
AppLocker rule for packaged apps with a publisher
condition.
Delete an AppLocker rule This topic for IT professionals describes the steps to delete
an AppLocker rule.
Edit AppLocker rules This topic for IT professionals describes the steps to edit a
publisher rule, path rule, and file hash rule in AppLocker.
Enable the DLL rule collection This topic for IT professionals describes the steps to enable
the DLL rule collection feature for AppLocker.
Enforce AppLocker rules This topic for IT professionals describes how to enforce
application control rules by using AppLocker.
Run the Automatically Generate Rules wizard This topic for IT professionals describes steps to run the
wizard to create AppLocker rules on a reference device.
The three AppLocker enforcement modes are described in the following table. The enforcement mode setting
defined here can be overwritten by the setting derived from a linked Group Policy Object (GPO) with a higher
precedence.
EN F O RC EM EN T M O DE DESC RIP T IO N
Not configured This is the default setting which means that the rules defined
here will be enforced unless a linked GPO with a higher
precedence has a different value for this setting.
Enforce rules Rules are enforced.
Audit only Rules are audited but not enforced. When a user runs an
app that is affected by an AppLocker rule, the app is allowed
to run and the info about the app is added to the AppLocker
event log. The Audit-only enforcement mode helps you
determine which apps will be affected by the policy before
the policy is enforced. When the AppLocker policy for a rule
collection is set to Audit only , rules for that rule collection
are not enforced
When AppLocker policies from various GPOs are merged, the rules from all the GPOs are merged and the
enforcement mode setting of the winning GPO is applied.
Rule collections
The AppLocker console is organized into rule collections, which are executable files, scripts, Windows Installer
files, packaged apps and packaged app installers, and DLL files. These collections give you an easy way to
differentiate the rules for different types of apps. The following table lists the file formats that are included in
each rule collection.
RUL E C O L L EC T IO N A SSO C IAT ED F IL E F O RM AT S
Executable files .exe

.com
Scripts .ps1
.bat
.cmd
.vbs
.js
Windows Installer files .msi

.msp
.mst
Packaged apps and packaged app installers .appx
DLL files .dll

.ocx
Impor tant: If you use DLL rules, you need to create an allow rule for each DLL that is used by all of the
allowed apps.
When DLL rules are used, AppLocker must check each DLL that an application loads. Therefore, users may
experience a reduction in performance if DLL rules are used.
The DLL rule collection is not enabled by default. To learn how to enable the DLL rule collection, see DLL rule
collections.
EXE rules apply to portable executable (PE) files. AppLocker checks whether a file is a valid PE file, rather than
just applying rules based on file extension, which attackers can easily change. Regardless of the file extension,
the AppLocker EXE rule collection will work on a file as long as it is a valid PE file.
Rule conditions
Rule conditions are criteria that help AppLocker identify the apps to which the rule applies. The three primary
rule conditions are publisher, path, and file hash.
Publisher: Identifies an app based on its digital signature
Path: Identifies an app by its location in the file system of the computer or on the network
File hash: Represents the system computed cryptographic hash of the identified file
Publisher
This condition identifies an app based on its digital signature and extended attributes when available. The digital
signature contains info about the company that created the app (the publisher). Executable files, dlls, Windows
installers, packaged apps and packaged app installers also have extended attributes, which are obtained from
the binary resource. In case of executable files, dlls and Windows installers, these attributes contain the name of
the product that the file is a part of, the original name of the file as supplied by the publisher, and the version
number of the file. In case of packaged apps and packaged app installers, these extended attributes contain the
name and the version of the app package.
Note: Rules created in the packaged apps and packaged app installers rule collection can only have
publisher conditions since Windows does not support unsigned packaged apps and packaged app installers.
Note: Use a publisher rule condition when possible because they can survive app updates as well as a
change in the location of files.
When you select a reference file for a publisher condition, the wizard creates a rule that specifies the publisher,
product, file name, and version number. You can make the rule more generic by moving the slider up or by using
a wildcard character (*) in the product, file name, or version number fields.
Note: To enter custom values for any of the fields of a publisher rule condition in the Create Rules Wizard,
you must select the Use custom values check box. When this check box is selected, you cannot use the
slider.
The File version and Package version control whether a user can run a specific version, earlier versions, or
later versions of the app. You can choose a version number and then configure the following options:
Exactly. The rule applies only to this version of the app
And above. The rule applies to this version and all later versions.
And below. The rule applies to this version and all earlier versions.
The following table describes how a publisher condition is applied.
O P T IO N T H E P UB L ISH ER C O N DIT IO N A L LO W S O R DEN IES…
All signed files All files that are signed by any publisher.
Publisher only All files that are signed by the named publisher.
Publisher and product name All files for the specified product that are signed by the
named publisher.
Publisher and product name, and file name Any version of the named file or package for the named
product that are signed by the publisher.
Publisher, product name, file name, and file version Exactly

The specified version of the named file or package for the
named product that are signed by the publisher.
Publisher, product name, file name, and file version And above
The specified version of the named file or package and any
new releases for the product that are signed by the
publisher.
Publisher, product name, file name, and file version And below
The specified version of the named file or package and any
earlier versions for the product that are signed by the
publisher.
Custom You can edit the Publisher , Product name , File name ,
Version Package name , and Package version fields to
create a custom rule.
Path
This rule condition identifies an application by its location in the file system of the computer or on the network.
AppLocker uses custom path variables for well-known paths, such as Program Files and Windows.
The following table details these path variables.
W IN DO W S DIREC TO RY O R DISK A P P LO C K ER PAT H VA RIA B L E W IN DO W S EN VIRO N M EN T VA RIA B L E
Windows %WINDIR% %SystemRoot%
System32 and SysWOW64 %SYSTEM32% %SystemDirectory%
Windows installation directory %OSDRIVE% %SystemDrive%
Program Files %PROGRAMFILES% %ProgramFiles% and

%ProgramFiles(x86)%
Removable media (for example, a CD %REMOVABLE%

or DVD)
Removable storage device (for %HOT%

example, a USB flash drive)
Impor tant: Because a path rule condition can be configured to include a large number of folders and files,
path conditions should be carefully planned. For example, if an allow rule with a path condition includes a
folder location that non-administrators are allowed to write data into, a user can copy unapproved files into
that location and run the files. For this reason, it is a best practice to not create path conditions for standard
user writable locations, such as a user profile.
File hash
When you choose the file hash rule condition, the system computes a cryptographic hash of the identified file.
The advantage of this rule condition is that because each file has a unique hash, a file hash rule condition applies
to only one file. The disadvantage is that each time the file is updated (such as a security update or upgrade) the
file's hash will change. As a result, you must manually update file hash rules.
AppLocker default rules

AppLocker includes default rules, which are intended to help ensure that the files that are required for Windows
to operate properly are allowed in an AppLocker rule collection. For background, see Understanding AppLocker
default rules, and for steps, see Create AppLocker default rules.
Executable default rule types include:
Allow members of the local Administrators group to run all apps.
Allow members of the Ever yone group to run apps that are located in the Windows folder.
Allow members of the Ever yone group to run apps that are located in the Program Files folder.
Script default rule types include:
Allow members of the local Administrators group to run all scripts.
Allow members of the Ever yone group to run scripts that are located in the Program Files folder.
Allow members of the Ever yone group to run scripts that are located in the Windows folder.
Windows Installer default rule types include:
Allow members of the local Administrators group to run all Windows Installer files.
Allow members of the Ever yone group to run all digitally signed Windows Installer files.
Allow members of the Ever yone group to run all Windows Installer files that are located in the
Windows\Installer folder.
DLL default rule types:
Allow members of the local Administrators group to run all DLLs.
Allow members of the Ever yone group to run DLLs that are located in the Program Files folder.
Allow members of the Ever yone group to run DLLs that are located in the Windows folder.
Packaged apps default rule types:
Allow members of the Ever yone group to install and run all signed packaged apps and packaged app
installers.
AppLocker rule behavior

If no AppLocker rules for a specific rule collection exist, all files with that file format are allowed to run. However,
when an AppLocker rule for a specific rule collection is created, only the files explicitly allowed in a rule are
permitted to run. For example, if you create an executable rule that allows .exe files in %SystemDrive%\FilePath
to run, only executable files located in that path are allowed to run.
A rule can be configured to use allow or deny actions:
Allow. You can specify which files are allowed to run in your environment, and for which users or groups of
users. You can also configure exceptions to identify files that are excluded from the rule.
Deny. You can specify which files are not allowed to run in your environment, and for which users or groups
of users. You can also configure exceptions to identify files that are excluded from the rule.
Impor tant: For a best practice, use allow actions with exceptions. You can use a combination of allow and
deny actions but understand that deny actions override allow actions in all cases, and can be circumvented.
Impor tant: If you join a computer running at least Windows Server 2012 or Windows 8 to a domain that
already enforces AppLocker rules for executable files, users will not be able to run any packaged apps unless
you also create rules for packaged apps. If you want to allow any packaged apps in your environment while
continuing to control executable files, you should create the default rules for packaged apps and set the
enforcement mode to Audit-only for the packaged apps rule collection.
Rule exceptions
You can apply AppLocker rules to individual users or to a group of users. If you apply a rule to a group of users,
all users in that group are affected by that rule. If you need to allow a subset of a user group to use an app, you
can create a special rule for that subset. For example, the rule "Allow everyone to run Windows except Registry
Editor" allows everyone in the organization to run the Windows operating system, but it does not allow anyone
to run Registry Editor.
The effect of this rule would prevent users such as Help Desk personnel from running a program that is
necessary for their support tasks. To resolve this problem, create a second rule that applies to the Help Desk
user group: "Allow Help Desk to run Registry Editor." If you create a deny rule that does not allow any users to
run Registry Editor, the deny rule will override the second rule that allows the Help Desk user group to run
Registry Editor.
DLL rule collection

Because the DLL rule collection is not enabled by default, you must perform the following procedure before you
can create and enforce DLL rules.
procedure.
To enable the DLL rule collection
1. Click Star t , type secpol.msc , and then press ENTER.
2. If the User Account Control dialog box appears, confirm that the action it displays is what you want,
and then click Yes .
3. In the console tree, double-click Application Control Policies , right-click AppLocker , and then click
Proper ties .
4. Click the Advanced tab, select the Enable the DLL rule collection check box, and then click OK .
Impor tant: Before you enforce DLL rules, make sure that there are allow rules for each DLL that is
used by any of the allowed apps.
AppLocker wizards
You can create rules by using two AppLocker wizards:
1. The Create Rules Wizard enables you to create one rule at a time.
2. The Automatically Generate Rules Wizard allows you to create multiple rules at one time. You can either
select a folder and let the wizard create rules for the relevant files within that folder or in case of packaged
apps let the wizard create rules for all packaged apps installed on the computer. You can also specify the user
or group to which to apply the rules. This wizard automatically generates allow rules only.
Additional considerations
By default, AppLocker rules do not allow users to open or run any files that are not specifically allowed.
Administrators should maintain an up-to-date list of allowed applications.
There are two types of AppLocker conditions that do not persist following an update of an app:
A file hash condition File hash rule conditions can be used with any app because a
cryptographic hash value of the app is generated at the time the rule is created. However, the hash
value is specific to that exact version of the app. If there are several versions of the application in
use within the organization, you need to create file hash conditions for each version in use and for
any new versions that are released.
A publisher condition with a specific product version set If you create a publisher rule
condition that uses the Exactly version option, the rule cannot persist if a new version of the app
is installed. A new publisher condition must be created, or the version must be edited in the rule to
be made less specific.
If an app is not digitally signed, you cannot use a publisher rule condition for that app.
AppLocker rules cannot be used to manage computers running a Windows operating system earlier than
Windows Server 2008 R2 or Windows 7. Software Restriction Policies must be used instead. If AppLocker
rules are defined in a Group Policy Object (GPO), only those rules are applied. To ensure interoperability
between Software Restriction Policies rules and AppLocker rules, define Software Restriction Policies rules
and AppLocker rules in different GPOs.
The packaged apps and packaged apps installer rule collection is available on devices running at least
Windows Server 2012 and Windows 8.
When the rules for the executable rule collection are enforced and the packaged apps and packaged app
installers rule collection does not contain any rules, no packaged apps and packaged app installers are
allowed to run. In order to allow any packaged apps and packaged app installers, you must create rules
for the packaged apps and packaged app installers rule collection.
When an AppLocker rule collection is set to Audit only , the rules are not enforced. When a user runs an
application that is included in the rule, the app is opened and runs normally, and information about that
app is added to the AppLocker event log.
A custom configured URL can be included in the message that is displayed when an app is blocked.
Expect an increase in the number of Help Desk calls initially because of blocked apps until users
understand that they cannot run apps that are not allowed.
Applies to
Windows 10
Windows Server
This topic for IT professionals shows how to create an AppLocker rule with a file hash condition.
File hash rules use a system-computed cryptographic hash of the identified file.
For info about the file hash condition, see Understanding the File Hash Rule Condition in AppLocker.
You can perform this task by using the Group Policy Management Console for an AppLocker policy in a Group
Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local computer or
in a security template. For info how to use these MMC snap-ins to administer AppLocker, see Administer
AppLocker.
To create a new rule with a file hash condition
1. Open the AppLocker console, and then click the rule collection that you want to create the rule for.
2. On the Action menu, click Create New Rule .
3. On the Before You Begin page, click Next .
4. On the Permissions page, select the action (allow or deny) and the user or group that the rule should
apply to, and then click Next .
5. On the Conditions page, select the File hash rule condition, and then click Next .
6. Browse Files to locate the targeted application file.
Note: You can also click Browse Folders which calculates the hash for all the appropriate files
relative to the rule collection. To remove hashes individually, click the Remove button.
7. Click Next .
8. On the Name page, either accept the automatically generated rule name or type a new rule name, and
then click Create .
Applies to
Windows 10
Windows Server
This topic for IT professionals shows how to create an AppLocker rule with a path condition.
The path condition identifies an app by its location in the file system of the computer or on the network.
Impor tant: When creating a rule that uses a deny action, path conditions are less secure for preventing
access to a file because a user could easily copy the file to a different location than what is specified in the
rule. Because path rules correspond to locations within the file system, you should ensure that there are no
subdirectories that are writable by non-administrators. For example, if you create a path rule for C:\ with the
allow action, any file within C:\ will be allowed to run, including users' profiles.
For info about the path condition, see Understanding the path rule condition in AppLocker.
in a security template. For information how to use these MMC snap-ins to administer AppLocker, see Administer
AppLocker.
To create a new rule with a path condition
4. On the Permissions page, select the action (allow or deny) and the user or group that the rule should
apply to, and then click Next .
5. On the Conditions page, select the Path rule condition, and then click Next .
6. Click Browse Files to locate the targeted folder for the app.
Note: When you browse to a file or folder location, the wizard automatically converts absolute file
paths to use AppLocker path variables. You may edit the path after browsing to specify an absolute
path, or you may type the path directly into the Path box. To learn more about AppLocker path
variables, see Understanding the path rule condition in AppLocker.
7. Click Next .
8. (Optional) On the Exceptions page, specify conditions by which to exclude files from being affected by
the rule. Click Next .
9. On the Name page, either accept the automatically generated rule name or type a new rule name, and
then click Create .
Applies to
Windows 10
Windows Server
This topic for IT professionals shows how to create an AppLocker rule with a publisher condition.
You can use publisher conditions only for files that are digitally signed; the publisher condition identifies an app
based on its digital signature and extended attributes. The digital signature contains information about the
company that created the app (the publisher). The extended attributes, which are obtained from the binary
resource, contain the name of the product that the file is part of and the version number of the application. The
publisher may be a software development company, such as Microsoft, or the information technology
department of your organization. Packaged app rules are by definition rules that use publisher conditions. For
info about creating a packaged app rule, see Create a rule for packaged apps.
For info about the publisher condition, see Understanding the publisher rule condition in AppLocker.
AppLocker.
To create a new rule with a publisher condition
4. On the Permissions page, select the action (allow or deny) and the user or group that the rule should apply
to, and then click Next .
5. On the Conditions page, select the Publisher rule condition, and then click Next .
6. On the Publisher page, click Browse to select a signed file, and then use the slider to specify the scope of
the rule. To use custom values in any of the fields or to specify a specific file version, select the Use custom
values check box. For example, you can use the asterisk (*) wildcard character within a publisher rule to
specify that any value should be matched.
7. Click Next .
8. (Optional) On the Exceptions page, specify conditions by which to exclude files from being affected by the
rule. Click Next .
9. On the Name page, either accept the automatically generated rule name or type a new rule name, and then
click Create .
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to create a standard set of AppLocker rules that will allow
Windows system files to run.
AppLocker includes default rules for each rule collection. These rules are intended to help ensure that the files
that are required for Windows to operate properly are allowed to run.
IMPORTANT
You can use the default rules as a template when creating your own rules to allow files within the Windows folders to run.
However, these rules are only meant to function as a starter policy when you are first testing AppLocker rules. The default
rules can be modified in the same way as other AppLocker rule types.
in a security template. For information how to use these MMC snap-ins to administer AppLocker, see Administer
AppLocker.
To create default rules
1. Open the AppLocker console.
2. Right-click the appropriate rule type for which you want to automatically generate default rules. You can
automatically generate rules for executable, Windows Installer, script rules and Packaged app rules.
3. Click Create Default Rules .
Related topics
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to specify which apps can or cannot run as exceptions to an
AppLocker rule.
Rule exceptions allow you to specify files or folders to exclude from the rule. For more information about
exceptions, see Understanding AppLocker rule exceptions.
AppLocker.
To configure exceptions for a rule
2. Expand the rule collection, right-click the rule that you want to configure exceptions for, and then click
Proper ties .
3. Click the Exceptions tab.
4. In the Add exception box, select the rule type that you want to create, and then click Add .
For a publisher exception, click Browse , select the file that contains the publisher to exclude, and then
click OK .
For a path exception, choose the file or folder path to exclude, and then click OK .
For a file hash exception, edit the file hash rule, and click Remove .
For a packaged apps exception, click Add to create the exceptions based on reference app and rule
scope.
Create a rule for packaged apps
Applies to
Windows 10
Windows Server
This article for IT professionals shows how to create an AppLocker rule for packaged apps with a publisher
condition.
Packaged apps, also known as Universal Windows apps, are based on an app model that ensures that all the files
within an app package share the same identity. Therefore, it is possible to control the entire app using a single
AppLocker rule as opposed to the non-packaged apps where each file within the app could have a unique
identity. Windows does not support unsigned packaged apps, which implies all packaged apps must be signed.
AppLocker supports only publisher rules for packaged apps. A publisher rule for a packaged app is based on the
following information:
Publisher of the package
Package name
Package version
All the files within a package as well as the package installer share these attributes. Therefore, an AppLocker rule
for a packaged app controls both the installation as well as the running of the app. Otherwise, the publisher
rules for packaged apps are no different than the rest of the rule collections; they support exceptions, can be
increased or decreased in scope, and can be assigned to users and groups.
For info about the publisher condition, see Understanding the publisher rule condition in AppLocker.
AppLocker.
To create a packaged app rule
2. On the Action menu, or by right-clicking on Packaged app Rules , select Create New Rule .
3. On the Before You Begin page, select Next .
4. On the Permissions page, select the action (allow or deny) and the user or group that the rule should apply
to, and then select Next .
5. On the Publisher page, you can select a specific reference for the packaged app rule and set the scope for
the rule. The following table describes the reference options.
SEL EC T IO N DESC RIP T IO N EXA M P L E

Use an installed packaged If selected, AppLocker requires You want the Sales group only
app as a reference you to choose an app that is to use the app named
already installed on which to Microsoft.BingMaps for its
base your new rule. AppLocker outside sales calls. The
uses the publisher, package Microsoft.BingMaps app is
name and package version to already installed on the device
define the rule. where you are creating the rule,
so you choose this option, and
select the app from the list of
apps installed on the computer
and create the rule using this
app as a reference.
Use a packaged app If selected, AppLocker requires Your company has developed a
installer as a reference you to choose an app installer number of internal line-of-
on which to base your new rule. business packaged apps. The
A packaged app installer has the app installers are stored on a
.appx extension. AppLocker uses common file share. Employees
the publisher, package name, can install the required apps
and package version of the from that file share. You want to
installer to define the rule. allow all your employees to
install the Payroll app from this
share. So you choose this
option from the wizard, browse
to the file share, and choose the
installer for the Payroll app as a
reference to create your rule.
The following table describes setting the scope for the packaged app rule.
Applies to Any publisher This is the least restrictive scope You want the Sales group to use
condition for an Allow rule. It any packaged app from any
permits every packaged app to signed publisher. You set the
run or install. permissions to allow the Sales
group to be able to run any
Conversely, if this is a Deny app.
rule, then this option is the
most restrictive because it
denies all apps from installing or
running.
Applies to a specific Publisher This scopes the rule to all apps You want to allow all your users
published by a particular to install apps published by the
publisher. publisher of
Microsoft.BingMaps. You could
select Microsoft.BingMaps as a
reference and choose this rule
scope.
Applies to a Package name This scopes the rule to all You want to allow your Sales
packages that share the group to install any version of
publisher name and package the Microsoft.BingMaps app.
name as the reference file. You could select the
Microsoft.BingMaps app as a
reference and choose this rule
scope.
Applies to a Package version This scopes the rule to a You want to be very selective in
particular version of the what you allow. You do not
package. want to implicitly trust all future
updates of the
Microsoft.BingMaps app. You
can limit the scope of your rule
to the version of the app
currently installed on your
reference computer.
Applying custom values to the Selecting the Use custom You want to allow users to
rule values check box allows you to install all Microsoft.Bing*
adjust the scope fields for your applications, which include
particular circumstance. Microsoft.BingMaps,
Microsoft.BingWeather,
Microsoft.BingMoney. You can
choose the Microsoft.BingMaps
as a reference, select the Use
custom values check box and
edit the package name field by
adding “Microsoft.Bing*” as the
Package name.
6. Select Next .
7. (Optional) On the Exceptions page, specify conditions by which to exclude files from being affected by the
rule. This allows you to add exceptions based on the same rule reference and rule scope as you set before.
Select Next .
8. On the Name page, either accept the automatically generated rule name or type a new rule name, and then
select Create .
Applies to
Windows 10
Windows Server
This article for IT professionals describes the steps to delete an AppLocker rule.
As older apps are retired and new apps are deployed in your organization, it will be necessary to modify the
application control policies. If an app becomes unsupported by the IT department or is no longer allowed due to
the organization's security policy, then deleting the rule or rules associated with that app will prevent the app
from running.
For info about testing an AppLocker policy to see what rules affect which files or applications, see Test an
AppLocker policy by Using Test-AppLockerPolicy.
AppLocker.
These steps apply only for locally managed devices. If the device has AppLocker policies applied by using MDM
or a GPO, the local policy will not override those settings.
To delete a rule in an AppLocker policy

2. Click the appropriate rule collection for which you want to delete the rule.
3. In the details pane, right-click the rule to delete, click Delete , and then click Yes .
NOTE
When using Group Policy, the Group Policy Object must be distributed or refreshed for rule deletion to take effect on
devices.
Application Identity service needs to be running for deleting Applocker rules. If you disable Applocker and delete
Applocker rules, make sure to stop the Application Identity service after deleting Applocker rules. If the Application
Identity service is stopped before deleting Applocker rules, and if Applocker blocks apps that are disabled, delete all of
the files at C:\Windows\System32\AppLocker .
When the following procedure is performed on the local device, the AppLocker policy takes effect immediately.
To clear AppLocker policies on a single system or remote systems

Use the Set-AppLockerPolicy cmdlet with the -XMLPolicy parameter, using an .XML file that contains the
following contents:
<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" />
</AppLockerPolicy>
To use the Set-AppLockerPolicy cmdlet, first import the AppLocker modules:
PS C:\Users\Administrator> import-module AppLocker
We will create a file (for example, clear.xml), place it in the same directory where we are executing our cmdlet,
and add the preceding XML contents. Then run the following command:
C:\Users\Administrator> Set-AppLockerPolicy -XMLPolicy .\clear.xml
This will remove all AppLocker Policies on a machine and could be potentially scripted to use on multiple
machines using remote execution tools with accounts with proper access.
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to edit a publisher rule, path rule, and file hash rule in
AppLocker.
For more info about these rule types, see Understanding AppLocker rule condition types.
AppLocker.
To edit a publisher rule
1. Open the AppLocker console, and then click the appropriate rule collection.
2. In the Action pane, right-click the publisher rule, and then click Proper ties .
3. Click the appropriate tab to edit the rule properties.
Click the General tab to change the rule name, add a rule description, configure whether the rule is
used to allow or deny applications, and set the security group for which this rule should apply.
Click the Publisher tab to configure the certificate's common name, the product name, the file name,
or file version of the publisher.
Click the Exceptions tab to create or edit exceptions.
When you finish updating the rule, click OK .
To edit a file hash rule
2. Choose the appropriate rule collection.
3. In the Action pane, right-click the file hash rule, and then click Proper ties .
used to allow or deny applications, and set the security group in which this rule should apply.
Click the File Hash tab to configure the files that should be used to enforce the rule. You can click
Browse Files to add a specific file or click Browse Folders to add all files in a specified folder. To
remove hashes individually, click Remove .
To edit a path rule
2. Choose the appropriate rule collection.
3. In the Action pane, right-click the path rule, and then click Proper ties .
used to allow or deny applications, and set the security group in which this rule should apply.
Click the Path tab to configure the path on the computer in which the rule should be enforced.
Click the Exceptions tab to create exceptions for specific files in a folder.
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to enable the DLL rule collection feature for AppLocker.
The DLL rule collection includes the .dll and .ocx file formats.
For info about these rules, see DLL rules in AppLocker.
AppLocker.
To enable the DLL rule collection
1. From the AppLocker console, right-click AppLocker , and then click Proper ties.
2. Click the Advanced tab, select the Enable the DLL rule collection check box, and then click OK .
Impor tant: Before you enforce DLL rules, make sure that there are allow rules for each DLL that is
used by any of the allowed apps.
Applies to
Windows 10
Windows Server
This topic for IT professionals describes how to enforce application control rules by using AppLocker.
After AppLocker rules are created within the rule collection, you can configure the enforcement setting to
Enforce rules or Audit only on the rule collection.
events generated from that evaluation are written to the AppLocker log.
There is no audit mode for the DLL rule collection. DLL rules affect specific apps. Therefore, test the impact of
these rules first before deploying them to production.
To enforce AppLocker rules by configuring an AppLocker policy to Enforce rules , see Configure an AppLocker
policy for enforce rules.
Caution: AppLocker rules will be enforced immediately on the local device or when the Group Policy object
(GPO) is updated by performing this procedure. If you want to see the effect of applying an AppLocker
policy before setting the enforcement setting to Enforce rules , configure the policy to Audit only . For info
about how to do this, see Configure an AppLocker policy for audit onlyor Test an AppLocker policy by Using
Test-AppLockerPolicy.
Applies to
Windows 10
Windows Server
This topic for IT professionals describes steps to run the wizard to create AppLocker rules on a reference device.
AppLocker allows you to automatically generate rules for all files within a folder. It will scan the specified folder
and create the condition types that you choose for each file in that folder.
Policy Object (GPO) or by using the Local Security Policy snap-in for an AppLocker policy on a local device or in
a security template. For info how to use these MMC snap-ins to administer AppLocker, see Administer
AppLocker.
To automatically generate rules
2. Right-click the appropriate rule type for which you want to automatically generate rules. You can
automatically generate rules for executable, Windows Installer, script and packaged app rules.
3. Click Automatically Generate Rules .
4. On the Folder and Permissions page, click Browse to choose the folder to be analyzed. By default, this
is the Program Files folder.
5. Click Select to choose the security group in which the default rules should be applied. By default, this is
the Ever yone group.
6. The wizard provides a name in the Name to identify this set of rules box based on the name of the
folder that you have selected. Accept the provided name or type a different name, and then click Next .
7. On the Rule Preferences page, choose the conditions that you want the wizard to use while creating
rules, and then click Next . For more info about rule conditions, see Understanding AppLocker rule
condition types.
Note: The Reduce the number of rules created by grouping similar files check box is selected
by default. This helps you organize AppLocker rules and reduce the number of rules that you create
by performing the following operations for the rule condition that you select:
One publisher condition is created for all files that have the same publisher and product name.
One path condition is created for the folder that you select. For example, if you select C:\Program
Files\ProgramName\ and the files in that folder are not signed, the wizard creates a rule for
%programfiles%\ProgramName\*.
One file hash condition is created that contains all of the file hashes. When rule grouping is disabled,
the wizard creates a file hash rule for each file.
8. Review the files that were analyzed and the rules that will be automatically created. To make changes,
click Previous to return to the page where you can change your selections. After reviewing the rules,
click Create .
Note: If you are running the wizard to create your first rules for a GPO, you will be prompted to create the
default rules, which allow critical system files to run, after completing the wizard. You may edit the default
rules at any time. If your organization has decided to edit the default rules or create custom rules to allow
the Windows system files to run, ensure that you delete the default rules after replacing them with your
custom rules.
Working with AppLocker policies
Applies to
Windows 10
Windows Server
This topic for IT professionals provides links to procedural topics about creating, maintaining, and testing
AppLocker policies.
In this section
Configure the Application Identity service This topic for IT professionals shows how to configure the
Application Identity service to start automatically or
manually.
Configure an AppLocker policy for audit only This topic for IT professionals describes how to set
AppLocker policies to Audit only within your IT
environment by using AppLocker.
Configure an AppLocker policy for enforce rules This topic for IT professionals describes the steps to enable
the AppLocker policy enforcement setting.
Display a custom URL message when users try to run a This topic for IT professionals describes the steps for
blocked app displaying a customized message to users when an
AppLocker policy denies access to an app.
Export an AppLocker policy from a GPO This topic for IT professionals describes the steps to export
an AppLocker policy from a Group Policy Object (GPO) so
that it can be modified.
Export an AppLocker policy to an XML file This topic for IT professionals describes the steps to export
an AppLocker policy to an XML file for review or testing.
Import an AppLocker policy from another computer This topic for IT professionals describes how to import an
AppLocker policy.
Import an AppLocker policy into a GPO This topic for IT professionals describes the steps to import
an AppLocker policy into a Group Policy Object (GPO).
Add rules for packaged apps to existing AppLocker rule-set This topic for IT professionals describes how to update your
existing AppLocker policies for packaged apps using the
Remote Server Administration Toolkit (RSAT).
Merge AppLocker policies by using Set-ApplockerPolicy This topic for IT professionals describes the steps to merge
AppLocker policies by using Windows PowerShell.
Merge AppLocker policies manually This topic for IT professionals describes the steps to
manually merge AppLocker policies to update the Group
Policy Object (GPO).
Refresh an AppLocker policy This topic for IT professionals describes the steps to force an
update for an AppLocker policy.
Test an AppLocker policy by using Test-AppLockerPolicy This topic for IT professionals describes the steps to test an
AppLocker policy prior to importing it into a Group Policy
Object (GPO) or another computer.
Configure the Application Identity service
Applies to
Windows 10
Windows Server
This topic for IT professionals shows how to configure the Application Identity service to start automatically or
manually.
The Application Identity service determines and verifies the identity of an app. Stopping this service will prevent
AppLocker policies from being enforced.
Impor tant: When using Group Policy, you must configure it to start automatically in at least one Group
Policy Object (GPO) that applies AppLocker rules. This is because AppLocker uses this service to verify the
attributes of a file.
To star t the Application Identity ser vice automatically using Group Policy
1. On the Star t screen, type gpmc.msc to open the Group Policy Management Console (GPMC).
2. Locate the GPO to edit, right-click the GPO, and then click Edit .
3. In the console tree under Computer Configuration\Windows Settings\Security Settings , click
System Ser vices .
4. In the details pane, double-click Application Identity .
5. In Application Identity Proper ties , configure the service to start automatically.
Membership in the local Administrators group, or equivalent, is the minimum access required to complete this
procedure.
To star t the Application Identity ser vice manually
1. Right-click the taskbar, and click Task Manager .
2. Click the Ser vices tab, right-click AppIDSvc , and then click Star t Ser vice .
3. Verify that the status for the Application Identity service is Running .
Starting with Windows 10, the Application Identity service is now a protected process. Because of this, you can
no longer manually set the service Star tup type to Automatic by using the Sevices snap-in. Try either of these
methods instead:
Open an elevated command prompt or PowerShell session and type:
sc.exe config appidsvc start= auto
Create a security template that configures appidsvc to be automatic start, and apply it using secedit.exe or
LGPO.exe.
Applies to
Windows 10
Windows Server
This topic for IT professionals describes how to set AppLocker policies to Audit only within your IT
environment by using AppLocker.
After AppLocker rules are created within the rule collection, you can configure the enforcement setting to
Enforce rules or Audit only .
events generated from that evaluation are written to the AppLocker log. You can perform this task by using the
Group Policy Management Console for an AppLocker policy in a Group Policy Object (GPO) or by using the
Local Security Policy snap-in for an AppLocker policy on a local computer or in a security template. For info how
to use these MMC snap-ins to administer AppLocker, see Administer AppLocker.
To audit rule collections
1. From the AppLocker console, right-click AppLocker , and then click Proper ties .
2. On the Enforcement tab, select the Configured check box for the rule collection that you want to enforce,
and then verify that Audit only is selected in the list for that rule collection.
3. Repeat the above step to configure the enforcement setting to Audit only for additional rule collections.
4. Click OK .
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to enable the AppLocker policy enforcement setting.
Note: When AppLocker policy enforcement is set to Enforce rules , rules are enforced for the rule
collection and all events are audited.
For info about how AppLocker policies are applied within a GPO structure, see Understand AppLocker rules and
enforcement setting inheritance in Group Policy.
AppLocker.
To enable the Enforce rules enforcement setting
1. From the AppLocker console, right-click AppLocker , and then click Proper ties .
2. On the Enforcement tab of the AppLocker Proper ties dialog box, select the Configured check box for
the rule collection that you are editing, and then verify that Enforce rules is selected.
3. Click OK .
For info about viewing the events generated from rules enforcement, see Monitor app usage with AppLocker.
Display a custom URL message when users try to
run a blocked app
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps for displaying a customized message to users when an
AppLocker policy denies access to an app.
Using Group Policy, AppLocker can be configured to display a message with a custom URL. You can use this URL
to redirect users to a support site that contains info about why the user received the error and which apps are
allowed. If you do not display a custom message when an apps is blocked, the default access denied message is
displayed.
To complete this procedure, you must have the Edit Setting permission to edit a GPO. By default, members of
the Domain Admins group, the Enterprise Admins group, and the Group Policy Creator Owners
group have this permission.
To display a custom URL message when users tr y to run a blocked app
1. On the Star t screen, type gpmc.msc to open the Group Policy Management Console (GPMC).
2. Navigate to the Group Policy Object (GPO) that you want to edit.
3. Right-click the GPO, and then click Edit .
4. In the console tree under Policies\Administrative Templates\Windows Components , click File
Explorer .
5. In the details pane, double-click Set a suppor t web page link .
6. Click Enabled , and then type the URL of the custom Web page in the Suppor t Web page URL box.
7. Click OK to apply the setting.
Export an AppLocker policy from a GPO
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to export an AppLocker policy from a Group Policy Object
(GPO) so that it can be modified.
results. Therefore, export the policy from the GPO and update the rule or rules by using AppLocker on your
AppLocker reference device.
Expor t the policy from the GPO
1. In the Group Policy Management Console (GPMC), open the GPO that you want to edit.
2. In the console tree under Computer Configuration\Policies\Windows Settings\Security
Settings\Application Control Policies , click AppLocker .
3. Right-click AppLocker , and then click Expor t Policy .
4. In the Expor t Policy dialog box, type a name for the exported policy (for example, the name of the GPO),
select a location to save the policy, and then click Save .
5. The AppLocker dialog box will notify you of how many rules were exported. Click OK .
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to export an AppLocker policy to an XML file for review or
testing. Membership in the local Administrators group, or equivalent, is the minimum required to complete
this procedure.
To expor t an AppLocker policy to an XML file
1. From the AppLocker console, right-click AppLocker , and then click Expor t Policy .
2. Browse to the location where you want to save the XML file.
3. In the File name box, type a file name for the XML file, and then click Save .
Import an AppLocker policy from another computer
Applies to
Windows 10
Windows Server
This topic for IT professionals describes how to import an AppLocker policy.
Before completing this procedure, you should have exported an AppLocker policy. For more information, see
Export an AppLocker policy to an XML file.
procedure.
Caution: Importing a policy will overwrite the existing policy on that computer.
To impor t an AppLocker policy

1. From the AppLocker console, right-click AppLocker , and then click Impor t Policy .
2. In the Impor t Policy dialog box, locate the file that you exported, and then click Open .
3. The Impor t Policy dialog box will warn you that importing a policy will overwrite the existing rules and
enforcement settings. If acceptable, click OK to import and overwrite the policy.
4. The AppLocker dialog box will notify you of how many rules were overwritten and imported. Click OK .
Import an AppLocker policy into a GPO
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to import an AppLocker policy into a Group Policy Object
(GPO). AppLocker policies can be created as local security policies and modified like any other local security
policy, or they can be created as part of a GPO and managed by using Group Policy. You can create AppLocker
policies on any supported computer. For info about which Windows editions are supported, see Requirements
to Use AppLocker.
Impor tant: Follow your organization's standard procedures for updating GPOs. For info about specific
steps to follow for AppLocker policies, see Maintain AppLocker policies.
To impor t an AppLocker policy into a GPO
1. In the Group Policy Management Console (GPMC), open the GPO that you want to edit.
2. In the console tree under Computer Configuration\Policies\Windows Settings\Security
Settings\Application Control Policies , click AppLocker .
3. Right-click AppLocker , and then click Impor t Policy .
4. In the Impor t Policy dialog box, locate the XML policy file, and click Open .
5. The AppLocker dialog box will notify you of how many rules were imported. Click OK .
Add rules for packaged apps to existing AppLocker
rule-set
Applies to
Windows 10
Windows Server
This topic for IT professionals describes how to update your existing AppLocker policies for packaged apps using
the Remote Server Administration Toolkit (RSAT).
You can create packaged app rules for the computers running Windows Server 2012 or Windows 8 and later in
your domain by updating your existing AppLocker rule set. All you need is a computer running at least Windows
8. Download and install the Remote Server Administration Toolkit (RSAT) from the Microsoft Download Center.
RSAT comes with the Group Policy Management Console which allows you to edit the GPO or GPOs where your
existing AppLocker policy are authored. RSAT has the necessary files required to author packaged app rules.
Packaged app rules will be ignored on computers running Windows 7 and earlier but will be enforced on those
computers in your domain running at least Windows Server 2012 and Windows 8.
Merge AppLocker policies by using Set-
ApplockerPolicy
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to merge AppLocker policies by using Windows PowerShell.
The Set-AppLockerPolicy cmdlet sets the specified Group Policy Object (GPO) to contain the specified
AppLocker policy. If no Lightweight Directory Access Protocol (LDAP) is specified, the local GPO is the default.
When the Merge parameter is used, rules in the specified AppLocker policy will be merged with the AppLocker
rules in the target GPO specified in the LDAP path. The merging of policies will remove rules with duplicate rule
IDs, and the enforcement setting specified by the AppLocker policy in the target GPO will be preserved. If the
Merge parameter is not specified, then the new policy will overwrite the existing policy.
For info about using Set-AppLockerPolicy , including syntax descriptions and parameters, see Set-
AppLockerPolicy.
For info about using Windows PowerShell for AppLocker, including how to import the AppLocker cmdlets into
Windows PowerShell, see Use the AppLocker Windows PowerShell cmdlets.
You can also manually merge AppLocker policies. For the procedure to do this, see Merge AppLocker policies
manually.
To merge a local AppLocker policy with another AppLocker policy by using LDAP paths
1. Open the PowerShell command window. For info about performing Windows PowerShell commands for
AppLocker, see Use the AppLocker Windows PowerShell cmdlets.
2. At the command prompt, type C:\PS>Get-AppLockerPolicy -Local | Set-AppLockerPolicy -LDAP
"LDAP: // <string>" -Merge where <string> specifies the LDAP path of the unique GPO.
Example
Gets the local AppLocker policy, and then merges the policy with the existing AppLocker policy in the GPO
specified in the LDAP path.
C:\PS>Get-AppLockerPolicy -Local | Set-AppLockerPolicy -LDAP "LDAP://DC13.Contoso.com/CN={31B2F340-016D-

11D2-945F-00C044FB984F9},CN=Policies,CN=System,DC=Contoso,DC=com" -Merge
Merge AppLocker policies manually
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to manually merge AppLocker policies to update the Group
Policy Object (GPO).
If you have created multiple AppLocker policies and need to merge them to create one AppLocker policy, you
can either manually merge the policies or use the Windows PowerShell cmdlets for AppLocker. You cannot
automatically merge policies by using the AppLocker console. You must create one rule collection from two or
more policies. For info about merging policies by using the cmdlet, see Merge AppLocker policies by using Set-
ApplockerPolicy.
The AppLocker policy is saved in XML format, and the exported policy can be edited with any text or XML editor.
Rule collections are specified within the RuleCollection Type element. The XML schema includes five attributes
for the different rule collections, as shown in the following table:
RUL E C O L L EC T IO N RUL EC O L L EC T IO N T Y P E EL EM EN T
Executable rules Exe
Windows Installer rules Msi
Script rules Script
DLL rules Dll
Packaged apps and packaged app installers Appx
Rule enforcement is specified with the EnforcementMode element. The three enforcement modes in the XML
correspond to the three enforcement modes in the AppLocker console, as shown in the following table:
XM L EN F O RC EM EN T M O DE EN F O RC EM EN T M O DE IN GRO UP P O L IC Y
NotConfigured Not configured (rules are enforced)
AuditOnly Audit only
Enabled Enforce rules
Each of the three condition types use specific elements. For XML examples of the different rule types, see Merge
AppLocker policies manually.
procedure.
To merge two or more AppLocker policies
1. Open an XML policy file in a text editor or XML editor, such as Notepad.
2. Select the rule collection where you want to copy rules from.
3. Select the rules that you want to add to another policy file, and then copy the text.
4. Open the policy where you want to add the copied rules.
5. Select and expand the rule collection where you want to add the rules.
6. At the bottom of the rule list for the collection, after the closing element, paste the rules that you copied from
the first policy file. Verify that the opening and closing elements are intact, and then save the policy.
7. Upload the policy to a reference computer to ensure that it is functioning properly within the GPO.
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to force an update for an AppLocker policy.
If you update the rule collection on a local computer by using the Local Security Policy snap-in, the policy will
take effect immediately. If Group Policy is used to distribute the AppLocker policy and you want to immediately
implement the policy, you must manually refresh the policy. The Group Policy refresh might take several
minutes, depending upon the number of policies within the Group Policy Object (GPO) and the number of target
computers.
To use Group Policy to distribute the AppLocker policy change, you need to retrieve the deployed AppLocker
policy first. To prepare for the update and subsequent refresh, see Edit an AppLocker policy
Edit an AppLocker policy and Use the AppLocker Windows PowerShell cmdlets.
To complete this procedure, you must have Edit Setting permission to edit a GPO. By default, members of the
Domain Admins group, the Enterprise Admins group, and the Group Policy Creator Owners group have
this permission.
To manually refresh the AppLocker policy by using Group Policy
1. From a command prompt, type gpupdate /force , and then press ENTER.
2. When the command finishes, close the command prompt window, and then verify that the intended rule
behavior is correct. You can do this by checking the AppLocker event logs for events that include "policy
applied."
To change a policy on an individual computer, or to implement that policy on other computers, without using
Group Policy, you first need to update the rule within the rule collection. For information about updating existing
rules, see Edit AppLocker rules. For information about creating a new rule for an existing policy, see:
procedure.
To refresh the AppLocker policy on the local computer
Update the rule collection by using the Local Security Policy console with one of the following
procedures:
When finished, the policy is in effect.
To make the same change on another device, you can use any of the following methods:
From the device that you made the change on, export the AppLocker policy, and then import the policy
onto the other device. To do this, use the AppLocker Expor t Policy and Impor t Policy features to copy
the rules from the changed computer.
Caution: When importing rules from another computer, all the rules will be applied, not just the one
that was updated. Merging policies allows both existing and updated (or new) rules to be applied.
Merge AppLocker policies. For procedures to do this, see Merge AppLocker policies manually and Merge
AppLocker policies by using Set-ApplockerPolicy.
Test an AppLocker policy by using Test-
AppLockerPolicy
Applies to
Windows 10
Windows Server
This topic for IT professionals describes the steps to test an AppLocker policy prior to importing it into a Group
Policy Object (GPO) or another computer.
The Test-AppLockerPolicy Windows PowerShell cmdlet can be used to determine whether any of the rules in
your rule collections will be blocked on your reference computer or the computer on which you maintain
policies. Perform the following steps on any computer where the AppLocker policies are applied.
Any user account can be used to complete this procedure.
To test an AppLocker policy by using Test-AppLockerPolicy
1. Export the effective AppLocker policy. To do this, you must use the Get-AppLockerPolicy Windows
PowerShell cmdlet.
a. Open a Windows PowerShell command prompt window as an administrator.
b. Use the Get-AppLockerPolicy cmdlet to export the effective AppLocker policy to an XML file:
Get-AppLockerPolicy –Effective –XML > <PathofFiletoExport.XML>
2. Use the Get-ChildItem cmdlet to specify the directory that you want to test, specify the Test-
AppLockerPolicy cmdlet with the XML file from the previous step to test the policy, and use the Expor t-
CSV cmdlet to export the results to a file to be analyzed:
Get-ChildItem <DirectoryPathtoReview> -Filter <FileExtensionFilter> -Recurse | Convert-Path | Test-
AppLockerPolicy –XMLPolicy <PathToExportedPolicyFile> -User <domain\username> -Filter
<TypeofRuletoFilterFor> | Export-CSV <PathToExportResultsTo.CSV>
The following shows example input for Test-AppLockerPolicy :
PS C:\ Get-AppLockerPolicy –Effective –XML > C:\Effective.xml

PS C:\ Get-ChildItem 'C:\Program Files\Microsoft Office\' –filter *.exe –Recurse | Convert-Path | Test-
AppLockerPolicy –XMLPolicy C:\Effective.xml –User contoso\zwie –Filter Denied,DeniedByDefault | Export-CSV
C:\BlockedFiles.csv
In the example, the effective AppLocker policy is exported to the file C:\Effective.xml. The Get-ChildItem cmdlet
is used to recursively gather path names for the .exe files in C:\Program Files\Microsoft Office\. The XMLPolicy
parameter specifies that the C:\Effective.xml file is an XML AppLocker policy file. By specifying the User
parameter, you can test the rules for specific users, and the Expor t-CSV cmdlet allows the results to be
exported to a comma-separated file. In the example, -FilterDenied,DeniedByDefault displays only those files
that will be blocked for the user under the policy.
AppLocker design guide
Applies to
Windows 10
Windows Server
This topic for the IT professional introduces the design and planning steps required to deploy application control
policies by using AppLocker.
This guide provides important designing and planning information for deploying application control policies by
using AppLocker. It is intended for security architects, security administrators, and system administrators.
Through a sequential and iterative process, you can create an AppLocker policy deployment plan for your
organization that will address your specific application control requirements by department, organizational unit,
or business group.
This guide does not cover the deployment of application control policies by using Software Restriction Policies
(SRP). However, SRP is discussed as a deployment option in conjunction with AppLocker policies. For info about
these options, see Determine your application control objectives.
To understand if AppLocker is the correct application control solution for your organization, see Understand
AppLocker policy design decisions.
In this section
Understand AppLocker policy design decisions This topic for the IT professional lists the design questions,
possible answers, and ramifications of the decisions when
you plan a deployment of application control policies by
using AppLocker within a Windows operating system
environment.
Determine your application control objectives This topic helps you with the decisions you need to make to
determine what applications to control and how to control
them by comparing Software Restriction Policies (SRP) and
AppLocker.
Create a list of apps deployed to each business group This topic describes the process of gathering app usage
requirements from each business group in order to
implement application control policies by using AppLocker.
Select the types of rules to create This topic lists resources you can use when selecting your
application control policy rules by using AppLocker.
Determine the Group Policy structure and rule enforcement This overview topic describes the process to follow when you
are planning to deploy AppLocker rules.
Plan for AppLocker policy management This topic for describes the decisions you need to make to
AppLocker policies.
After careful design and detailed planning, the next step is to deploy AppLocker policies. AppLocker
Deployment Guide covers the creation and testing of policies, deploying the enforcement setting, and managing
and maintaining the policies.
Applies to
Windows 10
Windows Server
This topic for the IT professional lists the design questions, possible answers, and ramifications of the decisions
when you plan a deployment of application control policies by using AppLocker within a Windows operating
system environment.
When you begin the design and planning process, you should consider the ramifications of your design choices.
The resulting decisions will affect your policy deployment scheme and subsequent application control policy
maintenance.
You should consider using AppLocker as part of your organization's application control policies if all the
following are true:
You have deployed or plan to deploy the supported versions of Windows in your organization. For specific
operating system version requirements, see Requirements to Use AppLocker.
You need improved control over the access to your organization's applications and the data your users
access.
The number of applications in your organization is known and manageable.
You have resources to test policies against the organization's requirements.
You have resources to involve Help Desk or to build a self-help process for end-user application access
issues.
The group's requirements for productivity, manageability, and security can be controlled by restrictive
policies.
The following questions are not in priority or sequential order. They should be considered when you deploy
application control policies (as appropriate for your targeted environment).
Which apps do you need to control in your organization?
You might need to control a limited number of apps because they access sensitive data, or you might have to
exclude all applications except those that are sanctioned for business purposes. There might be certain business
groups that require strict control, and others that promote independent application usage.
Control all apps AppLocker policies control applications by creating an

allowed list of applications by file type. Exceptions are also
possible. AppLocker policies can only be applied to
applications installed on computers running one of the
supported versions of Windows. For specific operating
system version requirements, see Requirements to use
AppLocker.
Control specific apps When you create AppLocker rules, a list of allowed apps are
created. All apps on that list will be allowed to run (except
those on the exception list). Apps that are not on the list will
be prevented from running. AppLocker policies can only be
applied to apps installed on computers running any of the
supported versions of Windows. For specific operating
system version requirements, see Requirements to use
AppLocker.
Control only Classic Windows applications, only Universal AppLocker policies control apps by creating an allowed list of
Windows apps, or both apps by file type. Because Universal Windows apps are
categorized under the Publisher condition, Classic Windows
applications and Universal Windows apps can be controlled
together. AppLocker policies for Universal Windows apps can
be applied only to apps that are installed on PCs that
support the Microsoft Store, but Classic Windows
applications can be controlled with AppLocker on all
supported versions of Windows. The rules you currently
have configured for Classic Windows applications can
remain, and you can create new ones for Universal Windows
apps.
For a comparison of Classic Windows applications and
Universal Windows apps, see Comparing Classic Windows
applications and Universal Windows apps for AppLocker
policy design decisions in this topic.
Control apps by business group and user AppLocker policies can be applied through a Group Policy
Object (GPO) to computer objects within an organizational
unit (OU). Individual AppLocker rules can be applied to
individual users or to groups of users.
Control apps by computer, not user AppLocker is a computer-based policy implementation. If

your domain or site organizational structure is not based on
a logical user structure, such as an OU, you might want to
set up that structure before you begin your AppLocker
planning. Otherwise, you will have to identify users, their
computers, and their app access requirements.
Understand app usage, but there is no need to control any AppLocker policies can be set to audit app usage to help you
apps yet track which apps are used in your organization. You can then
use the AppLocker event log to create AppLocker policies.
Impor tant: The following list contains files or types of files that cannot be managed by AppLocker:
AppLocker does not protect against running 16-bit DOS binaries in a NT Virtual DOS Machine (NTVDM).
This technology allows running legacy DOS and 16-bit Windows programs on computers that are using
Intel 80386 or higher when there is already another operating system running and controlling the
hardware. The result is that 16-bit binaries can still run on Windows Server 2008 R2 and Windows 7
when AppLocker is configured to otherwise block binaries and libraries. If it is a requirement to prevent
16-bit applications from running, you must configure the Deny rule in the Executable rule collection for
NTVDM.exe.
You cannot use AppLocker to prevent code from running outside the Win32 subsystem. In particular, this
applies to the (POSIX) subsystem in Windows NT. If it is a requirement to prevent applications from
running in the POSIX subsystem, you must disable the subsystem.
AppLocker can only control VBScript, JScript, .bat files, .cmd files and Windows PowerShell scripts. It does
not control all interpreted code that runs within a host process, for example Perl scripts and macros.
Interpreted code is a form of executable code that runs within a host process. For example, Windows
batch files (*.bat) run within the context of the Windows Command Host (cmd.exe). To use AppLocker to
control interpreted code, the host process must call AppLocker before it runs the interpreted code, and
then enforce the decision that is returned by AppLocker. Not all host processes call into AppLocker.
Therefore, AppLocker cannot control every kind of interpreted code, for example Microsoft Office macros.
Impor tant: You should configure the appropriate security settings of these host processes if you
must allow them to run. For example, configure the security settings in Microsoft Office to ensure that
only signed and trusted macros are loaded.
AppLocker rules allow or prevent an app from launching. AppLocker does not control the behavior of
apps after they are launched. Applications could contain flags that are passed to functions that signal
AppLocker to circumvent the rules and allow another .exe or .dll file to be loaded. In practice, an app that
is allowed by AppLocker could use these flags to bypass AppLocker rules and launch child processes. You
must follow a process that best suits your needs to thoroughly vet each app before allowing them to run
using AppLocker rules.
For more info, see Security considerations for AppLocker.
Comparing Classic Windows applications and Universal Windows apps for AppLocker policy design decisions
AppLocker policies for Universal Windows apps can only be applied to apps that are installed on computers
running Windows operating systems that support Microsoft Store apps. However, Classic Windows applications
can be controlled in Windows Server 2008 R2 and Windows 7, in addition to those computers that support
Universal Windows apps. The rules for Classic Windows applications and Universal Windows apps can be
enforced together. The differences you should consider for Universal Windows apps are:
All Universal Windows apps can be installed by a standard user, whereas a number of Classic Windows
applications require administrative credentials to install. So in an environment where most of the users are
standard users, you might not need numerous exe rules, but you might want more explicit policies for
packaged apps.
Classic Windows applications can be written to change the system state if they run with administrative
credentials. Most Universal Windows apps cannot change the system state because they run with limited
permissions. When you design your AppLocker policies, it is important to understand whether an app that
you are allowing can make system-wide changes.
Universal Windows apps can be acquired through the Store, or they can be side-loaded by using Windows
PowerShell cmdlets. If you use Windows PowerShell cmdlets, a special Enterprise license is required to
acquire Universal Windows apps. Classic Windows applications can be acquired through traditional means,
such as through software vendors or retail distribution.
AppLocker controls Universal Windows apps and Classic Windows applications by using different rule
collections. You have the choice to control Universal Windows apps, Classic Windows applications, or both.
For more info, see Packaged apps and packaged app installer rules in AppLocker.
How do you currently control app usage in your organization?
Most organizations have evolved app control policies and methods over time. With heightened security
concerns and an emphasis on tighter IT control over desktop use, your organization might decide to consolidate
app control practices or design a comprehensive application control scheme. AppLocker includes improvements
over SRP in the architecture and management of application control policies.
Security polices (locally set or through Group Policy) Using AppLocker requires increased effort in planning to
create correct policies, but this results in a simpler
distribution method.
Non-Microsoft app control software Using AppLocker requires a complete app control policy
evaluation and implementation.
Managed usage by group or OU Using AppLocker requires a complete app control policy
Authorization Manager or other role-based access Using AppLocker requires a complete app control policy
technologies evaluation and implementation.
Other Using AppLocker requires a complete app control policy

Which Windows desktop and server operating systems are running in your organization?
If your organization supports multiple Windows operating systems, app control policy planning becomes more
complex. Your initial design decisions should consider the security and management priorities of applications
that are installed on each version of the operating system.
Your organization's computers are running a AppLocker rules are only applied to computers running
combination of the following operating systems: the supported versions of Windows, but SRP rules can
be applied to all versions of Windows beginning with
Windows 10 Windows XP and Windows Server 2003. For specific
Windows 8 operating system version requirements, see
Requirements to use AppLocker.
Windows 7
Windows Vista Note
If you are using the Basic User security level as
Windows XP assigned in SRP, those privileges are not supported on
Windows Server 2012 computers running that support AppLocker.
Windows Server 2008 R2

Windows Server 2008 AppLocker policies as applied through a GPO take
precedence over SRP policies in the same or linked GPO.
Windows Server 2003 SRP policies can be created and maintained the same
way.
Your organization's computers are running only the Use AppLocker to create your application control
following operating systems: policies.
Windows 10
Windows 8.1
Windows 8
Windows 7
Windows Server 2012
Are there specific groups in your organization that need customized application control policies?
Most business groups or departments have specific security requirements that pertain to data access and the
applications used to access that data. You should consider the scope of the project for each group and the
group’s priorities before you deploy application control policies for the entire organization.
Yes For each group, you need to create a list that includes their
application control requirements. Although this may increase
the planning time, it will most likely result in a more effective
deployment.
If your GPO structure is not currently configured so that you
can apply different policies to specific groups, you can
alternatively apply AppLocker rules in a GPO to specific user
groups.
No AppLocker policies can be applied globally to applications

that are installed on PCs running the supported versions of
Windows as listed in Requirements to use AppLocker.
Depending on the number of apps you need to control,
managing all the rules and exceptions might be challenging.
Does your IT department have resources to analyze application usage, and to design and manage the
policies?
The time and resources that are available to you to perform the research and analysis can affect the detail of
your plan and processes for continuing policy management and maintenance.
Yes Invest the time to analyze your organization's application

control requirements, and plan a complete deployment that
uses rules that are as simply constructed as possible.
No Consider a focused and phased deployment for specific

groups by using a small number of rules. As you apply
controls to applications in a specific group, learn from that
deployment to plan your next deployment.
Does your organization have Help Desk support?

Preventing your users from accessing known, deployed, or personal applications will initially cause an increase
in end-user support. It will be necessary to address the various support issues in your organization so security
policies are followed and business workflow is not hampered.
Yes Involve the support department early in the planning phase

because your users may inadvertently be blocked from using
their applications, or they may seek exceptions to use
specific applications.
No Invest time in developing online support processes and

documentation before deployment.
Do you know what applications require restrictive policies?

Any successful application control policy implementation is based on your knowledge and understanding of app
usage within the organization or business group. In addition, the application control design is dependent on the
security requirements for data and the apps that access that data.
Yes You should determine the application control priorities for a

business group and then attempt to design the simplest
scheme for their application control policies.
No You will have to perform an audit and requirements

gathering project to discover the application usage.
AppLocker provides the means to deploy policies in Audit
only mode, and tools to view the event logs.
How do you deploy or sanction applications (upgraded or new) in your organization?

Implementing a successful application control policy is based on your knowledge and understanding of
application usage within the organization or business group. In addition, the application control design is
dependent on the security requirements for data and the applications that access that data. Understanding the
upgrade and deployment policy will help shape the construction of the application control policies.
Ad hoc You need to gather requirements from each group. Some

groups might want unrestricted access or installation, while
other groups might want strict controls.
Strict written policy or guidelines to follow You need to develop AppLocker rules that reflect those
policies, and then test and maintain the rules.
No process in place You need to determine if you have the resources to develop
an application control policy, and for which groups.
Does your organization already have SRP deployed?

Although SRP and AppLocker have the same goal, AppLocker is a major revision of SRP.
Yes You cannot use AppLocker to manage SRP settings, but you
can use SRP to manage application control policies on
computers running on any of the supported operating
systems listed in Requirements to use AppLocker. In
addition, if AppLocker and SRP settings are configured in the
same GPO, only the AppLocker settings will be enforced on
computers running those supported operating systems.
Note: If you are using the Basic User security level as

assigned in SRP, those permissions are not supported on
computers running the supported operating systems.
No Policies that are configured for AppLocker can only be

applied to computers running the supported operating
systems, but SRP is also available on those operating
systems.
What are your organization's priorities when implementing application control policies?
Some organizations will benefit from application control policies as shown by an increase in productivity or
conformance, while others will be hindered in performing their duties. Prioritize these aspects for each group to
allow you to evaluate the effectiveness of AppLocker.
Productivity: The organization assures that tools work and To meet innovation and productivity goals, some groups
required applications can be installed. require the ability to install and run a variety of software
from different sources, including software that they
developed. Therefore, if innovation and productivity is a high
priority, managing application control policies through an
allowed list might be time consuming and an impediment to
progress.
Management: The organization is aware of and controls the In some business groups, application usage can be managed
apps it supports. from a central point of control. AppLocker policies can be
built into a GPO for that purpose. This shifts the burden of
app access to the IT department, but it also has the benefit
of controlling the number of apps that can be run and
controlling the versions of those apps
Security: The organization must protect data in part by AppLocker can help protect data by allowing a defined set of
ensuring that only approved apps are used. users access to apps that access the data. If security is the
top priority, the application control policies will be the most
restrictive.
How are apps currently accessed in your organization?

AppLocker is very effective for organizations that have application restriction requirements if they have
environments with a simple topography and application control policy goals that are straightforward. For
example, AppLocker can benefit an environment where non-employees have access to computers that are
connected to the organizational network, such as a school or library. Large organizations also benefit from
AppLocker policy deployment when the goal is to achieve a detailed level of control on the desktop computers
with a relatively small number of applications to manage, or when the applications are manageable with a small
number of rules.
Users run without administrative rights. Apps are installed by using an installation deployment
technology.
AppLocker can help reduce the total cost of ownership for Users must be able to install applications as needed.
business groups that typically use a finite set of apps, such
as human resources and finance departments. At the same
time, these departments access highly sensitive information,
much of which contains confidential and proprietary
information. By using AppLocker to create rules for specific
apps that are allowed to run, you can help limit
unauthorized applications from accessing this information.
**Note: **AppLocker can also be effective in helping create
standardized desktops in organizations where users run as
administrators. However, it is important to note that users
with administrative credentials can add new rules to the local
AppLocker policy.
Users currently have administrator access, and it would be Enforcing AppLocker rules is not suited for business groups
difficult to change this. that must be able to install apps as needed and without
approval from the IT department. If one or more OUs in
your organization has this requirement, you can choose not
to enforce application rules in those OUs by using
AppLocker or to implement the Audit only enforcement
setting through AppLocker.
Is the structure in Active Directory Domain Services based on the organization's hierarchy?
Designing application control policies based on an organizational structure that is already built into Active
Directory Domain Services (AD DS) is easier than converting the existing structure to an organizational
structure. Because the effectiveness of application control policies is dependent on the ability to update policies,
consider what organizational work needs to be accomplished before deployment begins.
Yes AppLocker rules can be developed and implemented

through Group Policy, based on your AD DS structure.
No The IT department must create a scheme to identify how

application control policies can be applied to the correct user
or computer.
Record your findings

The next step in the process is to record and analyze your answers to the preceding questions. If AppLocker is
the right solution for your goals, you can set your application control policy objectives and plan your AppLocker
rules. This process culminates in creating your planning document.
For info about setting your policy goals, see Determine your application control objectives.
Applies to
Windows 10
Windows Server
This article helps with decisions you need to make to determine what applications to control and how to control
them by comparing Software Restriction Policies (SRP) and AppLocker.
AppLocker is effective for organizations with app restriction requirements whose environments have a simple
topography and whose application control policy goals are straightforward. For example, AppLocker can benefit
an environment where non-employees have access to computers connected to the organizational network, such
as a school or library. Large organizations also benefit from AppLocker policy deployment when the goal is a
detailed level of control on the PCs they manage for a relatively small number of apps.
There are management and maintenance costs associated with a list of allowed apps. In addition, the purpose of
application control policies is to allow or prevent employees from using apps that might actually be productivity
tools. Keeping employees or users productive while implementing the policies can cost time and effort. Lastly,
creating user support processes and network support processes to keep the organization productive are also
concerns.
Use the following table to develop your own objectives and determine which application control feature best
addresses those objectives.
Scope SRP policies can be applied to all AppLocker policies apply only to
Windows operating systems the support versions of Windows
beginning with Windows XP and listed in Requirements to use
Windows Server 2003. AppLocker.
Policy creation SRP policies are maintained AppLocker policies are maintained
through Group Policy and only the through Group Policy and only the
administrator of the GPO can administrator of the GPO can
update the SRP policy. The update the policy. The
administrator on the local administrator on the local
computer can modify the SRP computer can modify the
policies defined in the local GPO. AppLocker policies defined in the
local GPO.
Policy maintenance SRP policies must be updated by AppLocker policies can be updated
using the Local Security Policy by using the Local Security Policy
snap-in (if the policies are created snap-in, if the policies are created
locally) or the Group Policy locally, or the GPMC, or the
Management Console (GPMC). Windows PowerShell AppLocker
cmdlets.
Policy application SRP policies are distributed AppLocker policies are distributed
through Group Policy. through Group Policy.
Enforcement mode SRP works in the “deny list mode” By default, AppLocker works in
where administrators can create allow list mode. Only those files
rules for files that they don't want are allowed to run for which
to allow in this Enterprise, but the there's a matching allow rule.
rest of the files are allowed to run
by default.
SRP can also be configured in the
“allow list mode” such that by
default all files are blocked and
administrators need to create
allow rules for files that they want
to allow.
File types that can be controlled SRP can control the following file AppLocker can control the
types: following file types:
Executables Executables
DLLs DLLs
Scripts Scripts
Windows Installers Windows Installers
SRP cannot control each file type Packaged apps and
separately. All SRP rules are in a installers
single rule collection.
AppLocker maintains a separate
rule collection for each of the five
file types.
Designated file types SRP supports an extensible list of AppLocker doesn't support this.
file types that are considered AppLocker currently supports the
executable. You can add extensions following file extensions:
for files that should be considered
executable. Executables (.exe, .com)
DLLs (.ocx, .dll)
Scripts (.vbs, .js, .ps1, .cmd,
.bat)
Windows Installers (.msi,
.mst, .msp)
Packaged app installers
(.appx)
Rule types SRP supports four types of rules: AppLocker supports three types of
rules:
Hash
Hash
Path
Path
Signature
Publisher
Internet zone
Editing the hash value SRP allows you to select a file to AppLocker computes the hash
hash. value itself. Internally it uses the
SHA2 Authenticode hash for
Portable Executables (exe and DLL)
and Windows Installers and an
SHA2 flat file hash for the rest.
Support for different security levels With SRP, you can specify the AppLocker does not support
permissions with which an app can security levels.
run. Then configure a rule such
that Notepad always runs with
restricted permissions and never
with administrative privileges.
SRP on Windows Vista and earlier
supported multiple security levels.
On Windows 7, that list was
restricted to just two levels:
Disallowed and Unrestricted (Basic
User translates to Disallowed).
Manage Packaged apps and Unable .appx is a valid file type which
Packaged app installers. AppLocker can manage.
Targeting a rule to a user or a SRP rules apply to all users on a AppLocker rules can be targeted
group of users particular computer. to a specific user or a group of
users.
Support for rule exceptions SRP does not support rule AppLocker rules can have
exceptions exceptions that allow
administrators to create rules such
as “Allow everything from
Windows except for Regedit.exe”.
Support for audit mode SRP doesn't support audit mode. AppLocker supports audit mode
The only way to test SRP policies is that allows administrators to test
to set up a test environment and the effect of their policy in the real
run a few experiments. production environment without
impacting the user experience.
Once you are satisfied with the
results, you can start enforcing the
policy.
Support for exporting and SRP does not support policy AppLocker supports the importing
importing policies import/export. and exporting of policies. This
allows you to create AppLocker
policy on a sample computer, test
it out and then export that policy
and import it back into the desired
GPO.
Rule enforcement Internally, SRP rules enforcement Internally, AppLocker rules for exes
happens in user-mode, which is and dlls are enforced in kernel-
less secure. mode, which is more secure than
enforcing them in the user-mode.
For more general info, see AppLocker.

Create a list of apps deployed to each business
group
Applies to
Windows 10
Windows Server
This topic describes the process of gathering app usage requirements from each business group in order to
implement application control policies by using AppLocker.
Determining app usage

For each business group, determine the following information:
The complete list of apps used, including different versions of an app
The full installation path of the app
The publisher and signed status of each app
The type of requirement the business groups set for each app, such as business critical, business productivity,
optional, or personal. It might also be helpful during this effort to identify which apps are supported or
unsupported by your IT department, or supported by others outside your control.
A list of files or apps that require administrative credentials to install or run. If the file requires administrative
credentials to install or run, users who cannot provide administrative credentials will be prevented from
running the file even if the file is explicitly allowed by an AppLocker policy. Even with AppLocker policies
enforced, only members of the Administrators group can install or run files that require administrative
credentials.
How to perform the app usage assessment
You might already have a method in place to understand app usage for each business group. You'll need to use
this information to help create your AppLocker rule collection. AppLocker includes the Automatically Generate
Rules wizard and the Audit only enforcement configuration to assist you with planning and creating your rule
collection.
Application inventor y methods
Using the Automatically Generate Rules wizard quickly creates rules for the applications you specify. The wizard
is designed specifically to build a rule collection. You can use the Local Security Policy snap-in to view and edit
the rules. This method is useful when creating rules from a reference computer and when creating and
evaluating AppLocker policies in a testing environment. However, it does require that the files be accessible on
the reference computer or through a network drive. This might mean additional work in setting up the reference
computer and determining a maintenance policy for that computer.
Using the Audit only enforcement method permits you to view the logs because it collects information about
every process on the computers receiving the Group Policy Object (GPO). Therefore, you can see what the
enforcement will be on the computers in a business group. AppLocker includes Windows PowerShell cmdlets
that you can use to analyze the events from the event log and cmdlets to create rules. However, when you use
Group Policy to deploy to several computers, a means to collect events in a central location is very important for
manageability. Because AppLocker logs information about files that users or other processes start on a
computer, you could miss creating some rules initially. Therefore, you should continue your evaluation until you
can verify that all required applications that are allowed to run are accessed successfully.
TIP
If you run Application Verifier against a custom application with any AppLocker policies enabled, it might prevent the
application from running. You should either disable Application Verifier or AppLocker.
You can create an inventory of Universal Windows apps on a device by using two methods: the Get-AppxPackage
Windows PowerShell cmdlet or the AppLocker console.
The following topics describe how to perform each method:

Prerequisites to completing the inventory
Identify the business group and each organizational unit (OU) within that group to which you will apply
application control policies. In addition, you should have identified whether or not AppLocker is the most
appropriate solution for these policies. For info about these steps, see the following topics:
Next steps
Identify and develop the list of apps. Record the name of the app, whether it is signed or not as indicated by the
publisher's name, and whether or not it is a mission critical, business productivity, optional, or personal
application. Record the installation path of the apps. For info about how to do this, see Document your app list.
After you have created the list of apps, the next step is to identify the rule collections, which will become the
policies. This information can be added to the table under columns labeled:
Use default rule or define new rule condition
Allow or deny
GPO name
For guidance, see the following topics:
Determine the Group Policy structure and rule enforcement
Document your app list
Applies to
Windows 10
Windows Server
This planning topic describes the app information that you should document when you create a list of apps for
AppLocker policies.

Apps
Record the name of the app, whether it is signed as indicated by the publisher's name, and whether it is a
mission critical, business productivity, optional, or personal app. Later, as you manage your rules, AppLocker
displays this information in the format shown in the following example: MICROSOFT OFFICE INFOPATH signed
by O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US .
Installation path
Record the installation path of the apps. For example, Microsoft Office 2016 installs files to
%programfiles%\Microsoft Office\Office16\, which is C:\Program Files\Microsoft Office\Office16\ on most
devices.
The following table provides an example of how to list applications for each business group at the early stage of
designing your application control policies. Eventually, as more planning information is added to the list, the
information can be used to build AppLocker rules.
O RGA N IZ AT IO N A L IM P L EM EN T
B USIN ESS GRO UP UN IT A P P LO C K ER? APPS IN STA L L AT IO N PAT H
Bank Tellers Teller-East and Yes Teller Software C:\Program

Teller-West Files\Woodgrove
\Teller.exe
Windows files C:\Windows
Human HR-All Yes Check Payout C:\Program

Resources Files\Woodgrove
\HR\Checkcut.exe
Time Sheet C:\Program

Organizer Files\Woodgrove
\HR\Timesheet.ex
e
O RGA N IZ AT IO N A L IM P L EM EN T
B USIN ESS GRO UP UN IT A P P LO C K ER? APPS IN STA L L AT IO N PAT H
Internet C:\Program
Explorer 7 Files\Internet
Explorer</p>
Windows files C:\Windows
>Note: AppLocker only supports publisher rules for Universal Windows apps. Therefore, collecting the installation
path information for Universal Windows apps is not necessary. Event processing
As you create your list of apps, you need to consider how to manage the events that are generated by user
access, or you need to deny running those apps to make your users as productive as possible. The following list
is an example of what to consider and what to record:
Will event forwarding be implemented for AppLocker events?
What is the location of the AppLocker event collection?
Should an event archival policy be implemented?
Will the events be analyzed and how often?
Should a security policy be in place for event collection?
Policy maintenance
As you create your list of apps, you need to consider how to manage and maintain the policies that you will
eventually create. The following list is an example of what to consider and what to record:
How will rules be updated for emergency app access and permanent access?
How will apps be removed?
How many older versions of the same app will be maintained?
How will new apps be introduced?
Next steps
After you have created the list of applications, the next step is to identify the rule collections, which will become
the application control policies. This information can be added to the table under the following columns:
Use default rule or define new rule condition
Allow or deny
GPO name
To identify the rule collections, see the following topics:
Determine Group Policy structure and rule enforcement
Applies to
Windows 10
Windows Server
This topic lists resources you can use when selecting your application control policy rules by using AppLocker.
When determining what types of rules to create for each of your groups, you should also determine what
enforcement setting to use for each group. Different rule types are more applicable for some apps, depending
on the way that the applications are deployed in a specific business group.
The following topics provide additional information about AppLocker rules that can help you decide what rules
to use for your applications:
Select the rule collection
The rules you create will be in one of the following rule collections:
Executable files: .exe and .com
Windows Installer files: .msi, .msp, and .mst
Scripts: .ps1, .bat, .cmd, .vbs, and .js
Packaged apps and packaged app installers: .appx
DLLs: .dll and .ocx
By default, the rules will allow a file to run based upon user or group privilege. If you use DLL rules, a DLL allow
rule has to be created for each DLL that is used by all of the allowed apps. The DLL rule collection is not enabled
by default.
In the Woodgrove Bank example, the line-of-business app for the Bank Tellers business group is C:\Program
Files\Woodgrove\Teller.exe, and this app needs to be included in a rule. In addition, because this rule is part of a
list of allowed applications, all the Windows files under C:\Windows must be included as well.
Determine the rule condition
A rule condition is criteria upon which an AppLocker rule is based and can only be one of the rule conditions in
the following table.
RUL E C O N DIT IO N USA GE SC EN A RIO RESO URC ES

RUL E C O N DIT IO N USA GE SC EN A RIO RESO URC ES
Publisher To use a publisher condition, the files For more info about this rule
must be digitally signed by the condition, see Understanding the
software publisher, or you must do so publisher rule condition in AppLocker.
by using an internal certificate. Rules
that are specified to the version level
might have to be updated when a new
version of the file is released.
Path Any file can be assigned this rule For more info about this rule
condition; however, because path rules condition, see Understanding the path
specify locations within the file system, rule condition in AppLocker.
any subdirectory will also be affected
by the rule (unless explicitly exempted).
File hash Any file can be assigned this rule For more info about this rule
condition; however, the rule must be condition, see Understanding the file
updated each time a new version of hash rule condition in AppLocker.
the file is released because the hash
value is based in part upon the
version.
In the Woodgrove Bank example, the line-of-business app for the Bank Tellers business group is signed and is
located at C:\Program Files\Woodgrove\Teller.exe. Therefore, the rule can be defined with a publisher condition.
If the rule is defined to a specific version and above (for example, Teller.exe version 8.0 and above), then this will
allow any updates to this app to occur without interruption of access to the users if the app's name and signed
attributes stay the same.
Determine how to allow system files to run
Because AppLocker rules build a list of allowed apps, a rule or rules must be created to allow all Windows files
to run. AppLocker provides a means to ensure system files are properly considered in your rule collection by
generating the default rules for each rule collection. You can use the default rules (listed in AppLocker default
rules) as a template when creating your own rules. However, these rules are only meant to function as a starter
policy when you are first testing AppLocker rules so that the system files in the Windows folders will be allowed
to run. When a default rule is created, it is denoted with "(Default rule)" in its name as it appears in the rule
collection.
You can also create a rule for the system files based on the path condition. In the preceding example, for the
Bank Tellers group, all Windows files reside under C:\Windows and can be defined with the path rule condition
type. This will permit access to these files whenever updates are applied and the files change. If you require
additional application security, you might need to modify the rules created from the built-in default rule
collection. For example, the default rule to allow all users to run .exe files in the Windows folder is based on a
path condition that allows all files within the Windows folder to run. The Windows folder contains a Temp
subfolder to which the Users group is given the following permissions:
Traverse Folder/Execute File
Create Files/Write Data
Create Folders/Append Data
These permissions settings are applied to this folder for application compatibility. However, because any user
can create files in this location, allowing apps to be run from this location might conflict with your organization's
security policy.
Next steps
After you have selected the types of rules to create, record your findings as explained in Document your
AppLocker rules.
After recording your findings for the AppLocker rules to create, you will need to consider how to enforce the
rules. For info about how to do this, see Determine Group Policy structure and rule enforcement.
Document your AppLocker rules
Applies to
Windows 10
Windows Server
This topic describes what AppLocker rule conditions to associate with each file, how to associate these rule
conditions, the source of the rule, and whether the file should be included or excluded.

To complete this AppLocker planning document, you should first complete the following steps:
1. Determine your application control objectives
2. Create a list of apps deployed to each business group
3. Select the types of rules to create
Document the following items for each business group or organizational unit:
Whether your organization will use the built-in default AppLocker rules to allow system files to run.
The types of rule conditions that you will use to create rules, stated in order of preference.
The following table details sample data for documenting rule type and rule condition findings. In addition, you
should now consider whether to allow an app to run or deny permission for it to run. For info about these
settings, see Understanding AppLocker allow and deny actions on rules.
USE DEFA ULT

RUL E O R
DEF IN E N EW
B USIN ESS O RGA N IZ AT I IM P L EM EN T A P P L IC AT IO N IN STA L L AT IO RUL E A L LO W O R
GRO UP O N A L UN IT A P P LO C K ER? S N PAT H C O N DIT IO N DEN Y
Bank Teller-East Yes Teller C:\Progra File is

Tellers and Teller- Software m signed;
West Files\Woo create a
dgrove\Te publisher
ller.exe condition
Windows C:\Windo Create a

files ws path
exception
to the
default
rule to
exclude
\Windows
\Temp
USE DEFA ULT
RUL E O R
DEF IN E N EW
B USIN ESS O RGA N IZ AT I IM P L EM EN T A P P L IC AT IO N IN STA L L AT IO RUL E A L LO W O R
GRO UP O N A L UN IT A P P LO C K ER? S N PAT H C O N DIT IO N DEN Y
Human HR-All Yes Check C:\Progra File is

Resources Payout m signed;
Files\Woo create a
dgrove\H publisher
R\Checkc condition
ut.exe
Time C:\Progra File is not

Sheet m signed;
Organizer Files\Woo create a
dgrove\H file hash
R\Timesh condition
eet.exe
Internet C:\Progra File is

Explorer 7 m signed;
Files\Inter create a
net publisher
Explorer< condition
/p>
Windows C:\Windo Use the

files ws default
rule for
the
Windows
path
Next steps
For each rule, determine whether to use the allow or deny option, and then complete the following tasks:
Determine Group Policy structure and rule enforcement
Determine the Group Policy structure and rule
enforcement
Applies to
Windows 10
Windows Server
This overview topic describes the process to follow when you are planning to deploy AppLocker rules.
In this section
Understand AppLocker enforcement settings This topic describes the AppLocker enforcement settings for
rule collections.
Understand AppLocker rules and enforcement setting This topic for the IT professional describes how application
inheritance in Group Policy control policies configured in AppLocker are applied through
Group Policy.
Document the Group Policy structure and AppLocker rule This planning topic describes what you need to investigate,
enforcement determine, and record in your application control policies
plan when you use AppLocker.
When you are determining how many Group Policy Objects (GPOs) to create when you apply an AppLocker
policy in your organization, you should consider the following:
Whether you are creating new GPOs or using existing GPOs
Whether you are implementing Software Restriction Policies (SRP) policies and AppLocker policies in the
same GPO
GPO naming conventions
GPO size limits
Note: There is no default limit on the number of AppLocker rules that you can create. However, in Windows
Server 2008 R2, GPOs have a 2 MB size limit for performance. In subsequent versions, that limit is raised to
100 MB.
Applies to
Windows 10
Windows Server
This topic describes the AppLocker enforcement settings for rule collections.
Rule enforcement is applied only to a collection of rules, not to individual rules. AppLocker divides the rules into
four collections: executable files, Windows Installer files, scripts, and DLL files. For more info about rule
collections, see Understanding AppLocker rule collections. By default, if enforcement is not configured and rules
are present in a rule collection, those rules are enforced. The following table details the three AppLocker rule
enforcement settings in Group Policy for each rule collection.
EN F O RC EM EN T SET T IN G DESC RIP T IO N
Not configured By default, enforcement is not configured in a rule collection.

If rules are present in the corresponding rule collection, they
are enforced. If rule enforcement is configured in a higher-
level linked Group Policy object (GPO), that enforcement
value overrides the Not configured value.
Enforce rules Rules are enforced for the rule collection, and all rule events
are audited.
Audit only Rule events are audited only. Use this value when planning
and testing AppLocker rules.
For the AppLocker policy to be enforced on a device, the Application Identity service must be running. For more
info about the Application Identity service, see Configure the Application Identity service.
When AppLocker policies from various GPOs are merged, the enforcement modes are merged by using the
standard Group Policy order of inheritance, which is local, domain, site, and organizational unit (OU). The Group
Policy setting that was last written or applied by order of inheritance is used for the enforcement mode, and all
rules from linked GPOs are applied.
Understand AppLocker rules and enforcement
setting inheritance in Group Policy
Applies to
Windows 10
Windows Server
This topic for the IT professional describes how application control policies configured in AppLocker are applied
through Group Policy.
Rule enforcement is applied only to collections of rules, not individual rules. AppLocker divides the rules into the
following collections: executable files, Windows Installer files, scripts, packaged apps and packaged app
installers, and DLL files. The options for rule enforcement are Not configured , Enforce rules , or Audit only .
Together, all AppLocker rule collections compose the application control policy, or AppLocker policy.
Group Policy merges AppLocker policy in two ways:
Rules. Group Policy does not overwrite or replace rules that are already present in a linked Group Policy
Object (GPO). For example, if the current GPO has 12 rules and a linked GPO has 50 rules, 62 rules are
applied to all computers that receive the AppLocker policy.
IMPORTANT
When determining whether a file is permitted to run, AppLocker processes rules in the following order:
1. Explicit deny. An administrator created a rule to deny a file.

2. Explicit allow. An administrator created a rule to allow a file.
3. Implicit deny. This is also called the default deny because all files that are not affected by an allow
rule are automatically blocked.
Enforcement settings. The last write to the policy is applied. For example, if a higher-level GPO has the
enforcement setting configured to Enforce rules and the closest GPO has the setting configured to
Audit only , Audit only is enforced. If enforcement is not configured on the closest GPO, the setting
from the closest linked GPO will be enforced. Because a computer's effective policy includes rules from
each linked GPO, duplicate rules or conflicting rules could be enforced on a user's computer. Therefore,
you should carefully plan your deployment to ensure that only rules that are necessary are present in a
GPO.
The following figure demonstrates how AppLocker rule enforcement is applied through linked GPOs.
In the preceding illustration, note that all GPOs linked to Contoso are applied in order as configured. The rules
that are not configured are also applied. For example, the result of the Contoso and Human Resources GPOs is
33 rules enforced, as shown in the client HR-Term1. The Human Resources GPO contains 10 non-configured
rules. When the rule collection is configured for Audit only , no rules are enforced.
When constructing the Group Policy architecture for applying AppLocker policies, it is important to remember:
Rule collections that are not configured will be enforced.
Group Policy does not overwrite or replace rules that are already present in a linked GPO.
AppLocker processes the explicit deny rule configuration before the allow rule configuration.
For rule enforcement, the last write to the GPO is applied.
Document the Group Policy structure and
AppLocker rule enforcement
Applies to
Windows 10
Windows Server
This planning topic describes what you need to investigate, determine, and record in your application control
policies plan when you use AppLocker.

4. Determine the Group Policy structure and rule enforcement
After you determine how to structure your Group Policy Objects (GPOs) so that you can apply AppLocker
policies, you should record your findings. You can use the following table to determine how many GPOs to
create (or edit) and which objects they are linked to. If you decided to create custom rules to allow system files
to run, note the high-level rule configuration in the Use default rule or define new rule condition column.
The following table includes the sample data that was collected when you determined your enforcement
settings and the GPO structure for your AppLocker policies.
USE
DEFA ULT
RUL E O R
IM P L EM EN DEF IN E
O RGA N IZ A T N EW RUL E
B USIN ESS T IO N A L A P P LO C K E IN STA L L AT I C O N DIT IO A L LO W O R
GRO UP UN IT R? APPS O N PAT H N DEN Y GP O N A M E
Bank Teller- Yes Teller C:\Prog File is Allow Tellers-

Tellers East Softwar ram signed; AppLoc
and e Files\W create kerTelle
Teller- oodgro a rRules
West ve\Telle publish
r.exe er
conditi
on
USE
DEFA ULT
RUL E O R
IM P L EM EN DEF IN E
O RGA N IZ A T N EW RUL E
B USIN ESS T IO N A L A P P LO C K E IN STA L L AT I C O N DIT IO A L LO W O R
GRO UP UN IT R? APPS O N PAT H N DEN Y GP O N A M E
Windo C:\Win Create Allow

ws files dows a path
excepti
on to
the
default
rule to
exclude
\Windo
ws\Tem
p
Human HR-All Yes Check C:\Prog File is Allow HR-

Resourc Payout ram signed; AppLoc
es Files\W create kerHRR
oodgro a ules
ve\HR\ publish
Checkc er
ut.exe conditi
on
Time C:\Prog File is Allow

Sheet ram not
Organi Files\W signed;
zer oodgro create
ve\HR\ a file
Timesh hash
eet.exe conditi
on
Interne C:\Prog File is Deny

t ram signed;
Explore Files\In create
r7 ternet a
Explore publish
r</p> er
conditi
on
Windo C:\Win Use a Allow

ws files dows default
rule for
the
Windo
ws
path
## Next steps
After you have determined the Group Policy structure and rule enforcement strategy for each business group's
apps, the following tasks remain:
Applies to
Windows 10
Windows Server
This topic for describes the decisions you need to make to establish the processes for managing and
maintaining AppLocker policies.
Policy management
Before you begin the deployment process, consider how the AppLocker rules will be managed. Developing a
process for managing AppLocker rules helps assure that AppLocker continues to effectively control how
applications are allowed to run in your organization.
Application and user support policy
Developing a process for managing AppLocker rules helps assure that AppLocker continues to effectively
control how applications are allowed to run in your organization. Considerations include:
What type of end-user support is provided for blocked applications?
How are new rules added to the policy?
How are existing rules updated?
Are events forwarded for review?
Help desk suppor t
If your organization has an established help desk support department in place, consider the following when
deploying AppLocker policies:
What documentation does your support department require for new policy deployments?
What are the critical processes in each business group both in work flow and timing that will be affected by
application control policies and how could they affect your support department's workload?
Who are the contacts in the support department?
How will the support department resolve application control issues between the end user and those who
maintain the AppLocker rules?
End-user suppor t
Because AppLocker is preventing unapproved apps from running, it is important that your organization
carefully plan how to provide end-user support. Considerations include:
Do you want to use an intranet site as a first line of support for users who have tried to run a blocked app?
How do you want to support exceptions to the policy? Will you allow users to run a script to temporarily
allow access to a blocked app?
Using an intranet site
AppLocker can be configured to display the default message but with a custom URL. You can use this URL to
redirect users to a support site that contains information about why the user received the error and which
applications are allowed. If you do not display a custom URL for the message when an app is blocked, the
default URL is used.
The following image shows an example of the error message for a blocked app. You can use the Set a suppor t
web link policy setting to customize the More information link.
For steps to display a custom URL for the message, see Display a custom URL message when users try to run a
blocked app.
AppLocker event management
Each time that a process requests permission to run, AppLocker creates an event in the AppLocker event log. The
event details which file tried to run, the attributes of that file, the user that initiated the request, and the rule
GUID that was used to make the AppLocker execution decision. The AppLocker event log is located in the
following path: Applications and Ser vices Logs\Microsoft\Windows\AppLocker . The AppLocker log
includes three logs:
1. EXE and DLL . Contains events for all files affected by the executable and DLL rule collections (.exe, .com, .dll,
and .ocx).
2. MSI and Script . Contains events for all files affected by the Windows Installer and script rule collections
(.msi, .msp, .ps1, .bat, .cmd, .vbs, and .js).
3. Packaged app-Deployment or Packaged app-Execution , contains events for all Universal Windows
apps affected by the packaged app and packed app installer rule collection (.appx).
Collecting these events in a central location can help you maintain your AppLocker policy and troubleshoot rule
configuration problems. Event collection technologies such as those available in Windows allow administrators
to subscribe to specific event channels and have the events from source computers aggregated into a forwarded
event log on a Windows Server operating system collector. For more info about setting up an event
subscription, see Configure Computers to Collect and Forward Events.
Policy maintenance
As new apps are deployed or existing apps are updated by the software publisher, you will need to make
revisions to your rule collections to ensure that the policy is current.
for the policy by importing additional rules. To ensure version control when modifying an AppLocker policy, use
Group Policy management software that allows you to create versions of Group Policy Objects (GPOs). An
example of this type of software is the Advanced Group Policy Management feature from the Microsoft Desktop
Optimization Pack. For more info about Advanced Group Policy Management, see Advanced Group Policy
Management Overview (https://go.microsoft.com/fwlink/p/?LinkId=145013).
New version of a suppor ted app

When a new version of an app is deployed in the organization, you need to determine whether to continue to
support the previous version of that app. To add the new version, you might only need to create a new rule for
each file that is associated with the app. If you are using publisher conditions and the version is not specified,
then the existing rule or rules might be sufficient to allow the updated file to run. You must ensure, however, that
the updated app has not altered the file names or added files to support new functionality. If so, then you must
modify the existing rules or create new rules. To continue to reuse a publisher-based rule without a specific file
version, you must also ensure that the file's digital signature is still identical to the previous version—the
publisher, product name, and file name (if configured in your rule) must all match for the rule to be correctly
applied.
To determine whether a file has been modified during an app update, review the publisher's release details
provided with the update package. You can also review the publisher's web page to retrieve this information.
Each file can also be inspected to determine the version.
For files that are allowed or denied with file hash conditions, you must retrieve the new file hash. To add support
for a new version and maintain support for the older version, you can either create a new file hash rule for the
new version or edit the existing rule and add the new file hash to the list of conditions.
For files with path conditions, you should verify that the installation path has not changed from what is stated in
the rule. If the path has changed, you need to update the rule before installing the new version of the app
Recently deployed app
To support a new app, you must add one or more rules to the existing AppLocker policy.
App is no longer suppor ted
If your organization has determined that it will no longer support an application that has AppLocker rules
associated with it, the easiest way to prevent users from running the app is to delete these rules.
App is blocked but should be allowed
A file could be blocked for three reasons:
The most common reason is that no rule exists to allow the app to run.
There may be an existing rule that was created for the file that is too restrictive.
A deny rule, which cannot be overridden, is explicitly blocking the file.
Before editing the rule collection, first determine what rule is preventing the file from running. You can
troubleshoot the problem by using the Test-AppLockerPolicy Windows PowerShell cmdlet. For more info
about troubleshooting an AppLocker policy, see Testing and Updating an AppLocker Policy
(https://go.microsoft.com/fwlink/p/?LinkId=160269).

5. Plan for AppLocker policy management
The three key areas to determine for AppLocker policy management are:
1. Support policy
Document the process that you will use for handling calls from users who have attempted to run a
blocked app, and ensure that support personnel know recommended troubleshooting steps and
escalation points for your policy.
2. Event processing
Document whether events will be collected in a central location, how that store will be archived, and
whether the events will be processed for analysis.
3. Policy maintenance
Detail how rules will be added to the policy, in which Group Policy Object (GPO) the rules should be
defined, and how to modify rules when apps are retired, updated, or added.
The following table contains the added sample data that was collected when determining how to maintain and
manage AppLocker policies.
USE
DEFA ULT
RUL E O R
DEF IN E
IM P L EM E N EW
O RGA N IZ NT IN STA L L A RUL E
B USIN ESS AT IO N A L A P P LO C K T IO N C O N DIT I A L LO W GP O SUP P O RT
GRO UP UN IT ER? APPS PAT H ON O R DEN Y NAME P O L IC Y
Bank Teller- Yes Teller C:\Pr File is Allow Tellers Web

Tellers East Softw ogra signe - help
and are m d; AppL
Teller- Files\ creat ocker
West Woo ea Teller
dgrov publis Rules
e\Tell her
er.exe condi
tion
Wind C:\Wi Creat Allow Help

ows ndow ea desk
files s path
excep
tion
to
the
defau
lt rule
to
exclu
de
\Win
dows
\Tem
p
USE
DEFA ULT
RUL E O R
DEF IN E
IM P L EM E N EW
Hum HR- Yes Chec C:\Pr File is Allow HR- Web

an All k ogra signe AppL help
Resou Payo m d; ocker
rces ut Files\ creat HRRu
Woo ea les
dgrov publis
e\HR\ her
Chec condi
kcut.e tion
xe
Time C:\Pr File is Allow Web

Sheet ogra not help
Orga m signe
nizer Files\ d;
Woo creat
dgrov ea
e\HR\ file
Times hash
heet. condi
exe tion
Inter C:\Pr File is Deny Web

net ogra signe help
Explo m d;
rer 7 Files\I creat
ntern ea
et publis
Explo her
rer</ condi
p> tion
Wind C:\Wi Use Allow Help

ows ndow the desk
files s defau
lt rule
for
the
Wind
ows
path
The following two tables illustrate examples of documenting considerations to maintain and manage AppLocker
policies.
Event processing policy
One discovery method for app usage is to set the AppLocker enforcement mode to Audit only . This will write
events to the AppLocker logs, which can be managed and analyzed like other Windows logs. After apps have
been identified, you can begin to develop policies regarding the processing and access to AppLocker events.
The following table is an example of what to consider and record.
A P P LO C K ER EVEN T
C O L L EC T IO N
B USIN ESS GRO UP LO C AT IO N A RC H IVA L P O L IC Y A N A LY Z ED? SEC URIT Y P O L IC Y
Bank Tellers Forwarded to: Standard None Standard

AppLocker Event
Repository on
srvBT093
Human DO NOT 60 months Yes, summary Standard

Resources FORWARD. reports monthly
srvHR004 to managers
Policy maintenance policy When applications are identified and policies are created for application control, then
you can begin documenting how you intend to update those policies. The following table is an example of what to
consider and record.
A P P L IC AT IO N A P P L IC AT IO N
RUL E UP DAT E DEC O M M ISSIO N A P P L IC AT IO N DEP LO Y M EN T
B USIN ESS GRO UP P O L IC Y P O L IC Y VERSIO N P O L IC Y P O L IC Y
Bank Tellers Planned: Through General policy: Coordinated

Monthly through business office Keep past through business
business office triage versions for 12 office
triage months
30-day notice 30-day notice
Emergency: required List policies for required
Request through each application
help desk
Human Planned: Through HR General policy: Coordinated

Resources Monthly through triage Keep past through HR
HR triage versions for 60
30-day notice months 30-day notice
Emergency: required required
Request through List policies for
help desk each application
Applies to
Windows 10
Windows Server
This topic for IT professionals introduces the concepts and describes the steps required to deploy AppLocker
policies.
This guide provides steps based on your design and planning investigation for deploying application control
policies by using AppLocker. It is intended for security architects, security administrators, and system
administrators. Through a sequential and iterative deployment process, you can create application control
policies, test and adjust the policies, and implement a method for maintaining those policies as the needs in
your organization change.
This guide covers the use of Software Restriction Policies (SRP) in conjunction with AppLocker policies to control
application usage. For a comparison of SRP and AppLocker, see Using Software Restriction Policies and
AppLocker policies in this guide. To understand if AppLocker is the correct application control solution for you,
see Understand AppLocker policy design decisions.
Prerequisites to deploying AppLocker policies

The following are prerequisites or recommendations to deploying policies:
Understand the capabilities of AppLocker:
AppLocker
Document your application control policy deployment plan by addressing these tasks:
Understand the AppLocker policy deployment process
Create list of apps deployed to each business group
Select types of rules to create
Determine Group Policy Structure and rule enforcement
Contents of this guide

This guide provides steps based on your design and planning investigation for deploying application control
policies created and maintained by AppLocker for computers running any of the supported versions of
Windows listed in Requirements to use AppLocker.
In this section
Understand the AppLocker policy deployment process This planning and deployment topic for the IT professional
describes the process for using AppLocker when deploying
application control policies.
Requirements for Deploying AppLocker Policies This deployment topic for the IT professional lists the
requirements that you need to consider before you deploy
AppLocker policies.
Use Software Restriction Policies and AppLocker policies This topic for the IT professional describes how to use
Software Restriction Policies (SRP) and AppLocker policies in
the same Windows deployment.
Create Your AppLocker policies This overview topic for the IT professional describes the
steps to create an AppLocker policy and prepare it for
deployment.
Deploy the AppLocker policy into production This topic for the IT professional describes the tasks that
should be completed before you deploy AppLocker
application control settings.
Understand the AppLocker policy deployment
process
Applies to
Windows 10
Windows Server
This planning and deployment topic for the IT professional describes the process for using AppLocker when
deploying application control policies.
To successfully deploy AppLocker policies, you need to identify your application control objectives and construct
the policies for those objectives. The key to the process is taking an accurate inventory of your organization's
applications, which requires investigation of all the targeted business groups. With an accurate inventory, you
can create rules and set enforcement criteria that will allow the organization to use the required applications and
allow the IT department to manage a controlled set of applications.
The following diagram shows the main points in the design, planning, and deployment process for AppLocker.
Resources to support the deployment process
The following topics contain information about designing, planning, deploying, and maintaining AppLocker
policies:
For info about the AppLocker policy design and planning requirements and process, see AppLocker Design
Guide.
For info about the AppLocker policy deployment requirements and process, see AppLocker deployment
guide.
For info about AppLocker policy maintenance and monitoring, see Administer AppLocker.
For info about AppLocker policy architecture, components, and processing, see AppLocker technical
reference.
Requirements for deploying AppLocker policies
Applies to
Windows 10
Windows Server
This deployment topic for the IT professional lists the requirements that you need to consider before you deploy
AppLocker policies.
The following requirements must be met or addressed before you deploy your AppLocker policies:
Deployment plan
Supported operating systems
Policy distribution mechanism
Event collection and analysis system
Deployment plan
An AppLocker policy deployment plan is the result of investigating which applications are required and
necessary in your organization, which apps are optional, and which apps are forbidden. To develop this plan, see
AppLocker Design Guide. The following table is an example of the data you need to collect and the decisions you
need to make to successfully deploy AppLocker policies on the supported operating systems (as listed in
Requirements to use AppLocker).
USE
DEFA ULT
RUL E O R
DEF IN E
IM P L EM E N EW
Bank Teller- Yes Teller C:\Pr File is Allow Tellers Web

Tellers East softw ogra signe help
and are m d;
Teller- Files\ creat
West Woo ea
dgrov publis
e\Tell her
er.exe condi
tion
USE
DEFA ULT
RUL E O R
DEF IN E
IM P L EM E N EW
Wind C:\Wi Creat Allow Help

ows ndow ea Desk
files s path
excep
tion
to
the
defau
lt rule
to
exclu
de
\Win
dows
\Tem
p
Time C:\Pr File is Allow Web

Sheet ogra not help
Orga m signe
nizer Files\ d;
Woo creat
dgrov ea
e\HR\ file
Times hash
heet. condi
exe tion
Hum HR- Yes Chec C:\Pr File is Allow HR Web

an All k ogra signe help
Resou Payo m d;
rces ut Files\ creat
Woo ea
dgrov publis
e\HR\ her
Chec condi
kcut.e tion
xe
Inter C:\Pr File is Deny Help

net ogra signe Desk
Explo m d;
rer 7 Files\I creat
ntern ea
et publis
Explo her
rer</ condi
p> tion
USE
DEFA ULT
RUL E O R
DEF IN E
IM P L EM E N EW
Wind C:\Wi Use Allow Help

ows ndow the Desk
files s defau
lt rule
for
the
Wind
ows
path
Event processing policy
A P P LO C K ER EVEN T
C O L L EC T IO N
B USIN ESS GRO UP LO C AT IO N A RC H IVA L P O L IC Y A N A LY Z ED? SEC URIT Y P O L IC Y
Bank Tellers Forwarded to: Standard None Standard

srvBT093
Human Do not forward 60 months Yes; summary Standard

Resources reports monthly
to managers
Policy maintenance policy
RUL E UP DAT E A P P DEC O M M ISSIO N A P P VERSIO N A P P DEP LO Y M EN T

B USIN ESS GRO UP P O L IC Y P O L IC Y P O L IC Y P O L IC Y
Bank Tellers Planned: Through General policy: Coordinated

Monthly through business office Keep past through business
business office triage; 30-day versions for 12 office; 30-day
triage notice required months notice required
Emergency: List policies for
Request through each application
Help Desk
Human Planned: Through HR General policy: Coordinated

Resources Through HR triage; 30-day Keep past through HR; 30-
triage notice required versions for 60 day notice
months required
Emergency:
Request through List policies for
Help Desk each application
### Supported operating systems

AppLocker is supported only on certain operating systems. Some features are not available on all operating
systems. For more information, see Requirements to use AppLocker.
Policy distribution mechanism
You need a way to distribute the AppLocker policies throughout the targeted business groups. AppLocker uses
Group Policy management architecture to effectively distribute application control policies. AppLocker policies
can also be configured on individual computers by using the Local Security Policy snap-in.
Event collection and analysis system
Event processing is important to understand application usage. You must have a process in place to collect and
analyze AppLocker events so that application usage is appropriately restricted and understood. For procedures
to monitor AppLocker events, see:
See also
Use Software Restriction Policies and AppLocker
policies
Applies to
Windows 10
Windows Server
This topic for the IT professional describes how to use Software Restriction Policies (SRP) and AppLocker policies
in the same Windows deployment.
Understand the difference between SRP and AppLocker

You might want to deploy application control policies in Windows operating systems earlier than Windows
Server 2008 R2 or Windows 7. You can use AppLocker policies only on the supported versions and editions of
Windows as listed in Requirements to use AppLocker. However, you can use SRP on those supported editions of
Windows plus Windows Server 2003 and Windows XP. To compare features and functions in SRP and
AppLocker so that you can determine when to use each technology to meet your application control objectives,
see Determine your application control objectives.
Use SRP and AppLocker in the same domain

SRP and AppLocker use Group Policy for domain management. However, when policies are generated by SRP
and AppLocker exist in the same domain, and they are applied through Group Policy, AppLocker policies take
precedence over policies generated by SRP on computers that are running an operating system that supports
AppLocker. For info about how inheritance in Group Policy applies to AppLocker policies and policies generated
by SRP, see Understand AppLocker rules and enforcement setting inheritance in Group Policy.
Impor tant: As a best practice, use separate Group Policy Objects to implement your SRP and AppLocker
policies. To reduce troubleshooting issues, do not combine them in the same GPO.
The following scenario provides an example of how each type of policy would affect a bank teller software app,
where the app is deployed on different Windows desktop operating systems and managed by the Tellers GPO.
T EL L ERS GP O W IT H
T EL L ERS GP O W IT H A P P LO C K ER P O L IC Y A N D
O P ERAT IN G SY ST EM A P P LO C K ER P O L IC Y T EL L ERS GP O W IT H SRP SRP
Windows 10, Windows 8.1, AppLocker policies in the Local AppLocker policies AppLocker policies in the
Windows 8,and Windows 7 GPO are applied, and they supersede policies GPO are applied, and they
supersede any local generated by SRP that are supersede the policies
AppLocker policies. applied through the GPO. generated by SRP in the
GPO and local AppLocker
policies or policies
generated by SRP.
T EL L ERS GP O W IT H
T EL L ERS GP O W IT H A P P LO C K ER P O L IC Y A N D
O P ERAT IN G SY ST EM A P P LO C K ER P O L IC Y T EL L ERS GP O W IT H SRP SRP
Windows Vista AppLocker policies are not Policies generated by SRP in Policies generated by SRP in
applied. the GPO are applied, and the GPO are applied, and
they supersede local policies they supersede local policies
generated by generated by SRP.
SRP.AppLocker policies are AppLocker policies not
not applied. applied.
Windows XP AppLocker policies are not Policies generated by SRP in Policies generated by SRP in
applied. the GPO are applied, and the GPO are applied, and
they supersede local policies they supersede local policies
generated by SRP. generated by SRP.
AppLocker policies are not AppLocker policies not
applied. applied.
Note: For info about supported versions and editions of the Windows operating system, see Requirements
to use AppLocker.
Test and validate SRPs and AppLocker policies that are deployed in
the same environment
Because SRPs and AppLocker policies function differently, they should not be implemented in the same GPO.
This makes testing the result of the policy straightforward, which is critical to successfully controlling application
usage in the organization. Configuring a testing and policy distribution system can help you understand the
result of a policy. The effects of policies generated by SRP and AppLocker policies need to be tested separately
and by using different tools.
Step 1: Test the effect of SRPs
You can use the Group Policy Management Console (GPMC) or the Resultant Set of Policy (RSoP) snap-in to
determine the effect of applying SRPs by using GPOs.
Step 2: Test the effect of AppLocker policies
You can test AppLocker policies by using Windows PowerShell cmdlets. For info about investigating the result of
a policy, see:
Test an AppLocker policy by using Test-AppLockerPolicy
Another method to use when determining the result of a policy is to set the enforcement mode to Audit only .
When the policy is deployed, events will be written to the AppLocker logs as if the policy was enforced. For info
about using the Audit only mode, see:
See also
Applies to
Windows 10
Windows Server
This overview topic for the IT professional describes the steps to create an AppLocker policy and prepare it for
deployment.
Creating effective application control policies with AppLocker starts by creating the rules for each app. Rules are
grouped into one of five rule collections. The rule collection can be configured to be enforced or to run in Audit
only mode. An AppLocker policy includes the rules in the five rule collections and the enforcement settings for
each rule collection.
Step 1: Use your plan

You can develop an application control policy plan to guide you in making successful deployment decisions. For
more info about how to do this and what you should consider, see the AppLocker Design Guide. This guide is
intended for security architects, security administrators, and system administrators. It contains the following
topics to help you create an AppLocker policy deployment plan for your organization that will address your
specific application control requirements by department, organizational unit, or business group:
1. Understand the AppLocker policy deployment process
2. Understand AppLocker policy design decisions
7. Plan for AppLocker policy management
Step 2: Create your rules and rule collections

Each rule applies to one or more apps, and it imposes a specific rule condition on them. Rules can be created
individually or they can be generated by the Automatically Generate Rules Wizard. For the steps to create the
rules, see Create Your AppLocker rules.
Step 3: Configure the enforcement setting

An AppLocker policy is a set of rule collections that are configured with a rule enforcement setting. The
enforcement setting can be Enforce rules , Audit only , or Not configured . If an AppLocker policy has at least
one rule, and it is set to Not configured , all the rules in that policy will be enforced. For info about configuring
the rule enforcement setting, see Configure an AppLocker policy for audit only and Configure an AppLocker
policy for enforce rules.
Step 4: Update the GPO

AppLocker policies can be defined locally on a device or applied through Group Policy. To use Group Policy to
apply AppLocker policies, you must create a new Group Policy Object (GPO) or you must update an existing
GPO. You can create or modify AppLocker policies by using the Group Policy Management Console (GPMC), or
you can import an AppLocker policy into a GPO. For the procedure to do this, see Import an AppLocker policy
into a GPO.
Step 5: Test the effect of the policy

In a test environment or with the enforcement setting set at Audit only , verify that the results of the policy are
what you intended. For info about testing a policy, see Test and update an AppLocker policy.
Step 6: Implement the policy

Depending on your deployment method, import the AppLocker policy to the GPO in your production
environment, or if the policy is already deployed, change the enforcement setting to your production
environment value—Enforce rules or Audit only .
Step 7: Test the effect of the policy and adjust

Validate the effect of the policy by analyzing the AppLocker logs for application usage, and then modify the
policy as necessary. To do this, see Monitor app usage with AppLocker.
Next steps
Follow the steps described in the following topics to continue the deployment process:
1. Create Your AppLocker rules
2. Test and update an AppLocker policy
3. Deploy the AppLocker policy into production
See also
Create Your AppLocker rules
Applies to
Windows 10
Windows Server
This topic for the IT professional describes what you need to know about AppLocker rules and the methods that
you can to create rules.
Creating AppLocker rules

AppLocker rules apply to the targeted app, and they are the components that make up the AppLocker policy.
Depending on your IT environment and the business group that requires application control policies, setting
these access rules for each application can be time-consuming and prone to error. With AppLocker, you can
generate rules automatically or create rules individually. Creating rules that are derived from your planning
document can help you avoid unintended results. For info about this planning document and other planning
activities, see AppLocker Design Guide.
Automatically generate your rules
You can use a reference device to automatically create a set of default rules for each of the installed apps, test
and modify each rule as necessary, and deploy the policies. Creating most of the rules for all the installed apps
gives you a starting point to build and test your policies. For info about performing this task, see the following
topics:
Create your rules individually
You can create rules and set the mode to Audit only for each installed app, test and update each rule as
necessary, and then deploy the policies. Creating rules individually might be best when you are targeting a small
number of applications within a business group.
Note: AppLocker includes default rules for each rule collection. These rules are intended to help ensure that
the files that are required for Windows to operate properly are allowed in an AppLocker rule collection. You
can also edit the default rules. For information about creating the default rules for the Windows operating
system, see Create AppLocker default rules.
For information about performing this task, see:

1. Create a rule that uses a publisher condition
2. Create a rule that uses a path condition
3. Create a rule that uses a file hash condition
4. Edit AppLocker rules
5. Enforce AppLocker rules
6. Configure an AppLocker policy for audit only
About selecting rules

AppLocker policies are composed of distinct rules for specific apps. These rules are grouped by collection, and
they are implemented through an AppLocker policy definition. AppLocker policies are managed by using Group
Policy or by using the Local Security Policy snap-in for a single computer.
When you determine what types of rules to create for each of your business groups or organizational units
(OUs), you should also determine what enforcement setting to use for each group. Certain rule types are more
applicable for some apps, depending on how the apps are deployed in a specific business group.
For info about how to determine and document your AppLocker rules, see AppLocker Design Guide.
For info about AppLocker rules and AppLocker policies, see the following topics:
Next steps
1. Import an AppLocker policy into a GPO
2. Import an AppLocker policy from another computer
3. Test and update an AppLocker policy
4. Deploy the AppLocker policy into production
Related topics
Applies to
Windows 10
Windows Server
This topic for the IT professional describes the tasks that should be completed before you deploy AppLocker
application control settings.
After successfully testing and modifying the AppLocker policy for each Group Policy Object (GPO), you are ready
to deploy the enforcement settings into production. For most organizations, this means switching the AppLocker
enforcement setting from Audit only to Enforce rules . However, it is important to follow the deployment plan
that you created earlier. For more info, see the AppLocker Design Guide. Depending on the needs of different
business groups in your organization, you might deploy different enforcement settings for linked GPOs.
Understand your design decisions
Before you deploy an AppLocker policy, you should determine:
For each business group, which applications will be controlled and in what manner. For more info, see Create
a list of apps deployed to each business group.
How to handle requests for application access. For info about what to consider when developing your
support policies, see Plan for AppLocker policy management.
How to manage events, including forwarding events. For info about event management in AppLocker, see
Monitor app usage with AppLocker.
Your GPO structure, including how to include policies generated by Software Restriction Policies and
AppLocker policies. For more info, see Determine the Group Policy structure and rule enforcement.
For info about how AppLocker deployment is dependent on design decisions, see Understand AppLocker policy
design decisions.
AppLocker deployment methods
If you have configured a reference device, you can create and update your AppLocker policies on this device, test
the policies, and then export the policies to the appropriate GPO for distribution. Another method is to create
the policies and set the enforcement setting on Audit only , then observe the events that are generated.
This topic describes the steps to use an AppLocker reference computer to prepare application control
policies for deployment by using Group Policy or other means.
Deploy AppLocker policies by using the enforce rules setting
This topic describes the steps to deploy the AppLocker policy by changing the enforcement setting to
Audit only or to Enforce rules .
See also
Use a reference device to create and maintain
AppLocker policies
Applies to
Windows 10
Windows Server
This topic for the IT professional describes the steps to create and maintain AppLocker policies by using a
reference computer.
Background and prerequisites

An AppLocker reference device is a baseline device you can use to configure policies and can subsequently be
used to maintain AppLocker policies. For the procedure to configure a reference device, see Configure the
AppLocker reference device.
An AppLocker reference device that is used to create and maintain AppLocker policies should contain the
corresponding apps for each organizational unit (OU) to mimic your production environment.
Impor tant: The reference device must be running one of the supported editions of Windows. For
information about operating system requirements for AppLocker, see Requirements to use AppLocker.
You can perform AppLocker policy testing on the reference device by using the Audit only enforcement setting
or Windows PowerShell cmdlets. You can also use the reference device as part of a testing configuration that
includes policies that are created by using Software Restriction Policies.
Step 1: Automatically generate rules on the reference device

With AppLocker, you can automatically generate rules for all files within a folder. AppLocker scans the specified
folder and creates the condition types that you choose for each file in that folder. For the procedure to do this,
see Run the Automatically Generate Rules wizard.
Note: If you run this wizard to create your first rules for a Group Policy Object (GPO), after you complete
the wizard, you will be prompted to create the default rules, which allow critical system files to run. You can
edit the default rules at any time. If your organization has decided to edit the default rules or create custom
rules to allow the Windows system files to run, ensure that you delete the default rules after you replace
them with your custom rules.
Step 2: Create the default rules on the reference device

that are required for Windows to operate properly are allowed in an AppLocker rule collection. You must run the
default rules for each rule collection. For info about default rules and considerations for using them, see
Understanding AppLocker default rules. For the procedure to create default rules, see Create AppLocker default
rules.
Impor tant: You can use the default rules as a template when you create your own rules. This allows files
within the Windows directory to run. However, these rules are only meant to function as a starter policy
when you are first testing AppLocker rules.
Step 3: Modify rules and the rule collection on the reference device
If AppLocker policies are currently running in your production environment, export the policies from the
corresponding GPOs and save them to the reference device. For the procedure to do this, see Export an
AppLocker policy from a GPO. If no AppLocker policies have been deployed, create the rules and develop the
policies by using the following procedures:
Step 4: Test and update AppLocker policy on the reference device

You should test each set of rules to ensure that they perform as intended. The Test-AppLockerPolicy Windows
PowerShell cmdlet can be used to determine whether any of the rules in your rule collection will be blocked on
your reference device. Perform the steps on each reference device that you used to define the AppLocker policy.
Ensure that the reference device is joined to the domain and that it is receiving the AppLocker policy from the
appropriate GPO. Because AppLocker rules are inherited from linked GPOs, you should deploy all of the rules to
simultaneously test all of your test GPOs. Use the following procedures to complete this step:
Test an AppLocker Policy with Test-AppLockerPolicy
Discover the Effect of an AppLocker Policy
Caution: If you have set the enforcement setting on the rule collection to Enforce rules or you have not
configured the rule collection, the policy will be implemented when the GPO is updated in the next step. If
you have set the enforcement setting on the rule collection to Audit only , application access events are
written to the AppLocker log, and the policy will not take effect.
Step 5: Export and import the policy into production

When the AppLocker policy has been tested successfully, it can be imported into the GPO (or imported into
individual computers that are not managed by Group Policy) and checked for its intended effectiveness. To do
this, perform the following procedures:
Import an AppLocker policy into a GPO or
Discover the Effect of an AppLocker Policy
If the AppLocker policy enforcement setting is Audit only and you are satisfied that the policy is fulfilling your
intent, you can change it to Enforce rules . For info about how to change the enforcement setting, see
Configure an AppLocker policy for enforce rules.
Step 6: Monitor the effect of the policy in production

If additional refinements or updates are necessary after a policy is deployed, use the appropriate following
procedures to monitor and update the policy:
See also
Determine which apps are digitally signed on a
reference device
Applies to
Windows 10
Windows Server
This topic for the IT professional describes how to use AppLocker logs and tools to determine which applications
are digitally signed.
The Windows PowerShell cmdlet Get-AppLockerFileInformation can be used to determine which apps
installed on your reference devices are digitally signed. Perform the following steps on each reference computer
that you used to define the AppLocker policy. The device does not need to be joined to the domain.
procedure.
To determine which apps are digitally signed on a reference device
1. Run Get-AppLockerFileInformation with the appropriate parameters.
The Get-AppLockerFileInformation cmdlet retrieves the AppLocker file information from a list of files
or from an event log. File information that is retrieved can include publisher information, file hash
information, and file path information. File information from an event log may not contain all of these
fields. Files that are not signed do not have any publisher information.
2. Analyze the publisher's name and digital signature status from the output of the command.
For command parameters, syntax, and examples, see Get-AppLockerFileInformation.
Related topics
Applies to
Windows 10
Windows Server
This topic for the IT professional describes the steps to create an AppLocker policy platform structure on a
reference computer.
An AppLocker reference device that is used for the development and deployment of AppLocker policies should
mimic the directory structure and corresponding applications in the organizational unit (OU) or business group
for the production environment. On a reference device, you can:
Maintain an application list for each business group.
Develop AppLocker policies by creating individual rules or by creating a policy by automatically generating
rules.
Create the default rules to allow the Windows system files to run properly.
Run tests and analyze the event logs to determine the affect of the policies that you intend to deploy.
The reference device does not need to be joined to a domain, but it must be able to import and export
AppLocker policies in XML format. The reference computer must be running one of the supported editions of
Windows as listed in Requirements to use AppLocker.
Warning: Do not use operating system snapshots when creating AppLocker rules. If you take a snapshot of
the operating system, install an app, create AppLocker rules, and then revert to a clean snapshot and repeat
the process for another app, there is a chance that duplicate rule GUIDs can be created. If duplicate GUIDs
are present, AppLocker policies will not work as expected.
To configure a reference device

1. If the operating system is not already installed, install one of the supported editions of Windows on the
device.
Note: If you have the Group Policy Management Console (GPMC) installed on another device to test
your implementation of AppLocker policies, you can export the policies to that device
2. Configure the administrator account.

To update local policies, you must be a member of the local Administrators group. To update domain
policies, you must be a member of the Domain Admins group or have been delegated privileges to use
Group Policy to update a Group Policy Object (GPO).
3. Install all apps that run in the targeted business group or OU by using the same directory structure.
The reference device should be configured to mimic the structure of your production environment. It
depends on having the same apps in the same directories to accurately create the rules.
See also
After you configure the reference computer, you can create the AppLocker rule collections. You can build,
import, or automatically generate the rules. For procedures to do this, see Working with AppLocker rules.
Applies to
Windows 10
Windows Server
This overview topic for IT professionals provides links to the topics in the technical reference. AppLocker
advances the application control features and functionality of Software Restriction Policies. AppLocker contains
new capabilities and extensions that allow you to create rules to allow or deny apps from running based on
unique identities of files and to specify which users or groups can run those apps.
In this section
What Is AppLocker? This topic for the IT professional describes what AppLocker is
and how its features differ from Software Restriction Policies.
Requirements to use AppLocker This topic for the IT professional lists software requirements
to use AppLocker on the supported Windows operating
systems.
AppLocker policy use scenarios This topic for the IT professional lists the various application
control scenarios in which AppLocker policies can be
effectively implemented.
How AppLocker works This topic for the IT professional provides links to topics
about AppLocker architecture and components, processes
and interactions, rules and policies.
AppLocker architecture and components This topic for IT professional describes AppLocker’s basic
architecture and its major components.
AppLocker processes and interactions This topic for the IT professional describes the process
dependencies and interactions when AppLocker evaluates
and enforces rules.
AppLocker functions This topic for the IT professional lists the functions and
security levels for the Software Restriction Policies (SRP) and
AppLocker features.
Security considerations for AppLocker This topic for the IT professional describes the security
considerations you need to address when implementing
AppLocker.
Tools to Use with AppLocker This topic for the IT professional describes the tools available
to create and administer AppLocker policies.
AppLocker Settings This topic for the IT professional lists the settings used by
AppLocker.
What Is AppLocker?
Applies to
Windows 10
Windows Server
This topic for the IT professional describes what AppLocker is and how its features differ from Software
Restriction Policies.
AppLocker advances the app control features and functionality of Software Restriction Policies. AppLocker
contains new capabilities and extensions that allow you to create rules to allow or deny apps from running
based on unique identities of files and to specify which users or groups can run those apps.
Using AppLocker, you can:
Control the following types of apps: executable files (.exe and .com), scripts (.js, .ps1, .vbs, .cmd, and .bat),
Windows Installer files (.mst, .msi and .msp), and DLL files (.dll and .ocx), and packaged apps and packaged
app installers (appx).
Define rules based on file attributes derived from the digital signature, including the publisher, product name,
file name, and file version. For example, you can create rules based on the publisher attribute that is
persistent through updates, or you can create rules for a specific version of a file.
Create exceptions to rules. For example, you can create a rule that allows all Windows processes to run
except Registry Editor (Regedit.exe).
Import and export rules. The import and export affects the entire policy. For example, if you export a policy,
all of the rules from all of the rule collections are exported, including the enforcement settings for the rule
collections. If you import a policy, all criteria in the existing policy are overwritten.
Streamline creating and managing AppLocker rules by using Windows PowerShell cmdlets.
AppLocker helps reduce administrative overhead and helps reduce the organization's cost of managing
computing resources by decreasing the number of help desk calls that result from users running unapproved
apps
For information about the application control scenarios that AppLocker addresses, see AppLocker policy use
scenarios.
What features are different between Software Restriction Policies and

AppLocker?
Feature differences
The following table compares AppLocker to Software Restriction Policies.
F EAT URE SO F T WA RE REST RIC T IO N P O L IC IES A P P LO C K ER
Rule scope All users Specific user or group

F EAT URE SO F T WA RE REST RIC T IO N P O L IC IES A P P LO C K ER
Rule conditions provided File hash, path, certificate, registry File hash, path, and publisher
path, and Internet zone
Rule types provided Defined by the security levels: Allow and deny
Disallowed
Basic User
Unrestricted
Default rule action Unrestricted Implicit deny
Audit-only mode No Yes
Wizard to create multiple rules at No Yes

one time
Policy import or export No Yes
Rule collection No Yes
Windows PowerShell support No Yes
Custom error messages No Yes
Application control function differences

The following table compares the application control functions of Software Restriction Policies (SRP) and
AppLocker.
Operating system scope SRP policies can be applied to all AppLocker policies apply only to
Windows operating systems those supported operating system
beginning with Windows XP and versions and editions listed in
Windows Server 2003. Requirements to use AppLocker.
But these systems can also use
SRP.
Note
Use different GPOs for SRP and
AppLocker rules.
User support SRP allows users to install AppLocker policies are maintained
applications as an administrator. through Group Policy, and only
the administrator of the device can
update an AppLocker policy.
Policy maintenance SRP policies are updated by using AppLocker policies are updated by
the Local Security Policy snap-in or using the Local Security Policy
the Group Policy Management snap-in or the GPMC.
Console (GPMC).
AppLocker supports a small set of
PowerShell cmdlets to aid in
administration and maintenance.
Policy management infrastructure To manage SRP policies, SRP uses To manage AppLocker policies,
Group Policy within a domain and AppLocker uses Group Policy
the Local Security Policy snap-in within a domain and the Local
for a local computer. Security Policy snap-in for a local
computer.
Block malicious scripts Rules for blocking malicious scripts AppLocker rules can control the
prevents all scripts associated with following file formats: .ps1, .bat,
the Windows Script Host from .cmd, .vbs, and .js. In addition, you
running, except those that are can set exceptions to allow specific
digitally signed by your files to run.
organization.
Manage software installation SRP can prevent all Windows The Windows Installer rule
Installer packages from installing. collection is a set of rules created
It allows .msi files that are digitally for Windows Installer file types
signed by your organization to be (.mst, .msi and .msp) to allow you
installed. to control the installation of files
on client computers and servers.
Manage all software on the All software is managed in one rule Unlike SRP, each AppLocker rule
computer set. By default, the policy for collection functions as an allowed
managing all software on a device list of files. Only the files that are
disallows all software on the user's listed within the rule collection will
device, except software that is be allowed to run. This
installed in the Windows folder, configuration makes it easier for
Program Files folder, or subfolders. administrators to determine what
will occur when an AppLocker rule
is applied.
Different policies for different users Rules are applied uniformly to all On a device that is shared by
users on a particular device. multiple users, an administrator
can specify the groups of users
who can access the installed
software. Using AppLocker, an
administrator can specify the user
to whom a specific rule should
apply.
Related topics
Requirements to use AppLocker
Applies to
Windows 10
Windows Server
This topic for the IT professional lists software requirements to use AppLocker on the supported Windows
operating systems.
General requirements
To use AppLocker, you need:
A device running a supported operating system to create the rules. The computer can be a domain controller.
For Group Policy deployment, at least one device with the Group Policy Management Console (GPMC) or
Remote Server Administration Tools (RSAT) installed to host the AppLocker rules.
Devices running a supported operating system to enforce the AppLocker rules that you create.
Note: You can use Software Restriction Policies with AppLocker, but with some limitations. For more info,
see Use AppLocker and Software Restriction Policies in the same domain.
Operating system requirements

The following table show the on which operating systems AppLocker features are supported.
C AN BE
VERSIO N C O N F IGURED C A N B E EN F O RC ED AVA IL A B L E RUL ES N OT ES
Windows 10 Yes Yes Packaged apps You can use the

Executable AppLocker CSP to
Windows Installer configure AppLocker
Script policies on any
DLL edition of
Windows 10
supported by Mobile
Device Management
(MDM). You can only
manage AppLocker
with Group Policy on
devices running
Windows 10
Enterprise, Windows
10 Education, and
Windows
Server 2016.
C AN BE
Windows Server Yes Yes Packaged apps

2019 Executable
Windows Windows Installer
Server 2016 Script
Windows Server DLL
2012 R2
Windows Server
2012
Windows 8.1 Pro Yes No N/A
Windows 8.1 Yes Yes Packaged apps

Enterprise Executable
Windows Installer
Script
DLL
Windows RT 8.1 No No N/A
Windows 8 Pro Yes No N/A
Windows 8 Yes Yes Packaged apps

Enterprise Executable
Windows Installer
Script
DLL
Windows RT No No N/A
Windows Yes Yes Executable Packaged app rules

Server 2008 R2 Windows Installer will not be enforced.
Standard Script
DLL

Enterprise Script
DLL

Datacenter Script
DLL

Server 2008 R2 for Windows Installer will not be enforced.
Itanium-Based Script
Systems DLL
Windows 7 Ultimate Yes Yes Executable Packaged app rules

Windows Installer will not be enforced.
Script
DLL
C AN BE
Windows 7 Yes Yes Executable Packaged app rules

Enterprise Windows Installer will not be enforced.
Script
DLL
Windows 7 Yes No Executable No AppLocker rules

Professional Windows Installer are enforced.
Script
DLL
AppLocker is not supported on versions of the Windows operating system not listed above. Software Restriction
Policies can be used with those versions. However, the SRP Basic User feature is not supported on the above
operating systems.
See also
Use AppLocker and Software Restriction Policies in the same domain
AppLocker Design Guide
AppLocker policy use scenarios
Applies to
Windows 10
Windows Server
This topic for the IT professional lists the various application control scenarios in which AppLocker policies can
be effectively implemented.
AppLocker can help you improve the management of application control and the maintenance of application
control policies. Application control scenarios addressed by AppLocker can be categorized as follows:
1. App inventor y
AppLocker has the ability to enforce its policy in an audit-only mode where all app access activity is
collected in event logs for further analysis. Windows PowerShell cmdlets are also available to help you
understand app usage and access.
2. Protection against unwanted software
AppLocker has the ability to deny apps from running simply by excluding them from the list of allowed
apps per business group or user. If an app is not specifically identified by its publisher, installation path, or
file hash, the attempt to run the application fails.
3. Licensing conformance
AppLocker can provide an inventory of software usage within your organization, so you can identify the
software that corresponds to your software licensing agreements and restrict application usage based on
licensing agreements.
4. Software standardization
AppLocker policies can be configured to allow only supported or approved apps to run on computers
within a business group. This permits a more uniform app deployment.
5. Manageability improvement
AppLocker policies can be modified and deployed through your existing Group Policy infrastructure and
can work in conjunction with policies created by using Software Restriction Policies. As you manage
ongoing change in your support of a business group's apps, you can modify policies and use the
AppLocker cmdlets to test the policies for the expected results. You can also design application control
policies for situations in which users share computers.
Use scenarios
The following are examples of scenarios in which AppLocker can be used:
Your organization implements a policy to standardize the applications used within each business group, so
you need to determine the expected usage compared to the actual usage.
The security policy for application usage has changed, and you need to evaluate where and when those
deployed apps are being accessed.
Your organization's security policy dictates the use of only licensed software, so you need to determine which
apps are not licensed or prevent unauthorized users from running licensed software.
An app is no longer supported by your organization, so you need to prevent it from being used by everyone.
Your organization needs to restrict the use of Universal Windows apps to just those your organization
approves of or develops.
The potential that unwanted software can be introduced in your environment is high, so you need to reduce
this threat.
The license to an app has been revoked or is expired in your organization, so you need to prevent it from
being used by everyone.
A new app or a new version of an app is deployed, and you need to allow certain groups to use it.
Specific software tools are not allowed within the organization, or only specific users have access to those
tools.
A single user or small group of users needs to use a specific app that is denied for all others.
Some computers in your organization are shared by people who have different software usage needs.
In addition to other measures, you need to control the access to sensitive data through app usage.
Related topics
How AppLocker works
Applies to
Windows 10
Windows Server
This topic for the IT professional provides links to topics about AppLocker architecture and components,
processes and interactions, rules and policies.
The following topics explain how AppLocker policies for each of the rule condition types are evaluated:
The following topics explain how AppLocker rules and policies work:
AppLocker Design Guide
Applies to
Windows 10
Windows Server
This topic describes how AppLocker rules are enforced by using the allow and deny options in AppLocker.
If no AppLocker rules for a specific rule collection exist, all files with that file format are allowed to run. However,
when an AppLocker rule for a specific rule collection is created, only the files explicitly allowed in a rule are
permitted to run. For example, if you create an executable rule that allows .exe files in %SystemDrive%\FilePath
to run, only executable files located in that path are allowed to run.
A rule can be configured to use either an allow or deny action:
Allow . You can specify which files are allowed to run in your environment and for which users or groups of
users. You can also configure exceptions to identify files that are excluded from the rule.
Deny . You can specify which files are not allowed to run in your environment and for which users or groups
of users. You can also configure exceptions to identify files that are excluded from the rule.
Impor tant: You can use a combination of allow actions and deny actions. However, we recommend using
allow actions with exceptions because deny actions override allow actions in all cases. Deny actions can also
be circumvented. For example, if you configure a deny action for a file or folder path, the user can still run
the file from any other path.
Related topics
How AppLocker works
Applies to
Windows 10
Windows Server
This topic describes the result of applying AppLocker rule exceptions to rule collections.
You can apply AppLocker rules to individual users or a group of users. If you apply a rule to a group of users, all
users in that group are affected by that rule. If you need to allow a subset of a user group to use an app, you can
create a special rule for that subset.
For example, the rule "Allow Everyone to run Windows except Registry Editor" allows Everyone to run Windows
binaries, but does not allow anyone to run Registry Editor (by adding %WINDIR%\regedit.exe as a Path
Exception of the rule).
The effect of this rule would prevent users such as Helpdesk personnel from running the Registry Editor, a
program that is necessary for their support tasks.
To resolve this problem, create a second rule that applies to the Helpdesk user group: "Allow Helpdesk to run
Registry Editor" and add %WINDIR%\regedit.exe as an allowed path. If you create a deny rule that does not
allow any users to run Registry Editor, the deny rule will override the second rule that allows the Helpdesk user
group to run Registry Editor.
Related topics
How AppLocker works
Applies to
Windows 10
Windows Server
This topic explains the five different types of AppLocker rules used to enforce AppLocker policies.
An AppLocker rule collection is a set of rules that apply to one of five types:
Executable files: .exe and .com
Windows Installer files: .msi, mst, and .msp
Scripts: .ps1, .bat, .cmd, .vbs, and .js
DLLs: .dll and .ocx
Packaged apps and packaged app installers: .appx
If you use DLL rules, a DLL allow rule has to be created for each DLL that is used by all of the allowed apps.
Impor tant: Each app can load several DLLs, and AppLocker must check each DLL before it is allowed to
run. Therefore, creating DLL rules might cause performance problems on some computers. Denying some
DLLs from running can also create app compatibility problems. As a result, the DLL rule collection is not
enabled by default.
For info about how to enable the DLL rule collection, see Enable the DLL rule collection.
Related topics
How AppLocker works
Understanding AppLocker allow and deny actions
on rules
Applies to
Windows 10
Windows Server
This topic explains the differences between allow and deny actions on AppLocker rules.
Allow action versus deny action on rules

Unlike Software Restriction Policies (SRP), each AppLocker rule collection functions as an allowed list of files.
Only the files that are listed within the rule collection are allowed to run. This block by default, allow by
exception configuration makes it easier to determine what will occur when an AppLocker rule is applied.
You can also create rules that use the deny action. When applying rules, AppLocker first checks whether any
explicit deny actions are specified in the rule list. If you have denied a file from running in a rule collection, the
deny action will take precedence over any allow action, regardless of which Group Policy Object (GPO) the rule
was originally applied in. Because AppLocker functions as an allowed list by default, if no rule explicitly allows or
denies a file from running, AppLocker's default deny action will block the file.
Deny rule considerations
Although you can use AppLocker to create a rule to allow all files to run and then use rules to deny specific files,
this configuration is not recommended. The deny action is generally less secure than the allow action because a
malicious user could modify the file to invalidate the rule. Deny actions can also be circumvented. For example, if
you configure a deny action for a file or folder path, the user can still run the file from any other path. The
following table details security concerns for different rule conditions with deny actions.
RUL E C O N DIT IO N SEC URIT Y C O N C ERN W IT H DEN Y A C T IO N
Publisher A user could modify the properties of a file (for example, re-
signing the file with a different certificate).
File hash A user could modify the hash for a file.
Path A user could move the denied file to a different location and
run it from there.
Impor tant: If you choose to use the deny action on rules, you must ensure that you first create rules that
allow the Windows system files to run. AppLocker enforces rules for allowed applications by default, so after
one or more rules have been created for a rule collection (affecting the Windows system files), only the apps
that are listed as being allowed will be permitted to run. Therefore, creating a single rule in a rule collection
to deny a malicious file from running will also deny all other files on the computer from running.
Related topics
How AppLocker works
Applies to
Windows 10
Windows Server
This topic for the IT professional describes the three types of AppLocker rule conditions.
Rule conditions are criteria that the AppLocker rule is based on. Primary conditions are required to create an
AppLocker rule. The three primary rule conditions are publisher, path, and file hash.
Publisher
To use a publisher condition, the files must be digitally signed by the software publisher, or you must do so by
using an internal certificate. Rules that are specified to the version level might have to be updated when a new
version of the file is released. For more info about this rule condition, see Understanding the publisher rule
condition in AppLocker.
Path
Any file can be assigned this rule condition; however, because path rules specify locations within the file system,
any subdirectory will also be affected by the rule (unless explicitly exempted). For more info about this rule
condition, see Understanding the path rule condition in AppLocker.
File hash
Any file can be assigned this rule condition; however, the rule must be updated each time a new version of the
file is released because the hash value is unique to that the version of the file. For more info about this rule
condition, see Understanding the file hash rule condition in AppLocker.
Considerations
Selecting the appropriate condition for each rule depends on the overall application control policy goals of the
organization, the AppLocker rule maintenance goals, and the condition of the existing (or planned) application
deployment. The following questions can help you decide which rule condition to use.
1. Is the file digitally signed by a software publisher?
If the file is signed by a software publisher, we recommend that you create rules with publisher
conditions. You may still create file hash and path conditions for signed files. However, if the file is not
digitally signed by a software publisher, you can:
Sign the file by using an internal certificate.
Create a rule by using a file hash condition.
Create a rule by using a path condition.
NOTE
To determine how many applications on a reference computer are digitally signed, you can use the Get-
AppLockerFileInformation Windows PowerShell cmdlet for a directory of files. For example,
Get-AppLockerFileInformation –Directory C:\Windows\ -FileType EXE -recurse displays the
properties for all .exe and .com files within the Windows directory.
2. What rule condition type does your organization prefer?

If your organization is already using Software Restriction Policies (SRP) to restrict what files users can run,
rules using file hash or path conditions are probably already in place.
NOTE
For a list of supported operating system versions and editions to which SRP and AppLocker rules can be applied,
see Requirements to use AppLocker.
Related topics
How AppLocker works
Understanding the publisher rule condition in
AppLocker
Applies to
Windows 10
Windows Server
This topic explains the AppLocker publisher rule condition, what controls are available, and how it is applied.
Publisher conditions can be made only for files that are digitally signed; this condition identifies an app based on
its digital signature and extended attributes. The digital signature contains information about the company that
created the app (the publisher). The extended attributes, which are obtained from the binary resource, contain
the name of the product that the app is part of and the version number of the app. The publisher may be a
software development company, such as Microsoft, or the Information Technology department of your
organization. Publisher conditions are easier to maintain than file hash conditions and are generally more
secure than path conditions. Rules that are specified to the version level might have to be updated when a new
version of the file is released. The following table describes the advantages and disadvantages of the publisher
condition.
P UB L ISH ER C O N DIT IO N A DVA N TA GES P UB L ISH ER C O N DIT IO N DISA DVA N TA GES
Frequent updating is not required. The file must be signed.

You can apply different values within a certificate. Although a single rule can be used to allow an
entire product suite, all files in the suite must be
A single rule can be used to allow an entire signed uniformly.
product suite.
You can use the asterisk (*) wildcard character
within a publisher rule to specify that any value
should be matched.
Wildcard characters can be used as values in the publisher rule fields according to the following specifications:
Publisher
The asterisk (*) character used by itself represents any publisher. When combined with any string value,
the rule is limited to the publisher with a value in the signed certificate that matches the character string.
In other words, the asterisk is not treated as a wildcard character if used with other characters in this field.
For example, using the characters "M*" limits the publisher name to only a publisher with the name "M*."
Using the characters "*x*" limits the publisher name only to the name “*x*”. A question mark (?) is not a
valid wildcard character in this field.
Product name
The asterisk (*) character used by itself represents any product name. When combined with any string
value, the rule is limited to the product of the publisher with a value in the signed certificate that matches
the character string. In other words, the asterisk is not treated as a wildcard character if used with other
characters in this field. A question mark (?) is not a valid wildcard character in this field.
File name
Either the asterisk (*) or question mark (?) characters used by themselves represent any and all file
names. When combined with any string value, the string is matched with any file name containing that
string.
File version
The asterisk (*) character used by itself represents any file version. If you want to limit the file version to a
specific version or as a starting point, you can state the file version and then use the following options to
apply limits:
Exactly . The rule applies only to this version of the app
And above . The rule applies to this version and all later versions.
And Below . The rule applies to this version and all earlier versions.
The following table describes how a publisher condition is applied.
All signed files All files that are signed by a publisher.
Publisher only All files that are signed by the named publisher.
Publisher and product name All files for the specified product that are signed by the
named publisher.
Publisher, product name, and file name Any version of the named file for the named product that is
signed by the publisher.
Publisher, product name, file name, and file version Exactly

The specified version of the named file for the named
product that is signed by the publisher.
Publisher, product name, file name, and file version And above
The specified version of the named file and any new releases
for the product that are signed by the publisher.
Publisher, product name, file name, and file version And below
The specified version of the named file and any older
versions for the product that are signed by the publisher.
Custom You can edit the Publisher , Product name , File name ,
and Version fields to create a custom rule.
For an overview of the three types of AppLocker rule conditions and explanations of the advantages and
disadvantages of each, see Understanding AppLocker rule condition types.
Related topics
How AppLocker works
Applies to
Windows 10
Windows Server
This topic explains the AppLocker path rule condition, the advantages and disadvantages, and how it is applied.
The path condition identifies an application by its location in the file system of the computer or on the network.
When creating a rule that uses a deny action, path conditions are less secure than publisher and file hash
conditions for preventing access to a file because a user could easily copy the file to a different location than the
location specified in the rule. Because path rules specify locations within the file system, you should ensure that
there are no subdirectories that are writable by non-administrators. For example, if you create a path rule for C:\
with the allow action, any file under that location will be allowed to run, including within users' profiles. The
following table describes the advantages and disadvantages of the path condition.
PAT H C O N DIT IO N A DVA N TA GES PAT H C O N DIT IO N DISA DVA N TA GES
You can easily control many folders or a single It might be less secure if a rule that is configured
file. to use a folder path contains subfolders that are
writable by non-administrators.
You can use the asterisk (*) as a wildcard
character within path rules. You must specify the full path to a file or folder
when creating path rules so that the rule will be
properly enforced.
AppLocker does not enforce rules that specify paths with short names. You should always specify the full path to
a file or folder when creating path rules so that the rule will be properly enforced.
The asterisk (*) wildcard character can be used within Path field. The asterisk (*) character used by itself
represents any path. When combined with any string value, the rule is limited to the path of the file and all the
files under that path. For example, %ProgramFiles%\Internet Explorer\* indicates that all files and subfolders
within the Internet Explorer folder will be affected by the rule.
AppLocker uses path variables for well-known directories in Windows. Path variables are not environment
variables. The AppLocker engine can only interpret AppLocker path variables. The following table details these
path variables.
W IN DO W S DIREC TO RY O R DRIVE A P P LO C K ER PAT H VA RIA B L E W IN DO W S EN VIRO N M EN T VA RIA B L E
Windows %WINDIR% %SystemRoot%
System32 and sysWOW64 %SYSTEM32% %SystemDirectory%
Windows installation directory %OSDRIVE% %SystemDrive%
Program Files %PROGRAMFILES% %ProgramFiles% and

%ProgramFiles(x86)%
W IN DO W S DIREC TO RY O R DRIVE A P P LO C K ER PAT H VA RIA B L E W IN DO W S EN VIRO N M EN T VA RIA B L E
Removable media (for example, CD or %REMOVABLE%

DVD)
Removable storage device (for %HOT%

example, USB flash drive)
Related topics
How AppLocker works
Understanding the file hash rule condition in
AppLocker
Applies to
Windows 10
Windows Server
This topic explains the AppLocker file hash rule condition, the advantages and disadvantages, and how it is
applied.
File hash rules use a system-computed cryptographic hash of the identified file. For files that are not digitally
signed, file hash rules are more secure than path rules. The following table describes the advantages and
disadvantages of the file hash condition.
F IL E H A SH C O N DIT IO N A DVA N TA GES F IL E H A SH C O N DIT IO N DISA DVA N TA GES
Because each file has a unique hash, a file hash condition Each time that the file is updated (such as a security update
applies to only one file. or upgrade), the file's hash will change. As a result, you must
manually update file hash rules.
Related topics
How AppLocker works
Applies to
Windows 10
Windows Server
This topic for IT professional describes the set of rules that can be used to ensure that required Windows system
files are allowed to run when the policy is applied.
that are required for Windows to operate properly are allowed in an AppLocker rule collection.
IMPORTANT
You can use the default rules as a template when creating your own rules. However, these rules are only meant to
function as a starter policy when you are first testing AppLocker rules so that the system files in the Windows folders will
be allowed to run.
If you require additional app security, you might need to modify the rules created from the built-in default rule
collection. For example, the default rule to allow all users to run .exe files in the Windows folder is based on a
path condition that allows all files within the Windows folder to run. The Windows folder contains a Temp
subfolder to which the Users group is given the following permissions:
Traverse Folder/Execute File
Create Files/Write Data
Create Folders/Append Data
These permissions settings are applied to this folder for app compatibility. However, because any user can create
files in this location, allowing applications to be run from this location might conflict with your organization's
security policy.
In this section
Executable rules in AppLocker This topic describes the file formats and available default
rules for the executable rule collection.
Windows Installer rules in AppLocker This topic describes the file formats and available default
rules for the Windows Installer rule collection.
Script rules in AppLocker This topic describes the file formats and available default
rules for the script rule collection.
DLL rules in AppLocker This topic describes the file formats and available default
rules for the DLL rule collection.
Packaged apps and packaged app installer rules in This topic explains the AppLocker rule collection for
AppLocker packaged app installers and packaged apps.
Related topics
How AppLocker works
Applies to
Windows 10
Windows Server
This topic describes the file formats and available default rules for the executable rule collection.
AppLocker defines executable rules as any files with the .exe and .com extensions that are associated with an
app. Because all of the default rules for the executable rule collection are based on folder paths, all files under
those paths will be allowed. The following table lists the default rules that are available for the executable rule
collection.
P URP O SE NAME USER RUL E C O N DIT IO N T Y P E
Allow members of the local (Default Rule) All files BUILTIN\Administrators Path: *
Administrators group
access to run all executable
files
Allow all users to run (Default Rule) All files Everyone Path: %windir%*
executable files in the located in the Windows
Windows folder folder
Allow all users to run (Default Rule) All files Everyone Path: %programfiles%*
executable files in the located in the Program Files
Program Files folder folder
Related topics
Understanding AppLocker Default Rules
Applies to
Windows 10
Windows Server
This topic describes the file formats and available default rules for the Windows Installer rule collection.
AppLocker defines Windows Installer rules to include only the following file formats:
.msi
.msp
.mst
The purpose of this collection is to allow you to control the installation of files on client computers and servers
through Group Policy or the Local Security Policy snap-in. The following table lists the default rules that are
available for the Windows Installer rule collection.
Allow members of the local (Default Rule) All Windows BUILTIN\Administrators Path: *
Administrators group to Installer files
run all Windows Installer
files
Allow all users to run (Default Rule) All digitally Everyone Publisher: * (all signed files)
Windows Installer files that signed Windows Installer
are digitally signed files
Allow all users to run (Default Rule) All Windows Everyone Path: %windir%\Installer*
Windows Installer files that Installer files in
are located in the Windows %systemdrive%\Windows\I
Installer folder nstaller
Related topics
Applies to
Windows 10
Windows Server
This topic describes the file formats and available default rules for the script rule collection.
AppLocker defines script rules to include only the following file formats:
.ps1
.bat
.cmd
.vbs
.js
The following table lists the default rules that are available for the script rule collection.
Allows members of the local (Default Rule) All scripts BUILTIN\Administrators Path: *
Administrators group to
run all scripts
Allow all users to run scripts (Default Rule) All scripts Everyone Path: %windir%*
in the Windows folder located in the Windows
folder
Allow all users to run scripts (Default Rule) All scripts Everyone Path: %programfiles%*
in the Program Files folder located in the Program Files
folder
Related topics
Applies to
Windows 10
Windows Server
This topic describes the file formats and available default rules for the DLL rule collection.
AppLocker defines DLL rules to include only the following file formats:
.dll
.ocx
The following table lists the default rules that are available for the DLL rule collection.
Allows members of the local (Default Rule) All DLLs

Administrators group to
run all DLLs
BUILTIN\Administrators Path: *
Allow all users to run DLLs (Default Rule) Microsoft

in the Windows folder Windows DLLs
Everyone Path: %windir%*
Allow all users to run DLLs (Default Rule) All DLLs

in the Program Files folder located in the Program Files
folder
Everyone Path: %programfiles%*
IMPORTANT
If you use DLL rules, a DLL allow rule has to be created for each DLL that is used by all of the allowed apps
Cau t i on
When DLL rules are used, AppLocker must check each DLL that an app loads. Therefore, users may experience a
reduction in performance if DLL rules are used.
Related topics
Packaged apps and packaged app installer rules in
AppLocker
Applies to
Windows 10
Windows Server
This topic explains the AppLocker rule collection for packaged app installers and packaged apps.
Universal Windows apps can be installed through the Microsoft Store or can be sideloaded using the Windows
PowerShell cmdlets. Universal Windows apps can be installed by a standard user unlike some Classic Windows
applications that sometimes require administrative privileges for installation. Typically, an app consists of
multiple components – the installer used to install the app and one or more exes, dlls or scripts. With Classic
Windows applications, not all those components always share common attributes such as the publisher name,
product name and product version. Therefore, AppLocker has to control each of these components separately
through different rule collections – exe, dll, script and Windows Installers. In contrast, all the components of a
Universal Windows app share the same attributes: Publisher name, Package name and Package version. It is
therefore possible to control an entire app with a single rule.
AppLocker enforces rules for Universal Windows apps separately from Classic Windows applications. A single
AppLocker rule for a Universal Windows app can control both the installation and the running of an app.
Because all Universal Windows apps are signed, AppLocker supports only publisher rules for Universal
Windows apps. A publisher rule for a Universal Windows app is based on the following attributes of the app:
Publisher name
Package name
Package version
In summary, including AppLocker rules for Universal Windows apps in your policy design provides:
The ability to control the installation and running of the app
The ability to control all the components of the app with a single rule rather than controlling individual
binaries within the app
The ability to create application control policies that survive app updates
Management of Universal Windows apps through Group Policy.
Applies to
Windows 10
Windows Server
This topic for IT professional describes AppLocker’s basic architecture and its major components.
AppLocker relies on the Application Identity service to provide attributes for a file and to evaluate the AppLocker
policy for the file. AppLocker policies are conditional access control entries (ACEs), and policies are evaluated by
using the attribute-based access control SeAccessCheckWithSecurityAttributes or AuthzAccessCheck
functions.
AppLocker provides three ways to intercept and validate if a file is allowed to execute according to an AppLocker
policy.
A new process is created
When a new process is created, such as an executable file or a Universal Windows app is run, AppLocker invokes
the Application Identity component to calculate the attributes of the main executable file used to create a new
process. It then updates the new process's token with these attributes and checks the AppLocker policy to verify
that the executable file is allowed to run.
A DLL is loaded
When a new DLL loads, a notification is sent to AppLocker to verify that the DLL is allowed to load. AppLocker
calls the Application Identity component to calculate the file attributes. It duplicates the existing process token
and replaces those Application Identity attributes in the duplicated token with attributes of the loaded DLL.
AppLocker then evaluates the policy for this DLL, and the duplicated token is discarded. Depending on the result
of this check, the system either continues to load the DLL or stops the process.
A script is run
Before a script file is run, the script host (for example. for .ps1 files the script host is PowerShell) invokes
AppLocker to verify the script. AppLocker invokes the Application Identity component in user-mode with the file
name or file handle to calculate the file properties. The script file then is evaluated against the AppLocker policy
to verify that it is allowed to run. In each case, the actions taken by AppLocker are written to the event log.
Related topics
Applies to
Windows 10
Windows Server
This topic for the IT professional describes the process dependencies and interactions when AppLocker
evaluates and enforces rules.
How policies are implemented by AppLocker

AppLocker policies are collections of AppLocker rules that might contain any one of the enforcement settings
configured. When applied, each rule is evaluated within the policy and the collection of rules is applied
according to the enforcement setting and according to your Group Policy structure.
The AppLocker policy is enforced on a computer through the Application Identity service, which is the engine
that evaluates the policies. If the service is not running, policies will not be enforced. The Application Identity
service returns the information from the binary -even if product or binary names are empty- to the results pane
of the Local Security Policy snap-in.
AppLocker policies are stored in a security descriptor format according to Application Identity service
requirements. It uses file path, hash, or fully qualified binary name attributes to form allow or deny actions on a
rule. Each rule is stored as an access control entry (ACE) in the security descriptor and contains the following
information:
Either an allow or a deny ACE ("XA" or "XD" in security descriptor definition language (SDDL) form).
The user security identifier (SID) that this rule is applicable to. (The default is the authenticated user SID, or
"AU" in SDDL.)
The rule condition containing the appid attributes.
For example, an SDDL for a rule that allows all files in the %windir% directory to run uses the following format:
XA;;FX;;;AU;(APPID://PATH == "%windir%\*").
An AppLocker policy for DLLs and executable files is read and cached by kernel mode code, which is part of
appid.sys. Whenever a new policy is applied, appid.sys is notified by a policy converter task. For other file types,
the AppLocker policy is read every time a SaferIdentifyLevel call is made.
Understanding AppLocker rules
An AppLocker rule is a control placed on a file to govern whether or not it is allowed to run for a specific user or
group. Rules apply to five different types, or collections, of files:
An executable rule controls whether a user or group can run an executable file. Executable files most often
have the .exe or .com file name extensions and apply to applications.
A script rule controls whether a user or group can run scripts with a file name extension of .ps1, .bat, .cmd,
.vbs, and .js.
A Windows Installer rule controls whether a user or group can run files with a file name extension of .msi,
.mst and .msp (Windows Installer patch).
A DLL rule controls whether a user or group can run files with a file name extension of .dll and .ocx.
A packaged app and packaged app installer rule controls whether a user or group can run or install a
packaged app. A Packaged app installer has the .appx extension.
There are three different types of conditions that can be applied to rules:
A publisher condition on a rule controls whether a user or group can run files from a specific software
publisher. The file must be signed.
A path condition on a rule controls whether a user or group can run files from within a specific directory
or its subdirectories.
A file hash condition on a rule controls whether a user or group can run files with matching encrypted
hashes.
An AppLocker rule collection is a set of rules that apply to one of the following types: executable files,
Windows Installer files, scripts, DLLs, and packaged apps.
Rule conditions are criteria that the AppLocker rule is based on. Primary conditions are required to create
an AppLocker rule. The three primary rule conditions are publisher, path, and file hash.
AppLocker includes default rules for each rule collection. These rules are intended to help ensure that the
files that are required for Windows to operate properly are allowed in an AppLocker rule collection.
You can apply AppLocker rules to individual users or a group of users. If you apply a rule to a group of
users, all users in that group are affected by that rule. If you need to allow only a subset of a user group
to use an application, you can create a special rule for that subset.
Understanding AppLocker rule behavior and Understanding AppLocker allow and deny actions on Rules
Each AppLocker rule collection functions as an allowed list of files.
Understanding AppLocker policies
An AppLocker policy is a set of rule collections and their corresponding configured enforcement settings that
have been applied to one or more computers.
Rule enforcement is applied only to collections of rules, not individual rules. AppLocker divides the rules
into four collections: executable files, Windows Installer files, scripts, and DLL files. The options for rule
enforcement are Not configured , Enforce rules , or Audit only . Together, all AppLocker rule collections
compose the application control policy, or AppLocker policy. By default, if enforcement is not configured
and rules are present in a rule collection, those rules are enforced.
Understanding AppLocker and Group Policy
Group Policy can be used to create, modify, and distribute AppLocker policies in separate objects or in
combination with other policies.
Understand AppLocker rules and enforcement setting inheritance in Group Policy
When Group Policy is used to distribute AppLocker policies, rule collections that are not configured will
be enforced. Group Policy does not overwrite or replace rules that are already present in a linked Group
Policy Object (GPO) and applies the AppLocker rules in addition to existing rules. AppLocker processes
the explicit deny rule configuration before the allow rule configuration, and for rule enforcement, the last
write to the GPO is applied.
Related topics
AppLocker functions
Applies to
Windows 10
Windows Server
This article for the IT professional lists the functions and security levels for the Software Restriction Policies
(SRP) and AppLocker features.
Functions
Here are the SRP functions beginning with Windows Server 2003 and AppLocker functions beginning with
Windows Server 2008 R2:
SaferGetPolicyInformation Function
SaferCreateLevel Function
SaferCloseLevel Function
SaferIdentifyLevel Function
SaferComputeTokenFromLevel Function
SaferGetLevelInformation Function
SaferRecordEventLogEntry Function
SaferiIsExecutableFileType Function
Security level ID
AppLocker and SRP use the security level IDs to specify the access requirements to files listed in policies. The
following table shows those security levels supported in SRP and AppLocker.
SEC URIT Y L EVEL ID SRP A P P LO C K ER
SAFER_LEVELID_FULLYTRUSTED Supported Supported
SAFER_LEVELID_NORMALUSER Supported Not supported
SAFER_LEVELID_CONSTRAINED Supported Not supported
SAFER_LEVELID_UNTRUSTED Supported Not supported
SAFER_LEVELID_DISALLOWED Supported Supported
NOTE
URL zone ID isn't supported in AppLocker.
Related articles
Security considerations for AppLocker
Applies to
Windows 10
Windows Server
This topic for the IT professional describes the security considerations you need to address when implementing
AppLocker.
The purpose of AppLocker is to restrict the access to software, and therefore, the data accessed by the software,
to a specific group of users or within a defined business group. The following are security considerations for
AppLocker:
AppLocker is deployed within an enterprise and administered centrally by those in IT with trusted credentials.
This makes its policy creation and deployment conform to similar policy deployment processes and security
restrictions.
AppLocker policies are distributed through known processes and by known means within the domain through
Group Policy. But AppLocker policies can also be set on individual computers if the person has administrator
privileges, and those policies might be contrary to the organization's written security policy. The enforcement
settings for local policies are overridden by the same AppLocker policies in a Group Policy Object (GPO).
However, because AppLocker rules are additive, a local policy that is not in a GPO will still be evaluated for that
computer.
Microsoft does not provide a way to develop any extensions to AppLocker. The interfaces are not public. A user
with administrator credentials can automate some AppLocker processes by using Windows PowerShell cmdlets.
For info about the Windows PowerShell cmdlets for AppLocker, see the AppLocker Cmdlets in Windows
PowerShell.
AppLocker runs in the context of Administrator or LocalSystem, which is the highest privilege set. This security
context has the potential of misuse. If a user with administrative credentials makes changes to an AppLocker
policy on a local device that is joined to a domain, those changes could be overwritten or disallowed by the GPO
that contains the AppLocker rule for the same file (or path) that was changed on the local device. However,
because AppLocker rules are additive, a local policy that is not in a GPO will still be evaluated for that computer.
If the local computer is not joined to a domain and is not administered by Group Policy, a person with
administrative credentials can alter the AppLocker policy.
When securing files in a directory with a rule of the path condition type, whether using the allow or deny action
on the rule, it is still necessary and good practice to restrict access to those files by setting the access control lists
(ACLs) according to your security policy.
AppLocker does not protect against running 16-bit DOS binaries in the Virtual DOS Machine (NTVDM). This
technology allows running legacy DOS and 16-bit Windows programs on computers that are using Intel 80386
or later when there is already another operating system running and controlling the hardware. The result is that
16-bit binaries can still run on Windows Server 2008 R2 and Windows 7 when AppLocker is configured to
otherwise block binaries and libraries. If it is a requirement to prevent 16-bit applications from running, you
must configure the Deny rule in the executable rule collection for NTVDM.exe.
You cannot use AppLocker (or Software Restriction Policies) to prevent code from running outside the Win32
subsystem. In particular, this applies to the (POSIX) subsystem in Windows NT. If it is a requirement to prevent
applications from running in the POSIX subsystem, you must disable the subsystem.
AppLocker can only control VBScript, JScript, .bat files, .cmd files, and Windows PowerShell scripts. It does not
control all interpreted code that runs within a host process, for example, Perl scripts and macros. Interpreted
code is a form of executable code that runs within a host process. For example, Windows batch files (*.bat) run
within the context of the Windows Command Host (cmd.exe). To control interpreted code by using AppLocker,
the host process must call AppLocker before it runs the interpreted code, and then enforce the decision returned
by AppLocker. Not all host processes call into AppLocker and, therefore, AppLocker cannot control every kind of
interpreted code, such as Microsoft Office macros.
IMPORTANT
You should configure the appropriate security settings of these host processes if you must allow them to run. For
example, configure the security settings in Microsoft Office to ensure that only signed and trusted macros are loaded.
AppLocker rules either allow or prevent an application from launching. AppLocker does not control the behavior
of applications after they are launched. Applications could contain flags passed to functions that signal
AppLocker to circumvent the rules and allow another .exe or .dll to be loaded. In practice, an application that is
allowed by AppLocker could use these flags to bypass AppLocker rules and launch child processes. You must
thoroughly examine each application before allowing them to run by using AppLocker rules.
NOTE
Two flags that illustrate this condition are SANDBOX_INERT , which can be passed to CreateRestrictedToken , and
LOAD_IGNORE_CODE_AUTHZ_LEVEL , which can be passed to LoadLibraryEx . Both of these flags signal AppLocker to
circumvent the rules and allow a child .exe or .dll to be loaded.
You can block the Windows Subsystem for Linux by blocking LxssManager.dll.
Related topics
Tools to use with AppLocker
Applies to
Windows 10
Windows Server
This topic for the IT professional describes the tools available to create and administer AppLocker policies.
The following tools can help you administer the application control policies created by using AppLocker on the
local device or by using Group Policy. For info about the basic requirements for using AppLocker, see
Requirements to use AppLocker.
AppLocker Local Security Policy MMC snap-in
The AppLocker rules can be maintained by using the Local Security Policy snap-in (secpol.msc) of the
Microsoft Management Console (MMC). For procedures to create, modify, and delete AppLocker rules,
see Working with AppLocker rules.
Generate Default Rules tool
AppLocker includes default rules for each rule collection accessed through the Local Security Policy snap-
in. These rules are intended to help ensure that the files that are required for Windows to operate
properly are allowed in an AppLocker rule collection. For info about how to use this tool, see Create
AppLocker default rules. For a list of the default rules, see AppLocker default rules.
Automatically Generate AppLocker Rules wizard
By using the Local Security Policy snap-in, you can automatically generate rules for all files within a folder.
The wizard will scan the specified folder and create the condition types that you choose for each file in
that folder. For info about how to use this wizard, see Run the Automatically Generate Rules wizard.
Group Policy
You can edit an AppLocker policy by adding, changing, or removing rules by using the Group Policy
Management Console (GPMC).
If you want additional features to manage AppLocker policies, such as version control, use Group Policy
management software that allows you to create versions of Group Policy Objects (GPOs). An example of
this type of software is the Advanced Group Policy Management feature from the Microsoft Desktop
Optimization Pack.
Remote Ser ver Administration Tools (RSAT)
You can use a device with a supported operating system that has the Remote Server Administration Tools
(RSAT) installed to create and maintain AppLocker policies.
Event Viewer
The AppLocker log contains information about applications that are affected by AppLocker rules. For info
about using Event Viewer to review the AppLocker logs, see Using Event Viewer with AppLocker, and
Monitor app usage with AppLocker.
AppLocker PowerShell cmdlets
The AppLocker Windows PowerShell cmdlets are designed to streamline the administration of AppLocker
policy. They can be used to help create, test, maintain, and troubleshoot an AppLocker policy. The cmdlets
are intended to be used in conjunction with the AppLocker user interface that is accessed through the
Local Security Policy snap-in and the GPMC. For information about the cmdlets, see the AppLocker
PowerShell Command Reference.
Related topics
Using Event Viewer with AppLocker
Applies to
Windows 10
Windows Server
This topic lists AppLocker events and describes how to use Event Viewer with AppLocker.
The AppLocker log contains information about applications that are affected by AppLocker rules. Each event in
the log contains detailed info about:
Which file is affected and the path of that file
Which packaged app is affected and the package identifier of the app
Whether the file or packaged app is allowed or blocked
The rule type (path, file hash, or publisher)
The rule name
The security identifier (SID) for the user or group identified in the rule
Review the entries in the Event Viewer to determine if any applications are not included in the rules that you
automatically generated. For instance, some line-of-business apps are installed to non-standard locations, such
as the root of the active drive (for example: %SystemDrive%).
For info about what to look for in the AppLocker event logs, see Monitor app usage with AppLocker.
To review the AppLocker log in Event Viewer
1. Open Event Viewer.
2. In the console tree under Application and Ser vices Logs\Microsoft\Windows , click AppLocker .
The following table contains information about the events that you can use to determine which apps are
affected by AppLocker rules.
EVEN T ID L EVEL EVEN T M ESSA GE DESC RIP T IO N
8000 Error Application Identity Policy Indicates that the policy

conversion failed. Status * was not applied correctly to
<%1> * the computer. The status
message is provided for
troubleshooting purposes.
8001 Information The AppLocker policy was Indicates that the

applied successfully to this AppLocker policy was
computer. successfully applied to the
computer.
8002 Information *<File name> * was allowed Specifies that the .exe or .dll
to run. file is allowed by an
AppLocker rule.
8003 Warning *<File name> * was allowed Applied only when the
to run but would have been Audit only enforcement
prevented from running if mode is enabled. Specifies
the AppLocker policy were that the .exe or .dll file
enforced. would be blocked if the
Enforce rules enforcement
mode were enabled.
8004 Error *<File name> * was not Access to <file name> is

allowed to run. restricted by the
administrator. Applied only
when the Enforce rules
enforcement mode is set
either directly or indirectly
through Group Policy
inheritance. The .exe or .dll
file cannot run.
8005 Information *<File name> * was allowed Specifies that the script or
to run. .msi file is allowed by an
AppLocker rule.
8006 Warning *<File name> * was allowed Applied only when the
to run but would have been Audit only enforcement
prevented from running if mode is enabled. Specifies
the AppLocker policy were that the script or .msi file
enforced. would be blocked if the
Enforce rules enforcement
mode were enabled.
8007 Error *<File name> * was not Access to <file name> is

allowed to run. restricted by the
administrator. Applied only
when the Enforce rules
enforcement mode is set
either directly or indirectly
through Group Policy
inheritance. The script or
.msi file cannot run.
8008 Error AppLocker disabled on the Added in Windows Server

SKU. 2012 and Windows 8.
8020 Information Packaged app allowed. Added in Windows Server

2012 and Windows 8.
8021 Information Packaged app audited. Added in Windows Server

2012 and Windows 8.
8022 Information Packaged app disabled. Added in Windows Server

2012 and Windows 8.
8023 Information Packaged app installation Added in Windows Server

allowed. 2012 and Windows 8.
8024 Information Packaged app installation Added in Windows Server

audited. 2012 and Windows 8.
8025 Warning Packaged app installation Added in Windows Server

disabled. 2012 and Windows 8.
8027 Warning No Packaged app rule Added in Windows Server

configured. 2012 and Windows 8.
Related topics
Tools to use with AppLocker
AppLocker settings
Applies to
Windows 10
Windows Server
This topic for the IT professional lists the settings used by AppLocker.
The following table describes the settings and values used by AppLocker.
SET T IN G VA L UE
Registry path Policies are stored in

HKEY_LOCAL_Machine\Software\Policies\Microsoft\
Windows\SrpV2
Firewall ports Not applicable
Security policies Custom created, no default
Group Policy settings Custom created, no default
Network ports Not applicable
Service accounts Not applicable
Performance counters Not applicable
Related topics

Appwhitelisting With Intune

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Appwhitelisting With Intune

Uploaded by

Copyright:

Available Formats

Contents

Application Control for Windows

Windows Defender Application Control

Choose when to use WDAC or AppLocker

Platform support Available on Windows 10 Available on Windows 8+

Management solutions Intune (limited built-in policies Intune (custom policy

Kernel mode policies Available on all Windows 10 versions Not available

Per-app rules Available on 1703+ Not available

Managed Installer (MI) Available on 1703+ Not available

Reputation-Based intelligence Available on 1709+ Not available

Multiple policy support Available on 1903+ Not available

COM object configurability Available on 1903+ Not available

Packaged app rules Available on RS5+ Available on Windows 8+

Windows Defender Application Control

Plan for success

Policy XML lifecycle management

WDAC event management

Application and user support policy

Document your plan

Decide what policies to create

WDAC design considerations

P O SSIB L E A N SW ERS DESIGN C O N SIDERAT IO N S

P O SSIB L E A N SW ERS DESIGN C O N SIDERAT IO N S

P O SSIB L E A N SW ERS DESIGN C O N SIDERAT IO N S

Yes WDAC policies can be created unique per team, or team-

No WDAC policies can be applied globally to applications that

P O SSIB L E A N SW ERS DESIGN C O N SIDERAT IO N S

Yes Invest the time to analyze your organization's application

No Consider a focused and phased deployment for specific

Does your organization have Help Desk support?

P O SSIB L E A N SW ERS DESIGN C O N SIDERAT IO N S

Yes Involve the support department early in the planning phase

No Invest time in developing online support processes and

Windows Defender Application Control policy rules

Table 1. Windows Defender Application Control policy - policy rule options

RUL E O P T IO N DESC RIP T IO N

0 Enabled:UMCI WDAC policies restrict both kernel-mode and user-mode

1 Enabled:Boot Menu Protection This option is not currently supported.

2 Required:WHQL By default, legacy drivers that are not Windows Hardware

4 Disabled:Flight Signing If enabled, WDAC policies will not trust flightroot-signed

7 Allowed:Debug Policy Augmented This option is not currently supported.

11 Disabled:Script Enforcement This option disables script enforcement options. Unsigned

13 Enabled:Managed Installer Use this option to automatically allow applications installed

Windows Defender Application Control file rule levels

RUL E L EVEL DESC RIP T IO N

Hash Specifies individual hash values for each discovered binary.

FileName Specifies individual binary file names. Although the hash

FilePath Beginning with Windows 10 version 1903, this specifies rules

Publisher This is a combination of the PcaCertificate level (typically one

FilePublisher This is a combination of the “FileName” attribute of the

LeafCer tificate Adds trusted signers at the individual signing certificate

PcaCer tificate Adds the highest available certificate in the provided

RootCer tificate Currently unsupported.

WHQL Trusts binaries if they have been validated and signed by

WHQLPublisher This is a combination of the WHQL and the CN on the leaf

WHQLFilePublisher Specifies that the binaries are validated and signed by

Example of file rule levels in use

More information about filepath rules

Windows Defender Application Control filename rules

RUL E L EVEL DESC RIP T IO N

Internal Name Specifies the internal name of the binary.

How does a managed installer work?

Security considerations with managed installer