- Clean up user profiles with PowerShell - Mon, Jun 9 2014
- Track user logons with a PowerShell script - Fri, Jun 6 2014
- Configuring logon PowerShell scripts with Group Policy - Tue, Jun 3 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.
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.