PVS vs MCS – Part 4: Deployment


This is part of a series comparing Provisioning Services and Machine Creation Services

So far, the latest analysis between Machine Creation Services and Provisioning Services included within XenApp and XenDesktop 7.9 has only focused on how Machine Creation Services has improved, but what about Provisioning Services?  Has anything been improved?

Most definitely! Especially around simplifying the deployment of Provisioning Services.

Hyper-V

Previously, Provisioning Services supported Hyper-V, or to be more specific, with generation 1 Hyper-V virtual machines. However, generation 1 Hyper-V virtual machines do not support PXE boot unless the VM utilizes the legacy network adapter.  Unfortunately, the legacy network adapter is not as efficient as the standard (synthetic) network adapter.

To get Provisioning Services to work with Hyper-V while taking advantage of the optimized synthetic network adapter, each virtual machine would require two separate network adapters. This configuration gets confusing, including the use of multiple IP addresses.

With the XenApp and XenDesktop 7.9 release, Provisioning Services supports Hyper-V generation 2 virtual machines.  And unlike generation 1 VMs, generation 2 VMs support PXE booting with the standard (synthetic) network adapter.

Now, each virtual machine only requires a single NIC. This is a huge improvement in simplicity.

Boot Options

Booting a PVS target device is easy in a lab environment where you have total control over DHCP and can easily set DHCP options 66 and 67 to the Provisioning Services TFTP server and boot file. But when we move into production, the network team is rarely as accommodating.

This led many of us to deploy the Boot Device Manager (BDM), which is a small boot file deployed as an .ISO file and attached to each target device. This worked great as we no longer required the configuration of those pesky DHCP options.

However, the BDM file was considered a 2-stage boot process because even though this BDM file contained the boot image, it did not contain the Provisioning Services boot drivers needed to complete the process and sign into the Provisioning Services server.  This meant we still needed a TFTP server. It meant we still needed TFTP IP helpers if we spanned multiple subnets.

Did you know that the BDM file was improved. It is now a single-stage BDM file. The ISO file attached to the target machines contains the boot file and the Provisioning Services boot drivers, eliminating the need for the Provisioning Services TFPT server.

Again, simplifying initial deployment.

So where does that leave us in the Machine Creation Services and Provisioning Services comparison.

SimpleI consider it to be even. Although Provisioning Services requires us to install the Provisioning Services server, the process is straight forward.  The complexity with Provisioning Services deployment was for Hyper-V environments and setting up the DHCP/TFTP options.

With the support for Gen 2 virtual machines on Hyper-V and a single stage boot device manager, the world of Provisioning Services is much easier to deploy.

Daniel (Follow on Twitter @djfeller)
XenApp Advanced Concept Guide
XenApp Best Practices
XenApp Videos

Advertisements

2 thoughts on “PVS vs MCS – Part 4: Deployment”

  1. Hey Dan, you missed the updated BDM feature when using a BDM disk partition. This is not new to 7.9, but in 7.9 you can updated this partition from the PVS console, where as before you had to destroy and recreate the VM. I think this is a big step in leveraging BDM without having to use the ISO file.

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s