In previous versions of ConfigMgr, client settings were globally configured by Site. In ConfigMgr 2012, by default the Default Client Settings (a bit like a ‘profile’ of settings) are applied to all clients. As well as editing the Default Client Settings, it is also possible to create your own settings ‘profiles’ that can be applied to specific collections. 

For example, you may have Installation Permissions configured globally to allow Administrators and Primary Users to initiate software installations, but a custom client setting can be configured to allow no users to initiate software installation for a group of sensitive computers.

The definition of WMI classes that get reported through Hardware Inventory is now managed through the Client Settings interface in the console. No more editing SMS_DEF.MOF or CONFIGURATION.MOF. What is really cool with this interface is that new classes can be added by connecting to WMI on any computer and browsing to the class you want to report on.

In addition, custom hardware classes may be exported to a MOF file and imported in the same interface. This allows custom inventory settings to easily be transferred from a lab environment to your production environment.

There are a number of features in ConfigMgr 2012 to ensure clients remain healthy, operational and efficient. The reality is that somewhere between 5% and 15% of your clients will experience issues and may stop communicating with ConfigMgr. ConfigMgr 2012 directly addresses the problem with ConfigMgr Client Heath Evaluation. This agent (which runs as a scheduled task separate from the ConfigMgr agent service) detects and remediates the most common causes of client failure, reporting its activities to ConfigMgr.

ConfigMgr clients will now upgrade themselves to the latest version if it is below the specified version, you enable this from Site Settings and you can configure the maximum number of days before the client must upgrade. In addition to this you will have control over how the Clients’ installation files are downloaded or not if the Distribution Point is on a Slow link and can even have a fallback source location. Note: Microsoft recommend using this as a catch-all after the bulk of any upgrade has finished.

To protect clients from malware, ConfigMgr 2012 now has Endpoint Protection fully integrated, so no more running two separate infrastructures. The Endpoint Protection client is installed using ConfigMgr 2012 client settings, so no need to create any Packages or Programs. Endpoint Protection reports and dashboard are integrated into ConfigMgr console further simplifying operational tasks. There is even an out-of-the-box security role for the Endpoint Protection Administrator, defining all the necessary rights to enable the role to be delegated.

Keeping up to date with software updates is an important step to ensuring the health and functionality of a client. A significant improvement to management of software updates in ConfigMgr 2012 comes with the ‘Automatic Deployment Rules’ feature. Administrators can ensure updates are automatically downloaded, approved and deployed based on specific criteria, instead of manually carrying out tasks. For example, this could be used to automatically deploy all critical updates for Windows 7, or to automatically deploy recent signature definitions for Forefront Endpoint Protection.

If you do not want to automatically deploy, the rule can be configured to retrieve compliance information from client computers for the software updates without deploying them.
Power Management, introduced in ConfigMgr 2007 R3, is enabled by default in ConfigMgr 2012 and includes some minor enhancements.  It continues to enforce the same peak and non-peak power plan settings for turning off the display, inducing sleep or hibernate, controlling battery notifications and button actions and scheduling desktop computers (deliberately not laptops) to wake from sleep.

You can now copy settings from another Collection so you only have to tweak the differences.  Also, users can now exclude their PC from power management which you can report on and override. 1E NightWatchman Enterprise fills in the gaps, enabling scheduled shutdown and wake-up for all systems, overriding processes that prevent computers going to sleep and enabling potential application issues when resuming to be addressed.  

ConfigMgr 2012 has been built with the user in mind. The Software Center, installed on all clients, provides an interface for the user to manage installation of software that has been made available to them and to view software that has been installed by ConfigMgr.

While this is fairly basic user self-service, 1E Shopping provides a much richer experience with configurable approval workflow, support for system as well as user based deployments, optional restriction of deployment if insufficient licenses exist, integration with other Service Desk systems and the ability for users to rent applications for a period of time.

The Software Center can also give the user control over the ConfigMgr actions that are likely to impact them most. For example, a user can define their working day and software deployments and updates can be configured to respect these and deploy outside of these hours.

There are some notable changes in the role of the Distribution Point (DP) in ConfigMgr 2012. The Branch Distribution Point (BDP) has been dropped in ConfigMgr 2012. Instead, there is a single DP role that can be installed on servers (2003 upwards) and workstations (Vista upwards).

Interestingly, the DP role is the only Site system that is supported on both 32 and 64 bit computers; all other Site systems require a 64 bit OS. Distribution of content to remote DPs (i.e. any DP that is not hosted on the Site server) can use scheduling and throttling similar to that defined in our old friend, the Site-to-Site Address, that has survived since the first version of SMS.

By default all content is obtained by clients using HTTP (or HTTPS), which means that any system (including a workstation) hosting a DP needs Internet Information Server (IIS) installed. Although there is the option to establish content for specific Packages on a ‘legacy style’ DP share (this is in fact necessary if you want to use OS deployment Task Sequences that obtain content directly from the DP), the HTTP/S server must always be present. If you currently use NAS devices to host ConfigMgr 2007 DP shares, you are going to need a new strategy for ConfigMgr 2012.

The DP role now incorporates the PXE Service as an optional feature if the DP is hosted on a server OS (Windows Deployment Services (WDS) is still required for PXE booting in ConfigMgr 2012). Talk to 1E about our Nomad Enterprise solution, which not only eliminates the need for any kind of DP in your remote locations but also enables PXE to be served from a workstation. Nomad Enterprise integrates seamlessly with the ConfigMgr 2012 Operating System Deployment (OSD) process, using content stored on local peer workstations to complete a full OS deployment without impacting the WAN.

A ConfigMgr 2007 hierarchy could support a maximum of 200,000 clients (300,000 with R3).  ConfigMgr 2012 supports up to 400,000 clients in a Single Site hierarchy when the database for the Central Administration Site is running SQL Server Enterprise. Each Primary Site can support up to 100,000 clients if the database and Primary Site roles are hosted on separate servers.

As with ConfigMgr 2007, each Management Point (MP) can support up to 25,000 clients. However, the concept of a Default Management Point no longer exists in ConfigMgr 2012, and neither does support (or necessity) for Network Load Balancing (NLB) an MP. Instead, up to four servers can host the MP role and clients manage the load balancing in much the same way as they do with Distribution Points.

ConfigMgr 2012 also increases the number of supported Distribution Points (DPs) per site from 100 to 250, each supporting up to 4,000 clients. As the PXE Service is now a feature of the DP role, it is no longer constrained to 75 per primary site as recommended in ConfigMgr 2007, although no specific recommendations for the maximum number of PXE servers per ConfigMgr 2012 site or hierarchy have been provided by Microsoft as yet.

The complexities of Native Mode in ConfigMgr 2007 no longer exist in ConfigMgr 2012 as the Mixed and Native Site modes are no more. Instead, the various Site system roles within the Site are configured to support HTTP or HTTPS connections (or both).

Within a Site, multiple Site systems (e.g. Management Points) can be deployed, allowing one or more servers situated in a DMZ to host internet-facing roles using HTTPS, with the same roles hosted on an internal server using HTTP. Use of HTTPS still requires a PKI to enroll Client and Server certificates (mutual authentication is still required), however the Site Server Document Signing Certificate is now created by the site as a self-signed certificate.

By default, if a client has a client authentication certificate issued by a trusted Certificate Authority (CA) it will use HTTPS and will be able to communicate with all Site systems that are configured to support HTTPS. If no such client authentication certificate exists, the client will use a self-signed certificate and use HTTP to communicate only with Site systems that are configured to support HTTP.

New to ConfigMgr 2012 is the possibility for Internet-based clients to evaluate user-based policy (such as Application Deployments). In order for this to occur, either the Management Point (MP) and user account must be in the same forest, or a trust must exist between the forests in which the MP and the user account reside. In either case, any perimeter firewall must allow AD authentication traffic between the MP and a Domain Controller in the user account’s forest.

The Admin Console is a big pain point for current ConfigMgr 2007 administrators.  Not only is it difficult to customize (allowing certain users to only see the features they administer), it tends to crash often. The Admin Console in 2012 ConfigMgr was completely redesigned and written from the ground up. It does not use MMC, displays only the features the admin has rights to, and has a separate MSI for installation.

If you run a small admin team where everyone does everything in ConfigMgr 2007, then your security configuration probably doesn’t extend beyond giving everyone in the team full rights on everything (very dangerous by the way).  With the vast array of features that ConfigMgr 2012 provides, it is likely that even small organizations will be delegating specific administrative tasks to different people and teams. This will require granular definition of security rights, which, while possible in ConfigMgr 2007 was quite cumbersome to manage.

ConfigMgr 2012 offers a completely revamped admin security model. This new model uses a combination of security roles, collections and security scopes to define what objects an administrative user can see and the types of actions he can perform on those objects. A security role is just a collection of permissions appropriate to a role, such as Software Update Manager (there are 14 predefined roles and new ones can be imported).

Admin users are associated with a Security Role which can be restricted to specific Collections and Security Scopes. A Security Scope is simply an identifier that can be applied to specific instances of objects within the console, so for example if there was a site, some Applications, DPs and Software Update Groups that were specific to Asia, it would be possible to associate all of these individual objects with an Asia Security Scope and then restrict administrators for Asia to this group of objects only.