CHAPTER 5
Network Design

Configuration Manager (ConfigMgr) makes extensive use of your organization’s network to manage Windows systems and other supported devices. This can include any form of long-haul or global circuits, wide area network (WAN) links, local area network (LAN) connections, and even the Internet. If a system or device can reach your ConfigMgr site over some type of network connection, ConfigMgr can help manage it.

This chapter does not cover network design; it discusses how to design and configure ConfigMgr for your organization’s network. Similarly, this chapter assumes that basic network services required for any network application are working properly. This includes, but is not limited to, the following:

Name resolution and Domain Name System (DNS) services

Internet Protocol (IP) routing

IP addressing and Dynamic Host Configuration Protocol (DHCP)

Firewall and proxy configuration

Network considerations affect your site design and operations. The following key concepts are covered in this chapter:

Network Utilization: ConfigMgr needs to live within your network without adversely affecting it or other applications using it. In short, ConfigMgr must be a good citizen of your network, while providing its services within an acceptable time frame.

Service Location: Managed systems must be able to find the services provided by ConfigMgr, regardless of where in the network the services or managed systems are located.

Security: If compromised, the data and systems managed by ConfigMgr could pose a serious risk to your network and to your organization. Protecting ConfigMgr includes protecting the network communication that is integral to ConfigMgr’s operations.

Knowing how ConfigMgr uses the network helps you deploy and configure ConfigMgr correctly, as well as optimize its use of the network and available bandwidth. Without this knowledge and proper planning, ConfigMgr can become a costly endeavor, failing to live up to its potential or even its basic capabilities. This chapter discusses what you need to know, including information regarding communication and data flows, ports and protocols, and site design considerations.

When designing a ConfigMgr-efficient network, you should identify and map the locations where managed systems exist or will exist and where the primary ConfigMgr services will be hosted. The latter is generally a decision already made based on the location of your organization’s main datacenter. If your organization has multiple datacenters, you must choose which will host your core ConfigMgr services. The main or chosen datacenter should have good connectivity to all locations that will have managed systems. Direct connectivity is not required as long as the clients can reach this datacenter over the network.

If the size of your organization dictates that you will be using a central administration site (CAS) and multiple primary sites, this main or chosen datacenter is where you should locate the CAS and the first primary site’s site server.

For each client location, compile the following information:

Name

Number of managed clients

Available bandwidth

Expected management activities

Current network usage patterns

IP addresses used

Ability to place servers at location

Network path

Gathering this data is not a trivial task; however, it is important to be thorough and accurate, as nearly all of your design and configuration stems from this information.

Use the collected information to determine the placement and location of additional ConfigMgr servers, including primary site servers (if using a CAS), secondary site servers, and site systems within any site. In general, you want to add and place these additional servers to minimize WAN usage and maximize local connectivity. This doesn’t mean every location requires its own ConfigMgr server, just that you should consider placing one at every location with a larger number of managed clients or limited bandwidth. This determination is subjective and organization specific.

The ConfigMgr client agent communicates with only six specific site roles. These are often categorized as the client-facing roles:

Application Catalog Web Service Point

Distribution Point

Fallback Status Point

Management Point

Software Update Point

State Migration Point

All other site roles support site-centric operations and do not directly support clients. To ensure the best and fastest possible network connection, place these roles in close proximity to the site server for the site to which they belong. In general, the site server is usually the best location for these roles and is required for the Endpoint Protection Point role, which must exist on the top-level site server in the hierarchy if System Center Endpoint Protection (SCEP) will be used and managed by ConfigMgr. The service connection point (SCP) also must exist on the top-level site server.

Of the six client-facing roles just introduced, one role handles a vast majority of client traffic: the Distribution Point (DP) role. Place this role in close proximity to the managed clients to minimize WAN usage and support clients at remote locations. You can implement this in one of two ways: by directly placing site systems hosting the DP role at or near the client locations or by placing secondary site servers at or near the locations. Using a DP that is part of a primary site is generally preferred as it is simpler to deploy and maintain.

Secondary sites provide an intermediary between a client’s assigned site and the site that manages the client. Clients are never directly assigned to a secondary site but can use the roles attached to a secondary site. This includes the following client-facing roles:

Distribution Point

Management Point

Software Update Point

State Migration Point

When you attach these client-facing roles to a secondary site that is close to its clients, a client does not need to communicate with its assigned primary site, which may be across a WAN link. Clients can use these roles based on the boundaries and boundary groups configured in the hierarchy, discussed in the “Using Boundaries and Boundary Groups” section, later in this chapter.

TABLE 5.1 Using DPs Versus Secondary Sites

Site Role	Pro	Con
Distribution point	Simple Can be hosted on Windows workstations	Only handles content distribution to clients
Secondary site	Handles content distribution to clients using its own DP role Handles policy, inventory, and client messaging using its own Management Point (MP) role Handles Windows Server Update Services (WSUS) catalog distribution with its own software update point role Handles state migration data during operating system deployment using its own state migration point (SMP)	Complex Requires a local instance of SQL Server Express (or SQL Server) Uses SQL replication to exchange information with the primary site Must be hosted on Windows Server 2008 R2 or above No availability options

As Table 5.1 shows, secondary sites handle nearly all client traffic while keeping it local. This makes it appear that a secondary site is the preferred approach, but secondary sites increase complexity in the hierarchy and also create the possibility of orphaned clients. Clients could become orphaned if the secondary site server is unavailable for some reason, as clients using roles at that site would be unable to obtain policy or download content until boundaries were manually changed at the primary site. Changing the boundaries would enable the clients to use different MPs and DPs until the secondary site was repaired.

How do you choose between secondary sites and DPs without any strict guidelines? The authors recommend weighing the available bandwidth to a location—which should include factors such as existing congestion and usage patterns—against the number of client systems to be managed at that location.

Communication to the client

Communication from the client

Communication between ConfigMgr site servers and sites

The following sections take an in-depth look at the first two data flows; the third is covered in the “Designing Intrasite Communication” section, later in this chapter.

Policies: Policies tell a client that something needs to be done. A client policy is created when an administrator using the ConfigMgr console makes a change to the client. Policies can be as simple as a change to the client settings that tells the client how often to check for new policy or as complex as informing the client that during hardware inventory, it must query the Windows Registry for new keys to include in inventory.

