Artículo original publicado el jueves, 3 de mayo de 2012

Acabo de pasar un rato horrible intentando que un grupo de disponibilidad de SQL 2012 funcionase correctamente con SharePoint 2010, así que he pensado en compartir mis progresos por si pueden ayudar a alguien.  En resumen, digamos que tenía mi grupo de disponibilidad de SQL 2012 configurado y parecía funcionar correctamente.  Creé una nueva base de datos de contenido en el nodo principal del grupo y, a continuación, realicé una copia de seguridad y lo añadí a la lista de bases de datos gestionadas por el grupo de disponibilidad (AG).  Hasta aquí, todo bien.  Llegué al sitio de SharePoint y se veía correctamente.  Sin embargo, después de la recuperación de errores del AG en un nuevo nodo, mi sitio de SharePoint no aparecía.  En lugar del contenido de la página, se generaba un error de tipo "403 Forbidden error".  Lo más raro era que podía abrir SQL Server Manager y conectarme a mi agente de escucha de AG sin problemas, podía realizar consultas y obtener resultados para todas las tablas de mi base de datos de contenido, alojada ahora en un servidor distinto.

Después de un buen rato intentando averiguar qué pasaba, mi amigo Bryan P., un loco de su trabajo en SQL (en el mejor de los sentidos) me indicó que, aunque la cuenta de la base de datos de mi grupo de aplicaciones se había movido con mi base de datos, el inicio de sesión SQL no lo había hecho.  Lo que quiero decir es que si voy en SQL Manager a la base de datos de contenido y consulto Seguridad...Usuarios  veré la cuenta SQL del grupo de aplicaciones.  Sin embargo, si miro en el nodo Seguridad de nivel superior del servidor y voy a Inicios de sesión, veré que no hay una cuenta de inicio de sesión correspondiente para la cuenta del grupo de aplicaciones.  Por lo tanto, he creado el inicio de sesión para la cuenta del grupo de aplicaciones y, a continuación, le he concedido derechos para las bases de datos de contenido que estaba gestionando con el AG.  Una vez realizado el cambio, todo empezó a funcionar correctamente por parte de SharePoint y ya puedo realizar una recuperación en caso de error en cualquiera de los nodos del clúster sin que ello afecte al funcionamiento de mi sitio de SharePoint.

Es una buena idea mantenerse al tanto de este problema, especialmente mientras crea grupos de aplicaciones con nuevas cuentas y si desea que las bases de datos de contenido se mantengan protegidas con un AG. Asegúrese de agregar las nuevas cuentas a los inicios de sesión de cada servidor de SQL 2012 que esté participando en los AG.

Esta entrada de blog es una traducción. Puede consultar el artículo original en 403 Forbidden Errors When Failing Over a SQL 2012 Availability Group with SharePoint 2010