2. Shoud I install one Primary site per admin Team ?
In the previous part, I provided the fundamentals about the reason to create a CAS or not.
Now it's time to discuss about one of the most common question I get in my job:
CAS or not CAS ? Part 2 - Shoud I install one primary site per admin team ?
Large companies may have several admin teams. For historical and/or political reasons, each team was used to manage devices in its own scope (geographic, business,...).
With SCCM 2007, each team had its own primary site. Whatever happens on the other primary sites, each team was free to work as they want.
Before saying if such design is still relevant with SCCM CB, let's return (again) to the fundamentals:
1. Data replication in SCCM
In SCCM 2007, everything was easy: The orders were coming down and the status were rising.
In SCCM CB, there are two kinds of replicated data:
- Global data: Global data is present at the central administration site, all primary sites, and a subset of it at the secondary sites.
Examples of global data include software deployments, software
updates, collection definitions, and role-based administration security
scopes.
- Site data: Site data is only replicated up the hierarchy and not across the hierarchy. In another words, site data is present on your primary site and on the CAS, not on the other primary sites.
Examples of site data include hardware inventory data, status messages,
alerts, and the results from query-based collections.
To get more information:
- Data Replication in System Center 2012 Configuration Manager: https://blogs.technet.microsoft.com/hybridcloud/2012/03/06/data-replication-in-system-center-2012-configuration-manager/
- Data transfers between sites in System Center Configuration Manager: https://docs.microsoft.com/en-us/sccm/core/servers/manage/data-transfers-between-sites
2. And so ?
I propose to analyze that in real life.
This a Lab environment with a CAS (called CAS) and 2 primary sites called SC1 and SC6. Each primary site has a computer account attached.
This a Lab environment with a CAS (called CAS) and 2 primary sites called SC1 and SC6. Each primary site has a computer account attached.
Client Policies, Boundaries, Queries...: Global data
Boundary Groups - Any site
Client Settings - Any site
That information are replicated on all the sites.
=> Be careful if you modify one of these settings. You will impact every clients in the infrastructure.
Sites, Roles, Discovery Methods: Site data
Discovery methods - CAS site
Discovery methods - SC6 site
Servers - CAS site
Servers - SC1 site
On the CAS console, you can see all information. On the primary site console, you see only information about your site.
Collections: ...
Collection is a little bit more tricky. Everything is global except content. That can create some confusions.
Collections - Any site
All collections are visible in the consoles. The deployments are also global data.
As a consequence, contrary to SCCM 2007, if you create a collection and/or a deployment, they are replicated on all sites.
Membership rules are also replicated.
However computers objects (and their inventories) are only site data and as a reminder, membership rules are processed on primary sites.
As a consequence, the content of collections depends on the site you watch.
Here is a small scenario that could be very dangerous:
On SC6, I create a test collection based on a query to add all computer beginning with "TEST".
Note that SCCM tells me there is 1 member in that site and 1 member allover the infrastructure.
Few minutes later a colleague call me to understand why I reinstall his test laptop.
Oups... it seems that now there are 2 computers allover the infrastructure (but still only one in my site) in the test collection.
Indeed, my membership rule has been replicated on the CAS and on all primary sites to be processed. The CS1 site added the TEST-SC1 device account in the collection and processed deployment.
Packages, Applications, Software Update Groups...: Global data
All that objects are also global. So event a small test on a site will be replicated everywhere.
What about Distribution point ? Remember that servers and roles are site data...
However, the list of the distribution points is global ! From a primary site console, you can distribute data on the distribution point of another primary site.
All that objects are also global. So event a small test on a site will be replicated everywhere.
What about Distribution point ? Remember that servers and roles are site data...
3. Conclusion and recommendations
As a conclusion, I hope that everybody is now convinced that creating primary sites is no longer a solution to create administration scopes.
The only solution to prevent a team to access the scope of another team is to create delegations, based on role (allowed operation), scopes and collections.
Moreover, working on the primary site console can be very dangerous especially because you don't see exactly the target members.
My recommendation is always to work on the CAS console. There are some exceptions especially to avoid replication delays between the CAS and the primary site (to accelerate a test, get a status...)
In the next articles, we will discuss about two case studies.
The only solution to prevent a team to access the scope of another team is to create delegations, based on role (allowed operation), scopes and collections.
Moreover, working on the primary site console can be very dangerous especially because you don't see exactly the target members.
My recommendation is always to work on the CAS console. There are some exceptions especially to avoid replication delays between the CAS and the primary site (to accelerate a test, get a status...)
In the next articles, we will discuss about two case studies.
Stay tuned
Julien
Julien
