Multi-Site SCCM Infra Design Question - DPs

[slice16]

Afternoon all!

 

Please can someone point me in the right direction with an SCCM design I am currently contemplating? We are currently running a project where we are automating the deployment and configuration of servers within our on-premise and Azure subscription. There will be significant automation workflows being called from a dedicated Orchestrator instance, that's primary job will be to deploy servers (physical/virtual) and hand over to SCCM for day to day management.

 

This would be a pretty easy design if it was standalone, however we already have a significant investment in SCCM for our desktop estate, with dedicated teams of packagers and admins.

 

I am recommending we utilise existing investments and build out the hierarchy, but there are some interesting questions that have come out of scoping:

 

1) Would it make sense to build out a new primary site dedicated to the server estate, and have both the desktop and server primary sites report into a CAS?

2) Does it make sense to have a dedicated packaging team/admin that is applied at the CAS layer... or do we split within each site?

3) How do we manage things like SCCM Updates (not wsus, but the infrastructure)... Desktops are pretty agile and moving quickly. With the level of automation and criticality of some servers, we need to be sure upgrades does effect the other.

 

Has anyone got any thoughts on the above?

 

Thanks

 

Paul

[Apexes]

1. How many clients do you have total, and do you need a CAS? I know MS recommends no CAS for anything below 100k clients, but i have seen companies using a CAS for a lot less. I've always gone for the single primary site with secondaries if required, and DP's where needed. With CAS you'll bring in a whole new dependency on DB replication across all sites - not that this is a bad thing, but i certainly saw a lot more issues with DB Replication links going down between a CAS and a primary, than what i did running a primary site with secondary's and DP's hanging off of it.

 

2. Only your business requirements can decided on splitting workload between sites - how many do you have?

 

3. SCCM Updates - Do you mean updates to SCCM infrastructure, or infrastructure on a whole? SCCM infrastructure should be relatively straight forward, if you mean the latter - I've managed servers and desktops all with software update management in SCCM on a monthly pattern.

 

Personally - I'd always push for one environment, any teams that you have doing work for separate regions/sites - bring in to one, and then you've got a standard across the whole business. I can see the benefit that separating the environment into sites which teams have their own access to can benefit - but i guess the question is, is that really needed, rather than applying these packages/admin just at the top level of one site.