WINDOWS 1002000 PROFESSIONAL RESOURCE KIT [Electronic resources] نسخه متنی

Step 3: Customize

When you have created a distribution folder and an answer file, you can start customizing the installation by adding devices, drivers, applications, Help files, support information, and other components of your choice. Depending on what you want to customize, perform either or both of the following tasks:

Add entries in the answer file to provide specific instructions to be carried out by Setup during installation.

Populate the distribution folder by adding to it the files, programs, and applications of your choice. These can include mass storage devices, Plug and Play devices, and applications.

You can customize features and components in Windows 2000 Professional. The examples provided cover the following:

Adding hardware devices, including storage devices, Plug and Play devices, and hardware abstraction layers (HALs).

Setting passwords for local user accounts. you can also force all users or certain users to change their passwords when they log on after an upgrade from Windows 95 or Windows 98.

Setting options for language and multilingual support and key descriptions for other regional options such as language-specific keyboard layouts.

Setting time zones.

Specifying display settings to ensure that setup automatically detects the display resolution on a portable computer.

Specifying file system settings to automatically convert FAT16/FAT 32 file systems to NTFS during installation.

Specifying BIOS settings to force setup to use the computer's BIOS to start the computer.

Using the $$Rename.txt file to automatically convert short file names to long file names.

Adding applications during the GUI-mode phase of Setup (using Cmdlines.txt), when the user logs on for the first time (using [GuiRunOnce]), using batch files, and packaging applications to be used with the Windows Installer Service.

There are a many Windows 2000 Professional features that you can customize after installation, such as wallpaper, screen saver settings, Active Desktop, custom toolbars and taskbars, and new Start and Programs menus options. For more information about post-installation customization, see "Introduction to Configuration and Management" and "Customizing the Desktop" in this book.

Adding Hardware Devices

This section details the steps you take to add hardware devices, including:

Mass storage devices

Plug and Play devices

HALs

For the most up-to-date information about hardware devices with Windows 2000, see the Windows Driver and Hardware Development Web site link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit
/webresources

Mass Storage Devices

In Windows 2000 Professional, Plug and Play installs most hardware devices, which can be loaded later in the setup process. However, mass storage devices, such as hard disks, must be properly installed for full Plug and Play support to be available during the GUI mode of Setup. For this reason, the installation of mass storage devices is handled differently from that of other hardware devices.

NOTE

---

It is not necessary to specify a device if it is already supported by Windows 2000.

To add SCSI devices during text-mode Setup—that is, before full Plug and Play support is available—you must provide a Txtsetup.oem file that describes how Setup needs to install the particular SCSI device. For more information about Txtsetup.oem, see the Microsoft® Windows® 2000 Device Driver Kit.

To install a mass storage device

In the distribution folder, create the Textmode subfolder in the $OEM$ subfolder.

In the Textmode subfolder, copy the following files, which you obtain from the device vendor (replace the word Driver with the appropriate driver name):




Driver.sys

Driver.dll

Driver.inf

Driver.cat

Txtsetup.oem

NOTE

---

You must also copy the driver files to the <PnPdrvrs> location that you specified for the OemPnPDriversPath parameter in the answer file. For example:

$OEM$$1<PnPdrvrs><Storage>

Some drivers, such as SCSI miniport drivers, might not include a DLL file.

In the answer file, create a [MassStorageDrivers] section, and include the driver entries that you want to include. For example, a possible entry in the [MassStorageDrivers] section might be the following:




"Adaptec 2940…" = "OEM"




Information for this section can be obtained from the Txtsetup.oem file, which is provided by the hardware manufacturer.

In the answer file, create an [OEMBootFiles] section, and include a list of the files in the $OEM$Textmode folder. For example, a possible entry to the [OEMBootFiles] section might be the following:




[OEMBootFiles] Driver.sys Driver.dll Driver.inf Txtsetup.oem




Where Driver is the driver name.

In the Txtsetup.oem file, verify that a section named [HardwareIds.Scsi.yyyyy] exists. If it does not, create it following this format:




[HardwareIds.scsi. yyyy] id = "xxxxx" , "yyyyy"




where xxxxx is the device identifier and yyyyy is the device service name. For example, for the Symc810 driver, which has a device ID of PCIVEN_1000&DEV_0001, you create this section:




