So as the title asks, How does end machines know which DC is the closest? Is this even done / possible? Or is it purely based on DNS servers in the DHCP scope?
Lets say I have 2 x domain controllers. One DC is in one office and another DC is in another office. The offices are far apart (over 100ms). DNS lookup on the domain.local returns both DCs. DHCP scope provides the closest DC in the primary DNS on the end machines.
What determines which DC is used for logging in / GPO / domain functions? Is it the DNS server or does the machine do a DNS lookup on the domain and go from there?
I'm just wondering what stops the machines connecting to / preferring a remote DC instead of one which is geographically local?
This article goes into much detail about the process and explains it way better than I ever could.
http://blogs.msmvps.com/acefekay/2010/01/03/the-dc-locator-process-the-logon-process-controlling-which-dc-responds-in-an-ad-site-and-srv-records/
In our environment, things are entirely and thoroughly fooked to the point where we have to have ANY device needing AD services for logon to be able to reach ANY domain controller. We do not currently have good management in our AD Sites and Services.
Given the size of Massive Global Multicorp AG where I work, this makes for some MASSIVE groups on every segmentation firewall..
Wow thanks for the link! I have some reading to do!
So looking into this, it seems we do need to do it. Although have not seen any negative impact at the moment.
The single biggest question I have and I've not been able to find out the answer relates to the "AD Sites / Services" portion. So what happens here is that you create the remote site in Microsoft AD, and you specify the remote network(s). Here's the confusing part, I have seen forum posts where people are specifying the remote /24 or a couple of remote /24's. In my design I give each site a /20 and then carve this up into separate /24's as needed.
My question is, in AD Sites Services - can I specify the /20 here or do I need to specify every /24? This info is used by each workstation. The workstation looks at it's subnet and then works out which DC it should used based on the AD Sites Services. Is the workstations clever enough to realise that 192.168.37.0/24 is part of 192.168.32.0/20?
Lastly, if I were to move a DC into a site, what is the impact to the existing / rest of the network - not seen any mention of that either. Guess it's needs to be done in a change window.
In your situation since the /24's are carved up out of the parent /20 for each site then you would specify the /20 to the site it belongs to in AD Sites and Services.
When you move a DC between sites the only thing that would be affected is the users in the subnet of that site if that was the only DC in that site.
Once it's set up, you can do a logon trace from a Windows machine (not a packet capture, it's a command line thing... can't remember the command, but it's there...) and see which DCs it's hitting for logon services.
Quote from: deanwebb on June 28, 2016, 07:57:53 AM
Once it's set up, you can do a logon trace from a Windows machine (not a packet capture, it's a command line thing... can't remember the command, but it's there...) and see which DCs it's hitting for logon services.
echo %logonserver% ......There are other commands that will get the same result plus more information, but that is the simplest if you just want the name of the "logon" DC.
That's the one. Doing that on one of our boxes will deliver a list 30-40 servers long. We have a bit of an issue in our AD Sites & Services...
:kiwf:
Thanks guys and thanks for the info about the subnet - that makes my life a jagillion times easier.
I know I need to do this because echo %logonserver% reports my server is in Sri Lanka. But like I said, I haven't seen any impact at all, my machine is working the same as before the server was installed. This might be fine at the moment because the Riverbeds are optimising this traffic. I'll get this prepped now I know I can use the /20 for simplification and then move the DC in AD over a weekend.
Just keep in mind that there is some traffic that just has to bypass the Riverbed and go on through.
Done this recently, watched a training video on CBT nuggets. Easy peasy.
Steps:
1. renamed "default first site" to "CITY"-ROOT
2.Created new site
3. created the subnets in the /20, and assigned all of those to their respective sites
4. moved the new site's DC and Riverbed into the new site in AD
5. logged off and logged on using a test machine and then issued "echo %logonserver%" again and confirmed the logon DC had changed to the local DC
6. boasted about about great I am to my boss
7. made tea.
8. steps 6 and 7 are lies
9. step 8 is true
:)
Well, as long as steps 1-5 worked, you got a good deal going. 8)
Wait so you didn't make us all tea? :(
:problem?:
My concern was making the changes during the day and scuffing up logged in users. But seems the config only takes affect when logging in, not unlocking your computer.
tbh I dont drink that much tea anymore. Used to be on 10 or 20 cups a day, because we'd take turns in making tea and so whilst you were fully involved with a job (you know when you don't really notice anything going on around you because your face is glued to the screen) then a cup of tea would be placed on your desk; sometimes without you noticing.
I've tried to start tea rounds before, but you can't actually ask or tell someone to make you one. You just have to keep making them one until they feel guilty enough to repay the favour
:rofl:
This is why I have a 52-oz cup with a lid and a straw and don't mind drinking room-temperature diet cola. One visit to the fridge or convenience store in the morning, and I'm good all day.
To get back on topic, I hate Active Directory some times. And then, other times, I love it. I am never ambivalent about Active Directory. It brings out the passion in me.
I've hated Active Directory ever since that day when I built my 2003 server demo and added my home PC to the domain running with the default domain policies.
:zomgwtfbbq: