2

Hi fellow technology enthusiasts,

I have some questions regarding the following setup. I hope you guys can help me out 😉.

Topology view

The goal is to link the redundant domain controller at a new building to the redundant domain controller in another building. Everything falls under the same domain (xyz.com). Therefor a new site (Site-B) has to be created with the new subnet (172.21.0.0/16).

The network devices at Site-B will have no access to the devices of the other site and vice versa. Only the domain controllers will be able to communicate with each other. Is this setup possible?

Currently the redundant domain controller at the old building resides in the default site Default-First-Site-Name with the default site link DEFAULTIPSITELINK. There is no subnet object created or linked to Default-First-Site-Name for the existing network range (172.20.0.0/16).

Note. The domain controllers at Default-First-Site-Name have Windows Server 2008 R2 installed and the domain controllers at Site-B will have Windows Server 2019 installed. The Forest and Domain functional level is Windows Server 2008 R2.

How I think we should proceed (Correct me if I’m wrong):

  1. Create Site-B with DEFAULTIPSITELINK as the site link, create the subnet object for this site (172.21.0.0/16) and link it to this site.
  2. Install the AD DS role on the Primary DC of Site-B and promote the server with following settings:

    1. Deployment Configuration:

      • Deployment Operation: Add a domain controller to an existing domain
      • Root domain name: xyz.com
    2. Domain Controller Options:

      • Specify domain controller capabilities: DNS server + Global Catalog
      • Site name: Site-B
  3. Configure the redundant DC

My questions for you:

  1. Will there be any downtime at the Default-First-Site-Name site?
  2. Do we need to create a subnet object for the computers in the Default-First-Site-Name site? If so, will this cause any downtime?
  3. Will the 5 FSMO roles remain located on the Primary DC in Default-First-Site-Name after linking both sites?
  4. If I understand this correctly, when a computer in Site-B starts up it will know in which site it resides thanks to the subnet object. If the computer can’t access the domain controllers in Site-B he will try to contact the domain controllers in the next closest site (in our case the ones in Default-First-Site-Name). Because network communication is only allowed between the domain controllers is there a way to prevent this behavior?
  5. At the moment you promote the first domain controller at Site-B it has to populate its own AD DS database using replication. This will replicate the AD DS database from the Primary DC at Default-First-Site-Name. Does this require much resources and network bandwidth? I know you have the possibility to install the database from media (IFM) but this will not work in our situation because we have an OS mismatch between domain controllers.

Are there any additional things we need to keep in mind?

Thank you in advance!

0

Your plan sounds good to me. I'll try my best to focus on answering your direct questions.

  1. Will there be any downtime?

No. Creating a new AD site will not cause any down time. The client DC locator process will ensure an available DC is used for authentication.

  1. Do we need to create a subnet object for the computers in the Default-First-Site-Name site?

Yes. Every subnet on your network should be mapped to the appropriate authentication site.

  1. Will the 5 FSMO roles remain located on the Primary DC in Default-First-Site-Name after linking both sites?

Yes. The roles will remain where they were. Changes to sites and site links will not move FSMO roles. These roles must be deliberately moved by a Domain or Enterprise Administrator.

  1. When a computer in Site-B can’t access the domain controllers in Site-B he will try to contact the domain controllers in the next closest site. Because network communication is only allowed between the domain controllers is there a way to prevent this behavior?

Yes. The DC locator process on the client will fail to LDAP ping the remote site DCs and will not choose them for authentication. Authentication will resume when the local site DCs are available.

  1. At the moment you promote the first domain controller at Site-B it has to populate its own AD DS database using replication. This will replicate the AD DS database from the Primary DC at Default-First-Site-Name. Does this require much resources and network bandwidth?

The primary payload for the initial replication is the Active Directory database (NTDS.DIT). Measure how large the DIT is currently, and that's about what you're going to use in bandwidth during the initial replication.

  1. I know you have the possibility to install the database from media (IFM) but this will not work in our situation because we have an OS mismatch between domain controllers.

If the DIT is huge then you could first build a 2008 Server DC in your new site, use install from media, and then build your 2019 DCs so their initial replication is with that 2008 local DC.

5
  • 1
    Thank you very much for your feedback! We are going to configure it in such a way that the clients of Site-B can't reach the DCs of the other site and vice versa. Next we will increase the priority of the SRV records (records with the lowest priority are used first) that contain the DCs at Site-B. This way nothing will change at Default-First-Site-Name, the clients at Site-B will have a 0.8 seconds delay during the DC Locator process because they will try to contact the DCs at Default-First-Site-Name but this is no problem. – Yves D. Jun 11 '20 at 9:35
  • Out of curiosity why wouldn't you want clients to be able to use Site-B as a backup if the network impacts access to the primary site DCs? Also, you can create 'Site-A' and delete the Default-First-Site-Name site after moving the Server objects and subnets over. Most people prefer to name sites after the geographic location they represent. But there's many ways to design it. If your network links are stable enough, you could even go with a single site. – twconnell Jun 12 '20 at 21:41
  • We want minimal change for Site A because it is a critical live environment and we don't want to cause any downtime by changing something. We could indeed create a new site with a correct name for the site but yet again, we didn't want to change anything that could potentially create downtime at site A. I also read that changing the site could create problems when clients for example don't have updated their registry entries containing the site they are in. – Yves D. Jun 15 '20 at 16:00
  • A note regarding the priority of the SRV records: because the records are dynamically updated it was not possible to change the priority of the SRV records. When I did this a new record would be created. We could disable this but we chose to let it like this because with disabling dynamic update we could introduce other problems. – Yves D. Jun 15 '20 at 16:04
  • @YvesD. As long as the client fails to LDAP ping the remote site DCs, the DC locator process will not allow them to connect for authentication. So I don't think manipulating SRV records is necessary. – twconnell Jun 16 '20 at 18:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.