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.


Friday, November 20, 2009

Simple discoverability function for PowerShell

Sometimes it's easy to forget the little things that have made my life with PowerShell much better and more efficient. PowerShell's verb-noun command structure is great, but when I'm typing away in the shell I prefer brevity. While the command 'Get-Alias' might sounds like it would tell you what alias(es) are available for a particular command that you're tired of typing the full name of, it doesn't. So I created a quick little one-liner in my user profile:

function Get-Aliases ($cmd) { Get-Alias | where { $_.Definition -eq $cmd } }

This simply gets all the defined aliases and compares the definition of each alias to the command you specify.  Any alias that matches is written to output.  But since 'Get-Aliases' can be a bit long I use an alias for it:

Set-Alias gals Get-Aliases

And that's it!  Now we can run:

PS> gals get-command

CommandType  Name  Definition
-----------  ----  ----------
Alias        gcm   get-command

Little shortcuts like learning aliases can go a long way to improving your experience.  Have fun with them!

Friday, October 30, 2009

PDFCreator as a Service on Server 2008

The latest version of this information can be found here.

PDFCreator is a great tool for users you just need to quickly convert a document into pdf format.  Getting it to run properly as a service on Windows Server 2008 proved to be a bit of trouble.  Here's what I did to get things working in our environment.

Install PDFCreator in 'Server installation' mode.  If  data execution prevention is enabled, PDFCreator needs to be added to the exception list.  DEP hides a little bit under Control Panel - System - Advanced system settings - Advanced - Data Execution Prevention.

Next we need to get srvany.exe from the Windows Server 2003 Resource Kit.  I decided to put it in \Program Files\oldResourceKitTools.  This article explains how to use instsrv.exe to setup a custom service that uses srvany.exe to run what we want.  Trouble is instsrv.exe doesn't work very well on Server 2008.  Thankfully we can use sc.exe to create the service in a similar way.

However, before we create the service we have to decide what credentials to have the service run as.  Depending on your environment running as the local system (the default) may be sufficient.  If PDFCreator will need to save files anywhere other than the local system we'll  need to choose either Network Service, or create a domain user for the service.  As I like to be able to control specific permissions I created a new domain user, svc-pdfcreator, with a strong password.

Armed with that information we can now create the service with the sc command:

C:\> sc create pdfcreator start= auto binPath= "C:\Program Files\oldResourceKitTools\srvany.exe" DisplayName= "PDFCreator" obj= DOMAIN\User password= password

We can double check that the service was created successfully by using sc query:

C:\>sc query pdfcreator

SERVICE_NAME: pdfcreator
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 1  STOPPED
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

Now we need to follow the registry editing instructions from KB137890 :

  1. Run Registry Editor (Regedt32.exe) and locate the following subkey:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<My Service>
  2. From the Edit menu, click Add Key. Type the following and click OK:

    Key Name: Parameters
    Class :<leave blank>
  3. Select the Parameters key.
  4. From the Edit menu, click Add Value. Type the following and click OK:

    Value Name: Application
    Data Type : REG_SZ
    String : <path>\<application.ext>

    <path>\<application.ext> is the drive and full path to the application executable including the extension (i.e., C:\WinNT\Notepad.exe)
  5. Close Registry Editor.
Almost done setting up the service.  I found that it was necessary to run PDFCreator.exe and PDFSpool.exe in "Server 2003 SP1" compatibility mode.  Go to the compatibility tab on the properties of each executable and check "Run this program in compatibility mode for:" and select "Windows Server 2003 (Service Pack 1)".

That's it!  Test the service either by running "net start pdfcreator" or from the services mmc snap-in.  If all goes well it should start successfully.

The last piece of the puzzle is setting up Auto-save in PDFCreator itself.  Run "PDFCreator Settings" from the start menu and click the 'Auto-save' link on the left side of the window.  What you setup here will vary depending on your environment.  We have a standardized structure for our users:

This setup works well for the auto-save in PDFCreator, as we can setup the auto-save directory to be:

You may have to get creative with the auto-save path if your userdata paths aren't uniform across the users that have access to the PDFCreator printer.  We could probably solve the issue by setting up a shared folder like:

Wherever you decide to have PDFCreator save its output, make sure that the account the service runs as has permissions to create and modify files and your users have at least read access.

That's it!  Hope this proves helpful for somebody out there.

Tuesday, October 13, 2009

Group Policy CSE execution order

We have all kinds of tools to help us troubleshoot group policy processing. Modeling and RSoP in the management console get used almost every week around here. Have you ever wondered in which order the client side extensions get processed in, though? Trying to find the answer only led to the helpful but not quite user friendly answer that they are processed in the numerical order they are found in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions. However, pointy clicking my way through that list wasn't going to cut it for me. Using powershell it was pretty simple to create a user friendly human readable list. The list and the command to produce it on my Windows 7 Professional workstation are below. How to get at the information remotely, or using another tool, I haven't quite worked out yet, but this seems a good place to start. Command (broken into multiple lines for clarity): $key = "hklm:\software\microsoft\windows nt\currentversion\winlogon\gpextensions" $CSEs = get-childitem $key $CSEs | sort name | foreach-object { $_.getvalue('') } Output: Wireless Group Policy Group Policy Environment Group Policy Local Users and Groups Group Policy Device Settings Folder Redirection Microsoft Disk Quota Group Policy Network Options QoS Packet Scheduler Scripts Internet Explorer Zonemapping Group Policy Drive Maps Group Policy Folders Group Policy Network Shares Group Policy Files Group Policy Data Sources Group Policy Ini Files Windows Search Group Policy Extension Internet Explorer User Accelerators Security Deployed Printer Connections Group Policy Services Internet Explorer Branding Group Policy Folder Options Group Policy Scheduled Tasks Group Policy Registry 802.3 Group Policy Group Policy Printers Group Policy Shortcuts Microsoft Offline Files Software Installation TCPIP Internet Explorer Machine Accelerators IP Security Group Policy Internet Settings Group Policy Start Menu Settings Group Policy Regional Options Group Policy Power Options Audit Policy Configuration Group Policy Applications Enterprise QoS CP Not too shabby for a first blog post since I quit and decided to pick it back up again a few years later, eh?