jeudi 23 mars 2017

[SCCM CB] CAS or not CAS ? Part 2 - Shoud I install one Primary site per admin Team ?

2. Shoud I install one Primary site per admin Team ?
Case Study 1 - Infrastructure pooling
Case Study 2 - The Worldwide Company

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.
Administrators can create global data at central administration sites and primary 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.
Site data is only viewable at the central administration site and the primary site where the data originates. Site data can be modified only at the primary site where it was created.
Examples of site data include hardware inventory data, status messages, alerts, and the results from query-based collections.

To get more information:

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.

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".

So I get, 1 computer in the collection.
Note that SCCM tells me there is 1 member in that site and 1 member allover the infrastructure.

and I launch my OSD deployment...

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.

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.

Stay tuned

Aucun commentaire:

Enregistrer un commentaire

Remarque : Seul un membre de ce blog est autorisé à enregistrer un commentaire.