Planning for Communications in Configuration Manager

 

Updated: September 9, 2016

Applies To: System Center 2012 Configuration Manager, System Center 2012 Configuration Manager SP1, System Center 2012 Configuration Manager SP2, System Center 2012 R2 Configuration Manager, System Center 2012 R2 Configuration Manager SP1

Before you install System Center 2012 Configuration Manager, plan for the network communications between different sites in a hierarchy, between different site system servers in a site, and between clients and site system servers. These communications might be contained in a single domain, or they might span multiple Active Directory forests. You might also have to plan for communications to manage clients on the Internet.

Use the following sections in this topic to help you plan for communications in Configuration Manager.

• Planning for Intersite Communications in Configuration Manager

  • File-Based Replication

  • Database Replication

• Planning for Intrasite Communications in Configuration Manager

• Planning for Client Communication in Configuration Manager

  • Communications Initiated by Clients

  • Service Location and how clients determine their assigned management point

  • Planning How to Wake Up Clients

• Planning for Communications Across Forests in Configuration Manager

• Planning for Internet-Based Client Management

  • Features that Are Not Supported on the Internet

  • Considerations for client communications from the Internet or untrusted forest

  • Planning for Internet-Based Clients

  • Prerequisites for Internet-Based Client Management

• Planning for Network Bandwidth in Configuration Manager

  • Controlling Network Bandwidth Usage Between Sites

  • Controlling Network Bandwidth Usage Between Site System Servers

  • Controlling Network Bandwidth Usage Between Clients and Site System Servers

What’s New in Configuration Manager

Note

The information in this section also appears in the Getting Started with System Center 2012 Configuration Manager guide.

The following items are new or have changed for site communication since Configuration Manager 2007:

• Site-to-site communication now uses database replication in addition to file-based replication for many site-to-site data transfers, including configurations and settings.

• The Configuration Manager 2007 concept of mixed-mode or native-mode sites to define how clients communicate to site systems in the site has been replaced by site system roles that can independently support HTTP or HTTPS client communications.

• To help support client computers in other forests, Configuration Manager can discover computers in these forests and publish site information to these forests.

• The server locator point is no longer used, and the functionality of this site system role is moved to the management point.

• Internet-based client management now supports the following:

  • User policies when the Internet-based management point can authenticate the user by using Windows authentication (Kerberos or NTLM).

  • Simple task sequences, such as scripts. Operating system deployment on the Internet remains unsupported.

  • Internet-based clients on the Internet first try to download any required software updates from Microsoft Update, rather than from an Internet-based distribution point in their assigned site. Only if this fails, will they then try to download the required software updates from an Internet-based distribution point.

What’s New in Configuration Manager SP1

Note

The information in this section also appears in the Getting Started with System Center 2012 Configuration Manager guide.

The following items are new or have changed for site communication for Configuration Manager SP1:

• File replication routes replace addresses for file-based replication between sites. This is only a change in the name for file-based replication and brings consistency with database replication. There is no change in functionality.

• Configure database replication links between site databases to control and monitor the network traffic for database replication:

  • Use distributed views to prevent the replication of selected site data from a primary site to the central administration site. The central administration site then accesses this data directly from the primary site database.

  • Schedule the transfer of selected site data across database replication links.

  • Control the frequency that replication traffic is summarized for reports.

  • Define custom thresholds that raise alerts for replication problems.

• Configure replication controls for the SQL Server database at a site:

  • Change the port that Configuration Manager uses for the SQL Server Service Broker.

  • Configure the period of time to wait before a replication failure triggers a site to reinitialize its copy of the site database.

  • Configure a site database to compress the data that it replicates by database replication. The data is compressed only for transfer between sites, and not for storage in the site database at either site.

• When Configuration Manager SP1 clients run Windows 7, Windows 8, Windows Server 2008 R2, or Windows Server 2012, you can supplement the Wake on LAN site setting for unicast packets by using the wake-up proxy client settings. This combination helps to wake up computers on subnets without the requirement to reconfigure network switches.

Planning for Intersite Communications in Configuration Manager

In a Configuration Manager hierarchy, each site communicates with its parent site and its direct child sites by using two data transfer methods: file-based replication and database replication. Secondary sites not only communicate to their parent primary sites by using both data transfer methods, but can also communicate with other secondary sites by using file-based replication to route content to remote network locations.

Configuration Manager uses file-based replication and database replication to transfer different types of information between sites.

File-Based Replication

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.

Beginning with Configuration Manager with SP1	Configuration Manager without service pack
File Replication Account	Site Address Account
File replication route	Address
File Replication node in the Configuration Manager console	Addresses node in the Configuration Manager console

File Replication Routes

Configuration Manager uses file replication routes to transfer file-based data between sites in a hierarchy. File replication routes replace addresses, which are used in previous versions of Configuration Manager. The functionality of file replication routes is unchanged from addresses. The following table provides information about file replication routes.

