Hi Edgar, Is it at all possible to describe more details on ntdsConnection objects for the RODC which do not have NTDSCONN_OPT_RODC_TOPOLOGY?
>From what I understand, they should exist, but I have yet to see any in a test setup I built to observe (which may be due to failing to wait long enough). ADTS 6.2.2.7 - Updating the RODC NTFRS Connection Object mentions updating the fromServer attribute from a connection which does have NTDSCONN_OPT_RODC_TOPOLOGY to the fromServer of an ntdsConnection which does not have NTDSCONN_OPT_RODC_TOPOLOGY. Similarly the question, on the RODC FAQ [1] asks: Why does an RODC have two inbound connection objects? I assume it refers to the same phenomenon. Cheers, Garming [1] https://technet.microsoft.com/en-us/library/cc754956%28v=ws.10%29.aspx > Garming, > RODCs are particular in the sense they are designed for inbound > unidirectional replication, and are not meant to replicate outbound or > between each other. An RODC KCC does consider itself as part of the > topology. NTDS-DSA-RO object category types are not returned in KCC / ISTG > queries while attempting to enumerate inbound topology objects. > The RODC connection object is however created during dcpromo when the RODC > machine account is set. > The RODC ntdsConnection object has > Options: 0x41 NTDSCONN_OPT_IS_GENERATED | NTDSCONN_OPT_RODC_TOPOLOGY > fromServer: the nTDSDSA object of the source DC. > RODC connections are marked as IS_GENERATED although they are not > auto-generated. > > MS-ADTS 6.1.1.2.2.1.2.1.3 RODC NTFRS Connection Object > https://msdn.microsoft.com/en-us/library/dd340911.aspx > > In Section 6.2, the options bit NTDSCONN_OPT_RODC_TOPOLOGY is referenced > whenever appropriate. > > Thanks, > Edgar > > -----Original Message----- > From: Garming Sam [mailto:[email protected]] > Sent: Wednesday, April 22, 2015 9:45 PM > To: Edgar Olougouna > Cc: [email protected]; MSSolve Case Email > Subject: Re: [REG:115041612643080 ] MS-ADTS 6.2 - Knowledge consistency > checker > > 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
