This week is a follow-up on the post of last week about easily configuring the Intune Management Extension as managed installer for Windows Defender Application Control. That post already had a note regarding supplemental Application Control policies. This week, the focus will be on adding supplemental Application Control policies on top of the base Application Control policies that are created when using the built-in controls in the creation of an Application Control policy. The great thing is that those base Application Control policies all have standard configurations and can easily be reused. This post will focus on those base Application Control policies and using those with supplemental Application Control policies. This post will finish with the distribution of such supplemental Application Control policies and the related experience.
Note: This post does not go into details about actually creating the supplemental Application Control policy. An easy start can be by using the New-CIPolicy cmdlet that is provided by Microsoft.
Base Application Control policies based on the built-in controls
When looking at supplemental Application Control policies, it all starts with the base Application Control policies. The base Application Control policy is the foundation for other supplemental Application Control policies. That can be useful when differentiating between apartments for example. All with the idea to only allow applications that are actually needed, and keeping the attack surface as small as possible. Supplemental Application Control policies can expand only a single base Application Control policy, but multiple Application Control policies can expand the same base Application Control policy. These supplemental Application Control policies must be in XML format, and must reference the PolicyID of the base Application Control policy. The good part is that the base Application Control policies, that are created when using the built-in controls, always have the same PolicyID that can be used for the reference. Those PolicyIDs are documented below.
PolicyID of the base policy | Configuration combination in the built-in controls |
---|---|
{A8012CFC-D8AE-493C-B2EA-510F035F1250} | Enable app control policy to trust Windows components and Store apps. |
{D6D6C2D6-E8B6-4D8F-8223-14BE1DE562FF} | Enable app control policy to trust Windows components and Store apps and Trust apps with good reputation. |
{63D1178A-816A-4AB6-8ECD-127F2DF0CE47} | Enable app control policy to trust Windows components and Store apps and Trust apps from managed installers. |
{2DA0F72D-1688-4097-847D-C42C39E631BC} | Enable app control policy to trust Windows components and Store apps and Trust apps with good reputation and Trust apps from managed installers. |
Note: With the built-in controls of the Application Control policies, only these four combinations can be made.
Adding the PolicyID to supplemental Application Control policy
When the PolicyIDs of the different base Application Control policies are known, it’s time to look at how to use those within supplemental Application Control policies. The base Application Control policy will automatically be enabled to allow supplemental Application Control policies. Besides that, the supplemental Application Control policies must reference the base Application Control policy that it applies to. That can be achieved by using the Set-CIPolicyIdInfo cmdlet. So, create the supplemental Application Control policy and use the command below to specify the PolicyID.
Set-CIPolicyIdInfo -FilePath ".\SupplementalExample.xml" -SupplementsBasePolicyID "{63D1178A-816A-4AB6-8ECD-127F2DF0CE47}"
The provided command will change the policy type of the created supplemental Application Control policy, as shown below.
<SiPolicy xmlns="urn:schemas-microsoft-com:sipolicy" PolicyType="Supplemental Policy">
Besides that, the base policy id will be added to the supplemental Application Control policy, as shown below.
<BasePolicyID>{63D1178A-816A-4AB6-8ECD-127F2DF0CE47}</BasePolicyID>
Note: This example only shows how to add the PolicyID of the base Application Control policy to the supplemental Application Control policy. This does not go into details about creating the supplemental Application Control policy.
Distributing the supplemental Application Control policy
When the base Application Control policy information is known, and the PolicyID is added to the supplemental Application Control policy, it’s time to look at the actual configuration of the Application Control policy for the supplemental Application Control policy. That can be achieved by using the xml data option within the Application Control policy. The following seven steps will walk through the configuration of an Application control policy using that xml data option.
- Open the Microsoft Intune admin center portal and navigate to Endpoint security > Application control
- On the Endpoint security | Application control page, on the Application control tab, click Create Policy
- On the Basics page, specify a valid name to distinguish the policy from other similar policies and click Next
- On the Configuration settings page, as shown in Figure 1, provide the following information and click Next
- Configuration settings format: Select Enter xml data to add the newly created supplemental policy
- Application control policy: Select the XML-file of the created supplemental policy
- XML value: Shows the content of the XML-file of the added supplemental policy

