mercredi 14 février 2018

[SCCM CB] CAS or not CAS ? Case Study 1 - Infrastructure pooling

Case Study 1 - Infrastructure pooling
Case Study 2 - The Worldwide Company

In the previous parts, I provided the fundamentals about the reason to create a CAS or not.
I also show you why creating a primary site is longer a solution to isolate actions.
Now a propose to discuss about a first case study.

CAS or not CAS ? Case Study 1 - Infrastructure pooling

Two companies merged.
In a first time, they want to share the same SCCM CB infrastructure but each company's resources must be managed by the admin team of that company.
The first company has 100k devices and the secund has 60k devices.

The consultant proposes to create an architecture with a CAS and 2 primary sites.
Each company will have its own primary site and he promises that "if ever one admin team makes a mistake, the other company won't be impacted".

My point of view:
We could be tempted by a standalone primary site. However, as a reminder, a standalone primary site is limited to 150.000 desktop.

So a CAS is required. Each child primary site support up to 150.000 devices.
2 primary sites seems to be the right decision.

However, I disagree with the promise of the consultant.
Each company will be able to use its own primary site, however, most of the actions will be replicated on the other primary site.

The companies must now work on common process: to deploy et tests packages, to design collections...
They also must work a process to manage the global settings (boundaries...) and deploy updates.

In a next article, we will discuss about a worldwide company.

Stay tuned !

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

mardi 28 février 2017

[SCCM CB] CAS or not CAS ? Part 1 - The fundamentals

Yes, I know it's a very common question and there are already a lot of articles and discussions about that on the Internet. Even myself, I already wrote an article after the SCCM 2012 SP1 release.
However, I think it's time to provide some pragmatic information and to kill some very common ideas.

1. The Fundamentals

CAS or not CAS ? Part 1 - The Fundamentals

I. Why not using a CAS ?
A CAS doesn't provide any specific feature that you can't have with a standalone primary site.
Even if you install a standalone primary site, you can always install after a CAS (see Expanding a stand-alone primary site).

Never forget that:
About the last point, lot of people ignore site recovery prerequisites:
  • To restore a CAS, all your primary sites must function.
  • To restore a primary site, your CAS must function.
What if you've got a problem with your CAS and you discover that a primary site is also down ? You're stuck and you only have to call Microsoft support. :(

So my 1st recommendation: Keep your SCCM infrastructure as simple as possible and use a CAS only if you need one.

II. Why using a CAS ?
Sometime, there is no other solution but to install a CAS.

1. Because you're above the limits of standone primary site: Saying Microsoft (, a standalone primary site can manage up to 175.000 devices (150.000 PC + 25.000 mac).

2. Because you need more than 15 Management Point:
You need 1 MP for 25.000 PC (or 10.000 MDM devices / MAC).
You need also 1 MP if you want to manage clients is an untrusted forest (

If you've got a lot of untrusted forests (for security reason for example), you may require a lot of MP. However, never forget you can also manage clients in untrusted forest as workgroup clients (

Quick Case Study : you have :
  • 20.000 computers in your main forest (the forest that contains your site server);
  • 10.000 computers in a two-way trusted forest;
  • 10.000 computers (that you want to manage fully) in an untrusted forest;
  • 50 computers in an untrusted forest that you will manage as workgroup computers.
You need... 3 Management Point
2 Management Point that will manage 30.050 clients (main forest + trusted forest + workgroup)
1 Management Point that will manage the 10.000 clients in the untrusted forest.

3. Because you need to install a MP across a slow link:
A Management Point requires a fast link to the Database server.
Some people uses database replica, but that feature is normally reserved to reduce CPU processing of the site database server, not to provide a "local cache". Moreover, I'd rather to troubleshoot site replications than database replication. Note also that database replica must be disabled during SCCM updates (more maintenance operations).

As a consequence, when you need to install a MP across a slow link, you need to create an additional site. That can be secondary or another primary site with a CAS.

4. Because, you're above the limits a primary site:
  • > 250 secondary sites
  • > 250 Distribution point in the site
  • > 2000 pull-DP
  • > 5000 DP in the site and in the child secondary sites

In the next part, I will discuss about a really common question:
Is it relevant to create several primary site when you have several admin teams ?

Stay tuned!