Planning for Sites and Hierarchies in Configuration Manager
Updated: May 14, 2015
Applies To: System Center 2012 Configuration Manager, System Center 2012 Configuration Manager SP1, System Center 2012 Configuration Manager SP2, System Center 2012 R2 Configuration Manager, System Center 2012 R2 Configuration Manager SP1
Before you 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.
Tip
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.
Important
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
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
Planning for Client and Server Operating System Languages in Configuration Manager
About Language Packs
Planning for Server Language Packs
Planning for Client Language Packs
Best Practices for Managing Language Packs
Planning for the Configuration Manager Console
- About the Read-Only Console
Planning for Multiple Administrative Users and Global Data Replication in Configuration Manager
About Multiple Edits to Global Data in Configuration Manager
About Data Access From the Configuration Manager Console
What’s New in Configuration Manager
Note
The information in this section also appears in the Getting Started with System Center 2012 Configuration Manager guide.
System Center 2012 Configuration Manager introduces the central administration site and some changes to primary and secondary sites. The following tables summaries these sites and how they compare to sites in Configuration Manager 2007.
Site |
Purpose |
Change from Configuration Manager 2007 |
|---|---|---|
Central administration site |
The central administration site coordinates intersite data replication across the hierarchy by using Configuration Manager database replication. It also enables the administration of hierarchy-wide configurations for client agents, discovery, and other operations. Use this site for all administration and reporting for the hierarchy. |
Although this is the site at the top of the hierarchy in System Center 2012 Configuration Manager, it has the following differences from a central site in Configuration Manager 2007:
|
Primary site |
Manages clients in well connected networks. |
Primary sites in System Center 2012 Configuration Manager have the following differences from primary sites in Configuration Manager 2007:
|
Secondary site |
Controls content distribution for clients in remote locations across links that have limited network bandwidth. |
Secondary sites in System Center 2012 Configuration Manager have the following differences from secondary sites in Configuration Manager 2007:
|
What’s New in Configuration Manager SP1
Note
The information in this section also appears in the Getting Started with System Center 2012 Configuration Manager guide.
Beginning with Configuration Manager SP1 you can expand a stand-alone primary site into a hierarchy that includes a new central administration site. After you install the new central administration site, you can install additional primary sites. For more information, see Expand a Stand-Alone Primary Site into a Hierarchy with a Central Administration Site.
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.
.jpeg "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.
Server |
Purpose |
More information |
|---|---|---|
Central administration site |
The recommended location for all administration and reporting for the hierarchy. |
|
Primary site |
A required site that manages clients in well connected networks. All clients are assigned to a primary site. |
|
Secondary 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 database replication.
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 hierarchy.
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
Install a central administration site if you require multiple primary sites. However, unless you support more clients and devices than a single primary site can support, you can install a stand-alone primary site and reduce your administrative overhead and avoid unnecessary database replication between a primary site and a central administration site. In a stand-alone hierarchy design, a stand-alone primary site provides the same functionality as a central administration site. Prior to Configuration Manager SP1, this was a permanent decision. Beginning with Configuration Manager SP1, you can expand a stand-alone primary site into a hierarchy with a central administration site, and then add additional primary sites. However, System Center 2012 Configuration Manager does not supported the removal of a central administration site from a hierarchy to convert a hierarchy to a stand-alone hierarchy design.
Use a central administration site to configure hierarchy-wide settings and to monitor all sites and objects in the hierarchy. This site type does not manage clients directly but it does coordinate inter-site data replication, which includes the configuration of sites and clients throughout the hierarchy.
Use the following information to help you plan for a central administration site:
The central administration site is the top-level site in a hierarchy.
When you configure a hierarchy that has more than one primary site, you must install a central administration site, and it must be the first site that you install.
The central administration site supports only primary sites as child sites.
The central administration site cannot have clients assigned to it.
The central administration site does not support all site system roles. For more information, see Planning Where to Install Sites System Roles in the Hierarchy.
You can manage all clients in the hierarchy and perform site management tasks for any primary site when you use a Configuration Manager console that is connected to the central administration site.
When you use a central administration site, the central administration site is the only place where you can see site data from all sites. This data includes information such as inventory data and status messages.
You can configure discovery operations throughout the hierarchy from the central administration site by assigning discovery methods to run at individual sites.
You can manage security throughout the hierarchy by assigning different security roles, security scopes, and collections to different administrative users. These configurations apply at each site in the hierarchy.
You can configure file replication and database replication to control communication between sites in the hierarchy. This includes scheduling database replication for site data, and managing the bandwidth for the transfer of file-based data between sites.
Determine Whether to Install a Primary Site
Use primary sites to manage clients. You can install a primary site as a child primary site below a central administration site in a larger hierarchy, or as the first site of a new hierarchy. A primary site that installs as the first site of a hierarchy creates a stand-alone primary site. Both child primary sites and stand-alone primary sites support secondary sites as child sites of the primary site.
Consider installing a primary site for any of the following reasons:
To manage clients directly.
To increase the number of clients and devices you can manage with a single hierarchy. For information about the number of clients and devices each primary site supports, see the Clients per Site section in the Supported Configurations for Configuration Manager topic.
To provide a local point of connectivity for administration.
To meet organizational management requirements. For example, you might install a primary site at a remote location to manage the transfer of deployment content across a low-bandwidth network. However, with System Center 2012 Configuration Manager you can use options to throttle the network bandwidth use when transferring data to a distribution point and this capability can replace the need to install additional sites.
Use the following information to help you plan for primary sites:
A primary site can be a stand-alone primary site or a child primary site in a larger hierarchy. When a primary site is a member of a hierarchy with a central administration site, the sites use database replication to replicate data between the sites. Unless you need to support more clients and devices than a single primary site can support, consider installing a stand-alone primary site. Beginning with Configuration Manager SP1, you can convert a stand-alone primary site into a larger hierarchy when your deployment exceeds the capacity of a single primary site.
A primary site supports only a central administration site as a parent site.
A primary site supports only secondary sites as child sites and can support one or more secondary child sites.
When you use Configuration Manager with no service pack, a primary site cannot change its parent site relationship after installation. However, beginning with Configuration Manager SP1, you can install a new central administration site as a parent site of an existing stand-alone primary site.
Primary sites are responsible for processing all client data from their assigned clients.
When a primary site installs, it automatically configures database replication with its designated central administration site.
Primary sites use database replication to communicate directly to their central administration site.
You can install typically used site system roles when you install a primary site. For a list of site system roles that are supported on primary sites, see Planning Where to Install Sites System Roles in the Hierarchy.
Determine Whether to Install a Secondary Site
Use secondary sites to manage the transfer of deployment content and client data across low-bandwidth networks.
You manage a secondary site from a central administration site or the secondary site’s parent primary site. Secondary sites must be attached to a primary site, and you cannot move them to a different parent site without uninstalling them, and then re-installing them as a child site below the new primary site. You can route content between peer secondary sites to help manage the file-based replication of deployment content. To transfer client data to a primary site, the secondary site uses file-based replication. However, a secondary site also uses database replication to communicate with its parent primary site.
Consider installing a secondary site if any of the following conditions apply:
You do not require a local administrative user for the site.
You have to manage the transfer of deployment content to sites lower in the hierarchy.
You have to manage client information that is sent to sites higher in the hierarchy.
If you do not want to install a secondary site and you have clients in remote locations, consider using Windows BranchCache or distribution points that are enabled for bandwidth control and scheduling. You can use these content management options with or without secondary sites, and they can help you to reduce the number of sites and servers that you have to install. For information about content management options in Configuration Manager, see Determine Whether to Install a Site or Use Content Management Options.
Use the following details to help you plan for secondary sites:
Secondary sites automatically install SQL Server Express during site installation if a local instance of SQL Server is not available.
Secondary site installation is initiated from the Configuration Manager console when it is connected to the central administration site or a primary site.
When a secondary site is installed, it automatically configures database replication with its parent primary site.
Secondary sites use database replication to communicate directly to their parent primary site and to obtain a subset of the shared Configuration Manager database.
Secondary sites support the routing of file-based content to other secondary sites that have a common parent primary site.
Secondary site installations automatically deploy a management point and distribution point that are located on the secondary site server.
Determine Whether to Install a Site or Use Content Management Options
If you have clients in remote network locations, consider using one or more content management options instead of a primary or secondary site. You can often remove the requirement for another site when you use Windows BranchCache, configure distribution points for bandwidth control, or manually copy content to distribution points (prestage content).
Consider deploying a distribution point instead of installing another site if any of the following conditions apply:
Your network bandwidth is sufficient for client computers at the remote location to communicate with a management point to download client policy, and send inventory, reporting status, and discovery information.
Background Intelligent Transfer Service (BITS) does not provide sufficient bandwidth control for your network requirements.
For more information about content management options in Configuration Manager, see Introduction to Content Management in Configuration Manager.
Planning to Expand a Stand-Alone Primary Site
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
A stand-alone primary site must meet the following prerequisites before you can expand it into a hierarchy with a central administration site:
Prerequisite |
Details |
|---|---|
The stand-alone primary site and new central administration site must run the same version of Configuration Manager |
For example, if you use Setup for SP1 to install a central administration site and expand a stand-alone primary site, that stand-alone primary site must also be at SP1. |
The stand-alone primary site cannot be configured to migrate data from another Configuration Manager hierarchy |
You must stop active migration to the stand-alone primary site, from other Configuration Manager hierarchies, and remove all configurations for migration This includes migration jobs that have not completed, and the configuration of the active source hierarchy. This is because migration operations are performed by the top-tier site of the hierarchy, and the configurations for migration do not transfer to the central administration site when you expand a stand-alone primary site. After you expand the stand-alone primary site, if you reconfigure migration at the primary site, it will be the central administration site that performs the migration related operations. For more information about how to configure migration, see Configuring Source Hierarchies and Source Sites for Migration to System Center 2012 Configuration Manager. |
The computer account of the computer that will host the new central administration site must be a member of the Administrators group on the stand-alone primary site |
To successfully expand the stand-alone primary site, the computer account of the new central administration site must be a member of the stand-alone primary sites Administrators group. This is required only during site expansion and the account can be removed from the group on the primary site after site expansion completes. |
The user account that runs setup to install the new central administration site must be granted role-based administration permissions at the stand-alone primary site |
To install a central administration site as part of a site expansion scenario, the user account that runs setup to install the central administration site must be defined in role-based administration at the stand-alone primary site as either a Full Administrator or an Infrastructure Administrator. |
You must uninstall the following site system roles from the stand-alone primary site before you can expand the site:
|
These site system roles are supported only at the top-tier site of the hierarchy. Therefore, you must uninstall these site system roles before you expand the site stand-alone primary site. After you expand the site, you can reinstall these site system roles at the central administration site. All other site system roles can remain installed at the primary site. |
The port for the SQL Server Service Broker must be open between the stand-alone primary site and the computer that will install the central administration site |
To successfully replicate data between a central administration site and a primary site, Configuration Manager requires that a port for use by the SQL Server Service Broker is open between the two sites. When you install a central administration and expand a stand-alone primary site, the prerequisite check does not establish that the port you specify for the SQL Server Service Broker is open on the primary site. |
When the stand-alone primary site is configured for migration, you must stop all active Data Gathering before you expand the site |
If you use migration to migrate data from another Configuration Manager hierarchy, you must stop all active Data Gathering before you expand the site. After the site expansion completes, you can reconfigure Data Gathering. For more information about stopping and reconfiguring data gathering for migration, see the Migration Data Gathering section in the Planning a Source Hierarchy Strategy in System Center 2012 Configuration Manager topic. |
Considerations when Expanding a Stand-Alone Primary Site
When you expand a stand-alone primary site, objects and configurations that exist in the primary site database are shared with the new central administration site. With the following exceptions, there are no special considerations when you expand a stand-alone primary site:
Considerations |
Details |
|---|---|
Software update points |
Prior to expanding a stand-alone primary site, you do not need to make configuration changes for software update points at the site. However, when you expand a stand-alone primary site, software update points at the primary site automatically reconfigure to synchronize with a software update point at the new central administration site. Therefore, after the new central administration site install completes, plan to install a software update point at that site as soon as possible, and configure it to synchronize with Windows Server Update Services (WSUS). Until you configure a software update point at the central administration site, software update points at the primary site will be unable to synchronize new software updates. Immediately after you expand a stand-alone primary site, expect a high level of data processing at the central administration site as that site synchronizes software update information from the primary site. The central administration site automatically creates new objects for software update management. The objects at the central administration site are authoritative for the hierarchy. Pre-existing configurations at the primary site automatically apply at the central administration site. These configurations include synchronization schedules, supersedence configurations, and additional related settings. |
Packages for software deployment |
Packages that were created at the stand-alone primary site before your expand the site, continue to be managed by the primary site. However, these packages replicate as global data to all sites in the hierarchy, and you can manage these packages from the central administration site. The only exception to this is the client installation package. |
Client installation package |
When you expand a stand-alone primary site, ownership of the client installation package transfers to the central administration site. However the package ID for this package remains unchanged. Because the top tier site of a hierarchy manages this package, and modifies the package to support only the client operating system languages that are selected at that site, ensure that the central administration site supports the same client languages that are selected at your primary site. For more information, see Planning for Client Language Packs section in Planning for Sites and Hierarchies in Configuration Manager topic. |
Client settings |
After you expand a primary site, you must restart the SMS_POLICY_PROVIDER component on the primary site. Until you restart the policy provider, the primary site does not provide new or updated client settings to clients, and continues to provide the client settings that were configured at the primary site before the primary site was expanded. To restart the policy provider, use the Configuration Manager Service Manager. To use the Configuration Manager Service Manager to manage a component, select the component in the Component Status node under System Status in the Monitoring workspace of the Configuration Manager console. After you select the component, click Start in the Component group on the Home tab, and then select Configuration Manager Service Manager. In Configuration Manager Service Manager, locate the component you want to manage, and then click Component. Next, click Query, and after you query the status of the component you can manage the status of that component. The policy provider also restarts when the SMS_EXECUTIVE service restarts on the site server, or after the site server computer reboots. |
Support for client languages |
When you expand a stand-alone primary site and install the central administration, plan to add support at the central administration site for the same client languages that the stand-alone primary site supports. Adding support for the same client languages is not a requirement; this is a best practice to ensure that new Configuration Manager clients you install support the client languages you expect. For more information about how to manage languages in Configuration Manager, see Planning for Client and Server Operating System Languages in Configuration Manager section in the Planning for Sites and Hierarchies in Configuration Manager topic. |
Default Boot WIM |
The central administration site creates and deploys a new default boot WIM. This WIM becomes the new default WIM for use in the hierarchy. The boot WIM from the stand-alone primary site remains unmodified, and objects for operating system deployment that are based on this WIM continue to function. |
Important
If you use System Center 2012 R2 Configuration Manager SP1: After you expand a stand-alone primary site that runs System Center 2012 R2 Configuration Manager SP1, run Configmgr2012R2SP1.msi at the new central administration site to enable the R2 capabilities for the hierarchy.
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
Note
The information in this section also appears in the Getting Started with System Center 2012 Configuration Manager guide.
The following items are new or have changed for language support since Configuration Manager 2007:
You no longer install site servers by using source files designed for a specific language. Additionally, you no longer install International Client Packs to support different languages on the client. Instead, you can choose to install only the server and client languages that you want to support.
Available client and server language packs are included with the Configuration Manager installation media in the LanguagePack folder, and updates are available to download with the prerequisite files.
You can add client and server language packs to a site when you install the site, and you can modify the language packs in use after the site installs.
You can install multiple languages at each site, and only need to install the languages that you use:
Each site supports multiple languages for Configuration Manager consoles.
At each site you can install individual client language packs, adding support for only the client languages that you want to support.
When you install support for a language that matches the display language of a computer, Configuration Manager consoles and the client user interface that run on that computer display information in that language.
When you install support for a language that matches the language preference that is in use by the web browser of a computer, connections to web-based information, including the Application Catalog or SQL Server Reporting Services, display in that language.
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 Software Center.
The display preference within a web browser applies to viewing reports and the Application Catalog.
Note
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 time.
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.
Important
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.
Method |
Details |
|---|---|
Repairing |
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 modify the language packs that are supported at the top-tier site of a hierarchy, the site initiates an update of the client installation package on each distribution point in the hierarchy, reinstalls applicable site system roles, and performs a site reset. Additionally, you must reinstall clients before they can use new language packs that you add to their site.
When you add support for client language packs to your central administration site, also add these client language packs to each primary site
When you modify the client language packs at a site, the client installation files that update depend on the site’s location in the hierarchy. When a client installs, it might use the client installation package that is managed by the top-tier site of the hierarchy, or it can fall back to using source files from the management point in the client’s assigned site when it cannot access the client installation package on a distribution point.
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.
Important
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.
Note
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
When you connect a Configuration Manager console to a primary site, there are certain conditions that result in the Configuration Manager console connecting as a read-only console. The read-only console lets you view objects and configuration settings but prevents you from making any changes that could be lost when the primary site completes initialization or is synchronized with the central administration site after replication issues are resolved.
Read-only consoles are established for the following reasons:
You connect to a primary site before it completes the Configuration Manager site installation.
You connect to a primary site that has intersite replication problems.
You connect to a primary site during a site restoration of that site.
You connect to a primary site when that site is initializing global data.
After the primary site is fully initialized, or replication issues between that site and the central administration site are resolved, you must close, and then reconnect the Configuration Manager console to establish a normal session where you can manage objects and configurations.
Note
A Configuration Manager console that connects to an evaluation installation of Configuration Manager after the evaluation period of 180 days ends will connect as a 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.
About Multiple Edits to Global Data in Configuration Manager
Because different administrative users at one or more sites can attempt to manage the same object at the same time, Configuration Manager prevents one administrative user from editing an object if another administrative user in the hierarchy is currently editing the same object. When an object you want to manage is already in use, you have the option to view the object as a read-only instance, or to retry to obtain ownership of the object. If you retry to obtain ownership and the object is no longer in use by another administrative user, you are granted ownership and can edit the object. Do not confuse the read-only status for an object you want to manage with the read-only Configuration Manager console. Unlike the read-only console, this is an object-specific condition that is temporary and based on the individual object’s current availability. This condition is not related to the status of the site to which your Configuration Manager console connects.
Configuration Manager also resolves edits to an object when those edits are made at different sites when one of the sites is unable to replicate data. This scenario might occur if a network link is disconnected. In this scenario, the first edit to an object that replicates to the central administration site takes precedence over a later edit from the primary site that was unable to replicate the data.
About Data Access From the Configuration Manager Console
Use role-based administration to define the objects in the hierarchy that administrative users can see in the Configuration Manager console and the permissions that they have for those objects. Use a combination of security roles, security scopes, and collections to help manage access to data throughout the hierarchy for each administrative user. For more information, see Planning for Security in Configuration Manager.