AZ-802: Administering Windows Server

An enforced App Control for Business (WDAC) base policy ignores any supplemental policy unless the base policy itself carries policy rule option 17, Enabled:Allow Supplemental Policies, documented as "Use this option on a base policy to allow supplemental policies to expand it" and marked as not valid as a supplemental option, so it can only be set on the base. Because option 17 is a policy rule option (Set-RuleOption -FilePath .\policy.xml -Option 17) and not a file rule, enabling it adds nothing to the base policy's allow rules, which remain identical across all forty servers. Once the base accepts supplemental policies, a supplemental policy created with New-CIPolicy -MultiplePolicyFormat and bound to the base with Set-CIPolicyIdInfo -SupplementsBasePolicyID can be deployed as its own {PolicyGUID}.cip to just the six pilot servers; a base policy and its supplemental policy combine as a union, so files allowed by either one run, and the remaining thirty-four servers stay governed by the unmodified base policy alone. The rule inside that supplemental policy should be a signer rule keyed to the vendor's single signing certificate. Signer-based levels such as Publisher and LeafCertificate grant trust at the certificate level, so every monthly rebuild signed by the same publisher keeps running without any policy edit. Hash rules behave the opposite way: each time a binary is updated its hash changes, therefore requiring a policy update, which would force a new policy revision every month. Filepath rules are weaker still, since they do not provide the same security guarantees that explicit signer rules do because they rest on mutable access permissions, and adding one to the base policy would both change the base policy's allow rules and authorize the app on all forty servers instead of only the pilot group. Putting the pilot servers into audit mode would permit every unapproved binary rather than one application and would give up enforcement on those servers entirely.