There are several ways to migrate Windows Folder Redirection to a new storage, below are four scenarios on how we can implement the change.

Migration Scenarios:

In this exercise we will explain four migration scenarios with varying level of client impact:.

Group Policy Points to “Do not move the contents of Documents to the new location”
Client sync the files for the last time before migration and IT department moves the data, source location is offline and not available to the client during and migration.
Group Policy Points to “Move the contents of Documents to the new location”
Client does not need to sync the files before migration and IT department just prepare the destination environment but do not move the data, Source location is still available and read/write during and after migration (until all user’s data has been migrated).
Group Policy Points to “Move the contents of Documents to the new location”
Client does not need to sync the files before migration and IT department moves the data, Source location is still available and read only before during and after migration (until all user’s data has been migrated).
Group Policy Points to “Do not move the contents of Documents to the new location”. Client does not need to sync the files before migration and IT department moves the data, source location is not available after the migration and new location has the same DNS name as the old source location after migration.

Please note you might need to add the following hotfixes to the client PC to execute a successful migration for Scenario’s 1, 2, or 3.

Offline files synchronization may not finish on a computer that is running Windows 7 or Windows Server 2008 R2
http://support.microsoft.com/kb/2561708

An unexpected network error occurred” error message when you try to browse a DFS folder in Windows 7 or in Windows Server 2008 R2
http://support.microsoft.com/kb/2649905

Improved interoperability between the BranchCache feature and the Offline Files feature in Windows 7 or in Windows Server 2008 R2
http://support.microsoft.com/kb/2675611

The Folder Redirection policy does not work if a previous user sets a redirected folder to an offline mode in Windows 7 or in Windows Server 2008 R2
http://support.microsoft.com/kb/2610379

You are unable to update the target location of offline file shares in the Offline File client side cache without administrative permission in Windows Server 2008 R2 or in Windows 7
http://support.microsoft.com/kb/977229

Scenario 1:

Group Policy Points to “Do not move the contents of Documents to the new location”
Client sync the files for the last time before migration and IT department moves the data, source location is offline and not available to the client during and migration.

Procedure to run the migration is as following:

Inform the client that we will be doing the migration and they should do the final sync for the files.
When clients shutdown the computer Win7 client will be pointing to M: to \\OldNAS\testuser.
Win7 client shutdown.
Copy the files from the old file system \\OldNAS\testuser to the new files system \\isilon\users\testuser, make sure to use a tool that preserves ACL permissions.
Remove the old shares from the server not the files “Remove \\OldNAS\testuser share”.
Access AD and change the profile path for the migrated user to \\isilon\users\testuser.
Start Win7 client.
Win7 client M: drive should be mapped to \\isilon\users\testuser
If fast logon is enabled, the group policy will be applied at the first logon and will be enabled at the second logon, client should reboot the computer for the sync center to be updated from \\OldNAS\testuser to \\isilon\users\testuser.
If the client did any work while the migration is in progress, he/she should open a case with helpdesk to move the modified files from the local sync center to the new path.

Note:
There is an issue with Windows 7 SP1 and deleting the old offline folder path after migration, please read the following KB977229
http://support.microsoft.com/en-us/kb/977229.

To make sure that the old path is deleted and all files are migrated successfully we need to add the following registry key after the migration and before the client first login:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer
DWORD: FolderRedirectionEnableCacheRename = 1
Also it is important to note that client should have a local admin privilege to the local machine for this registry key to be executed successfully.

Pros:

IT department move the data, server to server migration (network is not congested when client re-connect).
Data on the old array can be kept for specific period of time until we are sure migration is successful.

Cons:

Migration has to be done during a maintenance window; client not recommended to do any file changes during the maintenance window.
Client has to sync before the migration (This is a must or changed data will only be accessible using the sync center) unless KB977229 is executed.
Any client data changed between the last sync and the migration date will be accessible only using the sync center on the local workstation. unless KB977229 is executed
Duplicate cached files seem to get deleted after the migration is completed, but the unique one is preserved using the sync center.
In the sync center the client will continue seeing the old and the new path, although the old path is not accessible any more. unless KB977229 is executed

Scenario 2:

Group Policy Points to “Move the contents of Documents to the new location”
Client does not need to sync the files before migration and IT department just needs to prepare the destination environment but do not move the data. Source location is still available and read/write during and after migration (until all user’s data has been migrated).

Procedure to run the migration is as following:

Inform the client that we will be doing the migration and they should notice a temporary increased in log on time next time they boot up.
When clients shutdown the computer Win7 client will be pointing to M: to \\OldNAS\testuser.
Win7 client shutdown.
Enable the share \\isilon\users\testuser, make sure to be accessible to the client.
Access AD users and computers and change the profile path for the migrated user to \\isilon\users\testuser.
Start Win7 client.
Win7 client M: drive should be mapped to \\isilon\users\testuser
If fast logon is enabled, the group policy will be applied at the first logon and will be enabled at the second logon, client should reboot the computer for the sync center to be updated from \\OldNAS\testuser to \\isilon\users\testuser.
Client Computer will start doing the migration and copying the files from \\OldNAS\testuser to \\isilon\users\testuser after the files are finished copying all the files (and links to them) on the old system \\OldNAS\testuser will be deleted automatically by the client machine.

