En una entrada anterior vimos cómo hacer una migración de contenidos mediante DB Attach, pero efectivamente sólo se limitaba a migrar contenidos a nivel de Web Application. En esta entrada vamos a ver cómo ampliar esa migración, pudiendo realizar también la migración de los perfiles de usuario existentes en la granja de SharePoint 2007 a SharePoint 2010.
Es importante recalcar que este proceso sólo va a migrar los perfiles de usuario, pero no de las conexiones que tengamos configuradas para realizar la sincronización de perfiles. Estas conexiones hay que replicarlas de forma manual (tanto en la migración mediante DB Attach como en la migración en contexto o In Place).
Vamos a ver cómo se realizaría. Supongamos que tenemos una serie de perfiles importados, como muestra la siguiente imagen:
- Paso 1: En la granja actual, localizamos la base de datos que contiene la información de los perfiles de usuario. Por lo general tendría un nombre similar a <Nombre del SSP>_DB. Y realizamos un backup de dicha base de datos:
- Paso 2: Una vez hayamos copiado el fichero de backup a la nueva granja, procedemos a restaurarlo de la siguiente manera:
Es importante el nombre que establezcamos a la base de datos restaurada, puesto que luego ese nombre le usaremos cuando creemos el servicio de User Profile en SharePoint 2010.
- Paso 3: Si teníamos pre-creado el servicio de User Profile, lo eliminamos, junto con las bases de datos, y procedemos a crear uno nuevo que será el que usará la base de datos que acabamos de restaurar:
En la sección de Profile Database, debemos poner a la base de datos el mismo nombre que pusimos cuando la restauramos. Sino, creará una nueva y no se realizará la migración. El resto de las bases de datos las podemos dejar como están:
Una vez que termina el proceso, podemos entrar dentro del servicio para comprobar que efectivamente se ha realizado la migración correctamente:
Recordad, este proceso no migra las conexiones de importación de perfiles de usuario, sólo los perfiles y propiedades que ya estuvieran creados o importados. Manualmente habría que volver a configurar esas conexiones.
Si pensamos realizar una migración únicamente de contenidos de una versión de SharePoint Server 2007 a 2010, y tenemos el caso de que la arquitectura actual es de 32 bits, podemos plantearnos el realizar una migración mediante Database Attach (DB Attach), que básicamente se trata de restaurar una copia de seguridad de la base de datos de contenidos actual en el nuevo sistema.
En los siguientes pasos vamos a ver el caso más simple de restauración, que es cuando únicamente se va a migrar el contenido, sin incluir las personalizaciones.
Escenario:
Supongamos el siguiente escenario, por un lado una granja de SharePoint Server 2007, en una arquitectura de 32 bits, usando Windows Server 2003 y SQL Server 2005. Vamos a suponer además que el idioma de la plataforma de SharePoint es el español.
Por otro lado, la plataforma donde se va a migrar será una granja de SharePoint Server 2010, usando Windows Server 2008 R2 y SQL Server 2008 R2. Toda la plataforma está en Inglés y obviamente la arquitectura es de 64 bits.
Requisitos:
Por un lado necesitaremos tener al menos el Service Pack 2 de SharePoint Server 2007 en la plataforma actual, puesto que vamos a utilizar la herramienta de “preparación a la actualización” (preupgradecheck) incluida en esta actualización para comprobar que nuestro entorno está listo para ser migrado.
Por otro lado, puesto que la aplicación de SharePoint que vamos a migrar está en Español, y la nueva granja está en Inglés, necesitaremos instalar el Language Pack de Español en la nueva granja.
También vamos a dejar la nueva granja actualizada hasta el último Cumulative Update, que a día de hoy es el de febrero, y vamos a instalar para el Language Pack el Service Pack 1.
Pasos:
Vamos a comenzar con el proceso de migración mediante DB Attach.
En la plataforma actual:
1. Ejecutamos la herramienta de preupgradecheck:
2. Analizamos los resultados:
En principio todo el test ha ido bien, salvo los prerequisitos del Sistema Operativo, puesto que no tenemos una arquitectura preparada para instalar Windows Server 2008. El detalle del error en el informe es este:
3. Hacer una copia de la base de datos de contenido:
De la aplicación o aplicaciones que queremos migrar, realizamos una copia de seguridad. En el ejemplo la copia la creo desde SQL Server Management:
4. El fichero de Backup lo dejamos en una ubicación de red para poder acceder a él desde la nueva plataforma.
De esta forma ya estaría lista la copia del contenido que se quiere migrar.En la nueva plataforma:
Si ya tenemos la plataforma lista (con el Language Pack si es necesario, y las últimas actualizaciones) lo ideal sería copiar el archivo de Backup dentro de la misma máquina de SQL Server 2008, para evitar que un corte de red pueda complicar la migración. Una vez que tenemos el backup copiado (una ver terminada la migración se puede eliminar dicho backup), procedemos a realizar la migración.
1. Desde SQL Server Management Studio restauramos la copia:
Para ello, sobre la carpeta de Databases, hacemos clic derecho y seleccionamos la opción de Restore Database:
Indicamos un nombre de base de datos que no exista, y seleccionamos el fichero de backup que hemos copiado:
2. Desde la Administración Central de SharePoint, creamos una nueva Web Application, pero teniendo en cuenta que el nombre de la base de datos que pongamos no debe coincidir con el que hemos puesto a la base de datos migrada. Nos vale la de por defecto, WSS_Content:
Una vez creada la Web Application, no debemos crear ningún Site Collection, ya que el proceso de migración va a crear los necesarios.
3. El siguiente paso es bastante importante. Vamos a lanzar un test para verificar que a la base de datos restaurada no le falta ninguna dependencia en la Web Application que acabamos de crear. Para realizar el test usamos Test-SPContentDatabase, pasando el nombre de la base de datos, y la Web Application donde va a ser migrada:
Aparece un error causado por una dependencia, que es la de “Microsoft.Office.Excel.WebUI.dwp”, pero es debido a un problema con ese WebPart, y podemos ignorarla. Cualquier otro error debería ser resuelto antes de proceder a la migración.
4. Montar la nueva base de datos en la aplicación creada:
Desde una consola de PowerShell, y en modo administrador, desmontamos la base de datos que se ha creado al crear la Web Application, que es la WSS_Content:
Seguidamente, montamos la base de datos migrada en la Web Application, y esperamos a que termine:
Tanto si ha ido bien como si no, podemos ejecutar el siguiente comando que nos dará información de los problemas que puede haber con la base de datos montada. Si no aparece resultado, es que no hay problema:
De esta forma estaría terminada la migración. Sólo nos quedaría navegar al sitio para ver que está correcto (si tenéis algún problema al iniciar sesión en el sitio, probad a hacer un iisreset):
Obviamente, el aspecto de la aplicación sigue siendo el de la versión de SharePoint 2007. Si queremos cambiar el aspecto para que tenga la apariencia de SharePoint 2010, incluyendo la cinta Ribbon, basta con hacer la “Actualización visual”. Para ello:
De esta forma ya tendría la apariencia de SharePoint 2010:
Este es el caso de migración de contenido más simple, puesto que no se ha migrado código a medida ni personalización de estilos. Os recomiendo leer la información oficial antes de comenzar a planear cualquier migración, puesto que dependiendo del entorno y de la aplicación a migrar puede que deba realizarse siguiendo otra serie de pasos. Podéis consultar:
http://technet.microsoft.com/en-us/sharepoint/ee517214
http://technet.microsoft.com/library/cc303420(office.14).aspx
Una de las aproximaciones que existen a la hora de realizar una migración de SharePoint 2007 a 2010 es la migración en contexto, o migración in place. Básicamente se trata de instalar la versión de SharePoint 2010 sobre la misma instalación de SharePoint 2007. Esto tiene por un lado sus ventajas y sus inconvenientes, por ejemplo, una ventaja sería que la mayoría de las configuraciones de los servicios se migrarán con este método (administración de búsquedas, perfiles de usuario, etc.), pero en contra nos encontraremos con que durante este proceso la granja no estará disponible, y seguramente cuando se termine la migración tampoco, puesto que hay que realizar unas tareas de revisión y solución de imprevistos que siempre puede haber.
Lo fundamental para poder realizar este proceso, es disponer de la plataforma requerida. Por un lado, debe ser una arquitectura de 64 bits, con Windows Server 2008, y SQL Server 2008 o en su defecto Windows Server 2005 SP3.
![image_thumb[70]](http://lh5.ggpht.com/-b2USFrjw4tg/T40hdnfJyjI/AAAAAAAACBk/ueUonsoD6Rw/s1600-h/image_thumb%25255B70%25255D%25255B3%25255D.png "image_thumb[70]")
A continuación vamos a ver el proceso de una migración sencilla de un servidor de SharePoint 2007 a 2010.
- Paso 1: Ejecutar la herramienta de preupgradecheck para comprobar que el entorno está listo para la migración. Para ellos ejecutamos stsadm –o preupgradecheck:
Revisamos el fichero de log generado. En nuestro caso vamos a realizar la migración de una Web Application que además tiene MySite en otra Web (puertos 80 y 44444):
Además tenemos configurado el servicio de búsqueda con alguna regla creada y tenemos unos 49 perfiles en el servicio de User Profile.
Nos aseguramos de tener un backup de la granja por si acaso la operación no se realiza correctamente y necesitamos volver a la versión actual.
- Paso 2: Instalación de los pre-requisitos de SharePoint Server 2010. Durante el proceso es posible que nos pida reiniciar la máquina. Este paso habría que realizarle en cada servidor de la granja.
- Paso 3: Instalar SharePoint Server 2010, actualizando las versiones anteriores.
Cuando comience la instalación, el producto detectará que hay una versión anterior y sólo nos permitirá realizar la actualización:
Una vez terminada la instalación podemos ejecutar el asistente de configuración:
Indicamos que la actualización visual no deseamos realizarla en este momento:
Si por ejemplo tenemos instalado un Language Pack en la versión actual, y antes de lanzar el Wizard de configuración no hemos instalado su correspondiente en la versión 2010, nos aparecerá un error como el siguiente, y la configuración se detendrá:
En tal caso, instalamos el Language Pack, y cualquier otro componente necesario, y volvemos a ejecutar el Wizard de configuración:
Una vez que finalice, veremos una pantalla de resumen similar a la siguiente, donde se indica que el proceso de actualización aún no ha finalizado. Se debe abrir la administración central (lo normal es que al cerrar el resumen anterior se abra automáticamente) para ver el estado de la actualización:
Desde la Administración Central podemos ver que se está realizando la actualización:
Este proceso lo dejamos hasta que finalice. La propia pantalla se irá refrescando cada poco tiempo para mostrar el estado de la actualización:
Una vez finalizado, comprobamos que las Web Applications se han migrado correctamente:
Debemos revisar que los servicios de aplicación también. Observad que los servicios migrados se han creado con un prefijo en su nombre, que coincide con el nombre del servicio compartido de la versión anterior (SSP1):
Podemos revisar también cómo han quedado las Bases de Datos:
Por supuesto, ahora hay que realizar una revisión de la plataforma, la navegabilidad de las aplicaciones migradas para ver que todo el contenido es correcto, y una revisión de los logs y visores de eventos para validar y depurar posibles problemas que existan en la migración.
Esta migración ha sido muy simple, puesto que no hay código personalizado ni otros elementos que hagan más compleja la migración. De todas formas, siempre es necesario revisar la documentación que ofrece Microsoft para realizar todo el proceso. Estos enlaces me sirvieron de utilidad:
http://technet.microsoft.com/en-us/sharepoint/ee517214
http://technet.microsoft.com/library/cc303420(office.14).aspx
