The idea is a good one.  Align with a standard in your latest technologies methods used to manage yourself, making you more usable by others.

In this post I’ll offer a quick WinRM configuration PowerShell script to get this feature configured on a Windows 2008, R2, and Windows 2012 server.  I’ll also offer feedback on the security objection and what I think is the best solution for a native Windows environment since I’ve hand to handle these often in my line of work.

Configuration Simplified

Get right to it for those not wanting to read any more.  Open a PowerShell Console as Administrator on both the client and server, servers and execute:

Write-Host "Configuring WinRM for remote deployment..."
Enable-PSRemoting -Force 
winrm set winrm/config/client `@`{TrustedHosts=`"*`"`}

More detail…

For PowerShell, WinRM is the basis of many cmdlets performing remote commands and tasks.  This includes Enter-PSSession and Invoke-Command.  These cmdlets offer powerful abilities to perform tasks on a remote computer both synchronously and in parallel, asynchronously to an array object of server names.

Believe it or not (from this lengthy write up), Microsoft wanted taking advantage of the protocol easier and less of a burden to implement.  As a result, WinRM.exe comes with a “-quickconfig” option for quick local configuration of itself, complete with a set of Microsoft’s best practice defaults.  Almost too good, and I’ll get to that below.

Therefore, the easiest thing to do is to go to a cmd prompt as an admin and run to get it all started:

WinRM quickconfig

This will set up your local service with everything to get started.  Essentially, turning on the lights.

Powershell’s flavor of this command is rolled up into  Set-WSManQuickConfig.  However, these both only modify the config of the service.  For the windows firewall, Microsoft gave us another cmdlet that’s a wrapper for Set-WSManQuickConfig.  Enable-PSRemoting cmdlet performs a few other functions as well as executing the Set-WSManQuickConfig.  Things like configuring the Windows firewall (in 2.0 it creates the exception, in 3.0 it creates a rule).

If you ride the defaults of these configurations with regards to network port, any external firewalls between your client and server will need to allow tcp 5986 bidirectional for WinRM 2.0 and above, 443 for WinRM 1.1.

Even after you run the “WinRM -quickconfig” or “Enable-PSRemoting”, you’ll find commands attempted remotely like Invoke-Command or Enter-PSSession will still fail complaining about a configuration error.  The reason is that you’ve only turned on the lights, you haven’t told the bouncer who is allowed in.  Be default, these tools do not trust anyone to connect other than…localhost.  The list of allowed servers is listed in the “TrustedHost” property of WinRM configuration.  Both of these tools the default TrustedHost list is blank.

Therefore, lets get back to the PowerShell.  Its a quick and dirty solution that’s wide open and will that need to be executed on both machines you want to configure to talk remote to one another:

Write-Host "Configuring WinRM for remote deployment..."
Enable-PSRemoting -Force 
winrm set winrm/config/client `@`{TrustedHosts=`"*`"`} 
winrm set winrm/config/winrs `@`{MaxMemoryPerShellMB=`"2048`"`}

As you can guess, “*” is everyone and may not be good enough for your needs.  Below we discuss more security aspects of a quick configuration.

Locking it down

There are complex scripts on the internet that allow for the setup of servers, even doing it remotely.  Out of the box both the WinRM and the cmdlets leave you with blank TrustedHosts.  Servers that will send or receive commands from other hosts must either have a white listed “*” or the specific servernames/IP in this list before you can connect.

The next script creates a list of servers passed as a CSV file and establishes it as your TrustedHost property.  As long as a column within your CSV file contains “Server” as a heading, those values will be included in the trusted hosts configuration and applied to the machine’s TrustedHost configuration of WinRM.

param(
	[Parameter(Position=0, Mandatory=$true)]
	[ValidateNotNullOrEmpty()]
	[System.String]
	$CSVFilePath
)

function Get-ServerList {
	param(
		$CSVFilePath
	)

	$Servers = Import-Csv $CSVFilePath
	$Servers | % {$List += $_.Server + ","}

	Return $List.Substring(0,$List.Length - 1)

}

function Configure-WinRM {
	param(
		$ServerList
	)
	Write-Host "Configuring WinRM for remote deployment..."
	Enable-PSRemoting -Force 
	winrm set winrm/config/client `@`{TrustedHosts=`"$ServerList`"`}  
	winrm set winrm/config/winrs `@`{MaxMemoryPerShellMB=`"2048`"`}
}

Configure-WinRm -ServerList $(Get-ServerList -CSVFilePath $CSVFilePath)

Note:  In both examples within the explanation, I’ve up the MaxMemoryPerShellMB.  This is optional; however, I’ve found that many tools that I may need or objects that I create are heavier than the default 150 MB amount.  I’ve found that upping it to 2048 will mitigate my running out of remote memory during processing large commands like regasm or installation packages.  Mis-configuration usually results in an obfuscated -1 exit code or just instability.  It wasn’t until I popped open process explorer that I found I was hitting a limit that most bigger executables require more of.  Totally up to you, but it is part of my server buildout now along with a correct server.csv list and features.

The Remaining Security Concerns (For Windows Environments)

TrustedHosts means only these computers can connect.  Security engineers will wonder what those connections are passing, even if its in a protected zone, between the servers listed and if that’s secure.

First the obvious, SSL is an option for WinRM.  However, I caution configuring it if your talking Windows to Windows. When asked, if you should configure SSL for security loving systems folks it can be tempting to think it is better.  The balance between and security, support and use is something we all have to deal with constantly.  In banking and healthcare it constantly audited, as it should be and I understand, layers is the answer to security.  But, WinRM with WS-Management encrypts all content transmitted over the network using Kerberos and these NTLM (machine) keys.  With Windows, a minimum of 128 bit encryption (Windows 7/2008 and up) is already in place with most later OS’s pushing the AES 256 button now.

The only thing that HTTPS will do is encrypt commands differently, that can be watered down.  Not to mention give a shelf life to your configuration the length of the validity of your certificates, before they expire.  I applaud the extensiblility, but its truly overkill in a windows environment and making something that needs to remain easy too complex; hence me leaving it out of the configuration and discussing it here.

Now, if you’re leaving a Windows environment, yes; install and configure if you’re using a non Windows product to manage a Windows machine.  That’s part of the the initiative behind WS-Management, uniform cross platform communication.  Everyone OS doesn’t have the same encryption methods as Windows baked in.  For that, I’ll have to cover another day.