Planning for Communications in Configuration Manager

Configuration Manager uses file-based replication to transfer file-based data between sites in your hierarchy. This data includes content such as applications and packages that you want to deploy to distribution points in child sites, and unprocessed discovery data records that are transferred to parent sites where they are processed.

File-based communication between sites uses the Server Message Block (SMB) protocol by using TCP/IP port 445. You can specify configurations that include bandwidth throttling and pulse mode to control the amount of data transferred across the network, and schedules to control when to send data across the network.

Beginning with Configuration Manager SP1, addresses are renamed to file replication routes to bring consistency with database replication. Prior to SP1, Configuration Manager uses an address to connect to the SMS_SITE share on the destination site server to transfer file-based data. File replication routes and addresses operate the same way, and support the same configurations.

The following sections are written for changes introduced with service pack 1 and reference file replication routes instead of addresses. If you use Configuration Manager without a service pack, use the information in the following table to convert the references to file replication routes back to the related reference for addresses.

Configuration Manager database replication uses SQL Server to transfer data and merge changes that are made in a site database with the information stored in the database at other sites in the hierarchy. This enables all sites to share the same information. Database replication is automatically configured by all Configuration Manager sites. When you install a site in a hierarchy, database replication automatically configures between the new site and its designated parent site. When the site installation finishes, database replication automatically starts.

When you install a new site in a hierarchy, Configuration Manager creates a generic database at the new site. Next, the parent site creates a snapshot of the relevant data in its database and transfers that snapshot to the new site by file-based replication. The new site then uses a SQL Server bulk copy program (BCP) to load the information into its local copy of the Configuration Manager database. After the snapshot loads, each site conducts database replication with the other site.

To replicate data between sites, Configuration Manager uses its own database replication service. The database replication service uses SQL Server change tracking to monitor the local site database for changes, and then replicates those changes to other sites by using a SQL Server Service Broker. By default, this process uses the TCP/IP port 4022.

Configuration Manager groups data that replicates by database replication into different replication groups. Each replication group has a separate, fixed replication schedule that determines how frequently changes to the data in the group is replicated to other sites. For example, a configuration change to a role-based administration configuration replicates quickly to other sites to ensure that these changes are enforced as soon as possible. Meanwhile a lower priority configuration change, such as a request to install a new secondary site, replicates with less urgency and takes several minutes for the new site request to reach the destination primary site.

Configuration Manager classifies the data that it replicates by database replication as either global data or site data. When database replication occurs, changes to global data and site data are transferred across the database replication link. Global data can replicate to both a parent or child site, and site replicates only to a parent site. A third data type that is named local data, does not replicate to other sites. Local data includes information that is not required by other sites:

• Global Data: Global data refers to administrator-created objects that replicate to all sites throughout the hierarchy, although secondary sites receive only a subset of global data, as global proxy data. Examples of global data include software deployments, software updates, collection definitions, and role-based administration security scopes. Administrators can create global data at central administration sites and primary sites.

• Site Data: Site data refers to operational information that Configuration Manager primary sites and the clients that report to primary sites create. Site data replicates to the central administration site but not to other primary sites. Examples of site data include hardware inventory data, status messages, alerts, and the results from query-based collections. Site data is only viewable at the central administration site and the primary site where the data originates. Site data can be modified only at the primary site where it was created.

  All site data replicates to the central administration site; therefore the central administration site can perform administration and reporting for the whole hierarchy.

Use the information in the following sections to plan for using the controls that are available beginning with Configuration Manager SP1 to configure database replication links between sites, and to configure controls on each site database. These controls can help you control and monitor the network traffic that database replication creates.

Clients initiate communication to site system roles, Active Directory Domain Services, and on-line services. To enable these communications, firewalls must allow the network traffic between clients and the end point of their communications. Endpoints include:

• Management points from which clients download client policy.

• Distribution points from which clients download content.

• Software update points

• The following additional site system roles, each for feature specific tasks:

  • Application Catalog website point

  • Configuration Manager Policy Module (NDES)

  • Fallback status point

  • State Migration point

  • System Health Validator point

• Various domain services, like Active Directory Domain Services and DNS (for service location).

• Microsoft Update, to maintain antimalware protection.

• Cloud-based resources, like Microsoft update, or Microsoft Azure and Microsoft Intune when you use these cloud-based services with Configuration Manager.

For details about ports and protocols used by clients when they communicate to these endpoints, see Technical Reference for Ports Used in Configuration Manager.

Before a client can communicate with a site system role, the client uses service location to find a site system role that supports the client’s protocol (HTTP or HTTPS). By default, clients use the most secure method available to them:

• To use HTTPS, you must have a public key infrastructure (PKI) and install PKI certificates on clients and servers. For information about how to use certificates, see PKI Certificate Requirements for Configuration Manager.

• When you deploy a site system role that uses Internet Information Services (IIS) and supports communication from clients, you must specify whether clients connect to the site system by using HTTP or HTTPS. If you use HTTP, you must also consider signing and encryption choices. For more information, see Planning for Signing and Encryption.

The following site system roles and services support HTTPS communications from clients:

• Application Catalog website point

• Configuration Manager Policy Module

• Distribution point (HTTPS is required by cloud-based distribution points)

• Management point

• Software update point

• State Migration point

In addition to the preceding information, when planning for clients in untrusted locations, see Considerations for client communications from the Internet or untrusted forest

Clients determine their assigned site's default management point when they are first installed and assigned to a site. After a client finds its site's default management point, that management point becomes the clients assigned management point. This assignment is determined by the client.

• Beginning with cumulative update 3 for System Center 2012 R2 Configuration Manager, you can HYPERLINK "https://blogs.technet.com/b/jchalfant/archive/2014/09/22/management-point-affinity-added-in-configmgr-2012-r2-cu3.aspx" use management point affinity to configure a client to use one or more specific management points.

• Beginning with System Center 2012 Configuration Manager SP2, you can use preferred management points. A preferred management point is a management point that is associated to a boundary group as site system server, similar to how distribution points or state migration points are associated with a boundary group. If you enable preferred management points for the hierarchy, when a client uses a management point from its assigned site, it will try to use a preferred management point before using other management points from its assigned site.

After a client has an assigned management point, it periodically performs a service location request for its site's default management point, in case it has changed.

Each time a client needs to identify a management point to use, it checks a list of known management points (known as the MP list) which it stores locally in WMI. The client creates an initial MP list when it installs, and then periodically updates the list with details about each management point in the hierarchy.

When the client cannot find a valid management point on its MP list, it then searches the following service location sources, in order, until it finds a management point it can use:

1. Management point

2. Active Directory Domain Services

3. DNS

4. WINS

After a client successfully locates and contacts a management point, it downloads the current list of management points that are available in the hierarchy, and updates its local list. This applies equally to clients that are domain joined and those that are not.

For example, when a Configuration Manager client that is on the Internet connects to an Internet-based management point, the management point sends that client a list of available Internet-based management points in the site. Similarly, clients that are domain joined or in workgroups also receive the list of management points that they might use.

• A client that is not configured for the Internet would not be provided Internet-only facing management points.

• Workgroup clients configured for the Internet only communicate with Internet facing management points.

Following is information about each service location source:

Configuration Manager supports two wake on local area network (LAN) technologies to wake up computers in sleep mode when you want to install required software, such as software updates and applications: traditional wake-up packets and AMT power-on commands.

Beginning with Configuration Manager SP1, you can supplement the traditional wake-up packet method by using the wake-up proxy client settings. Wake-up proxy uses a peer-to-peer protocol and elected computers to check whether other computers on the subnet are awake, and to wake them if necessary. When the site is configured for Wake On LAN and clients are configured for wake-up proxy, the process works as follows:

1. Computers that have the Configuration Manager SP1 client installed and that are not asleep on the subnet check whether other computers on the subnet are awake. They do this by sending each other a TCP/IP ping command every 5 seconds.

2. If there is no response from other computers, they are assumed to be asleep. The computers that are awake become manager computers for the subnet.

   Because it is possible that a computer might not respond because of a reason other than it is asleep (for example, it is turned off, removed from the network, or the proxy wake-up client setting is no longer applied), the computers are sent a wake-up packet every day at 2 P.M. local time. Computers that do not respond will no longer be assumed to be asleep and will not be woken up by wake-up proxy.

   To support wake-up proxy, at least three computers must be awake for each subnet. To achieve this, three computers are non-deterministically chosen to be guardian computers for the subnet. This means that they stay awake, despite any configured power policy to sleep or hibernate after a period of inactivity. Guardian computers honor shutdown or restart commands, for example, as a result of maintenance tasks. If this happens, the remaining guardian computers wake up another computer on the subnet so that the subnet continues to have three guardian computers.

3. Manager computers ask the network switch to redirect network traffic for the sleeping computers to themselves.

   The redirection is achieved by the manager computer broadcasting an Ethernet frame that uses the sleeping computer’s MAC address as the source address. This makes the network switch behave as if the sleeping computer has moved to the same port that the manager computer is on. The manager computer also sends ARP packets for the sleeping computers to keep the entry fresh in the ARP cache. The manager computer will also respond to ARP requests on behalf of the sleeping computer and reply with the MAC address of the sleeping computer.

   Warning

   During this process, the IP-to-MAC mapping for the sleeping computer remains the same. Wake-up proxy works by informing the network switch that a different network adapter is using the port that was registered by another network adapter. However, this behavior is known as a MAC flap and is unusual for standard network operation. Some network monitoring tools look for this behavior and can assume that something is wrong. Consequently, these monitoring tools can generate alerts or shut down ports when you use wake-up proxy.

   Do not use wake-up proxy if your network monitoring tools and services do not allow MAC flaps.

4. When a manager computer sees a new TCP connection request for a sleeping computer and the request is to a port that the sleeping computer was listening on before it went to sleep, the manager computer sends a wake-up packet to the sleeping computer, and then stops redirecting traffic for this computer.

5. The sleeping computer receives the wake-up packet and wakes up. The sending computer automatically retries the connection and this time, the computer is awake and can respond.

Wake-up proxy has the following prerequisites and limitations:

• The supported clients are Windows 7, Windows 8, Windows Server 2008 R2, Windows Server 2012.

• Guest operating systems that run on a virtual machine are not supported.

• Clients must run Configuration Manager SP1 and be enabled for wake-up proxy by using client settings. Although wake-up proxy operation does not depend on hardware inventory, clients do not report the installation of the wake-up proxy service unless they are enabled for hardware inventory and submitted at least one hardware inventory.

• Network adapters (and possibly the BIOS) must be enabled and configured for wake-up packets. If the network adapter is not configured for wake-up packets or this setting is disabled, Configuration Manager will automatically configure and enable it for a computer when it receives the client setting to enable wake-up proxy.

• If a computer has more than one network adapter, you cannot configure which adapter to use for wake-up proxy; the choice is non-deterministic. However, the adapter chosen is recorded in the SleepAgent_<DOMAIN>@SYSTEM_0.log file.

• The network must allow ICMP echo requests (at least within the subnet). You cannot configure the 5 second interval that is used to send the ICMP ping commands.

• Communication is unencrypted and unauthenticated, and IPsec is not supported.

• The following network configurations are not supported:

  • 802.1X with port authentication

  • Wireless networks

  • Network switches that bind MAC addresses to specific ports

  • IPv6-only networks

  • DHCP lease durations less than 24 hours

As a security best practice, use AMT power on commands rather than wake-up packets when this is possible. Because AMT power on commands use PKI certificates to help secure the communication, this technology is more secure than sending wake-up packets. However, to use AMT power on commands, the computers must be Intel AMT-based computers that are provisioned for AMT. For more information about how Configuration Manager can manage AMT-based computers, see Introduction to Out of Band Management in Configuration Manager.

If you want to wake up computers for scheduled software installation, you must configure each primary site for one of the three options:

• Use AMT power on commands if the computer supports this technology; otherwise use wake-up packets

• Use AMT power on commands only.

• Use wake-up packets only.

To use wake-up proxy with Configuration Manager SP1, you must deploy Power Management wake-up proxy client settings in addition to selecting the Use wake-up packets only option.

Use the following table for more information about the differences between the two Wake-on-LAN (WOL) technologies, traditional wake-up packets and power on commands..

Choose how to wake up computers based on whether you can support the AMT power on commands and whether the computers assigned to the site support the Wake-on-LAN technology. Also consider the advantages and disadvantages of both technologies that are listed in the previous table. For example, wake-up packets are less reliable and are not secured, but power on commands take longer to establish and require more processing on the site system server that is configured with the out of band service point.

If you decide to use traditional wake-up packets, you must also decide whether to use subnet-directed broadcast packets, or unicast packets, and what UDP port number to use. By default, traditional wake-up packets are transmitted by using UDP port 9, but to help increase security, you can select an alternative port for the site if this alternative port is supported by intervening routers and firewalls.

Not all client management functionality is appropriate for the Internet; therefore they are not supported when clients are managed on the Internet. The features that are not supported for Internet management typically rely on Active Directory Domain Services or are not appropriate for a public network, such as network discovery and Wake-on-LAN (WOL).

The following features are not supported when clients are managed on the Internet:

• Client deployment over the Internet, such as client push and software update-based client deployment. Instead, use manual client installation.

• Automatic site assignment.

• Network Access Protection (NAP).

• Wake-on-LAN.

• Operating system deployment. However, you can deploy task sequences that do not deploy an operating system; for example, task sequences that run scripts and maintenance tasks on clients.

• Remote control.

• Out of band management.

• Software deployment to users unless the Internet-based management point can authenticate the user in Active Directory Domain Services by using Windows authentication (Kerberos or NTLM). This is possible when the Internet-based management point trusts the forest where the user account resides.

Additionally, Internet-based client management does not support roaming. Roaming enables clients to always find the closest distribution points to download content. Clients that are managed on the Internet communicate with site systems from their assigned site when these site systems are configured to use an Internet FQDN and the site system roles allow client connections from the Internet. Clients non-deterministically select one of the Internet-based site systems, regardless of bandwidth or physical location.

The following site system roles installed at primary sites support connections from clients that are in untrusted locations, like the Internet or an untrusted forest (secondary sites do not support client connections from untrusted locations):

• Application Catalog website point

• Configuration Manager Policy Module

• Distribution point (HTTPS is required by cloud-based distribution points)

• Enrollment proxy point

• Fallback status point

• Management point

• Software update point

About internet facing site systems: 
Although there is no requirement to have a trust between a client’s forest and that of the site system server, when the forest that contains an Internet facing site system trusts the forest that contains the user accounts, this configuration supports user-based policies for devices on the Internet when you enable the Client Policy client setting Enable user policy requests from Internet clients.

For example, the following configurations illustrate when Internet-based client management supports user policies for devices on the Internet:

• The Internet-based management point is in the perimeter network where a read-only domain controller resides to authenticate the user and an intervening firewall allows Active Directory packets.

• The user account is in Forest A (the intranet) and the Internet-based management point is in Forest B (the perimeter network). Forest B trusts Forest A, and an intervening firewall allows the authentication packets.

• The user account and the Internet-based management point are in Forest A (the intranet). The management point is published to the Internet by using a web proxy server (like Forefront Threat Management Gateway).

As the previous example shows, you can place Internet-based site systems in the intranet when they are published to the Internet by using a web proxy server, such as ISA Server and Forefront Threat Management Gateway. These site systems can be configured for client connection from the Internet only, or client connections from the Internet and intranet. When you use a web proxy server, you can configure it for Secure Sockets Layer (SSL) bridging to SSL (more secure) or SSL tunneling:

• SSL bridging to SSL: 
  The recommended configuration when you use proxy web servers for Internet-based client management is SSL bridging to SSL, which uses SSL termination with authentication. Client computers must be authenticated by using computer authentication, and mobile device legacy clients are authenticated by using user authentication. Mobile devices that are enrolled by Configuration Manager do not support SSL bridging.

  The benefit of SSL termination at the proxy web server is that packets from the Internet are subject to inspection before they are forwarded to the internal network. The proxy web server authenticates the connection from the client, terminates it, and then opens a new authenticated connection to the Internet-based site systems. When Configuration Manager clients use a proxy web server, the client identity (client GUID) is securely contained in the packet payload so that the management point does not consider the proxy web server to be the client. Bridging is not supported in Configuration Manager with HTTP to HTTPS, or from HTTPS to HTTP.

• Tunneling:
  If your proxy web server cannot support the requirements for SSL bridging, or you want to configure Internet support for mobile devices that are enrolled by Configuration Manager, SSL tunneling is also supported. It is a less secure option because the SSL packets from the Internet are forwarded to the site systems without SSL termination, so they cannot be inspected for malicious content. When you use SSL tunneling, there are no certificate requirements for the proxy web server.

You must decide whether the client computers that will be managed over the Internet will be configured for management on the intranet and the Internet, or for Internet-only client management. You can only configure the client management option during the installation of a client computer. If you change your mind later, you must reinstall the client.

Clients that are configured for Internet-only client management only communicate with the site systems that are configured for client connections from the Internet. This configuration would be appropriate for computers that you know never connect to your company intranet, for example, point of sale computers in remote locations. It might also be appropriate when you want to restrict client communication to HTTPS only (for example, to support firewall and restricted security policies), and when you install Internet-based site systems in a perimeter network and you want to manage these servers by using the Configuration Manager client.

