Linux:

Insert the XenClient installer CD and run:

sh /mount/cdrom/usb_inst.sh dialog

assuming that you have mounted the cdrom to /mount/cdrom ofcourse.

Windows:

Ok, but what if you’re like me and don’t have a Linux workstation lying around to create your bootable USB? No worries, I found a way to make a bootable USB stick/disk by using a few GNUWin32 tools that are available .

Setup your workspace
First we need to create a directory structure so we have an easy way to create the bootable USB installation.

Create a directory called XC_USB somewhere and the subfolders needed (in my example I create it under the root of D: )

mkdir d:\XC_USB
mkdir d:\XC_USB\staging
mkdir d:\XC_USB\bin

Insert your XenClient CD or mount the ISO file and copy the contents of the isolinux folder to the staging directory

xcopy H:\isolinux D:\XC_USB\staging /y

Copy the packages.main folder to the staging directory

xcopy H:\packages.main D:\XC_USB\staging\packages.main\ /y /s /e

Get the tools
Download the following tools and extract them to the bin directory created above.

• cpio (binaries) – http://gnuwin32.sourceforge.net/downlinks/cpio-bin-zip.php
• sed (dependencies) - http://downloads.sourceforge.net/gnuwin32/sed-4.2-1-dep.zip
• sed (binaries) - http://downloads.sourceforge.net/gnuwin32/sed-4.2-1-bin.zip
• gzip (binaries) - http://gnuwin32.sourceforge.net/downlinks/gzip-bin-zip.php
• findutils (binaries) - http://gnuwin32.sourceforge.net/downlinks/findutils-bin-zip.php
• syslinux (download the 3.86 .zip) -  http://www.kernel.org/pub/linux/utils/boot/syslinux/

HINT: In all the gnuwin32 zip files the files you need are located in the bin subfolder of the zip file.
IMPORTANT: For syslinux it is very important that you do NOT USE the syslinux 4.x release, but the 3.x release. Seeing as the mboot.c32 from the cd was created with syslinux 3.x it will not work with 4.x. The syslinux.exe is located in the win32 folder in the zip file.

Your XC_USB\bin folder should now look like this:

Slipstream the source files
First, we need to slipstream the packages.main files into the initrd (rootfs.gz) of the installer.

Unzip the rootfs.gz file

D:\XC_USB\bin\gzip.exe –9 –f –d D:\XC_USB\staging\rootfs.gz

Change directory to XC_USB\staging (important for inserting the packages.main into the initrd)

cd D:\XC_USB\staging

Slipstream the packages.main directory into the decompressed initrd (rootfs)

d:\XC_USB\bin\find.exe packages.main –print | d:\XC_USB\bin\cpio.exe --create --append --format newc --verbose --file rootfs

What this trick does: we create a list of file using find –print and use that list as input for cpio to append to the rootfs archive.

Next we need to find and replace packages.main\ with packages.main/ (remember this is going to be a linux install environment, so using a backslash as file separator will result in errors)

d:\XC_USB\bin\sed –b "s/packages.main\\/packages.main\//" < rootfs > rootfs2
del rootfs
ren rootfs2 rootfs

When that is done it’s time to create and slipstream the answerfile.

Creating the answerfile

For a full reference of the answerfiles please consult this answerfiles.txt
(Open with Notepad++ or another linux-aware text editor)

Creating the answerfile is very easy, just create a new textfile.
Here is an example for you:
Interactive installation (default)

IMPORTANT: There 2 very important sections in the answerfile I provided.

<preinstall>
# !/bin/bash
sed '/[ -r "\${INSTALL_SOURCE_DIR}/\${PACKAGES_DOT_MAIN}/\${DOM0_ROOTFS}" ] || exit \${CheckFail}/s/^/#/' /install/stages/Check-initrd-data > Check-initrd-data.tmp
cat Check-initrd-data.tmp > /install/stages/Check-initrd-data
chmod 755 /install/stages/Check-initrd-data
</preinstall>

This is used to comment out a line the Check-initrd-data installation script of the XenClient installer, that causes installation to fail. If you remove this preinstall script, your installation will not succeed! Read my previous blogpost for more details on this.

<source type="bootmedia"></source>

This tells the XenClient installer to look for the packages.main folder in the root of the booted media (so XenClient knows it is working with a slipstreamed installation)

Other then those 2 options you are free to do whatever in your answerfile
When you created your answerfile, save it in the staging directory. We are going to slipstream it in the initrd as well. In this example I will use answerfile.henk

cd d:\XC_USB\staging
d:\XC_USB\bin\find answerfile.henk | d:\XC_USB\bin\cpio.exe --create --append --format newc --verbose --file rootfs

Compress the initrd (rootfs) file

D:\XC_USB\bin\gzip –9 –f D:\XC_USB\staging\rootfs

Preparing the syslinux.cfg file

First, rename isolinux.cfg to syslinux.cfg in the staging directory

ren isolinux.cfg syslinux.cfg

Open syslinux.cfg in notepad or another text editor and insert the following:

Make sure all filenames are leaded by a slash /. The filenames are:

• mboot.c32 –> /mboot.c32
• xen.gz –> /xen.gz
• vmlinuz –> /vmlinuz
• rootfs.gz –> /rootfs.gz

Remove the eject_cdrom=1 entry from all 3 boot options

Or use the following command to do it for you, if you are lazy like me, beware it is a oneliner, might not appear so due to website formatting

D:\XC_USB\bin\sed “s/mboot.c32/\/mboot.c32/” < syslinux.cfg | D:\XC_USB\bin\sed “s/xen.gz/\/xen.gz/” | D:\XC_USB\bin\sed “s/vmlinuz/\/vmlinuz/” | D:\XC_USB\bin\sed “s/rootfs.gz/\/rootfs.gz/” | d:\xc_usb\bin\sed “s/eject_cdrom=1//”  > syslinux.cfg.tmp | del syslinux.cfg | ren syslinux.cfg.tmp syslinux.cfg

Edit the answerfile= entry to match the filename of your answerfile, again, this entry must be lead by a /. So in my case it would be:

answerfile=/answerfile.henk

Finally my syslinux.cfg will look like this:

DEFAULT xenclient
DISPLAY bootmsg.txt
PROMPT 1
TIMEOUT 20
LABEL xenclient
kernel /mboot.c32
append /xen.gz max_cstate=0 console=com1 com1=115200/921600,8n1,magic --- /vmlinuz quiet root=/dev/ram rw start_install=new  answerfile=/answerfile.henk console=xencons console=/dev/tty2 --- /rootfs.gz
LABEL verbose
kernel /mboot.c32
append /xen.gz max_cstate=0 console=com1,vga com1=115200/921600,8n1,magic --- /vmlinuz quiet root=/dev/ram rw start_install=new  answerfile=/answerfile.henk console=xencons --- /rootfs.gz
LABEL automatic
kernel /mboot.c32
append /xen.gz max_cstate=0 console=com1 com1=115200/921600,8n1,magic --- /vmlinuz quiet root=/dev/ram rw start_install=new  answerfile=/answerfile.henk console=xencons console=/dev/tty2 --- /rootfs.gz

Preparing the USB disk/stick

Make sure you formatted your usb stick/disk using fat32 filesystem

Copy all files except your answerfile and the packages.main directory to your usb disk/stick (no harm if you do copy them though)

copy D:\XC_USB\staging\* F:\

After that it’s time to syslinux the target partition to make it bootable.

D:\XC_USB\bin\syslinux.exe –a –f F:

And that’s it!
Now just boot your system from USB and install XenClient from USB .

Have fun!

-Henk Hofs

In the answerfile i used the <source type="bootmedia"></source> element so the installer would look for the packages.main in the root of the filesystem.
I put everything on my usb stick, created the syslinux.cfg file, syslinuxed the usb stick and booted up..

The installer booted up perfectly, I could see that it was using my answerfile, but then it kept looping in the Verifying installation media screen...
Switching to Alt+F2 I could see the script Check-initrd-data was returning CheckFail
So I switched to Alt+F3, logged in as root and looked at the contents of /install/stages/Check-initrd-data
I compared this script to /install/stages/Verify-optical-media and noticed a difference in the link functions.

Check-initrd-data:
link_bootmedia_repo()
{
# symlink so the installer can locate the install data
if [ -r "/${PACKAGES_DOT_MAIN}" ] ; then
mkdir -p $(dirname "${INSTALL_SOURCE_DIR}")
rm -rf "${INSTALL_SOURCE_DIR}/${PACKAGES_DOT_MAIN}"
ln -s "/${PACKAGES_DOT_MAIN}" "${INSTALL_SOURCE_DIR}/"
fi

[ -r "${INSTALL_SOURCE_DIR}/${PACKAGES_DOT_MAIN}/${DOM0_ROOTFS}" ] || exit ${CheckFail}

for F in "${PKGDATA_FILENAME}" "${REPOSITORY_FILENAME}" ; do
cp -f "${INSTALL_SOURCE_DIR}/${PACKAGES_DOT_MAIN}/${F}" "${INSTALL_DATA}/" || exit ${Abort}
done
}

Verify-optical-media:
link_bootmedia_repo()
{
# symlink so the installer can locate the install data
if [ -r "/${PACKAGES_DOT_MAIN}" ] ; then
mkdir -p $(dirname "${INSTALL_SOURCE_DIR}")
rm -rf "${INSTALL_SOURCE_DIR}/${PACKAGES_DOT_MAIN}"
ln -s "/${PACKAGES_DOT_MAIN}" "${INSTALL_SOURCE_DIR}/"
fi
# [ -r "${INSTALL_SOURCE_DIR}/${PACKAGES_DOT_MAIN}/${DOM0_ROOTFS}" ] || exit ${CheckFail}

for F in "${PKGDATA_FILENAME}" "${REPOSITORY_FILENAME}" ; do
cp -f "${INSTALL_SOURCE_DIR}/${PACKAGES_DOT_MAIN}/${F}" "${INSTALL_DATA}/" || exit ${Abort}
done
}

When I changed the line in Check-initrd-media (red) to match the one from Verify-optical-media (green), the installer worked, and finished my installation successfully.
Of course I had to change this line by booting the installer from my usb disk using an answerfile that ran interactively (so I could change the Check-initrd-media script using vi before it was invoked, by using Alt+F3 to switch to an interactive shell)

My guess is that the variable: ${DOM0_ROOTFS} is either not being populated by the other scripts that run before this script, or the value of ${DOM0_ROOTFS} is not correct... I wonder why this check has been commented out in the Verify-optical-media script, which is responsible for checking the repository when installing from CD...

I know there has not been an official statement or documentation from Citrix about booting up from USB disk and/or slipstreaming the packages.main into the initrd. But I thought, hey the functions are all there... let's try them

SUMMARY:

The script /install/stages/Check-initrd-media contains an error on line 15:

ORIGINAL LINE:

[ -r "${INSTALL_SOURCE_DIR}/${PACKAGES_DOT_MAIN}/${DOM0_ROOTFS}" ] || exit ${CheckFail}

FIX:

# [ -r "${INSTALL_SOURCE_DIR}/${PACKAGES_DOT_MAIN}/${DOM0_ROOTFS}" ] || exit ${CheckFail}

WORKAROUND:
Use a preinstall script in your answer file to comment out the faulty script
<preinstall>
# !/bin/bash
sed '/ || exit \${CheckFail}/s/^/#/' /install/stages/Check-initrd-data > Check-initrd-data.tmp
cat Check-initrd-data.tmp > /install/stages/Check-initrd-data
chmod 755 /install/stagse/Check-initrd-data
</preinstall>

-Henk Hofs

Ok, let’s get to the point.
This XenClient is awesome, but how are customers going to DEPLOY it to their systems? Using the CD was no option ofcourse!

So against all my geek instincts, I decided to read the XenClient manual. And b00m! They support installation using a PXELINUX server! Whooho!
But how many big enterprises, that are Windows houses have a PXELINUX server installed? Outside of universities I rarely see client deployment systems for Linux. Most of my customers use either MDT or SCCM to deploy their client machines. So I combined the steps in the XenClient manual, with my (very very very limited) knowledge of Linux systems. And came up with the following solution.

I created a script that will run from WindowsPE, install the necessary boot files onto a 100 mb fat partition. Inject your custom answerfile(s) and reboot the computer into the XenClient installation using the answerfile you have passed as an argument

VERY IMPORTANT. This script assumes that there is a 100mb (or more) FAT volume mounted to driveletter C: during the WindowsPE phase. Use the partitioning of MDT/SCCM to do this. Or create your own custom diskpart script, if you want to run it from Windows PE.

I use some free GNUWin / UnixTools for this script, which are not included in the download. But I provide the link where you can download them

So here are the instructions:

• Copy the packages.main folder from the XenClient cd to a location on a http or ftp server.
  The parent location of the packages.main folder is inserted in the answerfile.
  In my case I have a webserver at http://10.0.0.12 in which I created a subfolder xenclient. In my answerfile I refer to http://10.0.0.12/xenclient as the source URL for the packages.

• Creating the package

1. Download and extract my zip file to C:\XCInstaller for example
2. Download cpio for windows from http://sourceforge.net/projects/gnuwin32/files/cpio/ and extract cpio.exe to C:\XCInstaller\bin
   IMPORTANT, download version 2.4.2 (bin), because the commands I use in my script seem to be broken in higher versions
3. Download UnxUtils from http://sourceforge.net/projects/unxutils/ and extract usr\local\wbin\gzip.exe to C:\XCInstaller\bin
4. Download Syslinux from http://www.kernel.org/pub/linux/utils/boot/syslinux/ and extract win32\syslinux.exe to C:\XCInstaller\bin
5. Insert your XenClient cd and copy all files from the boot directory of the XenClient cd to C:\XCInstaller\boot

• Creating one or more answerfiles and place them in C:\XCInstaller\answerfiles

Here is an example of my answerfile

<interactive>false</interactive>
<mode>fresh</mode>
<source type="url">http://10.0.0.12/xenclient</source>
<primary-disk>sda</primary-disk>
<network-interface mode="dhcp"></network-interface>
<password>somepassword</password>
<enable-ssh>true</enable-ssh>
<license-key></license-key>

For a full reference of the answerfile, please consult the XenClient User Manual.

• Running the package

This script can be run from within WindowsPE, so this means that you can either use a vanilla WinPE boot image, or use MDT or SCCM to start this script. I will give an example for all three scenarios

NOTE: The .cmd file takes an answerfile name as a a parameter.
For example you have 2 answerfiles: fullunattend.txt and quickoptions.txt
If you want to install this machine using fullunattend.txt you can use InstallXenClient.cmd fullunattend.txt
If you do not specify a answerfile, the script will default back to the LAST answerfile found in the answerfiles directory. so if you have an answerfile called a.txt and an answerfile called z.txt and you did not specify the answerfile name, the script will default to z.txt

Vanilla Windows PE

• Share the C:\XCInstaller folder so you can access it via the network (in my case I host it on my windows server: 10.0.0.140)
• Start your target machine in Windows PE
• Partition and format the disk using diskpart:
  select disk 0
  clean
  create partition primary size=100
  select partition 1
  format fs=fat quick
  assign letter=c
  exit

• Connect to the XCInstaller share
  (in my case: net use \\10.0.0.140\XCInstaller)
• Start the script
  \\10.0.0.140\XCInstaller\InstallXenClient.cmd
  NOTE: The .cmd file takes an answerfile name as a a parameter.
  For example you have 2 answerfiles: fullunattend.txt and quickoptions.txt
  If you want to install this machine using fullunattend.txt you can use InstallXenClient.cmd fullunattend.txt
  If you do not specify a answerfile, the script will default back to the LAST answerfile found in the answerfiles directory.
• Reboot the machine and VOILA! Your xenserver installation is installing using your answerfile!

Microsoft Deployment Toolkit

• Import the XCInstaller directory as an application in MDT

• Create a new custom task-sequence called Install XenClient

• Add the following steps to the task-sequence
  Fake a NEWCOMPUTER DEPLOYMENT TYPE, otherwise the diskpartitioning will fail.
  
  Partition the disk to a 100mb fat partition
  
  Start the InstallXenClient.cmd
  
  Reboot the computer in the XenClient installation
  

