Man, last night I must've been feeling brazen (or bored), because I
usually don't tell customers about disabling replication, esp. not how to
do in the entire forest in one whack ... esp. not on a forum ... some
warnings last nights mail should've come with ...
Warning 1: YOU MUST MUST MUST still let DCs replicate, _in both
directions_, _on a regular basis_. The regularity of the basis is based
on the fact that AD replication must always happen end-to-end in the
forest within a tombstone lifetime or you end up with lingering objects.
It can be very difficult to your get your forest into a consistent state
again once you get lingering objects. By "let DCs replicate", I mean
reenable replication. If you were to get hit by a bus tomorrow, who
would
turn replication back on, to make sure this forest doesn't get lingering
objects?
Warning 2: You should of course know your AD replication topology,
because
if you for instance disable a DC in a forest with manual replication
connections, OR disable a DC in a site, that is in a chain of sites, with
no site linking bridging (IIRC), then you can schism your topology and
make it so two whole sets of DCs can't talk to each other, instead of
just
the single DC you intended to cut off ...
Warning 3: A word of caution on FSMO transfers ... FSMO transfers are
done
through replication, sooo be careful about transfering FSMOs across
disabled DCs ... don't know if it will work, or not work, but you should
understand a transfer of a FSMO implies replication of some subset of
objects in a Naming Context ... so when doing a FSMO transfer you may not
be isolating a couple DCs from each other, in the way you thought ... or
maybe disable replication does shutdown FSMO transfer ... I don't know
the
behavior, but you should before you transfer FSMO like this in
production,
so you don't have any unexpected results ...
Warning 3a: Oh and don't think you're so clever to instead seize
the FSMO, b/c the FSMO seizure tries to do a transfer first, and
I do not believe there is anyway to inhibit that behavior.
Warning 4: There might be issues with cutting off the PDC emulator & the
mechanism other DCs use against the PDC to sync an account's current
password on a bad password attempt. It might fail or it might work, and
either way it turns out it might not have been what you want, so you
should test which way it works, before you do it. I'm not really sure,
that's SAM stuff ...
I'm _not_ saying disabling replication is a bad idea, or isn't useful,
but
there are ways to make a mess of things for yourself. Probably other
warnings I should've mentioned. Anyway, the option is somewhat "expert".
And like (at least the U.S.) court system, not knowing the law is no
excuse, even if you unknowningly break the laws of replication, you'll
get screwed in the ...
Anyway, back to your question ... if you have the 3 DCs you implied
below,
and you disable the outbound replication of the other two DCs, that is
fine, but then they won't replicate with each other either, which I
didn't
think was exactly what you wanted to achieve ... to elaborate ...
So first remember AD replication is pull based ... there is no push based
replication, a DC never foists changes on another DC, a DC must decide to
ask for changes from another DC. Sometimes however a DC A will trigger
another DC B to turn around and immediately request changes from DC A,
and
obviously this can look effectively like push based replication. But DC
B
can decide to ignore DC A's triggering action, which may happen today
(?),
or may happen in future releases ...
OK, our AD replication basic's lesson aside, you can think of disabling
outbound replication as really "stopping a DC from giving recent changes
out" , i.e. it disables the DC from giving changes to other DCs when they
pull from it.
To approach it from an extremely practical scenario perspective...
Scenario 1:
If you want to keep some changes you're making to DC X, on DC X, until
you're satisifed, you want to disable outbound replication on that DC.
This allows the DC to stay abreast of the changes happening to the rest
of
the forest without injecting changes.
Scenario 2:
If you want to hold DC Y "back in time" from the rest of the forest, for
say backup, or insurance purposes, then you want to disable inbound
replication on that DC. This however doesn't stop a change made to DC Y
from propagating to the rest of the forest.
Scenario 3:
For whatever reason, you want completely isolate DC Z so changes don't go
out from the DC to the rest of the forest, and changes don't come in from
the rest of the forest, then disable both inbound and outbound
replication
on that DC.
Obviously, using disabled replication is very useful though, and if used
properly (for which of course there is very little guidance), it can
enable you superior control over your directory. If you didn't know or
think of warning 1 & 2 off the top of your head, you probably haven't
done
enough reading on AD replication internals to responsibly use this
option.
I'm an ESE dev now, AD replication was my last gig, so I don't really
feel
like writing up another couple pages on how to use it responsibly, but
I'd
recommend ensuring you are familiar with "repadmin /replsum" and/or
"repadmin /showutdvec /latency", to get an idea that the replication
latency doesn't get bigger than you want. There is a latency event in
Win2k3 as well, that basically does some processing of the internal data
that "repadmin /showutdvec" is showing. It's probably not obvious, but
if
you use the /showutdvec or event method to monitor replication, you
should
pick review the information on both a non-disabled DC and a disabled DC,
b/c one or the other might show and issue. Hopefully this plus the 4
warnings will keep you out of trouble ...
Cheers,
BrettSh
Windows::ESE::Programmer
This is definately getting the AS IS posting, so when one of my 1300
closest friends from this list call PSS a tombstone lifetime later, he or
she can't sue us. ;)
Disclaimer: This posting is provided "AS IS" with no warranties, and
confers no rights.
On Thu, 28 Jul 2005, Steve Schofield wrote:
Hi Brett,
Thanks again for the command and it works well. Few follow-up
questions.
Would this command be run only on the DC that I want to disable the
inbound
replication or should I also consider on the other two DC's disabling
OUTBOUND to this single DC or is that not an option. Apologize for the
additional questions just want to make sure. Thanks in advance.
Steve
----- Original Message -----
From: "Brett Shirley" <[EMAIL PROTECTED]>
To: <ActiveDir@mail.activedir.org>
Sent: Tuesday, July 26, 2005 9:46 PM
Subject: Re: [ActiveDir] turn off replication to a DC in same site
>
> Well you have _two_ completely seperate replication systems to deal
> with,
> and I know nothing about FRS, but for Active Directory replication,
> this
> command will do it:
>
> repadmin /options <DC> +DISABLE_INBOUND_REPL
>
> To turn back on, change the "+" to a "-". It's listed in /advhelp
> screen. You can list a current DC's options like this:
>
> repadmin /options <DC>
>
>
> Fun (albeit dangerous) tip:
>
> Even thought repadmin.exe doesn't admit it in the help, secretly I
> made
> repadmin /options work with DC_LIST / DSA_LISTS, so you can have the
> equivalent of the big red emergency shutoff button for replication for
> your forest:
> repadmin /options * +DISABLE_INBOUND_REPL
>
> The /force flag when provided to "repadmin /replicate" WILL override
> the
> disabled flag I showed above. In general everyone should be in the
> habit
> of not providing the /force flag, it's like hitting the OK button as
> habit, stay out of the habit, otherwise it'll be too late.
>
> This posting is "AS IS", if you turn off replication in your whole
> forest,
> it's not my problem.
>
> Cheers,
> -BrettSh [msft] SDE ESE
>
>
> On Tue, 26 Jul 2005, Steve Schofield wrote:
>
>> Hi,
>>
>> I have a single DC I would like to be able to turn on and off
>> replication
>> and only push changes at certain times. Is there command line
>> utility
>> to
>> turn on and off replication or is it as easy as turning FRS service
>> off.
>> I
>> can't separate this DC into a separate site to control replication
>> times.
>>
>> Steve
>>
>>
>> List info : http://www.activedir.org/List.aspx
>> List FAQ : http://www.activedir.org/ListFAQ.aspx
>> List archive:
>> http://www.mail-archive.com/activedir%40mail.activedir.org/
>>
>
> List info : http://www.activedir.org/List.aspx
> List FAQ : http://www.activedir.org/ListFAQ.aspx
> List archive:
> http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive:
http://www.mail-archive.com/activedir%40mail.activedir.org/
List info : http://www.activedir.org/List.aspx
List FAQ : http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
