Windows 10 MDM policy refresh

This week is all about the Windows 10 MDM policy refresh. More specifically, the policy refresh behavior starting with Windows 10, version 1903. Starting with Windows 10, version 1903, the policy refresh got a lot more interesting. Before Windows 10, version 1903, the policy refresh would simply tattoo the settings once during the device checking. Starting with Windows 10, version 1903, the settings that are implemented by the Policy CSP are actually refreshed during the device check-in. Not just tattooed once, but actually re-applied when for example adjusted by the user. Also, similar to that, those settings are also removed when no longer assigned. In this post I’ll have a look at the triggers for a device check-in, the different device check-in actions and the difference in behavior of the device check-ins (focused on the Policy CSP).

Triggers for device check-ins

Let’s start by looking at the multiple triggers for the device check-in. I would like to differentiate between the following three different type of device check-in triggers:

  • A notification – The check-in can be triggered by a notification from Microsoft Intune.
  • A scheduled check-in – The check-in can be triggered by a scheduled task.
  • A manual check-in – The check-in can be triggered manually by the user.

Notifications that trigger device check-ins

The challenge with notifications that trigger a device check-in is that it’s not an exact science and that we’re mainly bound to the docs about the process. When looking at the notifications that trigger device check-ins there are basically different actions, performed by the administrator, that can trigger a notification. The triggered notification will notify the device to check-in with Microsoft Intune. Actions that trigger a notification are for example when a policy, a profile, or an app is assigned (or unassigned), updated, or deleted.

The device will check-in with Microsoft Intune when the device receives a notification to check-in. The challenge is that it’s up to the device to actually check-in. A different priority, so to say, is for targeting a device or user with an action, like a lock, a passcode reset, an app, a profile or a policy assignment. With those actions Microsoft Intune immediately notifies the device to check in to receive these updates.

There are also changes that don’t cause a notification to the devices. For example revising the contact information in the Company Portal app don’t cause an immediate notification to be send to the device.

This device check-in will refresh the already applied Policy CSP settings and will also remove unassigned Policy CSP settings.

Scheduled device check-ins

The scheduled device check-ins are more clear. In that case we’re not mainly stuck to the docs, as the configuration is available in the Task Manager. After the device is enrolled in Microsoft Intune, three scheduled tasks will be enabled and run on different schedules. Let’s have a close look at those scheduled tasks.

Frequency of scheduled device check-ins

Once a Windows 10 device is enrolled in Microsoft Intune, three different scheduled tasks will be used to trigger the compliance and configuration check-ins. Those scheduled tasks can be found in the Task Scheduler at Microsoft > Windows > EnterpriseMgmt > {tenantId}.

Table 1 provides an overview of the different check-in schedules that belong to the different scheduled tasks. The first scheduled task repeats every 3 minutes for the first 15 minutes after the enrollment. The second scheduled task starts 15 minutes after the enrollment and repeats every 15 minutes for 2 hours and the third scheduled task starts 2 hours and 15 minutes after the enrollment and repeats every 8 hours indefinitely.

Table 1: Check-in frequency
Schedule Frequency
Schedule #1 created by the enrollment clientAfter triggered, repeat every 3 minutes for a duration of 15 minutes
Schedule #2 created by the enrollment clientAfter triggered, repeat every 15 minutes for a duration of 2 hours
Schedule #3 created by the enrollment clientAfter triggered, repeat every 8 hours indefinitely

Note: The behavior for devices without user affinity is different, as it’s up to the device to check-in.

Action during scheduled device check-ins

During the device check-in the deviceenroller.exe will be started as a program. The different scheduled tasks, used for triggering the compliance and configuration check-ins, use slightly different parameters.

Table 2 provides an overview of the different check-in actions. The deviceenroller.exe program itself is still a little bit of a mystery, as it’s being user for enrolling devices en also for check-ins. Both by using different parameter. Sadly not all parameters speak for itself, which makes it a little guesswork to fully understand.

This device check-in action will also refresh the already applied Policy CSP settings.

Table 2: Check-in action
Schedule Action
Schedule #1 created by the enrollment client%windir%\system32\deviceenroller.exe /o “{enrollmentId}” /c
Schedule #2 created by the enrollment client%windir%\system32\deviceenroller.exe /o “{enrollmentId}” /c
Schedule #3 created by the enrollment client%windir%\system32\deviceenroller.exe /o “{enrollmentId}” /c /b

