MicrosoftSecurity!OnlineServicesPackageUpdate health error
Started to see the error “Can only partially assess the health of this computer. The failing components are: MicrosoftSecurity!OnlineServicesPackageUpdate” again on latest WSEE update on Windows Server 2022 Standard.
This is the same/similar to the issue in the previous post a few years ago here https://www.theofficemaven.com/questions/question/windows-server-2016-essentials-health-monitor-error.
Checked https://learn.microsoft.com/en-us/answers/questions/545944/ws2016e-computer-monitoring-errors and it seems like the OnlineServicesConfigFile-GB.xml file is corrupted somehow – it does not seem to be a valid XML file and comes up with an error if opened in Edge to check its values.
I have server backups daily, so went back a week or so (to the last full backup) to restore this file so that I could compare it with the file now on the server. The files were VERY difference – the restored one being a valid XML file.
Have restored the old one (and kept a copy in case it does it again) but was wondering if anyone else has seen this, or if it was a one-off issue that the restore of the file will have fixed.
- Andrew asked 3 months ago
- You must log in to post comments.
Well, I can’t say that it surprises me that this issue has returned. Microsoft is constantly messing about with (and screwing up) their backend structure for Essentials. And with Essentials quickly racing towards end of support/end of life, we’ll probably start seeing more of these kinds of things happening.
While I’m not currently seeing the “Computer monitoring error” health alert (for the Microsoft Security\OnlineServicesPackagesUpdate health definition) popup over here on our EN-US installs (as compared to your EN-GB install), about all I can tell you would be to mark your good (non-corrupted) “OnlineServicesConfigFile-GB.xml” file as “read-only” so that it doesn’t continuously get replaced by the corrupted one that gets downloaded from Microsoft’s servers on a regular basis.
The (download) links that are referenced within that file haven’t changed in years now (if ever) and so no harm will come from marking it as read-only to prevent it from being frequently overwritten by the corrupted copy. If Microsoft ever gets around to fixing the issue with the corrupted download, then you can always just go back and remove the read-only attribute from the file again. If I recall correctly, that’s exactly how I worked around the issue previously.
Ya just gotta love Microsoft sometimes! : -D
- Mike answered 3 months ago
- last edited 3 months ago
- BTW, you should also mark the (non-corrupt versions of the) “CloudServiceEnvironment-GB.xml” and “OnlineServicesConfigLanguageResourceFile-EN-GB.xml” files as read-only as well if they happen to exist within the “C:\ProgramData\Microsoft\Windows Server\Data\Cloud” folder.
- You must log in to post comments.
For some reason this error has also corrupted the Windows Server Backup Solution.
The HDD is attached, and visible with copies, but the GUI says:”No next schedule available”
I found this solution, so i hope that this also will save the Backup Settings.
(Either it’s probably a reset, but with loss of data)
- MOHdennisNL answered 3 months ago
- last edited 3 months ago
- AFAIK, this particular issue would only affect Microsoft’s online (cloud) services and wouldn’t have anything to do with the client/server backups (unless you’re specifically talking about the “Azure Backup” feature in Essentials that is – SEE: https://www.itpromentor.com/essentials-azure-backup). Otherwise, it’s probably just a coincidence I’d say. That being said… Did you forget to link to the solution that you found? I’m sure it would help others if you wanted to share it.
- on a note for everyone, the WSEE looks in the Eventviewer for the WindowsBackupService. when you delete this one, they will ‘dissapear’ from the menu on the Server. (I did tis per Google find, as this should fix the issue with the BackupService, it didn’t) But for some reason the only way to ‘recover’ it, was creating a new setup for it, and let the Wizard place the ‘new’ backup to the new one. So in short, the backup is there, but not easily accessible anymore.
- @Mike, The solution i thought that would work, was setting the base folder of the WSEE to ReadOnly, and recovering the file trough ShadowCopy. But it has failed after that suddenly.
- You must log in to post comments.
