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.

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. Beginning with SP1, Configuration Manager uses a file replication route. File replication routes and addresses operate the same way, and support the same configurations.

The following sections are written for 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.

File Replication Routes

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

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

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

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

Note

Configuration Manager database replication is configured automatically and does not support configuration of replication groups or replication schedules. However, 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 with Configuration Manager SP1 to configure database replication links between sites, and to configure controls on each site database. These controls can help you control and monitor the network traffic that database replication creates.

Database Replication Links

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

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 with Configuration Manager SP1, this node also appears under the Hierarchy Configuration node in the Administration workspace. You can edit a replication link from either the parent site or the child site of the replication link.

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

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

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

Planning to use Distributed Views

For Configuration Manager SP1 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.

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

Prerequisites and Limitations for Distributed Views

The following are prerequisites and limitations for distributed views:

• Both the central administration site and primary site must run Configuration Manager 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.
  
  

Plan to Schedule Transfers of Site Data on Database Replication Links

For Configuration Manager SP1 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.

Plan for Summarization of Database Replication Traffic

For Configuration Manager SP1 only:

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

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

Plan for Database Replication Thresholds

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

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

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

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

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

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

Site Database Replication Controls

For Configuration Manager SP1 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.

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

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

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.

Note
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
   
   

Planning for Service Location from Management Points

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.

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

Planning for Service Location from Active Directory Domain Services

Planning for Service Location by Using DNS Publishing

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.

Determine Whether to Publish Management Points to DNS

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.
  
  

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

Client Discovery of Management Points from DNS

For clients to find a management point in DNS, you must assign the clients to a specific site instead of using automatic site assignment. Additionally, you must configure a client property that specifies the domain suffix of the management point.

Clients on the intranet use this domain suffix to query DNS for management points for their assigned site. When more than one management point for the site is published to DNS, a 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.

Publish Management Points to DNS

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

• Your DNS servers support service location resource records, by using a version of BIND that is at least 8.1.2.
  
  
• The specified intranet FQDNs for the management points in Configuration Manager have host entries (for example, A records) in DNS.
  
  

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

When your DNS servers support automatic updates, you can configure System Center 2012 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.
  
  

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

To manually publish management points to DNS on Windows Server

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

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

