vSphere Auto deploy TFTP on Citrix PVS

I occasionally do a deployment of Citrix on vSphere. When using Citrix a returning component is Provisioning Services (PVS) for automated deployment of Citrix session servers or VD images. When using a management cluster (to prioritize and separate control layer or infrastructure components) an option is to use auto deploy for the session images hypervisor hosts (depending on the edition, depending on the cluster requirements).
One of the components to use in auto deploy is TFTP for the boot image. This can be leveraged for PVS as well, as PVS also needs a type of boot image to start up the VM’s. With PVS this is also a TFTP service (or boot image, but we leave this out for this posting) that is installed at the PVS server.

Why not use this TFTP service as vSphere Auto Deploy does not include one?

What is Auto Deploy?

vSphere Auto Deploy facilitates a infrastructure for automatic server provisioning and network deployment (streaming) of the ESXi hypervisor image. It uses a central managed image, administrators just need to manage the central image and the host profiles. The deployment can be on local storage, state full on HDD, SD or USB or stateless to the hosts ram. It works in conjunction with:

– vCenter,
– host profiles,
– TFTP server,
– Auto Deploy server and Image Builder,
– a PXE boot infrastructure with a DHCP service.

These services can be installed on the vCenter host or hosted/integrated on specific services. When using the stateless host option be sure to have a high available Auto Deploy infrastructure. For example load balancing the TFTP and auto deploy services.

Auto Deploy and host profiles are available from the Enterprise plus Edition. Okay, not always will a virtual desktop cluster be set up with Enterprise Plus, but we can also do this in the management cluster as long as we prioritize the right machines.

What is PVS?

Provisioning Services infrastructure is also based on software-streaming technology. This technology allows computers to be provisioned and re-provisioned in real-time from a single shared-disk image. In doing so, administrators can completely eliminate the need to manage and patch individual systems. Instead, all image management is done on the master image.

PVS works with:

– PVS vDisk store for the master image,
– PVS Console for setting up farm, device collections and managing updates and assignments,
– PVS Streaming service,
– PVS Citrix Shared components, such as MSSQL data store, License server,
– PVS Network services DHCP, PXE and TFTP.

Boot image

A boot image or boot strap file is a small kernel used to start up the machine, connect to the network and receive it’s image via network. The boot file must be configured so that it contains the information needed to communicate with the streaming services, Auto Deploy or PVS.

Putting it all together

As the list above we have some components that are used on both the infrastructures, DHCP, TFTP and PXE. The DHCP is used to provide a bootp image server and image name to the PXE clients (options 66 to the PXE/TFTP on the PVS server and 67 for the boot image name). The PXE infrastructure is a networking zone where client connect to. These clients are configured to boot from network (change the VM bios boot order for example). This can be a separate network, a logical separated network (vLAN) or just a one in all network (policies are advisable to guarantee some networking bandwidth to different types) depending on the requirements of the organization. We will be using a DHCP scope already set up on Microsoft DHCP and TFTP service on the PVS server (why set up more than one).

We can setup the DHCP options on scopes (if logical separate networks) or on leases (DHCP reservations for the smallest amount of host. If we have less ESXi hosts than streaming VM’s we put a scope option to the common image and use DHCP reservations to the other image). We will use to same TFTP service (66), but depending on the sort of machine (VM or ESXi host) we use a different boot image name.

First we get the Auto deploy TFTP image from the vCenter service and put it in the PVS image locations. We connect to the vCenter services via the Web client and browse to vCenter, vCenter server name, manage and auto deploy. Here we have the option to download the TFTP boot zip.


The boot zip is a collection of vSphere boot straps with the correct IP of your auto deploy service (it is created on installation).


Next we connect to the PVS server and go to the PVS TFTP image location. This is in C:ProgramDataCitrixProvisioning ServicesTFTPboot.


Here we place the Auto Deploy images from the boot zip.


