Compartir a través de

Realización de una actualización de prueba para detectar posibles problemas (SharePoint Server 2010)

  • Artículo

 

Se aplica a: SharePoint Server 2010

Última modificación del tema: 2016-11-30

Antes de comenzar el proceso de actualización de Microsoft Office SharePoint Server 2007 a Microsoft SharePoint Server 2010, se recomienda probar el proceso de actualización para asegurarse de saber exactamente cómo proceder para lograr una actualización satisfactoria. El uso de una actualización de prueba para probar el proceso permite descubrir:

  • Las personalizaciones que hay en el entorno, de manera que pueda planear cómo tratarlas durante la actualización.

  • Si se debería actualizar el hardware para lograr que la actualización se ejecute de manera más eficiente y con mayor rapidez.

  • El momento oportuno para la actualización o cuánto tardará la actualización en el entorno.

  • Lo que se necesita para hacer una planeación operacional, por ejemplo, recursos que hay que tener disponibles.

Además, la actualización de prueba es útil para familiarizarse con las herramientas de actualización y con el proceso mismo, de manera que se sepa lo que podría suceder cuando se lleve a cabo el proceso real. Al realizar esta prueba, puede descubrir:

  • Los casos especiales que se aplican al entorno y el enfoque de actualización más eficiente.

  • Cómo es la interfaz de usuario, cómo se sabe que se ha finalizado una fase y se ha pasado a otra.

  • Dónde están los archivos de registro, cómo leerlos y la información que proporcionan.

  • Las técnicas que se pueden usar para reducir el tiempo de inactividad.

En este artículo se describen los pasos básicos para probar la actualización; además, se ofrecen recomendaciones para revisar los resultados y ajustar los planes de actualización basándose en lo que se aprendió durante las pruebas.

En este artículo:

  • Configuración de un entorno de prueba

  • Identificación e instalación de personalizaciones

  • Copia de datos reales en el entorno de prueba y comprobación de la actualización

  • Revisión de los resultados

  • Ajuste de los planes y repetición de las pruebas

Además, los siguientes recursos pueden resultar útiles al probar el proceso de actualización:

Configuración de un entorno de prueba

Para probar el proceso de actualización, se puede usar un hardware físico o virtual. Cada entorno es único, de manera que no hay instrucciones generales sobre el tiempo que dura una actualización o sobre la dificultad que entraña actualizar una personalización en particular. La mejor manera de medir el proceso de actualización es mediante la realización de una serie de actualizaciones de prueba.

Cuando cree el entorno de prueba:

  • La granja de servidores de prueba debe ser lo más parecido a la granja real, por ejemplo, hardware, software y espacio disponible.

  • Use las mismas direcciones URL en la granja de servidores de prueba y en la real. (De lo contrario, perderá tiempo diagnosticando problemas relacionados con direcciones URL que no aparecerán en la actualización real.)

  • Asegúrese de transferir todas las configuraciones y personalizaciones al entorno de prueba. La sección Identificación e instalación de personalizaciones proporciona información sobre la recopilación de esta información.

Uso de un entorno de prueba virtual

Al realizar pruebas en un entorno virtualizado, no se necesita mucho hardware. Para replicar el entorno, se pueden usar solo dos servidores que ejecuten Hyper-V. Un servidor tendrá imágenes de los servidores front-end web y los servidores de aplicaciones, y el otro tendrá imágenes de los servidores de base de datos.

Entorno de prueba virtual para una actualización de prueba

Uso de un entorno de prueba físico

Cuando se realizan pruebas en un entorno físico, se tiene que replicar el entorno de la granja de servidores completo y con el mayor parecido posible. Si simplifica demasiado la cantidad de servidores front-end web, los servidores de aplicaciones o los servidores de bases de datos, no tendrá una estimación precisa de cuánto tardará el proceso de actualización, y puede que no se tengan en cuenta complicaciones que surgen de interacciones entre servidores en el mismo rol (como transacciones de SQL Server). Si tiene varios servidores en un rol en la granja de servidores original, para probar dichos problemas, use al menos dos servidores para ese rol en la granja de servidores de prueba.

Granja de prueba física para una actualización de prueba

Entornos de prueba adicionales para la actualización de base de datos adjunta

Si va a usar el enfoque de actualización de base de datos adjunta, puede que necesite crear un entorno de prueba adicional: una única granja de servidores que ejecute Office SharePoint Server 2007 y que se pueda usar para ejecutar la herramienta de comprobación previa a la actualización antes de intentar actualizar los datos.

Para evitar este paso, ejecute la herramienta de comprobación previa a la actualización en la granja de servidores de producción existente.

Identificación e instalación de personalizaciones

Para que el proceso de prueba sea preciso, hay que buscar todas las personalizaciones en el entorno actual y copiarlas en el entorno de prueba. Para obtener más información sobre los tipos de personalizaciones que se deben identificar, vea Determinación del procedimiento para tratar las personalizaciones (SharePoint Server 2010).

  • Use la herramienta de comprobación previa a la actualización para identificar definiciones del sitio, plantillas del sitio y características del entorno.

    La herramienta de comprobación previa a la actualización examina todas las colecciones de sitios y genera un informe sobre el estado de cada sitio. También guarda información sobre la definición de cada lista. Puede revisar los informes para ver los problemas y solucionarlos antes de empezar el proceso de actualización. A diferencia de la herramienta de detección previa a la actualización para Office SharePoint Server 2007, la herramienta de comprobación previa a la actualización es una herramienta de solo lectura y no cambia los sitios. Para obtener más información acerca de esta herramienta y los pasos para ejecutarla, vea el tema sobre la detección previa a la actualización y generación de informes para versiones futuras (Office SharePoint Server) y Ejecución de la herramienta de detección previa a la actualización (SharePoint Server 2010).

  • Use la operación Stsadm –o enumallwebs en todas las bases de contenido del entorno de Office SharePoint Server 2007 para identificar las personalizaciones específicas en los subsitios. Esta operación indica un identificador para cada colección de sitios y subsitio del entorno y las plantillas que usa el sitio. Esta operación se introdujo por primera vez en Office SharePoint Server 2007 con Service Pack 2 (SP2). Para obtener más información, vea el tema sobre la operación Enumallwebs de Stsadm (Office SharePoint Server).

  • Use una herramienta como WinDiff (una herramienta que se proporciona con la mayoría de los sistemas operativos Microsoft) para comparar los servidores del entorno de producción con los servidores de la granja de prueba. Puede usar esta herramienta para ver los archivos que existen en los servidores y las diferencias entre ellos.

  • Compruebe los archivos web.config para averiguar si se efectuaron cambios y busque controles personalizados en el elemento SafeControls.

  • Use la herramienta de diagnóstico de SharePoint (SPDiag) para encontrar soluciones implementadas. Para obtener más información, vea el tema sobre la herramienta de diagnóstico de SharePoint (SPDiag).

  • Cree una lista de todas las personalizaciones que encuentre y, en lo posible, identifique el origen de las personalizaciones. Por ejemplo, ¿hay complementos de terceros o plantillas que se personalizaron internamente? Después de identificar el origen, puede comprobar si hay versiones actualizadas de las personalizaciones. Hay disponible una hoja de cálculo que se puede usar para rellenar información sobre el entorno, basada en los datos que se encuentran en los resultados de la herramienta de comprobación previa a la actualización y en la investigación de sus personalizaciones. Descargue esta hoja de cálculo desde https://go.microsoft.com/fwlink/?linkid=179928&clcid=0xC0A y personalícela según sus necesidades.

Sugerencia

¿Con quién se debe poner en contacto en relación con las personalizaciones que no creó?

  • Póngase en contacto con Microsoft en caso de que tenga problemas con una plantilla que descargó desde el sitio web de Microsoft (como las plantillas de aplicación de Windows SharePoint Services 3,0).

  • Póngase en contacto con el proveedor de soluciones de terceros si tiene problemas con una plantilla o componente que le suministraron para la versión anterior. Es posible que tengan disponible una versión actualizada.

Después de identificar todas las personalizaciones, cópielas en los servidores correspondientes en la granja de servidores de prueba. Puede usar el cmdlet test-spcontentdatabase de Windows PowerShell antes de adjuntar una base de datos a SharePoint Server 2010 para determinar si faltan personalizaciones del entorno. Ejecute este comando para cada base de datos después de restaurarlas en el servidor de base de datos, pero antes de ejecutar la actualización. Tenga en cuenta que este cmdlet se ejecuta en modo silencioso: no devolverá resultados a menos que haya un error.

