Although the Remote Installation Services (RIS) image we created in my previous article, Setting up workstations with RIS, is certainly usable, it isn't practical for large-scale client deployments. This is because the Setup process will prompt whoever is sitting at the client machine to answer all the usual questions (enter your product key, select your time zone, etc.).
There are three ways to install an operating system onto a client computer using RIS: a standard installation, a scripted installation or an image-based installation. Although Windows refers to the configuration we previously created as a RIS image, it is considered a standard installation because it's really nothing more than a network-bootable copy of the Windows installation CD.
This article will show you how to turn that standard installation into a scripted installation. Intimidated by the idea of writing scripts? Don't worry. The script used by RIS isn't a true script, but an answer file that conforms to the INI file format that's been around since Windows 3.1. Best of all, you don't even have to create this answer file yourself; Windows creates it automatically. All you do is fill in the blanks.
Windows actually creates this empty "script" as a part of a standard RIS deployment image. When we created the initial image, the default location for the image was in a directory named RemoteInstall. Assuming you went with this default location, the script is located at \RemoteInstall\Setup\English\Images\your image name\i386, and its filename is RISTNDRD.SIF. Here is what this file looks like:
[data]
floppyless = "1"
msdosinitiated = "1"
OriSrc = "\\%SERVERNAME%\RemInst\%INSTALLPATH%\%MACHINETYPE%"
OriTyp = "4"
LocalSourceOnCD = 1
DisableAdminAccountOnDomainJoin = 1
[SetupData]
OsLoadOptions = "/noguiboot /fastdetect"
SetupSourceDevice = "\:Device\LanmanRedirector\%SERVERNAME%\RemInst\%INSTALLPATH%"
[Unattended]
OemPreinstall = no
FileSystem = LeaveAlone
ExtendOEMPartition = 0
TargetPath = \WINDOWS
OemSkipEula = yes
InstallFilesPath = "\\%SERVERNAME%\RemInst\%INSTALLPATH%\%MACHINETYPE%"
LegacyNIC = 1
[UserData]
FullName = "%USERFIRSTNAME% %USERLASTNAME%"
OrgName = "%ORGNAME%"
ComputerName = %MACHINENAME%
[GuiUnattended]
OemSkipWelcome = 1
OemSkipRegional = 1
TimeZone = %TIMEZONE%
AdminPassword = "*"
[Display]
BitsPerPel = 16
XResolution = 800
YResolution = 600
VRefresh = 60
[Networking]
[NetServices]
MS_Server=params.MS_PSched
[Identification]
JoinDomain = %MACHINEDOMAIN%
DoOldStyleDomainJoin = Yes
[RemoteInstall]
Repartition = Yes
UseWholeDisk = Yes
[OSChooser]
Description = "Windows Professional"
Help = "This will install Windows Professional in a standard configuration."
LaunchFile = "%INSTALLPATH%\%MACHINETYPE%\templates\startrom.com"
ImageType = "Flat"
The file's contents will vary a bit, depending on the version of Windows the image is based on. In this case, the image was based on XP Professional with Service Pack 2 slipstreamed into it. But even if you have created an image based on a different version of Windows, most of the following techniques should still work.
Many of the lines in the script are fill-in-the-blanks. But if you decide to go beyond the basics, things can get complicated. I'm going to first explain the basics and assume you've never modified an INI file before. Then I'll move to more advanced scripting techniques.
Three command types
The script above contains a lot more than three commands. However, each line in the file falls into one of three command types: section header commands, fill-in-the-blank commands and binary commands. If you plan on performing even the most basic modifications to this script, you need to understand how these command types work.
Section header commands are a way of grouping commands that have similar functions. Section headers are always enclosed in brackets. Near the middle of the script above is a section header named [Display]. This is the script's way of telling Windows that the lines that follow are related to parameters like screen resolution, refresh rate and color depth.
There is no command that tells Windows it has reached the end of a section. Instead, Windows assumes that all the commands that follow are a part of that section until Windows encounters either another section header or the end of the file.
Fill-in-the-blank commands (I have no idea what the technical name for these types of commands are, or if Microsoft has a technical name for them) are the types of commands that you can directly modify to change the way that the Windows deployment works. The [Display] section is a good example of these types of commands. The script above contains the following lines:
BitsPerPel = 16
XResolution = 800
YResolution = 600
VRefresh = 60
These four commands work together to set the display resolution of the Windows desktop to 800x600 with a 16-bit color depth and a 60Hz refresh rate. A look at the lines of code above shows that you can manipulate these settings just by filling in the blank with a different value. To use a 32-bit color depth rather than 16-bit, just change the number 16 to 32.
Binary commands (again, this is my own name for them) are similar to fill-in-the-blank commands. The only real difference is that the command's value will either be zero or one. Windows interprets a binary value of zero as no or disabled, a value of one as yes or enabled.
Binary commands are not used extensively. In the script above, binary commands are used primarily to provide a semi-automated Windows deployment. If you've ever installed XP, you know you have to answer a lot of questions as part of the installation process. Some of these questions are important, such as the ones that ask for the product key. But some of the Setup Wizard's other questions aren't important. For example, there's no reason why you should have to look at the Welcome screen and then press a key when you're done reading it. If you've got hundreds of PCs to set up, you don't care about the Welcome screen.
This is where binary commands come into play. The first command in the [Guiunattended] section is OemSkipWelcome = 1. The binary value 1 tells the Setup Wizard not to display the Welcome screen. If you changed the command's value to zero, the Welcome screen would be displayed. There are a few other places in which the default script uses binary commands to automate portions of the deployment process.
Now it's time to begin modifying the script. In my next article, you'll learn some basic modifications you can make without having an advanced knowledge of Windows scripting.
About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server, Exchange Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. He writes regularly for SearchWinComputing.com and other TechTarget sites.
More information on this topic:
