System Center Configuration Manager 2007 : Configuration Manager Network Communications (part 1) - Intrasite Server Communications

9/25/2012 8:58:59 PM
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.

Figure 1. SQL Server communications

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.

Tip: Locating the Windows 2003 Resource Kit Tools

The Windows Server 2003 Resource Kit Tools are available at http://go.microsoft.com/fwlink/?linkid=4544.

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.

Figure 2. Distribution point 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.

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.

Figure 3. The software update point properties page

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.

Top 10
Review : Sigma 24mm f/1.4 DG HSM Art
Review : Canon EF11-24mm f/4L USM
Review : Creative Sound Blaster Roar 2
Review : Philips Fidelio M2L
Review : Alienware 17 - Dell's Alienware laptops
Review Smartwatch : Wellograph
Review : Xiaomi Redmi 2
Extending LINQ to Objects : Writing a Single Element Operator (part 2) - Building the RandomElement Operator
Extending LINQ to Objects : Writing a Single Element Operator (part 1) - Building Our Own Last Operator
3 Tips for Maintaining Your Cell Phone Battery (part 2) - Discharge Smart, Use Smart
- First look: Apple Watch

- 3 Tips for Maintaining Your Cell Phone Battery (part 1)

- 3 Tips for Maintaining Your Cell Phone Battery (part 2)
- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 1)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 2)

- How to create your first Swimlane Diagram or Cross-Functional Flowchart Diagram by using Microsoft Visio 2010 (Part 3)
Popular Tags
Microsoft Access Microsoft Excel Microsoft OneNote Microsoft PowerPoint Microsoft Project Microsoft Visio Microsoft Word Active Directory Biztalk Exchange Server Microsoft LynC Server Microsoft Dynamic Sharepoint Sql Server Windows Server 2008 Windows Server 2012 Windows 7 Windows 8 Adobe Indesign Adobe Flash Professional Dreamweaver Adobe Illustrator Adobe After Effects Adobe Photoshop Adobe Fireworks Adobe Flash Catalyst Corel Painter X CorelDRAW X5 CorelDraw 10 QuarkXPress 8 windows Phone 7 windows Phone 8