User in RDS and FSLogix has Delayed Write Failure only on Edge cache

Question

Good morning, all!

We have some users on a customer's RDS server using FSLogix for their profile disks. One of them has started having an error: "{Delayed Write Failed} Windows was unable to save all the data for the file C:\Users\%userguy%\AppData\Local\Microsoft\Edge\User Data\Default\Cache\data_1. The data has been lost." This started yesterday and has continued today. No other data appears to be affected, and no other FSLogix user has had this happen. There's no sign in the FSLogix logs that any problems have happened in the FSLogix stack.

When we can, we're going to ask the user to clear their Edge cache and see if that changes anything. Meanwhile, I'm posting to see if any other FSLogix users have seen this or comparable symptoms, and if you found any solutions.

Thanks to all for looking!

G

Answer 1

Hello @Gregg Hughes

As I understand it, the IE Cache folder should be excluded through redirections.xml.

The redirections.xml file instructs the FSLogix agent to redirect specific folders out of the profile container and into the local C: drive.
Any part of the profile that is excluded is deleted at sign-out.

redirections.xml

This article explains more about "Delayed Write Failed" .

Also is there any possibility that profile disks is overloaded ?

Best Regards
Karlie

----------

If the Answer is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 2

Hello, Karlie!

We've done some digging and updating and we have a little more info. First, I can say that the 50 errors are coming from FSLogix users; other users with local profiles aren't seeing this issue. Also, the dropped data from the delayed write failures are limited to cache and temp files, at least so far. The cache is mostly Edge, but there are a couple of Explorer icon cache and one Acrobat cache.
There are also a couple of general 137 errors. I'm going to try and get the GUID information from the user VHDs we have and see if they correlate to the errors. If so, I'm comfortable with ascribing them to FSLogix as well. I'm hoping to get permission to post the sanitized errors from Event Viewer to help.

Thanks!

Gregg

Answer 3

Good morning, all!

I've been working with Microsoft Support on this issue and I think I may have some clarity. I'm posting for the mind check if I'm on track or not.

The symptom of a NTFS Delayed Write warning referring to a cache or temp file not writing happens intermittently, I think when a user logs in to the RDS server, generates enough data for a cache, then disconnects. After the timeout, Windows signs out the user, and FSLogix cleans up the information and unmounts the user's profile VHDX. I think this is where the Delayed Write failure takes place.

FSLogix default behavior is to leave temp and INet cache on the local machine. If I set the registry to keep cache and temp in the VHDX, that might alleviate the warnings. On the other hand, this would, if it works as I suspect, leave an ever-increasing cache and temp file structure on the VHDX, and it would never get cleaned unless we manually mount the VHDX and delete cache and temp files - arduous and likely unnecessary.

The concern is that other, usable files might be Delayed Write clobbered, and users would actually lose data. Because of the way FSLogix has the registry and logic set for temp and cache files, and that users haven't reported any data missing, leads me to think that FSLogix is designed to be careful of non-cache files, and that there's no worry of missing "real" data. If I could be assured that this is the case, that would go a long way toward widening acceptance of FSLogix as a UPD management solution.,

Is this on track, or am I looking down the wrong path to understand this?

Thanks to all for looking!

Gregg