IThastobecool.com Geeks have opinions too!

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

10Jun/100

MDT 2010 Update 1 Beta

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

Tagged as: No Comments
25Nov/092

Installing WAIK unattended

Today I was thinking of creating a sort of “master” script for MDT implementation, that would install and configure MDT2010 unattendedly. So ofcourse, my first order of business was installing all the prerequisites unattendedly… and that’s where the trouble started…. Microsoft does not support installing the WAIK via the well known /qb-! or /qn switches… because of the EULA you have to accept. I found this great article by Richard Smith on the deployment guys blog. Unfortunately for me… my script will be running under a system account (SCCM)… which means no UI at all… so the Auto-IT method didn’t quite do it for me…

So I decided to go old school, whip out my favourite MSI editing tool: Orca and create a transform that removes the Full UI requirement.

Now all you have to do is: msiexec /i waikx86.msi TRANSFORMS=waik.mst /qn and voila… fully unattended WAIK installation…

Disclaimer: This is very much NOT supported by Microsoft… so use at your own risk.

Download

Tagged as: , 2 Comments
13Nov/090

Small workaround when Clear PXE advertisements doesn’t seem to work

I find it very annoying that sometimes when I clear an PXE Advertisement from the SCCM console and I reboot the machine I still get the PXE Boot Aborted message… a small workaround I always use is the following.

  • Clear the PXE Advertisement using SCCM console
  • Stop the WDS Service on the SCCM PXE Server
  • Clear RemoteInstall$\SMSTemp on the SCCM PXE Server
  • Start WDS Service on the SCCM PXE Server

And voila! The advertisement does work this time around…

All in all I have experienced a lot of troubles with PXE and SCCM… I am really hoping the next version of SCCM will bring major improvements to this part….

2Nov/0917

Creating a custom boot image for SCCM SP2 (WinPE 3.0)

Today I had to recreate my x86 boot image in my SCCM environment. I had just upgraded my testserver to SCCM SP2 and found that the old way of creating a boot image didn’t work anymore… seeing as SCCM SP2 uses DISM.exe instead of imagex and peimg. So I went looking for instructions on creating a custom SCCM SP2 image, but couldn’t found any, so here are the instructions :) .

1. Start the Deployment Tools Command prompt and enter the following command:

COPYPE.CMD x86 1 c:\WINPE

When you're working on a 64-bit WinPE image use "amd64" instead of "x86"

2. Mount the winpe.wim file to the mount dir that’s created automatically:

DISM /Mount-Wim /WIMFile:c:\winpe\winpe.wim /Index:1 /MountDir:C:\winpe\mount

3. Add the packages required by SCCM to the wim (again, if you’re working on 64-bit Windows PE substitute "x86" with "amd64")

DISM /Image:c:\winpe\mount /Add-Package /PackagePath:”C:\Program Files\Windows AIK\Tools\PETools\x86\WinPE_FPs\winpe-scripting.cab”

DISM /Image:c:\winpe\mount /Add-Package /PackagePath:”C:\Program Files\Windows AIK\Tools\PETools\x86\WinPE_FPs\winpe-wmi.cab”

After this step you can continue adding packages (such as winpe-hta.cab and winpe-mdac.cab) or custom files to the boot image. The 2 packages worked out above (Scripting and WMI) are required by SCCM, without these packages you will receive an error during updating your boot image to the distribution points.

4. Commit the changes to the WIM and unmount the WIM

DISM /Unmount-Wim /Mountdir:c:\winpe\mount /commit             (thank you for the correction Matt!, It appears as if I was quite sleepy when I wrote this post ;) )

5. Import your custom boot image into SCCM.

That’s it, just as simple as it was with the previous version of WAIK, only different commands :)

13Oct/090

New version of the MDT Wizard Editor is available

As I was browsing a few of my standard blog sites this morning I noticed that Michael Niehaus has uploaded a new version of the MDT Wizard Editor.

Original post by Michael here

Tagged as: No Comments
30Sep/090

MDT 2010: Fix for ‘Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed”

There is now a fix for the problem that MDT 2010 has when connecting to the deployment share with different credentials in sysprep, refresh, replace and custom task-sequences.

Read more about it here

Tagged as: , , , No Comments
10Sep/090

MDT 2010 released!

Microsoft Deployment Toolkit 2010 has been released for public downloading. Get your copy here.

Michael Niehaus did a great series of blog posts on most of the new features of MDT 2010. 

Tagged as: No Comments
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