Steve - David is not talking about a Cisco (or network layer) related network trick. This is at the site, or more appropriately, subnet object level. And, this should not prevent you from doing this on the public scope.
Consider that one of your public IP's is 12.30.10.0/24, for example. If you create an IP subnet object of 12.30.10.1/32 for instance, and the associated site and sitelink objects and associations, you've effectively created a site with a single object - the DC in question. Rick -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Schofield Sent: Saturday, July 30, 2005 4:26 PM To: [email protected] Subject: Re: [ActiveDir] turn off replication to a DC in same site 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: <[email protected]> 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: [email protected] > 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: <[email protected]> > 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: <[email protected]> >>> 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/ 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/
