Although we can find some discussions about migration of print services to 64 bit Window servers, there is very little information regarding caveats or things to note when doing such migration.
Recently, I had the opportunity to migrate some of our Windows 2003 32bit print server to Windows 2003 64bit print servers and here is some of my experience that I hope will help some people out there.
Here is a overview of what I did:
- SVR-32A: 1 x Windows 2003 32-bit printer server (this is one that users are using)
- SVR-32B: 1 x Windows 2003 32-bit as a jump server
- SVR-64: 1 x Windows 2003 64-bit printer server (this is the new printer server)
- SVR-08:1 x Windows 2008 printer server (this is necessarily to run printbrm)
- Use PrintMig to make a backup of SVR-32A (you can use printbrm if you like via SVR-08)
- Restore printers using PrintMig to SVR-32B (you can use printbrm if you like via SVR-08)
- For each printer in SVR-32B, install the 64-bit equivalent. For 64-bit native drivers, you need to point to the i386 or ADM64 source of the 64-bit server install source or CD.
- Clean up unwanted ports and drivers on SVR-32B
- From SVR-08, run printbrm to backup the printer on SVR-32B
- Then using printbrm to restore the printers to SVR-64.
– You need to install both 32-bit and 64-bit print drivers onto the W2k3 32bit server for the migration to work properly
– Both 32-bit and 64-bit driver must have the EXACT same name.
– Unfortunately, I found that some printers like HP 8150 PCL6 had the 32-bit drive name with “PCL 6” and the 64-bit as “PCL6”, whcih is totally useless. I had to revert to using the native Windows drivers (with less features) to resolve issue
– I recommend using PrintBrm utility for the migration, which means you need to have a Windows 2008 server to host the migration process, i.e. backup and restore, from and to the remote print servers.
– I recommend that you have another Windows 2003 32-bit server to host the printer drivers before migrating to the 64-bit server. Reason is that since your 32-bit server is in production live, you don’t want to risk installing 64-bit drivers into it and crashing it.
– An interesting thing I found is that PrintBrm will only work with a remote print server if the print$ is available. So you cannot have a server with only print spooler running and nothing else. PrintBrm will have error if you try to restore to it. You will need to create one dummy printer and share it out to make print$ available before PrintBrm will work.
– Some vendor supplied drivers use their own print processor, e.g. HP LJ 4350 uses hpzpp3zw print processor. However, the 64-bit print processor name is different from the 32-bit one. If you do nothing and just run PrintBrm import, you will see that it will fail to import the printers with those vendor supplied printer drivers.
The trick is to set all printers to winprint before you export from the 32-bit print. This will ensure that your import of the printers will work correctly. Interestingly, upon importing, Windows will match the print processor for that vendor supplied driver with its 64-bit print processor. If it doesn’t, you just need to change the print driver to another one and then put it back, this will restore the print processor used by the 64-bit printer driver (if you don’t know which print processor its using).
- If you have 32-bit clients, you will find that changing the default settings on the 64-bit print server will have no impact to them. This is because you are changing only the 64-bit drivers and not the 32-bit ones. To resolve this:
- you must logon to a 32-bit windows machine with admin rights to the 64-bit print server.
- Browse \\printserver to the printers folders.
- Open the properties of the printer and make the required default setting changes.
- I found that particularly on my color canons (HP printers are b/w mostly), the custom configuration did not get imported to the 32-bit drivers. Instead the 64-bit drivers got those settings. I had to redo some of the configurations again.
- Some old printer driverswill not save the settings despite what you do above. For example I had a canon v8.60 drivers and it just would not save the changes I made via a 32-bit machine. After upgrading to v8.80, all was okay.
- If you have old printers, your vendor may not have any supported drivers that will work. In that case, you may need to keep one 32-bit printer server still available and consolidate all these old printers there until they get ditched.
- Color profiles don’t necessary get migrated. You may have to copy the ICM files to the new printer or reinstall the drivers which will install the ICM files.