JCMD Lab

Customizing an ESXi 4.0 Installation

noreply@blogger.com (JC) — Wed, 03 Feb 2010 15:41:00 +0000

While there is little you can do as far as customizing an ESXi 4 installation, its worth the effort to do what you can :D. After some "googling" and a little Python training I have done a few things to the build to help speed things up.

DISCLAIMER: This information is provided "As-Is" and use at your own risk. Always, ALWAYS - test in your environment before commiting to Production!

Step 1 - What's up with all these screens?

First action is to get rid of some of the opening screens such as the Welcome and EULA. I found guidance for this at vinternals.com which explains it very well. Basically, if you look on the media in the root directory you will see a few .tgz files. The one we're interested in is "install.tgz" which contains the Python installation scripts (among other things). Extract this file and the main Python file we want to modify is "/usr/lib/vmware/installerThinESXInstall.py".

Find the line that says:

Steps = [ WelcomeStep, LicenseStep, TargetSelectionStep, ConfirmStep,\
          WriteStep, PostConfigStep, CompleteStep, RebootStep ]

which is each main step the installation follows. We want to get rid of the time consuming stuff (minor as that may be). So change the code to say:

Steps = [ TargetSelectionStep, WriteStep, PostConfigStep, RebootStep ]

As you can see, we've removed the Welcome, License, Confirm, and Complete steps. Hey, every keystroke counts - right?

Step 2 - SAN Isolation

The next modification I did was to make it "SAN safe" which means we don't want to have to physically disconnect the SAN storage just to install ESXi (a problem with ALL ESX versions). To do this with ESX required modifying a LOT of files but with ESXi it's actually quite simple.

Basically, I don't want the TargetSelectionStep showing any fibre channel devices during installation. To do this we'll need to add ONE LINE of Python code to the TargetSelectionStep section. The vinternals post referenced above provided the path/filename which is also in the install.tgz file as well - "/usr/lib/vmware/installer/ThinESX/Dialogs/DeviceSelectionDialog.py". The section we want is in in the "class TargetList(list)". What we're going to do is simply not add the FC disks to the selection list so the administrator won't even see them as a target.

Find these lines:

textWidget = TargetTextWidget(text, target, consolePath)
textList.append(urwid.AttrWrap(textWidget, color, selectedColor))

and add the following line so it now looks like this:

if diskType != "fc":
   textWidget = TargetTextWidget(text, target, consolePath)
   textList.append(urwid.AttrWrap(textWidget, color, selectedColor))

You'll notice there's no closing statement for IF. Threw me at first too but it's actually cool. Python uses INDENTING for code blocks. So when you add the IF statement be sure to indent the two lines or you'll get some "interesting" results :D

If you wanted to restrict the target list to a specific disk type (i.e. the local SAS drives) you could change the IF statement to suite your environment (i.e. if diskType == "sas": ). I build on various servers with both sas and scsi so simply not showing the SAN storage is sufficient.

Note: some FC cards will still present LUNS as local devices even though they are on a SAN so be sure to test in your environment. Whatever shows up under the "diskType" heading in the list is what ESXi thinks it is so handle accordingly.

Step 3 - Not So Fast on the Install!

