As mentioned earlier, spending some time on planning and analyzing your business may significantly help you in building a solution that will meet the requirements without being an overkill. It is always good to include some growth in your design plans, but there is a significant difference between planned overhead and overkill in achieving the goal.
With ConfigMgr 2007 still in your environment, the administrator would need to go through an upgrade process to migrate to the 1706 version. For 2012, there is an in-place upgrade possibility. Note that upgrade process topics won't be covered in this book.
When it comes to hierarchy planning, ConfigMgr gives a few possible options. Since ConfigMgr 1511, Microsoft has supported running ConfigMgr on the cloud.
Note
When considering your design, be aware that as of now, there is no support for using VM in Azure as a distribution point for WDS deployments using PXE. In such cases, use the on-premise distribution point.
SMS 2003 servers and ConfigMgr 2007 were supporting hierarchies made of many levels. It was causing a lot more issues related to data synchronization between servers. In ConfigMgr 2012, Microsoft introduced some significant changes. Hierarchy might consist of only three levels, and data synchronization is made directly between SQL Servers, which is a significant factor in improving the functioning of the entire system.
When designing a ConfigMgr deployment, we may choose between a few server types, and we also have the ability to combine these few servers together.
An important thing to keep in mind is that there is, in fact, the possibility of changing the environment after the deployment. The administrator might start with one server, and have a few of them at the end, or the other way--the number of servers might go down.
ConfigMgr is a scalable solution, so it can be changed and might grow together with the organization.
Note
There is, however, one thing that cannot be changed--if we wish to have two primary site servers, we need to have a central administration site to connect them in one solid structure.
Primary site is a fundamental ConfigMgr server type that manages the clients. We start each deployment by installing this server. As you can see, the smallest possible implementation is a single standalone server. This solution is often chosen, not only by small and average sized companies, but also by big firms with a dozen or so branches.
Even when you don't have the best connection between offices, you may use a distribution point that will be a local repository for clients; the idea of distribution points will be described later in this chapter.
In this scenario, all clients report to one single ConfigMgr server. So, simplified administrations here are an undisputed benefit for both administrators and workstations that have one point to report to. Having only one server eliminates the need to replicate the database.
When installing the standalone/primary site server, the complete version of the SQL database server is required. Being a primary site server, the machine participates in database replication:
Hierarchy with one sever primary site
This scenario goes a step further. With a secondary site, we tell the clients in satellite offices/branches to report to the secondary site instead of the primary one. The reason we want a secondary site is that our primary site has very bad wide area network (WAN) connections with branches; additionally, during the day, we prefer not to fill this link with ConfigMgr traffic.
Imagine a situation where we have New York, which is our primary site, and Philadelphia, where we have an office with approximately 5,000 computers, and we have a really slow WAN link between these two offices (which may be considered any link slower than 10 MB) in addition to some latency issues. Having computers reported to New York might be a real bottleneck, not just for workstation to ConfigMgr communications, but it will surely impact applications that try to send data over this WAN link, so it may have serious repercussions for your business. Secondary sites come into play when one of the following factors is important:
- Traffic compression between sites
- Scheduling time for data exchange between the primary and secondary site
Usually, you won't need a secondary site; as I mentioned, even in global enterprise deployments, people often choose to have one primary site with distribution points in satellite offices:
Hierarchy with one primary site and secondary site
This is the most complex scenario we can get. A central administration site may coexist with one or more primary sites--it is the top-level site in the hierarchy. You may consider using central administration if you have two or more very big sites (where the sum of Windows clients, for instance, might be bigger than 150,000), or you would like to separate clients from each site from each other--the legal factor might come into play in this case:
Most complex structure of ConfigMgr
A central administration site does not play any role in managing the clients in terms of actually having some clients assigned to it. You are not able to assign any clients here. It does not process any client data; it just saves data about the whole hierarchy.
Note
Server central administrations might be added to the primary site at any time. There is no need to install the central administration site as the first server in the hierarchy.
With the central administration site and two primary servers connected to it, it is possible--in the case of failure of one of them--to switch endpoints to report to the working one. This feature is the easiest form of high availability provided for endpoints. However, this switch does not happen automatically, and it needs to be triggered from the server console.
The most important roles, which need to be considered when designing the environment, are management point and distribution point.
If these roles are properly designed and deployed, the environment will work swiftly, firmly, and in accordance with expectations.
Management point is the most important server role that needs to be deployed in the ConfigMgr environment as it provides communication between the ConfigMgr server and the clients. If the mentioned role is not functioning correctly, clients will be unable to communicate with the server, which results in an immediate break in managing the environment. It makes communication on both sides impossible and clients won't be able to send any data to the ConfigMgr server.
Note
We might connect more than one management point to each ConfigMgr server. This situation might be desired when one single ConfigMgr server is servicing many clients or when endpoints are located in various geolocations and the administrator wants to provide good communication between the ConfigMgr server and the clients.
Clients choose the management point they will connect to, based on the boundary group, which will be described in more detail in Chapter 3, Configure Sites and Boundaries. Incorrectly designed infrastructure, resulting in a badly chosen management point by clients, might cause many unpredictable effects; for instance, clients won't perform installations, won't send data to the ConfigMgr server, or will connect and communicate with the wrong management point.
Note
In versions prior to 2012, it was not possible to tell the workstations which management point should be used. Secondary servers were used as a workaround, as it was possible to assign a workstation to a particular secondary server. Starting from the 2012 version, there has been the option of setting the management point as the preferred one from a certain site.
For better and more efficient usage of the network between the central office and company branches, it is possible to place the primary site server or simply a management point in these branches. In this scenario, all data targeting clients will be sent only once--from the primary site server to the management point from which clients will download the data using the local network.
This happens on the other side as well. When clients are making a hardware inventory, they send all pieces of data to the management point server; it aggregates the data and sends it at once to the ConfigMgr server. In this way, the administrator is able to significantly lower the amount of information sent over the network in the ConfigMgr environment.
Let's imagine a situation where we have a standalone server that is used as a distribution point for the main office in New York. We would like to install a few applications on 100 computers in Philadelphia, 200 computers in Washington, and 50 in Pittsburgh. All these workstations will download content from the New York server. To prevent such situations, we should use a distribution point that will act as a local application repository for clients.
With distribution points, we may push binaries to the local servers at the most convenient time of the day/or night--simply the quietest time from the network perspective. Having said that, we may now go to our workstation configuration and tell them to download binaries from the local distribution point server.
Note
Starting from ConfigMgr 2012, each and every distribution point associated with ConfigMgr might have different settings for data, sending configuration such as the days and hours in which ConfigMgr is allowed to distribute the content to the distribution point.
The ability to configure separate settings for each distribution point is a major ease when configuring the ConfigMgr environment. In this way, the administrator can fully control the time, the way, as well as from where data is being sent between ConfigMgr servers and clients.
If you're combining the aforementioned separated roles with a properly designed structure management point role, the administrator will have a clean view of which clients send data to which distribution points and management points. Each distribution point supports connections from up to 4,000 clients and a combined total of up to 10,000 packages and applications.
There have been a lot of changes in SQL Server use cases since ConfigMgr 2007. In all versions prior to 2012, SQL Server was only used for primary site needs. Since version 2012, all server types--central administration site, primary site, and secondary site, use SQL Server to store data.
For central administration site and primary site, we may use MS SQL Standard or Enterprise Edition. Secondary sites support MS SQL in Standard or Express versions:
The configuration of SQL Servers for ConfigMgr servers
When installing the secondary site server, SQL Express installation is conducted automatically by the ConfigMgr server. If we are more likely to use SQL Standard, we need to install SQL Server before starting the installation of the secondary site server.
ConfigMgr can be scaled to a size that will accommodate any type and size of organization. Keep in mind that we often split ConfigMgr installations and create additional sites/sub-sites, not because we are reaching limits in ConfigMgr, but to:
- Ease administration/maintenance
- Separate administrator access
- Physically separate the data (for example, to meet regulations)
- Put boundary lines between some instances
There are three types of ConfigMgr servers, and each has already been mentioned in the context of designing the hierarchy. Each of the following presented server types has a different role and way to be configured.
A central administration site is used to manage the whole hierarchy. All connected primary site servers synchronize with it, so all information about what is going on in the environment is available in one place. A central administration site supports up to 25 child primary sites.
A central administration site does not support clients directly, neither does it process client data. All this work is done by primary and secondary site servers that send the data to the central administration site. Because the CAS role does not support communication with clients, it is not possible to install management point or distribution point roles on the server. Additionally, some of the server roles are supposed to be installed only on a CAS server, such as a service connection point.
A primary site server is a fundamental server type deployed in the ConfigMgr environment. The main difference between this server and central administration is that it directly supports the clients as well as shares and receives data from them. This is a reason why this server type supports installing server roles such as management point and distribution point. It requires MS SQL and being connected to a central administration site; it replicates its own data and data received from the associated secondary site.
Each primary site can support up to:
- 250 secondary sites
- 15 management point
- 250 distribution points
A secondary site server should always be considered an optional one. In many cases, one primary site server is able to successfully serve the whole company. However, once a company has many branches, low-quality network links and lots of systems to manage, the secondary site server is what the administrator should consider.
Each secondary site supports a single management point that must be installed on the secondary site server. However, despite installing a management point, assigning clients to it will not be possible. Clients always need to be assigned to the superior server, in this case, the primary site.
When talking about supported clients, we can outline three different types:
- Client type 1: Windows Server, Windows Clients, and Windows Embedded, Linux, and Unix
- Client type 2: Devices managed by Windows Intune and those enabled for Exchange Server connector
- Client type 3: Devices enrolled by ConfigMgr and devices supported by the mobile device legacy client, macOS clients
- Central administration site:
- Up to 700,000 type 1 clients
- Up to 25,000 type 3 clients
- Up to 100,000 devices that you manage using on-premises MDM or up to 300,000 cloud-based devices
- Standalone primary site: The overall number of devices managed by standalone primary site is 175,000, where subdivisions are:
- Up to 150,000 type 1 clients
- Up to 50,000 type 2 clients
- Up to 25,000 type 3 clients
- 50,000 devices that you manage using on-premises MDM or up to 150,000 cloud-based devices
- Secondary site: Up to 15,000 type 1 clients
- Management point: The overall number of devices managed by the management point is 25,000, where subdivisions are:
- 25,000 type 1 clients
- Up to 10,000 devices that are managed using on-premises MDM or up to 10,000 type 3 clients