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!

samedi 14 septembre 2013

[Windows Server 2012] Issues with Active Directory in a Lab environment - Part 4

Active Directory is a great feature in Windows Server. However, imagine that you stop your lab environment for several days, weeks and perhaps months. You will certainly encounter some troubles when you'll try to turn on again your DCs.
In that series, I will share my own experience and show how to solve that troubles.

1. The DNS is waiting for Active Directory - KB 2001093
2. DFSR JET database is not shut down cleanly
3. This server has been disconnected from other partners for 60 days
4. The DFS Replication service failed to register the WMI providers

4. The DFS Replication service failed to register the WMI providers

You note that replication of the SYSVOL folder between your DCs doesn't work: For example, if you add manually a file in that folder, that file is not replicated on the other DC. That problem can also create some troubles on computers if they can't download the right version of their GPO.
Of course, all DCs are online and can be joined normally.

In Event logs,you find the following Event:

Event ID:      6104
Log Name:      DFS Replication
Source:        DFSR
Level:         Error
The DFS Replication service failed to register the WMI providers. Replication is disabled until the problem is resolved.


Unfortunately, I have not found any KB about that trouble on Microsoft web site. With several blogs and forums, I found command lines that solve my problem :

CD %windir%\system32\wbem
mofcomp dfsrprov.mof
mofcomp dfsrprov.mfl
wmiprvse /regserver
net stop dfsr
net start dfsr

I hope that feedback will be helpful if you encounter the same issue.

See you soon