微软虐我千百遍——记一次比较漫长的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的配置工具，初始化当前配置，并重新配置数据库。出于慎重考虑，选择了第二种。参考：

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都无法成功。开始推测时客户机的问题，然后再一次对客户机做了各种检查，仍然无果。
对客户机和服务器的行为总结如下：

期间好几次想先放一放，但是每次都有一种错觉，似乎这个问题马上就要解决了。等到实在困得不行的时候，已经过了凌晨一点，实在是乏的不行，加上还连累另外一个同事一起，遂作罢。

第四阶段：柳暗花明

休息了一晚上，信心又足了很多，决定继续怼这个问题。还是从net use这个指令开始，还是以大量的搜索为基础。在搜索的过程中，发现了net的另外一个指令，net view。这个指令时用来查看共享文件夹的。共享文件夹这个名词让我突然想到一件事情，以前公司为了共享安装包，在服务器上开了共享目录。但是有一天win 10的机子全部无法访问了，而win 7和win server 2008r2都正常。猜测可能是相同的原因。于是开始搜索和收集这方面的资料。在一个论坛里面，偶尔看到了一句评论，和SEP 12也就是证书有关。又突然想起来，年中的时候为了测试微信小程序，在服务器上安装了证书（误操作），同时升级了服务器的TLS版本.......或许大家以为我马上要发现了真相，走进了科学 ——其实不然，我觉得越发头大了，因为这里的可能性太多了，所以我打算换个思路解决问题。
从net use和net view这两个指令的执行情况来看，应该是服务器的设置问题，导致了部分客户机无法访问，所以我向换个服务器——也就是迁移DC。迁移DC就得首先安装备用的DC，参考： 。

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=>开始迁移=>数据库登录名冲突=>更改登录名=>全文索引服务未安装=>安装全文索引服务。