I am starting new blog series on my Configuration Manager 2012 for sharing early deployment observations and learning of Configuration Manager 2012 at Microsoft, which is the largest Configuration Manager 2012 deployment to date. My goal is to help you get ready for Configuration Manager 2012 deployment. I am very interested in your feedback and what specific areas around our deployment experience at that you would be interested in hearing about.
In this blog, I am going to share how we designed our Configuration Manager 2012 hierarchy.
Let’s first go through key facts for our hierarchy design at Microsoft.
The key desktop management services where we use Configuration Manager are listed below:
· Hardware and Software Asset Reporting
· Software Metering
· Software Deployment
· Software Update Management aka Patch Management
· Operating System Deployment
· Application Virtualization Deployment (App-V)
· Malware Protection (Forefront)
· Power Management
· Mobile Device Management
At Microsoft, our administration model for all systems is centralized administration, so all deployment and reporting is done from a central site. Before I share with you our new hierarchy design for Configuration Manager 2012, it is important for us to review our Configuration Manager 2007 hierarchy, as it will help in understanding some of key benefits you will able to achieve through new features of Configuration Manager 2012.
Figure 2: Configuration Manager 2007 hierarchy at Microsoft (Before state)
As you see in figure 2, we had 5 Configuration Manager 2007 primary sites aligned with regional locations. The first thing we decided was to deploy new Configuration Manager 2012 hierarchy in parallel to the above hierarchy because, as most of you might be already aware, Configuration Manager 2012 is not supported for in-place upgrade from Configuration Manager 2007. To start, we deployed Central Administration Site (CAS) and 3 child primary sites in phase 1. We decided to move all our machines reporting to Corporate headquarters (Redmond) and North and South America to Configuration Manager 2012 in a phase 1, which accounts for almost 50% of total machines managed in Configuration Manager 2007. During all client moves, we always ensured minimum service interruptions to end users along with meeting our standard service level agreements (SLA) for our services such as monthly patching SLA, and client health SLA.
Below is our Configuration Manager 2012 hierarchy as of today. We are making progress to add 2 more child primary site and moving clients from others regions such as Asia and Europe.
Figure 3: Configuration Manager 2012 hierarchy at Microsoft (Current state)
In figure 3, you will notice we have a total of 4 site systems hosted on physical servers, which include the CAS and all primary SQL servers, whereas the rest of the site systems are hosted on virtual servers.
The second thing you will notice is that we don’t have remote SQL server for CAS site, which differs from our use of remote SQL server for central site in Configuration Manager 2007. In Configuration Manager 2012, all client data is processed at the primary site level and is replicated to the CAS site through global and site data replication. The central administration site is only used for administration and reporting purposes. We did a comparison of the average processor utilization between Configuration Manager 2007 central site and Configuration Manager 2012 central administration site and found that CAS is ~20-30% less utilized than Configuration Manager 2007 SQL server.
The third major change you will see in figure 3 is that for the North and South America primary site, we had only 3 secondary sites. Compare this to the 35 secondary sites we used in Configuration Manager 2007 (refer figure 2). This is only possible because the distribution point sites system role in Configuration Manage 2012 can have scheduling and throttling settings for content distribution, which was only available for secondary site roles in Configuration Manager 2007.
The fourth benefit we had was for management point roles, as we used a new feature MPlist to allow us to have multiple management points without need of Network Load Balancing (NLB).
The fifth benefit we’re seeing from an infrastructure perspective is that we don’t need a dedicated primary site for site-level client settings. By this, I mean in Configuration Manager 2007, we had a limited service site to offer only patching services to one of our internal customers – labs. It was business critical requirement that there be no Configuration Manager admin accidentally deploys software to that group. To meet this requirement in Configuration Manager 2007, we used a have a separate primary with the setting software distribution to client disabled. In Configuration Manager 2012, we can combine the right Role Based Administration and Client Agent Settings to be confident we can meet this business requirement. As a result, we will be able to collapse the limited service primary site. We will write more about RBA later on.
There are so many things to share about Configuration Manager 2012. One of my colleagues blogged already on mobile device management in MSIT here: http://blogs.technet.com/b/system_center_in_action/archive/2011/09/02/configuration-manager-2012-exchange-connector-implementation-in-microsoft-it.aspx. We will continue to share our story, and the next blog post will focus on our experience migrating clients from Configuration Manager 2007. Please share your comments and questions! .