Category Archives: Note

This post outlines the steps to build a Reverse Image of a Citrix Provisioning Services vDisk with XenApp 6.5 Server to a VM with locally attached hard disk.

Whenever you have to install or upgrade software on a vDisk that interferes directly with the Citrix Provisioning Services infrastructure you need to choose the Reverse Imaging approach. The installation of such software would fail within a system that was booted either from the vDisk in Private mode or from a Maintenance version of the vDisk.

Reverse Imaging means booting from vDisk in order to capture the vDisk’s contents to a local hard drive. Afterwards you can boot from the local hard drive an make the changes without any of those issues that would arise if you’d have tried to change the vDisk directly.

Reverse Imaging is a time-consuming task. Normally you’ll capture a new vDisk following the Reverse Imaging process. In total you should plan a man-day including preparation, performing the Reverse Imaging, applying the updates, and capturing a new vDisk. Therefore, I recommend to start with it just at the beginning of the work day.

Dedicate or create a VM and PVS target device for the Reverse Imaging process. (For istance, an already existing update VM/target device for vDisk maintenance purposes would be a perfectly possible candidate for Reverse Imaging.)

Create and attach a new local hard disk to the Reverse Imaging VM that matches at least the size of the vDisk. (The HD size can be greater though, meaning that with Reverse Imaging you can’t only update software like VMware Tools but also increase the vDisk size as a side benefit.)

Prepare the source vDisk using one of this options:

Create a new version of the vDisk and keep the predefined mode, that is “Maintenance” (PVS 6 style)

Copy the vDisk and put it in Private mode (PVS 5 style)

Check or set the following target device properties:

Boot from: vDisk

Type: Maintenance

Double-check the target’s vDisk assignment. (Use the vDisk prepared in the third step)

Boot the target VM from vDisk and log on

Launch the disk management mmc snap-in.

Initialize the new local hard disk. (Keep default settings.)

Partition and format the hard disk. Keep the default disk type (Basic). The partition needs to be either a simple volume or at least a primary partition. (PVS reverse imaging doesn’t support both extended partitions and dynamic disks.)

Once again, the Image Builder will automatically reboot the target. Log on and confirm a message box saying “The device image build is complete”

Launch the disk management mmc snap-in and mark the partition of the new local hard disk as active.

In the PVS console, change the target’s “Boot from” setting to “Hard Disk”

Reboot the target and apply the required changes, updates, whatever..

Prepare capturing of a new vDisk with PVS Imaging Wizard, reboot, and log on to let XenConvert building the vDisk.

Close XenConvert to let Windows finalize the logon process.

In the PVS console, change the target’s “Boot from” setting to “vDisk”. Leave the vDisk in Private mode

Shutdown the target device VM.

Detach the local hard disk that was used to hold the Reverse Image.

Boot the target device VM and log on.

Launch the XenApp Server Role manager to prepare this server for imaging. (As the server already left the farm in step 8 you need to deselect the corresponding option.)

Shutdown

In the PVS console, change the new vDisk’s mode to Standard and configure the relevant targets to boot from this vDisk.

Clean up. For example you won’t ever use again both, the local hard disk created in step 2 and the Private mode vDisk or vDisk Maintenance version prepared in step 3.

Disclaimer: I hope that the information in this post is valuable to you. Your use of the information contained in this post, however, is at your sole risk. All information on this post is provided “as is”, without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by me. Further, I shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.

Back in the days of Citrix Provisioning Services 5.x it was common practice to copy an existing vDisk mostly due to maintenance reasons in order to apply updates, install new software and so on and so forth. On the contrary, sometimes the copy of a vDisk was needed as a starting point to create a new vDisk for other purposes (introduction of a new XenApp application silo/worker group for example).

Aside from the fact that Citrix introduced with PVS 6.0 a more flexible and robust vDisk updating approach based on VHD chaining, the good old copy approach still works. In the case of an unversioned vDisk the procedure is as straightforward as in PVS 5.x (copy/label the according *.vhd and *.pvp files, then choose ‘Add or Import Existing vDisk’ in the context menu of the vDisk Store).

If you go the same path with a versioned vDisk (copy the complete VHD cain) you’ll get an error message. Is it impossible to copy a versioned vDisk after all? No, you have two options: merge and export/import

Merging the VHD chain of the source vDisk seems to be the most obvious preparation step in order to copy the vDisk since it results in a single set of VHD/PVP files, meaning that afterwards you’re able to copy that vDisk as simple as ever. But to merge means to commit oneself to a single source vDisk version. You’ll lose flexibility

If you need to keep the source vDisk with all its versions as it is and want to get a copy anyway you should choose the export/import option. This approach is actually supposed to export and import both versioned and unversioned vDisks from an existing store to a store in a different PVS farm. However you can leverage it to get a copy in one and the same vDisk store as follows:

Open the PVS console, right click the source vDisk, and choose ‘Export vDisk…’. A dialog appears.

In the export dialog, choose the the latest version in the drop-down menu named ‘Export versions starting at’, then click OK. After a short delay the dialog closes. In the source vDisk’s store you’ll find a manifest file containing the entire information about the versions of that vDisk. The manifest file name matches with the name of the vDisk and it has a .xml suffix

Rename the manifest file using the name of the copied vDisk.

Open the manifest file in a text editor and accurately replace all references to the name of the source vDisk with the name of the copied vDisk. Double-check the changes, then save the file.

Now, you should have a set of VHD/AVHD/PVP file and an XML file with the same base file name. And the manifest/XML refers to the new VHD and AVHD files.

In the PVS console, right click the vDisk store, and choose ‘Add or Import Existing vDisk…’. A dialog appears.

In the import dialog, check the settings for Site, Store, and Server, then click Search. After a short delay the copied vDisk will be displayed.

Check the vDisk, check/uncheck the load balancing option as wanted, then click Add. After a short delay a popup appears saying that the import was successful. Click OK, then click Close in the import dialog.

Disclaimer: I hope that the information in this post is valuable to you. Your use of the information contained in this post, however, is at your sole risk. All information on this post is provided “as is”, without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by me. Further, I shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages.

Initially I intended to migrate the stuff related to batch scripting to the new blog as well. Due to lack of time and motivation I decided to postpone this task or rather to wait if I receive requests like “I’m wondering if you are considering bringing back your old content back”

I will tell you a secret: the old site is still online – check Batch Howto. In order to avoid trouble with the new site I needed to remove the permalinks, therefore I’m afraid your bookmarks/favorites to old site content may be broken.