Ever since the first article in this series came out in January 2014, I have been asked by numerous people to add an article that includes Boot Device Manager (BDM). Since I am here but to serve, I am finally getting around to updating the process to include BDM.

Introduction

As with most things involving XenDesktop and or PVS, there is NO one way or one right way to do anything. This article will give you detailed information on the process I worked out and documented and now updated to include Boot Device Manager.

Assumptions:

PVS 7.6 is installed, configured and a farm created. XenDesktop 7.6 is installed and a Site created and configured. Hosting resources are configured in Studio. PXE, TFTP, and DHCP are configured as needed.

Note: While with BDM, PXE, TFTP and DHCP Options 66 and 67 are not needed, they are needed for the initial running of the PVS Imaging Wizard.

Lab Setup

All servers in my lab are running Microsoft Windows Server 2012 R2 fully patched. The lab consists of:

1 PVS 7.6 server

1 XenDesktop 7.6 Controller running Studio

1 SQL 2012 SP1 Server

1 Windows 7 SP1 VM

I am using XenServer 6.2 fully patched for my hosting environment. There are separate Storage Repositories for the Virtual Machines (VM), Personal vDisk (PvD) and Write Cache as shown in Figure 1.

Update: This has been tested with XenServer 6.5 with no changes or issues.

Note: The partition for BDM is created when the XenDesktop Setup Wizard is run and is created in the same Storage Repository as the Write Cache drive.

The Hosting Resources are configured in Studio as shown in Figure 2.

To start off, in my lab I created my Organization Unit (OU) structure in Active Directory (AD) for my domain, WebstersLab.com, as shown in Figure 3.

One of the reasons to use PvD is to allow users to install applications. In order to do this, I created an AD security group, shown in Figure 4, that will contain the AD user accounts and that AD security group will be made a member of the local Administrators security group.

Three AD user accounts were created, shown in Figure 5, for the three different PvD users for this article.

Those three test user accounts were placed in the LocalAdmins AD security group as shown in Figure 6.

Most organizations that use XenDesktop to serve virtual desktops or servers require that Event Logs persist between reboots or the security team sits in the corner crying. Other items that may need to persist between desktop/VM reboots are antivirus definition files and engine updates. To accomplish these a Group Policy with Preferences is used. Why not manually change the file system and registry? Because the XenDesktop setup wizard completely ignores all the careful work done by creating folders on the Write Cache drive. When the Write Cache and PvD drives are created, they are empty and will NOT carry over ANY of the manual work done beforehand. So just forget about doing any of the items usually done by pre-creating a Write Cache drive. The Write Cache drive is always created as Drive D and the PvD is created with the drive letter assigned during the Wizard. My Group Policy with Preferences is linked at the OU that will contain the computer accounts created by the XenDesktop Setup Wizard. These are the settings in the policy used for this lab.

Computer Configuration\Policies\Administrative Templates\Windows Components\Event Log Service\Application\Control the location of the log file – Enabled with a value of D:\EventLogs\Application.evtx

Computer Configuration\Policies\Administrative Templates\Windows Components\Event Log Service\Security\Control the location of the log file – Enabled with a value of D:\EventLogs\Security.evtx

Computer Configuration\Policies\Administrative Templates\Windows Components\Event Log Service\System\Control the location of the log file – Enabled with a value of D:\EventLogs\System.evtx

Computer Configuration\Preferences\Folder – Action: Update, Path: D:\EventLogs

Computer Configuration\Preferences\Control Panel Settings\Local Users and Groups – Action: Update, Group name: Administrators (built-in), Members: ADD, <DomainName>\<Security Group Name>

User Configuration\Policies\Administrative Templates\Start Menu and Taskbar\Remove the Action Center icon – Enabled

These settings will:

Keep the user from getting popups from the Action Center

Create the EventLogs folder on drive D (the Write Cache drive)

Redirect the Application, Security, and System event logs to the new D:\EventLogs folder

Add the domain security group that contains user accounts who should be local admins to the desktop’s local Administrators group

Create the Virtual Machine

Next up is to create a Windows 7 VM to be used as the Master or Golden image. Do just basic configuration of the VM at this time. Do not install any applications at this time.

Citrix provides a PDF explaining how to optimize a Windows 7 image. http://support.citrix.com/servlet/KbServlet/download/25161-102-648285/XD%20-%20Windows%207%20Optimization%20Guide.pdf

Once the basic VM is built there are four things that need to be done before joining the VM to the domain.

Fix the WMI error that is the Application event log. I know it is not a critical error but I am OCD and simply must have error-free event logs. Run the Mr. FixIt (this one actually works) from http://support.microsoft.com/kb/2545227. Install the hotfix for using a VMXNet3 network card in ESXi. Request and install the hotfix from http://support.microsoft.com/kb/2550978. From an elevated command prompt, run WinRM QuickConfig. This allows the desktops to work with Citrix Director. Disable Task Offload by creating the following registry key: HKLM\System\CurrentControlSet\Services\TCPIP\Parameters\ Key: “DisableTaskOffload” (dword) Value: 1

The Write Cache drive will become drive D when it is created so before installing any software change the CD drive letter from D to another letter. I use Z.

The VM is ready to join the domain. After joining the domain, shut down the VM.

Now two hard drives need to be added to the VM. One for the Write Cache drive and the other for the PvD drive. NOTHING will be done to these drives, they are just stub holders so Windows knows there should be two additional drives. The Write Cache and PvD drive must be different sizes or strange things can happen. If they are the same size, it is possible the write cache file and page file can be placed on the PvD drive and not the Write Cache drive. To make your life easier, keep the drives different sizes with the PvD drive being larger. For this article, I will use a 10GB Write Cache drive and a 20GB PvD drive. Make sure the new drives are created in the proper storage locations as shown in Figures 7 through 9.

PVS uses the different disk sizes to determine which disk to use for the Write Cache. The smaller of the two disks is used for the Write Cache.

Power on the VM, log in with a domain account, start Computer Management and click on Disk Management as shown in Figure 10.

Click OK to initialize the two new drives as shown in Figure 11.

The two new drives appear in Disk Management as shown in Figure 12.

Leave the drives unformatted and exit Computer Management.

Install PVS Target Device Software

At this time, any software and updates needed can be installed. The Citrix Virtual Delivery Agent will be installed later. After all software and updates are installed, mount the PVS 7.6 ISO to the VM, open My Computer and double-click the CD.

When the PVS installer starts, click Target Device Installation on both screens as shown in Figures 13 and 14.

Follow the Installation Wizard to install the PVS Target Device Software. On the last page of the Installation Wizard, leave Launch Imaging Wizard selected and click Finish as shown in Figure 15.

You can exit the PVS Installer screen and unmount/disconnect the PVS 7.6 ISO from the VM’s CD drive.

Click Next on the Imaging Wizard as shown in Figure 16.

Enter the name or IP address of a PVS Server, select the option for Credentials and click Next as shown in Figure 17.

To Create new vDisk, click Next as shown in Figure 18.

Enter a vDisk name, Store, vDisk type and click Next .as shown in Figure 19.

Select the licensing type and click Next as shown in Figure 20.

Verify only the C drive is selected and click Next as shown in Figure 21.

Enter a Target device name, select the MAC address, select the target device Collection and click Next as shown in Figure 22.

Click Optimize for Provisioning Services as shown in Figure 23.

Verify all checkboxes are selected and click OK as shown in Figure 24.

Depending on the .Net Framework versions installed on the VM, the optimization process could take from less than a second to over an hour.

Once the process has completed click Finish as shown in Figure 25.

The vDisk is created.

Once the vDisk is created, a Reboot popup appears as shown in Figure 26. DO NOT reboot at this time. Depending on your hypervisor, you may need to shut down to make the next change. The VM needs to be configured to boot from the network first and the hard drive second. If this change can be made while the VM is running, make the change and click Yes. If not, click No, shut down the VM, make the change and power the VM on to continue.

Before we continue, what did the Imaging Wizard do inside of PVS? First, a vDisk was created as shown in Figure 27.

Second, a Target Device was created, as shown in Figure 28, with the MAC address of the VM, linked to the vDisk just created and the Target Device is configured to boot from its hard disk because the vDisk is empty right now.

Once the VM has been configured to boot from the network first and the hard drive second, either power on the VM or click Yes to reboot the VM as previously shown in Figure 26. When the VM is at the login screen, login with the same domain account and the Imaging Wizard process continues as shown in Figure 29.

When the Imaging Wizard process is complete, click Finish, as shown in Figure 30, and shut down the VM.

Note: If there are any errors, click Log, review the log, correct any issues and rerun the Imaging Wizard.

Configure the vDisk in PVS

What has happened is that the Imaging Wizard has now copied the contents of the VM’s C drive into the vDisk. That means the C drive attached to the VM is no longer needed. Detach the C drive from the VM as shown in Figures 31 and 32. DO NOT DELETE the C drive, just detach it.

Now that the VM has no C drive, how will it boot? In the PVS console, go to the Target Device, right-click and select Properties as shown in Figure 33.

Change the Boot from to vDisk as shown in Figure 34.

The vDisk contains everything that was on the original C drive and the vDisk is still set to Private Image mode. That means everything that is done to the vDisk is the same as making changes to the original C drive. Any changes made now will persist. When the vDisk is changed to Standard Image mode, the vDisk is placed in read-only mode and no changes can be made to it. Before the VM is powered on, an AD Machine Account must be created. Right-click the target device, select Active Directory and then Create Machine Account… as shown in Figure 35.

Select the Organization unit from the dropdown list as shown in Figure 36.

Once the correct Organization unit has been selected, click Create Account as shown in Figure 37.

When the machine account is created, click Close as shown in Figure 38. If there is an error reported, resolve the error and rerun the process.

Power on the VM and login with domain credentials. Open Computer Management and click on Disk Management. Here you can see the holders for the 10GB Write Cache and 20GB PvD drives and the C drive (which is the vDisk) as shown in Figure 39.

Exit Computer Management.

You can also verify the VM has booted from the vDisk by checking the Virtual Disk Status icon in the Notification Area as shown in Figure 40.

As shown in Figure 41, the Virtual Disk Status shows:

The vDisk status is Active,

The IP address of the PVS server streaming the vDisk,

That the Target Device is booting from the vDisk,

The name of the vDisk, and

The vDisk is in Read/Write mode.

Exit the Virtual Disk Status.

Install the Virtual Delivery Agent

The XenDesktop 7.6 Virtual Delivery Agent (VDA) needs to be installed. Mount the XenDesktop 7.6 ISO to the CD. Double-click the CD drive and the XenDesktop installation wizard starts. Click Start for XenDesktop as shown in Figure 42.

Note: At this time, PvD is only supported for desktop operating systems. PvD will not work and is not supported for XenApp 7.6.

Select Virtual Delivery Agent for Windows Desktop OS as shown in Figure 43.

Select Create a Master Image and click Next as shown in Figure 44.

Select the appropriate HDX 3D Pro option and click Next as shown in Figure 45.

Verify Citrix Receiver is selected and click Next as shown in Figure 46.

Enter the Fully Qualified Domain Name of a XenDesktop 7.6 Controller, click Test connection and, if the test is successful (a green check mark is displayed), click Add as shown in Figures 47 and 48. Repeat until all XenDesktop 7.6 Controllers are entered. Click Next when all Controllers are added.

Verify all options are selected and click Next as shown in Figure 49.

Select the appropriate firewall rules option and click Next as shown in Figure 50.

Click Install as shown in Figure 51.

The VDA installation starts as shown in Figure 52.

When the VDA installation completes, verify Restart machine is selected and click Finish as shown in Figure 53.

Disconnect/unmount the XenDesktop 7.6 ISO from the VM.

Update Virtual Delivery Agent Software

Citrix updates the VDA software often. At the time this article was released, 30-Dec-2014, there was one Public update to the VDA software (ICAWS760WXnn005 where nn is either 32 or 64 for the bitness of your desktop OS).

To check for recommended available updates, in your browser, go to XenDesktop 7.6 Recommended Updates.

Click on Support, select XenDesktop from the drop-down. Change All Versions to XenDesktop 7.6, click on Software Updates and then Public. See if there is an update for XenDesktop 7.6. If there is, download and install the VDA update.

After the VM restarts, log back into the desktop with domain credentials.

Update Personal vDisk Software

Citrix updates the Personal vDisk software often. At the time this article was released, 30-Dec-2014, there was no update to the Personal vDisk software.

To check for an available update, in your browser, go to http://www.mycitrix.com and login with MyCitrix.com credentials.

Click on Downloads, select XenDesktop and Components from the two dropdowns. See if there is an update for XenDesktop 7.6. If there is, download and install the Personal vDisk update.

Log back into the desktop with domain credentials.

Configure Personal vDisk

By default, PvD uses two drive letters: V and P. V is hidden and is a merged view of the C drive with the PvD drive. If drive V is already used, the drive letter can be changed.

If needed, change the hidden PvD drive letter:

Key : HKEY_LOCAL_MACHINE\Software\Citrix\personal vDisk\Config

Value : VHDMountPoint [REG_SZ]

Set this to the drive letter of your choice. Ensure that “:\” is appended to the end of your entry (Example: X:\ )

Both user profile data and applications and machine settings are stored in the PvD. By default, this is a 50/50 split if the PvD size is at least 4GB or larger. The percent to be allocated for applications and machine settings can be configured by setting the following registry value:

KEY: HKEY_LOCAL_MACHINE\Software\Citrix\personal vDisk\Config

VALUE: PercentOfPvDForApps By default, this value is set to 50 Changing this to 80 will result in the V: drive being allocated 80% of the PvD disk



Note: This value must be changed before the PvD is placed into production.

Everything is now complete. Before running the PvD Inventory, follow your standard procedure for sealing the image. This process is unique to every environment. For my lab, I have no antivirus software and I am not using WSUS so I have no registry keys to clear out. Manually run the PvD Inventory. Click Start, All Programs, Citrix, Update personal vDisk as shown in Figure 54.

The PvD inventory starts. Leave Shut down the system when update is complete selected as shown in Figure 55.

After the inventory completes, the VM is shut down.

PVS XenDesktop Setup Wizard

Make a copy of the VM and create a template of the copy. That way the original VM is still available when needed in the future.

When making the template, make sure the template is stored in a storage location that is available when running the XenDesktop Setup Wizard. Change the template to boot from the network only.

Since the C drive was detached, that leaves the Write Cache and PvD storage locations. If you do not, an error “<host resource> has no available templates defined that are fully accessible by all hosts” is displayed during the XenDesktop Setup Wizard. In the PVS console, click on the vDisk Pool node, right-click the vDisk and select Properties as shown in Figure 56.

Change the Access mode to Standard image and Cache type to Cache on device hard drive as shown in Figure 57.

Note: If you leave the Cache type at the default of Cache on server, when you run the XenDesktop Setup Wizard there will not be an option to configure the Write Cache drive size.

Note: I am using Cache on device hard drive for this article. With PVS 7.6, Cache in device RAM with overflow on hard disk is now the popular option. I highly recommend you read the following two articles by Dan Allen before making a decision on the Cache Type to use:

Right-click the Site and select XenDesktop Setup Wizard as shown in Figure 58.

Note: If you get an error popup that states “No Standard Image vDisk exists in this Site”, that simply means the vDisk is still in Private Image mode.

Click Next as shown in Figure 59.

