That is fine, I'm glad people speak up about different ideas, I don't claim to be an expert just was given the direction to come up with a solution. I'm not a Cisco expert and we currently do not have a private network all machines are publish IP based. This also has to be pretty hands off once deployed. I'll research the one ip solution with others and maybe that is the lesser of all evils.

Steve

----- Original Message ----- From: "David Adner" <[EMAIL PROTECTED]>
To: <ActiveDir@mail.activedir.org>
Sent: Saturday, July 30, 2005 4:58 PM
Subject: RE: [ActiveDir] turn off replication to a DC in same site


I don't agree with your overall plan, but regardless, do you know you can
define a single IP address to a Site of its own?  Just define it as, for
example, 10.10.1.1/255.255.255.255 (ie: a 32bit mask).

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steve Schofield
Sent: Saturday, July 30, 2005 3:35 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] turn off replication to a DC in same site

Hi Brett/Joe,

Great information and from your perspective this probably seems like an out
of the normal request which goes against best practices.  In most cases
things like this sooner or later causes issues and the "I told you so"
applies.  I definitely don't have the exposure to AD environments like you
being in ESE but from the world I live in, we have 6 public networks and
every IP address and network is valuable.  We don't have the extra network
to deploy a DC on. My preferred method would be to park this DC on its own network and control replication using site based replication vs. the manual
disable/enable that I am doing now.  btw, I have two batch files that are
automatically enable/disable replication everyday.

I have done this in another environment and worked effectively in having an *just-in-case* the world burns down in AD. I also lowered the LDAP records
in DNS so authentication, Kerberos attempts are not sent to this DC + this
DC is not used for DNS resolution. I would love to just turn off Kerberos, LDAP SRV records in DNS for this server. I think there is an article on this

but can't find it right now.   This has been deployed in production for a
few days and is working as expected. I caution others before implementing
something like this it has its drawbacks and if you are not sure don't
deploy it (or test, test, test!). You have to make sure other machines and
services do not use this DC as authentication, DNS attempts or for LDAP
requests because the data is not up-to-date.

This solution has its risks as any out of the ordinary ideas but I would
rather have a *hot-standby* like this available because so many critical
services depend on AD vs. having a total down situation where email, client user authentication is affected even for a few minutes. Because I only have
2 DC's if something happens, both are affected right away and services are
affected almost immediately. The restore of AD would take about 30 minutes
to 1 hour to restore is not an option.  So this is a risk I'm willing to
accept. This probably would make a good case study and it has its arguments either way. I originally was presented this idea in an AD class taught by a Microsoft engineer a few years back. Definitely appreciate all the inputs,
things to look for etc.

Steve Schofield
[EMAIL PROTECTED]


----- Original Message -----
From: "Brett Shirley" <[EMAIL PROTECTED]>
To: <ActiveDir@mail.activedir.org>
Sent: Friday, July 29, 2005 7:38 PM
Subject: Re: [ActiveDir] turn off replication to a DC in same site


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/


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/

Reply via email to