Ken,
Did you guys take a look at the bandwidth utilization when sending all the remote site print jobs to the central print server and back to the local printers again? I can understand why you'd want to centralize the print sharing, but, admittedly without having really looked in to this, I'd be a bit concerned about burdening the remote site WAN links with print jobs. -Malcolm From: Ken Schaefer [mailto:[email protected]] Sent: Wednesday, April 01, 2009 6:31 PM To: NT System Admin Issues Subject: RE: Redundant Print Servers We had a 30-odd page detailed design, and a 30 page implementation guide, a DR guide, ops guides etc... This was for a reasonably large organisation (around 10K users) who wanted to have a centralised print server cluster in one data center for all their small branch sites (several hundred of those), as well as a second print cluster in the DR data center. The failover was between these two data centers, as the customer didn't want to pay for a stretched cluster just for printing. And they wanted users to be able to search AD for printers. That last part was the kicker. In a DR situation, the only thing that needed to be changed (IIRC) was the cluster that the DNS hostname was pointing to. The rest of the ops work (e.g. creating the print queue objects) was all handled by a little wizard based HTA application that we wrote (IIRC) and worked into the operations processes of the org. Cheers Ken _____ From: Michael B. Smith [[email protected]] Sent: Wednesday, 1 April 2009 11:53 PM 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]] 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\parameter s] "DisableStrictNameChecking"=dword:00000001 Regards Tony Patton Desktop Operations Cavan Ext 8078 Direct Dial 049 435 2878 email: [email protected] "Michael B. Smith" <[email protected]> 31/03/2009 21:17 Please respond to "NT System Admin Issues" <[email protected]> To "NT System Admin Issues" <[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://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. ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
