原文发布于 2012 年 5 月 3 日（星期四）我刚刚在对 SQL 2012 可用性组进行故障转移以使其在 SharePoint 2010 上正常运行时大获成功，因此，我想我应该与大家分享一下这个成果，希望能帮助到其他人。简而言之，我对 SQL 2012 可用性组全部进行了设置，使其看
原文发布于 2012 年 5 月 3 日（星期四）我刚刚在对 SQL 2012 可用性组进行故障转移以使其在 SharePoint 2010 上正常运行时大获成功，因此，我想我应该与大家分享一下这个成果，希望能帮助到其他人。简而言之，我对 SQL 2012 可用性组全部进行了设置，使其看起来运行正常。我在该组的主节点上创建了一个新的内容，然后对其进行备份并将它添加到可用性组 (AG) 管理的列表中。到目前为止一切都很好。我可以点击 SharePoint 网站，网站可以顺利打开。但是，在我将 AG 故障转移到一个新的节点后，我的 SharePoint 网站就再也不会出现了。相反，我会收到 403 禁止错误，而不是页面内容。然而，真正让人烦恼的是我可以打开 SQL Server 管理器并可成功地连接到我的 AG Listener，也就是说，我可以对目前驻留在不同上的内容数据库中的任一表进行查询并获取结果。
在花费了大量时间来试着搞清楚这一点之后，我的朋友及 SQL 疯子天才（褒义）Bryan P. 指出，在我的应用程序池帐户的数据库帐户与我的数据库一起移走时，SQL 登录并没有移走；我的意思是，如果我在内容数据库中搜索 SQL 管理器和查看“Security...Users”（安全...用户），则会看到应用程序池的 SQL 帐户。但是，如果我查看服务器的顶级“安全”节点，然后登录，则没有应用程序池的相应登录帐户。因此，我只创建了应用程序池帐户的登录，然后授予其访问使用 AG 管理的内容数据库的权限。在进行这样的更改后，一切都可在 SharePoint 上正常运行了，现在，我可以故障转移到该群集中的任何节点 ，且我的 SharePoint 网站会继续正常运行。
这听起来是一个值得注意的问题，尤其是在您使用新帐户创建应用程序池并希望您的内容数据库受到 AG 的保护的情况下，请确保已将这些新帐户添加到每个正在参与 AG 的 SQL 2012 服务器的登录中。