3. Verify that there is a host record (A or 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.
     
     

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

Planning for Service Location by Using WINS

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.

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

1. Computers that have the Configuration Manager SP1 client installed and that are not asleep on the subnet check whether other computers on the subnet are awake. They do this by sending each other a TCP/IP ping command every 5 seconds.
   
   
2. If there is no response from other computers, they are assumed to be asleep. The computers that are awake become manager computers for the subnet.
   
   Because it is possible that a computer might not respond because of a reason other than it is asleep (for example, it is turned off, removed from the network, or the proxy wake-up client setting is no longer applied), the computers are sent a wake-up packet every day at 2 P.M. local time. Computers that do not respond will no longer be assumed to be asleep and will not be woken up by wake-up proxy.
   
   To support wake-up proxy, at least three computers must be awake for each subnet. To achieve this, three computers are non-deterministically chosen to be guardian computers for the subnet. This means that they stay awake, despite any configured power policy to sleep or hibernate after a period of inactivity. Guardian computers honor shutdown or restart commands, for example, as a result of maintenance tasks. If this happens, the remaining guardian computers wake up another computer on the subnet so that the subnet continues to have three guardian computers.
   
   
3. Manager computers ask the network switch to redirect network traffic for the sleeping computers to themselves.
   
   The redirection is achieved by the manager computer broadcasting an Ethernet frame that uses the sleeping computer’s MAC address as the source address. This makes the network switch behave as if the sleeping computer has moved to the same port that the manager computer is on. The manager computer also sends ARP packets for the sleeping computers to keep the entry fresh in the ARP cache. The manager computer will also respond to ARP requests on behalf of the sleeping computer and reply with the MAC address of the sleeping computer.
   
   

   Warning

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

4. When a manager computer sees a new TCP connection request for a sleeping machine and the request is to a port that the sleeping machine was listening on before it went to sleep, the manager computer sends a wake-up packet to the sleeping computer, and then stops redirecting traffic for this computer.
   
   
5. The sleeping computer receives the wake-up packet and wakes up. The sending computer automatically retries the connection and this time, the computer is awake and can respond.
   
   

Wake-up proxy has the following prerequisites and limitations:

Important

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

• The supported clients are Windows 7, Windows 8, Windows Server 2008 R2, Windows Server 2012.
  
  
• Guest operating systems that run on a virtual machine are not supported.
  
  
• Clients must run Configuration Manager SP1 and be enabled for wake-up proxy by using client settings. Although wake-up proxy operation does not depend on hardware inventory, clients do not report the installation of the wake-up proxy service unless they are enabled for hardware inventory and submitted at least one hardware inventory.
  
  
• Network adapters (and possibly the BIOS) must be enabled and configured for wake-up packets. If the network adapter is not configured for wake-up packets or this setting is disabled, Configuration Manager will automatically configure and enable it for a computer when it receives the client setting to enable wake-up proxy.
  
  
• If a computer has more than one network adapter, you cannot configure which adapter to use for wake-up proxy; the choice is non-deterministic. However, the adapter chosen is recorded in the SleepAgent_<DOMAIN>@SYSTEM_0.log file.
  
  
• The network must allow ICMP echo requests (at least within the subnet). You cannot configure the 5 minute interval that is used to send the ICMP ping commands.
  
  
• Communication is unencrypted and unauthenticated, and IPsec is not supported.
  
  
• The following network configurations are not supported:
  
  
  • 802.1X with port authentication
    
    
  • Wireless networks
    
    
  • Network switches that bind MAC addresses to specific ports
    
    
  • IPv6-only networks
    
    
  • DHCP lease durations less than 24 hours
    
    

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

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

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

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

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

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

Important

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

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

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

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

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

Warning

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

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

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

• Client deployment over the Internet, such as client push and software update-based client deployment. Instead, use manual client installation.
  
  
• Automatic site assignment.
  
  
• Network Access Protection (NAP).
  
  
• Wake-on-LAN.
  
  
• Operating system deployment. However, you can deploy task sequences that do not deploy an operating system; for example, task sequences that run scripts and maintenance tasks on clients.
  
  
• Remote control.
  
  
• Out of band management.
  
  
• Software deployment to users unless the Internet-based management point can authenticate the user in Active Directory Domain Services by using Windows authentication (Kerberos or NTLM). This is possible when the Internet-based management point trusts the forest where the user account resides.
  
  

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

Note

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

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.
  
  

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

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

• SSL bridging to SSL:
  
  The recommended configuration when you use proxy web servers for Internet-based client management is SSL bridging to SSL, which uses SSL termination with authentication. Client computers must be authenticated by using computer authentication, and mobile device legacy clients are authenticated by using user authentication. Mobile devices that are enrolled by Configuration Manager do not support SSL bridging.
  
  The benefit of SSL termination at the proxy web server is that packets from the Internet are subject to inspection before they are forwarded to the internal network. The proxy web server authenticates the connection from the client, terminates it, and then opens a new authenticated connection to the Internet-based site systems. When Configuration Manager clients use a proxy web server, the client identity (client GUID) is securely contained in the packet payload so that the management point does not consider the proxy web server to be the client. Bridging is not supported in Configuration Manager with HTTP to HTTPS, or from HTTPS to HTTP.
  
  
• Tunneling:
  
  If your proxy web server cannot support the requirements for SSL bridging, or you want to configure Internet support for mobile devices that are enrolled by Configuration Manager, SSL tunneling is also supported. It is a less secure option because the SSL packets from the Internet are forwarded to the site systems without SSL termination, so they cannot be inspected for malicious content. When you use SSL tunneling, there are no certificate requirements for the proxy web server.
  
  

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.

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

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

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

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

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

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

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

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

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. With Configuration Manager SP1, you can configure the use of network bandwidth for database replication for selected site data.

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

• Controls for File-based Replication: During file-based data transfers, Configuration Manager uses all of the available network bandwidth to send data between sites. You can control this process by configuring the sender at a site to increase or decrease site-to-site sending threads. A sending thread is used to transfer one file at a time. Each additional thread allows additional files to be transferred at the same time, which results in more bandwidth use. To configure the number of threads to use for site-to-site transfers, configure the Maximum concurrent sendings on the Sender tab of the sites properties.
  
  To control file-based data transfers between sites, you can schedule when Configuration Manager can use a file replication route to a specific site. You can control the amount of network bandwidth to use, the size of data blocks, and the frequency for sending the data blocks. Additional configurations can limit data transfers based on the priority of the data type. For each site in the hierarchy, you can set schedules and rate limits for that site to use when transferring data by configuring the properties of the file replication rout to each destination site. Configurations for a file replication route only apply to the data transfers to the destination site specified for that file replication route.
  
  For more information about file replication routes, see the sub-section File Replication Routes in the Planning for Intersite Communications in Configuration Manager section in this topic.
  
  

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

• Controls for Database Replication: 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 and the distribution point must be configured to use BITS. If the client is configured to use BITS, but the distribution point is not, the client uses SMB to transfer the content.

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