Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
This document describes how to configure FSLogix Profile Containers and Office Containers using Parallels® RAS.
FSLogix Profile Container is a remote profile solution for non-persistent environments. It is supported in Parallels RAS starting from version 18. FSLogix Profile Container redirects the entire user profile to a remote location and maintains user context in non-persistent environments, minimizing sign-in times, providing native profile experience, and eliminating compatibility issues. Being the successor of Roaming Profiles and User Profile Disks, FSLogix Profile Container is the preferred profile management solution in Parallels RAS.
FSLogix Office Container is focused on storing only the profile content unique to Microsoft 365 (Office) applications. Previously, it was possible to use FSLogix Office Container with Parallels RAS, but it required management outside of Parallels RAS. Starting from version 19.3, management and configuration can be performed from within Parallels RAS Console and Management Portal. Office Container is used when it is necessary to separate Office data and other profile data. It provides protection from data loss or corruption in one of the containers and allows organizations to have different container sizes to accommodate specific workloads or data synchronized from, for example, Microsoft OneDrive.
Native FSLogix Profile Container and Office Container require manual configuration via the registry or group policy. Parallels RAS makes this process more efficient for administrators by allowing them to manage all Profile Container-related settings via Parallels RAS Console or Parallels RAS Management Portal.
In addition to tools for configuration and management of FSLogix Profile Containers, Parallels RAS supports configuration and management of FSLogix Office Containers. Below you will find the benefits of this solution used alone and together with Profile Containers.
As stated above, Profile Container is used to redirect the full user profile, while Office Container redirects only the local user files for Microsoft Office (for example .OST files for Microsoft Outlook and the Microsoft OneDrive cache). Office Container is especially useful for customers who are satisfied with their existing profile management solution and only want to enhance user experience with Microsoft 365 applications or use Profile Container and Office Container together.
The most important benefits of using both solutions are:
Office data is separated from other profile data.
If Office Container or Profile Container is damaged, the remaining data is kept intact. This can be useful when a problem occurs with Office Data which can be recovered from the server because the Office Container can be deleted without impacting the rest of the user configuration.
Office Container may be used with Profile Container as a mechanism to specify which Office components will have their data included in the container.
When using both Office Container and Profile Container, you have more granular control over the amount of data a user is allowed to store for each of the types of data.
For more information, see https://docs.microsoft.com/en-us/fslogix/profile-container-office-container-cncpt.
This technology was introduced by Microsoft more than 20 years ago. With Roaming User Profiles, the local profile is transferred to a network location so that a user can access it on multiple machines. The disadvantages of this approach are:
Slow login. Large roaming profiles take a long time to download, and sometimes users may need to wait more than a minute, depending on the profile size.
Slow logoff. A roaming profile needs to be uploaded back at logoff, and if this process is interrupted (for example, due to a network failure or power outage) the profile can be corrupted. This results in the creation of a temporary profile and the help of an IT specialist may be required to address the issue for the affected user.
Folder redirection creates a large amount of SMB traffic between the desktop and the file server. Each request to a file is treated as a new connection.
Every issue described above will also result in increased consumption of network resources.
As the successor of Roaming User Profiles, UPD stores user profiles in a VHD/VHDX container. This container mounts on a machine upon the user logging in. Microsoft is no longer actively developing UPD and as a result it is considered a legacy technology. Management of UPD in Parallels RAS is only available when upgrading from previous versions of Parallels RAS and is no longer available in new deployments of Parallels RAS.
The limitations of this technology are:
UDP cannot be used on multiple devices concurrently. Once VHD(X) is mounted for the user, it cannot be mounted on a different device if the user still has an active session on the given session host. If a user connects to another session host while the UPD is already in use, a temporary profile is created.
UPD requires a configuration at the level of RDS collections. Should there be a user with the ability to log on to several collections, a separate profile will be used for each collection. In Parallels RAS this applies to RDSH host pool. Whenever a user connects to two servers that belong to different RDSH host pool, the second RDP session uses a temporary profile.
Windows deletes the search index for a user profile when the UPD disconnects at logoff. The search index is recreated upon every login. This means that Windows search is not usable in non-persistent VDI environments. This issue also extends to Outlook search capabilities on RD Session Hosts.
UPD is supported on RD Session Hosts and Windows client systems in VDI. Physical Windows client machines are not supported.
As the successor of Roaming User Profiles and UPDs, FSLogix Profile Container has many advantages, such as:
Can be mounted to any computer (including physical Windows client systems).
The folder where the VHD is mounted is masked, therefore tricking the OS into believing that the profile is mounted locally and thus avoiding problems with file access by using junction points.
FSLogix allows simultaneous read access to the profile when the user is connected to more than one session at a time.
FSLogix works with Office 365, for example, it can keep Outlooks OST files and OneDrive, though OneDrive sync app does not support running multiple instances of the same container simultaneously (https://docs.microsoft.com/en-us/onedrive/sync-vdi-support).
Ability to keep certain directories local. By default, the profile container consists of the entire Windows profile except for the Temp and Internet Explorer cache folders. If needed, an administrator can specify what parts of the user profile must be persistent in the profile container. Any part of the profile that is excluded will be deleted at logoff.
Users connect to their non-persistent working environments in different ways, depending on how desktops and applications are delivered. When using virtual desktops and remote applications, users may:
Have one connection to a single instance of Windows at a time
Have multiple concurrent connections to a single instance of Windows
Have multiple concurrent connections to multiple instances of Windows at the same time
It is important to configure Profile Container correctly for use with concurrent connections and multiple connections.
With Profile Container, multiple connections are supported by using VHD(X) difference disks. Profile Container is configured for multiple connections using ProfileType. When configuring Profile Container, ProfileType can be set to one of four modes. Parallels RAS allows you to configure these profile types from within Parallels RAS Console.
To select a profile type:
In the Profile Settings dialog, select the Advanced tab.
Select the Profile type option.
Select one of the four modes that are available. Multiple connections are not supported for Office Container.
The profile types are explained in the section below.
Sign on:
Client tries to attach the VHD(X) file directly. No difference disks are used. If concurrent access is attempted, it will fail with a sharing violation (error 20).
Sign out:
Client detaches the VHD(X) file.
Sign on:
Client attempts to open the RW.VHD(X) difference disk with Read/Write access. If it is successful, it merges the difference disk to the parent. If it completes the merge, the RW.VHD(X) file is deleted.
Client creates a new RW.VHD(X) difference disk.
Client attaches the RW.VHD(X) as the Profile VHD.
Sign out:
Client detaches the RW.VHD(X) difference disk (the user's Profile VHD/X).
Client attempts to open the RW.VHD(X) difference disk with Read/Write access. If it is successful, it merges the difference disk to the parent. If it completes the merge, the RW.VHD(X) file is deleted.
Sign on:
Client attempts to open the RW.VHD(X) difference disk with Read/Write access. If it is successful, it merges the difference disk to the parent. If it completes the merge, the RW.VHD(X) file is deleted.
Client attempts to delete the previous RO difference disk (if it exists).
Client creates the new RO difference disk.
Client attached the RO difference disk as the user's Profile VHD.
Sign out:
Client detaches the RO difference disk.
Client deletes the RO difference disk.
Client attempts to open the RW.VHD(X) difference disk with Read/Write access. If it is successful, it merges the difference disk to the parent. If it completes the merge, the RW.VHD(X) file is deleted.
Sign on:
Client checks to see if a RW.VHD(X) file exists. If it doesn't, the client takes the RW role and performs the same steps as ProfileType = 1. If the RW.VHD(X) file does exist, the client takes the RO role and does the same steps as ProfileType = 2.
RO difference disks are stored in the local temp directory and are named %usersid%_RO.VHD(X).
The RW difference disk is stored on the network next to the parent VHD(X) file and is named RW.VHD(X).
The merge operation can be safely interrupted and continued. If one client begins the merge operation and the operation is interrupted (e.g. the client is powered off), another client can safely continue and complete the merge. For this reason, both the RW and RO clients begin by attempting a merge of the RW.VHD(X).
Merge operations on ReFS file system, where the difference disk and the parent reside on the same ReFS volume, are nearly instantaneous no matter how large the difference disk is.
Merge operations can only be done if there are no open handles to either the difference disk or the parent VHD(X). For this reason, the RO client also attempts to merge the RW VHD(X) as it may be the last session to disconnect.
For more information, see https://docs.microsoft.com/en-us/fslogix/configure-concurrent-multiple-connections-ht.