The SMS provider, ConfigMgr console, and policy provider component work together to create policies and update the collection of clients to which to distribute the policies. Usually when clients check for new policies, there is no policy to download. However, in a busy environment, a client could receive 5 to 10 policies each time it checks, which could potentially cause communication congestion on the network.

Clients contact an MP to download new policy. In the ConfigMgr back-end engine, the MP contacts the SQL Server database and runs a query for that client. The MP also writes the time and date that the client checked for the policy. When the MP has the policy, the client downloads it and stores the policy in its Windows Management Instrumentation (WMI) namespace. You can view these activities in the client’s policy agent log file.

Content: Content is the source files for applications, software packages, operating systems, updates, and anything else that you want the client to execute. Content is first sent to a DP. Once a client gets a policy that involves content, it makes a content location request to the MP, which queries the database using Active Directory (AD) and IP information provided by the client. The MP determines where the content is located and returns that information to the client. The client then connects to the DP’s web page and uses Background Intelligent Transfer Service (BITS) to download the content it needs.

Content downloads to the client or DP comprise the most significant network use by ConfigMgr, and you will spend the bulk of your time collecting information about network bandwidth and the number of clients at a location and determining the best location to place the DP. This information can help you determine how many DPs are necessary and where to place them. If you plan your DPs correctly, content download should not cause network issues.

Inventory Information: This consists of hardware inventory, software inventory, discovery data, and metering data. These items are collected by components running under the SMS Agent Host service and sent to the MP.

Client Health Information: When the client is installed, a scheduled task is created to run the CCMEval.exe program, which reads the CCMEval.xml file and runs tests against the different health items in the eXtensible Markup Language (XML) file. For example, it verifies whether the SMS Agent Host service is running; if the service is not running, CCMEval.exe starts the service. The results of all these tests are compiled and forwarded to the MP to be added to the client health section of the ConfigMgr database.

Messages and Alerts: The client service and its components generate a series of state messages, status messages, and alerts. For example, when the client runs a deployment, a status message is created that tells ConfigMgr the program is running. Another message is created for a success or failure when that program finishes. These are again stored locally and sent to the MP for processing into the ConfigMgr database.

All client communication is web based, uses HTTP or HTTPS, and is encrypted for security.

Whether simple or complex, all ConfigMgr Current Branch sites have the following core components that communicate with each other: the site server, the SMS provider, and the site database. All site server roles communicate with one or more of these components. Most of these site servers fall into the following communication groups:

SQL Server communication

Remote Procedure Call (RPC) communication

Server Message Block (SMB) communication

The following sections discuss these communication methods.

The default instance uses the standard port 1433. ConfigMgr Current Branch does not support using dynamic ports. If you use a named instance, you must set SQL to use a static port. As 1433 is a well-known port for SQL, the authors suggest using a different port for security reasons. Ensure that you open the firewall for that port number. Once the port number is defined, SQL Server communicates using Transmission Control Protocol/Internet Protocol (TCP/IP). ConfigMgr Current Branch also supports using named pipes to connect to SQL Server; however, you should use this communication only to troubleshoot SQL Server connection issues.

The SMS provider is a tool used to communicate with the SQL database. This is a WMI provider that you can access through WMI or managed classes. The ConfigMgr console makes extensive use of the SMS provider to communicate with the SQL database. Most site roles include code to communicate directly with SQL Server and bypass the SMS provider.

Consider an example of a ConfigMgr site server that needs to install an MP on a remote server. The site server uses the RPC client to connect to the endpoint mapper on port 135 and identify the service to which it wants to connect. The endpoint mapper service replies with the port number for the client to use. The client disconnects and reconnects to the server using the assigned port number; then the communication starts, the MP files are copied, and installation begins.

The dynamic port range used changed beginning with Windows Server 2008; it is now between 49152 and 65535. For security reasons, you may want to use something besides the default range, and you may want to change that range value. This can be accomplished with the netsh command:

Click here to view code image

netsh int ipv4 set dynamicport tcp start=number num=range
netsh int ipv4 set dynamicport udp start=number num=range
netsh int ipv6 set dynamicport tcp start=number num=range
netsh int ipv6 set dynamicport udp start=number num=range

If you are unsure of the dynamic port range, you can use the following commands to view that port range:

Click here to view code image

netsh int ipv4 show dynamicport tcp
netsh int ipv4 show dynamicport udp
netsh int ipv6 show dynamicport tcp
netsh int ipv6 show dynamicport udp

To illustrate an example of SMB communication for ConfigMgr, consider when the package transfer manager needs to copy a package to a DP. One of the first steps is to determine the dialect with the highest level of functionality that both the client and the server can support. Once this dialect protocol is established, the site server can connect or log in as needed to the DP. The site server can then proceed to connect to the tree (share name) on the DP. Once connected successfully, the site server gets a tree ID (TID) it can use when connecting to that share name in the future. The site server now can open, read, and write files using that TID.

Because this process occurs across multiple computers in a networked environment, network performance can affect SMB and cause failures. If network bandwidth is highly utilized, the file copy can slow down or even fail. Network latency also causes SMB file copies and connections to fail or stop partway into the connection.

Software Update Point (SUP): The SUP component interfaces with WSUS. One of the SUP’s components configures the WSUS server, and another component tells WSUS when to synchronize with Microsoft Updates. Communication between the WSUS server and Microsoft Update occurs over the HTTP and HTTPS protocols. The information is logged in the WCM.log, Wsyncmgr.log, WSUSCtrl.log, and SoftwareDistribution.log files.

Service Connection Point (SCP): This new component provides several functions, including helping manage your on-premise and off-premise mobile devices, upload ConfigMgr usage data, and download updates to your ConfigMgr infrastructure. This communication occurs over the HTTPS protocol. The information is logged in the CMUpdate.log file.

Asset Intelligence Synchronization Point (AI): AI provides two-way communication to Microsoft regarding your AI information. This information is mainly a download of new updates to the AI catalog, stored in the ConfigMgr database. Uploads consist of custom software title information for categorization. This communication occurs over the HTTPS protocol. Information is logged in the Aiupdatesvc.log file.

Downloading Software Updates: The console is used to create the software update deployment package. Software updates are downloaded from Microsoft Update into the deployment package. The component PatchDownloader performs this task over the HTTPS protocol. This component logs its information in the PatchDownloader.log file.

