Table 11-1 through Table 11-7 contain some of the important attributes of the various site topology objects.

You want to create a site.

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:

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.

Changing a Subnet’s Site Assignment; Modifying the Sites That Are Part of a Site Link

You want to obtain the list of sites in a domain.

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.

You want to rename 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.

MSDN: Object Names and Identities; MSDN: Using objectGUID to Bind to an Object

You want to delete a site.

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.

You want to configure a site so that it does not require access to a global catalog server during most user logins.

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

You want to create a subnet.

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

You want to list the subnet objects in Active Directory.

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.

Get-WinEvent -LogName System | where {$_.ID -eq "5807"}

Get-WinEvent -ComputerName <NameOfDC> -LogName System | where {$_.ID -eq "5807"}

Get-WinEvent cmdlet reference; “Freaky neat Active Directory site links with PowerShell”

You want to delete a subnet object.

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.

Remove-ADReplicationSubnet cmdlet reference

You want to change the site object that a particular subnet is associated with.

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

You want to create a site link to connect two or more sites together.

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.

“Active Directory Replication Concepts”; New-ADReplicationSiteLink cmdlet reference

You want to list the site links that are associated with a site.

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.

You want to modify the sites associated with a site link.

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

You want to modify the cost for a site link.

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.

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.

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.

Forcing Replication from One Domain Controller to Another to force replication from one DC to another; MSDN: ActiveDirectorySchedule Class

You want to disable site link transitivity to control replication manually.

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.

Modifying a Bit-Flag Attribute for more on setting a bit-flag attribute

You want to create a site link bridge because you’ve disabled site link transitivity.

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

You want to find the bridgehead servers for a site.

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).

“Active Directory Replication Concepts”; “Bridgehead Server Selection”

You want to set a preferred bridgehead server for a site.

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.

“Active Directory Replication Concepts”

You want to list the server objects in the site topology.

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.

You want to move a domain controller to a different site.

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.

“Automatic detection of site membership for domain controllers”

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.