SCCM 2012 - Migración fácil - Parte 2

En la Parte 1 de esta serie de blogs presenté una visión general de los requisitos necesarios para preparar una migración de Configuration Manager 2007 a 2012. Con esa información en la mano, creo que debería tener una comprensión general de los requisitos previos necesarios para comenzar su proceso de migración.

El proceso de migración de límites permite una migración directa uno a uno de cada límite especificado en un sitio de origen de ConfigMgr 2007. Como ConfigMgr 2012 utiliza grupos de límites junto con límites estándar, el proceso de migración creará cada límite y creará automáticamente un grupo de límites (para el sitio de origen correspondiente) del que formarán parte los límites migrados. La Figura 1 muestra tres límites que se han migrado desde un único sitio ConfigMgr 2007 y la Figura 2 muestra que se ha creado un único grupo de límites que contiene 3 límites.

Figura 1 - Límites migrados de ConfigMgr 2012

Figura 2 - Grupo límite creado automáticamente en ConfigMgr 2012

La migración de colecciones es, con diferencia, uno de los procesos más útiles de la utilidad por un par de razones. software En primer lugar, las colecciones seleccionadas para la migración son analizadas automáticamente por la utilidad de migración para determinar si existen paquetes, anuncios, actualizaciones de software o secuencias de tareas asociados a las colecciones seleccionadas. Si se identifica alguno de estos elementos o todos ellos, la utilidad ofrecerá la opción de migrar los elementos a los que se hace referencia específica para que vayan junto con la colección o colecciones.

Si se da cuenta, los "anuncios" no están presentes en la lista predeterminada de objetos de migración que se mencionaron anteriormente y que, sin embargo, forman parte de la migración de colecciones. No se trata de un error. La migración de un anuncio sólo es una opción durante la migración de la colección, y sólo si un anuncio se dirige a la colección que se está migrando. El propósito de esto, que es mi opinión y no un hecho publicado, es que un anuncio no puede migrarse a menos que su colección y paquete objetivo estén presentes.

En segundo lugar, si tienes una estructura de colecciones que utiliza colecciones vacías para los marcadores de posición y la organización, la utilidad de migración traduce esas colecciones en carpetas organizativas. Aunque yo también tenía mis dudas al principio, después de ver la traducción del objeto de migración puedo decir que el proceso es muy eficaz. La captura de pantalla de la Figura 3 muestra las colecciones seleccionadas para la migración, y la Figura 4 muestra el aspecto de dichas colecciones tras la migración.

Figura 3 - Asistente de migración de colecciones

Figura 4 - Colecciones migradas

Nota importante: No se pueden migrar colecciones que contengan tanto usuarios como sistemas. Se recomienda separar las colecciones mixtas antes de la tarea de migración.

Software es evidente que los paquetes no tienen nada que envidiar a los objetos disponibles para la migración. Todas las opciones y programas de los paquetes se mantienen durante la migración. Sin embargo, los paquetes migrados no se traducen al nuevo "modelo de aplicación". La figura 5 muestra dos paquetes migrados y su correspondiente recuento de programas.

Figura 5 - Paquetes migrados Software

Microsoft ha diseñado convenientemente un Gestor de Conversión de Paquetes (PCM) para ayudarle a convertir sus Paquetes Software migrados en Aplicaciones ConfigMgr 2012. Para obtener más información sobre el PCG navegar al siguiente enlace:

https://technet.microsoft.com/en-us/library/hh531519.aspx

Una advertencia es la ubicación del contenido de origen. Para facilitar una migración sin problemas de los paquetes de software , todas las ubicaciones de los archivos de origen deben utilizar una ruta UNC. Cualquier paquete que utilice una ruta de unidad local como ubicación de origen al migrar no se distribuirá a menos que la ruta especificada y el contenido de origen correspondiente estén presentes en el servidor ConfigMgr 2012.

Como se mencionó en la Parte 1 de este blog es necesario tener instalada y configurada la infraestructura deseada de ConfigMgr 2012 para ejecutar correctamente una migración. Debo hacer hincapié en la importancia de esto en lo que respecta a la migración de software actualizaciones. Aunque probablemente es evidente que Software Update point(s) son necesarios antes de la migración de Software Updates, lo que hay que destacar es que el Catálogo de Productos y los idiomas de actualización deben coincidir perfectamente con la configuración de ConfigMgr 2007 y sincronizarse correctamente. Si falta una sola actualización de un paquete de actualización completo, la migración de ese paquete fallará.

Nota importante: Todas las actualizaciones personalizadas y las actualizaciones de SCUP publicadas localmente deberán volver a publicarse, ya que no pueden migrarse.

Software paquetes de actualización, así como la plantilla de actualización todavía existen dentro de ConfigMgr 2012. Las Plantillas de Actualización necesitarán tener los ajustes de duración reconfigurados ya que no migran. El proceso de migración convertirá las listas de actualización de Software en grupos de actualización de Software y un despliegue de actualización de Software se convertirá en un despliegue y su correspondiente grupo de actualización.

Durante la migración de objetos OSD los Drivers, Driver Packages, OS Images, y OS Install Packages (ahora llamados OS Installers) son migrados exactamente como lo eran en ConfigMgr 2007. La única excepción a la regla son las Imágenes de Arranque. Mientras que están listados como objetos que pueden ser migrados, hay algunos detalles que necesitan ser identificados.

La primera y más impactante es que las personalizaciones que se hicieron a las imágenes de arranque en ConfigMgr 2007 no se pueden migrar. Ahora que algunos de ustedes están gritando en el interior permítanme explicar por qué. El archivo WIM de la imagen de arranque no es lo que se está migrando. Los controladores que se han inyectado en las imágenes de arranque ConfigMgr 2007 se están inyectando automáticamente en imágenes de arranque con nombres similares que se crean a partir de los archivos WIM de arranque desde el AIK en el servidor ConfigMgr 2012. En una nota positiva, un buen número de personalización se puede hacer a las imágenes de arranque a través de la nueva interfaz gráfica de usuario en ConfigMgr 2012, tales como ganchos de pre-ejecución y los archivos asociados.

Las secuencias de tareas también se migran de forma casi idéntica. El único cambio que se realizará automáticamente es cuando se utilice un paquete de instalación de cliente; se sustituirá por una referencia al paquete de cliente ConfigMgr 2012 creado previamente.

Hay dos elementos que merecen un breve resumen en términos de migración de objetos DCM. En primer lugar, los paquetes de configuración de ConfigMgr 2007 se pueden importar en ConfigMgr 2012. El paquete de configuración se convierte automáticamente para ser compatible. En segundo lugar, los elementos de configuración no interpretados NO se migrarán ni se podrán importar.

No hay cambios significativos ni en Asset Intelligence ni en Software Metering. Por lo tanto, la migración de estas dos categorías es básicamente perfecta y aparecerán en ConfigMgr 2012 tal y como lo hacían en 2007.

• Consultas de SCCM
• Seguridad del sitio y derechos de instancia
• Seguridad de objetos y derechos de instancia
• Informes de SCCM
• Inventario de clientes
• Datos del historial del cliente
• Datos de aprovisionamiento AMT
• Archivos caché de cliente
• Personalización de la imagen de arranque
• Sitio secundario

Por favor, vuelva para la Parte 3 que cubrirá el proceso de migración real, incluyendo la creación de trabajos de migración, lo que los elementos migrados se ven en la nueva consola, y algunos elementos en torno a la limpieza de la migración. Y como siempre espero que esta información sea beneficiosa para todos aquellos que buscan en Configuration Manager 2012.