Friday, December 11, 2009

Configuring WinRM for Powershell Remoting via Group Policy

(or "Why you should make sure your central ADMX store is current")

With the release of WinRM and Powershell 2.0 for Vista/XP/2008/2003 I'm pretty excited about the new-ish remote execution potential for managing our workstations and servers.  But before we get too excited there are a few things to note.

First, by default when you use 'Enter-PSSession' to launch a remote shell (once WinRM is configured) you will only have access to local resources.  This is because credential delegation must first be configured on the remote host and the local computer.  Unfortunately the mechanism for this delegation (credSSP) is not supported on Windows systems older than Vista.  Even though this technet article and this MSDN page had me convinced that it should work.  Perhaps there is some deeper technical reason it doesn't.  Guess it's good old psexec.exe -d for the older OSes.

Second, the article 'Multi-Hop Support in WinRM' will tell you that the 'Enable CredSSP Authentication' setting is available in group policy under Computer Configuration\Administrative template\Windows Components\Windows Remote Management (WinRM)\WinRM Client.  But as I discovered it doesn't appear if your ADMX files are not current.  I don't know when the last time I updated them was, Vista SP1 I think, but there wasn't any 'Enable CredSSP Authentication' there until I copied the newer group policy definitions from my Windows 7 workstation:

copy-item $env:SystemRoot\PolicyDefinitions\* \\domain\sysvol\domain\Policies\PolicyDefinitions -recurse

So then, on to getting a basic config working:
  1. Using a new or existing group policy object, under 'Computer Configuration\Administrative template\Windows Components\Windows Remote Management (WinRM)\WinRM Service', enable 'Allow automatic configuration of listeners' and 'Allow CredSSP authentication' for your computers that you want to allow remote connections to.

  2. The WinRM service needs to be configured to startup automatically.  Under 'Computer Configuration\Windows Settings\Security Settings\System Services' set the 'Windows Remote Management (WS-Management)' service to Automatic.

  3. For the computers you want to be able to make remote connections from you need to enable 'Allow CredSSP authentication' under 'Computer Configuration\Administrative template\Windows Components\Windows Remote Management (WinRM)\WinRM Client'

That pretty much takes care of the basic configuration.  To test our new configuration, we can either reboot the client and server systems or run gpupdate /target:computer to get the latest settings.  If you don't reboot the machines you may have to start the WinRM service manually.  Time to test the new powershell remoting, open up a new powershell instance and attempt to enter a new pssession on a configured remote computer:

Enter-PSSession -computer remoteHost -credential (Get-Credential) -authentication credSSP
OR (for XP/2003)
Enter-PSSession -computer remoteHost -credential (Get-Credential)

If everything is working correctly you should get a new prompt after a few moments that looks like:

[RemoteHost.domain] PS C:\yada\...\yada> _

Hope that helps, and have fun with it!

Friday, December 4, 2009

Group Policy Backup Script

It's group policy cleanup time for me, which means a few things:
  • I Need to bone up on group policy itself
  • I Need to get group policy cleaned up
  • I Need to automate as much as possible
Chapter 11 in Jeremy's group policy fundamentals book has some great scripts for automating backups for group policy using Powershell.  However, since the book was published the group policy team at Microsoft has released the group policy module for Powershell v2.  They also posted a script to backup all group policies that have changed in the last month.

I wanted a bit more flexibility in an automated group policy backup solution so I wrote ScheduledGPOBackups.ps1, which you can find the current code for after the jump.  The quick description is that using the configuration block in the script you can define where to back GPOs up to, how often to backup everything and how often to backup only what has changed since the last good backup.  Schedule the script to automatically run every so often depending on your needs and you should have a nice GPO backup solution.

Using this script will require that you use Powershell 2.0 with the grouppolicy module available, which means Server 2008 R2 or Windows 7 with the RSAT installed.  I'm going to keep working on it to include cleanup of old backups, backup of WMI filters and starter GPOs, etc. but I thought this was a good enough start to share.