Designing a Lite-Touch Deployment (part 3) - Customizing Target Deployments

4. Customizing Target Deployments

The previous section describes the basic LTI deployment process, but at first glance, many administrators would not consider the interaction required to be especially light. In fact, there is quite a bit of interaction involved, and performing the entire sequence on hundreds of computers can be nearly as tedious and time-consuming as installing Windows 7 manually. Fortunately, MDT 2010 provides a method for automating the deployment process even further.

4.1. Using CustomSettings.ini

CustomSettings.ini is the main configuration file for MDT 2010. Each deployment share has its own CustomSettings.ini file, located in the Control folder. Target computers read the file when they load the Windows Deployment Wizard, and the settings inside control the behavior of the wizard and the deployment process.

The format of CustomSettings.ini is the same as most Windows Configuration files. Section headings are enclosed in square brackets, and properties under each heading are separated from their values by equal signs, as in the following sample:

[Heading]
Property=value

Many of the properties that CustomSettings.ini supports take binary values in the form of YES or NO, such as SkipProductKey=YES. Others take alphanumeric values, such as AdminPassword=Pa$$w0rd.

Note:

EXPRESSING BINARY PROPERTY VALUES

CustomSettings.ini properties that take the binary values YES and NO must use uppercase text for the values, as in the following example:

SkipAdminPassword=YES

This is so that the deployment scripts running on the target computers can properly process the values.

When you create a deployment share, the New Deployment Share Wizard creates a CustomSettings.ini file, based on your responses to the wizard’s prompts. For example, if you select the Ask User For A Product Key check box, the wizard adds the SkipProductKey=NO command to the CustomSettings.ini file. Later, when the Windows Deployment Wizard running on the target computers reads that command, it causes the wizard to suppress the appearance of the Specify The Product Key Needed To Install This Operating System page.

A typical default CustomSettings.ini file contains the following commands:

[Settings]
Priority=Default
Properties=MyCustomProperty

[Default]
OSInstall=Y
SkipAppsOnUpgrade=YES
SkipCapture=NO
SkipAdminPassword=NO
SkipProductKey=NO

The SkipCapture, SkipAdminPassword, and SkipProductKey commands correspond to the Allow Image Capture, Allow Admin Password, and Allow Product Key pages in the New Deployment Share Wizard, reflecting the responses you supplied when creating the share. If you ever want to change these defaults, you can simply modify the commands in CustomSettings.ini by changing the NO values to YES.

You can edit the CustomSettings.ini file manually, using Notepad or any other text editor, but you can also view and edit the file in Deployment Workbench. To access CustomSettings.ini for a particular deployment share, right-click the share in Deployment Workbench and, from the context menu, select Properties. When the Properties sheet for the deployment share appears, select the Rules tab, as shown in Figure 17.

In addition to modifying the existing commands in a CustomSettings.ini file, you can add hundreds of others to customize your deployments. The following sections describe some of the ways in which you can use CustomSettings.ini to reduce the amount of interaction required during a workstation deployment.

Note:

CUSTOMSETTINGS.INI REFERENCE

For a complete list of the properties you can use in a CustomSettings.ini file, along with explanations and examples of their syntax, open the Microsoft Deployment Toolkit Documentation Library help file included with MDT 2010 and browse to the Properties heading in the Microsoft Deployment Toolkit Reference section.

4.1.1. Suppressing Windows Deployment Wizard Pages

In many cases, the interactive pages that appear in the Windows Deployment Wizard are nothing more than chores to the installer sitting at the target computers. For example, if you are deploying 100 computers, all into the same domain, requiring the installer to type the domain name and administrative credentials on every workstation is time-consuming and redundant. Using CustomSettings.ini properties, you can automate the required inputs and suppress the appearance of the Join The Computer To A Domain Or Workgroup page in the Windows Deployment Wizard. The commands you must add to CustomSettings.ini to do this are as follows:

JoinDomain=domain_name
DomainAdmin=domain_administrator_name
DomainAdminPassword=domain_administrator_password
DomainAdminDomain=domain_administrator_domain
SkipDomainMembership=YES

The CustomSettings.ini commands that you can use to replace each of the replaceable pages in the deployment procedure are listed in Table 1.

