共享文件夹与本机文件夹的区别（共享文件夹从2012R2到）

网管小贾 / sysadm.cc

公司的文件服务器系统稳定地跑了5年，期间没有发生过什么大问题，直到有一天它要搬家了。

虽然平时悉心管理，但是日久天长共享文件夹渐渐变得结构层次复杂，人员权限又交错叠加。

牵一发而动全身，如果原原本本将共享文件夹复制照搬到新服务器上，势必就要重新配置权限、设定配额及过滤器等等，费时费力想想都可怕。

毛主席教导我们，世上最怕认真二字，活还是得干，还要干得漂亮。

于是我又去翻阅了大量资料，找到了传说中的神奇工具 Windows Server 迁移工具 。

请恕我孤陋寡闻了，这件神器早在 Windows 2008 时代就已经存在了，它基于 PowerShell 平台，再具体的我也说不太清楚，总之它可以帮我们迁移服务器各种功能，其中就包括共享文件服务。

网上可查到的资料基本都很零散，单独参考任何一篇都很可能掉进不知多深的坑洞里。

经过一番苦苦战斗，现在我将详细说明整个共享文件的迁移过程，其中当然也包括我遇到的那些坑，最后我也会来个总结，帮助小伙伴们最终理清并概括操作思路。

环境背景，将共享文件夹从旧服务器完美地迁移到新服务器上。

旧服务器：Windows Server 2012 R2

新服务器：Windows Server 2016

共享文件夹：D:\sysadm.cc

一、安装 Windows Server迁移工具

安装非常简单，点击 服务器管理器 中的 添加角色和功能 ，然后选中 Windows Server 迁移工具 安装即可。

我在新旧两台服务器上都安装了迁移工具，不过请小伙伴们注意，这里其实埋了个坑，具体稍后会说。

二、打开防火墙端口

迁移工具在两台服务器之间传输通讯肯定要通过某些端口来建立连接。

根据官网的介绍，是需要分别打开源服务器与目标服务器的 7000 端口。

不过经过我测试，似乎目标服务器需要开通 7000 和 7001 两个端口，也可能是不需要 7001 ，总之保险一点我开通了两个。

手动添加或通过命令添加都可以，参考命令如下：

netsh advfirewall firewall add rule name= "Windows Server 迁移工具" dir=in action=allow protocol=TCP localport=7000

三、迁移服务器本地用户和组

如果共享文件夹中含有服务器本地用户或组的权限，那么应该先在目标服务器上完成这些用户和组的迁移。

换句话说，旧服务器上有非域的本地用户和组，那么应该保证目标服务器上已经创建了这些用户和组。

因为在后面的迁移过程中，文件夹的权限列表是一起迁移的，所以要事先保证服务器上都能正常读取到这些本地用户和组的信息。

举个例子说明，就是旧服务器上有个用户叫 sysadm ，那么新服务器上就应该建个用户也叫 sysadm ，两头保持一致。

四、迁移命令

我们现在用到的迁移命令就两个，一个叫作 Send-SmigServerData ，用来发送数据，另一个叫作 Receive-SmigServerData ，用来接收数据。

这两条命令就像一对要好的兄弟，发送端在源服务器，接收端在目标服务器。

两个兄弟之间要拉上手建立连接才能传输数据，而拉上手之前的等待时间是 300 秒，也就是 5 分钟。

也就是说，不管兄弟俩谁等谁，他们俩都事先商量好的，只等对方 5 分钟，之后就过时不侯了。

一般情况下等个人 5 分钟也就抽根烟的功夫，通常这时间也差不多够用了。

不过嘛总有一些特殊情况，比如闹肚子上个厕所啥的，可这时间就延长了，咋办？

没事儿，其实这个等待时间还是可以修改的，不行我就多等你一会儿呗。

按以下内容修改注册表即可修改等待时间（连接超时时间）。

注册表项: \HKLM\Software\Microsoft\ServerMigration 注册表键: MaxConnectionTime (REG_DWORD) 键值: 1 至 3600 间取值 (连接超时时间，单位秒，大于 3600 则按 3600 取值)

多等一会儿不是问题了，下面来看看这俩兄弟怎么干活的。

1、接收端命令

Receive-SmigServerData -Password <SecureString> [<CommonParameters>]

为什么先说接收端，因为它真的超级简单，别看命令语法有点吓人，其实直接输入命令本身就可以用了。

在目标服务器上输入 Receive-SmigServerData 回车，然后再输入通讯密码后等待发送端动作就可以了。

2、发送端命令

Send-SmigServerData [-Force] [-Recurse] -ComputerName <string> -DestinationPath <string> -Include <All | Data | Share> -Password <SecureString> -SourcePath <string> [-confirm] [<CommonParameters>]

发送端语法这么复杂，是不是也很吓人呢？

其实也不难，举个例子就明白了。

# 将文件夹 D:\sysadm.cc 打包发送到服务器 ServerX 的相同路径上 Send-SmigServerData -ComputerName ServerX -SourcePath D:\sysadm.cc -DestinationPath D:\sysadm.cc -Recurse -Include All

• -ComputerName 目标服务器名称
• -SourcePath 源服务器上的文件夹
• -DestinationPath 目标服务器上的文件夹（最好和源服务器上一致）
• -Include 包含文件夹的哪些属性，数据、共享还是全部
• -Recurse 拷贝所有子文件夹，如果没有这个参数，那么只有拷贝根文件夹

