Contents

1.0 Introduction
1.1 Reading this Document 1.2 Overview 1.3 Definitions 1.3.1 What is Microsoft Windows Deployment Service (WDS)? 1.3.2 What is the Microsoft Windows Automated Installation Kit? 1.3.3 What is the Preboot Execution Environment? 1.3.4 What is a ks.cfg File? 1.3.5 What are the initrd.img and vmlinuz Files?

4
4 4 4 4 4 4 4 5

2.0 Deployment Infrastructure Overview

2.1 Overview 2.2 Pre-requisites 2.3 Hardware and Software Requirements

5
5 5 5

3.0 Preparing the Automated Deployment

3.1 Configuration Overview 3.2 Running the win2k302 Installation and Configuration Scripts

7
7 8

4.0 ESX Scripted Deployments

4.1 Overview 4.2 ESX 3.5 Basic Scripting 4.2.1 Using the ks.cfg File 4.3 ESX 4.0 Basic Scripting 4.3.1 Root Password 4.3.2 Network Configuration 4.3.3 Using the ks.cfg File

8
8 8 9 9 10 10 10

5.0 Advanced Scripting

5.1 ks.cfg %pre Section 5.1.1 Example Script: Using the %pre Section 5.2 ks.cfg %post Section 5.3 Example Script: Using the %post Section (ESX 3.x) 5.3.1 What is the rc.local File? 5.3.2 %post Section A 5.3.3 %post Section B 5.3.4 %post Section C 5.3.5 %post Section D 5.3.6 Example Script: postinst01.sh 5.3.7 The Full Process 5.4 Example Script: Using the %post Section (ESX 4.x) 5.4.1 ESX 4.x %post Section Modifications

11
11 11 12 13 13 13 13 14 14 14 14 14 15

6.0 The Xtravirt Build Method

6.1 Demonstration 6.2 Detailed Explanation and Steps 6.2.1 The xtravirtmethodks.cfg File: Overview 6.2.2 The xtravirtmethodks.cfg File: %pre Section 6.2.3 The xtravirtmethodks.cfg File: Common Section 6.2.4 The xtravirtmethodks.cfg File: Host Specific Kickstart Commands 6.2.5 The xtravirtmethodks.cfg File: Individual %post Scripts 6.3 Adding a New Host

16
16 17 17 18 18 19 19 19

Appendix A
A1 Using DHCP Reservations to Allocate IP Addresses to ESX Hosts A2 Sample Code A2.1 Create a vSwitch A2.2 Delete a vSwitch A2.3 Create a Port Group A2.4 Delete a Port Group

20
20 22 22 22 22 22

A2.5 Configure a VLAN ID for a Specific Port Group A2.6 Remove a VLAN ID for a Specific Port Group on a vSwitch A2.7 Configure a VLAN ID for all Port Groups on a vSwitch A2.8 Remove a VLAN ID for all Port Groups on a vSwitch A2.9 Link a Network Adaptor to a vSwitch A2.10 Un-link a Network Adaptor from a vSwitch A2.11 Configure a Logon Message (for SSH Connections) A2.12 Configure MOTD Message A2.13 Configure Firewall A2.14 Permit Root Logon via SSH A2.15 Add a Local Account A2.16 NTP Configuration

22 22 22 23 23 23 23 24 24 24 25 25

Appendix B: Manual WDS\IIS Configuration

B1 Creating a Basic Windows PE Image File B2 Installing WDS, FTP Components (Manually) B3 Install IIS and Create FTP Site B4 Configure WDS Services B5 Adding Support for ESX3.5 B5.1 Configuring the Boot Menu B5.2 Creating the ESX 3.5 Distribution Point B5.3 Testing a PXE Boot Installation of ESX 3.5 B6 Adding Support for ESX 4.0 B6.1 Enable ESX 4.0 Boot Menu B6.2 Creating the ESX 4.0 Distribution Point B6.3 Adding Scripted Build Support to ESX 3.5 B7 Adding Support for ESX 4.0 B7.1 Adding Scripted Build Support to ESX 4.0

26
26 26 27 27 28 28 29 30 30 30 31 31 31 31

1.0 Introduction
1.1 Reading this Document
The following standards are used throughout this document. To view the embedded videos, Acrobat 6.0 or higher is required, and may require installation of the Adobe Flash plugin. 1. Sample text
# Sample text

Indicates an action is required, eg: install or configure a component An example, used to illustrate a concept

1.2 Overview
This e-book discusses scripted builds for VMware ESX Server, including optional usage of Microsoft WDS server to deploy a scripted ESX build using PXE boot. Whilst many resources for VMware ESX Server deployment already exist, this guide delves much deeper into scripted technologies, which allow automated provisioning with flexible scripted builds. Although this guide has been written with a focus on ESX4, ESX3.5 is also covered. The e-book also documents the Xtravirt build methodology. This is a custom approach which has enabled many of our customers to rapidly provision ESX servers to a consistent and standardised level. The following table outlines each chapter and its purpose and context.
Chapter Description E-book overview and key definitions Manual tasks to create an automated deployment environment Run scripts provided with e-book to configure the automated deployment environment How to use ks.cfg files for scripting, and steps to take for a basic configuration Examples of advanced scripting for ks.cfg files Explanation of an Xtravirt build methodology and how to apply it

Key scripts are provided in the correct file format within a downloadable iso rather than copy/pasting from the e-book. Information about use of the .iso is provided in Chapter 3. The concepts in this book are discussed at an advanced level and assumes the reader has experience of VMware ESX Server, and familiarity of scripting and Microsoft WDS.

Installation Kit (WAIK) is a collection of tools written by Microsoft. The tools are provided to aid customers deploying Windows. The toolkit provides tools to create and edit images, the Windows Pre-installation Environment (Windows PE), the Windows System Image Manager and many more.

1.3 Definitions
1.3.1 What is Microsoft Windows Deployment Services (WDS)?
Windows Deployment Services (WDS) is a network-based installation technology provided by Microsoft. It is the successor of Microsofts legacy Remote Installation Services (RIS). WDS aids customers in deploying Windows Vista, Windows Server 2008, Windows 2003 Server and Windows XP. WDS deploys disked based images using the proprietary Microsoft WIM format. WDS utilizes PXE boot, resulting in images which can be deployed rapidly to multiple machines simultaneously. WDS is a role included in all editions of Windows Server 2008 and was added to Windows 2003 Server with the introduction of Service Pack 2. It is also shipped within the free of charge Microsoft WAIK toolkit.

1.3.3 What is the Preboot Execution Environment?

The Preboot Execution Environment (PXE) is an environment that can be used to boot computers to a network-connected state, regardless of type or hardware. The environment is booted over the network across the network adaptor. PXE functionality must be supported by the machine BIOS and network adaptor. All modern machines generally support PXE; and always check that it is enabled in the BIOS when configuring these types of environments.

1.0 2.0 3.0

1.3.4 What is a ks.cfg File?

A ks.cfg (kickstart) file provides configuration information for the Linux installer process. The Linux installer process is used to install ESX on to the target hardware. Typically a manual installation requires user input at the console, ie: to provide partitioning information and configure regional settings. The ks.cfg provides preset answers resulting in an automated installation, often referred to as scripted installation, scripted build or unattended build.

