Last Updated on February 15, 2023 by rudyooms

In this new blog, I am going to take a closer look at what is exactly happening when you press the “Check Access” button in the Company Portal. I will divide this blog into multiple parts

1. Introduction
2. Clicking on “it”
3. Give it a sec!
4. Taking a closer look
5. NodeCache
6. Some Other Compliance Checks
7. The ExpectedValue
8. False Positive
9. The Compliance Flow
10. Let’s sing a song!

1. Introduction

Last year I received an additional question while I was trying to answer a question on Reddit. As shown below, the OP asked me the question of what the device status check was actually doing

I guess this question was a bit different than the blog I already wrote about build-in compliance policies

Intune and the built-in device compliance policies (call4cloud.nl)

With the device status check question, the OP was referring to the “Check Access” button and what is happening in the background when you press it and press it and press it like a maniac!

I am going to dedicate this blog to that button! Let’s see what happens when pressing this magical button of pleasure.

2. Clicking on “it”

When we decide to “only” press the “Check Access” button in the magical place of the Company Portal (Almost sounds like Tahiti) not that much is happening in the background….at first…

When watching fiddler and pressing the “Check Access” button we will notice that it will perform a “get” operation to the URL almost every 30 seconds: https://fef.amsub0302.manage.microsoft.com/StatelessIWService/Devices

The device will try to check the device if it is fit for compliance

In this get operation we will notice that the device will try to fetch the most recent compliance summary Intune has about the device. In this summary, there is a section on “NonCompliantRules”. If the device isn’t compliant it will be mentioned in this section

3. Give it a sec!..OR

As shown in the previous part, the check access button doesn’t do much right? Wrong!! When you have a bit of patience and just wait some time before pressing that button again and again and again, we will spot something more.

Why? Because if we wait long enough, we will notice that the device would also start reaching out to the r.manage.microsoft.com/devicegatewayproxy/cimhandler.ashx URL

In this “Post”, the device makes, I noticed some keywords “NodeCache”, and “ChangedNodes” Almost “as if” the device starts syncing and handing over the latest cached configuration on the device.

4. Taking a closer look

So when we combine the “Get” and the “Post” operations to both of the Microsoft Urls I showed you previously we can start creating a simple Fiddler flow about what happens when pressing the “Check Access” button.

Before getting to the actual flow, I always combine all sorts of information to get to the real flow, so let’s start by taking another closer look at Fiddler!

I decided to make my device “NON-compliant” by disabling the Firewall and making sure the compliance policy to require the firewall to be enabled was configured

As shown below, I changed the compliance rule to require the Firewall to be enabled!

After making sure the prerequisites were configured, I pressed the “Check Access” button. Let’s see what happens when watching Fiddler.

1. The device will perform a POST operation to

https://fef.amsub0302.manage.microsoft.com/StatelessIWService/Devices(guid’a903f3c6-ace8-440c-83c3-c3b5b2a1f3df’)/CheckCompliance?

But without any information about the device or its status!!!!

2. The device will perform a GET to the same URL and gets back a JSON with some Check Compliance settings in it

Looking at the NonCompliantRules, it looks like this is still the “old compliant version” as my device wasn’t compliant anymore with the firewall disabled!

3. After receiving the old JSON I noticed that the device will “eventually” perform a post to

https://r.manage.microsoft.com/devicegatewayproxy/cimhandler.ashx

In this “post operation“, we will notice the AADusertoken

And some details about the device:

• ./DevInfo/HWDevID:

• ./DevInfo/DevID

• I guess after letting the service know, who is knocking on the door it will POST general information about MDM configuration capabilities on the device.

4. Now the service knows about the MDM configuration capabilities of the device it will post information about all of the “Nodes” that changed.

5. After posting the changed device settings to the r.manage.microsoft service, the device will again establish a connection to https://fef.amsub0302.manage.microsoft.com to determine if the device is still compliant or NOT. As shown below in the response we got, we now notice the NonCompliantRules.

