CIW Design Tasks

When designing the CIW process, your primary tasks are to choose the following

The operating system installation options you want to present to clients.

The setup options you want to provide to clients.

The CIW configuration you want to provide.

For a job aid to record your design decisions for your CIW process, see "Designing the RIS Deployment Mode and CIW Process" (ACIRIS_08.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "Designing the RIS Deployment Mode and CIW Process" on the Web at https://www.microsoft.com/reskit).

Defining CIW Operating System Installation Options

The operating system installation options that you provide in the CIW enable users to receive the correct operating systems on their computers. By setting explicit user or group security permissions on the answer file associated with specific operating system images on your RIS server, you can control which installation images the CIW displays to users or user groups. You can restrict users and user groups to viewing a s 20120f54u ingle image in the CIW or you can make all operating system images on your RIS server available to them.

Each Risetup or Riprep image that you add to your RIS server has an associated \Templates directory that contains a default answer file (Ristndrd.sif or Riprep.sif) and any additional answer files that you create and associate with that image. These are the answer files on which you configure permissions to cause the CIW to display operating system image installation options on the OSChoice screen. However, you must set these permissions from your RIS server Properties dialog box, rather than setting them directly on the answer files in the \Templates directory.

Because selecting individual users for specific image access is time consuming, consider using security groups when applying permissions on answer files. This way, any new users that you add to a particular group automatically receive the correct operating system image installation options.

For this part of your CIW design process, it is unnecessary to record your operating system installation access configuration options if you specified them earlier in "Defining the Operating System Image" using job aid "Designing the RIS Deployment Mode and CIW Process" (ACIRIS_08.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "Designing the RIS Deployment Mode and CIW Process" on the Web at https://www.microsoft.com/reskit). However, if you did not do so, decide on them now and record them under the "Operating System Installation Access" section in the job aid.

Defining CIW Setup Options in Group Policy

The setup options that you configure in Group Policy help guide users to the correct choices for installing their operating systems. When determining the setup options you want to provide to users, you need to consider the sophistication level of the users who will be installing using RIS. You can provide advanced users with options that allow them to:

Specify a name for their computer accounts and a location in Active Directory, if you enable the Custom Setup option.

Restart a failed installation attempt, if you enable the Restart Setup option.

Access maintenance and troubleshooting tools, if you enable the Tools option.

For less knowledgeable users, you might want to prestage client computers in Active Directory, automate installations for those computers, and enable the Automatic Setup option in the Group Policy object that users at the client computer receive. If the Group Policy object applied to the users is configured with the Automatic Setup option, then the CIW does not present computer account setup options to the users. In this case, the CIW only displays the following installation options:

Those that offer a choice of operating systems the user can install.

Those that exist on any other custom screens you create.

You can apply a setup option configuration for clients by using the default domain Group Policy settings, or you can create new Group Policy objects that you customize and apply to specific user security groups. If you apply a new Group Policy object that has any of the setup options set to "Not Configured", the settings for the corresponding options in the default domain policy apply.

For this part of your CIW design process, it is unnecessary to record your Group Policy configuration options if you specified them earlier in "Designing for the RIS Deployment Mode" using job aid "Designing the RIS Deployment Mode and CIW Process" (ACIRIS_08.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "Designing the RIS Deployment Mode and CIW Process" on the Web at https://www.microsoft.com/reskit). However, if you did not do so, record your Group Policy setup option design choices after evaluating the information in the following paragraphs.

Automatic setup

This option provides the simplest way to install an operating system on the client computer. When the Group Policy object applied to the client is configured with this option, RIS searches Active Directory for a computer account object with a UUID that matches the UUID of the client computer. If RIS finds a match, the client computer is named according to the prestaged computer account name. If RIS does not find a match, the client computer account is named and located according to the automatic naming format and Active Directory location that you preconfigured on the RIS server.

Custom setup

This option allows users to override the automatic computer naming process and the default location specification in Active Directory for client computer account objects. However, if the user leaves either the computer name or location field blank, RIS uses the automatic naming and location process.

The Custom Setup option is similar to the Automatic Setup option, although you can use Custom Setup to set up the client computer for other users. Because the default configuration of a RIS-based installation is to automatically create computer account names based on the user who logs on to the client computer, it is impractical to use the Automatic Setup option when you need to set up another user's computer. For example, Help Desk personnel can use the Custom Setup option to preinstall an operating system on a client computer, prior to delivery to the client.

If the name and location the user enters under the Custom Setup option and the client UUID match the name, location, and UUID of an existing computer account object, the existing computer account object is reused. If only one of the fields between name, location, and UUID match, a duplicate name or duplicate UUID error screen displays. However, because the user can bypass the error screen, do not use the Custom Setup option for prestaged client computers in installations that users perform directly.

Restart setup

This option allows users to restart a failed installation attempt, which might occur if the installation process fails or network connectivity is disrupted during the text-mode stage of the setup process. This part of setup is where the CIW process runs prior to the image copy stage. If you provide this option, a Restart Setup command is available to users the next time they restart their computers. If the user executes the command, the operating system installation process restarts using the information provided in the previous installation attempt. Display of this command is controlled by the client-specific temporary answer file that RIS generates and then deletes before running Mini-Setup.

Tools

This option allows users to access maintenance and troubleshooting tools for use prior to completing the operating system installation. Such tools include a system flash BIOS update tool, diagnostic tools, or other tools provided by third parties.

Defining the CIW Configuration

You can choose to use the default CIW configuration or create a custom configuration. If the default CIW configuration is adequate for your purposes, you can use it as a quick way to provide basic installation guidance to your clients. If necessary, review the functionalities described in "CIW Screen Functions" earlier in this chapter before making your decision.

For a customized configuration, you can build new screens by renaming existing screens and modifying them with OSCML tags. You can also modify existing screens by adding certain OSCML tags that allow you to provide additional information. In addition, you can construct screen prompts for custom user input and use OSC variables in your answer files to capture the input information. You can also use one of the sample .osc files as a new CIW screen to display to users.

If you anticipate network problems, you can even create waiting screens to allow you to debug network delays that might exist between clients and the RIS server, or between the RIS server and the domain controller. For more information, see the discussion about defining new CIW screens and OSC variables later in this section.

For this part of your CIW design process, decide if you want to use the default CIW configuration. If you think you will need custom screens or modifications to existing screens, choose a custom CIW configuration. To record your decision, use the "CIW Configuration" section in job aid "Designing the RIS Deployment Mode and CIW Process" (ACIRIS_08.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "Designing the RIS Deployment Mode and CIW Process" on the Web at https://www.microsoft.com/reskit).

If you choose the default configuration, you can skip the remainder of this section. If you choose to define a custom CIW configuration, you need to decide if you want to do one or more of the following:

Add new screens to the CIW process, including wait screens.

Modify existing screens with custom prompts or information displays.

Remove any screens from the CIW process.

Defining new CIW screens and OSC variables

You can customize the CIW process by creating additional screens that require the user to provide custom information to complete the installation. This can assist you when creating interactive deployments because it gives you some flexibility in the way you gather user input.

For example, you can build a new screen from an existing screen by modifying its contents using OSCML tags. You can then add user input prompts to the new CIW screen. You also use an OSCML tag to define which screen the CIW displays next, so you can insert a new screen into the CIW process at the correct point. This tag has the following format:

<FORM ACTION ="SCREENAME">

When you add input prompts, you must also have a method to capture the user input information. To do this, you create OSC variables in the image answer file. When the CIW runs, RIS replaces the OSC variables in the answer file with the values the user enters in the CIW screen input prompt. RIS then uses these values in the temporary answer file it creates for the client installation configuration.

You can create an OSC variable for any answer file value that works with an unattended setup process in addition to those specifically designed for RIS. However, you must specify OSC variables in your answer file by enclosing them in percent signs so RIS can identify and parse them correctly. For example, you could create prompts on a custom CIW screen that ask users to specify the X and Y resolution and the refresh rate for their video display. To do this, you must include the following OSCML tags in the new screen and specify input name strings such as the following:

<INPUT NAME="X-res">

<INPUT NAME="Y-res">

<INPUT NAME="Refresh">

Then, in your answer file, you need to specify the OSC variables that capture the user input. You can do this by setting the appropriate unattend values equal to the corresponding OSC variables in the unattended [Display] section, as follows:

[Display]

XResolution=%X-res%

YResolution=%Y-res%

VRefresh=%Refresh%

You can use up to 64 unique OSC variables per client session; however, there are certain variables that are reserved for RIS use only. For a list of these variables, see job aid "Reserved OSC Variables" (ACIRIS_12.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "Reserved OSC Variables" on the Web at https://www.microsoft.com/reskit) Also, you cannot define OSC variables prior to the time the user logs on to the network, with exception of the %language% variable, which the user can only set before logging on. This allows users to select the proper language in which to proceed in the installation. For more information about OSCML tags, see job aid "OSCML and Client Installation Wizard Variables" (ACIRIS_13.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "OSCML and Client Installation Wizard Variables" on the Web at https://www.microsoft.com/reskit).

The logon process from a PXE client to a Windows Server 2003 RIS server uses NTLM v2 by default to encrypt the user name and password sent between the client and RIS server. After authentication, the client and server communicate using SMB. For more information about NTLM v2, see "Evaluating the NTLM Authentication Level" earlier in this chapter.

From this point forward in the CIW process, you can create any OSC variables you need for custom or existing screens, as long as you associate them with sections in the Unattend.txt answer file. For more information about sections in the Unattend.txt answer file, see "Unattended.txt" in the Microsoft  Windows Server 2003 Corporate Deployment Tools User's Guide (Deploy.chm). Deploy.chm is included in the Deploy.cab file in the Support folder on the Windows Server 2003 operating system CD.

Also, if you observe significant time delays between CIW screens, you might consider inserting waiting screens at the appropriate point of the CIW process. One way you might observe where delays are occurring is to configure waiting screens in a test CIW configuration and perform a test installation in your production network environment. If there are no delays, the waiting screens display only for a moment and then the next CIW screen appears. Otherwise, the waiting screens display for the length of the network delay. Once you know where the delays are occurring, you can include waiting screens in your user CIW process.

For example, users might experience a delay between the time they log on and the time they receive the operating system choice screen Choice.osc. To improve the user experience, you can place a waiting screen between Login.osc and Choice.osc with a statement that asks the user to please wait while their logon credentials are verified. Also, slow network access to the domain controller might occur when creating computer account objects in Active Directory. To accommodate the delay, you might add a waiting screen between Choice.osc and Autodup.osc asking the user to wait while creating their computer account.

Lastly, when you insert a new or modified screen into the CIW process on a RIS server, you enable all users who are configured to use the RIS server to view the new screen. Also, you must include changes to the CIW process on each RIS server because there is no capability to synchronize changes to .osc files across multiple RIS servers.

For this part of your CIW design process, use the "CIW Configuration" section in job aid "Designing the RIS Deployment Mode and CIW Process" (ACIRIS_08.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "Designing the RIS Deployment Mode and CIW Process" on the Web at https://www.microsoft.com/reskit) to record the following information:

New screens to be added, including wait screens.

Insertion points in the CIW process for new screens.

New user input prompts.

OSC variables to create for new user prompts and the associated answer file entries.

Also, use the "Operating System Installation Access" section of job aid "Designing the RIS Deployment Mode and CIW Process" (ACIRIS_08.doc) to indicate which answer files require configuration with OSC variables.

Defining modifications to existing CIW screens

You can modify existing screens with the same techniques that you use for customizing new CIW screens. This means you use a combination of OSCML tags in your .osc files and OSC variables in your image answer file (in cases where you are gathering custom user input). However, remember that you cannot create OSC variables in screens that display before the Logon screen, with exception of the %language% variable, which you can use in the Welcome screen configuration.

When you need to provide custom information in a CIW screen, you can use the following OSCML tag to add the text:

<BODY>

Text you want to provide.

</BODY>

For this part of your CIW design process, use the "CIW Configuration" section in job aid "Designing the RIS Deployment Mode and CIW Process" (ACIRIS_08.doc) to record the following information:

Names of the existing screens you want to modify.

Input prompts or information you want to provide.

OSC variables and answer file entries you want to use.

Also indicate the answer files that require configuring with OSC variables. Use the "Operating System Installation Access" section of job aid "Designing the RIS Deployment Mode and CIW Process" (ACIRIS_08.doc) to record this information.

Defining screens to remove

There might be specific screens you want to remove from the CIW process. This could include the Setup Options, Error, Operating System Choice, and Caution screens. You might want to do this for RIS clients that receive an automated installation, or if you decide you don't want a particular screen to display. However, be aware that you must not remove the Welcome, Logon, or Summary screens.

If you want to remove a screen from the CIW process, you can change the target of the appropriate OSCML tag so that it no longer calls the screen. These OSCML tags exist in each CIW screen and they point to the next .osc file the CIW displays. For example, the following OSCML tag in the Oschoice.osc file calls the Warning.osc screen:

<FORM ACTION = WARNING >

Therefore, if you want to skip the Warning screen, you can change the target screen of this tag to the Summary screen.

For this part of your CIW design process, use the "CIW Configuration" section of job aid "Designing the RIS Deployment Mode and CIW Process" (ACIRIS_08.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "Designing the RIS Deployment Mode and CIW Process" on the Web at https://www.microsoft.com/reskit) to identify the screens you want to remove from the CIW process.

At this point, you should have gathered enough information to identify the new CIW screen sequence. Record this information in job aid "Designing the RIS Deployment Mode and CIW Process" (ACIRIS_08.doc) under the "New CIW Sequence" section along with the RIS servers to which you want the new configuration to apply. Also, if you want to test the new CIW configuration in your RIS test environment, select the appropriate check box in the "New CIW Sequence" section.

Defining a multilanguage CIW process

If you need to support multiple languages, you can use a single RIS server to provide service to clients that install different language versions of the Windows Server 2003 or Windows XP Professional operating systems. You can modify the Welcome screen to include the language options you want the RIS server to support. You can find the Welcome.osc file in the \OSChooser directory on your RIS server. Also in this directory is the sample Multilng.osc file that shows how to configure multilanguage support.

The CIW screens that display following the Welcome screen are obtained by RIS from the specific language folder in the \OSChooser directory. The list of operating system images presented to the user is restricted to images for the language selected. For each language version you want to make available to users, you must provide a set of CIW screens in a separate language folder in the \OSChooser directory. The \OSChooser\English version is provided by default.

Certain language restrictions apply to the CIW; these include not providing support for the following:

Non-101 key keyboards.

Non OEM fonts.

Multi-Byte Character Set (MBCS)/Unicode character sets.

These restrictions apply to data used within the CIW, including computer, domain, and directory or file names such as answer file names. It also applies to any example or descriptive text you display to users and to the text that users input to the CIW, such as user names, passwords, and domain names. Because of these restrictions, you must ensure these user input strings do not contain any non-ASCII characters, since they cannot be used within the CIW. Furthermore, even though you can use a different set of CIW screen files for each language you want to make available, in many cases it is not possible to create screens that are fully localized to a specific language using available character sets.

Also, to support Riprep images in different languages, a Risetup (CD-type) image of the language must also exist on your RIS server. This is necessary to supply files such as device drivers that are needed during installation of the Riprep image, but that did not exist on the master installation from which you derived the Riprep image.

For this part of your CIW design process, record your decision to provide a multilanguage CIW process under "CIW Configuration" in job aid "Designing the RIS Deployment Mode and CIW Process" (ACIRIS_08.doc) on the Windows Server 2003 Deployment Kit companion CD (or see "Designing the RIS Deployment Mode and CIW Process" on the Web at https://www.microsoft.com/reskit). Also indicate your choices for the language options you want to provide using the "Required User Input" section of job aid "Designing the RIS Deployment Mode and CIW Process" (ACIRIS_08.doc), if you did not do so in "Defining User Input" earlier in this chapter.