Migrating User Profile Disks in Remote Desktop Services
Published Mar 16 2019 12:47 PM 55.5K Views
Microsoft
First published on TECHNET on May 06, 2015

Good morning AskPerf!  This is Sree Krishna and Ramesh from Remote Desktop Services Team. Today we will discuss User Profile Disk migrations.


As you may know, Microsoft released a new feature to manage user profiles in Remote Desktop Services (RDS) deployments called User Profile Disks. User Profile Disks (UPD) store user and application data on a single virtual disk that is dedicated to one user.


UPD takes advantage of the NTFS attributes to control the permissions of objects. Since every user has their own user profile disk, each disk is created with explicit permissions. In other words when a user profile disk is created, the ACL (Access Control List) is added with the below default permissions:



a) SYSTEM


b) Administrator


c) <User account to which the User profile disk belongs >



All other user permissions are removed to avoid the user profile disk being accessed other than the corresponding user.


Why would this be an issue?


Let's consider the below scenario:



  • You have the user profile disks created on Drive A:.

  • For some reason such as (Space constraints/ Server migration / Data migration) you are forced to move your User Profile disks to a different location.


This is when you should consider the Windows NT permission architecture.


Scenario 1


You plan to migrate the UPD files on within the same Drive (Migrating the files that are one volume to another volume on the same disk)


If so, then you have nothing to worry about as this not difficult.


Scenario 2


On the Other Hand you Move between different drives. For Example (From a Volume on Drive A to a volume on Drive B:), Windows NT permissions Architecture is not going to favor you here.


Below are summary highlights between copy and Move among Same/different Volumes.



Same Volume



Different Volume



Copy



Security attributes are NOT retained and NOT carried



Security attributes are NOT retained and NOT carried



Move



Security attributes are retained and carried



Security attributes are NOT retained and NOT carried



The differences and conditions are neatly outlined in the below articles:


How permissions are handled when you copy and move files and folders


All this being said, when the permissions of a User Profile Disk loses its default permissions (especially in Scenario 2), you will likely end up with problems in your Remote desktop Services environment.


Symptoms you May notice:


If the User Profile Disk loses permission for its corresponding user, that user will be logged on with a temporary profile. The issue with this is all of the users profile settings will not be available, and, any changes made in that session will be lost.



Additionally you may see Event ID’s 1511 recorded in the event viewer for every login attempt.


Mitigation options:


HOW TO: Copy a Folder to Another Folder and Retain its Permissions




  • To preserve permissions when files and folders are copied or moved, use the Xcopy.exe utility with the /O or the /X switch. The object’s original permissions will be added to inheritable permissions in the new location.

  • To add an object's original permissions to inheritable permissions when you copy or move an object, use the Xcopy.exe utility with the –O and –X switches.

  • To preserve existing permissions without adding inheritable permissions from the parent folder, use the utilities such as Robocopy.exe


xcopy c:\old c:\new /O /X /E /H /K



where old is the source folder and new is the destination folder.


/E - Copies folders and subfolders, including empty ones.
/H - Copies hidden and system files also.
/K - Copies attributes. Typically, Xcopy resets read-only attributes.
/O - Copies file ownership and ACL information.
/X - Copies file audit settings (implies /O ).


Hopefully this post makes you aware of issues that can arise from migrating UPD’s.


Reference:



-Sree & Ramesh

3 Comments
Version history
Last update:
‎Mar 16 2019 05:47 AM
Updated by: