微軟虐我千百遍——記一次比較漫長的TFS數據庫遷移

原由

七月三日早晨剛到公司，同事就跟我講TFS開始返回 TF30042錯誤，報告數據庫已滿。按照處理問題的第一直覺，我上bing的英文網站搜了一下，發現是部署TFS的時候使用的SQL Express限制致使的。因而就開始漫長的數據庫遷移之旅。

第一階段：自信滿滿

給整個開發團隊發了消息，通知TFS臨時中斷半小時到一小時。關停了TFS全部的相關服務，找到SQLExpress的數據庫文件，而後拷貝到數據庫服務器上。因爲數據庫文件比較大，拷貝大概花了半小時。因爲最近在思考怎麼制定一個比較好的發佈流程，在這個拷貝過程當中，把基本的發佈工具的設計肯定了下，還有點沾沾自得。拷貝完成後開始附加數據庫，結果SQL服務器提示現有數據的版本太高，沒法兼容。檢查了一下SQL Expres的版本，要比SQL 2008R2高個好幾十，隨手百度了下，也沒找到820版本對應的數據庫的發行版本號，一狠心決定部署下SQL 2016，正好能夠研究一下SQL 2016對結構化數據（json等）執行屬性查詢的功能。因而又開始了下載過程。又花了半個多小時，期間給團隊成員發了個延期通知，許諾下午一點鐘以前搞定。一邊等待下載，一邊繼續寫工具，雖然麻煩，可是一切盡在掌握。

第二階段：略有腹誹

終於下載完安裝鏡像，準備開始部署數據庫服務。可是安裝程序提示當前運行的服務器爲WIN SERVER 08R2，SQL 2016不支持。因而又開始着手準備兼容的WIN Server服務器環境。當時也沒有細想，直接就選用了WIN SERVER 2016。下載大概花了一個小時，慌里慌張的，中途還把語言包看成安裝文件下載下來了。中途去開了一個會議，回來的時候，已經下午三點鐘了，顯然的，給團隊的承諾已經無限延期了。因爲服務器有點久了，並且是在虛擬機上安裝，安裝過程持續了大概四十分鐘。而後部署數據庫服務、遷移數據庫文件。遷移完成以後，須要將TFS的數據庫綁定重定向。這裏有幾個作法：1：修改配置文件 2：使用TFS的配置工具，初始化當前配置，並從新配置數據庫。出於慎重考慮，選擇了第二種。參考：http://www.accentient.com/blog/unconfiguring-team-foundation-server-2013/

tfsconfig setup /uninstall:all

從新啓動TFS的配置管理器進行TFS配置。執行到數據庫這一步的時候，發現只能填寫一個host名稱，沒法提供登錄信息。因而開始了各類腦補：TFS默認配置了一個登錄身份信息？TFS使用了一個配置文件？TFS僅支持基於域服務器場的部署？好吧，鑑於微軟的方便使用、無腦點擊下一步的做風，最後一個可能性最大。仍是經過bing搜索了下，找到了確定的答案。參考：https://serverfault.com/questions/457006/how-to-connect-tfs-2012-with-a-remote-database-using-sql-server-authentication 以及 https://serverfault.com/questions/457006/how-to-connect-tfs-2012-with-a-remote-database-using-sql-server-authentication 。
心中雖然腹誹，可是還算是鬆了一口氣，畢竟簡單的集成域環境也還簡單。看下時間，已經五點半了，因而依然開始了無盡之旅。

第三階段：無盡的折磨

按照通常性套路，開始修改客戶機的dns，指向dc的ip，同時爲dc所在的服務器添加了一條host，防止一些亂七八糟的沒法訪問。點擊加域。5秒，15秒，30秒......沒法找到網絡路徑。雖然內心奇怪，可是仍是繼續bingstackoverflowserverfault，同時也象徵性的百度。而後不停檢查TCP/IP NETBIOS Service，檢查文件和打印機共享，檢查dns，檢查和禁用ipv6，檢查防禦牆防火牆例外，關閉、開啓防火牆，檢查hdcp，檢查ip，檢查ping。快馬加鞭的檢查了三四個小時，仍然無果以後開始自檢，首先查看window server的日誌，發現返回狀態碼53，而後檢查system windows debug下的日誌，發現net use 指令致使了53的結果碼。而後開始瘋狂的搜索與net use相關的，與53狀態碼相關的，與network path not found相關的資料，開始拿不一樣的服務器作對比實驗。最後發現，win server 2008r2的服務器都能成功入域，而win server 2016與win 10都沒法成功。開始推測時客戶機的問題，而後再一次對客戶機作了各類檢查，仍然無果。
對客戶機和服務器的行爲總結以下：

