Apps 365 update log analysis

[Ruzitko]

Hi everyone.

I am going through some stuff in few environments, where we are experiencing some prolonged delays in Apps 365 update procedures. We have setup a deferral period of 1 day and deadline also of 1 day for the Apps 365 via MEM Device Configuration Policy (not using servicing profiles from A365 admin portal). Running SA channel.

I am aware Microsoft has own logic in gradually releasing the update in the location and some other specifics to group the computers together.

I would like to know, if someone can shed a light into one particular log entry.

08/01/2022 11:05:40.326 OFFICECL (0x140c) 0x45d4 Click-To-Run General Telemetry bgmm1 Medium MRO::DetermineVersionToUse {"MachineId": "<redacted>", "SessionID": "<redacted>", "GeoID": 61, "Ver": "16.0.14326.21018", "C2RClientVer": "16.0.15225.20286", "ContextData": "{'Branch':'7ffbc6bf-bc32-4f92-8982-f9dd17fd3114','CurInstBld':'16.0.14326.21018','AvailBld':'16.0.14931.20646','LKG':'16.0.14326.21018','MROThroVal':'200','MachineThroVal':'802', 'CurBldExp':'1', 'CurBldFnd':'0', 'AvailBldExp':'0','AvailBldFnd':'0','LKGFnd':'0','VerToUse':'16.0.14326.21018','success':'TRUE','DmsStatus':'{Enabled, Success}','VCabStatus':'<<uninitialized>>'}"}

I am interested what are the parameters MROThroVal and MachineThroVal.
Where do they come from, and what are the values? Is it Minutes?

Also what is LKG build? Last Known Good?

The problem is, this particular machine knows there is a new build available as seen 'AvailBld':'16.0.14931.20646' but later the process determines there is no new version to update to ('VerToUse':'16.0.14326.21018'). It is long after the 07/26 where the update was released (log from 08/01), so I would expect the machine to see the update available around 07/28 at least, as our deferral is only 1 day.

As MS is also including their own deferral period in the process, what from above values is from policy and which one comes from MS internal logic?

The problem is, in two past months, we were experiencing very long delay in applying new security update in the environments, which causes the security teams to freak out. Attaching the graph from Defender for Endpoint monitoring.

This is happening across multiple environments.

Thank you for any insights.

[#2]

The ThroVal are internal/private values used by Microsoft to determine if a device should already adopt a new build or check again during the next update discovery (which happens every 24hrs if I recall correctly).

Things were a bit different in July, as an issue with Access was discovered (https://support.microsoft.com/en-us/topic/error-when-trying-to-open-an-accde-mde-file-created-in-a-d...) and Microsoft released a new update with a fix for this issue.

So timeline for a given device could have been (longest-possible scenario):

Update released on 7/12.
Before the per-device throttle value allows the update to be downloaded & applied, Microsoft stopped the rollout (around 7/15) and started working on a fix.
Fixed release made available on 7/26, as usual, released in a staged manner.
Again, device is randomly throttled and gets the clearance to get the new update 4-5 days later.
On ~7/31, the device meets the throttle value and is allowed to install the new update.
Now the deferral you set kicks in. The device waits for another 24 hrs before downloading the update. (Deferral counts from the beginning of the individual device becoming aware of the pending update, not from the point in time when Microsoft releases a new update).
On 8/1 the device downloads the update, can't apply as apps are running and waits another 24 hrs before nagging the user (your setting of deadline=1 day).
The user can postpone the actual application of the update for ~48hrs.
So on 8/3 latest, the update should be installed.

As mentioned, above is the "slowest scenario". Other device might meet the throttle settings on day 1 (7/26), device downloads on 7/27, user has no apps open and the update is applied right away. Job done.