When a user who has Elastic Assignments logs in, our Layering Service (ULayer.exe) creates a conenction to the designated file share, using the user’s credentials. We identify the layer VHD files that are required, and call Disk Management to attach those disks. When the volume identifiers become available, we inform our filter drivers to begin using the new disks.
From then on, Windows is responsible for persisting the connection to the VHD and/or the file share itself. Unfortunately, Windows does not log file share connection events or attached VHD events, so the only indication you may have is from UlayerSvc.log.
Following the example, eventually Windows loses the share, or maybe Windows just loses the VHD. Windows might or might not retry or have some timeouts before it gives up. All of this is completely determined by Microsoft, we do not (and cannot) set any parameters to affect this behavior.
When Windows finally decides the VHD is no longer attached, the volume identifier disappears from Windows’ list of volumes. That is the first that our software is aware of anything at all. We check every 60 seconds, so the disconnect could have happened some time ago. We log that the volume is no longer visible, we tell the filter driver to stop using it, and we note in the log that the next time someone logs in who has this layer assigned, we will attempt to reattach it and reuse it.
That whole process has nothing to do with whether the attached VHD is an app layer or a VHD or something completely different. It’s all up to Windows’ native fault tolerance in this situation. We have no idea that there’s even a problem until the volume disappears.
However, this just means that the contents of that layer will be unavailable until the next login. The machine will continue operation, any other layers will continue functioning, and when a user (even the same user) that has that particular layer assigned logs in again, we will attach the missing layers. This process, other than temporarily losing access to the contents of the Elastic Layer, should be completely nondisruptive.
Note that if the volume that disappears is the User Layer, then you will not see this log entry, and Windows itself will become substantially unresponsive, being unable to find anything, including things on the boot disk which is still attached.
So what can you do about it? Unfortunately, since Windows does not generally log VHD or file server failure events, it can be very difficult to figure out why the disk is disappearing. App Layering and ULayer don’t know anything about the cause, we just know about when it happened. Start recording the times when it happens, in case there is some external event that you can correlate to the lost volumes. See if there are any other events in the Windows System and Application event logs approximately when ulayersvc.log reports the volume disappearing.
There is some suggestion that the disconnects can be the result of an overeager antivirus, but we do not have any information about why or how to stop it. If the problem goes away completely if you stop including your AV layer in the published image, it might be worth a conversation with your AV vendor about the circumstances where they might disconnect a VHD from a machine they’re protecting.
In some circumstances (and this might be why you looked for this page in the first place), we have seen layers disconnected in the logs, but when the user (or any user) attempts to login again, at the point where we should be reattaching the VHD, the entire machine hangs. Something is blocking our ability to reattach the VHD. So far, all we know is that this too appears to be correlated to antiviruses. If we ever figure out why, and how to stop them, we’ll certainlty record it here.