- On the Scope tags page, configure the required scope tags and click Next
- On the Assignments page, configure the required assignment by selecting the applicable group and click Next
- On the Review + create page, review the configuration and click Create
Note: Within the figure above, the focus is on the IDs that are configured within the supplemental Application Control policy. That information can be used to easily find the applied configuration.
Experiencing the supplemental policy
When the supplemental Application Control policy is assigned and successfully applied, it’s time to verify the applied the configuration. That can be done by trying to install applications that are not allowed, but that can also be done by verifying the active code integrity policies. Simply because that provides a quick overview of the applied IDs of the Application Control policies. Navigate to C:\Windows\System32\CodeIntegrity\CiPolicies\Active and locate the PolicyID of the base Application Control policy and the policy ID of the supplemental Application Control policy (as shown below in Figure 2).

More information
For more information about Windows Defender for Application Control and supplemental policies, refer to the following docs.
- Manage approved apps for Windows devices with Application Control policy and Managed Installers in Microsoft Intune | Microsoft Learn
- Application Control for Windows | Microsoft Learn
- Use multiple Windows Defender Application Control Policies – Windows Security | Microsoft Learn
- Set-CIPolicyIdInfo (ConfigCI) | Microsoft Learn
Discover more from All about Microsoft Intune
Subscribe to get the latest posts sent to your email.
Hello Peter,
Maybe you will have an idea. 😉 I try WDAC for several days.
My default base policy with Intune (App Control for Business (Preview)) works.
I try to add supplemental policies to authorise some other apps.
For exemple I try to authorize opening Notepad++ exe for installation.
It works, I can run the exe without the Windows WDAC blue blocking message.
But the installation failed because of message like that :
Code Integrity determined that a process (\Device\HarddiskVolume4\temp\npp.8.6.9.Installer.x64.exe) attempted to load \Device\HarddiskVolume4\Users\XXXUSERNAMEXXX\AppData\Local\Temp\nshE4E1.tmp\UserInfo.dll that did not meet the Enterprise signing level requirements or violated code integrity policy (Policy ID:{63d1178a-816a-4ab6-8ecd-127f2df0ce47}).
or this one :
Code Integrity determined that a process (\Device\HarddiskVolume4\Windows\SysWOW64\rundll32.exe) attempted to load \Device\HarddiskVolume4\Program Files\Notepad++\contextMenu\NppShell.dll that did not meet the Enterprise signing level requirements or violated code integrity policy (Policy ID:{63d1178a-816a-4ab6-8ecd-127f2df0ce47}).
It seems that needed dll are blocked.
I have this for other apps.
Do you have an idea to authorize that please?
Hi Michael,
Apologies for the late reply, I was on holiday. What does your current configuration look like?
Regards, Peter
Hi Peter,
No problem. Thanks for answer. 😉
I can’t add image but my XML did with WDAC wizard is like that :
10.0.0.1
{2E07F7E4-194C-4D20-B7C9-6F44A6C5A234}
{A98E5D7F-5102-4862-94A2-16DDB01C520F}
{63D1178A-816A-4AB6-8ECD-127F2DF0CE47}
Enabled:Unsigned System Integrity Policy
Enabled:Inherit Default Policy
Enabled:UMCI
0
My Supplemental Policy_2024-08-07
2024-08-07
And how are you adding the different apps to the policy?
Regards, Peter
Hello Peter,
I didn’t see that my comment was cut so we didn’t see all the xml.
With the wizard I select the .exe that I want to authorize and I check Issuing CA and Publisher. And some times the Product name. And I create the rule.
And are those DLL-files also signed?
Regards, Peter
I suppose the dll are not signed or not by the same editor. But if we need to validate dll install by the program too, it will be very complicated to use this…
It is indeed often challenging to get it fully up-and-running for all the required apps, with only the really required exemptions..
Regards, Peter
Thanks Peter. 😉
Hi Peter,
do you know if its possible that we can block Exe Files in generell ?
Currently we have the Situation that Apps with UAC are blocked but the app that can be installalled without any permissions.
So we need to block in general AppInstallation.
Hi Matthias,
So, if I understand it correctly, your users can currently install apps like Google Chrome in their user profile. If so, that’s indeed something you can prevent with Application Control (and a lot more).
Regards, Peter