4.0 5.0 6.0

The appendices in this book also provide additional scripting samples and manual configurations should the reader choose not to use the automation scripts provided.

1.3.2 What is the Microsoft Windows Automated Installation Kit?

The Microsoft Windows Automated

1.3.5 What are the initrd.img and vmlinuz Files?

The initrd.img or initial ram disk is a file system that is used to boot a Linux file system. The vmlinuz file contains the system kernel. These files are used during the installation process.

2.0 Deployment Infrastructure Overview

2.1 Overview
The deployment platform is based upon a compact virtualization infrastructure - see Figure 2-1. This setup can be achieved using a physical environment or a mixture of both. For the purposes of this scenario, a PC which meets a minimum hardware specification has been used.
Figure 2-1: Deployment Infrastructure Overview Name Hardware Compatibility Guest Operating System Role(s) IP Address Subnet Mask DNS & Gateway Memory Hard Disk CD/DVD Network Adaptor Processors Domain Name DHCP/DNS Information Start IP Address End IP Address Limited to Scope Options 003 Router 006 DNS Servers 015 DNS Domain Name DNS Information Required Software 192.154.30.1 192.154.30.1 <user specified> Forward and reverse lookup zones should be created None 192.154.30.220 192.154.30.254 1 Hour(s) win2k301 Workstation 7 Windows 2003 Server R2 (with SP2) Windows Domain Controller, DHCP, DNS 192.154.30.1 255.255.255.0 192.154.30.1 384MB 40GB (not pre-allocated) Yes, connected Connected to host only VMNET 1 <user specified>

2.2 Pre-requisites
Three virtual machines are required to be created before proceeding. The specifications for the 3 virtual machines are outlined in tables within Section 2.3. All VMs should be created at this point. VM 3 will be the target for the scripted deployment.

2.3 Hardware and Software Requirements

The minimum requirements consist of a PC with 3GB RAM and AMD-V / Intel VT enabled processor, with at least 20GB of free disk space VMware Workstation 7, Windows 2003 SP2 R2, ESX 3.x, ESX 4.x media, and the Microsoft Windows Table 2-1: The virtual machine will require Active Directory, DNS and DHCP roles installed and configured.

Table 2-1: Virtual Machine 1 - win2k301

Name Hardware Compatibility Guest Operating System Role(s) IP Address Subnet Mask DNS & Gateway Memory Hard Disk 1 Hard Disk 2

win2k302 Workstation 7 Windows 2003 Server R2 (with SP2) Windows WDS and IIS FTP Server 192.154.30.2 255.255.255.0 192.154.30.1 384MB 40GB Operating System (not pre-allocated) 40GB for WDS and FTP repositories (not pre-allocated) Note: This must have the Windows drive letter E: assigned

Automated Installation Kit (Microsoft WAIK). Note that all IP addresses referred to in this document are based on the scenario outlined. You may require or choose to use alternative IP addressing. Next Steps 1. Install VMware Workstation on a PC 2. Create and configure VMs win2k301, win2k302 & esxtest - see Tables 2-1, 2-2, 2-3 3. Ensure that the pre-requisite software for win2k302 is installed before proceeding further, or subsequent steps will fail For the esxtext VM(Table 2-3), the VMNET switch should be a host only connection. For this scenario the connection should not be running any DHCP services provided by VMware Virtual Networking and should be confirmed before proceeding. If DHCP is enabled on the virtual network then it should be disabled as VM1 (win2k301) will be providing DHCP. The status of any VMNET can be checked in the VMware Virtual Network Editor.

Network Adaptor Processors Domain Member Required Software

Connected to host only VMNET 1 Yes Microsoft Dot Net Framework 2.0, Microsoft MSXML 6 (provided in learning_materials.iso) Microsoft WAIK toolkit (download the latest version from Microsoft)

Table 2-2: Virtual Machine 2 - win2k302

Name Hardware Compatibility Guest Operating System Role(s) IP Address Subnet Mask DNS & Gateway Memory Hard Disk CD/DVD Network Adaptor Processors Domain Member Table 2-3: Virtual Machine 3 - esxtest

esxtest Workstation 7 VMware ESX / ESX Server 4.0 ESX Server (deployed via scripted build) <assigned by DHCP> <assigned by DHCP> <assigned by DHCP> 2048MB 40GB (not pre-allocated) Connected Connected to host only VMNET 1 No

3.0 Preparing the Automated Deployment

3.1 Configuration Overview
Virtual machine 2 (win2k302) requires additional Windows components, folders and files. Accompanying this e-book is an iso file named learning_materials.iso containing a scripted installation of all of the components, as well configuration of folders and files. These scripts carry out the tasks illustrated in Figure 3-1. Follow the steps in the next section to apply the scripts provided.

Figure 3-1: Win2k302 Scripted Configuration Process

Once complete, the PXE boot environment, FTP deployment repository and initial PXE boot menu will have been configured. ESX 3.5 and ESX 4.0 files are copied to the FTP repository location. Note: The above tasks can be carried out manually if you do not wish to use the scripts. The manual process can be found in Appendix B.

3.2 Running the win2k302 Installation and Configuration Scripts

These scripts will carry out the installation of required Windows components. Once complete the server will reboot. When next logged on, the configuration process will continue. Follow the onscreen prompts when required to provide media for ESX3.5 and ESX4.x - see Video 3-1; note, to enlarge the video, adjust the size from the Adobe PDF View menu. Next Steps 1. Ensure all prevous pre-requisites have been completed. Connect the learning_ materials.iso file to the win2k302 VM.

2. Copy the CD contents to the root of the E: drive. 3. Once copied, disconnect the learning_ materials.iso and connect the CD to the Windows 2003 Standard Server R2 (with SP2) ISO CD 1 (not provided). 4. Open a command prompt by entering cmd.exe from the Start -> Run dialogue 5. Change the working directory to the E: drive and then enter the following command (typed as one line - refer Figure 3-2):
cscript.exe 1_Install_Deployment_ Server.vbs

4.0 ESX Scripted Deployments

4.1 Overview
This chapter discusses scripted deployment methology for both ESX 3.5 and ESX4. It walks through basic concepts and how to apply them.

4.2 ESX 3.5 Basic Scripting

Below shows the contents of a sample ks.cfg file for ESX 3.5. Each command is commented to provide information on its use.
# specify ftp path to esx35 media url --url ftp://192.154.30.2/esx35 # specify the root password rootpw xtravirt # specify use of MD5 and shadow passwords file auth --useshadow --enablemd5 # specify location of the boot loader bootloader --location=mbr # Set timezone timezone --utc Europe/London # Skip skipx # Perform an install install # Run install in text mode text # Use US English language lang en_US # Use US English language langsupport --default en_US # Use UK Keyboard keyboard uk # Dont use a mouse mouse none # Reboot at the end of the install reboot # Disable firewall during kickstart process firewall disabled # Accept the VMware provided EULA vmaccepteula %packages @ base %post

Figure 3-2: Start Installation and Configuration Script

Video 3-1: Win2k302 Scripted Configuration Demonstration

Example 4-1: Sample ESX3.5 ks.cfg

4.2.1 Using the ks.cfg File

Using the contents of the example41.txt file provided, support can be added for a scripted build to the WDS PXE boot system. Next Steps 1. Create a new ks.cfg file and name it ks.cfg 2. Copy the contents of the example41.txt file to it. Save and close. 3. Copy ks.cfg file to E:\ftp_deployment\ esx35\

The APPEND line passes commands and syntax to the Kernel during boot. These include the following:
initrd esx text ks ksdevice=eth0
specifies the boot image to use installer boots in text mode location of ks.cfg file specifies which physical NIC to use as service console during installation

Powering on the esxtest VM and selecting the ESX 3.5 Scripted (ks.cfg) option will initiate a semi-unattended installation of ESX 3.5 (you will be prompted for network and disk information). Note: If the PXE boot fails, ie: no menu displayed, ensure that the WDS services are running correctly on the win2k302 VM.

An option needs to be provided so that during the PXE boot process a user can select the scripted installation method. The next steps show how to add an additional item to the boot menu. Note: The PXE boot menu is stored in a file called default, located in E:\ remoteinstall\Boot\x86\pxelinux. cfg\

4.3 ESX4 Basic Scripting

Below shows the contents of a sample ks.cfg file for ESX 4.0. Each command is commented to provide information on its use.
# Accept the ESX License Agreement accepteula # Configure authentication for the host. Enables shadow password file and MD5based passwords authconfig --enableshadow --enablemd5 # Configure the bootloader. Sets the location to be the Master Boot Record of the disk bootloader --location=mbr # Removes all partitions on the first disk and overwrite existing VMFS partition clearpart --firstdisk --overwritevmfs # Partitioning Section - create partitions of sizes and types part /boot --fstype=ext3 --size=2000 --onfirstdisk part storage1 --fstype=vmfs3 --size=10000 --grow --onfirstdisk part None --fstype=vmkcore --size=100 --onfirstdisk # Creates the vmdk on the cos vmfs partition. virtualdisk cos --size=5000 --onvmfs=storage1 # Partitions the virtual disk. part / --fstype=ext3 --size=3040 --grow --onvirtualdisk=cos part swap --fstype=swap --size=256 --onvirtualdisk=cos # Allows all incoming connections via the ESX firewall during installation firewall --allowIncoming # Specifies the type of installation. URL = network install, network path to install files install url ftp://192.154.30.2/esx40 # Specify Keyboard Layout keyboard uk

Next Steps 1. Edit the default file using WordPad or similar. Add the following text to the end of the file. Entries are single continuous lines where shown wrapped.
LABEL ESX35A MENU LABEL ESX3.5 Scripted (KS.CFG) KERNEL linux/vmlinuz-esx35 APPEND initrd=linux/ initrd-esx35.img esx text ks=ftp://192.154.30.2/esx35/ ks.cfg ksdevice=eth0

The LABEL tag provides a unique name for this menu item. The MENU LABEL tag specifies the text that the user sees on the menu during the PXE boot process. The KERNEL tag specifies which Kernel to boot when this item is selected. In this case this is the ESX 3.5 kernel file copied during the scripted configuration process.

# Specify Timezone timezone --utc Europe/London # Tell the installer to automatically reboot after the install is complete reboot # Configure the root Password (can be optionally encrypted) rootpw xtravirt # Configure Network to obtain IP address and information from DHCP server network --bootproto=dhcp %pre %post

Example 4-2: Sample ESX4 ks.cfg

10

The script in Example 4-2 provides enough information for a partially automated installation of ESX4. However, there are a number of other optional entries which can provide additional configuration.

4.3.1 Root Password

The root password is provided in the sample file in plain text. This presents an obvious security risk should an unauthorised person obtain the file.
# Configure the root Password (can be optionally encrypted) rootpw xtravirt

Example 4-3: Plain text password

The root password can be encrypted in the ks.cfg file so that it cannot be read. The encrypted password can be generated from an ESX console - refer http://xtravirt.com/ xd10083. However, if you do not have an installation of ESX, there is a free MD5 password generator utility which can create an encrypted password. The utility runs on Windows systems and can be downloaded from http://xtravirt.com/xd10097.

Figure 4-1: If ESX hosts require a static IP address, then multiple ks.cfg files are typically needed

# configure Network to use static IP address, DNS and provide hostname Network static device=vmnic0 ip=192.154.30.200 gateway=192.154.30.1 nameserver=192.154.30.1 hostname=esxtest

An option is required during the PXE boot process to allow a user to select the scripted installation. To do this we add an additional item to the boot menu. Note: The PXE boot menu is stored in a file called default, located in E:\ remoteinstall\Boot\x86\pxelinux. cfg\ Next Steps 1. Edit the default file using WordPad or similar. Add the following text to the end of the file. Entries are single continuous lines where shown wrapped.
LABEL ESX40A MENU LABEL ESX4.0 Scripted (ks. cfg) KERNEL linux/vmlinuz-esx40 APPEND initrd=linux/ initrd-esx40.img text ks=ftp://192.154.30.2/esx40/ ks.cfg mem=512M url=ftp://192.154.30.2/esx40

Example 4-5: Static network configuration

4.3.2 Networking Config.

This script instructs the ESX installer to obtain an IP address leased from a DHCP server for the service console. For evaluation or testing purposes this is acceptable, however in a production environment it is typical to specify a static IP.
# configure Network to obtain IP address and information from DHCP server network --bootproto=dhcp

When using static IP addresses it soon becomes apparent that a ks.cfg file is required per server - see Figure 4-1. However there are alternative scripting techniques that can be used to counter this, and will be covered in later sections. The ESX and Virtual Center installation guide from VMware lists compatible ks.cfg scripting commands.

Example 4-4: ESX DHCP IP addressing

4.3.3 Using the ks.cfg File

Using the contents of the example42.txt file provided, support can be added for a scripted build to the WDS PXE boot system. Next Steps 1. Create a ks.cfg file and name it ks.cfg 2. Copy the contents of the example42.txt file to it. Save and close. 3. Copy ks.cfg to E:\ftp_deployment\ esx40\

To configure a static IP address the following information is required:

--ip --netmask --gateway --nameserver --hostname --device
ESX Server service console IP Subnet mask Defaul gateway DNS server IP address. Only one can be specified at this stage FDQN hostname The physical NIC to assign to the service console

The LABEL tag provides a unique name for this menu item. The MENU LABEL tag specifies the text that the user sees on the menu during the PXE boot process. The KERNEL tag specifies which Kernel

11

to boot when this item is selected. In this case this is the ESX 4 kernel file copied during the scripted configuration process. The APPEND line passes commands and syntax to the Kernel during boot. These include the following:
initrd esx text ks mem url
Specifies the boot image to use Installer boots in text mode Location of ks.cfg file Memory to allocate to the installer Path to the ESX 4.x installation files (RPMS)

Powering on the esxtest VM will now display a new PXE boot menu item. When selected an unattended installation of ESX 4 will begin.

Figure 5-1: Overview of the ks.cfg processing model

5.0 Advanced Scripting

5.1 ks.cfg %pre Section
Although the sample ks.cfg file is sufficient to automatically deploy a generic ESX host, we can also inject unique personality for a server, eg: hostname, IP address. Through this customization there are also advanced techniques to minimise the number of ks.cfg files needed. In the ks.cfg sample files you may have noticed two tags in the file:
%pre %post

