Scenario: A Citrix Engineer has updated the XenDesktop master image, which the head office users connect to in order to use Personal vDisk. When testing the new image, the engineer discovers that…

Mei-Ling H.Nov 14, 2025

The answer is A, and the key word to notice in that option is "NOT," which flips the meaning completely if you read too fast. Personal vDisk keeps an inventory that tracks what belongs to the base master image versus what the user has added on their own disk. When you update the master image and the Update Inventory process gets interrupted, that inventory record becomes corrupted or incomplete, so XenDesktop can no longer correctly separate base image data from personal data, and the feature breaks. Options B and D describe real PvD considerations but they are about setup or capacity, not about what causes failure during an image update specifically. Always protect the Update Inventory process from interruption when pushing a new master image and you will avoid this problem on every future update.

Lena V.Oct 25, 2025

The Update Inventory process is what gives Personal vDisk a clean baseline to compare against after a master image change, so if it gets interrupted the PvD layer has no reliable reference point and breaks. Anyone know exactly when in the image prep workflow that inventory step has to finish before you seal and shut down the master, because I want to make sure my team is not cutting it too close?

Yusuf A.Oct 21, 2025

I was leaning toward C because my senior always drills us about keeping the admin profile clean when prepping a master image, but then I remembered him explaining that the Update Inventory process is what actually syncs the new image layers with the PvD data, so if that gets cut short the whole thing breaks. Interrupting that process mid-run is the most common way the PvD feature goes sideways during a master image update, which is exactly what the question is describing.

Ingrid P.Nov 1, 2025

The Personal vDisk architecture depends on a clean inventory snapshot of the master image so the system knows exactly what belongs to the base layer versus what the user has accumulated on their PvD. When that Update Inventory process gets cut short, the PvD driver loses its reference point and cannot correctly separate the two layers on the next boot, which is precisely what breaks the feature. The other options are noise for this scenario, B and D address storage and capacity concerns that have nothing to do with the synchronization step, and C is about a different class of PvD conflict involving binary placement. So here is what I am genuinely unsure about and would love a more experienced engineer to clarify: does an interrupted Update Inventory leave the PvD in a recoverable state if you re-run the process afterward, or does the corruption require you to rebuild from the old master image snapshot before the update?