Descripción del Escenario
Partimos de una Granja de SharePoint, formada por un servidor SQL y un servidor MOSS 2007 SP2, en la cual, existen varias Aplicaciones Web, una de las cuales contiene unas 400 Bases de Datos de Contenido (cada una de las cuales contiene una única Colección de Sitios). También había una Aplicación Web para My Site, con una única Base de Datos de Contenido que almacenaba 2000 Colecciones de Sitios, y varias aplicaciones más. Esta granja estaba ejecutándose en VMWare. El tamaño del SQL Server era de algo menos de 1TB. Además, la Granja tenía multitud de personalizaciones, paquetes WSP desplegados, Workflows de SharePoint Designer, formularios de InfoPath, y demás historias.
Necesitamos instalar el Service Pack 3 de SharePoint 2007, ya que estamos en Diciembre, y en Enero quedará fuera de Soporte el MOSS 2007 Service Pack 2.
Descripción del Problema: No es posible instalar el Service Pack 3 de MOSS 2007
Básicamente, el problema es que el Service Pack 3 de SharePoint 2007 no se dejaba instalar correctamente. El primer paso de instalación, no daba problemas. Sin embargo al ejecutar el SharePoint Products and Technologies Wizard (es decir, el psconfig.exe de toda la vida) daba error.
Lo intenté varias veces. Probé con diferentes usuarios, revisé permisos (Farm Admin, Administrador Local de las máquinas, SysAdmin en SQL Server, etc.), comprobé espacio libre en disco en el MOSS y en el SQL Server, liberé espacio en el disco C del MOSS, probé lanzando el SharePoint Products and Technologies Wizard de forma gráfica, lo probé desde comandos con el psconfig.exe, probé a ejecutar el psconfig.exe con la opción –force, etc. Nada de Nada. No había dónde rascar.
Revisando el contenido del upgrade.log, podía ver errores similares a los siguientes.
[SPManager] [ERROR] [12/12/2012 12:08:33 PM]: Upgrade [SPContentDatabase Name=WSS_Content_GuilleSQL Parent=SPDatabaseServiceInstance] failed.
[SPManager] [ERROR] [12/12/2012 12:09:25 PM]: ReflexiveUpgrade [SPWebApplication Name=guillesql Parent=SPWebService] failed.
[SPManager] [ERROR] [12/12/2012 12:18:56 PM]: ReflexiveUpgrade [SPWebServiceInstance Parent=SPServer Name=VIIS03] failed.
[SPManager] [ERROR] [12/12/2012 12:18:56 PM]: An update conflict has occurred, and you must re-try this action. The object SPWebApplication Name=guillesql Parent=SPWebService is being updated by GUILLESQL\administrator, in the PSCONFIG process, on machine VIIS03. View the tracing log for more information about the conflict.
[SPManager] [ERROR] [12/12/2012 12:18:56 PM]: at Microsoft.SharePoint.Administration.SPConfigurationDatabase.StoreObject(SPPersistedObject obj, Boolean storeClassIfNecessary, Boolean ensure)
Busqué más información en los Logs de SharePoint, incluyendo los ficheros PSCDiagnostigs y en el Application Event Log, pero fui incapaz de encontrar ninguna pista.
Dándole más vueltas, descubrí que en cada uno de los intentos de instalación del Service Pack 3 de SharePoint 2007, el primero de los errores que se producía era relacionado con la actualización de alguna Base de Datos de Contenido. Pero el detalle que me llamó la atención es que en cada ocasión el error se producía sobre una Base de Datos de Contenido diferente, siempre de la misma Aplicación Web.
Fue en este momento, cuando pensé en la solución: Quitar todas las Bases de Datos de Contenido de dicha Aplicación Web. Ojo, que me refiero a quitar las Bases de Datos de Contenido a nivel de SharePoint (ej: con el comando STSADM deletecontentdb), no a quitarlas de SQL Server (detach).
La Solución: Quitar las Bases de Datos de Contenido y detener el Servicio del Timer
Llegados a este punto, me preparé un Script para ejecutar los comandos STSADM deletecontentdb para todas las Bases de Datos de Contenido de la Aplicación Web, que eran una 400 bases de datos. Sin embargo, al ejecutarlo me encontré de forma aleatorio con muchos errores como los siguientes:
- An update conflict has occurred, and you must re-try this action. The object SPWebApplication Name=guillesql Parent=SPWebService is being updated by GUILLESQL\mosssvc, in the STSADM process, on machine VIIS03. View the tracing log for more information about the conflict.
- Object reference not set to an instance of an object.
Mal rollo. Probé a reintentar con alguna Base de Datos de las que había fallado y funcionó bien. Sin embargo, con tantas bases de datos y el tiempo que se necesita para ejecutar cada comando STSADM, si además falla de forma aleatoria y tenemos que volver a ejecutar otro script para reintentar las Bases de Datos que falten, entonces está claro que tenemos un problema: Nos vamos de ventana fijo.
Hice alguna prueba más, pero estos errores persistían. Finalmente, dándole vueltas al tema descubrí por dónde iban los tiros: Timer Jobs. Existían varios Timer Jobs que se estaban ejecutando casi constantemente, correspondiente a personalizaciones o aplicaciones particulares de este cliente. La ejecución de estos Timer Jobs junto con la ejecución de los comandos STSADM deletecontentdb estaban entrando en conflicto, así que, decidí detener el servicio Windows SharePoint Timer Service, volví a lanzar el Script con los STSADM deletecontentdb, y el Script se ejecutó con éxito para todas las Bases de Datos de Contenido. Eso sí, tardó unas 15 horas.
Ahora, con todas las Bases de Datos de Contenido quitadas de SharePoint, volví a ejecutar el SharePoint Products and Technologies Wizard (psconfig.exe), y en esta ocasión, su ejecución finalizó con éxito. Genial ! Ya tenemos instalado el Service Pack 3 de SharePoint 2007 ! Bueno, o casi, ya que no tenemos ninguna de nuestras 400 Colecciones de Sitio ;-)
Llegados a este punto, ahora toca ejecutar un Script con los comandos STSADM addcontentdb para todas las Bases de Datos de Contenido que quitamos antes. El principal problema es el tiempo necesario para ejecutarlo (en mi caso, unas 30 horas), ya que por lo demás, teniendo detenido el Servicio del Timer, debe funcionar perfectamente (lentico, pero bien). En mi caso, el Script terminó correctamente, y todas las Bases de Datos de Contenido fueron adjuntadas con éxito.
El importante, tener en cuenta, que esta tarea de quitar las Bases de Datos de Contenido para luego volverlas a poner, tiene un poquitín de riesgo, ya que en alguna ocasión me he encontrado con algún error al intentar añadir una Base de Datos de Contenido a SharePoint, lo cual, puede suponer una pérdida de datos algo incómoda (especialmente para el dueño de los datos ;-)
Despedida y Cierre
Tras tres días bastante intensos, la instalación del Service Pack 3 de SharePoint 2007 ha finalizado con éxito. Y suerte que no había que parchear Language Packs y que sólo había un servidor de MOSS. Es interesante tener conciencia, de que quitar las Bases de Datos de Contenido antes de instalar el Service Pack pueda ser vital para poder finalizar con éxito una instalación de este tipo, lo cual, evidentemente implica que posteriormente habrá que volver a adjuntar de nuevo las Bases de Datos de Contenido al SharePoint, y todo esto requiere de mucho tiempo.
Así que, si alguna vez os ocurre esto, confío que el presente artículo os pueda ayudar a quitaros un marrón.
Poco más por hoy. Como siempre, confío que la lectura resulte de interés.
