Acro boost edits

windows/security/threat-protection/security-policy-settings/shut-down-the-system.md

@@ -28,9 +28,9 @@ Describes the best practices, location, values, policy management, and security
 
 This security setting determines if a user who is logged on locally to a device can shut down Windows.
 
-Shutting down domain controllers makes them unavailable to perform functions such as processing logon requests, processing Group Policy settings, and answering Lightweight Directory Access Protocol (LDAP) queries. Shutting down domain controllers that have been assigned operations master roles (also known as flexible single master operations or FSMO roles) can disable key domain functionality; for example, processing logon requests for new passwords, which is performed by the primary domain controller (PDC) emulator master.
+Shutting down domain controllers makes them unable to do things like process logon requests, process Group Policy settings, and answer Lightweight Directory Access Protocol (LDAP) queries. Shutting down domain controllers that have been assigned operations master roles, which are also known as flexible single master operations or FSMO roles, can disable key domain functionality. For example, processing logon requests for new passwords, which are done by the primary domain controller (PDC) emulator master.
 
-The **Shut down the system** user right is required to enable hibernation support, to set the power management settings, and to cancela shutdown.
+The **Shut down the system** user right is required to enable hibernation support, to set the power management settings, and to cancel a shutdown.
 
 Constant: SeShutdownPrivilege
 
@@ -42,8 +42,8 @@ Constant: SeShutdownPrivilege
 
 ### Best practices
 
-1.  Ensure that only Administrators and Backup Operators have the **Shut down the system** user right on member servers, and that only Administrators have the user right on domain controllers. Removing these default groups might limit the abilities of users who are assigned to specific administrative roles in your environment. Ensure that their delegated tasks will not be negatively affected.
-2.  The ability to shut down domain controllers should be limited to a very small number of trusted administrators. Even though a system shutdown requires the ability to log on to the server, you should be very careful about the accounts and groups that you allow to shut down a domain controller.
+1.  Ensure that only Administrators and Backup Operators have the **Shut down the system** user right on member servers. And that only Administrators have the user right on domain controllers. Removing these default groups might limit the abilities of users who are assigned to specific administrative roles in your environment. Ensure that their delegated tasks won't be negatively affected.
+2.  The ability to shut down domain controllers should be limited to a small number of trusted administrators. Even though a system shutdown requires the ability to log on to the server, you should be careful about the accounts and groups that you allow to shut down a domain controller.
 
 ### Location
 
@@ -91,20 +91,20 @@ This section describes how an attacker might exploit a feature or its configurat
 
 ### Vulnerability
 
-The ability to shut down domain controllers should be limited to a very small number of trusted administrators. Although the **Shut down the system** user right requires the ability to log on to the server, you should be very careful about which accounts and groups you allow to shut down a domain controller.
+The ability to shut down domain controllers should be limited to a very small number of trusted administrators. Although the **Shut down the system** user right requires the ability to log on to the server, you should be careful about which accounts and groups you allow to shut down a domain controller.
 
-When a domain controller is shut down, it is no longer available to process logon requests, process Group Policy settings, and answer Lightweight Directory Access Protocol (LDAP) queries. If you shut down domain controllers that possess operations master roles, you can disable key domain functionality, such as processing logon requests for new passwords, which is performed by the PDC master.
+When a domain controller is shut down, it can't process logon requests, process Group Policy settings, and answer Lightweight Directory Access Protocol (LDAP) queries. If you shut down domain controllers that have operations master roles, you can disable key domain functionality, such as processing logon requests for new passwords, which are performed by the PDC master.
 
-For other server roles, especially those where non-administrators have rights to log on to the server (such as RD Session Host servers), it is critical that this user right be removed from users that do not have a legitimate reason to restart the servers.
+For other server roles, especially roles where non-administrators have rights to log on to the server, such as RD Session Host servers, it's critical that this user right be removed from users who don't have a legitimate reason to restart the servers.
 
 ### Countermeasure
 
-Ensure that only the Administrators and Backup Operators groups are assigned the **Shut down the system** user right on member servers, and ensure that only the Administrators group is assigned the user right on domain controllers.
+Make sure that only the Administrators and Backup Operators groups are assigned the **Shut down the system** user right on member servers. And make sure that only the Administrators group is assigned the user right on domain controllers.
 
 ### Potential impact
 
