Resucita el full Content Deployment en SharePoint

Este es el oscuro proceso de artes necrománticas para resucitar un full content deployment fallido.

Para realizar este proceso, necesitará de los siguientes materiales:

• Algo de su ropa.
• Algo de su cabeza.
• Algo de su cuerpo.
• Algo de sus muertos.

Ah no. Esto es para un muñeco vudú…

El content deployment de SharePoint, es un servicio que se configura entre aplicaciones web, que pueden estar en la misma granja o en dos granjas distintas. El servicio sirve para llevar el contenido desde la colección de sitios de origen a una de destino, creando una réplica de nuestro sitio web. Esto puede servir para tener una copia de seguridad de nuestra aplicación en una granja distinta o incluso para mostrar al público una aplicación con diferente configuración de acceso o ubicada en distintas zonas. Esto equivaldría, por ejemplo, a tener un entorno de edición en una red interna, con toda la configuración de permisos para los usuarios editores y un entorno de publicación en una red DMZ con acceso anónimo para que el público externo acceda a la aplicación.

Para lanzarlo, necesitaremos que el entorno de destino tenga creada una colección de sitios vacía sin plantilla. El primer content deployment que se lance se llamará full content deployment y se llevará todo el contenido del origen (si hay versionado, solo llevará la última versión publicada) y recreará el sitio en el destino. Los sucesivos content deployment, se llamarán incrementales, y solo llevarán el contenido que se haya modificado desde la última ejecución.

El content deployment tiene el problema de ser un servicio que puede dar errores con relativa facilidad. La edición en el entorno de destino está completamente desaconsejada, no suele haber problemas en algunas ediciones, como la habilitación del acceso anónimo, pero cualquier modificación del contenido puede dar problemas con los despliegues incrementales. En la mayoría de los casos, un error de content deployment requiere que se lance un nuevo full, pero en aplicaciones de gran tamaño, esto puede ser problemático ya que un full content deployment puede llegar a tardar días en completarse.

EL content deployment ejecuta un job en el servidor de origen y posteriormente, otro en el de destino. El job de edición comprueba el estado del job de destino, pero no al revés. El content deployment consta de tres frases principales.

• Exporting: Se inicia el job en origen y se generan los cab con el contenido que se va a desplegar en destino.
• Transporting: Se llevan los cab al servidor de destino.
• Importing: Se inicia el job en destino y se genera el contenido en el servidor. En este punto, el job en origen va consultando periódicamente al job de destino para saber su estado.

En la granja de origen, tenemos dos listas importantes para el content deployment:

/Lists/Content%20Deployment%20Jobs/AllItems.aspx

Esta lista contiene los datos de configuración del job y el estado general del mismo. El campo más importante es LastStatus, el cual nos indica el estado actual del job.

 Lists/Job%20Reports/AllItems.aspx

Esta lista contiene los datos del histórico de ejecución de todos los Jobs de content deployment.

Problemas solucionables del content deployment

El content deployment puede generar una serie de problemas que tienen diversas soluciones. En esta página solo vamos a tratar en profundidad los errores graves que tienen soluciones oscuras.

Vamos a diferenciar primero una serie de casos en los que podemos solucionar problemas del Content Deployment en función de sus errores. El job puede fallar en ambas granjas:

• Fallo del job en la granja de origen
  • Fase de Exporting: Si el job falla en origen en esta fase, probablemente, se habrá producido un fallo con el contenido. Habrá que identificar qué problema ha ocurrido y su solución. Sea como sea, tendremos que volver a lanzar el content deployment. Si el error es un CobaltException, consultar su solución más abajo.
  • Fase de Transporting: Un error en esta fase, se producirá por falta de espacio en el servidor de destino o por un corte de conexión entre las granjas. Habrá que solucionar los problemas de espacio y conexión y volver a lanzar el content deployment. Cuando se está haciendo un full content deployment, es posible que un firewall intermedio interprete el gran volumen de paquetes que se envían como un ataque.
  • Fase de Importing: Durante la fase de importing, la granja de origen solamente consulta el job de destino para actualizar su estado. Un error de conexión de sql o un reinicio del SPTimer provocarán que el job en origen falle, pero esto no afecta al job de destino, que seguirá importando contenido. Para solucionar este problema, distinguiremos varios casos:
    • Content deployment incremental: En este caso, simplemente volveremos a lanzar el content deployment cuando destino termine su ejecución. Si el siguiente job incremental falla, puede deberse a que esté intentando llevar contenido que el destino ya tiene. En ese caso, una posible solución es identificar el contenido que ya existe y eliminarlo a mano.
    • Content deployment full: En este caso, para evitar tener que volver a lanzar un pesado full content deployment, ejecutaremos los pasos listados más abajo.
    • Time out: En los dos casos anteriores, el job en origen habrá terminado con un estado de error. Pero en ocasiones, hagas un incremental o un full, el job de origen termina en un estado Timed out. Este estado indica que el job de origen aún se está ejecutando, pero ha tenido un time out al intentar consultar el estado del job de destino. El job en destino puede que aun siga ejecutándose o que ya haya terminado, en el menú contextual del job, aparecerá una opción de check status, que forzará una comprobación del job de destino y actuará en consecuencia, actualizando el estado real del content deployment.