Object	More information
File replication route	Each file replication route identifies a destination site to which file-based data can transfer. Each site supports a single file replication route to a specific destination site. Configuration Manager supports the following configurations for file replication routes: File Replication Account: This account is used to connect to the destination site and to write data to that site’s SMS_SITE share. Data written to this share is processed by the receiving site. By default, when a site is added to the hierarchy, Configuration Manager assigns the computer account of the new sites site server as that sites File Replication Account. This account is then added to the destination site’s SMS_SiteToSiteConnection_<Sitecode> group which is a local group on the computer that grants access to the SMS_SITE share. You can change this account to be a Windows user account. If you change the account, ensure you add the new account to the destination site’s SMS_SiteToSiteConnection_<Sitecode> group. Note Secondary sites always use the computer account of the secondary site server as the File Replication Account. Schedule: You can configure the schedule for each file replication route to restrict the type of data and time when data can transfer to the destination site. Rate Limits: You can configure rate limits for each file replication route to control the network bandwidth that is used when the site transfers data to the destination site: Use Pulse mode to specify the size of the data blocks that are sent to the destination site. You can also specify a time delay between sending each data block. Use this option when you must send data across a very low bandwidth network connection to the destination site. For example, you might have constraints to send 1 KB of data every five seconds, but not 1 KB every three seconds, regardless of the speed of the link or its usage at a given time. Use Limited to maximum transfer rates by hour to have a site send data to a destination site by using only the percentage of time that you specify. When you use this option, Configuration Manager does not identify the network’s available bandwidth, but instead divides the time it can send data into slices of time. Then data is sent in a short block of time, which is followed by blocks of time when data is not sent. For example, if the maximum rate is set to 50%, Configuration Manager transmits data for an amount of time followed by an equal period of time when no data is sent. The actual size amount of data, or size of the data block, is not managed. Instead, only the amount of time during which data is sent is managed. Warning By default, a site can use up to three concurrent sendings to transfer data to a destination site. When you enable rate limits for a file replication route, the concurrent sendings for sending data to that site are limited to one. This applies even when the Limit available bandwidth (%) is set to 100%. For example, if you use the default settings for the sender, this reduces the transfer rate to the destination site to be one third of the default capacity. You can configure a file replication route between two secondary sites to route file-based content between those sites. To manage a file replication route, in the Administration workspace, expand the Hierarchy Configuration node, and select File Replication.
Sender	Each site has one sender. The sender manages the network connection from one site to a destination site, and can establish connections to multiple sites at the same time. To connect to a site, the sender uses the file replication route to the site to identify the account to use to establish the network connection. The sender also uses this account to write data to the destination site’s SMS_SITE share. By default, the sender writes data to a destination site by using multiple concurrent sendings, typically referred to as a thread. Each concurrent sending, or thread, can transfer a different file-based object to the destination site. By default, when the sender begins to send an object, the sender continues to write blocks of data for that object until the entire object is sent. After all the data for the object has been sent, a new object can begin to send on that thread. You can configure the following settings for a sender: Maximum concurrent sendings: By default, each site is configured to use five concurrent sendings, with three available for use when it sends data to any one destination site. When you increase this number you can increase the throughput of data between sites by enabling Configuration Manager to transfer more files at the same time. Increasing this number also increases the demand for network bandwidth between sites. Retry settings: By default, each site is configured to retry a problem connection two times with a one minute delay between connection attempts. You can modify the number of connection attempts the site makes, and how long to wait between those attempts. To manage the sender for a site, expand the Site Configuration node in the Administration workspace, select the Sites node, and then click Properties for the site that you want to manage. Click the Sender tab to change the sender configuration.

Database Replication

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.

Note

Configuration Manager database replication is configured automatically and does not support configuration of replication groups or replication schedules. However, beginning with Configuration Manager SP1, you can configure database replication links to control when specific traffic traverses the network. You can also configure when Configuration Manager raises alerts about replication links that have a status of degraded or failed.

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.

Database Replication Links

When you install a new site in a hierarchy, Configuration Manager automatically creates a database replication link between the two sites. A single link is created to connect the new site to the parent site.

Beginning with Configuration Manager SP1, each database replication link supports configurations to help control the transfer of data across the replication link. Each replication link supports separate configurations. The controls for database replication links include the following:

• Use distributed views to stop the replication of selected site data from a primary site to the central administration site, and enable the central administration site to directly access this data from the database of the primary site.

• Schedule when selected site data transfers from a child primary site to the central administration site.

• Define the settings that determine when a database replication link is in a degraded status or has failed.

• Configure when to raise alerts for a failed replication link.

• Specify how frequently Configuration Manager summarizes data about the replication traffic that uses the replication link. This data is used in reports.

To configure a database replication link, you edit the properties for the link in the Configuration Manager console from the Database Replication node. This node appears in the Monitoring workspace, and beginning with Configuration Manager SP1, this node also appears under the Hierarchy Configuration node in the Administration workspace. You can edit a replication link from either the parent site or the child site of the replication link.

Tip

You can edit database replication links from the Database Replication node in either workspace. However, when you use the Database Replication node in the Monitoring workspace you can also view the status of database replication for replication links, and access the Replication Link Analyzer tool to help you investigate problems with database replication.

For information about how to configure replication links, see Site Database Replication Controls. For more information about how to monitor replication, see the How to Monitor Database Replication Links and Replication Status section in the Monitor Configuration Manager Sites and Hierarchy topic.

Use the information in the following sections to plan for database replication links.

Planning to use Distributed Views

For System Center 2012 Configuration Manager SP1 and later: 

Distributed views enable requests that are made at a central administration site for selected site data, to access that site data directly from the database at a child primary site. This direct access replaces the need to replicate this site data from the primary site to the central administration site. Because each replication link is independent from other replication links, you can enable distributed views on only the replication links you choose. Distributed views are not supported between a primary site and a secondary site.

Distributed views can provide the following benefits:

• Reduce the CPU load to process database changes at the central administration site and primary sites.

• Reduce the amount of data that transfers across the network to the central administration site.

• Improve the performance of the SQL Server that hosts the central administration sites database.

• Reduce the disk space used by the database at the central administration site.

Consider using distributed views when a primary site is located in close proximity on the network to the central administration site, and the two sites are always on, and always connected. This is because distributed views replace the replication of the selected data between the sites with direct connections between the SQL Servers at each site. This direct connection is made each time a request for this data is made at the central administration site. Typically, requests for data you might enable for distributed views is made when you run reports or queries, view information in Resource Explorer, and by collection evaluation for collections that include rules that are based on the site data.

By default, distributed views are disabled for each replication link. When you enable distributed views for a replication link, you select site data that will not replicate to the central administration site across that link, and enable the central administration site to access this data directly from the database of the child primary site that shares the link. You can configure the following types of site data for distributed views:

• Hardware inventory data from clients

• Software inventory and metering data from clients

• Status messages from clients, the primary site, and all secondary sites

