Enable WMI Explorer Remote Connection Permissions

• Scripting
• Windows PowerShell

One of my first tasks, after I was hired at SAPIEN, was to figure out why users couldn’t view WMI classes on remote computers and turn the solution into an easy-to-follow blog post. After completing that, I had to turn it into a script so that it was even easier to set up. Although I managed to complete the script, there was the catch that it worked only on Windows 8. I couldn’t figure out why it wasn’t working on Windows 10. With the help of a couple of SAPIEN MVPs (thanks, Mike and James!), I’m happy to share that I have a script that works on Windows 7, 8, and 10.

To use the script, you can download it here: Set-WMIExplorerPermissions. Or you can also get it from within WMI Explorer in the ribbon. Click the Tools tab and use one of the new Open/Copy Script buttons. Open Script launches the script in your default program of choice whereas Copy Script will export it to the place of your choice:

Run the script locally, in an elevated session (Run as Administrator), on the machine that you want to access. This script is not designed to be run remotely, for example, by using Invoke-Command. Because it grants permission to the current user, be sure that the script runs in the user account of the person running WMI Explorer.

It requires PowerShell 3.0+ and in order to follow the progress of the script, use its Verbose parameter.

Windows 8 v. Windows 10

I couldn’t get the previous script to run on Windows 10 because you have to enable Windows Management Instrumentation (WMI) in the firewall. On Windows 8, you only have to enable Windows Remote Management (WRM). To solve the firewall problem, if you have the NetSecurity module and the WMI/WRM rule groups, I use the Set-NetFirewallRule cmdlet . Otherwise, I use netsh to create the rule groups and set the permissions. If the user doesn’t have permission to modify the results, an exception is thrown.

Error Checking

The last major change was to prevent errors and properly handle any errors that might have been missed. For example, in the original script, I added the current user to the DCOM Users Group, but never actually checked to see if the user was in the group. Now, it checks to see if the current user is in the DCOM Users Group and, if so, it’ll skip over this step; otherwise it adds them.

Also, instead of continuing in the background if an error was encountered, I throw terminating errors so that the user knows where it went wrong and we can fix it for a future release.

Devin Leaman is the Jr. Software Test Engineer at SAPIEN Technologies, Inc. You can find him on the SAPIEN forums and follow him on Twitter at @SAPIENTech and @dleaman212.

• Next