Before We Start

Third-party device control and DLP solutions often provide features to block program execution.

These days, asking an AI about how each feature works usually gives you a decent understanding of the underlying logic.

When I looked into this, the three native Windows options most commonly recommended were:

• IFEO (Image File Execution Options)
• AppLocker
• WDAC (Windows Defender Application Control)

Among these, WDAC has been rebranded as App Control for Business and is now used under that name.

In this post, I'll walk through how to deploy an App Control for Business policy through Intune.

1. What Is App Control for Business (WDAC)?

App Control for Business is still commonly referred to as WDAC in the field. It's frequently compared with AppLocker. Here's how they differ:

App Control for Business vs. AppLocker

Item App Control for Business (WDAC) AppLocker

Key Difference

While AppLocker operates as a user-mode policy, WDAC supports kernel-level enforcement based on Code Integrity. That's the most significant distinction.

2. Creating a Policy

WDAC requires you to create policies in XML format. Microsoft provides a dedicated tool for this.

Installing the App Control Policy Wizard

You can download the Microsoft App Control Wizard

and use the Policy Creator to build XML-based policies.

Operationally, the workflow is: deploy a Base Policy → supplement it with Supplemental Policies.

Note that Supplemental Policies can only add Allow rules — they cannot lift blocks defined in the Base Policy, nor can they add new deny rules.

Operational Structure

The typical flow is:

Deploy Base Policy
↓ Add exceptions via Supplemental Policy

Notes on Supplemental Policies

• Can add Allow rules
• Cannot remove existing Block rules
• Cannot add new Deny rules

In other words, all blocking (Deny) must be designed at the Base Policy level.

This post does not cover Supplemental Policy deployment.

2.1 The Three Base Templates

The wizard provides three templates out of the box:

Template Allowed scope Security Flexibility

Think of these three as a spectrum — stricter on the left (DefaultWindows), more flexible on the right (SignedAndReputable). Pick the balance that fits your organization's security requirements and operational flexibility.

Strict
DefaultWindows
↓ AllowMicrosoft
↓ SignedAndReputable
Flexible

3. Testing Default Windows Mode

Applying Default Windows Mode

Select Default Windows Mode in the wizard.

Disabling Audit Mode

To verify actual enforcement behavior, disable Audit Mode.

Proceed with Next.

Generating the Policy

Complete the wizard to generate the XML.

4. Deploying the Policy

Intune Admin Center

Navigate to Endpoint Security → App Control for Business.

After creating a policy:

• Name the policy

• Upload the XML

• Assign targets and create the policy

Verifying Policy Application

Check the applied policy files at:

C:\Windows\System32\CodeIntegrity\CIPolicies\Active

You can compare the folder contents before and after application.

Testing

Try launching Chrome.

Result: Blocked.

Checking Policies via PowerShell

CiTool.exe -lp

You can also verify the applied policies using this PowerShell command.

5. Designing a Real-World Policy

In practice, most enterprise environments start with AllowMicrosoft or SignedAndReputable as the Base Policy, then layer in Allow rules for LOB applications and Deny rules for risky binaries as needed.

DefaultWindows is theoretically the most secure, but the exception-management overhead is usually too high for general office environments. It tends to be reserved for regulated industries or fixed-function devices.

5.1 Designing an AllowMicrosoft Policy

Template Creation

Select Allow Microsoft Mode.

Confirming Chrome Is Blocked

Out of the box, Chrome execution is blocked.

Checking the Event Log

You can review enforcement events at:

Applications and Services Logs → Microsoft → Windows → CodeIntegrity → Operational

The log will show that chrome.exe failed to meet the conditions required by the applied Policy ID and was therefore blocked.

For whitelist operation, I chose not to modify the template itself — instead, I added only the necessary exception paths. Below is an example of how I configured those exceptions.

Adding Whitelisted Path Exceptions

Use Add Custom.

Rather than creating rules path-by-path, I registered the main exception paths using wildcards (*) for broader coverage. This dramatically reduces maintenance overhead — you don't need to update the policy every time a subfolder or new file is added.