HTTPS is used for all ConfigMgr external communication, which occurs over TCP port 443. The firewall should be opened to allow port 443 traffic. A proxy account or server may be needed, and each of these components includes areas to specify proxy information.

File-based replication

SQL Server–based replication

Intersite communication describes these two forms of replication and how they are used by sites to communicate with each other. It is important that both types of replication work correctly in a multisite hierarchy. Consider an example of a package created at the CAS. The metadata for that package is sent to the lower-tiered sites via SQL Server–based replication, and the actual content is sent using file-based replication. If either method is not working or is impacted by network issues, the package deployment will be unsuccessful.

Content: It doesn’t matter what type of content is involved; package, application, and software updates all use file-based replication to move from site to site or from site to DP.

Status Messages from a Client that are for the Fallback Status Point (FSP): These messages are sent to the client’s assigned site.

Data from a Secondary Site: Most secondary site data is sent to the parent site via SQL Server–based replication, but some data from components running on the secondary site server use file-based replication.

Data Discovery Records (DDRs): DDRs are sent to the discovery site via file-based replication the first time they are discovered, and after that, they are processed at their assigned site. If DDRs are sent to a different site than the assigned site, file-based replication is used to send them to the correct assigned site for that client.

File-based replication can occur in both directions: from the parent site to the child site and from the child site to the parent site. Two key threads of the SMSExec service perform these services:

Scheduler Thread: The scheduler works off a job file. This file is usually created by the thread wanting to do file-based replication. The scheduler reads the job file, which contains the destination site code, the path to the instruction file and the data file, and the job ID. The scheduler then creates a send request file for the sender to act on. The scheduler updates a log file called schedule.log that is located in the Logs folder.

Sender Thread: The sender works off the sender request file created by the scheduler. This file can be found in the inboxesschedule.boxoutboxesLAN folder and generally ends with a SRQ file extension. The file contains the destination site code, the job file ID, the path to the instruction file, and the path to the data file. The sender reads this file, makes a network connection to the destination site, and uses the SMB protocol to copy the instruction and data files. The sender logs its information in Logssender.log.

The sender has settings that control how it functions, located on the Sender tab of the site properties. Figure 5.1 shows these settings:

The sender uses a file replication route to understand how to connect to the destination site. Each route includes a source site and a destination site, the security account to use when making the connection, and the fully qualified domain name (FQDN) of the destination site server. The route has several configurable settings to help with a slow network or to limit bandwidth to certain hours. These are located in the ConfigMgr console under Administration -> Hierarchy Configuration -> File Replication, which lists all the file replication routes. You can then choose a route and look at its properties (see Figure 5.2).

The Schedule tab allows you to choose the hours of the day and night the sender can use to send data to the destination site. This is based on the priorities that have been set for the data. Three priorities can be set for the data:

High

Medium

Low

The Rate Limits tab allows you to set the percentage of available network capacity to use when sending data to the destination site. Figure 5.3 provides an example.

When implementing rate limits, there are three options to choose from:

Unlimited When Sending to This Destination: This option allows an unlimited data transfer rate.

Pulse Mode: Using Pulse mode allows you to limit the amount of data sent by specifying the size of the data blocks sent in kilobytes and the delay in seconds for how often the blocks should be sent. For example, say that you set up Pulse mode for 50KB and the delay is 5, meaning ConfigMgr will send 50KB across the network, wait 5 seconds, and then send another 50KB and wait 5 seconds, and so on. When you have a slow network between sites, this is an efficient way to avoid overutilizing the network.

Limited to Specified Maximum Transfer Rates by Hour: This setting is often misunderstood. It allows you to set a time period and a percentage amount to use during that time period. An example would be to set the time period from 8 AM to 10 AM and the percentage amount to 50%. This means that during the hours of 8 AM to 10 AM, ConfigMgr would use 100% of the bandwidth 50% of the time and 0% of the bandwidth the other 50% of the time. This is accomplished by dividing out the time into time periods. You can configure this setting for every hour of the day.

Utilizing this setting is useful if you have a network on the edge of being overutilized during the day, and you need to make sure ConfigMgr doesn’t consume all your bandwidth when sending data. Because this setting can be set for only daytime hours, at night ConfigMgr could send 100% of the data 100% of the time.

Global Data: This is data intended to be shared with all ConfigMgr sites and includes any data generated by the ConfigMgr console. Global data is present and replicated at the CAS and all primary sites. Secondary sites also contain a small subset of global data, such as MP and DP lookup information. Following are examples of global data:

Collection rules and counts

Package, program, and application metadata

All deployments

Configuration items metadata

Software update metadata

Task sequence metadata

Site control file information (now stored in the ConfigMgr database)

System resource lists

Site security objects

Alert rules

Global data can be created at the CAS or a primary site. If created at a primary site, it is replicated to the CAS, which replicates it to all primary sites. Primary sites replicate needed information to the secondary sites.

Site Data: This is data generated by clients and the local site systems. Site data is replicated up the hierarchy and not across the hierarchy. This means a client’s hardware inventory is sent to the local site and then replicated up to the CAS but not replicated to any other primary site. Following are examples of site data:

Collection membership results

Alert messages

Hardware and software inventory

Software metering data

Asset intelligence client access license track data

Status messages

Software distribution status details

Status summary data

Component and site status summarizers

Client health data and history

Wake on LAN

Software updates site data

Data is replicated through the hierarchy (or, in the case of site data, up the hierarchy) every one to seven minutes to ensure that anyone looking at the CAS has the most accurate view of what is occurring in the hierarchy. The CAS and all primary sites contain the same global data. This helps with disaster recovery when a site crashes; because the same data is at the CAS, it can be recovered faster, leading to less downtime for the hierarchy.

Database replication has several components that work together inside and outside SQL to move the data from the database of a site server to the database of other site servers. The following components replicate the data:

Data Replication Service (DRS): DRS is the name given to the overall process and service ConfigMgr uses to replicate data through SQL Server to other sites. DRS was written partly in SQL and partly in ConfigMgr. This is not to be confused with SQL replication, which is a feature of SQL Server. ConfigMgr uses DRS instead of SQL replication.

SQL Server Service Broker (SSB): SSB is a feature of SQL Server that was first introduced with SQL Server 2005. It is an integrated part of the database engine and provides queuing and reliable direct asynchronous messages between itself and other service brokers. This is accomplished by exchanging messages in a dialog conversation between the two service brokers. SSB is used to send the data from one database to another.

