The most common AVD setup is a pooled configuration with FSLogix. This means that you have two or more session hosts and a group of many users who connect to those hosts. FSLogix handles the user profiles, so it doesn’t matter which session host the user connects to. Their profile is mounted to whichever host received their connection, and their experience is the same regardless of the host.
This all works pretty seamlessly once it’s set up. As long the session hosts and authenticating users have access to the location where the FSLogix profiles are stored, there are rarely any issues to deal with. However, if access to the storage account is unavailable, users can end up with a local or temp profile. There are a couple of configuration options in FSLogix that can help deal with local profiles. One is to delete the local profile when FSLogix should apply. If this is enabled, then a user signs into an AVD host, if they have a local profile on that host, it will be deleted and the user’s FSLogix profile will be used. This is usually a good practice, but be careful implementing this if for some reason users have already been using AVD without FSLogix for a period of time.
Another option is to prevent logins if FSLogix fails to mount their profile or if the user receives a temporary profile. The downside to using these policies is if there is a storage account or networking issue where your hosts lose access to the FSLogix location, then no users can sign into AVD.
The DeleteLocalProfileWhenVHDShouldApply policy is used in all my new AVD environments. However, I had an issue recently where a large client’s storage account hit capacity. This caused hundreds of users to receive local profiles since their profiles couldn’t be mounted. If you’re using Teams, Ring Central, Chrome, Edge, or other programs that cache a few GBs of data in the user profile, this can cause your host system disks to grow substantially from the local profiles. For example, if you have 128 GB host disks with around 60 GB free, and 12 users receive local user profiles that grow to 3-4 GB after all the app data is cached, those host system disks are going to hit or be very close to hitting capacity.
Warning: make sure you read this before the next section. The OS can’t tell if a profile is an FSLogix profile or a local profile when a user is signed in. So, do not run this script while users are signed into the AVD hosts. It should be ran during a maintenance window while no users are signed into AVD, and all hosts are in drain mode. This ensures that only the orphaned local profiles are targeted. If you have an RMM or your session hosts are in Intune, you can push the script out using one of those methods. The script should be ran as admin or system.
Normally, the policy to delete the local profile when VHD should apply will take care of this over time, but when your host pool is 40+ session hosts, the odds of the user reconnecting to the host where their local profile was generated is very low. So, we need to take some manual action to free up disk space on our session hosts. In this case, we wanted a clean slate. This script is what I came up with. This will remove any local user profile not specified in the $keep variable. In addition, it will also remove any “local_” folders generated from FSLogix from the c:\users directory. The output is logged to c:\temp. Depending on how many profiles need to be cleaned up, this can take a little time. Some of my hosts took 20 minutes to finish running the script. When its finished, you should have much more disk space and no more orphaned local profiles.