• Fallo del job en la granja de destino: Cualquier fallo del job en destino, va a requerir obligatoriamente que se ejecute un nuevo content deployment ya que el contenido no ha terminado de desplegarse. Es posible que haya que solucionar a mano algún error de contenido que se haya producido, en otras ocasiones, puede deberse a algún error más mundano, como fallos de conexión con SQL. Un content deployment incremental se podrá volver a lanzar sin problemas. Si se trataba de un full content deployment, es altamente recomendable eliminar la colección de sitios de destino, crear una nueva, eliminar el path y el job y crearlos de nuevo. Después, podremos volver a lanzar el full content.

Errores en origen en la fase de exporting por Cobalt.ErrorException

Este error se produce cuando algún fichero no se puede abrir por un fallo en SQL. Los ficheros afectados pueden ser páginas o documentos, en ambos casos, el objeto File asociado al ListItem, no es accesible de ninguna manera. El ListItem, en cambio, sí que es accesible y puede ser consultado y editado con normalidad.

La única solución a este problema es eliminar el ListItem asociado al fichero que falla y volver a lanzar el content deployment. Es recomendable desarrollar y ejecutar algún script de listado de errores Cobalt. Estos scripts recorren toda la colección de sitios abriendo los archivos. Los archivos que generen una excepción al hacerles un OpenBinary, serán listados para poder ser tratados posteriormente.

Error en origen en la fase de importing

Si el job falla en la fase de importación en la granja de origen, pero sigue funcionando en la granja de destino, aun podemos recuperar el content sin tener que cancelar y lanzar un nuevo full content. En aplicaciones de gran tamaño, esta práctica puede servirte para no perder uno o dos días esperando a que se complete un full content.

Si el job de destino aún está ejecutándose, nos dirigiremos a la lista de Content Deployment Job. Esta lista tiene cuatro columnas en las que no se guarda contenido pero que tienen marcado el check de requeridas, las editaremos en la configuración de la lista para quitar el requerido. Se trata de las siguientes columnas:

• RemoteJobDestinationServerUrl
• RemoteJobDestinationSiteCollection
• RemoteJobIncludeSecurity
• RemoteJobIncludeUserInfoDateTime

Una vez hecho esto, Editaremos el objeto del job fallido y en el campo LastStatus pondremos el número 6, que corresponde con Import in progress. Si vamos a la página general de los path del content deployment, veremos que este ahora aparece como running.

Esta es la tabla completa de estados de los Jobs.

Cuando el job termine en destino, comprobaremos el log para ver si ha terminado con succes o fail. Si ha terminado con fail, volveremos a cambiar el estado del elemento del job al de Failure, el número 2, volveremos a poner las columnas como requeridas y tendremos que ejecutar un nuevo full content ya que no se ha insertado el contenido en destino.

Si la ejecución en destino ha terminado correctamente, procederemos a intentar enganchar el content deployment.

En la lista de Content Deployment Job, editaremos el elemento y pondremos en el LastStatus el número 1. Cambiaremos en la LastStatusMessage el failed, por succeeded. En el campo de LasSuccessfullDeployTime, pondremos los mismos datos que en la columna LastRunTime.

En la lista de Job Reports, buscaremos el elemento que corresponda con la última ejecución del job fallido. Editamos el elemento y pondremos los siguientes datos, en la columna Status pondremos el 1. En StatusMessage, cambiaremos el failed por succeeded. En la columna EndTime, pondremos la hora de finalización que nos marque el log del job de destino.

Una vez realizados estos cambios, para todos los efectos, el sistema considerará que ha ejecutado un full content deployment satisfactoria. Pero para evitar problemas con las horas de ejecución, lanzaremos por consola de comando un job incremental asignando una hora determinada, que podrá ser cualquiera entre que terminó la fase de exportación y terminó el job en destino (el propio sistema no dejará poner una hora posterior a la finalización del job.

• $contDep = get-spcontentdeploymentjob –identity «»
• $contDep.Run($false, $DateTime)

Si el job termina correctamente el incremental, podremos ya probar a lanzar uno con la administración central. Si este termina correctamente, es recomendable hacer algún cambio en Origen y lanzar un incremental para comprobar que lleva el contenido correctamente.

Una vez que nos aseguremos de que el content deployment es estable, volveremos a poner las columnas como requeridas.