If you’ve configured Update Compliance with Intune, you’re probably familiar with the experience of rushing over to the newly configured Update Compliance Log Analytics workspace to eagerly see how your devices are checking in only to see something like:
“Note that it can take up to 24 hours for configured devices to appear or take longer if they’re not currently connected to the internet.” So now we wait, but what’s really going on here?
Windows 10 telemetry
Update Compliance information piggybacks on Windows 10 telemetry and Windows 10 telemetry works to the beat of its own drummer. That drummer is the Windows DiagTrack process.
The service description from services.msc reads:
The Connected User Experiences and Telemetry service enables features that support in-application and connected user experiences. Additionally, this service manages the event driven collection and transmission of diagnostic and usage information (used to improve the experience and quality of the Windows Platform) when the diagnostics and usage privacy option settings are enabled under Feedback and Diagnostics.
In other words, this is the service that sends telemetry data from your Windows 10 machine to Microsoft. What telemetry data is being sent to those Microsoft endpoints? That depends on your diagnostic data settings. The data sent up varies by the setting (Security, Basic, Enhanced, or Optional (Full)). How often? It kind of depends: is the device plugged in or running on battery? On a metered network? The range goes from something like every fifteen minutes to every four hours.
Remember that Update Compliance requires at least the Basic level set for telemetry data. If you’re curious, you can use the Diagnostic Data Viewer to review the information your device is sending to Microsoft.
Taking a device census
Earlier I said Update Compliance data piggybacks on telemetry data. It does this by running a separate process that leverages the Windows Diagnostic Data upload routines to report what it finds when it runs. Enabling telemetry creates the bridge we need to get Update Compliance data uploaded to the Microsoft endpoints.
The process that actually collects Update Compliance data is an .EXE going by the name of devicecensus.exe. You can see this process running as a scheduled task under Task Scheduler (Local) > Task Scheduler Library > Windows > Device Information:
There are two scheduled tasks here. One runs in the user context and is triggered at log on and the other runs in the system context and is triggered every 24 hours. And that’s why you see the note about it possibly taking up to 24 hours (or longer) to show up in the initial Update Compliance workspace summary. Mystery solved.
It might take a while for your devices’ data to reach the Update Compliance workspace because they’re all independently sending telemetry when their specific devicecensus.exe scheduled task says it’s time to get that done.
Now that we know how Update Compliance data is sent, you might be wondering what data is being sent. Some of the data we need for Update Compliance reporting is sent on-demand as it’s based on events such as critical events that are uploaded when they are created. Other data, not based on events, will take longer to be sent. In fact, some changes might only be sent weekly. So how do we force our managed devices to give us the full scoop on what’s going on?
Run a full census sync
Again, according to the docs:
Census is a service that runs on a regular schedule on Windows devices. A number of key device attributes, like what operating system edition is installed on the device, are included in the Census payload. However, to save network load and system resources, data that tends to be more static (like edition) is sent approximately once per week rather than on every daily run. Because of this, these attributes can take longer to appear in Update Compliance unless you start a full Census sync.
Bottom line: if you’ve recently enrolled devices into Update Compliance, it could take up to 24 hours for them to show up, and then possibly up to a week for you to get the full picture of what’s going on Update Compliance-wise. The way to speed all this up, is to force a full Census Sync on the device.
All the information we need to do this with Intune is, as usual, in the docs:
- For every device you are manually configuring for Update Compliance, add or modify the registry key located at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Census to include a new DWORD value named FullSync and set to 1.
- Run Devicecensus.exe with administrator privileges on every device. Devicecensus.exe is in the System32 folder. No additional run parameters are required.
- After Devicecensus.exe has run, the FullSync registry value can be removed or set to 0.
Which means we can use Intune to push down a PowerShell script to do our Update Compliance bidding. Here’s the script. Save it as a PowerShell (.PS1) file, you’ll need it later:
$sysdir = [System.Environment]::SystemDirectory
$regpath = “HKLM:Software\Microsoft\Windows\CurrentVersion\Census”
Set-ItemProperty $regpath FullSync 1
Start-Process -FilePath “devicecensus.exe” -WorkingDirectory $sysdir | Out-Null
Remove-ItemProperty $regpath FullSync
At this point, the title of this blog post is probably making a whole lot more sense to you.
Use Intune to Force an Update Compliance Full Census Sync
Head over to the MEM admin center and navigate to Devices > Scripts and + Add a new script for Windows 10. Go through the simple wizard-like process to create the new script deployment. Just upload the script you saved from the PowerShell example above and ensure the script runs in the system context:
Now just assign the script to the same Windows 10 device groups that you assigned the custom OMA-URI policies to configure Update Compliance to and you’re done.
If you’re in a big hurry, go to one of the devices you targeted with the PowerShell script and restart the Intune Management Extension service. That’s in Task Scheduler under Task Scheduler (Local) > Task Scheduler Library > Microsoft > Intune. Or, just reboot the system, that works too.
Troubleshooting tip
If you forget to run the script in 64-bit mode, the logs will tell you that they key you’re trying to modify doesn’t exist. The Intune management Extension is a 32-bit app so it will try to run the script in that context unless you tell it otherwise.
Anyway, I’m sure you didn’t do that, but it’s good to know information. I mean I certainly didn’t do that when writing this post…well, maybe I did. Moving on.
The Intune management extension agent checks with Intune once every hour and after every reboot for any new scripts or changes. Once the script executes, it doesn’t execute again unless there’s a change in the script or policy.
Last thoughts
Now you know how to force a full census sync to speed-up Update Compliance reporting on your Intune-managed Windows 10 devices. Just remember it’s a two-part process and consider your deployment timing accordingly:
- Use custom OMA-URI policies to configure your devices for Update Compliance. These are Intune Device Configuration profiles and can take up to 8 hours to apply to a device.
- Use Intune to push a PowerShell script to force a full census sync (this post). The Intune Management extension will check for new scripts every hour.
You might want to give your devices a day or two before pushing the PowerShell script is all I’m saying.
You’ve seen my blog; want to follow me on Twitter too? @JeffGilb
