次の方法で共有

Migrating User Profile Disks in Remote Desktop Services

  • [アーティクル]

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.

clip_image002

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

clip_image004

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

Comments

  • Anonymous
    May 06, 2015
    Good morning AskPerf! This is Sree Krishna and Ramesh from Remote Desktop Services Team. Today we will