When deciding to begin a Windows migration, whether an NT to Win2K3, Win2K to Win2K3, or even inter-forest migrations, most companies choose to implement new hardware, rather than to simply upgrade their old boxes to Windows Server 2003. In choosing this somewhat more complex migration method, one of the services that needs migrating is Print services. There are two basic issues you'll need to address when migrating Print services:
* Moving Printer shares, permissions and drivers
* Updating Clients to point to the new server
Your first instinct is that you can do all this manually (which you can), but some of you are thinking "I have 5,000 desktops and 10 print servers!" so the manual approach is not something you'd care to think about. This means an automated method would be far more desirable for most of you. Enter the Print Migrator utility, know as PrintMig. This free utility from Microsoft will make moving your print service an easy task. PrintMig has two basic functions: exporting out the source server's printing environment and importing that environment to the target server. So let's address the first need of moving the print services to a new server.
The export process works by creating a single .CAB file that contains all relevant registry entries, share names, permissions and drivers. This resulting single file is all that needs to be copied to the target server. Now before you import this file into the target server, you will need to ensure you have all print monitors that exist on the source server installed on the target *prior* to importing the PrintMig export file. For example, if the source server has a HP JetDirect Print Monitor (so the server can support a JetDirect Port type), you need to install the same monitor software on the target server so the port type is supported there as well. Importing with PrintMig is nothing more than selecting the Import option and choosing the export file to be imported. It is truly that easy!
Now to update your clients, you have two options: The first is to update each client's settings to point to the new server name. This can be done manually, with some scripting, or with third-party tools like ScriptLogic's Desktop Authority. Whichever method you use, you'll need to basically remove the old printer definitions and create new ones. For some of you, that doesn't sit well. So instead I'll give you a sneaky alternative – you can give the new server a secondary name of the old server. Here's how it works: You have the source server in our migration named NT4PS and the target server named W2K3PS. Since NT4PS will be retired, once you have all of the printers migrated to W2K3PS via PrintMig, you can add the REG_SZ value OptionalNames to NT4PS in the following key in W2K3PS's registry:
Once the Server service is restarted (a reboot is better) the W2K3PS server will also respond to all requests that go to NT4PS. For example, whether a client prints to the printer NT4PSHP2100 or to W2K3PSHP2100, the print job will go to the W2K3PS machine and be printed. Using the PrintMig utility and one of the client update methods listed in this article, you can make migrating your print environment a simple, quick and painless task.
The PrintMig utility and information on how to run it can be found at http://support.microsoft.com/kb/275529.
Nick Cavalancia (MCSE, MCT, MCNE and MCNI) is the owner and principal consultant at Exchange Consultants (www.exchangeconsultants.com), a consulting firm specializing in the architecting of Active Directory and Exchange solutions.