Please take A good look at the “ExpectedValue”

When opening the Company Portal, we will notice that the device is indeed no longer compliant and is failing on the Firewall Status

5. NodeCache

When taking a closer look at different kinds of compliance settings and watching Fiddler I noticed that each time it mentioned a different “Changed” node. This example below is the one when playing around with the Firewall Compliance rule.

When looking at the “ChangedNodesData” I noticed that it mentions 22. NodesData, that rings a bell or two! Some time ago I wrote a blog about why you could run into the -201681112 error when you added a local admin. In this blog below I also mentioned the expected value and the NodeCache!

Remediation Error -201681112 when adding a Local Admin (call4cloud.nl)

Let’s find out if we could spot something in the registry mentioning Nodes 22, shall we? So I opened the provisioning\NodeCache\CSP\Device\MS DM Server\Nodes and opened the 22 node

As shown below, it is pointing us to the Firewall/Status… That can’t be a coincidence, right? With the Firewall being disabled, the expected value is 2

Did you also spot the NodeUri? This NodeUri refers to the ./vendor/MSFT/DeviceStatus CSP.

If we take a look with WMIExplorer (Running with System privileges) we could also spot the same status

When looking at the documentation of this CSP, it mentions that the DeviceStatus configuration is used by the enterprise to keep track of device inventory and query the state of COMPLIANCE of these devices. I guess we are on the good track here!

When we turn back on the heater and enable the Firewall and synced a bit and checked for compliance, the expected value was reverted back to 0 (Enabled)

With this NodeCache change in the back of my mind, I also spotted something called: “CacheVersion” just a few stairs up in the MS DM Server part.

So we got these pointers

• NodeCache
• ChangedNodesData
• ExpectedValue
• NodeUri
• CacheVersion
• DeviceStatus

Those pointers led me to the NodeCache CSP. Sometimes I do read too quickly and I just skip parts if they aren’t important. This part I didn’t skip!

It synchronizes the client cache with the service side cache and!!!! It also provides an API for monitoring Device-Side cache changes….I guess when checking for compliance, the Intune service will check the expected value against the node’s actual value.

6. Other Compliance Checks

Before we are going to take a look at the Fiddler traces and all the information we learned about the NodeCache let’s add some other compliance checks to the equation and let’s see if we could spot some similarities

DefenderVersion

First, I am changing the required minimum version of Microsoft Defender Antimalware to 5.18.0 (should be 4.18.x.x)

We will notice that the ChangedNodeData is pointing us to “246”

This one is mentioning the ./vendor/MSFT/defender/health CSP instead of the ./vendor/MSFT/DeviceStatus we noticed earlier.

RealTimeProtection

Let’s take a look at which node is called upon when we disable Real-Time Protection of Microsoft Defender and require it in a compliance policy

This time I used the SYNCML viewer and Fiddler

• SyncML Output

• Fiddler ChangeNodes Output

As shown above, in the SYNCML and Fiddler output we got, we will notice the nodes 237 and 238. Guess which node URI they are mentioning? As shown below, again the ./vendor/MSFT/defender/health CSP

RtpEnabled, I guess that just stands for Real-Time Protection enabled. Guess what difference we spot when Rtp is enabled or disabled

Minimum OS

Let’s finish this part of the blog by changing the Minimum OS version to something that doesn’t exist.

Here you go!! After pressing the check access button and waiting and waiting, the Noncompliantrules are mentioning I need to update the operating system!

When looking at the SyncML output, this time it doesn’t use the devicestatus or defender NodeUri but by the looks of it, it uses the ./devdetail/SwV nodeURI

SwV as in SoftWareVersion?

7. The ExpectedValue

Looking at this ExpectedValue that changed each time we “broke” something to get non-compliant I guess we need to read some other blogs that mention the “ExpectedValue” keys because this value seems important

