Erreurs d’interdiction 403 lors du basculement d’un groupe de disponibilité SQL 2012 avec SharePoint 2010

Article d’origine publié le jeudi 3 mai 2012

Je viens d’avoir beaucoup de difficulté à faire fonctionner correctement le basculement d’un groupe de disponibilité avec SharePoint 2010, et j’ai pensé partager le résultat de mes recherches au cas où cela pourrait servir à d’autres personnes. En bref, après avoir établi mon groupe de disponibilité SQL 2012, tout semblait fonctionner correctement. J’ai créé une nouvelle base de données de contenu sur le nœud principal du groupe, puis je l’ai sauvegardée et ajoutée à la liste de base de données gérée par le groupe de disponibilité (AG). Jusque là, tout va bien. Je pouvais accéder au site SharePoint et il se restituait parfaitement. Cependant, après le basculement du groupe de disponibilité sur un nouveau nœud, mon site SharePoint n’était plus accessible. J’obtenais alors une erreur d’interdiction 403 à la place du contenu de la page. Ce qui était vraiment frustrant, c’est que je pouvais ouvrir SQL Server Manager directement et me connecter sans problème à l’écouteur AG. Je pouvais effectuer des requêtes et obtenir des résultats de toutes les tables de ma base de données de contenu qui était maintenant hébergée sur un autre serveur.

Après avoir passé beaucoup de temps à essayer de résoudre ce problème, mon ami et barjo SQL (dans le bon sens !) Bryan P. m’a fait remarquer que bien que le compte de base de données pour mon compte de pool d’applications ait bien suivi ma base de données, ce n’était pas le cas de l’identifiant SQL. En fait, si je regarde dans SQL Manager la base de données de contenu et vérifie Sécurité...Utilisateurs, je vois bien le compte SQL pour le pool d’applications. Cependant, si je vérifie le nœud Sécurité de niveau supérieur pour le serveur, puis les identifiants, je constate qu’il n’y a pas de compte de connexion correspondant pour le compte de pool d’applications. J’ai donc simplement créé le compte du pool d’applications, puis lui ai affecté les droits d’accès aux bases de données de contenu que je gère avec le groupe de disponibilité. Après cette modification, tout fonctionne correctement côté SharePoint, je peux maintenant basculer sur n’importe quel nœud dans le cluster et mon site SharePoint continue à parfaitement fonctionner.

C’est bon à savoir, surtout si vous créez des pools d’applications avec de nouveaux comptes et souhaitez protéger vos bases de données de contenu avec un groupe de disponibilité. Assurez-vous donc d’ajouter ces nouveaux comptes aux identifiants de chaque serveur SQL 2012 participant dans vos groupes de disponibilité.

Ceci est un billet de blog localisé. L’article d’origine est disponible à l’adresse 403 Forbidden Errors When Failing Over a SQL 2012 Availability Group with SharePoint 2010