Forum Discussion
Solved
Server Manager problem: Online - Data retrieval failures occurred
Hello, I'm using Windows Server 2022 and I have this problem: data retrieval on Server Manager. Is there a fix for this issue? Obs: - this is a test lab - all servers are domain members - I'm c...
DG00 I am sorry to hear this. I had a fair number of our customers affected.
For me it is gone when WS 2022 (target OS you want to manage remotely) is patched.
The only situation where I still see the issue is the WS 2025 DC created by mslab, when added to a remote Server Manager. Doesn't matter the remote OS or LCU.
I have reported everything with SR 2411120050002891. Including videos and repro steps.
As you are still affected, please open a business support case and refer to the SR number above in the case description.
I see no other way to get yours addressed.
Could you please try the following and report back:
- spin up a VM with WS 2022 latest ISO + LCU 10-2024 or newer (alternatively WS 2025, when licensed)
- Join OS to the same network and domain of the cluster
- Add your cluster / nodes to Server Manager on this VM
- Does this change anything?
- Have you tried any of the many workarounds on the cluster or is it in default state?
Has anyone come up with a DURABLE solution to this? One that survives more than one reboot? I tried the MOF rebuild, I tried removing the event log registry key, which worked on reboot to not register the log, but the registry key got set back every time on reboot, which turned out was from AutoLogger, which I removed with Powershell commands, but I can get it turned off for the next reboot, but the one after that will re-enable all of it again.
It seems like some component or driver is re-registering something, and I can't figure out what's doing it?
Durable solution for now is here for me:
https://learn.microsoft.com/en-us/answers/questions/643354/server-manager-problem-online-data-retrieval-failu.html?page=1&pageSize=10&sort=oldest
Hi, after backup I just deleted REG_DWORD "Enabled"=dword:00000001 that's enough so that the error no longer appears.I can only confirm that after 5 months, the cluster production works properly without the errors mentioned above or any system crashes.
The REG_DWORD 'Enabled' is still deleted from the key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-Kernel-IoTrace/Diagnostic on both cluster nodes and I haven't found any other solution except deleting REG_DWORD 'Enabled'
So, I spent a couple of days, on and off, trying this in many variations. It always started out looking hopeful, and then the log would reappear.
I found that this log was being created by a PerfMon Startup event trace session, so I went to PerfMon -> Data Collector Sets -> Startup Event Trace Sessions, and disabled the EventLog-Microsoft-Windows-Kernel-IoTrace-Diagnostic Session. I then ran Remove-AutoLoggerConfig -Name EventLog-Microsoft-Windows-Kernel-IoTrace-Diagnostic for good measure, to remove the setup. Then I rebooted.
Then I applied your change - I found Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-Kernel-IoTrace/Diagnostic, and deleted the Enabled value. Then I rebooted.
When it came back up, at the start, things looked promising. I rebooted again, and again, and everything looked great. I went to a different machine and started applying the same "recipe". About 20 minutes later, I came back to the first machine, and the log is back.
There is _something_ going on somewhere, in a driver or some other component, that is reconfiguring this log in the background. I'm convinced of it. I just don't know what it is.
Thanks for the suggestion, though!
My 2 node cluster (Fujitsu PRIMERGY RX2540 M5) is working for now almost 6 months without problems with this DWord deleted but I would also like to know the real cause of the problem...
- try this at your own risk
#fix servermanager events
$VerbosePreference = 'SilentlyContinue';
$delete = $true;
$backup = $true;
$backupRoot = "c:\temp";
$code45 = "Failure opening metadata of the owning provider for channel";
$code46 = "Generic failure querying the localized name for channel";
$rkey = "HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels";
if ($backup) { REG EXPORT $rkey "$backupRoot\channels.reg" /y }
$slogs = Get-WinEvent Microsoft-Windows-ServerManager-MgmtProvider/Operational | Where-Object Id -In 45, 46 | Select-Object message -Unique;
if ($null -ne $slogs) {
$smessage = $slogs.message;
$smessage | ForEach-Object {
if ($_ -match $code45 -or $_ -match $code46) {
$eventId = $_.Split(":").Split("[")[1].Trim();
$finalkey = "$rkey\$eventId";
$targetreg = $eventId -replace '/', '-';
$finalfile = "$backupRoot\$targetreg.reg";
if ($backup) { REG EXPORT $finalkey $finalfile /y }
if ($delete) { REG DELETE $finalkey /f }
}
}
#Restart-Service EventLog -Force;
restart-computer -force
}- I appreciate the suggestion but I have no idea what key it's trying to delete?
Great news everyone. I am seeing this one fixed after in-place upgrade of Azure Stack HCI 22H2 to 23H2
Azure Stack HCI 22H2 clustered nodes are affected by this, same as Windows Server 2022 clustered nodes
Hope that this fix could be backported.
Please leave me like if you want to see this one fixed in Windows Server 2022, too.
