It's been a while since we migrated our systems, and since we went from 32 bit WS03 R2 to a 64 bit WS08 R2 print cluster with a new name, I didn't use printbrm at the time. That being said, I've used printbrm to do exports of our config and it doesn't restore everything well to another box, like you've experienced, but it's also been a while since I've tried using it (not counting my nightly export scripts).
I think the main issue for us is because of print processors, and in our case may be related to a bug where Windows doesn't always delete old processors over time - http://support.microsoft.com/kb/242394 and since we are using HP Universal drivers, it gets complicated at times--you may be in the same boat. I've had to remove the old processors after updating queues on more than one occasion. And, based on some experience I've had from testing removal of print processors, I've also seen that if the print processor is not there, the queue does not appear at all, like what you are reporting. But, the queue does show in the registry, meaning if you only could load the print processor files, it would work. If you're using HP's UP drivers, I can provide more info on the messiness of it--it sort of sounds like that might be the scenario. Otherwise, if I were looking at what you are working on, I would focus on which print processors are missing for the queues that don't appear at import, and whether you can just reload the software for that easily or just recreate the queues. In our case, with 500 network printers, I keep all of the original drivers on hand (that aren't via windows update) in case we had to rebuild and printbrm or some other available restore mechanism (like a BMR) doesn't do the trick, along with our printer info DB. -Bonnie -----Original Message----- From: Michael Leone [mailto:oozerd...@gmail.com] Sent: Thursday, January 31, 2013 8:34 AM To: NT System Admin Issues Subject: Re: Migrating from a 32bit print server to a 64bit print server I'm surprised no one responded at all. Anyways, here's further info: I did do the "printbrm -R -F filename". And there were errors. So I reverted back to a clean snapshot (it's a VMware VM), added the same print drivers that are on the production server (both 32 and 64 bit drivers, same versions) - I used the list of print drivers shown in "Printer Management" on the production server. Made a new snapshot. And tried restoring again (no overwriting, no queue publishing). And I'm still getting errors. I am only getting about 2/3 of the printers/queues restored. I am getting errors 0x80070706 and 0x80070705. 0x80070706 is "Print Processor unknown", which is odd, because I am getting that for some queues that use one of the pre-installed drivers. And other queues, using the same driver, import with no errors, so I guess those are finding the print processor, so it must exist ... 0x80070705 is "Printer Driver unknown". Again, this is for a driver pre-installed, and other printer queues that use this driver work; they restore (haven't tried printing to them yet, as those printers aren't local to me). I have 92 printers, and only 68 import correctly. So what should I do at this point - just manually install the 24 printers that didn't come through? I just don't understand why the print processor seems to work for some printer queues, and not others. I know I am going from 32bit to 64bit, but I have both drivers already installed (for both the production 32 bit and the new 64bit). Anyone have any ideas, before I go installing 2 dozen printers? On Wed, Jan 23, 2013 at 12:35 PM, Michael Leone <oozerd...@gmail.com> wrote: > I have a VM that is running Win2008 (not R2) 32bit, and we are using > this as our print server. I save the printer definitions and queues > using the "printbrm -B -F filename" command as a scheduled task. Note > that this server has both 32bit and 64bit drivers installed to it (I > am told). 64bit drivers installed to that print server using the > "Print Manager" snapin from a 64bit PC. > > Now, I want to replace this VM with a new one, running Win2008 R2. I > think I should just be able to do: > > printbrm -R -f filename > > and then all my printers and queues should install, and be ready to > go. Then I can decommission the old server, re-name the new server, > re-use the old IP, and everyone who uses a printer defined on that > print server name should continue to Just Work. > > .. .which seems Too Easy. Am I missing some consideration here? > > Thanks ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to listmana...@lyris.sunbeltsoftware.com with the body: unsubscribe ntsysadmin