Operationally, distributed views are invisible to an administrative user who views data in the Configuration Manager console or in reports. When a request is made for data that is enabled for distributed views, the SQL Server that hosts the database for the central administration site directly accesses the SQL Server of the child primary site to retrieve the information. For example, you use a Configuration Manager console at the central administration site to request information about hardware inventory from two sites, and only one site has hardware inventory enabled for a distributed view. The inventory information for clients from the site that is not configured for distributed views is retrieved from the database at the central administration site. The inventory information for clients from the site that is configured for distributed views is accessed from the database at child primary site. This information appears in the Configuration Manager console or report without distinction as to the source.

As long as a replication link has a type of data enabled for distributed views, the child primary site does not replicate that data to the central administration site. As soon as you turn off distributed views for a type of data, the child primary site resumes the replication of that data to the central administration site as part of normal data replication. However, before this data is available at the central administration site, the replication groups that contain this data must reinitialize between the primary site and the central administration site. Similarly, after you uninstall a primary site that has distributed views enabled, the central administration site must complete reinitialization of its data before you can access data that was enabled for distributed views on the central administration site.

Important

When you use distributed views on any replication link in the hierarchy, you must disable distributed views for all replication links before you uninstall any primary site. For more information, see the Uninstall a Primary Site that is Configured with Distributed Views section in the Install Sites and Create a Hierarchy for Configuration Manager topic.

Prerequisites and Limitations for Distributed Views

The following are prerequisites and limitations for distributed views:

• Both the central administration site and primary site must run the same version of Configuration Manager and have a minimum version of SP1

• The central administration site must use an Enterprise edition of SQL Server. The primary site does not have this requirement

• Distributed views are supported only on replication links between a central administration site and a primary site.

• The central administration site can have only one instance of the SMS Provider installed, and that instance must be installed on the site database server. This is required to support the Kerberos authentication required to enable the SQL Server at the central administration site to access the SQL Server at the child primary site. There are no limitations on the SMS Provider at the child primary site.

• The central administration site can have only one SQL Server Reporting Services point installed, and it must be located on site database server. This is required to support the Kerberos authentication required to enable the SQL Server at the central administration site to access the SQL Server at the child primary site.

• The site database cannot be hosted on a SQL Server cluster.

• The computer account of the database server from the central administration site requires Read permissions to the site database of the primary site.

• Distributed views and schedules for when data can replicate are mutually exclusive configurations for a database replication link.

Plan to Schedule Transfers of Site Data on Database Replication Links

For System Center 2012 Configuration Manager SP1 and later:

To help you control the network bandwidth that is used to replicate site data from a child primary site to its central administration site, you can schedule when a replication link is used, and specify when different types of site data replicates. You can control when the primary site replicates status messages, inventory, and metering data. Database replication links from secondary sites do not support schedules for site data. The transfer of global data cannot be scheduled.

When you configure a database replication link schedule, you can restrict the transfer of selected site data from the primary site to the central administration site, and you can configure different times to replicate different types of site data.

For more information about how to control the use of network bandwidth between Configuration Manager sites, see the section Controlling Network Bandwidth Usage Between Sites in this topic.

Plan for Summarization of Database Replication Traffic

For System Center 2012 Configuration Manager SP1 and later:

Beginning with Configuration Manager SP1, each site periodically summarizes data about the network traffic that traverses database replication links that include the site. This summarized data is used in reports for database replication. Both sites on a replication link summarize the network traffic that traverses the replication link. The summarization of data is performed by the SQL Server that hosts the site database. After summarization of the data, this information replicates to other sites as global data.

By default, summarization occurs every 15 minutes. You can modify the frequency of summarization for network traffic by editing the Summarization interval in the properties of the database replication link. The frequency of summarization affects the information you view in reports about database replication. You can modify this interval from 5 minutes to 60 minutes. When you increase the frequency of summarization, you increase the processing load on the SQL Server at each site on the replication link.

Plan for Database Replication Thresholds

Database replication thresholds define when the status of a database replication link is reported as either degraded or failed. By default, a link is set to degraded when any one replication group fails to complete replication for a period of 12 consecutive attempts, and set to failed when any replication group fails to replicate in 24 consecutive attempts.

Beginning with Configuration Manager SP1, you can specify custom values to fine-tune when Configuration Manager reports a replication link as degraded or failed. Prior to Configuration Manager SP1, you cannot adjust these thresholds. Adjusting when Configuration Manager reports each status for your database replication links can help you accurately monitor the health of database replication across your database replication links.

Because it is possible for one or a few replication groups fail to replicate while other replication groups continue to replicate successfully, plan to review the replication status of a replication link when it first reports a status of degraded. If there are recurring delays for specific replication groups and their delay does not present a problem, or where the network link between sites has low available bandwidth, consider modifying the retry values for the degraded or failed status of the link. When you increase the number of retries before the link is set to degrade or failed, you can eliminate false warnings for known issues, allowing you to more accurately track the status of the link.

You should also consider the replication synchronization interval for each replication groups to understand how frequently replication of that group occurs. You can view the Synchronization Interval for replication groups on the Replication Detail tab of a replication link in the Database Replication node in the Monitoring workspace.

For more information about how to monitor database replication including how to view the replication status, see the How to Monitor Database Replication Links and Replication Status section in the Monitor Configuration Manager Sites and Hierarchy topic.

For information on configuring database replication thresholds, see Site Database Replication Controls.

Site Database Replication Controls

For System Center 2012 Configuration Manager SP1 and later:

Each site database supports configurations that can help you control the network bandwidth used for database replication. These configurations apply only to the site database where you configure the settings, and are always used when the site replicates any data by database replication to any other site.

Replication controls for each site database include the following:

• Change the port that Configuration Manager uses for the SQL Server Service Broker.

• Configure the period of time to wait before replication failures trigger the site to reinitializes its copy of the site database.

• Configure a site database to compress the data that it replicates by database replication. The data is compressed only for transfer between sites, and not for storage in the site database at either site.

To configure the replication controls for a site database, you edit the properties of the site database in the Configuration Manager console from the Database Replication node. This node appears under the Hierarchy Configuration node in the Administration workspace, and also appears in the Monitoring workspace. To edit the properties of the site database, select the replication link between the sites, and then open either the Parent Database Properties or Child Database Properties.

Tip

You can configure database replication controls from the Database Replication node in either workspace. However, when you use the Database Replication node in the Monitoring workspace you can also view the status of database replication for a replication link, and access the Replication Link Analyzer tool to help you investigate problems with replication.

For more information about how to configure database replication controls, see Configure Database Replication Controls. For more information about how to monitor replication, see Monitor Site Database Replication.

Planning for Intrasite Communications in Configuration Manager

Each Configuration Manager site contains a site server and can have one or more additional site system servers that host site system roles. Configuration Manager requires each site system server to be a member of an Active Directory domain. Configuration Manager does not support a change of the computer name or the domain membership while the computer remains a site system.

When Configuration Manager site systems or components communicate across the network to other site systems or Configuration Manager components in the site, they use either server message block (SMB), HTTP, or HTTPS. The communication method depends on how you choose to configure the site. With the exception of communication from the site server to a distribution point, these server-to-server communications in a site can occur at any time and do not use mechanisms to control the network bandwidth. Because you cannot control the communication between site systems, ensure that you install site system servers in locations that have well connected and fast networks.

You can use the following options to help you manage the transfer of content from the site server to distribution points:

• Configure the distribution point for network bandwidth control and scheduling. These controls resemble the configurations used by intersite addresses, and you can often use this configuration instead of installing another Configuration Manager site when the transfer of content to remote network locations is your main bandwidth consideration.

• You can install a distribution point as a prestaged distribution point. A prestaged distribution point lets you use content that is manually put on the distribution point server and removes the requirement to transfer content files across the network.

For more information about network bandwidth considerations, see Network Bandwidth Considerations for Distribution Points in Planning for Content Management in Configuration Manager.

Planning for Client Communication in Configuration Manager

Configuration Manager clients and managed devices communicate with computers that host Configuration Manager infrastructure like site system roles, domain infrastructure like DNS or Active Directory Domain Services, and with services on the Internet.

Consider the following when planning for client communications:

Communication scenarios	More information
Communications initiated by clients	Clients initiate communications to the following: Management points: To submit inventory, status and discovery data. The management point is the client’s primary point of contact for a site. Various domain services: To request service from domain services, like Active Directory Domain Services and DNS (for service location). Content access: To access content from distribution points on servers, peers, and cloud-based services. Software update points: To download and install updates you deploy. Microsoft Update: To maintain antimalware protection. Additional site system servers: Application Catalog website point Configuration Manager Policy Module (NDES) Fallback status point State Migration point System Health Validator
Service location	Service location is the method by which clients identify an assigned site, and dynamically locate management points. Management points are the primary contact point for clients and are used to: Learn about other available management points Download client policy Submit client data to the site, like status, inventory, and discovery data.

Use the information in the following sections to plan for communications by Windows-based clients.

Beginning with Configuration Manager SP1, you can manage clients that run Linux and UNIX. Clients that run Linux and UNIX operate as clients in workgroups. For information about supporting computers that are in workgroups, see the Planning for Communications Across Forests in Configuration Manager in this topic. For additional information about communication for clients that run Linux and UNIX, see the Planning for Communication across Forest Trusts for Linux and UNIX Servers section in the Planning for Client Deployment for Linux and UNIX Servers topic.

Communications Initiated by Clients

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

Service Location and how clients determine their assigned management point

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:

The MP list

A clients MP list is the preferred source for service location source as it is a prioritized list of management points that the client previously identified. This list is sorted by each client based on its network location when the client updates the list, and then stored locally on the client in WMI.

Building the Initial MP list

During installation of the client, the following rules are used to build the clients initial MP list:

• The initial list includes management points specified during client installation (when you use the SMSMP= or the /MP options).

• The client queries Active Directory Domain Services (AD DS) for published management points. In order to be identified from AD DS, the management point must be from the client’s assigned site, and be of the same product version as the client.

• If no management point was specified during client installation, and when the Active Directory schema is not extended, the client checks DNS and WINS for published management points.

• When building the initial list, information about some management points in the hierarchy might not be known.

Organizing the management point list

Clients organize their list of management points using the following classifications:

• Proxy: A proxy management point is a management point at a secondary site.

• Local: Any management point that is associated with the client’s current network location as defined by site boundaries.

  • When a client belongs to more than one boundary group, the list of local management points is determined from the union of all boundaries that include the current network location of the client.

  • Typically, Local management points are a subset of a clients Assigned management points unless the client is on a network location associated with another site with management points servicing its boundary groups.

• Assigned: Any management point that is a site system for the client’s assigned site.

  Beginning with System Center 2012 Configuration Manager SP2, you can use preferred management points. Preferred management points are management points from a client’s assigned site that are associated to a boundary group that the client is using to find site system servers.

  Management points at a site that are not associated with a boundary group, or that are not in a boundary group associated with a client’s current network location, are not considered preferred, and will be used when the client cannot identify an available preferred management point.

Selecting a management point to use

For typical communications, a client attempts to use a use a management point from the classifications in the following order, based on the client’s network location:

1. Proxy

2. Local

3. Assigned

However, the client always uses the assigned management point for registration messages and certain policy messages, even when other communications are sent to a proxy or local management point.

Within each classification (proxy, local, or assigned), clients attempt to use a management point based on preferences, in the following order:

1. HTTPS capable in a trusted or local forest (when the client is configured for HTTPS communication)

2. HTTPS capable not in trusted or local forest (when the client is configured for HTTPS communication)

3. HTTP capable in trusted or local forest

4. HTTP capable not in trusted or local forest

From the set of management points sorted by preferences, clients attempt to use the first management point on the list:

• This sorted list of management points is random, and cannot be ordered.

• The order of the list can change each time the client updates its management point list.

When a client cannot establish contact with the first management point, it tries each successive management point on its list, trying each preferred management point in the classification before trying the non-preferred management points. If a client cannot successfully communicate with any management point in the classification, it will then attempt to contact a preferred management point from the next classification, and so on until the client finds a management point to use.

After establishing communication with a management point, clients continue to use that same management point until:

• After 25 hours the client randomly selects a new management point to use.

• The client is unable to communicate with the management point for 5 attempts over a period of 10 minutes, at which time the client selects a new management point to use.

Active Directory

Clients that are domain joined can use Active Directory Domain Services (AD DS) for service location. This requires sites to publish data to Active Directory.

Clients can use Active Directory Domain Services for service location when all the following conditions are true:

• The Active Directory schema is has been extended for System Center 2012 Configuration Manager or was extended for Configuration Manager 2007.

• The Active Directory forest is configured for publishing, and Configuration Manager sites are configured to publish.

• The client computer is a member of an Active Directory domain and can access a global catalog server.

If a client cannot find a management point to use for service location from AD DS, it then attempts to use DNS. Clients that are domain joined can use AD DS for service location. This requires sites to publish data to Active Directory.

DNS

Clients on the intranet can use DNS for service location. This requires at least one site in a hierarchy to publish information about management points to DNS.

Consider using DNS for service location when any of the following conditions are true:

• The Active Directory Domain Services schema is not extended to support Configuration Manager.

• Clients on the intranet are located in a forest that is not enabled for Configuration Manager publishing.

• You have clients on workgroup computers, and those clients are not configured for Internet-only client management. (A workgroup client configured for the Internet will only communicate with Internet facing management points and will not use DNS for service location.)

• You can configure clients to find management points from DNS.

When a site publishes service location records for management points to DNS:

• Publishing is applicable only to management points that accept client connections from the intranet.

• Publishing adds a service location resource record (SRV RR) in the DNS zone of the management point computer. There must be a corresponding host entry in DNS for that computer.

By default, domain joined clients search DNS for management point records from the client’s local domain. You can configure a client property that specifies a domain suffix for a domain that does have management point information published to DNS.

For more information about how to configure the DNS suffix client property, see How to Configure Client Computers to Find Management Points by using DNS Publishing in Configuration Manager.

If a client cannot find a management point to use for service location from DNS, it then attempts to use WINS.

Publish Management Points to DNS

To publish management points to DNS, the following two conditions must be true:

• Your DNS servers support service location resource records, by using a version of BIND that is at least 8.1.2.

• The specified intranet FQDNs for the management points in Configuration Manager have host entries (for example, A records) in DNS.

Important

Configuration Manager DNS publishing does not support a disjoint namespace. If you have a disjoint namespace, you can manually publish management points to DNS or use one of the other alternative service location methods that are documented in this section.

When your DNS servers support automatic updates, you can configure Configuration Manager to automatically publish management points on the intranet to DNS, or you can manually publish these records to DNS. When management points are published to DNS, their intranet FQDN and port number are published in the service location (SRV) record. You configure DNS publishing at a site in the sites Management Point Component Properties. For more information, see Configuring Site Components in Configuration Manager.

When your DNS servers do not support automatic updates but do support service location records, you can manually publish management points to DNS. To accomplish this, you must manually specify the service location resource record (SRV RR) in DNS.

Configuration Manager supports RFC 2782 for service location records, which have the following format:

_Service._Proto.Name TTL Class SRV Priority Weight Port Target

To publish a management point to Configuration Manager, specify the following values:

• _Service: Enter _mssms_mp*_<sitecode>*, where <sitecode> is the management point's site code.

• ._Proto: Specify ._tcp.

• .Name: Enter the DNS suffix of the management point, for example contoso.com.

• TTL: Enter 14400, which is four hours.

• Class: Specify IN (in compliance with RFC 1035).

• Priority: This field is not used by Configuration Manager.

• Weight: This field is not used by Configuration Manager.

• Port: Enter the port number that the management point uses, for example 80 for HTTP and 443 for HTTPS.

  Note

  The SRV record port should match the communication port used by the management point. By default, this is 80 for HTTP communication, and 443 for HTTPS communications.

• Target: Enter the intranet FQDN that is specified for the site system that is configured with the management point site role.

If you use Windows Server DNS, you can use the following procedure to enter this DNS record for intranet management points. If you use a different implementation for DNS, use the information in this section about the field values and consult that DNS documentation to adapt this procedure.

To configure automatic publishing:

1. In the Configuration Manager console, expand Administration > Site Configuration > Sites.

2. Select your site and then click Configure Site Components.

3. Select Management Point.

4. Select the management points you want to publish. (This selection applies to publishing to AD DS, and DNS).

5. Select the checkbox to publish to DNS:

   - This dialog allows you to select which management points to publish, and to publish to DNS.
   
   - This dialog does not configure publishing to AD DS.
   

To manually publish management points to DNS on Windows Server

1. In the Configuration Manager console, specify the intranet FQDNs of site systems.

2. In the DNS management console, select the DNS zone for the management point computer.

3. Verify that there is a host record (A or AAAA) for the intranet FQDN of the site system. If this record does not exist, create it.

4. By using the New Other Records option, click Service Location (SRV) in the Resource Record Type dialog box, click Create Record, enter the following information, and then click Done:

   - **Domain**: If necessary, enter the DNS suffix of the management point, for example **contoso.com**.
   
   - **Service**: Type **\_mssms\_mp***\_\<sitecode\>*, where *\<sitecode\>* is the management point's site code.
   
   - **Protocol**: Type **\_tcp**.
   
   - **Priority**: This field is not used by Configuration Manager.
   
   - **Weight**: This field is not used by Configuration Manager.
   
   - **Port**: Enter the port number that the management point uses, for example **80** for HTTP and **443** for HTTPS.
   
     <div class="alert">
   
   
     > [!NOTE]
     > <P>The SRV record port should match the communication port used by the management point. By default, this is <STRONG>80</STRONG> for HTTP communication, and <STRONG>443</STRONG> for HTTPS communications.</P>
   
   
     </div>
   
   - **Host offering this service**: Enter the intranet fully qualified domain name that is specified for the site system that is configured with the management point site role.
   

Repeat these steps for each management point on the intranet that you want to publish to DNS.

WINS

When other service location mechanisms fail, clients can find an initial management point by checking WINS.

By default, a primary site publishes to WINS the first management point at the site that is configured for HTTP and the first management point configured for HTTPS.

If you do not want clients to find an HTTP management point in WINS, configure clients with the CCMSetup.exe Client.msi property SMSDIRECTORYLOOKUP=NOWINS.

Planning How to Wake Up Clients

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:

Important

If you have a separate team that is responsible for the network infrastructure and network services, notify and include this team during your evaluation and testing period. For example, on a network that uses 802.1X network access control, wake-up proxy will not work and can disrupt the network service. In addition, wake-up proxy could cause some network monitoring tools to generate alerts when the tools detect the traffic to wake-up other computers.

• 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..

Technology	Advantage	Disadvantage
Traditional wake-up packets	Does not require any additional site system roles in the site. Supported by many network adapters. UDP wake-up packets are quick to send and process. Does not require a PKI infrastructure. Does not require any changes to Active Directory Domain Services. Supported on workgroup computers, computers from another Active Directory forest, and computers in the same Active Directory forest but using a noncontiguous namespace.	Less secure solution than AMT power on commands because it does not use authentication or encryption. If subnet-directed broadcast transmissions are used for the wake-up packets, this has the security risk of smurf attacks. Might require manual configuration on each computer for BIOS settings and adapter configuration. No confirmation that computers are woken up. Wake-up transmissions as multiple User Datagram Protocol (UDP) packets can unnecessarily saturate available network bandwidth. Unless you use wake-up proxy with Configuration Manager SP1, cannot wake up computers interactively. Cannot return computers to sleep state. Management features are restricted to waking up computers only.
AMT power on commands	More secure solution than traditional wake-up packets because it provides authentication and encryption by using standard industry security protocols. It can also integrate with an existing PKI deployment, and the security controls can be managed independently from the product. Supports automatic centralized setup and configuration (AMT provisioning). Established transport session for a more reliable connection and auditable connection. Computers can be woken up interactively (and restarted). Computers can be powered down interactively. Additional management capabilities, which include the following: Restarting a nonfunctioning computer and booting from a locally connected device or known good boot image file. Re-imaging a computer by booting from a boot image file that is located on the network or by using a PXE server. Reconfiguring the BIOS settings on a selected computer and bypassing the BIOS password if this is supported by the BIOS manufacturer. Booting to a command-based operating system to run commands, repair tools, or diagnostic applications (for example, upgrading the firmware or running a disk repair tool).	Requires that the site has an out of band service point and enrollment point. Supported only on computers that have the Intel vPro chip set and a supported version of Intel Active Management Technology (Intel AMT) firmware. For more information about which AMT versions are supported, see Supported Configurations for Configuration Manager. The transport session requires more time to establish, higher processing on the server, and an increase in data transferred. Requires a PKI deployment and specific certificates. Requires an Active Directory container that is created and configured for publishing AMT-based computers. Cannot support workgroup computers, computers from another Active Directory forest, or computers from the same Active Directory forest but that use a noncontiguous namespace. Requires changes to DNS and DHCP to support AMT provisioning.

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.

Important

Because of the additional overhead involved in establishing, maintaining, and ending an out of band management session to AMT-based computers, conduct your own tests so that you can accurately judge how long it takes to wake up multiple computers by using AMT power on commands in your environment (for example, across slow WAN links to computers in secondary sites). This knowledge helps you determine whether waking up multiple computers for scheduled activities by using AMT power on commands is practical when you have many computers to wake up in a short amount of time.

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.

For Traditional Wake-up Packets: Choose Between Unicast and Subnet-Directed Broadcast for Wake-on-LAN

If you chose to wake up computers by sending traditional wake-up packets, you must decide whether to transmit unicast packets or subnet-direct broadcast packets. If you use wake-up proxy with Configuration Manager SP1, you must use unicast packets. Otherwise, use the following table to help you determine which transmission method to choose.

Transmission method	Advantage	Disadvantage
Unicast	More secure solution than subnet-directed broadcasts because the packet is sent directly to a computer instead of to all computers on a subnet. Might not require reconfiguration of routers (you might have to configure the ARP cache). Consumes less network bandwidth than subnet-directed broadcast transmissions. Supported with IPv4 and IPv6.	Wake-up packets do not find destination computers that have changed their subnet address after the last hardware inventory schedule. Switches might have to be configured to forward UDP packets. Some network adapters might not respond to wake-up packets in all sleep states when they use unicast as the transmission method.
Subnet-Directed Broadcast	Higher success rate than unicast if you have computers that frequently change their IP address in the same subnet. No switch reconfiguration is required. High compatibility rate with computer adapters for all sleep states, because subnet-directed broadcasts were the original transmission method for sending wake-up packets.	Less secure solution than using unicast because an attacker could send continuous streams of ICMP echo requests from a falsified source address to the directed broadcast address. This causes all of the hosts to reply to that source address. If routers are configured to allow subnet-directed broadcasts, the additional configuration is recommended for security reasons: Configure routers to allow only IP-directed broadcasts from the Configuration Manager site server, by using a specified UDP port number. Configure Configuration Manager to use the specified non-default port number. Might require reconfiguration of all intervening routers to enable subnet-directed broadcasts. Consumes more network bandwidth than unicast transmissions. Supported with IPv4 only; IPv6 is not supported.

Warning

There are security risks associated with subnet-directed broadcasts: An attacker could send continuous streams of Internet Control Message Protocol (ICMP) echo requests from a falsified source address to the directed broadcast address, which cause all the hosts to reply to that source address. This type of denial of service attack is commonly called a smurf attack and is typically mitigated by not enabling subnet-directed broadcasts.

Planning for Communications Across Forests in Configuration Manager

System Center 2012 Configuration Manager supports sites and hierarchies that span Active Directory forests.

Configuration Manager also supports domain computers that are not in the same Active Directory forest as the site server, and computers that are in workgroups:

• To support domain computers in a forest that is not trusted by your site server’s forest, you can install site system roles in that untrusted forest, with the option to publish site information to the client’s Active Directory forest. Or, you can manage these computers as if they are workgroup computers. When you install site system servers in the client’s forest, the client-to-server communication is kept within the client’s forest and Configuration Manager can authenticate the computer by using Kerberos. When you publish site information to the client’s forest, clients benefit from retrieving site information, such as a list of available management points, from their Active Directory forest rather than downloading this information from their assigned management point.

  Note

  If you want to manage devices that are on the Internet, you can install Internet-based site system roles in your perimeter network when the site system servers are in an Active Directory forest. This scenario does not require a two-way trust between the perimeter network and the site server’s forest.

• To support computers in a workgroup, you must manually approve these computers if they use HTTP client connections to site system roles because Configuration Manager cannot authenticate these computers by using Kerberos. In addition, you must configure the Network Access Account so that these computers can retrieve content from distribution points. Because these clients cannot retrieve site information from Active Directory Domain Services, you must provide an alternative mechanism for them to find management points. You can use DNS publishing, or WINS, or directly assign a management point.

  For information about client approval, see Configure Settings for Client Approval and Conflicting Client Records in Configuring Settings for Client Management in Configuration Manager.

  For information about how to configure the Network Access Account, see the Configure the Network Access Account section in the Configuring Content Management in Configuration Manager topic.

  For information about how to install clients on workgroup computers, see the How to Install Configuration Manager Clients on Workgroup Computers section in the How to Install Clients on Windows-Based Computers in Configuration Manager topic.

Configuration Manager supports the Exchange Server connector in a different forest from the site server. To support this scenario, ensure that name resolution works across the forests (for example, configure DNS forwards), and specify the intranet FQDN of the Exchange Server when you configure the Exchange Server connector. For more information, see How to Manage Mobile Devices by Using Configuration Manager and Exchange.

When your Configuration Manager design spans multiple Active Directory domains and forests, use the additional information in the following table to help you plan for the following types of communication.

Scenario	Details	More information
Communication between sites in a hierarchy that spans forests: Requires a two-way forest trust, which supports Kerberos authentication that Configuration Manager requires.	Configuration Manager supports installing a child site in a remote forest that has the required two-way trust with the forest of the parent site. For example: You can place a secondary site in a different forest from its primary parent site so long as the required trust exists. If you do not have a two-way forest trust which supports Kerberos authentication, then Configuration Manager does not support the child site in the remote forest. Note A child site can be primary site (where the central administration site is the parent site), or a secondary site. Intersite communication in Configuration Manager uses database replication and file-based transfers. When you install a site, you must specify an account to install the site on the designated server. This account also establishes and maintains communication between sites. After the site successfully installs and initiates file-based transfers and database replication, you do not have to configure anything else for communication to the site. For more information about how to install a site, see the Install a Site Server section in the Install Sites and Create a Hierarchy for Configuration Manager topic.	When a two-way forest trust exists, Configuration Manager does not require any additional configuration steps. By default, when you install a new site as a child of another site, Configuration Manager configures the following: An intersite file-based replication address at each site that uses the site server computer account. Configuration Manager adds the computer account of each computer to the SMS_SiteToSiteConnection_<sitecode> group on the destination computer. Database replication between the SQL Server at each site. The following configurations must also be set: Intervening firewalls and network devices must allow the network packets that Configuration Manager requires. Name resolution must work between the forests. To install a site or site system role, you must specify an account that has local administrator permissions on the specified computer.
Communication in a site that spans forests: Does not require a two-way forest trust.	Primary sites support the installation of site system roles on computers in other forests. Two exceptions are the out of band service point and the Application Catalog web service point, which must be installed in the same forest as the site server. When a site system role accepts connections from the Internet, as a security best practice, install the site system roles in a location where the forest boundary provides protection for the site server (for example, in a perimeter network). When you install a site system role on a computer in an untrusted forest: You must specify a Site System Installation Account which is used to install the site system role. This account must have local administrative credentials to connect to, and then install site system roles on the specified computer. You must select the site system option Require the site server to initiate connections to this site system. This requires the site server to establish connections to the site system server to transfer data. This prevents the computer in the untrusted location from initiating contact with the site server that is inside your trusted network. These connections use the Site System Installation Account. When you use a site system role in an untrusted forest, firewalls must allow the network traffic even when the site server initiates the transfer of data. Additionally, the following site system roles require direct access to the site database. Therefore, firewalls must allow applicable traffic from the untrusted forest to the sites SQL Server: Asset Intelligence synchronization point Endpoint Protection point Enrollment point Management point Reporting service point State migration point See Technical Reference for Ports Used in Configuration Manager for more information.	The management point and enrollment point site system roles connect to the site database. By default, when these site system roles are installed, Configuration Manager configures the computer account of the new site system server as the connection account and adds the account to the appropriate SQL Server database role. When you install these site system roles in an untrusted domain, you must configure the site system role connection account to enable the site system role to obtain information from the database. If you configure a domain user account for these connection accounts, ensure that the account has appropriate access to the SQL Server database at that site: Management point: Management Point Database Connection Account Enrollment point: Enrollment Point Connection Account Consider the following additional information when you plan for site system roles in other forests: If you run a Windows Firewall, configure the applicable firewall profiles to pass communications between the site database server and computers that are installed with remote site system roles. For information about firewall profiles, see Understanding Firewall Profiles. When the Internet-based management point trusts the forest that contains the user accounts, user policies are supported. When no trust exists, only computer policies are supported.
Communication between clients and site system roles when the clients are not in the same Active Directory forest as their site server.	Configuration Manager supports the following scenarios for clients that are not in the same forest as their site’s site server: There is a two-way forest trust between the forest of the client and the forest of the site server The site system role server is located in the same forest as the client The client is on a domain computer that does not have a two-way forest trust with the site server and site system roles are not installed in the client's forest The client is on a workgroup computer Note Configuration Manager cannot manage AMT-based computers out of band when these computers are in a different forest from the site server.	Clients on a domain computer can use Active Directory Domain Services for service location when their site is published to their Active Directory Forest. To publish site information to another Active Directory forest, you must first specify the forest and then enable publishing to that forest in the Active Directory Forests node of the Administration workspace. Additionally, you must enable each site to publish its data to Active Directory Domain Services. This configuration enables clients in that forest to retrieve site information and find management points. For clients that cannot use Active Directory Domain Services for service location, you can use DNS, WINS, or the client’s assigned management point.

