And, that's what I *LOVE* about the way that Microsoft implemented site / subnet objects - you're no where near as dependent on your network engineers (who, IMHO tend to be a PITA and complicate things much more than necessary - apologies to our NE friends on the list...) as the sites and subnet objects don't have to follow EXACTLY what the physical is. Even more true once you are Intra-Site rather than over WAN linked Inter-Site.
Rick -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Schofield Sent: Sunday, July 31, 2005 2:16 PM To: ActiveDir@mail.activedir.org Subject: Re: [ActiveDir] turn off replication to a DC in same site Thanks Rick for putting clarifying that, networking stuff clutters my mind some times if I don't work with it very often. I didn't mean to give the impression I was totally clueless to networking aka Cisco, rather I don't control the Cisco setup and will have to get with the network guys *who do control the network routers/switches* to setup this. I didn't think to do this as a solution over what I have currently. I was doing the solution I had control over but definitely want to have the *correct* solution vs. some hack. Steve Schofield ----- Original Message ----- From: "Rick Kingslan" <[EMAIL PROTECTED]> To: <ActiveDir@mail.activedir.org> Sent: Sunday, July 31, 2005 11:47 AM Subject: RE: [ActiveDir] turn off replication to a DC in same site > 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: ActiveDir@mail.activedir.org > 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: <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/ > > 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/
