Before you deploy Configuration Manager 2012 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 where you will deploy them. Plan for each site and identify where to install site system roles in each site.
.gif) Tip |
|---|
| Make sure that your plan considers future server hardware changes in addition to current hardware requirements. |
You can deploy configuration manager as a single standalone primary site, or as multiple sites in a hierarchical relationship. When you plan your initial deployment, consider a design that allows for the future growth your organization might require. Planning for expansion is an important step because the changes in Configuration Manager 2012 from previous versions of the product mean that Configuration Manager can now support more clients with fewer sites.
Use the following sections in this topic to help you to implement a hierarchy design:
- Planning a
Hierarchy of Sites in Configuration Manager 2012
- Planning for
Multiple Administrators and Global Data Replication in
Configuration Manager 2012
What’s New in Configuration Manager 2012
Configuration Manager 2012 introduces the following changes to site types that will influence your hierarchy design:
- The top-level Configuration Manager 2007 site
in a multi-primary site hierarchy was known as a central site. In
Configuration Manager 2012 this is replaced by a new site
type, the central administration site:
- The central administration site is not a
primary site at the top of the hierarchy. Instead, it is a separate
site type for centrally managing the other sites in the hierarchy
and from where you run reports.
- A central administration site supports a
limited selection of site system roles and does not directly
support clients or process client data.
- If you use a central administration site, you
must install it before you install any primary sites that will be
part of the hierarchy under the central administration site.
- The central administration site is not a
primary site at the top of the hierarchy. Instead, it is a separate
site type for centrally managing the other sites in the hierarchy
and from where you run reports.
- Primary sites in Configuration Manager 2007
could be tiered below other primary sites, and were often used to
enable decentralized administration and to define configurations
for client agents or to partition security. In
Configuration Manager 2012, primary sites no longer
provide those functions. Primary sites have the following functions
and characteristics:
- Support for higher number of clients when you
add another primary site.
- Direct support for clients and client data
processing.
- Do not support another primary site as a
child site. Only secondary sites can be a child site of a primary
site.
- At installation, they must be joined to the
central administration site. You cannot later change the parent
site association for a primary site without uninstalling and then
reinstalling the primary site.
- Support for higher number of clients when you
add another primary site.
- Secondary sites in Configuration Manager 2007
were often used to manage the network bandwidth for sending client
data and content to remote locations. In
Configuration Manager 2012, secondary sites are used
mainly to control the upward flow of client data in the hierarchy.
Secondary sites have the following changes in functionality:
- Secondary sites now participate in database
replication with their parent primary site. This requires a
SQL Server Express or SQL Server installation at the
secondary site.
- Each secondary site must be a direct child of
a primary site. This is unchanged from Configuration Manager
2007.
- Secondary sites now support the routing of
file-based content to other secondary sites.
- Secondary sites now participate in database
replication with their parent primary site. This requires a
SQL Server Express or SQL Server installation at the
secondary site.
- Configuration Manager 2012 supports
limited changes to a hierarchy structure after sites install:
- Primary sites cannot change their parent site
relationship and must be configured to be a child of a central
administration site at the time the primary site installs.
- As in Configuration Manager 2007, you cannot
move a secondary site between parent primary sites but must
uninstall and then recreate the secondary site.
- Primary sites cannot change their parent site
relationship and must be configured to be a child of a central
administration site at the time the primary site installs.
Planning a Hierarchy of Sites in Configuration Manager 2012
When you plan for a Configuration Manager 2012 hierarchy, consider your network and computing environment and identify your business requirements. You can then plan to implement Configuration Manager 2012 by using the minimal number of servers and the least amount of administration overhead to meet your organization’s goals.
Configuration Manager 2012 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 earlier versions. To maintain the investment in your current Configuration Manager 2007 infrastructure, you must install Configuration Manager 2012 as a new hierarchy and then migrate Configuration Manager 2007 data and clients to Configuration Manager 2012. This side-by-side implementation provides an opportunity to redesign and simplify your hierarchy by using fewer site servers.
For more information about migration, see Migrating from Configuration Manager 2007 to Configuration Manager 2012.
About Site Types in Configuration Manager 2012
Your Configuration Manager 2012 deployment will consist of either a hierarchy of sites or a standalone site. A hierarchy consists of multiple sites, each with one or more site system servers. A standalone site also consists of one or more site system servers. Site system servers extend the functionality of Configuration Manager, for example you might install a site system at 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, make sure that you review the information about each site type and the alternatives to sites offered by content deployment related site systems.
Use the following table to help you plan the type of sites that you might need in your hierarchy.
| Server | Purpose | More Information |
|---|---|---|
|
Central administration site |
The recommended location for all administration and reporting for the hierarchy. |
|
|
Primary site |
A required site that manages clients in well-connected networks. All clients are assigned to a primary site. |
|
|
Secondary site |
Manages clients in remote locations where network bandwidth control is required. |
|
When you plan a Configuration Manager 2012 hierarchy, consider the following:
- You can schedule and throttle network traffic
when you distribute deployment content to distribution points. This
capability allows you to 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, you should 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 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 need
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 to determine whether to install Configuration Manager 2012 sites and site systems.
Determine Whether to Install a Central Administration Site
Install a central administration site if you will 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 .
- You can manage all clients in the hierarchy and perform site
management tasks for any primary site when you use the
Configuration Manager console that is connected to the 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.
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 directly manage clients.
- To increase the number of clients to manage.
Each primary site can support up to 100,000 clients.
- To reduce the effect of failure from a single
primary site or to load balance support of clients between multiple
servers.
- 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 to plan for primary sites:
- A primary site can be a standalone 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.
- 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 .
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 sites parent primary site. Secondary sites are frequently used in locations that do not have a local administrator. 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 will use file-based replication. However, a secondary site will also use 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 administrator for
the site.
- You need to manage the transfer of deployment
content to sites lower in the hierarchy.
- You need 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 for 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 need to install. For information about content management options in Configuration Manager 2012, see Determine Whether You Should Install a Site or Use Content Deployment 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 installs, 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.
- 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.
- You want to use multicast to deploy operating
systems to computers at the remote location.
- You want to stream virtual applications to
computers at the remote location.
For more information about content management options in Configuration Manager 2012, see Introduction to Content Management in Configuration Manager 2012.
Planning for Multiple Administrators and Global Data Replication in Configuration Manager 2012
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 the Configuration Manager Console in Configuration Manager 2012
Administrative users use the Configuration Manager console to manage the Configuration Manager 2012 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.
You can connect an unlimited 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 will not be able to 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 (your hierarchy has a standalone primary site), you can use the Configuration Manager console to access all the data in your hierarchy.
.gif) 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. |
About Multiple Edits to Global Data in Configuration Manager 2012
Global data is present on all sites in the hierarchy with a subset of that global data on the secondary sites. This creates a separate instance of the object at each site. Administrative users at different sites might 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. Configuration Manager 2012 also provides resolution for edits that are made at different sites if one of the sites is unable to replicate data, which might occur if a network link is down. 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 2012 console and the permissions that they have for those objects. Use a combination of security roles, security scopes, and collections to help manage data access throughout the hierarchy. For more information, see Planning for Security in Configuration Manager 2012.