Good morning AskPerf! Digvijay here to chat about print server migration. All server admins have probably had an opportunity to migrate print servers. This process can be fast and easy when migrating between the same versions of operating systems; and can be done with a bit of effort moving between Operating Systems with different architecture (e.g., moving from 32-bit to 64-bit versions of Server 2008). However, things really get challenging when we have to migrate from an older Operating System to the latest Operating System on a different architecture. (e.g., from Windows 2003 Server x86 to Windows Server 2008 R2 x64). Fortunately, there are new tools such as the Print Management Console that ships with Server 2008 R2 or, if you prefer the command line interface, then you can use PRINTBRM.EXE. However, there can be some hurdles getting all the printers migrated successfully if we do not understand the Printer restoration process and fulfill necessary pre-requisites.

Things to keep in mind during printer migrations:

1. A print queue cannot function without a driver of the same server architecture (x86 or x64) on which it exists. 

2. Unless the print processor is migrated successfully, the print queue will not show up.

3. If you are migrating from a 32-bit Operating System to a 64-bit Operating System, it is important that you have 64-bit drivers pre-installed for all of your printers, along with the 32-bit drivers. (Remember that for a 64-bit client to print to print server hosted on 32-bit Operating System, you need the 64-bit version of the driver.)

4. When a cross-architecture migration includes the migration of printer language monitors, an error will occur during the process of restoring the printers to the destination server using the PRINTBRM command-line tool. The reason for the error is that language monitor driver architecture must always be the same as the source server architecture. Therefore, when migrating from x86-based architecture to x64-based platforms, language monitor migration cannot be successful. An error posted to the event log will state that the source architecture is not the same as that of the destination server. More info about this behavior can be found in the Print Services Migration Guide.

5. When using PRINTBRM, always run commands from an Administrative command prompt

If performing a 32-bit to 64-bit migration and all the existing client machines are 32-bit, then you will have to install 64-bit drivers for all the 32-bit drivers before starting the migration. It is common to have third-party 32-bit printer drivers that do not have 64-bit equivalents. For those instances, we typically suggest using universal drivers if available but contacting the printer vendor for their input is the safest bet.

During the Printer restore in cross-platform scenarios, if the backup file does not contain driver binaries for target server platform, PRINTBRM will attempt to install the drivers from the target server’s driver store if a matching driver is available. If a matching driver for the target platform is not available (either in the backup or on the server) then the print queue will not be created and there will be errors. See below:

We will see relevant events in the event viewer also:

So to make it easy for everyone to understand, here is the straightforward way to successfully restore all the printers:

1. Install 64-bit drivers on the Windows 2003 x86 Print server (source) or install all the required 64-bit drivers on the 2008/R2 Server (target). Keep in mind that the driver name string must be an exact match. If the names do not match exactly, the migration will treat it as if the driver is not present.

2. Take a backup of the printers on the Windows 2003 source server using the Print Management Console or printbrm.exe run from the Windows 2008 R2 Server.

3. Import the backup to the 2008 R2 server.

NOTE We need to preinstall any driver that has different components when installed on x86 than when installed on x64. As long as the driver is installed then the printer installation will not be blocked unless there is a non-existent Monitor value in the Printer registry key.  If the printer (not the driver) requires this setting, then we will need to install the driver that uses this monitor on the x64 machine.  If there is no x64 monitor provided by the vendor or if the vendor provides a new x64 monitor that uses a different name, then you will need to add a printer using the x64 version of the driver on the new machine since the vendor providing the driver did not provide compatibility to the new OS.

Keeping it simple

To avoid most of these driver and component pitfalls, it’s often easiest to switch all the print processors and print monitors on the source server over to some basic defaults ones (eg: cleaning up the PRINT registry before starting with the migration). This will speed up the process and maximize the number of queues successfully migrated.

Microsoft has provided a Spooler FixIT for Windows 2003/2008 to automate the spooler cleanup process. See our previous AskPerf blog entry for information about the functionality and usage of this tool.

We also recommend removing old and unused drivers from the server before taking a backup.

However, if you do not want to go through this lengthy process of fulfilling these prerequisites, are on a time crunch, want to quickly restore the print queue information on the target server and deal with the driver worries later, then read on.

In order to quickly get the queues migrated to the new server, we can create them using the “Generic / Text only” printer driver without restoring any of original the drivers on the target. Remember that we need to have 64-bit drivers present either in the package or on the target server for the restore to finish and the print queue to be available for printing.

Here are the steps to successfully migrate all of your print queues using the in-box “Generic/Text Only” print driver:

1. On the source Windows 2003 Server, change all print processors to winprint using the following setprinter.exe command:

SetPrinter.exe \\Servername 2 pPrintProcessor="Winprint"

This can also be accomplished using WMI:

wmic printer set PrintProcessor = WinPrint

2. Install the latest update for Printbrm on the target 2008R2 server:

KB 2636591  An update to improve the restore operation performance of Printbrm.exe in Windows 7 or in Windows Server 2008 R2

3. Install a local printer on the target 2008 R2 server using the Generic / Text Only driver and share it to enable the firewall exceptions for the Print Services.

4. From the Windows 2008R2 server, take a backup of the 2003 print server using the nobin switch

(we are using the nobin switch since we don’t want to migrate any of the print drivers):

Printbrm.exe –b –s \\servername –f nobin.printerexport –nobin

5. Next, we have to modify the contents of the backup files. Expand the printerexport backup to a directory and the replace the BrmDrivers.xml, BRMLMons.xml and PProcs.xml files. The command to extract the files to a directory is:

printbrm.exe  -r -d c:\temp\expand  -f nobin.printerexport

The Expanded directory will look similar to this:

• BrmDrivers – contains a list of every driver installed on the computer and the driver files for each driver
• BrmForms – contains a list of all the installed forms
• BrmLMons – will usually contain either Windows NT x86 or Windows x64 as the architecture and a list of port monitors and the port monitor files installed
• BrmPorts – contains a list of all the installed printer ports
• BrmPrinters – contains a list of all printers that have been installed
• BrmSpoolerAttrib – contains information about the spooler directory path and also indicates whether or not the source server was a cluster server

6. Now we need to edit the existing xml files and delete the information about unused print processors, language monitors and drivers in them and then create a new file without these components.

NOTE You may ask if we already set all the printers to use WinPrint as default print processor using the earlier methods, then why do I need to do this? The answer is that when we take a backup using PRINTBRM, the tool copies all the files from their respective directories inside C:\Windows\System32\spool\. Hence even if we have replaced the information on the queues, these files will be backed up and at the restore operation, they will also be restored. So even though we took a backup using the nobin switch, the xml files contains information about all the drivers. When you attempt to restore, the server will try to look for these drivers and restore them. Also, the -nobin switch only omits the driver files, the Language monitor and the Print processors are still backed-up.

For creating new BrmDrivers.xml, BRMLMons.xml and PProcs.xml files, we can use the following templates:

BrmDrivers.xml

===========

<PRINTERDRIVERS>
</PRINTERDRIVERS>

===========

BRMLMons.xml

==========

<LMONS Arch="Windows x64"/>

==========

PProcs.xml

========

<PPROCS>

</PPROCS>

=========

7. Once we have saved the new xml files in place, we will re-pack the backup using this command to get a new backup file that we will use to restore on the target server:

printbrm.exe  -b -d c:\temp\expand  -f newbackupfile.printerexport

8. Now that we have a clean printer backup, we will use the BRMConfig file to create all the printers using the “Generic / Text only” driver. The BRMConfig.xml file needs to have a mapping of all the drivers present on the source server that we want to restore with the Generic / Text Only driver.

A sample BRMConfig file may look like this:

=============

<BrmConfig>

<PLUGINS>

</PLUGINS>

<DriverMap>

<DRV old="HP Universal Printing PCL 6" new="Generic / Text Only"/>

<DRV old="HP Laserjet 5000 PCL 6" new="Generic / Text Only"/>

<DRV old="HP Universal Printing PS 6" new="Generic / Text Only"/>

</DriverMap>

</BrmConfig>

==================

For restoring all the printers from the backup, we need to mention all the existing drivers here.

NOTE The name of the driver has to be an exact match.

9. Once you have your brmconfig.xml file finished, run this command to start the restore:

printbrm –r –s \\2008R2Servername  –f newbackupfile.printerexport -c c:\temp\brmconfig.xml

NOTE We need to provide the absolute path of the BrmConfig.xml file here.

10. If all the mentioned instructions have been followed, you will see all the print queues getting created on the server using the Generic / Text Only driver.

This is where we started from:

And this is what we have accomplished:

11. Verify that the printers are working fine by sending some test pages to the printers.

12. After the queues are created on the target server, you can install the 64bit drivers for the printers as per your convenience and then switch the queues again.

Simplifying the BRMConfig.xml file creation

Considering most typical production scenarios, Print Servers you have hundreds of print queues and many print drivers, creating the BrmConfig.XML file for mapping each driver to Generic / Text Only driver can be real time consuming process. To ease the pain of creating this file yourself, there’s a BRMC tool that will come in handy. Download the tool from https://brmc.codeplex.com/ and run it from the directory where the BRMDrivers.XML is located. (So run it from the expanded location). Once the tool is run, and it creates a BRMConfig.xml file, pack the backup and then run the restore using the BrmConfig.XML file (to to step 8 and then go to step 10).

The BRMC tool creates the brmconfig.xml file that has the driver mappings. It also creates clean BrmDrivers.xml, BRMLMons.xml and PProcs.xml in the same directory. Be aware, the tool overwrites the original files, so save the original .printerexport file as a backup of BrmDrivers.xml, BRMLMons.xml and PProcs.xml.

Troubleshooting