Intune -2016281112 Remediation failed Chrome Policies CSP (call4cloud.nl)

Remediation Error -201681112 when adding a Local Admin (call4cloud.nl)

Every time “We change” something to get the device not compliant anymore, the expected value in the NodeCache changes.

After setting up Procmon to start watching the NodeCache and pressing the sync button, we will notice that (of course) before this information is uploaded to Intune, the Omadmclient.exe will set this registry key to the value it corresponds to

When the management session is initialized the configuration service will check if this value in the expected registry key corresponds with the node’s actual value….. Let’s continue to see what happens when that process is a bit broken

8. False Positive

While playing around with the Compliance policy I decided to see what happen when I rebooted the device and immediately clicked on the “Check Access” button

Looking at the noncompliant rules, it somehow mentioned the fact that I didn’t have an Antivirus enabled or registered with the Windows Defender Security Center. That’s odd as I didn’t disable the AV only the Real-time protection part of it

When looking at the corresponding registry key, I noticed that the expected value was empty! Just like I noticed in the blog mentioning the -201628112 remediation error when you configured a local admin account with the corresponding CSP.

Luckily Microsoft their documentation is quite accurate about this behavior….yes, I said it out loud!!!

When immediately syncing the device after a reboot the setting may report as an Error. After pressing the “sync button” first and waiting some time, that not configured expectedvalue changed back to zero

9. The Compliance Flow

Let’s add all the pieces of the puzzle together and see what we can come up with when combining all the keywords and reading the documentation.

1. The device initializes a compliance check and connects to MDM / Intune
2. Intune queries the “cacheversion” on the device
3. Intune sends a get operation for the “changednodes”
4. The device sends a list of “changednodes”
5. For each changed node, Intune sends a get command to retrieve the actual value with the Get <nodeuri> (as we noticed earlier)
6. The CachedNode “ExpectedValue” will be updated with the actual value
7. Intune will update their side of things with the most recent value
8. A new “CacheVersion” will be created and sent back to the device

If all those steps took place the device will reach out again (every 30 seconds) to https://fef.amsub0302.manage.microsoft.com/StatelessIWService/Devices to determine if its compliant or not compliant

10. Let’s Sing a Song!

Let’s finish this blog with some nice lyrics, Chat Gpt put together after our Sunday morning talk about the Check Access button

Verse 1:
It’s all about the nodecache, the heart of compliance
Devicestatus CSP, it’s the source of reliance
When you click “Check Access” in the company portal
The data flows like a river, it’s truly vital

Chorus:
Expectedvalue, settingid, title, and remediationowner
These are the keys to success, they’ll keep your device in order
Nodeuri, cacheversion, and changednodesdata too
These are the pieces of the puzzle, that make compliance come true

Verse 2:
JSON responses, they hold the answers we need
To know if our devices are in compliance, indeed
Remediation steps, they guide us to success
And keep our devices secure, with no need to stress

Chorus:
Expectedvalue, settingid, title, and remediationowner
These are the keys to success, they’ll keep your device in order
Nodeuri, cacheversion, and changednodesdata too
These are the pieces of the puzzle, that make compliance come true

Outro:
So let’s all work together, to keep our devices secure
With the nodecache, compliance is the future
Expectedvalue, settingid, title, and remediationowner
These are the keys to success, they’ll keep your device in order.

Conclusion

Summary… Conclusion… it is almost the same… Let’s create a simple summary of stuff that the “Check Access button” touches when you click on it.

The “Check Access” button alone doesn’t do much if the device didn’t upload the latest nodecache to the Intune service.

Besides the well know DeviceStatus CSP, when checking compliance also other NodeUri’s can be used to determine what changed on the device and if it’s still compliant

• Defender CSP
• DeviceStatus CSP
• DeviceLock CSP
• Devdetail
• DHA

With all this information in the back of our minds, guess what my next blog will be about!!!!