Action1: "Failed to get the version of the operating system"

[LeMarchand]

Loving Action1, but some clients are throwing a "Failed to get the version of the operating system" error. The below is from a suite machine; other machines in the suite seem fine.

 

 

In the console the OS is correctly reported! Rebooting doesn't help and my Google-Fu has failed me.

 

Anyone had and fixed this? It's bugging me!

[TheHyperTechie]

WMI might be corrupted - https://learn.microsoft.com/en-us/windows/win32/wmisdk/wmi-troubleshooting

[LeMarchand]

Thanks.

 

When I can get to one of the affected machines I'll try a few of the fixes I found. Because that MS page is mainly "We used do have something that might help and did all sorts of cool stuff, but you've gotta search elsewhere if you want help".

[LeMarchand]

Thanks again to @HyperTech for pointing me in the right direction.

 

For posterity, after working my way through less nuclear fixes what did the trick was:

 

From Admin command prompt:

 

>net stop winmgmt (Y to the "Really?" prompt)

 

>Rename C:\Windows\System32\wbem\Repository Repository.old (You can also try to delete it)

 

>net start winmgmt (Probably unnecessary as the next step to...)

 

Reboot machine

 

I had to reboot a couple of the machines that didn't want to do the rename to get it to take. This also had the bonus of sorting out the lockscreens that were defaulting to the Windows choice that was on the "must look at" pile.

[GeneMoody-Action1]

A little late to this party, but if these machines do not share a common image, then I would question a very specific type of corruption in WMI on several systems.

*Could* be indicative of tampering.

[LeMarchand]

13 hours ago, GeneMoody-Action1 said:

A little late to this party, but if these machines do not share a common image, then I would question a very specific type of corruption in WMI on several systems.

*Could* be indicative of tampering.

 

That's a worrying thought. No common "image" as such. I've been using MDT to serve up an almost vanilla Windows installation with everything else installed after that through various methods. So far the problem seems limited to the ICT Suite which has very old machines that are often unsupervised. I'm praying that it's down to power being pulled at bad times .

[GeneMoody-Action1]

It is not out of the question, of course if tampering, it *may* not be malicious.  It is not uncommon for vendors to insert special management classes into the WMI, it could be a common driver or application doing this, I would personally experiment as such, deploy vanilla, test, install normal drivers, test, apps, test, and see if you can find a step that induces the behavior.

 

Typically that kind of diagnostics time I reserve just for situations like this, where I have a distributed problem, no good answer, and need one before something critical happens.
It is tedious and time consuming, but it beats something going catastrophically wrong in the future and stating the clock then.