If you encounter any errors during a Print Migration restore, check the event logs for possible causes. Common ones may be Print Processor is unknown, Unknown Port, or Print driver is unknown which usually means that the spooler was not cleaned properly on the source server when the initial backup was generated. Look for more in-depth troubleshooting of these kinds errors in a future blog.

I hope this information will come in handy the next time you are working through a printer migration. Until next time…

Addition Resources

• Print Services Migration Guide
• AskPerf Blog: Installing cross-architectural print drivers from the server locally
• AskPerf Blog: Windows 7 / Windows Server 2008 R2: PrintBRM
• Two Minute Drill: PRINTBRM and the Configuration File

-Digvijay

Hello AskPerf! I’m Craig Marcho, a Senior Support Escalation Engineer in the Microsoft Platforms Core Team. There has been an increase in cases lately with Windows 7 Clients and Windows Server 2008 R2 Print Servers where Clients will show print queues as being offline, while at the same time, other Clients can print just fine and the Print Server shows the queue as online. While there are a few things that can cause this behavior, all of our normal troubleshooting steps were not providing relief for this particular issue.

We found that this issue occurs because a restricted client thread that runs in the spooler detects an offline print server. When a client thread detects that a print server is offline, Windows registers a polling loop to check the status of the print server. After the polling loop is registered, Windows queries the print server periodically to check whether it is back online.

In rare cases, a client thread that has a restricted token detects that a print server is offline. In this situation, Windows registers the polling loop in the context of this thread. However, the thread does not have sufficient rights to query the print server. Therefore, the polling request fails. Restarting the spooler or the client machine will obviously kill this thread running under the restricted context and will query the server with the correct security.

The hotfix became available on July 11^th and you may download it here:

A network printer is displayed as offline incorrectly on a computer that is running Windows 7 or Windows Server 2008 R2

So if you have been experiencing this issue, or know someone who has, please spread the word that a fix is now available.

-Craig Marcho

Hello AskPerf Blog Readers!  Steven Sinofsky published the below blog last week just in case you missed it.  It was authored by one of our lead Program Managers on the Printing team.  It talks about some of the new exciting Printing features included in Windows 8.  Check it out!

Simplifying printing in Windows 8

-Blake

Good morning AskPerf!  Akash Nema here from the Performance team.  Today we are going to chat about how to tweak the printer list presented when using the Add Printer Wizard in Windows 7.

We frequently see situations with Domain joined users on Windows Vista and higher that try to connect to a network printer.  When the user accesses the Add Printer Wizard, they are surprised to see the list of printers presented is limited to only 20 entries - this is by design.

The user can still search for a specific network printer by selecting "The printer I want isn't listed" and then selecting "Find printer in the directory based on location or feature".

(For more information on pre-populating this list with network discovery enabled - see the following walkthrough from our friends at MCP Magazine.)

The list of printers limit behavior is controlled by the following Group Policy setting for Printers:

Add Printer wizard - Network scan page (Managed network)

The policy sets the maximum number of printers (of each type) that the Add Printer wizard will display on a computer on a managed network when the computer is able to reach a domain controller (for example, a domain-joined laptop on a corporate network).  

To access the Group Policy Object, click Start, click Administrative Tools, and then click Group Policy Management. Or, click Start, click Run, type GPMC.MSC, and then press Enter.  

In Group Policy Management Editor, expand the following folders:

+Computer Configuration

    + Administrative Templates

          +Printers

                Add Printer wizard - Network scan page (Managed network)

This policy sets the maximum number of printers (of each type) that the Add Printer wizard will display on a computer on a managed network.

In order to view available TCP/IP printers or Web Services printers on your network, ensure that network discovery is turned on.  To turn on network discovery, click Start, click Control Panel, and then click Network and Internet.  On the page, click Network and Sharing Center.  On the Network and Sharing Center page, click Change advanced sharing settings.  On the Advanced sharing settings page, click the arrow next to Domain arrow, click turn on network discovery, and then click Save changes.

If this setting is disabled, the network scan page will not be displayed.  If this setting is not configured, the Add Printer wizard will display the default number of printers of each type:

• Directory printers: 20
• TCP/IP printers: 0
• Web Services printers: 0
• Bluetooth printers: 10
• Shared printers: 0

If you would like to not display printers of a certain type, enable this policy and set the number of printers to display to 0.

Directory printers are any print queues that the domain print administrators have chosen to publish in Active Directory.

TCP/IP printers are print devices that you access directly using the TCP/IP protocol.

Web Services printers include both IPP and WSPAD print devices that are shared on the network.

Shared printers are print queues that show up in the deprecated “browse list”.

If you are a die-hard fan of users searching for their own printers (how the wizard looked with Windows XP), you can disable the Network Scan Page entirely via this same policy and the Wizard will go directly to the “Find printer in the directory based on location or feature” page of the Add Printer wizard.

Happy Printing!

-Akash Nema

Additional Resources

• Group Policy Search
• How to use Group Policy settings to control printers in Active Directory
• Printer Location Tracking

Hi AskPerf readers, this is Paul from the Microsoft Remote Resources Support Team. We have been receiving a number of support questions concerning the use of Client Access Points (CAPs) and the use of CNAME alias records when referencing a Failover Clustered Print Spooler Resource.

Unlike a File Share Resource the multiple Client Access Point (CAP) feature is not supported when referencing a Print Spooler Resource. In Windows Server 2008 and 2008 R2 Failover Clusters, the interaction between the Cluster Service and the Server Service has changed and with this change shared printers are now associated with a single Spooler resource and are 'scoped' to the Network Name resource which is part of the Client Access Point (CAP). The share names when using Client Access Points (CAP) in Windows Server 2008 and 2008 R2 do not work in the same manner as they did with Windows Server 2003 Failover Print Clusters. This is due to intentional design changes that enhance the security when making Server Message Block (SMB) connections to the print spooler resource (the print share). A Failover Clustered Print Spooler consists of 3 components; a single Client Access Point (Network Name and IP Address), a single Spooler Resource and a “shared” Disk resource (Cluster Shared Volume; CSV).

The recommended method for accessing the Failover Clustered Print Server Resource is to login to any of the cluster nodes and open the Printer Management Console by clicking “Manage Printers” from the Failover Cluster Manager. This ensures you are accessing the clustered spooler resource and not the local spooler; an area that we receive numerous support calls about.

The Failover Cluster Manager will not prevent an administrator from creating more than one Client Access Point (Name and IP resource) in any group. When this is done in a Spooler resource group it is not immediately evident that this creates a potential configuration problem. The first indicator that this is not supported is when the admin attempts to use the Manage Printers feature from the Clustered Print Servers Action menu.

The Failover Cluster Manager displays the following configuration error clearly stating that the Spooler Resource is not configured correctly if there are multiple Network Names in the group.

An alternative way to manage the clustered Print Spooler Resource is directly through the Print Management Console (PMC). In the PMC, an admin can add the Clustered Spooler Resource Network Name to the list of Managed Print Servers.

If a spooler resource group has multiple CAPs defined and an administrator attempts to use the PMC to manage any of the CAP instances other than the first one defined when the resource was created, they’ll receive the second indicator that there is a configuration issue.  Attempts to add a printer to any of the additional CAP names in the PMC the following error is displayed indicating that the target is invalid.

While we have created a valid Network Name we have not created a target object container for the installation of printers:

Performing a query for the meaning of this error message using the NET Helpmsg command (http://technet.microsoft.com/en-us/library/bb490705.aspx). Typing the following command:

C:\>net helpmsg 67

The network name cannot be found.

(Net Helpmsg only accepts decimal error messages. 0x43 is 67 in decimal)

This gives us a more easy to read error - indicating that the configuration is not valid because the target does not exist.

Best practice recommendations around Clustered Spooler CAPs:

1. Choose one CAP to represent the Clustered Print Spooler resource.

2. For consistency the Group name and the CAP name should be the same to minimize confusion.

3. Publish this to the end user community to use only this CAP name to add printers to their workstations.

If the requirement is to provide multiple Client Access Points (CAPs) or Multiple Named references (aliases) then it is recommended that additional print spooler resource groups be created with the desired names and migrate the printers to the new spooler resources using the Print Management Console Export and Import feature.

The bottom line is there can be only one print spooler resource per Cluster Resource Group and a single network name reference to that resource.

Please review the following article which contains a very detailed explanation concerning the use of CNAME alias DNS entries and why they do not work as expected with Windows 2008 and 2008 R2 Failover Clusters:

File Share 'Scoping' in Windows Server 2008 Failover Clusters

-Paul

It’s day 13 of our Launch Series and we are nearing the finish line.  Today we are going to look at ways to print from your Modern UI Apps.

So you have loaded Windows 8, and need to print from one of the new Modern Apps that have installed, but you do not see a ‘print’ icon, and there is no “File, Print, …” menu.  Windows 8 includes a new user interface that is designed to help users easily discover and install devices.  Print, Fax, and Scan devices are installed from the Settings or Devices charms:

Charms Bar with Devices and Settings

Adding Devices

To install a Printer using the Windows 8 Modern App style interface, do the following:

1. Activate the Charms bar by swiping in from the right edge of a touch screen, pressing the Windows+C keys on the keyboard, or moving the mouse to the upper right corner of the display.
2. Click or touch Settings, and then More PC Settings.
3. Click or touch Devices, and then click or touch Add a device.
4. Windows will scan the network for devices and display the list of printers that were found.  If the administrator has published printers to the active directory then they should show up at the top of the list.

Searching for Devices

5. Click or touch the device that you wish to install and it will be added to the list of devices. If the printer is using a Version 4 driver then no other user interaction is necessary to install the device.

Installed Printer

Printing from Windows 8 Modern Apps

Windows 8 has a new user interface for discovering and printing to print devices on a network.  A Modern App that runs in the Windows 8 interface may have a custom printing interface that is accessible via the application bar or it may provide a printing link similar to the Modern App style Internet Explorer application.

Additionally, the CTRL + P hotkey will activate the shell print dialog.

Note Not every Modern App will allow you to print from it.

To print a document from a Windows 8 Modern App, do the following:

1. Use the application user interface and select the Print option or use the CTRL + P hotkey to activate the Printing interface.

2. Choose a device to print to by clicking or touching the Print device icon:

Choosing a print device

3. A print preview and basic print settings are displayed. The document can be printed using the Print button:

Basic print settings

4. Clicking on More Settings will activate the advanced print settings dialog where page layout, paper and quality, and output options can be specified:

More settings

But now you’ve launched the Bing News app, and you are trying to print.  You do not see printers when you open the Charms and go to Devices.  You may see something like this:

No Printers

When you see this, it indicates that this app does not support printing, or that you have no printers installed.  We covered adding printers at the beginning of this blog, so we’ll take a guess that this app does not support printing.  What do you do from here?  Well, no need to worry.  Some Modern Apps do support opening the article in Internet Explorer, and you can then print the article from there.  To do this, you can right click in the article you are viewing, and see the following at the bottom of the screen:

View in Browser

Click on View in browser, and you can then print from Internet Explorer the same way we mentioned above.

The following apps installed with Windows 8 support printing from within the app:

• Mail
• Photos
• News (only when viewing My News and use the open in browser method)
• Bing Finance (when you use open in browser)
• Maps

The following apps do not support printing from within the app:

• Bing
• Finance
• Sports
• Travel
• Weather
• Messaging
• People
• Calendar
• SkyDrive

And there you have it, everything you need to know about printing in the new Windows 8 Modern App interface!  Thanks for reading!  We'll take a brief look at Windows PowerShell Web Access in tomorrow's post.

-AskPerf blog Team

Good morning AskPerf!  My name is Sandeep Bhatia and I work with Networking team here in Microsoft Support.  In today’s post, we will discuss Print issues when using a CNAME on Windows 2008 R2 Server, with a non-Microsoft DNS Servers.

When you connect a printer hosted on Windows 2008 R2 Server using a CNAME alias it returns the following error:

Operation could not be completed (Error 0x0000079). Double check the printer name and make sure that the printer is connected to the network.

This error is returned because of the optimization changes to the spooler service in Windows 2008 R2 Server.  The Print Spooler service uses the local names to service requests.  We’ve verified the name being used is correct and we can connect using the NetBIOS, FQDN and IP address of the server.

Step one is to make sure the target print server has the DNSOnWire registry key set to 1:

HKLM\SYSTEM\CurrentControlSet\Control\Print\DNSOneWire (REG_DWORD)

More details about this registry key is available at KB979602

However, if the DNS Server that the Print server is using is not a Windows based DNS Server we could still see a similar error issue because of how the DNS server formats the reply.  When the DNSOnWire registry key is set to 1, the Print Server on startup will send a recursive DNS query expecting to get both the host record (A) the CNAME refers to and the IP address of the host.

A sample DNS request and reply would look something like this:

Printserver.contoso.com Dnsserver.contoso.com DNS DNS:QueryId = 0x1389, QUERY (Standard query),

This will query for printservercname.contoso.com of type ALL on class Internet.

When the type is set to ALL, the client would expect all the information about the record in on packet.  This query is also a recursive query to the DNS server for the name printservercname.contoso.com.

The second step is to make sure is the DNS server supports both a query type of ALL as well as recursive queries. The DNS server should be compliant with RFC 1035.

In this example of a non-compliant DNS response, the reply from the DNS Server to the Print server for the DNS query, the DNS Server did not respond back with the IP Address of the Print Server.  It does send back the CNAME entry which points to the Print Server’ Host record, but the expectation is both should be returned.

Dnsserver.contoso.com Printserver.contoso.com DNS DNS:QueryId = 0x1389, QUERY (Standard query), Response - Success, Array[IP Address Of the DNS Servers]  {DNS:242, UDP:241, IPv4:240}

  - Flags:  Response, Opcode - QUERY (Standard query), AA, RD, RA, Rcode - Success

     RD:                (.......1........) Recursion desired

  - ARecord: printservercname.contoso.com of type CNAME on class Internet: Printserver.contoso.com

     ResourceName: printservercname.contoso.com

    ResourceType: CNAME, Canonical name for an alias, 5(0x5)

     ResourceClass: Internet, 1(0x1)

     TimeToLive: 1800 (0x708)

     ResourceDataLength: 15 (0xF)

     CName: Printserver.contoso.com

  + AuthorityRecord: in.Contoso.com of type NS on class Internet: DNSServer.Contoso.com

  + AdditionalRecord: DNSServer.Contoso.com of type Host Addr on class Internet: 192.168.1.100

Under an ideal scenario, the reply for a recursive query from the DNS Server should look more like:

Dnsserver.contoso.com Printserver.contoso.com DNS DNS:QueryId = 0x1389, QUERY (Standard query), Response - Success, Array[IP Address Of the DNS Servers]  {DNS:242, UDP:241, IPv4:240}

  + Flags:  Response, Opcode - QUERY (Standard query), AA, RD, RA, Rcode - Success

  - QRecord: Printservercname.contoso.com of type ALL on class Internet

     QuestionName: printserver.contoso.com

     QuestionType: A request for all records, 255(0xff)

     QuestionClass: Internet, 1(0x1)

  - ARecord: printservercname.contoso.com of type CNAME on class Internet: printserver.contoso.com

     ResourceName: printservercname.contoso.com

     ResourceType: CNAME, Canonical name for an alias, 5(0x5)

     ResourceClass: Internet, 1(0x1)

     TimeToLive: 3600 (0xE10)

     ResourceDataLength: 15 (0xF)

     CName: printserver.contoso.com

  - AdditionalRecord: printserver.contoso.com of type Host Addr on class Internet: 192.168.1.110

     ResourceName: printserver.contoso.com

     ResourceType: A, IPv4 address, 1(0x1)

     ResourceClass: Internet, 1(0x1)

     TimeToLive: 1200 (0x4B0)

     ResourceDataLength: 4 (0x4)

     IPAddress: 192.168.1.100

The key takeaway is that the configured DNS Server must return both the CNAME information and the IP Address of the Host in the same response in order to use printing to a CNAME successfully.

-Sandeep Bhatia

Additional Resources:

• RFC 1035 - Domain Name System (DNS) Parameters
• KB 979602 - Error message when you try to connect to a printer by using an alias (CNAME) resource record: "Windows couldn't connect to the printer"
• Recursive and Iterative DNS Queries
• Nslookup: set type

Hello folks.  This is a quick post to inform you that the “Microsoft Fixit for Printing” is now live with .msi packages for Windows 7 and Windows Server 2008 R2.  We know a lot of you have been asking for this for months, and we apologize for how long it took.  With that, please see the original blog post below, in which you will find the links.

Microsoft Fixit for Printing

http://blogs.technet.com/b/askperf/archive/2012/02/24/microsoft-fixit-for-printing.aspx

-AskPerf Blog team

Hello everyone!  I am writing today to raise awareness of an issue that we have come across recently.  I was working on a case with a customer where Server Manager in Windows Server 2012 would crash when he selected the Local Computer tab.  While debugging the issue, we found that Server Manager was crashing when trying to display a bitmap image for the Local Computer icon.  As we looked further into this, we found that when loading the bitmap image, it was trying to load a color profile in order to display the bitmap image properly.  If you have ever worked with color profiles, you will recall that they are stored on disk under the Spooler folder, “C:\windows\System32\spool\drivers\color” and you can view them by loading Color Management from Control Panel, or from the Start screen just type “Color Management” and it will come up.

Figure 1: Color Management loading color profiles properly:

We have discovered that if the Print Spooler Service is stopped or disabled in Windows Server 2012 R2, the color profiles will not load properly and Color Management will be blank.  If the color profiles are unable to load, then when Server Manager is trying to load them to display the bitmap icon, it returns a null and causes Server Manager to crash.  This issue only seems to occur in Windows Server 2012 R2 and not Windows Server 2012.

Microsoft is aware of the issue and we will keep you posted here.

-Craig

Hello folks, today I am going to talk about a new feature that's available in Microsoft Windows 8.1 and Server 2012 R2 called NFC “tap to connect” Printing. NFC stands for Near Field Communication, which allows a two way communication between devices (endpoints) within a very close proximity; typically no more than few centimeters.

NFC “tap to connect” printing makes installation of printers very simple, in short, the user can just tap an NFC enabled device (for ex: a laptop or a tablet) on an NFC enabled printer and can then immediately install that particular printer.

This way, the user does not have to follow the traditional method of printer installation and does not need to know any details of the printer. For example, the print server where it’s hosted on, or the actual printer name itself. NFC “tap to connect” printing can be used for both WSD printers and shared printers.

There are printers that already have NFC capability built-in. The good news is, you can make any existing non-NFC printer NFC capable, by using an NFC tag. NFC tags are like stickers that can be programed to store the required information.

So how do we program an NFC tag? You can do this by using a simple PowerShell cmdlet called Write-PrinterNfcTag. Below are the steps to accomplish this:

1. Launch PowerShell as an administrator on a Windows 8.1 / 2012 R2 system that has NFC hardware capability. You can verify whether the system is NFC capable in device manager; if the system has an NFC device, it will be located under "Proximity devices" in device manager.

2. Type in the following command in the PowerShell window:

Write-PrinterNfcTag -Sharepath <UNC path of the printer>

Example:

Write-PrinterNfcTag -Sharepath \\Myprintserver\PrinterX

3. Once you run this command, you will be prompted to tap the NFC sticker (tag) against the device on which you ran the command. You now need to tap it against the NFC radio on the Windows 8.1 / 2012 R2 system within 30 seconds. Once tapped, the printer share information is written into the NFC tag. That’s it! Your NFC tag is now encoded with the printer share information and all you need to do is attach the NFC tag on the printer that you have specified in the Write-PrinterNfcTag command.

Note:

• It is recommended to use NFC forum approved tags, of at least 1kb capacity
• You can use the -Lock parameter with the above mentioned commands if you want to prevent further modification of the NFC tag once its programmed
• To read an NFC tag, you can use the Read-PrinterNfcTag cmdlet

For a user to print, all they need to do is tap an NFC enabled device (for instance a tablet), on the NFC tag that’s attached on the printer, and the user will be prompted for the installation of that particular printer.

Please note, the NFC tag and the Printer never communicates with each other, the print process still uses the existing infrastructure and the network. NFC “tap to connect” printing is just a way to pair and install the printer and it does this like a charm!

Additional Resources

• What's New in Print and Document Services in Windows Server 2012 R2

-Madhurjya

Hello again AskPerf!  Today I’m going to introduce a new Windows 8.1 feature called Printer Roaming.

Windows 8 provided the ability for users to roam a number of settings with their Microsoft account, such as the desktop background and web history.

Windows 8.1 extends this functionality to include roaming of printer connections, and this is primarily aimed at bring-your-own-device (BYOD) scenarios.

If you use Microsoft-connected accounts in your workplace (i.e. an account tied to a Hotmail.com or Outlook.com e-mail address), Windows 8.1 will store your UNC printer connections in the cloud and reconnect them on other Windows 8.1 devices you bring into the workplace.

So, let’s say you’ve manually mapped 3 printer connections (e.g. \\ServerName\PrinterShare) on your Windows 8.1 desktop PC at work.  When you bring a Windows 8.1 tablet into the workplace, the operating system will keep your printer connections in sync by automatically connecting them.

This feature is currently grouped with Other Windows Settings, which can be found in the SkyDrive options in the PC Settings application.

There are a few important caveats that I’d like to note.

• Printer connections pushed through group policy are not automatically connected.  This feature is aimed at personalizing the experience for printers the user has manually connected.
• Only queues utilizing v4 printer drivers will be roamed.  This guarantees compatibility with Windows RT clients.
• This feature currently offers an on/off toggle.
• If you use Microsoft-connected accounts in your workplace and want to disable Printer Roaming, all of the Sync settings in Other Windows Settings must also be disabled.
• Individual printer connections cannot be configured to roam or not roam.

When considering Microsoft-connected accounts in your workplace, you can count Printer Roaming among the many valuable feature opportunities that become available.

-Aaron

Welcome back AskPerf readers!  Prior to Windows 8.1, scanning could be a relatively frustrating experience with many questions coming to mind…

• Will my scanner work on Windows RT?
• Do I need to download a driver from the manufacturer?
• Do I have the necessary applications to acquire and edit an image?

With Windows 8.1, any Windows Image Acquisition (WIA) 2.0 compliant scanner will simply plug in and work, thanks to the magic of generic in-box scanner class drivers.

Since WIA 2.0 has been a logo requirement for all locally-connected scanner devices since June 2010, you can be fairly confident that any new scanner device will be supported.

The software to acquire images is also included with the operating system, thanks to the modern in-box Scan app.  Start typing “Scan” at the Start screen and its tile will be displayed.

The Scan app will occupy the left side of the screen, with scanner configuration options that are automatically detected based on the device.  You will also be presented with a choice of image formats and a location to save the image file to.

Once an image has been acquired, the Pictures modern app will be displayed to the right with the images you’ve scanned in.

At this point you’re free to import the image into any application of your choice, and have hopefully had a much better scan experience than in years past.

-Aaron

This is in continuation of the topic discussed by John Dickson in his blog post entitled Installing Windows Vista Print Drivers on Windows Server 2003http://blogs.technet.com/askperf/archive/2008/09/19/installing-windows-vista-print-drivers-on-windows-server-2003.aspx

With advancing technology and increasing demand for resources, many enterprises are now opting for 64-bit operating systems on their servers. The OS on the client machines could be either 32-bit or 64-bit depending in the customer’s environment and requirements.

We are specifically dealing with Print server in this article. When we deploy a 64-bit print server which is to cater to 32-bit clients, usually the clients use the point and print functionality to connect to the desired print queue on the print server and drivers are mapped.

This requires the 64-bit print server to have 32-bit printer drivers installed.

Following are the steps to install 64-bit printer drivers on a 32-bit server. We will also discuss a common issue that we see during installation. (I’ll also be enumerating the steps implemented vice-versa i.e. Installing 64-bit printer drivers on a 32-bit server)

Note: File and Printer Sharing must be enabled.

Installing 64-bit printer drivers on a 32-bit server:

Local Method:

1. Go to the Printers and Faxes folder.

2. Go to the properties of the print queue for which you intend to add the x64 driver.

3. Go to the Sharing tab and choose Additional Drivers.

4. Choose x64 as the processor type and click OK.

5. When prompted, point to the location of the x64 driver.

This should install the additional x64 drivers required for the x64 clients to print through the x86 servers.

You can also perform the above steps remotely from another machine by connecting to the print server using the UNC path \\printservername and then browsing to the Printers and Faxes folder.

Another option is to install the driver remotely using the Add Driver wizard. To do this:

1. Logon to the 64-bit server with an Administrator account. This account has to have administrative privileges on the 32-bit print server as well.

2. Connect to the print server using the UNC path (Start -> Run -> \\32BitPrintServer)

3. You should see the Printers and Faxes folder. Open this folder

4. Go to File--> Server Properties -> Drivers tab and choose Add Driver. Using this option add the required driver by choosing the appropriate architecture type.

Note: When you add the driver directly it doesn’t check if the driver matches the existing x86 version. If it does not the clients may not be able to download the driver and print successfully. See the section on Issues for details.

A great scenario to use the remote install option is when you don’t have the OEM version of the x64 driver available or if you prefer to install the inbox drivers instead.

When you install remotely by connecting through UNC, it first looks for the driver in the local driver store. If available, it will install the driver without any further prompts. Only if an inbox driver is not available will it prompt for the driver location.

You can also take advantage of this method to install inbox 32-bit drivers, where the print server doesn’t have an inbox driver for the printer, but a later version of the OS has the required drivers inbuilt.

Installing 32 Bit printer drivers on a 64 Bit server:

· Login using a domain administrator account to a 32 bit machine.

· On any one of the clients machine running 32-bit OS

· Access the print server\\PrintserverName\Printers

· Open the printer required to add the 32-bit driver

· Go to properties -> Sharing Tab -> Additional drivers

· Check the box with appropriate architecture type.

In this case it is nothing but using the same steps as in the x64 driver scenario, but in this case the additional driver we will be adding will be a 32bit driver.

Common Issues seen while installing a 32-bit driver on a 64-bit server and vice versa.

1) Option to choose OS architecture i.e. x64 could be grayed out.

2) You may see the error ‘Driver is not installed.’

3) You may see architecture incompatibility errors while trying to install drivers.

The x64 option could be grayed out or not visible if the OS on the print server doesn’t support or is not aware of the x64 architecture. A good example is Windows 2000 print servers where you cannot add an x64 driver.

The option is also grayed out in Windows Server 2003 RTM (without any Service Pack)

The ‘Driver is not installed’ error can occur if the additional driver you installed doesn’t match the existing driver in name and INF parameters.

These names need to be the same if the driver installation is to go through without errors.

An example of this is a recent case I was working where we needed to install a 32-bit driver for an already present (inbox) HP LaserJet 8150 PCL 5 x64 driver.

The obvious thing to do first was to obtain the 32-bit driver from the OEM website for installation. Upon looking for the HP LaserJet 8150 PCL 5 (32 bit) driver, we find that vendor gives us the option to download HP Universal Print Driver for Windows PCL 6. Hence we downloaded and tried installing it, but this failed.

The problem was that when we were using the inbox 64-bit driver to install the HP LaserJet 8150 PCL 6 driver, the actual driver is named “HP LaserJet 8150 Series PCL6”.

However, the HP LaserJet 8150 PCL 6 (32-bit driver) from the HP website is named “HP Universal Printing PCL 6”.

As you see, the names are different and hence the installation errors out. The same installation goes through successfully if we download the HP LaserJet PCL 6 32-bit driver from the website. This is because the driver is named “HP Universal Printing PCL 6”, which is the same name as the 64-bit driver.

I hope this helps to give you a better understanding of some of the nuances of print driver behavior on various types of servers.

Thank you very much for your time,

Aamer Shedam

Share this post :

Hello AskPerf readers.  My name is Randy Grogan and this is my first post on this blog.  If you are familiar with some of the Printing Improvements in Windows Server 2008 R2 then you may already know how much easier it is to Delegate Printer Management tasks to non-admin users.  Although things are much improved in Win2K8 R2, there are still a lot of Windows Server 2003 Print Servers in use and we are often asked how to accomplish this task with this platform.

The answer has both good and bad news.  First the good; It is possible to apply a set of custom permissions to all of your printers.  Now the bad; The permissions you setup will be populated to every printer and new printers will not receive the custom permissions.  So, if you have a new delegation model to apply to your existing Windows Server 2003 Print Server then the steps below will help you with the implementation.

The majority of the modifications that need to be done are changes on the local Print Server.  The only aspects of this delegation that can be applied via GPO are the local User Rights explained later in this post.

