Reviewed AppLocker articles for accuracy and fixed acrolinx and readability issues

windows/security/application-security/application-control/windows-defender-application-control/applocker/applocker-architecture-and-components.md

@@ -1,34 +1,31 @@
 ---
 title: AppLocker architecture and components
-description: This topic for IT professional describes AppLocker’s basic architecture and its major components.
+description: This article for IT professional describes AppLocker’s basic architecture and its major components.
 ms.localizationpriority: medium
 ms.topic: conceptual
-ms.date: 09/21/2017
+ms.date: 12/23/2023
 ---
 
 # AppLocker architecture and components
 
-> [!NOTE]
+This article for IT professional describes AppLocker's basic architecture and its major components.
-> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
 
-This topic for IT professional describes AppLocker's basic architecture and its major components.
+AppLocker uses 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 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 run according to an AppLocker policy.
 
-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
 
-**A new process is created**
+When an app file is run, a new process is created. When that happens, AppLocker calls 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.
 
-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
 
-**A DLL is loaded**
+When a DLL is loaded, 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.
 
-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
 
-**A script is run**
+Before a script file is run, the script host (for example, PowerShell) calls AppLocker to verify the script. AppLocker calls 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 should run. In each case, the actions taken by AppLocker are written to the event log.
 
-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's allowed to run. In each case, the actions taken by AppLocker are written to the event log.
+## Related articles
-
-## Related topics
 
 - [AppLocker technical reference](applocker-technical-reference.md)

windows/security/application-security/application-control/windows-defender-application-control/applocker/applocker-functions.md

@@ -1,45 +1,40 @@
 ---
 title: AppLocker functions
-description: This article for the IT professional lists the functions and security levels for the Software Restriction Policies (SRP) and AppLocker features.
+description: This article for the IT professional lists the functions and security levels for AppLocker.
 ms.localizationpriority: medium
 ms.topic: conceptual
-ms.date: 09/21/2017
+ms.date: 12/23/2023
 ---
 
 # AppLocker functions
 
-> [!NOTE]
+This article for the IT professional lists the functions and security levels for AppLocker.
-> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
-
-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](/windows/win32/api/winsafer/nf-winsafer-safergetpolicyinformation)
-
+- [SaferCreateLevel Function](/windows/win32/api/winsafer/nf-winsafer-safercreatelevel)
--   [SaferGetPolicyInformation Function](/windows/win32/api/winsafer/nf-winsafer-safergetpolicyinformation)
+- [SaferCloseLevel Function](/windows/win32/api/winsafer/nf-winsafer-safercloselevel)
--   [SaferCreateLevel Function](/windows/win32/api/winsafer/nf-winsafer-safercreatelevel)
+- [SaferIdentifyLevel Function](/windows/win32/api/winsafer/nf-winsafer-saferidentifylevel)
--   [SaferCloseLevel Function](/windows/win32/api/winsafer/nf-winsafer-safercloselevel)
+- [SaferComputeTokenFromLevel Function](/windows/win32/api/winsafer/nf-winsafer-safercomputetokenfromlevel)
--   [SaferIdentifyLevel Function](/windows/win32/api/winsafer/nf-winsafer-saferidentifylevel)
+- [SaferGetLevelInformation Function](/windows/win32/api/winsafer/nf-winsafer-safergetlevelinformation)
--   [SaferComputeTokenFromLevel Function](/windows/win32/api/winsafer/nf-winsafer-safercomputetokenfromlevel)
+- [SaferRecordEventLogEntry Function](/windows/win32/api/winsafer/nf-winsafer-saferrecordeventlogentry)
--   [SaferGetLevelInformation Function](/windows/win32/api/winsafer/nf-winsafer-safergetlevelinformation)
+- [SaferiIsExecutableFileType Function](/windows/win32/api/winsafer/nf-winsafer-saferiisexecutablefiletype)
--   [SaferRecordEventLogEntry Function](/windows/win32/api/winsafer/nf-winsafer-saferrecordeventlogentry)
--   [SaferiIsExecutableFileType Function](/windows/win32/api/winsafer/nf-winsafer-saferiisexecutablefiletype)
 
 ## 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.
+AppLocker uses the security level IDs to specify the access requirements to files listed in policies. The following table shows those security levels supported in AppLocker.
 
-| Security level ID | SRP | AppLocker |
+| Security level ID | AppLocker |
-| - | - | - |
+| --- | --- |
-| SAFER_LEVELID_FULLYTRUSTED | Supported | Supported | 
+| SAFER_LEVELID_FULLYTRUSTED | Supported |
-| SAFER_LEVELID_NORMALUSER | Supported | Not supported |
+| SAFER_LEVELID_NORMALUSER | Not supported |
-| SAFER_LEVELID_CONSTRAINED | Supported | Not supported |
+| SAFER_LEVELID_CONSTRAINED | Not supported |
-| SAFER_LEVELID_UNTRUSTED | Supported | Not supported |
+| SAFER_LEVELID_UNTRUSTED | Not supported |
-| SAFER_LEVELID_DISALLOWED | Supported | Supported | 
+| SAFER_LEVELID_DISALLOWED | Supported |
- 
+
->[!Note]
+> [!NOTE]
->URL zone ID isn't supported in AppLocker.
+> URL zone ID isn't supported in AppLocker.
 
 ## Related articles
 

windows/security/application-security/application-control/windows-defender-application-control/applocker/applocker-processes-and-interactions.md

@@ -1,9 +1,9 @@
 ---
 title: AppLocker processes and interactions
-description: This topic for the IT professional describes the process dependencies and interactions when AppLocker evaluates and enforces rules.
+description: This article for the IT professional describes the process dependencies and interactions when AppLocker evaluates and enforces rules.
 ms.localizationpriority: medium
 ms.topic: conceptual
-ms.date: 09/21/2017
+ms.date: 12/23/2023
 ---
 
 # AppLocker processes and interactions