That said, overly permissive wildcards can become bypass points for malware, so it's essential to limit wildcards to the narrowest scope actually needed.

Once the Allow rules are complete, deploy the policy.

Result

Chrome now launches successfully.

Any files outside the allowed paths are still blocked. For example, running a Chrome installer from the desktop will be blocked. This effectively prevents users from installing arbitrary applications. If needed, you can add paths like Downloads to the Allow rules to permit installation.

You can confirm in the event log that execution was blocked by policy.

What This Achieves

This structure delivers:

• Prevention of arbitrary application installation
• Execution limited to approved paths only

5.2 Designing a SignedAndReputable Policy

Finally, let's look at Signed and Reputable Mode.

Template Selection

Select Signed and Reputable Mode.

Confirming Policy Application

Check the applied policy files and review the event log.

Testing Chrome Execution

Chrome runs successfully — allowed based on ISG reputation.

6. ISG (Intelligent Security Graph)

ISG is a reputation-based allow mechanism that leverages Microsoft's global security signals to determine whether an application can be trusted.

For organizations with no prior experience running whitelist-based policies, starting with this template is usually the most realistic option.

Most IT environments operate on the principle of "allow broadly by default, block only specific problematic applications" — and the SignedAndReputable mode fits this pattern best.

7. SignedAndReputable Operational Design Flow

Step 1

Deploy the SignedAndReputable Base Policy.

Step 2

Enable Managed Installer — this automatically trusts applications deployed via Intune.

Step 3

Add Allow rules for key execution paths.

Step 4

Add Deny rules for specific risky applications (for example, WinRAR).

Result

• Chrome → Allowed

• WinRAR → Denied

Important

Deny rules take precedence over Allow rules.

Monitoring via Advanced Hunting

If your devices are onboarded, you can monitor enforcement events through Advanced Hunting:

DeviceEvents
| where ActionType in ("AppControlCodeIntegrityPolicyAudited",
                       "AppControlCodeIntegrityPolicyBlocked")
| summarize
    AuditCount = countif(ActionType endswith "Audited"),
    BlockCount = countif(ActionType endswith "Blocked"),
    LastSeen = max(Timestamp)
    by DeviceName, FileName, FolderPath
| sort by AuditCount + BlockCount desc

Final Thoughts

In my opinion, the most practical starting point is the combination:

SignedAndReputable + Allow rules for key execution paths + Deny rules for specific risky applications

This strikes the best balance between security and operational feasibility for most enterprise environments.

In this post, we will walk through how to configure a Shared PC (Shared Device) using Microsoft Intune.

Shared PCs are commonly used in environments such as:

• Meeting rooms
• Training centers
• Lobby kiosks
• Factory floor terminals

Because multiple users access the same device, credential management and data persistence prevention are critical.

For example:

• User A finishes work but forgets to sign out.
• User B logs in next and unintentionally gains access to User A’s session or data.

This scenario can create serious risks from a privacy and compliance perspective.

To mitigate this risk, Intune provides the Shared multi-user device policy, which allows you to automatically delete user profiles when users sign out.

Official documentation:
Shared or multi-user Windows device settings in Microsoft Intune - Microsoft Intune | Microsoft Learn

Youtube: https://youtu.be/GNIXtqwN6Ck

Step 1. Enroll the Device into Intune

Before deploying policies, the device must first be enrolled in Intune.

Even if the device is intended for shared usage, enrollment should be performed using an administrator or master account.

After enrollment:

1. Create a Security Group for policy deployment
2. Add the shared PC to the group

Only after completing these steps can the policy be successfully assigned.

Step 2. Create a Shared Multi-User Device Policy

Navigation Path

Intune Admin Center > Devices > Windows > Manage Devices > Configuration > Create > New Policy

Select the following options:

• Platform: Windows 10 and later
• Profile Type: Templates
• Template: Shared multi-user device

Then assign a policy name.

Policy Configuration Example

Below is an example configuration:

Key Design Intent of This Configuration

1️⃣ Immediate Profile Deletion Upon Sign-out

When a user signs out, their profile is immediately deleted.

→ Prevents residual data from remaining on the shared device.

Note: The contents of the Downloads folder are also removed after sign-out.

2️⃣ Local Storage Restriction

By disabling local storage, files are not permanently stored on the shared device.

3️⃣ Sign-in Required After Sleep

• Device enters sleep after inactivity
• User must sign in again when waking the device

→ Prevents session hijacking

4️⃣ When Entra ID Sign-in Is Allowed

If users sign in with their M365 (Entra ID) account:

• OneDrive integration is available
• Personal environment is maintained during the session
• Profile is deleted after sign-out

This enables temporary personalization while maintaining shared-device security.

Assigning the Policy

Assign the policy to the device group and create it.

Once applied:

• Users can sign in using Guest or Domain accounts

• A new profile is created each time a user signs in

• Only the Downloads folder is accessible in File Explorer

• Data inside Downloads is removed after sign-out

Considerations When Using Guest Accounts

Guest accounts do not require a password by default.

If a user leaves without signing out:

• The next user may access the active session
• Previous user activity may be visible

This can create a security vulnerability.

Advantages of Allowing Entra ID Sign-in

When Domain (Entra ID) sign-in is enabled:

• Re-authentication is required after screen lock
• Session protection is enhanced
• Overall security posture improves

Depending on the enterprise environment, Entra ID-based sign-in is generally recommended.

Additional Mitigation for Guest-Based Environments

If operating primarily with Guest accounts, consider implementing:

• Automatic forced sign-out after a defined idle time
• Screen lock enforcement
• Additional session protection policies

This can be achieved through PowerShell scripts or Intune remediation scripts.

Many IT engineers and managers are unaware that if your Hyper-V host server is running Windows Server Datacenter Edition, you can use AVMA (Automatic Virtual Machine Activation) keys to automatically activate guest VMs. Leveraging this feature simplifies the activation process and makes management much easier.

In this post, I’ll walk you through how AVMA works, how to use it, and some practical tips for automating Windows Server VM activation on Hyper-V.

Youtube: https://youtu.be/deyWNdW6S-U

What is AVMA?

AVMA (Automatic Virtual Machine Activation) allows you to activate Windows Server virtual machines running on a Datacenter edition Hyper-V host without needing to enter a product key for each VM. This is especially useful for environments where you frequently deploy or redeploy VMs.

Reference:
Automatic Virtual Machine Activation in Windows Server | Microsoft Learn

• Guest VM: The version of Windows Server you can activate depends on the host OS version.

Supported Host and Guest Combinations

For example, if your host is Windows Server 2025, you can activate guest VMs from 2012 R2 up to 2025 using AVMA keys.

AVMA Keys for Each Windows Server Version

You can find the official AVMA keys in Microsoft’s documentation. Here are some examples:

How to Use AVMA Keys During Installation

When installing Windows Server as a VM on your Hyper-V Datacenter host, you can enter the AVMA key during setup:

Choose a licensing method:
Select “Use a product key” and enter the AVMA key for your OS version.

Select the image:
The installer will recognize the OS version that matches the AVMA key.

Post-Installation Activation

After installation, you might notice that Windows is not yet activated. Here’s how to proceed:

Check Activation Status:
Go to Start > Settings > System > Activation. If not activated, you may see an error (e.g., 0xC004F012).

Activate via Command Line:
Open PowerShell or Command Prompt as Administrator and run:

This will trigger activation using the AVMA key.

Verify Activation:
The activation state should now show as “Active”.

Activating an Already Installed VM

If you’ve already installed the OS without entering a key, you can still activate:

Go to System Settings:
Start > System > About > Product key and activation.

Change Product Key:
Enter the appropriate AVMA key and proceed with activation.

Next

Activate

Pro Tip: Using Sysprep

After completing activation, running Sysprep is highly recommended for managing test environments efficiently. This avoids repetitive product key entry and ensures your template VMs are ready for rapid deployment.

Conclusion

AVMA is a powerful feature for anyone managing Windows Server VMs on Hyper-V Datacenter hosts. It streamlines activation, reduces manual work, and helps maintain compliance. Make sure to use the correct AVMA key for your guest OS version, and enjoy hassle-free VM deployments!