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.
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.
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.
With System Center 2012
Configuration Manager SP1, you have two additional options.
First, you can migrate data from one System Center 2012
Configuration Manager SP1 hierarchy into another
System Center 2012 Configuration Manager SP1
hierarchy. Second, you can expand a single
System Center 2012 Configuration Manager SP1
stand-alone primary site into a larger hierarchy when you install a
new central administration site.
For more information about migration, see Migrating Hierarchies in
System Center 2012 Configuration Manager.
For information about expanding a stand-alone primary
site, see the section Planning to
Expand a Stand-Alone Primary Site later in this topic.
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 plan to
install multiple primary sites. 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.
Consider installing a primary site for any of the
following reasons:
- To manage clients directly.
- To increase the number of clients to manage.
Each primary site can support up to 100,000 clients.
- 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.
Use the following information to help you plan for
primary sites:
- A primary site can be a stand-alone primary
site or a member of a hierarchy.
- A primary site only supports a central
administration site as a parent site.
- A primary site only supports secondary sites
as child sites and can support one or more secondary child
sites.
- A primary site cannot change its parent site
relationship after installation. However, with 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 is installed, 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 Configuration Manager SP1 only:
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 SP1 Setup 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.
|
|
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
|
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.
|
|
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 MSI 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
|
An MSI repair action reuses the MSI 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
