記錄一次悲催的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
還原該服務應用程序 稍等片刻 全部組件應該都啓動了（如果你需要擴展搜索拓撲那麼現在是最好的時機）
此後創建該服務應用程序代理 並且加入相關代理組就不再多說了
此時搜索應用應該是下面的樣子
可搜索爲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
再次安裝該服務
再次查看該服務 一般情況下都會啓動了，如果還不行的話那就刪掉，重新啓動該實例所在服務器再來一次
好了到此爲止本次的遷移基本告一段落，後面的事情就是檢查組件正常使用了。同時源場可依然正常使用