Active Directory needs information about the underlying network to determine how domain controllers should replicate and what domain controller(s) are optimal for a given client to authenticate with. This network information is often referred to as the site or replication topology, and it consists of numerous object types that represent various aspects of the network.
At a high level, a site is a logical collection of high-speed LAN
segments. One or more subnets can be associated with a site, and this
mapping is used to determine which site a client belongs to, based on its
IP address. Sites are connected via site links, which are analogous to WAN
connections. Finally, each domain controller in a site has one or more
connection
objects, which define a
replication connection to other domain controllers.
These site topology objects are contained under the Sites
container within the Configuration naming
context. Figure 11-1 shows an example of
the site topology hierarchy using the Active Directory Sites and Services
snap-in.
Directly under the Sites
container are the individual site containers, plus containers that store
the site link objects (cn=Inter-site
Transports
) and subnets (cn=Subnets
). Three objects are included within a
site:
The Servers
container contains a
server
object for each domain
controller that is a member of the site, along with any other servers that
need to be represented in the site topology (e.g., DFS servers). Figure 11-1 shows a site topology
hierarchy.
A server
object can contain an
NTDS Settings (nTDSDSA)
object, which
distinguishes domain-controller server
objects from other server
objects. The
NTDS Settings
object stores several
attributes that are used to customize replication behavior for a specific
domain controller. The NTDS Settings
object can contain one or more nTDSConnection
objects, which define the
replication connections between domain controllers.
Table 11-1 through Table 11-7 contain some of the important attributes of the various site topology objects.
Table 11-1. Attributes of site objects
Attribute | Description |
---|---|
| RDN of the object. This is the name of the site (e.g., Raleigh). |
| Contains a prioritized list of GPOs that are linked to the site. |
| Multivalued attribute that contains a list of distinguished names for each subnet that is associated with the site. |
Table 11-2. Attributes of nTDSSiteSettings objects
Attribute | Description |
---|---|
| RDN of the object, which
is always equal to |
| Distinguished name of the NTDS Settings object of the current ISTG. |
| If universal group caching is enabled, contains the distinguished name of the site that domain controllers should refresh their cache from. See Enabling Universal Group Membership Caching for more information. |
| Bit flag that determines if universal group caching is enabled, whether site link transitivity is disabled, and if replication schedules should be ignored. For more information see Configuring Universal Group Caching for a Site. |
| Octet string that represents the default replication schedule for the site. |
Table 11-4. Attributes of siteLink objects
Attribute | Description |
---|---|
| |
| Number that represents the site link cost. See Modifying the Cost for a Site Link for more information. |
| Interval in minutes that replication occurs over the site link. |
| Octet string that represents the replication schedule for the site link. |
| Multivalued list of distinguished names of each site that is associated with the site link. See Finding the Site Links for a Site for more information. |
Table 11-5. Attributes of server objects
Table 11-6. Attributes of nTDSDSA (NTDS Settings) objects
Attribute | Description |
---|---|
| |
| GUID that represents the DIT (ntds.dit) on the domain controller. |
| Multivalued attribute containing the list of writable naming contexts (does not include application partitions) stored on the domain controller. |
| Multivalued attribute containing the list of read-only naming contexts stored on the domain controller. This will be populated only if the domain controller is a global catalog server. |
| Number that represents the functional level (i.e., operating system) of the domain controller. |
| Contains the distinguished name of the writable domain-naming context stored on the domain controller. |
| A combination of all available read-only and writable naming contexts stored on the domain controller. |
| Multivalued attribute that contains distinguished names of each read-only naming context stored on the domain controller. This will be populated only if the domain controller is a global catalog server. |
| Multivalued attribute that contains distinguished names of each writable naming context and application partition stored on the domain controller. |
| Bit flag that determines whether the domain controller is a global catalog server. |
| If set, the distinguished name of the LDAP query policy object to be used by the domain controller. |
Table 11-7. Attributes of nTDSConnection objects
Attribute | Description |
---|---|
| RDN of the object. For KCC-generated connections, this is a GUID. |
| Boolean that indicates whether the connection is available to be used. |
| Distinguished name of the
|
| Multivalued attribute that stores reason codes for why the connection exists. There will be one entry per naming context the connection is used for. |
| Bit flag where a value of
|
| Octet string that represents the replication schedule for the site link. |
| Distinguished name of the transport type (e.g., IP or SMTP) that is used for the connection. |
Create an LDIF file called create_site.ldf with the following contents:
dn: cn=<SiteName>
,cn=sites,cn=configuration,<ForestRootDN>
changetype: add objectclass: site dn: cn=Licensing Site Settings,cn=<SiteName>
,cn=sites,cn=configuration,↵ <ForestRootDN>
changetype: add objectclass: licensingSiteSettings dn: cn=NTDS Site Settings,cn=<SiteName>
,cn=sites,cn=configuration,<ForestRootDN>
changetype: add objectclass: nTDSSiteSettings dn: cn=Servers,cn=<SiteName>
,cn=sites,cn=configuration,<ForestRootDN>
changetype: add objectclass: serversContainer
Then run the following command:
> ldifde -v -i -f create_site.ldf
You also can create a site by issuing the following three AdMod commands:
> admod -config -rb "cn=<SiteName
>,cn=sites" -add objectclass::site > admod -config -rb "cn=NTDS Site Settings,cn=<SiteName
>,cn=sites" -add↵ objectclass::nTDSSiteSettings > admod -config -rb cn=Servers,cn=<SiteName>
,cn=sites" -add↵ objectclass::serversContainer
To create a site in Active Directory, a few objects must be
created. The first is a site
object,
which is the root of all the other objects. The site
object contains the following:
nTDSSiteSettings
This object stores replication-related properties about a site, such as the replication schedule, current ISTG role holder, and whether universal group caching is enabled.
serversContainer
This container is the parent of the server
objects that are part of the
site. All the domain controllers that are members of the site will
be represented in this container.
After a site is created in PowerShell, you’ve essentially got an
empty site. If you didn’t do anything else, the site would not be of
much value. To make it usable, you need to assign subnet
objects to it (see Changing a Subnet’s Site Assignment), and add the site to a
siteLink
object to link the site to
other sites (see Modifying the Sites That Are Part of a Site Link). At that point, you
can promote or move domain controllers into the site, and it should be
fully functional.
Site
objects are stored in the
Sites
container (e.g., cn=sites,cn=configuration,dc=adatum,dc=com
) in
the Configuration naming context. For more information on creating
sites, see Creating a Site.
Renaming a site in Active Directory involves changing the cn
of the site
object. The largest concern with renaming
a site, as with any other AD object, is to ensure that no applications
reference the site by name. A best practice to avoid this pitfall is to
reference AD objects by their GUIDs, which will not change even when the
object is renamed.
When deleting a site, be very careful to ensure that no active
server
objects exist within it. If
you delete a site that contains domain controllers, it will disrupt
replication for all domain controllers in that site. A more robust
solution would be to first perform a query for all server
objects using the distinguished name of
the site as the base DN. If no servers were returned, then you could
safely delete the site. If server
objects were found, you should move them before deleting the
site.
It is also worth noting that deleting a site does not delete any of the subnets or site links that are associated with the site.
Creating a Site for more on creating a site; Creating a Subnet for creating a subnet
You want to delegate permission of an AD site to allow it to be administered by another user or group.
The following example will delegate administration of the
managedBy
attribute of a
site:
Open the Active Directory Sites and Services snap-in (dssite.msc).
Click on the Sites
container.
In the right pane, right-click the site you want to delegate and select Delegate Control.
Click Next to bypass the initial Welcome screen of the Delegation of Control Wizard.
Click Add to select the users or groups that you want to delegate control to. Click Next to continue.
Select “Create a custom task to delegate” and click Next.
Click “Only the following objects in the folder.” Place a
checkmark next to site
objects
and click Next.
Deselect the General permissions and then select the Property-specific permissions.
Place a checkmark next to “Write managedBy.” Click Next to continue.
Click Finish.
You can delegate control over a site via the Delegation of Control Wizard or by using dsacls at the command line. The Delegation of Control Wizard allows you to delegate one preconfigured task—managing Group Policy links—or create a custom task to delegate. When delegating a custom task, first you must determine whether you are delegating permission over the entire site and all objects contained therein or whether you only are going to delegate control over specific child objects. For example, you can delegate control over all computer objects within a site. Once you’ve made this determination, then you’ll designate the specific permissions that you’re delegating; you can delegate anything from full control of the entire object down to granting read permissions on a single attribute.
You want to configure a site so that it does not require access to a global catalog server during most user logins.
Open the Active Directory Sites and Services snap-in (dssite.msc).
In the left pane, browse to the site you want to enable group caching for and click on it.
In the right pane, double-click on the NTDS Site Settings
object.
Under Universal Group Membership Caching, check the box beside Enable Universal Group Caching.
If you want to force the cache refresh from a particular
site, select a site; otherwise, leave the default set to
<Default>
.
Click OK.
You can use ldifde to enable universal
group caching. Create a file called enable_
univ_cache.ldf with the following contents, but change
<SiteName>
to the name of the site
you want to enable, and
<ForestRootDN>
to the distinguished
name of the forest root domain:
dn: cn=NTDS Site Settings,cn=<SiteName>
,cn=sites,cn=configuration,<ForestRootDN>
changetype: modify replace: options options: 32 -
Then use the following command to import the change:
> ldifde -i -f enable_univ_cache.ldf
You also can perform this change using a combination of AdFind and AdMod, using the following syntax:
> adfind -config -rb "cn=NTDS Site Settings,cn=<SiteName>
,cn=Sites" options -adcsv | admod options::{{.:SET:32}}
To explicitly set the site that domain controllers in this
site should use to refresh universal group membership, configure the
msDS-Preferred-GC-Site
attribute
on the NTDS Site Settings
object
with the DN of the desired site.
To enable a site for universal group membership caching, use the following syntax:
Set-ADReplicationSite -Identity <SiteName
> -UniversalGroupCachingEnabled:$True
To enable a site for universal group membership caching while also setting the site to refresh the cache from, use the following syntax:
Set-ADReplicationSite -Identity <SiteName
> -UniversalGroupCachingEnabled:$True -UniversalGroupCachingRefreshSite:<RefreshSiteName
>
An authenticating domain controller is required to contact a global catalog server (if it is not one itself) in order to process any client authentication requests. This is necessary because of the need to verify universal group memberships for any clients attempting to access the domain. Universal group caching was introduced in Windows Server 2003 to reduce the impact of this requirement. Universal group caching can be enabled on a site-by-site basis and allows domain controllers to cache universal group information locally. This largely removes the need to query the global catalog during client logon, though a global catalog will still need to be contacted the first time a new user logs on because no membership information will be cached in that case. The local DC will also need to contact a GC at regular intervals to update its cached information.
You can enable universal group caching manually by enabling bit 5
(32 in decimal) on the options
attribute of the NTDS Site Settings
object. The ldifde solution blindly writes a value
of 32 to that attribute, which is not ideal since it will overwrite any
existing values that may already be in place.
Searching with a Bitwise Filter for more on
viewing bitwise attributes; Modifying a Bit-Flag Attribute for information on
configuring bitwise values; Set-ADReplicationSite
cmdlet reference
Open the Active Directory Sites and Services snap-in (dssite.msc).
Right-click on the Subnets
container and select New
Subnet.
In the Prefix dialog box, enter the Address and Mask (e.g.,
for IPv4 enter 192.168.1.0/24
and for IPv6 enter 3FFE:FFFF:0:C000::/64
) and then select
the site the subnet is part of.
Create an LDIF file called create_subnet.ldf with the following contents:
dn: cn=<Subnet>
,cn=subnets,cn=sites,cn=configuration,<ForestRootDN>
changetype: add objectclass: subnet siteObject: cn=<SiteName>
,cn=sites,cn=configuration,<ForestRootDN>
Then run the following command:
> ldifde -v -i -f create_subnet.ldf
You can also create a subnet using AdMod. The following command creates a subnet for 10.1.1.0/24 in the adatum.com domain and associates the subnet with the Dallas site:
> admod -b "cn=10.1.1.0/24,cn=subnets,cn=sites,cn=configuration,dc=adatum,dc=com" objectClass::subnet siteObject::"cn=Dallas,cn=sites,cn=configuration,dc=adatum,dc=com" -add
Subnet
objects reside in the
Subnets
container in the
Configuration NC (e.g., cn=subnets,cn=sites,cn=configuration,dc=adatum,dc=com
).
The RDN of the subnet should be the subnet address and bit-mask
combination (e.g., 10.1.1.0/24
). The
other important attribute to set is siteObject
, which should contain the DN of the
site that the subnet is associated with.
New-ADReplicationSubnet
cmdlet reference
Get-ADReplicationSubnet
cmdlet reference
You want to find the subnets that are missing from your site topology. Missing subnets can result in clients not authenticating against the most optimal domain controller, which can degrade performance.
Having all of your subnets in Active Directory is important because a client that attempts to log on from a subnet that is not associated with any site may authenticate with any domain controller in the domain. This can result in the logon process taking longer to complete.
One way to dynamically determine missing subnets is to query each
domain controller for 5807 events and then to look at the netlogon.log file. Each IP address that has a
NO_CLIENT_SITE
entry needs to be
addressed by adding a subnet to a corresponding site.
Here is an example of a 5807 event log entry:
Event Type: Warning Event Source: NETLOGON Event Category: None Event ID: 5807 Date: 12/11/2012 Time: 4:42:20 AM User: N/A Computer: DC1 Description: During the past 4.18 hours there have been 48 connections to this Domain Controller from client machines whose IP addresses don't map to any of the existing sites in the enterprise. Those clients, therefore, have undefined sites and may connect to any Domain Controller including those that are in far distant locations from the clients. A client's site is determined by the mapping of its subnet to one of the existing sites. To move the above clients to one of the sites, please consider creating subnet object(s) covering the above IP addresses with mapping to one of the existing sites. The names and IP addresses of the clients in question have been logged on this computer in the following log file '%SystemRoot%debug etlogon.log' and, potentially, in the log file '%SystemRoot%debug etlogon.bak' created if the former log becomes full. The log(s) may contain additional unrelated debugging information. To filter out the needed information, please search for lines which contain text 'NO_CLIENT_SITE:'. The first word after this string is the client name and the second word is the client IP address. The maximum size of the log(s) is controlled by the following registry DWORD value 'HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices NetlogonParametersLogFileMaxSize'; the default is 20000000 bytes. The current maximum size is 20000000 bytes. To set a different maximum size, create the above registry value and set the desired maximum size in bytes.
Instead of scraping the event logs on every domain controller, you
can look directly at the %SystemRoot%debug
etlogon.log file on each
domain controller and parse out all of the NO_CLIENT_SITE
entries.
Here is an example of some of the NO_CLIENT_SITE
entries from the netlogon.log file:
12/11 20:02:35 [1316] ADATUM: NO_CLIENT_SITE: WIN8-CLIENT02 192.168.0.143 12/11 20:09:25 [1316] ADATUM: NO_CLIENT_SITE: 2012-SERVER05 192.168.10.245 12/11 20:12:08 [1316] ADATUM: NO_CLIENT_SITE: WIN8-CLIENT14 172.16.0.14 12/11 20:17:35 [1316] ADATUM: NO_CLIENT_SITE: WIN8-CLIENT02 192.168.0.143 12/11 20:17:37 [1316] ADATUM: NO_CLIENT_SITE: WIN8-CLIENT02 192.168.0.143 12/11 20:20:51 [4156] ADATUM: NO_CLIENT_SITE: 2012-SERVER09 192.168.1.8 12/11 20:32:38 [1316] ADATUM: NO_CLIENT_SITE: WIN8-CLIENT01 10.16.0.77
If you wanted to get creative and automate a solution to do this,
you could write a script that goes out to each domain controller, opens
the netlogon.log file, and
retrieves NO_CLIENT_SITE
entries.
Then you could examine all of the IP addresses and create subnets in
Active Directory that would contain them. You could associate all of
those subnets with a placeholder site or even use the Default-First-Site-Name
site (if it still
exists). Then, once a week (or another desired length of time), you
could look at the sites that were created or that were associated with
the default site and determine what site they should actually be
associated with.
You can get a list of all 5807 events from the System event log on the local computer by running the following command:
Get-WinEvent -LogName System | where {$_.ID -eq "5807"}
You can also get the events on a remote computer by using the following syntax:
Get-WinEvent -ComputerName <NameOfDC>
-LogName System | where {$_.ID -eq "5807"}
You can delete a subnet
object using the built-in dsrm utility or AdMod.
The dsrm utility takes the following syntax (note
the parameter at the end to avoid being prompted for
confirmation):
> dsrm cn=<SubnetName>
,cn=subnets,cn=sites,cn=configuration,<ForestRootDN>
↵ -noprompt
To remove a subnet using AdMod, use this syntax:
> admod -b cn=<SubnetName>
,cn=subnets,cn=sites,cn=configuration,<ForestRootDN>
↵ -del
Before removing a subnet, you should confirm that it is not in use by examining the netlogon.log file on domain controllers. If IP addresses within the subnet range appear in the logfile, it may point to activity from the subnet.
Since the site topology that you create in Active Directory is
meant to map to your physical network topology, an Active Directory
subnet
object can be associated with
only a single AD site at any one time. If you modify your site
configuration or need to delete a site object for any reason, you should
configure any subnets associated with that site that are still active on
your network so that they are associated with another Active Directory
site. This will ensure that any clients that reside on those subnets
will be able to locate resources such as domain controllers
appropriately, without sending authentication requests across site links
unnecessarily.
Finding Missing Subnets to find missing subnets
on your network; Deleting a Subnet for more on
deleting subnet
objects
Open the Active Directory Sites and Services snap-in (dssite.msc).
Expand the Sites
container.
Expand the Inter-Site
Transports
container.
Right-click on IP (or SMTP) and select New Site Link.
For Name, enter the name for the site link.
Under “Sites not in this site link”, select at least two sites and click the Add button.
Click OK.
The following LDIF would create a site link connecting the SJC and Dallas sites:
dn: cn=Dallas-SJC,cn=IP,cn=inter-site transports,cn=sites,cn=configuration,<ForestRootDN>
changetype: add objectclass: siteLink siteList: cn=SJC,cn=sites,cn=configuration,<ForestRootDN>
siteList: cn=Dallas,cn=sites,cn=configuration,<ForestRootDN>
If the LDIF file were named create_site_link.ldf, you’d then run the following command:
> ldifde -v -i -f create_site_link.ldf
You also can also create a site link using AdMod, as follows:
> admod -b "cn=<SiteLinkName>
,cn=IP,cn=inter-site transports, cn=sites,cn=configuration,<ForestRootDN>
" objectclass::sitelink "sitelist:++:cn=<FirstSite>
,cn=sites,cn=configuration,<ForestRootDN>
;cn=<SecondSite>
,cn=sites,cn=configuration,<ForestRootDN>
" cost::50 replInterval::180 -add
Without site links, domain controllers would not be able to determine the optimal partners to replicate with. The cost that is associated with a site defines how expensive the link is. A lower cost is less expensive (or faster) than a higher cost. Link costs are inversely proportional to bandwidth, so a faster link should be configured with a lower cost than a low-speed one. (Sometimes bandwidth costs can play a role, too.) Site link costs are manually configured items, which means that the administrator can control how inter-site replication should take place on the network.
You can list the site links associated with a particular site using DSQuery or AdFind. DSQuery uses the following syntax:
> dsquery * "cn=inter-site transports,cn=sites,cn=configuration,<ForestRootDN>
"-filter "(&(objectcategory=siteLink)(siteList=cn=<SiteName>
,cn=sites,cn=configuration,<ForestRootDN>
))" -scope subtree -attr name
To obtain this information using AdFind, use the following:
> adfind -config -f "(&(objectcategory=siteLink)(siteList=cn=<SiteName>
,cn=sites,cn=configuration,<ForestRootDN>
))" name
A site can be included as a part of zero or more site links. A site with no site links would be considered orphaned from the site topology, since there is no way to determine how and where it connects into the topology. Branch office sites may have only a single site link back to a hub, while a hub site may have numerous links that connect it to the rest of the world.
Finding the site links associated with a site consists of
performing a query for all siteLink
objects that have the DN of the site included in the siteList
attribute for a link. The siteList
attribute is a multivalued attribute
that contains all the sites that are connected via the site link.
Open the Active Directory Sites and Services snap-in (dssite.msc).
In the left pane, expand Sites→Inter-Site Transports.
Click either the IP or SMTP folder, depending on where the site link is stored.
In the right pane, double-click on the link you want to modify.
Under the General tab, you can add and remove sites that are associated with the site link.
Click OK.
Create an LDIF file called modify_site_link.ldf with the following
contents. Replace <LinkName>
with the
name of the link and <SiteName>
with
the site to add to the link:
dn: cn=<LinkName>
,cn=IP,cn=inter-site transports,cn=sites,cn=configuration,<ForestRootDN>
changetype: modify add: siteList siteList: cn=<SiteName>
,cn=sites,cn=configuration,<ForestRootDN>
-
Then run the following command:
> ldifde -v -i -f modify_site_link.ldf
You can also add sites to a site link using AdMod, as follows:
> admod -b "cn=<LinkName>
,cn=IP,cn=inter-site transports,cn=sites,cn=configuration,<ForestRootDN>
" siteList:+:"cn=<SiteName>
,cn=sites,cn=configuration,<ForestRootDN>
"
To add one or more sites to a site link by using PowerShell, use the following syntax:
Set-ADReplicationSiteLink "<SiteLinkName>
" -SitesIncluded @{Add="<SiteName1>
","<SiteName2>
"}
To remove one or more sites from a site link by using PowerShell, use the following syntax:
Set-ADReplicationSiteLink "<SiteLinkName>
" -SitesIncluded @{Remove="<SiteName1>
","<SiteName2>
"}
To associate a site with a site link, add the DN of the site to
the siteList
attribute of the
siteLink
object that represents the
link. To remove a site from a link, remove the DN associated with the
site from the siteList
attribute. For
example, to remove a site from a site link using AdMod, replace siteList:+:
with siteList:-:
.
Finding the Site Links for a Site for finding the links associated with a site
Open the Active Directory Sites and Services snap-in (dssite.msc).
In the left pane, expand Sites→Inter-Site Transports.
Click either the IP or SMTP folder, depending on where the site link is stored.
In the right pane, double-click on the link you want to modify.
Under the General tab, you can change the cost for the site link.
Create an LDIF file called modify_site_link_cost.ldf with the
following contents. Replace
<LinkName>
with the name of the link
you want to modify and <LinkCost>
with the cost:
dn: cn=<LinkName>
,cn=IP,cn=inter-site transports,cn=sites,cn=configuration,<ForestRootDN>
changetype: modify replace: cost cost:<LinkCost>
-
Then run the following command:
> ldifde -v -i -f modify_site_link_cost.ldf
You can also modify the cost of a site link using AdMod, as follows:
> admod -b "cn=<LinkName>
,cn=IP,cn=inter-site transports,cn=sites,cn=configuration,<ForestRootDN>
" cost::<LinkCost>
The cost
attribute is one of
the most important attributes of siteLink
objects. cost
is used by the KCC to determine what
connection
objects should be created
to allow domain controllers to replicate data.
cost
is inversely proportional
to bandwidth—the lower the cost, the greater the bandwidth. (Don’t
forget about looking at the bandwidth costs, too.) The number you use
for the cost is also arbitrary; the default is 100. You could use
100–1,000 as the range for your site link costs, or you could use 1–10.
The actual number isn’t important, so long as you configure the values
to be relative based on the other site links you’ve configured. The
costs that you assign to your site links should be configured according
to the physical topology of your network, where you assign the lowest
costs to the highest-speed links (or lowest-cost links), and higher
costs to lower-speed links between two sites.
You want to enable change notification between sites so that replication will occur as changes occur rather than according to a set schedule.
Open the Active Directory Sites and Services snap-in (dssite.msc).
In the left pane, expand Sites→Inter-Site Transports.
Click either the IP or SMTP folder, depending on where the site link is stored.
In the right pane, double-click on the link you want to modify.
On the Attribute Editor tab, scroll to the options
attribute and then click
Edit.
Enter a 1
to enable
change notification and then click OK.
By default, intra-site replication occurs on the basis of change
notifications where replication occurs almost immediately after a change
occurs, while domain controllers in different sites will, by default,
only replicate with each other on a set schedule. To configure a
particular site link to use the change-notification mechanism for
replication, you can set bit 1
of its
options
attribute. Keep in mind that
this will create more frequent replication traffic on the site link in
question, but it will ensure that changes made in one site can be
replicated to the other site much more quickly than by using the default
inter-site replication schedules.
Modifying a Bit-Flag Attribute for more on modifying bitwise attributes; Modifying Replication Schedules for more on modifying replication schedules
You want to change the times of day or week that a particular site link (IP or SMTP) is available for replication.
Open the Active Directory Sites and Services snap-in (dssite.msc).
In the left pane, expand Sites→Inter-Site Transports.
Click either the IP or SMTP folder, depending on where the site link is stored.
In the right pane, double-click on the link you want to modify.
On the General tab, click Change Schedule.
Select the times and days of the week that you wish to allow or disallow replication, and select the Replication Available or Replication Not Available radio button, as appropriate.
Click OK twice to save the changes.
To configure a site link to be available 24 hours a day, seven days a week, use the following syntax:
> admod -b cn=<SiteLinkName>
,cn=<TransportName>
,cn=Inter-site↵ Transports,cn=sites,cn=configuration,<ForestRootDN>
schedule::0
The following PowerShell command will configure a site link to allow replication Monday through Friday from midnight to 7:45 a.m. and from 5:00 p.m. to 11:45 p.m. while allowing replication all day and night on Saturday and Sunday:
$schedule = New-Object -TypeName System.DirectoryServices.ActiveDirectory.ActiveDirectorySchedule;$schedule.ResetSchedule();$schedule.SetSchedule ("Monday","Zero","Zero","Seven","FortyFive");$schedule.SetSchedule ("Monday","Seventeen","Zero","TwentyThree","FortyFive");$schedule.SetSchedule ("Tuesday","Zero","Zero","Seven","FortyFive");$schedule.SetSchedule ("Tuesday","Seventeen","Zero","TwentyThree","FortyFive");$schedule.SetSchedule ("Wednesday","Zero","Zero","Seven","FortyFive");$schedule.SetSchedule ("Wednesday","Seventeen","Zero","TwentyThree","FortyFive");$schedule.SetSchedule ("Thursday","Zero","Zero","Seven","FortyFive");$schedule.SetSchedule ("Thursday","Seventeen","Zero","TwentyThree","FortyFive");$schedule.SetSchedule ("Friday","Zero","Zero","Seven","FortyFive");$schedule.SetSchedule ("Friday","Seventeen","Zero","TwentyThree","FortyFive");$schedule.SetSchedule ("Saturday","Zero","Zero","TwentyThree","FortyFive");$schedule.SetSchedule ("Sunday","Zero","Zero","TwentyThree","FortyFive");Set-ADReplicationSiteLink "<SiteLinkName>
" -ReplicationSchedule $schedule
When you configure an inter-site replication link, you can specify a particular schedule during which the link will be available for replication. By default, inter-site links can pass replication traffic 24 hours a day, seven days a week, but you can restrict this so that it is only available for specific hours of the day and/or days of the week. This might be useful for a heavily utilized link that you do not want to have overloaded with replication traffic. For example, a bank headquarters may wish to prevent replication traffic from being initiated during a two-hour time period at the end of every day while its branch offices are transmitting daily report information.
The SetSchedule
method is
used, which allows each day of the week to have a different schedule,
if desired. This is handy when, for example, replication is available
all day and all night on weekends. An alternative is to use the
SetDailySchedule
method, which will
use the same replication schedule for every day of the week.
Forcing Replication from One Domain Controller to Another to force replication from one DC to another; MSDN: ActiveDirectorySchedule Class
Open the Active Directory Sites and Services snap-in (dssite.msc).
In the left pane, expand Sites→Inter-Site Transports.
Right-click either the IP or SMTP folder, depending on which protocol you want to disable transitivity or ignore schedules for.
Select Properties.
To disable site link transitivity, uncheck “Bridge all site links”.
To ignore site link schedules, check “Ignore schedules”.
Click OK.
Active Directory site links, by default, are transitive, which
means that if site A is linked to site B, and site B is linked to site
C, then site A is also linked (through site B) to site C. The KCC uses
transitivity when making decisions about creating connection
objects. You can, however, disable
this behavior if you so choose. Typically, this is not something you’ll
want to do without a very good reason. Disabling transitivity may be
necessary, for example, in some legacy deployments that have a lot of
sites and find that the KCC is having a hard time keeping up. Since
Windows Server 2003, the KCC has been greatly improved, and site link
transitivity should not cause these problems.
The other reason you might want to disable transitivity is if you
need to make replication more deterministic—that is, you want to exert
more manual control over the process. Disabling transitivity makes it
much easier to determine where the KCC will attempt to establish
connection
objects, because the KCC
on a domain controller will not be able to replicate with domain
controllers that are not in sites that are directly linked. There can be
other reasons, one of which is when you have nonroutable
networks.
We mention site link schedules here primarily because the same
attribute (i.e., options
) that
determines site link transitivity also determines whether link schedules
are enforced. If you enable the ignore
schedules
option for a particular transport (i.e., IP or
SMTP), the KCC ignores any preconfigured link schedules. If you later
disable this setting, link schedules will go back into effect.
There are multiple value variations for the options
attribute. By setting the value to
4, it reverts the settings to the default (all site links bridged with
schedules enabled). By setting the value to 3, it disables site link
bridging while ignoring schedules. By setting the value to 1, it
enables site link bridging and ignores schedules.
Modifying a Bit-Flag Attribute for more on setting a bit-flag attribute
Open the Active Directory Sites and Services snap-in (dssite.msc).
In the left pane, expand Sites→Inter-Site Transports.
Right-click either the IP or SMTP folder, depending on which protocol you want to create a site link bridge for.
Select New Site Link Bridge.
Enter a name for the bridge.
Highlight two or more site links in the left box.
Click the Add button.
Click OK.
Create an LDIF file called create_site_link_bridge.ldf with the
following contents, where <Link1>
and
<Link2>
refer to the site links to be
bridged:
dn: cn=<BridgeName>
,cn=IP,cn=inter-site transports,cn=sites,cn=configuration,;<ForestRootDN>
changetype: add objectclass: siteLinkBridge siteLinkList: cn=<Link1>
,cn=IP,cn=Inter-site Transports,cn=sites,cn=configuration,<ForestRootDN>
siteLinkList: cn=<Link2>
,cn=IP,cn=Inter-site Transports,cn=sites,cn=configuration,<ForestRootDN>
Then run the following command:
> ldifde -v -i -f create_site_link_bridge.ldf
You can also create a site link bridge using AdMod, as follows:
> admod -b "cn=<BridgeName>,cn=IP,cn=inter-site transports,cn=sites,cn=configuration,<ForestRootDN>" objectclass::sitelinkBridge "sitelinklist:++:cn=<FirstSiteLink>,cn=IP,cn=inter-site transports,cn=sites,cn=configuration,<ForestRootDN>;cn=<SecondSiteLink>,cn=IP, cn=inter-site transports,cn=sites,cn=configuration,<ForestRootDN>" -add
If you’ve disabled site link transitivity or have networks that lack direct routes between sites, you should create site link bridges. Creating a site link bridge to link several links is analogous to creating a site link to link several sites. Let’s take an example where site link transitivity is disabled and we have four sites, among which site A has a link to site B and site C has a link to site D. If site link transitivity has been disabled and we want domain controllers in sites A and B to replicate with sites C and D, we need to create a site link bridge to bridge the A–B link with the C–D link.
Disabling Site Link Transitivity or Site Link Schedules for disabling site link transitivity
The replmon.exe utility is no longer available in Windows Server 2008 and later; for 2008 and later servers the command-line interface option is appropriate. Open the Replication Monitor from the Support Tools (replmon.exe)
From the menu, select View→Options.
In the left pane, right-click on Monitored Servers and select Add Monitored Server.
Use the Add Monitored Server Wizard to add a server in the site you want to find the bridgehead server(s) for.
In the left pane, right-click on the server and select Show BridgeHead Servers→In This Server’s Site.
To search for all bridgehead servers in a site, use the following syntax:
Get-ADObject -Filter {objectClass -eq "server"} -SearchBase "cn=<SiteName>
,cn=sites,cn=configuration,<ForestRootDN>
" -SearchScope subtree -Properties * | Where {$_.bridgeheadTransportList -ne $NULL} | Select Name,bridgeheadTransportList
To search for all bridgehead servers across all sites in the domain, use the following syntax:
Get-ADObject -Filter {objectClass -eq "server"} -SearchBase "cn=sites,cn=configuration,<ForestRootDN>
" -SearchScope subtree -Properties * | Where {$_.bridgeheadTransportList -ne $NULL} | Select Name,bridgeheadTransportList
Bridgehead servers are responsible for replicating data between sites. Instead of all domain controllers replicating the same naming contexts outside of the site, the bridgehead servers act as a funnel for replication into and out of a site. Any domain controller in a site can become a bridgehead server, and bridgeheads are designated by the KCC for each writable partition in the site. You can control which servers are designated as bridgehead servers by defining preferred bridgehead servers (see Setting a Preferred Bridgehead Server for a Site for more on how to do this).
Open the Active Directory Sites and Services snap-in (dssite.msc).
In the left pane, expand Sites, expand the site where the
server you want to set as a bridgehead is contained, and expand
the Servers
container.
Right-click on the server you want to set as the bridgehead and select Properties.
Highlight IP, SMTP, or both, depending on the protocol(s) for which you want the server to be a bridgehead.
Click the Add button.
Click OK.
Create an LDIF file called set_bridgehead_server.ldf with the following contents:
dn: cn=<DCName>
,cn=servers,cn=<SiteName>
,cn=sites,cn=configuration,<ForestRootDN>
changetype: modify add: bridgeheadTransportList bridgeheadTransportList: cn=IP,cn=Inter-site Transports,cn=sites,cn=configuration,<ForestRootDN>
-
Then run the following command:
> ldifde -v -i -f set_bridgehead_server.ldf
You can also set the preferred bridgehead server with AdMod, using the following syntax:
Admod -b cn=<DCName>
,cn=servers,cn=<SiteName>
,cn=sites,cn=configuration,<ForestRootDN>
bridgeheadTransportList:+:"cn=IP,cn=Inter-site transports,cn=sites,cn=configuration,<ForestRootDN>
"
You can set a preferred bridgehead server using the following
syntax. Note that the transport can be set as IP
or SMTP
.
Set-ADObject -Identity "cn=<DCName
>,cn=servers,cn=<SiteName
>,cn=sites,cn=configuration, <ForestRootDN
>" -Add @{bridgeHeadTransportList="cn=<Transport
>,cn=Inter-site Transports,cn=sites,cn=configuration,<ForestRootDN
>"}
Setting a preferred bridgehead server can give you more control over which domain controllers participate in inter-site replication, but it is also limiting. The KCC typically selects bridgehead servers dynamically, but if you set preferred bridgehead servers, the KCC will not select new ones if the preferred servers become unavailable. Therefore, you should ensure that if you do select preferred bridgehead servers, you select at least two for a given partition in a site.
As a general rule, you shouldn’t set preferred bridgehead servers if at all possible.
> dsquery server [-site <SiteName>
]
To list all servers in the site topology using AdFind, use the following syntax:
> adfind -config -rb cn=sites -f (objectcategory=server)
To restrict the results to a specific site, do the following:
> adfind -config -rb cn=<SiteName>
,cn=sites -f (objectcategory=server)
To list all servers in the site topology by using PowerShell, use the following syntax:
Get-ADObject -SearchBase "cn=sites,cn=configuration,<ForestRootDN
>" -Filter {objectCategory -eq "server"} | Select Name
To list all servers in a specific site, use the following syntax:
Get-ADObject -SearchBase "cn=<SiteName>
,cn=sites,cn=configuration,<ForestRootDN
>" -Filter {objectCategory -eq "server"} | Select Name
Each Active Directory domain controller is represented in the site
topology by a server
object that is
associated with a specific site. Replication decisions are made based on
links from this site to other sites that contain domain
controllers.
Other types of services can also add server
objects to the site topology. The way
you can distinguish which ones are domain controllers is the presence of
an NTDS Settings (nTDSDSA)
object
that is a child of the server
object.
Only domain controllers will have that object.
Open the Active Directory Sites and Services snap-in (dssite.msc).
In the left pane, expand Sites, expand the site where the
server you want to move is contained, and expand the Servers
container.
Right-click on the server you want to move and select Move.
Select the site to move the server to.
Click OK.
You can also drag and drop the server
object from one site to another, if
desired. To do so, drag the server
object to the desired Servers
container under the destination
site.
You can move a domain controller to a new site using either the built-in DSMove utility or AdMod. DSMove takes the following syntax:
> dsmove "cn=<ServerName>
,cn=servers,cn=<CurrentSite>
,cn=sites,cn=configuration,<ForestRootDN>
" -newparent "cn=servers,cn=<NewSite>
,cn=sites,cn=configuration,<ForestRootDN>
"
To move a DC using AdMod, use the following syntax:
> admod -b "cn=<ServerName>
,cn=servers,cn=<CurrrentSite>
,cn=sites,cn=configuration,<ForestRootDN>
-move "cn=servers,cn=<NewSite>
,cn=sites,cn=configuration,<ForestRootDN>
After you move a server to a new site, you might want to monitor replication to and from that server to make sure that any new connections that are needed get created and start replicating. See Viewing the Replication Status of Several Domain Controllers for more on viewing the replication status of a server.
You want to configure a domain controller to cover multiple sites, which will cause clients in all of those sites to use that domain controller for authentication and directory lookups.
Locate the GPO that applies to the domain controller.
Right-click on the policy and then click Edit.
In the Group Policy Management Editor, browse to Computer Configuration→Administrative Templates→System→Net Logon→DC Locator DNS Records.
Double-click the “Specify sites covered by the DC Locator DNS SRV records” setting.
Click Enabled and then enter the sites that the DC should cover in the Sites dialog box. Each site should be separated by a space.
Click OK and then close the Group Policy Management Editor.
In an Active Directory environment, it is perfectly valid to have a site that does not contain its own domain controller. In fact, if you model the site topology after your real network, some sites will lack their own domain controllers unless you’ve deployed a branch office architecture or have very few sites. If you create sites without any domain controllers, the site links between the sites will determine which domain controllers will cover or advertise their services to the site. When a domain controller covers for a remote site, it needs to publish site-specific DNS resource records that clients in the remote site can use to find the domain controller. Active Directory will select DCs to cover DC-less sites automatically, but you can hardcode the list of sites a specific domain controller should cover by using a Group Policy setting as described in the preceding section.
Configuring a Domain Controller to Cover Multiple Sites describes how to configure a domain controller to cover multiple sites. Disabling Automatic Site Coverage for a Domain Controller describes how you can prevent a domain controller from covering for any sites other than its own.
If you want to reduce the load on a domain controller, one way is to prevent it from covering for other sites. Automatic site coverage happens when a site does not contain any domain controllers.
Viewing the Site Coverage for a Domain Controller for viewing the site coverage for a domain controller
In the following command, replace
<HostName>
with the name of the host
you want to find the site for:
> nltest /server:<HostName>
/DsGetSite
You’ll use the /server:
<HostName>
parameter even if you
are specifying a client computer.
Microsoft provides a DsGetSiteName
method that can be used by
languages such as Visual Basic and C++ to retrieve site coverage
information. In fact, the nltest
command shown in the CLI solution is a wrapper around this
method.
The IADsTool interface provides a wrapper around this method:
set objIadsTools = CreateObject("IADsTools.DCFunctions")
strSite = objIadsTools.DsGetSiteName("<HostName>
")
Wscript.Echo "Site: " & strSite
Each domain controller has a server
object that is contained within a site.
Clients are different—they are associated with a site based on their IP
address, and the corresponding subnet that it matches is in the Subnets
container. The client site information
is important because it determines the domain controller the client
authenticates with. If the client’s IP address does not match the subnet
range of any of the subnets stored in Active Directory, it will randomly
pick a site to use, which means it could authenticate against any domain
controller in the domain. See Forcing a Host into a Particular Site for a way to hardcode
the site association for a client.
Forcing a Host into a Particular Site for forcing a host into a particular site; MSDN: DsGetSiteName
You can bypass the part of the DC Locator process that determines
a client’s site by hardcoding it in the Registry. This is generally not
recommended and should primarily be used as a troubleshooting tool. If a
client is experiencing authentication delays due to a misconfigured
site
or subnet
object, you can hardcode its site so
that it temporarily points to a more optimal location (and domain
controller) to see whether this alleviates the problem. However, in a
situation like this, your ultimate goal should be to properly configure
your sites and subnets so that the DC Locator process can function
without this kind of manual intervention.
Unlike client computers, hardcoding a domain controller via this solution does not change the site of the domain controller.
Finding the Site for a Client for finding the site for a client
Open the Active Directory Sites and Services snap-in (dssite.msc).
In the left pane, expand Sites, expand the site that
contains the connection
object
you want to check, expand the Servers
container, and expand the server
for which you want to create the connection
object.
Right-click on the NTDS
Settings
object, click New, and then click
Connection.
Select the replication partner and click OK.
Hopefully you will not need to create connection
objects manually, since creating
and maintaining connection
objects is
the job of the KCC. It can be a lot of work to keep your connection
objects up to date by yourself,
especially if you have a large topology. The KCC uses complex algorithms
to determine the best partners for a domain controller to replicate
with.
It is sometimes necessary to create connections manually if you find a replication problem and need to get replication going again between one or more sites. By creating a connection and forcing replication to occur over that connection, you can get servers back in sync quickly.
Listing the connection Objects for a Server for
listing the connection
objects for a
server
Open the Active Directory Sites and Services snap-in (dssite.msc).
In the left pane, expand Sites, expand the site that
contains the connection
object
you want to check, expand the Servers
container, expand the server
that contains the connection
object, and click on the NTDS
Settings
object.
In the right pane, under the Name column, the snap-in will
display which connection
objects were automatically generated by the KCC and which ones
were manually generated.
connection
objects are used to
replicate inbound changes to a domain controller. By viewing the
connection
objects for a server, you
can see what domain controllers it receives updates from. connection
objects are created automatically
by the KCC, but they can be created manually if necessary.
Creating a connection Object for creating a
connection
object
One domain controller in every site is picked as the ISTG for that
site. While each domain controller is responsible for creating its own
intra-site connection
objects, the
ISTG for a site is responsible for creating the inter-site connection
objects for the bridgehead servers
in the site.
The current ISTG for a site is stored in the interSiteTopologyGenerator
attribute of the
site’s NTDS Site Settings
object. The
distinguished name of ISTG’s NTDS
Settings
object is stored in the interSiteTopologyGenerator
attribute.
Disabling inter-site topology generation is synonymous with disabling the KCC for a site. See Disabling the KCC for a Site for more information on disabling the KCC.
You want to move the ISTG for a site to another domain controller. This happens automatically if you take the current ISTG offline, but you may want to transfer the role to a server that is more optimal in your environment.
Open the Active Directory Sites and Services snap-in (dssite.msc).
Click on the site you are interested in.
In the right pane, double-click on the NTDS Site Settings
object.
Open the Attribute Editor tab and then modify the interSiteTopologyGenerator
attribute to
include the DN of the NTDS
Settings
object of the domain controller you want to
transfer the ISTG role to.
> admod -b "cn=NTDS Site Settings,cn=<SiteName>
,cn=sites,cn=configuration,;<ForestRootDN>
" interSiteTopologyGenerator::"cn=NTDS Site Settings, ;cn=<NewISTGName>
,cn=servers,cn=<SiteName>
,cn=sites,cn=configuration,<ForestRootDN>
You can modify the Inter-Site Topology Generator for an AD site by using PowerShell, as follows:
Set-ADObject -Identity "cn=NTDS Site Settings,cn=<SiteName
>,cn=sites,cn=configuration,<ForestRootDN
>" -Replace @{interSiteTopologyGenerator="cn=NTDS Settings,<DCName
>,cn=Servers,cn=<SiteName
>,cn=Sites,cn=Configuration,<ForestRootDN
>"}
The current ISTG for a site is stored as the DN of the ISTG’s
NTDS Settings
object in the interSiteTopologyGenerator
attribute of the
site’s NTDS Site Settings
object.
Domain controllers communicate their presence as the ISTG by
writing to the interSiteTopologyGenerator
attribute at a set
interval. If you want another domain controller to assume the role of
the ISTG, you need to write the distinguished name of that domain
controller’s NTDS Settings
object to
the interSiteTopologyGenerator
attribute of the NTDS Site Settings
object for the site.
Two Registry settings govern the ISTG registration process, both
of which are stored under the HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNTDSParameters
key. The interval (in minutes) in which the current ISTG should write to
the interSiteTopologyGenerator
attribute to inform the other DCs in the site that it is still the ISTG
is stored in the KCC site generator renewal
interval (minutes)
value. The default is 30 minutes. The other
value is named KCC site generator failover
(minutes)
and contains the time in minutes that each domain
controller in the site should wait for the interSiteTopologyGenerator
attribute to be
written to before attempting to register itself as the ISTG. The default
is 60 minutes.
The KCC runs every 15 minutes by default on all domain controllers
to generate the intra-site topology connections. The KCC that runs on
the server that is selected as the ISTG generates inter-site topology
connections to other sites from the bridgehead servers in its site. In
some situations—such as when you create new site
, siteLink
, or subnet
objects—you may want to run the KCC
immediately so that any new connections between domain controllers are
created right away.
Determining Whether the KCC Is Completing Successfully for determining whether the KCC is completing successfully; “The Role of the Inter-Site Topology Generator in Active Directory Replication”
The main way to debug issues with the KCC is by looking for NTDS KCC events in the Directory Service event log. If you suspect a problem or perhaps are seeing errors, you can increase the amount of logging in the event log by enabling diagnostics logging for the KCC. When KCC diagnostics logging is enabled, each KCC exception logs a significant amount of information to the event log that may help you pinpoint the problem. See Enabling Diagnostics Logging for more information on enabling diagnostics logging.
You want to disable the KCC for a site and generate your own replication connections between domain controllers.
Open the Active Directory Sites and Services snap-in (dssite.msc).
Click on the site you are interested in.
In the right pane, double-click on the NTDS Site Settings
object.
Modify the options
attribute. To disable only intra-site topology generation, enable
bit 0 (decimal 1). To disable inter-site topology generation,
enable bit 4 (decimal 16). To disable both, enable both bit 4 and
bit 1 (decimal 17).
Click OK.
You can disable the KCC for
<SiteName>
by using the
ldifde utility and an LDIF file that contains the
following:
dn: cn=NTDS Site Settings,<SiteName>
,cn=sites,cn=configuration,<ForestRootDN>
changetype: modify replace: options options:<OptionsValue>
-
If the LDIF file were named disable_kcc.ldf, you would run the following command:
> ldifde -v -i -f disable_kcc.ldf
You can also perform this change using a combination of AdFind and AdMod, as follows:
> adfind -b "cn=NTDS Site Settings,cn=<SiteName>
,cn=Sites,cn=configuration, ;<ForestRootDN>
" options -adcsv | admod options::{{.:SET:<OptionsValue>
}}
The ldifde solution simply overwrites the
value of the options
attribute
without checking to see whether any current value may be in place.
See Modifying a Bit-Flag Attribute, or use the
AdFind/AdMod solution for a safer method to modify bitwise
values.
The following command will update the options
attribute. To disable only
intra-site topology generation, enter the number 1
for the value. To disable inter-site
topology generation, enter the number 16
for the value. To disable both, enter the
number 17
as the value.
Set-ADObject "cn=NTDS Site Settings,cn=<SiteName>
,cn=sites,cn=configuration, ;<ForestRootDN>
" -Replace @{Options="<OptionsValue>
"}
In some cases, you may want to disable the KCC from generating the
intra-site topology connections, inter-site topology connections, or
both. The connection
objects that the
KCC dynamically creates determine how domain controllers replicate with
each other. Disabling the KCC was sometimes necessary with legacy
versions of Windows due to scalability issues with the KCC and very
large topologies. Since Windows Server 2003, the KCC has been greatly
improved, and it is unlikely that you will need to disable the KCC. If
you disable the KCC, you will need to pay close attention to any domain
controller or site topology changes and manually adjust the connection
objects accordingly.
Disabling the KCC can be done only at the site level. You have to
modify the NTDS Site Settings
object
of the site for which you want to disable the KCC. The options
attribute (a bit flag) on this object
determines whether the KCC runs. If the 00001 bit is enabled, intra-site
topology generation is disabled; if the 10000 bit is enabled (16 in
decimal), inter-site topology generation is disabled. See Modifying a Bit-Flag Attribute for more on the proper way
to set bit flags.
Modifying a Bit-Flag Attribute for more on
setting bit flags; Creating a connection Object for
creating a connection
object
manually
Expand HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNTDSParameters.
Right-click on Parameters and select New→DWORD Value.
Enter the following for the name: Repl topology update period
(secs)
.
Double-click on the new value, and under “Value data” enter the KCC interval in number of seconds (900 is the default).
By default, the KCC checks its connections every 15 minutes and makes changes as necessary. You can modify this interval by simply modifying the Registry.
There is another related Registry setting you should also be aware
of. By default, the KCC waits five minutes after Active Directory starts
up before it runs. You can change this delay by creating a REG_DWORD
value called Repl topology update delay (secs)
under the
HKLMSystemCurrentControlSetServicesNTDSParameters
key. The data for the value should be the number of seconds to wait
after startup before the KCC starts. The default is 300, which is five
minutes.
3.149.242.9