- FSLogix VHDX compaction: Resize virtual disks - Thu, Dec 1 2022
- Sysinternals Process Monitor: Real-time file system, registry, and process monitoring - Fri, Oct 28 2022
- Custom error message for access denied - Tue, Sep 27 2022
The profile management feature works by mounting either the user's entire profile or specific parts of the profile (such as cache files) into a VHDX that allows for smooth roaming and fast mounting. When the user opens a new session on a new device, their profile is mounted from the previous session, and all their customizations are instantly applied.
FSLogix works with a simple, straightforward architecture that uses an agent on the endpoint, Group Policy Objects to drive the configuration, and SMB shares that hold the VHDX files that are mounted across or into the user profile.
Since the Microsoft acquisition, there has been a notable lack of new features and improvements within the FSLogix stack. Development focus appears to be solely on bug fixes rather than growth within the product. However, the latest preview version, released in October 2022, has finally brought a much-requested new feature.
One of the drawbacks of using a VHDX-based model for mounting a profile, or folders within a user profile, is the requirement for compaction maintenance. Enterprises normally always use the dynamic expansion option in FSLogix because it is pointless to commit all your available storage at first logon.
However, when a VHDX file is expanded, it cannot afterwards be dynamically compacted. So, if a user downloads a huge set of files into their profile, the VHDX will expand to accommodate them, but if the user then removes said files, the VHDX will remain at the expanded size, potentially eating up storage that is now effectively white space.
FSLogix is clever enough to use the "white space" first when available, so storage will not be wantonly wasted—but for enterprises with large storage footprints that pay for it by consumption, having potentially huge amounts of white space located within your user profiles is not an efficient mode of operation.
Previously, enterprises relied on running PowerShell maintenance scripts to compact the white space within their FSLogix deployments. The best-known was Invoke-FSLShrinkDisk. However, setting these up could add unwanted overhead of management and complexity to the FSLogix implementation.
With the 2210 preview release from FSLogix, there is now a built-in capability to compact the user's VHDX files, if required, at logoff from their session.
Download the new FSLogix preview version and install it on your target endpoints by using software deployment, manual installs, or updating your golden images. A reboot may be required after installation.
Copy the ADMX and ADML files from the installation source directory into your Group Policy store (copy the ADMX file to the main store and the ADML file to the en-us subfolder of the main store).
Ensure that you are not disabling the Optimize Drives service (defragsvc) in the golden image or on your target endpoints. Some optimization software (such as the Citrix Optimizer) will disable this service. The service is required for the FSLogix compaction to function as it queries the MSFT_Partition API using the SizeMin parameter from the GetSupportedSize method. The service can be set to Manual as below—just make sure it is not disabled.
In your GPO that controls FSLogix, add the following additional setting to your configuration: Computer Configuration > Admin Templates > FSLogix > Disk Compaction. Setting this to Enabled, as shown below, will turn on the feature.
The Registry entry that this controls is noted in the GPO description. Note that as this is not in a Policies key, setting this configuration item will effectively "tattoo" it into the Registry, and it must be specifically removed or set to 0 to disable it. Merely switching to Not Configured will not work.
Refresh the policy on your endpoints to take effect. Once this is in place, any FSLogix-capable users will now compact their profiles at logoff if certain conditions are met.
FSLogix will determine whether to run compaction at every logoff once the above policy is set. It does so as follows:
- The size of the user's container must be over 1 GB (of committed space, so including any white space).
- The difference between the committed size (the current size of the container, including white space) and the minimum size (the actual size of the total of files in the container, not including white space) must be greater than or equal to 20% of the committed size.
So, if I have a 6 GB committed size with only 1 GB of files, the difference of 5 GB is more than 20% of 6 GB, so compaction will run.
However, if I have a 6 GB committed size with a total of 5 GB of files, the difference of 1 GB is less than 20% of 6 GB, so compaction will not run.
Bear in mind that depending on the maximum size of your container (which is set in the GPO that configures FSLogix), the minimum size of your container may differ slightly from the actual size of the files within it. This is because of an NTFS concept called immutable files, which exist in a specific place within the VHDX container. The larger the maximum container size, the further into the profile these immutable files will sit, potentially affecting the minimum possible compaction size. Usually, 10% is a good indicator. If you had a maximum profile size of 100 GB, and only 2 GB of files within the container, you would find you may only have a minimum size of around 10 GB, rather than the 2 GB you would expect. To this end, it is probably wise to be prudent when setting the maximum container size in your GPO.
Compaction in action
I've logged on to a Windows 10 virtual desktop for the first time here, and you can see that the container size for my profile after the first logon is not particularly large at all.
Now, I am going to copy a number of large files into my profile.
And you can see that the profile has expanded, as expected.
I then permanently delete all the large items from my profile.
As expected, the committed size of the container on disk does not change, even though the files occupying that space were removed.
However, because the difference between the committed size (5.6 GB) and the actual consumed size (0.2 GB) is way above 20% of the committed size (5.4 GB is the difference and 1.12 GB is 20% of the committed size), then compaction will be triggered at logoff.
As you can see, the compaction has reduced the total size of the container to less than it was after the first logon, indicating that, in addition to the files we deleted, other extraneous files have been removed from the profile as well at some point, saving even more space.
Especially when first introduced, the compaction process may introduce a delay while the user logs off, depending on the size of the container and the amount of white space. This will improve when run regularly. If sizable amounts of white space are anticipated, it may make sense to compact them manually using Invoke-FslShrinkDisk prior to introducing the logoff compaction feature.
Compaction will run for no longer than five minutes. If this is exceeded, it will stop and then continue again at the next user logoff.
Events related to the compaction feature will be written to the FSLogix/Operational area of the event logs.
Subscribe to 4sysops newsletter!
In addition to the compaction feature, the 2210 version of FSLogix also introduces the capability to persist the users' Recycle Bins, allowing users to retrieve deleted files even when roaming from session to session. This is configured in the same GPO area.