谨以此文 记录一次悲催的SharePoint 迁移
最近遇上一个SP迁移 ，经过简单的交谈发现迁移工作并不是特别复杂，两个网站集，有几个自定义

的解决方案当前版本是 SharePoint 2013 不带SP1 打算迁移到SharePoint 2013
当我听到这个想法的时候颇为震惊，为毛会有如此需求 如果是因为要换机器也没有必要做迁移，我

们可以向场中添加新的服务器， 然后删除废弃的服务器 并且断开场连接。
带着如此疑问我看了下原始环境，不看不知道一看吓一跳当前只有一个服务器，该服务器即承担SQL

，SharePoint 前端，以及SharePoint 应用程序 典型的All in One （经检查该场非独立安装）而且该

场与WF 2013绑定，Office Web App 绑定 ，万幸的是 没有做其他BI 组建的关联，仅有的几个解决

方案都有原始Wsp 文件。
关于服务应用程序
BI 方面没有使用，可以考虑放弃迁移
搜索已经使用 存在索引分区 必须要迁移 迁移前仔细看好 拓扑以及索引分区 而且该搜索拓扑全部组

件均在一台机器上
SSS（即安全凭据存储） 没有使用，可以考虑放弃迁移
UPS （用户配置文件同步） 正在使用，且同步出现问题 ，而且 我的网站宿主 与 名为SP.xxx.cn的网

站集同属一个web应用程序，该内容数据库已经到达300G 以上
经沟通可以不迁移个人站点，用户配置文件均可清空 。
关于表单，没有任何自定义的表单在场中存在 InfoPath Forms Services 也未使用
关于web应用程序
虽然场中存在两个web应用程序，但真正使用的仅有一个，故剩余的那个无需迁移，
而且均未使用SLL 所以我们在迁移时候就可以无视证书的事情 否则连证书要一起迁移过去
据沟通结果该web应用程序早已废弃不用，但一直没删。
关于传入传出邮件
场，web应用程序，站点均已经使用，且SMTP配置数据有记录
关于Web.Config
好吧 我实在无法确切的得知到底都修改了什么，我也不打算得知 我们可以用一个文本对比工具尽可能的

还原。我带着为什么要迁移的疑问进行沟通，沟通结果出乎意料的简单，粗暴，因为太慢了
因为UPS 同步问题。

So 根据如上所述 我们得出一个结论 SharePoint 本身没有进行迁移的必要 响应慢的原因应该是 SQL数

据库磁盘IO 过低的原因(他们在一块机械盘上完整的这一切，包括OS,SQL Server ，SharePoint) Shit

！！！（Sorry 原谅我爆粗）
下面我们列举下应该都要迁移什么
1 场要迁移 （别问我为什么要迁移场）
2 web 应用程序
3 服务应用程序
4 自定义解决方案
5 WebApp 绑定 工作流绑定
6 Web.Config
或许我想做的事情并不符合诸位看官迁移的概念，
为什么这么说呢 因为我在做的时候并没有创建新场，而是直接把场配置数据库迁移到另外一个独立

的SQL Server 上 并且用一台全新安装的SharePoint 做一个扩展场的动作 然后顺理成章的把一个 ”迁移”

 的动作变成一个移动 虽然表面看起来 这是一次迁移实际上我们仅仅使用了一个叫做 移动数据库，扩展场

的做法.下面我们将简单的说下几个重点问题
首先准备出一个SQL，我们简称他为SQLA 该SQL的版本不能低于原始SQL Server 的版本，且服务账户

 管理账户，账户权限，身份验证与之前的一样（如果你之前的场中存在RS等集成模式请不要在该服务器安装）
一个全新安装并未加入场的SharePont 服务器我们简称他为SPA，（安装账户等与之前一样）

首先 移动数据库，(由于未在原始环境截图，所以我们在实验环境重现该场景)
在这里也许我们会纠结下到底先移动那个数据库，但是我第一个移动的是场配置数据库
我们先简单的说下如何移动场配置数据库
首先在原始场中 关闭除去配置数据库之外的机器 包括App，WFE 我们要断开场与SQL的连接（该动作

仅适合移动配置数据库 其他库无需此步骤）
然后在数据库服务器上执行一个叫做 分离的动作 如下图

也许你也已经看到 当前数据有19的连接 我们可以选择删除连接然后让他分离 ，但是我们还是稳妥点

的好 ，由于一般迁移升级类的动作都不会在 工作时间进行，SO 大胆的把他们关掉把
数据库分离后 拷贝原始MDF，LDF文件到新的SQL Server 上 即SQLA 请注意你需要有SQLA服务器

的本地管理员权限 并且在SQL 拥有db_owner 固定数据库角色 权限，如果你不清楚的话 就把你的SQL

 管理员账户暂时加入本地管理员组把，或者找DBA去，同时附加该数据库 。
