起因
七月三日早晨剛到公司，同事就跟我講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
這個問題尚未解決，歡迎道友指路。