Enrollment Time Grouping and Client-Driven Compliance: Two Intune Features Nobody Told You About

If you've never heard of either of these, you're not behind — Microsoft's own documentation for both sits several clicks deep, and neither has had the kind of plain explanation that tells you what problem it actually solves. This post gives you both: enough concept that a helpdesk analyst could follow along, and enough depth (registry keys, log markers, Graph verification calls) that an engineer can confirm it's actually working.

Who needs to read this

The problem: two kinds of lag that look unrelated but aren't

Here are two tickets that land on different desks but have the same root cause: Intune finding out about something later than it should.

Ticket one. A new starter's laptop finishes Autopilot, reaches the desktop, and the required line-of-business apps aren't there. Nothing failed — the apps just haven't arrived yet. The device shows as enrolled and healthy. Ask again in a few hours and everything is installed. The user's first morning on a new laptop was spent waiting.

Ticket two. A device fails a compliance check for a disabled firewall rule. The user (or an admin) re-enables it immediately. The device is now, in reality, compliant. But Conditional Access still blocks it, Intune still reports it as non-compliant, and nobody did anything wrong — the system just hasn't been told yet. The fix happened in real time; the system found out on its next scheduled check.

Why it happens: group-after-enrollment, and compliance-on-a-timer

ETG: why apps used to take up to 8 hours to show up

Without enrollment time grouping, Intune groups a device the ordinary way: by its inventory properties and group tag, after it has already enrolled. Only once the device is in the right group does Intune know which apps and policies belong to it. Microsoft's own documentation is direct about the consequence: devices grouped this way "often aren't ready for immediate use," and it "can take up to 8 hours post enrollment for devices to receive all apps and policies."

That 8-hour figure isn't a bug — it's a side effect of the ordering. Group membership, then targeting, then delivery, each with their own evaluation cycle. Enrollment Time Grouping collapses the first step by letting you tell Intune the group before the device even exists in your tenant, bound to the enrollment profile itself rather than discovered afterwards.

Client-driven compliance evaluation: why "I fixed it" doesn't mean "it's compliant" yet

The older compliance model is schedule-driven: the device checks in on a timer, Intune evaluates whatever it reported at that check-in, and the result stands until the next cycle. A user who fixes a problem between check-ins is, for all practical purposes, still non-compliant until the clock comes back round.

Client-driven compliance evaluation adds a second trigger that runs independently of the schedule. A small monitor inside the Intune Management Extension watches a defined list of security-relevant values on the device. The moment one of those values changes — BitLocker gets turned back on, a firewall rule is restored, a Defender signature updates — the monitor requests an MDM check-in right then, rather than waiting.

How to verify: a Graph call and a registry read, no guessing

ETG: confirm a policy is actually using it

An enrollment policy with ETG configured can be checked directly through Graph, without opening the admin center at all.

GET https://graph.microsoft.com/beta/deviceManagement/configurationPolicies('{PolicyID}')/retrieveJustInTimeConfiguration

# ---------------- what a configured policy returns ----------------
{
  "targetGroupId": "11111111-2222-3333-4444-555555555555",
  "targetGroupDisplayName": "Shared inventory devices",
  "justInTimeConfigurationEnabled": true
}

# An unconfigured policy returns an empty or null targetGroupId instead.

If you'd rather check the group side, confirm the Intune Provisioning Client is actually an owner — this is the single most common reason ETG silently fails, because the group looks correctly configured in every other respect.

GET https://graph.microsoft.com/v1.0/groups/{GroupID}/owners

# Look for an owner with appId f1346770-5b25-470b-88bd-d5744ab7952c
# displayName is usually "Intune Provisioning Client", occasionally
# "Intune Autopilot ConfidentialClient" on some tenants - same AppId,
# same thing. If neither appears in the owners list, ETG cannot write
# to this group and will fail silently.

Client-driven compliance evaluation: read the monitor's own state

Everything the monitor is doing lives in the registry on the device itself, under the IME's own key. This is read-only — nothing below changes anything.

$base = 'HKLM:\SOFTWARE\Microsoft\IntuneManagementExtension'

$config = Get-ItemProperty -Path "$base\SessionSettings" -Name ComplianceMonitorConfigJson -ErrorAction SilentlyContinue
if (-not $config) {
    Write-Host "No ComplianceMonitorConfigJson found - this device has not received the feature configuration."
}
else {
    $json = $config.ComplianceMonitorConfigJson | ConvertFrom-Json
    [pscustomobject]@{
        Enabled           = $json.Enabled
        PollIntervalSecs  = $json.PollIntervalSeconds
        MaxChecksPerHour  = $json.DciMaxCheckInsPerHourPerDevice
        WatchedSettings   = ($json.Settings -join ', ')
    }
}

