A few references that may help:
https://blogs.technet.microsoft.com/askds/2011/04/29/sites-sites-everywhere/
https://technet.microsoft.com/en-us/library/2009.06.subnets.aspx
This is how I’m reading you have it setup; please correct me if I’m wrong. ☺
AD Site 1 (main office), with following subnets defined and associated:
10.0.0.0/8 (catch-all)
172.16.0.0/16 (catch-all)
192.168.0.0/16 (catch-all)
192.168.17.0/24 (actual subnet)
AD Site 2 (AWS) with the following subnet defined and associated:
10.0.0.0/16 (actual AWS subnet)
If that’s correct, (and AD Sites & Services at both sites shows it as such),
you should have the desired behavior. However, if there is an old/incorrect
site locater DNS record (see first link), you may get unexpected results till
it gets cleaned up.
DAMIEN SOLODOW
IT Engineering Lead
317.447.6033 (office)
HARRISON COLLEGE
From: [email protected] [mailto:[email protected]] On
Behalf Of Michael B. Smith
Sent: Tuesday, February 7, 2017 4:44 PM
To: [email protected]
Subject: RE: [NTSysADM] Blocking AD Client Traffic to a Certain Site
I’m sorry, I don’t have time to look it all up and cite chapter and verse.
Perhaps Brian can chime in and he has it all handy.
If you try it as I suggest, I bet it’ll work.
My team’s out.
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Charles F Sullivan
Sent: Tuesday, February 7, 2017 4:01 PM
To: [email protected]<mailto:[email protected]>
Subject: RE: [NTSysADM] Blocking AD Client Traffic to a Certain Site
Thanks. I just spotted a typo I made where I should have typed
“192.168.17.0/24<http://192.168.17.0/24>”. Unless you are referring to that, I
don’t see how I’m not using the catch-alls as intended.
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>]
On Behalf Of Michael B. Smith
Sent: Tuesday, February 7, 2017 3:00 PM
To: [email protected]<mailto:[email protected]>
Subject: RE: [NTSysADM] Blocking AD Client Traffic to a Certain Site
Catch-all subnets (also known as supernets) are absolutely supported, but you
are not using them the way they were intended.
TL;DR; have a separate subnet for the AWS site and everything will be peachy
(except when/if all AWS DCs are down).
Brian’s book has great coverage on these topics, but it’s really 3 different
topics. You need to understand “catch-all subnets”, “automatic site coverage”,
and the “DC locator process” – especially what happens to a computer that was
moved between AD sites. Those are 3 search terms that will give you great
information.
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Charles F Sullivan
Sent: Tuesday, February 7, 2017 2:34 PM
To: [email protected]<mailto:[email protected]>
Subject: RE: [NTSysADM] Blocking AD Client Traffic to a Certain Site
I’ve only been able to do very limited testing.
- I had about 8 member servers in a site which were actually all in
the same subnet as each of and the one DC we had for testing, let’s call the
subnet 198.168.17.0/24<http://198.168.17.0/24>. In that site I included the
usual private ranges: 192.168.0.0/16<http://192.168.0.0/16>,
172.16.0.0/12<http://172.16.0.0/12> and 10.0.0.0/8<http://10.0.0.0/8>
- At AWS I had a subnet with one DC and just a couple of member
servers in the 10.0.0.0/16<http://10.0.0.0/16> subnet, which was defined as the
only AWS site.
Note that the AWS subnet is a subset of one that I defined at the main site,
but this absolutely is supported by MS and others have told me that this works
for them. Despite all of this I did see one member server in the main site use
the AWS DC after a reboot even though the local DC was clearly present and
being used by the other member servers. So that means 1 out 8 member servers I
had for testing crossed sites. This made me wonder how often it might happen in
our production environment where there are thousands of member computers.
I do have to say that I recently got to test this again, this time having 5 DCs
at the main site and 2 at AWS. Again, I had just a handful of member servers
and a workstation and this time I didn’t see any of them using an AWS DC. The
AWS admin didn’t see his one member server use anything besides an AWS DC.
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>]
On Behalf Of Michael B. Smith
Sent: Tuesday, February 7, 2017 1:32 PM
To: [email protected]<mailto:[email protected]>
Subject: RE: [NTSysADM] Blocking AD Client Traffic to a Certain Site
Doesn’t make sense to me.
The only reason you should have cross-site connections at this point is because
you don’t have all of the relevant subnets defined in ADS&S.
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Charles F Sullivan
Sent: Tuesday, February 7, 2017 11:40 AM
To: [email protected]<mailto:[email protected]>
Subject: [NTSysADM] Blocking AD Client Traffic to a Certain Site
I’d like to get some ideas and opinions regarding this, especially if anyone
has had a similar need…..
Our AD topology to this point has been as simple as can be. Since just about
everything on our extended network is connected at high speeds, we have never
had to have more than one AD site. We are about to put a couple of DCs at AWS,
which of course will require a second site to be defined. This will still be
pretty straightforward. Everything but AWS will be on the one existing site and
a second site will be added for the one subnet at AWS.
I know that even with the two sites defined, some clients may at times use the
remote site. This is what I have seen in testing, for whatever reason, but I
don’t consider it to be a real problem because I assume it would not happen
often. The problem is that our director wants absolutely no cross-site traffic
except in the case of a disaster.
It is being proposed that the firewall between the sites allow only AD traffic
between the DCs themselves. AD clients would be stopped at the firewall. I’m
not comfortable with that as a solution because I’m concerned that when clients
do try to use DCs at the remote site, it will cause slowness if not failure.
Does this seem like a bad idea for that or any other reason?
I was thinking that maybe I could use weight and priority within SRV records so
that the DCs at AWS would be weight=0 and priority=65535. If I did that, would
the clients at AWS honor the site rules over the SRV records weight and
priority? I’m guess that would be unpredictable, thus also not a good solution.
Thanks in advance for any help.
Charlie Sullivan
Sr. Windows Systems Administrator
