Controlling WMI timeout behaviour becomes very important when you're parallelising queries across hundreds of servers. Even though other queries may execute quickly when one server fails to respond WMI can hang indefinitely and stop any further processing in its tracks.
Not anymore. I've published a GitHub module which is provides a Get-WmiObjectCustom function as a nearly feature complete replacement of Get-WmiObject. Pull back the contents of the GitHub repository into a Modules\WmiObjectCustom folder, and
Import-Module WmiObjectCustom
Get-Help Get-WmiObjectCustom
# Replace Get-WmiObject with Get-WmiObjectCustom in your scripts.
Get-WmiObjectCustom Win32_Volume
Default timeouts are 10s for connection and 30s for enumeration of results, but these can be controlled with the parameters.
What's missing?
-AsJob and -Recurse. I could not find a way to exactly reproduce the jobs created by the v3 version of Get-WmiObject (they have a special type), and I could not understand exactly how the -Recurse parameter worked.
Other notes
There was a previous implementation of Get-WmiObjectCustom but it was not a drop-in replacement like this. Adding all the other parameter sets and confirming the behaviour was the same took much longer than you thought it would.
There's also an outstanding Connect item to add a timeout parameter to Get-WmiObject but IMHO it's useless to add it in later PowerShell considering that most of us are stuck on v2 or v3 and need it now.