Export (0) Print
Expand All
Expand Minimize

Planning for Communications in Configuration Manager

Updated: April 1, 2014

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

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.

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

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

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.

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

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.

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

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

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.

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

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.

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

For System Center 2012 Configuration Manager SP1 and System Center 2012 R2 Configuration Manager only:

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.

ImportantImportant
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 when you Use Distributed Views section in the Install Sites and Create a Hierarchy for Configuration Manager topic.

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

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

For System Center 2012 Configuration Manager SP1 and System Center 2012 R2 Configuration Manager only:

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.

For System Center 2012 Configuration Manager SP1 and System Center 2012 R2 Configuration Manager only:

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.

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.

For System Center 2012 Configuration Manager SP1 and System Center 2012 R2 Configuration Manager only:

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.

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

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.

Client communication in Configuration Manager includes client-to-site-system communications and service location inquiries. By using service location inquiries, Configuration Manager clients can identify the site system servers to use.

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.

Configuration Manager clients initiate communication to site system roles that provide services to clients. This includes management points from which clients download client policy, and distribution points from which clients download content. To communicate with a site system role, the client must first locate a site system role that is configured to support the protocol (HTTPS or HTTP) that the client can use. By default, clients use the most secure method available to them. Therefore, a client that is configured to use a PKI certificate attempts to locate and communicate with a site system role by using HTTPS before it communicates with a site system role that uses HTTP.

For a Configuration Manager client to use HTTPS, you must have a public key infrastructure (PKI) and must install PKI certificates on clients and servers. The client requires a certificate that has client authentication capability for mutual authentication with the site system server. 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 that include management points, an Application Catalog website point, a state migration point, or distribution points, 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.

You can also configure the site system to use an intranet fully qualified domain name (FQDN) and an Internet FQDN. When you configure an Internet FQDN, you can then configure the site system role to accept client connections from the Internet. You can configure support for client connections from the Internet only, or clients connections from the intranet and Internet.

You can deploy multiple instances of a site system role in a site and separate instances of that site system role support different communication settings. For example, in a single site, you can have one management point that accepts HTTPS client communication and another management point that accepts HTTP client communication. You can use one site to manage clients across different network locations that use different communication protocols and security settings.

When clients use a PKI certificate to authenticate themselves to a management point, Configuration Manager knows that the client is trusted because the trust is established by using PKI. When you do not use PKI to establish this trust, Configuration Manager uses a process named client approval to register this trust.

By default, Configuration Manager uses the computer account of the device and Kerberos authentication to verify that the device is trusted. By using this default setting, you must manually verify that any client that is displayed as Not Approved in the Configuration Manager console is a trusted device, and then approve it to be managed by Configuration Manager. This scenario applies to computers that are in untrusted forests and in workgroups. It also applies if the Kerberos authentication failed for any reason.

Although Configuration Manager has a configuration option to automatically approve all clients, do not use this configuration unless Configuration Manager is running in a secured test environment. You can also select a configuration option to always manually approve clients.

The approval setting is for all devices in the hierarchy, and you can manually approve clients from anywhere in the hierarchy.

noteNote
Although some management functions might work for clients that are not approved, Configuration Manager does not support the management of these devices.

Service location is how Configuration Manager clients find sites, site information, and site system roles that they can communicate with. For example, for clients to successfully download client policy, they must first locate a management point from their site that uses the same protocol as they use.

Service location is independent from name resolution, which maps a computer name to an IP address. Name resolution is performed by DNS or WINS. However, DNS and WINS can also be used for service location.

Clients search for a management point by using the following options in the order specified:

  1. Management point

  2. Active Directory Domain Services

  3. DNS

  4. WINS

When you install a Configuration Manager client, you can use the /MP option to indicate the management point for the client installation process to download the client installation files. You can use the SMSMP= option to identify the initial management point that the client first communicates with. When a client communicates successfully with a management point from its assigned site, it downloads the current list of available management points and stores this information locally in WMI for future use. After the initial list of management points is built, the client updates the list every 25 hours, and when it receives a new IP address, and when the client CCMEXEC service starts.

During the installation of the client, the client builds a lookup list of management points (also known as an MP list) that include the management points that you specify during client installation, and management points that the client can identify from Active Directory Domain Services. A site must have one or more management points installed, and the site must publish to Active Directory Domain Services before the client can discover the site’s management points from Active Directory Domain Services. Management points that are found in Active Directory Domain Services must match the client’s assigned site code and client version. The client ignores management points that are published by Configuration Manager 2007. If you did not specify a management point to the client during client installation, and if you have not extended the Active Directory schema, the client checks DNS and WINS for management points to add to its lookup list.

noteNote
When a client is a member of more than one boundary group that is configured for site assignment, the management point lookup list is determined by a union of all of the boundaries that are associated to each of those boundary groups.

