Citrix released Citrix Virtual Apps and Desktops 1903 on the 28th March 2019. See the video below for Ultima’s highlights of this release.
MCS Storage Optimisation (MCSIO) has had an overhaul in 1903 and has unlocked some great new options for administrators!
So what’s changed? Cache in RAM and overflow to disk originally appeared as a Citrix Provisioning Services capability that was subsequently replicated in MCS as MCSIO. The main difference being that they have different implementations – PVS using a file based cache, effectively a VHD placed on an formatted volume attached to each machine – MCS using a disk based cache, attached to the machine but generally inaccessible.
I won’t get into the “why” of the different implementations, but they were different and it showed. The PVS cache method has proved to be robust and highly stable. The MCS cache method, less so.
What do you do if you’re Citrix? You use the PVS caching mechanism for MCS! Not quite as straightforward as it may sound, but if you have a tried and trusted approach, then it must be a good idea to lead with that.
So what does this give us in 1903? Well, for those of you deploying machine catalogs with MCSIO, you will notice that your deployed machines will have a D:\ drive attached (much like PVS!) . In this D Drive you will have an mcsdif.vhdx file – this is where the magic happens. For sizing purposes, you need to ensure that your cache disk is big enough to contain:
- Any writes/changes that occur in the lifetime of that VM (in between reboots)
- The system pagefile
Note: If you’re deploying in Azure, the pagefile won’t be moved here, it will stay on the temporary storage assigned to your instance.
One important thing here is that this new D drive is persistent, it’s the VHDX that will be reset on reboot, not the disk. First off – how did the disk get there? Well, the good news is that MCS takes care of it for you as below:
- New VM is Provisioned.
- Write-Cache Disk is attached.
- VM Boots
- Write-Cache Disk is formatted
- VM Restarts
- VM Is booted and usable
Note that you now have two reboots before a newly provisioned VM is available. I should also mention here that I said this new disk is persistent, this is true with the exception of Azure.
In Azure, storage costs money. If you have lots of instances deployed, that can mean lots of money. The fine people at Citrix have decided that in Azure by default this new Cache disk will be removed when the instance is shutdown. The downside of this is that when powering on an instance in Azure the boot time will be extended by virtue of the need for an additional reboot to configure the cache disk. By default in this instance means that you can change the behaviour and make them persistent if you prefer:
Using PowerShell to create an Azure catalog with persistent write-back cache disk
To configure an Azure catalog with persistent write-back cache disk, use the PowerShell parameter New-ProvScheme CustomProperties. This parameter supports an extra property, PersistWBC, used to determine how the write-back cache disk persists for Azure Resource Manager hosted MCS provisioned machines. The PersistWBC property is only used when the UseWriteBackCache parameter is specified, and when the WriteBackCacheDiskSize parameter is set to indicate that a disk is created.
Why is this new disk a good thing – well firstly it should work better! Secondly, its a persistent storage location that you can use for things like:
- Redirected Event logs
- Application Log Files
- Antivirus DAT files
- Ivanti UWM Configuration Files
- Basically anything that would benefit from being persisted between reboots.
Now a word of caution, Citrix recommend that if you have MCSIO enabled already, you may wish to re-evaluate the storage size allocated to ensure that you have allowed for pagefile storage as well as writes and changes. Obviously, if you plan on storing anything else there you need to factor that in to your sizing too.
This can affect existing catalogs, not just new ones, so be aware that if you deploy an update to an existing machine catalog, then it will use the already configured RAM Cache and Cache Disk Sizes configured, the existing cache disk will be formatted at first boot of the VM with the 1903 VDA installed. If you need to change the configured sizes, you will need to create new machine catalogs as it is not possible to change these sizes after the catalog has been provisioned. It is also not possible to enable MCSIO after provisioning, so again if it is not already enabled, you will need to create new machine catalogs.
For help planning your upgrade or to find out more about your upgrade options, please contact your account manager for further information.
Written by Andy McCullough (Solutions Architect)
