Overlapping Boundaries within same site
Our SCCM hieracy in live is going to follow our DC topology in the fact that wherever a DC resides, a secondary SCCM site server will also reside, primaraly to use as a DP and a PMP.
Now not all of our subnets within each AD site can be considered as fast, so what we was thinking was to add the AD site name as a boundary to our secondary site servers (configure as fast), but then also add an IP subnet or range (that exisits within the same AD site) as a boundary on the same secondary site server, but configure as slow.
We was hoping that a PC that fell within this IP subnet (Slow), but also resides in the AD Site(Fast), would air on the side of caution and consider itself as a client on the end of a slow link with regards to processing it's advertisements.
Is there anyone else also trying to test what we are with regards to the overlapping boundaries on the same site server?
We beleive having overlapping boundaries (AD Site & IP Subnet/range) on the same site server is administratively a lot easier that having to add each individual IP Subnet/range as well as less chance of errors from communication breakdowns as any new subnet added will automatically fall under the boundaries of a secondary site server as it will exist within one of the AD Sites. Hope I have managed to explain what we are trying to achieve and the reasons for it.BTW We understand that overlapping boundaries on different SCCM sites within the hierarchy is a big no no, but we beleive that overlapping boundaries within the same site should be ok, please see the following lik for more info:
http://www.myitforum.com/forums/m_168544/mpage_1/key_/tm.htm#168583
Answers
In a single site scenario, if you have a fast boundary and a slow boundary, the slow boundary would take precedence over the fast boundary.
There isn't really a concept of overlapping boundaries within a single site.
Why do you have the IP subnet set as slow? Or is that the 512KB link?
By default, for Configuration Manager, we prefer DPs on the same subnet as the client. So, if I'm reading what you are saying correctly, then the client would prefer the branch DP over the DP in the secondary site as the branch DP is protected for the subnet the client is on.
Hi Kevin,
OK, I was able to track down someone to get an answer.
If all things were the same, then yes, we'd get the branch DP over the secondary site's DP. However, I've found out that all things are not the same :-(
If we have multiple DPs in the same selection criteria, then we prefer BITS-enabled DPs over SMB DPs.
Branch DPs are always SMB, not BITS-enabled. And if you have branch DPs, then you have to have a BITS-enabled DP. So, if the client is in both protected boundaries, then it is always going to prefer the BITS-enabled DP over the SMB (branch) DP.
That's a bummer, I was not aware we added this preference in. That means it is harder to ensure that the clients will use the branch DP if in both boundaries.
So, that's where it stands, hope it helps clear it up.
Wally
All Replies
In a single site scenario, if you have a fast boundary and a slow boundary, the slow boundary would take precedence over the fast boundary.
There isn't really a concept of overlapping boundaries within a single site.
- Perfect, that's exactly what I wanted to hear, it will make things so much easier for us and will reduce the risk of communication breakdown between AD Administrator and SCCM Admins
One more question on boundaries.
This is the scenario:
NOTES: AD Site "HQ" is made up of IP Subnets 10.8.100.0/24 & 10.6.100.0/24. The link speed between the client and the secondary is 1/2Mb, the link speed between the client and the BDP is 100Mb.
1 x Primary
1 x Secondary with protected Boundaries:
AD Site = HQ - Speed = Fast
1 x Branch Distribution Point with protected Boundary 10.6.100.0/24
1 x Client, IP = 10.6.100.10, (So this client falls under the boundary of the Secondary and BDP). How can I make it so that the client carries out software distribution from the BDP (100Mb), instead of the secondary (1/2Mb), for some reason it seems to be carrying out software distribution from the DP and not the BDP?
Typically on the secondaries we want to use AD Sites instead of IP Subnets as it is administratively easier and less prone to errors resulting from communication breakdowns between AD Administrator and SCCM Admin.
Why do you have the IP subnet set as slow? Or is that the 512KB link?
By default, for Configuration Manager, we prefer DPs on the same subnet as the client. So, if I'm reading what you are saying correctly, then the client would prefer the branch DP over the DP in the secondary site as the branch DP is protected for the subnet the client is on.
sorry i posted that incorrectly, thats the settings we used to have.
Have edited previous post
You need to have the IP subnet assigned somewhere, as you can only protect Boundaries that you have configured in the site :-)
If the client is assigned to the subnet, and that subnet is protected for the branch DP, then the client should prefer it. You'd also want to ensure that no deployments are allowed to fall back to an unprotected DP (if you have any).
So it should still prefer the BDP even if the client falls under the boundaries of the DP on the secondary site server?
The deployment did allow it to fallback to other DPs, I will try that change tomorrow.
The client will query the MP for location. It takes the returned list from the MP and sorts by:
Protected DPs
Those in the same IP subnet
Those in the same AD site
Those in the same Configuration Manager site
Those that are remote
What would win if the Client existed in the protected boundary of a Secondary Site Server (as AD Site) and also a protected boundary of a Branch Distribution Point (as IP Subnet)?
Our settings are:
Secondary Site Server - Site Code = HIG
-
Boundaries
-
High (AD Site) - Fast
-
10.6.100.0 (IP Subnet) - Fast. NOTE: This has been set to fast as there is a BDP within this IP subnet.
-
-
BITS enabled DP
-
Protected Site System
-
High (AD Site). NOTE: The AD Site "High" contains 2 IP Subnets, 10.8.100.0/24 & 10.6.100.0/24
-
Branch Distribution Point - Linked to DP on HIG
-
Protected Site System
-
10.6.100.0 (IP Subnet). NOTE: This subnet is also part of the AD Site "High"
-
If I deploy a package to a client within 10.6.100.0, I want it to use the BDP as it is closest to the client, however with the above settings the client see the locations available for the package, but it decides to download the package from the Secondary DP instead of the BDP. If I remove the protected Site System boundary from the Secondary Site System, the package downloads from the BDP no problem.
This creates another problem though as I don't want any other clients at any other site trying to download content from anything other than their most local DP. I know this will mean that if one of our DP's goes down that we lose the Software Deployment feature at that site, but I don't see it as an issue as restoring a Secondary Site Server should be achievable within 24 hours.
I want to ensure that traffic created via Software Distribution stays as local to the client as possible at all times.
Is what we want achievable? or does it go against best practice?
-
Well, given that I've always been told that in Configuration Manager, we prefer IP subnets over AD sites, I'd have thought that the client would still use the branch DP over the secondary site's DP in that case. But that is not what you are seeing.
If know if there are multiple DPs in the same selection criteria, we do random selection. And I thought that even within the protected category, we still sorted by IP subnet, then AD site, then SMS site, etc. But maybe it is that all protected ones are just the category, so then we are doing random selection at that point. I'll have to check. If so, then that makes sense that the client COULD select the secondary site server's DP over the branch DP.
If what you are seeing is correct, then the only way to achieve what you want is to have completely unique boundaries for the secondary site server and the branch DP. It is a best practice to have content accessed from DPs as closely to the client as possible.
Thanks for the reply Wally.
If possible could this be clarified?
Our SCCM structure follows our AD design, so we wanted to use AD site to define fast boundaries and then use IP subnets to define slow boundaries or boundaries where a BDP existed.
After reading through the Microsoft documentation, we thought this was achievable, but as you can see from our results, this doesn't seem to be the case.
- I'm trying, but finding a lot of people are already off on vacation this week. So still working on it, but not sure when an answer will come in. As soon as I get a confirmation either way, I'll post.
Hi Kevin,
OK, I was able to track down someone to get an answer.
If all things were the same, then yes, we'd get the branch DP over the secondary site's DP. However, I've found out that all things are not the same :-(
If we have multiple DPs in the same selection criteria, then we prefer BITS-enabled DPs over SMB DPs.
Branch DPs are always SMB, not BITS-enabled. And if you have branch DPs, then you have to have a BITS-enabled DP. So, if the client is in both protected boundaries, then it is always going to prefer the BITS-enabled DP over the SMB (branch) DP.
That's a bummer, I was not aware we added this preference in. That means it is harder to ensure that the clients will use the branch DP if in both boundaries.
So, that's where it stands, hope it helps clear it up.
Wally
I can understand why BITS enabled DP is preffered over a SMB DP, but for our scenario (and I am sure plenty of other companies) that have based there SCCM Infrastructure around the AD Infrastructure design, this is probably a step backwards.
I now think that we have no choice, but to explicitly use IP Subnets as boundaries on all of our Secondary's and IP Subnet on the BDP protected boundary.
It's a shame this is the case because it is administratively harder and there is now a greater chance of clients becoming unmanaged or managed via an incorrect site because of communication breakdown.
Thanks for clarifying this for us though, we thought we was going mad.
- Agreed. It is more administration effort to use subnets instead of AD sites :-(