4.1.2. Grouping Target Computers

When you place commands in the [Default] section of the CustomSettings.ini file, they apply to all target computers that access the deployment share. However, this does not mean that you can’t use CustomSettings.ini commands if you have to assign different property values to some of your computers. You can define groups in a CustomSettings.ini file and assign properties with different values to the computers in each group.

MDT 2010 enables you to group your target computers by location or according to hardware or software attributes. For example, to create groups based on locations in a CustomSettings.ini file, you assign group names to the default gateway addresses of the subnets on your network, as in the following sample:

[Default Gateway]
192.168.1.1=Boston
192.168.2.1=Chicago
192.168.3.1=Seattle

You then create sections named for the groups and place your group-specific properties in those sections. For example, the following commands join the target computers to a different domain depending on the city where they are located:

[Boston]
JoinDomain=boston.example.local
DomainAdmin=Alice
DomainAdminPassword=Pa$$w0rd
DomainAdminDomain=boston.example.local

[Chicago]
JoinDomain=chicago.example.local
DomainAdmin=Ralph
DomainAdminPassword=Pa$$w0rd
DomainAdminDomain=chicago.example.local

[Seattle]
JoinDomain=seattle.example.local
DomainAdmin=Ed
DomainAdminPassword=Pa$$w0rd
DomainAdminDomain=seattle.example.local

4.1.3. Configuring Individual Computers

Some properties require values that must be unique on every computer, such as the OSDComputerName property, which specifies the computer name assigned to a target computer during the Windows 7 installation. To assign properties like these to individual computers, you must create separate sections for each computer in the CustomSettings.ini file. As with the group capabilities, you can use different criteria to identify individual computers, including hardware, software, and user-defined attributes.

For example, to identify target computers using the media access control (MAC) addresses assigned to their network interface adapters, you create a section for each computer named using the six-byte hexadecimal value of its MAC address. Then you add the computer-specific properties into each section, as shown in the following example:

[Settings]
Priority=MACAddress, Default

[00:1a:6b:3c:ba:1f]
OSDComputerName=Wkstn1

[00:0c:29:ab:07:a2]
OSDComputerName=Wkstn2

Note:

DISPLAYING MAC ADDRESSES

To display the MAC address of a Windows computer, open a Command Prompt window and run the Ipconfig.exe program using the /all parameter.

In the [Settings] section, the Priority property specifies the order in which the Windows Deployment Wizard on the target computer should parse the settings in the CustomSettings.ini file. Adding the MACAddress property to the Priority command causes the computers to apply the commands in the MAC address sections first, and then to apply the commands in the [Default] section.

Note:

USING A MICROSOFT SQL SERVER DATABASE WITH MDT 2010

Automating a truly large deployment project using CustomSettings.ini files alone can still be a huge task. For this reason, MDT 2010 also provides the ability to use a SQL Server database to store the settings for individual computers and define group settings as well. Deployment Workbench includes the ability to create and interact with a database on a computer running SQL Server.

4.2. Multicasting LTI Deployments

A large operating system deployment product normally requires the build computer to transmit a separate copy of the captured install image to each target computer. Because these images can run to several gigabytes in size, the amount of network traffic generated by the deployment process can be enormous. Part of your initial planning for your project should include issues such as when you plan to perform the target computer deployment, how much network bandwidth is available, and how many workstations you can safely deploy at the same time.

One way to reduce the amount of network bandwidth the deployment process consumes is to use multicast transmissions to deliver the image files to the target computers. A multicast is a type of TCP/IP transmission that delivers a single copy of the data to multiple destinations. Most TCP/IP transmissions are unicasts, which are transmissions to a single destination, or broadcasts, which are transmissions to all possible destinations. A multicast falls between these two by transmitting to a selected group of destinations—in this case, a group of target computers that you want to receive a single transmission of an image at the same time.

The versions of Windows Deployment Services included in Windows Server 2008 and Windows Server 2008 R2 have multicasting capabilities, and you can use WDS to deploy your captured images directly to target computers using multicasts. However, this method bypasses the MDT 2010 deployment share, which prevents you from using task sequences to control your deployments.