[HardwareIds.scsi.symc810] id = "PCIVEN_1000&DEV_0001" , "symc810"

Plug and Play device drivers that are not included on the Windows 2000 Professional operating system CD can easily be added by following the steps in this section. This method works for all Plug and Play device drivers. You can also use this method for updating drivers.

To add plug and play devices

In the $OEM$ subfolder of the distribution folder, create a subfolder for any special Plug and Play drivers and their INF files, for example:




$OEM$$1PnPDrvrs




In the answer file, edit the [Unattend] key for Plug and Play, adding the path to the list of Plug and Play search drives, for example:




OEMPnPDriversPath = "PnPDrvrs"

To maintain the folders so that they can accommodate future device drivers, create subfolders for potential device drivers. By dividing the folders into subfolders, you can store device driver files by device type, rather than having all device driver files in one folder. Suggested subfolders types include Audio, Modem, Net, Print, Storage, Video, and Other. An Other folder can give you the flexibility to store new hardware devices that might not be currently known.

If the PnPDrvs folder contains the subfolders Audio, Modem, and Net, the answer file must contain the following line:

OEMPnPDriversPath = "PnPDrvsAudio;PnPDrvsModem;PnPDrvsNet"

NOTE

---

The specified folder is created at the root of the system drive and remains there after setup is complete.

Driver Signatures

If you intend to use any updated drivers, you must first verify that they are properly signed. If they are not, those drivers might not be installed. To verify that drivers are properly signed, contact the vendor.

Driver Signing Policy

In the answer file, the DriverSigningPolicy key in the [Unattended] section specifies how nonsigned drivers are processed during installation.

IMPORTANT

---

Microsoft strongly advises against using DriverSigningPolicy = Ignore unless you have fully tested the device driver in your environment and are sure that it works properly. Using unsigned drivers increases the risk of device driver problems that can effect the performance or stability of your computer.

If you are using DriverSigningPolicy = Ignore and you attempt to install a newer, unsigned copy of a driver that is protected by Windows 2000 Professional, the policy level is automatically updated to Warn.

For more information about driver signing policy, see Unattend.doc in SupportToolsDeploy.cab on the Windows 2000 Professional operating system CD.

Hardware Abstraction Layers

To specify HALs for installation, you must have a Txtsetup.oem file and the HAL files, which the vendor provides. Use the same Txtsetup.oem file if you are installing mass storage device drivers. Only one Txtsetup.oem file can be used, so if you have to install HALs and mass storage device drivers, combine entries into one file.

To use third-party drivers, you must make appropriate changes to the answer file. For more information about answer file parameters and syntax, see Unattend.doc in SupportToolsDeploy.cab on the Windows 2000 Professional operating system CD.

To install a HAL

If you have not already done so, create a Textmode subfolder in the $OEM$ folder.

Copy the files that you receive from the device vendor to the Textmode subfolder.

In the answer file, edit the [Unattend] section for the HAL, adding any drivers that you want to install. For example, type the following:




[Unattend] Computertype = "HALDescription ", OEM




Information for the HALDescription can be obtained from the [Computer] section of the Txtsetup.oem file from the driver provider.

In the answer file, create an [OEMBootFiles] section, and enter the names of the files in the $OEM$Textmode folder.

When upgrading from Windows 95 or Windows 98, you can customize your answer files to set passwords for all local user accounts and to force all users or specific users to change their passwords when they first log on. You can also set passwords for the local Administrator account.

Table 5.12 describes the types of passwords that you can set in an answer file:

Table 5.12 Types of Passwords That Can Be Set in an Answer File

Setting Passwords on All Local Accounts

For Windows 95 or Windows 98 upgrades, you can customize your answer file to set all local account passwords to a default value.

To set passwords on all local accounts

In your answer file, add the following entry in the [win9xupg] section:




[Win9xUpg] DefaultPassword = "password"




where password is the default password you want to set for all local users.

NOTE

---

If a local account must be created for a user without a UserPassword entry and no DefaultPassword is specified, Setup creates a random password. After the first restart, the user is prompted to enter a password.

Forcing All Users to Change Local Account Passwords When Upgrading from Windows 95 or Windows 98

