List a Printer in Active Directory Using a CNAME

(See also David’s comment below, which uses the native ActiveDirectory module)

This was a fun one for me…

One of the great questions we are dealing with now is how to make printers easy to locate on the network. Traditionally, users mapped a printer by UNC path only. This is not always helpful when identifying location and features. Although our printers are published in Active Directory, browsing the directory for a printer is not standard practice. I have to take some of the blame for this since I worked at our Help Desk for several years and reinforced this method. Now, I am trying to convince others that browsing the directory is much simpler and allows for greater freedom in printer naming (i.e.: including location information in the printer name is no longer critical).

However, after tackling how to list more than 20 directory printers in the first “Add Printer Wizard” screen of Windows 7 (http://community.spiceworks.com/how_to/show/1374), I unearthed a problem: When browsing the directory, Windows will map the printer via its print server’s Windows name, rather than a CNAME (or, alias). That is kind of a no-brainer when you consider how that information gets into AD from the server, but it is an important point to note. Why is this a problem? We use an alias for printer mappings so we can swap print servers without axing all printing. If everyone maps directly to the server’s Windows name, they will lose their mapping when that server is replaced. Other IT shops use DNS round-robin to load-balance print servers. Adding a printer from the browser negates that benefit.

There are two options at this point. First, you can choose to add the printers to AD manually. This allows you to modify the UNC path and server name without a fuss. However, it does not update features, model, location, etc. automatically. When you chose “List in the directory” from the print server, all of this is handled automatically. The second option, which I suggest, is to let the print server list your printers and update them for you. This, of course, requires a workaround for the alias.

The Quest for Option 2

Naturally, I hit the Googles. When a few searches turned up nothing, I had a realization: All of this information is in AD and has to be accessible. I turned to Quest’s AD cmdlets and began exploring the properties of the AD object known as a “printqueue”. I was surprised to find these objects nested within the print server’s container. Three properties carried importance to me: serverName, shortServerName, and uNCName (interesting capitalization, by the way). In the end, the only property in this list that determines the network path to the server is uNCName. But, the other properties are good to update for display purposes.

Using Quest Active Roles, I was able to update the relevant properties:

set-QADobject CN=SOMESERVER-SomePrinter,CN=SOMESERVER,OU=Servers,DC=domain,DC=com -objectattributes @{servername="prints.domain.com";shortservername="prints";uNCName="\\prints.domain.com\SomePrinter"}

You can also use the printer’s name instead of its distinguished name. For example, instead of “CN=SOMESERVER-SomePrinter,CN=SOMESERVER,OU=Servers,DC=domain,DC=com” you could simply use “SOMESERVER-SomePrinter”. In most organizations, this should be distinguished enough.

Directory-Wide Update Script

#Add the Quest Active Roles AD Management snapin but silently continue if it fails
 Add-PSSnapin Quest.ActiveRoles.ADManagement -EA 0

#Variables for the print servers' real names, based on DN
 $PrintServersDN = @("CN=SOMESERVER-SomePrinter,CN=SOMESERVER,OU=Servers,DC=domain,DC=com")
 $PrintServersDNS = @()

#Variables for the print server's CNAME/alias
 $PrintServerAlias = "prints"
 $PrintServerAliasDnsSuffix = "domain.com"
 $PrintServerAliasLong = "$PrintServerAlias.$PrintServerAliasDnsSuffix"

#Get all the print servers' FQDNs and add them to the $PrintServersDNS array
 ForEach ($s in $PrintServersDN){
 $serverDNS = (Get-QADComputer $s | select DnsName).DnsName.tolower()
 $PrintServersDNS += $serverDNS
 }

$printers = get-qadobject -type printqueue -includeallproperties | where {$PrintServersDNS -contains $_.servername}

If ($printers -ne $null){

Foreach ($p in $printers){
 $printShareName = $p.printsharename
 $printerDN = $p.DN
 $uncName = "\\$PrintServerAliasLong\$printShareName"
 set-QADobject $printerDN -objectattributes @{servername="$PrintServerAliasLong";shortservername="$PrintServerAlias";uNCName="$uncName"}
 }
 }

Else{Write-Host "No changes to be made"}

I was excited by the results. The Add Printer Wizard picked up the new alias and mapped the printer according to the server’s alias. The downside? Every time I made a configuration change on the print queue, the server (as mentioned earlier) automatically updated AD with the print server’s Windows name. That’s when the wonderful Task Scheduler came to my rescue. I could simply setup a task triggered by 306 events in the Microsoft>Windows>PrintService>Operational log. But, this took a lot more study and brainstorming than I expected. And I learned a lot more about the Task Scheduler.

Here was the big question: “How can I run a script every time a printer’s configuration changes that will not have to update the whole directory every time?” As I considered triggering only one event that had a long enough pause to cover all changes in the even of a mass-update, I stumbled across this post: http://blogs.technet.com/b/otto/archive/2007/11/09/find-the-event-that-triggered-your-task.aspx. It shows how to create and pull variables from a scheduled task using Value Queries. This may not be news to you, but it was to me. Good news. I was able to write a script (shared below) that triggers at each printer configuration change and updates only that printer. Then, I hit another wall: a race condition. When the script fired right away, it would not detect any changes in AD because of either replication or a delayed write. Delaying the task by 30 seconds did the trick. It’s not perfect, but it does work. You can tweak your own settings. I just have to avoid changing two printers less than 45 seconds apart.

Single Update Script

Param(
[string]$PrinterName
)

#Add the Quest Active Roles AD Management snapin but silently continue if it fails
Add-PSSnapin Quest.ActiveRoles.ADManagement -EA 0

#Get the printer's share name (in case it is different than the printer's name)
$PrinterShareName = (Get-ItemProperty hklm:\system\currentcontrolset\control\print\printers\$PrinterName)."Share Name"

#Variables for the print server's real names
$PrintServer = (Get-Item env:computername).Value
$PrintServerDNS = (Get-QADComputer $PrintServer).DnsName

#Variables for the print server's CNAME/alias
$PrintServerAlias = "prints"
$PrintServerAliasDnsSuffix = "domain.com"
$PrintServerAliasLong = "$PrintServerAlias.$PrintServerAliasDnsSuffix"

#Find the printer object in AD
$PrinterADname = "$PrintServer-$PrinterShareName"
$PrinterADobject = Get-QADObject -Type printqueue $PrinterADname -IncludeAllProperties | where {$_.servername -eq $PrintServerDNS}

If ($PrinterADobject -ne $null){

$printerDN = $PrinterADobject.DN
$uncName = "\\$PrintServerAliasLong\$PrinterShareName"
set-QADobject $printerDN -objectattributes @{servername="$PrintServerAliasLong";shortservername="$PrintServerAlias";uNCName="$uncName"}
Write-Host "Done"
}

Else{Write-Host "No changes to be made"}

Please note, this script is intended for Server 2008. Server 2003 stores its printer elsewhere in the registry. While modifying the script to detect and respond to Server 2003 and Server 2003 x64, I realized it probably would not be helpful anyway as a triggered event.

To complete the process, I created a task (following the steps in the linked Technet blog above) which set “param1” to the task’s variable “$(param1)”. This was passed in as the “$PrinterName” parameter variable in the PowerShell script. Here is the Value Query I created in the task:

<ValueQueries>
<Value name="param1">Event/UserData/PrinterSet/Param1</Value>
</ValueQueries>

Further configurations included setting the task to delay itself by 30 seconds and not launch a new instance if triggered. Otherwise, you may get 20 parallel processes. That’s basically it:

1. Create your script
2. Create a scheduled task based on an event 306 in the PrintService>Operational log, delay it by 30 seconds, and make sure it passes the printer name parameter to your script

The directory-wide script is good for cleanup, but the single update script is better for regular updates. This should keep your directory up-to-date with your print server(s) CNAME.