diff --git a/windows/device-security/device-guard/deploy-code-integrity-policies-steps.md b/windows/device-security/device-guard/deploy-code-integrity-policies-steps.md
index 5049f022b1..932cebc339 100644
--- a/windows/device-security/device-guard/deploy-code-integrity-policies-steps.md
+++ b/windows/device-security/device-guard/deploy-code-integrity-policies-steps.md
@@ -20,7 +20,7 @@ For an overview of the process described in the following procedures, see [Deplo
The process for creating a golden code integrity policy from a reference system is straightforward. This section outlines the process that is required to successfully create a code integrity policy with Windows PowerShell. First, for this example, you must initiate variables to be used during the creation process. Rather than using variables, you can simply use the full file paths in the command. Next, you create the code integrity policy by scanning the system for installed applications. When created, the policy file is converted to binary format so that Windows can consume its contents.
-> **Note** Before you begin this procedure, make sure that the reference PC is virus and malware-free,and that any software you want to be scanned is installed on the system before creating the code integrity policy.
+>[!Note] Before you begin this procedure, make sure that the reference PC is virus and malware-free,and that any software you want to be scanned is installed on the system before creating the code integrity policy.
### Scripting and applications
@@ -64,12 +64,12 @@ In certain circumstances, if the use case is appropriate, for example if your op
->!Note
+>[!Note]
>This application list is fluid and will be updated with the latest vendor information as application vulnerabilities are resolved and new issues are discovered.
When an application version is upgraded, you may want to add deny rules to your code integrity policies for that application’s previous, less secure versions, especially to fix a vulnerability or potential Device Guard bypass. Certain vendors may or may not intend to update their software to work with Device Guard.
-To block the listed applications, you can merge this policy into your existing policy by adding the following deny rules using the Powershell Merge-CIPolicy cmdlet:
+To block the listed applications, you can merge this policy into your existing policy by adding the following deny rules using the PowerShell Merge-CIPolicy cmdlet:
```
@@ -153,7 +153,7 @@ To block the listed applications, you can merge this policy into your existing p
### Disable Windows Script Host
-If you are using Device Guard code integrity policies, the policies place constraints on Powershell and WSH scripts. When Device Guard is enabled, by default, PowerShell scripts execute in “ConstrainedLanguage” language mode, in which neither wscript.exe and cscript.exe can invoke untrusted Active X controls or COM objects. However, signed PowerShell scripts are permitted to execute in “FullLanguage” language mode, and trusted or signed wscript or cscript scripts can invoke Active X controls or COM objects. For further information on Powershell language modes, see [Language Modes](https://msdn.microsoft.com/en-us/powershell/reference/4.0/microsoft.powershell.core/about/about_language_modes).
+If you are using Device Guard code integrity policies, the policies place constraints on PowerShell and WSH scripts. When Device Guard is enabled, by default, PowerShell scripts execute in “ConstrainedLanguage” language mode, in which neither wscript.exe and cscript.exe can invoke untrusted Active X controls or COM objects. However, signed PowerShell scripts are permitted to execute in “FullLanguage” language mode, and trusted or signed wscript or cscript scripts can invoke Active X controls or COM objects. For further information on PowerShell language modes, see [Language Modes](https://msdn.microsoft.com/en-us/powershell/reference/4.0/microsoft.powershell.core/about/about_language_modes).
Alternatively, though script hosts are safer with Device Guard enabled, if your reference PC does not require any scripting, you may want to completely disable WSH. Disabling WSH prevents all users from running any scripts, including VBScript and JScript scripts. Note that some applications may require WSH to be enabled. You can disable WSH by configuring Device Guard code integrity policies.
@@ -250,7 +250,7 @@ To disable Windows Script Hosting, you can simply create further deny rules to a
-The June 2017 Windows updates resolve a vulnerability in Powershell that allowed an attacker to bypass Device Guard code integrity policies. Powershell cmdlets cannot be blocked by name or version, and therefore must be blocked by their corresponding hashes. We recommend that you block the following Powershell cmdlets and merge this policy into your existing policy by adding the following deny rules using the Merge-CIPolicy cmdlet:
+The June 2017 Windows updates resolve a vulnerability in PowerShell that allowed an attacker to bypass Device Guard code integrity policies. Powershell cmdlets cannot be blocked by name or version, and therefore must be blocked by their corresponding hashes. We recommend that you block the following PowerShell cmdlets and merge this policy into your existing policy by adding the following deny rules using the Merge-CIPolicy cmdlet:
```
diff --git a/windows/device-security/device-guard/planning-and-getting-started-on-the-device-guard-deployment-process.md b/windows/device-security/device-guard/planning-and-getting-started-on-the-device-guard-deployment-process.md
index 2ab4faeb53..d122d6450b 100644
--- a/windows/device-security/device-guard/planning-and-getting-started-on-the-device-guard-deployment-process.md
+++ b/windows/device-security/device-guard/planning-and-getting-started-on-the-device-guard-deployment-process.md
@@ -35,7 +35,7 @@ This topic provides a roadmap for planning and getting started on the Device Gua
In day-to-day operations, your organization’s security policy may allow certain applications, code, or scripts to run on your systems depending on their role and the context. However, if your security policy requires that you run only trusted applications, code, and scripts on your systems, you may decide to lock these systems down securely with Device Guard code integrity policies.
You can also fine-tune your control by using Device Guard in combination with AppLocker, as described in [Device Guard with AppLocker](https://technet.microsoft.com/itpro/windows/keep-secure/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies#device-guard-with-applocker).
- Legitimate applications from trusted vendors provide valid functionality. However, an attacker could also potentially use that same functionality to run malicious executable code that could bypass code integrity policies. For operational scenarios that require elevated security, certain applications with known Code Integrity bypasses may represent a security risk if you whitelist them in your code integrity policies. Other applications whose older versions have vulnerabilities also represent a risk. Therefore, you may want to deny or block such applications from your code integrity policies. Once applications with vulnerabilities are fixed, you can create a rule that only allows the fixed version or newer versions of that application. The decision to allow or block applications depends on the context and on how the reference system is being used.
+ Legitimate applications from trusted vendors provide valid functionality. However, an attacker could also potentially use that same functionality to run malicious executable code that could bypass code integrity policies. For operational scenarios that require elevated security, certain applications with known Code Integrity bypass vulnerabilities may represent a security risk if you whitelist them in your code integrity policies. Other applications whose older versions have vulnerabilities also represent a risk. Therefore, you may want to deny or block such applications from your code integrity policies. Once applications with vulnerabilities are fixed, you can create a rule that only allows the fixed version or newer versions of that application. The decision to allow or block applications depends on the context and on how the reference system is being used.
Security professionals collaborate with Microsoft® continuously to help protect customers. With the help of their valuable reports, Microsoft has identified a list of known applications that an attacker could potentially use to bypass Device Guard code integrity policies.
Depending on the context, you may want to block these applications. To see the list of applications, and for use case examples such as disabling Windows Script Host (WSH) or disabling msbuild.exe, (See [Deploy code integrity policies: steps](https://technet.microsoft.com/itpro/windows/keep-secure/deploy-code-integrity-policies-steps)).