Copia de datos reales en el entorno de prueba y comprobación de la actualización

No es posible lograr los objetivos de prueba a menos que se usen datos reales. Se pueden usar los siguientes métodos para crear una copia de los datos:

No hay mejor manera de saber lo que puede surgir durante la actualización que realizando la prueba en una copia de todos los datos. Sin embargo, es posible que esto no siempre sea una opción realista para la prueba inicial. Puede realizar el proceso paulatinamente probando una base de datos a la vez (en caso de que las bases de datos sean grandes) para poder tener la seguridad de que se prueba aquello que es único en ese conjunto de datos, o bien poder ensamblar un subconjunto de datos desde sitios representativos del entorno. Si desea probar primero con un subconjunto de los datos, asegúrese de que el subconjunto tenga las siguientes características:

  • El subconjunto de datos contiene sitios que son típicos de los sitios admitidos en el entorno.

  • El tamaño y la complejidad del subconjunto de datos son muy parecidos al tamaño y complejidad reales del entorno.

Importante

La prueba de un subconjunto de los datos no produce una referencia válida acerca de cuánto tiempo tardará el procesamiento del volumen de datos total para el entorno.

Después de copiar los datos, haga una primera pasada por el proceso de actualización para ver qué pasa. Esto es solo la ronda preliminar.

Prueba de la actualización en contexto

Si desea probar un enfoque de actualización en contexto, siga estos pasos para probar el proceso de actualización:

  1. Cree una copia de seguridad de la granja de servidores.

  2. Restaure la copia de seguridad en la granja de servidores de prueba.

    Para obtener más información, vea el tema sobre copia de seguridad y restauración de una granja de servidores completa (Office SharePoint Server 2007).

  3. Ejecute la herramienta de comprobación previa a la actualización. Tome nota de cualquier problema que se encuentre. Conviene solucionar estos problemas en el entorno original antes de ejecutar la actualización real en la granja de servidores del producto. Para obtener más información, vea Ejecución de la herramienta de detección previa a la actualización (SharePoint Server 2010).

  4. Siga los pasos en Realización de una actualización en contexto (SharePoint Server 2010) para probar la actualización en contexto.

  5. Revise los resultados.

Prueba de una actualización de base de datos adjunta

  1. Cree una copia de seguridad de SQL Server de las bases de datos de contenido y las bases de datos del proveedor de servicios compartidos (SSP).

  2. Use SQL Server para restaurar las copias de seguridad en la granja de prueba de un solo servidor y adjuntar las bases de datos de contenido a ese entorno.

    Para obtener más información, vea el tema sobre copia de seguridad y restauración de bases de datos (Office SharePoint Server).

  3. Ejecute la herramienta de comprobación previa a la actualización. Tome nota de los problemas que encuentre y los cambios que haga. Conviene solucionar estos problemas y hacer estos cambios en el entorno original antes de ejecutar la actualización real en la granja de servidores del producto. Para obtener más información, vea Ejecución de la herramienta de detección previa a la actualización (SharePoint Server 2010).

  4. Siga los pasos que se indican en Preparación del nuevo entorno de SharePoint Server 2010 para una actualización de base de datos adjunta para configurar el entorno de prueba para una actualización de base de datos adjunta.

  5. Siga los pasos que se indican en Bases de datos adjuntas y actualización a SharePoint Server 2010 para probar el proceso de actualización de base de datos adjunta.

Revisión de los resultados

Después de completar la actualización de prueba, puede revisar los resultados y volver a comprobar los planes. Examine los archivos de registro, los sitios actualizados y compruebe las personalizaciones. Vea cómo funcionó el trabajo de actualización para el entorno, lo que descubrió y qué se necesita para reconsiderar el plan de actualización.

Revisión de los archivos de registro

