System Center Configuration
Manager (also known as SCCM or ConfigMgr) is the successor to System
Management Server (SMS). It is Microsoft's systems management solution
for accomplishing the following:
Two other features are of great interest to us:
We're going to take
a few moments now to introduce ConfigMgr to those who have not done
much with it before. After that we'll look at why it is important to
OSD. Then we'll look at installing ConfigMgr and getting it to the point
of being ready for the processes of OSD.
1. Introducing Configuration Manager
As of this
writing, Microsoft System Center Configuration Manager 2007 R2 is the
current release of the product and Configuration Manager 2007 R3 was in
the process of completing its prerelease testing. Also known as SCCM or
ConfigMgr, this product sometimes requires you to run many variations of
a search when researching the product or trying to troubleshoot an
issue. It is the successor to System Management Server (SMS) 2003 R2.
Since SMS, it went through ConfigMgr 2007 (a major release) and was
followed by the minor release of 2007 R2. Service Pack 2 has also been
released and applied to the 2007 and 2007 R2 releases.
|
Each of the releases of
Configuration Manager is a differently licensed product. Each one
requires server licensing for the site servers and for the agent
computers. That means you cannot deploy ConfigMgr 2007 R3 if you have
only purchased ConfigMgr 2007 licenses. You will either need to purchase
Software Assurance with the original license acquisition or purchase
new licenses once again. Consult with a large account reseller (LAR) for
Microsoft licensing to learn more.
|
ConfigMgr is what it says on
the tin: It allows an organization to manage the configuration of
desktops, laptops, servers, and mobile devices. That may include
distributing software, performing updates (including custom ones from
third parties and those you create yourself), auditing hardware and
software, checking how often software is being used, verifying and
implementing security policies, and reporting on all of those
activities. It is one of the biggest and most powerful products that
Microsoft has. OSD was considered to be significantly important when
ConfigMgr 2007 was originally developed. In fact, it is rumored that
over 25 percent of the entire engineering effort was focused on OSD.
Configuration Manager has a number of basic components in the architecture:
Site Server
A site server is used for
managing computers in a site. All managed computers in the site
communicate with the site server to receive instructions.
Database
A SQL database is used for a
primary site. You'll learn about primary sites when we talk about
architecture next. The SQL database can be on a dedicated server or on a
SQL cluster. Normally, however, this is a small database and it can be
kept on the primary site server to keep backup and recovery operations
more manageable. What is best practice? The unfortunate answer is: it
depends. SQL licensing and the desire to cluster the database for fault
tolerance are some factors that will lead you to not placing the SQL
database on the site server.
Site
A site is an
administrator-defined boundary made up of networks. The administrator,
engineer, or consultant who defines the site will take WAN and LAN
traffic into consideration when planning the placement of site servers
and roles.
Site System Role
Each role enables a
feature of ConfigMgr to be deployed. This allows certain things to be
done. For example, a Service Locator Point allows clients that are not
Active Directory members to find a Management point. The management
point provides instructions to the client.
Client
This is the piece of
software that is deployed onto desktops, laptops, and servers that you
wish to manage using ConfigMgr. It is capable of running a number of
task-specific agents, such as hardware auditing or software
distribution.
Collection
A collection is a group
that is used for targeting tasks at clients. The members are either
statically defined by an administrator or are based on some query. For
example, an administrator can have a collection for all computers in a
specific site. Out of the box you will see sample collections such as
the one that contains all Windows XP computers. Tactful use of
collections can make a ConfigMgr administrator's work much easier; for
example, you could have a specific job to audit all Windows XP computers
that meet the criteria of Windows 7 and then automatically use that for
something, as you might well figure out in a little while!
Management Point
This is the site system role that provides instructions to clients in the site.
Distribution Point
Any package that must be delivered to a client will be shared via a distribution point.
PXE Service Point
Preboot Execution
Environment (PXE) allows computers with no operating system to download a
Windows PE client. This site system role enables those machines to
connect to ConfigMgr with a ConfigMgr client for operating system
deployment.
State Migration Point
This site system role
provides a location for the User State Migration Toolkit to temporarily
store any captured user states during the installation of a new
operating system in place of an old one.
Figure 1
includes a possible architecture with many sites in a WAN. This does
get confusing; a physical site is one thing; then you have an Active
Directory site and a ConfigMgr site. Often they are the same thing, but
this architecture will show you that there are more options depending on
interoffice bandwidth, server placement, and how you must deploy
administrator delegation.
Every ConfigMgr architecture
has at least one primary site with one site server. It's a primary site
server because it has a SQL database. This allows administrators to
perform administration that is unique to this site on this server. Any
sites that are below it will inherit the configuration done by
administrators in the root primary site. If the site is quite big, then
site system roles might be deployed onto other servers.
Child sites may be
either primary sites or secondary sites. You'll choose a primary site if
you wish to allow administrators in that site to manage their own site
server and how things work in their site. However, they do inherit
configuration details or instructions from the primary site. Clients in
the child primary site will report to their site server. The child
primary site server will roll up this data to its parent site server.
This allows root primary site administrators to view the status of all
tasks. For example, they may control security updates in the root site
and want to get a report on the update status of the entire enterprise.
Secondary site servers
are there for WAN optimization reasons. They don't allow for custom
deployments to be done on the secondary site server. For this sort of
work, the parent primary site administrators would need to do some role
creation and collection delegation on the parent primary site of the
secondary site. Clients in a secondary site will communicate with local
site system roles. The secondary site server will inherit tasks from the
parent site and feed back the results. This optimizes cross-WAN traffic
for larger offices that don't require much of a local ConfigMgr
administration presence or customization and enables clients to work
well.
It is possible to include
remote locations into a site's boundaries. However, the responsible
engineer should understand the architecture, how to employ the site role
services, and the potential impact on the WAN. One optimization is the
use of the branch distribution point. Normally a client downloads
packages that it must install from a distribution point on a site
server. It then feeds back the results of the installation to the site
server.
Consider this
scenario. Say your retail operation has hundreds of branch offices with
just a few computers, adding up to thousands of computers. Would you
want to deploy a site server into each one to optimize WAN traffic?
There would be a significant cost in hardware, software, complexity, and
administration effort. You certainly could not have them all connect to
a central distribution point on the site server because it would clog
the WAN. For example, a scheduled download and install of Office 2010
could shut down your entire retail outlet network. Instead, a branch
distribution point can be deployed into each branch office. Then,
packages can be replicated once to each office in a controlled manner.
Clients in that office will use the local branch distribution point to
download from. Results from the installation and management instructions
still do communicate between the central site server and the remote
clients across the WAN, but that issue might not be too bad.
Placement of a branch
distribution point usually requires a server, and it is something that
still must be managed in the ConfigMgr architecture. Hundreds of branch
offices means there are hundreds of branch distribution points to
replicate software to every time you create a new package. Windows
Server 2008 R2 and Windows 7 (Ultimate and Enterprise editions) have a
number of "better together" technologies. One of these is BranchCache.
When used with Background Intelligent Transfer Service (BITS) to share
packages from the site server distribution point, remote offices can
optimize how they download the package on an on-demand basis:
BranchCache is enabled on the distribution point and on the Windows 7 Enterprise/Ultimate computers in the branch office.
One
of two architectures is used for BranchCache in the branch office. A
distributed model is used when there are no servers. In this situation,
the first computer to download the package from the distribution point
will share it with the others. If a server is in the office, it can be
used as the sharing point. This arrangement is preferred if Windows
clients are powered off or are mobile on a frequent basis, thus making
their local cache share unavailable and requiring a new cross-WAN
download.
2. Why Use Configuration Manager for OSD?
When ConfigMgr deploys a
client to a computer, the hardware auditing agent is usually enabled.
The agent gathers hardware information about a managed computer. But it
also gathers information such as the software installed and the
operating system information. So the known information about any
computer might include the following:
The computer name
The location
The operating system edition, version, and service pack
The software installed
The amount of memory, the size of the hard disk, and the processor
This is the sort of information
that could be used to tell if a computer could run Windows 7.
Potentially, an administrator could create a ConfigMgr collection and
use that as a target for a job to upgrade the operating system.
Speaking of which, ConfigMgr
does have the ability to deploy operating systems. It uses the same
basic building blocks that you have already learned about when reading
about WSIM, WDS, or MDT. In fact, WDS is used by ConfigMgr behind the
scenes for OSD.
ConfigMgr also has the
concept of task sequences as found in MDT. This feature allows a
scripted set of tasks to be executed in a specific order. For example, a
user state could be captured on a Windows XP computer and saved to
somewhere safe, a new operating system installed, and the user state
restored.
ConfigMgr is primarily used as a
software and update distribution system. The task sequence can include
this functionality. If the computer is targeted with Office 2010, Visio
2010, Adobe Reader, or others, then all of those programs can be
automatically installed and patched by ConfigMgr. The computer can be
completely provisioned by the user by the time they log in. MDT can be
installed and integrated with ConfigMgr to extend its task sequencing.
But why not just use the
free-to-download MDT? It can do a lot of this work. MDT is what is
referred to as a light touch installation (LTI). An administrator still
has to walk to a computer and kick off that installation. ConfigMgr is a
zero touch installation (ZTI). An IT department can deploy a ConfigMgr
site server. Clients can be deployed automatically from the
administrator desktops (using a locally installed ConfigMgr console) to
all computers on the network. An OSD package can be created. Then the
administrator can target all computers to run that package according to a
task sequence and on a scheduled basis. For example, all XP computers
meeting Windows 7 requirements can be rebuilt with Windows 7 at 5:00
p.m. on Friday night. At no point has the administrator or any help desk
engineer visited those XP computers. Success or failure data is sent
back to the site server as the jobs run on the targeted computers. This
is more than you can get with MDT. Hopefully all will go well. However, a
help desk engineer can visit those desktops that do fail to rebuild
correctly. This by-exception visit is much more efficient than the LTI
deployment.
An organization with
hundreds or tens of thousands of computers will see the benefits of
this. A little engineering up front, which is pretty similar to what is
required for MDT, yields a ZTI deployment that will live with the
organization forever. The Windows 7 project will be more efficient.
Future rebuilds or new PC purchases will be easier. ZTI is a long-term
investment too; the project to deploy the replacement for Windows 7 will
also be easier.
Now that we've whetted your appetite, let's look at installing ConfigMgr.
3. Understanding the ZTI Flow
The processes that you will go
through to set up ZTI are long and time consuming. There are a number
of high-level steps that you will go through:
Install Configuration Manager:
It is a lengthy and manual process to get a functional ConfigMgr server
up and running. You can skip this step if the ConfigMgr server is
already installed and healthy.
Prepare and configure boot images:
This step is when the OSD work begins. Drivers are brought into the
control of ConfigMgr and boot images are created for image capture and
OSD operations.
Create and capture a reference image:
A bare-metal machine with no operating system will be booted up on the
network using PXE and configured with Windows 7. The machine is
configured, Sysprep is run, and a reference image is created.
Identify and target machines for rebuilding: A collection or collections of Windows 7-capable machines is created so that Windows 7 deployments can be completed.
Deploy Windows 7:
The Windows 7 reference image is deployed to preexisting computers that
are a part of the Windows 7 deployment collection(s). New machines with
no operating system are booted up using PXE to download the reference
image over the network.
Monitor deployment progress: The progress of the deployment can be tracked using the reports that ConfigMgr provides.
It
is a lot of work, but the effort will be worth it when you see how
powerful and flexible the final solution can be. Most of the work is
reusable.
