Realizar una actualización de prueba en SharePoint 2013 para detectar posibles problemas

Artículo
03/08/2023

SE APLICA A: yes-img-13 2013 no-img-16 2016 no-img-19 2019 no-img-se Subscription Edition no-img-sop SharePoint en Microsoft 365

Antes de comenzar una actualización de Productos de SharePoint 2010 a SharePoint 2013, le recomendamos que pruebe el proceso de actualización para cerciorarse de que sabe exactamente lo que hay que hacer para que la actualización se lleve a cabo correctamente. Una actualización de prueba para probar el proceso puede poner de manifiesto los problemas siguientes:

Si un plan de actualización determinado va a funcionar o si hay ajustes que sea necesario realizar.
Las personalizaciones que hay en el entorno, de modo que pueda planear cómo tratarlas durante la actualización.
Si se debería actualizar el hardware para lograr que la actualización se lleve a cabo 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.
Aquello con lo que debe contar desde el punto de vista operativo, 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 a qué atenerse cuando se lleve a cabo el proceso real. Al hacer esta prueba, puede descubrir:

¿Cómo es la interfaz de usuario de actualización? ¿Cómo sabe cuándo ha terminado una fase y se está moviendo a través de otra?
¿Dónde están los archivos de registro y cómo se leen? ¿Qué información proporcionan?
Si debe llevar a cabo ajustes de algún tipo en scripts o comandos que se usen durante el proceso de actualización, especialmente si trabaja con scripts que se usaron al actualizar a Productos de SharePoint 2010.
Si tiene un buen plan para gestionar las interrupciones que pueda haber.

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 en base a lo que se haya observado durante las pruebas.

Los siguientes recursos también pueden resultar útiles para probar el proceso de actualización:

SharePoint 2013: probar el modelo de proceso de actualización

Descargue el póster Productos de SharePoint 2013 Preview: Modelo de prueba del proceso de actualización para ver una presentación visual de la información sobre cómo probar el proceso de actualización.
Vea los procedimientos recomendados para probar el proceso de actualización en Procedimientos recomendados para actualizar de SharePoint 2010 a SharePoint 2013.

Configurar un entorno de prueba

Para probar el proceso de actualización, se puede usar un hardware físico o virtual. Cada entorno es único. Por lo tanto, no hay directrices generales sobre cuánto tiempo tardará la actualización o qué tan difícil será actualizar una personalización determinada. La mejor manera de medir cómo se realizará la actualización es realizar una serie de actualizaciones de prueba.

A continuación presentamos unas cuantas cosas que hay que tener en cuenta al crear un entorno de prueba:

La granja de servidores de prueba debe ser lo más parecida posible a la granja de servidores real; por ejemplo en hardware, software y espacio disponible.
En la granja de servidores de prueba, use las mismas direcciones URL que en la real. De lo contrario, perderá tiempo diagnosticando problemas relacionados con direcciones URL que no aparecerán en la actualización real. Puede hacerlo si usa las mismas direcciones URL y realiza las pruebas solo desde los equipos que tengan cambios en los archivos host.
Use diferentes nombres de PC para sus servidores web y servidores de aplicaciones.

Esto evitará que se generen conflictos con los Servicios de Dominio de Active Directory (AD DS).
Use servidores independientes que ejecuten SQL Server para su granja de servidores de prueba

Si usa los mismos servidores que ejecutan SQL Server para su granja de servidores de prueba que para su granja de producción, es posible que el rendimiento de su granja de servidores de producción se vea afectado durante la realización de las pruebas. Recomendamos que use dos PC SQL Server diferentes (y no solo instancias) para las granjas de servidores de producción y de prueba.
Use los mismos nombres de base de datos en su entorno de prueba.

De este modo, podrá validar cualquier script que use para administrar el entorno. Una vez más, asegúrese de usar servidores independientes que ejecuten SQL Server o se arriesga a que el proceso afecte a su entorno de producción.
Asegúrese de transferir todas las configuraciones y personalizaciones al entorno de prueba. La sección Identificación e instalación de personalizaciones proporciona indicaciones para recopilar esta información.

Asegúrese de que las acciones que realice en el entorno de prueba no repercutirán en el entorno vivo. Tenga especial cuidado con lo siguiente:

Conexiones a datos externos

Aunque esté trabajando con una copia del entorno, el enlace al origen de datos es real. Los cambios que haga en los datos del entorno de prueba afectarán al entorno de producción.
Ejecutar comandos sobre una base de datos activa que todavía esté en producción

Asegúrese de usar copias de su base de datos para hacer pruebas, no una versión que siga activa en su entorno de producción. Por ejemplo, si ejecuta Test-SPContentDatabase sobre una base de datos activa en vez de sobre una copia, puede que esto afecte al rendimiento de su entorno de producción.

Uso de un entorno de prueba virtual

Cuando se hacen pruebas en un entorno virtual, no es necesario tener mucho hardware. El entorno se puede replicar con solo dos servidores que ejecuten Hyper-V. Un servidor tendrá imágenes de los servidores front-end web y de los servidores de aplicaciones, y el otro tendrá imágenes de los servidores de base de datos.

