This is part of a series comparing Provisioning Services and Machine Creation Services
- Part 1: Resource Delivery Options
- Part 2: Scalability
- Part 3: Storage Optimization
- Part 4: Deployment
- Part 5: On-going Maintenance
- Part 6: Architecture
- Part 7: Summary
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.
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.
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.
I 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.