Working with User Profile Disks on Session-Based Desktop Deployments


Introduction


By now you have probably heard about the term User Profile Disks and what the basic idea behind this technology is. If so, you can quickly read through this first paragraph since this will be a recap of what you already know. If not, make sure you read this paragraph to understand the basic idea behind User Profile Disks, which from now on we will be calling UPD.


You will probably also be familiar with the term and technology called Roaming Profiles. Basically, for RDS roaming profiles is a technique that allows you to have the same personal settings no matter on what RD Session Host you log on to. Obviously this is very important when running multiple RD Session Host servers in a farm. These settings roam with you. Without going into too much detail here the technique behind this is as follows; A user logs on to a RD Session Host and his roaming profile is copied from a central network share to the RD Session Host server (by default under C:\Users\<Username.V2). If the user makes changes to his profile these are saved on the local location of the RD Session Host server. Upon log off the changes are copied back to the central network share. Upon logon and logoff the complete profiles (or at least the changes) are copied back and forth. If you’ve been working with roaming profiles you certainly will have seen cases where profiles were not copied properly, did not clean up properly (although you configured to delete cached copies) or cause profile corruption where you had no other option but to remove the roaming profile and start over.


With the introduction of Windows Server 2012 Virtual Desktop Infrastructure (Powered by Remote Desktop Services) obtains two different flavors. Session-Based Desktop Deployment, based on RD Session Host servers and Virtual Machine-Based Desktop deployment, based on RD Virtualization hosts. If you have experience with Virtual Machine-Based Desktop deployment before Windows Server 2012 (back then more often referred to as VDI) you’ll know that there are two flavors of VDI. There is VDI based on Personal Desktops, which basically means that every user has his own virtual machine running Windows 7 or 8. And there is VDI based flavor on Pooled Desktops where users share virtual machines available in a pool. It’s obvious that pooled VDI has advantages when it comes to the amount of resources needed since ideally you have less VM’s stored compares to personal VDI. The downside has always been that Pooled VDI did not support personalization.


To overcome this downside with Windows Server 2012, along with many other new features, User Profile Disks (UPD) was introduced. UPD contains a technique were profiles are stored on a central share inside a .vhdx file per user. As you might know .vhdx is the new standard introduced in Windows Server 2012, where previously .vhd was used, and is improved in many ways. As we’ll see in the next chapter a template .vhdx file is created upon initial configuration of UPD. Using the template a new .vhdx file gets created for every user that logs on for the first time. This .vhdx is then on the fly mounted to the location C:\users\<username> upon logon. Basically everything that would normally be stored in C:\users\<username> on the local cached copy is now immediately saved to the .vhdx on the central location. As UPD works on a lower level there are no compatibility issues. The OS is still writing settings to C:\users\<username>. This suddenly means really easy personalization of a pooled VM in your Windows Server 2012 Virtual Machine-Based Desktop deployment. Moreover, since Session-Based Desktop Deployment is part of the same RDS platform, UPD can also be enabled for RD Session Hosts running Windows Server 2012. In this article we’ll take a look at how to configure UPD for Session-Based Desktop Deployment and we’ll cover some considerations, pros and cons.


Installation


The following steps assume that you already have a basic Session-Based Desktop Deployment running, with an RD Connection Broker, an RD Web Access and at least 1 RD Session Host. As you probably know these roles can run on a single Windows Server 2012 box. We also assume that a basic Deployment and Session Collection have been created. Besides basic deployment the only prerequisite for setting up UPD is having a central share where we can store the User Profile Disk itself. Obviously, in production environments this would ideally be a high-available file server or SAN but for this demo we’ll be using a virtual machine running Windows Server 2012.



  1. We create a new folder, in our case U:\UPD



Figure 1:
UPD folder



  1. Using the Server Manager console we create a new share. We won’t go over all the steps there, basically, we create a SMB share using the wizard, and leave the permissions intact. We then browse to the path to make sure it accessible.


Figure 2: UPD Share



  1. Within the Server Manager we open the Remote Desktop Services Management (RDMS), and open the properties of the Session Collection.


Figure 3: Session Collection Properties



  1. We select the User Profile Disks tab, and select “Enable user profile disks”. We then provide the UNC path of the share we just created, provide a maximum size, and (as a first step) we configure to store all user settings and data inside the profile disk.


Figure 4: User Profile Disk properties



  1. That’s all for the configuration.

When we go back to the share, we’ll see that a new file has been created called UVHD-template.vhdx. This is the template file we mentioned earlier in the introduction.



Figure 5: UHVD-template


For every new user that logs on to an RD Session Host in this Session Collection a new .vhdx file will be created based on the template. As you can see the users GUID will be used in the name of the file.



Figure 6: UHVD files per user


As described earlier in the introduction, on the RD Session Host servers the .vhdx file is mounted underneath C:\users\<username>. Also, note that UPD makes sure that if an existing cached copy of a roaming profile is in place it will create a backup, by renaming that folder to <username>-BACKUP-<number>. Since this is a mounted volume, it’s fully transparent for applications that need to read and write to the profile.



Figure 7: Mount point in C:\Users\<username>


When the user that owns the .vhdx is not logged on, administrators are also able to simply mount the .vhdx file to see what’s inside and even make modifications if necessary. Just be sure to unmount the file again before the user logs on again.



Figure 8: Mount a .VHDX file


Considerations, pros and cons


Now, that we’ve completed the basic setup let’s discuss some of the considerations, pros and cons. The big pro for VDI is obvious here: Using a fully transparent mechanism, we are now able to add personalization on pooled VDI. A big pro for both Session-Based as well as Virtual Machine-based, is the fact that UPD can save all the settings in the profile, so that it also includes folders like AppData\Low and AppData\LocalLow were legacy applications sometimes write settings that normally are not part of a roaming profile. Another pro is the fact that RD Session Host does not have to copy the roaming profile back and forth upon logon and logoff, and thus no disk space is required on the RD Session Host anymore to (temporarily) store the local caches copies of the roaming profiles. Do note of course, that additional storage is required to store all the UPD files on your central share and every user takes up at least the space of the template. Also, note that UPD is enabled on the Session Collection. This means that the path of the share where you want to store the UPD’s is identical for all users that use that Session Collection. You cannot have different locations for the UPD files based on i.e. OU, or group membership. In our example, we simply configured the setup to add everything inside the UPD. What you can also do, since UPD operates on a lower level and is fully transparent, is to combine UPD with (existing) folder redirections and only store profile data and registry data inside the UPD, as shown below. This also results in a smaller template .vhdx file.



Figure 9: UPD storage options


Conclusion


As mentioned in the previous section, there are certainly a lot of pros for User Profile Disks for Session-Based and as well as Virtual Machine-Based deployments of Remote Desktop Services. The fact that UPD works on a lower level and thus offer transparency for applications as well as existing folder redirection techniques will ease the implementation process. As more RDS/VDI environments will be moved to Windows Server 2012, we’ll gain more insights in how UPD operates in (larger) production environments. Hopefully, this article was useful information for you and if you have any additional questions feel free to contact me.

About The Author

1 thought on “Working with User Profile Disks on Session-Based Desktop Deployments”

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top