Intune Compliance Check Delay

Hi Stuart Hendry ​​​​ , sorry for my delayed reply. Please can you confirm - do you have your intune settings configured to mark hosts with no compliance policies assigned as compliant? this may cause the issue. You could try using the alternative option of ‘all policy types’, which will ensure that all items including apps are successfully deployed before releasing the host. Thanks. 

Hi Toby, thanks for reviewing my feature request and for the response.

I’ve double‑checked, and yes — this setting is enabled at the tenant level.

Unfortunately, because we have a very large endpoint estate, disabling or significantly altering this global Intune compliance policy isn’t a practical option for us. With that in mind, we were really hoping for a more granular control to be incorporated at the pool level within Virtual Machines — something along the lines of an additional setting, for example:
 

This would allow Nerdio to intentionally wait for Intune to fully “settle” before making a compliance decision during host provisioning.

We've noticed it’s common for Intune to take up to an hour (or more) to:

Fully evaluate compliance policies
Complete dynamic group membership
Finish required app deployments

During that window, Intune often temporarily reports the device as Compliant, only to later flip it to Not Compliant once all policies have evaluated and any base apps have been installed. In the meantime, Nerdio has already acted on that initial compliant state and released the host.

Because of this behaviour, the existing Intune compliance timeout doesn’t really solve the problem — it only waits up to a fixed duration for Intune to mark the device compliant, but doesn’t account for the later re-evaluation that happens once policies and apps fully apply.

A separate “settle” or stabilisation period before Nerdio consumes the compliance signal would help prevent hosts being released prematurely and would make the provisioning flow far more deterministic.

Let me know if something like this would be feasible — happy to discuss or continue the conversation.  We'd be delighted be able to finally use Nerdio with Intune, but without this step, its not something we can presently do.  Hopefully this kind of feature would also be useful to your other customers. 

Thanks very much.
 

Hi Stuart Hendry ​​​​ - thanks again for these details - but I just want to confirm, does the alternate option of ‘All Intune policies’ not resolve the issue? This setting should keep the host in draim mode until all Intune policy actions are complete, including app deployments. Are you seeing hosts prematurely released even if you use this setting? 

If the current options aren't getting you where you need to be, we certainly want to help, but I just want to understand if the strict ‘all policies’ option might work, and if not, where the gaps are. Thanks!

Hello, we need Intune to deploy our base security apps on all new session hosts, and to only mark the device as compliant once they are detected.  The only way to do that in Intune, is to use a Custom Compliance Policy.  Therefore, we only selected ‘Compliance Policies Only’ for that reason. 

We could re-test with All Intune Policies to see if it works though?  The problem is, Intune does initially mark the device as compliant, which I think would still happen unless there is some kind of ‘Convergence’ timeout to begin with

thanks Stuart Hendry ​​​​ - if you have time to test the ‘all policies’ option to see if it resolve your issue, please do. We have quite a few customers using this feature and I haven't seen the issue you mentioned raised. However - most people aren't using the compliance policy only option, because many orgs don't have well crafted custom compliance policies.

So your original concern is certainly valid and I will capture, I just wanted to see if the alternate option give you a workaround.

Hi Toby, 

All Policies does actually seem to work so thank you.  It timed out sadly (even with 8 hours).  But lets acknowledge the win first, this did mean Nerdio paused as it caught the fact that the Custom Policy was not yet compliant, so a step forward there.

Intune actually installed all the apps needed for the compliance policy to pass shortly after enrollment.   The custom compliance policy doesn't seem to re-scan after the initial scan when the device is first enrolled.  By design MS state it should re-scan every 5 mins or so for the few few hours.  

So what might help, is if we could somehow reboot the machine AFTER the compliance policy checks were in play.  Deploying a scripted action to reboot may not work, since the host would reboot too early in the workflow.  It ideally needs time to enrolled with Intune, THEN reboot, and that ‘should’ increase the chance of the Custom Compliance Policy from ‘re-scanning’.    If it had rescanned even after 1 hour, it would have passed the compliance.  

Sorry I realise we are deep into Intune territory now and not Nerdio.  If you have any ideas it would really help us! 

Hi Toby,

Adding a bit more colour here, specifically for environments using Intune Custom Compliance Policies (CCP), as this behaves differently from standard compliance.

From logs and recent testing, Nerdio is now correctly waiting for Intune, then polling compliance repeatedly. That part is working as designed (thanks!). The issue is that with CCP, waiting alone is not sufficient.

CCP evaluation depends on the Intune Management Extension (IME) running a discovery script on the device, and that does not automatically re-run when underlying conditions change (e.g. required apps finish installing). Microsoft explicitly notes that CCP runs on an ~8‑hour cadence and cannot be pushed on demand in the same way as other policy types. As a result, Nerdio can poll compliance many times and still receive the same stale “Noncompliant” result.

This is what is now happening, it waits for 8 hours then fails.  Then the next day, Intune finally evaluates and passes marking the device as compliant. Since its not feasible to leave VMs powered on for that, here is a revised request. 

In our case, Nerdio:

• Finds the Intune device
• Waits for policies to apply
• Polls compliance every few minutes
  …but Intune never re-evaluates CCP during that window, so compliance never flips.

A reliable workaround today is deploying a short‑lived scheduled task on the session host during provisioning which waits for IME/enrollment, then triggers a compliance sync (synccompliance) so CCP actually re-runs while Nerdio is polling.  

This is a simple command you can run to force CCP to sync, however, there is no place in Nerdio (at present) to place that script.  It needs to happen AFTER Nerdio has found the device, and once Nerdio has started evaluating the compliance state.  

This is why CCP-heavy environments are disproportionately affected, and why a CCP-aware readiness / gating mechanism (delay + retry, or the ability to trigger re-evaluation during the wait phase) would be hugely beneficial as a first‑class Nerdio feature.

Happy to share logs or the scheduled-task approach if useful.