Capacity Planning
Capacity
requirements are frequently miscalculated in the initial planning phases
of ConfigMgr deployments because adequate thought is not given to the
actual amount of data that will be kept on each site server and site
system. Adding storage after the fact is a rather
difficult situation to deal with; it frequently requires outages,
possibly moving roles around, and in general is something that could
have been dealt with in advance if properly architected.
A number of items contribute to ConfigMgr capacity requirements:
Software inventory has the ability to do file collection.
In
a 5,000-seat environment, collecting a 1MB file will add 5GB of storage
to the server, backups, and the network load while transferring the
data. ConfigMgr software inventory file collection can be configured to
limit the maximum amount transferred per client, but the site server and
network infrastructure will need to handle this size times the number
of clients reporting to the site server or hierarchy.
Adding
a software file extension such as .dll to your inventory can easily
double the ConfigMgr database size. Tables in the ConfigMgr database
such as softwarefile can grow exponentially in size, affecting reporting
and Resource Explorer performance. When designing your ConfigMgr
solution, it is important to know what software file types will be
inventoried to help determine backend storage requirements from a
capacity and performance perspective.
You can scale SUPs and MPs beyond 25,000 clients per site by implementing these site system roles with NLB, as illustrated in Figure 5.
If you
are implementing NLB on an MP in a mixed mode site, IIS does not allow
clients to authenticate to the site system using Kerberos
authentication. To support an NLB implementation, you must reconfigure
the website application pools running under the Local System account to
run under a domain user account.
Distribution points have disk I/O and network I/O constraints.
Considerations
affecting the size of the volume needed include how many packages are
planned to be kept on distribution points year-round, and the number of
packages a given distribution point is expected to support. Although the
ConfigMgr documentation states that a distribution point can handle up
to 4,000 clients, network speed, disk performance, and package size
greatly impact this value.
Tip: Capacity Planning Calculations
DPs and state
migration points are site systems with unique capacity requirements. As a
rule of thumb, take the current size of your existing software library
volume and then triple it to use as a starting point for DPs or package
source repository requirements.
The
state migration point (SMP) is a Configuration Manager 2007 site role
providing a secure location to store user state, data, and settings,
prior to an operating system deployment.
You
can store the user state on the SMP while the operating system
deployment proceeds, and then restore the user state to the new computer
from the state migration point, as illustrated in Figure 6.
Each
SMP site server can only be a member of one Configuration Manager 2007
site. State migration points provide ConfigMgr administrators the
ability to store users’ data
and purge it automatically after it has become stale, a period defined
by the ConfigMgr administrator. The concept behind this relies on the
data being restored or backed up within the allotted threshold. Figure 7 shows the state migration point properties.
Site Boundaries
ConfigMgr boundaries,
are logical groupings defining where the site server has management
capabilities. You can specify boundaries using AD sites, Internet
Protocol (IP) subnets, IP address ranges, or IPv6 prefixes. Figure 8 depicts the Dallas site boundary on the Bluebonnet central site.
When defining
boundaries, the ConfigMgr administrator must define whether these
boundaries are slow or fast (which really means unreliable or reliable).
Boundaries should be unique to each site server and ideally not
overlap.
When planning your
ConfigMgr site boundaries, you may discover unique requirements for
some AD sites or subnets, which may often lead to creating additional
ConfigMgr sites. Some client settings at a site level only may not be
allowed on certain subnets or AD sites (as an example, remote
controlling a computer without user interaction). This action may be
prohibited in the Accounting AD site or subnet and ultimately require
an additional site server with unique settings for the location.
Roaming
Roaming in ConfigMgr is the
capability allowing clients to move between sites in the hierarchy, yet
still be managed, while making the best use of local network resources.
ConfigMgr clients have the ability to roam throughout the hierarchy,
allowing clients to leverage services from a nearby site server in the
hierarchy so that traversing a WAN or “slow” network is not required. As
an example, if a client is at a remote location supporting a site
server the client does not belong to, the client can use the roaming
feature to install packages off that site server’s DP if the packages
are present, thus minimizing impact to the WAN and optimizing the
end-user experience of software distribution.
Figure 9
illustrates how a client can roam to a different network defined as a
slow or unreliable network managed by another site. This is a common
scenario when laptops travel, which allows ConfigMgr clients to
automatically download and execute packages rather than installing them
across the WAN.
The following
includes information taken from the “About Client Roaming in
Configuration Manager” section of the ConfigMgr help file.
Roaming occurs
when a ConfigMgr client leaves the corporate local area network (LAN)
and changes to a home network environment. Roaming is often a
misunderstood concept and technology—the simplest way to view roaming
behavior is to understand that whenever a client changes network
subnets, it is roaming. Roaming always involves an IP address change.
Roaming boundaries are based on subnets in the hierarchy, which indicate
where the ConfigMgr administrators want the clients to go to download
content.
Global roaming,
which is only available if you have extended the schema, occurs when a
client first identifies the site into which it has roamed, by comparing
its current IP address with the list of IP subnets that define the
boundaries in the hierarchy. When the client finds a match for the
boundary, it can identify which site is configured for that boundary and
locate the management point for that site. The default management point
for the site that the client has roamed into is referred to as the resident management point.
The resident
management point informs the roaming client of distribution points in
its site containing package source files that the client can access.
However, if the package source files are not available in the site the
client has roamed into, the client falls back to asking its default
management point for distribution points.
If Active Directory
is not available, or if the Active Directory schema is not extended,
clients can roam only to the lower-level sites of their assigned site.
This is called regional roaming. In regional roaming, the client can roam to lower-level sites and still receive software packages from distribution points.
When an
advertisement is sent to the client, the client receives information
about the advertised package location from its assigned management
point. Alternatively, if the client has roamed into a secondary site, it
receives information about the advertised package location from a proxy
management point, if one is available. The client then uses the
distribution points of one of its assigned site’s lower-level sites. The
distribution point it uses depends on which roaming boundary the client
is in and whether the advertised package is available on the
distribution point.
Global roaming allows the
client to roam to higher-level sites, sibling sites, and sites in other
branches of the ConfigMgr hierarchy and still receive software packages
from distribution points. Global roaming requires Active Directory and
the Active Directory schema extensions. Global roaming cannot be
performed across Active Directory forests.
Regional roaming
behavior occurs when clients cannot access Configuration Manager 2007
site information published to AD; these clients continue to contact the
default management point in their assigned site. The clients are not
aware of the site’s identity that they have roamed into, or of the
management points in that site.
In
this scenario, when clients roam into a site that is lower in the
hierarchy than their assigned site (for example, a child site or a
grandchild site), the client’s default management point informs the
roaming client of the closest distribution points the client can access.