Replication Configuration Monitor (RCM): RCM is a thread of the SMSExec service. This thread is responsible for interacting with the SQL side of DRS. RCM monitors and configures different items of DRS. RCM writes to the rcmctrl.log file in the Logs folder. This log file should be the first place you look when DRS is not working properly.

Replication Group: Replication includes global and site data. That data is broken down further into replication groups. A replication group is a group of database tables that are similar in nature. An example of a replication group is the Alerts group, which contains information from all the alert tables.

Replication Pattern: Once you have a replication group, the data is further segregated using replication patterns. Three patterns are used:

Global: This pattern is any data that is created by the administrator using the ConfigMgr console or PowerShell scripts that need to be replicated between the CAS and primary sites.

Global_Proxy: This subset of the global pattern contains data that is shared across the primary sites and their respective secondary sites.

Site: This pattern is the same as the site data previously mentioned in this section. This is data shared between the primary site and the CAS and is created primarily by the clients.

Article Names: Replication groups are further divided into article names based on a replicationID assigned to the replication group. It is the grouping of the replicationID that creates the article name.

DRS has two modes:

Site Initialization Mode: It is important to understand how a site is initialized, as that can affect your network traffic. Consider an example with a CAS and two primary sites. Say that you are adding a third primary site to your hierarchy. When the site installation is complete, the site will begin to initialize.

The new primary site creates a message sent through DRS to the CAS, telling the CAS that the primary site is new and has no SQL data. The rcmctrl component on the CAS uses the Bulk Copy Program (BCP) to extract the data from the database and store it in encrypted files. The data is extracted according to the replication groups previously discussed in this section. Once extracted, the rcmctrl component compresses all the files into a single file. File-based replication then starts, and the file is transferred to the new primary site, where the rcmctrl component uncompresses the files and uses BCP to copy the data into the primary site’s database.

This process continues until the primary site has all the data from the CAS. For a medium to large environment, this involves transferring gigabytes of data using file-based replication, which can create some network traffic issues even in the best of bandwidth situations. Be aware of the potential impact to network traffic and bandwidth when bringing a new primary site into the hierarchy.

Site Active mode: Once a site is initialized, the global data is ready to be used and shared. The site goes into active mode, where DRS is the source of data replication. An example of this would be a user at the CAS creating a new package using the ConfigMgr console. The SMS provider would write that package’s metadata into several tables at the CAS, one being the SMSPackages table. SQL change tracking notes that the SMSPackages table has changed; this changed data is gathered up, and DRS is used to replicate it to all primary sites in the hierarchy.

TABLE 5.2 Default Ports and Protocols for Client Communication

Client Service	Port Number	Protocol Used
Client request	80	HTTP
Client request	443	HTTPS
Client notification	10123	TCP
Wake on LAN	9	UDP

An organization may want to change the port numbers so that they are different from those listed in Table 5.2 for security reasons; this could be related to network firewall policies or perhaps a custom IIS website. The client spends the majority of time communicating with the MP and the DP; because these are websites, they may not be installed on the IIS default website and may require access using a custom port number. ConfigMgr Current Branch allows you to change the port numbers used for HTTP and HTTPS communication. Figure 5.4 shows the Ports tab for the site properties, where you can add a custom port.

If using a custom port, ensure that the client knows the port number and uses that port when communicating. You accomplish this by using a command-line option when installing or reinstalling the client. The full set of command-line options for client installation is at https://technet.microsoft.com/library/mt489016.aspx. The following is a sample command to install the client to use the custom port 8080:

Click here to view code image

CCMSetup.exe /mp:armada.odyssey.com SMSSITECODE=PR1 CCMHTTPPORT=8080

The command-line option CCMHTTPPORT=8080 tells the client that when communicating using HTTP, it should use port 8080.

If the client is already installed, and you need to change the port number used for communication, you have three options:

Reinstall the client using a command line specifying the correct port number to use.

Run a dual configuration for a period of time. However, you must have both the default and custom ports enabled at the same time. The client obtains the new port number from Active Directory Domain Services (ADDS); you can disable the old port number when all the clients have the new port number.

Use the portswitch.vbs script. This sample script is provided in the tools folder of the ConfigMgr installation media and is designed to be run with software distribution. You can use a deployment to have the clients run the script, which sets the new port number. If you use this script, both the current port number and the new port number must be enabled, as the client downloads the policy and continues to run this deployment with the old port.

Every 25 hours of continuous operation

When the client detects a change to its network configuration or location

When the ccmexec.exe service starts or is restarted

When the client must locate a site system role providing a required service

The client uses the following three options to complete the service request:

ADDS: The client uses ADDS as its primary method of service location. This requires the AD schema to be extended, ConfigMgr Current Branch to publish its site information in ADDS, the AD forest to be enabled for publishing inside ConfigMgr, and the computer to be a member of the domain.

DNS: If you cannot publish the ConfigMgr information into ADDS, you can publish the MPs’ information into DNS. The client will query DNS to find any published MPs.

WINS: When all else fails, ConfigMgr falls back to using Windows Internet Name Service (WINS) to find an MP.

When a client successfully locates and contacts an MP from one of these resources, it downloads a current list of available MPs and updates its local MP list. This list is sorted by client, based on network location, and the list is stored locally in WMI. The MP list is sorted by the following classifications:

Proxy: This is an MP at a secondary site.

Local: This is any MP associated with the client’s current network location, defined by the site boundaries. If the client falls into multiple boundary groups, the local MP list is a union of all MPs within the boundary groups.

Assigned: This is any MP that is a site system for the client’s assigned site.

The client uses an MP based on this MP list; if multiple MPs are within the same classification, it chooses the most secure MP available. If all the MPs in the list use the same security method, the client randomly chooses an MP to use.

BITS transfers files on behalf of applications requesting its service. A transfer occurs in the background as long as there is a network connection. If the network connection is lost, the transfer is suspended; when the network connection becomes available, the transfer restarts where it was suspended.

BITS constantly monitors network traffic so it uses only idle bandwidth. This makes BITS a perfect choice for networks with slow connection links or high bandwidth utilization.

BITS works by having the application that needs a transfer create a job that is placed into the BITS queue. BITS reads the queue and starts to schedule the job for transfer to the destination URL.

BITS used round-robin scheduling to process jobs in the same priority and prevent large transfer jobs from holding up smaller jobs.