# ---------------- output on a device with the feature active ----------------
Enabled           : True
PollIntervalSecs  : 300
MaxChecksPerHour  : 2
WatchedSettings   : ActiveFirewallRequired, BitLockerEnabled, SecureBootEnabled, OsBuildVersion

The IME's own log confirms the monitor is actually running, not just configured. Search for these markers:

The fix: setting up both, step by step

Setting up Enrollment Time Grouping

1. Sign in to the Microsoft Intune admin center.
2. Go to Groups › All groups › New group.
3. Set Group type to Security, give it a clear name, and set Membership type to Assigned — not Dynamic. ETG does not work with dynamic membership rules.
4. Under Owners, add the service principal with AppId f1346770-5b25-470b-88bd-d5744ab7952c. It usually appears as Intune Provisioning Client; search by that AppId if you see a different name or nothing at all.
5. Select Create. You don't need to add any devices or users to this group yet.
6. Go to Devices › Device onboarding › Enrollment, and open (or create) the enrollment policy for your platform — Windows Autopilot device preparation, Apple automated device enrollment, or Android Enterprise.
7. In the policy, add the security group you just created as its enrollment time group. You can add exactly one static group per policy.
8. Save the policy. The setting applies to devices enrolling from this point forward only — it has no effect on devices already enrolled.

Checking whether client-driven compliance evaluation applies to you

This feature isn't something you switch on yourself yet — it's a Microsoft-controlled preview rollout to supported Windows devices. There's no admin center toggle to find. What you can do is confirm whether your devices qualify and are receiving it:

1. Confirm Microsoft Defender is the active antivirus provider on the device. Any other antivirus, even a fully supported one, disqualifies the device from the fast path entirely.
2. Confirm the Intune Management Extension is at version 1.103.101.0 or later — run the version check in the quick reference table below.
3. Run the read-only registry check from the previous section to see whether the device has actually received a ComplianceMonitorConfigJson configuration yet.
4. Check the IME log for [ComplianceMonitor] Start entered to confirm the monitor is live, and watch for decision=Invoked after deliberately toggling a watched setting (for example, briefly disabling then re-enabling a firewall rule on a test device) to see the fast path actually fire.

Proof it worked: what success looks like for each

ETG: the device is in the group before it finishes setup

Check the security group's membership while the device is still mid-Autopilot — on the Please wait screen, before the user ever reaches the desktop. If ETG is working, the device already appears as a member at that point, not minutes or hours after.

Also worth checking the failure report, which exists specifically to catch the cases where this doesn't happen:

Client-driven compliance evaluation: a real-time fix clears in about a minute

On a pilot device with the monitor confirmed active, deliberately disable a watched setting, fix it, and time how long it takes to clear.

# Firewall rule disabled at 10:14:02, re-enabled at 10:14:40

[ComplianceMonitor] detected change: ActiveFirewallRequired False -> True
[ComplianceMonitor] decision=Invoked, reason=SettingChanged, setting=ActiveFirewallRequired
[ComplianceMonitor] MDM check-in requested

# Compliance status in the Intune admin center updated to Compliant
# at 10:15:31 - 89 seconds after the fix, not the next scheduled cycle.

Quick reference: every registry key, signal and requirement

Enrollment Time Grouping

Client-driven compliance evaluation

Glossary

Frequently asked questions

References

• Set up enrollment time grouping — Microsoft Learn. The primary source for ETG: requirements, the exact console steps, the Graph workaround for the Apple ADE removal gap, and the failure report.
• Windows Autopilot device preparation — create a device group — Microsoft Learn. The Windows-specific walkthrough this post's setup steps are based on, including the Intune Provisioning Client service principal detail.
• Device compliance policies in Microsoft Intune — Microsoft Learn. The umbrella documentation client-driven compliance evaluation sits under.

Microsoft MVP community deep-dives

Related reading on EndpointWeekly

• Autopilot Device Preparation Needs an Assigned Group, Not a Dynamic One — the deeper dive on the group-ownership gotcha referenced in this post's verification section.
• Intune 2609: Faster Win32 App Delivery — a different mechanism attacking a related but distinct problem: push-triggered IME check-ins after assignment, rather than group membership at enrollment time.