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:


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:


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:


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


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:


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


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.

Dynamic Remote Desktop Connection Manager connection list

Microsoft recently released a free tool for managing multiple remote desktop connections called “Remote Desktop Connection Manager”.

A sample screenshot:


There are several nice features, such as “Connect group” which lets you connect to all servers in a group at once:


On the “Group Properties” you may set common settings for all connections in the group, like logon credentials:


Further, there are group properties for RDS Gateway (formerly TS Gateway), display settings, local resources and so on.

There are several applications for remote desktop connections on the market, and some of them got these settings as a per server setting. Its nice to be able to group servers and configure common settings.

Dynamically creating the connection list

When you work in larger environments with hundreds, maybe thousands of servers, setting up each connection manually isnt an option.

Since Remote Desktop Connection Manager stores the config-files in xml-files, its rather easy to create dynamic config-files for a domain using Windows PowerShell. Ive created a script to accomplish this, called New-RDCManFile.ps1, available from here. It uses Microsofts PowerShell-module for Active Directory, which is available in Windows Server 2008 R2 and RSAT for Windows 7.

The script does the following:
Creates a template xml-file
Inserts the logged on user
s domain name in the file properties
Inserts the logged on users domain name in the group properties
Inserts the logged on user
s username in the logoncredentials section
Inserts the logged on users domain name in the logoncredentials section
Retrieves all computer objects from Active Directory with the word “server” in the operatingsystem property
Adds each computer object as a server object
Saves the XML-file to %userprofile%domain-name.rdg

When done you can open the rdg-file in Remote Desktop Connection Manager. I would recommend you to insert your password in the Group Properties to avoid being asked for credentials for each connection.

Feel free to customize the script to your needs, in example by editing the XML-template to edit the Group Properties. Another customization might be creating a group for each server OU for enhanced overview in larger environments.

If you would rather use Quests PowerShell Commands for Active Directory (which works on downlevel operatingsystems like Windows XP and Windows Server 2003), or any other way to retrieve the server names, you may customize this on line 110.

You might also want to schedule the script to run on a regular basis, saving the file to a central location. This way the IT personnel will always have access to the latest version with the most recent servers added.

If you got any further ideas or comments, please let me know in the comments section below.