Note: The documented actions can also be used to “manually” trigger a device check-in.

Manual device check-ins

The manual device check-ins are also in the gray area. It’s clear that the manual device check-in can be triggered by using the Settings panel. Navigate to Accounts > Access work or school and click Sync. Another option is by using the Company Portal app. Navigate to Settings and click Sync.

During the device check-in the omadmclient.exe will perform actions to sync the policies.

This device check-in will not refresh the already applied Policy CSP settings.

Recognize different device check-ins

I noticed that the easiest method to fully recognize the difference in device check-ins, is by using the Event Viewer. When opening the Event Viewer, simply navigate to Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider and look at for Event ID 208. The difference will be in the origin of the started session, as shown in the following list:

  • A notification – MDM Session: OMA-DM session started for EnrollmentID ({enrollmentId}) with server: (MS DM Server), Server version: (NULL), Client Version: (1.2), Origin: (0x7), Initiator: (0x0), Mode: (0x2), SessionID: (0x7C), Authentication Type: (0x3).
  • A scheduled check-in – MDM Session: OMA-DM session started for EnrollmentID ({enrollmentId}) with server: (MS DM Server), Server version: (NULL), Client Version: (1.2), Origin: (0x3), Initiator: (0x0), Mode: (0x2), SessionID: (0x75), Authentication Type: (0x3).
  • A manual check-in (by using Settings panel) – MDM Session: OMA-DM session started for EnrollmentID ({enrollmentId}) with server: (MS DM Server), Server version: (NULL), Client Version: (1.2), Origin: (0x5), Initiator: (0x0), Mode: (0x2), SessionID: (0x76), Authentication Type: (0x3).
  • A manual check-in (by using Company Portal app) – MDM Session: OMA-DM session started for EnrollmentID ({enrollmentId}) with server: (MS DM Server), Server version: (NULL), Client Version: (1.2), Origin: (0xD), Initiator: (0x0), Mode: (0x2), SessionID: (0x77), Authentication Type: (0x3).

Example Windows 10 MDM policy refresh

Now let’s end this post by having a look at an example of the Windows 10 MDM policy refresh. Below on the right I’ve adjusted the telemetry setting of the device and below on the left I’m manually running the device check-in action of the scheduled task (yes, I’ve tested it multiple times). It end’s by refreshing the telemetry value immediately after the check-in.

More information

For more information about installing applications for devices, please refer to the doc about Common questions, issues, and resolutions with device policies and profiles in Microsoft Intune.

29 thoughts on “Windows 10 MDM policy refresh”

  1. HI Peter,

    Do you have an official Microsoft document on the Windows 10 MDM policy refresh that you can point me to?

    Thank you,

    Reply
  2. Think a light edit required at the end of the doc:
    “…Below on the right I’ve adjusted the telemetry setting of the device and below on the ##LEFT## I’m manually running…”

    Thank you for these super helpful Intune, Autopilot & MDM articles – please keep them coming !

    Reply
  3. Hi Peter, as the policy refresh is (worst case) only done every 8 hours this causes the compliance status to be inacurate. For example: if bitlocker is disabled by the user, detection by Intune could take up to 8 hours and during that time frame the user still keeps access to corporate resources based on conditional access.

    In our case end users have local admin rights, although all important security measures are enforced using policies, still Windows contains some back doors to (temporary) bypass Intune policies.

    Whats your opinion about this? From my point of view this should be considered as a security risk.

    Reply
    • Hi Ingmar,
      Nearly all available compliance checks for Windows 10 devices have quite a big impact on the user to change and I’m wondering what’s in it for the user to change it.. What is it exactly that you’re afraid of?
      Regards, Peter

      Reply
  4. Hi Peter,

    There is some really good content on your site, so thank you.
    Regarding the above, it seems a little limiting to re-apply the settings again specifically for settings that may have been defined at device enrolment (set the users Timezone as an example) but without the ability for these to be overridden by the user thereafter.

    Imagine the user travels and changes the timezone to the country they are currently in, this means every 8 hours the timezone will revert back to the CSP item configured within Intune (Which in reality only needs to be a “apply Once” setting). therefore this will then cause people to miss meetings etc as the calendar notifications use the system clock.

    There must be an easy way to Set the required settings as a “default” for the user and then no longer re-apply the settings. The timezone is just one example that springs to mind, however I expect there are other user initiated actions that will occur during the life-cycle of the device that will make the device unusable if settings keep getting reverted.

    Obviously moving back to on-premise GPO’s is one way to overcome this as we have a greatly control on how the policies apply, however if we are truly to embrace modern management, then there needs to be a happy medium in applying settings, specifically “user based settings”, where you may want to set some “defaults” but these can then be overwritten by the user as required.

    Reply
    • Hi Tom,
      I agree, it would be easy to have more control on when and how settings apply. For now the only way to play with this is with dynamic targeting (were possible).
      For product suggestions make sure to drop them at the Intune User Voice.
      Regards, Peter

      Reply
  5. Hi Peter, this is great information thank you.

    Reference the EventID 208 and the “Origin: (0x0)” values, where did you find what the hex value represents?

    I have events with 0x25,0x26 and 0xF values and am trying to work out what they are. I used the following “one liner” to find them.

    Get-WinEvent -LogName ‘Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin’ | ? ID -eq 208 | % { $_.Message | ? { $_ -notmatch ‘Origin:\s\(0x(7|3|76|77)\)’ } }

    e.g
    MDM Session: OMA-DM session started for EnrollmentID xxxxGUIDxxxx with server: (MS DM Server), Server version: (3.0), Client Version: (1.2), Origin: (0x25), Initiator: (0x0), Mode: (0x2), SessionID: (0x5D), Authentication Type: (0x1)

    MDM Session: OMA-DM session started for EnrollmentID xxxxGUIDxxxx with server: (MS DM Server), Server version: (3.0), Client Version: (1.2), Origin: (0x26), Initiator: (0x0), Mode: (0x2), SessionID: (0x5B), Authentication Type: (0x1).

    MDM Session: OMA-DM session started for EnrollmentID xxxxGUIDxxxx with server: (MS DM Server), Server version: (3.0), Client Version: (1.2), Origin: (0xF), Initiator: (0x0), Mode: (0x2), SessionID: (0x5A), Authentication Type: (0x1).

    Client is Win10 Enterprise version 2004 build 19041.630 x64

    Many thanks,
    Craig

    Reply
  6. Thanks, Peter. There is a lot of good information here.

    What I am seeing is that not all policies get refreshed on device check-in. Firewall settings for example. I have an Endpoint Security policy that enables the firewall for all 3 network profiles (Domain, Private and Public). An administrator is able to turn off the firewall for any or all of the network profiles, but when the device check-in happens, the firewall is not re-enabled for the network profile.

    Is the refresh only applicable to the Policy CSP?

    Thanks,

    Reply
    • Hi Dan,
      I’ve only verified the behavior for the Policy CSP (of course I didn’t test every setting) and I haven’t seen the behavior for any other CSP yet. Of course that can change in the future.
      Regards, Peter

      Reply
  7. Hey Peter,
    Another great article that I stumbled upon in my reading….
    I realize this is a 4 year old article and things have changed.
    Some observations in the new Event Viewer (ID 208) results for check-ins:
    – Origin now seems to be labelled “UserAgentOrigin”
    – origin numbers seemed to have changed as follows

    A manual check-in (by using Company Portal app): UserAgentOrigin: (0x8)
    A manual check-in (by using Settings panel): UserAgentOrigin: (0x1)
    A notification – MDM Session: UserAgentOrigin: (0x7)
    A scheduled check-in – MDM Session: UserAgentOrigin: (0x2)

    Cheers and thanks for sharing your knowledge with everyone.

    Reply
  8. We have some machines that have been removed from a Group, but are unable to sync. The timezone Device Config (that we have tried to remove) is incorrect and so the users clock is being changed, even though they havent sync’d with InTune for ages. Is that how it works, do configs get reapplied even if the sync is unsuccessful?

    Reply
  9. Good morning Peter,
    This documentation (estimated frequency) is only for post-registration updates, correct?
    I have an environment where the device registration notification to the Windows end user takes 4 hours. Is this expected behavior or am I in trouble?

    I didn’t find any documentation that guides me on this topic.

    Thanks.

    Reply

Leave a Reply to Peter van der Woude Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.