Enter the name of a XenDesktop 7.6 Controller and click Next as shown in Figure 60.

Select the host resource from those configured in Citrix Studio and click Next as shown in Figure 61.

Enter the login credentials for the host resource and click OK as shown in Figure 62.

Select the appropriate template and VDA version and or functionality desired and click Next as shown in Figure 63.

Select the vDisk and click Next as shown in Figure 64.

Select whether to Create a new catalog or Use an existing catalog and click Next as shown in Figure 65. If you Create a new catalog, enter a Catalog name and Description.

Note: The wizard creates a Machine Catalog in XenDesktop and a Device Collection in PVS with the Catalog name entered here.

Select Windows Desktop Operating System and click Next as shown in Figure 66.

Since we are using PvD, select The same (static) desktop, also select Save changes and store them on a separate personal vDisk and click Next as shown in Figure 67.

Make the appropriate choices.

For this lab, I am creating 3 VMs (desktops) with 2 vCPUs, 2 GB RAM, a 10GB write cache disk, a 20 GB PvD disk, changing the PvD drive to Y and selecting BDM disk. Click Next as shown in Figure 68.

Note: If you do not see the option Local write cache disk that means you left the vDisk at the default of Cache on server. Exit this wizard, correct the vDisk properties and rerun the wizard.

Select Create new accounts to have new AD computer accounts created and click Next as shown in Figure 69.

Select the Domain, OU, Account naming scheme and click Next as shown in Figure 70.

Verify the Summary information, click Finish, as shown in Figure 71, and the wizard will begin creating the following:

Virtual Machines

AD computer accounts

Target Devices

Machine Catalog in XenDesktop Studio

BDM

When the wizard is complete, click Done as shown in Figure 72.

Looking at the Device Collection in the PVS console (you may need to right-click the Site and select Refresh) shows the three target devices as seen in Figure 73.

Note: In the previous articles, each of the new target devices always booted automatically, one at a time, with no intervention on my part. That did not happen with BDM.

Looking in Active Directory Users and Computers shows the new computer accounts as seen in Figure 74.

In the hypervisor, look at the storage for one of the new virtual machines. You will see a BDM partition has been created as shown in Figure 75.

Change each of the new VMs to boot only from the hard drive.

Power on each of the new VMs. As shown in Figure 76, the VMs will boot from BDM.

Each VM will power on and then shut down. This is normal.

Note: In the previous articles, each of the VMs powered on and shutdown automatically with no intervention on my part. This did not happen with BDM.

Add Machines to Machine Catalog

In Citrix Studio, right-click on the Machine Catalogs node and select Refresh. The new Machine Catalog created by the XenDesktop Setup Wizard is shown in Figure 77.

Note: In the previous articles, I did not have to manually add the machines to the Machine Catalog before I created the Delivery Group.

Click Add Machines in the right Actions pane as shown in Figure 78.

Enter the IP address of the PVS server and click Connect as shown in Figure 79.

Select the Device Collection that contains the new machines and click Next as shown in Figure 80.

Review the Summary information and click Finish as shown in Figure 81.

The machines are added to the Machine Catalog as shown in Figure 82.

Create XenDesktop Delivery Group

Currently, there is no Delivery Group to deliver the desktops. Right-click the Delivery Groups node in Citrix Studio and select Create Delivery Group as shown in Figure 83.

Click Next as shown in Figure 84.

Select the Machine Catalog and the number of machines to be added from the catalog to this delivery group and click Next as shown in Figure 85.

Select Desktops and click Next as shown in Figure 86.

Click Add… as shown in Figure 87.

Use the Select Users or Groups dialog to add users and click OK as shown in Figure 88.

Click Next as shown in Figure 89.

Select the appropriate StoreFront option and click Next as shown in Figure 90.

Enter a Delivery Group name, Display name, an optional Delivery Group description for users and click Finish as shown in Figure 91.

From here, there are many options that can be configured. For this lab, I edited the Delivery Group and set both Weekdays and Weekend peak hours to 24 hours as shown in Figure 92.

