Mi blog

Este Blog tiene como intención, mantener informado al Staff de IT con las distintas soluciones de la familia de productos de Microsoft.
El foco del Blog, brinda mi experiencia con la familia de productos de Ms System Center.
Con 20 años de experiencia en los productos de Microsoft, quiero compatir información, mis propias experiencias y mis articulos.

Si tenes dudas existen 2 solapas, dejame tu consulta aquí … pero también mirá la solapa " consultas anteriores" donde existen otras consultas posteadas.


Marcela Berri
Instructor / Consultor Senior IT
MVP - MCT – MCITP – MCTS – MCSA – MAP



martes, 28 de agosto de 2012

Guía de Migración de Objetos -Job- paso a paso -

Una vez finalizada y establecida la conexión, estamos listos para migrar los objetos que se deseen.
Ver tambien: Paso 1 - conexión


Job de Migración:


Una vez que la conexión ya queda establecida, en la botonera,en el tab de “HOME”, tenemos “Create migration Job” para comenzar el asistente de la migración de objetos. (figura 9)


(figura 9)

Comienza el asistente y nos ofrece 3 alternativas: (figura 10)

Job
Jerarquía Origen
Qué migra
Collection migration
CM 2007 SP2
Migra todos los objetos que están relacionados a la colección que se seleccionó, incluyendo los objetos asociados con los miembros de dicha colección.
Se puede excluir instancias de objetos específicos durante la creación del job.
Object migration
CM 2007 SP2
CM 2012 SP1 solamente
Migra objetos individuales que se seleccionen para ser migrados.
Previously migrated object migration
CM 2007 SP2
CM 2012 SP1 solamente
Migra los objetos previamente migrados de la jerarquía origen.  Se utiliza si los objetos fueron actualizados luego de la última migración.

(figura 10)

El tipo de job elegido en este caso es por Colección; así que comienza explorando las colecciones que encontró de la estructura 2007. (figura 11) En el ejemplo, existen subcolecciones. 
Si se eligiera “Object migration” el asistente sería un poco más sencillo, ya que no contará con la posibilidad de elegir las colecciones; el resto será igual a lo expuesto posteriormente.
Recuerden que CM migrará también los seteos incluyendo las ventanas de mantenimiento y variables de la colección.
Si la colección “Ed Central” no tiene miembros, pasará como una carpeta y dentro pasarán las subcolecciones que tenía la estructura anterior.  Estos objetos se crearán en “User Collections o “Device Collections dentro de Assets and Compliance


(figura 11)

En la ventana de Selección de objetos, se podrán elegir aquellos objetos que se deseen migrar. (figura 12). Específicamente, se deja sin migrar “ConfigMgr 2007 Toolkit” para verlo mas adelante (figura 21)
(figura 12)

Luego se debe asignar un site CM 2012 que va a ser “owner” del contenido . (figura 13)  Esto va a permitir que los objetos de 2007 sean migrados y se traiga el contenido a un punto específico dentro de la nueva jerarquía.  El default es el Site Central de Administración (CAS)

TIP: Debería elegirse el Site que se encuentre más cercano al contenido, para acceder a él vía red cuando se necesite.
(figura 13)

Aquí se de asignar la seguridad que tendrán de los objetos migrados.  Salvo que se requiera algo específico, se encuentra disponible la seguridad “Default” (la habitual)  de los Objetos. (figura 14)

(figura 14)

Es posible limitar cualquier colección que pueda incrementar la membresía luego de la migración. (figura 15)  Esto se debe a que las colecciones en CM 2012 son “Globla Data” y son evaluadas en cada Site dentro de la jerarquía.
Por consiguiente los advertisements asociados podrían ser evaluados en cada site y afectar a un número de miembros distintos o no deseados; entonces, durante la migración, se puede elegir o acotar la colección destino 2012 para evitarlo (si es que la estructura nueva está armada).
(figura 15)

En el caso en que hubiera alguna Colección con un query que referencie al código de Site, el asistente brindará la posibilidad de cambiar el código de Site y acomodarlo a la nueva estructura. (figura 16)
(figura 16)

Ya casi finalizando, se permite que el administrador revea antes de migrar, cualquier información adicional a tener en cuenta que el asistente considere importante. (a modo de ayuda) y deja inclusive pasarla a un .txt en donde explica las consideraciones finales dependiendo de los objetos a migrar. (figura 17)
(figura 17)

Por último, está la posibilidad de agendar el job.  Además provee controles adicionales para aquellos objetos que puedan llegar a existir en el Site destino y su comportamiento luego de la migración. (figura 18)
(figura 18)

El Job puede ser visto y manipulado en el ítem de “Migration Jobs” dentro de “Migration” en la consola. (figura 19).  Es necesario refrescar la consola para actualizar la información del job.
(figura 19)
Al finalizar la migración, contamos con un resumen con los tipos de objetos migrados. (figura 20)
(figura 20)
 Tareas post Migración:
En “Active Source Hierarchy” donde encontramos las conexiones realizadas a la estructura 2007, podemos manipularlas pudiendo iniciar o parar obtensión de datos. (figura 21)
(figura 21)
 
Parados en Migration, en la botonera, en “Edit Exclusion List”, es posible ver los objetos que fueron excluidos de la migración (figura 12).  Los objetos aquí listados (figura 22), serán automáticamente excluidos en futuras migraciones (no seleccionados por default).  Si se remueven de esta lista, podrán ser nuevamente elegidos y migrados en el próximo job.
 (figura 22)
El último paso a realizar luego de haber migrado todo, es “Clean Up Migration Data” (figura 23), después de haber parado todas las conexiones (figura 21).  Aquí se remueven los datos de la base de datos acerca de la migración a la nueva jerarquía 2012.  Sin embargo, algunos datos útiles quedan, para poder ir nuevamente al contenedor de “Migration” y rever por ejemplo los objetos que fueron migrados, quien es el site dueño de los objetos, etc.
(figura 23)
 
  

No hay comentarios.:

Publicar un comentario

Dejame tu comentario