WBEMTest – Part 1: Testing WMI connectivity

• Author
• Recent Posts

Jeffery Hicks

Jeff Hicks is a long-time Microsoft MVP specializing in PowerShell and automation. He creates PowerShell content for Pluralsight and blogs regularly at https://jdhitsolutions.com/blog. Jeff's latest project is a premium content newsletter at jeffhicks.substack.com Follow him on Twitter as @jeffhicks.

Latest posts by Jeffery Hicks (see all)

• Use PowerShell splatting and PSBoundParameters to pass parameters - Wed, Nov 9 2022
• Using PowerShell with $PSStyle - Mon, Jan 24 2022
• Clean up user profiles with PowerShell - Mon, Jun 9 2014

Windows Management Instrumentation (WMI) has long been the management technology for Windows based systems. IT Pros have been able to access it from VBScript, the command line using WMIC.EXE, and now PowerShell. Yet WMI can be an elusive creature to tame. You may have a PowerShell tool that uses WMI but doesn’t work as expected. Sometimes the best thing is to get out of whatever tool you are using and look at WMI directly.

Starting WBEMTest

To launch the program, the easiest approach is to open the Run dialog box from the start menu and type wbemtest. You should get the screenshot below.

WBEMTest (Windows Management Instrumentation Tester)

Unfortunately, there is no way to resize the utility. But let’s see what we can do.

Connecting to a remote computer

One of the main challenges with any WMI-based script or tool is connecting and authenticating to remote systems. WMI relies on RPC and DCOM which doesn’t make it very firewall-friendly. The first step therefore is to attempt to connect to a remote computer. Click the Connect button. You should get something like the following screenshot.

WBEMTest - Connect to a remote computer

In the Namespace field, enter the path. On newer versions of Windows this defaults to root\cimv2 which is where all of the Win32 classes reside and what most people use. But if you know the path to another namespace, like root\SecurityCenter2 go ahead and use it. The default is the local computer which if that is the case all you need to do is click the Connect button.

For remote computers, prepend the computer name in the namespace path like this: \\server01\root\cimv2. WMI will use your current credentials. But you can specify alternate credentials for remote computers. Enter a username in the format domain\username. Or if connecting to a workgroup machine use the form computername\username. Enter the password and click Connect. You can leave everything else alone. Although for the most secure connection you can set Authentication Level to Packet Privacy.

At this point, if there are any errors connecting to the remote computer, you will get an error message like the RPC server is unavailable or Access is denied.

Error Number: 0x800706ba – Facility: Win32 – Description: The RPC server is unavailable

Error Number: 0x8007005 – Facility: Win32 – Description: Access is denied

Access denied should be self-explanatory. The credentials you use must have administrator rights.

If the server is not available, it may not be online or there is most likely some sort of firewall issue. If you get an error like this with WBEMTest, no Powershell or VBSCript that is trying to connect to the computer will work. This is where it helps to get out of script. Many people will think they’ve done something wrong with PowerShell when the problem is really WMI. Use WBEMTest to verify connectivity and credentials.

Summary

In my experiences training and helping out in forums 80% or more of WMI related problems are traced back to network access issues. Most likely firewall exceptions have not been enabled for WMI remote management or alternate credentials are invalid. So if you are troubleshooting a failing PowerShell command or script that uses Get-WMIObject, pop up WBEMTest and verify connectivity and credentials. In the next part we’ll look at using WBEMTest to validate WMI queries.