Why User Profile Disks?
User profile disks is a technology available on Windows Server 2012 and above which can be used to centrally store user and application data on a single virtual disk that is dedicated to one user’s profile. When the user logs on, their profile disk is attached to their session and detached when the user logs out. With this process, there is no copying of files on logon or logoff.
This is highly beneficial on a RDS server environment, where you need to store the user profiles on a separate volume, other than the System drive.
What’s the benefit over Roaming Profiles, Folder Redirection and User Experience – Virtualization?
The key benefit is the ability to store all user profile data in a centralized location, as a virtual hard disk file (.vhdx) which is mounted to a user’s profile location during logon and unmounts itself during logoff. In all the other methods, we are unable to redirect the “AppData\Local” folder, resulting in profile data being stored in two locations. User Profile Disks enable the data to be stored centrally, and is easily manageable and movable without having to worry about permissions due to its transparency to the end user.
Apart from the above, User Profile Disks offer several other benefits over other redirection technologies.
- Configuration and deployment is simpler than roaming profiles or folder redirection.
- User profiles can be maintained even on pooled virtual desktops that get rolled back after logoff.
- Logon and logoff times are reduced.
- Administrators can have granular control of exactly which locations get saved to the virtual hard disk (VHDX).
- User profile disks can be stored on Server Message Block (SMB) shares, cluster shared volumes, SANs, or local storage.
- User profile disks can be configured for a single collection only. A user connecting to two different collections will have two separate profiles.
- User profile disks work perfectly on a single RDS environment where a user will always connect to a single RDS server. However, in a multiple RDS endpoint environment, users should be advised to always log off at the end of their RDS session. This is required because the Virtual Disk is unmounted only during logoff, and if the user disconnects from one RDS endpoint and logs in to a different endpoint, the profile disk will not be mounted to the new connection, as it’s already mounted to the previous. This will result in the user experiencing a temporary profile on the second connection, if it’s connected to a different RDS endpoint.
- Operating System – Windows Server 2012 or above
- A RDS collection
- A file share per RDS collection
Configuration on an existing RDS Collection
- Create a folder on the drive you plan to store all the user profiles. It is recommended to use a separate drive to store all the user profiles.
After the folder is created, open the Properties of the folder, browse to Sharing tab and click on Advanced Sharing.
Tick the Share this folder selection and type in a Share name. (It is recommended to hide the share using “$” sign at the end of the share name.
After that, click on Permissions and give Read permissions to Everyone for the moment.
- Open Server Manager and select Remote Desktop Services on the left pane.
- Select the desired RDS Collection (Full Desktop in this instance), and click on the dropdown TASKS and select Edit Properties.
- Inside the Collection Properties, select the User Profile Disks from the left pane. Tick the Enable use profile disks selection, and provide the shared folder location created earlier. We can also specify the Maximum Size the disk can grow if needed.
- Since we need to also include the “AppData\Local” folder inside the User Profile Disk, scroll down and select Store only the following folders on the user profile disk radio button. Select all the check boxes in front of the folders.
Afterwards, on the Include the following folders: menu, click on Add… and enter \AppData\Local folder path and click OK. Save the settings by clicking on OK again on the Collection Properties menu.
Note: You can also include any other custom paths, provided that they are stored inside the User Profile folder. (default location: C:\Users)
- We are all set and done. If you go back to the permissions menu of the shared folder, you may notice that the permission inheritance is removed and the system has assigned several new permissions to the shared folder automatically.
Testing the Deployment
You may notice that the above configuration hasn’t done any significant changes to the current system. That is actually true. To test it, let’s create a new user called “rdstest” who will have access to the RDS Collection. (No step-by-step instructions here, bro! 😉 If you don’t know how to create a new user and assign them into a security group, you shouldn’t be reading this. Lolz).
If you look closely, I’ve created a security group called RDS Users and allowed only the members of that security group to access my RDS collection for additional security. I’ve added the user “rdstest” to the security group.
Now, I’m going to log into my RDS collection using the created user. But first, let me show you the C:\Users folder of my RDS server.
As you can see, there is no user account called “rdstest” inside the folder. I’m including the timestamps in the screenshots, so you can see the magic clearly. 😉
Now I’m logging into my RDS Collection using “rdstest” account.
I’m inside. You can see my RDS Collection “Full Desktop”. Let’s log in to it.
And… we are in! (Sorry about the screenshot time lapse between logging in and the RDS desktop. My RDS was in UTC time while the desktop was in GMT + 5.30. Had to change the RDS to the latter time zone). I’m also going to keep a text document I’ve created earlier in the desktop of the user “rdstest” to show something to you later.
Now let’s check the “C:\Users” folder of the RDS Server. We see that a profile has been created under the name “rdstest”. So, you may ask me, “What’s the big deal? That’s normal!”
and I use Barney Stinson’s favorite catchphrase: “Wait for ittttt……”.
Now, let’s sign out (or log off for the “pre Server 2012” techies out their…) from the RDS session.
Let’s check the “C:\Users” folder of the RDS server again. Voila! User profile “rdstest” is gone… Check the timestamps if you don’t believe me! Gone! Poof!
Now, to show you something interesting, let’s go to the shared folder we created to store the user profiles. You see there are several VHD files created for each user who logs into the RDS server, to store their User profiles. (The name, however is created using the SID of the user account.)
Now let’s find the SID for the username “rdtest”. There are several ways to do it. I find retrieving it using PowerShell module for Active Directory easier. (cmdlet is Get-ADUser “Username” | FormatList)
Okay, so the SID for user “rdstest” is S-1-5-21-2668890707-303316048-3023405480-2605. Let’s check the corresponding VHD file on the shared folder now, shall we?
I’m going to mount it to Windows Explorer and show you something.
Check it out! The document I’ve created earlier on the user’s desktop can be seen when we mount the VHD file.
Note: Always remember to unmount the VHD if you mount it on to Windows Explorer, or else the user will be created a temporary profile next time they log in. (Basics, right? A VHD file cannot be accessed simultaneously. Remember Hyper-V 101?)
Just go and right click on the mounted Volume on This PC (Again, My Computer for our elderly readers), and click on Eject and you’re good to go!
How User Profile Disks work…
During first logon, a virtual disk (VHDX) is created from a template disk. This VHDX is attached to the virtual machine or RD Session Host server that the user is logging on to. The profile service is then notified to use this VHDX as the location for the user’s profile. When the user logs off, the VHDX is then detached from the virtual machine.
On subsequent logons to the collection, the VHDX is remounted to the RD Session Host server the user is logging on to.
Also, it’s worth noting that User Profile Disks won’t be created for the existing user profiles on an RDS server. If you have existing users, you will have to back up their existing user profile data, delete the user profile from the “C:\Users” folder, remove the registry key for the profile from the registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\<profileSID>).
Afterwards, restart the server and then let the user log in. This will create the User Profile Disk on the Shared Location. You can then ask the user to sign out, copy the backed up user data to replace the files inside the VHD file and unmount it.
Here’s the PowerShell Cmdlet to enable User Profile Disks:
Set-RDSessionCollectionConfiguration -CollectionName “Your Collection Name” -EnableUserProfileDisk -MaxUserProfileDiskSizeGB “Maximum VHD disk size in GB” -DiskPath \\shared folder location
Written by: Janaka Dissanayake