For upgrades from Windows 95 or Windows 98, you can customize your answer file to require all users to change their passwords on their local accounts when they log on for the first time. When a user logs on for the first time, he or she is notified that his or her current password has expired and that a new one must be supplied.

To force users to change their password after an upgrade from Windows 95 or Windows 98

In your answer file, add the following entry in the [win9xupg] section:




[Win9xUpg] ForcePasswordChange = "Yes"

For Windows 95 or Windows 98 upgrades, you can customize your answer file to create passwords for specific local accounts. Because Windows 95 and Windows 98 passwords cannot be migrated during the upgrade, Setup must create passwords for local accounts during the upgrade process. Using this key, the administrator can predetermine those passwords for specific users. If a local account needs to be created for a user without a preset value for the UserPassword entry and no value is specified for DefaultPassword, Setup creates a random password.

To force a user to create a new password after an upgrade from Windows 95 or Windows 98

In the answer file, add the following entry in the [win9xupg] section:




[Win9xUpg] UserPassword = user,password [,user,password……]

You can customize the [RegionalSettings] section of your answer file to specify the regional options listed in Table 5.13

NOTE

---

To use this section of your answer file, you must add, as a minimum, the /copysource:lang switch to Winnt32.exe or the /rx:lang switch to Winnt.exe. This enables you to copy the appropriate language files to the hard disk. For example, if you are only interested in Korean settings while installing a U.S. version of Windows 2000 Professional, you can specify /copysource:langkor if starting from Winnt32.exe.

When specifying OemPreinstall = Yes and not providing values for the [RegionalSettings] section, set OEMSkipRegional = 1 in the [GuiUnattended] section of the answer file to ensure that Setup completes without prompting for regional option information.

Table 5.13 Customizing Regional Options

NOTE

---

A list of valid locales and their language groups is available at the Global Software Development Web site link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources.

NOTE

---

Any settings specified here are not kept if Sysprep is run on the computer.

To use [regionalsettings] for multilingual support during mini-setup

Create a subfolder named i386 under $OEM$$1Sysprep in the distribution folder.

At the command prompt, type the following to copy files from i386 of the Windows 2000 Professional operating system CD to the i386 directory in the Sysprep folder:




*.nl? kbd*.dl? *.fo? agt*.dl? agt*.hl? conime.ex? wbcache.* noise.* wbdbase.* infosoft.dl? f3ahvoas.dl? sylfaen.tt_ c_is*.dl_ Lang...

NOTE

---

You can also use Setup Manager to add the necessary files and folders to the i386 subfolder.

In Sysprep.inf, add the InstallFilesPath key to the [Unattended] section:




InstallFilesPath = %systemdrive%Sysprepi386




For more information about the InstallFilesPath key, see Unattend.doc provided in SupportToolsDeploy.cab on the Windows 2000 Professional operating system CD.

NOTE

---

The i386 subfolder and its contents are only required if the end user needs language support from one of the language groups provided in that folder.

The i386 subfolder is deleted after the Mini-Setup wizard has been run on the end user's computer. If you perform an audit, or if a reseller further customizes the computer, you must recreate Sysprepi386 and then rerun Sysprep.exe before the image is installed to allow the end-user to specify the necessary regional options.

Presetting Time Zones

You can specify the time zone of the computers in your organization by using the TimeZone key in the [GuiUnattended] section of your answer file or the Sysprep.inf file. If the TimeZone key is not present, the user is prompted for a time zone specification during setup.

To preset time zones

In your answer file, add the following entry in the [GuiUnattended] section:




[GuiUnattended] TimeZone = "index"




where index specifies the time zone of the computer.

For a list of valid TimeZone indixes, see Unattend.doc in SupportTools
Deploy.cab on the Windows 2000 Professional operating system CD.

Detecting Video Mode for Portable Computer Displays

You can customize the [Display] section answer file to ensure that Setup automatically detects the display resolution on a portable computer. Specify the optimal settings (you must know what the valid settings are) for the keys listed in Table 5.14. If the settings that you specify are not valid, Setup finds the closest match to the selected settings, but they might not be optimal.

Table 5.14 Customizing Display Settings

To ensure the video mode is properly detected by setup

Check that the computer BIOS supports the set of Video ACPI extensions.

Check that the drivers for the video cards and displays are included in the $1PnPdrvrs path.

In the [Unattended] section of the answer file, set the OemPnPDriversPath key to the $1PnPdrvrs path.

In the [Display] section of the answer file, set the optimal settings for your portable computer.

For the most up-to-date information about hardware devices with Windows 2000 Professional, see the Windows Driver and Hardware Development link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources/

Automatically Converting FAT16 and FAT32 to NTFS

You can customize the [Unattended] section of your answer file to convert FAT16 and FAT32 file systems automatically to NTFS.

To automatically convert FAT16 and FAT32 partitions to NTFS

In your answer file, add the following entry in the [Unattend] section:

[Unattended]
FileSystem = ConvertNTFS

When the FileSystem key is specified, Setup automatically converts your drive just before the GUI mode of Setup starts.

NOTE

---

The FileSystem = ConvertNTFS key and value do not work in Sysprep.inf.

For more information about the differences between the NTFS, FAT16, and FAT32 file systems, see "File Systems" in this book.

Converting Short File Names to Long File Names

If you are starting Setup from MS-DOS, you can convert short file names to long names by creating a file called $$Rename.txt and putting that file in the subfolder of the distribution folder that also contains the files that you want to convert. If you are starting Setup from any other operating system, they are converted automatically.

Setup uses the list of files that you specify in $$Rename.txt to convert short names to long names during the installation process. You must include a $$Renamte.txt file in each subfolder that contains

The $$Rename.txt file changes short file names to long file names during Setup. $$Rename.txt lists all of the files in a particular folder that must be renamed. Each folder that contains short file names to be renamed must contain its own version of $$Rename.txt.

To convert short file names to long file names

Create a $$Rename.txt file following this syntax:




[section_name_1] short_name_1 = "long_name_1" short_name_2 = "long_name_2" short_name_x = "long_name_x" [section_name_2] short_name_1 = "long_name_1" short_name_2 = "long_name_2" short_name_x = "long_name_x"




Where:

section_name_x is the path to the subfolder that contains the files. A section does not have to be named, or it can have a backslash () as a name, which indicates that the section contains the names of the files or subfolders that are in the root of the drive.

short_name_x is the name of the file or subfolder within this subfolder to be renamed. The name must not be enclosed in quotation marks.

long_name_x is the new name of the file or subfolder. This name must be enclosed in quotation marks if it contains spaces or commas.

TIP

---

If you are using MS-DOS to start the installation, and your MS-DOS-based tools cannot copy folders with path names longer than 64 characters, use short file names for the folders and then use $$Rename.txt to rename them later.

Adding Applications

There are several methods from which you can choose to add applications to your installation:

Using Cmdlines.txt to add applications during the GUI mode of setup.

Installing applications when the user logs on for the first time by customizing the [GuiRunOnce] section of the answer file.

Using batch files.

Using windows installer.

Using the Sysdiff tool to install applications that don't have an automated installation routine.

The Cmdlines.txt file contains the commands that GUI mode runs when installing optional components, such as applications that must be installed immediately after Windows 2000 Professional is installed. If you plan to use Cmdlines.txt, place it in the $OEM$ subfolder of the distribution folder. If you are using Sysprep, place Cmdlines.txt in the $OEM$$1Sysprep subfolder.

Use Cmdlines.txt under following conditions:

You are installing from the $OEM$ subfolder of the distribution folder.

The application that you are installing:




Does not configure itself for multiple users (for example, Microsoft® Office 95).

Is designed to be installed by one user and to replicate user-specific information.

The syntax for Cmdlines.txt is as follows:

[Commands]
"<command_1>"
"<command_2>"
.
.
"<command_x>"

Keys are defined as follows:

"<command_1>", "<command_2>", … "<command_x>" refer to the commands that you want to run (and the order in which you want to run them) when GUI mode calls Cmdlines.txt. Note that all commands must be in quotation marks.

When you use Cmdlines.txt, be aware of the following:

When the commands in Cmdlines.txt are carried out during setup, there is no logged-on user and there is no guaranteed network connectivity. therefore, user-specific information is written to the default user registry, and all users receive that information.

Cmdlines.txt requires that you place the files that you must have to run an application or tool in directories that you can access during the setup process, which means that the files must be on the hard disk.

