Same here, I still have our physical server but I used Microsoft Print Migrator to copy all 40 printers and setting to the new Virtual server. We now setup all new printers from the new server and slowly moving everybody to the new one. The plan is to have all moved in 4 - 6 months. I guess we could create a login script to do the change but why bother. Anyhow ones everybody is on the virtual we have redundancy with VMWare as mentioned below.
___________________________________ Stefan Jafs From: Sherry Abercrombie [mailto:[email protected]] Sent: Wednesday, April 01, 2009 9:25 AM To: NT System Admin Issues Subject: Re: Redundant Print Servers We had tried for years to have the print server as part of our "File & Print" cluster. No matter what we tried, we couldn't get the cluster on the print server part of it to fail over. This became a critical situation a couple of months ago when the physical machine that owned this resource, started getting BSOD's. As soon as I would fail over it's resources, it would blue screen. We'd had this issue a few weeks prior on a domain controller that we ended up rebuilding. I was able to leave this server up with no clustered resources on it and have it stay up, so I had a little time to do some research on this particular stop code rather than just rebuild it. Found an unpublished MS KB article in a discussion forum that fit exactly, right down to all the codes from the BSOD, it was a simple reg hack fix, and it worked. This got us moving to a different solution for print server though because it glaringly pointed out the single point of failure for about 5 hours of no one being able to print on the network. Yikes, we were not very popular during that time...... The solution we came up with, VMWare. We've built a new print server virtual machine, and are gradully moving the network printers over to it. This has been a fairly painless process since we had the fortunate event of having most of our network printers being replaced by new ones, so it was just part of the process of implementing the new printers. With VMWare's HA, if the host this server is running on goes down, we have it set to automatically come up on another host server (it's called clustering in VMWare ESX land, but it's not MS clustering), down time would be minimal, ~3 minutes. So, to make a long reply even longer, I would recommend, if you have the virtual infrastructure, going virtual with your print server and having the HA/failover options based on that. Have I ever mentioned that I really really like VMWare??? ;) On Wed, Apr 1, 2009 at 7:59 AM, Thomas Gonzalez <[email protected]<mailto:[email protected]>> wrote: That's what I need to see, especially when Canon comes out and takes down our 5185 without notifying me. If you have that process written up, could you please share? TIA Thomas From: Michael B. Smith [mailto:[email protected]<mailto:[email protected]>] Sent: Wednesday, April 01, 2009 7:53 AM To: NT System Admin Issues Subject: RE: Redundant Print Servers Is that process written up anywhere? ________________________________ From: Ken Schaefer [[email protected]] Sent: Wednesday, April 01, 2009 7:58 AM To: NT System Admin Issues Subject: RE: Redundant Print Servers What we did at one customer was: a) disable printer publishing into AD b) create custom printQueue objects in AD under a custom computer account (which is your print server alias) c) disable print queue pruning That way: - users can still search AD for printers - you still get the redundancy you want (whether by DNS failover, content switch load balancing or whatever) Cheers Ken ________________________________ From: tony patton [[email protected]<mailto:[email protected]>] Sent: Wednesday, 1 April 2009 7:29 PM To: NT System Admin Issues Subject: Re: Redundant Print Servers We have 2 print servers per site, an active and passive. When we make a change to an active printserver, we do the same on the passive, or we're supposed to :-) The way we handle redundancy is to use a dns alias, so we have srv-print<sitecode>01 and srv-print<sitecode>02 with the dns alias of srv-print<sitecode> If the active server goes down, we just change the dns entry to point to the other server. The only problem with this is that if the user goes to add a printer and selects the Find in directory, it lists the queues on the actual servers. I've created a vbscript that checks the users printers and if its not connected to the alias, it deletes it and re-maps to the alias queue. I can pass on the script if needed. You also need to do the following reg edit otherwise you get a duplicate name error. [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters] "DisableStrictNameChecking"=dword:00000001 Regards Tony Patton Desktop Operations Cavan Ext 8078 Direct Dial 049 435 2878 email: [email protected]<mailto:[email protected]> "Michael B. Smith" <[email protected]<mailto:[email protected]>> 31/03/2009 21:17 Please respond to "NT System Admin Issues" <[email protected]<mailto:[email protected]>> To "NT System Admin Issues" <[email protected]<mailto:[email protected]>> cc Subject Redundant Print Servers So...what is everyone doing for redundant print servers? (That is, one server hosting all printers goes down, the other takes over; alternately, two servers share the load usually until one crashes and the other takes over?) I can think of a couple of ways to handle this, but I'd like to know what "everyone else" is doing... Regards, Michael B. Smith, MCITP:SA,EMA/MCSE/Exchange MVP My blog: http://TheEssentialExchange.com/blogs/michael<http://theessentialexchange.com/blogs/michael> Monitoring Exchange w/OpsMgr now available http://snurl.com/45ppf ==================================================================== http://www.quinn-insurance.com This e-mail is intended only for the addressee named above. The contents should not be copied nor disclosed to any other person. Any views or opinions expressed are solely those of the sender and do not necessarily represent those of QUINN-Insurance, unless otherwise specifically stated . As internet communications are not secure, QUINN-Insurance is not responsible for the contents of this message nor responsible for any change made to this message after it was sent by the original sender. Although virus scanning is used on all inbound and outbound e-mail, we advise you to carry out your own virus check before opening any attachment. We cannot accept liability for any damage sustained as a result of any software viruses. ==================================================================== QUINN-Life Direct Limited is regulated by the Financial Regulator. QUINN-Insurance Limited is regulated by the Financial Regulator and regulated by the Financial Services Authority for the conduct of UK business. ==================================================================== QUINN-Life Direct Limited is registered in Ireland, registration number 292374 and is a private company limited by shares. QUINN-Insurance Limited is registered in Ireland, registration number 240768 and is a private company limited by shares. Both companies have their head office at Dublin Road, Cavan, Co. Cavan. This email and any attached files are confidential and intended solely for the intended recipient(s). If you are not the named recipient you should not read, distribute, copy or alter this email. Any views or opinions expressed in this email are those of the author and do not represent those of the Girl Scouts of Southwest Texas. Warning: Although precautions have been taken to make sure no viruses are present in this email, Girl Scouts of Southwest Texas cannot accept responsibility for any loss or damage that arise from the use of this email or attachments. -- Sherry Abercrombie "Any sufficiently advanced technology is indistinguishable from magic." Arthur C. Clarke Sent from Haslet, TX, United States ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
