Forum Discussion
Autopatch - Microsoft 365 Apps Update Rings
I’m trying to understand how the UpdateDeferredVersions registry value is updated in an Intune Autopatch scenario, specifically the version and FileTime values.
Registry path:
HKLM\SOFTWARE\Microsoft\Office\ClickToRun\Updates
Example value:
UpdateDeferredVersions = 16.0.19725.20170:13420719560293 | 16.0.19822.20180:13421142577563
I’ve observed the following and would appreciate any clarification:
- When I modify deadline or deferral settings via Autopatch (policy changes), the FileTime value does not update.
- Is there a delay or specific trigger (e.g., policy refresh, scheduled task, CDN sync) that updates this FileTime?
- How exactly is this FileTime calculated? Is it tied to when the build was released, assigned, or when the policy was applied?
- Is there any supported way to force or influence this FileTime update?
- Or is this value simply tracking when the build cap was issued, with deferral logic calculated relative to that timestamp?
Additionally, I’ve noticed that updates only seem to apply when the FileTime is approximately 4 days behind the current date, is this expected behavior with Autopatch deferral logic? I was able to successfully test this updating FileTime 4 days behind ((Get-Date).AddDays(-4)).ToFileTime().
Any insights into how this mechanism works under the hood (especially with Click-to-Run + Autopatch interaction) would be really helpful.
Below is Autopatch group settings for Microsoft 365 update rings that we set in our environment:
Test - Deferral 0 - Deadline 0
Ring 1 - Deferral 1 - Deadline 0
Ring 2 - Deferral 2 - Deadline 0
Last - Deferral 4 - Deadline 1
Thanks in advance!
4 Replies
Hi Bogdan_Guinea,
Thanks for taking a look at my question. My goal here is specifically to understand the behavior of the UpdateDeferredVersions value in an Autopatch scenario, particularly how the FileTime is determined and what triggers its update.
I’m not trying to achieve a separate outcome beyond that clarification; I’m just looking to better understand the underlying mechanism so I can interpret and manage update behavior more accurately in our environment.
I do have a working theory, which I’m planning to validate during the next Patch Tuesday cycle. Once I’ve confirmed whether it’s correct or not, I’ll share my findings here as well.
If you have any insight into how that timestamp is calculated or updated, I’d really appreciate it.
Thanks again.
Mate, what's your goal? What do you want to achieve besides the clarification regarding the behavior of Autopatch and 365 Apps?
Good luck!
Thanks for taking a look at my question. My goal here is specifically to understand the behaviour of the UpdateDeferredVersions value in an Autopatch scenario, particularly how the FileTime is determined and what triggers its update.
I’m not trying to achieve a separate outcome beyond that clarification; I’m looking to better understand the underlying mechanism so I can interpret and manage update behavior more accurately in our environment.
I do have a working theory, which I’m planning to validate during the next Patch Tuesday cycle. Once I’ve confirmed whether it’s correct or not, I’ll share my findings here as well.
If you have any insight into how that timestamp is calculated or updated, I’d really appreciate it.
Thanks again.
Ok, from my perspective i think the UpdateDeferredVersions is handeld as a timestamp that Microsoft's CDN stamps on a build when it becomes available for your specific ring, not a record of anything you did in Intune. When you tweak deferral or deadline settings in Autopatch, that stamp doesn't change, because the build itself didn't change on Microsoft's end.
The deferral days you configure in Autopatch simply tell the C2R client: "wait this many days after that CDN stamp before actually applying the update." So if the stamp says a build arrived 1 day ago but your deferral is set to 2 days, the client will sit and wait. The moment you backdate that timestamp to be older than your deferral window, which is exactly what your 4-day test did, the client sees the waiting period as already elapsed and proceeds with the update.
If you were able to find mismatches, just raise a ticket with Microsoft and maybe they'll have more insights.
Good luck!
