Introduction to Configuration Manager 2012 (Part 2)

If you would like to read the other parts in this article series please go to:


In part 1 of this series, we went through a complete installation of System Center 2012 Configuration Manager and, by the end of the article, had a fully operational system. Now, you’re able to start investigating the new features and the console, which is exactly what we’ll be doing in this and the next part of this article series.

The console

Perhaps the most visible change to the SCCM 2012 administrative experience lies in the complete overhaul of the administrative console. Whereas even SCCM 2007 still carried remnants of the original SMS product, SCCM 2012 will never be mistaken for an older version. In all of the System Center 2012 products, Microsoft has implemented a consistent administrative experience, helping administrators more easily jump between the individual products in the suite. After all, you shouldn’t need to learn a different administrative model for each part of a group of interrelated products.

Even the console’s foundation has changed and no longer relies on the Microsoft Management Console framework. SCCM 2012 instead has its own model, which is based on that of Outlook, as you can see in the figure below.

Figure 1: The SCCM 2012 administrative console

Immediately, the Outlook-like nature of the console becomes apparent. In the lower left corner of the screen, you can see a series of what Microsoft calls wunderbars, or distinct administrative areas of the product. Above that, there is the navigation area, which changes based on which wunderbar is active. At the very top of the screen is the now-familiar Ribbon, which has replaced Microsoft’s traditional menu-driven interfaces. Personally, as the Ribbon makes its way into more and more products, the more useful I find it.

The balance of the screen is consumed by a large informational and detail area that shows information based on whatever is currently selected or the action that’s underway. Because of this overhaul and due to Microsoft shifting elements around, SCCM 2012’s interface enables administrators to take quicker reactive actions when things start to go south and also provides more proactive monitoring than was found in earlier versions of the software.

A security overhaul

Although it’s not as immediately obvious, the console has also undergone a complete security makeover. Gone are the days when primary sites defined security boundaries. This is a good thing! It allows administrators to drastically simplify their SCCM architecture. Now, rather than deploying a bunch of primary sites just to enable granular administration, you can use SCCM 2012’s new Role Based Access Control function to achieve extremely granular administrative segregation.

Role Based Access Control is found in many System Center 2012 products. In addition to restricting what users can do, it limits what users can see when they’re in the console. RBAC hides interface elements based on user profile so that the user is shown only what is relevant.

Security in SCCM is controlled through the application of roles and scopes. A role defines what a user can do and a scope defines where a user can do it. When these two items are overlapped, you’re left with a look at a user’s abilities in the SCCM console.

SCCM ships with 14 predefined security roles, but administrators can create additional roles to meet unique business needs. During the initial installation of SCCM, the administrative account is added to the Full Administrators role. Here’s a look at the list of roles available in SCCM 2012.

This information was pulled directly from the SCCM console.


Role description

Application Administrator

Grants permissions to perform both the Application Deployment Manager role and the Application Author role. Administrative users who are associated with this role can also manage queries, view site settings, manage collections, and edit settings for user device affinity.

Application Author

Grants permissions to create, modify, and retire applications. Administrative users who are associated with this role can also manage applications, packages.

Application Deployment Manager

Grants permissions to deploy applications. Administrative users who are associated with this role can view a list of applications, and they can manage deployments for applications, alerts, templates and packages, and programs. Administrative users who are associated with this role can also view collections and their members, status messages, queries, and conditional delivery rules.

Asset Manager

Grants permissions to manage the Asset Intelligence Synchronization Point, Asset Intelligence reporting classes, software inventory, hardware inventory, and metering rules.

Compliance Settings Manager

Grants permissions to define and monitor Compliance Settings. Administrative users associated with this role can create, modify, and delete configuration items and baselines. They can also deploy configuration baselines to collections, and initiate compliance evaluation, and initiate remediation for non-compliant computers.

Endpoint Protection Manager

Grants permissions to define and monitor security policies. Administrative Users who are associated with this role can create, modify and delete Endpoint Protection policies. They can also deploy Endpoint Protection policies to collections, create and modify Alerts and monitor Endpoint Protection status.

Full Administrator

Grants all permissions in Configuration Manager. The administrative user who first creates a new Configuration Manager installation is associated with this security role, all scopes, and all collections.

Infrastructure Administrator

Grants permissions to create, delete, and modify the Configuration Manager server infrastructure and to perform migration tasks.

Operating System Deployment Manager

Grants permissions to create operating system images and deploy them to computers. Administrative users who are associated with this role can manage operating system installation packages and images, task sequences, drivers, boot images, and state migration settings.

Operations Administrator

Grants permissions for all actions in Configuration Manager except for the permissions that are required to manage security, which includes managing administrative users, security roles, and security scopes.

Read-only Analyst

Grants permissions to view all Configuration Manager objects.

Remote Tools Operator

Grants permissions to run and audit the remote administration tools that help users resolve computer issues. Administrative users that are associated with this role can run Remote Control, Remote Assistance and Remote Desktop from the Configuration Manager console. In addition, they can run the Out of Band Management console and AMT power control options.

Security Administrator

Grants permissions to add and remove administrative users and to associate administrative users with security roles, collections, and security scopes. Administrative users who are associated with this role can also create, modify, and delete security roles and their assigned security scopes and collections.

Software Update Manager

Grants permissions to define and deploy software updates. Administrative users who are associated with this role can manage software update groups, deployments, deployment templates, and enable software updates for Network Access Protection (NAP).

Table 1

As you can see from the table above, these roles all define what users that are members of the role can do. So, how do you control there “where” aspect?

That’s where security scopes come into play. SCCM 2012 ships with two default security scopes:

  • All. A built-in security scope that contains all securable objects. A Configuration Manager administrator associated with the All security scope will have the permissions of their role for every object in the Configuration Manager environment.
  • Default. A built-in security scope with which securable objects can be associated.

Neither of these security scopes can be changed or deleted.

Appropriate objects in SCCM 2012 are tagged with security scopes and can be added to new security scopes, where necessary. This is how you can avoid having to create multiple primary sites to form security boundaries. Now, for example, you can simply change an existing site’s security scope membership. To do so, right-click the site and, from the shortcut menu, choose Set Security Scopes. You can see this in Figure 2.

Figure 2: Changing a site’s security scope

When the Set Security Scopes window appears, you will be shown a list of the security scopes that exist on the system. Note that there are two shown in Figure 3 – Default and TEST, which I created.

Figure 3: The security scopes in my lab

There are a number of different object types in SCCM 2012 that can be scoped in this way. So, a security scope secures based on a sort of instance element. You can also use collection limiting to further restrict what can be done.


It’s clear that Microsoft has gone to great lengths to simplify the SCCM administrative model. From redesigning the various System Center 2012 consoles to have a similar experience to implementing granular security controls that negate the need to create complex architectures in the name of security, SCCM 2012 is a major step in the right direction. In the next part of this series, we will continue to investigate SCCM 2012’s new features.

If you would like to read the other parts in this article series please go to:

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top