If you ever allow the system (C:) drive to fill up on a Windows Server 2012 running Remote Desktop Services (RDS) that is also utilizing “User Profile Disks” then get ready for a headache. Okay, this particular headache isn’t THAT painful and can be fixed relatively quickly.
Are you getting this message when trying to login to your RDS 2012 host?
The User Profile Service service failed the sign-in.
User profile cannot be loaded.
Here’s the solution (or solutions). You may want to reboot the server after each step and/or before asking users to attempt to login again.
1. If this problem was caused by lack of free space on the system (C:) drive, you obviously need to deal with that first. Sometimes that is all that is needed to fix this error. Just for good measure, browse to C:\Users and delete all non-system local user profiles (don’t do this if you are only using local profiles…this entire blog post assumes you are using User Profile Disks). If these actions don’t fix the problem, continue to the next step.
2. Before proceeding on to specific user profile troubleshooting, let’s see if a simple permissions change can fix the issue. Check your Event (Application) Log for this (or similar) entry:
Event 1509, User Profile General
Windows cannot copy file \\?\C:\Users\Default\AppData\Local\Microsoft\Windows\WER to location \\?\C:\Users\TEMP\AppData\Local\Microsoft\Windows\WER. This error may be caused by network problems or insufficient security rights.
DETAIL - Access is denied.
If you see the above error, and you’ve confirmed the system (C:) drive is not out of space, then perform these steps.
- Make the local “SYSTEM” account an owner of the “WER” sub directory listed in the above error, and then apply to all child sub directories and files.
- Enable inheritance on the “WER” sub directory, and then delete all non inherited permissions on “WER” and it’s child sub directories and files.
If the permissions change doesn’t fix the problem, continue onward.
3. Determine the SID for the user with the problem (if this is affecting all users, skip to Step 6). To find the SID, open up Active Directory Users and Computers and browse to the user object in question (first make sure you are in Advanced mode by clicking on the View menu and clicking “Advanced Features”) and then double-click the user object. Click on the “Attribute Editor” tab and scroll down to the “objectSid” attribute. Note the value of this attribute (S-1-5-21*** and so on) as you will need to refer to it in a moment.
4. Load REGEDIT and browse to this location:
HKLM\SOFTWARE\Microsoft\Windows NT\Current Version\ProfileList
Find and DELETE the sub key that matches the “objectSid” attribute of the user object. Have the user try to login. If it is still not working, continue to the next step.
5. You may have a corrupt User Profile Disk. Browse to the share where these disks are located. Each User Profile Disk is stored in one self-contained file with the (.VHDX) extension. Use the “objectSid” obtained in Step 3 to locate the User Profile Disk. Once you find it (UVHD-S-1-5-21-***.vhdx), either rename the file or delete it. Have the user try to login (you may want to repeat step 4 first before asking the user to try again).
6. If all users are getting the above error, you want to perform the same steps, but apply it to all users. Hopefully you won’t have to rename/delete all user profile disks as that would be unfortunate. What I’ve found is that when this error happens to all users, it is typically resolved by deleting all profile sub keys (you might want to start with all profile sub keys named *.bak first). So simply follow Step 4 but instead of locating one specific sub key, delete them all EXCEPT for the system related ones. (It’s easy to make this distinction because the system sub keys are shorter in length.)
You may have to perform the above steps for more than one RDS host server if you have a load balanced collection.