此后开启场中任意服务器，
执行如下动作 （以下动作适用于移动全部数据库 具体到特别部分我们会进行详细说明）
关闭任何已经打开的Cmd ，PowerShell 窗口，场中网站以及管理中心窗口 请务必谨记
首先停止服务器的如下几个服务
SPAdminV4 ，SPTimerV4  ，SPTraceV4，SPWriterV4，SPSearchHostController  ，W3svc
然后IISreset /stop
这样我们就停止场
当然对于我来说我更喜欢用命令来完成这些事情
脚本如下 打开全新的PowerShell 窗口运行如下命令
Get-Service SP* |Stop-Service -Force
Stop-Service W3svc
iisreset /stop
虽然我的脚本使用 Get-Service SP* 获取SharePoint 相关服务，但是会有误停止的服务，比如软件

保护，打印服务 好吧 我承认这都不是问题。
（如果你迁移的是其他非配置数据库 请在停止如上服务之后对原始数据库进行分离 附加到新的SQL

Server 实例 我们建议再这时候对全部的数据库做一个备份以防不测 如果出现问题 我们可以通过还原

数据库的方式 继续使用源场）
脚本执行完成没有错误之后 管理该窗口
打开新的SharePoint 命令管理工具 如下图

 
好吧 我承认我一向更喜欢使用ISE，那么你可以打开ISE 运行 Add-PSSnapin * 来加载SharePoint

管理单元 当然这种做法也会加载其他的管理单元，好吧 我还得承认这都不是问题
我们运行 Get-SPDatabase 来获取数据库 注意区分你要移动的数据库 记录下ID 如下图

由于我现在迁移的是一个叫做 配置数据库的东西 So
我们运行下面的命令
$1 = Get-SPDatabase fe15dfae-2485-47b4-a77f-c44d6426a0a2
我们将该数据库对象放入一个变量
$1.ChangeDatabaseInstance("win206.ilync.cn")                            
调用该对象的ChangeDatabaseInstance 方法来修改 其新的数据库服务器为SQLA 请注意建议写FQDN
如果使用SQL 镜像
还需要调用Failoverserviceinstance 来填充镜像连接名称
官方文档请参考
http://technet.microsoft.com/zh-cn/library/cc512725(v=office.15).aspx
然后在没有红色错误的情况下运行
$1.Update()                                                                                    
调用该对象的Update() 方法以使修改生效
如果在ChangeDatabaseInstance 时候 提示你更新冲突 没关系 关掉窗口 重新运行
此后
将刚才停止的服务启动 并且执行IISreset
到此 迁移配置数据库完成（至此 迁移非配置数据库也到此完成）
然后我们以此把全部数据库附加到SQLA 将全部数据库迁移到SQLA上
由于 此时我们移动了配置数据库 原始服务器将无法访问管理中心
这就是为什么我们要准备一个新的SharePoint 服务器并不将其加入场的原因
我们使用SPA 加入场 请注意 加入的场为配置数据库所在的SQLA 服务器 （这个动作相当于我们复制

了一个场）
然后完成任何加入场动作 ，记得将该计算机作为管理中心宿主 加入完毕之后 将原始的网站访问IP 或者

解析修改为新的服务器 即SPA然后 用你能想到的一切办法在SPA 上还原任何Web.Config更改。
同时在在我们复制出来的场中删除之前场中的全部服务器，同时在SPA上启动一切你需要的服务
至此 我们完成了场的迁移 到此步骤 我们的解决方案以及WebApp绑定都无需重新配置
或许你可以开始测试下一些站点的访问是否成功 但是不要有其他动作

下面我们来看看Web应用程序的事情
事实上 经过我们上面的动作根本无需再过多的关心Web应用程序 因为一切都在 就好比科幻片一样 我

们的思维仍在只不过换了个躯壳，但是我们的身体可能不太适应思维(各种科幻大片都是一样的道理)所

以我们下面将开始让身体适应思维，我们要做如下的这些动作
可能我记录的并不完整，也许你的环境中有更多需要进行修改的 总之尽可能的仔细些
将场电子邮件地址进行修改该 在IIS上重新绑定SSL 证书，如果需要的话你还需要重新在SPA 上修改注

册表以关闭IIS LoopBackCheck，还原之前任何依赖的DLL 等等一切你自定义的修改。
还原应用程序池的任何修改 回收配置 进程数，内存等请尤其注意承担我的网站宿主的Web应用 的应用

程序池千万要检查 加载用户配置文件 属性为True
关于服务应用程序
大部分的服务应用程序你无需担心 你只需要在新的服务器上启动相应的服务即可
这里我们重点说几个需要关照的家伙
User Profile Service Application
把UPS 说成微软最坑爹的服务我相信不算过分 MSDN,TechNet 上到处充斥长时间正在启动，无法启

动，等等
这里有几个小窍门
1 在首次启动以及停止后在启动  User Profile Synchronization Service 这个服务时候
首先将该服务对应的服务实例托管账户加到本地管理员组 （在该服务启动后可将该用户从本地管理员组

