Deploy an OS by Using SMS

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.

   Previous  [1]  2  Next