When you want to manage workgroup clients on the Internet, you must install them as Internet-only.

Other client computers can be configured for Internet and intranet client management. They can automatically switch between Internet-based client management and intranet client management when they detect a change of network. If these clients can find and connect to a management point that is configured for client connections on the intranet, these clients are managed as intranet clients that have full Configuration Manager management functionality. If the clients cannot find or connect to a management point that is configured for client connections on the intranet, they attempt to connect to an Internet-based management point, and if this is successful, these clients are then managed by the Internet-based site systems in their assigned site.

The benefit in automatic switching between Internet-based client management and intranet client management is that client computers can automatically use all Configuration Manager features whenever they are connected to the intranet and continue to be managed for essential management functions when they are on the Internet. Additionally, a download that began on the Internet can seamlessly resume on the intranet, and vice versa.

Internet-based client management in Configuration Manager has the following external dependencies:

Configuration Manager transfers data between sites by using both file-based replication and database replication. Prior to Configuration Manager with SP1 you can configure file-based replication to control the use of network bandwidth for transfers, but cannot configure the use of network bandwidth for database replication. Beginning with Configuration Manager SP1, you can configure the use of network bandwidth for database replication for selected site data.

When you configure network bandwidth controls, you should remain aware of the potential for data latency. If communications between sites is restricted or configured to only transfer data after regular business hours, administrators at either the parent site or child site might be unable to view certain data until the intersite communication has occurred. For example, if an important software update package is being sent to distribution points that are located at child sites, the package might not be available at those sites until all pending intersite communication is completed. Pending communication might include delivery of a package that is very large and that has not yet completed its transfer.

• Controls for File-based Replication: During file-based data transfers, Configuration Manager uses all of the available network bandwidth to send data between sites. You can control this process by configuring the sender at a site to increase or decrease site-to-site sending threads. A sending thread is used to transfer one file at a time. Each additional thread allows additional files to be transferred at the same time, which results in more bandwidth use. To configure the number of threads to use for site-to-site transfers, configure the Maximum concurrent sendings on the Sender tab of the sites properties.

  To control file-based data transfers between sites, you can schedule when Configuration Manager can use a file replication route to a specific site. You can control the amount of network bandwidth to use, the size of data blocks, and the frequency for sending the data blocks. Additional configurations can limit data transfers based on the priority of the data type. For each site in the hierarchy, you can set schedules and rate limits for that site to use when transferring data by configuring the properties of the file replication rout to each destination site. Configurations for a file replication route only apply to the data transfers to the destination site specified for that file replication route.

  For more information about file replication routes, see the sub-section File Replication Routes in the Planning for Intersite Communications in Configuration Manager section in this topic.

  Important

  When you configure rate limits to restrict the bandwidth use on a specific file replication route, Configuration Manager can use only a single thread to transfer data to that destination site. Use of rate limits for a file replication route overrides the use of multiple threads per site that are configured in the Maximum concurrent sendings for each site.

• Controls for Database Replication: Beginning with Configuration Manager SP1, you can configure database replication links to help control the use of network bandwidth for the transfer of selected site data between sites. Some of the controls are similar to those for file-based replication, with additional support to schedule when hardware inventory, software inventory, software metering, and status messages replicate to the parent site across the link.

  For more information, see the section Database Replication in this topic.

Within a site, communication between site systems uses server message blocks (SMB), can occur at any time, and does not support a mechanism to control network bandwidth. However, when you configure the site server to use rate limits and schedules to control the transfer of data over the network to a distribution point, you can manage the transfer of content from the site server to distribution points with controls similar to those for site-to-site file-based transfers.

Clients regularly communicate with different site system servers. For example, they communicate with a site system server that runs a management point when they have to check for a client policy, and communicate with a site system server that runs a distribution point when they have to download content to install an application or software update. The frequency of these connections and the amount of data that is transferred over the network to or from a client depends on the schedules and configurations that you specify as client settings.

Typically, client policy requests use low network bandwidth. The network bandwidth might be high when clients access content for deployments or send information such as hardware inventory data to the site.

You can specify client settings that control the frequency of client-initiated network communications. Additionally, you can configure how clients access deployment content, for example, by using Background Intelligent Transfer Service (BITS). To use BITS to download content, the client must be configured to use BITS. If the client cannot use BITS it uses SMB to transfer the content.

For information about client settings in Configuration Manager, see Planning for Client Settings in Configuration Manager.