Mapping printers based on Active Directory group membership using Windows PowerShell

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 wasnt quite sure how to check for a users group membership in Active Directory. This sure can be accomplished with a tool like Quests PowerShell Commands for Active Directory. However, installing this on every domain computer wasnt an option.
Then I found Andy Grogans PowerShell function for determining AD group membership.

Based on this function, and the printui.dll the task was easy to accomplish. Ive published a sample script to, 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.

Deploying printers using Group Policy

Traditionally printer connections have been deployed to users with scripting, like batch (net use) and Kixtart (AddPrinterConnection).

I would now like to show how printer connections can be deployed using Group Policy. Today we have 2 possible solutions for natively deploy printers using Group Policy without the need for any scripting:

1) Group Policy Preferences – available in Windows Server 2008 and later

2) Print Management – available in Windows Server 2003 R2 and later

Using Group Policy Preferences to deploy printers are described in an earlier blog post, available here. Therefore, I wont explain any further details regarding this.

I will focus on the Print Management which has a powerful “Deploy with Group Policy” feature.

Configure printer deployment on

print servers

To use the “Deploy with Group Policy” feature, you need to install the “Print Management Component” feature from “Add/Remove Windows Components” in Windows Server 2003 R2. In Windows Server 2008/2008 R2 you need to install the “Print Server”-role from the “Add Roles Wizard”.

When installed, youll find “Print Management” under “Administrative tools” on the Start menu:


The following screenshots are taken from Windows Server 2008 R2.

When you open the Print Management Console you will see an overview of Custom Filters, Print Server and Deployed Printers:


You may add additional filters and print servers to the console, which you can read more about in the links in the bottom of this post. For now, well focus on the printer deployment part.

Right-click the printer you want to deploy, and select “Deploy with Group Policy”:


Select “Browse” to choose a Group Policy Object where the printer connection will be deployed. Select “per user” and/or “per machine” and press “Add”. Then click “OK”:


You should now receive a message stating that the deployment operation was successful. Click “OK”:


The printer will now be deployed to client computers.


Behind the scenes

To understand how the print deployment feature works, well activate the “Advanced Features” option on the “View”-menu in “Active Directory Users and Computers”:


Open the “Group Policy Management Console”, go to the Group Policy Object you deployed the printer to, and select “Details”:


Note the “Unique ID” (GUID).

Back in ADUC, expand “System” and then “Policies”:


This is where the actual Group Policy Objects in Active Directory are stored, in addition to \domain.localsysvolpolicies.

Find and expand the Group Policy Object you deployed the printer to. You will now see “PushedPrinterConnections” under the “Machine” and “User” nodes:


When looking at “PushedPrinterConnections” under the “User” node, we see an entry of type “msPrint-ConnectionPolicy”:


When we go into “Properties” on the “msPrint-ConnectionPolicy” and go to “Attribute Editor”, we can see that this represents the printer connection we added:


Deployment to client computers

Client computers running Windows Vista and later have native support for the new printer connection policies, and will work “out-of-the-box” when printer connections are added to a Group Policy.

Client computers running Windows 2000 and Windows XP doesnt support the the new printer connection policies natively. To resolve this, there are a utility called “pushprinterconnections.exe” which must be added to a logonscript in Group Policy. This utility will check the computer and user Group Policy Objects and add any printer connections defined.

This utility have 1 parameter: –log. This is useful when troubleshooting problems, and I would recommend you to use this parameter. As you can see, the utility should not be run manually from the command line:


Here is an example of the utility added to a logon-script in a Group Policy Object:


The log-files are named “ppcUser.log” and “ppcComputer.log”. These are located in the %temp% directory:


Here is an example output of the logfile:


In Windows 2000 and Windows XP, no other feedback than these log-files are provided.

In Windows Vista/Windows Server 2008 and later, the following feedback are shown during logon:


In addition, any failures are logged to the “Application”-log with Source “SpoolerSpoolss”.

Special considerations

Windows 2000 supports only “per machine” deployments when using the pushprinterconnections.exe utility.

The pushprinterconnections.exe utility wont catch “per user” connection policies when using “User Group Policy loopback processing”. You must link the GPO containing the “per user” connection policies to an Organizational Unit where the users reside.

Use ACL`s  on the printer objects on the print servers to publish the printers based on group membership. By using this approach, all printer connections may be defined in the same Group Policy Object.

My recommendations

As I said in the introduction to this post, printer connections have traditionally been deployed to users with scripting. Since there are native ways to accomplish this using Group Policy, this would be my recommendation.

Considerations for using the “Deploy with Group Policy” feature in the print server role:

-the print administrator would have an overview over all printers which are deployed with the Print Management Group Policy feature in the Print Management console
-printers can be administered in an individual GPO like GP Preferences with the Print Management console. To do so, open Group Policy Editor, expand Computer Configuration/User Configuration->Policies->Windows Settings->Deployed Printers
-it requires that pushprinterconnections.exe are run on Windows XP and Windows Server 2003 clients
-it is available with Windows XP/Windows Server 2003 R2 and later (backwards compatible to Windows 2000 Professional/2000 Server)
-it requires Windows Server 2003 Client Access Licenses (CALs)

Considerations for using Group Policy Preferences:

-it can handle more different printer types (local, TCP/IP, and shared instead of only “shared”)
-it has several additional options (deleting all existing connections, setting default printer, etc.)
-it can save a lot of GPOs because you can have many printer objects in one GPO and use “Item Level Targeting” to address each printer individually (e.g. clients in a specific IP-range, per group or even per user)
-it is easy to automate the process of adding printer objects to a GPO using Windows PowerShell, since the GP Preferences settings are store in XML-files
-it requires that Group Policy Client Side Extenstions are deployed on Windows XP and Windows Server 2003 clients
-it is available with Windows Vista/Windows Server 2008 and later (backwards compatible to Windows XP/2003 Server)
-it requires Windows Server 2008 Client Access Licenses (CALs)


Resource links

Step-by-Step Guide for Print Management
(Applies To: Windows Server 2003 R2)

Print Management Step-by-Step Guide
Applies To: Windows Server 2008

Print Management
(Applies To: Windows 7, Windows Server 2008 R2, Windows Vista)

Deploy the PushPrinterConnections.exe Utility

Bulk-create printer objects on print servers using Windows PowerShell

When installing a new print-server with several hundreds or thousands of printer objects there arentt 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 Ive created a basic Windows PowerShell script, available on 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-serverprinter” /revoke=”Power Users”
subinacl.exe /printer “\print-serverprinter” /grant=”DOMAINDomain Users”

The tool can be downloaded from here.

How to install an Excel Add-in with PowerShell

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. Ive used this KB-article as a template.

Although this worked very well, Im 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 ngened, as described on the PowerShell Teams 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 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: