Extending the Schema
Leveraging
Active Directory with schema extensions provides a constant, redundant,
easily accessible, and secure location when querying for ConfigMgr
information. This makes extending the schema the preferred approach when
implementing ConfigMgr. If you previously extended the AD schema for
SMS 2003, it should be extended again because not all functionality for
ConfigMgr 2007 exists in SMS 2003 schema extensions. Table 2 illustrates the ConfigMgr features that depend and benefit from AD schema extensions.
Table 2. Schema Extension Dependencies for ConfigMgr 2007
| Feature | Schema Extension Required |
|---|
| Client installation and site assignment | Recommended |
| Site mode setting and related settings such as client certificate selection and CRL checking | Recommended |
| Port configuration for client-to-server communication | Recommended |
| Global roaming | Required |
| Network Access Protection (NAP) | Required |
| Secure key exchange between sites | Recommended |
| Verifying a trusted management point | Recommended |
| Recovering from the failure of a central site server hosting the management point role | Recommended |
When the schema is not
extended, ConfigMgr administrators have to perform manual maintenance
tasks that could otherwise be automated with ConfigMgr 2007. These
include running scripts and maintaining group policy objects (GPOs) as
well as other items required to roll out clients and have them perform
with acceptable functionality. Many of the workarounds published in the
ConfigMgr online help file do not even scale to support medium-size
deployments.
Secondary Site Considerations
It is extremely important to
understand how to leverage secondary sites over slow links when defining
the distribution point architecture across the WAN. Secondary site
servers can host a role known as the proxy management point (PMP),
which, to conserve bandwidth, caches a local copy of the policies stored
on the parent primary site.
If you place
distribution points in a secondary site, clients that are local to the
secondary site and within its boundaries can request content from a
local DP rather than downloading it across the WAN. The benefit here is
that although multiple clients request the content, it is only sent
across the slower WAN link once and then installed locally across the
LAN by each client. This conserves bandwidth and improves the end-user
experience.
You can also use
branch DPs in this manner, which provide the added benefit of being
supported on client operating systems such as Windows XP and Vista. If
you’re deploying secondary site servers purely for the sake of
throttling transmissions to DPs, use branch DPs rather than creating
secondary sites. However, although branch DPs will keep traffic down,
they do not provide the ability to cache and push client inventories,
status messages, and policies, as does the PMP of a secondary site
server. Branch DPs are limited to 10 concurrent connections when being
run from a client operating system rather than a server.
Secondary site
servers have a number of advantages and limitations, which should be
understood to implement them in your organization effectively.
Advantages of secondary site servers include the following:
Do not require a ConfigMgr Server license.
Do not require a SQL Server database.
Can be managed remotely.
Can have PMPs to optimize WAN traffic.
Can have DPs to optimize WAN traffic.
Here are some of the disadvantages of secondary site servers you will want to consider:
Cannot have child sites.
Can only have a primary site as a parent site.
Cannot be moved in the hierarchy without uninstalling and then reinstalling.
Cannot be upgraded to a primary site.
Cannot have ConfigMgr clients assigned to them; hence, client agent settings are inherited from the primary parent site.
Although
configuring the site address allows throttling and scheduling of
inventories as well as status and policy transmissions, overly
restrictive settings may result in undesirable behavior.
Note: Secondary Site Upgrades
ConfigMgr
provides the capability to upgrade SMS 2003 secondary sites to
ConfigMgr 2007 secondary sites; however, this process will not upgrade a
secondary site to a primary.
Site Modes
ConfigMgr provides two
modes of security: mixed and native. If you are familiar with SMS 2003,
that version used standard and advanced site security modes. Different
from SMS 2003, if you upgrade the site to the more secure mode, you can
downgrade it later. ConfigMgr 2007’s mixed mode is functionally
equivalent to SMS 2003’s advanced security. Because self-signing of
transmissions by the management point or the site server using
certificates is only available with ConfigMgr, Internet-Based Client
Management (IBCM) is not available on ConfigMgr sites running in mixed
mode, as IBCM requires manipulating the certificate templates. On the
other hand, authentication between clients and site servers uses the
same proprietary technology as SMS 2003 when ConfigMgr is in mixed mode.
Native mode
introduces new functionality and complexity to ConfigMgr security, such
as using industry-standard Public Key Infrastructure certificates and
Secure Sockets Layer (SSL) authentication between clients and site
systems. ConfigMgr also supports third-party certificates, as long as
their template is modifiable. SSL does not encrypt transmissions of
policies; these are signed by the site server and management point.
Metering data, status messages, policy, and inventory are all signed and
encrypted. Because IBCM requires clients to communicate over HTTPS
across the Internet to the ConfigMgr hierarchy, it requires native mode.
Note: Securely Publishing to the Web
When publishing HTTP or
HTTPS to the Web from inside a network, you should use Microsoft
Internet Security and Acceleration (ISA) Server to perform web
publishing of these ports. ISA acts as a reverse proxy in this fashion
and provides application layer packet inspection to protect internal
systems from malicious code.
Configuration Manager 2007 Roles
ConfigMgr 2007 has
numerous roles that serve various purposes. Some roles are mandatory,
some are optional, and some are recommended.
Table 3. ConfigMgr 2007 Roles
| Role | Mandatory/Recommended/Optional |
|---|
| Site/component server | Mandatory |
| Management point | Recommended; mandatory if hosting clients |
| Server locator point | Recommended |
| Distribution point | Recommended |
| Reporting point | Recommended |
| State migration point | Optional |
| PXE service point | Optional |
| Software update point | Recommended |
| Fallback status point | Recommended |
| System Health Validator | Recommended |
| Out of Band service point | Optional |
| Asset Intelligence sync point | Optional |
| Reporting service point (R2) | Recommended |
Each role has different
purposes that create unique loads on the site system housing that role.
You will need to plan to ensure the site system can handle the load
placed on it once in production. The following sections touch on many of
the common design considerations that go into a ConfigMgr deployment.
Site Servers
Site servers are the
most heavily planned role in the hierarchy. They typically include a
local installation of SQL Server and the reporting point, may have
thousands of systems reporting to them, run queries, update collection
membership, house the management point and server locator point (SLP),
and provide connections for ConfigMgr administration consoles across the
organization. Site servers handle updating distribution points, process
discovery data, and collect inventory from client systems. When a
hierarchy of sites exists, site servers also replicate bidirectionally,
sending collection, query, and various package data down the hierarchy
and consuming inventory data from the lower tier of the hierarchy.
Inventory data is only replicated from any given child to its parent and
from that site to the next parent site if one exists. Eventually all
inventory data makes it to the top of the hierarchy, the central site.
In large implementations, the central site does not have any clients,
and it is used primarily for reporting purposes.
Note: Placement of the Reporting Point Role
Microsoft
recommends placing the reporting point role on a dedicated system in
the central site position of the hierarchy for large deployments, to
offload the reporting impact on SQL Server.
Collections are
updated on a schedule in ConfigMgr, which defaults to every 24 hours
beginning at the time the collection was created. Depending on the size
of your site and the habits of your ConfigMgr administrators, there may
be hundreds to thousands of collections. With so many collections
updating against the SQL Server database, you may see a negative
performance impact if too many collections are updating or collections
are updating too often. This is a scenario often observed in the field,
when large numbers of clients in collections are updating on a very
aggressive schedule, such as hourly or every 15 minutes. Although these
types of intervals are sometimes required, it is important to understand
the load this puts on SQL Server and Windows disks. Adequate spindle
counts will allow such aggressive collection evaluation.
Tip: Collection Evaluation
Take note of the
collection evaluation intervals and throttle back the evaluation
intervals on those collections rarely used. It is common to find many
collections that only need updating on a weekly basis, thus freeing
resources on the site server for other pertinent tasks.
Distribution Points
Distribution points
are typically the most heavily used role from an I/O perspective in all
of ConfigMgr. Hundreds to thousands of clients may download or install
packages from any given distribution point. Because each environment has
unique circumstances around the volume of packages they push, the
frequency in which the packages are pushed, and the average size of the
packages, it is difficult to create a standard recommendation for sizing
distribution points. Here are several best practices for DPs:
Use BITS whenever possible to download and execute packages.
Protect DPs on slow links or in remote locations.
Verify there are enough spindles on the DP to support the packages pulled from them.
Group distribution points as possible, for simpler administration.
Make sure DPs have sufficient drive space to accommodate packages.
If
DPs are placed on a system with multiple purposes, such as a domain
controller, make sure the load will not hinder other services the system
provides.
When
placed on systems providing other network services, the DPs should be
placed on a dedicated logical drive, if possible, to segregate I/O.
If a WAN link exists
between a site server and the distribution point, using a secondary site
server for the remote DP has a number of advantages. The primary
benefit is the scheduling and throttling of traffic between the primary
site server and secondary site server in regard to package replication.
Here are some points to keep in mind:
When the WAN
link is reliable but somewhat small (such as a T1) or the link hosts
important services for users across the WAN, a secondary site server
housing the DP is highly recommended, as shown in Figure 4.
When
the WAN link is unreliable or very slow (such as in a circuit under
1.5Mbps), it is best to use a branch DP, which enables leveraging BITS
to replicate the package data.
System Health Validator
Network Access
Protection requires Windows Server 2008. The NAP role is dependent on
the Server 2008 version because it obtains the network policy data from
Windows Server 2008. Windows Server 2008 has a role within the operating
system itself called the Network Policy Server (NPS) role. This role
defines what is deemed as healthy and unhealthy as well as the
remediation actions to take when unhealthy clients are found. NAP relies
extensively on NPS and the ConfigMgr System Health Validator role. If
you plan to implement NAP, Windows Server 2008 and SHV will be a
critical piece of your ConfigMgr topology and architecture.
Server Locator Point
By
default, clients on the intranet query the Active Directory for their
site assignment and resident management point. If the AD schema is not
extended, server locator points become mandatory. SLPs are only required
when you are managing clients in a workgroup or another AD forest, or
have not extended the Active Directory schema. SLPs are not required
when IBCM is used. Typically, only one SLP per site is necessary if
implemented; the site server hosts this role in a sufficient manner.
Management Point
The management
point is the most significant role in the ConfigMgr site. This role is
the primary point for contact between clients and the site server. The
management point requires IIS and WebDAV (Web Development Authoring and
Versioning).
Note: MPs on Server 2008
You must download, install, and configure WebDAV manually on management points running Windows Server 2008.
Management points provide the following services to clients:
Installation prerequisites
Client installation files
Configuration details
Advertisements
Software distribution package source file locations
Receive inventory data
Receive software-metering information
Receive status and state messages from clients
When
provisioning an MP, the ConfigMgr wizard prompts the administrator for
whether the site database (which is the default) or a database replica
should be used. The database replica option should only be selected when
desiring to use NLB for the MPs. The site systems hosting the MP roles must have permission to update their objects in AD.
Management
points can support intranet, Internet, and device clients. Management
points supporting Internet clients require a web server signing
certificate. By default, and as a best practice, the management point
computer account is used to access site database information.
Fallback Status Point
The fallback status point
(FSP) is the lifesaver of ConfigMgr 2007. It cannot be stressed enough
how important it is to implement this role. The FSP lets administrators
know when a client installation has failed, is having communication issues with the MP, and is left in an unmanaged state.
The FSP receives
state messages from clients and relays them to the site. Because clients
can be assigned to only one FSP, make sure to assign them prior to
deployment.
|
“Examples of state
messages a client might send to a fallback status point if it
encountered problems during client deployment include the following:
The client
failed to install properly (for example, because of incorrect setup
options or syntax errors, or because it failed to locate the required
files). The client failed to be assigned to a site. The client failed to register with its assigned site. The client failed to locate its management point. There was a network connectivity problem between the client and the management point. The
management point is not configured correctly (for example, IIS is not
configured correctly for a Configuration Manager Management Point).
In addition to
sending state messages when there is a problem during client deployment,
the client will send a state message to the fallback status point when
it is successfully installed and when it is successfully assigned to a
Configuration Manager 2007 site. In this scenario, the client will also
report if a restart is required to complete the installation.
Because the
fallback status point accepts unauthenticated communications, it accepts
state messages from native mode clients when PKI certificate issues
prevent communication between the client and its management point.
Examples of state messages a client might send to a fallback status
point to identify problems with native mode communication include the
following:
There is no valid client certificate. There is more than one possible valid client certificate without an appropriate certificate selection configuration specified. A server certificate needed for native mode communication fails to chain successfully to the trusted root certification. A server certificate needed for native mode communication is expired. A server certificate needed for native mode communication is revoked.
|
Software Update Point
Microsoft’s documentation
states that the software update point (SUP) role is required within the
ConfigMgr hierarchy if you are deploying software updates. The SUP
interacts with WSUS to configure settings, to request synchronization to
the upstream update source and on the central site, and to synchronize the software updates from the WSUS database to the site server database.
Note: ConfigMgr SP 1 Requirements
Configuration
Manager 2007 SP 1 requires WSUS 3.0 SP 1 at the time of this writing. As
service packs for both Configuration Manager and WSUS evolve, this
requirement may change. Make sure to refer to the release notes and
requirements prior to deploying either ConfigMgr or WSUS.
Never make changes to
WSUS from within the WSUS Administration console. The active software
update point is controlled via the ConfigMgr console. Changes made to
WSUS will be overwritten hourly by ConfigMgr’s WSUS Configuration
Manager component of the SMS Executive Service.
Reporting Point
A reporting point
(RP) is a ConfigMgr role designed to host web reports that query the
database of the primary site for which they belong. Because they require
SQL to run queries against, RPs can only belong to primary sites, not
secondary sites. When multiple primary sites are in a hierarchy, it is a
good idea to implement an RP at each primary site. This gives the
individual groups who manage the site servers the ability to run reports
specific to their managed environment.
Reporting points have the following requirements:
The site system computer must have IIS installed and enabled.
Active Server Pages must be installed and enabled.
Microsoft Internet Explorer 5.01 SP 2 or later must be installed on any server or client that uses Report Viewer.
To
use graphs in reports, Office Web Components (Microsoft Office 2000 SP
2, Microsoft Office XP, or Microsoft Office 2003) must be installed.
Note: Reporting Point Prerequisite Requirements
When you
install ASP.NET on a Windows Server 2008 operating system reporting
point, you must also manually enable Windows Authentication. For more
information, see the “How to Configure Windows Server 2008 for Site
Systems” section of the ConfigMgr R2 help file.
Office
Web Components is not supported on 64-bit operating systems. If you
want to use graphs in reports, use 32-bit operating systems for your
reporting points.
Not All Roles Are Available All the Time
Not every role is
available all the time to clients. If you will be implementing IBCM, it
is important to understand that only a few roles are available to
clients out on the untrusted network. Only the following roles are
available to IBCM clients:
