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:
What’s New in Configuration Manager
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:
- Does not process data submitted by clients,
except for the Heartbeat Discovery data record.
- Does not accept client assignments.
- Does not support all site system roles.
- Participates in database replication
|
|
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:
- Additional primary sites allow the hierarchy
to support more clients.
- Cannot be tiered below other primary
sites.
- No longer used as a boundary for client agent
settings or security.
- Participates in database replication.
|
|
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:
- SQL Server is required and
SQL Server Express will be installed during site
installation if required.
- A management point and distribution point are
automatically deployed during the site installation.
- Secondary sites can send content distribution
to other secondary sites.
- Participates in database replication.
|
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.
| Server |
Purpose |
More information |
|
Central administration site
|
The recommended location for all administration and reporting
for the hierarchy.
|
- Does not process client data.
- Does not support client assignment.
- Not all site system roles are available.
- Participates in database replication.
|
|
Primary site
|
A required site that manages clients in well connected networks.
All clients are assigned to a primary site.
|
- Additional primary sites provide support for
a higher number of clients.
- Cannot be tiered below other primary
sites.
- Participates in database replication.
|
|
Secondary site
|
Manages clients in remote locations where network bandwidth
control is required.
|
- SQL Server Express or a full instance of
SQL Server is required. If neither is installed when the site
is installed, SQL Server Express is automatically
installed.
- A management point and distribution point are
automatically deployed when the site is installed.
- Secondary sites must be direct child sites
below a primary site, but can be configured to send content to
other secondary sites.
- Participates in database replication.
|
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
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
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:
- Asset Intelligence synchronization point
- Endpoint Protection point
- Windows Intune connector
|
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.
|
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
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
|
- The site runs a site reset and reinstalls all
site system roles at the site. For information about a site reset,
see the Perform a
Site Reset section in the Manage Site and
Hierarchy Configurations topic.
- When you modify client languages at the
top-tier site (central administration site or stand-alone primary
site), the site modifies the client installation package, and
updates this package on each distribution point in the
hierarchy.
- When you modify client languages at a primary
site, the site updates the Client folder on the site server
and on management points in that site.
- The site copies updated files to each
Application Catalog website point and management point, and if you
modify support for mobile device clients, it also updates the files
on the enrollment proxy point.
|
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.
See Also
