Computer Imaging System Feature Team Guide

Figure 11 illustrates the primary tasks that are completed during the Developing Phase. These activities consist primarily of completing the base build and then extending it with additional drivers or other components that may be required within the environment.

Figure 11. Developing Phase activities
See full-sized image

On This Page

	Roles and Responsibilities
	Build Process Overview
	Creating the Base Build
	Extending the System
	Capturing the Image
	Deploying the Image: Lite Touch
	Milestone: Image Scope Completed

Roles and Responsibilities

Table 7 defines the focus areas for the different role clusters during the Developing Phase.

Table 7. Roles and Responsibilities During the Developing Phase

Top of page

Build Process Overview

Figure 12 is a high-level view of the build and deployment processes. The build process can be broken down into two major processes: the pre-image process and the post-image process. In between is the deployment process.

Although only a loose relationship exists between the pre-image process and the deployment process, there is a strong relationship between the deployment process and the post-image process.

Figure 12. Pre-image process overview
See full-sized image

The first section—from Start through Pre-imaging process complete—is completed in the lab on a specific, known hardware platform such as a Dell Latitude D600 notebook. At the completion of this phase, the target workstation is left in one of four states, as listed here:

Top of page

Creating the Base Build

Build Process Detailed Flowchart

This section presents flowcharts illustrating the workstation imaging process in detail. Figure 13 illustrates starting the build.

Figure 13. Build process—starting the build
See full-sized image

BuildGui.bat

Figure 14 illustrates BuildGui.bat.

Figure 14. Build process—BuildGui.bat
See full-sized image

Dispatch.cmd

Figure 15 illustrates Dispatch.cmd.

Figure 15. Build process—Dispatch.cmd
See full-sized image

Cleanup.vbs

Figure 16 illustrates Cleanup.vbs.

Figure 16. Build process—Cleanup.vbs
See full-sized image

Post1.bat

Figure 17 illustrates Post1.bat.

Figure 17. Build process—Post1.bat
See full-sized image

Post2.bat

Figure 18 illustrates Post2.bat

Figure 18. Build process—Post2.bat
See full-sized image

Litetouch.bat, USMTLoad.bat, and LOBApps.bat

Figure 19 illustrates Litetouch.bat, USMTLoad.bat, and LOBApps.bat

Figure 19. Build process—Litetouch.bat, USMTLoad.bat and LOBApps.bat
See full-sized image

Post3.bat

Figure 20 illustrates Post3.bat.

Figure 20. Build process—Post3.bat
See full-sized image

Build Process Control

This section describes the files that are used to control the imaging process. It also details information about what user accounts are used, when the system restarts, and how user profiles are affected by the imaging process.

Several scripts control the overall flow of the system from script to script, restart to restart. These scripts in turn call myriad other files that perform the installations and customizations on the workstation:

Reboots, User Accounts, and Profiles

This system executes many system restarts and automatically logs on as required. The entire pre-imaging process is done using the local Administrator account. After Windows has completed the base unattended system, the system restarts and logs in as the local Administrator account. It then executes the BuildGui.bat and Dispatch.cmd files. These files customize Windows and install applications, restarting as necessary based on the application requirements. This work is all done to make the Administrator account’s profile behave according to the requirements for the image.

When mini-setup executes, Windows automatically copies the Administrator’s profile over the default user profile, so that all settings from the Administrator account are used for subsequent user logons as well.

Note   This process requires Windows XP SP2 and the SP2 version of Sysprep, because these versions include necessary fixes for this to work properly. Extra steps are required if you are using Windows XP Service Pack 1.

During the post-imaging process, the system enumerates the new hardware and installs any hardware-specific software such as DVD software, keyboard software, and so on.

The system then cleans up working files on the system, renames the local Administrator account, resets the Administrator password, creates a dummy Administrator account, and presents a system-complete dialog.

Image Files

When the decision point is reached in Cleanup.vbs, the system continues in one of three directions. If you select the menu option to Build the System Now, the system continues processing with Post1.bat. Otherwise, Sysprep is executed. When the Sysprep process is complete, the workstation should shut itself down and turn off. A disk-imaging tool must then be run that can package the hard disk into a file and copy that file to a server share for later use by the deployment process. See the “Capturing the Image” section for details.

Customizing the Image

The image-creation process can be customized in several ways. The three most common methods are customizing actions that should be performed, editing configuration files, and applying branding. This customization is performed to better meet the needs of an organization.

Customizing Actions

The Computer Imaging System comes preconfigured with many commonly performed actions or commands that should be executed as part of the build or deployment process. Each of these can be enabled or disabled, or even deleted. Additional actions can be defined as well, with each action specifying the command to execute, the working directory, and whether a restart is required after executing the command.

Some actions may require additional configuration. For example, you may need to alter the list of languages installed by the MUI actions. (See http://www.microsoft.com/globaldev/reference/winxp/xp-lcid.mspx for a list of supported languages and the associated LCID values required.)

Table 8 describes the preconfigured actions.

Table 8. Image Configuration Actions

Customizing Deployment Scripts

During the deployment process, two main scripts are executed: Post2.bat and Post3.bat. Each of these in turn executes other scripts, described in the Table 9.

Table 9. Image Deployment Scripts

Branding

Some files can be edited to personalize or brand the images created. These files include the following:

Top of page

Extending the System

From time to time, it may be necessary to extend the system beyond the default set of scripts and options supplied. This system was designed from the beginning to be extensible. It provides a framework of folder structures and scripts that can be easily modified to suit the needs of an organization.

You may need to extend the system when any of the following conditions are met:

Adding Operating Systems and Service Packs

The system was designed to host multiple operating systems and multiple service pack releases within each operating system.

For example, in order to extend the system to allow building systems for Windows XP Service Pack 3, you need to add the Service Pack 3 information. To add this service pack, follow these steps:

Updating Flow Control Scripts

There are a few instances within the control scripts when a particular action needs to be taken dynamically at run time based on the operating system or service pack currently being built.

Run-Time System Evaluation (Sys2file)

To accomplish this, a script was created (Unattend\Master $OEM$\$OEM$\$1\Local\Sys2file.vbs) that batch files can use to determine the operating system and service pack currently installed on the system. When this script is run, a series of empty text files is created in the C:\local\sysinfo folder. By testing for the existence of these files, the system can then make run-time execution decisions about which scripts to run or branches to take.

Sys2file.vbs creates the text files in Table 10 based on the operating system currently installed.

Table 10. Run-Time Operating System Description Files

For a system running Windows XP Service Pack 1, the following three files would be created in C:\local\sysinfo:

In addition to enumerating information about the operating system, the Sys2file.vbs script also generates information on the computer manufacturer, model, and certain hardware-specific items such as the presence of DVD, CD-ROM, and CD-RW devices, the version of BIOS installed, as well as the audio and video controller installed.

Scripts Utilizing Run-Time System Evaluation

Several scripts use this run-time evaluation in order to make determinations on which files to execute.

Considerations for Placing Updates

Once you have determined that an update needs to be made to extend the functionality of the system, you must decide where to place the update within the imaging framework. There are a few items to consider when making this decision:

Hardware Updates

When you need to extend the system to provide support for a new hardware device, one of the first things to determine is whether the new update is a driver or an application.

Most true drivers can be installed using Windows Plug and Play support and do not require running an application setup or installation program. A good example of a typical driver is a NIC driver.

Some hardware requires a combination of a driver and an application in order for it to install and run properly. These installations either are not recognized by Windows Plug and Play or are not entirely installed with Plug and Play. The best way to such an application installed is to run the installation program that comes with the application. An example of a hardware application is DVD software, where the driver (Codec) in this case is embedded inside the installation application.

Drivers

Adding a driver into the image is a three-step process of identifying the driver, adding a folder for the files, and adding the folder path to the appropriate files.

Identifying the Driver

Identifying the driver is usually a matter of locating the appropriate file on the hardware vendor’s support Web site and downloading the file onto a test system. To ensure that the correct files have been installed and the component works correctly, it is typically easier to install the driver manually on a system before trying to add it to the image.

Most driver updates are downloaded in the form of a self-extracting executable that, when run, copies the files to a working folder you specify.

In the case of the HP Compaq Business Desktop d530 PC, the SP26991.exe file was downloaded from the Hewlett-Packard Support Web site. The file contains the NIC drivers for the Broadcom gigabit network adapter. The file was run and expanded into a working folder called C:\SWSetup\SP26991, with C:\SWSetup\SP26991\WindowsXP32 containing the actual driver files. The files were then manually installed and tested on the workstation to ensure they worked correctly.

Adding the Driver

Once the driver has been successfully identified and tested, you can copy it into the image process. Drivers are copied into the Unattend\Master $OEM$\$OEM$\$1\Drivers folder. They typically are further delineated by manufacturer and function.

In the case of the NIC driver for the HP d530, a suitable folder may be created at Unattend\Master $OEM$\$OEM$\$1\Drivers\HP\d530\NIC and the files placed into that subfolder. Using this type of structure allows the developer to easily identify the system and component to be managed.

It is not always obvious which files must be included, so some iterative testing may be needed to find the right balance. In the case of the HP d530 NIC driver, the download file used during testing was 50 MB in size because it contained drivers for many different operating systems. By isolating just the drivers needed for Windows XP, the number of needed files was reduced considerably. Minimizing the files used decreases the installation time of the system in the lab because fewer files need to be copied to the local workstation.

One way to gain information about the needed drivers is to install the drivers manually on a system running Windows XP and then look at the Driver Details tab of the Properties page in Device Manager.

Note   If the driver being installed is for a NIC, then Windows PE will also need to be updated. See the Adding NIC Drivers to Windows PE section in this document for more information.

Updating the Build-Specific Configuration Files

The last step is to update the two configuration files used by the system to identify the new Plug and Play path they should use. These two files are

In the [Unattended] section of each of these files is an entry called OemPnPDriversPath. This line needs to be updated with the folder path created in the previous step (for example, \Drivers\HP\d530\NIC). Here is a sample line:

Note: The following code snippet has been displayed in multiple lines only for better readability. This should be entered in a single line.

OemPnPDriversPath="\Drivers\Dell\LatD600\Audio;
\Drivers\Dell\LatD600\Modem;\Drivers\Dell\LatD600\NIC;
\Drivers\LatD600\Pointer;\Drivers\LatD600\Smatcard;
\Drivers\Dell\OptGX270\Audio;\Drivers\Dell\OptGX270\NIC;
\Drivers\Dell\OptGX270\Video;\Drivers\HP\d530\Audio;
\Drivers\HP\d530\NIC;\Drivers\HP\d530\Video;\Drivers\IntelINF"

When Windows reads this OEMPNPDriversPath, it automatically adds the SYSTEMDRIVE variable to each label; hence, \Drivers\HP\d530\NIC becomes C:\Windows\Drivers\HP\d530\NIC.

The folder names specified must be separated by semicolons. It is also a good idea to surround the whole string in quotation marks to allow the system to process long file names correctly.

In Windows XP, the OEMPNPDriversPath has a maximum length of 4,096 characters. This should be long enough for typical installations, but steps such as reducing the folder name sizes may be needed if this limit is reached.

Adding Video and Other Hardware Applications

If the system needs an update that is a hardware-based application, you should add it to the Unattend\Master $OEM$\$OEM$\$1\local\post2.bat file.

Post2.bat is dedicated to installing hardware-specific applications. It leverages the information created by the Sys2file.vbs file to branch to different sections of the batch file and, based on the information provided, to install specific applications. For background information on the Sys2file script, see the “Run-Time System Evaluation (Sys2file)” section in this document.

In this release of the offering, all of the hardware applications to be installed are copied into the Unattend\Master $OEM$\$OEM$\$1 folder under an appropriate vendor folder structure, much like the driver files that were previously presented. This means that all images have the hardware applications for all systems available locally for processing in the post-imaging process of Post2.bat.

This approach involves a trade-off: These files can be quite large, and files are being copied that may not have any applicability to the system being installed.

For example, an HP d530 desktop system that is being reinflated by the Windows mini-setup program has all the hardware applications it needs locally but also has the hardware applications for a Dell Latitude D600 notebook.

This was done for two reasons. The first was to limit the number of image files. By building each image to contain all potentially required files, the overall number of images required is reduced. For example, a Sysprep image for hardware abstraction layer (HAL) type Halacpi contains all the applications for hardware of that type. The second reason was to ensure that the files were not updated outside of the tested lab environment. The developer can certify that only applications that were thoroughly integrated and tested are available in the image.

Alternatively, these applications could be placed on a production server, and the Post2.bat file could map a drive to the server share where these files are located (as is done in the case of supplemental or LOB applications in LobApps.bat). This would allow the image sizes to be considerably smaller and therefore installed more quickly. It would also allow these applications to be updated without needing to re-create the image. The constraint here is the potential opportunity to introduce new applications or new application versions that have not been approved and tested.

Neither approach is perfect. Both have their benefits and limitations, but the system is flexible enough to allow for either option.

As new hardware models are introduced, you can run the Sys2file.vbs file manually on the workstation to get the exact file names it produces based on the hardware in that system.

For example, Table 11 shows the files in C:\local\sysinfo that could be produced by running Sys2file.vbs on a Dell OptiPlex GX270 desktop.

Table 11. Sample Sys2file.vbs Text Files

You can then test for the existence of these files to control which applications the Post2.bat file tries to install.

Any application that is installed should support a silent or scripted installation. An in-depth discussion of applications is beyond the scope of this guide, but the following ideas may help.

Similar to drivers, these applications should be manually installed first to ensure they work properly before you try to automate them.

Most hardware-based applications support some form of silent installation. Review any help or text files that come with the application for specific guidance about command-line installation options.

Try running the application from a command prompt with a -? or /? switch. It often displays the supported command-line switches.

When all else fails, try running the application with a –s switch. It may execute a silent installation.

If the application is being installed by the InstallShield application, you may be able to automate it. Most InstallShield applications have a Setup.iss file in the same folder as the Setup.exe program. The Setup.iss file is an answer file for the application. When you run Setup.exe –s, the application installs using the answers in the Setup.iss file.

For most InstallShield applications, you can create your own Setup.iss file by running Setup.exe –r and then manually installing the application. The answers to the messages are stored at C:\windows\setup.iss. Once the installation is complete, copy the C:\windows\setup.iss file to the folder with the Setup.exe file. Subsequent installations should be run with the defined options by running Setup.exe –s.

If the application is a Microsoft Installer package (.msi file), you typically can do a silent installation by executing MSIExec.exe /I NameofAPP /QN, which tells the application to install silently with no restart when complete.

Windows GUI applications, when launched from a batch file with a silent installation request, immediately return control to the batch file. To avoid this, you can typically run these applications using the START/WAIT shell command. If this does not work, you may need to pause the system for a specified period in seconds to wait for the installation to finish. If this is required, run cscript.exe C:\local\sleep.vbs x, where x is the number of seconds to sleep.

If no other means of automating the application installation can be found, you can attempt to script the application with Scriptit. This solution contains Scriptit in C:\Program Files\BDD Standard 2.5\Lite Touch Deploy\ScriptIt. This is known as a keyboard stuffing utility. Basically, you record the keystrokes necessary to install the application into a file and then play them back when necessary. Almost any application can be installed in this manner, but this can be difficult to set up and should only be considered as a last resort.

Adding Core Applications

Core applications are those applications that are to be installed on all systems regardless of the user or hardware. Office 2003 is a great example of such an application.

Core applications should all be installed by defining actions that are processed during the image build process. When these actions execute, the M drive is mapped back to the build server so that these files can be installed from an appropriate applications folder. Reboots can be performed as required, with the build process continuing after the restart.

For example:

Although it is highly recommended that all core applications be scripted for an automated installation, nothing in this process requires that the applications support silent installation. It is possible to insert simple reminders and pause statements to prompt where certain applications should be installed. When the system reaches this part of the build, it stops; the developer can manually install the application and then respond to the pause prompt and allow the system to continue processing. This is not a recommended approach, but it is possible.

Adding System Hotfixes

Adding system hotfixes into the image is a multistep process:

Types of Images

The Solution Accelerator for BDD supports creating Sysprep images. Sysprep images are a combination of using Sysprep and hard disk imaging. When used together, these tools take a sample workstation, remove the security identifier (SID), and create a single file that contains all of the files and system settings. This is similar to zipping the entire system into a single file. This file can then be copied and redistributed as necessary.

For the Sysprep image, there must be sufficient space on a file server to store the image file created.

Number of Images

The number of images for each type of platform is based primarily on the number of systems with different HALs.

Table 12 contains hardware information for the six platforms used in the Trey Research example.

Table 12. Trey Hardware and HALs

As shown in this table, there are seven different systems, and these systems use three different HALs: the Halacpi.dll, the Halaacpi.dll, and the hal.dll

In this case, a minimum of three images is needed: one for the notebook (D600), one for the Tablet PC (because it has additional core software), and one for the desktops (d530 and GX270) to support all five platforms.

Other factors can affect the number of images required. It is important to test each image on each target system to ensure that all components work as intended.

Some organizations generate even more images by creating departmental or other subdivisions of images. Typically, the differences between these images are the set of core applications that are installed in the image.

There is no correct number of images, but the fewer images an organization creates, the easier they will be to manage and maintain.

Top of page

Capturing the Image

Once an image has been successfully created, it must be captured before it can be deployed. In the standard edition of the Solution Accelerator for BDD, one mechanism is available to accomplish this task: Capture the disk image using third-party imaging tools, such as PowerQuest PQIDeploy, Symantec Ghost, and others. These tools are run after preparing the image using Sysprep, described previously. Various deployment mechanisms are available depending on the product.

Capturing Using PowerQuest PQIDeploy

PowerQuest has created a suite of tools for disk imaging and deployment called the PowerQuest Deploy Toolkit. One of the tools included in this suite is the PQIDeploy application, a 32-bit, fully scriptable executable that can be run from a Windows PE boot disk to create and restore image files.

Note   A demo version of the PowerQuest Deploy Toolkit is included with the Solution Accelerator for BDD. This can be used only for lab purposes; per-PC licenses must be obtained from PowerQuest before using this software for true deployments.

To capture an image with PQIDeploy, start the workstation that was just Sysprep’d using the Windows PE lab CD. When the prompt is displayed to connect to the server, select the Cancel option. This exits the lab application and leaves the system at a Windows PE command prompt window.

Note   The prompt for the server connection takes a time-out after 10 seconds and auto-connects to the server. Alternatively, you can make a custom Windows PE CD that does not call the Connect.vbs script as specified in the Startnet.cmd file on the Windows PE CD.

On the build server, share C:\Program Files\BDD Standard 2.5\Lite Touch Deploy\PQDI as PQDI, and give everyone Write permission. Share C:\Program Files\BDD Standard 2.5\Lite Touch Deploy\Images as Images, and give everyone Write permission. Then, from the workstation’s command prompt, make a connection to a server share where the PQ executables are and where the image should be stored. For example:

Once you are connected to the appropriate shares, the PQ application can be prepared to run. The PQ tool PQIDeploy.exe is a script-driven application. It is run with the syntax pqideploy.exe /cmd=scriptfile /err=errorfile /img=imagefile, where

Refer to the PowerQuest Deployment Toolkit documentation for a complete description of the tool, commands, and processing procedures.

Table 13. PowerQuest Script

Select Drive 1
Select Partition All
Set Description "BDD Standard Image"
STORE WITH COMPRESSION HIGH

To upload the image onto the server in this example, you would execute the command P:Pqideploy.exe /cmd=p:script.txt /err=P:Errors.txt /img=I:SomeBDDimage.Pqi. This would attempt to create the file SomeBDDImage.PQI on drive I. If for any reason the upload was not successful, the file P: errors.txt would contain information about the errors encountered. Once this file has been uploaded, it can be copied to other servers or used in the lab to test the deployment process.

Capturing Using Symantec Ghost32

Symantec also has a suite of imaging tools available as part of the Symantec Ghost Corporate Edition package. Included in the latest version of this package is Ghost32, a 32-bit, fully scriptable executable that can be run from a Windows PE boot disk to create and restore image files.

The procedure for creating an image file with Ghost32 is very similar to that discussed in the previous section. Boot the workstation that was just Sysprep’d using the Windows PE lab CD. When the prompt is displayed to connect to the server, select the Cancel option. This exits the lab application and leaves the system at a Windows PE command prompt window.

Note   The prompt for the server connection takes a time-out after 10 seconds and auto-connects to the server. Alternatively, you can make a custom Windows PE CD that does not call the Connect.vbs script as specified in the Startnet.cmd file on the Windows PE CD.

On the build server, share C:\Program Files\BDD Standard 2.5\Lite Touch Deploy\Ghost as Ghost, and give everyone Write permission. Share C:\Program Files\BDD Standard 2.5\Lite Touch Deploy\Images as Images, and give everyone Write permission. Then, from the workstation’s command prompt, make a connection to a server share where the Ghost32 executables are and where the image should be stored. For example:

Once you are connected to the appropriate shares, the Ghost32 application can be executed. It is run with the syntax ghost32.exe -clone,mode=create,src=1,dst=imagefile –sure, where imagefile is the name of the image file to be created. Refer to the Ghost product documentation for a complete description of the tool, commands, and processing procedures.

To upload the image onto the server in this example, the command to execute would be G:Ghost32.exe –clone,mode=create,src=1,dst=I:SomeBDDimage.gho –sure. This would attempt to create the file SomeBDDImage.gho on drive I. If for any reason the upload was not successful, the file Ghosterr.log written to the current directory would contain information about the errors encountered. Once this file has been uploaded, it can be copied to other servers or used in the lab to test the deployment process.

Top of page

Deploying the Image: Lite Touch

Between the pre-image process and the post-image process is the deployment process (see Figure 21). The Lite Touch Deployment Feature Team Guide describes this process in greater detail; it is described here to show that a tightly coupled relationship exists between the image process and the deployment process.

Figure 21. Deployment process overview
See full-sized image

Post-Image Process

This section occurs either after the image has been deployed and reinflated or when the build is simply continuing on, as in the case when the Build System Now options were chosen in the pre-image process.

Unlike in the first section, where it was known what specific platform the image was running on, at this point the image could be on any hardware platform that supports this image type. For example, the image may have been built in the pre-image phase on a Dell Latitude; but now, in the post-image process, the image may have been redeployed or reinflated onto a HP d530 desktop. The system auto-detects the new system type and installs any hardware-specific software that has been included in the build process, such as DVD software, keyboard applications, and so on.

At this phase, the imaging process and the deployment process converge. During the first customization phase of this post-imaging process (see Figure 22), the system looks for a migration file (Migrate.inf) to assist it with completing the build. The system assumes that it may need to install user-specific applications or restore user files, settings, and preferences from a network location.

Several scenarios impact how the system proceeds. For example:

Several factors determine how the system behaves at this stage. They are described here:

•	If a Sysprep image was installed, but the image is being installed on new hardware, the system stops and prompts for a location and credentials for the migrate.inf file.
•	If a Sysprep image was installed, and this image is being installed on the same hardware that the interview application was run on in the deployment process, then the system finds the migrate.inf file on the local hard disk and continues on without stopping.
•	If the system was told to build the system completely now during the pre-image phase, the system continues without a migrate.inf file. Figure 22. Post-image process overview See full-sized image

The deployment process creates a migration information file (Migrate.inf) that drives the behavior of the post-image process. It determines whether user data files are restored, what user specific applications are installed, and so on.

Most of the processing is done as an account specified in the Migrate.inf file. Here is what happens:

Lite-Touch Deployment Process Flow

Figure 23 and Figure 24 show the flow in the following scripts:

Figure 23 illustrates LobApps.bat.

Figure 23. Deployment process—LobApps.bat
See full-sized image

Figure 24 illustrates USMTLoad1.bat and USMTLoad.bat.

Figure 24. Deployment process—USMTLoad1.bat, and USMTLoad.bat
See full-sized image

Adding Just-in-Time Drivers to Sysprep Images

The imaging process as provided has all the drivers statically installed inside the image so that when the Sysprep mini-setup wizard runs, it has access to all the tested drivers for devices such as audio, video, and network cards.

If desired, an organization can change this functionality so that when Windows PE copies the image file to the target computer, it also downloads the latest set of available drivers and updates the oempnpdriverspath entry in the Sysprep.inf file to reflect the new drivers.

To do this, you need to edit the Boot Disks\WINPE\Deploy\i386\System32\winpeApp.vbs.vbs file and customize the UpdateSysprepInf subroutine. This is the routine that copies the Migrate.inf file to the local workstation and updates the Sysprep.inf file with the end-user-specific updates. Because a network connection already exists to the image storage location, it would be reasonably easy to copy a new set of driver folders to the local disk and then update the oempnpdriverspath entry.

You should give great care and consideration to this approach before you attempt it. It allows for real-time dynamic updating of the image during deployments, and it could possibly circumvent the testing and quality assurance processes of the organization and negatively impact the performance of the workstation.

If, however, strong access controls are placed over the location at which these updated drivers are stored, and a strong testing and change-control process is in place, then this can be a very powerful way to reduce the number of times an image needs to be regenerated to support new drivers.

Similar updates are available for RIS images by editing the files and folder structures of the image directories on the RIS server.

Top of page

Milestone: Image Scope Completed

A fully functional image has been created, and a deployment method can now be tested (see Table 14). This feature team needs to work with the Deployment feature team to ensure that the image can be deployed successfully.

Table 14. Deliverables

In the Developing Phase, the developers have customized and extended the imaging system as necessary to ensure that the images they have produced match the requirements defined in the functional specification.

Top of page

6 of 7