Last Update: Sep 04, 2024 | Published: Mar 05, 2014
System Center 2012 Configuration Manager (SCCM) is an amazing product, but attempting to approach it as a whole can be overwhelming. A better approach is to look at elements of SCCM individually, so in this post I’m going to share the architecture templates that I typically end up deploying in most of the small and medium businesses I’ve worked with. These have scaled from simple single-office deployments to the typical geographically dispersed organization using simple Internet-based VPN connections as the WAN fabric.
One point of note: In all of these environments I haven’t needed to consider deploying a Central Administration Server (CAS), as not one of these organizations come close to that magical number of 100,000 systems, which thankfully make things a lot simpler.
While each and every environment is different, and there are specific considerations that must be accounted for, ranging from political to physical (the templates continue to emerge in each case). Of course, there are occasions when specific roles might be split and deployed to dedicated servers (for example the web catalog), but these decisions will always be environment specific.
There are five main server templates that emerge. Let’s take a closer look at each of these.
At the very heart of the SCCM deployment, the primary site server will be configured with a locally installed copy of SQL Server using dedicated disks for the SQL installation, and additional disks for SCCM to host its packages.
Generally, this server will not be exposed to the clients and will not host any HTTP/HTTPS services, keeping its attack surface limited. Whenever possible, I like to keep this server protected using DPM, or Hyper-V Replica, and of course have the SCCM SQL backup job configured.
The roles that the server will assume normally include the following:
The management servers in my environment are normally a consolidation of roles, duplicated to multiple instances to deliver higher capacity and availability while also providing disaster recovery support for each other.
In general I will deploy two classes of management servers: ones focused primarily on offering management to systems on the Intranet, and a second class of Management Servers that will be focused on Internet-based clients. To keep things nice and clean, I try to leverage load balancers to publish the role services I host on these servers, enabling the ability to publish a managed set of virtual IPs and associated fully qualified domain names for the respective services.
Similar to the primary site server, each of my management servers also includes a dedicated local instance of SQL Server. Each local instance is respectively configured with a replica of the primary site server’s database, and the management point role is configured per server to use the local replica of the database.
These are typically hosted centrally or deployed to a set of select locations such as organizational hubs, serving clients either across the complete organization, or focused to their respective hubs. For example, in a geographically dispersed organization these hub are regularly distributed per continent. As a rule of thumb, these will be deployed in pairs or larger multiples to ensure there is enough capacity to support the scoped clients.
Normally, the roles which I will deploy to these servers will be:
These are basically a carbon copy of the Intranet management servers, but they are generally deployed in the DMZ of the data center, and are not domain joined. The key difference on these servers is that the management point role is configured to allow Internet-only connections using secure HTTPS connections.
The Internet management servers will host the following:
Normally, I will deploy a reporting server in the same physical location as my primary server, and then I’ll publish the reports by integrating the reporting service with SharePoint, or just via the normal SCCM Console integration.
This server is very simple, maintaining only the reporting role.
In many of my deployments, this is where the real number of SCCM site server instances starts to scale. Quite often when the organizations are geographically distributed, so we will deploy a distribution point per location. Quite often this will converge with deployments of Active Directory domain controllers and use quite similar boundary groups to the existing Active Directory sites.
The distribution point will host a replica of the packages and applications that we will distribute to the associated clients. We would normally also enable operating system deployments and user state migrations from these servers and use them as our wake up proxies.
While my SCCM experiences have begun to converge and I have begun to build a template for deploying SCCM to support different scales of organizations, its flexibility to morph and change to address requirements of some of the largest organizations on the planet truly means there is no one right way to do this!
I hope this post helps in some way to answer your own questions, validates decisions you may have made in your deployments, and confirms some the the patterns you have already deployed.