| Author | Messages | |
Parzival
Posts:38
 | | 09/24/2008 1:35 PM |
| Hi All,
I'm looking into replication links (what else to do on a thursday night).. and found something interesting.. probably nothing.. but who knows..
When I request the Connection Objects from one server with repadmin, i get the following result:
Repadmin: running command /showconn against full DC localhost
Base DN: CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL
==== KCC CONNECTION OBJECTS ============================================
Connection --
Connection name : 28e853b9-4c32-4288-87c7-d4b09beaab97
Server DNS name : DC01.ROOTDOMAIN.LOCAL
Server DN name : CN=NTDS Settings,CN=DC01,CN=Servers,CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOTDOMAIN,DC=LOCA
L
Source: DATACENTER2\DC02
No Failures.
TransportType: IP
options: isGenerated overrideNotifyDefault
ReplicatesNC: CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=DomainDnsZones,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=ForestDnsZones,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
Connection --
Connection name : 3329e0ea-9caa-4fd8-92aa-12605fdf4773
Server DNS name : DC01.ROOTDOMAIN.LOCAL
Server DN name : CN=NTDS Settings,CN=DC01,CN=Servers,CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOTDOMAIN,DC=LOCA
L
Note that for the replicatesNC.. there is no schema link.. i checked the other servers, but non of them have that link.. (note this is an automated connection object created by the KCC)..
Question: Could it be that the schema is actually in the configuration partition ? The servers are newly built (Demo environment) and do not show errors with replication..
Roelf
| | | |
| dwells
Posts:39
| | 09/24/2008 1:41 PM |
| Perhaps you misinterpret the purpose served by the term replication
priorities; these priorities serve to influence the sequence of events that
occur during inbound replication when a downstream DC is informed that
changes have occurred to more than one of the partitions it shares with its
upstream partner. The priorities govern which partition it will deal with
first and are not reflected by replica links or their connection objects.
Replica links themselves are simply the result of connection translation -
the process that converts a simple connection agreement (i.e. a connection
object) into something more tangible by determining which partitions are
common to the two DCs on either end of it.
The config. and schema do indeed follow a single repl. topology (more
typically referred to as the 'Enterprise configuration') and likely do so
because a good reason not to wasn't expressed at the time. As best as I'm
able to infer - this is just another example of a design decision. If you
go looking for an all-encompassing technical justification, you'll likely be
disappointed. Since they are distinct partitions, however, the capability
to separate them remains. Perhaps Dmitri or Don H. were involved in that
decision and have an accurate recollection? Other similar design decisions
have also caused confusion, for example - if two DCs replicate a domain NC,
they will also replicate the enterprise configuration regardless of whether
the topology's design goals warrant it or not . this too can be confusing
when trying to justify why the KCC made the decisions it did.
Note that Longhorn's behavior differs here slightly in that the schema NC's
replica link is displayed independently from the config.; I'm afraid at this
stage though, I have nothing further to offer as to the significance of
that.
--
Dean Wells
* Email: limeypride@gmail.com
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Thursday, September 11, 2008 5:28 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
okay.. I get the very important thing about the two.. but isn't that why
replication has priorities.. in the order, schema,
configuration,domain,application ? or does the single link for
schema/configuration automatically combine the first two.. meaning over the
configuration link (which includes the schema).. the schema (if changed) is
always replicated first ? and by combining the config and schema over 1 link
actually this can be forced (by code)
_R
_____
From: ActiveDir-owner@mail.activedir.org
[ActiveDir-owner@mail.activedir.org] On Behalf Of Grillenmeier, Guido
[guido.grillenmeier@hp.com]
Sent: Thursday, September 11, 2008 4:14 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Well, for one thing it wouldn't work if it shared it with the domain
partition ;-)
More importantly, the schema NC and config NC are both the key piece of
every DC's configuration in the forest and an inconsistency between the two
N (which you can have by replicating them via separate links) can have dire
consequences.
/Guido
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Thursday, September 11, 2008 8:52 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Is there any reason why it shares the replication link with the config
partition?
_R
_____
From: ActiveDir-owner@mail.activedir.org
[ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond
[brian@briandesmond.com]
Sent: Wednesday, September 10, 2008 1:48 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
The schema partition is separate however it replicates with the same
topology as the config partition.
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Wednesday, September 10, 2008 1:58 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Replication Links
Hi All,
I'm looking into replication links (what else to do on a thursday night)..
and found something interesting.. probably nothing.. but who knows..
When I request the Connection Objects from one server with repadmin, i get
the following result:
Repadmin: running command /showconn against full DC localhost
Base DN: CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL
==== KCC CONNECTION OBJECTS ============================================
Connection --
Connection name : 28e853b9-4c32-4288-87c7-d4b09beaab97
Server DNS name : DC01.ROOTDOMAIN.LOCAL
Server DN name : CN=NTDS
Settings,CN=DC01,CN=Servers,CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOT
DOMAIN,DC=LOCA
L
Source: DATACENTER2\DC02
No Failures.
TransportType: IP
options: isGenerated overrideNotifyDefault
ReplicatesNC: CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=DomainDnsZones,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=ForestDnsZones,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
Connection --
Connection name : 3329e0ea-9caa-4fd8-92aa-12605fdf4773
Server DNS name : DC01.ROOTDOMAIN.LOCAL
Server DN name : CN=NTDS
Settings,CN=DC01,CN=Servers,CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOT
DOMAIN,DC=LOCA
L
Note that for the replicatesNC.. there is no schema link.. i checked the
other servers, but non of them have that link.. (note this is an automated
connection object created by the KCC)..
Question: Could it be that the schema is actually in the configuration
partition ? The servers are newly built (Demo environment) and do not show
errors with replication..
Roelf
| | | |
| rboswell
Posts:20
| | 09/24/2008 1:43 PM |
| Nice job Joe, Dean just totally stopped class to see what you wrote. And
the truth will set you free....
Richard Boswell | Senior Systems Engineer | Enterprise Systems
Engineering | Visa, Inc. | 1764 Old Meadow Lane, Office 6042, McLean, VA
22102-4373 | Work - 703.287.7939. | Mobile - 512.750.4583
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Thursday, September 11, 2008 9:43 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Yes my old friend, you have gotten very chatty as of late. Gone are the
cryptic 2 line answers with one of those lines being... "call me"... and
the other being "because I am not typing anymore"... and now your true
verbosity shines through.... 
I wonder why?
http://blog.joeware.net/2008/09/11/1461/
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
________________________________
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dean Wells
Sent: Thursday, September 11, 2008 11:04 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
You only like it 'cause it was loooooooooooooong J
Seriously though, they are oddly similar in places!
--
Dean Wells
* Email: limeypride@gmail.com
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Thursday, September 11, 2008 8:35 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
You would almost think we were in the same room when we typed our
responses... Or at least talking on the phone (unless you know me and my
purposeful avoidance of anything phone-like).
Well written Deano.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
________________________________
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Dean Wells
Sent: Thursday, September 11, 2008 10:11 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Perhaps you misinterpret the purpose served by the term replication
priorities; these priorities serve to influence the sequence of events
that occur during inbound replication when a downstream DC is informed
that changes have occurred to more than one of the partitions it shares
with its upstream partner. The priorities govern which partition it
will deal with first and are not reflected by replica links or their
connection objects. Replica links themselves are simply the result of
connection translation - the process that converts a simple connection
agreement (i.e. a connection object) into something more tangible by
determining which partitions are common to the two DCs on either end of
it.
The config. and schema do indeed follow a single repl. topology (more
typically referred to as the 'Enterprise configuration') and likely do
so because a good reason not to wasn't expressed at the time. As best
as I'm able to infer - this is just another example of a design
decision. If you go looking for an all-encompassing technical
justification, you'll likely be disappointed. Since they are distinct
partitions, however, the capability to separate them remains. Perhaps
Dmitri or Don H. were involved in that decision and have an accurate
recollection? Other similar design decisions have also caused
confusion, for example - if two DCs replicate a domain NC, they will
also replicate the enterprise configuration regardless of whether the
topology's design goals warrant it or not ... this too can be confusing
when trying to justify why the KCC made the decisions it did.
Note that Longhorn's behavior differs here slightly in that the schema
NC's replica link is displayed independently from the config.; I'm
afraid at this stage though, I have nothing further to offer as to the
significance of that.
--
Dean Wells
* Email: limeypride@gmail.com
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Thursday, September 11, 2008 5:28 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
okay.. I get the very important thing about the two.. but isn't that why
replication has priorities.. in the order, schema,
configuration,domain,application ? or does the single link for
schema/configuration automatically combine the first two.. meaning over
the configuration link (which includes the schema).. the schema (if
changed) is always replicated first ? and by combining the config and
schema over 1 link actually this can be forced (by code)
_R
________________________________
From: ActiveDir-owner@mail.activedir.org
[ActiveDir-owner@mail.activedir.org] On Behalf Of Grillenmeier, Guido
[guido.grillenmeier@hp.com]
Sent: Thursday, September 11, 2008 4:14 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Well, for one thing it wouldn't work if it shared it with the domain
partition ;-)
More importantly, the schema NC and config NC are both the key piece of
every DC's configuration in the forest and an inconsistency between the
two N (which you can have by replicating them via separate links) can
have dire consequences.
/Guido
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Thursday, September 11, 2008 8:52 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Is there any reason why it shares the replication link with the config
partition?
_R
________________________________
From: ActiveDir-owner@mail.activedir.org
[ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond
[brian@briandesmond.com]
Sent: Wednesday, September 10, 2008 1:48 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
The schema partition is separate however it replicates with the same
topology as the config partition.
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Wednesday, September 10, 2008 1:58 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Replication Links
Hi All,
I'm looking into replication links (what else to do on a thursday
night).. and found something interesting.. probably nothing.. but who
knows..
When I request the Connection Objects from one server with repadmin, i
get the following result:
Repadmin: running command /showconn against full DC localhost
Base DN: CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL
==== KCC CONNECTION OBJECTS ============================================
Connection --
Connection name : 28e853b9-4c32-4288-87c7-d4b09beaab97
Server DNS name : DC01.ROOTDOMAIN.LOCAL
Server DN name : CN=NTDS
Settings,CN=DC01,CN=Servers,CN=DATACENTER1,CN=Sites,CN=Configuration,DC=
ROOTDOMAIN,DC=LOCA
L
Source: DATACENTER2\DC02
No Failures.
TransportType: IP
options: isGenerated overrideNotifyDefault
ReplicatesNC: CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=DomainDnsZones,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=ForestDnsZones,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
Connection --
Connection name : 3329e0ea-9caa-4fd8-92aa-12605fdf4773
Server DNS name : DC01.ROOTDOMAIN.LOCAL
Server DN name : CN=NTDS
Settings,CN=DC01,CN=Servers,CN=DATACENTER1,CN=Sites,CN=Configuration,DC=
ROOTDOMAIN,DC=LOCA
L
Note that for the replicatesNC.. there is no schema link.. i checked the
other servers, but non of them have that link.. (note this is an
automated connection object created by the KCC)..
Question: Could it be that the schema is actually in the configuration
partition ? The servers are newly built (Demo environment) and do not
show errors with replication..
Roelf
| | | |
| DonH
Posts:21
| | 09/24/2008 1:43 PM |
| Wow, the bat signal goes off twice in one morning.
Anyway, yes, you have it exactly correct. Those two NCs are replicated
everywhere, so they can certainly be replicated over the same topology. We
could have calculated the topology independently for the two, but doing so
offers no benefits. Either the two computed topologies would be identical
(in which case we would have wasted some computing effort), or they'd be
different (in which case we'd need to figure out why they were different,
and whether or not it mattered). It was simpler and easier to just compute
the topology once and use it twice. Sorry if that made repadmin's output
(even more) confusing.
The real question, though, is if schema and config both replicate everywhere
and over the same topology, why didn't we just put them together in the same
NC? The danger is that doing so could lead to a replication deadlock.
Imagine for a moment that someone defines a new class of config object (call
it MyConfig) in the schema, creates a MyConfig object in the config NC, and
then (danger!) adds a comment onto the MyConfig schema definition. We have
two objects that need to replicate (the MyConfig object and the classSchema
object), and the classSchema object, being modified more recently, will
replicate after the MyConfig object. Unfortunately, the receiving DSA will
not be able to understand the MyConfig object (since it is not in that DSA's
schema) and will be unable to apply the replication packet.
With the two NC design we can still replicate in an object whose schema we
don't know, but when that happens the receiving DSA simply cues up an
immediate replication of the schema NC from the DSA giving it the confusing
object. We complete the schema NC replication, and then go back to the
config NC replication, and all is well.
But what, you ask, if some recursively evil person defines a new attribute
(call it Trouble), adds Trouble as a mayHave on attributeSchema (by
modifying the classSchema object that governs attributeSchema), and then
adds a Trouble value on the attributeSchema object that governs Trouble?
Well, then, you're in trouble, and your schema will never replicate again.
We put in safeguards to prevent you from getting into this situation, but I
can't remember how foolproof they were, so don't try it.
Lastly, what if Microsoft itself someday needed a way to expand the
definition of attributeSchema or classSchema? Since I just showed that
doing so could lead straight to a deadlock, how could it be done? To guard
against that I left myself (or my successors, now) a small escape hatch. I
defined an extra attribute in the schema, and allowed it on classSchema and
attributeSchema. It's multi-valued, and I can't remember if it's Unicode or
binary. Anyway, the intent was to be able to use it in name=value format to
record extra information in schema definitions without having to change the
schema definition of a schema definition. Clearly life would have been
easier if we had had XML back then.
I've forgotten the name of the attribute by now (extendedSchemaFlags?
something anodyne like that) but transitory fame and glory await the first
person who takes a peek at classSchema or attributeSchema and finds it.
Don
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Thursday, September 11, 2008 7:26 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
I don't think this is documented really well anywhere so all of this is
simply IMO based on experience and from what I have heard in misc chatter.
Maybe Don or Dmitri will pop along with some more info. Or possibly ~Eric
but I am not sure if ~E has the history on this one.
The schema and config replicate to all DCs so it makes sense to combine them
into the same link; not sure if there is another technical reason. If they
could have different links, the links realistically would likely duplicate
each other anyway as the algorithm to generate their topologies would be the
same. This isn't the case for the Domain NCs (in a multiforest deployment)
or App NCs (possibly ever).
>From a priority standpoint, that isn't about connections... That is about
replication requests. The schema and config replication request priority
values are identical. See the chart I generated from watching replication
with AdQueueLoop for on Slide 45 of Dean and my DEC 2006 presentation (you
can get it from Jadonex.com). Outside of that, if the replication operation
determines there is a differential in the schema, replication will throw a
schema mismatch error, queue a schema replication request (I believe) from
the same source, and complete that replication before allowing any other
replication.
The order in which the repl requests will be queued depends on the tool or
process that queued them, not priorities. The prioritization will float the
schema and config replications to the top of the replication pile. And by
replication pile, there is only one pile, but the intrasite and intersite
replication requests have different priority sets so it is like two logical
piles - you burn through the intrasite requests first and then the
intrasite. See the chart mentioned above. For example, an intrasite Domain
NC replication has a higher priority than an intersite schema replication
request.
There was another note about the schema being contained in the config. This
isn't correct from my understanding. If one was contained in the other, you
would have one replication request for both and replicating the config would
be enough to replicate the schema. They have a hierarchical relationship but
in terms of replication that is simply like a parent/child NC relationship.
You can replicate one without the other (except in the case where the schema
is mismatched and you want to replicate just the config). They are two
complete and separate partitions/NCs.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Thursday, September 11, 2008 7:28 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
okay.. I get the very important thing about the two.. but isn't that why
replication has priorities.. in the order, schema,
configuration,domain,application ? or does the single link for
schema/configuration automatically combine the first two.. meaning over the
configuration link (which includes the schema).. the schema (if changed) is
always replicated first ? and by combining the config and schema over 1 link
actually this can be forced (by code)
_R
_____
From: ActiveDir-owner@mail.activedir.org
[ActiveDir-owner@mail.activedir.org] On Behalf Of Grillenmeier, Guido
[guido.grillenmeier@hp.com]
Sent: Thursday, September 11, 2008 4:14 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Well, for one thing it wouldn't work if it shared it with the domain
partition ;-)
More importantly, the schema NC and config NC are both the key piece of
every DC's configuration in the forest and an inconsistency between the two
N (which you can have by replicating them via separate links) can have dire
consequences.
/Guido
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Thursday, September 11, 2008 8:52 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Is there any reason why it shares the replication link with the config
partition?
_R
_____
From: ActiveDir-owner@mail.activedir.org
[ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond
[brian@briandesmond.com]
Sent: Wednesday, September 10, 2008 1:48 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
The schema partition is separate however it replicates with the same
topology as the config partition.
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Wednesday, September 10, 2008 1:58 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Replication Links
Hi All,
I'm looking into replication links (what else to do on a thursday night)..
and found something interesting.. probably nothing.. but who knows..
When I request the Connection Objects from one server with repadmin, i get
the following result:
Repadmin: running command /showconn against full DC localhost
Base DN: CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL
==== KCC CONNECTION OBJECTS ============================================
Connection --
Connection name : 28e853b9-4c32-4288-87c7-d4b09beaab97
Server DNS name : DC01.ROOTDOMAIN.LOCAL
Server DN name : CN=NTDS
Settings,CN=DC01,CN=Servers,CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOT
DOMAIN,DC=LOCA
L
Source: DATACENTER2\DC02
No Failures.
TransportType: IP
options: isGenerated overrideNotifyDefault
ReplicatesNC: CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=DomainDnsZones,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=ForestDnsZones,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
Connection --
Connection name : 3329e0ea-9caa-4fd8-92aa-12605fdf4773
Server DNS name : DC01.ROOTDOMAIN.LOCAL
Server DN name : CN=NTDS
Settings,CN=DC01,CN=Servers,CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOT
DOMAIN,DC=LOCA
L
Note that for the replicatesNC.. there is no schema link.. i checked the
other servers, but non of them have that link.. (note this is an automated
connection object created by the KCC)..
Question: Could it be that the schema is actually in the configuration
partition ? The servers are newly built (Demo environment) and do not show
errors with replication..
Roelf
| | | |
| bsonposh
Posts:171
| | 09/24/2008 1:43 PM |
| wow <== me acting surprised... who woulda thunk it 
On Thu, Sep 11, 2008 at 11:42 AM, joe <listmail@joeware.net> wrote:
> Yes my old friend, you have gotten very chatty as of late. Gone are the
> cryptic 2 line answers with one of those lines being... "call me"... and the
> other being "because I am not typing anymore"... and now your true verbosity
> shines through....
>
> I wonder why?
>
> http://blog.joeware.net/2008/09/11/1461/
>
>
>
> --
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
>
> ------------------------------
> *From:* ActiveDir-owner@mail.activedir.org [mailto:
> ActiveDir-owner@mail.activedir.org] *On Behalf Of *Dean Wells
> *Sent:* Thursday, September 11, 2008 11:04 AM
>
> *To:* ActiveDir@mail.activedir.org
> *Subject:* RE: [ActiveDir] Replication Links
>
> You only like it 'cause it was loooooooooooooong J
>
>
>
> Seriously though, they are oddly similar in places!
>
> --
> Dean Wells
> * Email: *limeypride@gmail.com*
>
>
>
> *From:* ActiveDir-owner@mail.activedir.org [mailto:
> ActiveDir-owner@mail.activedir.org] *On Behalf Of *joe
> *Sent:* Thursday, September 11, 2008 8:35 AM
> *To:* ActiveDir@mail.activedir.org
> *Subject:* RE: [ActiveDir] Replication Links
>
>
>
> You would almost think we were in the same room when we typed our
> responses... Or at least talking on the phone (unless you know me and
> my purposeful avoidance of anything phone-like).
>
>
>
> Well written Deano.
>
>
>
>
>
> joe
>
>
>
>
>
> --
>
> O'Reilly Active Directory Third Edition -
> http://www.joeware.net/win/ad3e.htm
>
>
>
>
>
>
> ------------------------------
>
> *From:* ActiveDir-owner@mail.activedir.org [mailto:
> ActiveDir-owner@mail.activedir.org] *On Behalf Of *Dean Wells
> *Sent:* Thursday, September 11, 2008 10:11 AM
> *To:* ActiveDir@mail.activedir.org
> *Subject:* RE: [ActiveDir] Replication Links
>
> Perhaps you misinterpret the purpose served by the term replication
> priorities; these priorities serve to influence the sequence of events that
> occur during inbound replication when a downstream DC is informed that
> changes have occurred to more than one of the partitions it shares with its
> upstream partner. The priorities govern which partition it will deal with
> first and are not reflected by replica links or their connection objects.
> Replica links themselves are simply the result of connection translation –
> the process that converts a simple connection agreement (i.e. a connection
> object) into something more tangible by determining which partitions are
> common to the two DCs on either end of it.
>
>
>
> The config. and schema do indeed follow a single repl. topology (more
> typically referred to as the 'Enterprise configuration') and likely do so
> because a good reason not to wasn't expressed at the time. As best as I'm
> able to infer – this is just another example of a design decision. If you
> go looking for an all-encompassing technical justification, you'll likely be
> disappointed. Since they are distinct partitions, however, the capability
> to separate them remains. Perhaps Dmitri or Don H. were involved in that
> decision and have an accurate recollection? Other similar design decisions
> have also caused confusion, for example – if two DCs replicate a domain NC,
> they will also replicate the enterprise configuration regardless of whether
> the topology's design goals warrant it or not … this too can be confusing
> when trying to justify why the KCC made the decisions it did.
>
>
>
> Note that Longhorn's behavior differs here slightly in that the schema NC's
> replica link is displayed independently from the config.; I'm afraid at this
> stage though, I have nothing further to offer as to the significance of
> that.
>
> --
> Dean Wells
> * Email: *limeypride@gmail.com*
>
>
>
> *From:* ActiveDir-owner@mail.activedir.org [mailto:
> ActiveDir-owner@mail.activedir.org] *On Behalf Of *Roelf Zomerman
> *Sent:* Thursday, September 11, 2008 5:28 AM
> *To:* ActiveDir@mail.activedir.org
> *Subject:* RE: [ActiveDir] Replication Links
>
>
>
> okay.. I get the very important thing about the two.. but isn't that why
> replication has priorities.. in the order, schema,
> configuration,domain,application ? or does the single link for
> schema/configuration automatically combine the first two.. meaning over the
> configuration link (which includes the schema).. the schema (if changed) is
> always replicated first ? and by combining the config and schema over 1 link
> actually this can be forced (by code)
>
>
>
> _R
> ------------------------------
>
> *From:* ActiveDir-owner@mail.activedir.org [
> ActiveDir-owner@mail.activedir.org] On Behalf Of Grillenmeier, Guido [
> guido.grillenmeier@hp.com]
> *Sent:* Thursday, September 11, 2008 4:14 AM
> *To:* ActiveDir@mail.activedir.org
> *Subject:* RE: [ActiveDir] Replication Links
>
> Well, for one thing it wouldn't work if it shared it with the domain
> partition ;-)
>
>
>
> More importantly, the schema NC and config NC are both the key piece of
> every DC's configuration in the forest and an inconsistency between the two
> N (which you can have by replicating them via separate links) can have dire
> consequences.
>
>
>
> /Guido
>
>
>
> *From:* ActiveDir-owner@mail.activedir.org [mailto:
> ActiveDir-owner@mail.activedir.org] *On Behalf Of *Roelf Zomerman
> *Sent:* Thursday, September 11, 2008 8:52 AM
> *To:* ActiveDir@mail.activedir.org
> *Subject:* RE: [ActiveDir] Replication Links
>
>
>
> Is there any reason why it shares the replication link with the config
> partition?
>
>
>
> _R
> ------------------------------
>
> *From:* ActiveDir-owner@mail.activedir.org [
> ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond [
> brian@briandesmond.com]
> *Sent:* Wednesday, September 10, 2008 1:48 PM
> *To:* ActiveDir@mail.activedir.org
> *Subject:* RE: [ActiveDir] Replication Links
>
> *The schema partition is separate however it replicates with the same
> topology as the config partition. *
>
>
>
> *Thanks,*
>
> *Brian Desmond*
>
> *brian@briandesmond.com*
>
>
>
> *c - 312.731.3132*
>
>
>
> *From:* ActiveDir-owner@mail.activedir.org [mailto:
> ActiveDir-owner@mail.activedir.org] *On Behalf Of *Roelf Zomerman
> *Sent:* Wednesday, September 10, 2008 1:58 PM
> *To:* ActiveDir@mail.activedir.org
> *Subject:* [ActiveDir] Replication Links
>
>
>
> Hi All,
>
>
>
> I'm looking into replication links (what else to do on a thursday night)..
> and found something interesting.. probably nothing.. but who knows..
>
>
>
> When I request the Connection Objects from one server with repadmin, i get
> the following result:
>
>
>
> Repadmin: running command /showconn against full DC localhost
> Base DN: CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL
> ==== KCC CONNECTION OBJECTS ============================================
> Connection --
> Connection name : 28e853b9-4c32-4288-87c7-d4b09beaab97
> Server DNS name : DC01.ROOTDOMAIN.LOCAL
> Server DN name : CN=NTDS
> Settings,CN=DC01,CN=Servers,CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOTDOMAIN,DC=LOCA
> L
> Source: DATACENTER2\DC02
> No Failures.
> TransportType: IP
> options: isGenerated overrideNotifyDefault
> * ReplicatesNC: CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL*
> Reason: IntersiteTopology
> Replica link has been added.
> * ReplicatesNC: DC=DomainDnsZones,DC=ROOTDOMAIN,DC=LOCAL**
> * Reason: IntersiteTopology
> Replica link has been added.
> * ReplicatesNC: DC=ForestDnsZones,DC=ROOTDOMAIN,DC=LOCAL*
> Reason: IntersiteTopology
> Replica link has been added.
> * ReplicatesNC: DC=ROOTDOMAIN,DC=LOCAL**
> * Reason: IntersiteTopology
> Replica link has been added.
> Connection --
> Connection name : 3329e0ea-9caa-4fd8-92aa-12605fdf4773
> Server DNS name : DC01.ROOTDOMAIN.LOCAL
> Server DN name : CN=NTDS
> Settings,CN=DC01,CN=Servers,CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOTDOMAIN,DC=LOCA
> L
>
>
>
> Note that for the replicatesNC.. there is no schema link.. i checked the
> other servers, but non of them have that link.. (note this is an automated
> connection object created by the KCC)..
>
>
>
> *Question: Could it be that the schema is actually in the configuration
> partition ? The servers are newly built (Demo environment) and do not show
> errors with replication.. *
>
>
>
> Roelf
>
| | | |
| listmail
Posts:440
| | 09/24/2008 1:45 PM |
| Don likes me better. He woo'ed the ActiveDir email system into sending it to
me faster than everyone else. :o)
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Brandon Shell
Sent: Thursday, September 11, 2008 2:56 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] Replication Links
Ditto.. I never received Dons original post.
On Thu, Sep 11, 2008 at 2:39 PM, Dean Wells <limeypride@gmail.com> wrote:
Thanks, great to know!
PS - I'm optimistically going to ask if your memory been further jogged
since posting that regarding the 'escape-hatch' attribute you alluded to?
I'd like to do some digging on that and will likely find it easier with a
specific point of reference; here's hoping .
PPS - I've yet to receive Don's original post. So far, it's only appearing
in the thread beginning with joe's response . anyone else :0/
--
Dean Wells
* Email: limeypride@gmail.com
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Don Hacherl
Sent: Thursday, September 11, 2008 12:19 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Wow, the bat signal goes off twice in one morning.
Anyway, yes, you have it exactly correct. Those two NCs are replicated
everywhere, so they can certainly be replicated over the same topology. We
could have calculated the topology independently for the two, but doing so
offers no benefits. Either the two computed topologies would be identical
(in which case we would have wasted some computing effort), or they'd be
different (in which case we'd need to figure out why they were different,
and whether or not it mattered). It was simpler and easier to just compute
the topology once and use it twice. Sorry if that made repadmin's output
(even more) confusing.
The real question, though, is if schema and config both replicate everywhere
and over the same topology, why didn't we just put them together in the same
NC? The danger is that doing so could lead to a replication deadlock.
Imagine for a moment that someone defines a new class of config object (call
it MyConfig) in the schema, creates a MyConfig object in the config NC, and
then (danger!) adds a comment onto the MyConfig schema definition. We have
two objects that need to replicate (the MyConfig object and the classSchema
object), and the classSchema object, being modified more recently, will
replicate after the MyConfig object. Unfortunately, the receiving DSA will
not be able to understand the MyConfig object (since it is not in that DSA's
schema) and will be unable to apply the replication packet.
With the two NC design we can still replicate in an object whose schema we
don't know, but when that happens the receiving DSA simply cues up an
immediate replication of the schema NC from the DSA giving it the confusing
object. We complete the schema NC replication, and then go back to the
config NC replication, and all is well.
But what, you ask, if some recursively evil person defines a new attribute
(call it Trouble), adds Trouble as a mayHave on attributeSchema (by
modifying the classSchema object that governs attributeSchema), and then
adds a Trouble value on the attributeSchema object that governs Trouble?
Well, then, you're in trouble, and your schema will never replicate again.
We put in safeguards to prevent you from getting into this situation, but I
can't remember how foolproof they were, so don't try it.
Lastly, what if Microsoft itself someday needed a way to expand the
definition of attributeSchema or classSchema? Since I just showed that
doing so could lead straight to a deadlock, how could it be done? To guard
against that I left myself (or my successors, now) a small escape hatch. I
defined an extra attribute in the schema, and allowed it on classSchema and
attributeSchema. It's multi-valued, and I can't remember if it's Unicode or
binary. Anyway, the intent was to be able to use it in name=value format to
record extra information in schema definitions without having to change the
schema definition of a schema definition. Clearly life would have been
easier if we had had XML back then.
I've forgotten the name of the attribute by now (extendedSchemaFlags?
something anodyne like that) but transitory fame and glory await the first
person who takes a peek at classSchema or attributeSchema and finds it.
Don
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Thursday, September 11, 2008 7:26 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
I don't think this is documented really well anywhere so all of this is
simply IMO based on experience and from what I have heard in misc chatter.
Maybe Don or Dmitri will pop along with some more info. Or possibly ~Eric
but I am not sure if ~E has the history on this one.
The schema and config replicate to all DCs so it makes sense to combine them
into the same link; not sure if there is another technical reason. If they
could have different links, the links realistically would likely duplicate
each other anyway as the algorithm to generate their topologies would be the
same. This isn't the case for the Domain NCs (in a multiforest deployment)
or App NCs (possibly ever).
>From a priority standpoint, that isn't about connections... That is about
replication requests. The schema and config replication request priority
values are identical. See the chart I generated from watching replication
with AdQueueLoop for on Slide 45 of Dean and my DEC 2006 presentation (you
can get it from Jadonex.com). Outside of that, if the replication operation
determines there is a differential in the schema, replication will throw a
schema mismatch error, queue a schema replication request (I believe) from
the same source, and complete that replication before allowing any other
replication.
The order in which the repl requests will be queued depends on the tool or
process that queued them, not priorities. The prioritization will float the
schema and config replications to the top of the replication pile. And by
replication pile, there is only one pile, but the intrasite and intersite
replication requests have different priority sets so it is like two logical
piles - you burn through the intrasite requests first and then the
intrasite. See the chart mentioned above. For example, an intrasite Domain
NC replication has a higher priority than an intersite schema replication
request.
There was another note about the schema being contained in the config. This
isn't correct from my understanding. If one was contained in the other, you
would have one replication request for both and replicating the config would
be enough to replicate the schema. They have a hierarchical relationship but
in terms of replication that is simply like a parent/child NC relationship.
You can replicate one without the other (except in the case where the schema
is mismatched and you want to replicate just the config). They are two
complete and separate partitions/NCs.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Thursday, September 11, 2008 7:28 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
okay.. I get the very important thing about the two.. but isn't that why
replication has priorities.. in the order, schema,
configuration,domain,application ? or does the single link for
schema/configuration automatically combine the first two.. meaning over the
configuration link (which includes the schema).. the schema (if changed) is
always replicated first ? and by combining the config and schema over 1 link
actually this can be forced (by code)
_R
_____
From: ActiveDir-owner@mail.activedir.org
[ActiveDir-owner@mail.activedir.org] On Behalf Of Grillenmeier, Guido
[guido.grillenmeier@hp.com]
Sent: Thursday, September 11, 2008 4:14 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Well, for one thing it wouldn't work if it shared it with the domain
partition ;-)
More importantly, the schema NC and config NC are both the key piece of
every DC's configuration in the forest and an inconsistency between the two
N (which you can have by replicating them via separate links) can have dire
consequences.
/Guido
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Thursday, September 11, 2008 8:52 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Is there any reason why it shares the replication link with the config
partition?
_R
_____
From: ActiveDir-owner@mail.activedir.org
[ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond
[brian@briandesmond.com]
Sent: Wednesday, September 10, 2008 1:48 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
The schema partition is separate however it replicates with the same
topology as the config partition.
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Wednesday, September 10, 2008 1:58 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Replication Links
Hi All,
I'm looking into replication links (what else to do on a thursday night)..
and found something interesting.. probably nothing.. but who knows..
When I request the Connection Objects from one server with repadmin, i get
the following result:
Repadmin: running command /showconn against full DC localhost
Base DN: CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL
==== KCC CONNECTION OBJECTS ============================================
Connection --
Connection name : 28e853b9-4c32-4288-87c7-d4b09beaab97
Server DNS name : DC01.ROOTDOMAIN.LOCAL
Server DN name : CN=NTDS
Settings,CN=DC01,CN=Servers,CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOT
DOMAIN,DC=LOCA
L
Source: DATACENTER2\DC02
No Failures.
TransportType: IP
options: isGenerated overrideNotifyDefault
ReplicatesNC: CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=DomainDnsZones,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=ForestDnsZones,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
Connection --
Connection name : 3329e0ea-9caa-4fd8-92aa-12605fdf4773
Server DNS name : DC01.ROOTDOMAIN.LOCAL
Server DN name : CN=NTDS
Settings,CN=DC01,CN=Servers,CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOT
DOMAIN,DC=LOCA
L
Note that for the replicatesNC.. there is no schema link.. i checked the
other servers, but non of them have that link.. (note this is an automated
connection object created by the KCC)..
Question: Could it be that the schema is actually in the configuration
partition ? The servers are newly built (Demo environment) and do not show
errors with replication..
Roelf
| | | |
| Parzival
Posts:38
| | 09/24/2008 1:45 PM |
| I can say nore more but what a clear answer.. and unclear answer., but that probably to blaim on my slow learning brain.. I had to read the 2nd part for like 3 time, before I get to start to understand.. perhaps joe or someone else can present it during DEC (or new name equivalent).. and clear it up even more
But I understood the first part completely.. and another question raises in my mind.. What if I'm in a crisis scenario .. say the exam of the MCM program and I disable the KCC and need to manually define my replication. For the schema replication do I need to manually add a link, or would adding a link for the configuration partition be enough to automatically also replicate the schema over that link.. sayin:g is the KCC so smart to combine the two or is the replication mechanism so smart to combine the two..
PS: If I really stretch the boundaries of the community here.. I probably can wait till DEC and ask it offline
But for so far.. thanks for the answer!
_R
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Don Hacherl
Sent: Thursday, September 11, 2008 6:19 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Wow, the bat signal goes off twice in one morning.
Anyway, yes, you have it exactly correct. Those two NCs are replicated everywhere, so they can certainly be replicated over the same topology. We could have calculated the topology independently for the two, but doing so offers no benefits. Either the two computed topologies would be identical (in which case we would have wasted some computing effort), or they'd be different (in which case we'd need to figure out why they were different, and whether or not it mattered). It was simpler and easier to just compute the topology once and use it twice. Sorry if that made repadmin's output (even more) confusing.
The real question, though, is if schema and config both replicate everywhere and over the same topology, why didn't we just put them together in the same NC? The danger is that doing so could lead to a replication deadlock. Imagine for a moment that someone defines a new class of config object (call it MyConfig) in the schema, creates a MyConfig object in the config NC, and then (danger!) adds a comment onto the MyConfig schema definition. We have two objects that need to replicate (the MyConfig object and the classSchema object), and the classSchema object, being modified more recently, will replicate after the MyConfig object. Unfortunately, the receiving DSA will not be able to understand the MyConfig object (since it is not in that DSA's schema) and will be unable to apply the replication packet.
With the two NC design we can still replicate in an object whose schema we don't know, but when that happens the receiving DSA simply cues up an immediate replication of the schema NC from the DSA giving it the confusing object. We complete the schema NC replication, and then go back to the config NC replication, and all is well.
But what, you ask, if some recursively evil person defines a new attribute (call it Trouble), adds Trouble as a mayHave on attributeSchema (by modifying the classSchema object that governs attributeSchema), and then adds a Trouble value on the attributeSchema object that governs Trouble? Well, then, you're in trouble, and your schema will never replicate again. We put in safeguards to prevent you from getting into this situation, but I can't remember how foolproof they were, so don't try it.
Lastly, what if Microsoft itself someday needed a way to expand the definition of attributeSchema or classSchema? Since I just showed that doing so could lead straight to a deadlock, how could it be done? To guard against that I left myself (or my successors, now) a small escape hatch. I defined an extra attribute in the schema, and allowed it on classSchema and attributeSchema. It's multi-valued, and I can't remember if it's Unicode or binary. Anyway, the intent was to be able to use it in name=value format to record extra information in schema definitions without having to change the schema definition of a schema definition. Clearly life would have been easier if we had had XML back then.
I've forgotten the name of the attribute by now (extendedSchemaFlags? something anodyne like that) but transitory fame and glory await the first person who takes a peek at classSchema or attributeSchema and finds it.
Don
________________________________
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Thursday, September 11, 2008 7:26 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
I don't think this is documented really well anywhere so all of this is simply IMO based on experience and from what I have heard in misc chatter. Maybe Don or Dmitri will pop along with some more info. Or possibly ~Eric but I am not sure if ~E has the history on this one.
The schema and config replicate to all DCs so it makes sense to combine them into the same link; not sure if there is another technical reason. If they could have different links, the links realistically would likely duplicate each other anyway as the algorithm to generate their topologies would be the same. This isn't the case for the Domain NCs (in a multiforest deployment) or App NCs (possibly ever).
>From a priority standpoint, that isn't about connections... That is about replication requests. The schema and config replication request priority values are identical. See the chart I generated from watching replication with AdQueueLoop for on Slide 45 of Dean and my DEC 2006 presentation (you can get it from Jadonex.com). Outside of that, if the replication operation determines there is a differential in the schema, replication will throw a schema mismatch error, queue a schema replication request (I believe) from the same source, and complete that replication before allowing any other replication.
The order in which the repl requests will be queued depends on the tool or process that queued them, not priorities. The prioritization will float the schema and config replications to the top of the replication pile. And by replication pile, there is only one pile, but the intrasite and intersite replication requests have different priority sets so it is like two logical piles - you burn through the intrasite requests first and then the intrasite. See the chart mentioned above. For example, an intrasite Domain NC replication has a higher priority than an intersite schema replication request.
There was another note about the schema being contained in the config. This isn't correct from my understanding. If one was contained in the other, you would have one replication request for both and replicating the config would be enough to replicate the schema. They have a hierarchical relationship but in terms of replication that is simply like a parent/child NC relationship. You can replicate one without the other (except in the case where the schema is mismatched and you want to replicate just the config). They are two complete and separate partitions/NCs.
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
________________________________
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Thursday, September 11, 2008 7:28 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
okay.. I get the very important thing about the two.. but isn't that why replication has priorities.. in the order, schema, configuration,domain,application ? or does the single link for schema/configuration automatically combine the first two.. meaning over the configuration link (which includes the schema).. the schema (if changed) is always replicated first ? and by combining the config and schema over 1 link actually this can be forced (by code)
_R
________________________________
From: ActiveDir-owner@mail.activedir.org [ActiveDir-owner@mail.activedir.org] On Behalf Of Grillenmeier, Guido [guido.grillenmeier@hp.com]
Sent: Thursday, September 11, 2008 4:14 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Well, for one thing it wouldn't work if it shared it with the domain partition ;-)
More importantly, the schema NC and config NC are both the key piece of every DC's configuration in the forest and an inconsistency between the two N (which you can have by replicating them via separate links) can have dire consequences.
/Guido
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Thursday, September 11, 2008 8:52 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Is there any reason why it shares the replication link with the config partition?
_R
________________________________
From: ActiveDir-owner@mail.activedir.org [ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond [brian@briandesmond.com]
Sent: Wednesday, September 10, 2008 1:48 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
The schema partition is separate however it replicates with the same topology as the config partition.
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Wednesday, September 10, 2008 1:58 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Replication Links
Hi All,
I'm looking into replication links (what else to do on a thursday night).. and found something interesting.. probably nothing.. but who knows..
When I request the Connection Objects from one server with repadmin, i get the following result:
Repadmin: running command /showconn against full DC localhost
Base DN: CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL
==== KCC CONNECTION OBJECTS ============================================
Connection --
Connection name : 28e853b9-4c32-4288-87c7-d4b09beaab97
Server DNS name : DC01.ROOTDOMAIN.LOCAL
Server DN name : CN=NTDS Settings,CN=DC01,CN=Servers,CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOTDOMAIN,DC=LOCA
L
Source: DATACENTER2\DC02
No Failures.
TransportType: IP
options: isGenerated overrideNotifyDefault
ReplicatesNC: CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=DomainDnsZones,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=ForestDnsZones,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
Connection --
Connection name : 3329e0ea-9caa-4fd8-92aa-12605fdf4773
Server DNS name : DC01.ROOTDOMAIN.LOCAL
Server DN name : CN=NTDS Settings,CN=DC01,CN=Servers,CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOTDOMAIN,DC=LOCA
L
Note that for the replicatesNC.. there is no schema link.. i checked the other servers, but non of them have that link.. (note this is an automated connection object created by the KCC)..
Question: Could it be that the schema is actually in the configuration partition ? The servers are newly built (Demo environment) and do not show errors with replication..
Roelf
| | | |
| GuidoG
Posts:58
| | 09/24/2008 1:47 PM |
| "But what, you ask, if some recursively evil person defines a new attribute (call it Trouble), adds Trouble as a mayHave on attributeSchema (by modifying the classSchema object that governs attributeSchema), and then adds a Trouble value on the attributeSchema object that governs Trouble? Well, then, you're in trouble, and your schema will never replicate again." Ώ]
I just LOVED this ;-))
Thanks Don!
/Guido
Ώ] Guess I'll have to test those safeguards in my test-lab...
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Don Hacherl
Sent: Thursday, September 11, 2008 6:19 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Wow, the bat signal goes off twice in one morning.
Anyway, yes, you have it exactly correct. Those two NCs are replicated everywhere, so they can certainly be replicated over the same topology. We could have calculated the topology independently for the two, but doing so offers no benefits. Either the two computed topologies would be identical (in which case we would have wasted some computing effort), or they'd be different (in which case we'd need to figure out why they were different, and whether or not it mattered). It was simpler and easier to just compute the topology once and use it twice. Sorry if that made repadmin's output (even more) confusing.
The real question, though, is if schema and config both replicate everywhere and over the same topology, why didn't we just put them together in the same NC? The danger is that doing so could lead to a replication deadlock. Imagine for a moment that someone defines a new class of config object (call it MyConfig) in the schema, creates a MyConfig object in the config NC, and then (danger!) adds a comment onto the MyConfig schema definition. We have two objects that need to replicate (the MyConfig object and the classSchema object), and the classSchema object, being modified more recently, will replicate after the MyConfig object. Unfortunately, the receiving DSA will not be able to understand the MyConfig object (since it is not in that DSA's schema) and will be unable to apply the replication packet.
With the two NC design we can still replicate in an object whose schema we don't know, but when that happens the receiving DSA simply cues up an immediate replication of the schema NC from the DSA giving it the confusing object. We complete the schema NC replication, and then go back to the config NC replication, and all is well.
But what, you ask, if some recursively evil person defines a new attribute (call it Trouble), adds Trouble as a mayHave on attributeSchema (by modifying the classSchema object that governs attributeSchema), and then adds a Trouble value on the attributeSchema object that governs Trouble? Well, then, you're in trouble, and your schema will never replicate again. We put in safeguards to prevent you from getting into this situation, but I can't remember how foolproof they were, so don't try it.
Lastly, what if Microsoft itself someday needed a way to expand the definition of attributeSchema or classSchema? Since I just showed that doing so could lead straight to a deadlock, how could it be done? To guard against that I left myself (or my successors, now) a small escape hatch. I defined an extra attribute in the schema, and allowed it on classSchema and attributeSchema. It's multi-valued, and I can't remember if it's Unicode or binary. Anyway, the intent was to be able to use it in name=value format to record extra information in schema definitions without having to change the schema definition of a schema definition. Clearly life would have been easier if we had had XML back then.
I've forgotten the name of the attribute by now (extendedSchemaFlags? something anodyne like that) but transitory fame and glory await the first person who takes a peek at classSchema or attributeSchema and finds it.
Don
________________________________
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Thursday, September 11, 2008 7:26 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
I don't think this is documented really well anywhere so all of this is simply IMO based on experience and from what I have heard in misc chatter. Maybe Don or Dmitri will pop along with some more info. Or possibly ~Eric but I am not sure if ~E has the history on this one.
The schema and config replicate to all DCs so it makes sense to combine them into the same link; not sure if there is another technical reason. If they could have different links, the links realistically would likely duplicate each other anyway as the algorithm to generate their topologies would be the same. This isn't the case for the Domain NCs (in a multiforest deployment) or App NCs (possibly ever).
>From a priority standpoint, that isn't about connections... That is about replication requests. The schema and config replication request priority values are identical. See the chart I generated from watching replication with AdQueueLoop for on Slide 45 of Dean and my DEC 2006 presentation (you can get it from Jadonex.com). Outside of that, if the replication operation determines there is a differential in the schema, replication will throw a schema mismatch error, queue a schema replication request (I believe) from the same source, and complete that replication before allowing any other replication.
The order in which the repl requests will be queued depends on the tool or process that queued them, not priorities. The prioritization will float the schema and config replications to the top of the replication pile. And by replication pile, there is only one pile, but the intrasite and intersite replication requests have different priority sets so it is like two logical piles - you burn through the intrasite requests first and then the intrasite. See the chart mentioned above. For example, an intrasite Domain NC replication has a higher priority than an intersite schema replication request.
There was another note about the schema being contained in the config. This isn't correct from my understanding. If one was contained in the other, you would have one replication request for both and replicating the config would be enough to replicate the schema. They have a hierarchical relationship but in terms of replication that is simply like a parent/child NC relationship. You can replicate one without the other (except in the case where the schema is mismatched and you want to replicate just the config). They are two complete and separate partitions/NCs.
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
________________________________
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Thursday, September 11, 2008 7:28 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
okay.. I get the very important thing about the two.. but isn't that why replication has priorities.. in the order, schema, configuration,domain,application ? or does the single link for schema/configuration automatically combine the first two.. meaning over the configuration link (which includes the schema).. the schema (if changed) is always replicated first ? and by combining the config and schema over 1 link actually this can be forced (by code)
_R
________________________________
From: ActiveDir-owner@mail.activedir.org [ActiveDir-owner@mail.activedir.org] On Behalf Of Grillenmeier, Guido [guido.grillenmeier@hp.com]
Sent: Thursday, September 11, 2008 4:14 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Well, for one thing it wouldn't work if it shared it with the domain partition ;-)
More importantly, the schema NC and config NC are both the key piece of every DC's configuration in the forest and an inconsistency between the two N (which you can have by replicating them via separate links) can have dire consequences.
/Guido
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Thursday, September 11, 2008 8:52 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Is there any reason why it shares the replication link with the config partition?
_R
________________________________
From: ActiveDir-owner@mail.activedir.org [ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond [brian@briandesmond.com]
Sent: Wednesday, September 10, 2008 1:48 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
The schema partition is separate however it replicates with the same topology as the config partition.
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Wednesday, September 10, 2008 1:58 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Replication Links
Hi All,
I'm looking into replication links (what else to do on a thursday night).. and found something interesting.. probably nothing.. but who knows..
When I request the Connection Objects from one server with repadmin, i get the following result:
Repadmin: running command /showconn against full DC localhost
Base DN: CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL
==== KCC CONNECTION OBJECTS ============================================
Connection --
Connection name : 28e853b9-4c32-4288-87c7-d4b09beaab97
Server DNS name : DC01.ROOTDOMAIN.LOCAL
Server DN name : CN=NTDS Settings,CN=DC01,CN=Servers,CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOTDOMAIN,DC=LOCA
L
Source: DATACENTER2\DC02
No Failures.
TransportType: IP
options: isGenerated overrideNotifyDefault
ReplicatesNC: CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=DomainDnsZones,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=ForestDnsZones,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
Connection --
Connection name : 3329e0ea-9caa-4fd8-92aa-12605fdf4773
Server DNS name : DC01.ROOTDOMAIN.LOCAL
Server DN name : CN=NTDS Settings,CN=DC01,CN=Servers,CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOTDOMAIN,DC=LOCA
L
Note that for the replicatesNC.. there is no schema link.. i checked the other servers, but non of them have that link.. (note this is an automated connection object created by the KCC)..
Question: Could it be that the schema is actually in the configuration partition ? The servers are newly built (Demo environment) and do not show errors with replication..
Roelf
| | | |
| dwells
Posts:39
| | 09/24/2008 1:47 PM |
| Lab? You big girl - c'mon man, HP have a forest begging for a rebuild . and
I thought you were supposed to the "D.R." guy - wimp! J
Teasing of course Guido . but perhaps solutions exist even in this nightmare
of a situation (some quite scary in terms of effort/potential scale though.)
The potential issue Don manufactured seems to be caused by the circular
dependency between the definition of 'trouble' and the fact that that
definition employs 'trouble' as part of its makeup. Regular replication is
almost certainly incapable of getting both the chicken and its egg in-place
at the same time - thus the deadlock. A few workarounds springs to mind -
1. remove 'trouble' from its attributeSchema definition
a. I doubt the schema-devil would be necessary here (but it's possibly
of use)since this is all hearsay until someone like Guido tests it J
2. retire the offending schema FSMO, metadata clean it and seize the
role
3. demote every other DC in the forest (you'll possibly hit a wall or
two here on a few DCs while replicating changes off so force removal may
also be a requirement), metadata clean everyone else and re-promote them all
using an IFM taken from the polluted schema FSMO
. that's all I can think of for now.
--
Dean Wells
* Email: limeypride@gmail.com
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Grillenmeier, Guido
Sent: Thursday, September 11, 2008 2:00 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
"But what, you ask, if some recursively evil person defines a new attribute
(call it Trouble), adds Trouble as a mayHave on attributeSchema (by
modifying the classSchema object that governs attributeSchema), and then
adds a Trouble value on the attributeSchema object that governs Trouble?
Well, then, you're in trouble, and your schema will never replicate again."
Ώ]
I just LOVED this ;-))
Thanks Don!
/Guido
Ώ] Guess I'll have to test those safeguards in my test-lab.
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Don Hacherl
Sent: Thursday, September 11, 2008 6:19 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Wow, the bat signal goes off twice in one morning.
Anyway, yes, you have it exactly correct. Those two NCs are replicated
everywhere, so they can certainly be replicated over the same topology. We
could have calculated the topology independently for the two, but doing so
offers no benefits. Either the two computed topologies would be identical
(in which case we would have wasted some computing effort), or they'd be
different (in which case we'd need to figure out why they were different,
and whether or not it mattered). It was simpler and easier to just compute
the topology once and use it twice. Sorry if that made repadmin's output
(even more) confusing.
The real question, though, is if schema and config both replicate everywhere
and over the same topology, why didn't we just put them together in the same
NC? The danger is that doing so could lead to a replication deadlock.
Imagine for a moment that someone defines a new class of config object (call
it MyConfig) in the schema, creates a MyConfig object in the config NC, and
then (danger!) adds a comment onto the MyConfig schema definition. We have
two objects that need to replicate (the MyConfig object and the classSchema
object), and the classSchema object, being modified more recently, will
replicate after the MyConfig object. Unfortunately, the receiving DSA will
not be able to understand the MyConfig object (since it is not in that DSA's
schema) and will be unable to apply the replication packet.
With the two NC design we can still replicate in an object whose schema we
don't know, but when that happens the receiving DSA simply cues up an
immediate replication of the schema NC from the DSA giving it the confusing
object. We complete the schema NC replication, and then go back to the
config NC replication, and all is well.
But what, you ask, if some recursively evil person defines a new attribute
(call it Trouble), adds Trouble as a mayHave on attributeSchema (by
modifying the classSchema object that governs attributeSchema), and then
adds a Trouble value on the attributeSchema object that governs Trouble?
Well, then, you're in trouble, and your schema will never replicate again.
We put in safeguards to prevent you from getting into this situation, but I
can't remember how foolproof they were, so don't try it.
Lastly, what if Microsoft itself someday needed a way to expand the
definition of attributeSchema or classSchema? Since I just showed that
doing so could lead straight to a deadlock, how could it be done? To guard
against that I left myself (or my successors, now) a small escape hatch. I
defined an extra attribute in the schema, and allowed it on classSchema and
attributeSchema. It's multi-valued, and I can't remember if it's Unicode or
binary. Anyway, the intent was to be able to use it in name=value format to
record extra information in schema definitions without having to change the
schema definition of a schema definition. Clearly life would have been
easier if we had had XML back then.
I've forgotten the name of the attribute by now (extendedSchemaFlags?
something anodyne like that) but transitory fame and glory await the first
person who takes a peek at classSchema or attributeSchema and finds it.
Don
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Thursday, September 11, 2008 7:26 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
I don't think this is documented really well anywhere so all of this is
simply IMO based on experience and from what I have heard in misc chatter.
Maybe Don or Dmitri will pop along with some more info. Or possibly ~Eric
but I am not sure if ~E has the history on this one.
The schema and config replicate to all DCs so it makes sense to combine them
into the same link; not sure if there is another technical reason. If they
could have different links, the links realistically would likely duplicate
each other anyway as the algorithm to generate their topologies would be the
same. This isn't the case for the Domain NCs (in a multiforest deployment)
or App NCs (possibly ever).
>From a priority standpoint, that isn't about connections... That is about
replication requests. The schema and config replication request priority
values are identical. See the chart I generated from watching replication
with AdQueueLoop for on Slide 45 of Dean and my DEC 2006 presentation (you
can get it from Jadonex.com). Outside of that, if the replication operation
determines there is a differential in the schema, replication will throw a
schema mismatch error, queue a schema replication request (I believe) from
the same source, and complete that replication before allowing any other
replication.
The order in which the repl requests will be queued depends on the tool or
process that queued them, not priorities. The prioritization will float the
schema and config replications to the top of the replication pile. And by
replication pile, there is only one pile, but the intrasite and intersite
replication requests have different priority sets so it is like two logical
piles - you burn through the intrasite requests first and then the
intrasite. See the chart mentioned above. For example, an intrasite Domain
NC replication has a higher priority than an intersite schema replication
request.
There was another note about the schema being contained in the config. This
isn't correct from my understanding. If one was contained in the other, you
would have one replication request for both and replicating the config would
be enough to replicate the schema. They have a hierarchical relationship but
in terms of replication that is simply like a parent/child NC relationship.
You can replicate one without the other (except in the case where the schema
is mismatched and you want to replicate just the config). They are two
complete and separate partitions/NCs.
joe
--
O'Reilly Active Directory Third Edition -
http://www.joeware.net/win/ad3e.htm
_____
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Thursday, September 11, 2008 7:28 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
okay.. I get the very important thing about the two.. but isn't that why
replication has priorities.. in the order, schema,
configuration,domain,application ? or does the single link for
schema/configuration automatically combine the first two.. meaning over the
configuration link (which includes the schema).. the schema (if changed) is
always replicated first ? and by combining the config and schema over 1 link
actually this can be forced (by code)
_R
_____
From: ActiveDir-owner@mail.activedir.org
[ActiveDir-owner@mail.activedir.org] On Behalf Of Grillenmeier, Guido
[guido.grillenmeier@hp.com]
Sent: Thursday, September 11, 2008 4:14 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Well, for one thing it wouldn't work if it shared it with the domain
partition ;-)
More importantly, the schema NC and config NC are both the key piece of
every DC's configuration in the forest and an inconsistency between the two
N (which you can have by replicating them via separate links) can have dire
consequences.
/Guido
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Thursday, September 11, 2008 8:52 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Is there any reason why it shares the replication link with the config
partition?
_R
_____
From: ActiveDir-owner@mail.activedir.org
[ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond
[brian@briandesmond.com]
Sent: Wednesday, September 10, 2008 1:48 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
The schema partition is separate however it replicates with the same
topology as the config partition.
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
From: ActiveDir-owner@mail.activedir.org
[mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Wednesday, September 10, 2008 1:58 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Replication Links
Hi All,
I'm looking into replication links (what else to do on a thursday night)..
and found something interesting.. probably nothing.. but who knows..
When I request the Connection Objects from one server with repadmin, i get
the following result:
Repadmin: running command /showconn against full DC localhost
Base DN: CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL
==== KCC CONNECTION OBJECTS ============================================
Connection --
Connection name : 28e853b9-4c32-4288-87c7-d4b09beaab97
Server DNS name : DC01.ROOTDOMAIN.LOCAL
Server DN name : CN=NTDS
Settings,CN=DC01,CN=Servers,CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOT
DOMAIN,DC=LOCA
L
Source: DATACENTER2\DC02
No Failures.
TransportType: IP
options: isGenerated overrideNotifyDefault
ReplicatesNC: CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=DomainDnsZones,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=ForestDnsZones,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
Connection --
Connection name : 3329e0ea-9caa-4fd8-92aa-12605fdf4773
Server DNS name : DC01.ROOTDOMAIN.LOCAL
Server DN name : CN=NTDS
Settings,CN=DC01,CN=Servers,CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOT
DOMAIN,DC=LOCA
L
Note that for the replicatesNC.. there is no schema link.. i checked the
other servers, but non of them have that link.. (note this is an automated
connection object created by the KCC)..
Question: Could it be that the schema is actually in the configuration
partition ? The servers are newly built (Demo environment) and do not show
errors with replication..
Roelf
| | | |
| WBoyd
Posts:2
| | 09/24/2008 1:51 PM |
| I see test questions<vbEg>.
Walter Boyd
Senior Program Manager
Directory Technologies Master Program
Directory Ranger Program
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Grillenmeier, Guido
Sent: Thursday, September 11, 2008 4:00 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
"But what, you ask, if some recursively evil person defines a new attribute (call it Trouble), adds Trouble as a mayHave on attributeSchema (by modifying the classSchema object that governs attributeSchema), and then adds a Trouble value on the attributeSchema object that governs Trouble? Well, then, you're in trouble, and your schema will never replicate again." Ώ]
I just LOVED this ;-))
Thanks Don!
/Guido
Ώ] Guess I'll have to test those safeguards in my test-lab...
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Don Hacherl
Sent: Thursday, September 11, 2008 6:19 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Wow, the bat signal goes off twice in one morning.
Anyway, yes, you have it exactly correct. Those two NCs are replicated everywhere, so they can certainly be replicated over the same topology. We could have calculated the topology independently for the two, but doing so offers no benefits. Either the two computed topologies would be identical (in which case we would have wasted some computing effort), or they'd be different (in which case we'd need to figure out why they were different, and whether or not it mattered). It was simpler and easier to just compute the topology once and use it twice. Sorry if that made repadmin's output (even more) confusing.
The real question, though, is if schema and config both replicate everywhere and over the same topology, why didn't we just put them together in the same NC? The danger is that doing so could lead to a replication deadlock. Imagine for a moment that someone defines a new class of config object (call it MyConfig) in the schema, creates a MyConfig object in the config NC, and then (danger!) adds a comment onto the MyConfig schema definition. We have two objects that need to replicate (the MyConfig object and the classSchema object), and the classSchema object, being modified more recently, will replicate after the MyConfig object. Unfortunately, the receiving DSA will not be able to understand the MyConfig object (since it is not in that DSA's schema) and will be unable to apply the replication packet.
With the two NC design we can still replicate in an object whose schema we don't know, but when that happens the receiving DSA simply cues up an immediate replication of the schema NC from the DSA giving it the confusing object. We complete the schema NC replication, and then go back to the config NC replication, and all is well.
But what, you ask, if some recursively evil person defines a new attribute (call it Trouble), adds Trouble as a mayHave on attributeSchema (by modifying the classSchema object that governs attributeSchema), and then adds a Trouble value on the attributeSchema object that governs Trouble? Well, then, you're in trouble, and your schema will never replicate again. We put in safeguards to prevent you from getting into this situation, but I can't remember how foolproof they were, so don't try it.
Lastly, what if Microsoft itself someday needed a way to expand the definition of attributeSchema or classSchema? Since I just showed that doing so could lead straight to a deadlock, how could it be done? To guard against that I left myself (or my successors, now) a small escape hatch. I defined an extra attribute in the schema, and allowed it on classSchema and attributeSchema. It's multi-valued, and I can't remember if it's Unicode or binary. Anyway, the intent was to be able to use it in name=value format to record extra information in schema definitions without having to change the schema definition of a schema definition. Clearly life would have been easier if we had had XML back then.
I've forgotten the name of the attribute by now (extendedSchemaFlags? something anodyne like that) but transitory fame and glory await the first person who takes a peek at classSchema or attributeSchema and finds it.
Don
________________________________
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of joe
Sent: Thursday, September 11, 2008 7:26 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
I don't think this is documented really well anywhere so all of this is simply IMO based on experience and from what I have heard in misc chatter. Maybe Don or Dmitri will pop along with some more info. Or possibly ~Eric but I am not sure if ~E has the history on this one.
The schema and config replicate to all DCs so it makes sense to combine them into the same link; not sure if there is another technical reason. If they could have different links, the links realistically would likely duplicate each other anyway as the algorithm to generate their topologies would be the same. This isn't the case for the Domain NCs (in a multiforest deployment) or App NCs (possibly ever).
>From a priority standpoint, that isn't about connections... That is about replication requests. The schema and config replication request priority values are identical. See the chart I generated from watching replication with AdQueueLoop for on Slide 45 of Dean and my DEC 2006 presentation (you can get it from Jadonex.com). Outside of that, if the replication operation determines there is a differential in the schema, replication will throw a schema mismatch error, queue a schema replication request (I believe) from the same source, and complete that replication before allowing any other replication.
The order in which the repl requests will be queued depends on the tool or process that queued them, not priorities. The prioritization will float the schema and config replications to the top of the replication pile. And by replication pile, there is only one pile, but the intrasite and intersite replication requests have different priority sets so it is like two logical piles - you burn through the intrasite requests first and then the intrasite. See the chart mentioned above. For example, an intrasite Domain NC replication has a higher priority than an intersite schema replication request.
There was another note about the schema being contained in the config. This isn't correct from my understanding. If one was contained in the other, you would have one replication request for both and replicating the config would be enough to replicate the schema. They have a hierarchical relationship but in terms of replication that is simply like a parent/child NC relationship. You can replicate one without the other (except in the case where the schema is mismatched and you want to replicate just the config). They are two complete and separate partitions/NCs.
joe
--
O'Reilly Active Directory Third Edition - http://www.joeware.net/win/ad3e.htm
________________________________
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Thursday, September 11, 2008 7:28 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
okay.. I get the very important thing about the two.. but isn't that why replication has priorities.. in the order, schema, configuration,domain,application ? or does the single link for schema/configuration automatically combine the first two.. meaning over the configuration link (which includes the schema).. the schema (if changed) is always replicated first ? and by combining the config and schema over 1 link actually this can be forced (by code)
_R
________________________________
From: ActiveDir-owner@mail.activedir.org [ActiveDir-owner@mail.activedir.org] On Behalf Of Grillenmeier, Guido [guido.grillenmeier@hp.com]
Sent: Thursday, September 11, 2008 4:14 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Well, for one thing it wouldn't work if it shared it with the domain partition ;-)
More importantly, the schema NC and config NC are both the key piece of every DC's configuration in the forest and an inconsistency between the two N (which you can have by replicating them via separate links) can have dire consequences.
/Guido
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Thursday, September 11, 2008 8:52 AM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
Is there any reason why it shares the replication link with the config partition?
_R
________________________________
From: ActiveDir-owner@mail.activedir.org [ActiveDir-owner@mail.activedir.org] On Behalf Of Brian Desmond [brian@briandesmond.com]
Sent: Wednesday, September 10, 2008 1:48 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Replication Links
The schema partition is separate however it replicates with the same topology as the config partition.
Thanks,
Brian Desmond
brian@briandesmond.com
c - 312.731.3132
From: ActiveDir-owner@mail.activedir.org [mailto:ActiveDir-owner@mail.activedir.org] On Behalf Of Roelf Zomerman
Sent: Wednesday, September 10, 2008 1:58 PM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Replication Links
Hi All,
I'm looking into replication links (what else to do on a thursday night).. and found something interesting.. probably nothing.. but who knows..
When I request the Connection Objects from one server with repadmin, i get the following result:
Repadmin: running command /showconn against full DC localhost
Base DN: CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL
==== KCC CONNECTION OBJECTS ============================================
Connection --
Connection name : 28e853b9-4c32-4288-87c7-d4b09beaab97
Server DNS name : DC01.ROOTDOMAIN.LOCAL
Server DN name : CN=NTDS Settings,CN=DC01,CN=Servers,CN=DATACENTER1,CN=Sites,CN=Configuration,DC=ROOTDOMAIN,DC=LOCA
L
Source: DATACENTER2\DC02
No Failures.
TransportType: IP
options: isGenerated overrideNotifyDefault
ReplicatesNC: CN=Configuration,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=DomainDnsZones,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=ForestDnsZones,DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
ReplicatesNC: DC=ROOTDOMAIN,DC=LOCAL
Reason: IntersiteTopology
Replica link has been added.
Connection --
Connection name : 3329e0ea-9caa-4fd8-92aa-12605fdf4773
Server DNS name : DC01.ROO |
|
|