Steve, you actually don't have to be a Cisco expert for this one - this is rather unrelated to the underlying network technology used: AD supports "super-netting" for the configuration of subnets to define site-boundaries. Say you have a class C network that holds the majority of your clients and servers, but a specific range should be defined to a different AD site. You could still define the whole class C subnet to your main AD site (e.g. a 24 bit mask like 155.20.1.0/255.255.255.0 ) and then add another subnet with a higher mask for another site (e.g. a 26 bit mask like 155.20.1.50/255.255.255.192). As previously mentioned, this can go as high as a 32bit mask to define a single IP address to a subnet which could again be added to another site. Naturally you can add many subnets to a single site, so that using subnets with a 32bit mask allow you to only specific machines to a certain site.
I've used this configuration quite often to ensure that so called lag-site DCs are defined in their own AD site within a shared subnet, which seems to be exactly what you want to do. You can then create a site-link between this new site and your main site to define a replication schedule that suits your needs. To add to Brett's list of warnings... Warning A: Brett has already mentioned the issue with forcing replication => neither disabling inbound replication nor changing the site-schedule will hinder any sufficiently authorized admin to force changes from one DC to all other DCs in the forest. This includes your "hot-standby" DC as you call it - I call it a "lag-DC" as the goal is to keep it lagging behind in replication. The problem is, that the admin might not really know that he's doing this - although it's pretty obvious if you use the /FORCE switch with repadmin /replicate, it's not so obvious if you use the replmon UI, which many admins tend to use instead of repadmin command. Replmon actually uses forced replication for many of it's actions, whithout telling you it's doing so. So if admins want to push a specific change from one DC out to the rest of the forest, they'd often use replmon's "Push mode" option, which in the background is actually forcing the destination DCs to replicate with the source DC - this would already invalidate your approach to use disabling inbound replication as a safety option if the "lag-DC" in the same site... But if you're unlucky and the admin also chooses the "Cross site boundaries" option in replmon, the changes would also be written on those DCs that are "protected" via the specified replication-schedule (lag-site). The only way around this is to ensure that the lag-DCs are either turned off or their network is disabled - not saying that this is easy, but running them as virtual machines might be an option to control this process. Ofcourse you should also limit those admins that have the ability to force replication in the first place. Warning B: you have to beware that a single DC that's protected from "normal" replication might not give you the protection you're seeking with respect to having a valid "lag-DC" to protect your AD. Picture the incident that causes your AD disaster happening one minute or a few seconds prior to your configured replication schedule (no matter if you use a separate site or a script that periodically forces replication to keep your "lag-DC" up-to-date): you would likely have no way to react _in time_ to the incident to keep your special DC from replicating the bad changes. Thus you'd be off to normal recovery afterall. You have to be aware of this risk and either accept it, or add another "lag-DC" which has an offset replication interval to the first one so that, so that it would not replicate this bad change at the same time (giving you more time to react on the incident). The choice of the replication schedules for each "lag-DC" certainly depends on your specific requirements and environment => lag-DCs in global AD infrastructures (where changes happen around the clock, anywhere in the world) have different needs than a very local installation of AD. /Guido -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Schofield Sent: Samstag, 30. Juli 2005 23:26 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/
