IThastobecool.com Geeks have opinions too!

5Sep/105

Step by step guide: Installing Citrix XenClient RC2 from USB

Ok, so RC2 for Citrix XenClient was released, great.. but I had a bit of a problem… because I have replaced the cd-rom drive of my laptop computer with a secondary hard drive which I use for XenClient. So I needed an alternate installation method for XenClient that didn’t involve booting from the CD… Booting from USB seemed the logical choice… but that wasn’t as trivial as I first thought it would be, at least not when using a Windows workstation to create your bootable USB Winking smile. If you use a Linux workstation it’s very easy…

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 Smile.

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.

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:

image

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 Smile
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! Open-mouthed smile
Now just boot your system from USB and install XenClient from USB Smile.

Have fun!

-Henk Hofs

Tagged as: , 5 Comments
21Jun/1011

Installing Citrix XenClient from MDT / SCCM / WinPE

Ok… I have been playing with Citrix XenClient for a while now, and I like it a lot!
Yes it has it’s quirks, bugs and issues, but what can we expect from a RC! So far I think Citrix has done an amazing job… to you XenClient developers, we salute you!

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.

image

  • 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

image

  • 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

image

  • Create a new custom task-sequence called Install XenClient

image

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

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)

IMG_0128

IMG_0129

IMG_0130

IMG_0133

IMG_0134

IMG_0135

IMG_0136

Download zip file

Have fun with this!
-Henk Hofs

30Aug/096

Xenocode: A damn good alternative to VMware Thinapp!

As Mark pointed out in his earlier post: The VMware Thinapp team really needs to wake up… it’s not acceptable (from my point of view) to still not have Windows 7 support for you application virtualization product!!

Mark pointed me to an alternative called Xenocode: This is looks a LOT like Thinapp/Thinstall and works on Windows 7 as well :)

Virtualizing Applications

To get started, first go to www.xenocode.com and download the Virtual Application Studio.
When you fire up the VAS you get a wizard which provides you with 3 ways of virtualizing your application:

image

The first option allows users to easily virtualize an application using a template. This template contains all the settings for virtualizing an application. It’s as easy as next next finish :) . This is really awesome for organizations where you want your application support team to virtualize the application, as they don’t have to know in-depth how application virtualization works :) .

The second option allows users to virtualize an application the way we know it from VMware Thinapp. It first takes a snapshot of the computer, then prompts the user to install the application /set configuration options etc and then takes another snapshot and does a diff on the snapshots to determine what files and registry settings should be in the virtual application.

The third option allows users to manually specify the files/folders and registry settings that are required for this application to run (really useful when virtualizing your in-house developed applications, seeing as the developers know exactly what file should go where, and you don’t get any clutter from background processes etc.)

After you captured your application, you can easily include common runtimes from the runtimes tab (such as the .NET frameworks, java, flash etc)

image

The toolbar on the left side of the screen gives us access to the various parts of the virtual application, such as File system, Registry etc.

image

I’ts also possible to generate a MSI package for the virtual application for easier deployment using SCCM/MDT/GPO/Whatever you use to deploy your software to your users.

image

For troubleshooting your virtual application Xenocode provides a checkbox to Generate diagnostic-mode executable. Basically what this does is create an executable that will output logging in 3 log files next to the application, so if something is not working in your application, you can easily troubleshoot :)

image

If you enabled it in your application settings (on by default) it’s also possible to pass command line switches to your application at startup time.

    • /XEnv=Variable Name=Value Specifies additional environment variables.  Multiple /XEnv arguments can be used to add additional environment variables.
    • /XLayerPath=Layer Path Adds the given xlayer file into the virtual environment.  Multiple /XLayerPath arguments can be used to add additional virtual layers.
    • /XSandboxPath=Sandbox Path Specifies the path to be used for the application sandbox.
    • /XShellEx=Command Specifies a shell execute command to be launched from within the virtual application environment.  This option overrides any startup files specified in the virtual application configuration.  Only one /XShellEx argument can be specified.
    • /XShellExVerb=Command Verb Specifies the verb to be used in conjunction with the XShellEx command.  The default verb is OPEN.
Middleware

When dealing with middleware, in Thnapp we could specify an applink and with App-V we can use dynamic suiting to allow for interbubble communications. In Xenocode you don’t make an application for your middleware, but make it a component, which you can import in your applications.