-The impact of removing these default groups from the **Shut down the system** user right could limit the delegated abilities of assigned roles in your environment. You should confirm that delegated activities are not adversely affected.
+The impact of removing these default groups from the **Shut down the system** user right could limit the delegated abilities of assigned roles in your environment. Confirm that delegated activities aren't adversely affected.
 
-## Related topics
+## Related articles
 
 - [User Rights Assignment](user-rights-assignment.md)

windows/security/threat-protection/security-policy-settings/system-objects-require-case-insensitivity-for-non-windows-subsystems.md

@@ -22,7 +22,7 @@ ms.date: 04/19/2017
 **Applies to**
 -   Windows 10
 
-Describes the best practices, location, values, policy management and security considerations for the **System objects: Require case insensitivity for non-Windows subsystems** security policy setting.
+Describes the best practices, location, values, policy management, and security considerations for the **System objects: Require case insensitivity for non-Windows subsystems** security policy setting.
 
 ## Reference
 

windows/security/threat-protection/security-policy-settings/system-objects-strengthen-default-permissions-of-internal-system-objects.md

@@ -1,5 +1,5 @@
 ---
-title: System objects Strengthen default permissions of internal system objects (e.g. Symbolic Links) (Windows 10)
+title: System objects Strengthen default permissions of internal system objects (e.g., Symbolic Links) (Windows 10)
 description: Best practices and more for the security policy setting, System objects Strengthen default permissions of internal system objects (e.g. Symbolic Links).
 ms.assetid: 3a592097-9cf5-4fd0-a504-7cbfab050bb6
 ms.reviewer: 
@@ -17,7 +17,7 @@ ms.topic: conceptual
 ms.date: 04/19/2017
 ---
 
-# System objects: Strengthen default permissions of internal system objects (e.g. Symbolic Links)
+# System objects: Strengthen default permissions of internal system objects (for example Symbolic Links)
 
 **Applies to**
 -   Windows 10

windows/security/threat-protection/security-policy-settings/system-settings-optional-subsystems.md

@@ -1,6 +1,6 @@
 ---
 title: System settings Optional subsystems (Windows 10)
-description: Describes the best practices, location, values, policy management and security considerations for the System settings Optional subsystems security policy setting.
+description: Describes the best practices, location, values, policy management, and security considerations for the System settings Optional subsystems security policy setting.
 ms.assetid: 5cb6519a-4f84-4b45-8072-e2aa8a72fb78
 ms.reviewer: 
 ms.author: dansimp
@@ -22,7 +22,7 @@ ms.date: 04/19/2017
 **Applies to**
 -   Windows 10
 
-Describes the best practices, location, values, policy management and security considerations for the **System settings: Optional subsystems** security policy setting.
+Describes the best practices, location, values, policy management, and security considerations for the **System settings: Optional subsystems** security policy setting.
 
 ## Reference
 

windows/security/threat-protection/security-policy-settings/user-account-control-allow-uiaccess-applications-to-prompt-for-elevation-without-using-the-secure-desktop.md

@@ -26,17 +26,17 @@ Describes the best practices, location, values, and security considerations for
 
 ## Reference
 
-This security setting controls whether User Interface Accessibility (UIAccess or UIA) programs can automatically disable the secure desktop for elevation prompts that are used by a standard user.
+This security setting controls whether User Interface Accessibility (UIAccess or UIA) programs can automatically disable the secure desktop for elevation prompts used by a standard user.
 
 >**Note:**  This setting does not change the behavior of the UAC elevation prompt for administrators.
  
 **Background**
 
-User Interface Privilege Isolation (UIPI) implements restrictions in the Windows subsystem that prevent lower-privilege applications from sending messages or installing hooks in higher-privilege processes. Higher-privilege applications are permitted to send messages to lower-privilege processes. UIPI does not interfere with or change the behavior of messages between applications at the same privilege (or integrity) level.
+User Interface Privilege Isolation (UIPI) implements restrictions in the Windows subsystem that prevent lower-privilege applications from sending messages or installing hooks in higher-privilege processes. Higher-privilege applications are permitted to send messages to lower-privilege processes. UIPI doesn't interfere with or change the behavior of messages between applications at the same privilege (or integrity) level.
 
