Citrix Provisioning Server vDisk Update Management

Citrix Provisioning Server (PVS) is now at version 6.1.  Released in version 6.0 was the vDisk Update Manager and I think it is worth some time looking more closely at this feature.

Once installed and configured the PVS management console has a new node the vDisk Update Manager.  This has three sections; Hosts, vDisks and Tasks.

Hosts; references the hypervisor hosts in use, XenServer ESX and Hyper-V are all supported.

vDisks; is the PVS vDisks enabled for update management.

Tasks; is the automated scripts that power the Electronic Software Distribution (ESD) client software.  Microsoft System Center Configuration Manager (SCCM), Microsoft Windows Update Service (WSUS) and custom scripts are all supported.  Please note: the ESD client software must already be installed in the vDisk image.

First let’s take a look at manual updates. In previous versions you had to make a copy of the vhd file (vDisk), mount this against a new machine in PVS, boot and make the changes required, shutdown the image, increment the vDisk version number and make it available to all machines.  It was possible to script this process via PowerShell however in my experience not everyone did this and there was still manual work to do to integrate this into your environment.

To utilise the new features you require a running environment with machines utilising a standard mode vDisk.  This feature is only available for standard mode disks; private disks are read / write and therefore can be managed by existing ESD tools.

Step one is to add the host that you are using; right click on the Hosts node and follow the wizard.  You will require the correct host / pool credentials.

Step two is to add a vDisk to this tool; right click on the vDisks node and follow the wizard.  This will search your Store for available vDisks and ask you to enter the VM on your host that will be used as your maintenance VM. Finally it will require an AD machine account in order to process the updates to the vDisk.  If you have not created the VM on your host with then name specified in this step do so now.

In the image below you can see the PVS Services Console with the properties of the vDisk Update Management node highlighted.  It shows that the vDisk in the Store StoreW7 is on host XenServer-1 and the VM on the host that will use this disk is called W73.  The vDisk has to exist before you start step two however it does not check the Host to make sure the VM is there, so this can be created after if required.  It will however need to be present for this process to work correctly, as highlighted below XenCenter is showing a VM with the name of W73.

Once this is completed from the Stores node you can select the vDisk and manage the Versions.  Right click on the vDisk in the Store and select Versions.

Select New; this will create a new disk in Maintenance mode.  To edit this disk boot your maintenance VM from the Host.  Once this is completed if you refresh the vDisks Versions  console you will see a single device is now accessing this version of the disk and that the Access type is Maintenance. Please note: you have not had to remove any locks form the existing vDisk, log off any users or shut down machines to start this process.

You can now make any changes required to the VM as the version you are using is in read write mode.  To achieve this PVS is using avhd files and creating a chain to the original disk.   This saves on time and disk space when making changes,  it also means if we are not happy with the results we can revert back quickly to the previous image.  Once we are satisfied with the build we can merge all updates, this stops a long chain becoming a performance drain.
Reboot the VM to apply any changes and then shut the Maintenance VM down.  You can then Promote the vDisk and can set the access version to Test or Production.  If you set it to Production and apply the changes immediately, on next reboot all users will have access to this disk.

Before reboot the VMs are still using disk 7.3

After reboot they are now using 7.4

As you can see this is a great improvement on the original way of updating the vDisk.  However you will not always want to run through this process, especially when it comes to patching.  This is where the Tasks feature of the vDisk Update Management tool comes into play.  To implement; right click the Tasks node and follow the simple steps.  This will by default allow you to connect to WSUS, SCCM or implement pre or post scripts.  Like all tasks this can be scheduled and after the update the vDisk can be placed into Maintenance, Test or straight into Production modes.

In my opinion simplifying this process for desktops is a great win for XenDesktop.  It makes it an easy step to get to grips with PVS and by integrating into SCCM and WSUS most desktop admins see significant advantages to their current virtual desktop update process.  If you couple this with the advantages of PVS in terms of single image disk management, read IOPS cache and control over the write IOPS then we now have access to a powerful desktop management tool.

Finally lets not forget that all these advantages are available to XenApp too.  With a number of organisations now virtualising XenApp servers the number of server instances is on the rise, what better way to manage them than with PVS.