输入命令后和接收端一样需要提供通讯密码，密码通常为6位以上。

好了，基本上了解这些就够我们用了，下面开始才是重中之重哦！

五、迁移过程及填坑1、尝试迁移

首先，我在目标服务器上打开 Windows Server 迁移工具 。

服务器管理器 > 工具 > Windows Server Migration Tools > Windows Server 迁移工具

在出现的迁移工具窗口中输入 Receive-SmigServerData 并回车，然后输入6位以上密码并回车。

小伙伴们要注意，此处必须是以管理员权限运行的。

接收端程序已经开始运行，等待发送动作了。

我们回到源服务器上，同样找到并执行 Windows Server 迁移工具 。

输入前面介绍的发送命令 Send-SmigServerData 并回车，然后同样输入与接收端相同的密码并回车。

这时本想着应该开始迁移动作了，没成想居然报错了。

这里只放了一张接收端的图，但两边的错误出奇的一致，都说迁移工具的版本不同。

源服务器与目标服务器操作系统不同，前者是 2012R2 ，后者是 2016 ，迁移版本不同可以理解，那么这个问题怎么解决呢？

原来官方有相关的解决方法，毕竟从低版本系统迁移到高版本系统也是常态啊。

方法很简单，就是在高版本一侧的系统中制作并生成低版本适用的迁移工具，然后在低版本系统一侧运行生成的迁移工具即可。

明白，具体怎么做？

2、生成低版本迁移工具

我们到目标服务器上，也就是 2016 系统那台服务器上，在 Windows Server 迁移工具 所在的文件夹中，有一个名为 SmigDeploy 的程序，它可以完成制作低版本迁移工具的任务。

具体命令可参考如下：

cd C:\Windows\System32\ServerMigrationTools SmigDeploy /package /architecture amd64 /os WS12R2 /path C:\sysadm.cc

第二条命令只要记住两点，一个是 /os 后面是对应的低版本系统名称，另一个是 /path 将生成的文件放到哪个文件夹路径中。

我们现在的旧系统是 2012R2 ，所以 /os 后应该是 WS12R2。

如果是 2008 ，那么就应该是 WS08 ，以些类推。

制作生成的文件放在 C:\sysadm.cc 文件夹中，这个文件夹可以随意指定。

我知道明明是你懒，可你偏偏说是忙，所以我将迁移工具打包放在这儿，你们下载后可以直接用上了。

2016 适用于 2012R2 的迁移工具（3.98M）

下载链接：https:///s/1Zqt66It2NMEjKvvmjui8bw

提取码：<关注公众号，发送 000818>

3、再次尝试迁移

将前面生成的低版本迁移工具拷贝至源服务器上。

此处需要说明一下，文件夹中有两个文件，执行哪一个都可以，只是务必注意要以管理员权限运行。

打开 ServerMigration.psc1 后还是按之前的迁移命令执行，可是却仍然出现版本不一致的错误。

另外，执行 SmigDeploy.exe 则会闪退。

有时在迁移动作一开始还会出现程序崩溃的问题。

这都是些什么坑爹玩意啊？

4、再次调整，重新出发

明明已经使用了新生成的低版本工具，为何还会出现一系列的问题，到底哪里出错了？

求助网络后才发现，其实是自己犯了一个低级错误，原来是因为最早先在源服务器上安装了迁移工具，其与新建的低版本迁移工具产生了冲突。

你说这叫啥事儿啊！

了解到这一点后我立马删除了源服务器上自带的迁移工具。

接着还是按之前的命令和操作步骤再次走一遍，结果顺利开启了迁移动作！

发送端正在加密并发送数据。

接收端则在接收和解密数据。

一切OK，接下来就是耐心等待迁移工作的完成。

此外，网上有说迁移工具只适用于数据量小于 100 GB 的情况，不过我这边尝试下来并没有这样的限制。

要知道如今的数据量往往会超过 100 GB 这个级别，当然也不排除是新版本系统已经支持大数据量传输的可能。

最后总结

就本文案例我总结精简一下整个迁移步骤和过程。

实现目的：

旧服务器（2012R2）---> 迁移共享到 ---> 新服务器（2016）

操作步骤：

1. 在目标服务器及源服务器的防火墙上分别开放 7000 端口。
2. 在目标服务器 Windows 2016 上安装迁移工具。
3. 在目标服务器上通过迁移工具命令 SmigDeploy 制作 Windows 2012R2 适用的低版本迁移工具。
4. 在源服务器 Windows 2012R2 上不要安装自带的迁移工具，而是拷贝第三步制作的低版本迁移工具。
5. 在目标服务器及源服务器上分别执行接收命令及发送命令，完成迁移过程。

以上便是我的共享文件服务的整个迁移过程，其中有不少大大小小的坑。

虽然踩坑是必然，但是网络上的相关资料，不是有点过时，就是非常零散，所以我写这些也算是将它们整理归纳在一起，避免遗漏操作过程中可能遇到的各种问题，进而方便给小伙伴们借鉴参考。

希望本文能给大家有所帮助，厚着脸皮多说一句哈，还请各位积极关注、点赞分享哦！

网管小贾 / sysadm.cc

,