Windows 2003 Release 2 – slipstreaming Service Pack 2

For anyone who has to build Windows servers on a regular basis integration of Service Packs has been pretty much a must have skill for a while now. The reason I say this is we have all been in the situation where a new server is needed now, now meaning 2 days ago… meaning that time is premium and having to apply Service Packs after the build once the server is up and running can slow you down.

Windows 2003 Release 2 offered a slightly newer challenge compared to older versions of Windows, being that it had 2 CD’s. After some googling around I found that the /integrate option of the Service Pack would actually work with both disks. So I extracted both CDs to folders on my computer and ran the integrate command:

WindowsServer2003-KB914961-SP2-x86-ENU.exe /integrate:C:\Temp\W2K3_R2_CD1
WindowsServer2003-KB914961-SP2-x86-ENU.exe /integrate:C:\Temp\W2K3_R2_CD2

This worked without any problem. So I got to thinking, that the second CD is not actually that big, so why not include that with CD1. So I went through the extraction process and put the contents of both CD’s into one folder on my PC. The size of this folder was 763MB, so this would indeed fit on a 800MB CD as well as being a good ISO. You can then integrate the Service Pack with this combined directory either using the command line method of *service pack name*.exe /integrate:*file path* or you could use this handy utility I found called nLite (http://www.nliteos.com/).

nLite is a very useful utility as this allows you not only to slipstream in Service Packs, but also standard Windows Updates, Drivers, add/remove components, unattended options, general options, tweaks (Registry and Services) and it can create a bootable ISO. So if you have to press F6 during the build to install the disk array drivers, nLite can save you this pain. nLite works with Windows 2000, XP and 2003.

I am now using a single disk/ISO Windows 2003 Release 2 (with SP2 and most common array drivers) for both physical builds and VM’s.

VMware ColdClone – Unable to determine Guest OS

So for anyone that has migrated a physical server to a virtual server (P2V’ed), you may well have come across the “Unable to determine Guest OS” message when using the ColdClone CD. For those of you who have not yet migrated a physical server to an ESX Environment I will quickly run through the main two ways you will see…

HotClone – This refers to using the VMware Converter plugin from within VirtualCenter itself. This process is done with the target server up and running, so really should only be used on servers with static data, as during the migration users, other admins, etc will still have access to the server. The pre-requisites are licensing for Converter and the plugin installed and enabled in VirtualCenter.

To initiate a HotClone of a physical server you select the cluster or host ESX server you wish to migrate the server to, now right click and select Import Machine… The wizard will then start and guide you through the process of importing the machine. I am not going to go into detail about the HotClone process as I am going to move onto the ColdClone process as this is where you will see the error I mentioned.

ColdClone – Considered the safest form of migrating a physical server to a VM. This is mainly due to the fact that the server is effectively down during the migration process. The ColdClone process uses a bootable ISO image, to bring the server up in WinPE that runs VMware Converter. So as with a standard installation of Windows, the drivers included in the base build may not be relevant to the hardware you are using.

So the “Unable to determine Guest OS” is, from my experience, normally due to WinPE not being able to access the harddisks. In most cases this will be due to the Array driver not being part of WinPE.

Included with the ColdClone.iso (which is available to download from http://www.vmware.com/, providing you have the Enterprise license for Converter) is the PETOOL.EXE. This can add drivers to WinPE, however I have had mixed results using this so I have also got a manual way of doing it, which I will now detail.

Step 1 - Download the required drivers
Depending on your hardware vendor download their drivers for the Array Controller, you will need the driver that would be used during the text phase of a Windows server, the same driver that you would use the F6 option during the Windows installation process.

Step 2 – Extract the driver files
Once the download has completed extract the drivers to a folder on your computer.

Step 3 – Extract the ColdClone.iso
Extract the contents of the ColdClone.iso to a local folder on your computer.

Step 4 – Create the driver folder
Browse to \i386\System32\Drivers in the extracted ISO. Create a folder for your driver, e.g. PERC.

Step 5 – Add the drivers
Now copy the drivers to the folder you just created.

Step 6 – Edit winpeoem.sif
Browse to \i386\System32 and edit winpeoem.sif in a text editor, e.g. Notepad. Now find the following lines in the file:

[OemDriverParams]
OemDriverRoot= "drivers"
OemDriverDirs= vmscsi, Adaptec, Emulex, QLogic

These lines represent the drivers that will be loaded, so now you need to add the folder that contains your drivers. See example below:

[OemDriverParams]
OemDriverRoot= "drivers"
OemDriverDirs= vmscsi, Adaptec, Emulex, QLogic, PERC

Save the file.

Step 7 – Create a bootable ISO
Now create a bootable ISO (and/or CD) using the modified ColdClone files.

You should now be able to test this by booting a server up using the CD/ISO and checking that it can now see the hard disks. This process can be repeated to add multiple drivers, giving you one ColdClone CD/ISO that will work with all your servers.

VMware ESX 3.5 & VirtualCenter 2.5 with Update 2

So for my first post I thought I would mention something I have found while working with ESX 3.5 and VirtualCenter 2.5. Recently I was at a customers site doing a VMware ESX installation. We had three ESX 3.5 Update 1 servers up and running all being managed by a VirtualCenter server running 2.5 Update 1.

So when demoing Update Manager we set one of the ESX servers to apply the critical updates by applying the baseline and then setting remediate to run 5 minutes in the future. So the customer looks on happily at how the ESX server puts itself into Maintenance Mode and migrates VM's off in preparation for patching and the subsequent reboot. The ESX host comes back up and all is well. That is until we rebooted the VirtualCenter server, this is when the VirtualCenter service decides that it will no longer start... the following error is in Event Viewer...

Event ID 7024 - The VMware VirtualCenter Server service terminated with service-specific error 2 (0x2)

So with some google'ing about I find the following thread on the VMware forums, http://communities.vmware.com/thread/122543;jsessionid=7A5139DFE94BA6A4AD870E08F442DF23?tstart=0&start=15

Although this post lists this situation now, it didn't at the time, and admittedly I did add this scenario to that post... The post was mentioning IIS and Converter Services being the issue, I had no IIS and and even when disabling Converter I had the same issue...

So after stepping back to think about what had changed recently, I realised that one of the three ESX servers was a higher build version than VirtualCenter. So I installed VirtualCenter 2.5 Update 2 to the VC server and rebooted... the VC server came back up, all services started without any complaints and we were running again.

Historically speaking, when working with ESX environments pre-Update Manager, VirtualCenter was always updated first, thanks to Jason Willey (http://www.virtuallycrazy.blogspot.com). As it makes complete sense that the management server is backwards compatible with older versions of ESX, but cannot know about new features or changes.

I am a fan of Update Manager for ESX, my main reason for posting this is to get the point across that it will make your lives easier as long as you remember to keep VirtualCenter updated too, and more importantly updated before the ESX servers.