Pros:

IT department will only need to prepare the environment.
Client does not need to sync before the migration.
Any client data changed between the last sync and the migration date will not be lost
Process as following after the migration:
- Data sync back to old array.
- Data sync back using the client host between old array and the Isilon.
- After several reboots, all links and data in the old arrays are deleted.

Cons:

Server to server migration is not supported.
Both shares the old and new needs to be online and accessible to the client.
Old Array data will be deleted after the windows PC migration is completed.
Duplicate cached files will get deleted after the migration is completed.
Bandwidth is an issue as the client computer will be moving the data when client computers boots up.

Scenario 3:

Group Policy Points to “Move the contents of Documents to the new location”
Client does not need to sync the files before migration and IT department moves the data, Source location is still available and read only before during and after migration (until all users’ data has been migrated).

Procedure to run the migration is as following:

Inform the client that we will be doing the migration and they should notice a temporary increased in log on time next time they boot up.
When clients shutdown the computer Win7 client will be pointing to M: to \\OldNAS\testuser.
Win7 client shutdown.
Enable the share \\isilon\users\testuser, make sure to be accessible to the client.
Make \\OldNAS\testuser a read-only share.
Copy the files from the old file system \\OldNAS\testuser to the new files system \\isilon\users\testuser, make sure to use a tool that preserves ACL permissions.
Access AD users and computers and change the profile path for the migrated user to \\isilon\users\testuser
Start Win7 client.
Win7 client M: drive should be mapped to \\isilon\users\testuser.
If fast logon is enabled, the group policy will be applied at the first logon and will be enabled at the second logon, client should reboot the computer for the sync center to be updated from \\OldNAS\testuser to \\isilon\users\testuser.
Client Computer will start comparing files between the old system and the new systems, all new changes will be updated on \\isilon\users\testuser the old system will be a read-only and only accessible using sync center.

Pros:

IT department move the data, server to server migration (network is not congested when client connect back).
Data on the old array can be kept for specific period of time until we are sure migration is successful.
Client does not need to sync before the migration.
Any client data changed between the last sync and the migration date will not be lost.
Process as following after the migration:
- Data sync to new array.

Cons:

The old system & shares need to be online until all clients have been migrated successfully.
Duplicate cached files will stay until we manually delete the old path.

Scenario 4:

Group Policy Points to “Do not move the contents of Documents to the new location”
Client does not need to sync the files before migration and IT department moves the data, source location is not available after the migration and the new location has the same DNS name like the old source location after migration.

Procedure to run the migration is as following:

When clients shutdown the computer Win7 client will be pointing M: to \\OldNAS\users\testuser.
Win7 client shutdown.
IT Copy the files from the old file system \\OldNAS\users\testuser to the new files system \\isilon\users\testuser, make sure to use a tool that preserve ACL permissions.
Access DNS and change the A/CNAME record of \\OldNAS to point \\Isilon
Ping \\OldNAS and it should reply with the IP addresses of the Isilon (after DNS timeout)
Start Win7 client.
Win7 client M: drive should still be mapped to \\OldNAS\testuser.
If the Client worked while the migration is in progress, all modifications will be synced back to the Isilon.

Pros:

IT department move the data, server to server migration (network is not congested when client re-connect).
Data on the old array can be kept for specific period of time until we are sure migration is successful.
Client does not need to sync before the migration.
Any client data changed between the last sync and the migration date will not be lost.
Cached files do not get deleted after the migration, as the client computer will not recognize any client path changes.

Cons:

Migration has to be done in one shot, this means bigger outage window.

Migration Considerations:

Migration tool:

For this migration example we will be using emcopy.

The command that we will be using will be the following:

Example command:

emcopy64.exe \\OldNAS\testuser “\\isilon\users\testuser” /ignoredhsm /secforce /o /sd /s /de /sdd /th 64 /purge /secforce /c /r:1 /w:1 /log+:d:\copy_logs\users\ testusers-final.log
Note: Isilon support sometimes recommends 16 threads MAX, contact support if you have an issue running th 64.

Permissions for Migration account:

For the migration data to be copied from source to target, the tool access the data must be able to access the source and the target data and have enough permission to modify the ACLs on the target.

Make sure to add the migration service account in following groups for a successfully replication of ACLs

Windows Side:

Add the service migration account to the local admin group of the migrated server
Or user an account in the Domain Administrators Group and Backup Operators Group
You might also need to grant the service migration account manage auditing privilege.

Isilon Side: