Aqui os dejo varios artículos sobre la migración de SCCM 2007 a SCCM 2012:
Articulo 1: Pre requisitos para la Migración
Artículo 2: Preparación para la Migración
Artículo3: Proceso de la Migración
Artículo 4: Guía de Migración de Objetos paso a paso. La conexión
Artículo 5: Guía de Migración de Objetos paso a paso. Job
Artículo 1 Pre requisitos para la Migración
Prerequisitos 2007 para la migración
Son pocos los prerrequisitos necesarios antes de la migración. Es importante repasarlos con anterioridad y obtener una migración tranquila y sencilla.
1) Los Sites de SCCM2007 deben estar mínimamente en Configuration Manager SP2.
2) Se deben configurar el acceso a la estructura 2007 mediante 2 cuentas:
· Acceso al SMS Provider de la estructura 2007: La cuenta debe tener permisos de Read a todos los objetos de Configuration Manager 2007.
· Acceso a la base de datos del site 2007: La cuenta debe tener permisos de Read y Execute a la base del Configuration Manager 2007.
Estas cuentas se pedirán al momento de configurar el job de migración. La configuración de dichas cuentas tienen un botón de TEST!! ;), pudiendo verificar la conexión a SQL y al WMI del Site de 2007.
Es posible utilizar una cuenta existente de AD, crear una nueva o bien acceder mediante la cuenta de máquina “COMPUTER$” del CAS 2012. (esta última opción es muy buena ya que no se maneja password).
3) Al conectarse a la vieja estructura, el SMS Provider y la cuenta del SQL utilizan los siguientes puertos:
NetBIOS/SMB – 445 (TCP)
RPC (WMI) - 135 (TCP)
SQL Server - 1433 (TCP)
Prerequisitos 2012 para la migración
Ya que la migración es side-by-side, son necesarios algunos requisitos para que las 2 estructuras se conecten.
1) Se debe instalar una Jerarquía CM2012 en la misma red que la estructura 2007.
2) Se debe contar con privilegios administrativos para realizar la migración.(Full Control Administrator)
3) Se debe configurar y sincronizar el rol de SUP- Software Update Point en la nueva estructura para poder migrar los updates.
4) Tener configurado al menos 1 site (CAS o primario) que usen los mismos puertos que la estructura 2007. Eso permite que los clientes 2012 puedan utilizar el/los Distribution Points compartidos durante el proceso de migración.
5) Asegurarse que la cuenta configurada en el job de migración tenga permisos de Borrado de Site en la estructura 2007 para que se puedan remover automáticamente los Distribution Points durante la migración.
Artículo 2 Preparación para la Migración
Preparación del Site para la migración de SCCM2007 a CM2012
Son varias las consideraciones a tener en cuenta para migrar exitosamente a la nueva estructura. Les dejo un resumen de lo que hay que tener en cuenta antes de comenzar el proceso de migración:
· Todos los Sites deben tener como mínimo Configuration Manager 2007 SP2. Si la actualización es mayor (generalmente R3), será posible migrar paquetes virtuales también.
· Recuerden que la estructura CM2012 no puede contener más de 3 niveles, CAS-Primary-Secondary, no siendo así en la vieja estructura 2007. Es prudente llevar la estructura vieja a no más de 3 niveles o planificar con anterioridad qué se hará con los niveles actuales que superen dichos niveles.
· Tener en cuenta que la nueva estructura no permite que un primario sea hijo de otro primario. Se deben consolidar.
· Ver la opción de convertir los Sites Secundarios en Distribution Points cuando sea posible durante la migración.
· Es importante revisar el software base para CM2012. El requisito mínimo para la estructura es Windows Server 2008 y para la base de datos es SQl Server 2008, todo en 64 bits.
· Considerar la utilización de BranchCache en vez de Distribution Points. Estos podrán seguir formando parte en la nueva estructura.
· Considerar la virtualización de servidores. CM2012, funciona perfectamente en dicho ambiente.
· Revisar las colecciones mixtas (usuarios y máquinas), ya que no migran y recordar que las sub-colecciones pasarán como colecciones independientes.
· Es conveniente revisar todos los paquetes de software para que el origen esté configurados con el path UNC(\\server\sharedappl\appl.msi) y no local. Con esto evitan tener que redefinir paquetes.
· Asegurarse que el código de site sea único entre 2007 y 2012.
ver además: Prerequisitos para la migración
Artículo 3 Proceso de la Migración
Estos son los pasos que deberían seguirse durante el proceso de migración de una estructura SCCM2007 a CM2012:
1. Configurar la jerarquía.
En primer lugar, se debe especificar el sitio top de la jerarquía 2007, generalmente el “Central Site” o bien el Site primario. Este sitio será además el que se tomará como origen para la migración de los objetos de la vieja estructura 2007 a la nueva en 2012.
2. Configuración de los sitios adicionales.
Se puede especificar los sitios adicionales que contengan objetos que se desea migrar. Se podrán elegir aquellos sitios que estén por debajo del top site.
3. Configurar un Distribution Point compartido. (opcional)
Es posible configurar un Distribution Point 2007 que será visible para los clientes de Configuration Manager 2012 después de la migración. Este DP será el que tendrá los paquetes disponibles para los nuevos clientes 2012 sin tener que redistribuir el contenido.
4. Migración de colecciones y objetos asociados.
Se crea una tarea de migración para migrar colecciones y objetos a migrar.
5. Migrar objetos por tipo.
Se puede seleccionar los tipos de objetos que van a ser migrados.
6. Migración de clientes
Se migrarán los clientes a la nueva estructura por cualquiera de los siguientes métodos: Client Push, políticas de grupo, logon scripts o instalación manual. Los clientes migrados, mantienen el historial de ejecución de sus advertisements.
7. Convertir sitios secundarios en Distribution Points.(opcional)
Es posible convertir los Sites Secundarios en Distribution Points. El asistente “Upgrade Shares Distribution Point” desinstala el sitio secundario y luego configura el server como DP de CM2012, manteniendo el contenido existente.
Luego de la migración, se debe:
1. Retirar el Distribution Point compartido (puesto en el punto 3) una vez que todos los clientes de Configuration Manager se migraron a la versión 2012.
2. Remover la configuración de la jerarquía 2007 (punto 1) y desinstalar la estructura 2007.
Ver ademas: preparación de site para la migración
Artículo 4 Guía Migración de Objetos -conexion- paso a paso
Guía de Migración de Objetos - paso a paso -
Para migrar objetos desde Configuration Manager 2007 al nuevo Site en 2012, Existe un asistente built-in dentro de la consola que permite elegir los objetos que se deseen pasar.
Inclusive, estos Jobs pueden correrse mas de una vez, si es que durante una migración escalonada, los objetos origen fueron cambiados a lo largo de la transición.
Esta guía brinda los pasos necesarios para una migración completa de objetos.
Son pocos los prerrequisitos necesarios antes de la migración. Es importante repasarlos con anterioridad y obtener una migración tranquila y sencilla.
1) Los Sites de SCCM2007 deben estar mínimamente en Configuration Manager SP2.
2) Se deben configurar el acceso a la estructura 2007 mediante 2 cuentas:
· Acceso al SMS Provider de la estructura 2007: La cuenta debe tener permisos de Read a todos los objetos de Configuration Manager 2007.
· Acceso a la base de datos del site 2007: La cuenta debe tener permisos de Read y Execute a la base del Configuration Manager 2007.
Estas cuentas se pedirán al momento de configurar el job de migración. La configuración de dichas cuentas tienen un botón de TEST!! ;), pudiendo verificar la conexión a SQL y al WMI del Site de 2007.
Es posible utilizar una cuenta existente de AD, crear una nueva o bien acceder mediante la cuenta de máquina “COMPUTER$” del CAS 2012. (esta última opción es muy buena ya que no se maneja password).
3) Al conectarse a la vieja estructura, el SMS Provider y la cuenta del SQL utilizan los siguientes puertos:
NetBIOS/SMB – 445 (TCP)
RPC (WMI) - 135 (TCP)
SQL Server - 1433 (TCP)
Prerequisitos 2012 para la migración
Ya que la migración es side-by-side, son necesarios algunos requisitos para que las 2 estructuras se conecten.
1) Se debe instalar una Jerarquía CM2012 en la misma red que la estructura 2007.
2) Se debe contar con privilegios administrativos para realizar la migración.(Full Control Administrator)
3) Se debe configurar y sincronizar el rol de SUP- Software Update Point en la nueva estructura para poder migrar los updates.
4) Tener configurado al menos 1 site (CAS o primario) que usen los mismos puertos que la estructura 2007. Eso permite que los clientes 2012 puedan utilizar el/los Distribution Points compartidos durante el proceso de migración.
5) Asegurarse que la cuenta configurada en el job de migración tenga permisos de Borrado de Site en la estructura 2007 para que se puedan remover automáticamente los Distribution Points durante la migración.
Artículo 2 Preparación para la Migración
Preparación del Site para la migración de SCCM2007 a CM2012
Son varias las consideraciones a tener en cuenta para migrar exitosamente a la nueva estructura. Les dejo un resumen de lo que hay que tener en cuenta antes de comenzar el proceso de migración:
· Todos los Sites deben tener como mínimo Configuration Manager 2007 SP2. Si la actualización es mayor (generalmente R3), será posible migrar paquetes virtuales también.
· Recuerden que la estructura CM2012 no puede contener más de 3 niveles, CAS-Primary-Secondary, no siendo así en la vieja estructura 2007. Es prudente llevar la estructura vieja a no más de 3 niveles o planificar con anterioridad qué se hará con los niveles actuales que superen dichos niveles.
· Tener en cuenta que la nueva estructura no permite que un primario sea hijo de otro primario. Se deben consolidar.
· Ver la opción de convertir los Sites Secundarios en Distribution Points cuando sea posible durante la migración.
· Es importante revisar el software base para CM2012. El requisito mínimo para la estructura es Windows Server 2008 y para la base de datos es SQl Server 2008, todo en 64 bits.
· Considerar la utilización de BranchCache en vez de Distribution Points. Estos podrán seguir formando parte en la nueva estructura.
· Considerar la virtualización de servidores. CM2012, funciona perfectamente en dicho ambiente.
· Revisar las colecciones mixtas (usuarios y máquinas), ya que no migran y recordar que las sub-colecciones pasarán como colecciones independientes.
· Es conveniente revisar todos los paquetes de software para que el origen esté configurados con el path UNC(\\server\sharedappl\appl.msi) y no local. Con esto evitan tener que redefinir paquetes.
· Asegurarse que el código de site sea único entre 2007 y 2012.
ver además: Prerequisitos para la migración
Artículo 3 Proceso de la Migración
Estos son los pasos que deberían seguirse durante el proceso de migración de una estructura SCCM2007 a CM2012:
1. Configurar la jerarquía.
En primer lugar, se debe especificar el sitio top de la jerarquía 2007, generalmente el “Central Site” o bien el Site primario. Este sitio será además el que se tomará como origen para la migración de los objetos de la vieja estructura 2007 a la nueva en 2012.
2. Configuración de los sitios adicionales.
Se puede especificar los sitios adicionales que contengan objetos que se desea migrar. Se podrán elegir aquellos sitios que estén por debajo del top site.
3. Configurar un Distribution Point compartido. (opcional)
Es posible configurar un Distribution Point 2007 que será visible para los clientes de Configuration Manager 2012 después de la migración. Este DP será el que tendrá los paquetes disponibles para los nuevos clientes 2012 sin tener que redistribuir el contenido.
4. Migración de colecciones y objetos asociados.
Se crea una tarea de migración para migrar colecciones y objetos a migrar.
5. Migrar objetos por tipo.
Se puede seleccionar los tipos de objetos que van a ser migrados.
6. Migración de clientes
Se migrarán los clientes a la nueva estructura por cualquiera de los siguientes métodos: Client Push, políticas de grupo, logon scripts o instalación manual. Los clientes migrados, mantienen el historial de ejecución de sus advertisements.
7. Convertir sitios secundarios en Distribution Points.(opcional)
Es posible convertir los Sites Secundarios en Distribution Points. El asistente “Upgrade Shares Distribution Point” desinstala el sitio secundario y luego configura el server como DP de CM2012, manteniendo el contenido existente.
Luego de la migración, se debe:
1. Retirar el Distribution Point compartido (puesto en el punto 3) una vez que todos los clientes de Configuration Manager se migraron a la versión 2012.
2. Remover la configuración de la jerarquía 2007 (punto 1) y desinstalar la estructura 2007.
Ver ademas: preparación de site para la migración
Artículo 4 Guía Migración de Objetos -conexion- paso a paso
Guía de Migración de Objetos - paso a paso -
Para migrar objetos desde Configuration Manager 2007 al nuevo Site en 2012, Existe un asistente built-in dentro de la consola que permite elegir los objetos que se deseen pasar.
Inclusive, estos Jobs pueden correrse mas de una vez, si es que durante una migración escalonada, los objetos origen fueron cambiados a lo largo de la transición.
Esta guía brinda los pasos necesarios para una migración completa de objetos.
Conexión:
Para poder comenzar a conectar las 2 estructuras, es necesario ejecutar un asistente que nos pedirá toda la información necesaria para una migración exitosa.
Dentro de la Consola 2012à en Administration, se encuentra el punto de “Migration”, desde allí lanzamos el asistente que se encuentra arriba en la Botonera: “Specify Source Hierarchy” (Figura 1)
En ella debemos colocar el nombre o FQDN del Site server Top de la jerarquía.
(figura 1)
El proceso necesita colectar información de la estructura CM 2007 y para ello nos pide las cuentas con los privilegios necesarios que establecen la conexión.
Es posible utilizar la cuenta de máquina del Site CM2012 o bien utilizar alguna cuenta de AD con los privilegios necesarios. En el botón de “Set…”, donde se coloca la cuenta, se puede realizar un TEST de conexión tanto a la base como al WMI de la estructura 2007. (figura 2)
(figura 2)
Una vez establecida las cuentas, el proceso de conexión hacia los datos comienza (figura 3). Este proceso se repite por Schedule cada 4 horas por defecto. El proceso inicial debe traer la información de todos los objetos de la base de Configuration Manager 2007 y la lista de Distribution Points.
(figura 3)
Como resultado, en la consola de “Migration” se puede ver el número de objetos que se encontraron listos para migrar. Como la conexión es realizada al top-level Site, cualquier site por debajo es visto en la consola. (figura 4)
Es posible generar otra conexiones a otros sites (todos los que se necesiten) siempre con la lógica top to down. Es importante tener en cuenta que estas nuevas conexiones se deben hacer después de completar los Jobs activos, ya que ConfMgr cancelará los Jobs activos para darle prioridad al nuevo configurado.
(figura 4)
Dentro de la consola, en el ítem de “Active Source Hierrchy”, vemos un resumen de la o las conexiones realizadas, su estatus y el resumen de los objetos encontrados. (figura 5)
(figura 5)
Durante lo que dure el proceso de migración, es posible que se necesite que el contenido de paquetes que está en los Distribution Points de 2007 también esté disponible para los clientes migrados a 2012. Esto es posible configurando “Distribution Point sharing”. Esto asegura que se mantenga el mismo contenido para ambos clientes, hasta que se complete la migración.
Al ser esta característica opcional, si observamos la consola (figura 6), no hay por defecto ningún DP asignado. Si se necesita, en la botonera, se encuentra “Share Distribution Point”, la opción que permite habilitar dicha característica. (figura 7)
(figura 6)
(figura 7)
Aquí se verán aquellos DP de la estructura 2007 que serán compartidos. (figura 8)
(figura 8)
Una vez finalizada y establecida la conexión, estamos listos para migrar los objetos que se deseen.
Artículo 5 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)
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.
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
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)
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.
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)
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).
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)
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)
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)
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.
Al finalizar la migración, contamos con un resumen con los tipos de objetos migrados. (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)
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.
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.
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