IThastobecool.com

Geeks have opinions too!

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

One of the things that I come across in my everyday job is the fact that the “Workstation” virtualization software that is being used at every customer differs based on personal preference of the engineeers or the fact that a company has made a guideline for this.

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

image

image

image

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

Whoohoo! MDT 2010 Update 1 is available as beta via connect.microsoft.com!
Here are the new features as Michael Niehaus posted them on his blog:

  • 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

Here is a little powershell snippet that will generate a random mac address.

$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)

Today a co-worker and I were struggling with the installation of JRE 1.6 update 19. It just wouldn’t install on a few boxes, on other boxes it ran smoothly… this drove me nuts! Time after time I was getting this error:

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

Today I found an interesting article from Gartner, they predict that in 2012 60 percent of all virtual servers will be less secure than the physical servers they replace. Gartner expects this percentage to drop to 30% at the end of 2015. 

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

The mona lisa

Wohoo!! When we where creating Login VSI we had a few goals in mind, one of them is becoming the de facto standard for benchmarking virtual environments (TS/VDI/Bare metal etc). And i have to say: something is happening in the industry. To begin with we have Project VRC by Ruben and Jeroen but recently Citrix published some rather interesting whitepapers.

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

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
http://www.virtualrealitycheck.net/.

In IT everybody i meet always has something against AutoIT, this is for a obvious reason you don’t want to use recorded mouseclicks or sendkeys to install your applications unless there is really (no really!) no other option left.

In everyday usage i use AutoIT to create most parts of VSI, its perfect for emulating the user workloads because it works like a real user and because i dont have real programming skills the rest of VSI is also created in AutoIT script.

You would think a large company would do this a little different, maybe they would create the workloads in AutoIT scripts but creating the configuration GUI’s would be done much more professional…. Well VMWare dissagrees :) apparently.

 

vmware

Conclusion: +1 for the AutoIT team and –1 for VMware!

Well it’s always nice to know when you production environment will break, i wish i knew this for all software running in my environment ;) . But it doesn’t look really professional from the vendor side. And this time the vendor is: Citrix!

As of 2010-03-25 (March 25th, 2010), EdgeSight 5.0 and 5.1 (all service packs) will stop functioning.

Customers will receive the following error message for payload uploads:

“Archive load error: The archive ‘/edgesight/app/suser/ZRemoteLib.zpd#12!lsync.htm’ is not appropriately signed.  The system cannot find the file specified.”

General symptoms: Payloads will not be uploaded and many of the EdgeSight components will not work properly resulting in different errors.

 

Congratz to Citrix for reintroducing a bug the already discovered in version 4.5 of their software product!