This message was deleted.
# microsoft-fslogix
s
This message was deleted.
d
Yes. In our case (yours may be different) we had XA sessions in disconnected state with Outlook open at the time the nightly VDA reboots happened. ‘Gracefully’ logging off those sessions giving Outlook a chance to close properly before the reboots stopped almost all our OST ‘corruption’. We schedule a PS script on a controller which does it all 30m before reboot schedules start.
c
Hmm we have win10.
m
I have a customer with View VDI Win10 single user VMs and CloudCache enabled on their Profile Containers and they're experiencing corruption with the OST and other data in the profile such as files on the desktop or IE Favorites. 1909 HF_01 didn't fix the issue. Outlook error is "Outlook is using an old copy of your Outlook data file (.ost). Exit Outlook, delete the file, and restart Outlook. A new file will be automatically created the next time you initiate a send/receive."
c
@Mike Driest I have the same issue.
Anyone know what retries he’s talking about?
m
I saw that thread yesterday. Registry only lets you configure ReAttachRetryCount/Re-AttachIntervalSeconds and LockedRetryCount/LockedRetryInterval - I'm assuming it would be ReAttach that would be most helpful for CloudCache but I could be incorrect. I am curious what settings they configured. I have a case open with Microsoft Support as well, waiting on a reply. https://docs.microsoft.com/en-us/fslogix/profile-container-configuration-reference#lockedretrycount
The customer that I am working with has the following configured via GPO (we have not changed these values yet): Locked VHD retry count: 3 Locked VHD retry interval: 30 Volume re-attach retry count: 3 Volume re-attach retry interval: 20
c
I will copy those settings, so far so good.
m
The settings I mentioned - that customer has profile container / outlook OST corruption issues w/CloudCache enabled and those are the retry settings they have - so we don't a resolution yet. To David's point about idle sessions overnight, our customer said they do allow the non-persistent VDI sessions to persist throughout the work week if the user's don't log out and then reboots occur weekly on the weekend. Now I'm wondering if there's an overnight network/file server/backups blip that could be causing this.
c
Yep sale issue, did you ever get an answer from MS?
m
No not yet
What storage locations do you have configured in CloudCache? Our customer had two SMB locations and for troubleshooting we have it down to one SMB location.
c
Not using cloud cache
m
@Cory Zaner ahh ok. are you using ReFS on your file server? our customer with the corruption problem is.
c
Hmm not sure unless it’s on by default. Building new 2019 with iscsi storage going to nutanix