Hi,

would like to seek your advise for my CM12 boundary setup.

Current AD subnet configuration is match with client computer's, e.g. one of AD site subnet configuration is 10.197.0.0/16 but the DHCP scopes on that site are:

do I have to add each of subnet into the boundary or the magic CM12 AD forest discover will offload my work?

Hi,

I would create a IP address range boundary instead, 10.197.1.0 - 10.197.9.254, that is the easiest way.

Regards,
Jrgen

Well, as far as i remember you are covered with that assignment you created there.

At least i have an implementation where i implementet 172.16.0.0 which covers both my 172.16.1.x and 172.16.4.x :)

I would not do as you have been advised to do with creating subnets, the reason you can find bby reading this blogpost. :)
http://blogs.technet.com/b/configmgrteam/archive/2013/03/01/when-not-to-use-ip-address-ranges-as-boundaries-in-configuration-manager.aspx

/Morten

I would not do as you have been advised to do with creating subnets, the reason you can find bby reading this blogpost. :)
http://blogs.technet.com/b/configmgrteam/archive/2013/03/01/when-not-to-use-ip-address-ranges-as-boundaries-in-configuration-manager.aspx

That blog post is based purely on performance -- IP Address ranges are much more costly than the other two boundary types during content lookup on the SQL Server and so *if* everything is rationale and you have large numbers of subnets, using IP Subnet or AD Site boundaries is prefered.

Boundary creation can be a time consuming task for sure -- but, it's not necessarily supposed to be easy -- some things in life and work just take time and elbow grease.

Without knowing all the gory details of your network, it's nearly impossible to recommend a strategy for you.

AD Forest Discovery will create IP Address Range boundaries for you based upon the subnets in AD -- you will still have to group then into Boundary Groups though. As long as all the subnets are well-defined in AD, then you should be able to use this functionality.

How many primary sites are you going to have? If just one, then as long as your DP placement matches your AD Sites, there's no reason you can't use AD site boundaries though. With the separation of content and site assignment into two different type of boundary groups, this makes it much easier to design. You would simply create one all encompassing IP Address Range boundary for site assignment (which is the only time AD site boundaries have potential issues) and then use your AD sites for the content location boundaries.

I have 14 primary site and a few protected DPs.

Not in ConfigMgr 2012 you don't. The maximum is 10 (within a single hierarchy) and that would be far from a smart thing to do anyway.

The number use case for having multiple primary sites in 2012 is support of more than 100,000 clients -- all other use cases are minor and should not be considered.

Using aggregated subnets like that in your AD site's subnets is fine (although technically not supported) as long as you are not using IP subnet boundaries and are using AD Site boundaries for everything.

Frankly I've used AD Site boundaries with great success in the past. As a matter fact for years that was the only way I did boundaries. Since you have all class C subnets so long as the clients are getting 255.255.255.0 as the subnet mask I think you'd be fine.

I have 14 primary site and a few protected DPs.

Not in ConfigMgr 2012 you don't. The maximum is 10 (within a single hierarchy) and that would be far from a smart thing to do anyway.

The number use case for having multiple primary sites in 2012 is support of more than 100,000 clients -- all other use cases are minor and should not be considered.

Using aggregated subnets like that in your AD site's subnets is fine (although technically not supported) as long as you are not using IP subnet boundaries and are using AD Site boundaries for every

Thanks John.

I would agree with you if I had a well-maintained AD subnets.

one of example that I pull from AD subnet is shown in below

AD subnets

DCHP scopes are

with such configuration, do you think it would be still working fine with AD subnet boundary ?

"supposedly" you could have problems. In the real world, I never saw problems BUT I had a really good network guy and he made sure that the subnet mask on the client and what was in the AD site matched. The problems will happen when someone gets lazy and puts in for instance 10.198.0.0/16 however the clients get something like 10.198.1.50/255.255.255.0 (or something like that, I've only read about what causes the problem, I've never actually had it)

Interesting, that must have changed with SP1.

To bring up the old question though -- which isn't related to boundaries -- do you have 300,000+ clients (100,000 for each primary)? As mentioned, that is truly the only reason to have multiple primary sites. Using multiple primary sites and thus SQL replication introduces all kinds of nasty latency (both administrative and operational) that is to be avoided at all costs IMO and IME.

I don't think number of computer is the only reson i should considered when creaingt multiple primary sites. For this project, some of business unit wanna own the solution as they spouse the project. They want their own IT to manage local site independently. Second reason is to eliminate single point of failure Third reason is that I am expecting file base replication in SP1 giving us Good site replication experience like we all had inCM07 One step back, even if I choose single primary site, I still need put secondary site servers for those large sites, then I still can't run away from the site re

For 2000 computers, this would be a good conversation...

I assume you want to use a secondary site rather than a DP because you want those clients to have a local MP? To clarify MP's do not adhere to boundaries so the only way to get a local MP in those locations is by having a secondary site. Traffic to the MP has always been pretty small. IMO the proxy MP never really saved us much bandwidth in 2007 and earlier versions. A DP can support up to 4000 clients so technically you can get away with only a DP for 2000 clients but that may not mean you should. This decision would probably come down to many deciding factors but primarily WAN link speeds. The secondary site will most likely only hold two roles, the MP and the DP so what we are trying to determine here is if the additional infrastructure is required to simply reduce the load on those WAN links. Personally I'd probably try without the secondary site first and add one if I saw poor performance. But to answer your question is it justifiable? I definitely wouldn't say it's not justifiable.

Now let's talk about the "redundancy" aspect of your design. I'm gonna try to drive this point over and over...ALL ADMINISTRATION SHOULD BE DONE FROM THE CENTRAL ADMINISTRATION SITE (CAS). Having said that when using a single primary site you should build in some redundancy into that site by offloading site roles etc. However CM has never offered a true HA solution. My point here is if the CAS dies everything is down anyway so I don't think you are buying yourself anything as far as redundancy by adding those primary sites. Admins should not be performing administrative tasks at those child primary sites anyway. The docs clearly state that primary sites are for scale out ONLY. They are not intended to provide any type of HA or redundancy nor are they intended to provide administrative segregation and when properly used they don't even offer any around either of those scenarios. There is no legitimate reason to ever have more than a single primary site unless you have over 100k clients.

To add another aspect to this, please define down and also define the impact of down?

Garth finally put into words what I've been trying to intimate and what the product team's view of this is in the following thread: http://social.technet.microsoft.com/Forums/systemcenter/en-US/83cf70c1-886b-4c23-a327-f350101a9b43/sccm-central-site-high-availability

Essentially, this notion that ConfigMgr is somehow business critical *and* it not being available for a few hours is actually going to cost your organization any money is not reality. ConfigMgr is not a service users rely on to be there every second of the day nor does it need to be. See Garth's post for more.

For 2000 computers, this would be a good conversation...

I assume you want to use a secondary site rather than a DP because you want those clients to have a local MP? To clarify MP's do not adhere to boundaries so the only way to get a local MP in those locations is by having a secondary site. Traffic to the MP has always been pretty small. IMO the proxy MP never really saved us much bandwidth in 2007 and earlier versions. A DP can support up to 4000 clients so technically you can get away with only a DP for 2000 clients but that may not mean you should. This decision would probably come down to many deciding factors but primarily WAN link speeds. The secondary site will most likely only hold two roles, the MP and the DP so what we are trying to determine here is if the additional infrastructure is required to simply reduce the load on those WAN links. Personally I'd probably try without the secondary site first and add one if I saw poor performance. But to answer your question is it justifiable? I definitely wouldn't say it's not justifiable.

Now let's talk about the "redundancy" aspect of your design. I'm gonna try to drive this point over and over...ALL ADMINISTRATION SHOULD BE DONE FROM THE CENTRAL ADMINISTRATION SITE (CAS). Having said that when using a single primary site you should build in some redundancy into that site by offloading site roles etc. However CM has never offered a true HA solution. My point here is if the CAS dies everything is down anyway so I don't think you are buying yourself anything as far as redundancy by adding those primary sites. Admins should not be performing administrative tasks at those child primary sites anyway. The docs clearly state that primary sites are for scale out ONLY. They are not intended to provide any type of HA or redundancy nor are they intended to provide administrative segregation and when properly used they don't even offer any around either of those scenarios. There is no legitimate reason to ever have more than a single primary site unless you have over 100k cli

Thanks Jason.

when I mentioned "down", it means that the whole BU site down.

I do agree with you that CM not suppose to be a critical solution especially in CM07 or SMS time.

In this project, there is a high expectation for application self-service portal. Initially I was thinking publish BU app to local application catalog to reduce the risk. 

Basically, you're introducing complexity that *will* introduce noticeable and impactful latency into *every* activity you perform administratively and will delay every operational activity also to prepare for a black swan event which can be handled by a simple backup and restore within 4-8 hours.

Also, the levels of HA in *every* component/role of ConfigMgr (except the site server itself) means that if properly designed, even if you were to lose the site server, the down time would be completely transparent to the end user including application deployment from the app catalog. 

after 2 rounds discussion with Microsoft, the decision goes to multiple primary sites. there is no right or wrong suggestion in this post, just somehow I could not post all customer info & concerns into the forum and it leads to have different suggestions in this discussion. I would take note each of them for my future design and I'm sincerely thanks for the contributions from each of you. 

I was highlighted for the potential site db replication issue which I have encountered in my previous cm12 project with multiple primary sites. i have accumulated some experiences over there and I hope it will help for this project too.

Thanks for viewing.