No two ConfigMgr
implementations are the same. Between network topology, desired
functionality, and requirements, each ConfigMgr implementation is unique
in its own way. Some organizations have federated or distributed IT
departments, lending themselves to a tiered ConfigMgr hierarchy where
support personnel have ownership of the clients in their respective
regions. Figure 1 illustrates a decentralized IT model, where sitewide management functions are typically handled at the regional level.
Alternatively, with the
rising cost of IT in today’s economy, the push is greater than ever
before to consolidate and centralize resources. For proof of this point,
look at the virtualization market leading the way in cost savings via
consolidation, particularly in larger environments. ConfigMgr scales to very large numbers, as listed in Table 1, which is taken from the ConfigMgr 2007 R2 help file.
Table 1. Configuration Manager 2007 Supported Scalability Numbers
| Site Role | Maximum Numbers |
|---|
| Hierarchy (central site) | 200,000 clients |
| Primary site | 100,000 clients |
| Secondary site | 500 secondary sites per primary site |
| System Health Validator | 100,000 clients |
| Management point | 25,000 clients (greater with Network Load Balancing [NLB]) |
| Distribution point (non-OSD) | 4,000 clients |
| Distribution point (OSD) | Limited by disk I/O and network bandwidth |
| State migration point | Limited by disk I/O and network bandwidth |
| Software update point (SUP) | 25,000 clients (greater with NLB) |
| Fallback status point | 100,000 clients |
| Branch distribution point | 2,000 per site, 100 clients each; limited by disk I/O, network bandwidth, and operating system license version |
With the scalability numbers as high as specified in Table 4.1,
implementing a single site (which would be the central site) provides
ConfigMgr administrators the ability to manage a very large number of
clients. Most often, the number of site servers is driven by various
demands—from the network team, management, political influences, and
finally technical requirements. A centralized hierarchy is the easiest
to manage if you have the bandwidth and hardware to support the client
load.
Note: ConfigMgr Site Database Placement
Starting in the late
1990s, Microsoft has recommended loading SQL Server locally on primary
site servers. The recommendation comes from the requirement for the WBEM
(Web-Based Enterprise Management) provider to have “fast access” to the
site database. However, if a high-speed connection is available to a
remote SQL Server, performance might be better than collocating due to
the more database-intensive processing required.
Centralized hierarchies, as displayed in Figure 2,
come in several flavors. A good example of ConfigMgr centralization is a
manufacturing company that has implemented one site in the United
States, another in Europe, and finally a third in Asia. The requirement
for a primary site server in Asia was one that falls into the technical
category, because several countries in that site use native language
operating systems that leverage double-byte characters.
Using three primary sites and hundreds of distribution points, the organization depicted in Figure 4.3
was able to effectively roll out patches monthly as well as operating
systems on demand in refresh and new system Operating System Deployment
(OSD) scenarios, provide remote support, perform detailed inventory, and
use a third party add-on—asset management—for thousands and thousands
of clients. This is managed using approximately six individuals around
the world supporting over 100 locations.
In some cases, organizations
implement a flat hierarchy to satisfy political desires within the
organization yet still comply with management’s desires concerning
inventory management, patching, and so on. The flat hierarchy model
allows for a simple hierarchy providing some measure of autonomy, while
still allowing a higher level of management over child sites. This is a
common approach when a complex hierarchy is required but the
organization wants to isolate network communication between tiers. Flat
hierarchies, such as the one illustrated in Figure 3, are particularly useful in situations where reliable network communications are of concern.
Regardless
of the hierarchy model implemented, the overall solution will work the
same and provide the same robust level of management across the
organization. The key difference is in the flexibility afforded by the
solution as a whole to the enterprise. It is up to the design team to
determine the hierarchy that will be best for the requirements, network,
and usage profile.
The next sections discuss areas to consider when developing your solution architecture.
Developing the Network Infrastructure
The design team
should spend a considerable amount of time on the network
infrastructure. Large amounts of data may be passed across the network,
and the traffic patterns will match that which may be blocked by a
variety of network intrusion detection systems (IDS), intrusion
prevention systems (IPS), and firewalls. Major roadblocks in a managed client
deployment often occur at the lowest layers in the Open Systems
Interconnection (OSI) model, with large amounts of time spent
troubleshooting it at the application level.
|
If your network is using
solutions such as IDS and IPS between site servers and clients, you will
need to work with the network group to configure these systems properly
to allow ConfigMgr traffic. Due to the nature of discovery, client
pushing, and the client connecting to AD and management points (MPs),
the traffic pattern matches what is commonly known as a zombie attack and will therefore be blocked by these solutions.
The symptom is usually a
ConfigMgr client that is only partially installed. In addition, many of
these solutions seem to block this traffic when in passive mode and
without logging it. You will need to refer to your specific solution’s
support information to configure it to allow this traffic.
|
Network mediums such as
Frame, ATM, and so on are usually transparent to the ConfigMgr solution.
Little regard needs to be given to the network medium, but this is not
the case with the individual circuit speed. Understanding circuit
speeds, the number of clients at a given location, and the expectations
of software distribution are the three most substantial factors in
planning where to place distribution points (DPs). If client demands are
significant enough, such as a large number of systems at a location
with inventory and software distribution requirements, an additional
primary or a secondary ConfigMgr site may be warranted.
The following times
are examples of how long a circuit could be saturated pushing software
such as Microsoft Office to a distribution point:
A 1GB file transferred over a 512Kbps link will take approximately 4 hours and 40 minutes.
A 1GB file copied over a T1 will take only 1 hour and 33 minutes.
Increase this circuit to a DS3, which is approximately 45Mbps, and the transfer time drops to just over 3 minutes.
This scenario
demonstrates how additional bandwidth may be required in locations that
may have previously not needed such bandwidth capacity. You can recoup
the return on investment (ROI) of this additional bandwidth with lower
overall administrative costs, including the following:
Reducing or eliminating the need for local server resources
Reducing or eliminating the need for remote backup operations
Reducing travel for IT resources that travel to locations for administration or support reasons
Consolidating voice and data services over a single circuit
Eliminating long-distance charges due to interoffice direct dialing
