If your user layer is out of space and you need to figure out where the space is going (as opposed to simply expanding the User Layer disks with https://support.citrix.com/article/CTX222095, or https://support.citrix.com/article/CTX226688 for Unidesk version 2), you will need to examine the User Layer disk directly.

---

Instructions

First, to get access to the User Layer disks, you need to find the VHD on your File Share.  Have the user logout so their User Layer VHD is no longer locked, and then you can use Disk Management, "Attach VHD", from virtually any Windows system to get access to their VHD.  You will need to access it from a machine and user account that has permissions to read and write files on that specific folder of your file share.  Obviously you would not want to leave your User Layer folders open to access by any user.

(If you are using Unidesk version 2, follow this article: https://support.citrix.com/article/CTX227122.)

That will allow you to directly inspect the data on the User Layer disk(s). User Layer disks are simply normal NTFS filesystems, and they contain only the files actually created, modified or deleted in the desktop.

A deleted file appears as a normal, zero-byte file with the same name, in the same location, with the Last Access Time set to 6/28/1601 at 12:41AM. "Last Access Time" is not displayed by default in Explorer to "DIR" from a CMD prompt. Probably the easiest way to see this is to run CMD, and use "dir /ta" to run "dir" while displaying the last access time. Look for your file with a last access time that is in 1601.

However, since the full Windows permissions still apply to the User Layer disks, you may find that Windows is lying to you about space. If you look at the disk properties and see all 8GB in use, but when you right-click and get Properties on all the directories in the root, you only see 1.5GB in use, then Windows is hiding things from you because you don't have rights to view the directories. To get around this, you need to run your analysis as the Local System account.

Download these two tools - WinDirStat and PsExec:

http://windirstat.info which will redirect you to https://www.fosshub.com/WinDirStat.html

https://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

WinDirStat is a pretty easy to use tool that will give you a report of the usage of your filesystem for every folder it can reach. Which, by default, is not all of them. To get WinDirStat to see everything, you need to use PsExec from the Microsoft SysInternals suite. After you have downloaded, unblocked and unpacked both of those packages, run this:

psexec -i -s -d windirstat.exe

That will execute WinDirStat using the Local System Account, and you will finally get a full view of your filesystem. We have previously seen Windows hide large amounts of data in \Windows\CSC (where Roaming Profiles and Offline Files store cached files) and \Windows\Temp.

Once you know what files you care about, it's also possible to get an idea of when they were copied to the User Layer.  You can't rely on the timestamp of the file in the User Layer, because when we initially copy the file over at the moment it's opened as read/write, the file hasn't been modified yet and the timestamp has not been updated.

In the user desktop, look through C:\Program Files\Unidesk\Uniservice\Log\LOG0.txt.  This file records a number of fliter-driver transactions, including when a file is first copied from a read-only layer to the writable disks.  Look for "Move" events like this:

[03/22/2018][18:27:41:935] Move Detail Data Length 0 Path \Device\HarddiskVolume13\Windows\assembly\NativeImages_v4.0.30319_64\System.Transactions\922f3f17f5112441e77f9d3d56d5b753 TargetVolume 1101376597148984131:0:1:0 SourceVolume 1101376597065203742:0:3:0

The TargetVolume is always your User Layer, and you can usually infer the SourceVolume based on what file is being copied.  You usually never need to actually identify the disk by that long integer ID number.  Mostly what you care about here is when it happened.  If you find that all of Office has been copied to your User Layer, you can use LOG0.txt to identify when.  If it happened at 1PM, then it was probably a user action.  If it happened at 3AM, it might be an automatic update.  Either waym you can take this timestamp and check the Windows logs for corroborating information.

We have no idea what process caused the file to move, or why, but you can at least tell when.