En estos momentos, el alcance del proyecto se limita a la migración de usuarios y grupos, los cuales, deberán mantener sus permisos y contenidos en SharePoint, con todo lo que esto implica, para lo cual he estado preparando este Laboratorio de Migración (las pruebas, con gaseosa ;-).

En un futuro, una vez finalizada la migración de usuarios y grupos, se realizará la migración de los recursos, sean Shares, bases de datos de SQL Server, Sitios de SharePoint, o cualquier otro tipo de recurso utilizado por los usuarios. Sin embargo, esa fase de proyecto, de momento se encuentra lejana en la ubicación temporal del Project de marras.

En cualquier caso, aunque un poco más adelante lo dejo claro, comentar desde ya que el presente artículo sólo comprueba la migración de usuarios, y no la migración de grupos (esto, para la próxima entrega).

Descripción del Marrón… digo… del Escenario de Migración

Partimos de un escenario formado por dos Bosques de Directorio Activo, entre los cuales se ha creado una relación de confianza bidireccional con el filtrado de SID deshabilitado, para permitir la utilización de SIDHistory. Ambos dominios tienen un único Controlador de Dominio ejecutando Windows Server 2003 R2. Además, ambos dominios están en Modo Nativo (Windows Server 2003). Por supuesto, está configurada correctamente la resolución de nombres DNS, abiertos los puertos de FW, y demás historias.

En el dominio origen, existe una Granja de SharePoint 2007 SP3, edición Enterprise, que ofrece el servicio de Intranet Corporativa. En consecuencia:

• Existen multitud de Colecciones de Sitios y SubSitios, cada uno con sus correspondientes elementos (ej: Librerías de Documentos, Listas, Workflows, Formularios de InfoPath, etc.). En consecuencia, los usuarios pueden ser propietarios o tener concedidos permisos en diferentes niveles, ya sea por su pertenencia a grupos o directamente al usuario, que deben mantener al migrar el usuario al nuevo dominio.
• Se está utilizando la importación de perfiles de usuario desde Directorio Activo, que implica que los usuarios pueden modificar algunas propiedades de su perfil que son importadas desde Directorio Activo, como por ejemplo la foto. En consecuencia, se debe mantener el valor de estas propiedades en el perfil de la cuenta de usuarios del nuevo Dominio.
• Muchos usuarios se han configurado Alertas en multitud de Listas y Bibliotecas, con el objetivo de ser avisados de la creación y modificación de documentos y elementos de lista. Por lo tanto, se desea poder mantener esta configuración de Alertas en la cuenta del usuario del nuevo dominio al realizar la migración.
• Campos de tipo People and Groups. Muchas aplicaciones en SharePoint (ej: Listas de Tareas) utilizan un campo de tipo People and Groups, de tal modo que, siguiendo con el ejemplo de las Tareas, se pueda asignar una Tarea a un Usuario. En consecuencia, al migrar un usuario al nuevo dominio, debería garantizarse que el contenido de este tipo de campos se asigna al nuevo usuario del nuevo dominio.

En el dominio de origen también existe un Cluster de Exchange Server 2003, en el cual se hospedan los buzones de los usuarios. En el presente laboratorio no incluiremos las tareas correspondientes de Exchange, tan sólo comentar, que el usuario mantendrá su dirección de correo electrónico.

Para empezar a poner nombres y apellidos a las cosas, el dominio de origen es GUILLESQL (guillesql.local) y el dominio destino es YOLINET (yolinet.local).

Objetivos y Alcance del presente Laboratorio de Migración

El alcance del presente artículo se limita sólo a los usuarios de Directorio Activo, quedando fuera de Alcance la migración de los grupos. Es consecuencia se tratará de comprobar la forma de migrar usuarios desde un dominio origen a un nuevo dominio. Al margen, del mismo modo que se hace en muchos proyectos de migración, la migración de los recursos es un paso que se realizará más adelante, por lo tanto, de momento no nos preocuparemos de este tema tampoco, que también queda fuera de Alcance.

Cara a realizar la migración de los usuarios, lo primero que deberemos comprobar, es si funciona o no el atributo SIDHistory de los usuarios con SharePoint. Como sabemos, el SIDHistory no es ni de lejos una solución definitiva, pero sin embargo, se presenta como una solución temporal de gran ayuda para acometer los proyectos de Migración de Directorio Activo, eso sí, con sus cosas, ya que es un agujerito de seguridad, y además no todas las aplicaciones lo soportan.

En nuestro Laboratorio de Migración, vamos a migrar los usuarios con ADMT utilizando SIDHistory y deshabilitando el filtrado de SID (SID filtering) en la relación de confianza, ya que además de SharePoint hay muchos más recursos a los que acceden los usuarios, por lo que seguro que podremos aprovechar las bondades y virtudes del SIDHistory (por ejemplo, recordemos que SQL Server soporta SIDHistory).

Téngase en cuenta que la migración no será de tipo BigBang, una locura, al estar hablando de una infraestructura formada por decenas de miles de usuarios. Por el contrario, se tratará de una migración escalonada, que en un principio se realizará oficina a oficina, y según avancen los acontecimientos, pues ya se verá.

