Configuration Manager clients
and server systems use a variety of protocols to communicate with each
other across the network. The following sections discuss the network
communications between server roles within a site, the communications of
ConfigMgr clients with servers in the site, and communications between
sites.
Intrasite Server Communications
A ConfigMgr site
contains of a set of servers carrying out various system roles. In the
simplest configuration, the ConfigMgr site server holds all deployed
site system roles. Designs that are more complex may involve moving
certain roles to other servers within the site. Assigning roles to
multiple servers brings network considerations into play for intrasite
communications. This section discusses the protocols used for network
communications and the flow of information between site systems.
Configuration Manager
site systems use various protocols to communicate with each other. The
most important protocols include the following:
Configuration Manager site systems use standard SQL Server communication protocols to talk to MicroSoft SQL Server.
The site server and other systems use the Remote Procedure Call (RPC) protocol to invoke remote functionality on other systems.
Most file-transfer operations use the Server Message Block (SMB) protocol.
BITS and various other services use Hypertext Transfer Protocol (HTTP) and/or Secure Hypertext Transfer Protocol (HTTPS).
The following sections discuss the specifics of these protocols.
Communications with SQL Server
With Configuration
Manager 2007, SQL Server connectivity uses standard SQL Server TCP/IP
communications. Microsoft reserved Transmission Control Protocol (TCP)
port 1433 as the default port with the default SQL Server instance; for
named instances, the port is dynamic and is not 1433—the SQL Browser
listens on User Datagram Protocol (UDP) port 1434 and directs the
connection to a dynamically chosen TCP port. You can use the SQL client
network configuration tools and server setup to specify a port other
than 1433 for the default instance. For additional information on
changing the port used by SQL Server, see http://support.microsoft.com/kb/823938,
which describes static and dynamic port allocation as well as
configuring SQL Server to use a static or dynamic port. Although
ConfigMgr supports Named Pipes connections to SQL Server, you should use
the Named Pipes protocol for troubleshooting only.
The primary site
server, SMS provider, and management point all make intensive use of SQL
Server. The reporting point, PXE (Preboot Execution Environment)
service point, and server locator point (SLP) also access the database
directly. In Configuration Manager 2007 Release 2 (R2), the reporting
services point, multicast-enabled distribution point, and client status
reporting host also connect to the site database.
Note: About Named Pipes
Named Pipes uses NT LAN
Manager (NTLM) authentication only and does not support Kerberos
authentication. Kerberos provides mutual authentication of the client
and server, whereas NTLM authenticates the client only. TCP/IP also
provides better performance under challenging network conditions such as
across a wide area network (WAN) link.
The Configuration
Manager console accesses the site database using the SMS provider, which
is an intermediate Windows Management Instrumentation (WMI) layer used
for database communication. Figure 1
shows the systems that communicate with SQL Server. The figure does not
show other communications involving these site systems, such as
communications with the site server or with clients.
Communications Using RPC
RPC is an
industry-standard protocol used to invoke code across process
boundaries, generally between processes on different machines. The
calling process initiates an RPC call on TCP or UDP port 135 and
receives a response on a dynamically allocated TCP port in the range of
1024 to 5000 (unless you have configured a custom range on your systems,
which can be done using the RPC Configuration Tool [RPCCfg.exe] from
the Windows Server 2003 Resource Kit). The site server initiates RPC
connections for configuring site systems.
Communications Using SMB
SMB
is the core protocol for Windows file, printer, and port sharing and
for interprocess communications mechanisms such as Named Pipes and Mail
Slots. Configuration Manager components rely heavily on file exchanges
to communicate with each other. Most site systems also pass
status message and state message files back to the site server using
SMB. SMB traffic involves a series of requests and responses, which can
involve multiple roundtrips between the communicating systems. This
means that network latency can substantially affect certain SMB
communications.
The largest
file transfers between site systems involve distributing software
packages (including Operating System Deployment [OSD] image files) to
distribution points. Transfers from the site server to a standard
distribution point use SMB. The Distribution Manager component of
Configuration Manager handles distributing packages to the standard
distribution points within the site. Branch distribution points use BITS
to download packages from standard BITS-enabled distribution points.
Software distribution
settings are located under System Center Configuration Manager ->
Site Database -> Site Management -> <Site Code> <Site Name> -> Site Settings -> Component Configuration in the Configuration Manager console. As shown in Figure 2,
several parameters are available that you can tune to regulate how
packages are sent to distribution points. These parameters control
concurrent distribution and retry behavior. The first section
(Concurrent distribution settings) allows packages to be sent in
parallel to more than one distribution point, whereas the second area
(Retry settings) controls how often to retry unsuccessful sending
attempts as well as the delay in minutes before retrying. The settings
in this figure are the default settings.
Maximum number of packages— Specifies the maximum number of packages (from one to seven) that can be copied to distribution points in parallel.
Maximum threads per package—
Specifies the maximum number of threads (from 1 to 50) allocated to
each package during distribution. The maximum total number of threads
allocated to package distribution is (Maximum number of packages) ×
(Maximum threads per package).
Number of retries— Specifies the number of times (from 1 to 1,000) that the Distribution Manager will retry a failed package distribution attempt.
Delay before retrying (minutes)— Specifies the delay (from 1 minute to 1,440 minutes [24 hours]) before retrying a failed distribution attempt.
The distribution
settings dialog box also provides a check box to enable the option Send
package from the nearest site in the hierarchy. This option causes child
sites to retrieve newly targeted packages from the nearest site at
which the required packages are available, rather than from the source
site for the package.
Although
increasing the maximum packages and maximum threads per package will
require more server and network resources, it results in faster package
deployment. In many instances, you can increase the maximum number of
threads from the default value of 5. Adjustments to these values should
be based on the following criteria:
The retry and
delay settings determine the resiliency of your package distribution if
you encounter intermittent connectivity problems. The reliability of
your network and the Mean Time To Restore (MTTR) specified in your
Service Level Agreements (SLAs) governing network outages determine the
optimum settings for your environment.
Caution: Use Care when Adjusting Distribution Point Settings
Changing the distribution point settings shown in Figure 5.2
will have an impact on overall site function. If you are already seeing
backlogs in any of the inboxes or sluggish site server processing,
adjusting these settings may make overall performance worse.
Site System Communications Using HTTP and HTTPS
HTTP and
HTTPS (secure HTTP) are used for communication between the site server
and the software update point (SUP). Branch distribution points also use
these protocols for BITS-enabled transfers of packages from standard
distribution points.
At
the highest-level site in your hierarchy that has a software update
point configured, the SUP will need to connect to the Internet over HTTP
to synchronize with Microsoft updates. If the server is not able to
connect to the Internet directly, you can specify a proxy server on the
ConfigMgr software update point properties page, as displayed in Figure 3.
To access this page, expand the ConfigMgr Console tree to System Center
Configuration Manager -> Site Database -> Site Management ->
<Site Code> <Site Name> -> Site Settings -> Site Systems -> <Site System> and then right-click ConfigMgr software update point and choose Properties.
Software update
points at downstream sites can synchronize with a Windows Software
Updates Server (WSUS) at a higher level of the hierarchy.
Replication of Package Refresh Data
When you initially
deploy a package to a distribution point, Configuration Manager provides
two mechanisms specifically designed to minimize the amount of network
traffic generated when replicating changes to the package. These
mechanisms are delta replication and binary differential replication:
Systems Management Server (SMS) 2003 introduced file-based delta replication.
When a package is updated, a delta compressed package file—containing
only the files that have changed since the previous version—is created
in addition to the full compressed package file. The source site server
will maintain deltas for up to five versions of a package. Only changed
files are sent if the package is sent to a distribution point or site
that already has one of the previous five versions of the package.
A new option in Configuration Manager 2007 is binary differential replication of packages. Binary differential replication works similarly to delta replication, with two exceptions:
A binary comparison of the files is made.
Only the portions of the files that have changed are sent, not entire files.
Binary
differential replication is highly advantageous for packages consisting
of very large files, such as Windows Installer packages or operating
system (OS) images.
For
packages with many small files, binary differential replication may not
be worth the overhead it incurs. You can enable the option to use
binary differential replication on a per-package basis.
Other Server Communications
In addition to communications between Configuration Manager systems, the following basic network services are required:
Active Directory
Domain services
Global Catalog (GC) services
DNS (Domain Naming Service)
NetBIOS name resolution (in some configurations)
If
you have any of the Active Directory discovery methods configured, a
high volume of network traffic will occur between the site server and
domain controller (DC) while AD discovery is running.
