Desktop Deployment

Zero Touch Windows Deployment With SMS

Adam Gordon

At a Glance:

• A look inside the deployment process
• Creating and packaging the installation image
• Installing the image package on target systems
• Details of the OSD package environment

Systems Management Server 2003

OSD Feature Pack

Windows PE

Traditionally, deploying an OS to a computer has entailed dispatching a technician on foot with a boot floppy or CD in hand. Over the years, though, many

solutions have appeared on the market to automate this process through network services, allowing system administrators to launch an OS upgrade or refresh over the network without the need to dispatch a technician.

Two techniques are typically used to support remote OS deployment: image-based deployment and automated script-based Windows® setup. Microsoft® Systems Management Server (SMS) 2003 supports the ability to deploy Windows to computers using the automated script-based setup method, as long as the target computers are SMS-managed clients. This is accomplished by using the standard application package distribution of SMS. which tells the target computer the equivalent of "Hey, PC, run Winnt32.exe."

With the introduction of the SMS Operating System Deployment Feature Pack (OSD) in 2004, Microsoft added support for an image-based OS deployment technique. OSD works its magic by adding a new OS package object type to SMS, and building new infrastructure and functionality around that object.

In this article, I will focus on how OSD works rather than how to use it. I’ll describe the OSD processes, directory structures, and settings files. My goal is to provide you with an understanding of the OSD inner workings, as a means to better understand how to use and troubleshoot OSD-based deployments.

Launching the Image Installation

There are three methods commonly used to start image installation on client computers. The most appropriate method depends on the status of your target computer and the configuration of your network.

Installing from a Boot CD If you boot the computer from the Image Installation CD, Windows PE will launch Osdshell.exe, which initializes Windows PE to run the other OSD programs. This initialization includes installing scripting support and running Startnet.cmd to load the network stack. Osdshell then launches Osdinstallcd.exe with the /CDBOOT parameter. Osdinstallcd.exe references the Ripinfo.ini file to connect to the SMS management point and from there find a local distribution point. If the CD is configured to run a program or script to select an image program and package automatically, it will run that command and continue to the Preinstall Phase. Otherwise, it will first launch Osdinstallwizard.exe to prompt for image installation options, then continue to the Preinstall Phase.

Installing from CD on a Running System When you launch the Image Installation Wizard from the CD on a computer that is already running a local operating system, the Autoplay.inf file on the CD instructs Windows to run Osdinstallcd.exe. That program connects to the SMS infrastructure (using information in Ripinfo.ini) and launches Osdinstallwizard.exe to prompt for instructions about how to install the image. The wizard offers three options: upgrade (refresh) the computer, save the user state from the computer to load onto a new computer, or install as a new computer. Based on your response, the wizard will continue on to the State Capture or Preinstall Phase.

Installing from an SMS Advertisement If you launch the image installation process on an SMS-managed computer through an advertisement, installation begins by running Osdlaunch.exe. interprets the image program instructions from the Smsdeploy.xml file and proceeds with the image installation accordingly with the Validation Phase.

Now let me invoke a variant of the standard don’t hack the registry caveat: do not modify the directory structure and configuration files described in this article. The specifications of these files and directories are subject to change without notice, so leave the modification of this stuff to SMS. At this time there is not a supported means to automate the creation and modification of SMS OS packages, so I can understand the temptation to tweak things directly. Keep in mind that the SMS OSD offers some customization flexibility in the form of custom actions, described in this article. The Microsoft Solution Accelerator for Business Desktop Deployment (BDD) provides an implementation of OSD and custom actions that should minimize your need to automate the creation and modification of SMS OS packages.

Process Overview

A key principle underlying the OSD is that there’s more to image-based deployment than blasting a bunch of disk sectors to a computer over the network. This is particularly true when deploying to computers that are already on desks and out in the field. The OSD defines a set of orchestrated phases for the OS deployment to a managed computer (see Figure 1). The OSD image installer automates stepping a computer through these phases.

Figure 1 Deployment Phases

Obviously, before you can start deploying an OS image, you need an OS image to deploy. This suggests an OS image lifecycle, as described in Figure 2. OSD includes functionality covering three of these OS image lifecycle processes. Image-based operating system deployment techniques start with one or more reference systems. A reference system presents a master image that will be recorded and distributed to target computers. OSD does not include specific features for preparing a reference image apart from issuing the SYSPREP command prior to recording the image during the Image Capture process.

Figure 2** Image Creation and Deployment **

Because OSD does not have specific provisions for preparing a reference image, I won’t spend much space on this process. The BDD Solution Accelerator includes some best practices and tools (including the Computer Imaging System) for building a reference system. For more information on the BDD Solution Accelerator, see the article entitled "A Guide to Pain-Free Desktop Deployment" in this issue of TechNet Magazine, or visit the BDD Web site.

As Figure 2 illustrates, computer images are cyclical. As new elements of a computer image—core applications, critical OS updates, and so on—are made available, you may want to revise your image to incorporate these upgraded components. My recommendation here is to employ a predictable, repeatable process for building a reference system, so that as you upgrade certain components of an image, other aspects of the image remain the same as the previous image. (See the article by Shelly Bird, "Design More Secure Desktop Deployments," in this issue of TechNet Magazine for further details on this process.) The Computer Imaging System component of the BDD Solution Accelerator provides you with just such a process for building consistent reference systems. The Computer Imaging System also includes facilities for supporting multiple makes and models of target computers with a single image recorded from a reference system.

Packaging and Distribution

Once you have your reference system configured, it is time to record an image of that system. OSD includes the Capture CD Wizard to perform this process. Because you cannot accurately capture an OS image when that OS is active and running, the OSD Capture CD Wizard runs from a bootable CD. This allows you to run the reference system using the CD-based Windows Preinstallation Environment (Windows PE), so that the operating system on the reference system’s hard disk remains inactive during the capture process. In addition to the Capture CD Wizard process, SMS also provides the functionality to create the Capture CD Wizard disc.

As mentioned earlier, OSD builds quite a bit of functionality on top of the image itself. This includes instructions for deployment validation and user state transfer. In the process of packaging an image, you can define this functionality, which is wrapped around the basic hard disk image. In SMS and OSD, this is accomplished during the process of creating an OS package, when the image file is imported into a package directory structure with additional content that is used to drive the deployment process.

With the image packaged and distributed throughout the SMS infrastructure, it is now ready for deployment to target computers. An OS package can be targeted to existing SMS clients through the use of SMS advertisements. Administrators can also create an Image Installation CD that can be used for deployment to new computer systems. The image installation wizard can also be used in conjunction with Remote Installation Services (RIS) to deploy the image to new computers through a Pre-Boot Execution Environment (PXE) network startup.

Components and Tasks

The capabilities of OSD are built around the OS package. An OS package envelops an OS image with additional components, such as a Windows PE image that will be used to boot the target computer as it installs the new image. Each OS package is defined as both an object in the SMS database and a file structure on an SMS site server.

You can view the overall OSD system as a collection of components connected by tasks or processes. Figure 3 provides an overview of these components and tasks. The green rectangles represent components managed through the SMS OSD, such as the OS package. The orange rectangles describe components that are not managed directly by OSD, but are integral to the overall OS deployment process. Most notable among these is the reference system from which an OS image is captured. The blue ovals are the tasks supported by OSD. These tasks link the various components in the overall OSD system.

Figure 3** OSD Components and Tasks **

Let us take a closer look at the components and processes that comprise OSD, starting with the SMS OSD source directory. These processes correspond with the tasks listed in the SMS console’s context menu when you right-click on the Image Packages node or an operating system package node.

During the installation of OSD, the installer creates an OSD directory under the site server’s SMS directory. This directory provides a source location for files that will be used to create an OS package directory, as well as Image Capture and Image Installation CDs. Most of the files in this directory are OSD client utilities that are used to drive the Image Capture and installation processes.

In addition, the OSD directory contains a file named OSDWinPE.wim. This is an image file for the Windows PE operating system. The Windows PE operating system image contained within OSDWinPE.wim is used to boot a PC during the image installation and capture processes. Windows Imaging Format (WIM), by the way, is a new disk image format from Microsoft that’s expected to be part of the upcoming Windows Vista™ operating system. For more information about WIM and its associated XImage tool, check out the TechNet article, "XImage and WIM Image Format". Note that the XImage tool discussed there is not supported for use on OSD-based WIM files.

Image Capture CD

The Image Capture CD is used to boot a reference computer to Windows PE in order to record an image of the hard disk onto a network location. You create an Image Capture CD through the SMS console by right-clicking the Image Packages node and selecting Create Operating System Image Capture CD from the All Tasks menu.

During the CD creation process, the SMS console opens the OSDWinPE.wim file from the OSD source directory. SMS extracts the contents of the WIM file into a temporary directory by using some WIM management DLLs located in the SMS \Bin directory. Next, SMS adds the Image Capture application files from the source directory. If you specified any additional network or storage drivers, these files will be added into the temporary directory as well. Finally, SMS uses the Oscdimg.exe CD premastering utility to create a bootable CD ISO image from the contents of the temporary directory. You can then use a CD burning utility, such as Cdburn.exe from the Windows Resource Kit, to burn the ISO image onto an actual CD.

The Image Capture Wizard has two parts. The first part runs under the reference system’s operating system; the second part runs from Windows PE on the Image Capture CD. To capture an OS image file from a reference system, insert the Image Capture CD while the reference system’s operating system is running. This will invoke the wizard (Osdicw.exe), which then performs some validation checks: it verifies that the reference system is not joined to a domain, and that the SYSPREP tool has been installed on the reference system. The Image Capture Wizard then prompts you for a name for the image and a network share location where the WIM file should be created.

The Image Capture Wizard runs SYSPREP to prepare the reference system for Image Capture. After running SYSPREP, the system will prompt you to restart. At this juncture, you would restart the system and boot from Windows PE on the Image Capture CD. As Windows PE loads, it references a file named Winpeshl.ini in the \Windows\System32 directory. On the Image Capture CD, this file contains the following:

[LaunchApp]
AppPath=%SYSTEMROOT%\system32\osdshell.exe

This instructs Windows PE to load Osdshell.exe as its shell. Osdshell.exe is the run-time wrapper for the OSD processes that boot from CD, including Image Capture and Image Installation. Osdshell.exe initializes the environment for OSD and then references a file named Osdshell.ini (also located in System32). Osdshell.ini contains the following:

[Shell]
Run=OSDICWP.EXE

This directive instructs Osdshell.exe to launch Osdicwp.exe, the Windows PE portion of the Image Capture Wizard. Osdicwp.exe will use the WIM DLLs to capture the hard disk’s image to a WIM file in the network location specified when running the first half of the wizard.

OSD Directory Structure

Once you have captured a WIM image from a reference system, your next step is to incorporate the WIM image file into an image package. This is done by right-clicking on the Image Packages node in the SMS console and selecting Create Operating System Image Package from the New menu. When you issue this command, the New Operating System Image Package Wizard will prompt you for the location of the image file you just created, as well as the target package source directory. The package source entry is so named because it is the source from which SMS distribution points will derive their content for this image package.

As the wizard proceeds through the process of creating the image package, it will create an image package object in the SMS database. The wizard will also populate the Image Package directory in the location specified as the package source.

As with traditional application packages in SMS, you will need to create one or more programs for your image package in order to make use of it. Whereas the image package defines what gets deployed, the image package program defines how it gets deployed. To create a new program, expand the nodes under the icon for your newly created image package. Right-click the Programs icon, then select Operating System Program from the New menu.

The New Operating System Program Wizard prompts you for several details regarding how you want to deploy the image, such as the Windows product key and the domain to join after the image is installed onto the target computer. The wizard then creates a subdirectory for the new program under the package directory, and places the file Smsdeploy.xml in that directory. Smsdeploy.xml stores all of the details about the program. Figure 4 illustrates a portion of an Smsdeploy.xml program description file.

Figure 4 Smsdeploy.xml Excerpt