@@ -11,85 +11,85 @@ ms.date: 09/21/2017
 > [!NOTE]
 > Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
 
-This topic for the IT professional describes the process dependencies and interactions when AppLocker evaluates and enforces rules.
+This article for the IT professional describes the process dependencies and interactions when AppLocker evaluates and enforces rules.
 
-## How policies are implemented by AppLocker
+## How AppLocker applies policies
 
-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.
+AppLocker policies are collections of rules that might contain any one of the enforcement mode 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 isn't running, policies won't 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.
+The AppLocker policy is enforced on a computer through the Application Identity service (appid.sys), which is the engine that evaluates the policies and runs within the Windows kernel. If the service isn't running, policies aren't 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).
+- 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 user security identifier (SID) that this rule is applicable to. (The default is the authenticated user SID in SDDL.)
--   The rule condition containing the **appid** attributes.
+- 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%\\\*").
+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.
+Appid.sys reads and caches the effective AppLocker policy for DLLs and executable files. Whenever a new policy is applied, a policy converter task notifies appid.sys. For other file types, the AppLocker policy is read every time a **SaferIdentifyLevel** call is made.
 
-### Understanding AppLocker rules
+## Understanding AppLocker rules
 
-An AppLocker rule is a control placed on a file to govern whether or not it's allowed to run for a specific user or group. Rules apply to five different types, or collections, of files:
+An AppLocker rule is a control placed on a file that controls whether or not it runs for a specific user or group. You create AppLocker rules for five different types of files, or collections:
 
--   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.
+- 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 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 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 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.
+- 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 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 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.
+- A file hash condition on a rule controls whether a user or group can run files with matching encrypted hashes.
 
--   [Understanding AppLocker rule collections](understanding-applocker-rule-collections.md)
+- [Understanding AppLocker rule collections](understanding-applocker-rule-collections.md)
 
     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.
 
--   [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md)
+- [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md)
 
     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.
 
-    -   [Understanding the publisher rule condition in AppLocker](understanding-the-publisher-rule-condition-in-applocker.md)
+  - [Understanding the publisher rule condition in AppLocker](understanding-the-publisher-rule-condition-in-applocker.md)
-    -   [Understanding the path rule condition in AppLocker](understanding-the-path-rule-condition-in-applocker.md)
+  - [Understanding the path rule condition in AppLocker](understanding-the-path-rule-condition-in-applocker.md)
-    -   [Understanding the file hash rule condition in AppLocker](understanding-the-file-hash-rule-condition-in-applocker.md)
+  - [Understanding the file hash rule condition in AppLocker](understanding-the-file-hash-rule-condition-in-applocker.md)
--   [Understanding AppLocker default rules](understanding-applocker-default-rules.md)
+- [Understanding AppLocker default rules](understanding-applocker-default-rules.md)
 
     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.
 
-    -   [Executable rules in AppLocker](executable-rules-in-applocker.md)
+  - [Executable rules in AppLocker](executable-rules-in-applocker.md)
-    -   [Windows Installer rules in AppLocker](windows-installer-rules-in-applocker.md)
+  - [Windows Installer rules in AppLocker](windows-installer-rules-in-applocker.md)
-    -   [Script rules in AppLocker](script-rules-in-applocker.md)
+  - [Script rules in AppLocker](script-rules-in-applocker.md)
-    -   [DLL rules in AppLocker](dll-rules-in-applocker.md)
+  - [DLL rules in AppLocker](dll-rules-in-applocker.md)
-    -   [Packaged apps and packaged app installer rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md)
+  - [Packaged apps and packaged app installer rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md)
--   [Understanding AppLocker rule exceptions](understanding-applocker-rule-exceptions.md)
+- [Understanding AppLocker rule exceptions](understanding-applocker-rule-exceptions.md)
 
-    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.
+    You can apply AppLocker rules to individual users or a group of users. If you apply a rule to a group of users, the rule affects all users in that group. 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](understanding-applocker-rule-behavior.md) and [Understanding AppLocker allow and deny actions on Rules](understanding-applocker-allow-and-deny-actions-on-rules.md)
+- [Understanding AppLocker rule behavior](understanding-applocker-rule-behavior.md) and [Understanding AppLocker allow and deny actions on Rules](understanding-applocker-allow-and-deny-actions-on-rules.md)
 
     Each AppLocker rule collection functions as an allowed list of files.
 
-### Understanding AppLocker policies
+## 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.
+An AppLocker policy is a set of rule collections and their corresponding configured enforcement mode settings applied to one or more computers.
 
--   [Understand AppLocker enforcement settings](understand-applocker-enforcement-settings.md)
+- [Understand AppLocker enforcement settings](understand-applocker-enforcement-settings.md)
 
     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 isn't configured and rules are present in a rule collection, those rules are enforced.
 
-### Understanding AppLocker and Group Policy
+## 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](understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md)
+- [Understand AppLocker rules and enforcement setting inheritance in Group Policy](understand-applocker-rules-and-enforcement-setting-inheritance-in-group-policy.md)
 
-    When Group Policy is used to distribute AppLocker policies, rule collections that aren't configured will be enforced. Group Policy doesn't 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. 
+    When Group Policy is used to distribute AppLocker policies, rule collections containing one or more rules are enforced unless the enforcement mode is set to **Audit only**. Group Policy doesn't 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.
+    AppLocker processes explicit deny rules before any allow rules, and for rule enforcement, the last write to the GPO is applied.
 
-## Related topics
+## Related articles
 
 - [AppLocker technical reference](applocker-technical-reference.md)

windows/security/application-security/application-control/windows-defender-application-control/applocker/dll-rules-in-applocker.md

@@ -1,37 +1,34 @@
 ---
 title: DLL rules in AppLocker
-description: This topic describes the file formats and available default rules for the DLL rule collection.
+description: This article describes the file formats and available default rules for the DLL rule collection.
 ms.localizationpriority: medium
 ms.topic: conceptual
-ms.date: 09/21/2017
+ms.date: 12/23/2023
 ---
 
 # DLL rules in AppLocker
 
->[!NOTE]
+This article describes the file formats and available default rules for the DLL rule collection.
->Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
-
-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
+- .dll
--   .ocx
+- .ocx
+
+> [!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, including Windows system files.
 
 The following table lists the default rules that are available for the DLL rule collection.
 
 | Purpose | Name | User | Rule condition type |
-| - | - | - | - |
+| --- | --- | --- | --- |
-| Allows members of the local Administrators group to run all DLLs | (Default Rule) All DLLs| BUILTIN\Administrators | Path: *| 
+| Allows members of the local Administrators group to run all DLLs | (Default Rule) All DLLs | BUILTIN\Administrators | Path: * |
-| Allow all users to run DLLs in the Windows folder| (Default Rule) Microsoft Windows DLLs | Everyone | Path: %windir%\*| 
+| Allow all users to run DLLs in the Windows folder | (Default Rule) Microsoft Windows DLLs | Everyone | Path: %windir%\* |
-| Allow all users to run DLLs in the Program Files folder | (Default Rule) All DLLs located in the Program Files folder| Everyone | Path: %programfiles%\*| 
+| Allow all users to run DLLs in the Program Files folder | (Default Rule) All DLLs 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
 
 > [!CAUTION]
-> 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.
+> 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 on computers that are resource constrained.
- 
+
-## Related topics
+## Related articles
 
 - [Understanding AppLocker default rules](understanding-applocker-default-rules.md)

windows/security/application-security/application-control/windows-defender-application-control/applocker/executable-rules-in-applocker.md

@@ -1,26 +1,23 @@
 ---
 title: Executable rules in AppLocker
-description: This topic describes the file formats and available default rules for the executable rule collection.
+description: This article describes the file formats and available default rules for the executable rule collection.
 ms.localizationpriority: medium
 ms.topic: conceptual
-ms.date: 09/21/2017
+ms.date: 12/23/2023
 ---
 
 # Executable rules in AppLocker
 
->[!NOTE]
+This article describes the file formats and available default rules for the executable rule collection.
->Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
 
-This topic describes the file formats and available default rules for the executable rule collection.
+AppLocker executable rules conceptually apply to files with the .exe and .com extensions that are associated with an app. However, AppLocker executable rules actually apply to any portable executable (PE) file, regardless of the file's extension. Because all of the default rules for the executable rule collection are based on folder paths, all files under those paths can run. The following table lists the default rules that are available 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.
 
 | Purpose | Name | User | Rule condition type |
-| - | - | - | - |
+| --- | --- | --- | --- |
-| Allow members of the local Administrators group access to run all executable files | (Default Rule) All files| BUILTIN\Administrators | Path: * |
+| Allow members of the local Administrators group access to run all executable files | (Default Rule) All files | BUILTIN\Administrators | Path: * |
-| Allow all users to run executable files in the Windows folder| (Default Rule) All files located in the Windows folder| Everyone| Path: %windir%\*| 
+| Allow all users to run executable files in the Windows folder| (Default Rule) All files located in the Windows folder | Everyone| Path: %windir%\* |
-| Allow all users to run executable files in the Program Files folder | (Default Rule) All files located in the Program Files folder| Everyone | Path: %programfiles%\*| 
+| Allow all users to run executable files in the Program Files folder | (Default Rule) All files located in the Program Files folder| Everyone | Path: %programfiles%\* |
- 
+
-## Related topics
+## Related articles
 
 - [Understanding AppLocker Default Rules](understanding-applocker-default-rules.md)

windows/security/application-security/application-control/windows-defender-application-control/applocker/how-applocker-works-techref.md

@@ -1,45 +1,42 @@
 ---
 title: How AppLocker works
-description: This topic for the IT professional provides links to topics about AppLocker architecture and components, processes and interactions, rules and policies.
+description: This article for the IT professional provides links to articles about AppLocker architecture and components, processes and interactions, rules and policies.
 ms.localizationpriority: medium
 ms.topic: conceptual
-ms.date: 09/21/2017
+ms.date: 12/23/2023
 ---
 
 # How AppLocker works
 
->[!NOTE]
+This article for the IT professional provides links to articles about AppLocker architecture and components, processes and interactions, rules and policies.
->Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
 
-This topic for the IT professional provides links to topics about AppLocker architecture and components, processes and interactions, rules and policies.
+The following articles explain how AppLocker policies for each of the rule condition types are evaluated:
 
-The following topics explain how AppLocker policies for each of the rule condition types are evaluated:
+- [AppLocker architecture and components](applocker-architecture-and-components.md)
+- [AppLocker processes and interactions](applocker-processes-and-interactions.md)
 
--   [AppLocker architecture and components](applocker-architecture-and-components.md)
+The following articles explain how AppLocker rules and policies work:
--   [AppLocker processes and interactions](applocker-processes-and-interactions.md)
 
-The following topics explain how AppLocker rules and policies work:
+- [Understanding AppLocker rule behavior](understanding-applocker-rule-behavior.md)
+- [Understanding AppLocker rule exceptions](understanding-applocker-rule-exceptions.md)
+- [Understanding AppLocker rule collections](understanding-applocker-rule-collections.md)
+- [Understanding AppLocker allow and deny actions on rules](understanding-applocker-allow-and-deny-actions-on-rules.md)
+- [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md)
 
--   [Understanding AppLocker rule behavior](understanding-applocker-rule-behavior.md)
+  - [Understanding the publisher rule condition in AppLocker](understanding-the-publisher-rule-condition-in-applocker.md)
--   [Understanding AppLocker rule exceptions](understanding-applocker-rule-exceptions.md)
+  - [Understanding the path rule condition in AppLocker](understanding-the-path-rule-condition-in-applocker.md)
--   [Understanding AppLocker rule collections](understanding-applocker-rule-collections.md)
+  - [Understanding the file hash rule condition in AppLocker](understanding-the-file-hash-rule-condition-in-applocker.md)
--   [Understanding AppLocker allow and deny actions on rules](understanding-applocker-allow-and-deny-actions-on-rules.md)
--   [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md)
 
-    -   [Understanding the publisher rule condition in AppLocker](understanding-the-publisher-rule-condition-in-applocker.md)
+- [Understanding AppLocker default rules](understanding-applocker-default-rules.md)
-    -   [Understanding the path rule condition in AppLocker](understanding-the-path-rule-condition-in-applocker.md)
-    -   [Understanding the file hash rule condition in AppLocker](understanding-the-file-hash-rule-condition-in-applocker.md)
 
--   [Understanding AppLocker default rules](understanding-applocker-default-rules.md)
+  - [Executable rules in AppLocker](executable-rules-in-applocker.md)
+  - [Windows Installer rules in AppLocker](windows-installer-rules-in-applocker.md)
+  - [Script rules in AppLocker](script-rules-in-applocker.md)
+  - [DLL rules in AppLocker](dll-rules-in-applocker.md)
+  - [Packaged apps and packaged app installer rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md)
 
-    -   [Executable rules in AppLocker](executable-rules-in-applocker.md)
+## More resources
-    -   [Windows Installer rules in AppLocker](windows-installer-rules-in-applocker.md)
-    -   [Script rules in AppLocker](script-rules-in-applocker.md)
-    -   [DLL rules in AppLocker](dll-rules-in-applocker.md)
-    -   [Packaged apps and packaged app installer rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md)
 
-## Additional resources
+- [AppLocker Design Guide](applocker-policies-design-guide.md)
-
+- [AppLocker deployment guide](applocker-policies-deployment-guide.md)
--   [AppLocker Design Guide](applocker-policies-design-guide.md)
+- [Administer AppLocker](administer-applocker.md)
--   [AppLocker deployment guide](applocker-policies-deployment-guide.md)
--   [Administer AppLocker](administer-applocker.md)

windows/security/application-security/application-control/windows-defender-application-control/applocker/packaged-apps-and-packaged-app-installer-rules-in-applocker.md

@@ -1,30 +1,26 @@
 ---
 title: Packaged apps and packaged app installer rules in AppLocker
-description: This topic explains the AppLocker rule collection for packaged app installers and packaged apps.
+description: This article explains the AppLocker rule collection for packaged app installers and packaged apps.
 ms.localizationpriority: medium
 ms.topic: conceptual
-ms.date: 10/13/2017
+ms.date: 12/23/2023
 ---
 
 # Packaged apps and packaged app installer rules in AppLocker
 
->[!NOTE]
+This article explains the AppLocker rule collection for packaged app installers and packaged apps.
->Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
 
-This topic explains the AppLocker rule collection for packaged app installers and packaged apps.
+Packaged apps can be installed through the Microsoft Store or can be sideloaded using the Windows PowerShell cmdlets. Standard users can install packaged apps 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, those components often don't 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 Packaged app share the same attributes: Publisher name, Package name and Package version. It's therefore possible to control an entire app with a single rule.
 
-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.
+AppLocker enforces rules for Packaged apps separately from Classic Windows applications. A single AppLocker rule for a Packaged app can control both the installation and the running of an app. Because all Packaged apps are signed, AppLocker supports only publisher rules for Packaged apps. A publisher rule for a Packaged app is based on the following attributes of the app:
-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's 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
 
--   Publisher name
+In summary, including AppLocker rules for Packaged apps in your policy design provides:
--   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 control the installation and running of the app
+- The ability to create application control policies that survive app updates.
--   The ability to control all the components of the app with a single rule rather than controlling individual binaries within the app
+- Management of Packaged apps through Group Policy.
--   The ability to create application control policies that survive app updates
--   Management of Universal Windows apps through Group Policy.

windows/security/application-security/application-control/windows-defender-application-control/applocker/rule-collection-extensions.md

@@ -6,12 +6,12 @@ ms.collection:
 - must-keep
 ms.topic: conceptual
 ms.localizationpriority: medium
-ms.date: 12/19/2023
+ms.date: 12/23/2023
 ---
 
 # AppLocker rule collection extensions
 
-This article describes the rule collection extensions added in Windows 10 or later. Rule collection extensions are optional features available only for the EXE and DLL rule collections. Configure rule collection extensions by directly editing your AppLocker policy XML as shown in the following XML fragment.
+This article describes the rule collection extensions added in Windows 10 and later. Rule collection extensions are optional features available only for the EXE and DLL rule collections. Configure rule collection extensions by directly editing your AppLocker policy XML as shown in the following XML fragment.
 
 ```xml
 <RuleCollectionExtensions>

windows/security/application-security/application-control/windows-defender-application-control/applocker/script-rules-in-applocker.md

@@ -3,7 +3,7 @@ title: Script rules in AppLocker
 description: This article describes the file formats and available default rules for the script rule collection.
 ms.localizationpriority: medium
 ms.topic: conceptual
-ms.date: 06/15/2022
+ms.date: 12/23/2023
 ---
 
 # Script rules in AppLocker
@@ -20,10 +20,10 @@ AppLocker defines script rules to include only the following file formats:
 The following table lists the default rules that are available for the script rule collection.
 
 | Purpose | Name | User | Rule condition type |
-| - | - | - | - |
+| --- | --- | --- | --- |
 | Allows members of the local Administrators group to run all scripts| (Default Rule) All scripts| BUILTIN\Administrators | Path: `*\` |
-| Allow all users to run scripts in the Windows folder| (Default Rule) All scripts located in the Windows folder| Everyone | Path: `%windir%\*` |
+| Allow all users to run scripts in the Windows folder | (Default Rule) All scripts located in the Windows folder | Everyone | Path: `%windir%\*` |
-| Allow all users to run scripts in the Program Files folder| (Default Rule) All scripts located in the Program Files folder|Everyone | Path: `%programfiles%\*`|
+| Allow all users to run scripts in the Program Files folder| (Default Rule) All scripts located in the Program Files folder | Everyone | Path: `%programfiles%\*`|
 
 > [!NOTE]
 > When a script runs that is not allowed by policy, AppLocker raises an event indicating that the script was "blocked". However, the actual script enforcement behavior is handled by the script host. In the case of PowerShell, "blocked" scripts will still run, but only in [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). Authorized scripts run in Full Language Mode.

windows/security/application-security/application-control/windows-defender-application-control/applocker/security-considerations-for-applocker.md

@@ -1,47 +1,39 @@
 ---
 title: Security considerations for AppLocker
-description: This topic for the IT professional describes the security considerations you need to address when implementing AppLocker.
+description: This article for the IT professional describes the security considerations you need to address when implementing AppLocker.
 ms.localizationpriority: medium
 ms.topic: conceptual
-ms.date: 09/21/2017
+ms.date: 12/23/2023
 ---
 
 # Security considerations for AppLocker
 
->[!NOTE]
+This article for the IT professional describes the security considerations you need to address when implementing AppLocker.
->Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
 
-This topic for the IT professional describes the security considerations you need to address when implementing AppLocker.
+AppLocker helps restrict access to software for specific users or groups of users. The following are security considerations for 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 resources in IT with trusted credentials. This system 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 isn't in a GPO will still be evaluated for that computer.
+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 mode settings from AppLocker policies distributed through Group Policy Objects (GPO) take precedence over local policies. However, because AppLocker rules are additive, a local policy's rules are merged with rules from any GPOs applied to the computer.
 
 Microsoft doesn't provide a way to develop any extensions to AppLocker. The interfaces aren't 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](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ee460962(v=technet.10)).
 
-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 isn't in a GPO will still be evaluated for that computer. If the local computer isn't joined to a domain and isn't administered by Group Policy, a person with administrative credentials can alter the AppLocker policy.
+AppLocker runs in the context of Administrator or LocalSystem, which is the highest privilege set. This security context has the potential of misuse. Because AppLocker rules are additive, any local policy rules are applied to that computer along with any GPOs. If the local computer isn't joined to a domain or controlled by Group Policy, a person with administrative credentials can fully control the AppLocker policy.
 
-When files are being secured in a directory with a rule of the path condition type, whether using the allow or deny action on the rule, it's still necessary and good practice to restrict access to those files by setting the access control lists (ACLs) according to your security policy.
+AppLocker path rules don't replace access control lists (ACLs). You should continue to use ACLs to restrict access to files according to your security policy.
 
-AppLocker doesn't 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's 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's a requirement to prevent 16-bit applications from running, you must configure the Deny rule in the executable rule collection for NTVDM.exe.
+You can't use AppLocker to prevent code from running outside the Win32 subsystem. For example, it can't control code running in the Windows Subsystem for Linux. If it's a requirement to prevent applications from running in the Linux subsystem, you must disable the subsystem. Or, you can block the Windows Subsystem for Linux by blocking LxssManager.dll.
-
-You can't use AppLocker (or Software Restriction Policies) to prevent code from running outside the Win32 subsystem. In particular, this rule applies to the (POSIX) subsystem in Windows NT. If it's 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 doesn't 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 can't 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 doesn't control the behavior of applications after they're 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.
+AppLocker rules either allow or block application file from running. AppLocker doesn't control the behavior of applications after they're 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 allowed application 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 articles
- 
-## Related topics
 
 - [AppLocker technical reference](applocker-technical-reference.md)

windows/security/application-security/application-control/windows-defender-application-control/applocker/understanding-applocker-allow-and-deny-actions-on-rules.md

@@ -1,36 +1,28 @@
 ---
 title: Understanding AppLocker allow and deny actions on rules
-description: This topic explains the differences between allow and deny actions on AppLocker rules.
+description: This article explains the differences between allow and deny actions on AppLocker rules.
 ms.localizationpriority: medium
 ms.topic: conceptual
-ms.date: 09/21/2017
+ms.date: 12/23/2023
 ---
 
 # Understanding AppLocker allow and deny actions on rules
 
->[!NOTE]
+This article explains the differences between allow and deny actions on AppLocker rules.
->Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
-
-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.
+Each AppLocker rule collection functions as an explicit allowlist of files. You can only run files that are covered by one or more allow rules within the rule collection. You can also create rules that explicitly deny some files from running. All other files not covered by an explicit Allow or Deny rule are *implicitly* blocked from running. Understanding this **block by default, allow by exception** behavior is critical when analyzing how your policy affects users in your organization.
 
-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.
+When AppLocker applies rules, it first checks whether any explicit deny actions are specified in the rule list. If you deny a file from running in a rule collection, the deny action takes precedence over any allow action and can't be overridden. Then, AppLocker checks for any explicit allow actions for the file. Because AppLocker functions as an allowlist by default, if no rule explicitly allows or denies a file from running, AppLocker's default deny action blocks the file.
 
-### Deny rule considerations
+### Using AppLocker to implement a blocklist
 
-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.
+Although you can use AppLocker to create an explicit blocklist policy, this approach doesn't scale well for most organizations and isn't recommended as a practical application control strategy. However, if you choose to do so, be sure to include an "allow \*" rule within the rule collection so that all other files run.
 
-| Rule condition | Security concern with deny action |
+> [!IMPORTANT]
-| - | - |
+> If you don't include allow rules for all required apps, including Windows system files, within a rule collection, you will cause unexpected results because your policy will *implicitly* deny all other files on the computer from running.
-| 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.|
+## Related articles
-| Path | A user could move the denied file to a different location and run it from there.|
- 
->**Important:**  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](how-applocker-works-techref.md)

windows/security/application-security/application-control/windows-defender-application-control/applocker/understanding-applocker-default-rules.md

@@ -1,43 +1,39 @@
 ---
 title: Understanding AppLocker default rules
-description: 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.
+description: This article for IT professional describes the set of rules that can be used to ensure that required Windows system files continue to run when the policy is applied.
 ms.localizationpriority: medium
 ms.topic: conceptual
-ms.date: 09/21/2017
+ms.date: 12/23/2023
 ---
 
 # Understanding AppLocker default rules
 
->[!NOTE]
+This article for IT professional describes the set of rules that can be used to ensure that required Windows system files continue to run when the policy is applied.
->Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
 
-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.
+The AppLocker wizard 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.
-
-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.
 
 > [!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
+If you require extra 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:
--   Create Files/Write Data
+
--   Create Folders/Append Data
+- 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
 
-| Topic | Description |
+| Article | Description |
-| - | - |
+| --- | --- |
-| [Executable rules in AppLocker](executable-rules-in-applocker.md) | This topic describes the file formats and available default rules for the executable rule collection. |
+| [Executable rules in AppLocker](executable-rules-in-applocker.md) | This article describes the file formats and available default rules for the executable rule collection. |
-| [Windows Installer rules in AppLocker](windows-installer-rules-in-applocker.md) | This topic describes the file formats and available default rules for the Windows Installer rule collection.|
+| [Windows Installer rules in AppLocker](windows-installer-rules-in-applocker.md) | This article describes the file formats and available default rules for the Windows Installer rule collection.|
-| [Script rules in AppLocker](script-rules-in-applocker.md) | This topic describes the file formats and available default rules for the script rule collection.| 
+| [Script rules in AppLocker](script-rules-in-applocker.md) | This article describes the file formats and available default rules for the script rule collection.| 
-| [DLL rules in AppLocker](dll-rules-in-applocker.md) | This topic describes the file formats and available default rules for the DLL rule collection.| 
+| [DLL rules in AppLocker](dll-rules-in-applocker.md) | This article describes the file formats and available default rules for the DLL rule collection.| 
-| [Packaged apps and packaged app installer rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md) | This topic explains the AppLocker rule collection for packaged app installers and packaged apps.| 
+| [Packaged apps and packaged app installer rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md) | This article explains the AppLocker rule collection for packaged app installers and packaged apps.| 
- 
+
-## Related topics
+## Related articles
 
 - [How AppLocker works](how-applocker-works-techref.md)
 - [Create AppLocker default rules](create-applocker-default-rules.md)

windows/security/application-security/application-control/windows-defender-application-control/applocker/understanding-applocker-rule-behavior.md

@@ -1,27 +1,25 @@
 ---
 title: Understanding AppLocker rule behavior
-description: This topic describes how AppLocker rules are enforced by using the allow and deny options in AppLocker.
+description: This article describes how AppLocker rules are enforced by using the allow and deny options in AppLocker.
 ms.localizationpriority: medium
 ms.topic: conceptual
-ms.date: 09/21/2017
+ms.date: 12/23/2023
 ---
 
 # Understanding AppLocker rule behavior
 
->[!NOTE]
+This article describes how AppLocker rules are enforced by using the allow and deny options in AppLocker.
->Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
 
-This topic describes how AppLocker rules are enforced by using the allow and deny options in AppLocker.
+If no AppLocker rules exist for a specific rule collection, all files covered by that rule collection are allowed to run. However, once an AppLocker rule for a specific rule collection is created, only the files explicitly allowed by at least one 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. Executable files run from any other path are blocked.
-
-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.
+- **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 aren't 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 aren't 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.
 
->**Important:**  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.
+> [!IMPORTANT]
- 
+> 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.
-## Related topics
+
+## Related articles
 
 - [How AppLocker works](how-applocker-works-techref.md)

windows/security/application-security/application-control/windows-defender-application-control/applocker/understanding-applocker-rule-collections.md

@@ -1,33 +1,33 @@
 ---
 title: Understanding AppLocker rule collections
-description: This topic explains the five different types of AppLocker rules used to enforce AppLocker policies.
+description: This article explains the five different types of AppLocker rule collections used to enforce AppLocker policies.
 ms.localizationpriority: medium
 ms.topic: conceptual
-ms.date: 09/21/2017
+ms.date: 12/23/2023
 ---
 
 # Understanding AppLocker rule collections
 
->[!NOTE]
+This article explains the five different types of AppLocker rule collections used to enforce AppLocker policies.
->Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
-
-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
+- Executable files: .exe and .com
--   Windows Installer files: .msi, mst, and .msp
+- Windows Installer files: .msi, mst, and .msp
--   Scripts: .ps1, .bat, .cmd, .vbs, and .js
+- Scripts: .ps1, .bat, .cmd, .vbs, and .js
--   DLLs: .dll and .ocx
+- DLLs: .dll and .ocx
--   Packaged apps and packaged app installers: .appx
+- 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.
+> [!IMPORTANT]
+> Each app can load several DLLs, and AppLocker must check each DLL before it is allowed to run. Be sure you create DLL allow rules for every DLL that is used by any of the allowed apps. Denying some DLLs from running can also create app compatibility problems.
+>
+> DLL rules might cause performance problems on some computers which are already resource constrained.
+>
+> As a result, the DLL rule collection is not enabled by default.
 
->**Important:**  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](enable-the-dll-rule-collection.md).
 
-## Related topics
+## Related articles
 
 - [How AppLocker works](how-applocker-works-techref.md)
 - [Understanding AppLocker default rules](understanding-applocker-default-rules.md)

windows/security/application-security/application-control/windows-defender-application-control/applocker/understanding-applocker-rule-condition-types.md

@@ -1,55 +1,46 @@
 ---
 title: Understanding AppLocker rule condition types
-description: This topic for the IT professional describes the three types of AppLocker rule conditions.
+description: This article for the IT professional describes the three types of AppLocker rule conditions.
 ms.localizationpriority: medium
 ms.topic: conceptual
-ms.date: 09/21/2017
+ms.date: 12/23/2023
 ---
 
 # Understanding AppLocker rule condition types
 
->[!NOTE]
+This article for the IT professional describes the three types of AppLocker rule conditions.
->Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
-
-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**
+## 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](understanding-the-publisher-rule-condition-in-applocker.md).
+To use a publisher condition, the software publisher must digitally sign their app files, 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](understanding-the-publisher-rule-condition-in-applocker.md).
 
-**Path**
+## 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](understanding-the-path-rule-condition-in-applocker.md).
+Any file can be assigned this rule condition. However, because path rules specify locations within the file system, the rule also affects any subdirectories unless explicitly exempted. For more info about this rule condition, see [Understanding the path rule condition in AppLocker](understanding-the-path-rule-condition-in-applocker.md).
 
-**File hash**
+## 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](understanding-the-file-hash-rule-condition-in-applocker.md).
+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 Authenticode hash value is unique for each version of the file. For more info about this rule condition, see [Understanding the file hash rule condition in AppLocker](understanding-the-file-hash-rule-condition-in-applocker.md).
 
-### Considerations
+## 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?
+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:
+    If the software publisher signed the file, we recommend that you create rules with publisher conditions. You can still create file hash and path conditions for signed files. However, if the software publisher didn't sign the file, 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.
 
-    -   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, 
+        > 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.
-        `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?
-2.  What rule condition type does your organization prefer?
+
-    
+## Related articles
-    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](requirements-to-use-applocker.md).
-     
-## Related topics
 
 - [How AppLocker works](how-applocker-works-techref.md)