The %pre section instructions are executed prior to loading the operating system on the host server. Due to this, only a handful of commands can be executed. Although this may seem limited, the %pre section is actually very useful.

5.1.1 Example Script: Using the %pre Section

The following example allows custom information to be automatically added to the ESX server configuration during deployment. Using only the hostname, the ks.cfg file can install the server using a pre-allocated static IP address as well as providing DNS, gateway and subnet mask. In this example scenario the hostname of the ESX server is host1. The example script in Example 5-1 provides the code to insert in the %pre section of a ks.cfg file which will set the network configuration of an ESX server where the hostname is host1.
%pre < /proc/cmdline sed s/ /\n/g | grep ^myop_name > /tmp/boot_parameters . /tmp/boot_parameters if [[ $myop_name = host1 ]]; then echo network --bootproto=static --device=vmnic0 --ip=192.154.30.100 --gateway=192.154.30.1 --netmask=255.255.255.0 nameserver=192.154.30.1 --hostname=host1 >> /tmp/xtravirt.network else echo network --bootproto=dhcp >> /tmp/xtravirt.network fi

Any command in the %pre section is executed before all other instructions in the ks.cfg file. Commands in the %post section are read and carried out after all other commands in the ks.cfg have been executed. Note: The location of the %pre and %post sections must be at the end of all other instructions in the ks.cfg file.

Example 5-1: %pre section automation of ESX Server IP configuration

When host1 is PXE booted using this method, the PXE boot menu appears, and provides an option to select the ESX4.0 Scripted (ks.cfg) option. Pressing the tab key displays a line of text beneath the menu. This is the command line that is going to be executed by the installer as seen in Figure 5-2. All commands passed to the installer are automatically and temporarily stored in a file called /proc/cmdline. By simply typing commands on to the end of this line, further instructions can be passed to the installer. These can then act as a trigger for considerable installation configuration automation.

12

For example, adding the following command to the existing line - see Figure 5.2.
myop_name=host1

Example 5-2: Adding a hostname at installation command line

When the administrator presses enter the installer starts the installation process. After processing the ks.cfg file it proceeds to execute the instructions in the %pre section. The instructions in the %pre section read all of the command line parameters. If a parameter was passed called myop_name as in the example, then it checks the value to see if it is equal to host1.
if [[ $myop_name = host1 ]]; then

Figure 5-2: Passing additional commands to the installer

entry for networking:

# Configure Network to obtain IP address and information from DHCP server network --bootproto=dhcp

Example 5-3: Code snippet of hostname check (refer Example 5-1)

If the value matches, a string of text is written to a file called xtravirt.network located in /tmp
>> /tmp/xtravirt.network

Example 5-6: Default ks.cfg networking configuration

Under this solution it has been replaced with the following:

# Obtain networking settings from the /tmp/xtravirt.network file %include /tmp/xtravirt.network

Example 5-4: Code snippet of output to /tmp file (refer Example 5-1)

Note: --hostname=host1 entry can be a FQDN if required, e.g. host1. xtravirt.lab The string of text contains the ks.cfg networking script with all required syntax to set hostname, IP address, subnet mask, gateway and DNS server address. If the value is anything other than host1 then a different string is written to the file, configuring the host to use DHCP to obtain IP information.
else echo network --bootproto=dhcp >> /tmp/xtravirt.network fi

Example 5-7: Modified ks.cfg networking configuration

This instructs the installer to read the contents of the /tmp/xtravirt.network file and execute them. The %pre section can easily be amended to take in to account multiple hosts by adding further information as per Example 5-8. This %pre script contains entries for 2 different hosts: host1 and host2. Naturally this method can be scaled to as many hosts as needed, up to several hundred or more and only ever require one ks.cfg file, albeit a potentially long one. Reducing the configuration to a single ks.cfg for many hosts reduces management and complexity of ESX server deployments as well as deployment times.

%pre < /proc/cmdline sed s/ /\n/g | grep ^myop_name > /tmp/boot_ parameters . /tmp/boot_parameters if [[ $myop_name = host1 ]]; then echo network --bootproto=static --device=vmnic0 --ip=192.154.30.100 --gateway=192.154.30.1 --netmask=255.255.255.0 --nameserver=192.154.30.1 --hostname=host1 >> /tmp/xtravirt. network elseif [[ $myop_name = host2 ]]; then echo network --bootproto=static --device=vmnic0 --ip=192.154.30.101 --gateway=192.154.30.1 --netmask=255.255.255.0 nameserver=192.154.30.1 --hostname=host2 >> /tmp/xtravirt. network else echo network --bootproto=dhcp >> /tmp/xtravirt.network fi

Example 5-8: Automating multiple hosts

Additional command line instructions can be used in this manner to further refine scripted installations providing greater levels of managed flexibility.

5.2 ks.cfg %post Section

The %post section is executed once the %pre and standard ks.cfg sections have been read and processed. This module is useful for configuring scripts to run following the next reboot, or run commands that were not available during the %pre or standard ks.cfg sections.

Example 5-5: Code snippet of default DCHP configuration (refer Example 5-1)

The ks.cfg instructions outside of the %pre and %post sections are then executed. In this scenario the ks.cfg file default networking section has been amended. Originally the ks.cfg file had the following

Advert

13

The following sub-sections outline how the %post section could be used historically with ESX 3.x installations, and how this has been improved upon with ESX 4.x.

5.3 Example Script: Using the %post Section (ESX 3.x)

The following example enables a script to run upon start up following the automatic reboot at the end of the ESX installation process. To do this, the rc.local file is temporarily renamed and a replacement one is created in order to protect the original. Instructions are written in to this copy; examples being creation of local folders, allow SMB traffic through the ESX firewall, connect to an SMB share, and copy a script file to the local file system. Under this solution we configure the %post section into four key sections - see Figure 5-4.

Figure 5-3: Xtravirt ks.cfg %post 4-section process for ESX3.x

specific commands) have completed. In Windows terms it is similar to placing commands in the Start-up folder on the Windows start menu.

%post # Save a copy of rc.local cp /etc/rc.d/rc.local /etc/rc.d/ rc.local.sav

5.3.2 %post Section A

Section A begins by telling the installer that the %post section exists in the ks.cfg file. Following the %post statement, the Linux cp (copy) command is used to create a backup of the original rc.local file.

Example 5-9: Code snippet of %post rc.local backup/copy (refer Figure 5-4)

5.3.1 What is the rc.local File?

