Citrix Provisioning Services delivery of standard images to target machines relies on write-cache. The most common write-cache implementation places write-cache on the target machine storage. Independent of physical or virtual nature of the target machines this storage has to be allocated and formatted to be usable.
At the same time storage dedicated to write-cache needs occasional maintenance such as formatting and possibly reallocation to accommodate changes in required storage capacity.
This article discusses automation of both creation and maintenance of write-cache partitions. The methodology can be utilized with both local and shared storage.
- Standalone (AD membership is not required) Windows 7 or Windows 2008 R2 VHD image that is ready PVS delivery in a “standard” mode with caching on the PVS server.
- Write-cache storage, physical or virtual.
- Network share that can accommodate logging if necessary.
- On Provisioning Server(s) create new device collection and call it, for example, “FLUSH”.
- Create template device that is configured to boot from the designated VHD image with a batch file discussed below.
- When ready, move PVS devices that require write-cache partition maintenance to the “FLUSH” collection. Simultaneously start as many devices as the PVS environment can accommodate.
- Once the write-cache partition update is complete, target machines will automatically shut down and can be moved back to their original collections with their associated templates.
The “flush” batch job is triggered via Windows Task Scheduler on system startup. The execution identity can be set to “System” or other account with sufficient execution and (optionally) network access privileges. This process accomplishes the following:
- Clears any partitions from the write-cache storage.
- Allocates one partition to span all available disk space.
- Applies unique Disk ID “pre-socialized” to the subsequent PVS images to avoid “New Hardware found” messages.
- Formats partition with proper disk alignment and the desired block size.
- Creates folder structure if necessary. For example, folders can be created for event log redirecting to the write-cache partition for persistency.
- Creates a log file with machine name and write-cache partition information with an optional copy to a network share.
- Triggers machine shutdown when the job is complete.
Batch file “flush.bat” placed in “C:\batch” folder:
:: ========================================================== :: WARNING: contents of the selected disk will be deleted!!! :: ========================================================== diskpart /s C:\batch\diskpart.txt >> C:\batch\%computername%.txt E: md eventlogs dir >> C:\batch\%computername%.txt move C:\batch\%computername%.txt E:\ shutdown -s -t 0
Disk Partition Utility script “diskpart.txt” called from the “flush.bat” and is also located within the same “C:\batch” folder:
select disk 0 clean create partition primary format fs=ntfs label="LOCAL" quick assign letter=E uniqueid disk ID=AABBCCDD uniqueid disk
- Any persistent data that could have been stored on the write-cache partition can be preserved by updating the above batch files with backup/restore capabilities.
- Unique write-cache disk ID should be “pre-socialized” to all target images intended to be used with these write-cache partitions or just replaced with the ID value already known to these images.
- Described methodology works for both physical and virtual target machines. It is hardware and hypervisor agnostic.
- Both local and shared storage types are supported.
- There is no dependency on VM templates that are commonly used within the virtual environments when preparing write-cache partitions.
- Expected data transfer size per machine during the discussed process is within 250-350Mb per machine. Total execution time is about 30-45 seconds on top of the boot time. Boot times can be improved by preventing any unnecessary processes that are loaded on the “FLUSH” image, for example, disabling of unnecessary services such as Print Spooler, Windows Update, etc. is recommended.