IMPORTANT

---

Applications that can be set up by using Windows Installer cannot be added using Cmdlines.txt.

To specify a Cmdlines.txt file during the mini-Setup portion of Sysprep

Create a Sysprep.inf file to be used by Sysprep. This is a requirement and cannot by bypassed. The Sysprep.inf file must be named Sysprep.inf and be located in the folder Sysprep from the root of the volume that contains the folder %SystemRoot%.

Place the following entry in the [Unattended] section of the Sysprep.inf file:




InstallFilesPath = drive:path




where:

<path> is any folder you want to use. Microsoft recommends that <drive> be the volume containing the %SystemRoot% folder.

Create the folder drive:path. You can use any folder name you want, but it must match the location that you specified in Sysprep.inf.

In the drive:path folder, create a folder named $oem$, and then place the Cmdlines.txt file in this folder. This file is processed at the end of the mini-Setup wizard, before saving any settings.

The [GuiRunOnce] section of the answer file contains a list of commands that run the first time a user logs on to the computer after Setup has run. For example, you enter the following line to the [GuiRunOnce] section to start the application installation program automatically.

[GuiRunOnce]
"%systemdrive%appfolderappinstall -quiet"

If you plan to use the [GuiRunOnce] section to initiate an installation, there are some additional factors to take into consideration.

If the application forces a restart, determine whether there is a way to suppress the restart.

This is important because any time the system restarts, all previous entries in the [GuiRunOnce] section are lost. If the system restarts before completing entries previously listed in the [GuiRunOnce] section, the remaining items are not run. If there is no way within the application to suppress a restart, you can try to repackage the application into a Windows Installer package. There are third-party products that provide this functionality.

Windows 2000 includes Veritas WinINSTALL Limited Edition (LE), a repackaging tool for Windows Installer. You can use WinINSTALL LE to efficiently repackage pre-Windows Installer applications into packages that can be distributed with Windows Installer. For more information about WinINSTALL LE, see the Valueadd3rdpartyMgmtWinstle folder on the Windows 2000 Professional operating system CD.

For more information about Windows Installer packaging, see "Using Windows Installer Service" later in this chapter.

IMPORTANT

---

If you are adding an application to multiple localized language versions of Windows 2000 Professional, it is recommended that you test the repackaged application on the localized versions to ensure that the files are copied to the correct locations and the required registry entries are written appropriately.

If an application requires a Windows Explorer shell to install, the [GuiRunOnce] section does not work because the shell is not loaded when the Run and RunOnce commands are carried out.

Check with the application vendor to determine whether an update or patch is available that can address this situation for the application installation. If not, repackage the application as a Windows Installer package or use another means of distribution.

Applications that use the same type of installation mechanism might not run properly if a /wait switch is not used.

This can happen when an application installation is running and starts another process. When Setup is still running, initiating another process and closing an active one might cause the next routine listed in the RunOnce registry entries to start. Because more than one instance of the installation mechanism is running, the second application usually fails.

Using Application Installation Programs

The preferred method for adding an application is to use the installation routine supplied with the application. You can do this if the application that you are adding can run in quiet mode (that is, without user intervention) by using a /q or /s switch. For a list of switches supported by the installation mechanism, see the application Help file or documentation.

The following is an example of a line that you can place in the [GuiRunOnce] section to initiate the unattended installation of an application by using its own installation program:

<path to setup>Setup.exe /q

Setup parameters vary between applications. For example, the l parameter included in some applications is useful when you want to create a log file to monitor the installation. Some applications have commands that can keep them from restarting automatically. These commands are useful in helping to control application installations with a minimal number of restarts.

Make sure that you check with the application vendor for information, instructions, tools, and best practices information before you install any application.

IMPORTANT

---

You must meet the licensing requirements for any application that you install, regardless of how you install it.

Using a Batch File to Control How Multiple Applications Are Installed

If you want to control how multiple applications are installed, you can create a batch file that contains the individual installation commands and uses the Start command with the /wait switch. This method ensures that your applications install sequentially and that each application is fully installed before the next application begins its installation routine. The batch file is then run from the [GuiRunOnce] section.

The following procedure explains how to create the batch file, install the application, and remove all references to the batch file after the installation is complete.

To install applications using a batch file

Create the batch file containing lines similar to the following example:




Start /wait <path to 1st application>Setup <switches> Start /wait <path to 2nd application>Setup <switches> Quit




where:

<path> is the path to the executable file that starts the installation. This path must be available during Setup.

Setup is the name of the executable file that starts the installation.

<switches> are any available quiet-mode switches appropriate for the application that you want to install.

Copy the batch file to the distribution folders or another location to which you have access during setup.

With <file name>.bat as the name of the batch file, include an entry in the [GuiRunOnce] section of the answer file to run the batch file, as is done in the following example. This example assumes that the batch file was copied to the Sysprep folder on the local hard disk drive, though it can be in any location to which Setup has access during an installation.




[GuiRunOnce] "%systemdrive%sysprep<file name>.bat"= "<path-1>Command-1.exe" "<path-n>Command-n.exe" "%systemdrive%sysprepsysprep.exe –quiet"




where:

<path-1>Command-1.exe and <path-n>Command-n.exe are fully qualified paths to additional applications or tool installations or configuration tools. This can also be a path to another batch file. These paths must be available during setup.

Windows Installer Service is a Windows 2000 Professional component that standardizes the way applications are installed on multiple computers.

When you install applications without using Windows Installer Service, every application must have its own setup executable file or script. Each application has to ensure that the proper installation rules (for example, rules for creating file versions) are followed. This is because the application setup was not an integral part of the operating system development, so no central reference for installation rules exists.

Windows Installer Service implements all the proper Setup rules in the operating system itself. To follow those rules, applications must be described in a standard format known as a Windows Installer package. The data file containing the format information is known as the Windows Installer package file and has an .msi file name extension. Windows Installer Service uses the Windows Installer package file to install the application.

Windows Installer Terminology

The following terms are used to describe the installation process that uses Windows Installer technology:

Resource. A file, registry entry, shortcut, or other element that an installer typically delivers to a computer.

Component. A collection of files, registry entries, and other resources that are installed or uninstalled as a unit. When a particular component is selected for installation or removal, all of the resources in that component are either installed or removed.

Feature. The granular pieces of an application that a user can choose to install. Features typically represent the functional features of the application itself.

Product. A single product, such as Microsoft® Office. Products contain one or more features.

Windows Installer Package File

The package file is a database format that is optimized for installation performance. Generally, this file describes the relationships between features, components, and resources for a specific product.

The Windows Installer package file is typically located in the root folder of the Windows 2000 Professional operating system CD or network image, alongside the product files. The product files can exist as compressed files known as cabinet (CAB) files (which have a .cab file name extension). Each product has its own package file. During installation, Windows Installer Service opens the package file for the product and uses the information inside the Windows Installer package to determine which installation operations must be performed for that product.

Sysdiff Tool

The preferred method for automating application installation is to use their own scripting and installation routines. However, you can install applications that do not support this by using the Sysdiff tool. To perform the various steps to add applications, run Sysdiff in several different modes. In /snap mode, Sysdiff.exe takes a "snapshot" of a clean Windows 2000 Professional computer, and then the applications are installed. A clean copy of Windows 2000 Professional is an installation of Windows 2000 Professional that has not been modified and has not had additional software installed on it. Use Sysdiff in /diff mode to record all the changes that the application installation made to the computer (INI files, the registry, and so on).

Sysdiff creates a difference file or package that includes all the files and settings that you must install with applications on a clean copy of Windows 2000 Professional. Running Sysdiff in /apply or /inf mode applies the package to the clean Windows 2000 Professional installation.

Sysdiff generates the $OEM$ folder structure in 8.3 file name format for maximum compatibility with OEM preinstallation environments and methods. It places $$Rename.txt in the appropriate folder.

Sysdiff Parameters

The Sysdiff switches are listed in this section. The sections that follow discuss each switch in greater detail. Sysdiff syntax is as follows:

sysdiff [/snap | /diff | /apply | /dump | /inf] 
[/log:Log_file] 
[/m]
[/?]
[/dsp]
[/p]
[/q]
[/c:"comment"]
Snapshot_file
Sysdiff_file
Dump_file
Oem_root

where:

/snap, /diff, /apply, /dump, /inf are the modes available. You must specify one of these switches, because this switch determines the Sysdiff mode and specifies how Sysdiff proceeds.

Log_file is the name of an optional log file to which Sysdiff writes information describing its actions (used only in /snap and /diff modes).

/m is a switch that remaps file changes during the creation of a Sysdiff package so that they appear as Default User files. (Used only in /apply and /inf modes.)

/? is a switch that calls the Help file.

/dsp is a switch that instructs Sysdiff to not generate the distribution share point that sysdiff /inf normally generates because the files already exist in the appropriate folders on the destination computer. (Used only in /inf mode.)

/p is a switch that instructs Sysdiff to not scan all folders and files on the computer for changes. Instead, Sysdiff only scans files in the UserProfile folder. (Used in /snap and /diff modes.)

/q is a switch that instructs Sysdiff to run in unattended (quiet) setup mode.

"comment" is the name you give to th Sysdiff package as it appears in an onscreen message during setup. (used in /diff mode only.) This comment must contain only the names of the applications being added.

Snapshot_file is any valid Microsoft® Win32® file name. (Used in /snap and /diff modes only.) A snapshot of the system is recorded in this file.

Sysdiff_file is any valid Win32 file name. (Not used in /snap mode.) The specified file is the output of Sysdiff and can be applied to a Windows 2000 Professional installation by using sysdiff /apply or sysdiff /inf modes.

Dump_file is a Win32 path to a text file that is created to contain the dump. (Used in /dump mode only.) A dump file is used for diagnostic purposes.

Oem_root is the Win32 path of a folder. (Used in /inf mode only.) The $OEM$ structure is created in this folder, and the INF file is placed in this folder and named Sysdiff_file.inf.

Figure 5.3 shows the sequence of steps for using Sysdiff to add applications. The sections that follow discuss each step in greater detail.

Figure 5.3 Sysdiff Overview

Sysdiff is used in as many as six different steps to add applications during installation. The following sections explain these steps.

Step 1: Install Windows 2000 Professional on the Reference Computer

Before you add applications by using Sysdiff, you must install a clean copy of Windows 2000 Professional on your reference computer.

IMPORTANT

---

Do not make any changes to Windows 2000 Professional on the reference computer before you run Sysdiff.

Step 2: Modify the Sysdiff.inf File

You can exclude items from the Sysdiff snapshot by modifying the Sysdiff.inf file. When Sysdiff runs in /snap or /diff mode, it looks for the Sysdiff.inf file in the same folder that contains Sysdiff.exe. This file contains information that Sysdiff uses to exclude certain files and registry entries from snapshots or difference files. To modify the Sysdiff.inf file, follow the instructions in the file.

Step 3: Make a Snapshot of the Clean System

Sysdiff /snap takes a snapshot of a clean system. A clean system is a reference computer that is running Windows 2000 Professional but has no applications installed.

Run Sysdiff in /snap mode to create the snapshot for later difference files.

The syntax for this command is as follows:

sysdiff /snap [/log:Log_file] Snapshot_file

where:

Log_file is the optional name of a log file to which Sysdiff writes information describing its actions. The log file is not used in /apply or /dump modes.

Snapshot_file is any valid Win32 file name. A snapshot of the system is recorded in this file.

Step 4: Create the Difference Files

After you install applications on the reference computer, run Sysdiff with the /diff switch to determine the differences between the new system state of the computer and the earlier, clean system snapshot. The result is a Sysdiff difference file package that contains a description of the INI file changes, registry changes, and other changes (including the application files themselves, which can make Sysdiff packages quite large). You can then apply these changes to another Windows 2000 Professional installation, duplicating the changes made to the reference computer.

IMPORTANT

---

If you change any of the system's settings after you create the snapshot, you must recreate the snapshot file before you create the difference file.

The syntax for this command is as follows:

sysdiff /diff [/log:Log_file] Snapshot_file Sysdiff_file
/c:"comment"

where:

Log_file is the optional name of a log file to which Sysdiff writes information describing its actions. The log file is not used in /apply or /dump modes.

Snapshot_file is a file generated by an earlier invocation of sysdiff /snap on the same Windows 2000 Professional installation. (Sysdiff fails if Snapshot_file is from a different Windows 2000 Professional installation.)

