Set-WSManQuickConfig Error When Running PowerShell Enable-PSRemoting Cmdlet on Web Server

I recently ran into an issue when trying to access one of my Web Servers with PowerShell remoting. Here’s a simple test to show the error:

My first thought was that PowerShell remoting wasn’t enabled on the target computer. So let’s try to run this without remoting:

No luck with using that route either. I headed over to the web server and ran the Enable-PSRemoting Cmdlet and received another error:

Set-WSManQuickConfig : The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. 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”. At line:50 char:33 + Set-WSManQuickConfig <<<< -force + CategoryInfo : InvalidOperation: (:) [Set-WSManQuickConfig], InvalidOperationException + FullyQualifiedErrorId : WsManError,Microsoft.WSMan.Management.SetWSManQuickConfigCommand

I tried using the -Force option as specified in the error message but that didn’t help either. The problem was that this web server was running IIS and Apache so a registry key named “ListenOnlyList” had been added to prevent IIS from listening on all IP addresses:

The solution to this particular problem was adding the loopback IP to the listen only list which seems to be an issue with PowerShell remoting. Someone else has already logged this same issue on Microsoft Connect.

There are a couple of different ways to add the loopback address (127.0.0.1), either by editing the registry or by using netsh as shown in this Microsoft KB article. You’ll need to restart the server once the changes are made (the article states to restart services, but that didn’t work). You’ll then be able to enable PowerShell remoting:

I did run into an issue with one out of four servers where Apache wouldn’t start after adding this and rebooting. It appears that IIS must be listening on all the IP addresses that Apache is not listening on (or at least that was the only difference I could find in the four servers). I had one IP addresses that neither Apache or IIS was listening on and once it was added to the ListenOnlyList for IIS, Apache, IIS, and PowerShell were all happy.

Test this and be sure to read my disclaimer on the bottom right side of this site before attempting this on a production system.

µ

Leave a Reply

%d bloggers like this: