SharePoint 2010无法连接配置数据库，关联TFS 2012故障求助

从你描述的场景来看，虽然已经关闭了测试机，但克隆测试机的操作很可能留下了隐性影响，导致生产环境的SharePoint配置数据库连接异常。下面是一步步的排查思路，你可以按顺序尝试：

1. 先从事件日志找具体错误信息 #

这是最直接的一步，别瞎猜！打开生产服务器的事件查看器，定位到Windows日志 > 应用程序，筛选来源为SharePoint Foundation的事件，里面肯定有更详细的错误详情——比如是权限不足、SQL连接超时、数据库访问被拒绝，还是配置数据库本身有问题。这些细节能帮你直接锁定方向，比盲目试方案高效多了。

2. 验证SharePoint服务账户的数据库权限 #

TFS服务正常说明SQL服务器本身没问题，但SharePoint的服务账户可能失去了配置数据库的访问权限：

• 登录到SQL服务器，打开SQL Server Management Studio，找到SharePoint的配置数据库（通常叫SharePoint_Config）。
• 查看数据库的安全性 > 用户，确认SharePoint的服务账户（比如Timer Service、Web应用程序池的账户）是否在列表里，且拥有db_owner或对应的权限。
• 如果权限丢失，重新添加账户并赋予必要权限；如果权限存在，可以尝试重置服务账户的密码，然后在SharePoint管理中心的安全性 > 配置服务账户里更新凭据，重启SharePoint相关服务（Timer Service、Web Application Pool）。

3. 测试生产服务器到SQL的数据库连接 #

在生产服务器上打开命令提示符，用sqlcmd命令测试连接：

sqlcmd -S <你的SQL服务器名称/实例> -U <SharePoint服务账户> -P <账户密码>

如果能成功进入SQL命令行，说明网络和账户没问题；如果失败，根据报错信息排查（比如网络不通、账户密码错误）。

4. 检查测试机克隆导致的SID冲突问题 #

克隆Windows服务器如果没做sysprep重置SID，会导致AD环境里出现重复的安全标识符，哪怕测试机关了，也可能影响生产机服务账户的身份验证：

• 先处理生产端：尝试把SharePoint服务账户从AD组中移除再重新添加，或者在本地服务器上重新配置服务账户的登录权限。
• 后续测试机一定要做sysprep重置SID，避免再次出现这类冲突。

5. 确认SharePoint配置数据库状态 #

在SQL Server里检查SharePoint_Config数据库是否处于在线状态，有没有损坏：

• 执行命令：

DBCC CHECKDB('SharePoint_Config')

如果数据库有损坏，需要根据DBCC的提示进行修复；如果数据库正常，那问题大概率在连接或权限层面。

先按这个顺序排查，尤其是事件日志的错误信息，能帮你快速缩小范围。如果有具体的错误代码或日志内容，还能更精准地解决问题。

内容的提问来源于stack exchange，提问作者Mac Lee