Revise los siguientes archivos de registro:

  • El archivo de registro de la herramienta de comprobación previa a la actualización.

    Los archivos de registro para la herramienta de comprobación previa a la actualización (stsadm -o preupgradecheck) están en %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\12\LOGS. Los nombres de los archivos de registro tienen el siguiente formato: PreUpgradeCheck_AAAAMMDD-HHMMSS-SSS-número-aleatorio.log, donde AAAAMMDD es la fecha y HHMMSS-SSS es la hora (horas en formato de 24 horas, minutos, segundos y milisegundos) y se usa el número aleatorio para diferenciar entre posibles intentos simultáneos de ejecutar la herramienta de comprobación previa a la actualización.

  • El archivo de registro de Asistente para la configuración de productos de SharePoint (Psconfig.exe) (se genera cuando se ejecuta este asistente como parte de la actualización en contexto de prueba).

    Los archivos de registro de PSCDiagnostics están ubicados en %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS.

  • El archivo de registro de actualización y el archivo de registro de errores de la actualización (se genera cuando se ejecuta la actualización).

    El archivo de registro de actualización (.log) y el archivo de registro de errores de la actualización (.err) están ubicados en %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS. Los nombres de los archivos de registro tienen el siguiente formato: Upgrade-AAAAMMDD-HHMMSS-SSS.log, donde AAAAMMDD es la fecha y HHMMSS-SSS es la hora (horas en formato de 24 horas, minutos, segundos y milisegundos).

Para revisar los archivos de registro con el objetivo de encontrar y solucionar problemas, comience por la parte superior de los archivos. Los errores o advertencias pueden repetirse cuando se producen para varias colecciones de sitios en el entorno, o si bloquean el proceso de actualización totalmente. Por ejemplo, si no puede conectarse a la base de datos de configuración, el proceso de actualización lo intentará (y fracasará) varias veces, y estos intentos aparecerán en la lista del archivo de registro.

Busque las siguientes entradas:

  • Finished upgrading SPFarm Name= <nombre de la base de datos de configuración>

  • In-place upgrade session finishes. Root object = SPFarm= <Nombre de la base de datos de configuración> , recursive = True. 0 errors and 0 warnings encountered.

Si existen esas entradas, la instalación se realizó correctamente.

Si no encontró las entradas indicadas en el paso anterior, puede identificar problemas específicos que puedan haber contribuido al error realizando una búsqueda de los siguientes términos en el archivo Upgrade.log:

  • Busque ERROR en los archivos de registro para buscar los errores (como error en componentes o error en conexiones de bases de datos).

  • Busque WARNING para encontrar problemas como la ausencia de características o componentes.

Para buscar problemas de la actualización, puede resultar útil usar un analizador de registro para ejecutar consultas en los archivos de registro.

Reinicio de la actualización, si es necesario

Durante una actualización de base de datos adjunta, se omitirán los sitios que no se puedan actualizar. Durante una actualización en contexto, si el servidor se reinicia o se produce un error en la actualización, deberá reiniciar el proceso de actualización para actualizar los sitios restantes.

Para ver si se pasó por alto u omitió algún sitio durante la actualización, ejecute la operación stsadm -o localupgradestatus de Stsadm en cada servidor front-end web de la granja de servidores de SharePoint Server 2010. Para obtener más información acerca de esta operación, vea el tema sobre la operación Localupgradestatus de Stsadm (Office SharePoint Server).

Si la actualización omitió alguna colección de sitios, puede reiniciar el proceso de actualización para la base de datos que contiene esa colección de sitios mediante el siguiente cmdlet de Windows PowerShell: upgrade-spcontentdatabase -id <GUID>. Para obtener más información sobre este cmdlet, vea Upgrade-SPContentDatabase.

Para obtener más información, vea Reanudación de la actualización (SharePoint Server 2010).

Revisión de sitios actualizados

Revise los sitios actualizados para identificar cualquier problema que tenga que solucionarse antes de ejecutar el proceso de actualización en el entorno de producción. Para obtener más información sobre cosas específicas que hay que buscar, vea Comprobación de la actualización y revisión de los sitios actualizados (SharePoint Server 2010).

Ajuste de los planes y repetición de las pruebas

Repita el proceso de prueba hasta que esté seguro de que se han encontrado todos los problemas que pueden surgir y que sabe cómo solucionarlos. El objetivo es saber cuál es el plan si son las 4:00 p.m. del domingo, debe volver a estar conectado el lunes por la mañana y el proceso no está yendo bien. ¿Hay un punto sin retorno? Pruebe el plan de reversión y asegúrese de que funciona antes de comenzar la actualización real.