BITS has a built-in error-handling mechanism. Errors are either fatal or transient. If an error is fatal, BITS transfers control of the job to the application that created it. Transient errors are temporary errors that usually resolve themselves over time. BITS works with transient errors by retrying the transfer at the point where the error happened.

BITS transfers occur over SMB, HTTP, and HTTPS.

Configuration Manager makes extensive use of BITS to efficiently use network bandwidth and deal with network connections that are unreliable or not always available. BITS 2.5 or higher is a required ConfigMgr Current Branch component. BITS supports downloads over both HTTP and HTTPS.

BITS 2.5: Included on all systems running Windows Server 2008, Windows Vista, and Windows XP Service Pack (SP) 3, version 2.5 can also be installed on machines running Windows Server 2003 SP 1 or SP 2 or Windows XP SP 2 64 bit. The QMgr.dll version is 6.7.xxxx.xxxx.

BITS 3.0: This version is available on Windows Server 2008 and Windows Vista operating systems only. The QMgr.dll version is 7.0.xxxx.xxxx.

BITS 4.0: Available natively in Windows 7 and Windows Server 2008 R2, this version can be downloaded and installed on Windows Vista SP 1 or SP 2 and Windows Server 2008 SP 2. The QMgr.dll version is 7.5.xxxx.xxxx.

BITS 5.0: This version is included in Windows Server 2012, 2012 R2, Windows 8, and Windows 8.1. The version of QMgr.dll is 7.7.xxxx.xxxx. Windows 10 also includes BITS 5.0 but with some new features that allow the use of PowerShell cmdlets. The QMgr.dll version in Windows 10 is 7.8.xxxx.xxxx.

More information about the new features added with each version of BITS is available at https://msdn.microsoft.com/library/aa363167.aspx.

A problem with earlier versions of BITS is that the system is only aware of the traffic passing through the network interface card (NIC). Even when the network segment to which the machine is connected is congested, if there is little or no network activity on the local machine, it appears to BITS that most of the bandwidth supported by the card is available. Under these conditions, BITS transmits data at a high rate, potentially causing additional network congestion problems. BITS 2.5 and higher versions get around this limitation by pulling usage statistics from the Internet gateway device (IGD). Certain conditions must be met to pull statistics from the IGD:

Universal Plug and Play (UPnP) must be enabled.

The device must support UPnP byte counters.

UPnP traffic (TCP 2869 and UDP 1900) is not blocked by any firewall device or software.

The device must respond to GetTotalBytesSent and GetTotalBytesReceived in a timely fashion.

The file transfer must traverse the gateway.

BITS does an excellent job of intelligently managing the use of network bandwidth with its default settings. To tweak those settings to have BITS use only a certain amount of bandwidth or reserve extra bandwidth for other mission-critical applications, you can use one of the following methods to fine-tune BITS:

Active Directory Group Policy

ConfigMgr Client Settings for BITS

The next sections discuss these methods.

Some of the settings are self-explanatory; for more information, see https://msdn.microsoft.com/library/aa362844(v=VS.85).aspx.

Start and stop times for throttling

Maximum transfer rates during and outside the throttle times

The ability to allow BITS downloads outside the throttle window

You can find these settings in the client agent settings, located under Administration -> Client Settings -> Default Client Settings. Figure 5.6 shows the available settings.

Once these settings are changed, a policy is created for the collection to which the settings are deployed; if the default collection, the policy is created for all machines. Clients download these settings as a policy when they check again for policy at the MP. Once the client downloads the policy, it is applied to that machine.

Distributed Cache Mode: The content cache at a branch office is distributed among client computers.

Hosted Cache Mode: The content cache at a branch office is hosted on one or more server computers, which are called hosted cache servers.

BranchCache is a function of the operating system and ConfigMgr; however, ConfigMgr only works with BranchCache in distributed mode, taking advantage of HTTP and BITS as the protocol. The first client to pull the requested content does so across the WAN link from a DP. When other clients request the same content, they first attempt to locate the content in the BranchCache of a peer computer on the same subnet. If the content is available on the peer, it is pulled from there; otherwise, the clients go across the WAN to the DP for content. Using BranchCache in this fashion allows two important advantages for users located at sites across a WAN link:

Reduced Client Latency: Downloading content from the local subnet greatly reduces the time needed for retrieval. BranchCache also downloads content in 64KB blocks and makes each block available after it is downloaded and verified rather than waiting for the entire download to complete.

Improved WAN Utilization: WAN traffic is reduced because content may be downloaded to the local site once and used by many clients. In addition, BranchCache utilizes BITS 4.0, providing network-friendly optimizations such as bandwidth throttling and resumption of interrupted transfers.

BranchCache is easy to set up to use with ConfigMgr, with two items to configure:

Server Side: Because BranchCache is a feature of the operating system, it is installed from Server Manager on the DP used at the main location. ConfigMgr makes this easy by including a check box on the General tab of the properties of the DP. You can check this box to have ConfigMgr install BranchCache for you. Figure 5.7 shows the check box to install BranchCache. This is all that is required to install BranchCache on the server side.

Client side: Configuring the client side is somewhat more difficult. The client machines must have a group policy enabled to turn on BranchCache for them. Find the group policy at Computer Configuration -> Policies -> Administrative Templates -> Network -> BranchCache. Figure 5.8 shows the group policy settings for BranchCache.

At a minimum, you need to enable these two settings in group policy:

Turn on BranchCache

Set BranchCache Distributed Cache Mode

The authors also recommend you set the following two options:

Configure BranchCache for Network Files: This setting specifies the minimum latency for caching to occur. The client uses the BranchCache feature when it does not receive content from a remote source within the specified interval. The default value is 80ms. Setting a higher value causes more WAN downloads to occur but uses less disk space, I/O, and network throughput on the client systems acting as cache repositories.

Set Percentage of Disk Space Used for Client Computer Cache: The default setting allows up to 5% of the client disk space for caching. The cache is located under %systemroot%ServiceProfilesNetworkServiceAppDataLocalPeerDistRepub.

You must also configure Windows Firewall or third-party firewall software to allow BranchCache transfers and the Web Services Dynamic Discovery (WS-Discovery) protocol to discover cached content.

The last step in getting BranchCache to work with ConfigMgr is to configure your packages or applications to enable BranchCache. For applications, check the Allow Clients to Share Content with Other Clients on the Same Subnet box on the Content tab for the application properties. For packages, the same check box appears on the Distribution Point tab for the deployment properties.

When a BranchCache-enabled client attempts to access content from a server that is not on the local subnet, the client first determines the latency of the connection. If the latency exceeds the configured threshold, the client attempts to discover the content on the local subnet. The first BranchCache-enabled client on the subnet to access the content learns that it is not available locally and retrieves it from the remote DP. The client then caches the content and makes it available to other clients on the same subnet. When other clients later try to access the content, local clients respond that it is available in cache, and the content is sourced locally.

For more in-depth information on BranchCache, see http://technet.microsoft.com/network/dd425028.aspx.

The network access account (NAA) has full rights to the client cache folder: This is a big requirement because in the past, the NAA has always been a domain user with basic permissions on client systems. The NAA must have Full Control permission to the %windir%ccmcache folder. The NAA is used to access the cache folder and allow clients to download the content. Starting with the version of Peer Cache used with ConfigMgr Current Branch version 1706, the NAA is no longer used unless the client is running a task sequence that reboots the machine into Windows Preinstallation Environment (WinPE); in this case, the NAA is still needed to access content from a peer.

Peer Cache is only used by clients in the same boundary group: A client can only download content from the peer cache of a machine in the same boundary. When clients request machines that have content for it, peer cache clients with content in the same boundary are returned to the client.

Hardware inventory must be up to date: The current boundary of a peer cache content source is determined by the last hardware inventory the client has sent to the database. If a peer cache content source roams to a different boundary but does not submit an updated hardware inventory, a client could download content across a slow network. You should consider whether the machine is prone to roaming or is stationary when choosing what machines will become content peers.

The type of content does not matter: Any type of content that is in the cache of a peer source can be given out to clients requesting the content. Software updates, packages, applications, and any other content types are all available for download.

The requesting client does not have to have Peer Cache enabled: Clients without Peer Cache enabled can download content from a Peer Cache–enabled source. This means you can designate several peer cache source content clients in each boundary from which clients can download content.

