Protected Branch Distribution Point Using a Duplicate Boundary
My subject line may not sufficiently describe what I am asking, so I hope this clears it up: Up until now, we have had two site boundaries, a "LAN" and a "WAN" boundary, where all of our WAN sites are added to the WAN boundary. To ease the number of subnets added we used 10.20.0.0/16 for one of our WAN subnets (most of our remote sites fit into this category). We are now in the process of configuring a branch distribution point for our largest remote site and need to protect the distribution point so that only clients in the 10.20.41.0/24 subnet can connect to it. My question is this: Does leaving the larger subnet as-is affect how the clients will see and respond to the protected branch distribution point, or do I have to remove the larger scope and add each one individually? I want to avoid that, but need to make sure there isn't an issue with the 10.20.41.0 subnet being in two boundaries. Thanks in advance - let me know if I need to clarify anything. Brandon
October 21st, 2008 5:35pm

The client should specify its IP subnet, and AD site when looking for DPs. If one of those matches the protected boundary, it will use that. If not, then it will look at the IP subnet value first, then the AD site next. Does that answer it?
Free Windows Admin Tool Kit Click here and download it now
October 21st, 2008 7:32pm

It does - I also found that it looks at the smaller subnet designation first. Once I created the boundary and added it to SCCM, the client computers that were a part of the subnet changed their designation to be part of the new boundary (the one that is the smaller subnet range). Thanks for the confirmation! Brandon
October 22nd, 2008 10:10am

What if I only have one boundary (one AD boundary)? The subnetting in AD sites and Directories is set to a Class A for some reason. I did not set the BDP's to be protected. Will a remote client try to use any possible BDP? Thanks
Free Windows Admin Tool Kit Click here and download it now
August 27th, 2012 12:04pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics