I've done about two dozen SCCM deployments over the last several years. However they have all been pretty much single domain, single primary deployments.

I'm presented with the challenge of deploying this to a site with many sub domains in the environment. Each site has it's own sub domain and they would like as much as possible to be local to the site in their SCCM environment. I'm looking for suggestions from some experts who have actually done this configuration before.

My thought was to install the primary at the Colo and child primary sites at each site.

domain.com --- CAS, primary and SQL

sub1.domain.com --- child primary site, SQL Express is being requested (what are the limitations)

sub2.domain.com ---- child primary site, SQL Express

In this configuration I would need all files to be local to the child primary server and not propagate to the primary at the colo. So when applications, driver packages, operating systems, WSUS are created and configured the source and ALL SCCM files would stay local to the site. I would also need all Reporting to be centralized for all sites.

Let me know your thoughts.

Thanks

1. How many clients?

2. You cannot use SQL Express for Primary Sites

It could be possible to deploy a single primary site and manage permissions using RBAC.

"In this configuration I would need all files to be local to the child primary server and not propagate to the primary at the colo. So when applications, driver packages, operating systems, WSUS are created and configured the source and ALL SCCM files would stay local to the site."

What is the business driver 

They have about 5000 clients at 25 sites. I believe a Secondary can use SQL Express but I don't think a Secondary would meet the goals.

The need for local files is primarily due to bandwidth however there are also autonomy concerns and how they are one company but separate in many ways.

Hi,

For the scenario of setting up a CAS, please refer to the Jason and others posts in the thread below.

https://social.technet.microsoft.com/Forums/en-US/0abc4f13-9dc8-4bdf-92b7-daf20563a463/system-center-2012-and-cas?forum=configmanagergeneral

Moreover, you can use RBAC for delegation of administration for site.

The need for local files is primarily due to bandwidth however there are also autonomy concerns and how they are one company but separate in many ways.

What exactly do you mean by autonomy? Primary sites are NOT security boundary. There an admin at one site can affect things at another site.

I've been doing more research on my end and it looks like a CAS Server with child primary sites is the right direction. Then each site will have their own environment for their applications, drivers for their specific system models for OSD. I just wasn't sure how the communication happen between these remote sites and the CAS. Permissions will need to be defined for the CAS Server, CAS SQL Server, Primary Server and Primary SQL Server. RBAC will also need to be configured for the local site sccmadmin account.

Thanks

• Marked as answer by phretbuzz Wednesday, January 28, 2015 3:04 PM

That's simply an incorrect assertion. Primary sites do *not* provide separate "environments" or separation of any kind. Primary sites are for scalability (in terms of client count) only. RBA (seemingly semantics but actually an important distinction, RBAC does not exist in ConfigMgr) will provide the separation.

You never answered Gerry's question though: why does each need their own set of files?

I mentioned this above, "The need for local files is primarily due to bandwidth however there are also autonomy concerns".

They would like each site to have their own primary so when they configure applications, OSD, etc... it's going to stay local on their server and DP. They don't want to have everyone come back to colo and utilizing the same Primary server with delegation configured. With that configuration they would then have their source files local, copied over the WAN to the Primary in the colo when building packages and then copied back down again to their DP's. Building secondary's would also have this limitation. Building a CAS Server with child primary's connecting to the CAS seems to make the most sense. The only updates that would be coming back would be SQL Updates to the CAS Server for centralized reporting.

I discussed with a Microsoft resource yesterday and confirmed that this was the case.

Yes this is the case; however, compared to the pain, complexity, perf degradation, and additional latency introduced with everything you do when a CAS is involved, this issue is minor and to have it dictate your architecture is not a good idea.

"The only updates that would be coming back would be SQL Updates to the CAS Server for centralized reporting. "

While a true statement is general, this seriously under-emphasizes the true complexity and scope of what happens behind the scenes which is truly non-trivial and the source of many complex issues best avoided at all costs -- this is based on real-world experience.

Jason, what issues have you seen with the CAS model deployment? I built this in my lab and didn't seem to find any issues, however lab and real world are not the same. I'm my deployments in the past I have avoided it as well because I thought it was overkill. However in this scenario it seemed like the right choice given the requirements.

I called them out explicitly above: complexity, perf degradation, and additional latency in all admin tasks. SQL replication is a very complex beast understood by very few folks that adds a lot of overhead and a possible major failure point leading the to the possibility of things going very wrong -- which I've seen first hand multiple times.

A lab cannot properly simulate a production environment with respect to these things because you don't have the same load, usage, or limitations.

All of this just to avoid some WAN replication, which can be controlled, and some "my precious files" posturing is the wrong prioritization IMO. To avoid the double replication, an RDSH (aka Terminal/Citrix server) placed near the primary site and hosting the admin console for all admin users works quite well.

Thank you for the information Jason.

Just curious so I understand what's going on under the covers. If I have a local child primary and doing my tasks of application deployment, Software Update Deployments, OSD, I would think that it would give me acceptable performance.  And if I scheduled my SQL replication after hours, which I would think (without having configured this in production before) would be handled by Configuration Manager and wouldn't require a DBA to configure replication it "theoretically" should work. Is this not the case?

Yep, it works fine, not just in theory, but in practice. Many folks successfully use multiple primary sites and a CAS. They do it because they are forced to by scalability limitations though.

The risk of issues is greater with more moving parts as is the perf hit, additional latenecy, and general added complexity. Prioritizing these under one-off replication which can be scheduled and controlled and some concern over control of files and content is the wrong decision IMO which will lead to issues IMO.

They would like each site to have their own primary so when they configure applications, OSD, etc... it's going to stay local on their server and DP. 

That assumption is not 100% true. Everything that an admin creates in the console (e.g. packages, applications, task sequences etc) is considered "global data" and will be replicated to the CAS which in turn replicates it to all other primary sites. Distributing content is a different story though and does not differ from a CAS / non-CAS scenario. 

Just an addition to the pain points Jason already mentioned: don't forget about upgrading ConfigMgr (service packs, R-releases, CUs etc). This has to be done on each site. 

There is no way to control the data so what Site A configures on it's primary does not get propagated to primary Site B?

Well, it depends upon what you mean by "data".

Content, yes, mostly. "Mostly" because there's no reason someone from B couldn't distribute a package from site A to its DPs.

Client information, yes. Client information stays on the primary and only replicates to the CAS.

Configuration, no. All configuration data replicates everywhere. Configuration includes information about content, just not the content itself.

Jason and Torsten, thank you for your suggestions and sharing your experience. I value information found on technet and other sites but nothing beats another persons experience working with a specific product and in this case a specific design.

I also configured this in my lab to see exactly what propagated. It's a shame Microsoft didn't write this to give you the option as to whether you wanted global propagation or just one way replication from primary to CAS. That would have been a better design. Security Scopes help, but they only get you 90% there and still have limitations.

Due to the SQL global replication design and the reported latency and performance issues we've gone in a different direction.

Thanks for the info.