What is WinRM?

WinRM is short for Windows Remote Management. It is Microsoft's new remote management standard which allows administrators to remotely manage and remotely execute programs on windows machines. Prior to this Remote Procedure Calls (RPC) had to be used for everything by collecting data from the COM and DCOM services. A popular remote management tool that used these RPC calls was the PSTools package by Sysinternals.

WinRM 1.1 first showed its face in Windows Server 2003 R2 but can now also be downloaded and installed for Windows XP and Windows 2003 from:

http://www.microsoft.com/downloads/details.aspx?familyid=845289ca-16cc-4c73-8934-dd46b5ed1d33&displaylang=en

WinRM 1.1 can also be found in:
- Windows Vista
- Windows Server 2008
- Windows Server 2008 (Core Install)

The new version of WinRM 2.0 can be found in:
- Windows 7
- Windows Server 2008 R2
- Windows Server 2008 R2 (Core Install)

Although WinRM is enabled on all these builds of windows, it is not enabled by default on any.

WinRM is based on the Web Services for Management (WS-Management) standards. WS-Management uses SOAP (Simple Object Access Protocol) requests to send send and receive instructions to remote computers. As shown on the wikipedia page - SOAP Requests are sent and received using XML. An advantage of WinRM is it uses port 80 for communication, a port that is usually always open by firewalls and client machines on a network. Because WinRM is XML based, it will also pass through firewalls that perform packet inspection on port 80.

Hold on one second you're saying - I have servers that run IIS web servers. They are already listening on port 80. WinRM is rubbish! Well Microsoft has put special code around this that allows WinRM to share port 80 with IIS for your dedicated web servers. But be careful when installing third party web servers such as apache on a windows PC - I have not tested this but it is something to be mindful of. Please leave a comment if you have more information about different applications running on port 80 with WinRM. One more thing i'd like to point out is only WinRM 1.1 listens on port 80 by default. WinRM 2.0 on Windows 2008 R2 and Windows 7 use 5985 by default and 5986 for SSL based encryption.

WinRM leverages the WMI database to perform many tasks - so make sure WMI is running and is healthy if you are looking to use WinRM. You may already be running WinRM in your environment without knowing it. Many system management products on the market use WinRM as a means of gathering data from the network and performing remote tasks. One well known product that relies on WinRM 2.0 is Powershell 2.0. Powershell 2.0 uses WinRM to remotely launch code on a remote PC.

WinRM is only one half of WS-Management. There is actually a client that communicates with the WinRM server component called WinRS (Windows Remote Shell).

A question you maybe thinking is port 80, not 443. Does this mean it's not encrypted? No all WinRM data is encrypted using whatever the "Integrated Windows Authentication" is set to on the host machine (Either NTLM or Kerberos). Alternatively if you have a PKI setup you can setup SSL for use with WinRM on your internal network. If SSL is in use NTLM and Kerberos get ignored.

Enough Talk, Lets see WinRM in action!

First lets find out if the WinRM server is running on a windows PC by typing:

winrm enumerate winrm/config/listener



This error means no the WinRM server is not running:

WSManFault
Message = 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".

Error number: -2144108526 0x80338012
The client cannot connect to the destination specified in the request. Verify that the service on the destination is running and is accepting requests. Consultthe 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".

The easiest way to start the WinRM server unless you want to do custom configuration is by using the "winrm quickconfig" command.



Hit "Y" to make the change. Next it asks you if you want to allow it to make a HTTP listener and create a windows firewall exception.



Hit "Y" to make the change. WinRM is now running and can be remotely managed by WinRS (the WinRM client).



Now re-run the "winrm enumerate winrm/config/listener" command to see if WinRM is working:



We see it listening on port 5985, this is because I'm running Windows 7 on this PC so its using WinRM 2.0.

Now from another PC I can use the WinRS client to remotely execute commands against that workstation/server by using "winrs -r:https://myserver.com" command. Please note that you need to run the command as a user in the remote computers "Administrators" group. By default WinRS will use your active windows credentials. However I do not run my computer as administrator for security purposes so I will need to specify a user account with Domain Admins rights to ensure I have correct access by using the -u: switch.

Lets try grabbing a read out of the directory structure on c:\ of the remote PC:

winrs -r:http://tursanplt01:5985 -u:domainname\useraccount "dir c:\"



As you see it returned the results of the command. I blured my credentials as this is a production network and I do not want you to even know the name of one of my domain admin account.

Also lets see what build of windows the remote computer is running by sending the "ver" command:

winrs -r:http://tursanplt01:5985 -u:domainname\useraccount "dir c:\"



6.1.7600 is Windows 7 with no service pack.

As you see WinRM is a very handy tool and can be used instead of PSExec from the Systeminternals PSTools kit. With Powershell 2.0 integration the possibilities are endless with what you can do. Lastly I would like to point out that many other 2008 features such as Event Forwarding also relies soley on WinRM so it's a must know!