After the client builds its list of management points, it sorts the list into different priorities. When the client supports a client PKI certificate, the client uses a management point that supports HTTPS communication and puts HTTPS-capable management points first in the list, as preferred management points. The client then tries to contact a preferred management point before it uses a management point that is not preferred. The order of all equivalent management points is not set and only the relative priority is set. This order of equivalent management points can reset every time that the client updates its management point lookup list. Therefore, a client that has three HTTPS capable management points available to it might contact any of the three HTTPS management points during each new connection attempt. If the client cannot reach the first management point, it retries several times. If it continues to fail, it tries additional management points until communications are established, or there are no more management points on its list.

For information about how to install Configuration Manager clients, and how to use command-line parameters to specify management points and the protocol that a client uses to contact site system roles, see How to Install Clients on Windows-Based Computers in Configuration Manager.

If the client cannot contact a management point from its lookup list, it tries to use an alternative service location method.

Intranet clients use Active Directory Domain Services as their primary method of service location. Examples of site information include the location of available site system roles and their capabilities, and the security information that is required by client computers to establish trusted connections with site system servers in the site. Configuration Manager clients can use Active Directory Domain Services for service location when all the following conditions are true:

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

  • Configuration Manager sites publish to Active Directory Domain Services.

  • The Active Directory forest is enabled for publishing in Configuration Manager.

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

If any one of these conditions cannot be met, you can configure alternative service location methods. Alternatives include DNS, WINS, and a management point that is specified during client installation.

If you cannot publish site information to Active Directory Domain Services, consider publishing management points to DNS. You can publish this site system role for clients on the intranet.

When you publish Configuration Manager management points to DNS, this configuration adds a service location resource record (SRV RR) in the DNS zone of the site system server that hosts the management point. Ensure that you have a corresponding host entry for the site system server. Consider publishing to DNS 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.

  • Clients are on workgroup computers, and they are not configured for Internet-only client management.

ImportantImportant
Publishing service location records for management points in DNS is applicable only to management points that accept client connections from the intranet.

For clients on the intranet to find a management point in DNS, at least one site in the Configuration Manager hierarchy must be configured to publish to DNS. If clients reside in an Active Directory domain that does not have a management point published to DNS, you must configure a client property that specifies the domain suffix of a published management point. If you do not specify a domain suffix, the client’s domain is automatically searched.

After clients find a management point in DNS, this management point can inform the client about other management points in the Configuration Manager hierarchy. This means that the management point published in DNS does not have to be from the client’s Configuration Manager site for the client to successfully find a management point to download client policy.

When a client locates more than one management that is published to DNS, the client selects the first management point that matches its own communication setting for HTTPS or HTTP. A client that can use HTTPS always selects a management point that is configured for HTTPS if one is available.

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.

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.

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

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.

    noteNote
    If the management point accepts HTTP and HTTPS client connections, you must create two SRV records. In one record, specify the HTTP port number; in the other, specify the HTTPS port number.

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

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

      noteNote
      If the management point accepts HTTP and HTTPS client connections, you must create two SRV records. In one record, specify the HTTP port number; in the other, specify the HTTPS port number.

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

The first management point in the primary site that is configured to accept HTTP client connections and the first management point in the primary site that is configured to accept HTTPS client connections are automatically published to WINS. When other service location mechanisms fail, clients can find an initial management point by checking WINS. When they connect to this management point, they download a list of other management points. This behavior means that clients can indirectly locate all management points from WINS and use them for subsequent connections.

For example, you might prefer clients to use HTTPS when they connect to management points on the intranet, because this configuration provides improved security. You configure all management points but one to accept only HTTPS client connections. The one management point that accepts HTTP client connections is used only when clients first connect to the site.

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.

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.

    WarningWarning
    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:

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

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

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.

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

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.

    noteNote
    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 and how clients find management points, see the Planning for Client Communication in Configuration Manager section in this topic.

    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.

noteNote
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

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

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.

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.

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

The following site system roles in a primary site support client connections from the Internet:

  • Management point

  • Distribution point

  • Fallback status point

  • Software update point (with and without a network load balancing cluster)

  • Application Catalog website point

  • Enrollment proxy point

Secondary sites do not support client connections from the Internet.

All site systems must reside in an Active Directory domain. However, you can install site systems for Internet-based client management in an untrusted forest. This scenario might be appropriate for a perimeter network that requires high security. Although there is no requirement to have a trust between the two forests, when the forest that contains the Internet–based site systems 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.

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

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.

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

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

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.

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

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.

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

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.

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

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

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

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

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

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

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

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

-----
For additional resources, see Information and Support for Configuration Manager.

Tip: Use this query to find online documentation in the TechNet Library for System Center 2012 Configuration Manager. For instructions and examples, see Search the Configuration Manager Documentation Library.
-----
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft