Windows Remote Management is the Microsoft implementation of the WS-Management Protocol. It uses SOAP (Simple Object Access Protocol) over HTTP and HTTPS, and thus is considered a firewall-friendly protocol. It was designed to provide interoperability and consistency for enterprise networks that have a variety of operating systems, to locate and exchange management information.
WinRM provides a command line interface that can be used to perform common management tasks, and also provides a scripting API so you can write your own Windows Scripting Host based scripts. In the background, WinRM relies on management data provided by WMI; however it makes the exchange of data much easier by utilizing the HTTP protocol.
Apart from WMI, WinRM utilizes the Intelligent Platform Management Interface (IPMI) driver for hardware management. The IPMI provider and driver enable you to control and diagnose remote server hardware through BMCs [Baseboard Management Controllers] even when the OS is not running or deployed. Effectively BMC is a chip connected to the processor board of a server; it has its own network adapter and hence can monitor the server in situations even when the server is malfunctioning.
So, here is some basic WinRM configuration info:
Basic Configuration:
First, to make WinRM work on the server we need the Windows Firewall to be enabled. Once that is done, open a command prompt and run the following command:
winrm quickconfig
This command performs configuration actions to enable this machine for remote management, which includes:
1. Starts the WinRM service
2. Set the WinRM service type to auto start
3. Create a listener to accept requests on any IP address
4. Enable firewall exception for WS-Management traffic (for http only)
When you configure WinRM on the server it will check if the Firewall is enabled. If so, it then enables the Firewall exception for WinRM. In case the Firewall is disabled, you should get the following error message
- WSManFault
- Message
- ProviderFault
- WSManFault
- Message = Unable to check the status of the firewall.
- Error number: -2147023143 0x800706D9
- There are no more endpoints available from the endpoint mapper.
To list all the WinRM listeners, run this command:
Winrm enumerate winrm/config/listener
You can also get the configuration information of the Service, Client and WinRS by running the following command:
“Winrm get winrm/config”
Now let us look at the different operations that WinRM supports to access WMI data.
The list of currently supported operations is:
* GET
* PUT
* ENUMERATION
* INVOKE
Using the WinRM get command you can also query different services configuration running on the server.
Example
“Winrm get wmicimv2/Win32_Service?Name=spooler”
You can also use the WinRm get command to query the remote computer:
“Winrm get Winrm/config –r:remotemachinename”
Run this to query the service of remote computer:
“Winrm get wmicimv2/Win32_Service?Name=spooler –r:remotemachinename”
To reboot a remote machine:
“winrm invoke reboot wmicimv2/Win32_OperatingSystem -r:<some computer>”
Start a service on a remote machine
“winrm invoke startservice wmicimv2/Win32_Service?name=w32time -r:<some computer>”
Additional commands are listed at the following link in case you are interested:
http://blogs.technet.com/b/otto/archive/2007/02/09/sample-vista-ws-man-winrm-commands.aspx
I’ll also use this opportunity to discuss a recent issue I faced while working with WinRM, as I have seen multiple users complaining about similar issue when working with 3rd party apps that make use of WinRM. Hopefully this may help you if you have to tackle similar issues at a later stage.
In this specific issue the customer was using a 3rd party application to collect the event logs from servers located in different sites. The application uses WinRM to collect the event logs on Windows server 2008 and R2 Servers. This application also uses a service account using which it collects the logs. When they ran the application it failed and gave Access Denied errors. The customer was working on this case thinking this to be an application issue, as they were able to collect the logs from some Windows Server 2008 machines not others.
In order to narrow the issue down, we first logged in to the server using the service account and confirmed that this account did not have any obvious permission or logon issues. Now to remove the application out of the picture we checked if WinRM is able to connect to the remote server by itself. For this, we used the wevtutil tool try querying the event logs:
“winrs -r:http://<FQDN of the server> -u:username –p:password “wevtutil qe system”
First we used the Admin account credentials to query the event log and it worked correctly. Then we tried using the Service Account that the application was using and got an ACCESS DENIED. It seemed that the service account is missing some permissions on the target box. Since we were able to login correctly using this account earlier and also could do all other normal operations with this account, we suspected the issue to be something specific to WinRM or event log permissions. So, we started by comparing the “Channel Access” (read security setting) of the target machine with that of a working machine.
Below is the command to get the Channel Access information:
“wevtutil sl system /ca”
“/ca:<Channel>” sets the access permission for an event log. “<Channel>” is a security descriptor that uses the Security Descriptor Definition Language (SDDL).
By comparing against a working machine, we found that the Authenticated Users group had DENY permissions listed on the non-working box. Because of this, we replaced the Channel Access permissions on the non-working machine with that of the working machine. Now when accessing the event logs with the service account username and password we were able to successfully query. Once this was fixed, the application started collecting the event logs from all the servers.
So, in the end it wasn’t really a WinRM issue, but one might get that impression based on the symptom.
Hope this information was helpful. For more information on WinRM, please see:
Installation and Configuration for Windows Remote Management
http://msdn.microsoft.com/en-us/library/aa384372(VS.85).aspx
Helpforsure 