Sysdiff_file is any valid Win32 file name. The specified file is the output of Sysdiff, and you can apply it to a Windows 2000 Professional installation by using Sysdiff /apply or Sysdiff /inf.

"comment" is the name you give to the Sysdiff package. This name appears in a screen message during setup. (Used in /diff mode only.) This comment can contain only the names of the applications being added.

IMPORTANT

---

Do not try to quit Sysdiff until a message appears informing you that the difference package has been created. If you quit before this message appears, Sysdiff fails.

Step 5: View Difference File Information (Optional)

You can also run Sysdiff in /dump mode, which is a special mode for diagnostic purposes. The output of this command is a text file containing a readable form of the contents of a Sysdiff package.

The syntax for this command is as follows:

sysdiff /dump Sysdiff_file Dump_file

where:

Sysdiff_file is a Win32 path to a file that is created in /diff mode.

Dump_file is a Win32 path to a text file that is created to contain the dump.

Step 6: Apply Difference Files

After you create at least one snapshot on your reference computer and at least one difference file based on that snapshot, you have a Sysdiff package file that can be applied to multiple destination computers during Setup. Two Sysdiff modes can have difference files applied: Sysdiff /apply and Sysdiff /inf.

Sysdiff /apply

You can apply Sysdiff packages during setup if the Sysdiff package is available on the hard disk and the correct switch is specified. When a Sysdiff package is applied, Sysdiff copies each file from the package to its final location on the hard disk.

Setup starts Sysdiff in /apply mode to apply a difference file to a Windows 2000 Professional installation. You must specify /m when running Sysdiff in /apply mode. You can specify one or more Sysdiff switches in the Cmdlines.txt file.

The syntax for this command is as follows:

sysdiff /apply /m Sysdiff_file

where:

/m remaps file changes to the user profile (UserProfile) during the creation of a Sysdiff package so that they appear as Default User files. The /m switch is required when running Sysdiff in either /apply or /inf modes.

Sysdiff_file specifies the file that was generated by carrying out sysdiff /diff.

IMPORTANT

---

The SystemRoot folder must be located in the same position as it was on the system that generated the difference file. That is, if you generate a Sysdiff package on a Windows 2000 Professional installation in C:Winnt, that Sysdiff package can be applied on other computers only if they are running Windows 2000 Professional installed in C:Winnt.

Sysdiff /inf

Running Sysdiff /inf also allows Setup to install applications, but in this mode, the Sysdiff package does not contain the actual application files. Instead, Sysdiff determines the files that the application placed on the reference computer and their locations. Sysdiff then copies these files to the corresponding folders in the distribution folder. By including only information that refers to a location for the application files, the Sysdiff package can be much smaller.

Running Sysdiff /inf creates the following files, folders, and settings:

$OEM$Cmdlines.txt

$OEM$Package.inf Package represents the Sysdiff package file name.

$OEM$Cprograms C represents the drive where the newly installed application is stored, and Programs represents the folder.

Rather than creating the distribution folder manually, you can use Sysdiff to generate an Inf and $OEM$ folder structure from the Sysdiff file. The Inf folder contains registry and INI file settings. The $OEM$ folder structure is created during an early phase of Setup. The application files have already been copied to the hard disk when the GUI mode of Setup begins. This allows greater flexibility in applying changes.

Running Sysdiff in /inf mode creates an INF file that instructs Setup to make the INI file and registry changes contained in the Sysdiff package and also to generate an $OEM$ folder structure for file changes contained in the Sysdiff package. The folder structure is created using only file names in 8.3 format. The $$Rename.txt files throughout the tree contain mappings from file names in 8.3 format to long file names where necessary. These $$Rename.txt files are used during later phases of Setup.

The syntax for using /inf mode is as follows:

sysdiff /inf /m Sysdiff_file Oem_root

where:

/m remaps file changes during the creation of a Sysdiff package so that the files appear as Default User files. The /m parameter is required when running Sysdiff in /apply or /inf modes.

Sysdiff_file is the Win32 path to a file that was created by running Sysdiff in /diff mode. The name of this file must be no more than eight characters long.

Oem_root is the Win32 path of a folder. The $OEM$ structure is created in this folder, and the INF file is copied there and named Sysdiff_file.inf.