Apps en policies gefaseerd uitrollen met deployments in Intune
Rol een Win32-app of een Settings catalog- of endpoint security-policy voor Windows gefaseerd uit in ringen, met vaste wachttijden.
- Onderwerp: Intune
- Platform: Windows
6 min lezenNieuw

Een gebruiker zet de firewall op een laptop uit, of BitLocker staat na een herinstallatie nog niet aan. Intune en Conditional Access werken met de compliance-status van de laatste check-in. Zonder aanleiding checkt een apparaat dat al langer is ingeschreven ongeveer eens per acht uur in.
Intune heeft daar in de week van 14 september 2026 iets aan veranderd: Windows-apparaten kunnen zelf een nieuwe compliance-evaluatie aanvragen als een relevante instelling verandert. In deze blogpost lees je hoe die client-driven compliance evaluation werkt, welke instellingen eronder vallen en waar je in het Intune admin center de gerapporteerde compliance-status bekijkt.
Een compliance policy wordt geëvalueerd als het apparaat incheckt bij Intune, al leidt niet elke synchronisatie tot een nieuwe berekening. De gewone onderhoudssynchronisatie vindt volgens Microsoft ongeveer elke acht uur plaats, en een apparaat krijgt er hooguit één per 6,5 uur. Daarnaast bestaan er synchronisaties die door een wijziging worden gestart, bijvoorbeeld als je een policy toewijst. Vlak na de inschrijving checkt een Windows-apparaat tijdelijk vaker in.
Met client-driven compliance evaluation hoeft het apparaat niet op de volgende onderhoudssynchronisatie te wachten als een compliance-instelling verandert. Microsoft beschrijft twee mechanismen die elk een check-in kunnen aanvragen:
Realtime detectie geldt voor deze instellingen:
| Signaal | Relevante instelling(en) in de compliance policy |
|---|---|
| Firewall | Firewall |
| Antivirus | Antivirus |
| BitLocker | Require BitLocker, Encryption of data storage on a device |
| Status van Microsoft Defender | De instellingen onder Defender, zoals Microsoft Defender Antimalware |
| Build van het besturingssysteem | Minimum OS version, Maximum OS version, Valid operating system builds |
| Real-time protection | Real-time protection |
| Secure Boot | Require Secure Boot to be enabled on the device |
Microsoft publiceert alleen de signalen in de linkerkolom, niet welke policy-instellingen erbij horen. De rechterkolom is een eigen lezing: een hulpmiddel om je policy na te lopen, geen garantie dat elke genoemde instelling afzonderlijk realtime opnieuw wordt beoordeeld.
💡 Let op: Microsoft is niet eenduidig over de status. De documentatie zelf noemt geen preview, maar de aankondiging in What’s new en de pagina over compliancerapportage linken naar een kopje met -preview in het adres. Houd er rekening mee dat het gedrag nog kan veranderen.
De documentatie noemt geen instelling om de functie aan te zetten en beschrijft het als iets wat ondersteunde apparaten zelf doen.
Een snellere evaluatie verandert de compliance-status alleen als je policy de gewijzigde instelling ook controleert. Staat een instelling op Not configured, dan beoordeelt Intune die niet als voorwaarde voor compliance.
💡 Let op bij Require BitLocker: die waarde wordt via Device Health Attestation alleen bij het opstarten gemeten. Een apparaat waarop de versleuteling net klaar is, wordt pas compliant na een herstart, ook als de wijziging zelf snel wordt opgemerkt.
De periodieke controle loopt via de Intune Management Extension. Die wordt niet altijd geïnstalleerd: Intune zet de IME op een apparaat dat aan de voorwaarden voldoet zodra je er bijvoorbeeld een PowerShell-script, een Win32-app, een remediation of een discovery script voor custom compliance aan toewijst. Windows in S mode wordt niet ondersteund.
Je controleert de IME op het apparaat zelf: in Task Manager staat dan de service IntuneManagementExtension. De documentatie zegt niet of de realtime detectie ook van de IME afhangt.
Compliance-rapporten in Intune worden bijgewerkt als een apparaat incheckt. Omdat een apparaat met client-driven compliance evaluation vaker uit zichzelf incheckt na een wijziging, kunnen de rapporten van zo’n apparaat ook sneller bijgewerkt zijn.
Deze rapporten tonen de status van de laatste check-in. Ze laten niet zien welk mechanisme een evaluatie startte, of hoeveel sneller die was. Overzichten en detaillijsten worden bovendien niet altijd tegelijk bijgewerkt, waardoor de aantallen tijdelijk kunnen verschillen.
Intune heeft een ingebouwde begrenzing voor deze extra evaluaties. Volgen er veel wijzigingen kort op elkaar, dan kan een deel pas in een latere ronde verwerkt worden. Snel is dus niet hetzelfde als direct.
Voor de gebruiker verandert er weinig zichtbaars. Het verschil zit vooral in de toegang: wordt een apparaat niet-compliant, dan kan een Conditional Access-beleid dat een compliant apparaat vereist de toegang eerder blokkeren. Is het probleem opgelost, dan kan de toegang ook eerder terugkomen. Hoe zo’n beleid eruitziet, lees je in Sterkere security met Conditional Access: MDM en compliance vereist.
Een bestaande sessie stopt niet op het moment dat Intune de nieuwe status heeft. Conditional Access beoordeelt de toegang opnieuw als een app een nieuw toegangstoken ophaalt. Zonder continuous access evaluation (CAE) is zo’n token standaard een uur geldig; in een CAE-sessie kan dat oplopen tot 28 uur. Compliance hoort niet bij de gebeurtenissen die CAE tussentijds afdwingt, en Microsoft documenteert niet hoe snel een compliance-wijziging een lopende CAE-sessie beëindigt.
Wie niet wil wachten, kan zelf de status laten controleren in de Company Portal-app via Devices > Check Status, of synchroniseren via Settings > Sync.
📚 Meer lezen: How compliance calculation is triggered on Windows devices.
Client-driven compliance evaluation kan de tijd verkorten tussen een wijziging op een ondersteund Windows-apparaat en de bijgewerkte compliance-status in Intune. Dat geldt alleen voor de instellingen die je policy echt controleert, en throttling of de herstart die Require BitLocker nodig heeft kan het vertragen. Kijk je Windows-policy dus na op de instellingen uit de tabel.