<?xml version="1.0" encoding="utf-16"?>
<DeploymentInfo>
  <Settings>
    <UserNotification>
      <OrgName>Contoso</OrgName>
      <DetailsFile>osdsample.rtf</DetailsFile>
      <Deadline GMT="true">127530466560880000
      </Deadline>
      <Timeout>15</Timeout>
    </UserNotification>
    <Windows>
      <OrgName Migrate="true">Contoso</OrgName>
      <TimeZone Migrate="true">4</TimeZone>
    </Windows>
    <ProductKey Encrypted="false">A-B-C-D-E
    </ProductKey>
    <Licensing PerConnection="true" 
      ConnectionLimit="5"></Licensing>
    <Network>
      <IPAddress Migrate="true"/>
      <DomainSettings>
        <Domain>CONTOSO</Domain>
        <OU>LDAP://OU=Workstations,
          DC=contoso,DC=com</OU>
      </DomainSettings>
      <UserName>CONTOSO\DEPLOY</UserName>
      <RandomizePassword Randomize="false"/>
      <Reserved1>39E090C...CA339</Reserved1>
      <Reserved2>94122E7...841F1</Reserved2>
      <Reserved3>A895500...62DAF</Reserved3>
    </Network>
    <SMSClient>
      <SMSID Migrate="true"/>
      <Site Migrate="true"></Site>
      <ForcePolicyUpdate>true
      </ForcePolicyUpdate>
    </SMSClient>
    <StateMigration>
      <Location></Location>
      <Reserved1></Reserved1>
      <Reserved2></Reserved2>
      <Reserved3></Reserved3>
    </StateMigration>
  </Settings>
  <DeploymentSequence>
    <Phase Name="Validation">
      <Action>
        <Name>User Notification</Name>
        <CmdLine>OSDUserNotification.exe 
          @127530466560880000 15 "Contoso" 
          "osdsample.rtf" </CmdLine>
        <TimeOut>0</TimeOut>
        <File>OSDUserNotification.exe</File>
        <File>OSDClientUI.exe</File>
        <File>*\OSDClientRes.dll</File>
        <File><![CDATA[osdsample.rtf]]></File>
      </Action>
    </Phase>
...
  </DeploymentSequence>
</DeploymentInfo>

Program Actions

There are two major sections in Smsdeploy.xml: Settings and DeploymentSequence. The DeploymentSequence section demonstrates the real flexibility of the image installation process. The installation process steps through a series of setup phases (outlined in Figure 1). Each phase is defined as a series of actions. Figure 4 shows the configuration of actions that occur within the Validation Phase. OSD includes support for some predefined actions, such as running the User State Migration Tool as part of the State Capture Phase. You can also define your own custom actions for each phase of the image installation process.

When you define a custom action, you specify a command to run as well as any supporting files that are required. For example, suppose you want to run a program named Chkmodel.exe, which is located on Server1. This program will detect the target computer’s model and stop the image installation process if the model tag matches a designated value. You would add a custom action to the Validation Phase with the following attributes:

Name: Check Model
Command Line: CHKMODEL.EXE /MODEL:GX150
Files: \\SERVER1\PROGRAMS\CHKMODEL\CHKMODEL.EXE

This would result in an additional action in the Smsdeploy.xml file as illustrated in Figure 5.

Figure 5 Custom Validation Action

<Phase Name="Validation">
  <Action>
    <Name>User Notification</Name>
    <CmdLine>OSDUserNotification.exe 
      @127530466560880000 15 "Contoso" 
      "osdsample.rtf" </CmdLine>
    <TimeOut>0</TimeOut>
    <File>OSDUserNotification.exe</File>
    <File>OSDClientUI.exe</File>
    <File>*\OSDClientRes.dll</File>
    <File><![CDATA[osdsample.rtf]]></File>
  </Action>

  <Action>
    <Name>Check Model</Name>
    <CmdLine>chkmodel.exe 
      /MODEL:GX150</CmdLine>
    <File>\\server1\programs\chkmodel\chkmodel.exe
    </File>
  </Action>

</Phase>

When OSD adds this custom action to the image program, it copies the files listed for the custom action, Chkmodel.exe from Server1 in this example, to the image package’s directory. Note that it copies the file to the image package directory, not the image program subdirectory. This means that if you have custom actions defined for multiple actions for a particular program or programs, all of those files will be deposited in the same image package directory. Thus it’s important that you are aware of potential file conflicts.

Suppose you upgrade the Chkmodel.exe utility that you used in a custom action in the Validation Phase. You can use the Update Operating System Package Files task to copy the updated Chkmodel.exe from its source directory on Server1 to the image package directory.

When you select the Update Operating System Package Files task, OSD will go back to the source locations for all of the files that were incorporated into the image package and programs. This includes the OSDWinPE.wim and OSD program files from the OSD source directory, the operating system image file, and any files designated for custom actions.

You can use this task to update an operating system image for an existing image package and program. First, update your reference system. Capture the image from the reference system using the Image Capture CD. Designate the same file location and name for the image file. In the SMS administrator console, run the Update Operating System Package Files task for the image package. OSD will copy the updated image file as Os.wim into the image package directory.

Image Installation

To deploy an image package to a desktop that is not currently managed by SMS, you will need to boot that computer with an Image Installation CD (or boot the wizard from RIS). This image installation approach is typically used for new or repurposed computers where there is no user state to be preserved.

Not surprisingly, the process for creating an Image Installation CD is very similar to the process for creating an Image Capture CD. Right-click on the Image Packages node in the SMS console, then select the Create Operating System Image Installation CD task from the All Tasks menu. The wizard will prompt you for the image packages and programs that should be advertised on this CD, as well as the location of any supplementary network and storage drivers that should be added to Windows PE to support your hardware. The wizard also allows you to configure a program or script to run when you launch the Image Installation Wizard from the CD. You can use this program or script to automatically select options for the installation onto a new computer, such as selecting the appropriate image program.

When building the Image Installation CD, OSD will extract the contents of OSDWinPE.wim into a temporary directory, followed by adding the Installation program files and other files from each of the image programs selected for this CD. OSD will also add a file called Ripinfo.ini. This file, derived in part from the Smsdeploy.xml file, contains information that the Image Installation Wizard will use to connect to the SMS management and distribution points.

If you plan to upgrade or reinstall SMS-managed clients on your network with an image package, you will need to distribute the package to nearby SMS distribution points and create an SMS advertisement to target the image package to a collection of computers. These tasks work almost identically to distributing and advertising traditional SMS packages.

When you distribute an image package to an SMS distribution point, SMS replicates the contents of the SMS package directory to a directory under the distribution point’s SMSPKGn$ package share. As with traditional SMS packages, the image package folder on the distribution point is named according to its SMS ID. Keep in mind that when you create an image package in SMS, it shares the same numeric sequence for package IDs as other SMS packages. This ensures that image packages will not conflict with other packages in a distribution point’s package share.

There are three ways to start the OSD image installation process:

• Boot the target computer from the Image Installation CD.
• Run the Image Installation CD on a target computer currently running Windows.
• Advertise an image package and program to an SMS-managed target computer.

Each of these methods is slightly different in the way that they start, but eventually follow the same process. (Take a look at the "Launching the Image Installation" sidebar for more information about these installation startup options.) Figure 6 illustrates the OS image installation phases for these three different methods.

At certain phases of the installation process, the computer will not be running as a domain member or managed SMS agent, such as when you launch the Image Installation Wizard from a new unmanaged computer. In these situations, the computer still needs to connect to SMS to continue the installation process. This is where the Ripinfo.ini file on the Image Installation CD comes into play (see Figure 7).

Figure 7 Ripinfo.ini

[RIPInfo]
Images=1
LocalImage=Yes
WizTitle=XP Image Installer
AllowMachineName=Yes
SiteCode=NSC
ManagementPoint=SERVER1:80
Reserved1=3389FFB40E12AB3...ABC353453FDE34534534534543534534
Reserved2=91185453AAB6191...34535353453C2F83CD4F59614CAEC538
Reserved3=FCFCFC45456456DE7117

[UserCommand]
CommandLine=""\\server1\programs\mydiskformatter.exe"
NetworkShare=\\server1\programs
Reserved1=3389FFB40E12AB3...ABC353453FDE34534534534543534534
Reserved2=91185453AAB6191...34535353453C2F83CD4F59614CAEC538
Reserved3=FCFCFC45456456DE7117

[ImageInfo1]
DisplayName=MyImagePackage—MyImageProgram
PackageID=NSC00012
ProgramName=DeployOS

Figure 6** Installation Process Paths **

In this example, the ManagementPoint value directs the OSD client to the SMS management point. OSD can then communicate with the SMS management point to find the local distribution point. This is important because the SMS server will respond with a distribution point based upon the alignment of the target computer’s IP address with other SMS sites. If your image package is not distributed to the appropriate site, the OSD client will not be able to find it.

As described previously, you have the option of configuring a program or script to run during the New Computer phase. The information to run this command is stored in the [UserCommand] section of the Ripinfo.ini. The ImageInfon section of Ripinfo.ini contains information about each image program and package that you configured to be available when using a particular Image Installation CD. The Reservedn values seen in the [RIPInfo] and [UserCommand] sections store encrypted credentials used by the OSD client to connect with the SMS distribution point and other specified network resources.

During the image installation process, OSD creates a \Minint directory in the root of the client computer’s system drive (typically C:). OSD uses this directory to store data related to the installation process. This data may include an instance of the OSD version of Windows PE if the system is performing an image installation refresh (as opposed to a new computer installation). Log files are stored in the directory \Minint\Smsosd\Osdlogs. If the installation is configured to save user state information locally, this data is stored in \Minint\Smsosd\StateCapture. OSD configuration and state information is stored in \Minint\Smsosd\Osdenv.ini.

The OSD image installation environment provides extensive logging capabilities. Many of the OSD image installation programs discussed here, including Osdinstallcd.exe and Osdlaunch.exe, will produce logs in the \Minint\Smsosd\Osdlogs directory. These can be very helpful in debugging image installation issues.

The WIM imaging technology has the capability to preserve designated directories when it installs a new image onto a computer. In OSD, the WIM toolset is instructed to preserve the \Minint directory when performing an image refresh. Most significantly, this gives the OSD image installation process the ability to store user state locally on the target computer’s hard disk, precluding the need to ship all that user state data to a network share.

The OSD Environment

As the image installation process progresses from phase to phase, the OSD client will retain configuration and state information about the installation process. This information is preserved in \Minint\Smsosd\Osdenv.ini. When an OSD installation phase begins, a program called Osdenv.exe instantiates a COM object and populates that object’s attributes with any existing values in Osdenv.ini. The attributes of the OSD environment object are also accessible through scripts and batch files as Windows environment variables.

If you seek to customize and further automate the image installation process, you can do so by including actions in your program that will set these variables. For example, you could include a custom action to run a post-installation script that dynamically selects the domain and organizational unit a computer should join based on that computer’s IP address.

The BDD Solution Accelerator makes extensive use of these facilities—custom actions and the OSD environment variables—to provide dynamic, data-driven capabilities within the OSD image installation framework. More information on programming with the OSD environment variables is available in the Microsoft Systems Management Server 2003 Operating System Deployment Feature Pack Users Guide (Osd_fp_guide.doc) included with the OSD download.

Conclusion

OSD adds image-based deployment capabilities to SMS. Some of the key capabilities that make deployment easier include deploying an image to a target computer while preserving a portion of the hard disk’s data, preserving system and user state locally, and speeding up the computer refresh process.

You can also control image deployment through an orchestrated series of installation phases. The option to configure specific actions in each phase makes the OSD very flexible and extensible. You also have the ability to target computers using the hardware and software information in the SMS inventory, or to deploy images through CD-based installations.

I discussed some of the details of how OSD accomplishes various image management tasks. My hope is that with this information you will have a deeper understanding of OSD, which will assist you in the planning, implementation, and day-to-day use of OSD to set up and deploy systems.

Image Installation Phase

Now let’s dig into the details of the individual installation phases. The six phases are as follows.

Validation The Validation Phase is used to verify that the target computer is suitable for an image deployment. There are no pre-defined actions for the Validation Phase; however, you can add your own custom actions. This is where you can add safeguards to make sure that image package advertisements are not inadvertently sent to machines not intended for re-imaging.

Some examples of validation checks include determining whether the current target is a server or workstation, looking for a previously distributed fail-safe file or registry setting, or verifying that the target is in the correct location based on its subnet.

