由于在运行SQL 2014的Win 7.1 Pro桌面和Windows 2012 R2 Datacenter Azure服务器上应用完整的补丁集，SQL Management Studio（2008和2014版本）将无法连接到SQL 2014 Azure服务器。 客户端连接尝试超时并失败，SQL Server错误5。
SQL Server事务复制继续在本地SQL 2008实例和远程SQL 2014实例之间正常工作。 此外，远程（Azure）服务器上的SQL Management Studio 2014可以连接到本地（现场）SQL 2008实例，而不会影响远程（Azure）SQL 2014服务器。 双向DNSparsing和IP连接是正常的。 我可以看到，远程SQL 2014实例在启动时正确地创build了它的SPN。 SQL 2014上有一个警告，表示某些客户端正在使用NTLM回退。
我没有SQL 2014的本地实例，也没有SQL 2008的远程实例。所以我不确定这是一个相关的因素，服务器是远程的，在Azure上，通过VPN，或者如果我会看到相同的修补本地客户端和修补本地SQL服务器的问题。
我注意到远程SQL 2014服务器上的SQL浏览器服务已停止并被禁用。 我不确定这是否是预补丁的情况。 但是我在默认端口上运行一个实例，而不是一个命名实例，所以我希望我不需要SQL浏览器服务？
这个补丁星期二有关于Server 2003networking文件共享的身份validation问题。 我还没有看到一般的AD身份validation问题或SQL Server身份validation问题的报告。 有其他人有这个问题或类似的？ 任何build议，我应该试着回滚哪个KB？ 我应该运行Kerberosconfiguration分析器吗？ 我应该启动禁用的SQL浏览器服务吗？
任何帮助赞赏。
从服务器上删除MS15-027（KB3002657）并重新启动服务器不能解决问题。
删除客户端上的KB 3046049并重新启动客户端不能解决问题。 删除服务器上的KB 3046049并重新启动服务器不能解决问题，但错误代码从5更改为53（更常见的错误代码）。
编辑：这是不同于今晚的安全更新后 ， SQL Server Windows身份validation失败的问题：login来自不受信任的域，虽然它可能具有相同的根本原因。 （周二的补丁后，似乎有越来越多的关于authentication相关问题的报告）。具体来说，在我的情况下，Windows身份validation正常工作，我可以RDP到打补丁的机器之间，修补的机器和基于AD的login工作正常。
编辑：同样的问题影响SQL身份validation（非AD）。 完全相同的错误信息。 这表明这是一个连接问题，而不是authentication问题。
我们没有任何受影响的Windows 2003服务器。 所以我们看到的问题并不局限于Windows Server 2003（就像其他一些类似的March Patch问题所报道的那样）。
星期三上午2015年3月11日3月份Windows更新之后，我们开始使用ODBC和Spotlight软件连接到2005,2008 SQL实例，他们使用的是windows域的凭据。 SQL身份validation仍然工作。 错误：用户“login失败”。 用户没有与受信任的SQL Server连接相关联。 （Microsoft SQL Server，错误：18452）
我们的域级别是在Windows 2003 SP2服务器上的多个站点上的2003年。 在我们的Windows 2003域控制器上，我们退出了以下列出的所有更新： https : //technet.microsoft.com/library/security/ms15-Mar这恢复了我们所有的SQL数据库连接，并允许操作成功完成夜间系统处理。
我们拒绝通过我们的WSUS（Windows更新服务器）为我们的Intranet域上的所有服务器安装以下两个Windows更新：MS15-027（KB3002657）和MS15-031（KB3046049）
请阅读以下有关这些更新报告问题的文章： http : //www.infoworld.com/article/2895022/security/problems-reported-with-microsoft-patch-kb-3002657-and-a-warning-on-kb- 3046049.html＃tk.rss_security
support.microsoft.com/en-us/kb/3002657（阅读已知问题部分）
目前我们将不会在我们当前的2003域控制器上安装任何更新，因为我们正在监控其他问题。
MS15-27 KB3002657这不限于Windows 2003或Microsoft报告的EMC Epislon。
我的经历是：
映射驱动器或使用从Windows 7工作站到多个Windows 2008文件服务器（非域控制器）的uncpath将失败，并显示不正确的用户名消息。
问题是Windows 7工作站位于与Windows 2008文件服务器不同的Active Directory域中。 我们已经将静态dns条目添加到Windows 7工作站join的DNS区域，以解决Windows 2008服务器的IP地址。 因此，用户可以使用简短的计算机名称来访问文件共享（短名称= \服务器名称\共享名称FQDN长名称= \ servername.serverdomain.com \共享名称）此进程导致工作站在工作站dns后缀的\服务器名称。 workstationdomain.com名\共享名。 这会触发修补程序相信计算机名称已被欺骗，因为servername的fqdn是错误的。
为了纠正这个问题：
1-从工作站dns区域中删除服务器的dns条目。
2通过组策略部署到工作站一个dns后缀search列表包含工作站dns后缀和服务器dns后缀
现在，工作站仍然可以使用简短的uncpath名，并在通过dnssearch后缀列表后find正确的fqdn名称。
我们可能不是唯一这样做的人。