Windows Insider

First Look: WinRM & WinRS

Two new tools from Microosft that can drastically help server and workstation management.

In August we discussed how to set up event log subscriptions to forward log data from one Windows Vista or Windows Server 2008 computer to another. Part of configuring that subscription involves enabling the Windows Remote Management (WinRM) service on all affected machines.

This month we'll look a little deeper into WinRM and also WinRS, Microsoft's two new tools that leverage the Windows Remote Management service, and how they have the potential to change the way we manage our servers and workstations.

Remote Workhorse
WinRM is a component of Windows Hardware Management, and operates as a Web services-based mechanism for enumerating and manipulating configuration data on a Vista or Server 2008 machine. A SOAP-based protocol that is compliant with the open standards WS-Management protocol, WinRM is Microsoft's new tool for opening up a standards-based API for systems management.

If you're familiar with VBScript, then you're likely familiar with the Windows Management Instrumentation (WMI) database that has resided on every Windows machine since Windows NT. Within that WMI database is much of the hardware and software configuration of the machine, including video card information, NIC information, installed software and files, and connected printers. Everything that makes up the hardware and software of the computer resides within its WMI store.

Nearly all management tools you buy are little more than convenient skins that work with WMI to assist the administrator with enumerating information as well as changing configurations. VBScript and PowerShell scripters can do much of the same work as these tools by creating scripts to pull and update data.

WinRM enhances that capability by enabling applications to connect to WMI using a standards-based protocol that's much easier to pass through firewalls. WinRM actions operate as SOAP requests that pass over TCP port 80, essentially as an HTTP request. Because of this, systems in the DMZ that need to be managed can be done by opening just a single port in the firewall. WinRM also includes helper code that lets the WinRM listener to share port 80 with IIS or any other application that may need to use that port.

If enabling that functionality worries the security administrator in you, you can configure WinRM for multiple types of authentication prior to completing the requested action. Basic, Digest, Kerberos and even Client Certificate-based authentication means that systems outside your normal domain scope can be managed securely. Notwithstanding how authentication is configured, though, enabling WinRM does expand the attack surface of any system on which it is enabled. So, do your homework before turning it on.

Most of this new flexibility will be taken advantage of by the developers who build systems-management software. WinRM's new capabilities will enable those software manufacturers to augment their software with better management capabilities and firewall support. Scripting exposure has also been enabled, giving the scripters in the room the ability to wrap their existing scripts with WinRM's more firewall-friendly methods and properties.

For the rest of us, WinRM has a command-line tool that allows for data enumeration and manipulation from the command line. That tool, winrm.cmd, gives us some command-line capability to pull data from our WMI store without the need for complicated scripting and dozens of lines of code.

WinRM is not enabled by default. So using it first involves invoking its quick configuration by entering winrm quickconfig at the command prompt. As I wrote in August, this command starts the Windows Remote Management service and configures it for Automated (Delayed Start). If the firewall on the machine is up, it then enables an exclusion in the firewall for WinRM traffic. Lastly, it creates a listener to accept incoming remote management traffic.

Once enabled, you can use the winrm.cmd command to enumerate information on the machine. For example, to get the general properties of the computer, enter:

winrm get wmicimv2/Win32_OperatingSystem

This command alone is helpful for inventorying computers across your network as it provides over 60 pieces of information about the operating system including the last boot time, free physical and virtual memory and the OS installation date among others. Want to find out the specifics about the processes running on a remote computer? Try:

winrm get wmicimv2/Win32_Process -r:{Remote Host}

You'll get back specifics associated with running processes on that remote host including when it was created, its performance characteristics and the command line that launched the process.

Dig a little deeper into the command syntax and you'll find commands for starting and stopping services, creating new processes, and even rebooting remote computers.

Remote Stable
To be honest, the command structure for WinRM isn't all that easy to get used to, which is why the greatest use of this new capability will likely be by developers. But one useful tool that leverages WinRM can be a big help to the systems administrator: WinRS.

Similar in operation to the former Sysinternals tool PSExec, WinRS leverages Windows Remote Management to let you launch processes on remote machines. Where it differs from PSExec is in its ability to easily pass through firewalls in the same way as WinRM. For example, if you want to discover IP information about a remote machine, you can remotely launch ipconfig with the -all switch on that machine using this syntax:

winrs -r:{Remote Host} ipconfig -all

Another handy use of WinRS can be when installing software on remote systems. If you want to quietly install an application using an MSI file onto a remote machine, use the following syntax. This syntax assumes the MSI file has already been deposited into the C:\ folder.

winrs -r:{Remote Host} msiexec.exe /i c:\install.msi /quiet 

Although arguably of limited use right now, both of these tools will likely be used more heavily in Server 2008 Core installations where a console may not be present. The main problem with both tools is their near-complete lack of documentation. The help files are fairly cryptic as well, most especially with WinRM.

Keep an eye on this space, though, as Microsoft moves further toward comprehensive command-line management capability for every component of the Windows OS. This isn't the last you've heard of WinRM and WinRS.

About the Author

Greg Shields is Author Evangelist with PluralSight, and is a globally-recognized expert on systems management, virtualization, and cloud technologies. A multiple-year recipient of the Microsoft MVP, VMware vExpert, and Citrix CTP awards, Greg is a contributing editor for Redmond Magazine and Virtualization Review Magazine, and is a frequent speaker at IT conferences worldwide. Reach him on Twitter at @concentratedgreg.


comments powered by Disqus