Now let's get rid of the timer at the install screen! I found this especially annoying since ESXi does NOT eject the media after installation (?!?!?!). So if you're not WATCHING - ESXi will install, reboot, then reinstall after the timer runs out. Anyway, this is simple enough to do. Edit the "isolinux.cfg" file which is located in the root directory of the media and comment out "timeout 80" on line 3 (i.e. #timeout 80). I also change the menu title on line 2 but that's a cosmetic/internal thing :D

Step 4 - Scripting All of This

Finally, we need to put all of this back together as a new ISO. I have a script to do this which contains a few folders with the modified files (/icustom), script (/iscripts), and source iso (isource). The script creates some temporary folders to mount the source iso, copy everything off to another folder, extract/update/recreate the install.tgz, update the isolinxu.cfg file, then build the new iso. This assumes the modified .py and isolinux.cfg files are in the /icustom folder ready to be inserted. If you run this script provided below, all the extracted files will still be available after the first run to allow you to grab/modify what you need and put in the /icustom folder. Uncomment the "Cleaning up..." section at the bottom and they'll be whipped out at the end to help conserve disk space.

The Script:

#!/bin/bash

TIMESTAMP=`date +%F_%H%M`
ISOFILE="ESXi4U1-$TIMESTAMP.iso"

cd /

clear
echo -n "Creating working directories..."
if [ ! -d cdrom ]; then
  mkdir /cdrom
fi

if [ ! -d iwork ]; then
  mkdir /iwork
fi
chmod 777 /iwork
rm -rf /iwork/*

if [ ! -d iinstall ]; then
  mkdir /iinstall
fi
chmod 777 /iinstall
rm -rf /iinstall/*

echo "Done"

echo -n "Mounting CD..."
mount -o loop /isource/ESXi-4.0.0-update1.iso /cdrom
echo "Done"

echo -n "Copying content from ESXi 4 CD..."
cp -rp /cdrom/* /iwork
umount /cdrom
echo "Done"

echo -n "Uncompressing install.tgz image..."
cd /iinstall
tar -xzf /iwork/install.tgz
echo "Done"

echo -n "Copying custom files into install.tgz image..."
cp -f /icustom/ThinESXInstall.py /iinstall/usr/lib/vmware/installer
cp -f /icustom/DeviceSelectionDialog.py /iinstall/usr/lib/vmware/installer/ThinESX/Dialogs
echo "Done"

echo -n "Creating custom install.tgz..."
tar -czf install.tgz *
echo "Done"

echo -n "Copying new files to media..."
cp -f /iinstall/install.tgz /iwork
cp -f /icustom/isolinux.cfg /iwork
echo "Done"

echo -n "Creating new ISO image..."
cd /iwork
mkisofs -l -J -R -r -T -o /$ISOFILE -b isolinux.bin -c boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table /iwork &> /dev/null
echo "DONE"

#echo -n "Cleaning up..."
#cd / 
#rm -dRf /cdrom
#rm -dRf /iwork
#rm -dRf /iinstall
#echo "Done"

echo
echo "*** ISO IMAGE ($ISOFILE) CREATED ***"
echo

Enjoy and Good Luck!

Changing AD Forest Tombstone Lifetime with PowerShell v1

noreply@blogger.com (JC) — Sun, 20 Dec 2009 19:11:00 +0000

Recently an issue came up where the domain controllers had been offline for a few months and they were inoperable. Research initially indicated that the tombstone lifetime defaulted to 180 days so this was quite odd considering it had definitely NOT been more that this time period. With some digging it was discovered there is a "bug" in the W2K3 EE R2 media that actually changes the default from 180 to 60 days - this occurs when the second "R2" disk is installed. Microsoft's fix is SP2 but this is true only if SP2 is applied AFTER the OS is installed. We had slipstreamed SP2 onto the first R2 distribution disk (which is really just W2K3 EE).

A detailed explanation can be found here but it basically works out like this:

• If you install a W2K3 server from the first CD from the W2K3 R2 distribution set, then promote it to a DC and then install the R2 binaries from the second CD, the tombstone lifetime is set to 180 days

• If you install a W2K3 server from the first CD from the W2K3 R2 distribution set, then install the R2 binaries from the second CD and then promote it to a DC, the tombstone lifetime is set to 60 days!

The manual fix is easy enough (ADSI Edit) but we needed to do this as part of our automation effort using PowerShell v1 (v2 has the Set-ADObject cmdlet).

Here's the PS v1 code:

$root = [ADSI]""
$ds = [ADSI]("LDAP://CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration," + $root.DistinguishedName)
$ds.Put("tombstoneLifeTime","180")
$ds.SetInfo()

If you want a different time period than change 180 to the desired value.

You can also make the change using LDIFDE (included on every Windows 2003 Server).

Create a text file that looks like this and save as "tslt.ldf":

dn: CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=4BCT25ID,DC=DS,DC=ARMY,DC=SMIL,DC=MIL
changetype: modify
replace: tombstoneLifetime
tombstoneLifetime: 180
-

(the dash "-" on the last line is required)

Then run the following command on the domain controller with Schema Master FSMO role:

ldifde -v -i -f c:\tslt.ldf

and this will apply the change to the domain. This change will replicate to all the domain controllers.

etc/hosts file disappears

noreply@blogger.com (JC) — Mon, 30 Nov 2009 23:07:00 +0000

While working on a Powershell script to add web frontends to an existing SharePoint 2007 farm I decided to see what it would take to have a dedicated server for crawling (indexing). I went ahead and made the change through Central Admin first (to make sure it worked) and then just happened to check the event logs and found a LOT of errors - a new one every two minutes. Whenever I see the same error every two minutes I immediately think "TIMER JOB"! Well, it seems that as soon as I selected a dedicated frontend for crawling the HOSTS file disappeared!?!?!? How odd!

So, of course, the first thing we all do - GOOGLE IT!

The original post that addresses this problem can be found here.

Bottom line: the wss_admin_wpg local group (which contains the timer job service account) needs write/modify permissions to the ../drivers/etc directory. The reason this error doesn't usually come up is most people use the MOSS Admin account for all the services and it usually has local administrator rights to start with. But if we follow "Least Privilege" rules and use a separate account for this AND specify a dedicated frontend - then the problem will surface.

Now to figure out how to use stsadm.exe to specify a dedicated web frontend. :D