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

记录一次悲催的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的连接(该动作仅适合移动配置数据库 其他库无需此步骤)

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

好吧 我承认我一向更喜欢使用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来填充镜像连接名称

官方文档请参考

(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

获取该服务器的搜索服务实例

勇士面前无险路。

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

相关文章:

你感兴趣的文章:

标签云: