I have a site with four buildings. All the workstations in each building are in their own VLAN. My two domain controllers are on a different VLAN, in different buildings though. The buildings are all connected together via fiber optic cable.

To provide redundancy, in case the inter-building link goes down, would I be better off installing a domain controller in each of the buildings with its IP address in the VLAN range of that building?

And then, in the DHCP server scope DNS settings, I would list the domain controller local to the VLAN first, and then the rest of them.

Four domain controllers seems a bit overkill, but would this configuration achieve the redundancy? Would the clients always try the "local" domain controller first, and then try the other ones?

But what I was thinking is if there's a way to get the clients automatically try the domain controller in the same building first.

Or maybe this is not that big of an issue? During day-to-day operation, it probably won't make a difference, since there is virtually no difference in response time between the domain controllers.

But if the link goes down, in the worst case scenario, the client tries three other domain controllers before actually trying the one that's local, and available.

I thought that maybe by setting the DNS server order, the client would try the domain controllers in the same order, but maybe I just got confused since I have DNS and DC in the same server anyway, but they really are two different things. And you said that Windows doesn't honor the order anyway.

If actually much simpler than that:

Within AD Sites and Services, create two sites, one each for the buildings that hold the domain controllers.

Then create subnets for all of the buildings and assign them to the approrpaite site.

Once that's done, the client will automatically try the DC in it's site first and then fail back to the other one.

For DNS, you can assign the 'closest' DC as the primary DNS server in your DHCP scopes for each building but as I said, Windows really does ignore the DNS order, but DNS is a fairly light load protocol anyway and with fiber connectivity, it's probably not worth the effort to try to restrict tht any futher.

You also need to make sure that you have reverse DNS zones for all of your subnets you configure in Sites and Services.

As to the site cost, with the small scope you have, you can probably leave the site cost at the default as the clients will still try the DC in their 'home' site first. IF you also have remote DCs over WAN connectivity then make sure you add Sites and subnets for them too and then you would do site costing to make sure the faster links have a lower cost than the slower links.

10 Replies

If so, then Windows will simply go down the list until it find one that responds.. Also Windows clients don't necessarily honor the order of your DNS, in may cases they simply try one and if it response, they run with it.

Now, if you are lookng to achive full resiliency in the event of a shutdown of the fiber, you will need a DC in each building, not just to handle DNS, but also to handle authentication. Being able to find the IP for a system is useless if you can't actually authenticate to it.

BUT, before you go down that path - what is the likelihood of a failure occuring in the fiber on your campus? Does it justify the added expense of equipment,licensing and management if they are then only able to access the stuff in their own building?

But what I was thinking is if there's a way to get the clients automatically try the domain controller in the same building first.

Or maybe this is not that big of an issue? During day-to-day operation, it probably won't make a difference, since there is virtually no difference in response time between the domain controllers.

But if the link goes down, in the worst case scenario, the client tries three other domain controllers before actually trying the one that's local, and available.

I thought that maybe by setting the DNS server order, the client would try the domain controllers in the same order, but maybe I just got confused since I have DNS and DC in the same server anyway, but they really are two different things. And you said that Windows doesn't honor the order anyway.

If so, then Windows will simply go down the list until it find one that responds.. Also Windows clients don't necessarily honor the order of your DNS, in may cases they simply try one and if it response, they run with it.

Now, if you are lookng to achive full resiliency in the event of a shutdown of the fiber, you will need a DC in each building, not just to handle DNS, but also to handle authentication. Being able to find the IP for a system is useless if you can't actually authenticate to it.

BUT, before you go down that path - what is the likelihood of a failure occuring in the fiber on your campus? Does it justify the added expense of equipment,licensing and management if they are then only able to access the stuff in their own building?

You will need to setup AD site and services will all the subnet and sitelink cost, this way the remote PC's will know which DC is the closest to them. other wise they will pretty much pick one at random (it not really random but close enough for your scenario)

You will need to setup AD site and services will all the subnet and sitelink cost, this way the remote PC's will know which DC is the closest to them. other wise they will pretty much pick one at random (it not really random but close enough for your scenario)

But what I was thinking is if there's a way to get the clients automatically try the domain controller in the same building first.

Or maybe this is not that big of an issue? During day-to-day operation, it probably won't make a difference, since there is virtually no difference in response time between the domain controllers.

But if the link goes down, in the worst case scenario, the client tries three other domain controllers before actually trying the one that's local, and available.

I thought that maybe by setting the DNS server order, the client would try the domain controllers in the same order, but maybe I just got confused since I have DNS and DC in the same server anyway, but they really are two different things. And you said that Windows doesn't honor the order anyway.

If actually much simpler than that:

Within AD Sites and Services, create two sites, one each for the buildings that hold the domain controllers.

Then create subnets for all of the buildings and assign them to the approrpaite site.

Once that's done, the client will automatically try the DC in it's site first and then fail back to the other one.

For DNS, you can assign the 'closest' DC as the primary DNS server in your DHCP scopes for each building but as I said, Windows really does ignore the DNS order, but DNS is a fairly light load protocol anyway and with fiber connectivity, it's probably not worth the effort to try to restrict tht any futher.

You also need to make sure that you have reverse DNS zones for all of your subnets you configure in Sites and Services.

As to the site cost, with the small scope you have, you can probably leave the site cost at the default as the clients will still try the DC in their 'home' site first. IF you also have remote DCs over WAN connectivity then make sure you add Sites and subnets for them too and then you would do site costing to make sure the faster links have a lower cost than the slower links.

Be aware though that using sites will by default slow down your active directory syncing between sites. If I remember correctly it was a default of 15 minutes. On a fiber link there is no reason to slow down replication.

But what I was thinking is if there's a way to get the clients automatically try the domain controller in the same building first.

Or maybe this is not that big of an issue? During day-to-day operation, it probably won't make a difference, since there is virtually no difference in response time between the domain controllers.

But if the link goes down, in the worst case scenario, the client tries three other domain controllers before actually trying the one that's local, and available.

I thought that maybe by setting the DNS server order, the client would try the domain controllers in the same order, but maybe I just got confused since I have DNS and DC in the same server anyway, but they really are two different things. And you said that Windows doesn't honor the order anyway.

If actually much simpler than that:

Within AD Sites and Services, create two sites, one each for the buildings that hold the domain controllers.

Then create subnets for all of the buildings and assign them to the approrpaite site.

Once that's done, the client will automatically try the DC in it's site first and then fail back to the other one.

For DNS, you can assign the 'closest' DC as the primary DNS server in your DHCP scopes for each building but as I said, Windows really does ignore the DNS order, but DNS is a fairly light load protocol anyway and with fiber connectivity, it's probably not worth the effort to try to restrict tht any futher.

You also need to make sure that you have reverse DNS zones for all of your subnets you configure in Sites and Services.

As to the site cost, with the small scope you have, you can probably leave the site cost at the default as the clients will still try the DC in their 'home' site first. IF you also have remote DCs over WAN connectivity then make sure you add Sites and subnets for them too and then you would do site costing to make sure the faster links have a lower cost than the slower links.

Excellent. Exactly what I was looking for. Thanks!

0

This discussion has been inactive for over a year.

You may get a better answer to your question by starting a new discussion.