Choosing a Provisioning Services Boot Option 1

Provisioning Services works by streaming an operating system over the network. This very basic premise empowers administrators to tackle incredibly powerful use cases, reduce storage costs and scale to phenomenal levels at a reasonable cost. However, in order to accomplish this, some “magic” needs to happen in order to get the operating system going. It’s worth noting that the boot process is remarkably similar once the boot files have arrived at a machine, but they are detailed incredibly well in the Citrix Provisioning Services Boot Process Diagram. This article will discuss the various options available for delivering the boot files – known as “bootstrap” – to your Provisioning Services Target Devices. It is worth noting that “Target Devices” can be virtual or physical, something that is not possible with Machine Creation Services (and for that matter, Provisioning Services Target Devices do not need any other Citrix components besides license server to function).

TFTP (w/ PXE or DHCP)

By far the most widely deployed method for delivering the bootstrap files, this method is extremely flexible. The bootstrap files are delivered via TFTP (UDP Port 69) from any compatible TFTP server. When using the configuration wizard, if you specify that TFTP runs on the server it will start the Citrix TFTP Server.

TFTP delivers the file but it is up to PXE or DHCP to deliver the location and filename. This is accomplished by using either the built in PXE service (again, using the configuration wizard) or DHCP options 66/67 on your DHCP server (boot server / boot filename).

This option is very flexible as you can edit ARDBP32.bin using the “Configure Bootstrap” option from the PVS server very quickly and the next time the file is transferred the changes are live.

There are limitations to using the built in TFTP/PXE services. First, the PXE service will indicate that the local server is the source of the boot file. Also, there are issues related to multi-NIC servers where you cannot change/edit the NIC that the PXE service broadcasts as the boot server, though you can edit the TFTP service to listen on a different IP via registry editing or using the control panel applet (BNTFTP.cpl in the Provisioning Services directory. Note: On some operating systems this may not load or may crash).

Finally, when using this method in your environment you must take into consideration high availability of the services. The built in PXE/TFTP services, as mentioned, refer to their own server/services, so if you have two servers on a single subnet, scenarios can exist where certain services are unreachable or experiencing difficulty. The TFTP service can be load balanced using a NetScaler or other load balancing device, as described here.

BDM (ISO)-TSB

It is also possible to boot using a Boot Device Manager (BDM) ISO or drive. This utility can be dangerous if you click quickly so please use caution when loading it! Using this utility, you can specify the PVS servers from which to login to obtain PVS info and continue booting. This option is also required if you want to use static IP addresses.

Due to the overhead and complication of mounting ISO’s on every device, this is not used as often as the TFTP method. The BDM utility can also “Burn” partitions to attached hard disks. It is this functionality that makes the utility “dangerous” as I described as by default the tool selects the first disk attached to machine it is running on which presents a particular hazard as there is a slight delay when clicking “Next” on the previous screen. This can lead to “click happy” admins accidentally overwriting the C: partition/disk on their PVS server – bad times indeed! Be cautious and read all dialogs.

This boot method relies on the Citrix Two Stage Boot service running on the PVS servers to transfer the bootstrap file via a proprietary protocol based on TFTP on port UDP 6969.

BDM (Partition/Monolithic)

This method, similar to the TFTP method, relies on the “configure bootstrap” information of the farm (As of 7.9, there is a method which returns the first server in the farm only so in a large farm you don’t necessarily need to make them all match, but this could change in the future). Once the bootstrap information/settings are configured, you can provision this by using the XenDesktop Setup Wizard. It is worth noting that this method requires XenDesktop to provision initially. The bootstrap data is written to a partition on a disk attached to the target device, and as of 7.9, can be updated in the future as well.

Once provisioned, this disk can be copied manually to other non-XenDesktop setup wizard provisioned machines as needed, but keep in mind there is no officially supported way to update it in the future if you do not use the provisioning wizard. (The target device has a “BDM” flag and also relies on a non-settable HypervisorID in the database that is used to connect to the host and edit the BDM). As this method requires a XenDesktop host connection, it is used for virtual machines only.

This method does not rely on the two stage boot service as all information is written to the attached partition.

Summary

TFTP (w/ PXE or DHCP)

· Relies on external load balancing (potential off-host communication)

· Relies on TFTP service or third party TFPT server UDP port 69

· Prone to outages

· Built-in TFTP control panel configuration does not work on 2012 R2.  Multi-nic binding scenarios could be difficult

· Third-party TFTP servers often without support

· Multi-threaded TFTP servers traditionally don’t scale well

· Relies on either PXE or DHCP options for boot sever name

BDM (ISO)-TSB

· Highly customizable

· DNS or Static IP Definitions

· Relies on Two-stage boot service (and proprietary protocol on port UDP 6969)

· Can “burn” ISO or partitions

· BDM Utility does not identify which SCSI ID or other unique identifier for disks. Prone to misconfiguration (BE CAREFUL! CAN OVERWRITE YOUR MBR!)

BDM-Monolithic

· Cannot customize

· Relies on “CONFIGURE BOOTSTRAP” settings for farm (more on this in a moment)

· Cannot use DNS

· Includes all components required for boot (No TFTP, load balancing, TSB needed)

· High degree of “Fault isolation”

· Can be cumbersome to replace/update before 7.9

· Only available via XenDesktop setup wizard

· Newer (first release in 2013), not as widely used

Is one “better” than the other? The short answer is “No”, but that comes with a very large “it depends on your environment.” The TFTP method is extremely flexible, fast, widely deployed, and well supported, however it relies on a number of components that you must configure for high availability in a well-designed system. The BDM ISO incurs an overhead, but allows you to easily swap the boot files and even burn them for physical machines. It also includes UEFI support. The BDM (monolithic) partition does not rely on outside services, but can only be used with virtual machines.