So… this has been a sitting as a draft for almost 2 years now but wanted to get this out as it was a fun project and also to dispel a few myths out there around the infamous Remote Desktop feature “User Profile Disks” or UPD’s for short…
Firstly, let’s get controversial. UPD’s rock. Simply that. If you’re heading down the path of RDS and you have the underlying infrastructure that can support it (see below) then your default mindset should be “why not use UPD’s” as opposed to “why use UPD’s”
How to do them right…
Whilst there are many things that can decide whether a RDS deployment goes sour or not, stick to the below for UPD’s and you have yourself a good baseline.
- Use a Scale-Out File Server (SOFS).
- Apply all recommended updates and hotfixes… duh
- Use the Remote Desktop Collection management functionality form the Server Manager. Avoid GPO’s that conflict with these settings….
- Set your maximum size to be bigger than you ‘need’
- Use the inclusion mode with Folder Redirection rather than exclusion. i.e. Only include in the UPD what you tell it to
- Do it on Hyper-V (ok, so it should be fine on VMWare but I can’t attest to this… )
Scale-Out File Server (SOFS):
Why are scale-out file servers so important?
If you have a bit of a search, you’ll find yourself a few blogs around users unable to login with various errors, corrupt disks, a mention of someone coining the BSOW (Black Screen of Waiting – that’s my favourite) and so on and so on…
SOFS has something called continuous availability. This means that you can scale out your front end nodes using the same namespace and all connection will be automagically load balanced and persist through a node failure. And it works.
Ok, great. So we’re Highly Available. All well and good, but what about performance? Ok, go have a read of this technet article and this awesome blog (this one has a cat meme. Everyone loves a cat meme) and when done, come back to me and continue reading..
You didn’t read them did you? Sigh.. Ok, I’ll summarise it for you here then 🙂
3 key features that come into play with performance:
- Increased bandwidth with SMB Multichannel
- CSV Cache – yep throw a few extra gigs of memory on your VM’s (of physicals if that’s your style) and buff up your CSV cache. Check out a blog in CSV caching here or for those in a rush here’s an example of setting the CSV cache for all disks collectively to 4GB total
(Get-Cluster). BlockCacheSize = 4096
- Automatic rebalancing of SOFS clients. This means that client connections will again automagically be rebalanced across the nodes. This is extremely helpful in an RDS farm as it will balance itself based on user patterns. No predictive balancing and scaling..
So.. we’ve established that SOFS for UPD’s = HA + Performance.
There are a couple of things to be aware of if using SOFS but the important one for my fellow Hyper-V users is if you are deploying in a VM using a Shared VHDX, you have to consider your backup options carefully.
Apply all recommended updates and hotfixes
Ok, if you have to be told this, then I’m not sure sure you should be deploying and RDS farm anyway 😉
By default, apply all recommended updates from Microsoft.
Remote Desktop Services:
https://blogs.technet.microsoft.com/enterprisemobility/2016/06/06/recommended-hotfixes-and-updates-for-remote-desktop-services-in-windows-server-2012-r2/ or TechNet https://support.microsoft.com/en-au/kb/3147099
Failover Clusters (for SOFS)
Cluster fixes for deadlock and resource time-out issues in Windows Server 2012 R2 Update 1 (for SOFS)
Custom values for various MPIO timers in Windows Server 2012 R2 may not be honoured (for SOFS)
Hotfix to avoid a deadlock situation on a CSV file system volume on Windows Server 2012 R2 (for SOFS)
A SQL Server that is running in a Hyper-V virtual machine takes a long time to restore a database to a dynamic VHD (for SOFS)
Same rules apply for your standard Operating System updates and your Hyper-V hosts.
Ok, now you’re all patched and ready to rock and roll..
Use the Collection Management from Server manager:
I’ve seen it so many times that engineers will be building a brand spanking and shiny new RDS environment, just as they’ve always done and go and apply some GPO’s to either reiterate the settings in Server Manager or simply just because that’s how they’ve done it for years.
No matter their reasons, they all end up in the same place where you are unable to apply changes to your collection or you get errors when doing so.. This is typically because a GPO they’ve defined is stopping server manager from setting or even confirming a particular configuration.
You’re error could be different, but heer’s an example I’ve
I went at set a GPO to disconnect sessions to 8 hours, ran gpupdate on the farm to send the config and then tried to set the same setting in the properties of the collection..
Go back into the properties of the collection and we’re not looking right..
What’s the results here then? The GPO will win and users will in fact be dropped after 8 hours but the management tools will not accurately represent the settings.
Conclusion: Only use GPO for settings not defined in the server manager. You’ve been warned..
Bonus tip for management – Sidder (sorry, no steak knives.)
Quickly see which User Profile Disk maps to which Domain User – great tool!! Do not use UDP’s without it… tip: Run As Administrator..
Set maximum size to bigger than you need:
When starting out a new collection, you have the choice to define the maximum size of any UPD configured for that collection.
Whilst there are ways to modify this later, you’re better off setting it right first time round.
This one will be debated long and hard due to the constraints of your environment and how you deal with capcity planning etc. But while you have your RDS Admin hat on, you will want to be pushing the bigger is better argument for the ease of management.
Don’t go ridiculous and set 100GB per user, but likewise don’t set 500MB either. This all depends on what your users roaming profiles look like today, but as a minimum I would try to set something in excess of the 1GB zone in an effort to prevent your users filling all their disks up.
Inclusion mode with Folder Redirection vs Exclusion mode
When deploying UPD’s, you have 3 key options..
- The location.. This is your SOFS share.
- The maximum size of your profiles (can’t be changed via the GUI after initial config)
- And the ‘User profile disks data settings’
This is where you choose to either:
Store everything by default and choose what to exclude, or
Store nothing by default and choose what to include…
*the below is my lab environment. You custom inclusions would typically have a few listed there..
Do not store your user content on the UPD. Just don’t do it, end of story.
Use redirected folders except for AppData (Never do this. You’ve been warned), Start Menu, Searches and
Your environment might dictate otherwise.
Do it on Hyper-V:
Ok, so this isn’t critical. It will work if you’re subjected to the VMWare taxes. Even the Scale-Out File Server with an iSCSI disk attched. But if you’ve worked with me before you would know that I have all but drunk the entire Microsoft coolade.
But that’s part of why you are here too..
Ok, so if I follow all the guidance and do exactly what you advised, what will the experience be like?
User experience in our case was 30 second logon experience. You do get the BSOW (love that acronym, wish I’d thought of it) for a few seconds as the VHD is mounted to the RDS server and user registry hive is loaded.
Not once have we had a corrupted user profile disk and our users never get the temporary profile login that many claim is part of everyday life with UPD’s.
Things to consider and test in your environment:
- VMQ’s – Virtual Machine Queues: Make sure these are optimally configured. This could be very simple or very difficult depending on your kit. (One of my many drafted blog posts I cover my experiences with VMQ’s so hopefully this see’s the light of day soon. Another one of those misinterpreted technologies)
- RSS/vRSS – (Virtual) Receive Side Scaling: Make sure this is enabled on your 2012 R2 instances. RSS for physical RDS/SOFS and vRSS for VM’s.
- If you want to change the size of the default UPD post configuration, simply find the VHD located on the SOFS share and modify the disk. When a new user logs in the system essentially copies the default UPD bringing with it it’s properties such as maximum size etc.
- If you need to increase a user specific UPD, then you’ll need to expand that particular VHD and the logical volume within..
- Test the user experience thoroughly. Your organisation might have a key LOB application that writes user needed for roaming data to the local profile… sigh
Rightio then. That’s about it on the topic of UPD’s in RDS 2012R2 for now. Albeit a little later than first planned but better late than never.