Whether the machine is a desktop or stationary machine: The best machine to act as a peer cache source is one that does not move or change boundaries. The last hardware inventory reported by the machine is used to determine the boundary for which it can serve as a peer cache source. If the machine roams to different boundaries, content might be delivered across a slow network link. You can find out what machines are desktop units by querying their chassis type in the v_GS_System_Enclosure database view. You end up with a number that corresponds to a chassis type (see https://msdn.microsoft.com/library/aa394474(v=vs.85).aspx). The value for a desktop is 3.

Free disk space: Choose machines with a lot of free disk space, which enables you to have designated machines in boundaries that might have all or a great amount of your content stored in the content cache. The more content you store, the greater the disk space needed. On these machines, increase the client cache amount from the default size so the content is stored longer and is not removed when you need more space in the cache. You can collect this information in hardware inventory, but it is not turned on by default. Enable the Free Space (MB) item in the Logical Disk (SMS_LogicalDisk) class so that it can be returned in hardware inventory. This allows you to query the v_GS_Logical_Disk database view for that information.

Active clients: When searching for a machine, check that it is an active client. You may find the perfect machine to be a peer content source but then learn that it is only turned on once a week. When checking the machine, verify that it is an active client that stays powered on all the time.

When you have found the machines you want to use as peer cache content sources, create a collection and add them to the collection. This allows you to group the machines together. Now you are ready to configure the Peer Cache settings. Because you only want the machines in the collection to receive the Peer Cache policies, you need to create a new custom client device setting. Therefore, navigate to Administration -> Overview -> Site Configuration -> Client Settings and choose Create Custom Client Device Settings either from the ribbon bar or after right-clicking Client Settings. You then see a dialog box that allows you to name the custom device settings and choose the client settings you want to apply to this custom setting. Choose Client Cache Settings, and a new section is added to the dialog box, where you can configure the settings, as shown in Figure 5.9.

Use the last four settings on this page to configure the peer client cache settings:

Enable Configuration Manager Client in Full OS to Share Content: This dropdown box allows you to choose Yes or No. Choosing Yes enables this setting and also shows a popup dialog box on the screen. This popup explains that it will automatically configure Windows Firewall on clients to open the ports that you choose to use but that any third-party firewall must have the ports opened manually.

Port for Initial Network Broadcast: This option allows you to choose the port to use for the broadcast. When clients are trying to find a peer cache content source machine, they will broadcast on this port and wait for any machines to answer. Port 8004 is used by default. This port must be opened on any third-party firewalls and routers for communication to work correctly.

Enable HTTPS for Client Peer Communication: This dropdown box allows you to choose Yes or No. If you choose Yes, all peer communication occurs across HTTPS.

Port for Content Download from Peer (HTTP/HTTPS): You specify the port number the client will use to download content from the peer cache content source machine. This port is used for HTTP and HTTPS communication, and it must be open on any firewalls or routers.

After configuring these settings, deploy the custom client settings to the collection you created for your peer cache content source machines.

When these machines get the policy to be peer content sources, a hidden IIS web page is installed on each one, and the ports are opened in Windows Firewall to allow incoming connections. This is visible inside the CAS.log file on the peer content source machines. You can also see references to a new service thread for the client, known as the Super Peer service, as well as the website that peer clients will use to connect, called SCCM_BranchCache$. (That is just the name Microsoft used; it has nothing to do with BranchCache itself.) When monitoring the CAS log, you also see references to impersonating the NAA access account credentials. This is how the Super Peer service thread gets access to the Cache folder on the peer source.

When the peer sources have the content in their cache folders, create your deployment to other systems. When the clients receive the deployment and begin downloading content, a request is made to the MP, asking for DPs in this boundary with the content. The MP queries the database and returns a list of DPs and peer content sources. The client tries to use the peer content sources first and falls back to a DP if it cannot get the content from a peer source. When the download starts, you can monitor the Content Transfer Manager log (ContentTransferManager.log) for an overview of the download. To see detailed information about the download, follow the Data Transfer Service log file (DataTransferService.log). This log file shows information about the machine being connected to for the download, the files being downloaded, the job number used to download the files, errors that might occur during the download, and a success message with the start time, ending time, and amount of time for the download.

On the peer content source side, you can monitor the CAS log file to see the connections and the downloads that are occurring. If you see issues with a download, be sure to view both sides of the download: the client and the peer content source. You typically should not notice a difference between using a peer content source or a DP.

After the download completes and the applications, packages, or software updates have been installed, the download information is aggregated and sent back to the MP for inclusion into the database once every 24 hours. The data that is sent back is used to populate the new Client Data Sources dashboard, shown in Figure 5.10.

The dashboard has several tiles that display information that tells users what content has been downloaded using DPs, Peer Cache, BranchCache, and cloud DPs. You can also hover over the graphic tiles for a breakdown by size of the downloads of each of the content servers. Remember that this data is sent back from the clients only every 24 hours, which means it may take a day or so for the dashboard to be updated with new data.

Site Assignment: When you choose to use automatic site assignment, the client determines if its current network location (AD site and/or IP subnet/address) falls within a defined boundary. If it does, the client is assigned to the site defined within the boundary group of which the boundary is a member. This is an automatic site assignment process.

Site Systems: A boundary group contains a list of site systems to be used by clients falling within the boundaries of the group. These could be MPs, DPs, or even SMPs. When a site system is added to the boundary group, it can only be used by the clients that fall within the boundaries assigned to the boundary group; this is known as a protected site system.

A boundary is defined by using one of the following methods:

Active Directory site

IP subnet

IP address range

IPv6 prefix

In small to medium-sized networks, you should be able to use only the AD site method or perhaps a combination of AD sites and IP subnets. In larger networks, network administrators may be using classless interdomain routing (CIDR) and/or supernetting to define IP subnets (see https://technet.microsoft.com/library/cc958837.aspx for additional information). Note that ConfigMgr does not support these methods. The boundary methods expect AD sites and IP subnets to use a specific subnet mask, based on legacy class assignments. When using CIDR and/or supernetting, you may find that you are using a third boundary type, IP address ranges. Ranges allow you to define a group of IP addresses without being concerned about the type of subnetting that is in place.

If your hierarchy includes workgroup machines or clients residing in a different forest where there is no trust relationship, you must use a boundary method other than AD sites because workgroup machines cannot query AD to retrieve site information.

If a site includes multiple MPs, the client gets a list of all the MPs and randomly chooses one to communicate with to retrieve policies. This could lead to clients across a slow network link communicating with an MP on the other side of the slow link instead of communicating with a local MP. Adding the local MP to the boundary group of the clients across that slow link lets them get a list of preferred MPs; the client then communicates with the preferred MP in its boundary group first, falling back to the MP list only if it cannot communicate with the preferred MP. This can help prevent network congestion on the slow link. The same boundary groups can also contain DPs, providing the client with a location or locations for downloading content.

Starting with version 1610, ConfigMgr Current Branch changed how boundary groups work. Previous versions used the concept of fast and slow network links. When adding a site system to a boundary group, you could assign that system as a fast or slow link. You could also assign a DP as a fallback DP, meaning that if the client could not find the content on a DP or was not in the boundaries of a DP, it could use the fallback DP to look for content. This sometimes meant a client might go across a slow network link to pull content from the fallback DP, but at least it could get the content.

In ConfigMgr Current Branch version 1610, Microsoft removed the ability to use fast and slow links when adding site systems to a boundary group. ConfigMgr now automatically adds a default boundary group named Default-Site-Boundary-Group<site code>, which is used when a site upgrades to version 1610. To ensure that the current fallback behavior from the previous version remains available until the new boundary groups and relationships are configured, DPs that are enabled for fallback are added to this new default boundary group.

Adding site systems to a boundary group is the same as with previous versions; you just no longer have a fast or slow link to configure. There is a new tab in the properties of a boundary group called Relationships (see Figure 5.11).

You can use this tab to define the relationship between this boundary group and another boundary group, and you can allow the client to fall back if it cannot find content in its own boundary group. This relationship, called neighbor boundary groups, enables you to create a one-way link between the current boundary group and neighbor boundary groups you add. The client searches for content in its own boundary group and falls back to neighbor boundary groups if the content is not found. You can assign a time value to each neighbor, telling the client how long to wait before falling back to that neighbor to search for content; you can also define a priority list for the neighbors the client will search.

For detailed information on these changes to boundary groups, see https://docs.microsoft.com/sccm/core/servers/deploy/configure/define-site-boundaries-and-boundary-groups#a-namebkmkboundarygroupsa-boundary-groups.

Signed Client Data: To protect data sent from clients, you can require a client to sign the data before sending it. To enhance the security even further, you can require the data to be signed using the SHA-256 algorithm.

Encryption: While signing the data helps protect it from tampering, encryption protects the data from information disclosure, which means it is not vulnerable to network sniffing devices. 3DES is the encryption technology used when encryption is enabled. It protects inventory data and state messages.

PKI Certificates and HTTPS: When using HTTPS, the client must present a valid authentication certificate issued by the trusted root certificate authority to both the IIS server and the client. When using HTTPS for all client communications, you do not need to use the signing or encryption methods.

When ConfigMgr clients request policy, they first get a policy assignment so they know which policies apply to them, and then they request only those policy bodies. Each policy assignment contains the calculated hash for the corresponding policy body. The client retrieves the applicable policy bodies and then calculates the hash on each body. If the hash on a downloaded policy body does not match the hash in the policy assignment, the client discards the policy body.

In-depth information about cryptographic controls for ConfigMgr can be found at https://technet.microsoft.com/library/mt629331.aspx.

Basic connectivity to network services

DNS resolution

Routers and firewall ports

Congested or slow network links

MPs and DPs

Service Principal Names

The following sections briefly describe some of these issues and tools for troubleshooting these items.

To troubleshoot basic network connectivity, open a CMD window (by selecting Start -> Run and then typing cmd) and run the following commands (which work much better when you have administrator rights on the workstation):

ipconfig /all—This command provides a considerable amount of information about the TCP/IP configuration on your workstation.

Check whether you have a valid IP address from your DHCP server or, if you’re using a static IP address, whether it is correct. An IP address beginning with 169 is an auto-configuration address assigned when the machine cannot communicate with the DHCP server. This would be the first issue to resolve.

Next, check the DNS server address, which needs to be configured to point to the correct DNS server for name resolution.

Another item is the default gateway. This device allows the packets to leave your local network and travel to its destination. If it is not set correctly, your network traffic will not go past local resources.

Figure 5.12 shows the results of running ipconfig /all.

ping—If you determine that the machine has an IP address and the other items check out, you can next test TCP/IP connectivity by performing a ping test. When you use the ping command, your machine sends a ping packet to another IP address and waits for a result. If the other machine answers, you see reply messages; if it doesn’t, you see a request timed out message. You can also perform a ping test on your local machine to verify its connectivity: Use the machine’s IP address, which you obtain from the ipconfig command, or the industry standard 127.0.0.1 address, known as a loopback address. If you suspect that the local machine’s IP stack is not working correctly, you should ping the loopback address. Following are the commands for those tests:

Click here to view code image

ping 127.0.0.1
ping <Remote IP Address that you want to connect to>

Both of these commands should return something similar to the following:

Click here to view code image

Pinging 127.0.0.1 with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Ping statistics for 127.0.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 0ms, Average = 0ms

Figure 5.13 shows that the ping started with the FQDN, Athena.odyssey.com, which resolved to the IP address 95.211.219.66. The information returned then looks just like the ping in the previous section. Name resolution turns a name into an IP address, and the machine knows how to connect to that IP address. If name resolution is not working, you see results similar to the following:

Click here to view code image

ping athena.odyssey.com
Ping request could not find host athena.odyssey.com. Please check the name and try again.

Results such as these indicate a problem with DNS, which you can troubleshoot by using the NSlookup command, described at http://support.microsoft.com/kb/200525. To troubleshoot NetBIOS name resolution using Nbtstat and other methods, see http://support.microsoft.com/kb/323388. It is also useful to ping the known IP address of the target machine; if that works, the issue is narrowed to some type of name resolution–related issue.

An additional DNS problem that may arise is an incorrect referral. Incorrect referrals occur when a hostname is used instead of a FQDN and the wrong domain name is appended due to the DNS suffix search order. Incorrect referrals typically result in access denied errors. If you see unexpected access denied errors, ping the site system using both the hostname and FQDN to verify that they resolve to the same address.

Figure 5.14 shows that the name is resolved and then traces a route to it. There are nine hops, meaning the packet goes over nine routers to get to the address. Hops 5 and 8 show request timed out messages, but hops 6 and 9 look good. It might be that the router could not provide information at the hops where the messages occurred. If you see continuous request timed out messages, it means the packet got lost at that last hop.

If tracert shows that the packet makes it to the final destination, but ping still fails, you may have a port or firewall issue. The firewall could be set so that the machine doesn’t respond to incoming pings, which would cause your pings to fail. Ports blocked by firewalls and routers are common sources of connectivity problems. In other cases, a port may simply not be listening on the system to which you are trying to connect. You can attempt to connect to the specific port on the target system with the telnet command. For example, to verify that you can connect to the Trivial File Transfer Protocol (TFTP) daemon service (port 69) on PXE-enabled DP Charon.Odyssey.com, open a command prompt (by selecting Start -> Run and then typing cmd) and enter the following:

Click here to view code image

telnet Charon.Odyssey.com 69

If telnet is successful, it will open the telnet screen with a cursor. If the connection fails, you will receive an error message.

When a connection to a port fails, first verify that the service is listening on the appropriate port. On the machine that should receive the connections, enter the command netstat –a to list all connections and listening ports and then check the following:

If the port is not shown, verify that all system requirements and prerequisites are met.

If the port displays as enabled, check all network firewall logs for dropped packets.

Refer to your network team or vendor firewall documentation for procedures to check firewall logs. Also, check the Windows Firewall logs and settings (see http://technet.microsoft.com/network/bb545423.aspx) and any third-party security software that performs intrusion detection and prevention.

Additional tools are available to troubleshoot port status issues. Consider these examples:

The PortQry command-line utility, downloadable from http://www.microsoft.com/downloads/details.aspx?familyid=89811747-C74B-4638-A2D5-AC828BDC6983&displaylang=en.

PortQryUI, which you can download from http://www.microsoft.com/downloads/details.aspx?FamilyID=8355E537-1EA6-4569-AABB-F248F4BD91D0&displaylang=en. PortQryUI provides equivalent functionality to PortQry through a graphical user interface (GUI).

You can go to http://www.microsoft.com/downloads and search for PortQry to bring up links for these tools.

Click here to view code image

Reply from 172.31.50.53: bytes=32 time=50ms TTL=128

time=50ms means it took 50 milliseconds to get the reply from the destination site. The higher the number, the slower the network. A high value may also be returned if a network is congested. Sometimes the ping times out because the network is slow. In these cases, you can change the ping command line to insert a time to wait before timing out, like this:

Click here to view code image

Ping –w 3000 <IP address of target system>

In this example, 3000 is the number of milliseconds for the ping command to wait for a reply before timing out.

Click here to view code image

http://<FQDN of the MP>sms_mp/.sms_aut?mplist
http://<FQDN of the MP>/sms_mp/.sms_aut?mpcert

mplist returns a list of the MPs in the same site, and mpcert returns a string of characters corresponding to the MP certificate.

If you are using HTTPS for the MPs, enter the following:

Click here to view code image

https://<FQDN of the MP>sms_mp/.sms_aut?mplist
https://<FQDN of the MP>/sms_mp/.sms_aut?mpcert

You may run into issues where the client is not downloading the complete package or perhaps cannot find the package on the DP. In such a case, you can test the DP to verify package contents or see if the package is on the DP. Run the following command in your browser window (if using HTTPS, change HTTP to HTTPS):

Click here to view code image

http://<FQDN of the DP>/SMS_DP_SMSPKG$/<Package ID you want to test>

After entering this command, you are prompted to enter your user ID and password to verify that you have permissions to the content store where the package is located. Once access is granted, a list of package files is returned. Figure 5.15 shows an example of this, using the built-in ConfigMgr client package.

If running the SQL Server service using a domain account on the site database server or other roles requiring SQL Server, follow the instructions at http://technet.microsoft.com/library/bb735885.aspx to register the SPN. If the SQL Server service is configured to run under the local system account, the SPN does not need to be manually registered. However, running SQL Server as local system is not recommended for security reasons.

For site systems that require IIS, if the system is registered in DNS using a CNAME (a DNS alias rather than the actual computer name), you must register the SPN by using the procedure described at http://technet.microsoft.com/library/bb694288.aspx.

Chapter 6, “Installing and Updating System Center Configuration Manager,” covers installing and updating ConfigMgr.