Stephen (comments below) has provided some links to PVS documentation that go into more detail on additional tasks.  Thanks Stephen.

Creating and Managing Tasks

vDisk Update Task Properties

Thread: vDisk update: custom scripts

***Update*** 23/11/2012

You should all read Jarian Gibson’s post – Great article  Updating Provisioned XenApp vDisks: To XenAppPrep or not to XenAppPrep?

18 thoughts on “Citrix Provisioning Server vDisk Update Management”

  1. This is a great post. Several people have mentioned this feature recently and its good to finally understand how it works.

  2. Hi just wanted to say that I like your article very much. Please keep up the good posts Thanks a ton! and Have a good day

    1. The STA written to CtxSta.config is uiunqe, however, when the Master Target is deployed to the provisioned servers, they all end up with the same STA ID because they are all using the same image. According to the :During the resealing process, the updated Server Configuration Tool: Removes server-specific information, such as WSID in MF20.dsn, WSID in RadeOffline.dsn. Creates a uiunqe Secure Ticket Authority (STA) ID in CtxSta.config, using the MAC address.I have read reports that checking the Remove this current server instance from the farm checkbox in the XenApp Server Configuration Tool will cause a uiunqe STA ID to be generated when the provisioned servers boot, but I have not tested this myself. Regardless, I prefer using the script because it eliminates the possibility of a production outage due to a small mistake like forgetting to check the checkbox.

  3. I’m curious. You mention at the end of the article that “these advantages are available to XenApp too”. Not sure what you mean by that …. Are you talking about performing updates on XenApp servers that have been provisioned by provisioning server?

    1. Chris, Correct. XenApp Platinum includes the use of PVS. When scaling out a XenApp farm in this way you can use the same disk update utilities to manage your XenApp vDisks.

  4. Hey Jonathan,

    Great article, thanks mate.

    Is it still best practice to run the optimizations again. Such as:

    1. Prepare this server for imaging and provisioning
    2. sdelete
    3. chkdsk
    4. ipconfig /flushdns
    5. Provisioning Service Device Optimizer

    1. Blair,

      Good question. You wouldn’t need to run the optimizer again or need to go through the process of “preparing the server for imaging”. You could go though the process of cleaning up the disk however I would say the impact would be low because streamed disks are in read only mode. Therefore the overall changes are only occurring as part of an update process.

  5. You are my new personal Jesus. In my environment due to storage needs MCS is not an option and this is MCS-level easy update management. Thanks a lot!

  6. If you’re using multiple PVS servers in a load-balanced configuration, make sure that -after- you promote the vDisk that you copy the updates to all the PVS’s. If the time-stamp is off it won’t show it’s replicated across servers.

    1. Thanks for the comment and an interesting point. How are you making sure the updates are propagated and what are you using for the vDisk store?

      1. We’re using local server storage for the vdisk stores. We have 3 physical PVS servers and 1 vm PVS (for network-related issues testing). I’m having to make changes and updates on PVS1, and then have to manually copy the vdisk to the other servers after deleting the old version so the time stamp isn’t off. It’s a real pain compared to what I had with MCS.

        1. And as you know.. right clicking the vdisk will show replication status… that is how I am verifying they match.

          1. Are you using local storage to keep the read writes in local locations? PVS is normally quite good with reads as they go through the server memory space and are then pull out of there,with writes you can create a local disk on a VM and place the writes to local storage.

        2. We use DFS-R to replicate the local vDisk store between all the PVS servers – simple! (exclude lock files from replicating)

  7. Great article. To add to the conversation, here are a couple of links that tell you how to continue with the process of adding tasks; I work for Citrix and had a case where there was some confusion as to how to proceed further.

  8. Can somone confirm if it is necessary to run xenappprep /PVS after creating a a new version in maint. mode and making the changes to it?

    Also, if not, what about after merging the versions?

  9. I’ve got a question maybe someone here can help me with. I’m using KMS licensing for my VDAs AND PVS vDisk Mgmt. Using the “old manual method”, you would create a copy of said vDisk, remove locks, etc, then, you would change KMS to none. Run your updates, put the machine back in standard, then change licensing back to KMS. How do you handle KMS w/ versioning?

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.