Sin embargo, es posible que los entornos virtuales no tengan las mismas métricas de rendimiento que los entornos físicos. Si su entorno de producción es físico, le recomendamos que tenga en cuenta esta diferencia al calcular el tiempo necesario para actualizar su entorno de producción. Generalmente, podrá obtener estimados de rendimiento más ajustados si usa un servidor físico para SQL Server. Asegúrese de que tiene especificaciones de rendimiento similares a las del servidor que ejecuta SQL Server en el entorno de producción.

Distribución de los servidores en un entorno de prueba virtual

Granja de prueba virtual para la actualización

Uso de un entorno de prueba físico

Al probar mediante un entorno físico, debe replicar el entorno de granja de servidores de producción propuesto lo más estrechamente posible. Si simplifica demasiado el número de servidores front-end web, servidores de aplicaciones o servidores de bases de datos, no tendrá una estimación precisa del tiempo que tardará el proceso de actualización. No puede tener en cuenta las complicaciones que surgen de las interacciones entre servidores con el mismo rol (como las transacciones de SQL Server). Si tiene varios servidores en un rol en la granja de servidores de producción propuesta, use al menos dos servidores para ese rol en la granja de servidores de prueba para probar estos problemas.

Distribución de los servidores en un entorno de prueba físico

Granja de servidores física para probar la actualización

Identificación e instalación de personalizaciones

Para que el proceso de prueba sea preciso, hay que buscar todas las personalizaciones del entorno actual y copiarlas al entorno de prueba. Para obtener más información sobre los tipos de personalizaciones que tiene que identificar, vea Crear un plan para personalizaciones actuales durante la actualización a SharePoint 2013.

Use la operación Stsadm -o enumallwebs en todas las bases de datos de contenido del entorno de productos de SharePoint 2010 para identificar personalizaciones específicas en subsitios. Esta operación muestra un id. para cada colección de sitios y subsitios del entorno y las plantillas en las que se basa el sitio. Para obtener más información, vea Enumallwebs: operación de Stsadm.
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.
Cree una lista de todas las personalizaciones que encuentre. Identifique el origen de las personalizaciones, si es posible. Por ejemplo, ¿hay complementos o plantillas de terceros que se personalizaron internamente? Después de identificar el origen, puede comprobar si hay versiones actualizadas o actualizadas de las personalizaciones.

Sugerencia

¿Con quién se debe poner en contacto en relación con las personalizaciones que no creó? > Póngase en contacto con Microsoft si tiene problemas con una plantilla que descargó del sitio web de Microsoft. > Póngase en contacto con el proveedor de soluciones de terceros si tiene problemas con una plantilla o componente que le proporcionaron para la versión anterior. Es posible que tengan disponible una versión actualizada.

Una vez que haya identificado todas las personalizaciones, cópielas a los servidores correspondientes de su granja de servidores de prueba. Asegúrese de que se han implementado las siguientes personalizaciones:

Soluciones: de manera predeterminada, las soluciones heredadas se implementan en los directorios /14. Use el parámetro CompatibilityLevel al instalar las soluciones para implementarlas en los directorios /15. Para más información, vea Install-SPSolution.
Páginas maestras personalizadas
JavaScript personalizado
Archivos CSS personalizados (incluyendo los que son para temas)
Acciones de flujo de trabajo personalizadas (deben incluirse en el archivo de acciones)
Confirme la configuración de limitación de consultas de las listas grandes para asegurarse que las listas grandes se muestran como desea.

Cuando pruebe las personalizaciones, tenga en cuenta las siguientes indicaciones:

Compruebe si hay cambios visuales.
Compruebe si hay cambios en el comportamiento.
Haga las pruebas con las colecciones de sitios en modo 2010 y en modo 2013.
Busque si hay problemas de lenguaje o de carga de recursos.

Este es un problema con el que puede encontrarse cuando haya personalizaciones del modo 2013 que sustituyen personalizaciones que ya existen en modo 2010. Dado que solo hay un directorio global para los recursos de lenguaje, puede producirse un error al cargar el archivo correcto. Asegúrese de que las personalizaciones 2013 de sustitución incluyen los recursos 2010, de modo que las personalizaciones puedan seguir funcionando correctamente en ambos modos.
Compruebe que la actualización no afectó a las personalizaciones. Asegúrese de que las personalizaciones no estén bloqueando la actualización de la colección de sitios.

Puede usar el cmdlet Test-SPContentDatabase de Microsoft PowerShell antes de adjuntar una base de datos a SharePoint 2013 para determinar si faltan personalizaciones en el entorno. Ejecute este comando para cada base de datos una vez que haya restaurado las bases de datos al servidor de bases de datos, pero antes de ejecutar la actualización. Tenga en cuenta que este cmdlet se ejecuta en modo silencioso, y solo devuelve información si se encuentra un problema.

Copiar datos reales en el entorno de prueba y actualización de bases de datos

