Problem migrating printers on 2003 printservers

[jbarelds]

Hi,

I'm in the process of migrating printers on the current printserver to another host. Currently we have a clustered printserver running on a 2-node Server 2003 cluster. The reason we'd like to migrate the printserver is because the cluster is also used as our main fileserver, and we'd like to migrate the fileservices to a 64bit 2003 cluster. Due to 32bit printer driver limitations we'd like our printserver to remain 32bit, so I installed a new 32bit Server 2003 server to migrate our printers to.

As a test, I built a S2k3 VM and configured it as a printserver, serving one HP printer using a standard tcp/ip port. The printer is nicely shared and published in AD, and prints like a charm. I used the MS "printmig.exe" tool to backup the printserver config, and restored it on the new printserver.

However, it seems only the printer port (IP_172.29.39.6 in this case) is being recreated. The printer itself and its driver are not shown in the Print Management MMC.

This is not a good start. If this one test printer won't migrate correctly, I'm starting to worry about the 50 other printers to be migrated away from the cluster.

I hope some of you can give me some advice on how to get this migration going. Thanks in advance.

 

[jbarelds]

Further investigation shows that another user on this forum (XRJoe) also had similar issues:

http://www.tek-tips.com/viewthread.cfm?qid=1432771

In the Print Migrator log file it shows that there are files missing in the backup cabinet (.cab file). More specific; if a driver file set for a printer contains a .cab file, it is not included in the Print Migrator backup cabinet file. Seems to me like a serious bug in the Print Migrator application.

I checked the printerdriver directories on the current print cluster, and a nice list of .cab files were found. So I guess "Print Migrator" won't be usefull in my situation.

I hope someone else can help me get this migration going from here.

 

[58sniper]

If the drivers on the original server weren't signed, you'll run into that problem. Update all drivers on the original server first.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[jbarelds]

I found out the "printbrm.exe" printer migration tool that ships with Vista & Server 2008 does work the way it should. Drivers containing CAB files are included using printbrm utility, and printers are restored properly on the target server. Printbrm is a new replacement for printmig.

As such, I don't this driver signatures are not part of the problem here. At least not yet, I'll keep it in mind when migrating the actual printcluster.

One problem remaining... All printers in our organisation have been added manually by searching AD on the users' computers. If I were to migrate now, none of these installed printers will be usable anymore, as the name of the printserver has changed. In fact, the AD object for the printer has been removed and recreated, pointing to the new printserver.

Is there a way to migrate the printserver transparantly without having to pay 600 visits to users (besides sending a howto by mail)?

 

[58sniper]

In the vbscript forum here, MarkDMac has a logon script that will remove printers from a workstation.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/

 

[jbarelds]

Hi 58sniper & others,

Removing printers using a loginscript is easy, what I want is to edit the existing printer connections to point to the new printserver hostname (from \\prtsrv01\printer1 to \\prtsvr02\printer1 for instance).

Something like: wmic printer set servername="\\prtsvr02"
Needs further investigation obviously...

Or if that's not possible, to store the existing printer share names (printer1) in a temporary file, delete all printer connections, and the add printer connections using the new server name + the printernames stored in the file.

Something like:
for /f "DELIMS=\ TOKENS=2" %%i in ('"wmic printer get name | find /i "\\PRTSVR01""') do @echo %%i>>printers.txt
wmic printer delete
for /f %%i in (printers.txt) do @some command to add \\PRTSVR02\%%i

I don't want to show interactive dialog boxes to my users, everything has to be done automatically. Also, the script may not contain commands that are not available on XP clients, or that need special rights. The script will be deployed using a GPO (Login script).

Have been fidling with the /Ss and /Sr options of "rundll32 printui.dll,PrintUIEntry", but couldn't get it to work yet. Exporting is no problem, but upon importing no printers are created. No errors are shown though.

Hope someone can help me out with this.

 

[jbarelds]

FOUND A SOLUTION

The ChangePrintSRV.exe tool can change the printserver for all connected printers from a specific printserver to another printserver. It's available at

http://www.petri.co.il/changeprintsrv.htm

So my plan is as follows:

1. Use Printbrm from Server2008 to migrate all printers from the printservercluster to the newly installed printserver. After this step both printservers host the same 53 printers, and all printers are published twice in AD.

2. Configure a login script using ChangePrintSRV.exe to change the printserver for all printers installed for all users, store it on a share, and make a GPO to have all users execute the loginscript.

3. Leave this situation for a month or so, so that at least most users get their printers redirected to the new printserver. Check the amount of printing through the old printserver from time to time.

4. Inform the helpdesk about the removal of the old printserver and how to handle calls about offline printers resulting from the removal of the old printserver. Then actually remove the old server and clean up objects in AD.

5. Celebrate the end of another well executed project by eating pie.

 

[58sniper]

If you're using Windows Server 2003 R2, it has built in printer management that lets you administer printers really easy via GPO. But you'll need to get the old ones off first. Use the vbscript to pull the old ones, and use the Printer Management to deploy the new ones. In the future, if the server/printer changes, you merely make the required changes at the server and it rolls out to the org.

Pat Richard MVP
Plan for performance, and capacity takes care of itself. Plan for capacity, and suffer poor performance.

http://www.ucblogs.net/blogs/exchange/