Enable and configure Windows PowerShell Remoting using Group Policy

March 4, 2010

As you may know, Windows PowerShell 2.0 introduced a new remoting feature, allowing for remote management of computers.

While this feature can be enabled manually (or scripted) with the PowerShell 2.0 cmdlet Enable-PSRemoting, I would recommend using Group Policy whenever possible. This guide will show you how this can be accomplished for Windows Vista, Windows Server 2008 and above. For Windows XP and Windows Server 2003, running Enable-PSRemoting in a PowerShell startup script would be the best approach.

Windows PowerShell 2.0 and WinRM 2.0 shipped with Windows 7 and Windows Server 2008 R2. To take advantage of Windows PowerShell Remoting, both of these are required on the downlevel operating systems Windows XP, Windows Server 2003, Windows Vista and Windows Server 2008. Both Windows PowerShell 2.0 and WinRM 2.0 are available for download here, as part of the Windows Management Framework (Windows PowerShell 2.0, WinRM 2.0, and BITS 4.0).

 

Group Policy Configuration

Open the Group Policy Management Console from a domain-joined Windows 7 or Windows Server 2008 R2 computer.

Create or use an existing Group Policy Object, open it, and navigate to Computer Configuration->Policies->Administrative templates->Windows Components

Here you will find the available Group Policy settings for Windows PowerShell, WinRM and Windows Remote Shell:

image

To enable PowerShell Remoting, the only setting we need to configure are found under “WinRM Service”, named “Allow automatic configuration of listeners”:

image

Enable this policy, and configure the IPv4 and IPv6 addresses to listen on. To configure WinRM to listen on all addresses, simply use *.

No other settings need to be configured, however, I`ve provided screenshots of the other settings so you can see what`s available:

image

image

image

image

There is one more thing to configure though; the Windows Firewall.

You need to create a new Inbound Rule under Computer Configuration->Policies->Windows Settings->Windows Firewall with Advanced Security->Windows Firewall with Advanced Security->Inbound Rules:

image

The WinRM port numbers are predefined as “Windows Remote Management”:

image

With WinRM 2.0, the default http listener port changed from TCP 80 to TCP 5985. The old port number are a part of the predefined scope for compatibility reasons, and may be excluded if you don`t have any legacy WinRM 1.1 listeners.

image

 

image

When the rule are created, you may choose to make further restrictions, i.e. to only allow the IP addresses of your management subnet, or perhaps some specific user groups:

image

Now that the firewall rule are configured, we are done with the minimal configuration to enable PowerShell Remoting using Group Policy.

image

On a computer affected by the newly configured Group Policy Object, run gpupdate and see if the settings were applied:

image

As you can see, the listener indicates “Source*”GPO”, meaning it was configured from a Group Policy Object.

When the GPO have been applied to all the affected computers you are ready to test the configuration.

Here is a sample usage of PowerShell Remoting combined with the Active Directory-module for Windows PowerShell:

image

The example are saving all computer objects in the Domain Controller Organization Unit in a variable. Then, a foreach-loop are invoking a scriptblock, returning the status of the Netlogon-service on all of the Domain Controllers.

 

Summary

We`ve now had a look on how to enable and configure PowerShell Remoting using Group Policy.
There are an incredible number of opportunities opening up with the new Remoting feature in Windows PowerShell 2.0. For a complete walkthrough on how you can use this new feature, I would like to recommend the excellent Administrator’s Guide to Windows PowerShell Remoting written by Dr. Tobias Weltner, Aleksandar Nikolic and Richard Giles.


Validate SPN mappings using Windows PowerShell

January 28, 2010

 

What is a SPN mapping?

A Service Principal Name (SPN) mapping allows a service running on an Active Directory computer to be associated with a domain account that are responsible for the management of the service. This allows the use of mutual Kerberos authentication, and an account defined in a SPN mapping are able to request Kerberos tickets on the requesting user`s behalf. Examples of services that uses Kerberos and SPN mappings include SQL Servers, web servers, LDAP servers, Exchange servers and so on.

Validation of SPN mappings

A SPN mapping must be unique within an Active Directory domain, and duplicate mappings will result in problems for the involved services.

While the command line tool setspn.exe, which are used for managing SPN mappings also can be used for queries, I wanted to use Windows PowerShell to accomplish this. I`ve put together a script module with two functions:
Resolve-SPN – Resolves the provided SPN mapping
Resolve-AllDuplicateDomainSPNs – Resolves all SPN mappings in the domain and reports duplicate mappings

The script module are available on the TechNet Script Center Gallery, click here for the direct link.

Save the script module as a psm1-file in the following directory: %userprofile%\Documents\WindowsPowerShell\Modules\SPNValidation
 