Every XenDesktop project I have been on, the customer wants all desktops powered on at all times. To do this, on a Controller start a PowerShell session and enter the following commands as shown in Figure 93:

add-pssnapin *citrix*

Get-brokerdesktopgroup | set-brokerdesktopgroup -PeakBufferSizePercent 100

Note: I had a reader leave me a comment on the original article that said this setting does not apply to user-assigned desktops. But, I never got more than one desktop to start (out of the three in my lab) until I set the PeakBufferSizePercent. As soon as I entered that command, within a few seconds the other two desktops powered on.

Exit the PowerShell session. After a few minutes, all the desktops will power on. Back in the PVS console, the vDisk will show three connections and all three target devices will be powered on as shown in Figures 94 and 95.

Understanding How Personal vDisk Works

Now let us look at how the Write Cache and PvD drives work.

All three desktops are powered on. I will log in as a different user into each desktop.

All three users are presented with the standard Windows 7 desktop configured during the creation of the master image VM as shown in Figure 96.

Before we take a look at user customization and personalization, let’s see what is in the Write Cache and PvD drives. I had to show system and hidden files and operating system files. Figures 97 and 98 show the Write Cache drive which shows the write cache file, page file, and the EventLogs folder.

Figure 99 shows there is not much of anything useful to see on the PvD drive.

What about the BDM partition? As shown in Figure 100, it is an 8MB partition that does not have a file system recognized by Windows and is not seen by the user.

Back in Citrix Studio, refresh the Delivery Group and you will see there are now Sessions in use with no Unregistered or Disconnected machines as shown in Figure 101.

Double-click the Delivery Group to see detailed information as shown in Figure 102.

The first user is Ms. Know-It-All who probably knows Windows 7 better than the helpdesk team. She configures her desktop to get all the Windows 7 “frilly” stuff out of her way as shown in Figure 103.

The second user is Ms. Tree Hugger who wants a pretty cool picture for her background as shown in Figure 104.

The third user is Ms. Astrophysicist who needs a picture of her Tesla as her background as shown in Figure 105.

Now that each user has customized their desktop, reboot each desktop, log back into each desktop and verify the user’s customizations persisted.

User Installed Software

What about installing software? User1 installed NotePad++ since she knows more than you do anyways, User2 installed Google Chrome to save the world from Internet Exploder and User3 installed Mathematica so she could do some physics work. The three desktops are shown in Figures 106 through 108.

Now that each user has installed an application, reboot each desktop, log back into each desktop and verify the user’s installed application persisted. Since we are using PvD to allow users to install applications, where are the applications installed? Looking at User1, we can see that Notepad++ was installed to c:\Program Files\Notepad++ as shown in Figure 109.

User2’s Google Chrome is installed to C:\Program Files\Google\Chrome\Application as shown in Figure 110.

User3’s Mathematica is installed to C:\Program Files\Wolfram Research\Mathematica\10.0 as shown in Figure 111.

The C drive view is a combination of the hidden drive, V by default, and C. When users install applications they will install as usual to the C drive. There is no need to install to the visible PvD drive, P by default.

Updating the Master Image

How is the master image updated if an application needs to be installed that all users need? Simple, in the PVS console create a Maintenance version, update it, test it and then make it available to users. In the PVS console, right-click the vDisk and select Versions as shown in Figure 112.

Note: The virtual machine used for updating the Master Image must not have a PvD disk attached.

Click New as shown in Figure 113.

A new Maintenance version of the vDisk is created as shown in Figure 114. Click Done.

In the PVS console, go to the Device Collection the original master target device is in, right-click the target device and click Properties as shown in Figure 115.

Change the Type from Production to Maintenance and click OK as shown in Figure 116.

Note: In a production environment, you would have a dedicated Target Device to use for Maintenance versions of vDisks.

In the hypervisor, start that VM and open the VM’s console. An option to boot into either the Production version or the Maintenance version is shown. Select the Maintenance version as shown in Figure 117.

