原文發布于 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 服務器的登錄中。
