Avantgarde Technologies

<a href="http://www.avantgardetechnologies.com.au">Avantgarde Technologies</a>
Perth's IT Experts

Sunday, January 31, 2010

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!

25 comments:

  1. Excellent Post !

    ReplyDelete
  2. After running the winrm quickconfig command i get the exact same error as before:

    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".

    not sure how to solve this issue.

    ReplyDelete
  3. I was also getting the same errors, any idea how it is mended?

    ReplyDelete
  4. great feature, great article!

    ReplyDelete
  5. Any solutions to the above error? I have winrm listening and did winrm quickconfig on the Vista and Server 2008 which I am trying to get to communicate with each other and am still getting this error.

    ReplyDelete
  6. I have a windows 2003 R2 and in installed winrm.
    Its working perfectly for
    winrm e wmi/root/cimv2/WIN32_NetworkAdapter
    but not working for
    winrm e wmi/root/wmi/MSFC_FibrePortHBAAttributes
    any reason why its not working?

    Any help is highly appreciated.
    Thanks

    ReplyDelete
  7. The above is seen in windows server 2008 R2 too.,
    Only windows server 2008 seems to work for me :(

    ReplyDelete
  8. Very Helpful, Thanks a lot!!!

    ReplyDelete
  9. Can you help me please ...

    ReplyDelete
  10. Hi Clint ! I am Kunal , i am working as Software Engineer and i am having a problem of port no 443[https] access for my windows 2003 r2 machine ... I need your help , How can i make work HTTPS SSL access in windows 2003 r2 machine ? Please reply me the procedure should be take for it and also the syntax line to invoke it ...

    Any help is Highly Appreciated ....
    Special Thanks !!!

    ReplyDelete
  11. Check port 5985 by default and 5986 for SSL based encryption... WinRM v2

    ReplyDelete
  12. Hi Clint ! Kunal here :- Thanks for reply ... But can you just detailed me about this ?

    ReplyDelete
  13. WinRM 1.1 listens on port 80/443 by default. WinRM 2.0 on Windows 2008 R2 and Windows 7 use 5985 by default and 5986 for SSL based encryption.

    WinRM 1.1 had some smart code which allowed port 80/443 to be shared with the IIS. However when implementing network load balancing, as NLB takes control over the network stack it breaks this smart code. As a result MS had to move the WinRM ports to 5985 and 5986 for SSL in version 2.0

    ReplyDelete
  14. Hi Clint ! Kunal here :- Thanks for your reply ... It was very helpful to me :-)

    ReplyDelete
  15. Note: To remotely manage a non-winrm system you can use the traditional "Computer Management" instead of "Server Manager" MMC

    ReplyDelete
  16. hacker's wet dream!

    ReplyDelete
  17. SCVMM 2008 R2 SP1 reconfigures the WinRm port to 80 using a standard install.

    ReplyDelete
  18. Good post. Out of interest you perform some actions on your remote machines with PowerShell commands. Just wondered what the advantages would be. As for port 80, I am trying unsuccessfully to get my XAMP (Apache) server to listen on port 80 ( after turning off IIS7 ) - it will of course work on port 8080.

    ReplyDelete
  19. http://blog.powershell.no/2010/03/04/enable-and-configure-windows-powershell-remoting-using-group-policy/
    This article may help for the above post

    ReplyDelete
  20. Thanks for the article. I actually came across whilst I was trying to workout how to force authentication to Kerberos as I had setup a hardened WinRM config to use HTTPS and Kerberos via GPO. For those that might also need this in the future then the answer is you must use the -r switch to indicate remote machine (even though you maybe local) and you must use the -a switch to indicate the use of Kerberos. So to query the WinRm configuration of a local machine (testmachine) where HTTPS is enabled and only Kerberos authentication the command is:

    winrm get winrm/config -r:testmachine -a:kerberos

    Hope that helps others, you can also find a list of switches at http://ss64.com/nt/winrm.html

    Paul

    ReplyDelete
  21. if WinRM is not enabled and configured by default, you'll be in a catch-22 situation. how do you remotely enable and configure WinRM when you rely on WinRM for remote command execution?

    ReplyDelete
  22. You can enable it via Group Policy anonymous http://www.briantist.com/how-to/powershell-remoting-group-policy/

    ReplyDelete