The
other David pretty much covered it with perhaps the exception of Virtual DCs; in
the past I've tended to avoid placing intersite load on Virtual DCs though
I prefer to achieve such a result using staging/lag/latent (or whichever
term you prefer) sites assuming the customer in question fully grasps the
purpose and importance of the extra site(s) ... even that to some extent depends
on the perf. characteristics of the Virtual DC though.
Outside of that, the only additional comment I'd make is that, in my
experience, preferred bridgeheads are more frequently used to designate who's
not a bridgehead rather than who is ... thought that worth a
mention.
One
final and somewhat related comment, manual designation of the ISTG can prove to
be a much more valuable exercise in larger environments than manual designation
of bridgeheads since the ISTG process itself is computationally expensive and
warrants placement on suitably (proc. & memory wise) high-performance
hardware. This is a lesser concern these days due to the exponential leaps
in performance we've seen over the past few years but, obviously, the scale and
complexity of the forest and its replication topology impact the validity of
that statement. It may also become necessary to manipulate the failover
detection timers to prevent the role from being inadvertently moved during
scheduled downtime.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Cliffe
Sent: Monday, August 08, 2005 9:20 PM
To: [email protected]
Subject: RE: [ActiveDir] Preferred Bridgeheads
In the same spirit - but on the other side of the coin :) - I wouldn't
mind hearing a brief elaboration on your earlier
statement:
"I've found only a few scenarios in which they proved
valuable"
Perhaps one reason might be when one of
the servers in a site is underpowered/waiting to be upgraded,
etc..?
-DaveC
Reuters IS&T Service
Delivery
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells
Sent: Monday, August 08, 2005 6:14 PM
To: Send - AD mailing list
Subject: RE: [ActiveDir] Preferred Bridgeheads
Without wishing to labor the point Russ, what aspect of replication
'speed' was thought to be improved? I ask as I often lecture on AD (and
related technologies) and am interested to understand some of the
misconceptions.
--
Dean Wells
MSEtechnology
* Email: dwells@msetechnology.com
http://msetechnology.com
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rimmerman, Russ
Sent: Monday, August 08, 2005 6:08 PM
To: [email protected]
Subject: RE: [ActiveDir] Preferred Bridgeheads
We thought it would "help" with replication speed. I
guess it was more of a WAG.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells
Sent: Monday, August 08, 2005 2:13 PM
To: Send - AD mailing list
Subject: RE: [ActiveDir] Preferred Bridgeheads
If you
constrain the list of bridgeheads you may be incapable of replicating an app. NC
in and out of a site since in order to replicate a particular
partition, the bridgehead in question must hold a copy of it ... if the
preferred list contains only 2K DCs, that can't happen .. for the most part
... a 2K3 ISTG will override your choices and allocate a suitable
bridgehead for you, it will however whine and whine and whine and ... you get
the idea.
I've
found only a few scenarios in which they proved valuable ... may I ask why
you're using
them?
--
Dean Wells
MSEtechnology
* Email: dwells@msetechnology.com
http://msetechnology.com
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rimmerman, Russ
Sent: Monday, August 08, 2005 3:03 PM
To: [email protected]
Subject: [ActiveDir] Preferred Bridgeheads
We're almost all
Win2k3 Domain Controllers, have a few left to upgrade.
Question is, we have
at least one DC at each site configured as a preferred bridgehead for IP.
Is this not a good idea? Is it best to not prefer any bridgeheads and let
AD do its job? I'm seeing a lot of event ID 1567's about it as
well.
Thanks
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This e-mail is confidential, may contain proprietary information of the Cooper Cameron Corporation and its operating Divisions and may be confidential or privileged. This e-mail should be read, copied, disseminated and/or used only by the addressee. If you have received this message in error please delete it, together with any attachments, from your system. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This e-mail is confidential, may contain proprietary information of the Cooper Cameron Corporation and its operating Divisions and may be confidential or privileged. This e-mail should be read, copied, disseminated and/or used only by the addressee. If you have received this message in error please delete it, together with any attachments, from your system. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
-----------------------------------------------------------------
Visit our Internet site at http://www.reuters.com
To find out more about Reuters Products and Services visit http://www.reuters.com/productinfo
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Reuters Ltd.