If one of your validation custom actions returns a non-zero value, the OSD image installation process will send a failed advertisement status message to the SMS server and terminate. This actually applies to any phases with custom actions.

The Validation Phase is only invoked when you launch the image installation process with an SMS advertisement. The assumption is that if you have walked up to a computer with a CD to image it, that computer is a valid target. But you can also specify a script to run as part of the Image Installation Wizard when you create that CD. You could include a wrapper script that calls your various validation checks.

State Capture The State Capture Phase is intended for capturing system and user state prior to installing the new image. There is a predefined action for capturing user state; it invokes the Microsoft User State Management Tool (USMT). Alternatively, you can create your own custom actions for state capture. This might include your own spin on using the USMT tool, or using other state migration tools.

At the successful conclusion of state capture, OSD will expand the OSDWinPE.wim image for Windows PE into the \Minint directory. It will additionally replace the boot loader files (ntldr and setupldr) to boot the system to this Windows PE instance instead of the current Windows operating system (backup copies will be made and stored in the \Minint\backup directory). OSD then restarts the computer, which effectively transitions it to the Preinstall Phase running under Windows PE.

Preinstall The Preinstall Phase provides an opportunity during the image installation process to make adjustments to the current computer that you might not be able to do while the system is running its local Windows operating system.

One such operation might be to repartition or reformat the disk. However, be aware that in the refresh scenario, particularly when you are storing user state locally, you will not be able to reformat the system drive, as Windows PE is running from this volume. That said, there are third-party tools on the market that provide non-destructive changes to disk geometry.

Install In the Install Phase, OSD prepares the hard disk and installs the new operating system image from the SMS distribution point. There are a few disk preparation outcomes with respect to the current disk configuration of the target computer, as described in Figure A. At the conclusion of the Image Install Phase, OSD will continue to transition to the Postinstall Phase.

Postinstall The target computer is still running Windows PE during the Postinstall Phase. The significance here is that the system has not yet booted to the new operating system where it will begin to run the SYSPREP mini-setup process, including the installation of drivers. As a result, the Postinstall Phase provides an opportunity to inject drivers into the target computer prior to running SYSPREP. You can do so using either a local directory that was staged in the reference system’s image or by connecting to a network share and copying the drivers down to local storage. In either case, you will need to make sure that the OEMPNPDriverPath value in the Sysprep.inf file (or the corresponding registry key located at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\DevicePath if you’re not using SYSPREP) points to the location of these staged drivers on the local hard disk.

At the successful conclusion of this phase, OSD will restart the system. During the Image Capture process which was originally run on the reference machine, the OSDWinlogon.dll file was copied to \Windows\System32 and configured as a Winlogon event handler. This will ensure that when the newly imaged machine boots for the first time, OSD will continue with the State Restore Phase.

State Restore The State Restore Phase begins with processing the mini-setup. When SYSPREP runs as part of the Image Capture process, it configures the system to run a setup process on the next boot. Assuming that the reference system is then imaged, every system to which that reference system’s image is deployed will run this mini-setup process. Tasks managed by mini-setup include installing drivers based on the device enumeration of the target system and joining a designated domain or workgroup.

OSDWinlogon.dll will then be invoked to run any predefined state restore actions. This configuration is reentrant, so that if there is a restart somewhere in the midst of the State Restore Phase, it will resume with the next defined action.

The State Restore actions are typically used to restore the user and system state that was captured during the State Capture Phase. You can also use the State Restore to install applications that are not installed in the image itself. If you plan to do this, you may want to process these installations before other user state restore actions. Otherwise, some application installs may overwrite user settings in the registry or INI files. Each application may behave differently though, so this is something you’ll want to test per application.

One option for installing applications during this phase is to use the predefined Run SWD action. You can use this action to specify an SMS package and program to run. The OSD client will install this package directly without regard to collection or advertisement status. Another option is to use a custom action to install an application from a non-SMS source. At the conclusion of the State Restore Phase, OSDWinlogon.dll will be unregistered and deleted. The system will then be restarted and ready for use.

Adam Gordon is an architect with Microsoft Enterprise Services. He is based in Southern California. Adam focuses on various elements of IT infrastructure, including Microsoft Windows client and server deployment and management, directory services, and messaging.

© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.