Special Replication Operations
After you set up your sites and deploy your domain controllers, there shouldn't be much else to do but bask in a job well done. One or two things may crop up, though, that demand your attention.
Manually Creating Connections
Given enough time, the KCC will create an intra-site replication topology that converges changes as rapidly as possible. The ISTG will do the same for inter-site replication.
If a domain controller goes down, it may take a while for the KCC to recognize the problem and begin work to heal the replication ring. If the KCC or ISTG fails to respond in time to forestall an emergency, you can intervene and create a connection manually.
When you build a manual connection, you interfere with the automatic operation of the KCC. This isn't necessarily a bad thing. The network will not melt down if you make a mistake. But you may find that a domain controller gets into unexpected replication difficulties caused by your actions. Consider all manual interventions carefully before proceeding.
Moving Server Objects Between Sites
You may be part of a central IT group that builds new servers for remote locations and then ships them for installation by a local tech or an outsourcing agent. During the domain controller promotion, the local IP address of the server defines its site affiliation. This site may not be correct for the ultimate destination.
If you change the IP network of a domain controller, or build a new site that is assigned the IP network of an existing domain controller, you need to move the Server object for the domain controller to a new Site container along with the NTDS Settings object and the Connection objects. This is done using the AD Sites and Services console. Drag and drop the server object onto the Server container under the target site.
After moving a Server object, give the KCC lots of time to set up the new replication topology and change the replication transport from high-speed RPC to low-speed RPC. If you try to force replication before the KCC does its work, you'll get an error. Wait at least a half hour (two KCC intervals) then try again. If it still fails, check the Event log. You may see an error such as the one in Figure 7.19.
Figure 7.19. Event Log entry showing failure of the KCC to build a connection.
If you get a connection error, make sure you didn't accidentally associate the site with the wrong IP address. Check DNS to ensure that the SRV records are in their proper places and that the server is configured to point at a functioning DNS server. Also, if this is the first domain controller in the new site, it will become both the bridgehead and the ISTG, which will take a while to configure automatically.
Manually Controlling Replication Topology
When the KCC builds a connection, it selects two end-point domain controllers and places a Connection object into the NTDS Settings container for those servers. Connection objects always represent inbound data flows. You cannot change the inbound target of a Connection object, but you can change its replication partner.
When building manual connections, make absolutely sure that you don't inadvertently put the domain controller into a loop or place the end-point at a domain controller in the forest that does not communicate directly with other domain controllers holding replicas of the same naming contexts.
Also, the KCC will not delete manual connections when new domain controllers are added to the replica ring or other domain controllers are taken out or fail. You'll need to change the topology by hand after you take manual control of the connections.
You have two choices when manually controlling replication topology: you can select a new replication partner for a given connection or you can build a new Connection object.
Selecting a New Replication Partner
When you are ready to select a new replication partner, follow Procedure 7.11.
Procedure 7.11 Selecting a New Replication Partner
Open the AD Sites and Services console.
Expand the tree to find the target server and highlight its NTDS Settings icon.
Double-click the Connection object from the domain controller you want to change. This opens the Properties window for the connection (see Figure 7.20).
Figure 7.20. Properties window for <automatically generated> connection showing its replication partner.
The Replicate From field contains the name of the replication partner, the partner's site, and the domains that are replicated from that partner. In the example, the target server is in the Subsidiary.com domain and is not a Global Catalog server, so it does not replicate any other naming contexts.
In the Replicate From field, click Change. The Find Domain Controllers window opens. If you have an extensive forest, this list might be fairly long.
Double-click the domain controller that you want to be the server's new replication partner. This closes the window and returns you to the Properties window. The new replication partner is listed in the Server field.
Click OK to save the changes and close the window. The DRA sees the change and begins replication from the new partner. If this is an inter-site connection, it may take a while for replication to occur.
Building New Connections
When you are ready to create a new connection between domain controllers, do as directed in Procedure 7.12.
Procedure 7.12 Building a New Connection Object
Open the AD Sites and Services console.
Expand the tree to show the contents of the NTDS Settings container under the server for which you want to build a connection. There should already be at least one Connection object designated <automatically generated>. This was built by the KCC.
Right-click the NTDS Settings object and select NEW NT DS CONNECTION from the flyout menu. The Find Domain Controllers window opens.
Select the domain controller from which you want to build a connection. Remember that Connection objects always represent inbound data flows.
Click OK. The New Object – (Connection) window opens. The name of the domain controller you selected is inserted in the Name field.
Click OK to save the change and return to the console. The new Connection object appears on the list. You should keep an eye on the Event log to make sure the DRA sees the new connection and replicates across it. You may need to enable Active Directory diagnostics to do this. See the next section.