标签：robocopy permcopy fsmt 共享权限注册表
【共享权限迁移验证】
上文中我们提到了NTFS权限的迁移验证， 其实在企业中文件服务器建立出来还是要提供共享服务，所以通常情况下文件服务器的迁移也会伴随着共享权限的迁移，下面我将和大家分别探讨下Permcopy，FSMT，以及利用注册表如何实现共享权限的迁移。
【环境介绍】
2008dc.contoso.comDC角色 IP 192.168.1.2
2003FS.contoso.com2003文件服务器角色 IP 192.168.1.3
2012FS.contoso.com2012文件服务器角色 IP 192.168.1.4
本文将使用以上三台服务器进行同一域内文件服务器迁移验证
工具：Permcopy+Xcopy
工具简介：Permcopy自Windows NT时代已经作为Resource Kit 中的工具提供，主要用于复制跨磁盘，或跨服务器的共享文件夹权限使用
该命令并没有内置在之后的系统上，如果2008及以后的Server OS需要使用也请手动拷贝Permcopy.exe至system32目录，Permcopy.exe可以在网上下载得到，或者从2003 Resource Kit中得到
【迁移步骤】
使用共享文件夹IT，设置Info.MG组对于共享文件夹具备更改权限，但是NTFS权限添加IT组内mike具备完全控制权限，Jack具备只读权限
目标服务器2012R2上面E盘为空，一会要使用xcopy命令将03FS文件夹内容+权限复制过来
运行Xcopy迁移命令 xcopy \\192.168.1.3\ShareFloder\it E:\it /O /X /E /H /K
运行完成可以看到，和之前我们测试一样，NTFS权限已经得到复制迁移
注： 大家可以看到，我这次用的是 \\192.168.1.3 这种网络来源路径，实测xcopy是支持这种网络路径的，只不过有时候网络路径会遇到问题，所以会映射为网盘方式。
另外，虽然 \\192.168.1.3\it 也可以访问，但是如果希望单独迁移it目录的权限，也请你输入 \\192.168.1.3\ShareFloder\it，这种路径，因为Xcopy会去通过UNC路径访问文件路径，去抓取权限，实测输入 \\192.168.1.3\it不能迁移it文件夹权限。
刚才我们通过Xcopy将it文件复制过来，但是并没共享，permcopy不会自动去创建这个共享，所以需要我们手动将it文件夹开启共享，可以随便给个共享权限，反正permcopy命令执行后会用原共享权限，完全覆盖掉目标共享权限。
注意，这个permcopy的命令有很大的输入讲究，如果你输入\\Servername\sharename这样一定会报错，sharename前面不能加\参数，同时sharename前面必须要有一个空格，注意，仅一个空格，一个也不要多。
Permcopy 在进行迁移的时候只认共享名称，比如，你\\192.168.1.3 上面有个it共享文件夹，里面有一个子文件夹叫sharefloder，我想复制sharefloder行不行
对不起 ，不行，Permcopy只认共享名称，如果sharefloder没有出现在文件共享管理器中的共享名称里面Permcopy是不可以复制的。
Permcopy只复制共享文件夹的权限，使用permcopy复制，只好把每个需要复制共享权限的文件夹，全部变成 “ 共享“，才可以进行复制。
迁移效果，NTFS权限完整无缝迁移过来，共享权限完整无缝迁移过来
【点评】
功能实现: ★★★★★
专业性: ★★★★★
性能： ★★★★
易用性: ★★★★
通过以上验证大家可以看到，通过Xcopy+Permcopy，可以实现文件内容+NTFS权限+Share 权限的复制迁移，通过Xcopy复制的话，不能复制加密文件，父文件目录时间戳记会丢失。如果对于加密文件属性迁移，目录时间戳记迁移、以及复制性能没有过多要求，仅用于迁移NTFS权限+共享权限，那么Xcopy+Permcopy这种方案是不错的选择。
工具：Permcopy+Robocopy
工具简介：Permcopy自Windows NT时代已经作为Resource Kit 中的工具提供，主要用于复制跨磁盘，或跨服务器的共享文件夹权限使用
该命令并没有内置在之后的系统上，如果2008及以后的Server OS需要使用请手动拷贝Permcopy.exe至system32目录，Permcopy.exe可以在网上下载得到，或者从2003 Resource Kit中得到
【迁移步骤】
使用共享文件夹HR，设置Lucy对于共享文件夹具备完全控制权限，但是NTFS权限添加Frank具备完全控制权限，Lucy具备只读权限
目标服务器2012R2上面E盘为空，一会要使用xcopy命令将03FS文件夹内容+权限复制过来
运行robocopy迁移命令robocopy \\192.168.1.3\HR e:\hr /e /efsraw /copyall
运行完成可以看到，和之前我们测试一样，NTFS权限已经得到复制迁移
文件目录时间戳，文件内容时间戳，文件属性，也已经完整的迁移了过去
在执行robocopy命令之后可以看到迁移报告，也可以使用/MT:n 参数，启动多个线程来进行robocopy复制，但是请注意，MT参数不兼容efsraw与IPG参数
运行共享文件夹迁移命令 permcopy \\192.168.1.3 HR \\192.168.1.4 HR
刚才我们通过RoboCopy将HR文件复制过来，但是并没共享，permcopy不会自动去创建这个共享，所以需要我们手动将HR文件夹开启共享，可以随便给个共享权限，反正permcopy命令执行后会用原共享权限，完全覆盖掉目标共享权限。
迁移效果，NTFS权限完整无缝迁移过来，共享权限完整无缝迁移过来
【点评】
功能实现: ★★★★★
专业性: ★★★★★
性能： ★★★★★
易用性: ★★★★
目前看来Permcopy+Robocopy这种解决方案对于ITpro来说堪称最完美的了，即可以完整无缝的做到迁移文件内容+NTFS权限+共享权限+近乎全部的安全属性
也可以将诸如文件目录时间戳，文件时间戳，及文件属性等信息进行迁移，还可以利用RoboCopy完成更加高级的操作，比如进行多线程复制性能提升，文件增量复制等。
所以笔者认为如果你是一名ITpro，对于命令行操作不是特别抵触，那么使用Permcopy+Robocopy完成NTFS+共享权限的迁移绝对是你的最佳选择。
工具：FSMT
工具简介：FSMT( File Server Migration Toolki )是微软在Windows Server 2003推出的扩展工具，实测可以被2008 , 2008R2，2012，2012R2使用，需要单独从微软官网进行下载，通过FSMT可以帮助ITpro完成共享文件夹权限的迁移，以及DFS权限的迁移
迁移过程中采用迁移项目的方式进行运作，每次迁移FSMT都会创建一个项目迁移记录，帮助管理员用于回看，检查迁移时的报告。
工具下载地址: https://www.microsoft.com/enus/download/details.aspx?id=10268
【迁移步骤】
使用共享文件夹GR，设置Frank对于共享文件夹具备完全控制权限，NTFS权限添加Lucy具备只读权限
FSMT安装过程属于典型的微软惯例，故这里不做安装过程介绍，FSMT直接在目标端安装即可，安装完成后打开File Server MigrationWizard，界面如下图所示
注：如果FSMT是安装在2012系统上面请事先安装好.NET3.5功能
点击New即创建我们之前说过的迁移项目
通过弹出的向导提示可以看到，这里创建的项目，只是用于存放迁移对象基本信息，迁移设置，迁移log，迁移报告等信息。
点击Next之后会提示让我们一个设置项目文件夹，请注意，此文件夹仅用于存放之前提到的项目信息，并不会存放实际的迁移文件
如果FSMT检测到项目文件夹不存在会询问我们是否需要创建，点击是即可
点击Next之后，向导会提示让我输入DFS根服务器名称，用于将我们迁移过来的\\UNC路径文件映射到DNS命名空间下，此次迁移暂不涉及DFS，故取消勾选
点击Next，会提示需要我们选一个路径，这个路径就是目标服务器的路径了，也就是迁移过来的文件会真实的存在这里，这里有个说法，即便你指定的是磁盘根路径，例如
这种E:\，但是FSMT在迁移过程中仍然会在E:\下面创建一个文件夹03fs.contoso.com，所以03fs迁移过来的文件都会放在这里，之后的步骤中我们会通过修改xml实现存放在其它路径
创建完成项目之后，FSMT迁移过程主要的共享配置已经结束了，在工作台界面下点击Add Server ，输入添加来源服务器
添加完成完成服务器之后，有一个重要的选项要设置，点击到服务器，右侧有几个setting的选项
第一个选项，如果被勾选，当FSMT迁移源共享到目标共享之后，会把源共享停掉！！
第二个选项，是否要拷贝安全设置，一定要确保被勾选
第三个选项 Resolveinvalid security descriptors，一旦你勾选了这个复选框，FSMT迁移过程会去帮你解决无效的安全描述符，具体处理如下内容，让源文件夹更加适应目标端，如果你发现迁移过来之后SID不太对，可以试试取消勾选这个选项
Deny ACEs with unresolvable SIDs, are replaced with the Everyone SID.
Allow ACEs with unresolvable SIDs, the ACE is dropped.
Audit ACEs with unresolvable SIDs, the ACE is dropped.
An owner with an unresolvable SID, is set to the local Administrators group.
A group with an unresolvable SID, is replaced with the local Administrators group.
设置好了服务器设置之后，点击到ShareFloder，右侧可以设置，共享的映射信息，包括映射过来的目标文件夹和目标共享，可以看到，正如之前所说，即使我在上面指定了要存放在E:\根路径，但是这里迁移设置仍然会在E盘下创建FQDN名称的目标文件夹和目标共享名
可以手动将目标共享名和目标文件夹名称改成自己想要的
假设ShareFloder父共享下面有三个子共享，这里面不会显示出四个共享，而是只会显示一个ShareFloder父共享，但是可以通过下拉菜单选择到子共享，进行位置修改。
如果共享比较多，这样一个一个修改会不会太累了呢，除了手动修改的办法，还可以通过修改迁移项目xml实现批量更改，修改之前，需要暂时将FSMT迁移向导关闭，不然一会修改xml会提示正在被使用，无法修改
打开刚才设置过的项目目录，找到项目文件夹中的xml文件
打开xml之后，可以看到，只不过是把我们图形界面看到的选项都给xml化了，首先替换共享名称，搜索 _03fs.contoso.com 全部替换为空，这里请注意，并不一定所有的都是FQDN，如果你在添加Source Server那一步添加的是IP地址，这里就是替换_192.168.1.3 ，如果添加的是netbios计算机名称，这里就是替_03fs
除了共享名称，我们还需要替换目标位置名称，搜索E:\03fs.contoso.com
注意，这个位置的替换有说法，假设，你有四个独立的父共享，你希望四个父共享迁移过去都独立存放在E:\根目录，那你就把E:\03fs.contoso.com全部替换，然后只保留E:\父目标文件夹名称 ，E:\ShareFloder这样的名称，或者自定义一个目标文件夹名称。
如果你依然希望保留父共享存在子共享这种架构，就像我们这种场景，那么就比较特殊一些，有需要特别注意的地方。
首先你需要查找到父目标文件夹的名称，将03fs.contoso.com删除掉，只保留E:\父文件夹 e:\ShareFloder 这样的文件夹名称
之后你需要查找父目标文件夹的名称，将03fs.contoso.com替换掉，这里需要注意的是在替换03fs.contoso.com之后，一定要确保子文件夹physicalPah路径是E:\父文件夹\子文件夹 这种格式 ，E:\ShareFloder\GA
如果你很自信路径不会出问题的话，也可以直接全部替换03fs.contoso.com这样的名称
编辑完成之后保存，然后运行FSMT迁移向导，选择Open，打开刚刚保存的xml文件
可以看到设置已经按照我们批量替换的生效了，如果这一步提示报错，无法去验证，请检查xml文件中是否格式不正确
点击Continue，这是FSMT会去验证我们刚刚的来源目标的共享设置与文件夹设置是否正确，同时也会确认迁移的数据量，是否已经ready to copy
Ready tocopy之后我们点击Continue，FSMT则会开始启动拷贝文件的流程
拷贝文件和文件夹结束，提示有一个警告，点击报告查看，报告显示有一个文件不能被迁移，拒绝访问，这个文件是我之前设置过的加密文件，可见FSMT不能迁移加密属性的文件，这点类同于WSMT和Xcopy。
注意，这个时候如果你去看迁移过来的文件夹和目录，你会发现，你没有权限打开这个目录，即便你进去打开了，也会发现权限都没有迁移过来，千万不要着急，因为到目前为止我们只是拷贝了文件和文件夹，还没有将源端的权限及安全属性apply到目的端
继续点击Contiune，会出现一个警告，大致意思是，这是迁移的最后切换步骤，此步骤将apply权限和安全属性到目的端，执行此过程后，如果设置了关闭源共享，那么源共享将在这一步骤关闭，Ready好了就点是。
点击是之后开始执行最后的apply权限和切换过程，当提示完成之后，点击确定，即可去查看报告，验证权限
再次打开2012FS上面ShareFloder发现NTFS权限，只读属性，文件时间戳已经被迁移过来，文件目录时间戳没有被迁移可以理解，但是共享权限竟然没有被迁移过来。
说到这里，其实是个有意思的故事
当时一看共享权限没有迁移过来我就傻眼了，因为记得几年前学习FSMT的时候，那时候好像时可以迁移共享权限的阿，微软还说过，推荐使用FSMT这个工具，鼎鼎大名的FSMT到底怎么了，国内也好多人写过文章，说FSMT可以迁移共享权限+NTFS权限，为什么到我这里不行了，我首先排查是否是我操作步骤的问题，排查步骤如下
1. 检查目标端执行FSMT迁移账户是否不具备权限，确认执行账户是来源端和目标端本地管理员组成员，确保账户对源共享具备读取权限，目的端具备写入权限
2. 验证是否是因为修改了共享名和磁盘位置，什么都不改，就用默认，还是不行
3. 验证是否是因为系统版本问题，因为有看到FSMT官方上面没有写到支持2012R2，只写到2008R2，尝试在2008R2上面安装FSMT，还是不行。
我开始去国外找一些文章，看看是否也有别人遇到过和我一样的情况，或者是关于FSMT不能迁移共享权限的说明
https://social.technet.microsoft.com/Forums/en-US/734e790d-a1fb-4571-8e02-9c7cb05d44b7/how-can-i-migrate-file-shares-permissions-from-one-volume-to-another-on-the-same-server?forum=winserverMigration
https://social.technet.microsoft.com/Forums/windowsserver/en-US/46d8d9db-8e21-498d-a998-6df2c8394364/how-to-migrate-share-and-share-permissions?forum=winserverMigration
还有这位老兄的博客
https://sysblogging.com/2015/12/29/how-to-migrate-windows-file-server-shares-with-ntfs-permissions/
竟然真的也有人说过FSMT不能迁移共享权限，而且还有的是权威人士，这太奇怪了，同样的工具，同样的步骤，为什么有的人做出来就有共享权限，有的人做出来就没有共享权限，这太奇怪了，我本想就这样发表，说明FSMT实测不能迁移共享迁移。
因为说实话，之前也有北京的老师向我问过，如何迁移共享权限，我推荐老师用FSMT，结果老师告诉我实际测试FSMT不能迁移共享权限，我当时心里一直很疑惑。
不过这次我还是决定再做一下尝试，实践出真理，我一定要写出实践验证过的东西，是就是是，不是就是不是。我这次换了个思路，我把加密文件，只读文件，隐藏属性文件，都删除了，想最后碰碰耗子，再试试。
结果，这次就通过了，把这些文件删了之后，再用FSMT迁移，NTFS权限+共享权限就都迁移过来了，处于追求真理的偏执心发作，我又想再叫叫真，看看到底是因为那个文件导致的，一般只读文件，隐藏属性文件，不会导致拷贝拒绝，我把只读和隐藏属性文件加回来，还是可以迁移NTFS权限+共享权限。
现在我基本可以断定就是加密文件导致的文件，当再次把加密文件拷贝到来源端文件夹中，复制文件过程依然会提示这个警告
实测结果，只要来源父共享文件夹下存在加密文件，或者父共享下面子文件夹里面存在加密文件，都会提示这个警告，一旦由于其中一个加密文件，导致产生警告，则整个父共享文件夹下面的共享权限都不能被迁移，根据测试结果来看，我推测在拷贝文件过程中，事实上FSMT在拷贝文件过程，同时会去拷贝验证源文件的NTFS安全设置和共享权限，并且这个过程应该会吧NTFS安全设置与共享权限获取下来，如果其中因为加密文件而拒绝访问，则会导致共享权限获取中断，导致下一步共享权限无法被apply。根据国外朋友的文章显示长文件名也会导致发生中断，所以对于长文件名的文件名也要格外小心，小心被中断 :)
当我把加密文件拿掉，再次执行迁移，发现拷贝过程一次就会通过，不会产生警告，然后正常执行下一步，就会正常将NTFS权限+共享权限全部apply
【点评】
功能实现: ★★★★
专业性: ★★★★
性能： ★★★★
易用性: ★★★
说起来，本来觉得FSMT的部分应该是最简单最容易最顺利的，没想到会遇到这么多的波折，遇到的问题也没找到相关的文章，幸运总归还是自己找到了问题所在，哈哈
点评一下，其实这次实测下来我认为FSMT还是有一定的缺点的
1. 对于父共享下存在的子共享，嵌套支持不是很好，假设我只需要迁移其中一个子共享不行，只能连带着父共享一起迁移，其它工具则没有这个问题。
2. 会由于单个文件的拒绝访问而导致整个共享权限迁移失败，当发现这个问题的时候我还是比较奇怪的，怎么会有这样的问题，之前xcopy和wsmt，也是遇到加密文件会拒绝访问，但是xcopy可以有参数来设置，遇见拒绝访问要跳过继续后面的，wsmt也会自动跳过，到了FSMT这里则会因为一个加密文件的拒绝访问而导致整个父共享权限迁移失败。
总结来看，如果你的环境中，主要是以多个父共享为主，不存在子共享嵌套，且可以接受加密文件不能被迁移，对于文件目录时间戳记没有要求，那么你可以选择使用FSMT方案，FSMT可以提供GUI操作画面，对于技术性要求不会过高，同时可以提供相对完整漂亮的报告，这是它的优势。
工具：注册表导入
在NTFS权限迁移验证结尾我们大胆讨论了NTFS ACL列表到底存放在那里，也讨论了如何去备份还原这个ACL，在共享权限验证的最后，我们再来看下共享权限到底存在哪里呢
根据笔者的基础学习，得知Windows共享权限存在注册表中，如下位置
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\Shares
打开路径可以看到当前机器上面的所有共享
点击Security项，可以看到对应共享的权限设置，都保存成了注册表得一个个二进制值
当前目标服务器2012R2上面E盘为空，一会我们用RoboCopy命令将03FS IT共享文件夹内容+权限复制过来
权限添加共享权限Jack为更改，mike共享权限为读取，NTFS权限 mike具备完全控制权限，Jack具备只读权限
运行Robocopy迁移命令
robocopy \\192.168.1.3\it e:\it /e /efsraw /copyall
什么鬼？我大RoboCopy也因为加密文件无法迁移了？
去掉 /efsraw参数，还是不行，我的天啊
将源文件夹里面的加密文件删除试试
删除加密文件后，再次执行robocopy，成功了
但是老王怎么能允许这样的事情发生，上面说行，下面忽然就不行了，于是排错，最终得知，是因为共享目录权限导致的问题，我现在在目标端的执行账户是mike，mike对来源端it文件夹NTFS权限具备完全控制，对目的端也具备写入权限，but！对于共享只有读取权限，这样是肯定不行的， robocopy如果要迁移加密属性文件，目的端的执行账户必须要求对于共享目录具备更改权限
将mike加入成为到来源共享更改权限
再次执行robocopy \\192.168.1.3\it e:\it/e /efsraw /copyall，发现加密文件可以被迁移过来了，有朋友可能会问，唉，那之前的xcopy，wsmt，fsmt是不是也是因为这个原因导致加密文件不能迁移阿，实测之后发现，对于xcopy，wsmt，fsmt即使把执行账户加入到共享权限完全控制也没有用，真正支持加密属性文件迁移的工具，只有robocopy。
可以看到这回NTFS权限，文件属性，时间戳已经完整的被迁移了过来
我们将03FS上面的注册表项
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\Shares
导出成为03fs.reg，拷贝到2012FS上面
点击reg文件进行导入
导入完成后来到2012注册表路径下面，可以看到03上面的共享和共享权限已经存在
如果源共享文件夹迁移过来之后存放路径保持不变， 则不需要修改， 如果迁移过来之后存放路径变了，则需要自己在这里修改注册表，笔者把其它共享都删除了，只保留IT，修改IT的目录为E:\it，修改完成点击确定，关闭注册表编辑器
再次打开IT文件夹，可以看到共享权限已经经过注册表导入进来
通常都会立刻看到，有时可能要等几分钟之后才能看到权限，不要着急，如果注册表没有输入错误，一般几分钟之内再打开共享就可以看到共享权限
有一个小地方，导入注册表之后，虽然文件夹上面已经显示被共享，但是fsmgmt.msc里面有时候可能还是看不到的，但不影响网络共享访问。
微软相关KB https://support.microsoft.com/zh-cn/kb/125996
遇见这种情况重启之后就可以看见了 ，大功告成！
NTFS权限迁移各工具应用场景
对于迁移需要有更多控制，例如需要控制那些文件类型文件需要进行迁移迁移，那些日期后的文件需要继进行迁移，进行一些基本厂家的筛选控制，同时希望复制迁移过程能够比资源管理器有部分提升，仅需要迁移文件内容+NTFS权限，可以接受加密文件不能被迁移，父目录时间戳丢失，可以接受命令行操作，适用方案 Xcopy
对于迁移过程希望得到比Xcopy更高要求的灵活管理控制，希望获得迁移时得到较高的性能，希望迁移时能够完整迁移文件内容+NTFS权限+文件及目录的安全属性及时间戳，希望迁移过程能够输出完整过程及详细log，可以接受命令行操作，适用方案 RoboCopy
对于希望定时备份文件服务器ACL权限列表，希望单机服务器更换磁盘保存NTFS ACL权限表，希望跨服务器还原NTFS ACL权限列表，希望深入研究NTFS ACL内容，可以接受加密文件不能被迁移，文件目录时间戳丢失，可以接受命令行操作，适用方案 Icacls
当跨服务器还原ACL权限列表时，Icacls可以和xcopy，robocopy进行配合，或者自己资源管理器手动复制，再用Icacls还原ACL权限， 当和robocopy配合可以实现robocopy拷贝文件内容+时间戳+加密文件，Icacls去还原NTFS ACL权限。
NTFS+共享权限迁移各工具应用场景
对于需要将文件跨服务器迁移过程进行加密，希望通过来源服务器与目标服务器配合来完成迁移，希望获得完整详细的迁移输出，希望在迁移2003服务器系统AD DNS DHCP CA WSUS到2012R2顺带迁移文件服务器，仅需要迁移文件内容+NTFS权限+共享权限，可以接受加密文件不能被迁移，顶级父目录时间戳丢失，可以接受命令行操作，可以接受在来源端机器安装迁移工具，适用方案 WSMT
对于文件服务器迁移过程需要通过图形化界面完成，希望获得完整友好的迁移报告，希望可以将迁移过程分步骤，一步一步进行确认处理，可以接受加密属性文件不能被迁移，一旦迁移加密属性文件将导致共享权限迁移失效，可以接受所有共享下面文件目录时间戳全部丢失，可以接受迁移父共享下的嵌套子共享，必须迁移整个父共享，适用方案 FSMT
对于迁移过程希望获得更好的筛选控制，希望复制迁移过程性能比资源管理器复制有部分提升，可以接受迁移过程要遵循严格的命令规范，仅需要迁移文件内容+NTFS权限+共享权限，可以接受加密文件不能被迁移，顶级父共享目录时间戳丢失，可以接受命令行操作，可以接受使用两个不同的命令完成迁移，适用方案 Permcopy+Xcopy
对于迁移过程希望获得最好的灵活控制，希望复制迁移过程性能比资源管理器复制有大幅提升，希望迁移时能够完整迁移文件内容+NTFS权限+文件及目录的安全属性及时间戳，希望迁移过程能够输出完整过程及详细log，可以接受迁移过程要遵循严格的命令规范，可以接受命令行操作，可以接受使用两个不同的命令完成迁移，适用方案
Permcopy+Robocopy
对于希望定时备份文件服务器共享权限，希望更换共享文件夹磁盘，希望跨服务器还原共享权限，希望深入研究共享权限注册表内容，希望可以还原大批量的共享权限，可以接受在注册表中操作，适用方案
共享权限注册表导入
当跨服务器还原共享权限时，共享权限注册表导入可以和Xcopy， Robocopy进行配合，或者自己资源管理器手动复制，再用注册表导入还原共享权限，当和Robocopy配合，可以实现Robocopy拷贝文件内容+NTFS权限+时间戳+加密文件，导入共享权限注册表还原共享权限。,
在文章要结尾这两天一直在思考，这篇文章结尾总结到底要写点什么才合适呢，想来想去，还是决定按照上面场景式的方式写出来，什么样的场景，什么需求，适合用什么方案。
在比较典型的共享权限+NTFS权限迁移场景下，如果希望迁移时间戳和加密文件，那么笔者推荐你直接选择Permcopy+Robocopy方案，如果只是有迁移NTFS权限+共享权限的需求，那WSMT，FSMT，permcopy+xcopy，注册表导入你都可以去选择，单纯的NTFS权限迁移也是，有很多种方案，随心使用，朋友们如果要采用本文提到过的工具进行迁移，请一定仔细看过笔者的验证步骤，里面提到了近乎所有需要注意的地方。
说起来这篇文章从周一开始写，断断续续一直写到周六，也算是笔者对自己的一个交代了，话说最近一年的拖延症越来越严重，很多时候很多想法，但是却都没有实施下去，这次是下定决心了，一定要写完，磨炼一下自己的意志，人有时候就是要逼一下自己是吧。
其实说实话，写这篇文章，还是遇到很多坎坷的地方的，几乎每个迁移工具都遇到问题，想过放弃，但是最终还是坚持写下去，虽然实验验证真理的过程不太太平，但是验证过后得到的确是收获，不论是意志上还是技术上。
为什么要写这篇文章呢，一个原因是因为微软自身的文件服务器迁移工具有不少，但是我却从来没看到一篇文章，完整对比和试验过每个工具的。即便是有文章写了，但是很多关键的点，我也没有看到人写过。
所以我决定写一篇这样的文章，尽量涵盖所有常见的微软文件服务器迁移工具，来告诉大家什么场景下应该用什么方案，什么能实现，什么不能实现，不要模棱两可，不要一带而过，我们就来实际一步一步验证，在实际做的时候到底会遇见哪些问题，应该如何去解决，解决不了应该选什么方案，有哪些一定要规避处理的设置，如果不处理会出现什么错误，为即将做微软文件服务器迁移和正在做微软文件服务器迁移的朋友们查看，我认为这篇文章写得是有意义的。
最后希望看本人文章的各位朋友们，都能找到自己所需要的方案，也希望各位做技术的朋友都能变得越来越专业，一项技术一定要如果亲自验证过，或者亲眼见过 ，再告诉别人到底行不行，面对生活可以顺其自然 ，随缘随心，但是面对技术一定要精益求精，较真一些，希望能看到更多较真的文章出现 J
本文出自 “一个倔强的孤岛” 博客，请务必保留此出处http://wzde2012.blog.51cto.com/6474289/1874132
标签：robocopy permcopy fsmt 共享权限注册表
原文地址：http://wzde2012.blog.51cto.com/6474289/1874132