Fortunately, MDT 2010 is capable of utilizing the multicasting capabilities of WDS when transmitting images from its own deployment share. To do this, your build server must be running Windows Server 2008 or Windows Server 2008 R2, and must have Windows Deployment Services, Windows Automated Installation Kit 2.0, and Microsoft Deployment Toolkit 2010 installed and configured. You must also create an MDT 2010 deployment share that uses the share name LTI$.

After configuring WDS and MDT in the usual manner, you configure the deployment share to use multicasting by opening the share’s Properties sheet and, on the General tab, selecting the Enable Multicast For This Deployment Share check box, as shown in Figure 18. Then you must update the deployment share in the usual way to create boot images that support multicasting.

Note:

SUPPORTING MULTICASTING

To use multicasting successfully with MDT 2010, you must be using Windows AIK version 1.1 or later on your build server. This is because earlier versions of Windows AIK include Windows PE boot files that do not support multicasting.

This action in Deployment Workbench triggers the creation of a Multicast Transmission in WDS, as shown in Figure 19. You can then add the MDT 2010 boot images to the Windows Deployment Services console. This process does not add the MDT 2010 install images to WDS, but it does enable the MDT deployment share to use WDS multicasting for its transmissions.

WDS supports two types of multicasting, as follows:

• Auto-cast The server initiates a multicast transmission when an eligible client connects and requests an install image. If, while the transmission is in progress, other clients on the network request the same image, they are added to the multicast group and receive the same transmission as the first client.

• Scheduled-cast The server initiates a multicast transmission when a predetermined number of clients request the same image or when a scheduled date and time occurs. An administrator can also start a scheduled-cast transmission manually.

MDT 2010 supports the creation of only auto-cast multicast transmissions. To use scheduled-cast multicasting, you must deploy your images by using WDS directly, and not through MDT 2010.

To use multicasting effectively, any routers located between the build server and the target servers must support multicasting using the Internet Group Management Protocol (IGMP). Routers that do not support multicasts treat the transmissions as broadcasts, sending them to all of the computers on the network, instead of to only the ones requesting the transmission.

4.3. Practice: Customizing a CustomSettings.ini File

By working with the CustomSettings.ini file, you can automate elements of the LTI deployment process that by default require interaction on each target workstation.

EXERCISE 1 Modifying the Default Commands

A Windows SIM distribution share provides a directory structure in which you can store device drivers and other files you want to deploy to a workstation.

EXERCISE 2 Suppressing Windows Deployment Wizard Pages

Create your own CustomSettings.ini file based on the default commands created by the New Deployment Share Wizard, adding the code needed to accomplish the following tasks.

1. To suppress the Specify Credentials For Connecting To Network Shares page, add commands that supply the credentials needed to access your deployment share, as follows:

   UserID=<user_name>
   UserPassword=<password>
   UserDomain=<user_domain_name>Note Supplying Customized Values

   
   

   Replace the bracketed placeholders in this exercise with values appropriate for your network.

2. To suppress the Join The Computer To A Domain Or Workgroup page, add commands that will join the target computer to your domain, as follows:

   SkipDomainMembership=YES
   JoinDomain=YES
   DomainAdmin=<user_name>
   DomainAdminPassword=<password>
   DomainAdminDomain=<user_domain_name>

   
   

3. To suppress the Specify Where To Save Your Data And Settings and Specify Whether To Restore User Data pages so that the target computers do not capture or restore user state data, add the following command:

   SkipUserData=YES

   
   

4. To suppress the Specify The BitLocker Configuration page and add commands that implement BitLocker on the target computers using TPM and a startup key on drive L, storing the recovery key in Active Directory, use the following code:

   BDEInstall=TPMKey
   BDEInstallSuppress=NO
   BDERecoveryKey=AD
   OSDBitLockerStartupKeyDrive=L:

   
   

5. To suppress the Configure The Computer Name page and add commands to specify the name Client1 for your computer only, based on its MAC address, use the following code:

   [Settings]
   Priority=MACAddress, Default
   
   [<xx:xx:xx:xx:xx:xx>]
   SkipComputerName=YES
   OSDComputerName=Client1