Tech Line

Share Migrations Made Easy

Migrating file and folder permissions? Easy. Moving share permissions et al? That's another story. Here's how to ease the pain.

Chris: I have a simple question that I’ve never seen addressed anywhere else even though I’m sure this evolution takes place quite a lot. I’m migrating my user’s data from one server to another in order to increase the space and speed on the server. The data is comprised of their branch, department and division shared data. Consequently, there are a lot of shares created to allow the various user groups, special interest groups and inter-departmental cooperatives to share and work on files. Because of the various permissions given to the sundry groups throughout my command, I can’t just do a redirect like with home folder shares.

I’ve used the xcopy command previously to migrate the data and preserve the file/folder permissions but I haven’t found a way to preserve/migrate the shares and all their special permissions, since the shares are UNC path dependent. In the past I ended up just re-creating all the shares manually, but now, with over 50 shares and two servers needing migration, I’m looking for a more efficient way.

Do you know of a way, utility, script that would ease the migration?
— Brad

Tech Help—Just An
E-Mail Away

Got a Windows, Exchange or virtualization question or need troubleshooting help? Or maybe you want a better explanation than provided in the manuals? Describe your dilemma in an e-mail to the MCPmag.com editors at mailto:[email protected]; the best questions get answered in this column and garner the questioner with a nifty MCPmag.com baseball-style cap.

When you send your questions, please include your full first and last name, location, certifications (if any) with your message. (If you prefer to remain anonymous, specify this in your message, but submit the requested information for verification purposes.)

Good question, Brad. Bringing over the NTFS permissions when you copy shares to another box has never been a problem. This can be done with Xcopy, Robocopy, and most enterprise back-up tools. Share permissions have always been another story.

One method for migrating share permissions following the migration of shared folders would be to use the Windows Server 2003 Resource Kit tool Permcopy.exe. Permcopy.exe allows you to migrate share permissions between file servers, but requires that the folders on the target server already be shared in order to migrate the permissions. You could share the migrated folders on the target server manually (good luck!), or using a script.

I’m not going to spend any time elaborating on the first method, because there’s a better way. In 2004, Microsoft released the File Server Migration Toolkit. This is exactly what you need in your situation. This tool is your go anywhere file server migration friend. You can use it to:

  • Migrate shared folders and permissions
  • Migrate NTFS permissions
  • Configure DFS to assist in the migration process

In addition to migrating folders to a new server and preserving all NTFS and share permissions, what I like best about this tool is its use of DFS in the migration process. It walks you through setting up a DFS root to maintain consistent UNC paths throughout the migration process. This is done using the included DFS Consolidation Root Wizard tool. So, as shares are moved from one server to another, the movement of the shares are transparent to the end user. Personally, I like setting up DFS from the get-go and leaving it in place. This allows you to add file servers and relocate shared folders as needed without having to update UNC paths for users or applications. With all UNC paths pointing to the DFS root, the physical location of shared resources can change without impacting users or applications.

Again, for your specific problem, the File Server Migration Toolkit is all you need. One issue to be considered that does not apply in your specific case is migration to a server cluster. Server clusters support a maximum of 1,674 resources. So a straight migration of a large number of shares may not be feasible, as each migrated share would create a new resource.

If you are migrating to a virtual file server running on a server cluster, the File Server Migration Toolkit includes an "Optimize cluster resource usage" option. This option will cause a parent folder or setup on the target as a hidden share and the subfolder to be migrated as a subfolder within the hidden share. So if you migrate the E:\Profiles\User1 folder with the “Optimize cluster resource usage” option selected, the folder structure will be copied to the target and accessed as \\target\Profiles$\User1. In this scenario, NTFS permissions is required to restrict access to each migrated subfolder. Initially, the share permissions of the parent (Profiles$) is set to full control only for the Local Administrators group. So following the migration you need to set the appropriate NTFS permissions for each subfolder and then loosen the share permissions of the parent folder, such as by granting the Everyone group Read and Change share permissions. Any individual user’s permissions for any subfolder is ultimately dictated by the NTFS permissions.

If you haven’t worked with the File Migration Toolkit yet, take it out for a spin. In his capacity as unofficial spokesperson for Microsoft, Mike Tyson once described file share migration with the words “…you deserve to feel the pain that I feel." With the File Server Migration Toolkit, you can now consider yourself as having one less thing in common with Mike Tyson.

About the Author

Chris Wolf is a Microsoft MVP for Windows --Virtual Machine and is a MCSE, MCT, and CCNA. He's a Senior Analyst for Burton Group who specializes in the areas of virtualization solutions, high availability, storage and enterprise management. Chris is the author of Virtualization: From the Desktop to the Enterprise (Apress), Troubleshooting Microsoft Technologies (Addison Wesley), and a contributor to the Windows Server 2003 Deployment Kit (Microsoft Press).learningstore-20/">Troubleshooting Microsoft Technologies (Addison Wesley) and a contributor to the Windows Server 2003 Deployment Kit (Microsoft Press).

comments powered by Disqus
Most   Popular