Get-PrinterDriver driver version

Windows Server 2012 introduced the Print Management Cmdlets in Windows PowerShell, which is also available on Windows 8 if you install the Remote Server Administration Tools.

What I want to show in this article is a challenge when working with the Get-PrinterDriver cmdlet, related to version info.

Let us have a look at the default output:

image

With an IT Professionals mindset, the MajorVersion property shown in the default output would probably be the printer drivers driver version, right?

Let us have a look at the same printer drivers using the Print Management MMC Console:

image

If we compare the two outputs, an educated guess would tell us that the MajorVersion property in the output of Get-PrinterDriver is actually the driver type (for example “Type 3 – User Mode”).

So how can we get the “Driver Version” property in the Print Management MMC Console in PowerShell? Let us use Get-Member to explore what properties is available on an object produced by Get-PrinterDriver:

image

It seems like the property “DriverVersion” is what we want, let us try:

image

This does not look very promising. The data we want is there, but not in a human readable format. The data is in an uint64 format, and would need to be converted in order to see the same values as we get in the Print Management MMC Console.

We can find an explanation on how the data is represented in this article on MSDN:

image

By using Select-Object we can convert the DriverProperty value into the same format as the Print Management MMC Console:

image

Thanks to PowerShell MVP Keith Hill for assisting with the conversion process.

I have also filed a suggestion on Microsoft Connect suggesting that more user friendly driver version information should be available by default on the objects created by the Get-PrinterDriver cmdlet.

If you find the need to provide feedback to Microsoft, whether it is bug reports or feature suggestions, you can find more information on how to do this in a previous article I have written.

Adding printer drivers from a print server using Windows PowerShell

Managing printer drivers in a Remote Desktop Services (formerly Terminal Services) environment can be a challenge for administrators. There are many ways to ease this challenge, including third party solutions such as ThinPrint and UniPrint. When “thick” drivers are used on the RDS servers, all printer drivers must be installed locally on every server. Citrix XenApp has a printer driver replication feature which makes it possible to distribute printer drivers from a source server to one or more destination servers in a farm.

There might be situations where none of the mentioned solutions can be used for various reason, i.e. financial costs. A common way to solve this problem is to map all printer connections from a specified print server using administrative credentials during the initial setup of each RDS server. This solves the problem, but it can be time consuming as all printers that uses the same driver is being installed. Even though the driver is already installed on the local computer, it takes some time to process each printer connection.

I recently faced this challenge, as the installation of all printer connections from a few specified print servers took 30-40 minutes using a legacy script. I then wrote an advanced function in PowerShell to make the procedure more effective. This was accomplished by installing a printer connection only for unique printer drivers.
An example: A print server has 500 shared printer objects, while there is only 10 unique printer drivers. It would make more sense to add a printer connection (in order to install the driver) to 10 printer objects rather than 500, given the time consumed by installing a printer connection.

The function is available for download from here.

Sample usage and output:

image

 

image

There is a switch option added to the function called Clean. If this parameter is specified the function will also remove all mapped printer connections for the current user.

The function doesn’tt provide any log options. However, it produces PowerShell objects, so it would be easy to pipe the output to a file.
An example on how to export the output objects to a csv-file:

image

But what about printer drivers added to the print servers after the function is run on an RDS server? One way to solve this could be adding the PowerShell function to a script-file which is set up as a scheduled task to run i.e. once a day on every RDS server.  If the scheduled task is set up using Group Policy Preferences, it will be automatically created on every new RDS server that is added later on. Beside scheduling the task to run at specified intervals, the print server administrator may also invoke the scheduled task remotely on every RDS server whenever a new print driver is added to a print server. The details on how to do this is previously described in this blog-post.

Since the function might be run several times on the same computer, it also checks if the driver to be installed is already in place on the local computer. This means that after the first run, only printer drivers added to the print server after the first run is actually installed. This makes the script more effective, and depending on the number of shared printer objects on the specified print server, it shouldn'tt run for many seconds.

Coming back to the before mentioned example (~600 printer objects, ~50 unique drivers) where it took 30-40 minutes to install printer drivers from a print server, when using the Add-PrinterDriver PowerShell function the execution ran for 4 minutes. After the first run, subsequent executions ran for  20 seconds.

Automate Group Policy Preferences printer-management using Windows PowerShell

Ive 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 Softwares Group Policy Automation Engine, Ive 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%DocumentsWindowsPowerShellModulesGPPreferencesPrinters
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.

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 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.

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:

image

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:

image

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”:

image

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”:

image

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

image 

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”:

image

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

image

Note the “Unique ID” (GUID).

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

image

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:

image

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

image

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:

image

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:

image

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

image

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

image

Here is an example output of the logfile:

image

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:

image

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 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-serverprinter” /revoke=”Power Users”
subinacl.exe /printer “\print-serverprinter” /grant=”DOMAINDomain Users”

The tool can be downloaded from here.