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

最新推荐文章于 2021-08-04 13:36:21 发布

weixin_33860528

最新推荐文章于 2021-08-04 13:36:21 发布

阅读量159

点赞数

文章标签：数据库运维操作系统

原文链接：http://blog.51cto.com/strikene/1582043

版权

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

谨以此文记录一次悲催的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 绑定工作流绑定

6Web.Config

或许我想做的事情并不符合诸位看官迁移的概念，

为什么这么说呢因为我在做的时候并没有创建新场，而是直接把场配置数据库迁移到另外一个独立的SQL Server 上并且用一台全新安装的SharePoint 做一个扩展场的动作然后顺理成章的把一个 ”迁移”的动作变成一个移动虽然表面看起来这是一次迁移实际上我们仅仅使用了一个叫做移动数据库，扩展场的做法

下面我们将简单的说下几个重点问题

首先准备出一个SQL，我们简称他为SQLA 该SQL的版本不能低于原始SQL Server 的版本，且服务账户管理账户，账户权限，身份验证与之前的一样（如果你之前的场中存在RS等集成模式请不要在该服务器安装）

一个全新安装并未加入场的SharePont 服务器我们简称他为SPA，（安装账户等与之前一样）

首先移动数据库，(由于未在原始环境截图，所以我们在实验环境重现该场景)

在这里也许我们会纠结下到底先移动那个数据库，但是我第一个移动的是场配置数据库

我们先简单的说下如何移动场配置数据库

首先在原始场中关闭除去配置数据库之外的机器包括App，WFE 我们要断开场与SQL的连接（该动作仅适合移动配置数据库其他库无需此步骤）

然后在数据库服务器上执行一个叫做分离的动作如下图

也许你也已经看到当前数据有19的连接我们可以选择删除连接然后让他分离，但是我们还是稳妥点的好，由于一般迁移升级类的动作都不会在工作时间进行，SO 大胆的把他们关掉把

数据库分离后拷贝原始MDF，LDF文件到新的SQLServer 上即SQLA 请注意你需要有SQLA服务器的本地管理员权限并且在SQL 拥有db_owner 固定数据库角色权限，如果你不清楚的话就把你的SQL 管理员账户暂时加入本地管理员组把，或者找DBA去，同时附加该数据库。

此后开启场中任意服务器，

执行如下动作（以下动作适用于移动全部数据库具体到特别部分我们会进行详细说明）

关闭任何已经打开的Cmd ，PowerShell 窗口，场中网站以及管理中心窗口请务必谨记

首先停止服务器的如下几个服务

SPAdminV4 ，SPTimerV4 ，SPTraceV4，SPWriterV4，SPSearchHostController ，W3svc

然后IISreset/stop

这样我们就停止场

当然对于我来说我更喜欢用命令来完成这些事情

脚本如下打开全新的PowerShell 窗口运行如下命令

Get-ServiceSP* |Stop-Service -Force

Stop-ServiceW3svc

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

关于服务应用程序

大部分的服务应用程序你无需担心你只需要在新的服务器上启动相应的服务即可

这里我们重点说几个需要关照的家伙

UserProfile Service Application

把UPS 说成微软最坑爹的服务我相信不算过分 MSDN,TechNet 上到处充斥长时间正在启动，无法启动，等等

这里有几个小窍门

1在首次启动以及停止后在启动 User Profile SynchronizationService 这个服务时候

首先将该服务对应的服务实例托管账户加到本地管理员组（在该服务启动后可将该用户从本地管理员组删除服务器重新启动不影响）

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"-DatabaseServerwin208.ilync.cn-DatabaseNameSearch_Service_DB_6fa66ecda3cc412884bc40f5af123db4-AdminSearchServiceInstance$ins-ApplicationPoolSeachCenterPool

还原该服务应用程序稍等片刻全部组件应该都启动了（如果你需要扩展搜索拓扑那么现在是最好的时机）

此后创建该服务应用程序代理并且加入相关代理组就不再多说了

此时搜索应用应该是下面的样子