-Microsoft UI Automation is the current model to support accessibility requirements in the Windows operating systems. Applications that are designed to support an accessible user experience control the behavior of other Windows applications on behalf of the user. When all applications on the automation client computer and server are running as a standard user (that is, at a medium integrity level), the UIPI restrictions do not interfere with the Microsoft UI automation model.
+Microsoft UI Automation is the current model to support accessibility requirements in the Windows operating systems. Applications that support an accessible user experience control the behavior of other Windows applications for the user. When all applications on the automation client computer and server are running as a standard user (that is, at a medium integrity level), the UIPI restrictions don't interfere with the Microsoft UI automation model.
 
-However, there might be times when an administrative user runs an application with elevated privilege based on UAC in Admin Approval Mode. Microsoft UI Automation cannot drive the UI graphics of elevated applications on the desktop without the ability to bypass the restrictions that UIPI implements. The ability to bypass UIPI restrictions across privilege levels is available for UI automation programs by using UIAccess.
+However, there might be times when an administrative user runs an application with elevated privilege based on UAC in Admin Approval Mode. Microsoft UI Automation can't drive the UI graphics of elevated applications on the desktop without the ability to bypass the restrictions that UIPI implements. The ability to bypass UIPI restrictions across privilege levels is available for UI automation programs by using UIAccess.
 
 If an application presents a UIAccess attribute when it requests privileges, the application is stating a requirement to bypass UIPI restrictions for sending messages across privilege levels. Devices implement the following policy 
 checks before starting an application with UIAccess privilege.
@@ -120,7 +120,7 @@ Disable the **User Account Control: Allow UIAccess applications to prompt for el
 
 ### Potential impact
 
-If a user requests remote assistance from an administrator and the remote assistance session is established, elevation prompts appear on the interactive user's secure desktop and the administrator's remote session is paused. To avoid pausing the remote administrator’s session during elevation requests, the user can select the "Allow IT Expert to respond to User Account Control prompts" check box when setting up the remote assistance session. However, selecting this check box requires that the interactive user respond to an elevation prompt on the secure desktop. If the interactive user is a standard user, the user does not have the required credentials to allow elevation.
+If a user requests remote assistance from an administrator and the remote assistance session is established, elevation prompts appear on the interactive user's secure desktop and the administrator's remote session is paused. To avoid pausing the remote administrator’s session during elevation requests, the user can select the "Allow IT Expert to respond to User Account Control prompts" check box when setting up the remote assistance session. But selecting this check box requires the interactive user to respond to an elevation prompt on the secure desktop. If the interactive user is a standard user, the user doesn't have the required credentials to allow elevation.
 
 ## Related topics
 

windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-executables-that-are-signed-and-validated.md

@@ -22,7 +22,7 @@ ms.date: 04/19/2017
 **Applies to**
 -   Windows 10
 
-Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Only elevate executables that are signed and validated** security policy setting.
+Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Only elevate executables that are signed and validated** security policy setting.
 
 ## Reference
 
@@ -82,7 +82,7 @@ This section describes how an attacker might exploit a feature or its configurat
 
 ### Vulnerability
 
-Intellectual property, personally identifiable information, and other confidential data are normally manipulated by applications on the computer, and elevated credentials are required to access the information. Users and administrators inherently trust applications that are used with these information sources, and they provide their credentials. If one of these applications is replaced by a rogue application that appears identical to the trusted application, the confidential data could be compromised and the user's administrative credentials would also be compromised.
+Intellectual property, personal information, and other confidential data are normally manipulated by applications on the computer, and elevated credentials are required to access the information. Users and administrators inherently trust applications that are used with these information sources, and they provide their credentials. If one of these applications is replaced by a rogue application that appears identical to the trusted application, the confidential data could be compromised and the user's administrative credentials would also be compromised.
 
 ### Countermeasure
 

windows/security/threat-protection/security-policy-settings/user-account-control-only-elevate-uiaccess-applications-that-are-installed-in-secure-locations.md

@@ -22,11 +22,11 @@ ms.date: 04/19/2017
 **Applies to**
 -   Windows 10
 
-Describes the best practices, location, values, policy management and security considerations for the **User Account Control: Only elevate UIAccess applications that are installed in secure locations** security policy setting.
+Describes the best practices, location, values, policy management, and security considerations for the **User Account Control: Only elevate UIAccess applications that are installed in secure locations** security policy setting.
 
 ## Reference
 
-This policy setting enforces the requirement that apps that request running with a UIAccess integrity level (by means of a marking of UIAccess=true in their app manifest), must reside in a secure location on the file system. Relatively secure locations are limited to the following directories:
+This policy setting enforces the requirement that apps that request running with a UIAccess integrity level by marking *UIAccess=true* in their app manifest must reside in a secure location on the file system. Relatively secure locations are limited to the following directories:
 
 -   \\Program Files\\ including subdirectories
 -   \\Windows\\system32\\
@@ -36,11 +36,11 @@ This policy setting enforces the requirement that apps that request running with
  
 **Background**
 
-User Interface Privilege Isolation (UIPI) implements restrictions in the Windows subsystem that prevent lower-privilege applications from sending messages or installing hooks in higher-privilege processes. Higher-privilege applications are permitted to send messages to lower-privilege processes. UIPI does not interfere with or change the behavior of messages between applications at the same privilege (or integrity) level.
+User Interface Privilege Isolation (UIPI) implements restrictions in the Windows subsystem that prevent lower-privilege applications from sending messages or installing hooks in higher-privilege processes. Higher-privilege applications are permitted to send messages to lower-privilege processes. UIPI doesn't interfere with or change the behavior of messages between applications at the same privilege (or integrity) level.
 
-Microsoft UI Automation is the current model to support accessibility requirements in the Windows operating systems. Applications that are designed to support an accessible user experience control the behavior of other Windows applications on behalf of the user. When all applications on the automation client computer and server are running as a standard user (that is, at a medium integrity level), the UIPI restrictions do not interfere with the Microsoft UI automation model.
+Microsoft UI Automation is the current model to support accessibility requirements in the Windows operating systems. Applications that are designed to support an accessible user experience control the behavior of other Windows applications for the user. When all applications on the automation client computer and server are running as a standard user (that is, at a medium integrity level), the UIPI restrictions don't interfere with the Microsoft UI automation model.
 
-However, there might be times when an administrative user runs an application with elevated privilege based on UAC in Admin Approval Mode. Microsoft UI Automation cannot drive the UI graphics of elevated applications on the desktop without the ability to bypass the restrictions that UIPI implements. The ability to bypass UIPI restrictions across privilege levels is available for UI automation programs by using UIAccess.
+However, there might be times when an administrative user runs an application with elevated privilege based on UAC in Admin Approval Mode. Microsoft UI Automation can't drive the UI graphics of elevated applications on the desktop without the ability to bypass the restrictions that UIPI implements. The ability to bypass UIPI restrictions across privilege levels is available for UI automation programs by using UIAccess.
 
 If an application presents a UIAccess attribute when it requests privileges, the application is stating a requirement to bypass UIPI restrictions for sending messages across privilege levels. Devices implement the following policy checks before starting an application with UIAccess privilege.
 
@@ -87,7 +87,7 @@ This section describes features and tools that are available to help you manage
 
 ### Restart requirement
 
-None. Changes to this policy become effective without a device restart when they aresaved locally or distributed through Group Policy.
+None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy.
 
 ### Group Policy
 
@@ -95,11 +95,14 @@ All auditing capabilities are integrated in Group Policy. You can configure, dep
 
 ## Security considerations
 
-This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation.
+This section describes:
+- How an attacker might exploit a feature or its configuration.
+- How to implement the countermeasure.
+- The possible negative consequences of countermeasure implementation.
 
 ### Vulnerability
 
-UIAccess integrity allows an application to bypass User Interface Privilege Isolation (UIPI) restrictions when an application is elevated in privilege from a standard user to an administrator. When this setting is enabled, an application that has the UIAccess flag set to true in its manifest can interchange information with applications that are running at a higher privilege level, such as logon prompts and privilege elevation prompts. This ability is required to support accessibility features such as screen readers that are transmitting user interfaces to alternative forms, but it is not required by most applications. A process that is started with UIAccess rights has the following abilities:
+UIAccess integrity allows an application to bypass User Interface Privilege Isolation (UIPI) restrictions when an application is elevated in privilege from a standard user to an administrator. When this setting is enabled, an application that has the UIAccess flag set to true in its manifest can interchange information with applications that are running at a higher privilege level, such as logon prompts and privilege elevation prompts. This ability is required to support accessibility features such as screen readers that transmit user interfaces to alternative forms. But it is not required by most applications. A process that's started with UIAccess rights has the following abilities:
 
 -   Set the foreground window.
 -   Drive any application window by using the SendInput function.
@@ -113,8 +116,8 @@ Enable the **User Account Control: Only elevate UIAccess applications that are i
 
 ### Potential impact
 
-If the application that requests UIAccess meets the UIAccess setting requirements, computers running at least the Windows Vista operating system start the application with the ability to bypass most of the UIPI restrictions. If the application does not meet the security restrictions, the application is started without UIAccess rights, and it can interact only with applications at the same or lower privilege level.
+If the application that requests UIAccess meets the UIAccess setting requirements, computers that run at least the Windows Vista operating system start the application with the ability to bypass most UIPI restrictions. If the application does not meet the security restrictions, the application is started without UIAccess rights, and it can interact only with applications at the same or lower privilege level.
 
-## Related topics
+## Related articles
 
 - [Security Options](/windows/device-security/security-policy-settings/security-options)

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

@@ -1,6 +1,6 @@
 ---
 title: AppLocker functions (Windows 10)
-description: This topic 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 the Software Restriction Policies (SRP) and AppLocker features.
 ms.assetid: bf704198-9e74-4731-8c5a-ee0512df34d2
 ms.reviewer: 
 ms.author: dansimp
@@ -23,11 +23,11 @@ ms.date: 09/21/2017
 - Windows 10
 - Windows Server
 
-This topic for the IT professional lists the functions and security levels for the Software Restriction Policies (SRP) and AppLocker features.
+This article for the IT professional lists the functions and security levels for the Software Restriction Policies (SRP) and AppLocker features.
 
 ## Functions
 