• 網絡通訊正常，進行入域請求的時候，能夠正常接收到401的認證相應
• 能夠提交身份認證信息，可是沒法成功認證，即便提供了錯誤的用戶名和密碼，也沒法獲得認證結果
• net use \host$IPC 指令沒法正常使用

期間好幾回想先放一放，可是每次都有一種錯覺，彷佛這個問題立刻就要解決了。等到實在困得不行的時候，已通過了凌晨一點，實在是乏的不行，加上還連累另一個同事一塊兒，遂做罷。

第四階段：柳暗花明

休息了一夜，信心又足了不少，決定繼續懟這個問題。仍是從net use這個指令開始，仍是以大量的搜索爲基礎。在搜索的過程當中，發現了net的另一個指令，net view。這個指令時用來查看共享文件夾的。共享文件夾這個名詞讓我忽然想到一件事情，之前公司爲了共享安裝包，在服務器上開了共享目錄。可是有一天win 10的機子所有沒法訪問了，而win 7和win server 2008r2都正常。猜想多是相同的緣由。因而開始搜索和收集這方面的資料。在一個論壇裏面，偶爾看到了一句評論，和SEP 12也就是證書有關。又忽然想起來，年中的時候爲了測試微信小程序，在服務器上安裝了證書（誤操做），同時升級了服務器的TLS版本.......或許你們覺得我立刻要發現了真相，走進了科學 ——其實否則，我以爲愈加頭大了，由於這裏的可能性太多了，因此我打算換個思路解決問題。
從net use和net view這兩個指令的執行狀況來看，應該是服務器的設置問題，致使了部分客戶機沒法訪問，因此我向換個服務器——也就是遷移DC。遷移DC就得首先安裝備用的DC，參考：http://www.cnblogs.com/yankliu-vip/archive/2012/06/13/2547646.html 。

dcpromo

安裝完以後，忽然又想到，其實我並不必定要主控DC遷移，我須要的是一個能夠正常加域的入口，因而我將客戶機的DNS指向了新配置好的DC。接下來操做，就比較絲滑了。

回顧與總結

總的來說，在這個將近二十個小時裏面，我經歷了這些：

TFS數據庫滿了=>發現因爲sqlexpress的限制=>計劃升級sql服務版本=>sqlexpress的內核版本很高=>安裝sql2016=>sql2016不支持winserver2008r2=>安裝winserver2016=>部署時發現不支持數據庫用戶身份驗證=>集成域環境=>winserver2016沒法加入winserver2008r2的域環境=>bingstackoverflowserverfault=>都不知足=>繼續bingstackoverflowserverfault=>發現別人在貼日誌=>分析日誌=>net use指令返回53=>bingstackoverflowserverfault=>都不知足=>論壇裏面有人提到SEP12證書的問題=>刪除域控下面安裝的證書=>無效=>繼續搜索net use指令相關問題=>嘗試使用net view指令=>發現win10和winserver2016都沒法使用共享文件夾相關的功能=>回憶起來之前win10是能夠網絡共享的=>回憶起來這彷佛是和升級了TSL版本有關=>意識到本身作了不少無用功=>嘗試使用tfsdeleteproject先刪除部分項目釋放空間=>發現因爲數據庫滿了，刪除功能沒法正確使用=>
意識到能夠經過新建項目集合的方式來處理，可是因爲數據庫已滿，放棄=>繼續從DC這個點解決問題，決定遷移DC到一個乾淨的環境=>安裝了新的備份DC=>對備份DC 執行net use指令一切正常=>意識到能夠將客戶機的dns指向備份dc來解決問題=>成功加入域=>嘗試在其餘的服務器上部署tfs=>發現tfs版本不兼容遷移的數據庫=>升級tfs版本到update1=>開始遷移=>數據庫登陸名衝突=>更改登陸名=>全文索引服務未安裝=>安裝全文索引服務。

雖然我只是兼個部署，可是回頭想一想，其實很能發現問題：

• 部署管理有問題，DC不該該和其餘角色混淆
• 使用產品的時候，沒有仔細閱讀產品說明書
• 對當前部署的產品的版本沒有清醒的認識
• 決策的時候，沒有仔細收集資料，沒有分析可行性
• 決策衝動，不少時候爲了直觀而增長了複雜度
• 分析問題的方式有問題，不少時候應該從當前環境的日誌着手，而不是盲目的binggooglestackoverflow
• 解決問題的思路有問題，不少時候繞道實際上是更好的選擇
• 作部署工做的時候，千萬很差和環境講道理
  固然此次經歷也不滿是壞事，總的來說，我確認了一點，我確實擁有一顆還算堅韌的心。

關於net use 53 以及 network path not found

這個問題還沒有解決，歡迎道友指路。