windows/security/application-security/application-control/windows-defender-application-control/applocker/understanding-applocker-rule-exceptions.md

@@ -1,24 +1,23 @@
 ---
 title: Understanding AppLocker rule exceptions
-description: This topic describes the result of applying AppLocker rule exceptions to rule collections.
+description: This article describes the result of applying AppLocker rule exceptions to rule collections.
 ms.localizationpriority: medium
 ms.topic: conceptual
-ms.date: 09/21/2017
+ms.date: 12/23/2023
 ---
 
 # Understanding AppLocker rule exceptions
 
->[!NOTE]
+<!-- This topic needs a full re-write. Despite the title and description, it doesn't actually describe how rule exceptions work. Instead, this simply explains how to use a separate rule to allow an app to run for a different set of users. That's a valid scenario but not really an "exception" -->
->Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
 
-This topic describes the result of applying AppLocker rule exceptions to rule collections.
+This article 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.
+You can apply AppLocker rules to individual users or a group of users. If you apply a rule to a group of users, the rule affects all users in that group. 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 doesn't allow anyone to run Registry Editor (by adding %WINDIR%\regedit.exe as a Path Exception for 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 doesn't 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.
+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 blocks Registry Editor for all users, the deny rule overrides the second rule that allows the Helpdesk user group to run Registry Editor.
 