No es posible lograr los objetivos de la prueba a menos que se usen datos reales. Use la copia de seguridad SQL Server de Microsoft y restaure las herramientas para crear una copia de las bases de datos de contenido y de servicio.

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 las bases de datos una después de otra (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. También puede 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 muy comunes en 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 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. Siga los pasos descritos en Actualización de bases de datos de contenido de SharePoint 2010 a SharePoint 2013 para probar el proceso de actualización de la conexión de base de datos.

Cuando pruebe el proceso de actualización, asegúrese de probar los servicios que se comparten entre diferentes granjas de servidores. Tenga en cuenta todos los estados, como los siguientes:

Una granja de servidores de SharePoint Server 2010 conectada a una granja de servidores de servicio de SharePoint 2013.
Una granja de servidores de SharePoint 2013 conectada a una granja de servidores de servicio de SharePoint 2013.
Granjas de servidores de versiones distintas para servicios distintos.

Use el entorno de prueba para encontrar cualquier problema de seguridad, configuración, compatibilidad o rendimiento de las aplicaciones de servicio.

Revise los resultados una vez que haya actualizado las bases de datos

Una vez finalizada la actualización de prueba, puede revisar los resultados y volver a consultar los planes. Examine los archivos de registro, examine los sitios actualizados y revise las personalizaciones. ¿Cómo funcionó la actualización para su entorno? ¿Qué descubriste? ¿Qué tiene que replantearse sobre el plan de actualización?

Revisar los archivos de registro

Revise el archivo de registro de actualización y el archivo de registro de errores de la actualización (que se generan al ejecutar la actualización). El archivo de registro de la actualización (.log) y el archivo de registro de errores de la actualización (.err) se encuentran en %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\15\LOGS. Los archivos de registro se denominan en el formato siguiente: Upgrade- AAAAMMDD-HHMMSS-SSS.log, donde AAAAMMDD es la fecha y HHMMSS-SSS es la hora (horas en formato de reloj de 24 horas, minutos, segundos y milisegundos).

El formato de los archivos de registro sigue las convenciones de ULS (Unified Logging System). Para revisar los archivos de registro con el objetivo de encontrar y solucionar problemas, comience por la parte superior de los archivos. Es posible que los errores o advertencias se repitan si se producen en varias colecciones de sitios en el entorno, o si bloquean por completo el proceso de actualización. 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.

Revisar los sitios en modo 2010

Compruebe que las colecciones de sitios que no se actualizaron funcionan según lo previsto en modo 2010. Los sitios deberían tener el mismo aspecto y el mismo comportamiento que tenían en Productos de SharePoint 2010. Habrá algunos cambios que están previstos. Por ejemplo, Office Online y las características de análisis web han cambiado en SharePoint 2013 y los sitios que usaron estas características se verán afectados. Para obtener información sobre aspectos específicos que se van a buscar, vea Información general sobre el proceso de actualización de SharePoint 2010 a SharePoint 2013.

Si es necesario, ejecute la actualización de nuevo

Si tiene que hacerlo, puede reiniciar el proceso de actualización de una base de datos mediante el cmdlet Upgrade-SPContentDatabase de Microsoft PowerShell. Para más información sobre este cmdlet, consulte Upgrade-SPContentDatabase. Para más información, consulte Reiniciar la actualización de una base de datos adjunta o de una colección de sitios en SharePoint 2013.

Actualizar colecciones de sitios y Mis sitios

Una vez que haya probado y validado la actualización de las bases de datos de contenido y de servicio, puede probar el proceso de actualización de las colecciones de sitios. Siga los pasos descritos en Actualización de una colección de sitios a SharePoint 2013 para probar el proceso de actualización de la colección de sitios. Si tiene Mis sitios en su entorno, consulte Información general sobre el proceso de actualización de SharePoint 2010 a SharePoint 2013 para obtener más información sobre el proceso de actualización de ellos.

Nota:

El contenido sobre Mis sitios se aplica solo a SharePoint 2013

Revisar los resultados después de actualizar colecciones de sitios

Revise visualmente 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 aspectos específicos que se van a buscar, vea Información general sobre el proceso de actualización de SharePoint 2010 a SharePoint 2013.

Revise los archivos de registro de la actualización de la colección para identificar cualquier problema, de arriba hacia abajo. Revise la sección de resumen hacia el final del archivo de registro para ver el recuento de problemas y el estado real de la actualización (si no hay ningún estado significa que el proceso de actualización no se realizó correctamente y se debe reintentar la actualización de sitios). Los archivos de registro de las colecciones de sitios se guardan tanto en la misma colección de sitios (en la biblioteca de documentos _catalogs/Upgrade) como en el sistema de archivos. El archivo de registro del sistema de archivos contiene más información, si desea conocer los detalles de los problemas. La versión del sistema de archivos del archivo de error de la actualización del sitio se encuentra en %COMMONPROGRAMFILES%\Microsot Shared\Web server extensions\15\LOGS. Los archivos de registro se denominan en el formato siguiente: SiteUpgrade- AAAAMMDD-HHMMSS-SSS.log, donde AAAAMMDD es la fecha y HHMMSS-SSS es la hora (horas en formato de reloj de 24 horas, minutos, segundos y milisegundos).

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 puede encontrarse y de que sabe cómo solucionarlos. El objetivo es saber cuál es el plan si son las 4 de la tarde de 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.