Con todo esto, en nuestro Laboratorio de Migración aprovecharemos para comprobar empíricamente si funciona o no el SIDHistory con SharePoint, así como también comprobaremos la utilización del comando STSADM migrateuser y su comportamiento con las problemáticas que hemos comentado previamente (Permisos, información de Perfiles de Usuario, Alertas, y los campos de tipo Users and Groups). Eso sí, en el presente artículo, nos limitaremos a probar la migración de usuarios, pero no de los grupos.

No más rollos. Empezamos.

Ahora toca darle caña: Si no lo veo, no me lo creo (motos las justas)

Lo primero es comprobar si el atributo SIDHistory de los usuarios de Directorio Activo funciona o no con SharePoint, para lo que intentaremos acceder a SharePoint utilizando el usuario migrado del nuevo dominio, y cómo podemos comprobar, el SIDHistory no funciona con las cuentas de usuario en SharePoint. Access Denied. Tá claro.

A nivel de SQL Server, en cada Base de Datos de Contenido, existe una tabla UserInfo que contiene alguna información de los usuarios con permisos en las Colecciones de Sitio almacenadas en dicha Base de Datos de Contenido. En nuestro caso de ejemplo, para nuestro Laboratorio, tenemos una Base de Datos de Contenido sobre la que hemos creado dos Colecciones de Sitio, sobre las cuales tiene permisos el usuario que vamos a migrar.

En un servidor SharePoint, ejecutaremos el comando STSADM migrateuser para migrar los usuarios. Es importante utilizar la opción ignoresidhistory del STSADM migrateuser, al menos en nuestro caso.

Si volvemos a consultar la tabla UserInfo, ya no aparece la información del usuario original, y en su lugar, aparece la información del usuario correspondiente en el nuevo dominio. ¿Funcionará? Vamos a verlo.

De momento, el usuario original, que antes tenía permisos en el Site, ya no puede entrar, y como vimos antes, no hay restos de dicho usuario, así que, como por algún motivo tampoco pueda entrar el nuevo usuario, estonces podríamos estar algo jodidillos. Uff. Los pelos como escarpias.

Sin embargo, con el usuario del nuevo Dominio, podemos acceder satisfactoriamente al Site. Genial, esto pinta bien. Además, podemos comprobar que una Tarea que habíamos creado y asignado antes al usuario original (GUILLESQL\testMig), ahora aparece asignada al nuevo usuario (YOLINET\testMig). Bien. Esto mola.

Ahora vamos a comprobar las Alertas. Antes de la migración del usuario, creamos una Alerta para el usuario original (GUILLESQL\testMig). Ahora, una vez que hemos migrado el usuario nos surge la duda, de si la Alerta que habíamos creado estará asignada al nuevo usuario, con el hemos iniciado sesión en el Site, y la respuesta es que SI !!! Mola.

De momento, hasta ahora pinta bastante bien. Sin embargo, aún nos queda una de las cosas que más incertidumbre me genera: la información de los perfiles de usuario, en particular, las propiedades que NO se importan desde Directorio Activo y que son alimentadas por los propios usuarios. Antes de migrar el usuario en SharePoint con el comando STSADM migrateuser, teníamos configuradas dos conexiones de importación desde Directorio Activo, para importar los perfiles de los usuarios del dominio original (GUILLESQL) y del nuevo dominio (YOLINET). De hecho, teníamos ya importados los dos perfiles, el de GUILLESQL\testMig y el de YOLINET\testMig, con la única diferencia que el usuario original tenía rellenada a mano la propiedad About Me. ¿Será capaz el comando STSADM migrateuser de actualizar también la información del perfil del usuario en SharePoint? Pues parece sí.

Despedida y Cierre

La realidad, es que la experiencia de este Laboratorio ha sido muy positiva, aunque la realidad es que aún no hemos acabado (es decir, habrá más artículos), por lo que todavía es pronto para tener claras-claras las conclusiones. Recordemos que este artículo sólo incluía en alcance las cuentas de usuario, y los grupos quedaban fuera de alcance (para la próxima entrega).

[Actualizado 16/12/2012] SIDHistory, SharePoint, STSADM migrategroup, y las migraciones de Grupos de Directorio Activo

En principio, empezaba todo bastante mal. El SIDHistory no funcionaba, y además, había varios puntos de riesgo (Permisos, información de Perfiles de Usuario, Alertas, y los campos de tipo Users and Groups). Por si fuera poco, los primeros intentos con el comando STSADM migrateuser han generado error, hasta que hemos utilizado el parámetro ignoresidhistory. Sin embargo, superado todo esto, al realizar el Laboratorio de Migración, el resultado ha sido el mejor de los posibles. Todo lo que hemos probado, ha funcionado a la perfección, incluyendo el tema de la información de los Perfiles de Usuario.

STSADM migrateuser mola. Sin embargo, aún me pitan algunas cosas, y hay detalles que hay pulir algo más, para conseguir un Plan de Migración real y con el que nos sintamos seguros, antes de aplicarlo a un entorno de producción crítico, como el que aplica en mi caso.

Poco más por hoy. Como siempre, confío que la lectura resulte de interés.