RE: [ActiveDir] Application Partition Replication

[Dean Wells]

Title: [ActiveDir] Remote DSL link

As with the well-known 3 partitions, app. partitions, their connection objects and the resulting replica links are handled by the KCC, ISTG and DRA.  Site structure is taken into account, in short they're treated the same as the domain NC with the possible noteworthy exception that their content is ignored by GCs when sourcing partial replicas.    As for the bridgeheadinging aspect; yes, preferred b'heads will be used if they hold a replica of the partition in question.  If the list of preferred b'heads for a particular site does not include a DC in possession of an app. partition then the ISTG will bark, tell you you're a fool and assign one for you (a behavior new to 2003).  It is also worth mentioning that the ISTG must be running on a 2003 DC within a particular site in order for app. partitions to get a topology built for them but since 2003 DCs steal the ISTG role when added to a site containing no other 2003 DCs that isn't really a problem (especially since you have to have at least one 2003 DC within a site in order for an app. partition to be present there in the first place).   There are, of course, other behavioral differences 'tween app. partitions and their domain counterparts but I can't think of any that warrant mentioning in this context.   Specific to your error, have you disabled site link bridging?  A description of your site topology, the DCs within those sites and which of those DCs are or were running 2003's DNS service would be most useful? -- Dean Wells MSEtechnology * Email: dwells@msetechnology.com http://msetechnology.com   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Myrick, Todd (NIH/CIT) Sent: Thursday, October 28, 2004 4:33 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] Application Partition Replication We started seeing strange problems with our Directory replication recently when bringing up new Windows 2003 DC in our Hub and Spoke Site design.  Our network has a lot of firewalls, domains, and business units, and we have managed to coordinate most of the firewalls in the business units to allow full communications to the central site.    The tech working on the problem says that MSFT says “Application Partitions” replicate differently than GCs and Domains.  Adding further “Application Partitions” can sometimes choose different connections to replicate their data across.  I don’t necessarily believe the tech at this point, so I ask you all.  Do application partitions replicate differently?  Is there a way to force them to use hub and spoke topology, and not try to replicate outside the site links?  Also do they use Preferred Bridge Head Servers as other partitions do?   Thanks,   Todd     Event Type:       Error Event Source:    NTDS KCC Event Category: Knowledge Consistency Checker Event ID:           1311 Date:                10/28/2004 Time:                4:18:45 PM User:                NT AUTHORITY\ANONYMOUS LOGON Computer:         Description: The Knowledge Consistency Checker (KCC) has detected problems with the following directory partition.   Directory partition: DC=ForestDnsZones,DC=DHHSSECURITY,DC=LOCAL   There is insufficient site connectivity information in Active Directory Sites and Services for the KCC to create a spanning tree replication topology. Or, one or more domain controllers with this directory partition are unable to replicate the directory partition information. This is probably due to inaccessible domain controllers.   User Action Use Active Directory Sites and Services to perform one of the following actions: - Publish sufficient site connectivity information so that the KCC can determine a route by which this directory partition can reach this site. This is the preferred option. - Add a Connection object to a domain controller that contains the directory partition in this site from a domain controller that contains the same directory partition in another site.   If neither of the Active Directory Sites and Services tasks correct this condition, see previous events logged by the KCC that identify the inaccessible domain controllers.