- Recommended security settings and new group policies for Microsoft Edge (from 107 on) - Fri, Jan 27 2023
- Save and access the BitLocker recovery key in the Microsoft account - Tue, Jan 24 2023
- Reopen apps after Windows startup - Thu, Jan 19 2023
The concept of the FSLogix Profile Container is to offload user profiles to a VHD(X) file. The software then redirects the user to the data and settings in the external container. This virtual drive is mounted when the user logs on and integrates transparently into the file system from an application's perspective.
Installing the agent
An agent handles the VHD(X) operations; it is available in a 32- and a 64-bit version. The agent can be installed either interactively or unattended, for example, via SCCM. The target systems can be RD session hosts, or virtual or physical desktops. Setup and configuration are largely the same for all systems.
After the FSLogix software is installed, it remains idle unless you activate it via a group policy. But before you do that, you need to provision the storage for the user profiles. The storage is typically a share on a Windows Server or NAS device.
It is important to assign permissions such that each user only has access to his own profile. You can do this in the same way as when setting up shares for roaming profiles or a folder redirection.
In the documentation, Microsoft proposes a simple variant, where the users only receive Modify permissions.
When providing the storage, you should ensure it is highly available, if possible. If it fails, the affected users will lose data or will have to stop working. One option to achieve high availability is the FSLogix Cloud Cache feature, which synchronizes profiles with multiple providers.
You should also define the user groups whose profiles will be virtualized by FSLogix or excluded from it. During the installation, the agent creates four local groups on the computer, two each for Profile Container and Office 365 Container.
In the Include List, which already contains Everyone by default, you include those Active Directory groups whose profiles FSLogix should manage. The Exclude List should include those that should be left alone. The Exclude List could, for example, include the administrators.
Activating Profile Containers via GPO
Now you can proceed to configure the Profile Container via a group policy. To do this, you first must copy the supplied fslogix.admx template and the corresponding language file to the PolicyDefinitions folder and to its en-us subdirectory respectively, either locally under %systemroot% or in the Central Store on a DC.
Configure the mandatory settings Enabled to start the tool and VHD(X) Location to define the storage path.
In addition, it is recommended to consider the remaining options, as they do unlock some useful functions.
On session hosts in particular, you should save the Windows search index in the VHD(X) so that it does not have to be recreated after each logon.
FSLogix also allows you to set size restrictions or enable simultaneous access to the profile from multiple sessions. Another option allows you to change the naming scheme for the directories and VHDs if the default is not suitable.
Deleting or migrating existing profiles
As soon as the GPO is applied to the assigned computers and the first user logs in, FSLogix automatically creates a directory containing the VHD(X) for that user's profile. However, if the user has logged on to this computer in the past, so that a profile already exists, FSLogix terminates this operation.
As a result, the event log will show an entry with an error code of "0," but a reason code of "3." The same information and further details about a session can also be found in the registry, which can be extracted with PowerShell as follows:
As you can see on this page with the status codes, reason code "3" stands for REASON_LOCAL_PROFILE_EXISTS. For this scenario, you could activate the GPO setting Delete local profile when FSLogix Profile should apply. This setting should be used with caution.
In most cases, however, you will not want to delete existing profiles; instead, you'll want to migrate them to the Profile Container. For this task, the command line tool frx.exe supports the copy-profile switch. The tool is located in the program directory of FSLogix. You pass it the name of the user and the VHD(X) file. Be sure to adhere to the scheme you defined in the group policy. By default, this is "Profile_<username>.vhdx."
In addition, it is a good idea to configure the virtual drive as dynamic, so that it can grow with the increasing amount of data:
. "C:\Program Files\FSLogix\Apps\frx.exe" copy-profile -filename Profile_User.vhdx -username contoso\user -dynamic 1 -verbose
If you try to create the VHD(X) directly on the network drive, you may end up with an opaque error message. If you generate it locally, then you copy it to the FSLogix storage, to a directory that also complies with the naming convention. By default, this is "SID_<username>".
If you have a large number of user profiles, you can automate this process by using PowerShell to retrieve the SID with Get-ADUser.
If the permissions are set correctly, the Profile Container should be mounted the next time the user logs in and should contain all migrated data.
Keep selected directories in the local profile
By default, FSLogix redirects all directories except temp and the IE cache to the Profile Container. If you want to exclude certain folders, for example because you prefer to store their contents on a file server using folder redirection, then you define them in an XML file. Its structure is relatively simple and is described here.
To assign such a redirection.xml to the respective profiles, there is a separate setting in the group policies, called Provide RedirXML file to customize redirection. Specify the path to the configuration file, which is usually stored on a network share.
FSLogix Profile Containers are a much better solution for many environments than roaming profiles or user profile disks. This is especially true for RD Session Hosts, where the use of FSLogix is already covered by the Client Access Licenses.
Subscribe to 4sysops newsletter!
The installation and configuration of the tool is quite simple because it uses only common Windows techniques such as user groups, GPOs, or file shares in addition to its own agent.