IN THIS CHAPTER
Chapter 4, “Configuration Manager Solution Design,” discussed how using the framework of a solutions-based architecture could help to unleash the value of System Center Configuration Manager (ConfigMgr). Since today’s Information Technology (IT) solutions typically are delivered in a networked environment, effectively planning and implementing a ConfigMgr implementation is contingent on understanding your network, including the resources it offers and the limitations it imposes.
Central to the planning process is the reality that communication between systems is dependent on the network that connects them. Understanding how ConfigMgr lives within the network will help you design, deliver, and manage successful solutions to meet your business objectives. A recurrent issue with management solutions is providing the required core management services—without consuming excessive network resources or adversely affecting other network activity. When you start planning your Configuration Manager deployment, you should review all available network documentation and engage the team that supports the network in your organization. A consideration of how ConfigMgr will affect your network is critical to the success of your deployment.
This chapter discusses the ways in which Configuration Manager uses the network, with approaches for optimally delivering solutions in various network environments. The discussion includes the following areas:
• Discussing the network requirements for each ConfigMgr communication process.
• Understanding how Configuration Manager deals with fast and slow networks.
The Background Intelligent Transfer Service (BITS) is a key enabling technology in delivering Configuration Manager services. The chapter includes a detailed discussion of BITS to help in implementing and troubleshooting these services.
• Evaluating which network conditions to consider when designing your ConfigMgr hierarchy and server placement.
• Examining the special challenges around mobile, disconnected, and sometimes connected users.
• Considering how you can use Configuration Manager to discover network resources.
• Using Internet Protocol (IP) subnets and Active Directory (AD) sites to optimize delivery of services to your client systems.
• Discussing network communication problems that may occur and how to troubleshoot them.
After you complete this chapter, you should have a fundamental understanding of how Configuration Manager works in a networked environment. You will be able to use your knowledge of Configuration Manager networking to optimize your deployment and effectively troubleshoot network-related issues.
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.
As previously described in Chapter 2, “Configuration Manager 2007 Overview,” 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. For information on how network considerations affect your decision of how to distribute server roles, see the “Server Placement” section of this chapter.
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.
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.
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 5.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.
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.
Locating the Windows 2003 Resource Kit Tools
The Windows Server 2003 Resource Kit Tools are available at http://go.microsoft.com/fwlink/?linkid=4544.
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, as described in Chapter 3, “Looking Inside Configuration Manager.” 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. Packages are sent between sites using the sender mechanism, described in the “Site-to-Site Communications” section of this chapter.
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 5.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 available capacity of the network connecting your site server to the distribution points
• Monitoring the bandwidth used by package distribution
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.
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.
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 5.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.
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. Chapter 13, “Creating Packages,” and Chapter 14, “Distributing Packages,” discuss options for configuring packages and sending them to distribution points.
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. Chapter 12, “Client Management,” discusses Active Directory discovery methods.
Configuration Manager is designed to use Internet standard protocols for most client communications. In addition, most of the client communication ports are configurable. Configuration Manager supports both mixed and native mode sites. In mixed mode sites, most client communications are over HTTP, whereas native mode sites use HTTPS. For more information about mixed versus native mode, see Chapter 6, “Architecture Design Planning.”
Data sent across the network using the TCP or UDP protocol is transmitted in discrete units of data called packets. Each packet includes the following:
• A body that contains the actual data
• A header with addressing and other control information
The header includes the IP addresses of the source and destination machines as well as the port numbers of the source and destination services or applications. A port number is a number from 1 to 65535 used to identify the application. An application or service “listens” on a specific port if it has registered with the operating system to receive packets addressed to that port. Like many services, Configuration Manager services have standard ports on which they listen by default.
Table 5.1 lists the communications protocols and ports used by various applications and services. You can also find information regarding the communication protocols and ports used by ConfigMgr at http://technet.microsoft.com/en-us/library/bb632618.aspx.
In addition to standard ConfigMgr 2007 traffic, Network Access Protection (NAP) generates the traffic described in Table 5.2. If you use firewalls that block this traffic, you must reconfigure them for NAP to work with ConfigMgr 2007. You will also need to identify ports used by the client to communicate with the System Health Validator point (SHV). The NAP enforcement client you are using determines the ports for system health validation.
Information online regarding ports for NAP in Configuration Manager 2007 is located at http://technet.microsoft.com/en-us/library/bb694170.aspx.
You may choose to use custom rather than standard ports for client-to-server communications for the following reasons:
• Custom ports may be necessary for Configuration Manager to work with your network firewall policies.
• You may also need to use a custom website for ConfigMgr instead of the default site on your Internet Information Services (IIS) servers. Although this is not a best practice, it may be necessary if ConfigMgr is sharing IIS servers with other applications that depend on the default site.
You may specify custom ports for client communications during either Configuration Manager setup or later using the ConfigMgr console:
• During setup, you can specify a custom HTTP port for mixed mode sites or a custom HTTPS port for native mode sites in the Port Settings dialog box, displayed in Figure 5.4.
The port specified in Figure 5.4 is used for client-to-server communications by all site systems.
• After setup, you can change your selection and add alternate ports on the Ports tab of the Site Properties sheet in the ConfigMgr console. Perform the following steps:
Specifying Different Ports
If you utilize custom ports or custom websites, you should use them consistently throughout your hierarchy. Using different ports or websites at different sites can cause problems as clients roam from one site to another.
Regardless of whether you change the default HTTP and HTTPS ports, it is always a good idea to specify alternate ports to increase the availability of these services.
The initial communication between the client and the ConfigMgr hierarchy occurs during client installation. The sequence of network calls depends on the client installation method used. Client installation methods are discussed in detail in Chapter 12. For purposes of this discussion, there are two general types of client installation methods:
• Server initiated (client push)
• Client initiated (all other methods)
Client push installation includes a preinstallation phase in which the site server connects to the client to initiate installation:
• In the client push installation method, the server makes an initial connection to the admin$ share on the prospective client computer using Windows file sharing protocols.
• The server also establishes a WMI connection to the client using the Distributed Component Object Model (DCOM) through TCP port 135.
DCOM is a Microsoft standard for communication between software components, either on a local computer or across a network. This approach differs from SMS 2003, which used a remote Registry connection rather than WMI.
• The site server uses these connections to copy the required setup files to the client and then installs and starts the ccmsetup service. Additional requirements for client push installation are covered in Chapter 12.
Once the preinstallation phase is complete, the installation proceeds in a manner similar to other installation methods.
Regardless of the client installation method used, the first network-related task for the new client is to locate and contact a management point (MP) for its assigned site. From this point onward, the MP will be the primary point of contact between the client and its site. Unless the client installation source files are staged locally, the setup process uses BITS to pull the files from the CCM_CLIENT website on the MP. Once the client is installed, it continues to communicate with the management point using HTTP or HTTPS, and generally uses BITS to download policy and component updates and to send client information, including inventory, metering data, state messages, and status messages, to the site.
There are three general ways for the client to determine the site it is assigned to as well as to locate the management point for that site:
• Depending on the installation method used, the site code and management point may have been supplied as command-line arguments. The management point may be specified using an IP address, a Fully Qualified Domain Name (FQDN), or a simple name.
• If the information is not provided via the command line, clients in the same Active Directory forest with the site server can generally retrieve this information by querying AD (assuming the schema is extended and the appropriate information is published in AD).
• If the required information is not available in AD, the client must contact a server locator point for site and management point information:
• The SLP may be specified in the command line.
• If the SLP is not provided through the command line, it must be resolved through NetBIOS name resolution.
• If you are using WINS server for NetBIOS name resolution, you must manually add the SLP entry to WINS following the procedure found at http://technet.microsoft.com/en-us/library/bb632567.aspx:
Open a command prompt (Start -> Run, and then type cmd), type netsh, and then press Enter.
Type wins and then press Enter.
Type server and then press Enter.
Type the appropriate command to add the name. Here’s an example:
add name Name=SMS_SLP endchar=1A rectype=0 ip=<server locator point IP
address>
• If a WINS server is not available, you can supply the SLP information using an LMHosts file. The SLP information in LMHosts is as follows:
<SLP IP address > "SMS_SLP