Thoughts from the EPS Windows Server Performance Team
Useful Microsoft Blogs
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:
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:
<LMONS Arch="Windows x64"/>
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:
<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"/>
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.
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…
Just what I needed. Thanks Digvijay and Blake
Good inforation. But what if i dont want to use Generic Text Only and use other driver. Is there a way to automate selective restore?
Mike - you can use any other driver you want by editing the BRMConfig.xml file. We suggest Generic / Text Only because it's the most compatible.
There is no automated way to selectively restore the drivers.
You will have to manually edit the BRMDrivers.XML file and remove the ones that you dont want.
Is there a switich that can force PRINTBRM -B to overwrite the old backup file?
Thanks for the detailed steps. Helps a lot
How do we remap the driver for Print queue from Generic to the actual driver? We have a print environment with 100's of print queues. Are you suggesting that we use Generic/Text only driver for the problematic drivers and not for all. BRMC.exe tool just maps all of the drivers to Generic. Please clarify. Thanks much
JohnQJ - you remap them manually. We don't advocate any particular drivers - you have to work with the Print device vendors to use what they recommend.
The reason for mapping the queues to Generic / Plain Text is that we know it will migrate successfully without issue. It's the inbox driver for Printers that is actually written by Microsoft.
Salido165 - There is not a switch that can force PRINTBRM to overwrite old backup files - each one has to have a unique name. If you wanted to script the backup - you can include an entry in your script that renames the previous backup file.
Guys, Thanks for a very informative article, have one question that may not be as pertinent to this article as should be.
I am looking to migrate Print Queues, a few hundred of them actually, from a Windows 2003 R2 server to another Windows 2003 R2, (I am trying to mirror the Queues between a prod and DR Print server) would PrintBRM.exe be a tool I can use?
Yes, you can use PrintBRM to do the migration. You can also use the Print Management console of Windows 7/2008 R2 for the same.
One correction on the last step.
The location of BrmConfig.xml is not in C:\Temp\BrmConfig.xml. It should read C:\Temp\Expand\BrmConfig.xml
In case you can't see the forest for the trees. ;)
I am confused on the editing the xml step. Do you remove everything from the XML files so they look like the templates above or do you update the drivers to the x64 drivers that were installed?
Should this work ok with server 2012?
On the current print server I have 45 printers - is it possible to only migrate part of them - I have only 15 printers that I want to migrate - any thoughts?
I only have one problem. It does not work! In the sense that the print queues somehow have a new "identity"??
Even backing up from a server2008x64, to another server2008x64 having the same name, the print queues don't have the same "identity" thus making the clients fail upon reconnection, saying that the "print queue does not exist" ???
Is there NO way around this?
Exactly what i needed and is working very easy and fine!