Operating System Deployment Planning
Like
its SMS predecessors, Configuration Manager provides a range of useful
functionality. At each point in its history, though, SMS had a “killer
app” that drove its adoption.
In the early days of SMS
the one thing IT departments wanted was remote control. As remote
control became ubiquitous and eventually built in to Windows, it was no
longer as compelling a reason to deploy SMS. The release of SMS 2003
brought a new killer app that met a critical need facing the IT
community—patch management. Although the need for effective patch
management has become even more critical and the Configuration Manager
feature set supporting it has been improved, it may well be that the
most important new feature of Configuration Manager 2007 is OSD.
Provisioning new
systems to corporate standards is a repetitive chore without suitable
automated tools. Deploying new operating systems with increasingly
demanding hardware requirements and potential application compatibility
issues can be a daunting challenge for IT departments whose resources
are already stretched thin. Microsoft has made a major investment in
Configuration Manager OS deployment. Driving shorter adoption cycles for
new operating systems is undoubtedly a strategic goal for Microsoft, so
this is one part of the product the company is particularly motivated
to get right. Whether or not OSD will prove to be the killer app for
Configuration Manager 2007 remains to be seen, but the product certainly
has some useful and well-thought-out capabilities. Here are some of the
major capabilities of OSD:
Image capture and deployment—
ConfigMgr uses a Windows Image Format file (.WIM) image that can be
applied to a target computer. You can use an existing image, if one is
available, or you can capture an image from a reference computer. A reference computer
is a computer that you configure exactly as you would like to deploy
production machines with the same base hardware configuration.
User state migration—
When you want to provide a new computer to an existing user, the
Windows User State Migration Tool (USMT) can capture the user’s
environment, settings, and data for transfer to the new machine. The
Configuration Manager state migration point receives user state data
from the USMT and stores it for deployment to the target machine.
Task sequences—
A task sequence can encapsulate the entire process of configuring
source computers, capturing and deploying images, migrating user state
and other settings, and running any post-installation tasks such as
deploying ConfigMgr packages to the new machine.
Application Compatibility Toolkit— Although not strictly part of OSD, this ConfigMgr R2 feature makes the planning of a major OS rollout much simpler.
This section highlights some of the key planning issues around OSD.
You can choose from several options for deploying images and task sequences:
If upgrading
an existing ConfigMgr client computer, you can use ConfigMgr to initiate
the installation from a distribution point.
You can initiate the installation from bootable media configured to connect to the distribution point.
You
can use PXE (Preboot Execution Environment) Boot to initiate the
installation. Most network cards will initiate a PXE Boot request
sequence if an operating system is not already installed. The ConfigMgr
PXE service point is capable of responding to PXE Boot requests and
initiating an installation from a distribution point.
You
can use standalone media containing all the necessary installation
files. This avoids the network traffic generated by installing from a
distribution point, but requires you to build and distribute complete
images, including all drivers and other required files.
If you are replacing a user’s existing machine, you can use a state migration point to transfer user state data.
Tip: Task Sequences Are Not Just for OSD
Task sequences are
not only for OSD deployments. You can advertise a task sequence to
existing clients just as you would a program in a package. To advertise a
task sequence, just right-click the Advertisements node in the
ConfigMgr console and choose Advertise Task Sequence. This launches the
New Advertisement Wizard, which allows you to select the task sequence,
target collection, and specify other advertisement properties.
When preparing your
boot image, you must include all necessary network card and mass storage
drivers. You should inventory additional drivers in your target
environment and add them to the driver catalog you make available on
your distribution points. You may include applications in your OS image,
provided the applications do not contain unique identifiers that cannot
be generalized by Sysprep. You can also install applications separately
from the image as a post-install task. Including applications in your
images can increase the number of images you need to create and
maintain, but can make the installation process faster. OS images are
often 2GB or larger. You should consider your storage requirements when
sizing distribution points.
You should also
consider the bandwidth required to deploy images when planning your
deployment strategy. You may choose to use courier sender to distribute
images between sites on physical media rather than using the network for
this task. You should also consider backing up user data to the network
or using existing backups rather than migrating user data as part of
the user state migration.
ConfigMgr 2007 R2 introduces
multicast capability for OS image deployment. Multicast can greatly
reduce bandwidth consumption when deploying images to multiple machines.
The Application Compatibility Toolkit (App Compat), new in ConfigMgr 2007 R2, helps with two key tasks:
Inventorying applications in your environment and reporting on compatibility with Windows Vista
Providing reports on which devices in your environment are Vista compatible and what driver upgrades may be required
Although
not a replacement for testing applications with your specific build and
environment, App Compat can help to quickly identify the applications
and hardware that are likely to cause problems with your migration.
Planning for Wake On LAN
An increasing number
of organizations are using power management features to reduce energy
consumption by partially or even completely shutting down idle
computers. The Advanced Configuration and Power Interface (ACPI)
specification, which has become the industry standard for PC power
management, defines various “sleep states,” ranging from S0 (On and
fully functional) to S5 (Off and powered down). Wake On LAN can be used
to “wake up” computers in sleep states S1 through S5.
Configuration Manager can
use Wake On LAN to deploy software updates or mandatory advertisements
to client computers connected to the network that are in a sleeping
state. You can use this capability to deploy applications during
off-hours to avoid affecting users, while ensuring critical patch
deployments are not delayed by waiting for computers to power up.
Using Wake On LAN requires the following:
The power supply must support Wake On LAN.
The client network interface cards (NICs) must support the standard magic packet format.
The Basic Input/Output System (BIOS) settings for the NIC must have wake-up packets enabled.
Windows Logo–compliant NICs are required to support the magic packet format.
Tip: About Magic Packets
The magic packet is a
standard wake-up frame that targets a specific network interface. The
packet is a broadcast frame sent by the data link or OSI-2 layer. The
packet enables remote access to a computer that is in a power-saving
state (the computer is powered off, but some power is reserved for the
NIC). When the listening computer receives this packet, it checks the
packet for correct information, then switches on and boots.
The
Configuration Manager 2007 client is required for Wake On LAN
functionality, and Wake On LAN must be deployed at a primary site with
hardware inventory enabled. Limitations to Wake On LAN include the
following:
You can use either unicast packets or subnet-directed broadcasts for Wake On LAN:
Unicast packets, also known as directed packets, are sent to the last-known IP address for the target computer based on hardware inventory.
Subnet-directed
broadcasts are targeted to the last reported subnet of the target
machine. This allows subnet-directed broadcast packets to reach their
target even if the IP address has changed.
To support
subnet-directed Wake On LAN broadcasts, your network infrastructure must
allow IP-directed broadcasts between the site server and client
computers. For security reasons, by default most routers do not allow
subnet-directed broadcasts. Enabling subnet-directed broadcasts can
expose your network to certain types of denial-of-service attacks.
To
prevent attacks, if you choose to use subnet-directed broadcasts you
should use a nondefault port and allow broadcasts only from the site
servers. If you use unicast packets, you need to configure switches to
forward User Datagram Protocol (UDP) packets. Unicast packets also may
not work with all sleep states on some network adapters.
Out of Band (OOB) Management Planning
One
of the most exciting developments in desktop technology in recent years
is Intel’s Advanced Management Technology (AMT), based on the vPro
technology. For many years, server vendors have offered Out of Band
(OOB) Management capability using a dedicated network connection,
network card, and processor. Due to cost, this type of configuration is
generally not practical for desktop systems. Intel’s introduction of
network cards and chipsets supporting AMT, while not providing the
hardware redundancy of the server class solutions, brings the same
manner of management functionality to desktop systems.
OOB Management uses
Windows remote management technology (WS-Management) to connect to the
management controller on a computer. Configuration Manager 2007 SP 1
introduces support for OOB Management capabilities, including the
following:
Remote helpdesk functions—
Using the Out of Band Management console, a separate management console
that ships with SP 1, you can connect to systems and perform functions
such as the following:
Changing the power state of sleeping systems
Watching the boot sequence before the operating system loads
Managing system BIOS settings
Redirecting IDE drives to network locations or other devices
Powering up sleeping systems— This capability enables software distribution, software updates, and OSD.
ConfigMgr updates can be scheduled or done on demand.
AMT provides better security than Wake On LAN, including Kerberos authentication and encryption.
If you are planning
to use OOB Management, your desktop infrastructure and PKI deployment
must meet several requirements to support it. Even if you do not plan to
use this functionality immediately, you may want to plan for it in your
new hardware purchases. Table 1 lists the key dependencies to plan for if you want to use OOB Management.
Table 1. Dependencies for Using OOB Management
| Requirement Type | Details |
|---|
| Client hardware | Intel Centrino or Core Duo vPro chipset. |
| | Intel AMT firmware versions 3.2.1 or later. The Intel translator supports firmware revisions 3.0 and earlier. |
| | A supported network card such as the Intel 82566DM. |
| PKI | OOB Management requires a Microsoft Enterprise Certificate Authority. |
| | Each
AMT managed computer requires an OEM certificate installed in the
management controller memory and a Web Server Certificate. Your computer
supplier can install the OEM certificate, or it can be added manually
to each system. |
| | Configuration Manager can be running in mixed or native mode. Native mode is not required for OOB Management. |
| Configuration Manager setup | A site system must be configured with the Out of Band Service Point role. |
| | An AMT Provisioning and Discovery account must be configured. |
| | Computers supporting OOB Management must be discovered and provisioned. |
Note: About the DASH Standard
The
Distributed Management Task Force (DMTF) has introduced the Desktop and
Mobile Architecture for System Hardware (DASH) standard to bring
standardization to advanced desktop management technology. Intel AMT
3.2.1 is fully DASH compliant and has additional functionality making it
a superset of the DASH specification. Other hardware vendors such as
AMD have also released management technology based on the DASH standard.
It seems likely that in the future Configuration Manager will work with
these technologies as well.