Task 1: Modifying the printer permissions

The actions that will be followed in this step with require a tool from the Windows Server 2003 Resource Kit, SetPrinter.exe.  This tool can be downloaded from the following link:

http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&DisplayLang=en

It is important to understand that SetPrinter.exe does not modify permissions, it replaces them.  When we use this tool later, the effective permissions for all queues will be replaced to match the security descriptor of our “model printer”.  Additionally, the permissions that are set with this tool will not be inherited by print queues that are setup after following these steps.  This means that the desired permissions will need to be applied to all new printers on an ongoing basis.  You might implement a change control process for new printer installs so that the desired permissions are configured going forward.There is no supported method for automating this in Windows Server 2003.

Actions for modifying the printer permissions:

• BACK UP YOUR SERVER!  You will need a good System State backup to revert these changes if you wind up with undesired results!
• Pick an existing printer or install a new one to be used as the model for the desired permissions.
• Configure this printer with the desired Security Group and permissions via the security tab.

To achieve this task, we will use the local Print Operators group.  On the model Printer, add the local Print Operators group in the security tab.  Give this group the desired permissions.  In the screenshot below, we are giving Print, Manage Printers and Manage Documents permissions.

• Use the SetPrinter -show command to dump the security descriptor of the model printer that has the desired security permissions.  We will output the security descriptor into a text file so that we can copy and paste it in another step. From a command prompt, type the following command:

SetPrinter -show "printername" 3 > PrinterPerms.txt

Where Printername is the name of the printer that has the permissions/credentials needed. (e.g. \\servername\printsharename)

Open the text file and you should see the security descriptor info.  While it may be different on your system, it will look similar to the following string.

NOTE: The security descriptor below is an illustration only!  Do not use this example on your server!

pSecurityDescriptor="O:BAG:DUD:(A;OIIO;RPWPSDRCWDWO;;;BA)(A;;LCSWSDRCWDWO;;;BA)(A;CIIO;RC;;;CO)(A;OIIO;RPWPSDRCWDWO;;;CO)(A;;SWRC;;;WD)(A;OIIO;RPWPSDRCWDWO;;;PU)(A;;LCSWSDRCWDWO;;;PU)(A;;LCSWSDRCWDWO;;;PO)(A;OIIO;RPWPSDRCWDWO;;;PO)"

• Use the SetPrinter command to replace printer permissions on all existing printers using the security descriptor that was dumped from the model printer.

From a command prompt, type the following command.
SetPrinter \\Servername 3 pSecurityDescriptor="credentials"

Where credentials is the string listed as the value for pSecurityDescriptor.

After following the steps above, you should now see that the local Print Operators group has been added to all existing print queues.

REMEMBER: SetPrinter.exe does not provide partial permission modifications.   It will always replace all permissions with whatever is provided to it.

Now that the permissions have been set, we now need to give this right to a Domain Global group.

Task #2: Implementing the Security Group configuration

Create a Domain Global group that will be used for your Printer Management Role.  You will add the individual user accounts to this group when the users need to assume this task.  Add this new Domain Global group to the local Print Operators group on your Print Server.

After these steps have been completed, you now have delegated Printer Management rights to members of the Group “PrintOps” as illustrated in the example screen shots.

Task 3: Giving the Print Operators the appropriate rights on the Print Server

You will need to give the local Print Operators group additional permissions so that members can log on to the server and install Print drivers.  The suggested user rights are listed below.  These rights can be configured through local policy settings or via GPO.

• Allow log on locally (Not required if only RDP access will be used)
• Load and unload device drivers. (This is required for Printer Driver Installs)

Tip: You may want to allow your Print Operators to log on through Terminal Services.  To achieve this, you should add the Domain Global group to the local Remote Desktop Users group. This will let these users logon to the server for these Printer Management Tasks

With that, I conclude this post.  Until next time…

-Randy Grogan

Share this post :

Hello Everyone. This is Digvijay once again with a new blog post about my favorite component – Printing.

Since the release of Windows 2008 and Windows 2008 R2 there have been several times where we get calls from the customers saying that they have built a new 64-bit 2008 or a 2008 R2 print server and now the 32-bit clients are not able to access the print queues since the 32-bit printer drivers are missing. This is a known issue and many of our experts have already blogged about it herehere and here. We also have a Knowledge Base article that tells you what needs to be done http://support.microsoft.com/kb/952065 . And that way is to remotely install the drivers from a 32bit client running vista/win7 or 2008 server.

But, what if there is an environment where there are no 32-bit Windows Vista/Windows 7/Windows Server 2008 machines to pull the drivers remotely from? What if you want to add all the 32-bit inbox printer drivers on the server locally so that you don’t have to add the drivers remotely each time you install a new print queue?

Well, recently I got a case where the customer was wanting to do exactly that. He had set up a new Windows Server 2008 64-bit machine which was to be provisioned at his client’s location and all the workstations in his client’s environment were 32-bit Windows XP SP3. He created the print queues for the existing printers and added the 32-bit drivers remotely using steps mentioned in the KB. But the issue that he was facing was that once he gives the server to his client, what will happen if they add some new printers later? From where will he get the 32-bit version of the drivers? How do we make sure that he has all the 32-bit printer drivers available locally on the server all so we don’t need to add the drivers remotely?

There were a few options I was thinking of suggesting. They were:

a. Download an evaluation copy of 32-bit Windows 7 or Windows Server 2008 and then install it and follow the above steps mentioned in the KB. Windows 7 Trial can be found at - http://technet.microsoft.com/en-us/evalcenter/cc442495.aspx

b. Use the ImageX tool from the Windows Automated Installation Kit to extract the necessary driver files from an installation disk without installing the 32-bit OS.

c. Download an  evaluation .vhd of Windows Server 2008 and load it on a Virtual Machine (Hyper-V,Virtual Server,Virtual PC) and then add the drivers from there.

Once we had the .iso/.vhd file downloaded and a spare server to install, it would have been easy to get all the existing drivers, but what to do about loading all the 32-bit printer drivers that are available to the 64-bit target server?

I am assuming that we didn’t have a spare server to install the 32-bit OS, nor a virtualization solution to use the .vhd downloaded from the above links. In this case, we decided that the second option was the most feasible. So we need to manually extract the files from the Windows Server 2008 32-bit image using Imagex.exe. This is what we needed to do to accomplish this:

1. Download and install the Windows Automated Installation Kit (WAIK).

a. Save the program to your computer. (Windows AIK is distributed as an .iso file)

b. Burn the iso image to a DVD or extract the contents directly using other tools.

c. Once the DVD has been mounted/extracted or loaded click Windows AIK Setup to begin the installation.

2. Mount install.wim from the sources directory of the cross-architecture media . (This would be installing a 64-bit driver on an x86 server, or a 32-bit driver on an x64 server. In this example, I am installing 32-bit drivers on a 64-bit server.)

a. Create a folder for extracting the files (e.g., C:\32bitPrinterDrivers).

b. Insert the 32-bit Windows Server 2008/Windows Vista/Windows 7disk into the appropriate drive.

c. Open a command prompt with administrative credentials (Start - Search Programs –cmd.exe right-click Command Prompt, and select Run as administrator).

d. Navigate to the folder where WAIK is installed by typing cd C:\Program Files\Windows AIK\Tools\x64

e. Run the Imagex command using the /mount switch to open the WIM file in read-only mode, using the following command syntax:

imagex /mount <location and name of WIM file> <image number to open > <location of folder created in step a>

For example, to mount the first image of standard Windows Server 2008 install.wim file to path C:\32bitPrinterDrivers, where the d: drive represents the dvd drive where the 32-bit Windows Server 2008 media is loaded, use the following command:

imagex /mount d:\Sources\install.wim 1 C:\32bitPrinterDrivers

This will take some time to extract the files. Once the operation is completed, you can browse to the mounted location and see all the 32-bit inbox drivers.

A brief look at the contents of the folder may reveal that the folders which have the name in the format prn<manufacturer>001.inf_<random guid> are the ones that we will be using to install the print drivers. We will also need the ntprint.inf_xxxxxxxx folders. I copied all these files to a new folder and moved them locally to the 64-bit machine. In this case, they were about 981 MB in size. 

NOTE: the files names may differ since the last 8 digits are randomly created.

So, once I had the driver files, the rest was easy. From the 64-bit server, open the Printers snap in.

1. Right click the on the Printer already installed for which you want to load a 32bit driver and select Properties.

2. Within the printer’s Properties window select the Sharing tab and click on the Additional Drivers button which will cause the Additional Drivers window to appear.

3. Within the Additional Drivers window I selected x86 as the processor type and clicked on OK.

4. Browse to the location where the 32-bit printer driver files are saved, select the manufacturer and point to the ini file within the folder and click OK.

Once again, the names of the folders containing the printer drivers are in the format – prn<manufacturer>001.inf_<random guid>. So if I had to install a HP driver, I would select the prnhp001.inf_2ade4966 folder. For installing a Brother driver, I would select the prnbr001.inf_a54871ed folder.

5. Clicking on Open and then OK, we get a list of the all the drivers contained in the package by this manufacturer. Select the appropriate driver from the list and continue the install.

6. Once completed, we can verify that the driver has been installed successfully by going to the Additional Drivers section of the Print queue. We can also verify the same by looking at the drivers tab of the Print server properties or in the Print Management Console.

So now, once we get a new printer, we can just browse to the 32-bit driver’s directory and get the 32-bit drivers instantly without having to look for a 32-bit machine to add the drivers remotely from.

Caution: When sharing 32-bit drivers from a print queue created with 64-bit print drivers, the 32-bit and 64-bit print drivers MUST be the same version. Failure to use matching print drivers could cause a lack of communication between the print server and client, and may result in disrupted or no printing.

We still recommend that installing drivers remotely from the other system is often the only way to get an older OEM print driver to install additional drivers. The process of copying 32-bit print drivers to the 64-bit system and then adding the additional drivers works well with the print drivers that are available inbox.

With that, I come to the end of this post. Please feel free to contact us if you have any questions or suggestions about this post.

Thanks again for stopping by.

Digvijay Nath

Share this post :

In recent months we have seen an increasing volume of print cluster cases being opened due to poor performance. For example slow failover or spooler crashes. This article is provided as a guide for print server administrators to identify and resolve possible causes of these performance issues.

1.    To increase print server stability, only the print drivers that are needed should be installed.   Print drivers should be installed on the cluster print resource.  Print drivers should not be installed on the local physical nodes of the cluster unless it is required by the printer vender.  HP Universal Print Driver and the Xerox Global Print Driver and other Universal print drivers are a few of the print drivers that must be installed on the physical local nodes and on the Cluster print resource. 

HP universal print driver configuration in clustered environment Best practices
http://h20338.www2.hp.com/Hpsub/downloads/HP_Drivers_in_Cluster_Environments.pdf

From the HP web page above:

“When installing product specific drivers, it is recommended that the latest driver be used.  The latest version of the driver can be found at hp.com. Also, the driver should be
installed onto every node in the cluster prior to being installed onto the Virtual Print Server”

Xerox installation document:
http://download.support.xerox.com/pub/docs/GLOBALPRINTDRIVER/userdocs

You will need an account with Xerox to access the link above and obtain the documentation referenced below.

“The X-GPD must be installed on the each node prior to being installed on the client”

2.    There should not be multiple versions of the same HP Universal Printer Driver on the local nodes or the spooler resource, Example:  versions (5.0) and (5.1) ,

The installed drivers can be found by using Regedit.exe:

HKLM\Cluster\Resources\<PrintGUID>\Parameters\Environments\ Windows NT X86\Drivers
HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT X86\Drivers

3.     Ensure the newest version of your Universal Print Driver which is installed on the spooler resource matches the version installed on the local nodes (should be at least 5.1 for HP UPD).
Remove older versions of the UPD on the spooler resource and local nodes after changing all Print queues to the newest version. The removal can be done by going into the Print Server Properties under the Drivers tab.

Note: Print Server Properties can be accessed on 2008 and earlier by going into Printers and Faxes or Control Panel : Printers, right-click an empty area where the print queues are listed. Select Server Properties from the menu.

On Windows 7 And Windows Server 2008 R2, go into Printers and Faxes, select a print queue and the Server Properties option will be available in the toolbar.

  If possible, all Version 2 (Kernel Mode Print Drivers) originally designed for NT 4 systems should be replaced with Version 3 print drivers. Version 3 drivers are recommended over Version 2 drivers because they support advanced printing features and improved performance. If a server stops responding as a result of a Version 3 driver problem, you only need to stop and restart the print spooler instead of restarting the server. Additionally, Version 3 drivers can reduce printer downtime, because Windows Server 2003 provides automatic recovery of the spooler service by default. If a Version 2 driver stops responding, you must reboot the server, taking all other services offline while the server restarts. In addition, Version 2 printer drivers operate in kernel mode (inside the operating system kernel memory space) and are designed for Windows NT 4.0. Because of this, if a Version 2 driver crashes, it can effect the stability of the whole kernel instead of just the spooler process.

There are 3 ways to determine if there are Version 2 drivers running in your environment:

A.    Open Regedit.exe and check HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT X86\Drivers and if there is a Version 2 folder with drivers listed under it then you have some installed.

B.    On a spooler resource you will need to check HKLM\Cluster\Resources\(GUID) of the spooler resource\Parameters\Environments\Windows NT X86\Drivers:

C.    Alternatively you can check for version 2 drivers by opening Print Server Properties and clicking on the Drivers tab. Under the Version column Version 3 Drivers will show Windows 2000 and newer; however if it is a version 2 driver it will list Windows NT in the version column. Version 3 printer drivers operate in user mode (outside the operating system kernel memory space) and are designed for Windows 2000, Windows XP, and Windows Server 2003

5.       Removing drivers on the spooler resource that are not currently assigned to a print queue can help spooler stability. As a general rule of thumb the fewer drivers in your environment the more stable and the faster the Cluster Print spooler can fail over. To cleanup unused drivers: Note: Do not do this if you are using Terminal Services with Printer Redirection.

1.            Log in as Local Administrator
2.            Open the Printers (Printers and Faxes)
3.           Click Server Properties
5.            Select the Drivers tab
6.            Highlight all of the Drivers
7.            Select remove (You will Need Admin Rights for this step)
8.           This will only delete unused drivers, for any driver being used by a Print queue you will receive a popup stating the driver is in use and cannot be deleted.
9.             Click past all of the popups and you will be left with only the drivers assigned to a print queue and all unused drivers will now be gone.
10.           Open regedit (e.g. click Start, type regedit and press Enter)
11.           Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NTx86\Drivers
12.           Verify the Drivers are no longer listed in the registry.
13.           Restart the spooler.

Note: An alternative to Microsoft Print Clustering is Windows 2008 R2 Clustered VM.  You can cluster a Print Server VM and create Snapshots.  It is a nice alternative given printer vendors do not always test their print drivers on a Microsoft Print Cluster.  Clustered VMs is a new Hyper-V feature called Live Migration in Windows Server 2008 R2, which requires the failover clustering feature to be added and configured on the servers running Hyper-V. Hyper-V and failover clustering can be used together to make a virtual machine that is highly available, thereby minimizing disruptions and interruptions to clients. Live migration allows you to transparently move running virtual machines from one node of the failover cluster to another node in the same cluster without a dropped network connection or perceived downtime. In addition, failover clustering requires shared storage for the cluster nodes. This can include an iSCSI or Fiber-Channel Storage Area Network (SAN). All virtual machines are stored in the shared storage area, and the running virtual machine state is managed by one of the nodes. 

Windows Server 2008 R2 & Microsoft Hyper-V Server 2008 R2 - Hyper-V Live Migration Overview & Architecture.

http://www.microsoft.com/downloads/details.aspx?FamilyID=FDD083C6-3FC7-470B-8569-7E6A19FB0FDF&

If you’re configuring a 2008 R2 Print cluster it is highly recommended the hotfix below is installed.

Stability update for Windows Server 2008 R2 Failover Print Clusters http://support.microsoft.com/kb/976571

The 5 Steps I have outline in this document may not resolve all of the issues in your clustered Environment, however If you are experiencing slow failovers or spooler resources crashing this may be a very good place to start.

Andy Rowell

Share this post :

Hello everyone, it’s been a long time! Today we’ll discuss about cross-architecture print server migrations.

With the current and future line of windows servers moving exclusively to x64 architecture, cross-architecture print server migrations is inevitable. Migrating print servers within servers of the same architecture is straightforward using printbrm; it is as simple as backup and restore, no additional work is required. However, migrating from an existing x86 print server to an x64 server is a whole different game. It is easy if you already have the print drivers installed for both x86 and x64 clients, however that is mostly not the case.

The currently supported method of cross-architecture migration requires that you install the print drivers on the source server before taking the backup (recommended) or pre-install them on the target server prior to restoration of the backup. If there is only a relatively small number of printers, it is recommended that you install fresh so that all the old drivers are not carried over to the new server. See a complete list of recommendations here. However, this may be more easily said than done. Based on the number of print drivers, the migration can be time consuming and difficult as you need to download the correct drivers from the OEM website and install them manually.

Several customers have asked us if there is a way to automate this process. Unfortunately it is not technically feasible to automate the process. There is no way we can keep track of all the OEM printer drivers and its URLs, there are hundreds of printer models with every OEMs and you can imagine how difficult that can be. Today we’ll see how we can we can speed up the migration process and take out a bit of the pain.

By default, if you attempt to restore a printbrm backup of x86 server on to an x64 server, the print queues does not get restored on the target if there is no corresponding x64 driver available; only the 32bit drivers, Ports, Print Processors and Print monitors gets restored on the target node.

1. Speeding up migration using "Generic / Text Only" driver

As noted above, the print queues do not migrate until you install the x64 drivers, so how can you bring up the new server quickly with all the print queues? One simple workaround is to set all the existing print queues to the "Generic / Text Only" driver for migration and later switch them to the OEM driver at your convenience. Most printers allow basic printing using the Generic Text driver.

To do this, restore the backup to an intermediate x86 server and run the following command locally to set all the printers to "Generic / Text Only" driver.

Setprinter.exe "" 2 pDriverName="Generic / Text Only" Note: Setprinter.exe is part of the Windows 2003 Resource Kit tools

Remove all drivers from the interim server that are not in use. This is easily accomplished by opening the Print Management Console, expanding Print Servers \ Server Name \ Drivers, highlighting all drivers in the right-hand pane and hitting the delete key. (Note: The Generic / Text Only driver will indicate that it is in use.)

Now, backup and restore this interim server to your x64 Server using printbrm and you should see all your print queues appear on the target server.

Printbrm.exe –B –S \\oldserver–F c:\temp\GenericBackup.printerExport –NOBIN

At this point you may switch the queues on the destination server back to their original driver.

2. Substituting drivers the easy way using a configuration file for BRM

Sometime back we blogged about using a configuration file for PrintBRM here. While the configuration file itself is of great help, it is very difficult to create it manually. So, here is a sample VBScript to automatically generate the configuration file for you. Copy into Notepad and rename to CreateBRMConfigXML.vbs.  Note: This VB Script is not currently designed to work against a cluster.

strComputer = "."


quote= chr(34)

XMLtag="<?xml version=" + quote + "1.0" + quote + " encoding=" + quote + "UTF-8" + quote + " standalone=" + quote + "yes" + quote + "?>"

drvold="<DRV old=" +quote

newdrv=quote + " new="  +quote +"Generic / Text Only" + quote + "/>"



Set objWMIService = GetObject("winmgmts:\\"& strComputer & "\root\CIMV2") 
Set colItems = objWMIService.ExecQuery( _
"SELECT * FROM Win32_PrinterDriver",,48) 

Wscript.Echo XMLtag
Wscript.Echo "<BrmConfig>"
Wscript.Echo "<DriverMap>"

ForEach objItem in colItems 

'Wscript.Echo "<DRV old=" &quote & ExtractDriverName(objitem.Name) &quote & " new=" &quote & "Generic / Text Only" &quote & "/>" 
Wscript.Echo  drvold & ExtractDriverName(objitem.Name) &newdrv

Next


Wscript.Echo "</DriverMap>"
Wscript.Echo "</BrmConfig>"


Wscript.Quit


Function ExtractDriverName(dName)
ExtractDriverName = Left(dName,(InStr(dName,",")-1))
End Function

On the old print server run the following command to generate the Config File:

Cscript //Nologo CreateBRMConffigxml.vbs > DriverMapping.XML

This should create a file like the one below mapping every driver to the "Generic / Text Only" driver when used with the –C option in printbrm.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<BrmConfig>

<DriverMap>

<DRV old="Xerox WorkCentre Pro C3545 PS" new="Generic / Text Only"/>

<DRV old="Xerox WorkCentre Pro C2128 PS" new="Generic / Text Only"/>

<DRV old="HP LaserJet 8000 Series PCL 6" new="Generic / Text Only"/>

</DriverMap>

</BrmConfig>

Setting every printer to "Generic / Text Only" may not always serve our purposes, so we have some more tricks to allow for more customization. Here we will make use of the Universal drivers made available by various OEMs for a better printing experience.

Right click the DriverMapping.XML file and open with Microsoft Excel, preferably version 2010 as that is the one we tested on. Choose open "As an XML table" when prompted:

This should open up the driver mappings in an easily editable table:

Now you can Map the OEM drivers to its corresponding Universal driver by simply replacing the driver name in the “new” column with the exact driver name of the universal driver and use fill/copy for the rest of the drivers just as you would work with an excel file.

Note that the driver names you put in here should match EXACTLY with the installed driver; also make sure you install both x86 and x64 versions of these drivers on the target server before attempting the restore.

For example, some of the OEM universal drivers are named as follows: "Xerox Global Print Driver PCL6", "HP Universal Printing PCL 6", "Lexmark Universal" etc. There are various versions of UPD hence make a note of the one you have installed on the target server.

Once the substitution is done, right-click anywhere on the table and choose XML -> Export and save it as DriverMapping.XML This will create the new Configuration file with the newly added mappings to the Universal drivers or other compatible drivers of your choice.

Note:  Before running the restore, edit the XML configuration file in notepad and insert the following 2 lines as below between the <BrmConfig> and <DriverMap> sections. Missing this step will cause the export to fail with “unspecified error” (0x80004005).

<BrmConfig>
<PLUGINS />
<LanguageMonitors />
<DriverMap>

You can use the following command to specify the Configuration file when restoring:

Printbrm.exe –R –S \\NewServer -F c:\temp\Backup.printerExport –C c:\temp\ DriverMapping.XML –O FORCE

If you do not want to migrate your old drivers to the new server use the backup generated using the –NOBIN option:

Printbrm.exe –R –S \\NewServer -F c:\temp\nobinBackup.printerExport –C c:\temp\ DriverMapping.XML –O FORCE

This should restore the Printers to your new 64-bit server and map them to the Generic/Universal drivers without having to install hundreds of device specific OEM drivers.

Standard disclaimer: please note that we are in no way recommending the Universal drivers of any specific OEM and you will need to test them to make sure that it supports your printers and meets your business requirements.

REFERENCES:

Two Minute Drill: PRINTBRM and the Configuration File http://blogs.technet.com/b/askperf/archive/2009/02/20/two-minute-drill-printbrm-and-the-configuration-file.aspx

Best practices on deploying a Microsoft Windows Server 2008/Windows Server 2008 R2 Print Server http://blogs.technet.com/b/yongrhee/archive/2009/09/14/best-practices-on-deploying-a-microsoft-windows-server-2008-windows-server-2008-r2-print-server.aspx

Print Services Migration: Preparing to Migrate

http://technet.microsoft.com/en-us/library/dd379527(WS.10).aspx

Sumesh P.

Share this post :

A while back, I worked on an interesting issue involving RDS EasyPrint. The issue was that the printers from the client were getting redirected in the RDS session using easy print driver. However no print job could be printed to these redirected printers. Interestingly, no events were reported in the event logs, the print job just appeared in the redirected print queue for a few second, and then vanished. We paused the print queue of the printer on the client, but no print job came through to the print queue.

With no events or errors to go with, I decided to collect Process Monitor logs on the server and the client, and try and see if we can track down where the print jobs were going. With a basic knowledge of how the print job flows from an RDS session to the client printer, I was hoping to track this down. Basically we will see the application in conjunction with the spooler process spools the print job. As EasyPrint is XPS based, the spooler process (spoolsv.exe) uses the XPS driver (PrintFilterPipelinePrxy.dll loaded inside spoolsv.exe and printfilterpipelinesvc.exe) to generate XPS job, which the spooler will then send to the client using the virtual channel of the client printer. On the client side, the job is received by the RDC client as a .tmp file in the user’s temp folder, and we have the Terminal Server Print Wrapper (TsWpfWrp.exe), which converts this to the EMF format along with the spooler and spools the job to the destined client print queue.

Using this knowledge, I started looking at the Process Monitor logs, first the server. We see the job getting spooled as below:

After this, we see spoolsv.exe on the server writing the print job to \Device\Rdpdr\tsclient\PRN2, which is the virtual channel for the client printer.

So it seems like the job does leave the server for the client. Now, looking at the Process Monitor log collected from the client, I first went to the process tree view, and do see the tswpfwrp.exe process, as a child process of Mstsc.exe.

Looking at the command line for the tswpfwrp.exe process, it looks like as below:

"C:\windows\system32\tswpfwrp.exe" "\\MachineName\printername" "C:\DOCUME~\username\LOCALS~1\Temp\XPS29C.tmp"

So it seems like we are failing to convert the XPS job we got from the server and send it to the print queue at the client. To ensure that we are headed in the right direction, I created a test XPS print job on my workstation and at command prompt ran the following command:

TsWrpWpf.exe testprinter <location of xps>\test.xps

After doing this, the print job did appear in the paused print queue. Using the same XPS file we tried the same command on the affected client machine. No print job appeared in the queue.

So, it’s the tswpfwrp failing to do the XPS to EMF conversion. A quick comparison of Process Monitor logs collected while running the TsWrpWpf command as above, we see that the process is unable to locate the binary printvpt.dll and this .dll is a part of XPS.

A quick Bing search on ‘XPS’ and ‘printvpt.dll’ led me to Microsoft Knowledge Base article 954550, which includes a hotfix that turned out to alleviate this issue:

http://support.microsoft.com/kb/954550 .

Anshuman Ghosh

Many methods of programmatically working with printers exist and I’ll be going over the main ones we use on the Windows platform support teams in this blog. These can be real lifesavers for print server administrators if changes need to be made across many queues.

As a quick caveat, please keep in mind that we use many of these scripts and utilities for troubleshooting during the course of support incidents but not all of them are supported. I’ll explicitly call out which tools are eligible for Microsoft support services and which ones are not while we walk through them.

In-Box Print Admin Scripts

Supportability

The print management visual basic scripts provided with the OS are fully supported.

Script List

Location:

· Windows XP / Server 2003 - %windir%\system32

· Windows Vista / 7 / 2008 / 2008R2 - %windir%\system32\printing_admin_scripts

Scripts:

· PRNCNFG.VBS

Configures or displays configuration information about a printer.

· PRNDRVR.VBS

Adds, deletes, and lists printer drivers.

· PRNJOBS.VBS

Pauses, resumes, cancels and lists print jobs.

· PRNMNGR.VBS

Adds, deletes, and lists printers or printer connections, in addition to setting and displaying the default printer.

· PRNPORT.VBS

Creates, deletes, and lists standard TCP/IP printer ports, in addition to displaying and changing port configuration.

· PRNQCTL.VBS

Prints a test page, pauses or resumes a printer, and clears a printer queue.

· PUBPRN.VBS

Publishes a print queue to active directory.

Built-in Self Help

All of the in-box scripts display syntax information and examples if you run them without parameters.

CSCRIPT.EXE <ScriptName.vbs>

Commonly used commands:

Add HP Universal Printer Driver (UPD) 5.3 PCL 6 driver

cscript prndrvr.vbs -a -m "HP Universal Printing PCL 6 (v5.3)" -v 3 -i "C:\TEMP\hpcu115u.inf" -h "C:\TEMP"

Add HP UPD 5.3 Postscript (PS) driver

cscript prndrvr.vbs -a -m "HP Universal Printing PS (v5.3)" -v 3 -i "C:\TEMP\hpcu115v.inf" -h "C:\TEMP"

Add Xerox GPD 2.1 PS driver

cscript prndrvr.vbs -a -m "Xerox GPD PS V2.1" -v 3 -i "C:\TEMP\x2UNIVP.inf" -h "C:\TEMP"

Delete all printer drivers that are not in use

cscript prndrvr.vbs -x

Set a print queue to RAW only (disable Advanced Printing Features)

cscript prncnfg.vbs -t -p printer +rawonly

Set a print queue to print directly to the printer

cscript prncnfg.vbs -t -p printer +direct

Create a Standard TCP/IP port with SNMP status disabled

cscript prnport.vbs -a -md -r IP_127.0.0.1 -h 127.0.0.1 -o raw -n 9100

Print a test page to a queue

cscript prnqctl.vbs -p "HP Color LaserJet" -e

Cancel all print jobs in a queue

cscript prnqctl.vbs -p "HP Color LaserJet" -x

More Information:

The unsupported 2003 Resource Kit versions of these scripts can be run against a 32 or 64-bit cluster. 
2466246 - Printer VBScript error: 0x1A8. Object required
http://support.microsoft.com/kb/2466246

PrintUI.dll

Supportability

One-line PrintUI.dll commands are fully supported by Microsoft support services, but the in-box print admin scripts are always the preferred method of getting the same tasks done.

PrintUI.dll Help

PrintUI.dll contains a wealth of information and examples if you run the following command.

RUNDLL32 PRINTUI.DLL,PrintUIEntry /?

Commonly used commands:

Connect to a print queue:

rundll32 printui.dll,PrintUIEntry /u /in /n \\machine\printer

Add OEM printer driver using inf:

rundll32 printui.dll,PrintUIEntry /ia /m "Xerox WorkCentre 7775 PS" /h "x64" /v 3 /f C:\Xerox\x2DLEXP.inf

Add in-box printer driver:

rundll32 printui.dll,PrintUIEntry /ia /m "Brother DCP-116C" /h "x64" /v 3

Troubleshooting:

The vast majority of PrintUI.dll problems are related to incorrect or incomplete syntax.

ü Use example syntax as a template.

ü PrintUI.dll switches are case sensitive.

ü Driver names must be exactly as you see them in the GUI. (when installed manually)

ü Drivers require specification of the correct processor architecture using the /h switch. Use a simple “x86” or “x64” parameter to indicate your preference.

ü Drivers also require a version to be specified with the /v switch. You will always use 3 as the parameter for this switch. (There are no supported v2 kernel mode drivers today.)

More Information:

Deploying Printers and Print Drivers Remotely

SetPrinter (SetPrinter API wrapper)

SetPrinter Support Guidelines

SetPrinter.exe is distributed with the Windows Server 2003 Resource Kit and is subject to the Resource Kit Support Policy.

Resource Kit Support Policy

The SOFTWARE supplied in the Windows Resource Kit Tools is not supported under any Microsoft standard support program or service. Customers can, however, report issues and bugs by sending e-mail to rkinput@microsoft.com. Microsoft will, at its sole discretion, address issues and bugs reported in this manner, and responses are not guaranteed. This e-mail address is only for issues related to the Windows Resource Kit Tools and the Windows Deployment and Resource Kits.

The SOFTWARE (including instructions for its use and all printed and online documentation) is provided "AS IS" without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the SOFTWARE and documentation remains with you.

In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the SOFTWARE be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the SOFTWARE or documentation, even if Microsoft has been advised of the possibility of such damages.

Although no support services are available for this tool, it generally works with all OS’s, both clustered and stand-alone, from Windows XP to Windows Server 2008 R2.

A few sample commands are provided later in this document, but consumers of this tool will generally need to use the embedded help to customize the command line for a desired result.

SetPrinter Help

Running SetPrinter.exe without any arguments will display the embedded help.

Syntax: SetPrinter [-<mode>] <\\server|printer> <level> [<data> ...] [<cmd>]

or SetPrinter -help <level>

or SetPrinter -examples <level>

or SetPrinter -show [-<mode>] <\\server|printer> <level>

where:

\\server : (or \\server\*) change all local printers on this server

(use "" or "*" for all printers on local machine)

\\server\\: change server (not printer) settings

printer : change this printer (printer or \\server\printer)

level : PRINTER_INFO level (0 - 9).

data : (optional) Level specific data in 'keyword=value keyword=value'

format. Data is unchanged for keywords not specified.

cmd : (optional, but must be last if present) one of:

"pause", "resume", "purge", "setstatus"

-help : show format of data for <level>

-examples : show usage examples for <level>

-show : show current settings (no changes applied - all <data> ignored)

-<mode> : (optional) Only valid on Windows Vista and later.

Possible values: -cached, or -notcached

(See documentation for OpenPrinter2 API, pOptions parameter)

The <level> determines which members of the printer structure are used.

The most common <level> values are:

Level 2: Used to configure most print queue settings.

Level 3: Used to set print queue security.

Level 8: Used to set global document printing defaults.

Help for each level is available by running SetPrinter –help <level>

If there is a specific setting you are interested in, you may configure a print queue as desired in the GUI and then use the SetPrinter –show option to find the value.

Self-Help Walkthrough:

These scenarios are intended to “teach you to fish”.

Example One:

I need to know what setting controls landscape vs. portrait in the Printing Defaults, and then set that to landscape for all print queues.

1) This is a global setting that I want all clients to get when the print queue is connected to for the first time, so 8 is the appropriate level.

2) Run SetPrinter –help 8 to see the level-specific help.

3) Run SetPrinter –examples 8 to see some examples.

4) Create a printer called HP and configure it to print in portrait mode.

5) Run setprinter -show "HP" 8.

6) Use the GUI to reconfigure the HP printer to print in landscape mode.

7) Run setprinter -show "HP" 8.

8) Compare the SetPrinter –show results to discover dmOrientation has changed from 1 to 2.

9) Roll out the change to all print queues with SetPrinter "” 8 pDevMode=dmOrientation=1.

Example Two:

I need to know what setting controls a print processor, and then switch all queues to WinPrint.

1) This is a general setting for the print queue, so 2 is the appropriate level.

2) Run SetPrinter –help 2 to see the level-specific help.

3) Run SetPrinter –examples 2 to see some examples.

4) Create a printer called Xerox and set it to the WinPrint print processor.

5) Run setprinter –show “Xerox” 2.

6) Use the GUI to reconfigure the Xerox printer to use a 3^rd party print processor.

7) Run setprinter –show “Xerox” 2.

8) Compare the SetPrinter –show results to discover pPrintProcessor has changed.

9) Roll out WinPrint to all print queues with SetPrinter "" 2 pPrintProcessor=WinPrint.
Note: Most 3^rd party drivers work fine with WinPrint. When in doubt, ask your OEM.

Example Three:

I need to mirror the security settings on one print queue to all other queues.

1) This is a security setting for the print queue, so 3 is the appropriate level.

2) Run SetPrinter –help 3 to see the level-specific help.

3) Run SetPrinter –examples 3 to see some examples.

4) Create a printer called Lexmark and set security as desired.

5) Run setprinter –show “Lexmark” 3 and copy the security descriptor.

6) Roll out the security descriptor to all print queues with SetPrinter "" 3 <Security Descriptor>.

Note: You may need to run this as the local system account. (psexec –s –i cmd.exe)

TechNet Script Repository

The TechNet Script Repository provides printer management scripts with support provided through the forums. Whether you’re a developer or a “script kiddie”, this is the place to go for all of your custom printer management scripting needs. Maybe you can even contribute something to the community? J

TechNet Script Center Repository
http://gallery.technet.microsoft.com/scriptcenter

Disclaimer: The sample scripts are not supported under any Microsoft standard support program or service. The sample scripts are provided AS IS without warranty of any kind. Microsoft further disclaims all implied warranties including, without limitation, any implied warranties of merchantability or of fitness for a particular purpose. The entire risk arising out of the use or performance of the sample scripts and documentation remains with you. In no event shall Microsoft, its authors, or anyone else involved in the creation, production, or delivery of the scripts be liable for any damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the sample scripts or documentation, even if Microsoft has been advised of the possibility of such damages.

I hope you’ve enjoyed reading this information as much as I have putting it together for you, and I sincerely hope one or more of these options can save you some time in the near future.

-Aaron Maxwell

Hello folks, Pankaj here to show you an interesting way to change the Print Monitors and Processors registry keys with a single PowerShell command.  This command can be a timesaver if you have hundreds of 3rd party Print Processors and Monitors on your Print Server (s).

*NOTE* these commands only work on stand alone Print Servers and will not work on Clustered Servers

After you install PowerShell (comes preinstalled on Vista+) you can run these commands:

Command to change Print Processor of all Printers to “WinPrint”
set-itemproperty -path 'HKLM:\system\currentcontrolset\control\print\printers\*' -name 'Print Processor' -value WinPrint

Command to change Print Monitor to “Blank”

For x64 Drivers
set-itemproperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\*' -name 'Monitor' -value $null

For x86 Drivers
set-itemproperty -path 'HKLM:\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3\*' -name 'Monitor' -value $null

Steps to Perform:

1)    Open the PowerShell Command Window from the start menu

2)    Type in the command and hit enter

3)    Check the Print hive again and you will see that all the print processor and monitors have been changed

Location of Print Processors
HKLM\System\CurrentControlSet\Control\Print\Printers

Location of Print Monitors(for x86 Drivers)
HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows NT x86\Drivers\Version-3\

Location of Print Monitors(for x64 Drivers)
HKLM\SYSTEM\CurrentControlSet\Control\Print\Environments\Windows x64\Drivers\Version-3\

BONUS:
To get a total number of installed printers via PowerShell, run this command:

(Get-WmiObject -class "Win32_Printer" -Namespace "root\cimv2").Count

Until next time, take care!

Additional Resources:

What’s new in Windows PowerShell 2.0
http://blogs.technet.com/b/askperf/archive/2010/01/26/what-s-new-in-windows-powershell-2-0.aspx

-Pankaj Pande