mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-06-18 20:03:40 +00:00
Merge pull request #4421 from nschonni/fix--MD038/no-space-in-code
fix: MD038/no-space-in-code
This commit is contained in:
Daniel Simpson
GitHub
@ -204,7 +204,7 @@ If the physical computer is still running in a frozen state, follow these steps
|
||||
|
||||
2. From a remote computer that is preferably in the same network and subnet, go to **Registry Editor** \> **Connect Network Registry**. Then, connect to the concerned computer, and verify the following settings:
|
||||
|
||||
* ` `*HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\CrashDumpEnabled`
|
||||
* `HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\CrashDumpEnabled`
|
||||
|
||||
Make sure that the [CrashDumpEnabled](https://docs.microsoft.com/previous-versions/windows/it-pro/windows-2000-server/cc976050(v=technet.10)) registry entry is `1`.
|
||||
|
||||
|
||||
@ -91,7 +91,7 @@ When you have the Start layout that you want your users to see, use the [Export-
|
||||
|
||||
2. On a device running Windows 10, version 1607, 1703, or 1803, at the Windows PowerShell command prompt, enter the following command:
|
||||
|
||||
`Export-StartLayout –path <path><file name>.xml `
|
||||
`Export-StartLayout –path <path><file name>.xml`
|
||||
|
||||
On a device running Windows 10, version 1809, run the **Export-StartLayout** with the switch **-UseDesktopApplicationID**. For example:
|
||||
|
||||
|
||||
@ -89,7 +89,7 @@ In addition, note the following functionality with the Config.xml file:
|
||||
|
||||
- If a parent component is removed from the migration in the Config.xml file by specifying `migrate="no"`, all of its child components will automatically be removed from the migration, even if the child component is set to `migrate="yes"`.
|
||||
|
||||
- If you mistakenly have two lines of code for the same component where one line specifies `migrate="no" `and the other line specifies `migrate="yes"`, the component will be migrated.
|
||||
- If you mistakenly have two lines of code for the same component where one line specifies `migrate="no"` and the other line specifies `migrate="yes"`, the component will be migrated.
|
||||
|
||||
- In USMT there are several migration policies that can be configured in the Config.xml file. For example, you can configure additional **<ErrorControl>**, **<ProfileControl>**, and **<HardLinkStoreControl>** options. For more information, see the [Config.xml File](usmt-configxml-file.md) topic.
|
||||
|
||||
|
||||
@ -50,7 +50,7 @@ Before you modify the .xml files, become familiar with the following guidelines:
|
||||
|
||||
- **File names with brackets**
|
||||
|
||||
If you are migrating a file that has a bracket character (\[ or \]) in the file name, you must insert a carat (^) character directly before the bracket for the bracket character to be valid. For example, if there is a file named File.txt, you must specify `<pattern type="File">c:\documents\mydocs [file^].txt]</pattern> `instead of `<pattern type="File">c:\documents\mydocs [file].txt]</pattern>`.
|
||||
If you are migrating a file that has a bracket character (\[ or \]) in the file name, you must insert a carat (^) character directly before the bracket for the bracket character to be valid. For example, if there is a file named File.txt, you must specify `<pattern type="File">c:\documents\mydocs [file^].txt]</pattern>` instead of `<pattern type="File">c:\documents\mydocs [file].txt]</pattern>`.
|
||||
|
||||
- **Using quotation marks**
|
||||
|
||||
|
||||
@ -1499,7 +1499,7 @@ For example:
|
||||
|
||||
- **MergeMultiSzContent**
|
||||
|
||||
The MergeMultiSzContent function merges the MULTI-SZ content of the registry values that are enumerated by the parent <ObjectSet> element with the content of the equivalent registry values that already exist on the destination computer. `Instruction` and` String` either remove or add content to the resulting MULTI-SZ. Duplicate elements will be removed.
|
||||
The MergeMultiSzContent function merges the MULTI-SZ content of the registry values that are enumerated by the parent <ObjectSet> element with the content of the equivalent registry values that already exist on the destination computer. `Instruction` and `String` either remove or add content to the resulting MULTI-SZ. Duplicate elements will be removed.
|
||||
|
||||
Syntax: MergeMultiSzContent (*Instruction*,*String*,*Instruction*,*String*,…)
|
||||
|
||||
@ -3618,7 +3618,7 @@ The return value that is required by <script> depends on the parent elemen
|
||||
|
||||
Syntax: <script>MigXmlHelper.GetStringContent("*ObjectType*","*EncodedLocationPattern*", "*ExpandContent*")</script>
|
||||
|
||||
Example:` <script>MigXMLHelper.GetStringContent("Registry","HKLM\Software\MyApp\Installer [EXEPATH]")</script>`
|
||||
Example: `<script>MigXMLHelper.GetStringContent("Registry","HKLM\Software\MyApp\Installer [EXEPATH]")</script>`
|
||||
|
||||
- You can use [GenerateUserPatterns](#scriptfunctions) when <script> is within <objectSet>.
|
||||
|
||||
|
||||
@ -126,7 +126,7 @@ If your AD FS farm is not already configured for Device Authentication (you can
|
||||
2. On your AD FS primary server, ensure you are logged in as AD DS user with enterprise administrator privileges and open an elevated Windows PowerShell prompt. Then, run the following commands:
|
||||
|
||||
`Import-module activedirectory`
|
||||
`PS C:\> Initialize-ADDeviceRegistration -ServiceAccountName "<your service account>" `
|
||||
`PS C:\> Initialize-ADDeviceRegistration -ServiceAccountName "<your service account>"`
|
||||
3. On the pop-up window click **Yes**.
|
||||
|
||||
> [!NOTE]
|
||||
@ -150,7 +150,7 @@ The above PSH creates the following objects:
|
||||
If you plan to use Windows 10 domain join (with automatic registration to Azure AD) as described here, execute the following commands to create a service connection point in AD DS
|
||||
1. Open Windows PowerShell and execute the following:
|
||||
|
||||
`PS C:>Import-Module -Name "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1" `
|
||||
`PS C:>Import-Module -Name "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1"`
|
||||
|
||||
> [!NOTE]
|
||||
> If necessary, copy the AdSyncPrep.psm1 file from your Azure AD Connect server. This file is located in Program Files\Microsoft Azure Active Directory Connect\AdPrep
|
||||
@ -165,7 +165,7 @@ If you plan to use Windows 10 domain join (with automatic registration to Azure
|
||||
|
||||
3. Run the following PowerShell command
|
||||
|
||||
`PS C:>Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount [AD connector account name] -AzureADCredentials $aadAdminCred `
|
||||
`PS C:>Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount [AD connector account name] -AzureADCredentials $aadAdminCred`
|
||||
|
||||
Where the [AD connector account name] is the name of the account you configured in Azure AD Connect when adding your on-premises AD DS directory.
|
||||
|
||||
@ -176,7 +176,7 @@ To ensure AD DS objects and containers are in the correct state for write back o
|
||||
|
||||
1. Open Windows PowerShell and execute the following:
|
||||
|
||||
`PS C:>Initialize-ADSyncDeviceWriteBack -DomainName <AD DS domain name> -AdConnectorAccount [AD connector account name] `
|
||||
`PS C:>Initialize-ADSyncDeviceWriteBack -DomainName <AD DS domain name> -AdConnectorAccount [AD connector account name]`
|
||||
|
||||
Where the [AD connector account name] is the name of the account you configured in Azure AD Connect when adding your on-premises AD DS directory in domain\accountname format
|
||||
|
||||
|
||||
@ -77,13 +77,13 @@ Use the following procedure after you have been running a computer with a WDAC p
|
||||
|
||||
2. In an elevated Windows PowerShell session, initialize the variables that will be used. The example filename shown here is **DeviceGuardAuditPolicy.xml**:
|
||||
|
||||
` $CIPolicyPath=$env:userprofile+"\Desktop\"`
|
||||
`$CIPolicyPath=$env:userprofile+"\Desktop\"`
|
||||
|
||||
` $CIAuditPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"`
|
||||
`$CIAuditPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"`
|
||||
|
||||
3. Use [New-CIPolicy](https://docs.microsoft.com/powershell/module/configci/new-cipolicy) to generate a new WDAC policy from logged audit events. This example uses a file rule level of **Hash** and includes `3> CIPolicylog.txt`, which redirects warning messages to a text file, **CIPolicylog.txt**.
|
||||
|
||||
` New-CIPolicy -Audit -Level Hash -FilePath $CIAuditPolicy –UserPEs 3> CIPolicylog.txt`
|
||||
`New-CIPolicy -Audit -Level Hash -FilePath $CIAuditPolicy –UserPEs 3> CIPolicylog.txt`
|
||||
|
||||
> [!NOTE]
|
||||
> When you create policies from audit events, you should carefully consider the file rule level that you select to trust. The preceding example uses the **Hash** rule level, which is the most specific. Any change to the file (such as replacing the file with a newer version of the same file) will change the Hash value, and require an update to the policy.
|
||||
|
||||
@ -40,11 +40,11 @@ To create a WDAC policy, copy each of the following commands into an elevated Wi
|
||||
|
||||
1. Initialize variables that you will use. The following example commands use **InitialScan.xml** and **DeviceGuardPolicy.bin** for the names of the files that will be created:
|
||||
|
||||
` $CIPolicyPath=$env:userprofile+"\Desktop\"`
|
||||
`$CIPolicyPath=$env:userprofile+"\Desktop\"`
|
||||
|
||||
` $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"`
|
||||
`$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"`
|
||||
|
||||
` $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"`
|
||||
`$CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"`
|
||||
|
||||
2. Use [New-CIPolicy](https://docs.microsoft.com/powershell/module/configci/new-cipolicy) to create a new WDAC policy by scanning the system for installed applications:
|
||||
|
||||
|
||||
@ -41,7 +41,7 @@ To create a catalog file, you use a tool called **Package Inspector**. You must
|
||||
|
||||
2. Start Package Inspector, and then start scanning a local drive, for example, drive C:
|
||||
|
||||
` PackageInspector.exe Start C:`
|
||||
`PackageInspector.exe Start C:`
|
||||
|
||||
> [!NOTE]
|
||||
> Package inspector can monitor installations on any local drive. Specify the appropriate drive on the local computer.
|
||||
@ -69,13 +69,13 @@ To create a catalog file, you use a tool called **Package Inspector**. You must
|
||||
|
||||
For the last command, which stops Package Inspector, be sure to type the drive letter of the drive you have been scanning, for example, C:.
|
||||
|
||||
` $ExamplePath=$env:userprofile+"\Desktop"`
|
||||
`$ExamplePath=$env:userprofile+"\Desktop"`
|
||||
|
||||
` $CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"`
|
||||
`$CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"`
|
||||
|
||||
` $CatDefName=$ExamplePath+"\LOBApp.cdf"`
|
||||
`$CatDefName=$ExamplePath+"\LOBApp.cdf"`
|
||||
|
||||
` PackageInspector.exe Stop C: -Name $CatFileName -cdfpath $CatDefName`
|
||||
`PackageInspector.exe Stop C: -Name $CatFileName -cdfpath $CatDefName`
|
||||
|
||||
> **Note** Package Inspector catalogs the hash values for each discovered binary file. If the applications that were scanned are updated, complete this process again to trust the new binaries’ hash values.
|
||||
|
||||
@ -116,15 +116,15 @@ To sign the existing catalog file, copy each of the following commands into an e
|
||||
|
||||
1. Initialize the variables that will be used. Replace the *$ExamplePath* and *$CatFileName* variables as needed:
|
||||
|
||||
` $ExamplePath=$env:userprofile+"\Desktop"`
|
||||
`$ExamplePath=$env:userprofile+"\Desktop"`
|
||||
|
||||
` $CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"`
|
||||
`$CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"`
|
||||
|
||||
2. Import the code signing certificate that will be used to sign the catalog file. Import it to the signing user’s personal store.
|
||||
|
||||
3. Sign the catalog file with Signtool.exe:
|
||||
|
||||
` <path to signtool.exe> sign /n "ContosoDGSigningCert" /fd sha256 /v $CatFileName`
|
||||
`<path to signtool.exe> sign /n "ContosoDGSigningCert" /fd sha256 /v $CatFileName`
|
||||
|
||||
> **Note** The *<Path to signtool.exe>* variable should be the full path to the Signtool.exe utility. *ContosoDGSigningCert* represents the subject name of the certificate that you will use to sign the catalog file. This certificate should be imported to your personal certificate store on the computer on which you are attempting to sign the catalog file.
|
||||
>
|
||||
@ -148,14 +148,14 @@ After the catalog file is signed, add the signing certificate to a WDAC policy,
|
||||
|
||||
2. If you already have an XML policy file that you want to add the signing certificate to, skip to the next step. Otherwise, use [New-CIPolicy](https://docs.microsoft.com/powershell/module/configci/new-cipolicy) to create a WDAC policy that you will later merge into another policy (not deploy as-is). This example creates a policy called **CatalogSignatureOnly.xml** in the location **C:\\PolicyFolder**:
|
||||
|
||||
` New-CIPolicy -Level PcaCertificate -FilePath C:\PolicyFolder\CatalogSignatureOnly.xml –UserPEs`
|
||||
`New-CIPolicy -Level PcaCertificate -FilePath C:\PolicyFolder\CatalogSignatureOnly.xml –UserPEs`
|
||||
|
||||
> [!NOTE]
|
||||
> Include the **-UserPEs** parameter to ensure that the policy includes user mode code integrity.
|
||||
|
||||
3. Use [Add-SignerRule](https://docs.microsoft.com/powershell/module/configci/add-signerrule) to add the signing certificate to the WDAC policy, filling in the correct path and filenames for `<policypath>` and `<certpath>`:
|
||||
|
||||
` Add-SignerRule -FilePath <policypath> -CertificatePath <certpath> -User `
|
||||
`Add-SignerRule -FilePath <policypath> -CertificatePath <certpath> -User`
|
||||
|
||||
If you used step 2 to create a new WDAC policy, and want information about merging policies together, see [Merge Windows Defender Application Control policies](merge-windows-defender-application-control-policies.md).
|
||||
|
||||
|
||||
@ -28,13 +28,13 @@ Every WDAC policy is created with audit mode enabled. After you have successfull
|
||||
|
||||
1. Initialize the variables that will be used:
|
||||
|
||||
` $CIPolicyPath=$env:userprofile+"\Desktop\"`
|
||||
`$CIPolicyPath=$env:userprofile+"\Desktop\"`
|
||||
|
||||
` $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml" `
|
||||
`$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"`
|
||||
|
||||
` $EnforcedCIPolicy=$CIPolicyPath+"EnforcedPolicy.xml"`
|
||||
`$EnforcedCIPolicy=$CIPolicyPath+"EnforcedPolicy.xml"`
|
||||
|
||||
` $CIPolicyBin=$CIPolicyPath+"EnforcedDeviceGuardPolicy.bin"`
|
||||
`$CIPolicyBin=$CIPolicyPath+"EnforcedDeviceGuardPolicy.bin"`
|
||||
|
||||
> [!NOTE]
|
||||
> The initial WDAC policy that this section refers to was created in the [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md) section. If you are using a different WDAC policy, update the **CIPolicyPath** and **InitialCIPolicy** variables.
|
||||
@ -43,23 +43,23 @@ Every WDAC policy is created with audit mode enabled. After you have successfull
|
||||
|
||||
To ensure that these options are enabled in a policy, use [Set-RuleOption](https://docs.microsoft.com/powershell/module/configci/set-ruleoption) as shown in the following commands. You can run these commands even if you're not sure whether options 9 and 10 are already enabled—if so, the commands have no effect.
|
||||
|
||||
` Set-RuleOption -FilePath $InitialCIPolicy -Option 9`
|
||||
`Set-RuleOption -FilePath $InitialCIPolicy -Option 9`
|
||||
|
||||
` Set-RuleOption -FilePath $InitialCIPolicy -Option 10`
|
||||
`Set-RuleOption -FilePath $InitialCIPolicy -Option 10`
|
||||
|
||||
3. Copy the initial file to maintain an original copy:
|
||||
|
||||
` copy $InitialCIPolicy $EnforcedCIPolicy`
|
||||
`copy $InitialCIPolicy $EnforcedCIPolicy`
|
||||
|
||||
4. Use Set-RuleOption to delete the audit mode rule option:
|
||||
|
||||
` Set-RuleOption -FilePath $EnforcedCIPolicy -Option 3 -Delete`
|
||||
`Set-RuleOption -FilePath $EnforcedCIPolicy -Option 3 -Delete`
|
||||
|
||||
> [!NOTE]
|
||||
> To enforce a WDAC policy, you delete option 3, the **Audit Mode Enabled** option. There is no “enforced” option that can be placed in a WDAC policy.
|
||||
|
||||
5. Use [ConvertFrom-CIPolicy](https://docs.microsoft.com/powershell/module/configci/convertfrom-cipolicy) to convert the new WDAC policy to binary format:
|
||||
|
||||
` ConvertFrom-CIPolicy $EnforcedCIPolicy $CIPolicyBin`
|
||||
`ConvertFrom-CIPolicy $EnforcedCIPolicy $CIPolicyBin`
|
||||
|
||||
Now that this policy is in enforced mode, you can deploy it to your test computers. Rename the policy to SIPolicy.p7b and copy it to C:\\Windows\\System32\\CodeIntegrity for testing, or deploy the policy through Group Policy by following the instructions in [Deploy and manage Windows Defender Application Control with Group Policy](deploy-windows-defender-application-control-policies-using-group-policy.md). You can also use other client management software to deploy and manage the policy.
|
||||
|
||||
@ -30,26 +30,26 @@ To merge two WDAC policies, complete the following steps in an elevated Windows
|
||||
|
||||
1. Initialize the variables that will be used:
|
||||
|
||||
` $CIPolicyPath=$env:userprofile+"\Desktop\"`
|
||||
`$CIPolicyPath=$env:userprofile+"\Desktop\"`
|
||||
|
||||
` $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"`
|
||||
`$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"`
|
||||
|
||||
` $AuditCIPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"`
|
||||
`$AuditCIPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"`
|
||||
|
||||
` $MergedCIPolicy=$CIPolicyPath+"MergedPolicy.xml"`
|
||||
`$MergedCIPolicy=$CIPolicyPath+"MergedPolicy.xml"`
|
||||
|
||||
` $CIPolicyBin=$CIPolicyPath+"NewDeviceGuardPolicy.bin"`
|
||||
`$CIPolicyBin=$CIPolicyPath+"NewDeviceGuardPolicy.bin"`
|
||||
|
||||
> [!NOTE]
|
||||
> The variables in this section specifically expect to find an initial policy on your desktop called **InitialScan.xml** and an audit WDAC policy called **DeviceGuardAuditPolicy.xml**. If you want to merge other WDAC policies, update the variables accordingly.
|
||||
|
||||
2. Use [Merge-CIPolicy](https://docs.microsoft.com/powershell/module/configci/merge-cipolicy) to merge two policies and create a new WDAC policy:
|
||||
|
||||
` Merge-CIPolicy -PolicyPaths $InitialCIPolicy,$AuditCIPolicy -OutputFilePath $MergedCIPolicy`
|
||||
`Merge-CIPolicy -PolicyPaths $InitialCIPolicy,$AuditCIPolicy -OutputFilePath $MergedCIPolicy`
|
||||
|
||||
3. Use [ConvertFrom-CIPolicy](https://docs.microsoft.com/powershell/module/configci/convertfrom-cipolicy) to convert the merged WDAC policy to binary format:
|
||||
|
||||
` ConvertFrom-CIPolicy $MergedCIPolicy $CIPolicyBin `
|
||||
`ConvertFrom-CIPolicy $MergedCIPolicy $CIPolicyBin`
|
||||
|
||||
Now that you have created a new WDAC policy, you can deploy the policy binary to systems manually or by using Group Policy or Microsoft client management solutions. For information about how to deploy this new policy with Group Policy, see [Deploy and manage Windows Defender Application Control with Group Policy](deploy-windows-defender-application-control-policies-using-group-policy.md).
|
||||
|
||||
|
||||
@ -36,13 +36,13 @@ To modify the policy rule options of an existing WDAC policy, use [Set-RuleOptio
|
||||
|
||||
- To ensure that UMCI is enabled for a WDAC policy that was created with the `-UserPEs` (user mode) option, add rule option 0 to an existing policy by running the following command:
|
||||
|
||||
` Set-RuleOption -FilePath <Path to policy> -Option 0`
|
||||
`Set-RuleOption -FilePath <Path to policy> -Option 0`
|
||||
|
||||
Note that a policy that was created without the `-UserPEs` option is empty of user mode executables, that is, applications. If you enable UMCI (Option 0) for such a policy and then attempt to run an application, Windows Defender Application Control will see that the application is not on its list (which is empty of applications), and respond. In audit mode, the response is logging an event, and in enforced mode, the response is blocking the application. To create a policy that includes user mode executables (applications), when you run `New-CIPolicy`, include the `-UserPEs` option.
|
||||
|
||||
- To disable UMCI on an existing WDAC policy, delete rule option 0 by running the following command:
|
||||
|
||||
` Set-RuleOption -FilePath <Path to policy> -Option 0 -Delete`
|
||||
`Set-RuleOption -FilePath <Path to policy> -Option 0 -Delete`
|
||||
|
||||
You can set several rule options within a WDAC policy. Table 2 describes each rule option.
|
||||
|
||||
|
||||
@ -43,11 +43,11 @@ If you do not have a code signing certificate, see the [Optional: Create a code
|
||||
|
||||
1. Initialize the variables that will be used:
|
||||
|
||||
` $CIPolicyPath=$env:userprofile+"\Desktop\"`
|
||||
`$CIPolicyPath=$env:userprofile+"\Desktop\"`
|
||||
|
||||
` $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"`
|
||||
`$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"`
|
||||
|
||||
` $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"`
|
||||
`$CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"`
|
||||
|
||||
> [!NOTE]
|
||||
> This example uses the WDAC policy that you created in [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md). If you are signing another policy, be sure to update the **$CIPolicyPath** and **$CIPolicyBin** variables with the correct information.
|
||||
@ -58,11 +58,11 @@ If you do not have a code signing certificate, see the [Optional: Create a code
|
||||
|
||||
4. Navigate to your desktop as the working directory:
|
||||
|
||||
` cd $env:USERPROFILE\Desktop `
|
||||
`cd $env:USERPROFILE\Desktop`
|
||||
|
||||
5. Use [Add-SignerRule](https://docs.microsoft.com/powershell/module/configci/add-signerrule) to add an update signer certificate to the WDAC policy:
|
||||
|
||||
` Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath <Path to exported .cer certificate> -Kernel -User –Update`
|
||||
`Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath <Path to exported .cer certificate> -Kernel -User –Update`
|
||||
|
||||
> [!NOTE]
|
||||
> \<Path to exported .cer certificate> should be the full path to the certificate that you exported in step 3.
|
||||
@ -70,15 +70,15 @@ If you do not have a code signing certificate, see the [Optional: Create a code
|
||||
|
||||
6. Use [Set-RuleOption](https://docs.microsoft.com/powershell/module/configci/set-ruleoption) to remove the unsigned policy rule option:
|
||||
|
||||
` Set-RuleOption -FilePath $InitialCIPolicy -Option 6 -Delete`
|
||||
`Set-RuleOption -FilePath $InitialCIPolicy -Option 6 -Delete`
|
||||
|
||||
7. Use [ConvertFrom-CIPolicy](https://docs.microsoft.com/powershell/module/configci/convertfrom-cipolicy) to convert the policy to binary format:
|
||||
|
||||
` ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin`
|
||||
`ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin`
|
||||
|
||||
8. Sign the WDAC policy by using SignTool.exe:
|
||||
|
||||
` <Path to signtool.exe> sign -v /n "ContosoDGSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 $CIPolicyBin`
|
||||
`<Path to signtool.exe> sign -v /n "ContosoDGSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 $CIPolicyBin`
|
||||
|
||||
> [!NOTE]
|
||||
> The *<Path to signtool.exe>* variable should be the full path to the SignTool.exe utility. **ContosoDGSigningCert** is the subject name of the certificate that will be used to sign the WDAC policy. You should import this certificate to your personal certificate store on the computer you use to sign the policy.
|
||||
|
||||
@ -45,11 +45,11 @@ If you do not have a code signing certificate, see [Optional: Create a code sign
|
||||
|
||||
1. Initialize the variables that will be used:
|
||||
|
||||
` $CIPolicyPath=$env:userprofile+"\Desktop\"`
|
||||
`$CIPolicyPath=$env:userprofile+"\Desktop\"`
|
||||
|
||||
` $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"`
|
||||
`$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"`
|
||||
|
||||
` $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"`
|
||||
`$CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"`
|
||||
|
||||
> [!NOTE]
|
||||
> This example uses the WDAC policy that you created in the [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md) section. If you are signing another policy, be sure to update the **$CIPolicyPath** and **$CIPolicyBin** variables with the correct information.
|
||||
@ -60,11 +60,11 @@ If you do not have a code signing certificate, see [Optional: Create a code sign
|
||||
|
||||
4. Navigate to your desktop as the working directory:
|
||||
|
||||
` cd $env:USERPROFILE\Desktop `
|
||||
`cd $env:USERPROFILE\Desktop`
|
||||
|
||||
5. Use [Add-SignerRule](https://docs.microsoft.com/powershell/module/configci/add-signerrule) to add an update signer certificate to the WDAC policy:
|
||||
|
||||
` Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath <Path to exported .cer certificate> -Kernel -User –Update`
|
||||
`Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath <Path to exported .cer certificate> -Kernel -User –Update`
|
||||
|
||||
> [!NOTE]
|
||||
> *<Path to exported .cer certificate>* should be the full path to the certificate that you exported in step 3.
|
||||
@ -72,15 +72,15 @@ If you do not have a code signing certificate, see [Optional: Create a code sign
|
||||
|
||||
6. Use [Set-RuleOption](https://docs.microsoft.com/powershell/module/configci/set-ruleoption) to remove the unsigned policy rule option:
|
||||
|
||||
` Set-RuleOption -FilePath $InitialCIPolicy -Option 6 -Delete`
|
||||
`Set-RuleOption -FilePath $InitialCIPolicy -Option 6 -Delete`
|
||||
|
||||
7. Use [ConvertFrom-CIPolicy](https://docs.microsoft.com/powershell/module/configci/convertfrom-cipolicy) to convert the policy to binary format:
|
||||
|
||||
` ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin`
|
||||
`ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin`
|
||||
|
||||
8. Sign the WDAC policy by using SignTool.exe:
|
||||
|
||||
` <Path to signtool.exe> sign -v /n "ContosoDGSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 $CIPolicyBin`
|
||||
`<Path to signtool.exe> sign -v /n "ContosoDGSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 $CIPolicyBin`
|
||||
|
||||
> [!NOTE]
|
||||
> The *<Path to signtool.exe>* variable should be the full path to the SignTool.exe utility. **ContosoDGSigningCert** is the subject name of the certificate that will be used to sign the WDAC policy. You should import this certificate to your personal certificate store on the computer you use to sign the policy.
|
||||
|
||||
@ -177,7 +177,7 @@ reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v "Unlocked" /t REG
|
||||
|
||||
Windows 10 and Windows Server 2016 have a WMI class for related properties and features: *Win32\_DeviceGuard*. This class can be queried from an elevated Windows PowerShell session by using the following command:
|
||||
|
||||
` Get-CimInstance –ClassName Win32_DeviceGuard –Namespace root\Microsoft\Windows\DeviceGuard`
|
||||
`Get-CimInstance –ClassName Win32_DeviceGuard –Namespace root\Microsoft\Windows\DeviceGuard`
|
||||
|
||||
> [!NOTE]
|
||||
> The *Win32\_DeviceGuard* WMI class is only available on the Enterprise edition of Windows 10.
|
||||
|
||||
Reference in New Issue
Block a user