Microsoft Systems Management Server 2003 (SMS 2003) provides a great way to
deploy software and manage deployments, perform patch management, inventory
software and hardware, and meter software usage on deployed SMS clients. By
itself, though, SMS can't upgrade or deploy an OS—a capability that's
critical for administrators and IT managers who oversee many systems, especially
at physically scattered locations. To address this shortcoming, Microsoft provides
the Operating System Deployment Feature Pack (OSD) for SMS 2003 Service Pack
1 (SP1), which you can download for free at http://www.microsoft.com/smserver/downloads/
2003/osdfp.asp. The OSD is tightly integrated with the core SMS product and
uses SMS collections, advertisements, and distribution points to let you deploy
OSs through your existing SMS infrastructure. Here we'll explore how to use
the OSD to create an OS image, deploy the OS to a brand-new machine, and upgrade
the OS on an existing machine.
Task 1: Capturing an OS Image
The OSD is an image-based solution that uses the SMS infrastructure, specifically
distribution points (i.e., locations to which an SMS package is stored
for client delivery), to bring the OS to SMS clients. Figure
1 provides an overview of the image-capture and OS-installation process.
In the first part of the process, you create an ISO OS image file, then burn
that file to a CD-ROM on which you'll capture the OS image that you want to
deploy on other systems. The OSD uses Windows Imaging Format (WIM), a file-based
imaging format that offers some advantages compared with the older, sector-based
Microsoft imaging formats. (For more information about WIM, see the Web-exclusive
sidebar "A New Image Format," http://www.windowsitpro.com, InstantDoc ID 49498.)
Your first task in deploying an OS by using the OSD is to create the WIM (.wim) file that contains the OS image. After you've downloaded and installed the feature pack, you'll notice that the Microsoft Management Console (MMC) SMS Administrator snap-in has a new tree item, Image Packages. Display the context menu for Image Packages, as Figure 2 shows, and you'll see four options. We'll use two of these options: first, Create Operating System Image Capture CD to create media on which you'll capture the OS image from a reference machine (i.e., the machine whose OS will be "copied" to the other, target machines) and create the WIM file; next, Create Operating System Image Installation CD to install the OS on a new system, based on the captured WIM file.
To create the WIM file, insert the CD-ROM on which you'll place the captured OS image into the prepared reference machine. The reference machine must be running Windows 2000 or later, should have the SMS 2003 SP1 Advanced Client installed, must be a workgroup member, and should have the Sysprep tool installed in the C:\sysprep folder. You should also ensure that patches on the reference system's OS are up-to-date, to reduce the number of fixes that will need to be applied to the target computers after you've deployed the WIM file on them, and optionally install any applications that are common to all machines in your organization. (My personal preference is to keep the image as clean as possible and to not install applications at this time, to avoid having to re-create the image when you upgrade a core application.)
When you create the image-capture CD (and also the image-installation CD), you'll be given the option to include in the image additional SCSI and network drivers that aren't in Windows XP Service Pack 2 (SP2). You'll need to specify these drivers if you're using hardware that doesn't have the additional drivers in XP SP2 to enable communication to the local disks and network.
You'll need to create one image per OS you want to deploy. Additionally, Windows Server 2003, Windows 2003 Enterprise Edition, and XP will each require a separate image for each hardware abstraction layer (HAL) that the OS is used on—for example, one image for Advanced Configuration and Power Interface (ACPI) uniprocessor XP machines and one for ACPI multiprocessor XP machines. If you're using localized language versions of the OS, you'll also need to create a separate image for each version (you might not need to do this if you're using the Multilingual User Interface—MUI— version of an OS). However, you don't have to create separate images for different hardware because the OS detects the unique hardware on which a newly deployed OS is running at the first startup.
Once you've created the image-capture CD ISO file, you must burn it to a CD-ROM by using CD-ROM creation software that supports burning a disk from an ISO image file. After you've created the image-capture CDROM, place the CD in the reference machine. Doing so starts the Image Capture wizard, which asks you to specify a network location where the WIM file will be stored and any additional Sysprep switches. The Image Capture wizard then executes Sysprep and "cleans" the installed SMS Advanced Client by removing the client-specific security certificate (in the same way the CCMDelCert tool works to remove machine-specific SMS information). After Sysprep is finished running, the machine is automatically rebooted; you can't capture the OS while the computer is running because the system's core files are locked.
The image-capture CD-ROM contains not only the wizard to clean the machine but also an OSD-specific bootable Microsoft Windows Preinstallation Environment (Win-PE). The WinPE hosts a special OSD shell that facilitates capturing of the reference machine to a WIM file on the network location you specified in the Image Capture wizard. After the image file has been captured to the WIM file, the machine reboots. Unlike a typical WinPE, the WinPE that's supplied with the OSD has no licensing requirements; it's a locked-down WinPE that has limited functionality, provides no command line (although Microsoft supplies a lab version of the OSD shell that gives some command-line access for troubleshooting purposes), and runs only the OSD graphical shell. As I'll explain shortly, you can "upgrade" the WinPE that OSD uses if you need additional functionality.
Now that you've created a WIM file for one instance of the OS and HAL, what can you do with it? The first task is to create an SMS package, which is essentially the WIM file you created plus the OSD WinPE and installation environment. After you create the package, you can specify different SMS programs for the package (a program is essentially an SMS package-installation method) that will perform various installation functions. For example, one program could configure the target machine to use one product key and to join a domain, whereas another program could configure the target machine to join a workgroup and, after installing the OS, install Microsoft Office 2003 and WinZip. In this way, you could specify hundreds of programs and configurations for a single OS image file. (I discuss how to tailor the OSD for your installation in more detail in the Web-exclusive sidebar "Customizing an OSD Deployment," http://www.windowsitpro.com, InstantDoc ID 49499.)
Task 2: Deploying an OS on a New System
The second part of the OSD process is to create the image-installation CD-ROM.
The usual way to deploy a program in SMS is to advertise it to a collection
of computers that have the SMS client installed. The SMS client then downloads
the package from a distribution point and installs it on the SMS client machine.
However, a brand-new machine isn't in a collection and doesn't have the SMS
client installed, so the new system can't see the advertisement. To deploy an
OS on a brand-new system, you use the OSD's Image Installation CD option to
create an ISO file (which, like the OS image, you must burn to CD-ROM) that
contains a bootable WinPE and the OSD shell. WinPE and the OSD shell will pull
the OS image from a distribution point and install it (among other things) on
the target machine.
When you insert the image-installation CD into the target computer, the machine will boot into the WinPE environment and display a menu of available OSs, as Figure 3 shows. After you select an OS to install, you're prompted for a machine name to specify. After you do so, the physical disk's current content is cleaned (deleted), then the WIM file is pulled from a distribution point and extracted to the target computer's disk. The OSD shell then runs a post-install process, which edits the sysprep.inf file that's part of the original image and replaces it with values that were defined as part of the SMS OSD OS program properties (e.g., product key, domain to join). The target machine then reboots the deployed OS, runs the mini-setup wizard that Sysprep specifies, and is ready to go.
You might find that deploying an OS from the installation CD is cumbersome; you can actually make the process easier by integrating the CD's content with Remote Installation Services (RIS), which basically entails copying the content of the CD to the RIS server. This method enables a new machine to boot to the network via Pre-boot Execution Environment (PXE). Then RIS sends the OSD WinPE to the target machine, and from that point the rest of the process remains the same—for example, the target pulls the actual OS from a distribution point.
The processes I've just described demonstrate the most basic usage of the OSD, which effectively provides only the content and overall configuration of the original reference machine. You can use the OSD to do much more than this; after all, selecting and deploying the OS should be an automated process—and can be, as "Customizing an OSD Deployment" explains.
Task 3: Upgrading an Existing OS
Installing the OS on a fresh system is one thing, but how can you use the OSD
to upgrade an existing OS? When upgrading an OS, the main challenge is to install
the OS while maintaining the user and computer states. The OSD addresses this
challenge by using phases, which let you define or perform custom actions.
When you upgrade an OS on a system, the OSD captures the user's state (i.e., user profiles and documents from the original OS), then restores this information after the new OS is deployed. To perform these user-state actions, the OSD uses User State Migration Tool (USMT) 2.6, which is integrated with the OSD, although you need to download and install USMT 2.6 separately. (You can download USMT 2.6 via a link on the SMS 2003 OSD Feature Pack Web site.) USMT 2.6 captures all profiles on the existing OS and not just the currently logged-on profile. If you don't want to use USMT, you can run another application or script to capture and restore the state.
By default, the OSD saves the user-state information to the local disk in a subfolder of C:\minint. (The minint directory stores other data besides the state data; furthermore, it's the only directory that isn't deleted when the OSD cleans the disk to prepare for the new OS extraction.) You can save the user state to a Universal Naming Convention (UNC) path if you want (which you'd have to do in machine-refresh scenarios—that is, when a user gets a new machine). However, the best practice is to store the state data on the local disk; doing so is much faster than saving and restoring the potentially large state data to a share on the network.
The process of deploying the OS upgrade is the same as delivering any other application via SMS. SMS creates an advertisement and assigns the OS installation program to a collection. (The collection computers must be running the SMS 2003 Advanced Client SP1 to be able to recognize OS programs.) Typically, via SMS you'd offer the new OS to the collection perhaps two weeks before the mandatory install date, so that users can install the OS when it's convenient for them, but enable a data and time for an automatic installation for clients that haven't had the OS installed. In this situation, because SMS contains complete software and hardware inventory data for all the machines you want to target, you can customize the upgrade—for example, upgrade only Windows 2000 systems that are at least Pentium 3 machines with 128MB memory and 10GB C drive partitions. The OS advertisement appears to end users just like any other advertisement; they're prompted that a new program is available and can install it via the standard Add or Remove Programs Control Panel applet.
After the advertisement has run, the SMS OS program executes and displays a countdown screen (you can configure the countdown time value, which is 30 minutes by default), which lets the user install the OS now or postpone the installation. When the user chooses to install the OS, the machine state is captured to the configured location (either C:\minint or a UNC path as described earlier), then the OSD WinPE is installed in C:\minint. OSD replaces the root active partition files ntdetect.com and ntldr with versions that use the C:\minint location instead of the standard Windows installation (the original versions are backed up in C:\minint\backup). The machine then reboots into the now-local OSD WinPE, deletes all files on the disk except those in the minint folder, and downloads the new OS. This is the same process that the OSD uses for a brand-new OS deployment, and you can use the same OS image for both new-install and upgrade scenarios. The only mandatory difference between a new OS install and an upgrade is that a state-restore phase runs after the mini-setup wizard finishes to restore the state data from the minint or UNC location.
A More Powerful SMS 2003
The OSD expands SMS 2003's capabilities to let you create and install OS images
on computers across your organization. The OSD uses existing Windows technologies
that you're probably familiar with, such as Sysprep and USMT, and also gives you an opportunity to adopt Microsoft's latest
imaging format, WIM, which will be the basis for OS imaging in the next generation
of Windows. Most importantly, the OSD lets you install new OSs as well upgrade
existing OS versions through the SMS 2003 application-deployment infrastructure.
|
Solution Snapshot
|