NOTE: It is very important that you do not use the Install Application step, but the custom command line step for the installation. The install application step will not run from within the WinPE phase of MDT. Point this command line to z:\Applications\YOURIMPORTDIRNAME\InstallXenClient.cmd (which is mounted by default by MDT to the distribution share)

SCCM
For SCCM the steps are almost identical as to MDT. Instead of importing an application > create a new package. For the SCCM task-sequence you only need 3 steps:

• Format and Partition disk (make a 100mb fat partition)
• Run Command Line (point it to run from package) InstallXenClient.cmd
• Reboot Computer (in the target partition)

Et voila! Watch your target machine installing XenClient! Here are some“old-fashioned” screenshots, to prove I have it running. Seeing as XenClient requires VTx I couldn’t test it inside a VM and had to use a physical machine… (just an explanation for the photo’s)

Download zip file

Have fun with this!
-Henk Hofs

With “workstation” virtualization software I mean the software that is being used to build images, test out some software etc. The products that I see that are most used:

• VMware Workstation
• Microsoft Virtual PC 2007
• Microsoft Windows Virtual PC (Windows 7)

So why is that so annoying? It isn’t actually, it’s a minor nuisance.
The only problem I have is that in my daily work I give workshops and labs, for which I use… yes Virtual Machines . The problem is that I have to give the workshop/lab at the customer site, where they use for instance VMware Workstation, for which I and the company I work for don’t have any official licenses, and I’m not going to use a keygen or something like that!

So I have to download the trial of VMware workstation, create my lab VM’’s in that product and copy those to the customer’s environment. So for the same lab/workstation I need at least 2 images, VMware and Virtual PC

Recently I came into contact with VirtualBox (now from Oracle). Which is the perfect man in the middle for me, it’s free, it can work with vmdk, vhd and vdi (VirtualBox’s native disk format). But even better, it can clone the virtual disks to any of those formats as well

So I can build my environment in VirtualBox at home, and at a customer site just clone the .vdi disk to the preferred format and attach it to a new VM in the customer’s preferred Virtualization solution.

Only downside I found is that there’s no native export to function in the VirtualBox Media Manager. It had to be done via a cmdline utility, no problem ofcourse. But being a lazy bastard as I am… I build a script and context menu’s using powershell, so I can right-click on a VDI, VHD or VMDK file and select Export virtual disk and select

I created a Powershell script which has to be placed in the VirtualBox install directory, and then you need to edit the registry to enable the context menu items…. nah just kidding… download the zip contained in this post and extract it somewhere and run the Install.cmd as an adminstrator. Then you’re set to go… provided you already installed VirtualBox ofcouse .

NOTE 1: I only tested this on Powershell V2, but I think it should work with Powershell V1.
NOTE 2: The powershell execution policy should be set to Unrestriced for this to work!
NOTE 3: It’s important that you run the Install.cmd as an administrator as it makes changes to HKLM\Software\Classes
NOTE 4: Be aware that Microsoft Virtual PC only has support for 32-bit guests, so if you have to prepare a lab/workshop for virtual pc make sure you created a 32-bit machine in VirtualBox.

Download the files

• Support for Office 2010.  We’ve made a few adjustments to the way Deployment Workbench handles Office and customization so that it now supports Office 2007 and Office 2010.
• New “User-Driven Installation” scenario for ConfigMgr 2007 OS deployment, consisting of a few pieces:
  • A new task sequence template that displays a wizard at the beginning of the task sequence, asking various questions about the deployment (e.g. computer name, domain to join, apps to install, etc.), similar to what you would see with Lite Touch.
  • A wizard designer to configure the wizard behavior, settings, and defaults.
  • Offline user state capture, using USMT 4.0 hardlink support in Windows PE to capture the user state even when the task sequence is initiated via PXE.
