Implementación de SharePoint 2010: Prepárese para la actualización a SharePoint 2010
Puede ser tentador pasar directo a una actualización de SharePoint 2010, pero esto requiere de una considerable planificación. Este artículo lo guiará a través del proceso de planificación de la actualización.
Brien Posey
Actualizarse a SharePoint 2010 será diferente de cualquier otra actualización que haya hecho antes. Incluso antes de comenzar el proceso de planificación para su actualización, necesita familiarizarse con los requisitos del sistema para SharePoint 2010. A diferencia de versiones anteriores de SharePoint, SharePoint 2010 es sólo para 64 bits. Por ello, tendrá que instalar SharePoint 2010 sobre una versión de 64 bits de Windows Server 2008 o Windows Server 2008 R2.
SharePoint necesita una base de datos de un servidor SQL, pero esa base de datos no tiene que residir en el mismo servidor que SharePoint. SharePoint 2010 aún necesita un servidor SQL pero Microsoft ha realizado algunos cambios importantes. SharePoint 2010 necesita que la base de datos se ejecute en una edición de 64 bits de SQL Server 2005 ó 2008. Esto se aplica si la base de datos se instala de manera local en el servidor SharePoint o no.
Aunque no es técnicamente un requisito del sistema, puede considerar los exploradores web que utiliza. SharePoint2010 está diseñado para hacer un mejor uso de los estándares web. Esto significa que los usuarios deberían tener una experiencia coherente sin importar si están usando Internet Explorer o Firefox (3.x o una versión posterior). Una advertencia para esto es que SharePoint 2010 tiene una compatibilidad limitada para Internet Explorer 6. Los usuarios de IE6 no deberían tener ningún problema para ver el contenido de SharePoint, pero la creación de contenidos requiere de IE7 o una versión posterior (o Firefox 3.x o posterior).
Actualizaciones locales
Como puede haber escuchado, SharePoint 2010 permite actualizaciones locales desde Microsoft Office SharePoint Server (MOSS) 2007. Pero como SharePoint 2010 es de 64 bits, sólo puede realizar una actualización local si su MOSS 2007 existente se está ajecutando sobre una versión de 64 bits de Windows Server 2008. Si sus servidores SharePoint existentes cumplen con los requisitos necesarios del sistema, puede realizar una actualización local en cada servidor SharePoint de su granja.
Aunque SharePoint es totalmente compatible con esas actualizaciones, sólo recomendaría una actualización local si tiene una implementación sencilla de SharePoint y no ha hecho ninguna personalización. Se recomiendan migraciones completas en entornos más complejos porque hacerlo así le entrega un alto grado de control sobre el proceso de actualización. También son recomendables para entornos en los que ha hecho personalizaciones, para que no sobrescriba accidentalmente esas personalizaciones.
Una migración normalmente involucra crear una granja SharePoint completamente nueva ejecutando SharePoint 2010. Después de hacer eso, puede adjuntar sus bases de datos existentes de SharePoint a la nueva granja. También puede usar una estrategia de migración híbrida, que combina actualizaciones locales y servidores SharePoint 2010 completamente nuevos.
Proceso previo de actualización
Sin distinguir si está haciendo una actualización local o migración, necesitará hacer alguna planificación y preparación antes de comenzar realmente el proceso. Ejecutar el verificador de actualización previa es uno de los pasos más importantes en la preparación de la actualización a SharePoint 2010. Antes del lanzamiento de MOSS 2007, Microsoft entregó la utilidad Prescan.exe que lo ayudaba a asegurarse que su implementación SharePoint estaba en un buen estado antes de actualizar MOSS 2007.
Mientras que Prescan.exe era una buena herramienta en sus días, no es realmente apropiada para un análisis de implementación previa para SharePoint 2010. Siendo ese el caso, Microsoft proporcionó una nueva herramienta llamada el verificador de actualización previa. El verificador de actualización previa es una enorme mejora sobre Prescan.exe. Para comenzar, el verificador de actualización previa es sólo de lectura, por lo que no tiene que preocuparse de hacer cambios en sus servidores de SharePoint.
Lo que hace realmente útil el verificador de actualización previa es que hace un trabajo de detección de problemas mucho más completo que su predecesor Prescan.exe. También es extensible. El verificador de actualización previa viene con un conjunto de reglas que utiliza cuando analiza sus servidores SharePoint. Esas reglas están en formato XML, lo que significa que puede crear sus propias reglas personalizadas en el caso que fuese necesario. Usar reglas basadas en XML también hace más fácil para Microsoft actualizar el verificador de actualización previa si cambiaran alguna vez las prácticas recomendadas.
Posiblemente lo mejor sobre el verificador de actualización previa, sin embargo, es la información que compila. Aunque Microsoft diseñó el verificador de actualización previa como una herramienta de preparación para una actualización a SharePoint 2010, algunas organizaciones lo están usando para otros propósitos. Una compañía usa en realidad el verificador de actualización previa como parte de su plan de recuperación de desastres . La utilidad en realidad no hace nada para ayudar a rescatar a un servidor SharePoint fallido, pero la información que recopila puede ser de valor incalculable si alguna vez tiene la necesidad de reconstruir una implementación SharePoint (sólo asegúrese de ejecutar la herramienta antes que aparezca el error).
De manera similar, otra organización ha usado el verificador de actualización previa como una herramienta para asegurarse que sus servidores de SharePoint 2010 estén configurados de una manera coherente. Al ejecutar el verificador de actualización previa en cada uno de sus servidores de SharePoint, puede comparar los informes de cada servidor y buscar cualquier elemento de configuración individual que no se adhiera a la directiva corporativa.
Entonces, ¿dónde puede obtener el verificador de actualización previa? Es posible que usted ya lo tenga. Microsoft incluye el verificador de actualización previa en MOSS 2007 SP2. Pero de manera contraria a lo que esperaba, el verificador de actualización previa no es una herramienta independiente. En vez de eso, Microsoft lo incluye en la utilidad STSADM.EXE. Por cierto, después de aplicar SP2, tuve que reiniciar mi servidor de prueba un par de veces antes de que Windows me permitiera tener acceso a la nueva funcionalidad STSADM.EXE.
Dicho esto, quiero mostrarle cómo funciona el verificador de actualización previa. Como mencioné anteriormente, el verificador de actualización previa funciona analizando un archivo de reglas basado en XML, y después usando esas reglas para analizar su implementación de SharePoint. El verificador de actualización previa viene con un conjunto de reglas incluido. Estas reglas, que están basadas en el analizador de prácticas recomendadas, existen dentro de un archivo llamado OssPreUpgradeCheck.xml. Puede tener una idea de cómo se ve este archivo en la Figura 1.
Figura 1 El verificador de actualización previa usa un archivo de reglas basado en XML.
Cuando se invoca el verificador de actualización previa, no necesita llamar explícitamente este archivo de reglas. El verificador de actualización previa lo llamará de manera predeterminada. Tiene la opción de usar archivos de reglas personalizados. La sintaxis completa del verificador de actualización previa es la siguiente:
STSADM.EXE –O PreUpgradeCheck
[[-RuleFiles “<rule file name>”] [-ListRuleFiles]] [-LocalOnly]
Como puede ver en la sintáxis anterior, los únicos parámetros que se necesatan son –O y las palabras PreUpgradeCheck. El parámetro –RuleFiles es opcional y sólo se usa si desea especificar manualmente un archivo de reglas para ser utilizado. De la misma manera, puede usar el parámetro –ListRuleFiles para mostrar los archivos de reglas que tiene disponibles. Finalmente, puede usar el parámetro –LocalOnly para ejecutar las reglas sólo con el servidor local de SharePoint.
Para darle una mejor idea sobre cómo funciona el verificador de actualización previa, vea la Figura 2. Como puede ver en la figura, comencé abriendo una ventana de símbolo de sistema y exploré a través de la estructura de directorios hasta C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN. Desde allí, ejecuté el siguiente comando:
STSADMIN.EXE –O PreUpgradeCheck]
.jpg)
Figura 2 El verificador de actualización previa prueba su implementación de SharePoint.
Como puede ver en la Figura 2, el verificador de actualización previa realiza varias pruebas diferentes con la implementación de SharePoint. Los resultados de cada prueba están codificados en colores. El rojo indica una prueba con error y el verde indica que su servidor ha pasado la prueba. Los elementos de información se indican en amarillo.
Obviamente, el resultado del verificador de actualización previa no se explica detalladamente. La captura de pantalla en la Figura 2 sólo le indica si ha pasado una prueba o si tiene error; no obtiene ninguna información más detallada. Sin embargo, si mira en la parte inferior de la captura de pantalla, notará que hay un mensaje que indica que puede revisar los resultados en un archivo HTML que está ubicado en la carpeta C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Logs.
Cada vez que ejecuta el verificador de actualización previa, este crea tres archivos de registro separados. Uno de esos registros es el archivo HTML al que se hace referencia al final de la verificación de actualización, pero también hay un archivo LOG y un archivo XML. Puede usar cualquiera de esos archivos de registro, pero el erchivo HTML es el más fácil de leer.
Como se mencionó anteriormente, el verificador de actualización previa, compila mucha información. Por lo tanto, no debe ser una sorpresa que los registros resultantes sean muy largos para incluirlos en su totalidad. Sin embargo, puede tener alguna idea de cómo se ven los registros HTML en la Figura 3.
.jpg)
Figura 3 Los resultados de la verificación de actualización previa se pueden ver usando un explorador web.
Identifique sus personalizaciones
Otro paso crítico en el proceso de planificación de actualización es identificar cualquier personalización que ha hecho a sus servidores de SharePoint. Sin distinguir si está realizando una actualización local o migración, es fácil sobrescribir accidentalmente sus personalizaciones. Por lo tanto, debe documentar sus personalizaciones y hacer una copia de seguridad de esos archivos para que se puedan aplicar nuevamente después de la actualización, si surge la necesidad.
Afortunadamente, ha documentado exhaustivamente todas sus personalizaciones a medida que su entorno SharePoint ha evolucionado. De manera realista, puede ser difícil mantener un seguimiento de todos los cambios. Por lo tanto, tómese un tiempo para revisar su registro de personalización aun si piensa que todas sus personalizaciones están bien documentadas. Desafortunadamente, SharePoint no incluye ninguna herramienta para identificar las personalizaciones. Pero esto no significa que tendrá que revisar manualmente cada archivo de su servidor de SharePoint.
Una manera para obtener información sobre las personalizaciones es usar una técnica llamada “diffing” (diferenciación). La idea tras esta técnica es que puede configurar un servidor stock MOSS 2007 (asegurarse de que está ejecutando los mismos parches que sus servidores de producción) y después usar un programa diferenciador para ver qué archivos de sus servidores de producción son diferentes de un servidor SharePoint en estado original.
Microsoft recomienda usar WinDiff, pero existen varias utilidades de diferenciación disponibles, muchas de las cuales tienen características más completas que WinDiff.
Pruebe el proceso de actualización
Mientras se prepara para hacer la transición a SharePoint 2010, finalmente habrá un punto en el que desarrolla un plan acerca de cómo realizar la actualización. Suponiendo que ha tomado las medidas para cualquier problema informado por el verificador de actualización previa, entonces el proceso de actualización debería marchar relativamente sin problemas. Sin embargo, realmente no debe dejar nada al azar.
Implemente MOSS 2007 en un entorno de laboratorio aislado y pruebe su plan de actualización en laboratorio antes de tratar de hacer la actualización en sus servidores de producción. Usar un laboratorio puede ayudarle a familiarizarse con el proceso de actualización, así como identificar problemas que se pueden presentar cuando llegue el momento de la verdadera actualización.
El mejor enfoque en empresas pequeñas o medianas (SMB) es configurar algunos servidores virtuales, y después restaurar copias de seguridad de sus servidores de producción a los servidores de laboratorio. Esto le permitirá probar su plan de actualización en un entorno que es prácticamente igual a su entorno de producción.
En organizaciones más grandes, es probable que no resulte práctico crear un duplicado exacto de la implementación de producción de SharePoint. En esas situaciones, puede configurar un entorno en menor escala de una manera similar a su implementación de producción. También puede tratar de restaurar copias de seguridad de algunos, pero no de todos sus servidores de SharePoint, a un entorno de laboratorio. Aunque este enfoque puede parecer que deja mucho al azar, recuerde que probablemente no convertirá la implementación completa de una sola vez a SharePoint 2010; deseará enfocar su implementación en un área cada vez.
Verifique sus copias de seguridad
El último paso antes de comenzar una actualización a SharePoint 2010 es verificar que sus copias de seguridad estén funcionando correctamente. Justo esta semana, tuve que ayudar a una persona que pensó que había hecho diligentemente las copias de seguridad de sus servidores, pero que supo por el camino difícil que sus copias de seguridad eran inadecuadas. No permita que esto le ocurra. Compruebe sus copias de seguridad, y asegúrese que se pueden restaurar.
.jpg)
Brien Posey,** MVP, es autor técnico independiente con miles de artículos y docenas de libros a su haber. Puede visitar su sitio web en brienposey.com.