You need to manually create the 3 subfolders under %userprofile%\Documents if they doesn`t exist.

When done, start Windows PowerShell and type the following command:

image

You should now see the SPNValidation module.
Import the module with the Import-Module cmdlet:

image

Resolve-AllDuplicateDomainSPNs can be executed without any parameters:

image

Resolve-SPN has one mandatory parameter: –SPN
Example usage:

image

Note that the PowerShell Active Directory module for Windows
Server 2008 R2 are required, because the Get-ADObject cmdlet are used in one of the script module`s functions.
The PowerShell Active Directory module are also available in Remote Server Administration Tools (RSAT) for Windows 7.


Automate Group Policy Preferences printer-management using Windows PowerShell

January 18, 2010

I`ve written a couple of blog posts earlier on Group Policy Preferences and printer deployment using Group Policy.

Using Group Policy Preferences is a very flexible way to deploy printer connections. This is also very manageable in smaller environments. What if you got hundreds, or even thousands of printer connections you need to deploy? Do you want to sit down and make several thousands of mouse clicks to accomplish the task? There are better alternatives!

Based on SDM Software`s Group Policy Automation Engine, I`ve created a script module to handle this. The script module are available from this link.

Save the script module as a psm1-file in the following directory: %userprofile%\Documents\WindowsPowerShell\Modules\GPPreferencesPrinters
You need to manually create the 3 subfolders under %userprofile%\Documents if they doesn`t exist.

When done, start Windows PowerShell and type the following command:

image

You should now see the GPPreferencesPrinters module.
Import the module with the Import-Module cmdlet:

image

As you can see there are two functions in addition to SDM Software`s cmdlet: Add-GPPreferencesPrinter and Get-GPPreferencesPrinter.

Example 1:

image

Example 2:

If you got the printers listed in an Excel spreadsheet, save the document in csv-format:

image

The csv-file may be used like this to import the printer connections:

image

image

Additional functions and parameters will later be added to the script module, i.e. Remove-GPPreferencesPrinter and Item-Level Targeting. Note that example usage for Item-Level Targeting are provided in the Group Policy Automation Engine User Manual.


Outlook signature based on user information from Active Directory

January 9, 2010

To provide a consistent company image all users should use the same signature template in their Outlook profile. I`ve created a Windows PowerShell-script to deploy a consistent Outlook signature to users, based on user information retrieved from Active Directory. I`ve used the fields “Display name”, “Title, “E-mail” and “Telephone number”, however, additional fields may be added to suit your needs.

 

Step-by-step

1) Download the script from here. Save it to a UNC-path accessible for all users.

2) Adjust the custom variables:

image

3) From an Outlook client, create a signature based on your company template:

image

4) Copy the signature files from %appdata%\Microsoft\Signatures to the UNC-path specified in the SigSource-variable in the script:

image

5) Open both Company Name.rtf and Company Name.htm in Microsoft Office Word and insert the following bookmarks:

image

Mark each word, e.g. “EmailAddress”, go to “Insert”, press the “Bookmark”-button and name the bookmark “EmailAddress”. It`s important that the names of the bookmarks are “DisplayName”, “Title”, “TelephoneNumber” and “EmailAddress”.
This is because these bookmarks are replaced by the information retrieved from Active Directory for the logged-on user.

6) When appropriately tested, deploy the script to end users. This may be accomplished by e.g. Group Policy:

image

 

Additional information

Sample signature created using Set-OutlookSignature.ps1:

image

Active Directory object for sample user:

image image

Settings are stored in HKCU in the registry:

image

A few notes:
-Existing signatures are preserved
-Users are allowed to make customizations to their signatures until a new version are deployed. Then the exisiting company-signature will be overwritten.


Mapping printers based on Active Directory group membership using Windows PowerShell

November 28, 2009

While researching for a logon script setup for mapping network printers using Windows PowerShell, I thought of using the Windows native tool printui.dll for the actual printer mappings.
However, I was`nt quite sure how to check for a users` group membership in Active Directory. This sure can be accomplished with a tool like Quest`s PowerShell Commands for Active Directory. However, installing this on every domain computer wasn`t an option.
Then I found Andy Grogan`s PowerShell function for determining AD group membership.

Based on this function, and the printui.dll the task was easy to accomplish. I`ve published a sample script to PoshCode.org, available from here.

You may also want to check out “PrintUI.DLL User’s Guide and Reference“.

Tested with Windows PowerShell v 1.0/2.0 and Windows XP/Vista/7.

As an alternative, you may also want to check out this blog post on mapping printers using Group Policy.


Bulk-create printer objects on print servers using Windows PowerShell

November 7, 2009

When installing a new print-server with several hundreds or thousands of printer objects there arent`t too much fun doing this manually.

Here are 3 steps to automate this process:

1) Install all the necessary printer drivers on the printserver

2) Create a csv-file with a listing of all printer objects and their properties

3) Bulk-import the printer objects using a script

For the 3rd step I`ve created a basic Windows PowerShell script, available on PoshCode.org from this link.

The script contains one function for creating a TCP/IP printer port and one function for creating a printer object. These functions are used in a foreach-loop cycling through the csv-file containing all the printer objects. The script are pretty basic, and should be further expanded with error handling and further details for printer properties.

The script are created and tested on a Windows Server 2008 server against a remote Windows Server 2003 server.
Running the script from Windows Server 2003 returns an access denied error, possibly due to the impersonation-model in Windows Server 2003. However, it should work from Windows Vista, Windows 7, Windows Server 2008 and Windows Server 2008 R2 against remote print-servers (2000/2003/2008/2008 R2).

Especially the ability to set NTFS permissions on the printer objects would be a useful addition in the script.

Please feel free to leave suggestions for improvements in the comments section below.

Update 09.11.2009:
I`ve got some feedback regarding the ability to set NTFS permissions on the printer objects in the script.
A utility called SubInACL from Microsoft could be used for this.

Example usage:
subinacl.exe /printer “\\print-server\printer” /revoke=”Power Users”
subinacl.exe /printer “\\print-server\printer” /grant=”DOMAIN\Domain Users”

The tool can be downloaded from here.


How to install an Excel Add-in with PowerShell

November 1, 2009

Recently I had the need to automate the process of installing Excel Add-ins in a terminalserver (or more correctly Remote Desktop Services environment since this was Windows Server 2008 R2) environment.

Since Excel Add-ins are per-user based, this was in the first place a manual setting. Of course we wanted to automate this process, so I researched a bit on the internet and found mostly VBScripts. I`ve used this KB-article as a template.

Although this worked very well, I`m trying to leverage the use of PowerShell as much as possible. Many would say that VBScripts load much faster, and are more effecient as logonscripts.
Even though PowerShell v1 was a bit slow due to the lack of assemblies not being ngen`ed, as described on the PowerShell Team`s Blog, this bug is fixed in v2 and I`m quite happy with the loading time now.

I basicly re-wrote the sample VBScript in the KB-article, the result are uploaded to PoshCode.org and available from here.

I used an if-statement to check if the Add-in are already installed, to avoid installing it on every logon.

When tested and ready for production, the script may be distributed as a traditional logonscript, or alternatively with Group Policy:

image


Active Directory group membership modifications report

October 11, 2009

Based on customer needs I`ve created a Windows PowerShell script to report Active Directory group membership modifications. The script are uploaded to PoshCode and available from here.

In Windows 2000 Server and Windows Server 2003, the following security event IDs were valid for group membership changes:

Scope Member added Member removed
Local 636 637
Global 632 633
Universal 660 661

In Windows Server 2008 and Windows Server 2008 R2 the security event IDs changed:

Scope Member added Member removed
Local 4732 4733
Global 4728 4729
Universal 4756 4757

Source for 2000/2003 event IDs.
Source for 2008/2008 R2 event IDs.

Group membership auditing are enabled by default from Windows 2000 Server to Windows Server 2008 R2, so there are no need change any auditing settings to accomplish this.
I`ve added event ID`s for both 2000/2003 and 2008/2008 R2 to the script to cover all event ID`s currently available.
Group membership changes are logged to the Security eventlog on the domain controller the modification was run against. Because of this the script are set up to get all domain controllers in the current domain and loop through the security eventlog on each of them, searching for the relevant event ID`s described in the table above.

The script are based on Alan Renouf`s Daily Report script for PowerCLI.

The “isWithin”-function are taken from Jeffrey Snover`s blog-post regarding DateTime Utility Functions.

Preview of the HTML-report the script will generate:

image

A tip would be to run the script as a scheduled task e.g. once a day, and store the file in a central location.

For those of you interested in Active Directory auditing I would recommend you to have a look at the AD DS Auditing Step-by-Step Guide on Microsoft TechNet.
Personally I think the new "directory service changes" category are very useful, which allows us to see both the old and new values on modified Active Directory user objects.


Generate random passwords for Active Directory users v2

September 29, 2009

A litte while ago I posted a script to generate random passwords for each user in a specified OU in an Active Directory environment.

Now I`ve just posted another version of this script on PoshCode.

This script are intended for another scenario:
Power users with delegated permissions to reset password for specified Organizational Units. The power users get this script available as a published application in Remote Desktop Services.


Generate random passwords for Active Directory users

August 22, 2009

Lately I had the need to create a random password for each user in a specified OU in an Active Directory environment.
I accomplished this by using Windows PowerShell and the system.random .Net-class combined with Quest`s ActiveRoles Management Shell for Active Directory.

The script are uploaded to PoshCode, and available from here.

What I would like to add, is the encryption of the $password variable. If you have some good ideas on how to accomplish this, suggestions are welcome in the Comments-section below.