Windows 2019 WMI timeout causes guest processing to fail

[cableguy]

Hello,

I'd like to share some insights from my support case ID #03932442. We have two DCs running Windows Server 2019 on vmWare ESXi 6.7 U3. They backed up fine until Veeam gave an error message for both of them:

Error: VSSControl: -2147217389 Backup job failed.
Cannot create a shadow copy of the volumes containing writer's data.
Cannot prepare the [NTDS] data to a subsequent restore operation.
Cannot process NTDS data.
Cannot create a backup copy of the BCD.
Cannot get [BcdStore] object.
COM error: Code: 0x80041013

With our very helpful Veeam support engineer, we found out that the issue not with the VSS / Shadow copies as first suspected. In fact, the guest processing timed out when Veeam tried to get the BcdStore object from Windows WMI. We found that we could test with the PowerShell command

Code: Select all

gwmi -name root\wmi -list bcdstore

This normally takes only a second, but took several hours on the machines concerned. I can temporarily resolve the issue by restarting the Windows machine and then restarting the Windows Management Instrumentation service, but this will of course only last until the next restart.

One thing we changed on both machines on the day the guest processing failed for the first time was to add an additional name to each machine. I don't know whether this is really related to the WMI issue, though:

Code: Select all

netdom computername <machine> some-other-name.contoso.com

Any insights on this would be greatly appreciated.

Cheers,

cableguy

[Gostev]

Hello. Since the issue can be demonstrated without Veeam in the picture, and does not look typical and straightforward at all, I would highly recommend opening a case with Microsoft. Because the issue really does not look like something that can be troubleshoot via forum posts (even on Microsoft forums, where this topic would be more appropriate). To me, given that the reboot+restart cycle helps, it looks like some environment-specific bug in Windows. Thanks!

[cableguy]

Just in case someone stumbles upon this, I was able to find a workaround for us.

Log in to the domain controller in question as Administrator and open an admin shell.

Code: Select all

taskkill /im WmiPrvSE.exe /f

This will kill the process that blocks the WMI requests by Veeam. No restart is required.

Unfortunately, I was not able to automate this, so I need to do this every time the server is restarted. Still, it works for us.