删除 服务器重新启动不影响）
2 对该账户在本地策略中授予如下权限
  作为服务登录，允许本地登录，以操作系统方式执行 然后你可以选择重启SPTimerV4 服务但是我更建议

 重新启动要承担同步实例的服务器
3 检查服务应用程序的相关属性
 使用 Get-SPUserProfileServiceApplication 命令获取场中的 User Profile Service Application

（该命令非官方 由本人自定义开发目前尚不具备发布条件，部分已经拿到测试版本的同学感谢你们的测试

反馈）然后检查属性
NetBIOSDomainNamesEnabled 该属性在特定条件下需要修改下面列出该属性对应的条件
False 该应用程序使用的数据库实例为FQDN 非NetBios 名称 （这也是为什么我希望大家写FQDN的原

因避免不必要的麻烦）
True 该应用程序使用的数据库实例为NetBios 名称
如果你当前属性不满足以上需求 请做相应修改 然后调用Update()方法更新修改
4 在活动目录中委派该用户 复制目录更改，复制目录所有更改项
此后启动该服务 稍等片刻应该可以启动 如果还不能启动
请分别调用以下方法
ResetSynchronizationDatabase()                                         
ResetSynchronizationMachine()                                         
分别重置同步数据库以及同步实例 然后重新启动相应同步实例
希望这几个窍门能够帮到你。

Search Service Application
由于本次我们的迁移搜索应用程序只有一个非常简单的拓扑 所以我们无法演示在大型搜索拓扑时候

的样子 在本文的后半部分将会说明拓扑中组建分布在多台计算机即一个中型服务器场迁移的动作

下图就是搜索应用程序的样子

 
呵呵 的确很悲催 但是不要紧
首先启动该服务器的搜索服务实例
Get-SPEnterpriseSearchServiceInstance                                   

 -Local|Start-SPEnterpriseSearchServiceInstance                     
稍等片刻如下图等该服务启动

 
然后 记住这个服务应用程序的名称 以及所在数据库名称，以及所在应用程序池
然后放心的把这个已经挂掉搜索应用删掉不要删除数据库，如果你已经删除了数据库没关系从之前

场中拷贝一份即可（因为这个时候之前的场还是可以继续使用的）

然后输入命令
$ins =Get-SPEnterpriseSearchServiceInstance  -Local                            

获取该服务器的搜索服务实例
Restore-SPEnterpriseSearchServiceApplication -Name "Search Service" -DatabaseServer

 win208.ilync.cn -DatabaseName Search_Service_DB_6fa66ecda3cc412884bc40f5af123db4

-AdminSearchServiceInstance $ins -ApplicationPool SeachCenterPool 
还原该服务应用程序 稍等片刻 全部组件应该都启动了（如果你需要扩展搜索拓扑那么现在是最好的时机）
此后创建该服务应用程序代理 并且加入相关代理组就不再多说了
此时搜索应用应该是下面的样子

 
可搜索为0 显然是无法搜到任何东西。。你有两个选择 重新对内容源进行爬网
Restore-SPEnterpriseSearchServiceApplicationIndex -SearchApplication $1 -AllReplicas -AllowMove C:IndexComponent                                                                                                                                 
或者使用该命令进行还原

关于服务实例
搜索服务
不得不说这个也是个非常讨厌的东西
需要注意的只有一点如果你需要修改搜索拓扑那么请先确保搜索相关服务启动
分布式缓存
这个服务也是十分让人纠结一个搞不好就要出问题但是相对比较好解决
在我们加入新的SPA 后有一定的可能性SPA 上的分布式缓存服务未能正常启动
系统非常友好的提示你

 
不必惊慌 事情是非常好解决的，仅仅需要几个命令即可
我们要做的就是删除这个实例然后重新安装这个实例
同时提醒各位同学
在删除任意服务器前请停止该服务器上的分布式缓存服务实例再进行删除
否则新加入场的服务器上分布式缓存服务启动不成功的概率近乎100%
首先我们要获取该服务实例
$1 = Get-SPServiceInstance -Server win206 |where {$_.typename -eq "分布式缓存"}
我们可以使用这个命令获取该实例
$1.Delete()                                                                                                                    
然后调用该实例方法 Delete()删除之
Add-SPDistributedCacheServiceInstance                                                                    
再次安装该服务 

 
再次查看该服务 一般情况下都会启动了，如果还不行的话那就删掉，重新启动该实例所在服务器再来一次
好了到此为止本次的迁移基本告一段落，后面的事情就是检查组件正常使用了。同时源场可依然正常使用

 ---本文档由联科教育（http://www.iLync.cn）田梦博 原创提供，如有问题请电话：021-60745131---

本文出自 “iLync” 博客，请务必保留此出处http://ilync.blog.51cto.com/6203086/1583148

记录一次悲催的SharePoint “迁移”