Windows 7 : Zero Touch Installations - Understanding Configuration Manager

11/23/2012 2:50:25 AM
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:
  • Auditing computer hardware and software

  • Measuring software usage

  • Deploying software

  • Auditing machine and software settings

Two other features are of great interest to us:

  • Operating system deployment (OSD)

  • Software update deployment

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.

2007, 2007 R2, 2007 R3, and Licenses

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.


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.


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.


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.


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.

Figure 1. A Configuration Manager site architecture

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:

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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.

  6. 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.

Most View
Galaxy S4 vs iPhone 5 - The One Launched Later Is Not Necessary Better (Part 1)
Slim, Light And Mighty Ultrabooks Supertest (Part 3) : Lenovo IdeaPad U300s, HP Envy 14 Spectre, Lenovo U300s
Samsung Chromeboo - ARM Isn’t Always Slower Than x86
Apple iPad Secrets (Part 2)
What's New In Windows Phone 8 Update 3
Sonance Doi - Degrees Of Invisibility
Fitness Gadget Shootout : Fitness Gadgets (Part 2) - Motorola MOTOACTV, Nike+ Fuelband
Tips And Tricks To Set You Apart From The Tech Crowd (Part 2)
Windows 8 : Managing User Access and Security - Managing Local User Accounts and Groups (part 3)
Cooler Master Blizzard T2 - Bargain Basement Cooling For All
Top 10
Windows Server 2012 : Planning, implementing, and managing Group Policy (part 9) - Configuring WMI filtering
Windows Server 2012 : Planning, implementing, and managing Group Policy (part 8) - Managing GPO links, Configuring security filtering
Windows Server 2012 : Planning, implementing, and managing Group Policy (part 7) - Viewing infrastructure status, Creating GPOs
Windows Server 2012 : Planning, implementing, and managing Group Policy (part 6) - Advanced Audit Policy Configuration
Windows Server 2012 : Planning, implementing, and managing Group Policy (part 5) - User Rights Assignment, Security Options
Windows Server 2012 : Planning, implementing, and managing Group Policy (part 4) - Refreshing Group Policy
Windows Server 2012 : Planning, implementing, and managing Group Policy (part 3) - Configuring a central store, Using Starter GPOs
Windows Server 2012 : Planning, implementing, and managing Group Policy (part 2) - Group Policy and Active Directory design
Windows Server 2012 : Planning, implementing, and managing Group Policy (part 1) - Understanding policies vs. preferences
Windows 8 : Monitoring, optimizing, and troubleshooting system health and performance (part 5) - Monitoring system resources by using Performance Monitor