Summary: Ed Wilson, Microsoft Scripting Guy, talks about troubleshooting WinRM.

 Hey, Scripting Guy! So I thought that Windows PowerShell remoting was supposed to just work. Well, it doesn't. I am confused, and don’t even know where to begin. I am pretty sure that it should be enabled, but it is not working. Can you help?

—EG

 Hello EG,

Microsoft Scripting Guy, Ed Wilson, is here. This morning it is rather foggy outside. To be honest, I am not really certain if it is fog or low lying clouds. The weather stations are talking about a hurricane, but we are in central Florida, so we will not see a hurricane. Oh, they say we may get rain. Dude, we get thunder storms every afternoon around here in the summer, so why should today be any different? Basically, no one around here is too worried about a hurricane. They are more worried about getting tickets to the game on Saturday. At least they have their priorities straight.

I also have my priorities straight. I am outside enjoying the cool, if somewhat humid, morning, and sipping a nice cup of English Breakfast tea with a cinnamon stick, lemon grass, and a half teaspoon of local honey. It is the perfect combination of sweet, mellow, and tangy that goes well with Windows PowerShell.

So EG, you are having problems with remoting.

Note This is the second post in a series. You might enjoy also reading Troubleshooting WinRM with PowerShell—Part 1.

I am assuming that you are working with the client and not on the server side. In Windows Server (I believe beginning with Windows Server 2012), we enabled WinRM by default, and so there should not need to be any additional configuration.  On the client, it is still necessary to enable Windows PowerShell remoting.

A few things to check

When troubleshooting WinRM, there are basically three things that should be tested first. These steps are:

1. Does WinRM respond?
2. Is the WinRM service running?
3. Is the WinRM service listening on the appropriate TCP ports?

The easy way to see if WinRM is responding is to use the WinRM command and specify id:

Winrm id

If you receive back error messages, the WinRM service is not responding. You should receive information about the protocol version, the schema, and the profile. Here is the command with the proper response:

And here is an example of the command with error messages. Note that in each case (the message and the error number), it says to run WinRM quickconfig.

The next thing to do is to see if the service is running. To do this, you can use either SC.exe or Get-Service.

Note  If you use Windows PowerShell as your default command prompt, keep in mind that SC is an alias for
          Set-Content. Therefore, if you want to use the SC.exe program, you need to specify SC.exe.

The following image shows the use of SC.exe. Note that SC.exe displays exit codes in addition to the service state. If you only want to see if the service is running, use the Get-Service cmdlet.

When the WinRM service is running, the output from SC.exe appears as shown here:

The last thing to check is whether WinRM is listening. To do this, I am looking for two ports: 5985 and 4701. I can use the following NetStat command:

Netstat –anop TCP

Note that in the following output, those ports are absent.

But in a properly configured system, they appear as shown here:

It is obvious that I need to configure my system. To do this, I use the Enable-PSRemoting cmdlet. This makes several changes, each of which are detailed in the output from the command. The first time I run the command I receive the following error message:

The error message says that the network connection is set to Public. I need to change the connection to either Domain or Private. Luckily, I can make this change with Windows PowerShell. I can also tell Enable-PSRemoting to skip the network check. This command is shown here:

By default, there are like four prompts—one for each change it will make. If I have read all of that and I don’t want to be prompted, I use the –Force parameter. It will simply make the changes.

Now it seems that WinRM is working. But if it were not, the next thing I would do is reboot. Sometimes it seems to want a reboot for everything to work (like the firewall changes and the listener ports). I could probably get away with disabling and enabling the network adapter, but on some systems, I don’t have to do that. I guess it is partly driver and hardware dependent.

EG, now you know more about troubleshooting WinRM. Join me tomorrow when I will talk about more cool Windows PowerShell stuff.

I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy