{"id":2174,"date":"2015-01-12T13:03:17","date_gmt":"2015-01-12T09:03:17","guid":{"rendered":"https:\/\/rakhesh.com\/?p=2174"},"modified":"2015-01-12T22:20:37","modified_gmt":"2015-01-12T18:20:37","slug":"notes-on-ad-replication-contd","status":"publish","type":"post","link":"https:\/\/rakhesh.com\/windows\/notes-on-ad-replication-contd\/","title":{"rendered":"Notes on AD Replication (contd.)"},"content":{"rendered":"<p>This post is a continuation to my <a title=\"Notes on AD Replication, Updates, Attributes, USN, High-Watermark Vector, Up-to-dateness Vector, Metadata, etc.\" href=\"https:\/\/rakhesh.com\/windows\/notes-on-ad-replication-updates-attributes-usn-high-watermark-vector-up-to-dateness-vector-metadata-etc\/\">previous one<\/a>.\u00a0<\/p>\n<h2>How the AD Replication Model Works<\/h2>\n<p>(<a href=\"http:\/\/technet.microsoft.com\/en-us\/library\/cc772726(v=WS.10).aspx\" target=\"_blank\">source<\/a>)<\/p>\n<h3>Conflict Resolution<\/h3>\n<p>Previously I mentioned that conflict resolution in AD does not depend on timestamp. What is used instead of the &#8220;volatility&#8221; of changes. Here&#8217;s how it works in practice.\u00a0<\/p>\n<p>Remember the replication metadata stored on each object? The ones you can view using <code>repadmin \/showobjmeta<\/code>. I mentioned 5 metadata there &#8211; the Local USN, the Originating DSA, the Originating USN, the Originating Timestamp, and Version. Three of these metadata are used a <em>conflict resolution stamp<\/em> for every attribute:<\/p>\n<ul>\n<li>Version, which as we know is updated each time the attribute is updated<\/li>\n<li>Originating Timestamp, which is the timestamp from the DC where the update originated from<\/li>\n<li>Originating DSA, which is not the DSA name or GUID as you&#8217;d expect from the <code>repadmin<\/code> output, but <span style=\"text-decoration: underline;\">the <code>invocationID<\/code> of the DSA<\/span> where the update originated from.<\/li>\n<\/ul>\n<p>How is this stamp used? If there&#8217;s a conflict to an attribute &#8211; i.e. a change is made to an attribute on two separate DCs &#8211; first the <code>Version<\/code> is considered. Whichever update has the higher <code>Version<\/code> wins. Notice how the timestamp of the change doesn&#8217;t matter. Say WIN-DC01 had a change to an attribute twice (thus incrementing the <code>Version<\/code> twice) while WIN-DC02 had a change to the same attribute once, but at a later time, and both these changes reached WIN-DC03 together &#8211; the change from WIN-DC01 will win over the later change from WIN-DC02 because the number of changes were more there.\u00a0<\/p>\n<p>If two conflicting changes have the same <code>Version<\/code> then the timestamp is considered. This has a one-second resolution, and so unless the conflict changes happened at the exact same second this is usually enough to resolve the conflict.\u00a0<\/p>\n<p>However, if both <code>Version<\/code> and timestamp are unable to resolve the conflict, then the <code>invocationID<\/code> is considered. This is guaranteed to be different for each DC, and is random, so whichever change is from a DC with higher <code>invocationID<\/code> wins.\u00a0<\/p>\n<h3>Replication Metadata<\/h3>\n<p>The Knowledge Consistency Checker (KCC) (will be discussed in a later post) is the component that is responsible for maintaining the replication topology. It is maintains connection objects with the replication partners and stores this information, for <em>each<\/em> domain partition, in a <a href=\"http:\/\/msdn.microsoft.com\/en-us\/library\/cc228409.aspx\" target=\"_blank\">multivalued\u00a0attribute called <code>repsFrom<\/code><\/a> in the root of that domain partition.\u00a0<\/p>\n<p>For example, here are the replication partners for WIN-DC02. Although not shown here,\u00a0WIN-DC04 &amp; WIn-DC05 are of a child domain.\u00a0<\/p>\n<p><img loading=\"lazy\" decoding=\"async\" class=\"aligncenter size-full wp-image-2178\" src=\"https:\/\/i0.wp.com\/rakhesh.com\/wp-content\/uploads\/2015\/01\/win-dc02-replications.png?resize=404%2C448&#038;ssl=1\" alt=\"win-dc02-replications\" width=\"404\" height=\"448\" srcset=\"https:\/\/i0.wp.com\/rakhesh.com\/wp-content\/uploads\/2015\/01\/win-dc02-replications.png?w=404&amp;ssl=1 404w, https:\/\/i0.wp.com\/rakhesh.com\/wp-content\/uploads\/2015\/01\/win-dc02-replications.png?resize=271%2C300&amp;ssl=1 271w, https:\/\/i0.wp.com\/rakhesh.com\/wp-content\/uploads\/2015\/01\/win-dc02-replications.png?resize=135%2C150&amp;ssl=1 135w, https:\/\/i0.wp.com\/rakhesh.com\/wp-content\/uploads\/2015\/01\/win-dc02-replications.png?resize=400%2C444&amp;ssl=1 400w\" sizes=\"(max-width: 404px) 100vw, 404px\" data-recalc-dims=\"1\" \/><\/p>\n<p>Now consider the <code>repsFrom<\/code> attribute of the domain partition on WIN-DC02:\u00a0<\/p>\n<pre class=\"lang:batch decode:true\">repsFrom: dwVersion: 2 v1.cb: 500 v1.cConsecutive Failures: 0 v1.timeLastSuccess: 13065528686 v1.timeLastAttempt: 13065528686 v1.ulResultLastAttempt: 0 v1.cbOtherDraOffset: 216v1.cbOtherDra: 284v1.ulReplicaFlags: 805306448 v1.rtSchedule: &lt;skipped&gt; v1.usnvec.usnHighObjUpdate: 65780 v1.usnvec.usnHighPropUpdate: 65780 v1.pszUuidDsaObj: 33398129-7632-4014-a3b4-eabb2b74de8b v1.pszUuidInvocId: 56c05622-3023-450d-8807-5f51401be512 v1.pszUuidTransportObj: 00000000-0000-0000-0000-000000000000 v1.cbPASDataOffset: 0 v1~PasData: (none) v2~pdsa_rpc_inst v2.pszDSIServer 33398129-7632-4014-a3b4-eabb2b74de8b._msdcs.rakhesh.local v2.pszDSIAnnotation (null) v2.pszDSIInstance 33398129-7632-4014-a3b4-eabb2b74de8b._msdcs.rakhesh.local v2.pguidDSIInstance (null); \n\n<\/pre>\n<p>And here&#8217;s the <code>repsFrom<\/code> from the Configuration partition:<\/p>\n<pre class=\"lang:batch decode:true\">repsFrom (3): dwVersion: 2 v1.cb: 500 v1.cConsecutive Failures: 0 v1.timeLastSuccess: 13065529586 v1.timeLastAttempt: 13065529586 v1.ulResultLastAttempt: 0 v1.cbOtherDraOffset: 216v1.cbOtherDra: 284v1.ulReplicaFlags: 805306448 v1.rtSchedule: &lt;skipped&gt; v1.usnvec.usnHighObjUpdate: 65843 v1.usnvec.usnHighPropUpdate: 65843 v1.pszUuidDsaObj: 33398129-7632-4014-a3b4-eabb2b74de8b v1.pszUuidInvocId: 56c05622-3023-450d-8807-5f51401be512 v1.pszUuidTransportObj: 00000000-0000-0000-0000-000000000000 v1.cbPASDataOffset: 0 v1~PasData: (none) v2~pdsa_rpc_inst v2.pszDSIServer 33398129-7632-4014-a3b4-eabb2b74de8b._msdcs.rakhesh.local v2.pszDSIAnnotation (null) v2.pszDSIInstance 33398129-7632-4014-a3b4-eabb2b74de8b._msdcs.rakhesh.local v2.pguidDSIInstance (null); dwVersion: 2 v1.cb: 500 v1.cConsecutive Failures: 0 v1.timeLastSuccess: 13065529586 v1.timeLastAttempt: 13065529586 v1.ulResultLastAttempt: 0 v1.cbOtherDraOffset: 216v1.cbOtherDra: 284v1.ulReplicaFlags: 112 v1.rtSchedule: &lt;skipped&gt; v1.usnvec.usnHighObjUpdate: 26332 v1.usnvec.usnHighPropUpdate: 26332 v1.pszUuidDsaObj: 3e82a06d-ec61-48a9-ac83-f68623fdfe85 v1.pszUuidInvocId: bc68cc5f-9baf-443b-85d5-ecb056b917fc v1.pszUuidTransportObj: 00000000-0000-0000-0000-000000000000 v1.cbPASDataOffset: 0 v1~PasData: (none) v2~pdsa_rpc_inst v2.pszDSIServer 3e82a06d-ec61-48a9-ac83-f68623fdfe85._msdcs.rakhesh.local v2.pszDSIAnnotation (null) v2.pszDSIInstance 3e82a06d-ec61-48a9-ac83-f68623fdfe85._msdcs.rakhesh.local v2.pguidDSIInstance (null); dwVersion: 2 v1.cb: 500 v1.cConsecutive Failures: 0 v1.timeLastSuccess: 13065529586 v1.timeLastAttempt: 13065529586 v1.ulResultLastAttempt: 0 v1.cbOtherDraOffset: 216v1.cbOtherDra: 284v1.ulReplicaFlags: 112 v1.rtSchedule: &lt;skipped&gt; v1.usnvec.usnHighObjUpdate: 16771 v1.usnvec.usnHighPropUpdate: 16771 v1.pszUuidDsaObj: 1e8f2e00-76c6-4e7c-86da-63a398ee2095 v1.pszUuidInvocId: 682509ae-5766-4690-9226-b969c23612b4 v1.pszUuidTransportObj: 00000000-0000-0000-0000-000000000000 v1.cbPASDataOffset: 0 v1~PasData: (none) v2~pdsa_rpc_inst v2.pszDSIServer 1e8f2e00-...\n<\/pre>\n<p>Each entry starts from <code>dwVersion<\/code> and contains information like the number of failures, time of last successful sync, the DSA GUID, the database GUID, USNs, etc. Since only one DC is replicating with WIN-DC02 for the domain partition there&#8217;s only one value for that partition; while there are three DCs replicating for the Configuration partition and so there are three values for that partition.\u00a0<\/p>\n<p>Each DC polls the DSAs (DCs) in this attribute for changes (that&#8217;s for the scheduled changes, not the ones where the source DC sends and update to all its partners and they poll for changes). If a DC is demoted &#8211; i.e. its NTDS settings object is deleted (i.e. the DSA is no longer valid) &#8211; the KCC will remove this DSA from the attribute. This prevents replication attempts to demoted DCs. (Prior to Windows 2003 though, and even now if this attribute is assigned a value, there used to be an attribute called\u00a0<code>replTopologyStayOfExecution<\/code>. This value had a default of 14 days, and a maximum value of half the tombstone lifetime (the period for which deleted objects are retained). In the presence of this attribute &#8211; which existed by default in Window Server 2003 and prior, and can be set if required in later versions &#8211; if the KCC detects an invalid DSA, instead of removing it from the <code>repsFrom<\/code> attribute it will let it remain until such time the duration of the object being deleted exceeds <code>replTopologyStayOfExecution<\/code>).\u00a0<\/p>\n<h2>Atomicity<\/h2>\n<p>Atomicity is a term encountered in databases and operating systems (I first encountered it during my CS classes, specifically the OS course I think). An atomic operation can be thought of as an indivisible operation &#8211; meaning all events that take place during an atomic operation either take place together, or they don&#8217;t. (It comes from the idea that an atom was thought to be indivisible). With respect to databases, this is a guarantee that if a bunch of values are written in an atomic operation, either all the values are written or none of them. There&#8217;s no confusion that perhaps only a few values got committed while the rest were missed out. Even if one value didn&#8217;t get written, all others will not be written. That&#8217;s the guarantee!\u00a0<\/p>\n<p>In the context of AD, updates are written to the AD database. And all attribute updates to\u00a0a single object will be written atomically in a single transaction. However:<\/p>\n<ul>\n<li>If the attributes are linked attributes (remember the <a title=\"Notes on AD Replication, Updates, Attributes, USN, High-Watermark Vector, Up-to-dateness Vector, Metadata, etc.\" href=\"https:\/\/rakhesh.com\/windows\/notes-on-ad-replication-updates-attributes-usn-high-watermark-vector-up-to-dateness-vector-metadata-etc\/\" target=\"_blank\">previous post<\/a> where there are attributes with forward and back links, for e.g. <code>member<\/code> and <code>memberOf<\/code>) the updates won&#8217;t be atomic &#8211; not too surprising, they are for different objects after all, and also usually the back link is generated by the system not sent as an update.\u00a0<\/li>\n<li>Remember:\u00a0the maximum number of values that can be written in a single transaction is 5000.\u00a0<\/li>\n<li>To ensure that (nonlinked) attributes to an object are written atomically, updates to nonlinked attributes are prioritized over updates to linked attributes. This happens when a source DC packages all the updates into replication packets. The DC\u00a0prioritizes nonlinked attributes over linked attributes. When it comes to writing the updates to the destination DC database though:\n<ul>\n<li>For linked attributes, because of parent-child relationships the objects might be written out of order to how the updates are received. This is to ensure that objects are created before any links are applied to that object.<\/li>\n<li>When an object already exists on the destination DC, even though nonlined attributes are replicated first, they are <em>not guaranteed<\/em> to be written first to the database. Generally they are applied first, but it&#8217;s\u00a0not guaranteed. <em>(Note to self: I am not very clear about this point)<\/em>.\u00a0<\/li>\n<\/ul>\n<\/li>\n<li>Remember: the number of values in a replication packet is approximately 100. If there are more than 100 values, again the nonlinked attributes are tried to put in one packet, while the linked attributes can span multiple packets. In such cases, when they are written on the destination DC database, all updates to a single object can require multiple transactions. (They are still guaranteed to be written in the same replication cycle).\u00a0<\/li>\n<li>Note: Only originating updates must be applied in the same database transaction. Replicated updates can be applied in more than one database transaction.<\/li>\n<\/ul>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>This post is a continuation to my previous one.\u00a0 How the AD Replication Model Works (source) Conflict Resolution Previously I mentioned that conflict resolution in AD does not depend on timestamp. What is used instead of the &#8220;volatility&#8221; of changes. Here&#8217;s how it works in practice.\u00a0 Remember the replication metadata stored on each object? The &hellip; <a href=\"https:\/\/rakhesh.com\/windows\/notes-on-ad-replication-contd\/\" class=\"more-link\">Continue reading <span class=\"screen-reader-text\">Notes on AD Replication (contd.)<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","enabled":false}}},"categories":[333,85],"tags":[4,346,369,251,441,438,357],"jetpack_publicize_connections":[],"jetpack_sharing_enabled":true,"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/2174"}],"collection":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/comments?post=2174"}],"version-history":[{"count":0,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/posts\/2174\/revisions"}],"wp:attachment":[{"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/media?parent=2174"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/categories?post=2174"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/rakhesh.com\/wp-json\/wp\/v2\/tags?post=2174"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}