image

image

 
Deploying Virtual Applications

Deployment of the virtual applications is done through a tool called XReg. This allow the administrator to control how the application is published to the user.

image

 

This can be done from a startup/logon script. This area needs some more work in my perspective, there’s not a nice and nifty GUI management interface as with App-V.

Also the possibility to create MSI’s makes deployment a bit easier, just use your favorite deployment method for your virtual applications.

Pricing

Not the most fun part for us techies, but important for the ones who have to make the decisions about investments, and what application virtualization technology will be used.

The Xenocode Virtual Application Studio ISV Edition costs $1599

End-User licenses: $40 per seat.

 

Well that’s about it :) . As a final conclusion i think Xenocode is a real nice application virtualization product, it works easily and out of the box, users don’t have to know a lot about Windows and application when you just give them the right application templates :) . As with VMware Thinapp, the problem is how to distribute the applications to your clients, and how do you make sure that all users have the latest version of the virtualized application… well that’s something the Xenocode team needs to think about I guess.

19Aug/092

MDT 2010 Release Candidate!

The Release Candidate for MDT 2010 just went public!
This release promises a lot of bug fixes and is tested with pre-RC build of Config Manager 2007 SP2.

Sign up for it here: https://connect.microsoft.com/site/sitehome.aspx?SiteID=14

17Aug/0942

ZeroTouch for MDT 2010 without SCCM!

Don’t you just wish you could set all your clients to boot from network, and let the PXE server evaluate whether or not it should load the WinPE image to redeploy the computer? Well you can with SCCM using mandatory advertisements of course… but I've written a little script that will achieve the same functionality using native MDT, without the use of the SCCM infrastructure :)

Here’s how you do it:

  • Requirements:
    • MDT2010 (beta 2) /WDS installed on Windows Server 2008
    • Powershell enabled on the WDS server
    • MDT deployment share configured to use the database (i’m using an SQLEXPRESS instance configured on the same machine as MDT/WDS in this example)
    • SQL Server Management Studio or equal SQL server management tooling for editing the database.

Ok here we go and setting it up. First some simple stuff :)

  • Set your WDS server to admin approval mode

image

  • On the Directory Services tab, make sure you set the OU location in which the WDS server will create the temporary computer object for approved devices

image

  • Make sure your WDS server account has full control on the OU set in the WDS directory services

image

Ok, that was easy now wasn’t it?

Now let’s edit the MDT database to fit our needs. This assumes your already set up your database using the database wizard in the MDT Workbench.

  • Start the SQL Management Studio application and expand the MDT database (MDT_DB in this example)
  • Browse to Tables –> dbo.Settings –> Columns

image

  • Right click Collumns and select New Column

image

  • Give the new column the name of netBoot and type nvarchar(50)

image

  • Save and close the SQL management studio
  • Verify the database expansion was successful by opening the MDT Workbench and navigating to the database view > Computers > properties

image

  • Select the Details tab and browse all the way to the bottom to verify that the netBoot value is there

image

Ok, that was part 1 of the configuration. Now we have to know what to actually do with this extra field in the database. Well that’s where my script comes in. Here’s how you install it.

  • Run the following command as an administrator on the WDS/MDT server:
    • Server 2008: Powershell.exe –command “ & {Set-ExecutionPolicy Unrestricted } “
    • Server 2008 R2: Powershell.exe –command “ & {Set-ExecutionPolicy Bypass } “
  • Download the MDT-ZTI.ps1 file to your WDS/MDT server (in this example I'm using D:\MDT-ZTI.ps1)
  • Start Task Scheduler and Right click library > Create Task

image

  • Give the task a name of your liking. I’m using MDT-ZTI in this example.

image

  • On the triggers tab select: New

image

  • Begin the task: On an event

image

  • Log: Microsoft-Windows-Deployment-Services-Diagnostics/Operational
  • Source: Deployment-Services-Diagnostics
  • EventID: 4096
  • Click Ok and go to the Actions tab and select New

image

  • Add action

image

  • Start a Program
  • Program/Script: Powershell.exe
  • Add Arguments(optional): –command D:\MDT-ZTI.ps1

Ok the ZeroTouch “service” is almost ready to go. Now there’s another thing that we need to configure… we have expanded the MDT database to contain an extra column…  but how does the service know what database and what database server to use?. Well that is hardcoded in the top of the configuration of the MDT-ZTI.ps1 file. In the future I will be using params() from powershell, but for now just change it in the top of the script.

# //***************************************************************************
# // Configuration:
# // Notes: Set the database name and datasource for your environment here.
# // For SQLEXPRESS on the same server use "\SQLEXPRESS" as datasource  # //***************************************************************************
$Database = "MDT_DB"
$DataSource = ".\SQLEXPRESS"

 

 

Now how does the “service” know what computers are allowed to boot into WinPE and what computers should boot to the next boot device? That’s a simple 3 part answer:

  1. Every computer that is NOT in the MDT database will be rejected (pxeabort.com) by the ZTI.
  2. Every computer that IS IN the MDT database will be polled for the value of netBoot.
  3. If the value of netBoot does not equal FALSE it will approve the device so it will load the boot image, and then set netBoot to FALSE so the device won’t load the boot image on the next reboot :)

