Hi,
Everything that you've mentioned, I've managed to grasp. Likewise, I've
seen most of the available documentation on RODC and KCC including the
ones you've posted.
If the local site color is white or number of colored vertices is less than
two, KCC does not need to build spanning tree for that NC.
This check for a white vertex evidently happens in CreateConnections of
ADTS 6.2.2.3.4.5. This means, as it describes, that the topology does
not need to be computed. However, if the RODC does not compute the
topology, it doesn't explain how the inbound connection objects it needs
are created when its in its own site. At least from the KCC, all the
regular DC see the RODC as invisible (Why doesn't the KCC on writable
domain controllers try to build connections from an RODC? on
https://technet.microsoft.com/en-us/library/cc754956%28v=ws.10%29.aspx).
Is the connection creation outside of the KCC? The only thing I know for
certain that a KCC on an RODC does is update the FRS connection to point
at the same place as the DRS connection. But the description itself
obviously has checks to imply otherwise. Notably when it is in its own
site, according to ADTS 6.2.2.3.1 RODC apparently acts as an
intersite-topology generator for itself. Following the guidelines for
"is present", every indication seems to show that all the NC replicas on
the RODC satisfy these conditions. However, it seems irrelevant since
the KCC never gets far enough to use this value - again with the RODC
being invisible to everyone but itself.
Cheers,
Garming Sam
Either the local site does not host this NC, or the spanning tree would not
have any edge. In either case, we do not need to compute the topology. KCC
moves to the next NC in the list.
Recall that vertex initialization sets the color to ‘white’. The colored
vertices are sites which contain a writeable or partial replica of the NC
specified by CrossRef. Sites which contain at least one writeable replica are
considered 'red' vertices. Sites which contain at least one partial replica but
no writeable replicas are considered 'black' vertices. All other sites are
considered 'white' vertices as marked during initialization, and are not
colored.
Please take a look at the following references, including the non-MS-ADTS ones,
they may be useful.
MS-ADTS 6.2.2 Overview
https://msdn.microsoft.com/en-us/library/cc223797.aspx
. . .
To simplify the task descriptions, the following concepts are used:
• An NC replica that "is present" on a DC. Given NC replica r of NC n and a DC with
nTDSDSA object o, r "is present" on the DC if both of the following conditions is true:
o o!hasMasterNCs contains n or o!msDS-hasFullReplicaNCs contains n or
o!hasPartialReplicaNCs contains n.
o One of the following two conditions is true:
o!msDS-HasInstantiatedNCs contains no value v where the dsname portion
of v = n. (In this case n is in the process of being instantiated.)
o!msDS-HasInstantiatedNCs contains a value v, where the dsname part of
v = n, and the binary part of v (DWORD in big-endian byte order) is an integer
such that the IT_NC_GOING bit is clear. (In this case n is instantiated, and is
not in the process of being uninstantiated.)
• An NC replica that "should be present" on a DC. Given NC replica r of NC n and a
DC with nTDSDSA object o, r "should be present" on the DC if r is one of the following:
o A writable replica of the config NC, the schema NC, or the DC's default
NC on a writable DC.
o A full read-only replica of the config NC, the schema NC, or the DC's
default NC on an RODC.
o A writable replica of an application NC for which there exists a
crossRef object cr such that cr!nCName = n and cr!msDS-NC-Replica-Locations
contains a reference to o.
o A full read-only replica of an application NC for which there exists a
crossRef object cr such that cr!nCName = n and cr.ms-DS-NC-RO-Replica-Locations
contains a reference to o.
o If the DC is a GC server (that is, if bit NTDSDSA_OPT_IS_GC is set in
o!options), a partial replica of a domain NC n such that n ≠ the DC's default
NC, and there exists a crossRef object cr such that cr!nCName = n.
• An nTDSConnection object "implies" a tuple in the repsFrom abstract
attribute of an NC replica (and a corresponding edge in an NC replica graph). An
nTDSConnection object cn implies a tuple in r!repsFrom for NC replica r of NC n on the DC
with nTDSDSA object t, if each of the following is true:
o cn is a child of t.
o cn!fromServer references an nTDSDSA object s.
o An NC replica of n "is present" on s.
o r "should be present" on t.
o The NC replica on s is a full replica or r is a partial replica.
o n is not a domain NC, or r is a partial replica, or cn!transportType
has no value, or cn!transportType has an RDN of CN=IP.
Review Bridgehead Server Load-Balancing Improvements with Windows Server 2008
RODCs
https://technet.microsoft.com/en-us/library/dd735927(WS.10).aspx
Active Directory Replication Concepts
https://technet.microsoft.com/en-us/library/cc731537(v=ws.10).aspx
RODC Frequently Asked Questions
https://technet.microsoft.com/en-us/library/cc754956(v=ws.10).aspx
Thanks,
Edgar
-----Original Message-----
From: Edgar Olougouna
Sent: Thursday, April 16, 2015 10:23 AM
To: Garming Sam
Cc: [email protected]; MSSolve Case Email
Subject: [REG:115041612643080 ] MS-ADTS 6.2 - Knowledge consistency checker
[case number in subject]
[bcc dochelp; cc casemail]
Hello Garming,
Glad to hear from you. The case number 115041612643080 has been created for
this inquiry. I will investigate and assist you on this.
Thanks,
Edgar
-----Original Message-----
From: Garming Sam [mailto:[email protected]]
Sent: Wednesday, April 15, 2015 11:25 PM
To: Interoperability Documentation Help
Cc: [email protected]
Subject: MS-ADTS 6.2 - Knowledge consistency checker
Hi,
In attempting to implement the inter-site topology generation algorithm, it
appears that cases around RODC are lacking clarity in the documentation.
For instance described in 6.2.2.3.3 - Site Graph Concepts, essentially Red
describes sites with writable replicas, Black describes sites with only partial
read-only and White with neither writable nor partial read-only replicas. But
there is no mention of full read-only replicas.
The only assumption that could be made here is that they are white, however,
there are two problems:
1. In 6.2.2.3.4.3 - Site Graph Construction under ColorVertices, Red describes
sites with one or more DCs with full replicas - not writable.
This would make full read-only replica Red.
2. Being marked as White, during intersite topology generation, sites with only
an RODC do not appear in the spanning-tree computation.
Therefore, they will never create any connections.
Being marked as Red however, there does not appear to be any restrictions in
the graph construction on who may replicate from it (like a Black node for
instance). Is there something here I am misunderstanding?
What color is a site containing only an RODC intended to be? And are there any
additional undocumented special cases for RODC?
Cheers,
Garming Sam
_______________________________________________
cifs-protocol mailing list
[email protected]
https://lists.samba.org/mailman/listinfo/cifs-protocol