-## Related topics
+## Related articles
 
 - [How AppLocker works](how-applocker-works-techref.md)

windows/security/application-security/application-control/windows-defender-application-control/applocker/understanding-the-file-hash-rule-condition-in-applocker.md

@@ -1,26 +1,23 @@
 ---
 title: Understanding the file hash rule condition in AppLocker
-description: This topic explains the AppLocker file hash rule condition, the advantages and disadvantages, and how it's applied.
+description: This article explains how to use the AppLocker file hash rule condition and its advantages and disadvantages.
 ms.localizationpriority: medium
 ms.topic: conceptual
-ms.date: 09/21/2017
+ms.date: 12/23/2023
 ---
 
 # Understanding the file hash rule condition in AppLocker
 
->[!NOTE]
+This article explains how to use the AppLocker file hash rule condition and its advantages and disadvantages.
->Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
 
-This topic explains the AppLocker file hash rule condition, the advantages and disadvantages, and how it's applied.
+File hash rules use a system-computed Authenticode cryptographic hash of the identified file. For files that aren't digitally signed, file hash rules are more secure than path rules. The following table describes the advantages and disadvantages of the file hash condition.
-
-File hash rules use a system-computed cryptographic hash of the identified file. For files that aren't digitally signed, file hash rules are more secure than path rules. The following table describes the advantages and disadvantages of the file hash condition.
 
 | File hash condition advantages | File hash condition disadvantages |
