Deploying Active Directory for Branch Office Environments
| Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist. |
Chapter 4 - Pre-Staging Configuration at the Hub
Deployment and Operations Guide
This chapter outlines the steps needed to perform the necessary configuration at the hub site prior to creating the staging site and staging domain controllers for your branch offices. After completing these steps, automatic site-link bridging will be disabled, all of the sites and subnets for the branch offices will be created, the Inter-Site Topology Generator will be disabled in all sites, and the hub and spoke topology for your branch offices will have been created.
On This Page
Introduction Process Flowchart Deployment Considerations Disabling Automatic Site-Link Bridging Creating the Staging Site and the Branch Office Sites Disabling the Inter-Site Topology Generator Disabling the Intrasite KCC for the Staging Site Creating your Hub and Spoke Topology Configure the Branch Domain Controller Installation Scripts Summary
Introduction
Now that your hub site and bridgehead servers are created, the next step in the process is preparing for the creation of the staging site and the staging process by configuring your hub site. This chapter will step you through the processes that your organization must perform in the hub site before starting the staging process. By the end of the chapter, the sample environment will appear as follows:
.gif)
Resource Requirements
This section provides the details of the resources that you will need to prepare your environment for the staging process.
What You Will Need
To complete the procedures in this chapter, you will need:
All bridgehead servers installed.
The hub installation scripts.
The branch office installation scripts.
The quality assurance (QA) scripts.
What You Should Know
To complete the procedures in this chapter, you will need:
The user name and password for a user account that is a member of the enterprise admins group.
The names for all of the branch offices in your organization.
The subnets for all of the branch offices in your organization.
The computer names of all of the bridgehead servers in your organization.
The computer names of the first domain controller that will be installed for each branch office in your organization.
Process Flowchart
.gif)
Deployment Considerations
The processes covered in this chapter need to be performed by the information technology (IT) staff of the organization deploying the Active Directory directory service™. This will allow your organization to perform additional validation procedures that ensure the processes were completed successfully.
In addition, some of these processes must be performed while logged on with a user account that is a member of the Enterprise Admins group. By performing these processes in your organization, you will not have to provide the staging organization with a user account that is a member of the Enterprise Admins group.
Disabling Automatic Site-Link Bridging
In large branch office deployments, it is not desirable to allow the Knowledge Consistency Checker (KCC) to create and delete connection objects at will. Typically, the branch offices are connected to a data center, the hub site, and are not directly connected to each other. Therefore, the choice of domain controllers that can be selected as replication partners is limited by the branch office design. Therefore, in this chapter you will disable the transitiveness of site links to allow you to use scripts to create connection objects between the hub and each branch later in the process. This will force replication to occur between only the branch domain controllers and specified hub bridgehead servers.
Creating Sites and Subnets
At this point, you are preparing to create the staging domain controller so that you can begin to stage domain controllers. During the staging process, as the branch office domain controllers are created, you will be placing them in the branch office sites. After they are in their branch office site, you must ensure that they replicate with the appropriate hub bridgehead server. It is not possible to create the branch to hub site links until you have created the branch office sites.
Disabling the Inter-Site Topology Generator(ISTG)
Although using the KCC to generate the replication topology is the best solution for many situations, in the branch office scenario with a large number of branches, the KCC experiences scalability issues. Therefore, in a large branch office environment, more than 100 branches, it is recommended that the Inter-Site Topology Generator (ISTG) be disabled and that you use the scripts included with this guide to create connection objects. This will enable you to create a load-balanced hub and spoke replication topology between your bridgehead servers and branch offices.
Creating a Hub and Spoke Topology
Creating a hub and spoke topology allows you to ensure that replication occurs between only branch office domain controllers and hub bridgehead servers. This will prevent domain controllers in branches that are connected only through the hub and not connected directly from replicating with each other. See the Active Directory Branch Office Planning Guide for more information on a hub a spoke topology.
Permissions for the Creation of Replica Domain Controllers
If your staged domain controllers are being created for your organization by a third party, you may not want to provide the third-party company with a user account that is a member of the domain admins group. Instead, you may want to create a group with the permissions necessary to create replica domain controllers. See the Create Replica Domain Controllers section in Chapter 11: Delegating Tree/Forest Operations in Building Enterprise Active Directory Services Notes from the Field from MSPress.
Disabling Automatic Site-Link Bridging
This procedure needs to be performed only once for your environment. Disabling automatic site-link bridging will apply across your Active Directory implementation after it is configured.
To disable Automatic Site-Link Bridging:
Log on to ROOT1 as an Enterprise Admin.
Click Start, Programs, Administrative Tools, and then select Active Directory Sites and Services.
In Active Directory Sites and Services, in the console tree, right-click Active Directory Sites and Services, and then select Connect to Domain Controller.
Note: You may have to browse to the Branches domain for the bridgehead servers to appear in the next step.
In the Connect to Domain Controller dialog box, under Available controllers in, select the first bridgehead server, and then click OK.
Expand Sites, and then expand Inter-Site Transports.
Right-click the IP transport object, and then click Properties.
In the IP Properties dialog box, clear the Bridge all site links check box, and then click OK.
Related Topics
Article 244368, How to Optimize Active Directory Replication in a Large Network.
Creating the Staging Site and the Branch Office Sites
Before staging any domain controllers, you must first create all of your branch office sites and disable the ISTG in all of the sites. The branch office scripts included with this guide include a script that can be used to automatically create the sites and subnets you need for your environment.
Creating the Staging and Branch Office Sites
The Automksites.vbs script automates the creation of sites, subnets, and site links by using a comma separated (CSV) input file named Sites.csv. The script is located in the C:\ADBRANCH\HUB directory on the server selected to host the branch office installation files.
To create your sites:
Log on to HUBDC1, the domain controller containing the Active Directory branch office scripts, as Administrator.
Click Start, Programs, Administrative Tools, and then select Active Directory Sites and Services.
Verify that the sites and subnets you want to create do not already exist in Active Directory.
Start a command prompt, by clicking Start, Run, typing Cmd and then press ENTER.
Type CD \ADBRANCH\HUB and then press ENTER.
Type Notepad Sites.csv or use Microsoft Excel to edit the CSV input file. Each site, including the staging site, should have a line in the input file that contains the site name and the subnet and mask bits, for example:
Staging,10.10.30.1/32
Staging,10.10.30.2/32
Staging,10.10.30.3/32
Staging,10.10.30.4/32
Staging,10.10.30.5/32
BOSite1,10.10.21.1/32
BOSite2,10.10.22.1/32
BOSite3,10.10.23.1/32
BOSite4,10.10.24.1/32
BOSite5,10.10.25.1/32
Where the Internet Protocol (IP) addresses for the staging site are the addresses for the staging site server and the addresses that will be assigned to domain controllers while they are being staged. The IP addresses for the branch office sites are the final IP address range for the destination branch office sites.
After adding all of your sites, close Notepad and save your changes.
At the command prompt, start the script by using the following syntax:
cscript.exe automksites.vbs
Verify that the correct number of sites was created when the script displays the final status message.
Use Active Directory Sites and Services to verify that the sites and subnets were created as expected. If the sites and subnets were not created as expected, delete the sites and subnets, correct the Sites.csv file, and then rerun the script.
Note: Before proceeding, all of the sites for your organization should be created. If you create sites after disabling the ISTG, you will have to repeat the procedure for disabling the ISTG because the ISTG is disabled at the site level.
Related Topics
Step-by-Step Guide to Active Directory Sites and Services White Paper
Windows 2000 Resource Kit Distributed Systems Guide
Disabling the Inter-Site Topology Generator
The ISTG must be disabled for each site in your organization. For each site, there is one domain controller that is responsible for maintaining the intersite replication topology. This domain controller is referred to as the ISTG. As a result, it is important that all sites for your organization were created in the previous procedure. If additional sites are added after you complete the following procedure, you must repeat this procedure to disable the ISTG for the new site. You must use this procedure's script because there is no graphical user interface (GUI) or utility that will allow you to perform these steps.
The script used in this procedure performs the following tasks:
Binds to the RootDSE (Lightweight Directory Access Protocol [LDAP] information local to each Microsoft Windows 2000 domain controller) by using LDAP.
Determines the local computer name.
Determines the name of the configuration partition of the forest.
Enumerates each site in Active Directory and evaluates the settings for each site to determine if the inter-site KCC functionality is currently disabled or enabled.
If the inter-site KCC setting already reflects the correct configuration, H4sIAAAAAAACC7t+9tgsBjBoZDBiiAez/oYzMnAyMDBXAdlMDDJgMVYg5maCsXiYjIDqQTK/mb7+ h+ifwAgkQJghJDEjPzeRofzl8gPlDkC+CQeXYFrZwfJ8IFZgOFLOAhTTZYSYxAk3k5Hp////YBYT IyNUTI+RDUgKALEiqwhDeGZeSn55sYJrRUFOflFqkV5OXrYigyPUHQIM7GB37AGbyMjEpBRcWVyS mgviGQAxF4MaQxfYfUB7/pf8YWOAuIORgRmsDwD1edFRCgEAAA== no changes are made. Otherwise, the Active Directory object that controls the behavior for the particular site is modified to disable inter-site topology generation as specified.
The changes the script makes are propagated to each domain controller throughout the forest through Active Directory replication. When the ISTG discovers this change (after replication has occurred), the KCC acts accordingly.
To disable the ISTG:
Log on to HUBDC1, the domain controller containing the Active Directory branch office scripts, with an account that is a member of the Enterprise Admins group.
Open a command prompt, change to the C:\ADBranch\HUB folder, start the script using the following syntax:
cscript.exe configkcc.vbs /disable
As the script progresses, output is displayed in the command prompt detailing the script's progress.
Note: This procedure must be performed whenever a new site is added to your organization.
This procedure will disable the ISTG in all sites in your organization. If you have sites outside of your branch office environment in which you want the ISTG enabled, you will need to manually re-enable the ISTG for those sites. To enable the ISTG for a site, follow the procedure under the Disabling the Intrasite KCC for the Staging Site section later in this chapter for the site and set the options value to zero. For more information, see article 242780 "How to Disable the Knowledge Consistency Checker From Automatically Creating Replication Topology." In addition, because the ISTG must be disabled for the hub site, you will have to create manual connection objects between your hub site and the rest of your topology.
Verifying the ISTG is Disabled
To verify the ISTG is disabled:
Note: The on HUBDC1 in the C:\ADBranch\HUB folder is a script called Checkistg.vbs that can be used to verify the ISTG is disabled.
Click Start, Run, type Replmon.exe and then click OK.
On the Edit menu, click Add Monitored Server.
In the Add Server to Monitor dialog box, click Next.
In the Enter the name of the server to monitor explicitly box, type HUBDC1 (where HUBDC1 is the server on which you ran the Configkcc.vbs script), and then click Finish.
Right-click HUBDC1 (where HUBDC1 is the server you added in the previous step), and then select Generate Status Report.
In the File name box of the Save As dialog box, type C:\ISTGStatus and then click Save.
In the Report Options dialog box, clear all options except for Server/DC Configuration Data and Extended Site Configuration, and then click OK.
When the Report Status dialog box displays Report Complete, click OK, and then close Active Directory Replication Monitor.
Start Notepad, and then open C:\ISTGStatus.log.
In Notepad, scroll down to the Enterprise Data section of the ISTGStatus.log file. In this section, each site has its own section that starts with the following heading:
Site Name: Hub
---------------------------------------
For each site, verify that the Site Options entry contains: NTDSSETTINGS_OPT_IS_INTER_SITE_AUTO_TOPOLOGY_DISABLED
If a site does not indicate that the ISTG is disabled, repeat the procedure for running the ConfigKCC.vbs script.
Close Notepad.
Note: This procedure should be repeated on a regular basis to ensure that the ISTG is disabled for all the sites in your branch office environment. AppManager can provide a mechanism for regularly monitoring domain controllers to ensure that the ISTG is disabled. It can run this script on a regular basis for you.
Related Topics
Article 245610, How to Disable the Knowledge Consistency Checker Intersite Topology Generation for All Sites.
Article 242780, How to Disable the Knowledge Consistency Checker From Automatically Creating Replication Topology.
Disabling the Intrasite KCC for the Staging Site
In these steps you will disable the intrasite KCC in the staging site. This is done so that when you stage a domain controller, you can create connection objects between it and the staging site domain controller by using scripts. This ensures that staged domain controllers will only replicate with the staging site domain controller, instead of any domain controller in the staging site. By configuring the staging site in this way, if a staged domain controller is not working properly, it will not impact other staged domain controllers because it will not be a replication source for another staged domain controller.
To disable the intrasite KCC for the staging site:
Log on to HUBDC1, the domain controller that contains the Active Directory branch office scripts, with an account that is a member of the enterprise admins group.
Click Start, Run, type Ldp.exe, and then click OK.
On the Connection menu, click Connect.
Type the server name of a domain controller in the enterprise, verify that the port setting is 389, clear the Connectionless check box, and then click OK. After the connection is complete, server-specific data is displayed in the right pane.
On the Connection menu, click Bind. In the appropriate boxes, type the user name, password, and domain name (in Domain Name System [DNS] format) of an account that is a member of the Enterprise Administrators group (you may need to select the Domain check box), and then click OK. If the binding is successful, you should receive a message in the right pane that is similar to the following example:
Authenticated as dn:YourUserID
On the View menu, click Tree.
In the BaseDN box, type the distinguished name of the site object for the staging site in the configuration container of the forest. For example, if the staging site is named Staging in the hay-buv.com forest, the domain name would look like the following example:
CN=Staging,CN=Sites,CN=Configuration,DC=corp,DC=hay-buv,DC=com
If this object is located, LDP should display the object in the left pane.
Expand the view. One of the child objects should begin with CN=NTDS Site Settings. Double-click this object. In the right pane, LDP should output the current settings for the attributes for this object. Each attribute is preceded by a number and then an angle bracket (>). The number represents the number of values the attribute contains.
Look for the "options" attribute. If it is not present, this is normal and makes modifying the value easier.
In the right pane, locate the beginning of the output for the NTDS Site Settings object. It looks similar to the following example:
Expanding base 'CN=NTDS Site Settings,CN=Staging,CN=Sites,CN=Configuration,DC=corp,DC=hay-buv,DC=com'... Result <0>: (null) Matched DNs: Getting 1 entries: >> Dn: CN=NTDS Site Settings,CN=Staging,CN=Sites,CN=Configuration,DC=corp,DC=hay-buv,DC=com
Copy the string of data from the ">> Dn" portion of the LDP output.
On the Browse menu, click Modify. In the Dn box, paste the string you copied in the previous step.
In the Attribute box, type options
In the Values box, type 17 to disable both intrasite and intersite topology generation.
In the Operation box, click Replace, press ENTER, and then click Run.
In the right pane, the output should look similar to the following example if the operation is successful:
***Call Modify... ldap_modify_s(ld,'CN=NTDS Site Settings,CN=Staging,CN=Sites,CN=Configuration,DC=corp,DC=hay-buv,DC=com',[1] attrs); Modified "CN=NTDS Site Settings,CN=Staging,CN=Sites,CN=Configuration,DC=corp,DC=hay-buv,DC=com".
Click Close, and then close Ldp.exe.
Related Topics
Article 242780, How to Disable the Knowledge Consistency Checker From Automatically Creating Replication Topology.
Creating your Hub and Spoke Topology
The Active Directory branch office ZIP file includes scripts for creating connection objects in a hub and spoke topology. There are four main files used in the process for creating the connection objects:
Topo.dat Contains a list of hub bridgehead servers and a list of branch office domain controllers. This file must be manually built with all of your hub bridgehead servers, except for the PDC Emulator server (HUBDC1), and with the first domain controller for each branch office.
Mkhubbchtop.cmd Takes the Topo.dat file as input and builds the Mkdsx.dat file with the hub and spoke topology.
Mkdsx.dat Contains the hub and spoke topology to be used by Mkdsx.cmd. It was generated by running Mkhubbchtop.cmd with the Topo.dat as input.
Mkdsx.cmd Creates the connection objects for the hub and spoke topology specified in the Mkdsx.dat file.
Mkdsx Switches
There are a variety of switches that can be used in the Topo.dat file to control the functionality of Mkdsx. The following table lists each switch and its purpose:
Switch |
Purpose |
|---|---|
/dc BH1 |
Specifies the hub bridgehead server to bind to when Mkdsx.cmd is run on the result file. This should always be one of the well-connected hub bridgehead servers. |
/repinterval 9 |
The replication interval in hours between the hub and branch. This is the base interval between which replication is to occur between any given hub and branch office domain controller. After the interval and redundancy are established to build the 7x24 schedule, the schedule mask and schedule override parameters are applied to produce the final schedule. |
/schedoverride override.txt |
Specifies a file with a 7x24 string of ASCII hex-digit pairs to turn on the schedule. |
/schedmask mask.txt |
Specifies a file with a 7x24 string of ASCII hex-digit pairs to turn off the schedule. |
/hubredundancy 2 |
Specifies the number of redundant connections into the hub bridgehead servers from the branch office domain controllers. |
/bchredundancy 2 |
Specifies the number of redundant connections into the branch office domain controllers from the hub bridgehead servers. |
/output mkdsx.dat |
This is the file name for the output from running Mkhubbchtop.cmd with Topo.dat. |
/debug |
This will cause Mkdsx.cmd to process the file, but it will not create any connection objects. This is useful for verifying your topology without making changes. |
/auto_cleanup |
This causes Mkdsx.cmd to automatically delete all connection objects on all servers listed in the Topo.dat file. After running Mkdsx.cmd with this switch, the only connection objects on any domain controller in the Topo.dat file will be those created by Mkdsx.cmd. For more details, see below. |
In addition to using the above switches in the Topo.dat to control Mkdsx.cmd, you can also configure the behavior of Mkdsx.cmd by using the Mkdsx.dat file. When Mkhubbchtop.cmd processes the Topo.dat file and creates the Mkdsx.dat file, it creates a line for each bridgehead and branch office domain controller combination. Each line is then used to create a connection object. The entries in the Mkdsx.dat file appear as follows:
create BOSite1\BODC1 Hub\BH2 on s-1-18-0 /dc BODC1
There are four options that can be used at the beginning of the connection object lines in the Mkdsx.dat file:
Option |
Purpose |
|---|---|
Create |
This option creates a connection object under the domain controller in the specified site. The DN for the From-Server attribute is built by using the specified site and server name. The Enabled-Connection attribute is set based on the on/off parameter. The Schedule attribute is constructed by using the schedule parameter. Create behaves like Update if the specified connection already exists. |
Update |
This option updates a connection object under the domain controller in the specified site. The parameters for Update are the same as the parameters for Create. The specific connection object is found by searching for a connection under the site\server with a matching From-Server attribute. Update returns an error if the specified connection object is not found. Update reads the Schedule and Enabled attributes and performs the update only if there is a change. This means that the same Mkdsx.dat data file can be run repeatedly to try to create connections and only performs creates or updates as needed. |
Del |
This option deletes the connection object under the domain controller in the specified site. The specific connection object is found as described in the Update command. If there are duplicate connection objects with the same From Server attribute, all are deleted. In addition, if "*" is specified for the From Server attribute, all NTDS-Connection objects under the site\server are deleted. |
Dump |
This option dumps the attribute information for the specified connections and can be used to create connection object reports. |
Note: When Mkhubbchtop.cmd processes the Topo.dat file and creates Mkdsx.dat, it uses only the Create option in the Mkdsx.dat file. If you want to use one of the above options, in Mkdsx.dat, you must find the Create option and replace it with the option you want to use.
Creating the Server List File (Topo.dat)
To create the Topo.dat file:
Log on to HUBDC1, the domain controller that contains the Active Directory branch office scripts.
Start Notepad, and then open the Topo.dat file in the C:\ADBranch\BranchDC\Mkdsx folder.
On the /dc BH1 line, change BH1 to the bridgehead server you want to bind to when Mkdsx is run on the result file. This must be one of the well-connected bridgehead servers in the hub site. For example, to have the connection objects created on BH1, the line would read:
/dc BH1
Change the sample entries under "# list of hub servers for domain branches" to the names of your bridgehead servers in the hub site. Each bridgehead server should be represented, on its own line using the form:
Hub: Sitename\Bridgehead Server name
For example: hub: Hub\BH1
Note: Do not include the PDC Emulator, HUBDC1, in the list of bridgehead servers in this file.
Change the sample entries under "#list of branch office sites for the branches domain" to the names of your branch office domain controllers. The first domain controller for each branch office should be represented on its own line by using the form:
Bch: Sitename\Branch Office domain controller name
For example: bch: Site-Branch1\BODC1
Note: Only the first domain controller for each branch office should be listed in this file.
Review the other settings in the file to ensure that they are appropriate for your environment. The default settings should be appropriate for most environments.
Save the file as Topo.dat in the C:\ADBranch\BranchDC\Mkdsx folder.
The Topo.dat file for the sample topology used in this guide is as follows:
#
# A sample topo.dat input file might look as follows:
#
/REM This file was generated from topo.dat for <organization name>
/rem
/dc BH1
/repinterval 9 # replicate every 9 hours
# /schedoverride override.txt
/schedmask mask.txt
/hubredundancy 2 # Create connection objects in n different hubs that pull data from the same branch.
/bchredundancy 2 # create n connection objects in a branch that pull data from different hub machines.
/output mkdsx.dat
#/debug
/auto_cleanup
#
# list of hub servers for the branches domain
#
hub: Hub\BH1
hub: Hub\BH2
hub: Hub\BH3
#
# list of branches and domain controllers for the branches domain
#
bch: Site-Branch1\BODC1
bch: Site-Branch2\BODC2
bch: Site-Branch3\BODC3
bch: Site-Branch4\BODC4
bch: Site-Branch5\BODC5
#End of file
Creating the Topology File
The Mkhubbchtop script constructs a hub and spoke topology when given a list of hub servers and a list of branch servers along with parameters for the replication interval, hub redundancy, and branch redundancy. The output of Mkhubbchtop serves as input to the Mkdsx script that will be used to create the actual connection objects with the appropriate schedules.
To create the Mkdsx.dat file:
Open a command prompt, change to the C:\ADBranch\BranchDC\Mkdsx folder, and create the topology file by using the following syntax:
Mkhubbchtop Topo.dat
As the script progresses, output is displayed in the command prompt detailing the script's progress.
Verify that there is now an Mkdsx.dat file in the C:\ADBranch\BranchDC\Mkdsx folder with the current date and time.
Configure the Branch Domain Controller Installation Scripts
Some of the scripts included with this guide have some hard-coded settings that must be modified for your environment. This section steps you through the process of modifying all of the scripts that have hard-coded settings. These procedures should be performed on the domain controller on which you unzipped the Active Directory branch office ZIP file. By performing the changes on this server, you will be modifying the source files for the rest of your environment and therefore have to modify these files only one time. While building the staging site domain controller in the next chapter, you will copy the files from the domain controller to the staging site domain controller. From there, the files will then be copied to all of the domain controllers that are staged.
Note: These procedures should all be performed on the domain controller that contains the Active Directory branch office scripts.
Configure the Sethubdc.vbs File
The Sethubdc.vbs file is called by the Pre-Dcpromo.cmd file and configures an environment variable used later to source File Replication service (FRS) from.
To update Sethubdc.vbs for your environment:
Start Notepad, and then open C:\ADBranch\BranchDC\Sethubdc.vbs.
Change the computer names in the following lines to the computer names of your bridgehead servers. If you have more than three bridgehead servers, add additional lines for each bridgehead server.
HubServers(0) = "bh1"
HubServers(1) = "bh2"
HubServers(2) = "bh3"
Note: Do not include the PDC Emulator, HUBDC1, in the list of bridgehead servers in this file.
If you have more than three bridgehead servers, you will also have to modify the following line by changing 3 to the number of bridgehead servers that you have included in the list in the preceding step.
i = Int(3 * Rnd)
If you have more than three bridgehead servers, you will also need to modify the following line by changing 2 to the number of bridgehead servers that you have included in the above list, minus one. Therefore, if you have five bridgehead servers, you would change the value to 4.
Dim HubServers(2)
Close Notepad, and then click Yes when prompted to save the file.
Configure the Bodcpromo.txt File
The Bodcpromo.txt file is the Dcpromo.exe answer file for the staged domain controllers.
To update Bodcpromo.txt for your environment:
Start Notepad, and then open C:\ADBranch\BranchDC\Bodcpromo.txt.
In the following line, change Administrator to the user name of an administrator account in the domain:
UserName=Administrator
In the following line, change Adminpwd to the password of the administrator account:
Password=Adminpwd
In the following line, change branches.corp.hay-buv.com to the fully qualified domain name of the domain in which the administrator account used on the UserName= line exists:
UserDomain=branches.corp.hay-buv.com
In the following line, change branches.corp.hay-buv.com to the fully qualified domain name of the branch office domain:
ReplicaDomainDNSName=branches.corp.hay-buv.com
In the following line, change Staging.branches.corp.hay-buv.com to the fully qualified name of the staging site domain controller:
ReplicationSourceDC=Staging.branches.corp.hay-buv.com
Close Notepad, and then click Yes when prompted to save the file.
Note: Because the Bodcpromo.txt file contains the administrator password, the script runs after the Active Directory Installation Wizard deletes this file.
Configure the DNS-fwdx.cmd Files
The DNS-fwdx.cmd files, where x is a number, are called by Setfwddns.vbs file, which is called by the Run-Dcpromo.cmd file. These files configure the DNS forwarders for the branch office domain controllers.
To update DNS-fwdx.cmd for your environment:
Start Notepad, and then open C:\ADBranch\BranchDC\DNS\DNS-fwd1.cmd.
In the following line, change the IP addresses at the end of the line to the IP addresses of two of your root DNS servers, such as ROOT1 and ROOT2:
dnscmd %computername% /resetforwarders 10.10.1.1 10.10.1.2
Repeat this process for all six of the DNS-fwdx.cmd files. In each file, use a different combination of IP addresses, as shown in the example files.
If you have additional root DNS servers, create additional files for each combination of root DNS servers.
Close Notepad, and then click Yes when prompted to save the file.
Configure the Setfwddns.vbs File
The Setfwddns.vbs file is used to randomize the setting of the DNS forwarders for the branch office domain controllers.
Note: If you did not add additional DNS-fwd.cmd files in the previous procedure, this procedure can be skipped.
To update Setfwddns.vbs for your environment:
Start Notepad, and then open C:\ADBranch\BranchDC\Setfwddns.vbs.
In the following line, change 6 to the number of DNS-fwdx.cmd files in the C:\ADBranch\BranchDC\DNS folder:
i = Int(6 * Rnd)+1
Close Notepad, and then click Yes when prompted to save the file.
Configure the Stageco.cmd File
The Stageco.cmd file is used to create connection objects between the staging site domain controller and the branch office domain controller being staged.
To update Stageco.cmd for your environment:
Start Notepad, and then open C:\ADBranch\BranchDC\Mkdsx\Stageco.cmd.
In the following line, change STAGE to the name of your staging site:
echo BCH: STAGE\%Computername%>> stagetopo.dat
Close Notepad, and then click Yes when prompted to save the file.
Configure the Stagetopo.dat File
The Stagetopo.dat file is used to create the topology of the staging site domain controller and the branch office domain controller being staged.
To update Stagetopo.dat for your environment:
Start Notepad, and then open C:\ADBranch\BranchDC\Mkdsx\Stagetopo.dat.
In the following line, change Staging to the name of the staging site domain controller:
/dc Staging
In the following line, change STAGE to the name of your staging site and STAGING to the name of the staging site domain controller:
hub: STAGE\STAGING
Close Notepad, and then click Yes when prompted to save the file.
Configure the Pre-ship.cmd File
The Pre-ship.cmd file is used to help prepare the staged domain controller for shipment to the branch office.
To update Pre-ship.cmd for your environment:
Start Notepad, and then open C:\ADBranch\BranchDC\Pre-ship.cmd.
On each of the bridgehead servers, run repadmin /showreps, and record the ObjectGUID for each naming context for each bridgehead server.
Edit the following lines, changing the domain name and ObjectGUID for each naming context:
REM Replicate with Bridgehead DCs: BH1
repadmin -sync CN=Schema,CN=Configuration,DC=**corp,**DC=hay-buv,DC=com %computername% dea5a456-e7f3-4946-8c90-dfb4f0a53c9c >>pre-ship.log
repadmin -sync CN=Configuration,DC=corp,DC=hay-buv,DC=com %computername% dea5a456-e7f3-4946-8c90-dfb4f0a53c9c >>pre-ship.log
repadmin -sync DC=branches,DC=corp,DC=hay-buv,DC=com %computername% dea5a456-e7f3-4946-8c90-dfb4f0a53c9c >>pre-ship.log
REM Replicate with Bridgehead DCs: BH2
repadmin -sync CN=Schema,CN=Configuration,DC=corp,DC=hay-buv,DC=com %computername% 752c18b6-18e7-4365-8c81-7b5ec3e4edc1 >>pre-ship.log
repadmin -sync CN=Configuration,DC=corp,DC=hay-buv,DC=com %computername% 752c18b6-18e7-4365-8c81-7b5ec3e4edc1 >>pre-ship.log
repadmin -sync DC=branches,DC=corp,DC=hay-buv,DC=com %computername% 752c18b6-18e7-4365-8c81-7b5ec3e4edc1 >>pre-ship.log
REM Replicate with Bridgehead DCs: BH3
repadmin -sync CN=Schema,CN=Configuration,DC=corp,DC=hay-buv,DC=com %computername% 3f1334c7-ef2f-464c-827a-6f6f19db9e53 >>pre-ship.log
repadmin -sync CN=Configuration,DC=corp,DC=hay-buv,DC=com %computername% 3f1334c7-ef2f-464c-827a-6f6f19db9e53 >>pre-ship.log
repadmin -sync DC=branches,DC=corp,DC=hay-buv,DC=com %computername% 3f1334c7-ef2f-464c-827a-6f6f19db9e53 >>pre-ship.log
Close Notepad, and then click Yes when prompted to save the file.
Configure the QA_Check.cmd File
The QA_Check.cmd file is used to perform quality assurance checks on each server in your environment.
To update QA_Check.cmd for your environment:
Start Notepad, and then open C:\ADBranch\ADMonitor\QA_Check.cmd.
In the following line, change 10.10.20.99 to the IP address of the PDC Emulator domain controller, HUBDC1, on which the script will consolidate the results of the QA check (this must be the IP address of the server with the QAShare created in Chapter 2, "Building the Forest Root Domain and Central Hub Site"):
set HUB=10.10.20.99
Close Notepad, and then click Yes when prompted to save the file.
Summary
You have now created the hub and spoke topology for your branch office deployment. The ISTG is disabled at all sites, and the connectors between the branch sites and the hubs have been created in such a way that replication will not overload a single hub bridgehead server, but it will load balance among the bridgehead servers at the hub site. You are now ready to create the staging site and start the staging of branch domain controllers.
1200