• Improved driver importing with Deployment Workbench.  We’ll now automatically detect the platform of each driver as it is imported into the deployment share – if it says it supports x64 but we can’t find any proof of that, we’ll automatically uncheck the platform so that the driver doesn’t get used incorrectly (which causes all sorts of problems).
• Support for ConfigMgr R3 OEM prestaged media.  This provides a better alternative to the MDT 2010 ConfigMgr OEM task sequence templates for a couple of reasons:
  • You can have a single, standard task sequence that is used for OEM and non-OEM deployments.  (The MDT templates required a special two-part “split” task sequence, which meant that you needed a different task sequence for non-OEM deployments.)
  • You can prestage an OSD boot image on the hard drive.  (The MDT templates required using boot media or PXE to initiate the second half of the process.)

You can get the beta from here

$Randomizer = New-Object System.Random
$RandomMac = ''
ForEach ($Number in 1..6) {
    $r = $Randomizer.Next(16,255)
    $Digit = [Convert]::ToString($r,16)
    $RandomMac += $Digit + ':'
}
$RandomMac.Substring(0,17)

Product: Java(TM) 6 Update 19 -- Error 1330.A file that is required cannot be installed because the cabinet file C:\Users\########\AppData\LocalLow\Sun\Java\jre1.6.0_16\Data1.cab has an invalid digital signature. This may indicate that the cabinet file is corrupt.

I noticed that it was not an issue of Java, because some other installers would give me the same message… aaargh! So I decided to browse the web (which is always a good idea anyway ), and I found some forum posts about something being wrong with the Certificate Revocation List. Tried all the thing suggested by numerous articles, but to no avail…

So then we decided to be brave and look around in the registry ourselves. And we found the solution . So to all of you who are struggling with the above error (not only for Java ofcourse), try the following:

Delete this registry key and try the install again. For me it would install perfectly :

HKLM\Software\Policies\Microsoft\SystemCertificates\TrustedPublisher\Safer

These are the main risks Gartner identified, for the complete article check this page.

• Information Security Isn't Initially Involved in the Virtualization Projects
• A Compromise of the Virtualization Layer Could Result in the Compromise of All Hosted Workloads
• The Lack of Visibility and Controls on Internal Virtual Networks Created for VM-to-VM Communications Blinds Existing Security Policy Enforcement Mechanisms
• Workloads of Different Trust Levels Are Consolidated Onto a Single Physical Server Without Sufficient Separation
• Adequate Controls on Administrative Access to the Hypervisor/VMM Layer and to Administrative Tools Are Lacking
• There Is a Potential Loss of Separation of Duties for Network and Security Controls

 "Virtualization is not inherently insecure," said Neil MacDonald, vice president and Gartner fellow. "However, most virtualized workloads are being deployed insecurely. The latter is a result of the immaturity of tools and processes and the limited training of staff, resellers and consultants."

Latest generation virtualization techniques doubles capacity terminal servers

With that statement Ruben and Jeroen have just released Phase II of Project Virtual Reality Check (VRC) to create this whitepaper they have done more than 150 tests with Login VSI to measure the performance of servers while being stressed by a great amount of simulated users. This whitepaper has a few advantages to whitepapers published by the vendors themselves and whitepapers published by blogs that are only testing one hypervisor:

• The whitepaper is truly independent
• The whitepaper is approved by the different vendors
• Everybody can repeat the tests with the free available Login VSI
• The authors aren’t biased
• You can compare the results easily (the servers have been stressed the same way)

One of the most interesting conclusions of Phase II: The performance increase measured is not caused by improvements to the hypervisor but mainly by Intel’s innovations in the Nehalem architecture VRC states that it can be almost solely accredited for the performance improvements seen with TS workloads.

Get your free copy of the whitepaper at www.projectvrc.com

• Official Citrix Whitepaper with 5000 XenDesktop users. http://bit.ly/c5a0n5

Use free and reputable tools like LoginVSI from Login Consultants to simulate real-worldlike
user workloads.

• Official Citrix Whitepaper Single server scalability with XenDesktop http://bit.ly/b4MH75

VM density results are highly dependent upon workload characteristics. We used a
workload called Login VSI, created by an independent company, Login Consultants.
Login VSI, is well known in the VDI and terminal services community with testing of
8 various terminal services and VDI solutions from multiple vendors in a comprehensive,
ongoing test project called Project Virtual Reality Check.