So if you have a computer which is not booting into winPE just clear the netBoot field in the database and on the next reboot it will boot into winPE.

IMPORTANT: Please be sure to test this first in a test environment first, it is not recommended to implement this in production directly.

Download:  MDT-ZTI

12Aug/090

MDT 2010 beta 2 new features coverage

Well, I’m not going to re-invent the wheel here, seeing as Michael Niehaus (the lead engingeer on MDT) already wrote very very nice articles on the new features of MDT 2010 beta 2.

New features 1 to 11

New features 12 to 18

20May/090

Windows 7 Problem Steps Recorder Script

Yesterday I wrote about the Problem Steps Recorder and how it can help us lazy IT admins who have to screenshot some setups/manual actions for recipe files or documentation in general. When I was messing around with the PSR I found out one really annoying fact: the PSR window is always on top in all the problem report screenshots.. That's not really nice for our documentation now is it? So I wrote this quick Auto-IT script that Starts PSR>start recording>wait until ESC key is pressed>stop recording>ask where to save file

Download the script from here

Here is the code (simple ofcourse ;) )

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; Problem steps recorder script
;; V1.0 HHO Login Consultants
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
#include <Misc.au3>
Run("psr.exe")
WinActivate("Problem Steps Recorder")
WinWaitActive("Problem Steps Recorder")
Send("{ALTDOWN}a{ALTUP}")
WinSetState("Problem Steps Recorder", "", @SW_HIDE)
while 1
	if _IsPressed("1B") then ExitLoop
WEnd
WinSetState("Problem Steps Recorder", "", @SW_SHOW)
WinActivate("Problem Steps Recorder")
WinWaitActive("Problem Steps Recorder")
Send("{ALTDOWN}o{ALTUP}")
19May/091

Windows 7 Problem Steps Recorder

When you have to help out users with their problem, nothing is more frustrating then the users' inability to clearly state what their problem is, and how they got to the point where it went wrong. Fortunatly, Windows 7 packs a really really really awesome tool that will get rid of those problem once and for all: the Problem Steps Recorder.


This nifty little tool records the users' screen and outputs all relevant information in a MHTML document, which will contain all screenshots and steps needed by the helpdesk user. Thanks to Ment van der Plas for pointing this tool out to me :D

You can start Problem Steps Recorder by Start>Run>psr.exe and try it out :)

This tool is also very very very interesting for all us lazy IT guys, who don't want to screenshot their installations for recipe files etc :)

23Feb/090

Windows Vista Resource Kit book is available for free

In case you’ve missed all the blog entries about it, Microsoft Press has made available the full text of the Windows Vista Resource Kit book, downloadable as a PDF file.  See http://csna01.libredigital.com/?urws8un4p7 for the details.

Chapter 12 in this book is all about deploying with Microsoft Deployment Toolkit 2008. There are some nice examples on how to automate LTI deployments, as well as configuring ZTI deployments. In total there are 58 pages of MDT goodness in there :) .

There are plenty of familiar names in the acknowledgements section, including a few names (Michael Niehaus, Jerry Honeycutt, Tony Northup, Doug Steen, Dave Field) that have worked with the MDT team over the years on the MDT documentation.