Planning for Internet-Based Client Management

Internet-based client management lets you manage Configuration Manager clients when they are not connected to your company network but have a standard Internet connection. This arrangement has several advantages that include the reduced costs of not having to run virtual private networks (VPNs) and being able to deploy software updates in a timelier manner.

Because of the higher security requirements of managing client computers on a public network, Internet-based client management requires that clients and the site system servers that the clients connect to use PKI certificates. This ensures that connections are authenticated by an independent authority, and that data to and from these site systems are encrypted by using Secure Sockets Layer (SSL).

Use the following sections to help you plan for Internet-based client management.

Features that Are Not Supported on the Internet

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.

Note

New in System Center 2012 Configuration Manager, when you have a software update point that is configured to accept connections from the Internet, Configuration Manager Internet-based clients on the Internet always scan against this software update point, to determine which software updates are required. However, when these clients are on the Internet, they first try to download the software updates from Microsoft Update, rather than from an Internet-based distribution point. Only if this fails, will they then try to download the required software updates from an Internet-based distribution point. Clients that are not configured for Internet-based client management never try to download the software updates from Microsoft Update, but always use Configuration Manager distribution points.

Considerations for client communications from the Internet or untrusted forest

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).

Note

If Kerberos authentication fails, NTLM authentication is then automatically tried.

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.

Planning for Internet-Based Clients

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.

Note

For System Center 2012 R2 Configuration Manager and later: If you configure an Internet capable management point, clients that connect to the management point will become Internet-capable when they next refresh their list of available management points.

Tip

You do not have to restrict the configuration of Internet-only client management to the Internet and you can also use it on the intranet.

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.

Note

Mobile device clients are automatically configured as Internet-only when they are configured to use an Internet-based management point.

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.

Prerequisites for Internet-Based Client Management

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

Dependency	More information
Clients that will be managed on the Internet must have an Internet connection.	Configuration Manager uses existing Internet Service Provider (ISP) connections to the Internet, which can be either permanent or temporary connections. Client mobile devices must have a direct Internet connection, but client computers can have either a direct Internet connection or connect by using a proxy web server.
Site systems that support Internet-based client management must have connectivity to the Internet and must be in an Active Directory domain.	The Internet-based site systems do not require a trust relationship with the Active Directory forest of the site server. However, when the Internet-based management point can authenticate the user by using Windows authentication, user policies are supported. If Windows authentication fails, only computer policies are supported. Note To support user policies, you also must set to True the two Client Policy client settings: Enable user policy polling on clients Enable user policy requests from Internet clients An Internet-based Application Catalog website point also requires Windows authentication to authenticate users when their computer is on the Internet. This requirement is independent from user policies.
You must have a supporting public key infrastructure (PKI) that can deploy and manage the certificates that the clients require and that are managed on the Internet and the Internet-based site system servers.	For more information about the PKI certificates, see PKI Certificate Requirements for Configuration Manager
The following infrastructure services must be configured to support Internet-based client management: Public DNS servers: The Internet fully qualified domain name (FQDN) of site systems that support Internet-based client management must be registered as host entries on public DNS servers. Intervening firewalls or proxy servers: These network devices must allow the client communication that is associated with Internet-based site systems.	Client communication requirements: Support HTTP 1.1 Allow HTTP content type of multipart MIME attachment (multipart/mixed and application/octet-stream) Allow the following verbs for the Internet-based management point: HEAD CCM_POST BITS_POST GET PROPFIND Allow the following verbs for the Internet-based distribution point: HEAD GET PROPFIND Allow the following verbs for the Internet-based fallback status point: POST Allow the following verbs for the Internet-based Application Catalog website point: POST GET Allow the following HTTP headers for the Internet-based management point: Range: CCMClientID: CCMClientIDSignature: CCMClientTimestamp: CCMClientTimestampsSignature: Allow the following HTTP header for the Internet-based distribution point: Range: For configuration information to support these requirements, refer to your firewall or proxy server documentation. For similar communication requirements when you use the software update point for client connections from the Internet, see the documentation for Windows Server Update Services (WSUS). For example, for WSUS on Windows Server 2003, see Appendix D: Security Settings, the deployment appendix for security settings.

Planning for Network Bandwidth in Configuration Manager

System Center 2012 Configuration Manager includes several methods to control the network bandwidth that is used by communications between sites, site system servers, and clients. However, not all communication on the network can be managed. Use the following sections to help you understand the methods that you can use to control network bandwidth and to design your site hierarchy.

When you plan the Configuration Manager hierarchy, consider the amount of network data that will be transferred from intersite and intrasite communications.

Note

File replication routes (known as addresses prior to Configuration Manager SP1), are used only for intersite communications and are not used for intrasite communications between site servers and site systems.

Controlling Network Bandwidth Usage Between Sites

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.

Controlling Network Bandwidth Usage Between Site System Servers

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.

Controlling Network Bandwidth Usage Between Clients and Site System Servers

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.

See Also

Planning for Configuration Manager Sites and Hierarchy