As an IT professional managing enterprise environments, most of you would’ve often grappled with the challenges of keeping Windows devices up to date and secure. Microsoft’s Intune offers robust tools for device management, but when it comes to patch compliance for Windows, there’s room for improvement. In this post, I’ll share a custom approach I’ve developed to make compliance tracking more dynamic and scalable, especially in complex organizations.
The Challenge with Built-in Compliance Policies
Intune supports Windows device patch compliance through platform-specific compliance policies. These policies allow you to set a minimum required version for updates, ensuring devices meet security standards. However, this method isn’t dynamic—it requires IT admins to manually update the minimum version whenever new patches are released.
In a large enterprise spanning multiple regions, this becomes particularly cumbersome. Consider an organization with diverse device groups based on use cases: shopfloor machines, IT employees’ laptops, banking staff devices, helpdesk kiosks, and more. These groups often run different feature versions of Windows (e.g., various builds of Windows 10 or 11). To track non-secured devices and enforce conditional access to block corporate resources, admins end up maintaining multiple compliance policies, each with its own minimum version thresholds.
Adding to the complexity, Windows update catalog information isn’t readily available in a consumable format. Maintaining a custom catalog manually is time-consuming and error-prone. This fragmented approach can lead to oversight, delayed updates, and increased security risks.
A Smarter Approach: Dynamic Time-Based and Relative Compliance
To address these pain points, a more intelligent paradigm shifts from rigid version pinning to dynamic, relative assessments that adapt to release cadences and organizational policies.
One effective evolution calculates the “days since the release of the most recent patch installed” via a PowerShell discovery script executed on devices. Compliance is then defined through a flexible JSON configuration in custom compliance policies, setting thresholds like “non-compliant if >30 days behind” for general devices or “allow up to 60 days” for less critical assets.
Building on this foundation, I have added a more smarter approach further by incorporating update ring configurations: it determines relative patch levels (n=0 for latest, n-1 for prior), factors in deferral/deadline days, and cross-references against JSON settings for nuanced, ring-aware compliance verdicts. This method is universally applicable across feature versions, eliminating the need for version-specific policies and reducing administrative overhead. Key benefits include scalability for diverse fleets, tailored deferral logic (e.g., ring-based grace periods), and real-time adaptability to update timelines – ensuring faster vulnerability closure without constant tweaks.
Basic Scenario: Calculating days since the release of the most recent patch installed
Recently, I had an idea to simplify this: instead of relying on static version checks, why not compute the days since the release of the most recent patch installed on a device? If we are able to dynamically compute, this metric would work irrespective of the underlying feature version, providing a more universal and dynamic way to assess compliance.
Here’s how it works:
- Scrape Update Release Information: Pull feature and quality update release dates from official sources like the Windows 10 release information and Windows 11 release information pages.
- Device-Level Calculation: On each device, determine the most recent patch installed and calculate the number of days since its release date.
- Custom Compliance in Intune: Leverage Intune’s custom compliance policies. The discovery script computes the days since the release of the most recent patch installed. Define a JSON file with custom settings that specify a threshold (e.g., “flag as non-compliant if more than X days old”).
This method currently doesn’t support Insider builds, but you can easily customize the discovery script to fit your specific requirements.
Implementation Details
The core of this solution is a discovery script that runs on the devices. It fetches the necessary update history, computes the days elapsed, and stores the results for evaluation.
- Discovery Script: This PowerShell script scrapes the release info, checks the device’s update history, and calculates the days since the last patch. It creates a registry key at HKEY_LOCAL_MACHINE\SOFTWARE\WindowsUpdateCompliance on the device, which logs the data used for evaluation. This is invaluable for troubleshooting—admins can quickly inspect why a device was flagged.
Sample data from Target Devices
Updated Released < 30 days (COMPLIANT)
Updated Released > 30 days (NON-COMPLIANT)
Windows 11 24H2 – Base OS Installed and Never Updated. Feature Update released > 30 days (NON-COMPLIANT)
- JSON Settings File: In your custom compliance policy, upload a JSON file that defines the threshold (X days). For example: 30 days (as in below screenshot)
- If the calculated days exceed this, the device is marked non-compliant.
The beauty of this setup is its flexibility. Use the same discovery script across multiple compliance policies, each with a different threshold in the JSON settings. Tailor it to specific use cases:
- Shopfloor devices: Allow up to 60 days (less frequent updates due to operational constraints).
- IT employees: Enforce 30 days (higher security needs).
This way, you avoid the hassle of version-specific policies while maintaining granular control. Having less than 30 days is not recommended as the gap between two Patch Tuesday updates is around 30 days.
Advanced Scenario: Intelligent Compliance Evaluation Aligned with Update Ring Configurations
This method extends basic time-based compliance by assessing the device’s feature and quality update levels relative to Microsoft’s latest releases. It assigns CurrentPatchLevel value (e.g., 0 for the current version, -1 for the prior version etc.,) and evaluates them against thresholds that reflect your Update Ring policies’ deferral periods (delaying update availability) and deadlines (enforcing installation). This ensures devices are flagged as non-compliant if they lag beyond applicable patch level for the device, promoting timely patching while respecting ring-specific grace periods. It’s ideal for segmented fleets, where pilot rings might require stricter adherence than production ones.
Implementation Details
- Retrieve Current Feature Version and Build from the device.
- Find CurrentPatchLevel: Sort the releases for the corresponding feature by release date descending. Find the index of the matching version: CurrentPatchLevel = N, CurrentPatchLevel = N-1, etc.
- The script includes logic to skip a Patch, if it is not applicable for the corresponding feature version. For example KB5072359 with build number 26100.7178 is OOB but is applicable only for Windows Server 2025. So the script will exclude it for Windows 11.
- Find the RequiredPatchLevel based on Windows Update settings from registry – the deferral and deadline days.
- Example: for a ring with 7-day quality deferral and 7-day deadline (total 14 days allowance is available for current patch to install)
- Calculate DaysSinceLatestUpdateReleaseDate based on Availability Date of the LatestApplicableUpdate for the feature version (includes OOB, but D release is ignored)
- If DaysSinceLatestUpdateReleaseDate is less than the sum of deferral and deadline, the RequiredPatchLevel = N-1
- If DaysSinceLatestUpdateReleaseDate greater than the sum of deferral and deadline, the RequiredPatchLevel = N
- Now compare CurrentPatchLevel with RequiredPatchLevel and determine if the CurrentPatchLevel isLatestForThisDevice and mark accordingly.
- Now use a boolean comparison for isLatestForThisDevice variable in JSON Compliance Setting.
Resources and Customization
I’ve made the discovery script and sample JSON file available for you to download and customize:
- Discovery Script (Applicable for both scenarios)
- JSON Settings File (Basic Scenario)
- JSON Settings File (Advanced Scenario)
Feel free to tweak the script—for instance, add support for Insider builds or integrate additional logging. If you’re implementing this in your environment, test it in a pilot group first to ensure it aligns with your update rings and conditional access rules.
You can also use the Discovery script as Detection Script in Proactive Remediation along with a Remediation script to force update the device, reboot the device or create a service ticket.
Benefits and Final Thoughts
This custom approach transforms patch compliance from a manual, version-tied chore into a dynamic, time-based system. It reduces administrative overhead, improves security posture, and scales effortlessly across diverse device fleets. In an era where cyber threats evolve rapidly, ensuring patches are applied promptly—regardless of feature version—is crucial.
If you’ve faced similar challenges or have suggestions to refine this method, drop a comment below. I’d love to hear your thoughts!