If you know anything about PDQ.com, you know we get pretty excited about tools that make our lives easier. That’s why we’re such big fans of PowerShell. How big of fans are we? We’re big enough fans to add command-line functionality into our products. We’re big enough fans to add a PowerShell scanner right into PDQ Inventory. We’re big enough fans to have dedicated videos and blog posts about PowerShell. Heck, we even wear PowerShell t-shirts.
With that said, while PowerShell is excellent when it works, when it doesn’t work, it can definitely be frustrating. Usually, any issues I have with PowerShell are self-inflicted. Incorrect commands, misspelled variables, missing punctuation are all too common in my scripts. Occasionally though, I’ll run into issues that didn’t have anything to do with my poor scripting skills. Let’s take a look at an issue I ran into recently and how to resolve it.
While writing my recent blog post, What Is The PowerShell Equivalent Of IPConfig, I ran into an issue when trying to run a basic one-liner script.
Get-NetIPConfiguration -Computer “computer-name”
Running Get-NetIPConfiguration by itself locally on my computer worked perfectly, but running this command against a remote computer failed with the following error.
“Get-NetCompartment : computer-name: Cannot connect to CIM server. The client cannot connect to the destination specified in the request...”
If you want to see a very unintentional yet perfect example of this error in video form, check out our YouTube video covering IPConfig in PowerShell.
Thankfully, PowerShell is pretty good about giving us detailed error messages (I wish I could say the same thing about Windows). If you continue reading the message, it actually provides us with the solution to our problem.
“Consult the logs and documentation for the WS-Management service running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following command on the destination to analyze and configure the WinRM service: ‘winrm quickconfig’.”
Since I was working on a newly built lab, the WinRM (Windows Remote Management) service not running was definitely a possibility worth looking into. PowerShell was even kind enough to give me the command “winrm quickconfig” to test and see if the WinRM service needed to be configured.
The command “winrm quickconfig” is a great way to enable Windows Remote Management if you only have a few computers you need to enable the service on. The command will need to be run locally or remotely via PSEXEC. Here’s what happens when you run the command on a computer that hasn’t had WinRM configured.
Since the service hasn’t been configured yet, the command will ask you if you want to start the setup process. To begin, type “y” and hit enter.
After starting the service, you’ll be prompted to enable the WinRM firewall exception. Type “y” and hit enter to continue.
Once the process finishes, it’ll inform you that the firewall exception has been added, and WinRM should be enabled. This process is quick and straightforward, though it’s not very efficient if you have hundreds of computers to manage.
If you have hundreds or even thousands of computers that need to have WinRM enabled, Group Policy is a great option. With Group Policy, you can enable WinRM, have the service start automatically, and set your firewall rules.
Open Group Policy Management console
Right-click on the OU you want to apply the GPO to and click Create a GPO in this Domain, and Link it here…
Name the policy Enable WinRM and click OK
Right-click on the new GPO and click Edit
Expand Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service
Find the setting Allow remote server management through WinRM and double-click on it.
For the IPv4 and IPv6 filter, you can supply an IP address range, or you can use an asterisk * to allow all IP addresses. Once finished, click OK
Next, we’ll set the WinRM service to start automatically. Navigate to Computer Configurations > Preferences > Control Panel Settings
Right-click in the Services window and click New > Service
Change Startup to Automatic (Delayed Start)
Click the ellipsis button with the three dots next to Service name.
Find and select the service name WinRM
Select Start Service from the service action menu and then click Apply and OK
Lastly, we need to configure our firewall rules. Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security > Windows Firewall with Advanced Security
Right-click on Inbound Rules and select New Rule…
Select Predefined, and select Windows Remote Management from the drop-down menu, then click Next
Uncheck the Public profile rule
Select Allow the connection and click Finish
Congrats! Once all of your computers apply the new Group Policy settings, your environment will be ready for Windows Remote Management.
If Group Policy isn’t an option for your environment, you can use PDQ Deploy to push out the “winrm quickconfig” command to all of your computers, and we’ll use the “-quiet” parameter to make sure it installs silently without user interaction.
With PDQ Deploy, click New Package
Enter a name for your package, like Enable WinRM
Click New Step > PowerShell
Add the command winrm quickconfig -quiet
That’s all there is to it! Now you can deploy that package out to whatever computers need to have WinRM enabled.
Enabling WinRM will ensure you don’t run into the same issue I did when running certain commands against remote machines. One less thing to worry about while you’re scripting yourself out of a job… I mean, writing scripts to make your job easier.
If you’re looking for other ways to make your job easier, check out PDQ Deploy and Inventory. PDQ Deploy and Inventory will help you automate your patch management processes. We’ll do all the work, and we’ll let you take all the credit. Try PDQ Deploy and Inventory for free with a 14-day trial.