> 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?
just thought I'd add something that I've just recently experienced, which goes down the same direction as lingering objects with a slightly different aspect: => a couple of weeks ago, I've seen what I'd call a "lingering link" in a customer's AD forest - a user had been completele deleted, fully replicated as well as garbage collected on all DCs. I.e. the object was nowhere to be found in the forest and there wasn't a lingering object version of it creeping in the dark corner of any GC either. However, the user was still a member of one universal distribution group in AD... - i.e. the user was still linked to the group as a member. => it was the first group _member_ that I've ever seen with the "tombstone naming convention" (CN=<old CB>\0ADEL:<GUID>,CN=Deleted Objects,DC=<domain>) Naturally this should never happen, as deletion of a user object strips the memberOf attribute from the object and thus removes all it's group memberships, but for some reason it wasn't successful on this group. Certainly an awkward situation and not an easy thing to fix. /Guido -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley Sent: Samstag, 30. Juli 2005 01:39 To: [email protected] 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/