The rc.local file is common to most Linux distributions including ESX Server. The rc.local contents are executed after specific boot actions (referred to as run-level

The rc.local file is located in the /etc/rc.d folder. It is copied to the same location, in this example appending .sav to the end of the filename.

5.3.3 %post Section B

Section B writes instructions into the rc.local file, which will be executed following next reboot of the host.
# Set up rc.local cat >> /etc/rc.d/rc.local << EOF1 mkdir /tmp/script mkdir /tmp/mount esxcfg-firewall -e smbClient mount -t smbfs //192.154.30.250/ postbuild /tmp/mount -o username=in staller/192.154.30.250,password=xt ravirt1 cp /tmp/mount/* /tmp/script/

Example 5-10: Code snippet of %post Section B - writing next instructions (refer Figure 5-4)

Figure 5-4: %Post install section of our KS.CFG file

The Linux cat command is used to write information in to the rc.local file. The >> symbols mean that all text from this point onwards will be appended to the rc.local file. Text will continue to be written until it reaches the text EOF1. The mkdir (make directory) command is used to create two subfolders under the /tmp folder, one

14

called script the other called mount. The esxcfg-firewall command is run to enable the smbClient exception. This will allow smb traffic to pass through the firewall. Next, the Linux mount command is used to mount (or in Windows terms, map a network drive) the postbuild folder, on 192.154.30.250 to the /tmp/mount folder on the host. A username and password are specified to authenticate with the target device. Finally, the contents of the mounted folder, /tmp/mount/ are copied to the local host under /tmp/script/. Within the folder is the file postinst01.sh.

5.3.6 Example Script: postinst01.sh

The following simple example script postinst01.sh creates a virtual switch (vSwitch1) and links it to a separate physical network adaptor (nic 1). Note: The code snippet below assumes that the physical nics exist in the machine.
# Post ESX Server install configuration # Configure VM Production Network vSwitch setlabvswitch() { # Create vSwitch (vswitch1), create a portgroup (LAB), connect nic1 to it esxcfg-vswitch -a vSwitch1 esxcfg-vswitch A LAB vSwitch1 esxcfg-vswitch -L vmnic1 vSwitch1 } # Call function setlabvswitch shutdown -r now exit 0

Configure NTP Configure VMotion Add local user accounts Configure network policies Configure login banners Install and configure 3rd party hardware agents

5.3.7 The Full Process

Assuming the ks.cfg has been created correctly with the %pre and %post sections as well as SMB share and contents then the total build process would deploy as per Figure5-5.

5.3.4 %post Section C

Section C makes the contents of the /tmp/ script folder executable.
# Make script executable chmod +x /tmp/script/

5.4 Example Script: Using the %post Section (ESX 4)

The major development in ESX 4 is that almost all of the native ESX console commands are available during the ESX 4.x installer phase, meaning that additional commands are available during the time that the %post section is executed. This is as opposed to writing out the commands in a script file as per ESX 3.x and waiting for reboot- see Section 5.3. This reduces time and complexity of ESX deployments. The amended ks.cfg file would look like the example in Example 5-14. We can see that a second reboot command is no longer required, and the installer will reboot the host once the %post section is complete. An example %pre section code has also been included for completeness. The %post section code in Example 5-14 assumes that the physical nics exist in the machine.

Example 5-11: Code snippet of %post Section C - set execute permissions to instructions (refer Figure 5-4)

The Linux chmod command is used to mark the contents of the script folder as executable. This includes the postinst01. sh file.

Example 5-13: Code snippet of post installation script

5.3.5 %post Section D

The final part of the %post section runs the postins01.sh file and tells cat to stop writing to the rc.local file.
# Set postinst01.sh to run after reboot /tmp/postinstall/scripts/postinst01. sh EOF1

Most commands that can be executed at the ESX console can be used in the postinst01.sh script. As always, building a non-production ESX host and then testing out commands at the console is advisable before deploying to a live environment. Common tasks that can be carried out by the postinst01.sh script may include the following: Configure firewall rules (inbound / outbound exceptions) Configure networking (virtual switches, port groups, vlans, hostname, DNS)

Example 5-12: Code snippet of %post Section D - set instructions to run upon next reboot (refer Figure 5-4)

Figure 5-5: The complete build process including %pre, %post and postinst01.sh script

15

# Accept the ESX License Agreement accepteula # Configure authentication for the host - enable shadown password file and MD5based passwords authconfig --enableshadow --enablemd5 # Configure the bootloader - set the location to be the Master Boot Record of the disk bootloader --location=mbr # Remove all partitions on the first disk and overwrite existing VMFS partition clearpart --firstdisk --overwritevmfs # Partitioning Section - create partitions of sizes and types part /boot --fstype=ext3 --size=2000 --onfirstdisk part storage1 --fstype=vmfs3 --size=10000 --grow --onfirstdisk part None --fstype=vmkcore --size=100 --onfirstdisk # Create the vmdk on the cos vmfs partition. virtualdisk cos --size=5000 --onvmfs=storage1 # Partition the virtual disk. part / --fstype=ext3 --size=3040 --grow --onvirtualdisk=cos part swap --fstype=swap --size=256 --onvirtualdisk=cos # Allow all incoming connections via the firewall firewall --allowIncoming # Specifies the type of installation - URL = network install, network path to install files install url ftp://192.154.30.4/esx40 # Specify Keyboard Layout keyboard uk # Specify Timezone timezone --utc Europe/London # Tell the installer to automatically reboot after the install is complete reboot # Configure the root Password (can be optionally encrypted) rootpw xtravirt # Obtain networking settings from the /tmp/xtravirt.network file %include /tmp/xtravirt.network %pre < /proc/cmdline sed s/ /\n/g | grep ^myop_name > /tmp/boot_parameters . /tmp/boot_parameters if [[ $myop_name = host1 ]]; then echo network --bootproto=static --device=vmnic0 --ip=192.154.30.100 --gateway=192.154.30.1 --netmask=255.255.255.0 nameserver=192.154.30.1 --hostname=host1 >> /tmp/xtravirt.network else echo network --bootproto=dhcp >> /tmp/xtravirt.network fi %post # Create vSwitch (vswitch1), create a portgroup (LAB), connect nic1 to it esxcfg-vswitch -a vSwitch1 esxcfg-vswitch A LAB vSwitch1 esxcfg-vswitch -L vmnic1 vSwitch1

interpreter you wish to use for each statement. Errors generated from incorrect statements in %post section can be configured to be ignored or have the script stop processing if an error is found. For specific information on the %post section, see the VMware ESX and vCenter Server Installation Guide. Although the %pre section executes prior to ESX package installation, the %pre section can execute statements for Bash and Python. Perl is not supported natively.

6.0 The Xtravirt Build Method

The Xtravirt Build method is the culimination of experimention and experience. This section describes the architecture of the Xtravirt solution, and all files and configurations have been prepackaged into the learning_materials.iso file packaged with this download. It is not intended to dictate the best method of deployment, more as another option, and is built upon the following ideals: Deployment of consistent configuration across all ESX hosts (example, vSwitches, portgroups) Enable quick and simple addition of new host builds to the delivery mechanism As much hands off time as possible Deployment through PXE boot process using WDS

For the purposes of this scenario, the following assumptions are made The only unique information per host is as follows: Disk partitioning requirements Hostname Service console IP address, netmask, nameserver, gateway

Example 5-14: Sample ESX4 ks.cfg with direct %post commands

5.4.1 ESX 4 %post Section Modifications

The %post section commands that can be used under ESX 4.x provide greater flexibility than in previous versions. At the time that the %post section statements are executed, the ESX packages have been installed. These include the Python, Perl and Bash interpreters. The %post section can make use of all of the interpreters as you can specify which

16
Each host requires a host.cfg file. This file contains the unique footprint for each host. The host.cfg file contains the following information: Disk partitioning requirements Hostname Service console IP address, netmask, nameserver, gateway

Additionally each ESX host requires a host.vmotion file which contains VMotion configuration information for each host. Note: The Xtravirt Build Method is aimed at ESX 4 installations. ESX 3 can be catered for, but is not covered in this document.

6.1 Demonstration
This section is a pre-cursor to the detailed explanation in Section 6.2 and is used to demonstrate the solution over 3 embedded videos in this e-book. To ensure consistency when creating new host configuration files, we wrote a utility to prompt the administrator for key information - hostname, service console IP address and VMotion IP address - see Video 6-1. Once a unique host.cfg file and host VMotion file have been created by the utility, the target server can be PXE booted. At the Xtravirt installation menu the hostname of the target buildserver displays. An unattended build process then initiates - see Video 6-2. All common configurations are carried out by various scripts which execute at this time. Once the server has completed configuration it reboots and the ESX Operating System loads. The only configuration task carried out by the scripted installation process at this point is to enable VMotion. VMotion cannot be correctly configured during the previous boot stage as specific modules are not available. Once the server has finished booting, a connection to the host can be made. The configuration performed by the scripted install can be viewed in Video 6-3.
Video 6-2: Installation Demonstration Video 6-1: Installer Utility Demonstration

Note: To enlarge the video, adjust the zoom from the Adobe PDF View menu.

17

6.2 Detailed Explanation and Steps

The build mechanism is composed of 3 primary components - see Figure 6-1.
xtravirtmethodks.cfg hostx.cfg Post cfg
Contains common configuration data that is pushed to every ESX host that is built Contains specific unique information per host These files carry out specific configuration tasks

The files are all hosted in a folder structure in the FTP repository. The xtravirtmethodks.cfg file is stored in the root of the esx40 folder for simplicity. The individual hostx.cfg files are stored in the hostcfgs folder, which is a subfolder of esx40. The post configuration files are stored in the postcfgs folder, which is also a subfolder of the esx40 folder.
Video 6-3: vMotion Configuration

6.2.1 The xtravirtmethodks.cfg File: Overview

Traditionally administrators have created multiple ks.cfg files, one for each host. This creates an administrative overhead and increases the risk of error in each file especially where making multiple updates. The Xtravirt build method utilises a single ks.cfg file to store all common configuration items and control the installation process. Utilising this build method promotes consistency, and in most cases, once scripted customizations are in place, such as vSwitches, port groups, enabling VMotion etc, there is less liklihood of ongoing modification. When adding a new host to the build method the risk of creating an error is reduced and the speed of adding the new hosts into the build is greatly improved. It may be that in your environment the virtualization administrator wont always be the one adding new hosts. Therefore the more simplistic it is for anyone to add new hosts the easier it is to delegate these tasks. If all that needs adding is a single

Figure 6-1: Xtravirt Build Method Folder Architecture

18

line with the networking information and hostname there will be a reduced risk of error. Many hosts will often utilize the same gateway, netmask and nameservers. This means that the information required to add an additional host in to the method is often only hostname and IP address. The xtravirtmethodks.cfg file is composed of 4 main parts - see Figure 6-2:
%pre Common Host specific kickstart commands %post scripts
Carries our tasks that are required to make the build process work Contains kickstart commands to be processed Runs the specific hostx. cfg file Calls each individual post configuration script file

When the xtravirtmethodks.cfg file is processed, the sections are executed in order.

6.2.2 The xtravirtmethodks.cfg File: %pre Section

The %pre section carries out the following tasks: Reads the command line syntax that was passed to the installer Locates the value of the name= key that was passed and stores as $name variable Creates the folder /tmp/ xtravirtscripts From the ftp server, downloads $name.cfg, eg: host1.cfg, to /tmp/ xtravirtscripts/host.cfg From the ftp server, downloads $name.vmotion (example, host1. vmotion to /tmp/xtravirtscripts/ vmotion.cfg Downloads the following additional scripts from the ftp server o o o o o vswitches.cfg banners.cfg localaccounts.cfg ntp.cfg rootlogon.cfg
Figure 6-2: Key Sections of the xtravirtmethodks.cfg file

6.2.3 The xtravirtmethodks.cfg File: Common Section

The common section carries out the following tasks: Accepts the VMware EULA Enables shadow and md5 password handling Configures the bootloader location as the master boot record Sets firewall to allow incoming connections Configures the installation source as the ftp server

Sets the keyboard to UK layout (change this to your own regional setting) Sets the time zone to UTC Europe / London (change this to your own timezone) Tells the installer to reboot when completed Configures root password to xtravirt - change password as required

Once the common section has completed, the %include script host.cfg located at /tmp/xtravirtscripts/host.cfg is executed.

19

Next Steps 1. Open a command prompt window 2. Change directory to E:\ftp_deployment\ esx40\hostcfgs\ 3. Run the following command: cscript.exe newconfig.vbs
Figure 6-3: Sequential Execution of the xtravirtmethodks.cfg File

4. When prompted, enter the hostname, service console IP address and VMotion IP address

6.2.4 The xtravirtmethodks. cfg File: Host Specific Kickstart Commands

The host.cfg file carries out the following tasks - see Figure 6-4: Cleans and partitions the disks in the target server Configures hostname, service console IP address, gateway, nameserver, netmask and disables the creation of the default virtual machine port group

%include /tmp/xtravirtscripts/ vmotion.cfg. Creates a file to run after the next reboot to enable VMotion

The contents of each file should be reasonably explanatory.

Once complete, simply boot the new ESX host using PXE and select the scripted installation option, providing the hostname. Next Steps 1. PXE boot the host that you wish to build 2. At the PXE menu highlight the ESX4.0 (Xtravirt Method) option, press tab and enter name=your_hostname, where your_hostname is the hostname you entered previously. 3. Press Enter

6.3 Adding a New Host

To add a new host, a new host specific configuration needs to be generated. A visual basic script has been included in the learning materials which can do this automatically. Note: If you wish to use alternative IP addressing to that used in this e-book, edit the E:\ftp_deployment\ esx40\hostcfgs\host_template.cfg, and amend the gateway and nameserver IP addresses. Also modify E:\ftp_deployment\esx40\ xtravirtmethodks.cfg, amending any 192.154.30.2 IP addresses to the IP address of your own WDS/ File server.

6.2.5 The xtravirtmethodks.cfg File: Individual %post Scripts

The post scripts section calls individual scripts in sequence. Each script carries out specific configuration tasks: %include /tmp/xtravirtscripts/ vswitches.cfg. Configures virtual switches, portgroups and vlans %include /tmp/xtravirtscripts/ banners.cfg. Configures banners and MOTD %include /tmp/xtravirtscripts/ntp.cfg. Configures ntp settings %include /tmp/xtravirtscripts/ localaccounts.cfg. Creates various local accounts and configures sudo access %include /tmp/xtravirtscripts/ rootlogon.cfg. Enables root access via ssh

The new host will now run the Xtravirt build method applying the unique information you provided, eg: hostname, service console IP address, VMotion IP and any other customizations. Note: If an incorrect hostname is found then the installation will fail.

Figure 6-4: host.cfg File

20

Appendix A
A1 Using DHCP Reservations to Allocate IP Addresses to ESX Hosts
DHCP reserved IP addresses are distributed to hosts based on an IP to MAC address relationship. A reservation for a physical server is created in the DHCP scope by providing the MAC address of the network adaptor and the IP address you wish to assign. With ESX we assign the IP address to the service console, so the reservation actually needs to be created using the MAC address of vswif0. It is not possible to specify the MAC address for vswif0 as part of the scripted build process. The MAC address is created by the ESX installer during the installation process. The reservation will need to be created post installation. This introduces a two stage process.

Figure A-1: Using DHCP reservations requires a staged approach to allocating the final IP address

During stage 1, the ESX host boots up and obtains a free IP address on a lease from the DHCP server. The IP address is chosen from the scope range. The server will build using this assigned IP address. Once the server is built, the administrator can logon to the ESX console and obtain the MAC address for vswif0. Note: The ifconfig vswif0 command can be used to obtain the MAC address

Figure A-2: Obtaining the vswif0 MAC address (00:50:56:41:CC:B8)

21

Once the vswif0 MAC address has been obtained a reservation can be created in the DHCP scope. Once the reservation is created, reboot the ESX host to obtain the allocated IP address.

Figure A-3: Creating a reservation in DHCP

This two stage process may seem long winded. However, it has multiple benefits: Centralised control of the hosts IP address, subnet mask, gateway address and DNS address. If a static IP address is allocated through the KS.CFG file, multiple files need to be edited in the console (or alternatively through the GUI) to change it (as well as DNS, gateway and subnet mask information). To change any information with this method, simply update the reservation and reboot the host Centralised recorded information of IP addresses for each ESX host (within the DHCP console)

Note: If this method is used, the host will be built with a name of localhost. A further script could be run to change the name of the host which could be called from the %post section of the KS.CFG file.

22

A2 ESX 4 Sample Code

This section contains script examples for common tasks that can be performed during %post section processing.

A2.1 Create a vSwitch

Creates a vSwitch (vSwitch1)
esxcfg-vswitch a vSwitch1

A2.2 Delete a vSwitch

Deletes a vSwitch (vSwitch1)
esxcfg-vswitch d vSwitch1

A2.3 Create a Port Group

Adds a portgroup (called LAB) to an existing vswitch (vSwitch1)
esxcfg-vswitch A LAB vSwitch1

A2.4 Delete a Port Group

Deletes a portgroup (called LAB) from an existing vSwitch (vSwitch1)
esxcfg-vswitch D LAB vSwitch1

A2.5 Configure a VLAN ID for a Specific Port Group

Configures a VLAN (vlan 101) for a specific portgroup (called LAB) on an existing vSwitch (vSwitch1)
esxcfg-vswitch p LAB -v 101 vSwitch1

A2.6 Remove a VLAN ID for a Specific Port Group on a vSwitch

Removes a configured VLAN (vlan 101) for a specific portgroup (called LAB) on an existing vSwitch (vSwitch1)
esxcfg-vswitch p LAB -v 0 vSwitch1

A2.7 Configure a VLAN ID for all Port Groups on a vSwitch

Configures a VLAN (vlan 101) for all portgroups on an existing vSwitch (vSwitch1)
esxcfg-vswitch p ALL -v 101 vSwitch1

23

A2.8 Remove a VLAN ID for all Port Groups on a vSwitch

Removes a configured VLAN (vlan 101) for all portgroups on an existing vSwitch (vSwitch1)
esxcfg-vswitch p ALL -v 0 vSwitch1

A2.9 Link a Network Adaptor to a vSwitch

Links a nic (nic1) to an existing vSwitch (vswitch1)
esxcfg-vswitch L vmnic1 vSwitch1

A2.10 Un-link a Network Adaptor from a vSwitch

Un-links a nic (nic1) from an existing vSwitch (vswitch1)
esxcfg-vswitch U vmnic1 vSwitch1

A2.11 Configure a Logon Message (for SSH Connections)

Configures a logon message to be displayed for users that connect to the ESX host using a SSH connection
Setsshbanner() { touch /etc/ssh/ssh_banner cat >> /etc/ssh/ssh_banner << EOF1 ************************************************************************* Hostname: \n No. of logged in users: \u By logging on to this IT system you are agreeing to be bound by the terms of company XYZ. ************************************************************************* EOF1 cat >> /etc/ssh/sshd_config << EOF2 Banner /etc/ssh/ssh_banner EOF2 cat >> /etc/issue << EOF3 ************************************************************************* Hostname: \n No. of logged in users: \u By logging on to this IT system you are agreeing to be bound by the terms of company XYZ. ************************************************************************* EOF3 service sshd restart }

24

A2.12 Configure MOTD Message

Configures the MOTD to be displayed for users that connect to the ESX host
SetMOTD() { touch /etc/motd cat >> /etc/motd << EOF1 ************************************************************************* By logging on to this IT system you are agreeing to be bound by the terms of company XYZ. You have logged on to \n ************************************************************************* EOF1 }

A2.13 Configure Firewall

Enables services to traverse the ESX firewall. In this example the setfirewall() subroutine is called, which enables the required CIM services to pass through the firewall
setfirewall() { /usr/sbin/esxcfg-firewall --enableService CIMHttpsServer /usr/sbin/esxcfg-firewall --enableService CIMHttpServer /usr/sbin/esxcfg-firewall --enableService CIMSLP }

A2.14 Permit Root Logon via SSH

Uses the vi editor to search and replace the PermitRootLogin no statement to PermitRootLogin yes. This enables remote ssh access via the root account. After editing the file the firewall is configured to allow the sshServer access. Finally, the sshd (ssh daemon) is restarted to complete the changes. The sample code is called by calling the subroutine Permitsshrootlogon()
Permitsshrootlogon() { vi +%s/PermitRootLogin no/PermitRootLogin yes/g|wq /etc/ssh/sshd_config esxcfg-firewall -e sshServer service sshd restart }

Warning: Allowing remote SSH access in a production environment should not be enabled. A separate account should be used to connect, then where applicable SUDO or SU commands should be used to elevate privileges if required.

25

A2.15 Add a Local Account

Adds 3 local accounts to the ESX host. Each users password is encrypted for security. The username does not contain spaces (for example, pauldavey) whilst the friendly name does (for example, Paul Davey)
Addlocalaccounts() { useradd -p 5f4dcc3b5aa765d61d8327deb882cf99-c Paul Davey pauldavey useradd -p 5f4dcc3b5aa765d61d8327deb882cf99 -c Joe Bloggs joebloggs useradd -p 5f4dcc3b5aa765d61d8327deb882cf99 -c Andy Smith andysmith cat >> /etc/sudoers << eof pauldavey ALL=(ALL) ALL joebloggs ALL=(ALL) ALL andysmith ALL=(ALL) ALL eof }

A2.16 NTP Configuration

Configures NTP settings for an ESX host, ensures that NTP traffic can traverse the ESX firewall and restarts the NTP daemon
Configurentp() { echo restrict 127.0.0.1 > /etc/ntp.conf echo restrict default kod nomodify notrap noquery nopeer >> /etc/ntp.conf echo server 0.win2k301.xtravirt.lab >> /etc/ntp.conf echo fudge 127.127.1.0 stratum 10 >> /etc/ntp.conf echo driftfile /var/lib/ntp/drift >> /etc/ntp.conf Create the Step-Tickers File echo server 0.win2k301.xtravirt.lab >> /etc/ntp/step-tickers esxcfg-firewall -e ntpClient service ntpd start }

26

Appendix B: Manual WDS\IIS Configuration

B1 Creating a Basic WindowsPE Image File
1. 2. Once the Microsoft Windows AIK toolkit has been installed, click Start -> Programs -> Microsoft Windows AIK -> Windows PE Tools Command Prompt. At the command prompt enter the following command
copype x86 C:\ebook_disk

Figure B-1: Creating a basic Windows PE Image File

3.

Looking in the c:\ebook_disk directory, the .WIM file can be found.

B2 Installing WDS, FTP Components (Manually)

The WDS role needs to be installed on to the win2k302 server. This section outlines the process to accomplish this. 1. Add the Windows Deployment Services Role to the server from Add/Remove programs -> Windows Components

Figure B-2: Installing the WDS Role

2.

When prompted, reboot the server

27

B3 Install IIS and Create an FTP Site

1. 2. Create a file called iis_components.inf file in the root of the C: drive on the server Add the following contents to the file
[Components] iis_common = ON iis_www = ON iis_www_vdir_scripts = ON iis_inetmgr = ON iis_ftp = ON

3.

Open a command prompt and run the following:

Sysocmgr.exe /i:%windir%\inf\sysoc.inf /u:c:\IIS_components.inf

4. 5. 6. 7.

Open the Internet Information Services (IIS) Manager from Administrative Tools From under the FTP sites folder, stop the default FTP site and delete it. Right-click FTP Sites and select New -> FTP site Create a new FTP site with the following details:
Description: ftp deployment point IP: All Unassigned, port 21 Do not isolate users Path: E:\ftp_deployment Read permissions

8.

Close Internet Information Services (IIS) Manager

B4 Configure WDS Services

1. 2. 3. Open Windows Deployment Services from Administrative Tools Expand servers, highlight your server, right-click and select Configure Server Configure WDS using the following details:
Path: E:\remoteinstall Policy: Respond to all (known and unknown) client properties

4.

In the Windows Deployment Services console, right-click Boot Images and add the winpe_basic.wim file, located in the C:\ ebook_disk folder.

Figure B-3: Adding a boot image in to WDS

28
5. Right-click the server and select Properties. From the Advanced tab, ensure the following is enabled
Yes, I want to authorize the Windows Deployment Services server in DHCP

B5 Adding Support for ESX 3.5

B5.1 Configuring the Boot Menu
From the ESX3.5 media, copy and rename the following files
isolinux\vmlinuz copy to E:\remoteinstall\boot\x86\linux\ vmlinuz-esx35 isolinux\initrd.img copy to E:\remoteinstall\boot\x86\linux\ initrdesx35.img

In the E:\remoteinstall\boot\x86\pxelinux.cfg folder create a file called default.

Figure B-4: Create and edit the default file

Edit the default file and add the following text:

DEFAULT menu.c32 TIMEOUT 100 PROMPT 0 MENU WIDTH 60 MENU MARGIN 10 MENU ROWS 10 MENU TABMSGROW 18 MENU CMDLINEROW 18 MENU ENDROW 24 MENU TIMEOUTROW 20 MENU TITLE Xtravirt Installation Menu LABEL Xtravirt WAIK PE (x86) MENU LABEL Xtravirt WAIK PE (x86) KERNEL pxeboot.0 LABEL ESX35M MENU LABEL ESX3.5 Manual Install KERNEL linux/vmlinuz-esx35 APPEND initrd=linux/initrd-esx35.img

From the Windows Deployment Services console, select the server, right-click and select Properties. From the Boot tab, amend the Default boot program to point to the Boot\x86\pxelinux.0 file.

29

Figure B-5: Configuring the default boot programs in the WDS console

Close the Windows Deployment Services console

B5.2 Creating the ESX 3.5 Distribution Point

In the E:\ftp_deployment folder do the following
Create a folder called esx35 Copy the entire contents of the ESX35 media in to the E:\ftp_deployment\ esx35 folder

Ensure that you can browse via FTP to the E:\ftp_deployment folder.

Figure B-6: Ensure ftp browsing to the distribution point works fine

30

B5.3 Testing a PXE Boot Installation of ESX 3.5

PXE boot your test virtual machine (press F12 at the BIOS screen to select network boot) At the PXE boot men, select the ESX3.5 Manual GUI Install entry

Figure B-7: Test the PXE boot installation of ESX 3.5

The ESX installation process will start. Follow the installation wizard using the following details when prompted Installation Method: FTP Configure TCP/IP: Use dynamic IP configuration (BOOTP/DHCP) FTP site name: 192.154.30.100 Red Hat directory: esx35/ Follow the installation wizard to install ESX 3.5 on your test server

B6 Adding Support for ESX 4.0

B6.1 Enable ESX 4.0 Boot Menu
From the ESX4.0 media, copy and rename the following files: isolinux\vmlinuz copy to E:\remoteinstall\boot\x86\linux\ vmlinuz-esx40 isolinux\initrd.img copy to E:\remoteinstall\boot\x86\linux\ initrd-esx40.img Edit the E:\remoteinstall\boot\x86\pxelinux.cfg\default file and add the following:
LABEL ESX4M MENU LABEL ESX4.0 Manual Install KERNEL linux/vmlinuz-esx4 APPEND initrd=linux/initrd-esx40.img text mem=512M askmedia

31

B6.2 Creating the ESX 4.0 Distribution Point

In the E:\ftp_deployment folder do the following: Create a folder called esx40 Copy the entire contents of the ESX40 media in to the E:\ftp_deployment\esx40 folder

B6.3 Adding Scripted Build Support to ESX 3.5

To add a scripted installation file (ks.cfg) file Create your ks.cfg file Copy the ks.cfg file to the E:\ftp_deployment\esx35\ Add an additional entry in to the pxelinux.cfg\default file LABEL ESX35A

MENU LABEL ESX3.5 Scripted (KS.CFG) KERNEL linux/vmlinuz-esx35 APPEND initrd=linux/initrd-esx35.img esx text ks=ftp://192.154.30.2/esx35/ks.cfg ksdevice=eth0

Note: Ensure your KS.CFG file specifies the URL to the ESX35 installation files.

url --url ftp://192.154.30.4/esx35

B7 Adding Support for ESX 4.0

B7.1 Adding Scripted Build Support to ESX 4.0
To add a scripted installation file (ks.cfg) file Create your ks.cfg file Copy the ks.cfg file to the E:\ftp_deployment\esx40\ks.cfg Add an additional entry in to the pxelinux.cfg\default file

LABEL ESX4A MENU LABEL ESX4.0 Scripted (KS.CFG) KERNEL linux/vmlinuz-esx4 APPEND initrd=linux/initrd-esx40.img text ks=ftp://192.154.30.4/ esx40/ks.cfg mem=512M url=ftp://192.154.30.4/esx40

Note: Ensure the ks.cfg file specifies the URL to the ESX40 installation files.
Example: install url ftp://192.154.30.4/esx40