Si ha pasado tiempo con FIM, sabrá, y si no, pronto aprenderá que migrar la configuración de un Servicio FIM de un entorno a otro puede ser muy difícil.
Aunque Microsoft proporciona un procedimiento, algunas secuencias de comandos y algunas primitivas de PowerShell subyacentes para ayudar en el proceso, la solución sugerida asume que se va a migrar una configuración completa y que no es necesario gestionar varias configuraciones. Para ser justos, lo que Microsoft proporciona es sólo un punto de partida sugerido.
En esta entrada del blog, hablaré de un procedimiento que hemos elaborado en CSS que mejora el proceso de migración. Ciertamente no hemos resuelto todos los problemas, pero esperamos que lo que hemos hecho te resulte útil para crear tu propio proceso de migración del Servicio FIM.
Si lee el artículo de TechNet sobre la migración de la configuración FIM, se habla de hacer copias de seguridad de las bases de datos, extraer la configuración del Servicio FIM y del Motor de sincronización, copiar el flujo de trabajo del Servicio FIM y las DLL de extensión del Motor de sincronización, comparar las configuraciones del Servicio FIM e importar los cambios del Servicio FIM en el sistema de destino. Muchos de estos pasos son importantes (especialmente la copia de seguridad), pero no se tratan en este post. Sólo voy a hablar de la migración del esquema y la política en el propio Servicio FIM. Por favor, tómese su tiempo para leer el artículo de TechNet (enlazado arriba y abajo).
Para ayudar con los problemas de gestión de múltiples configuraciones, hemos actualizado los scripts de PowerShell para crear y trabajar desde directorios que contienen configuraciones individuales. Al automatizar la creación de directorios relacionados con las configuraciones, reducimos los errores que pueden producirse al copiar y renombrar manualmente los archivos, como es necesario al utilizar el proceso de migración de configuraciones de stock.
El primer paso es obtener los scripts y la herramienta delta. Están disponibles aquí. Descomprima los archivos en un directorio llamado "FIM Service Migration" o similar. Haga esto tanto en su máquina de desarrollo como en la de producción (o en cualquier entorno entre el que esté migrando).
A continuación, ejecute el script ExportConfig.ps1 en ambos entornos. Este script combina las funciones de los scripts ExportSchema y ExportPolicy originales y coloca los archivos de exportación resultantes en un subdirectorio nombrado con la fecha y hora actuales. Tenga en cuenta que, al igual que con los scripts originales de Microsoft, debe ejecutarlo como una cuenta que esté en el conjunto de "administradores" del servicio FIM. Si no lo hace, no obtendrá una exportación completa de la configuración.
Como el directorio creado por el script ExportConfig representa una configuración del Servicio FIM para un entorno específico en un momento determinado, querrá cambiar el nombre del directorio por algo que sea más significativo para usted. Yo recomendaría incluir al menos el nombre del entorno y una marca de tiempo o un número de versión. En este ejemplo, voy a cambiar el nombre de la exportación anterior (de la máquina de desarrollo) a "Dev-20140429" para indicar que se trata de la configuración del entorno de desarrollo a partir del 29 de abril. En la máquina de producción, haré lo mismo pero utilizaré el nombre de directorio "Prod-20140429". Copie el directorio de la máquina de desarrollo a la máquina de producción para que ambos directorios estén en la máquina de producción. En la máquina de producción, debería tener algo como:
A continuación, ejecute el script DiffConfig.ps1. Este script combina las funciones de los scripts SyncSchema y SyncPolicy originales. En lugar de pedirle que renombre los archivos de exportación a pilot.xml y production.xml para cada extracto de esquema y política (y pedirle que recuerde qué archivos son cada uno), el script DiffConfig toma los nombres de directorio de los pasos anteriores como parámetros. El parámetro SourceDirectory es la nueva configuración que quieres aplicar en algún lugar (en nuestro caso el entorno de desarrollo) y el parámetro TargetDirectory es la configuración sobre la que queremos aplicar la configuración fuente (en nuestro caso producción). Queremos aplicar el origen al destino (haciendo así que el destino se parezca al origen).
El script calculará qué cambios son necesarios en el destino y creará un conjunto de archivos de cambios. Estos archivos se colocan en un nuevo directorio que se llama "Diff-" seguido de los nombres de los directorios de origen y destino.
El script utiliza las mismas técnicas (cmdlets de automatización FIM PowerShell) que los scripts originales de Microsoft y presenta los mismos problemas. Si tiene instancias de objetos que tienen nombres de visualización no únicos o si ha creado tipos de recursos personalizados, es posible que tenga que limpiar sus datos o editar las reglas de unión dentro del script (para el caso, el proceso de exportación anterior puede tener problemas similares si hay referencias no válidas en su configuración o si tiene valores de cadena que "parecen" referencias a los cmdlets de automatización).
Mirando en el directorio resultante, ahora tenemos:
Aparte de los nombres de archivo, estos archivos son los mismos que los archivos changes.xml que los scripts SyncSchema y SyncPolicy de stock habrían proporcionado. Si supiéramos que queremos aplicar todos los cambios que se calcularon, podríamos simplemente aplicar estos archivos al entorno de producción y listo.
Pero, ¿y si tenemos cosas en el entorno de desarrollo que no queremos pasar a producción?
En nuestro ejemplo, el entorno de desarrollo contiene algunos tipos de recursos adicionales que se crearon inadvertidamente. En el Servicio FIM, una vez que se crea un nuevo tipo de objeto y se utiliza, no se puede eliminar, por lo que esto puede convertirse en un problema si no se desea tener material extra en producción. Nuestra configuración también incluye algunos conjuntos con pertenencia manual. Las personas colocadas en los conjuntos del entorno de desarrollo no estarán presentes en producción, por lo que si no hacemos algo especial, el proceso de migración intentará crear los usuarios de desarrollo en producción o se quejará de que no puede encontrar los usuarios correspondientes.
Tradicionalmente, para corregir esto había que abrir el archivo changes.xml y editar los objetos que no se querían pasar a producción. Además, si sólo quería ver los cambios exactos que estaban a punto de ser enviados a producción, tendría que inspeccionar a mano el archivo de cambios. Inspeccionar y editar el archivo de cambios es difícil y propenso a errores, ya que identifica internamente los objetos por sus ID de recursos de estilo GUID y muchos objetos contienen referencias a otros objetos. La edición incorrecta de un objeto o la ruptura de una cadena de referencias puede provocar fallos de importación más adelante en el proceso.
Hace aproximadamente un año, un caballero llamado Alex Skalozub publicó una herramienta estupenda en GitHub llamada "FimDelta". Esta herramienta muestra el contenido de un archivo de cambios en una estructura de árbol gráfica y te permite eliminar los elementos que no deseas pasar a producción. Los cambios pueden excluirse a nivel de objeto o atributo. La herramienta también permite navegar fácilmente por las referencias y relaciones entre objetos. Incluso si no va a excluir objetos de su rollo de producción, es una gran herramienta para simplemente ver cuáles son los cambios.
Por alguna razón, la herramienta no parece ser muy utilizada. La mayoría de nuestros clientes no han oído hablar de ella. Puede que se deba a que la herramienta es un poco difícil de poner en marcha, ya que requiere copiar y renombrar los archivos de extractos de origen y destino, así como el archivo de cambios, en el directorio en el que está instalada la herramienta.
Para facilitar su uso e integrarla en nuestro proceso de migración, he actualizado la herramienta. He añadido la posibilidad de pasar los nombres de archivo que necesita en la línea command y he añadido menús tradicionales de "archivo" para que desde dentro de la herramienta pueda navegar y abrir los archivos que necesita, así como especificar el nombre y la ubicación del archivo de cambios de salida. También he añadido la posibilidad de guardar y restaurar las "exclusiones" o las cosas que no desea migrar. Esto puede ahorrar tiempo si usted necesita hacer varias migraciones.
La herramienta actualizada se incluye junto con las secuencias de comandos de migración en el enlace anterior y el código fuente actualizado está disponible en GitHub (como con todas las cosas gratis, el uso bajo su propio riesgo, sin garantía, etc.).
Echemos un vistazo a la herramienta y veamos cómo excluir los cambios de esquema que tenemos en desarrollo, pero que no queremos en producción. El script LaunchFimDelta.ps1 lanza la herramienta y le da los nombres de archivo necesarios. Verá que toma los mismos parámetros que el script DiffConfig más uno más. Esto significa que si acaba de ejecutar el script Diff, puede pulsar la flecha hacia arriba, editar el nombre del script, pulsar la tecla fin y añadir el parámetro category. El parámetro category toma "schema" o "policy_portal" dependiendo del conjunto de cambios que estés examinando.
Cuando se abra la herramienta, verá el cuadro de diálogo "Abrir archivos" listo para funcionar, sólo tiene que hacer clic en Aceptar. Si ejecuta la herramienta manualmente, deberá especificar los archivos de extracción de origen y destino, así como el archivo de cambios generado por el proceso de diferencias. Tenga en cuenta que si le da a la herramienta un conjunto de archivos que no van juntos, es probable que se bloquee.
Los detalles de cómo usar la herramienta son otra entrada del blog, pero puedes ordenar los cambios por operación o tipo de objeto y puedes pasar todo tipo de tiempo examinando y filtrando tu archivo de cambios. Para esta narración, excluiremos algunos tipos de objetos no deseados:
Puedes ver que he desmarcado cinco tipos de recursos (tipos de objetos) que no queremos pasar a producción y he dejado marcado el único tipo de recurso nuevo (Ubicación) que sí queremos enviar al entorno de producción.
Ahora guardaremos nuestros cambios (Archivo, Guardar como). Por defecto, la herramienta añade "_filtered" al nombre del archivo y lo coloca en el mismo directorio del que procede el archivo de cambios.
A continuación, evitaremos que los usuarios de desarrollo sean migrados a producción. La siguiente captura de pantalla muestra el aspecto de la herramienta delta tras ejecutar el script LaunchFimDelta, esta vez con la opción policy_portal:
He agrupado los cambios por tipo de objeto y se pueden ver ejemplos de los distintos tipos de objeto no relacionados con el esquema que forman parte de la configuración de un servicio FIM. He desmarcado todos los objetos "Persona" porque no quiero mover ninguna identidad de desarrollo a producción. Puede ver que el tipo de operación es "Resolver", que es la operación que utiliza el proceso de importación (a continuación) para alinear referencias a objetos que aún no existen en el entorno de destino. Como no vamos a trasladar usuarios, no queremos molestarnos en buscarlos.
Si nos desplazamos un poco hacia abajo, podemos ver algunas definiciones de conjuntos:
Aquí puede ver que estamos optando por crear un conjunto llamado "_Administradores de ubicación", pero no vamos a transferir la pertenencia real del conjunto. En el archivo de cambios, los miembros del conjunto se almacenan como referencias, pero la herramienta delta tiene la inteligencia necesaria para mostrarle cuáles son las referencias. La captura de pantalla muestra que "ce2579dd-204c..." soy yo en el entorno de desarrollo. Si quisiera pasar mi cuenta a producción, podría haber dejado marcado mi atributo ExplicitMember y la acción de resolución correspondiente.
Después de guardar, tenemos lo siguiente en nuestro "directorio diff:"
Ahora es el momento de importar los cambios a producción. Para ello utilizamos el script CommitChanges.ps1. Este script combina las funciones de los scripts originales CommitChanges y ResumeUndoneImports.
Tenga en cuenta que el script CommitChanges realmente realiza cambios en su configuración, por lo que, como con cualquier cambio de configuración, debe asegurarse de tener una buena copia de seguridad de la base de datos del Servicio FIM antes de ejecutarlo.
CommitChanges toma el archivo de cambios como parámetro. Normalmente se le pasa la versión "filtrada" del fichero que se acaba de crear con la herramienta delta. Aquí está la importación del esquema, que se ejecuta limpiamente:
A veces la importación no se ejecuta "limpiamente". En nuestro caso, tenemos un error al importar la política:
En este caso, hemos utilizado una función añadida en una revisión de FIM (la posibilidad de ocultar el enlace de búsqueda avanzada en el portal). En el entorno de desarrollo, hemos añadido manualmente el esquema necesario para activar la función y hemos creado la regla de política de gestión necesaria para permitir el acceso al nuevo esquema. Estos cambios aún no se han realizado en producción y, por casualidad, la opción de configuración que contiene la nueva configuración se está aplicando antes que la MPR necesaria que permite cambiar la configuración. Este tipo de error de ordenación es un problema habitual en las migraciones de configuración. La solución será intentarlo de nuevo para los cambios que no se hayan podido importar.
Al igual que el script CommitChanges original, nuestro script actualizado muestra los cambios que no pudo enviar al sistema de destino. A diferencia del script original, construimos el nombre del archivo "deshecho" con el nombre del archivo de cambios que se utilizó más una marca de tiempo. De esta forma se tiene un historial de cada ronda de "deshechos".
Lo bueno es que el archivo deshecho tiene el mismo formato que el archivo de cambios. Esto significa que si no quieres examinar el XML a mano para ver lo que no llegó a producción, puedes cargarlo en la herramienta delta...
La herramienta delta nos dice que estamos intentando actualizar los atributos "HideAdvancedSearchLink" (y otros tres). El problema era que aún no se había creado el MPR que lo permite.
En nuestro caso, el MPR que necesitábamos estaba en el archivo de cambios original (fue justo después de la actualización de PortalUIConfiguration) y ahora está en producción. Esto significa que podemos enviar el archivo deshecho de nuevo al script CommitChanges y tener éxito:
Si echamos un último vistazo a nuestro directorio diff, veremos que tenemos un buen historial de los cambios calculados para nuestra "versión"; los cambios que realmente pasamos a producción; y los cambios con los que tuvimos dificultades:
Como reflexión final (por fin), considere que este proceso no tiene por qué ser sólo para la migración a producción. También puede utilizarlo para realizar un seguimiento del progreso dentro de un único entorno. La siguiente captura de pantalla muestra el aspecto que podría tener un entorno de desarrollo con exportaciones de configuración tomadas en varios momentos (ignora los tiempos de actualización de los archivos, es una simulación para la entrada del blog, fíjate en los nombres de los directorios...).
El directorio "Base3508" contiene una exportación de una versión de la base de datos del Servicio FIM recién instalada y parcheada hasta la compilación 3508. Los demás directorios contienen exportaciones de la configuración en las fechas indicadas en los nombres de los archivos.
Con esta información, podemos ejecutar el proceso DiffConfig en dos puntos cualesquiera en el tiempo:
- Si queremos saber cómo es nuestra configuración completa: Ejecuta "DiffConfig .\Base3508 .\Dev-20140429"
- Si queremos saber qué ha cambiado en la configuración entre el 24 y el 28 de marzo: Ejecuta "DiffConfig .\Dev-20140324 .\Dev-20140328"
También funciona al revés:
- Si queremos saber cómo deshacer los cambios ocurridos entre el 4 de abril y el 28 de marzo: Ejecuta "DiffConfig .\Dev-20140404 .\Dev-20140328"
- Si sólo queremos revertir un par de los cambios que se produjeron entre el 4 de abril y el 28 de marzo, podemos hacer lo anterior, pero ejecutar el archivo de cambios (hacia atrás) a través de la herramienta FIM Delta y desmarcar las cosas que no queremos revertir.
- Si queremos portar hacia atrás algunos cambios que sólo se han hecho en producción: Ejecute "DiffConfig .\Prod-xxx .\Dev-xxx". Una vez más, podemos utilizar la herramienta delta para seleccionar sólo los cambios que queremos volver a puerto y no borrar otros cambios en el desarrollo que aún no han rodado hacia adelante.
Aunque el proceso anterior no es perfecto, es una gran mejora con respecto a hacerlo todo manualmente. He encontrado las migraciones mucho más simple cuando se utiliza. Ya no me cuesta recordar qué versión del archivo changes.xml tengo delante. Ya no me asusto cuando tengo que mover sólo algunos elementos de configuración de un entorno a otro. Espero que el proceso anterior y la herramienta FIM Delta actualizada te resulten útiles.
Enlaces útiles:
Archivo Zip con la herramienta FIM Delta actualizada y los scripts de migración PowerShell: https://www.css-security.com/fdist/FimServiceMigration1.3.zip
Código fuente de la herramienta FIM Delta actualizada: https://github.com/RexWheeler/FIMDelta
Artículo de TechNet sobre la migración de la configuración FIM: https://technet.microsoft.com/en-us/library/ff400277%28v=ws.10%29.aspx
Scripts PowerShell de migración FIM de Microsoft: https://technet.microsoft.com/en-us/library/ff400275%28v=ws.10%29.aspx
Documentación de FIM PowerShell Cmdlets: https://technet.microsoft.com/en-us/library/ff394179.aspx
