Citrix Provisioning Services (PVS)

Citrix Provisioning Services (PVS) write cache disk assignment

As you can imagine we design, build and support quite a few Citrix Provisioning environments. We also consult and optimise Citrix implementations that are already live and a common issue we see is with the configuration of the PVS  Write Cache disk. This issue could be experienced during the building phase or later, once the PVS environment is already in production. It is important to ensure that the virtual machines will be consistent with the drive letter assignment to avoid unpleasant surprises.

As an example, let's say we have provisioned virtual machine's with a ‘Data’ (D:) drive and persistent ‘WriteCache’ (E:) drive, as this is typically where PVS write cache, Event Logs, UPM Logs, WEM Cache, page file or other required persistent information is stored.

If those drive letters are “swapped”, it means ‘Data’ drive now has ‘E:’ letter and vice versa. When this situation occurs you are guaranteed to experience some problems. Even more critical, if we have ‘D:’ drive hardcoded in the Citrix published application, script path or any other configurations. We first started to notice this problem from the introduction ‘RAM cache with overflow to hard disk’ as PVS disk cache mode was released back with the PVS 7.1 version. Its was dependant on the hypervisor used and related configurations though.

Citrix recommends using this cache type for PVS as it combines the best use of RAM with the stability of hard disk cache. As such, if you find that you are in this situation there are 2 ways of fixing the issue.

  1. Manually assign PVS write cache disk -

This is not commonly known by many Citrix administrators. It is quick, simple, and permanent solution. Idea is to create a file named {9E9023A4-7674-41be-8D71-B6C9158313EF}.VDESK.VOL.GUID in all of the drives, that you don’t want cache drive to be created. PVS bnistack driver skips it as a candidate for picking up write cache drive.

  1. Making sure persistent PVS write cache disk ID is exactly same as Golden/Master Image -

To make things even more simple, here are brief steps:

  • Note ‘uniqueid’ disk ID from Golden/Master machine - select disk number, which belongs to cache disk and type ‘uniqueid disk’ (‘diskpart’ commands are available in the above-mentioned Citrix article).
  • Run ‘diskpart’ on the impacted PVS target virtual machine, select cache disk (same steps as on Golden/Master) and enter ‘uniqueid disk ID={previously noted Golden/Master machine cache disk ID}
  • Reboot affected PVS target device

Startup check script is recommended to fix the issue before it appeared or to avoid manual work. Below script can be used to check if cache drive appears at all or path is correct. Depending on the environment, script may need to be modified. I just wanted to share the example of how it could be achieved using PowerShell. Idea is to create temporary text file with required ‘diskpart’ commands and use it as ‘ArgumentList’ for ‘diskpart.exe’ process.

If (-not (Test-Path -Path "E:\pvsvm")) {

    # E partition does not exist, create partition

    If (-not (Test-Path "C:\Temp\diskpart")) { New-Item -Path "C:\Temp\diskpart" -ItemType Directory }


    # Create Diskpart Script

    $DiskpartScript = "SELECT DISK 1







    Set-Content -Path "C:\Temp\diskpart\Partition.txt" -Value $DiskpartScript


    # Start Diskpart

    Start-Process -FilePath "diskpart.exe" - ArgumentList "/s C:\Temp\diskpart\Partition.txt" -Wait

    # Remove Temp location

    Remove-Item -Path "C:\Temp\diskpart" -Force -Recurse

    # Reboot the VM

    shutdown /r /t 0


We hope this helps but if you would like our assistance, please get in touch and we can arrange a consultation to discuss. 

Was this post helpful?