So continuing to troubleshoot the Web Studio creat...
# citrix-provisioningj
Jeff Riechers
02/14/2025, 2:00 PMSo continuing to troubleshoot the Web Studio created PVS machines. The PVS image is deployed to Azure via IPS, and that works great for the PVS console created machines. But Web studio machines will only do server side caching. I made a copy of the latest image in Azure. Opened it in Read/Write, closed it. And made it Standard. And it properly cached to ram fallback to disk. Switched back to the original non-opened disk, and it went back to server side. So it looks like something in the IPS deployment process might not be making it work correctly until you manually open and close it.
s
Simon Graham
02/14/2025, 2:38 PMThere is some logging that can help diagnose this in the failing case -- make sure you have target logging enabled at Info level, restart the VM and show it reverts to server side caching and then collect a problem report form the PVS server -- that should contain logs that will help tell us why it falls back to server side.
j
Jeff Riechers
02/14/2025, 2:47 PMYup, gathered all that and sent it off to support. Still haven't heard anything back. I am tempted to pull the registries from the 2 instances and doing a diff between them to see if there is something in there that is being set when opened and closed to fix things.
s
Simon Graham
02/14/2025, 2:47 PMOK thanks -- I will check on our end...
👍 1
Simon Graham
02/14/2025, 4:38 PMFYI, the logs show that the PVS code fails to open the partition on the cache disk with a path-not-found error, not sure why at this point.
About the only thing I can think of right now is the "SAN Policy" setting -- this cache disk will look like a new disk to Windows and the default setting for this policy on server class OSen is to block mounting new disks. You could compare the settings on the two disks (run
diskpartsan Copy code
[10:33:47] C:\sandbox\p\m\pvs> diskpart
Microsoft DiskPart version 10.0.17763.1911
Copyright (C) Microsoft Corporation.
On computer: RA-S19-CVAD022
DISKPART> san
SAN Policy : Online All
DISKPART>j
Jeff Riechers
02/14/2025, 4:42 PMThe odd thing is if I create a machines from the PVS console, works fine. Create it with Studio console it fails. But then opening and the closing the image it works fine. Digging through the registry the opened and closed image has all the Azure hardware descriptions in it. Not sure why that works for PVS derived machines, and not for Web studio derived machines.
s
Simon Graham
02/14/2025, 4:57 PMWell, PVS creates and manages the cache disk a little differently from studio/mcs. Definitely worth checking the san policy setting in the image - that might not be it of course, but it's the only idea I have right now. If it isn't that we'll need to escalate this to engineering.
j
Jeff Riechers
02/14/2025, 6:19 PMSo I checked the PVS image that is working. The Console built PVS that isn't working. And the console version that is working.
Jeff Riechers
02/14/2025, 6:20 PMAll of them show Offline Shared under san diskpart.
s
Simon Graham
02/14/2025, 8:32 PMOK -- so please update your original image to set the policy to onlineall and see if that helps.
If this works, I think it has to do with the different timings and methods for bringing the cache disk into service -- it happens to work with PVS provisioned but actually we have a CTX article indicating that you should make sure the SAN policy is OnlineAll in the original image to ensure it always works.
j
Jeff Riechers
02/14/2025, 10:08 PMok, I will test this out and see what we get. Thanks.
Jeff Riechers
02/19/2025, 4:26 PMSo modifying the SAN policy does allow the machine to work, unfortunately it moves the writecache drive to e: instead of d:. We have a bunch of gpo configuration for persistent logs coded to that d:.
s
Simon Graham
02/21/2025, 1:51 PMSo - the Azure machine size selected has, I imagine, a temp disk which is what gets drive letter D always. If that is not the case (if there is no temp disk in the chosen machine size) then we'd need more investigation... I believe, for example, that when IPS runs to convert the image it runs in an Azure machine size that has a temp disk -- this might be causing Windows to capture information in the registry that results in us assigning E as the next free drive letter for the cache disk at boot time.
The precise handling of the cache disk drive letter at boot time depends on how you have the pagefile settings configured in the image -- if there is no setting or it is explicitely setup to use the boot disk then the PVS drivers will mount the cache disk an assign a drive letter at boot time so that the pagefile can be moved off the boot disk - this is done by searching for the first drive letter that is not known by Windows. On the other hand, if the pagefile is configured to be on a disk other than the boot disk the PVS drivers do nothing at boot time and leave it up to Windows to assign a drive letter (since PVS itself doesn't care what the drive letter is).
j
Jeff Riechers
02/21/2025, 1:53 PMI cleaned up the maintenance image and removed the d drive that was mounted there, and just did another pull in case something with that was causing the issue. I also built a new catalog and will test around with that.
Jeff Riechers
02/21/2025, 1:55 PMDarn, same thing. Gonna mess around with the prov scheme to see what option I have.
s
Simon Graham
02/21/2025, 1:57 PMThere are no options for setting the PVS write cache drive letter in the prov scheme -- anything there is for MCSIO/MCS only.
Simon Graham
02/21/2025, 2:01 PMOne thing you might do... extract the serial console log from a VM that ends up assigning E: as the cache drive letter -- the PVS drivers write a log when they assign the letter -- that would at least tell us which component is doing this.
(NOTE: this relies on EMS being enabled in the VM -- for a VM that comes from on-premise this might or might not be the case -- Azure marketplace images have it enabled but your image is not coming from one of those).
Simon Graham
02/21/2025, 2:02 PMOh and one last thing -- does the Azure size you selected have a temp disk? If that is the case, try using one that does not have a temp disk.
j
Jeff Riechers
02/21/2025, 2:04 PMNope, no temp disk. So it has to be some type of leftover in the image itself. Going to dive into the registry.
Jeff Riechers
02/21/2025, 2:20 PMIt's just so weird. If I boot a machine that was configured from PVS console, drive letter is d:, works fine. If I boot a machine that was configured from web studio with the same image, writecache is e:
s
Simon Graham
02/21/2025, 2:25 PMWell, the serial log from a booted VM might have some hints...
j
Jeff Riechers
02/21/2025, 2:25 PMYup, working on gathering all those. Thanks.
s
Simon Graham
02/21/2025, 2:26 PMThat is very weird though I agree!
j
Jeff Riechers
02/21/2025, 7:09 PMWell. This is interesting. Tried running my own new-provscheme command and assign the Writecachedrive letter, and it seems to ONLY accept letters E-Z. Tried it on both 2402 and 2411 and got the same message. New-ProvScheme : Cannot validate argument on parameter 'WriteBackCacheDriveLetter'. The argument "D" does not match the "[ e-zE-Z]" pattern. Supply an argument that matches "[ e-zE-Z]" and try the command again.
At line:1 char:2031
s
Simon Graham
02/23/2025, 3:33 PMI need to check whether this setting has any effect with PVS streamed VDAs -- the mechanisms/code for doing this are completely different between MCSIO and PVS-WBC.
I think though that D is not allowed because it can never be used for the cache disk -- D is either the identity disk or the temp disk always
Simon Graham
02/23/2025, 3:38 PMBy the way -- without any settings of course the cache disk will always be E when provisioning via studio (sorry, should have pointed this out before) -- when you use that approach, the PVS VDA has three or four disks --
• boot disk (streamed)
• temp disk if machine size has one (will be D)
• identity disk (D or E depending on whether or not a temp disks exists)
• WBC disk (E or F depending as before)
You really WANT the identity disk approach since this enables a lot of features with PVS streamed VDAs that were not previously available (like hybrid AAD join, non-domain join, service continuity usw...)
BUT it means that if you need to know the cache disk drive letter, it is no longer always the same -- you should use the WMI class to determine the drive letter used at run time to be flexible.
j
Jeff Riechers
02/23/2025, 3:41 PMGotcha. Which is fine. We just need to modify our deployment mechanism for these new deployed machine types. Just sucks that we can't use the classic PVS target method to keep things easy. We may end up re-deploying on-premise instances as well to match the azure so that we can have parity long term.
s
Simon Graham
02/23/2025, 3:43 PMAny chance you could change things so you get the actual drive letter at run time? Instead of hard coding it...
Oh and one last thing is that you can use the studio provisioning method for on prem as well in which case the same applies (no temp disk, but identity will be D and WBC E).
I dont know what data you are putting on the cache disk, but if it is small then the identity disk is a better choice. If it is large, you have to worry about it reducing available space for the cache file of course.
j
Jeff Riechers
02/23/2025, 3:44 PMWe do a 100 GB wc drive, and right now just pagefile, eventlogs, and writecache itself.
s
Simon Graham
02/23/2025, 3:45 PMOK - then I agree the WBC disk is the right place. (pagefile is automatically redirected at boot time if necessary btw in case you didn't know)