GuilleSQL :: Microsoft SQL Server, SSIS, y más !!

SIDHistory, SharePoint, STSADM migrateuser, y las migraciones de Directorio Activo


En estos días estoy participando en un proyecto de Migración de Directorio Activo, revisando riesgos e impactos, así como identificando el mejor camino de migración, en lo referente a SharePoint. El alcance del proyecto incluye multitud de dominios origen con presencia en 50 países, que se migrarán y consolidarán en un único dominio destino. Además, existen múltiples Granjas de SharePoint en diferentes versiones, ubicaciones y pertenecientes a diferentes dominios. ¿Funcionará SIDHistory? ¿Cómo migrar los Perfiles de Usuario de SharePoint? ¿Qué pasa con las Alertas y con los campos de tipo People and Groups?

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.

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.

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.

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.

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.

De momento, el usuario original, que antes tenía permisos en el Site, ya no puede entrar. 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.

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.

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í.

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.

 


[Fecha del Artículo (UTC): 06/12/2012]
[Autor: GuilleSQL]


Comentarios

Jay - 20/05/2014 (UTC)
Gracias por el tutorial, está muy completo.

Tengo una duda, que ocurre si después de migrar las cuentas al dominio destino estás se han eliminado del dominio origen. En ese escenario no se podría realizar la migración de cuenta con el STSADM porqué te dice que la cuenta en origen no existe.

¿ Habría alguna otra manera de migrar las cuentas?

gracias

un saludo



Escribir un Comentario

Para poder escribir un comentario, debe Iniciar Sesión con un usuario.

Si no dispone de un usuario, puede Registrarse y hacerse miembro.

Si dispone de un usuario, pero no recuerda sus credenciales de acceso, puede Restablecer su Contraseña.

Miembros de
Miembros de GITCA (Global IT Community Association)

Menu de Usuario
  Iniciar Sesión
  Registrarse
  Restablecer Contraseña
  Ventajas de Registrarse

Acerca de
  Contigo desde Oct 2007
  771 usuarios registrados
  86146 pageloads/mes
  Ranking Alexa 498160

Social Networks
Sigue a Portal GuilleSQL en Linkedin !!
Sigue a Portal GuilleSQL en Twitter !!



Archivo

Marzo de 2017 (3)
Enero de 2017 (4)
Junio de 2016 (1)
Mayo de 2016 (2)
Abril de 2016 (2)
Septiembre de 2015 (2)
Agosto de 2015 (2)
Junio de 2015 (10)
Mayo de 2015 (4)
Abril de 2015 (8)
Marzo de 2015 (11)
Octubre de 2014 (3)
Septiembre de 2014 (7)
Agosto de 2014 (5)
Julio de 2014 (2)
Mayo de 2014 (4)
Abril de 2014 (4)
Marzo de 2014 (4)
Febrero de 2014 (1)
Enero de 2014 (5)
Diciembre de 2013 (8)
Noviembre de 2013 (2)
Octubre de 2013 (7)
Septiembre de 2013 (6)
Agosto de 2013 (1)
Julio de 2013 (6)
Junio de 2013 (11)
Mayo de 2013 (7)
Abril de 2013 (6)
Febrero de 2013 (5)
Enero de 2013 (7)
Diciembre de 2012 (12)
Noviembre de 2012 (13)
Octubre de 2012 (5)
Septiembre de 2012 (3)
Agosto de 2012 (6)
Julio de 2012 (4)
Junio de 2012 (1)
Mayo de 2012 (2)
Abril de 2012 (7)
Marzo de 2012 (16)
Febrero de 2012 (9)
Enero de 2012 (5)
Diciembre de 2011 (10)
Noviembre de 2011 (10)
Octubre de 2011 (4)
Septiembre de 2011 (5)
Agosto de 2011 (2)
Julio de 2011 (2)
Junio de 2011 (4)
Mayo de 2011 (2)
Abril de 2011 (6)
Marzo de 2011 (4)
Febrero de 2011 (10)
Enero de 2011 (5)
Diciembre de 2010 (6)
Noviembre de 2010 (4)
Octubre de 2010 (8)
Septiembre de 2010 (4)
Agosto de 2010 (1)
Julio de 2010 (3)
Mayo de 2010 (5)
Abril de 2010 (6)
Marzo de 2010 (8)
Febrero de 2010 (3)
Enero de 2010 (1)
Diciembre de 2009 (9)
Noviembre de 2009 (14)
Octubre de 2009 (2)
Septiembre de 2009 (8)
Agosto de 2009 (2)
Julio de 2009 (10)
Junio de 2009 (9)
Mayo de 2009 (10)
Abril de 2009 (9)
Marzo de 2009 (3)
Febrero de 2009 (2)
Enero de 2009 (3)
Noviembre de 2008 (2)
Octubre de 2008 (2)
Septiembre de 2008 (2)
Agosto de 2008 (5)
Julio de 2008 (5)
Junio de 2008 (1)
Mayo de 2008 (3)
Abril de 2008 (2)
Marzo de 2008 (2)
Febrero de 2008 (2)
Enero de 2008 (5)
Noviembre de 2007 (2)
Octubre de 2007 (2)






Esta información se proporciona "como está" sin garantías de ninguna clase, y no otorga ningún derecho.
This information is provided "AS IS" with no warranties, and confers no rights.

Copyright © 2007 GuilleSQL, todos los derechos reservados.
GuilleSQL.com y GuilleSQL.net son también parte de Portal GuilleSQL.

Visitas recibidas (Page Loads) en GuilleSQL (fuente: StatCounter):

screen resolution stats
Visitas