[ms office - o365] PowerPoint Deleting User Files after 2201 14827.20220 Update

[smarties11]

Hi All,

 

Following on from my previous thread about user files being deleted after March CU Windows Update, a procmon trace this morning has shown that it is powerpnt.exe doing the deletions. It may be that winword.exe and excel.exe could be doing the same.

 

Background - after deploying the 2201 14827.20220 Monthly Enterprise Update for Office 365 ProPlus client, we are seeing users losing that vast majority of documents saved in their 'Documents' folder (which we redirect to our file server).

 

I have included the procmon trace below. It looks like powerpnt.exe is checking the file attributes and dates, setting those dates to 01/01/1601 00:00:00, then receiving an 'invalid parameter' error, and then deleting the file? This trace shows the detail for one file (DSCN1975.jpg) and then there is a similar trace for every file in the user area. If I filter the operation to 'SetDispositionInformationFile' and the detail to 'Delete: True', then I am presented with a list of all files removed from the user area - in this case, 3GB worth!

 

I think the next course of action is to pull this update and attempt to roll-back in SCCM, and follow up with Microsoft - but wondered if anyone understood the trace below better than I do, or shed any further light on it?

 

This is happened to 6 or 7 users every day - sometimes the same users, sometimes different ones, on various computers throughout the School.

 

Thanks!

 

[smarties11]

UPDATE: We began the rollback to 2112 14729.20322 on Friday. So far, we've not had the issue occur on any machines that have successfully rolled back.

 

There is no official way to rollback the O365 client. You just deploy and older version on top. This is fine as we use SCCM so I have deployed said version, and we're using the 'VersionToReport' key from the registry as the detection method. HOWEVER! We're finding that some machines are coming back 'already compliant' when infact they have the newer version on. Check the registry on these machines, and indeed they show the old version number. So it looks like this key doesn't update reliably, or perhaps only updates on a schedule. There is another key 'ClientVersionToReport' however looking and some sample machines, this too isn't always correct. It seems to be that if one is wrong, the other will be correct, and vice versa. GRR!

 

Case has been logged with Microsoft. No escalation yet, they want to wait another 2 days to ensure rollback has solved it.

 

Has no one else experienced this issue with 2201 14827.20220? Perhaps the masses are using Semi-Annual?

[BOOT]

I rolled out the LTSC version and found that SCCM couldn't compare the ClientVersionToReport key correctly.

I switched to using the version number of several files instead.

[smarties11]

I rolled out the LTSC version and found that SCCM couldn't compare the ClientVersionToReport key correctly.

I switched to using the version number of several files instead.

 

Yes, think I am going to have to do the same. Was there a specific file you checked that is reliable?

 

Thanks

[BOOT]

I use OR rules in a group together:

protocolhandler.exe

PerfBoost.exe

officeappguardwin32.exe

msotd.exe

msoev.exe

[smarties11]

I use OR rules in a group together:

protocolhandler.exe

PerfBoost.exe

officeappguardwin32.exe

msotd.exe

msoev.exe

 

Thank you. Just had a look, it seems that the main .exe files (e.g. winword, excel etc) follow the correct convention too, have looked at a few sample machines and seems reliable. Cheers for the heads up!

[smarties11]

Latest update - Microsoft support have been pretty hopeless to be honest, they seem more interested in closing the case and asking for feedback on their engineers. They say it has been escalated, but I've yet to speak to anyone other than the initial engineer and his technical lead. I've insisted the case stay open until it is fixed, and expressed concern that because we are on the Monthly Enterprise Channel, we won't be able to get monthly security updates now until the issue is resolved. I keep getting vague assurances like 'I am sure it will be fixed before the next update' etc. I think we'll look to move to semi-annual and go from there.

 

However, despite the above, I have done some more digging online and have found that they acknowledged/fixed what I believe to be our issue, in the release notes for Monthly Channel (Preview) 2203 (Build 15028.20050) - https://docs.microsoft.com/en-us/officeupdates/current-channel-preview. So it looks like there is a process for clearing out old recovery files, and due to a bug in this process, non-recovery files fall within the scope and are deleted also. It mentions 'user-configured recovery file paths', and we do set the auto-recover path for all Office applications to the user's home area, through group policy; so that they are saved centrally rather than in local profiles to aid file recovery. Presumably this fix will hit the Monthly Enterprise Channel in 2-3 months time. It surprises me that such a catastrophic bug hasn't been fast-tracked into the other channels? There was an update for Current Channel (non-preview) yesterday and it's not mentioned in the release notes for that.

 

 

So, my summary is - the bug is caused by a combination of specifying a location for auto-recover files, and an error in the routine for clearing out old recovery files, that means it also includes non-recovery files. What a mess! I'm surprised no one else here has been affected - does no one else use the Monthly Enterprise Channel and update regularly?

Edited March 31, 2022 by smarties11

[Steve21]

We don’t force recovery paths to their home folders so guessing that’s why not been hit

 

Steve