Before you deploy System Center 2012 Configuration Manager in a production environment, plan the design of your sites and site hierarchy. During the planning phase, identify the number and type of sites, and the location where you plan to deploy them. Plan for each site and identify where to install site system roles at each site.
|Ensure that your plan considers future server hardware changes in addition to current hardware requirements.|
You can deploy Configuration Manager as a single stand-alone primary site, or as multiple sites in a hierarchy. When you plan your initial deployment, consider a design that can expand for the future growth that your organization might require. Planning for expansion is an important step because the changes in System Center 2012 Configuration Manager from previous versions of the product mean that Configuration Manager can now support more clients with fewer sites.
|Configuration Manager does not support moving a site server between domains. If you must move a site server, you must uninstall Configuration Manager from the server, move the server to the new domain, and then install a new Configuration Manager site. You cannot successfully restore the original site to a server that has been moved to a new domain.|
Use the following sections in this topic to help you to implement a hierarchy design:
- Planning a
Hierarchy in Configuration Manager
- About Site
Types in Configuration Manager
- Planning to
Expand a Stand-Alone Primary Site
- About Site Types in Configuration Manager
- Planning for Client and Server
Operating System Languages in Configuration Manager
- Planning for
the Configuration Manager Console
- Planning for
Multiple Administrative Users and Global Data Replication in
What’s New in Configuration Manager
What’s New in Configuration Manager SP1
Planning a Hierarchy in Configuration Manager
When you plan for a Configuration Manager hierarchy, consider your network and computing environment and identify your business requirements. You can then plan to implement Configuration Manager by using the minimal number of servers and the least amount of administration overhead to meet your organization’s goals.
If you have an existing investment in Configuration Manager 2007, System Center 2012 Configuration Manager provides an in-box solution for automated migration from Configuration Manager 2007. However, it does not support in-place upgrades from earlier versions of Configuration Manager or interoperability with Configuration Manager 2007 with the following two exceptions. The first exception is that during the time that you are actively migrating from Configuration Manager 2007 to System Center 2012 Configuration Manager, you can share Configuration Manager 2007 distribution points with System Center 2012 Configuration Manager making the content on these distribution points accessible to System Center 2012 Configuration Manager clients. The second exception is that you can upgrade Configuration Manager 2007 secondary sites to be System Center 2012 Configuration Manager distribution points.
Therefore, to maintain the investment in your current Configuration Manager 2007 infrastructure, you must install System Center 2012 Configuration Manager as a new hierarchy, and then migrate Configuration Manager 2007 data and clients to System Center 2012 Configuration Manager. This side-by-side implementation provides an opportunity to redesign and simplify your hierarchy by using fewer site servers.
Before you install the first site of a new System Center 2012 Configuration Manager hierarchy, consider your business and network environment requirements and review how new capabilities in Configuration Manager can help you meet these with a reduced amount of infrastructure. When possible, plan to only install a stand-alone primary site for your hierarchy, unless a single site cannot support the number of clients and devices that you manage. The stand-alone primary site hierarchy design avoids the overhead of managing additional sites, and the overhead of database replication between sites. If you must manage more devices than a single site supports, you will need to install a central administration site as your first site, and then install one or more primary child sites. For information about the number of clients a site supports, see the Clients per Site section in the Supported Configurations for Configuration Manager topic.
Some of the capabilities that support a decision to install a single primary site in place of multiple primary sites are new in System Center 2012 Configuration Manager. With System Center 2012 Configuration Manager you can manage the use of network bandwidth to transfer content to remote distribution points in a site, similar to how you manage the bandwidth between sites in a hierarchy. This functionality can replace the need to install additional sites to manage content transfers across slower networks, as seen in past versions of Configuration Manager. Additional changes include the use of Client Settings and role-based administration, which remove the need to maintain separate sites for custom client settings or separate sites for security based partitions of access or responsibilities. When all of the changes in System Center 2012 Configuration Manager are understood and considered, the remaining decision point for installing multiple primary sites is often the number of devices and clients your hierarchy must support; not the location of those clients and devices.
Prior to System Center 2012 Configuration Manager SP1, the initial hierarchy design you selected was permanent. Specifically, when you use System Center 2012 Configuration Manager with no service pack, there are no options to convert a stand-alone primary site into a child primary site that reports to a central administration site. Therefore, to change the configuration you would have to uninstall the stand-alone primary site and then install the site again as a child primary site below a central administration site. However, beginning with Configuration Manager SP1, you can expand a stand-alone primary site into a hierarchy that includes a central administration site, and then you can install additional child primary sites. This ability to expand a stand-alone primary site into a larger hierarchy is available to both new sites installed with Configuration Manager SP1 and to sites you upgrade from System Center 2012 Configuration Manager with no service pack. However, Configuration Manager does not support converting a hierarchy that includes a central administration site into a stand-alone primary site. For information about expanding a stand-alone primary site, see the section Planning to Expand a Stand-Alone Primary Site later in this topic.
The capability to expand a stand-alone primary site enables you to deploy Configuration Manager using the minimum server infrastructure, a single stand-alone primary site, with the capability to expand your hierarchy to support more devices at a later date. Additionally, beginning with Configuration Manager SP1, you can migrate data from one System Center 2012 Configuration Manager hierarchy to another Configuration Manager hierarchy when both hierarchies run the same service pack. For example, you could migrate data from one Configuration Manager SP1 site or hierarchy to a different Configuration Manager SP1 site or hierarchy. This means you can migrate data from a test environment to your production environment or migrate data from an acquisition, and then manage the combined environment of users and devices from a single System Center 2012 Configuration Manager hierarchy. For information about Migration, Migrating Hierarchies in System Center 2012 Configuration Manager.
About Site Types in Configuration Manager
Your Configuration Manager deployment consists of either a hierarchy of sites or a stand-alone site. A hierarchy consists of multiple sites, each with one or more site system servers. A stand-alone site also consists of one or more site system servers. The following diagrams show some example site designs.
Site system servers within a site extend the functionality of Configuration Manager. For example, you might install a site system in a site to support software deployment or to manage mobile devices. To successfully plan your hierarchy of sites and identify the best network and geographical locations to place site servers, ensure that you review the information about each site type and the alternatives to sites offered by site systems you use for content deployment.
Use the following table to help you plan the type of sites that you might require in your hierarchy.
Central administration site
The recommended location for all administration and reporting for the hierarchy.
A required site that manages clients in well connected networks. All clients are assigned to a primary site.
Manages clients in remote locations where network bandwidth control is required.
When you plan a Configuration Manager hierarchy, consider the following:
- You can schedule and throttle network traffic
when you distribute deployment content to distribution points.
Therefore, you can use a distribution point instead of a site for
some remote network locations.
- Discovery data records (DDRs) for unknown
resources transfer by using file-based replication from a primary
site to the central administration site for processing. Because
discovery can create a large number of DDRs, plan where to place
your central administration site and consider at which sites
discovery operations will run to minimize the transfer of DDRs
across low-bandwidth networks. DDRs for known resources are
processed at the first primary site to receive them and do not
transfer by using file-based replication to the central
administration site. Instead, after being processed at the primary
site, the discovery information replicates to other sites by using
- Role-based administration provides a central
administrative security model for the hierarchy, and you do not
have to install sites to provide a security boundary. Instead, use
security scopes, security roles, and collections to define what
administrative users can see and manage in the hierarchy.
- Alerts in the Configuration Manager console
provide state-based information for operations throughout the
Use the following sections to help you determine whether to install Configuration Manager sites and site systems.
Determine Whether to Install a Central Administration Site
Determine Whether to Install a Primary Site
Determine Whether to Install a Secondary Site
Determine Whether to Install a Site or Use Content Management Options
Planning to Expand a Stand-Alone Primary Site
For System Center 2012 Configuration Manager SP1 and System Center 2012 R2 Configuration Manager only:
Beginning with System Center 2012 Configuration Manager SP1, you can install a new central administration site as a parent site of an existing stand-alone primary site. This expands your stand-alone primary site into a larger hierarchy that supports the install of additional new primary sites. You can expand only one pre-existing primary site into the new hierarchy because the database of the new central administration site is based on the database of your stand-alone primary site. After this new central administration site installs, you cannot join or expand additional pre-existing primary sites to this same hierarchy. However, you can install new primary sites as child sites below the central administration site.
To expand a stand-alone primary site into a larger hierarchy, run Configuration Manager Setup from the media for Configuration Manager SP1 (or a later version of Configuration Manager), and install a new central administration site on a new server. During setup you can install the new central administration site as the first site in a new hierarchy or expand an existing stand-alone primary site into a hierarchy. When you expand an existing stand-alone primary site, you must specify the stand-alone primary site server you want to expand. After Setup contacts the site server of the stand-alone primary site, Setup continues normally.
After Setup completes, the primary site becomes a child primary site in a hierarchy with a central administration site, and is no longer a stand-alone primary site.
After you expand a stand-alone primary site into a hierarchy, you cannot then detach the primary site from the hierarchy to restore it to operation as a stand-alone primary site. To remove the primary site from the hierarchy, you must uninstall the primary site.
Prerequisites for Expanding a Stand-Alone Primary Site
Considerations when Expanding a Stand-Alone Primary Site
Planning for Client and Server Operating System Languages in Configuration Manager
System Center 2012 Configuration Manager supports the display of information in multiple languages. By default, the Configuration Manager user interface displays in English although objects that an administrative user creates display in the Configuration Manager console and on the client in the language that is used to create them. In addition, you can install server and client language packs to enable the user interface to display in a language that matches the preferences of the user.
Use the information in the following sections to help you plan for language support by installing language packs. For information about how to manage language packs, see the Manage Language Packs at Configuration Manager Sites section in the Manage Site and Hierarchy Configurations topic.
What’s New in Configuration Manager
About Language Packs
You add support for server and client language packs at the central administration site and at primary sites to enable Configuration Manager to display built-in text in a language that matches the user’s preference. Secondary sites automatically support the same client languages as their parent primary sites. For a list of supported languages, see the Supported Operating System Languages section in the Technical Reference for Language Packs in Configuration Manager topic.
- Use server language packs for the
Configuration Manager console and for site system roles such as the
reporting services point.
- Use client language packs for Configuration
Manager clients and the Application Catalog.
Language packs use the following language preferences to display information:
- The display language of a computer applies to
the Configuration Manager console, client notifications, and
- The display preference within a web browser
applies to viewing reports and the Application Catalog.
|Even when language packs are installed, data created by an administrative user is not affected by using language packs.|
When you run Setup, Configuration Manager copies the available languages from the LanguagePack folder on the Configuration Manager source media to the location that you specify for prerequisite downloads. If the source media is not accessible, Configuration Manager downloads language packs as part of the prerequisite files download. Additionally, any files that are missing or that have updates are also downloaded with the prerequisite files. Then, during Setup, you can select to add one or more of the available server and client language packs to the site.
If you do not install language packs when you install a site server, you can add them later by running Setup on the site server. You must run Setup from the Start menu or by opening Setup.exe from the installation path, and then choose to modify the site’s configuration. When you change the supported languages for a site Configuration Manager takes the following actions:
|Language pack type||Action|
Server language pack
Client language pack
Planning for Server Language Packs
Add support for a server language to a site to enable Configuration Manager consoles and reporting services points to display information in the supported language. You can install multiple server language packs at each site in your hierarchy.
Each server language pack that a site supports is added to the Configuration Manager console installation source files on that site server. Before a Configuration Manager console can display information in a supported language, you must add the language pack to the site and install the Configuration Manager console from source files that include that language.
Reporting services points automatically update to support the display of information in the language packs that you install at a site.
Planning for Client Language Packs
Configuration Manager supports client languages for device clients and mobile device clients:
- When a Configuration Manager client installs
on a device, it adds support for each client language packs that is
included with the client installation files.
- When a Configuration Manager client installs
on a mobile device, it adds support for all languages at the same
You can add support for client languages when you install a site, or by rerunning Setup on the site server computer after a site installs. Before a client can display information in a supported language, you must add support for the language to the client’s site, and install the client from source files that include that language. You must add support for the client language packs before you install the client.
When a site adds support for a client language pack, it updates the client installation files. The set of client installation files that the site updates depends on the site’s location in the hierarchy:
- The top-tier site of a hierarchy manages the
client installation package. This package is automatically
distributed to each distribution point in the hierarchy. By
default, when a client installs, it uses this package for the
client installation source files.
Note The top-tier site can be a central administration site, or a stand-alone primary site.
- Primary sites manage the client upgrade
package and update the supported languages in the Client
folder on the site server and on management points in that site.
Clients use the installation source files from their primary site
when the client installation process cannot access the client
installation package on a distribution point, or when the client
installation command-line property /source is used to
specify the these files.
Tip When you use a central administration site, ensure that a client installs the client language packs you expect by adding support for each language pack to the central administration site and to each primary site.
When you change the supported client languages at a top-tier site, allow time for the client installation package to replicate to distribution points in your hierarchy. You can monitor the redistribution of the package to distribution points by using the Content Status node in the Monitoring workspace of the Configuration Manager console. For more information, see the Monitor Content section in the Operations and Maintenance for Content Management in Configuration Manager topic.
Alternately, you can monitor progress by viewing status messages for the redistribution of the package:
- The client installation package name is
Configuration Manager Client Package.
- Distribution points generate a status message
with Message ID 2330 when the package successfully updates
on that distribution point.
After a new site server installs with support for client language packs, or after an existing site server updates the distribution points with the language pack changes, you can install new clients or reinstall existing clients on computers to add support for supported client language packs.
|Configuration Manager does not support reinstalling the mobile device client without first wiping the mobile device. Therefore, if you plan to support non-English mobile devices, enable support for mobile device client languages before you install the Configuration Manager mobile device client.|
When the Configuration Manager client installs on a new computer, CCMSetup modifies the Windows Installer command line to add support for each language pack that is included with the client installation source files. To update an existing client with new language packs, you must upgrade or reinstall the client.
For example, you can modify the languages supported on a computer when you redeploy the client software by using client push installation or software deployment.
The following table lists the client upgrade and installation methods that are not supported for managing the language pack support for a previously installed client.
A Windows Installer repair action reuses the Windows Installer command line last used to install the client, as stored in the registry of the client computer. This command line will not reference new client language packs.
Automatic client upgrade
This type of upgrade fails because automatic upgrades are based on a change of client version. New language packs do not change the client version.
Software update-based client installation
Software update points rely on a change of client version to install the client. New language packs do not change the client version.
For information about how clients access source files for installation, see How to Install Clients on Windows-Based Computers in Configuration Manager.
For information about client installation properties, see About Client Installation Properties in Configuration Manager
Best Practices for Managing Language Packs
Use the following best practices information to help you use language packs in System Center 2012 Configuration Manager.
Install languages at the time you install a site
When you add support for client language packs to your central administration site, also add these client language packs to each primary site
Planning for the Configuration Manager Console
Administrative users use the Configuration Manager console to manage the Configuration Manager environment. Each Configuration Manager console connects to either a central administration site, or a primary site. After the initial connection is made, the Configuration Manager console can connect to other sites. However, you cannot connect a Configuration Manager console to a secondary site.
To connect to a different site when you use the Configuration Manager console, on the Application Menu, select Connect to a New Site, and then specify the name of the site server. You can also specify a connection to a specific site when you open a new instance of the Configuration Manager console. To do so, you must specify the site server name as part of the command line to open the Configuration Manager console. For example, to connect to a site that runs on Server1, at the command prompt, type %path%\microsoft.configurationmanagement.exe Server1.
Configuration Manager does not limit the number of simultaneous Configuration Manager console connections to a primary site or central administration site. When you connect to the central administration site, you can view and configure data for all sites in the hierarchy. If you have a central administration site but connect the Configuration Manager console directly to a primary site, you can view and manage Configuration Manager data from this connection, but you cannot see data from other primary sites or from the secondary sites of other primary sites. However, if you do not have a central administration site because your hierarchy has a stand-alone primary site, you can use the Configuration Manager console to access all the data in your hierarchy.
|When you manage objects or clients by using a Configuration Manager console that is connected to a child primary site in a hierarchy with other primary sites, the changes you make replicate throughout the hierarchy to other primary sites, even though you cannot see data from those other primary sites.|
|When you connect a Configuration Manager console to an evaluation installation of Configuration Manager, the title bar of the console displays the number of days that remain before the evaluation installation expires. The number of days does not automatically refresh and only updates when you make a new connection to a site. After the evaluation period ends, the Configuration Manager console connects as a read-only console.|
About the Read-Only Console
Planning for Multiple Administrative Users and Global Data Replication in Configuration Manager
Use the following sections to help you plan for multiple administrative users who access objects and configuration settings that are shared between sites. This data is referred to as global data, and it is available throughout the hierarchy.