-| - | - |
+| --- | --- |
-| Because each file has a unique hash, a file hash condition applies to only one file. | Each time that 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.|
+| Because each file has a unique hash, a file hash condition applies to only one file. | Each time that the file is updated (such as a security update or upgrade), the file's Authenticode hash changes. As a result, you must manually update file hash rules. |
- 
-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](understanding-applocker-rule-condition-types.md).
 
-## Related topics
+For an overview of the three types of AppLocker rule conditions and their advantages and disadvantages of each, see [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md).
+
+## Related articles
 
 - [How AppLocker works](how-applocker-works-techref.md)

windows/security/application-security/application-control/windows-defender-application-control/applocker/understanding-the-path-rule-condition-in-applocker.md

@@ -1,29 +1,26 @@
 ---
 title: Understanding the path rule condition in AppLocker
-description: This topic explains the AppLocker path rule condition, the advantages and disadvantages, and how it's applied.
+description: This article explains how to apply the AppLocker path rule condition and its advantages and disadvantages.
 ms.localizationpriority: medium
 ms.topic: conceptual
-ms.date: 09/21/2017
+ms.date: 12/23/2023
 ---
 
 # Understanding the path rule condition in AppLocker
 
->[!NOTE]
+This article explains how to apply the AppLocker path rule condition and its advantages and disadvantages.
->Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
-
-This topic explains the AppLocker path rule condition, the advantages and disadvantages, and how it's 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.
+Path rules that use the deny action, are less effective than other types of rules, because a user (or malware acting as a user) can easily copy the file to a different location to run it. Because path rules specify locations within the file system, you should ensure that there are no subdirectories that are writable by nonadministrators. For example, if you create a path rule using the allow action for C:\\, any file under that location can run, including file within users' profiles. The following table describes the advantages and disadvantages of the path condition.
 
 |Path condition advantages|Path condition disadvantages|
-|--- |--- |
+| --- | --- |
-|<li>You can easily control many folders or a single file.<li>You can use the asterisk (*) as a wildcard character within path rules.|<li>It might be less secure if a rule that is configured to use a folder path contains subfolders that are writable by non-administrators.<li>You must specify the full path to a file or folder when creating path rules so that the rule will be properly enforced.|
+| <li> You can easily control many folders or a single file. <li> You can use the asterisk (*) as a wildcard character within path rules. | <li> It might be less secure if a rule that is configured to use a folder path contains subfolders that are writable by nonadministrators. <li> You must specify the full path to a file or folder when creating path rules so that the rule is properly enforced. |
 
-AppLocker doesn't 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.
+AppLocker doesn't 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 is 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.
+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 the rule affects all files and subfolders within the Internet Explorer folder.
 
 AppLocker uses path variables for well-known directories in Windows. Path variables aren't environment variables. The AppLocker engine can only interpret AppLocker path variables. The following table details these path variables.
 
@@ -36,8 +33,8 @@ AppLocker uses path variables for well-known directories in Windows. Path variab
 |        Removable media (for example, CD or DVD)         |       %REMOVABLE%       |                                        |
 | Removable storage device (for example, USB flash drive) |          %HOT%          |                                        |
 
-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](understanding-applocker-rule-condition-types.md).
+For an overview of the three types of AppLocker rule conditions and their advantages and disadvantages of each, see [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md).
 