What has happened is that the target device has been configured to boot from a Maintenance image and during the bootup communication, the PVS server recognized the MAC address and offered the target device the maintenance vDisk to boot from. The maintenance vDisk is in Read/Write mode so changes can be made to the vDisk. Log in to the desktop with domain credentials. I installed Adobe Acrobat Reader as shown in Figure 118.

Note: Whatever software is installed, verify that any license agreements and popups are acknowledged and any other configurations needed are done before sealing the image and running the PvD Inventory. For example, in Acrobat Reader I acknowledged the license agreement and disabled updater.

Before running the PvD Inventory, follow your standard procedure for sealing the image. This process is unique to every environment. For my lab, I have no antivirus software and I am not using WSUS so I have no registry keys to clear out. Manually run the PvD Inventory. Click Start, All Programs, Citrix, Update personal vDisk as shown in Figure 119.

The PvD inventory starts. Leave Shut down the system when update is complete selected as shown in Figure 120.

After the inventory completes, the VM is shut down. Once the VM has shut down, in the PVS console, right-click the vDisk and select Versions as shown in Figure 121.

Select the Maintenance version and click Promote as shown in Figure 122.

PVS 7.6 adds the ability to now have a Test version for a vDisk that uses PvD. This was not possible prior to version 7.6.

Select Test and click OK as shown in Figure 123.

The vDisk version is promoted to Test, as shown in Figure 124. Click Done.

In the PVS console, go to the Device Collection the original master target device is in, right-click the target device and click Properties as shown in Figure 125.

Change the Type from Maintenance to Test and click OK as shown in Figure 126.

Note: In a production environment, you would have dedicated Target Devices to use for Test versions of vDisks.

In the hypervisor, start that VM and open the VM’s console. An option to boot into either the Production version or the Test version is shown. Select the Test version as shown in Figure 127.

What has happened is that the target device has been configured to boot from a Test image and during the bootup communication, the PVS server recognized the MAC address and offered the target device the Test vDisk to boot from. The Test vDisk is in Read-only mode so no changes can be made to the vDisk. Log in to the desktop with domain credentials.

There are several things to notice about the Test version of the vDisk:

The application that was installed for all users is there (Figure 128), The vDisk is in Read-only mode (Figure 129), but The write cache is located on the PVS server (Figure 130) because, There is no Write Cache drive (Figure 131), There is no PvD drive attached (also Figure 131), but The stub holders for the write cache and PvD drives are still there (Figure 132).

Why is there no BDM partition in Figure 132? The BDM partition was created for the VMs created by the XenDesktop Setup Wizard. The VM used for the Maintenance and Test versions is the original VM used to create the vDisk placed into PVS. The original VM boots from the network so it can connect to the vDisk.

Once testing is completed, shutdown the VM.

Once the VM has shut down, in the PVS console, right-click the vDisk and select Versions as shown in Figure 133.

Select the Test version and click Promote as shown in Figure 134.

Select Immediate and click OK as shown in Figure 135.

The updated vDisk is now available for use as shown in Figure 136. Click Done.

Verify the Master Image Update

Restart the desktops for them to start using the updated vDisk. The desktops will automatically reboot after a few minutes. This is normal. Wait until this reboot is complete before allowing the users access to the desktop. Log in to each desktop and verify the new application is available and the user’s original customizations and installed applications persisted after the update. The three desktops are shown in Figures 137 through 139.

And there you have it, one way to do a XenDesktop 7.6 with Personal vDisk using BDM process.

Citrix lists four ways to do this process in eDocs, three with PVS and one with MCS. http://support.citrix.com/proddocs/topic/provisioning-7/pvs-inventory-vdisks-pvd.html

I think it is strange they have MCS listed as a process in the PVS documentation but that is beside the point.

I hope this detailed process explanation will help you in working with PvD and BDM with XenDesktop 7.6 and PVS 7.6.

Thanks

Webster