Next up we change the DHCP options accordant, I used the DHCP scope options for the PVS image and used a reservation for the ESXi hosts (as these are just three hosts). Citrix is using the ARDBP32.bin image from the lab PVS server.


And VMware is setup to use the undionly.kpxe.vmw-hardwired image from the same lab PVS server.


Let’s boot the machines up. First the ESXi host. It receives the correct VMware image and starts to boot the base image from auto deploy.


Next up start a VM to use the PVS stream image:

imageIt boot’s up to connect to the PVS server. Unfortunately I apparently forgot to add an entry for this device (auto create is off as well), no vDisk in this example. But if we add a vDisk this will load as well.


Alternatively we can setup a TFTP service in on a other host if we want to separate this service from the PVS service and do the same for the Citrix boot image. Just follow the same procedure and add the Citrix images as well.

High Available

Standard the TFTP service is not high available, and when using multiple dependent services the need to increase availability is even higher. Set up a High available PVS, auto Deploy service by for example leveraging a Netscaler (or other LB with service check technique) to load balance the TFTP services and streaming services.

VMware vSphere Auto Deploy and the GUI fling

As in my earlier IO Analyzer blog post, flings in VMware labs are an excellent place for very useful tools and extra’s for your VMware environment. You can find the VMware flings page at http://labs.vmware.com/flings/.

One of the flings I want to blog about is the Auto Deploy GUI. This fling is a front end graphical user interface to the Auto deploy server. The standard auto deploy proces is heavily VMware PowerCLI based. This can be a problem at some organisation where IT personnel is not yet PowerCLI/Powershell familiar. No excuse, but it can be helpful to lower prerequisite knowledge and add a GUI to the process. This way it might be easier for those organizations to accept VMware auto deploy.

Let me be clear…… this is no excuse to not learn PowerCLI. So please up your PowerCLI/Powershell skills as you will use that at a lot of places (also outside of the VMware infrastructure) and makes you life a lot easier (well, that is… after you learn it).

What is Auto Deploy?

Before you add something to a infrastructure, the Auto Deploy components should be known. vSphere Auto Deploy facilitates a infrastructure for automatic server provisioning and network deployment of the ESXi hypervisor. The deployment can be on local storage, statefull on HDD, SD or USB or stateless to the hosts ram. It works in conjunction with:

– vCenter,
– host profiles,
– TFT server,
– Auto Deploy server and Image Builder,
– a PXE boot infrastructure with a DHCP service.

These service can be installed on the vCenter host or hosted/integrated on specific services.  When using the stateless host option be sure to have a high available Auto Deploy infrastructure.

Auto Deploy and host profiles are available from the Enterprise plus Edition.


Auto Deploy server can be installed on a Windows based server, or can be used on or with the vCenter Server Appliance (vCSA).

Why a VCSA, when the 5.1 version with embedded database is for small deployments (maximum of 5 hosts) I hear you ask? Automation and centralized management! …And the fact the vCSA 5.5 will support a lot more hosts…..

As we need a Windows based service for the GUI and normally would need a Windows server for Update Manager, we can combine those on Windows based server.

For this blog post I’m using a 5.1 vCSA installation and Windows based server operating on Windows 2008R2 running Update Manager and Auto Depoy services (including DHCP for PXE boot).

Setting up Auto Deploy services

Here we had a choice (why always these choices…..) to use the vCSA vCenter server components together with Auto Deploy service or you a standalone Windows server for auto deploy services working together with the vCSA for vCenter services. The last makes a little more sense as the Auto Deploy GUI also needs Windows components, and so will Update Manager. If you happen to want to use auto deploy on the vCSA the service needs to be started. Like stated above I’m doing a Windows based installation in conjunction with the VCSA for vCenter services.

How the lab is build:

– VCSA5.1 downloaded and setup.
– Also downloaded the vCenter VIM installer to install Auto Deploy on the Windows host (You will also need this installer if any other vCenter service need to be on a Windows system. For example Update Manager).
– Windows 2008R2 Set up. All defaults.
– DHCP Role added to Windows 2008R2. You can setup your IPv4 scope here, but I will set it up when I’m ready for the TFTP to service. (And don’t forget other devices that offer DHCP such as your internet router, separate the traffic. I have added a LAN segment and let the W2K8R2 DHCP only serve this network. ESXi VM should be connected to this same network).
– Downloaded TFTP Server from Solarwinds (Free version at http://www.solarwinds.com/products/freetools/free_tftp_server.aspx).
– The TFTP server needs .Net Framework 3.5, and so does Auto Deploy Gui so install it to the server (Add Feature).
– Installed TFTP server on Windows 2008R2 and setup starts it. The folder c:TFTP-Root is used default.
– Install PowerCLI.
– Install Auto Deploy service. The default installer will register Auto Deploy with the VCSA.
– Setup a DHCP scope with option 66 = Boot Server Host Name to the IP of the Windows server. And add option 67 = Nothing Yet. We are gonna add the BootFile name later.
– Let’s check if the DHCP scope can serve a ESXi host. Create a VM to the DHCP served LAN segment. And start it up. DHCP is received, TFTP is looked up. And fails because it can’t find Nothing Yet. But we know DHCP is ok.


We can setup the boot image by opening the vSphere client and connecting to the vcenter. Click Auto Deploy (Administration). This will open the following screen:


Now click the download TFTP Boot Zip link and save to (and extract) to the TFTP-Root directory. You will probably need to change the file download to enabled to the IE security settings for Internet zone.

Change the DHCP option 67 to “undionly.kpxe.vmw-hardwired”. (still the PXE boot will fail because no ESXi image is yet prepared)

Setting up Auto Deploy with GUI

First we install the GUI this is really straightforward. This adds an plugin under Solutions And Application to your environment.


(This actually also has the link to download TFTP Boot zip).

Next up configuring your environment.

1. First up VMware depot, Right click and check or add VMware depot url to https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-­‐depot-­‐index.xml. (default it is in)
2. Next HA depot. Right click HA depot url. This should read http://<vchostname>/vSphere-­‐HA-­‐depot/index.xml. Else add it.
3. If you need a specific custom component (for example a Nexus VEM) you can add a zip depot.
4. This will fill up the Images in the Image Builder screen. Here you can build up your organization specific images (with specific software packages). For now I leave the defaults and move on.
5. Now we create the first deploy rule. Click the add rule and fill in the name,
6. I set it to the ESXi5.1 standard image, select where it must land (I select a host folder I created), select an host profile we skip (not yet created, if you have select your appropriate profile), in the rule set you can setup up a specific pattern (for example asset tag or vendor) very useful but not for this demo. I select apply all.

This will start up tasks to inject VIB’s to the cache. After this the rule is created.


7. Activate the newly created rule by right clicking and selecting active.

Start up the test VM created earlier (or reboot when it’s still is failing) and see if the host is added to the Auto Deploy Host folder.


Yup this time it found an image. Loading and you will notice a cache loading of ESXi next.


Received a DHCP address for the booted host. Let see if vCenter shows the host added to the correct host folder.


Success, base image and add to a vCenter managed infrastructure is done. Warning is about the unconfigured state and to non-persistant storage for the scratch partition.

What’s next?

To use your ESXi hosts in auto deployment scenario you will have to set up host profiles and add this to a deployment rule (or more if you have several environments).
Configure a host to be setup according to your environment (DNS, NTP, networking, name it….). Create a host profile from this host and fill up an answer file. Check compliancy to be sure this one’s correct.

Add this profile to the deployment Rule and voila you ESXi is deployed and setup in a profile.

– Enjoy your Auto deploy infrastructure with the Auto Deploy GUI! Be sure to learn PowerCLI another time!