-The following list includes the SRP functions beginning with Windows Server 2003 and AppLocker functions beginning with Windows Server 2008 R2 and links to current documentation on MSDN:
+Here are the SRP functions beginning with Windows Server 2003 and AppLocker functions beginning with Windows Server 2008 R2:
 
 -   [SaferGetPolicyInformation Function](https://go.microsoft.com/fwlink/p/?LinkId=159781)
 -   [SaferCreateLevel Function](https://go.microsoft.com/fwlink/p/?LinkId=159782)
@@ -40,7 +40,7 @@ The following list includes the SRP functions beginning with Windows Server 200
 
 ## Security level ID
 
-AppLocker and SRP use the security level IDs to stipulate the access requirements to files listed in policies. The following table shows those security levels supported in SRP and AppLocker.
+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.
 
 | Security level ID | SRP | AppLocker |
 | - | - | - |
@@ -50,9 +50,10 @@ AppLocker and SRP use the security level IDs to stipulate the access requirement
 | SAFER_LEVELID_UNTRUSTED | Supported | Not supported |
 | SAFER_LEVELID_DISALLOWED | Supported | Supported | 
  
-In addition, URL zone ID is not supported in AppLocker.
+>[!Note]
+>URL zone ID isn't supported in AppLocker.
 
-## Related topics
+## Related articles
 
 - [AppLocker technical reference](applocker-technical-reference.md)
  

windows/security/threat-protection/windows-defender-application-control/applocker/create-a-rule-for-packaged-apps.md

@@ -1,6 +1,6 @@
 ---
 title: Create a rule for packaged apps (Windows 10)
-description: This topic for IT professionals shows how to create an AppLocker rule for packaged apps with a publisher condition.
+description: This article for IT professionals shows how to create an AppLocker rule for packaged apps with a publisher condition.
 ms.assetid: e4ffd400-7860-47b3-9118-0e6853c3dfa0
 ms.reviewer: 
 ms.author: dansimp
@@ -23,9 +23,9 @@ ms.date: 09/21/2017
 - Windows 10
 - Windows Server
 
-This topic for IT professionals shows how to create an AppLocker rule for packaged apps with a publisher condition.
+This article for IT professionals shows how to create an AppLocker rule for packaged apps with a publisher condition.
 
-Packaged apps, also known as Universal Windows apps, are based on an app model that ensures that all the files within an app package share the same identity. Therefore, it is possible to control the entire app using a single AppLocker rule as opposed to the non-packaged apps where each file within the app could have a unique identity. Windows does not support unsigned packaged apps which implies all packaged apps must be signed. AppLocker supports only publisher rules for packaged apps. A publisher rule for a packaged app is based on the following information:
+Packaged apps, also known as Universal Windows apps, are based on an app model that ensures that all the files within an app package share the same identity. Therefore, it is possible to control the entire app using a single AppLocker rule as opposed to the non-packaged apps where each file within the app could have a unique identity. Windows does not support unsigned packaged apps, which implies all packaged apps must be signed. AppLocker supports only publisher rules for packaged apps. A publisher rule for a packaged app is based on the following information:
 
 -   Publisher of the package
 -   Package name
@@ -40,9 +40,9 @@ You can perform this task by using the Group Policy Management Console for an Ap
 **To create a packaged app rule**
 
 1.  Open the AppLocker console.
-2.  On the **Action** menu, or by right-clicking on **Packaged app Rules**, click **Create New Rule**.
-3.  On the **Before You Begin** page, click **Next**.
-4.  On the **Permissions** page, select the action (allow or deny) and the user or group that the rule should apply to, and then click **Next**.
+2.  On the **Action** menu, or by right-clicking on **Packaged app Rules**, select **Create New Rule**.
+3.  On the **Before You Begin** page, select **Next**.
+4.  On the **Permissions** page, select the action (allow or deny) and the user or group that the rule should apply to, and then select **Next**.
 5.  On the **Publisher** page, you can select a specific reference for the packaged app rule and set the scope for the rule. The following table describes the reference options.
     <table>
     <colgroup>
@@ -65,8 +65,8 @@ You can perform this task by using the Group Policy Management Console for an Ap
     </tr>
     <tr class="even">
     <td align="left"><p><b>Use a packaged app installer as a reference</b></p></td>
-    <td align="left"><p>If selected, AppLocker requires you to choose an app installer on which to base your new rule. A packaged app installer has the .appx extension. AppLocker uses the publisher, package name and package version of the installer to define the rule.</p></td>
-    <td align="left"><p>Your company has developed a number of internal line-of-business packaged apps. The app installers are stored on a common file share. Employees can install the required apps from that file share. You want to allow all your employees to install the Payroll app from this share. So you choose this option from the wizard, browse to the file share and choose the installer for the Payroll app as a reference to create your rule.</p></td>
+    <td align="left"><p>If selected, AppLocker requires you to choose an app installer on which to base your new rule. A packaged app installer has the .appx extension. AppLocker uses the publisher, package name, and package version of the installer to define the rule.</p></td>
+    <td align="left"><p>Your company has developed a number of internal line-of-business packaged apps. The app installers are stored on a common file share. Employees can install the required apps from that file share. You want to allow all your employees to install the Payroll app from this share. So you choose this option from the wizard, browse to the file share, and choose the installer for the Payroll app as a reference to create your rule.</p></td>
     </tr>
     </tbody>
     </table>
@@ -110,11 +110,11 @@ You can perform this task by using the Group Policy Management Console for an Ap
     <tr class="odd">
     <td align="left"><p>Applying custom values to the rule</p></td>
     <td align="left"><p>Selecting the <b>Use custom values</b> check box allows you to adjust the scope fields for your particular circumstance.</p></td>
-    <td align="left"><p>You want to allow users to install all Microsoft.Bing* applications which include Microsoft.BingMaps, Microsoft.BingWeather, Microsoft.BingMoney. You can choose the Microsoft.BingMaps as a reference, select the <b>Use custom values</b> check box and edit the package name field by adding “Microsoft.Bing*” as the Package name.</p></td>
+    <td align="left"><p>You want to allow users to install all Microsoft.Bing* applications, which includes Microsoft.BingMaps, Microsoft.BingWeather, Microsoft.BingMoney. You can choose the Microsoft.BingMaps as a reference, select the <b>Use custom values</b> check box and edit the package name field by adding “Microsoft.Bing*” as the Package name.</p></td>
     </tr>
     </tbody>
     </table>
      
-6.  Click **Next**.
-7.  (Optional) On the **Exceptions** page, specify conditions by which to exclude files from being affected by the rule. This allows you to add exceptions based on the same rule reference and rule scope as you set before. Click **Next**.
-8.  On the **Name** page, either accept the automatically generated rule name or type a new rule name, and then click **Create**.
+6.  Select **Next**.
+7.  (Optional) On the **Exceptions** page, specify conditions by which to exclude files from being affected by the rule. This allows you to add exceptions based on the same rule reference and rule scope as you set before. Select **Next**.
+8.  On the **Name** page, either accept the automatically generated rule name or type a new rule name, and then select **Create**.