Print Server Migration

Printing is probably the most vital function called upon in an enterprise network. Without printing, forms cannot be made, drawings cannot be assessed, and reports cannot be efficiently processed. It always takes me by surprise when I consistently see businesses taking printing for granted. The printing eco-system in your network is not tremendously complex but is an essential part of day-to-day business operations.

In home and small office environments, printing is typically done using a locally connected printer. This works well when only one person is using the printer, but doesn't scale when many people need to print many things at once. A desktop computer is inherently limited and cannot process multiple requests from multiple people without severely slowing down. This in turn creates a "bottleneck", a place in the network through which traffic is tremendously slowed down, and this in turn slows the entire network down just as an accident will slow down a highway system.

The solution is to use a dedicated print server which can support all clients that connect to it for printing.. Our client had an older server which was also serving as a security application server for their antivirus. This server was at the end of its useful life as the RAM and drive space was maxed out and it had an obsolete OS and no prospects for further upgrades. The client asked us to recommend a server and spearhead the migration. To complicate things, we needed to keep the exact same name and IP address since the print server interfaced at a core level with their primary business management system.

A print migration requires several items to be identified and backed up before the process can begin. First, the print queues need to be recorded, including what driver is being used, what IP address is being used and what share name is being used. While there are tools that may assist with this, it should be assumed that this information will need to be manually reentered on the new print server. The drive configuration of the print server should be selected for redundancy. We set up a RAID 1 or mirrored drive array to allow data to be continuously kept on two drives, and had a third drive set aside as a hot spare, allowing the system to seamlessly swap in the extra drive should there be a RAID failure and to prevent catastrophic data loss.

The OS chosen for the new print server was Windows Server 2008 R2 for its blend of reliability, compatibility with the existing server infrastructure, and useful features such as the Print Management console. The old server maintained a Server 2003 x64 OS due to hardware limitations. This server would continue faithful service as a dedicated security application server.

The print server migration proved to be fairly painless. As expected, the queues did not directly transfer over, however we found a trick to allow the queues to be transferrable with only minor adjustments. This allowed us to rapidly recreate the queues and begin testing. Aside from some minor driver incompatibilities, this went without a hitch.

One important consideration for a new print server is driver choice. Maintaining the old drivers (if fundamentally compatible) seems to be the obvious choice, however there is merit in using a single driver class for each group of compatible printers as this drastically reduces the load on the server. While we did start out with updated drivers, issues that cropped up post-migration showcased too many incompatibilities with the customer's software and we reverted back to the older drivers, which are working well.

So after reading that, you might expect me to say that this one was easy and move on right? Actually, no. The greater challenge of the migration was addressing the new security server. You may recall that I mentioned that in order to maintain compatibility with the customer's business management software, we needed to keep the same IP address and hostname?

An IP address is like a street address in that if it changes, everyone must be informed of that change or else no one can find it again. And the same is true that if your name changes, you must inform everyone from family to creditors of that change. This turned out to be the root problem here, in that when the server changed its address and name, over a hundred antivirus clients spread over three locations suddenly couldn't be told what to do.

After contacting the antivirus software vendor, several methods of relaying the new information to the existing clients were considered, but nearly all of them required complete redeployment of the clients, a process which might take days and may result in having the computers completely unprotected. We were therefore forced to think on the fly and come up with a solution that could be implemented in one night.

As it turned out, only a single file needed to be changed on each PC. We made a program to automatically copy the file to each computer on the network and reboot it. With the aid of this, we were able to complete the migration successfully over the night and everything was up and ready for the client the next day.

Since the migration, the client has enjoyed greater speed and reliability in both printing and in regards to their antivirus software. Interested in us helping you out with a printer or security server migration? Please feel free to contact us for a quote today!

Recent Posts


Would you like a downloadable copy of our service offerings?

Find Us Elsewhere

Come and find us on Facebook & LinkedIn!