-## Related topics
+## Related articles
 
 - [How AppLocker works](how-applocker-works-techref.md)

windows/security/application-security/application-control/windows-defender-application-control/applocker/understanding-the-publisher-rule-condition-in-applocker.md

@@ -1,63 +1,58 @@
 ---
 title: Understanding the publisher rule condition in AppLocker
-description: This topic explains the AppLocker publisher rule condition, what controls are available, and how it's applied.
+description: This article explains how to apply the AppLocker publisher rule condition and what controls are available.
 ms.localizationpriority: medium
 ms.topic: conceptual
-ms.date: 09/21/2017
+ms.date: 12/23/2023
 ---
 
 # Understanding the publisher rule condition in AppLocker
 
->[!NOTE]
+This article explains how to apply the AppLocker publisher rule condition and what controls are available.
->Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](/windows/security/threat-protection/windows-defender-application-control/feature-availability).
 
-This topic explains the AppLocker publisher rule condition, what controls are available, and how it's applied.
+Publisher conditions can be made only for files that are digitally signed. This condition identifies an app's file 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 can 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 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.
-
-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 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.
 
 |Publisher condition advantages|Publisher condition disadvantages|
-|--- |--- |
+| --- | --- |
-|<li>Frequent updating isn't required.<li>You can apply different values within a certificate.<li>A single rule can be used to allow an entire product suite.<li>You can use the asterisk (*) wildcard character within a publisher rule to specify that any value should be matched.|<li>The file must be signed.<li>Although a single rule can be used to allow an entire product suite, all files in the suite must be signed uniformly.|
+| <li> Frequent updating isn't required. <li> You can apply different values within a certificate. <li> A single rule can be used to allow an entire product suite. <li> You can use the asterisk (*) wildcard character within a publisher rule to specify that any value should be matched.| <li> The file must be signed. <li> Although a single rule can be used to allow an entire product suite, all files in the suite must be signed uniformly.|
- 
+
 Wildcard characters can be used as values in the publisher rule fields according to the following specifications:
 
--   **Publisher**
+- **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 isn't 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 (?) isn't a valid wildcard character in this field.
+    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 isn't 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 (?) isn't a valid wildcard character in this field.
 
--   **Product name**
+- **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 isn't treated as a wildcard character if used with other characters in this field. A question mark (?) isn't a valid wildcard character in this field.
 
--   **File name**
+- **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.
+    Either the asterisk (\*) or question mark (?) characters used by themselves represent any file names. When combined with any string value, the string is matched with any file name containing that string.
 
--   **File version**
+- **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
+  - **Exactly**. The rule applies only to this version of the app
-    -   **And above**. The rule applies to this version and all later versions.
+  - **And above**. The rule applies to this version and all later versions.
-    -   **And Below**. The rule applies to this version and all earlier versions.
+  - **And Below**. The rule applies to this version and all earlier versions.
 
 The following table describes how a publisher condition is applied.
 
 | Option | The publisher condition allows or denies...|
-| - | - |
+| --- | --- |
-| **All signed files** | All files that are signed by a publisher.| 
+| **All signed files** | All files signed by a publisher. |
-| **Publisher only** | All files that are signed by the named publisher.| 
+| **Publisher only** | All files 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** | All files for the specified product 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, and file name** | Any version of the named file for the named product and signed by the publisher. |
-| **Publisher, product name, file name, and file version** | **Exactly**<br/>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** | **Exactly** <br/> The specified version of the named file for the named product signed by the publisher. |
-| **Publisher, product name, file name, and file version** | **And above**<br/>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 above** <br/> The specified version of the named file and any later versions of the file for the named product signed by the publisher. |
-| **Publisher, product name, file name, and file version**| **And below**<br/>The specified version of the named file and any older versions for the product that are signed by the publisher.| 
+| **Publisher, product name, file name, and file version**| **And below** <br/> The specified version of the named file and any older versions for the named product signed by the publisher. |
-| **Custom** | You can edit the **Publisher**, **Product name**, **File name**, and **Version** fields to create a custom rule.| 
+| **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](understanding-applocker-rule-condition-types.md).
 
-## Related topics
+For an overview of the three types of AppLocker rule conditions and their advantages and disadvantages, see [Understanding AppLocker rule condition types](understanding-applocker-rule-condition-types.md).
+
+## Related articles
 
 - [How AppLocker works](how-applocker-works-techref.md)