Actualizar y migrar

En esta sección se describen los procedimientos para actualizar el software de Profile Management y se presenta información sobre cómo realizar la transición de los perfiles de usuario de Windows existentes a los perfiles de usuario de Citrix. Por ejemplo, puede actualizar fácilmente desde la versión 3.x a la versión 5.x usando estos procedimientos.

Antes de actualizar, es necesario entender qué funciones y parámetros de Profile Management están disponibles en la versión actual y en la versión a la que se actualiza. Para consultar esta información, consulte Directivas de Profile Management. Para facilitar actualizaciones desde archivos .ini a Directivas de grupo, este tema también describe la correspondencia entre los nombres de los parámetros del archivo .ini y los de los archivos .adm y .admx.

No configure Profile Management (ni en las Directivas de grupo ni en el archivo .ini) mientras está llevando a cabo una actualización. Separe estas dos tareas actualizando primero la implementación y configurando después los parámetros como sea necesario, preferentemente siguiendo las cuestiones planteadas en Toma de decisiones sobre la configuración.

Sugerencia: Se pueden aplicar revisiones hotfix a la implementación de Profile Management 2.1.1 o posterior, actualizándolo a la versión más reciente. Después de actualizarlo, puede habilitar si lo desea la nueva funcionalidad.

Entornos mixtos

Para entornos donde coexisten diferentes versiones de Profile Management, debe:

  • Minimizar el tiempo de coexistencia de ambas versiones
  • Agregar el archivo .adm o .admx de la versión más reciente a cada objeto de directiva de grupo en todos los controladores de dominio, asegurándose de que todas las funciones nuevas están inhabilitadas para dar tiempo a que las nuevas directivas se propaguen
  • Actualizar todos los equipos a la versión más reciente de Profile Management antes de habilitar cualquier directiva

Las implementaciones mixtas que contienen las versiones 5.x y 3.2 están respaldadas. No obstante hay que tratar dichos entornos como algo temporal que debe durar solo hasta que tiene lugar la migración completa desde la versión antigua a la más reciente.

Importante: Las implementaciones que contienen la versión 5.x con la versión 2.1.1 o versiones anteriores, entre las que se incluyen versiones Citrix Technical Preview o Beta, no están respaldadas. No obstante, si no puede realizar la actualización y esas versiones tienen que coexistir en la instalación, puede que le resulte útil consultar el resto de este tema.

Entornos mixtos con Profile Management 2.1.1 o versiones anteriores

El resto de este apartado contiene información sobre la coexistencia de Profile Management 2.1.1, o una versión anterior, y Profile Management 3.x ó 5.x. Se indica cómo migrar de una versión a otra. En este tema, se usan los términos versión 2 y versión 5 como forma abreviada para referirse a estas versiones.

Aísle cada versión en una unidad organizativa aparte y mantenga almacenes de usuarios separados para los equipos que ejecuten cada versión. De forma alternativa, si existe un solo almacén de usuarios para equipos que ejecutan ambas versiones, todos los parámetros de la versión 5 deben estar inhabilitados hasta que todos los equipos se hayan actualizado a dicha versión. Después de habilitar cualquier parámetro de la versión 4 en un almacén de usuarios “mixto”, los usuarios aún pueden iniciar sesión en un equipo que ejecuta la versión 2. Sin embargo, reciben un perfil de usuario temporal de Windows (en lugar de su perfil de usuario de Citrix en la red), y los cambios que hagan en ese perfil no se guardan. Por eso, conviene mantener entornos mixtos únicamente como algo temporal, y tratar de reducir al mínimo el tiempo de coexistencia antes de completar la actualización.

El uso de unidades organizativas y almacenes de usuario distintos puede presentar inconvenientes. Para evitar estas limitaciones, puede usar alguna de estas dos estrategias. Configure cada grupo en la versión apropiada de Profile Management con el parámetro Grupos procesados. La estrategia 2 implica más trabajo que la estrategia 1. Con la primera, debe actualizar continuamente los grupos de usuarios procesados con la versión 5. Además, debe mantener dos conjuntos de aplicaciones y escritorios (aunque puede automatizar este proceso exportando las definiciones de aplicaciones desde XenApp). La ventaja es que puede demorarse todo lo necesario durante la migración.

Nota: Como alternativa a las estrategias siguientes, con Active Directory de Windows Server 2008 se pueden usar filtros de WMI para aplicar un objeto de directiva de grupo a un subconjunto de equipos de una unidad organizativa, y determinar qué versión de Profile Management está instalada. Con lo que puede ajustar automáticamente qué directiva hay que aplicar, en función de la versión.

Estrategia 1: Migración en un solo paso

Este escenario asume que va a haber cierto periodo de inactividad y dicha situación es aceptable. Todos los equipos se migran al mismo tiempo.

La estrategia de migración es:

  1. Sustituya el archivo ADM de la versión 2 con el archivo de la versión 5. Esta última versión es compatible con la versión anterior, de manera que los equipos con la versión 2 siguen funcionando normalmente.
  2. Asegúrese de que todos los parámetros de la versión 5 estén inhabilitados. No dependa del valor predeterminado No habilitado.
  3. Inicie la actualización de todos los equipos desde la versión 2 a la versión 5. Incorpore esta tarea en su planificación normal de actualización y mantenimiento. Con una excepción, la versión 5 funciona como la versión 2 hasta que se habilita cualquier parámetro de la versión 5. La excepción es la siguiente. No es usual pero puede ocurrir si este paso de la actualización se alarga en el tiempo. Si un usuario accede a su perfil de usuario de Citrix desde varios servidores, se crean varias sesiones de la versión 4. Por ejemplo, primero usan una estación de trabajo para acceder a un escritorio virtual en un servidor y luego usan un portátil para acceder a una aplicación publicada en otro. Profile Management debe usar el área de archivos pendientes para la segunda sesión, la del portátil. En ese momento, la unidad organizativa entera se considera como una implementación de versión 5 (aunque sin funciones de versión 5 configuradas). Y PmCompatibility.ini se actualiza para reflejar este cambio.
  4. Opcionalmente, configure su grupo de usuarios procesados por la versión 5 para que incluya solo a los miembros de un pequeño grupo de prueba piloto. Espere a que los cambios de la directiva de grupo de AD se propaguen en toda la red (por ejemplo, a lo largo de un fin de semana). No necesita limitar el acceso a otros usuarios mientras se lleva a cabo este cambio. Realice una copia de seguridad de los perfiles del grupo piloto. Luego permita que el grupo piloto pruebe Profile Management.
  5. Cuando esté satisfecho con los resultados del grupo piloto, asegúrese de haber realizado copias de seguridad de los otros perfiles de usuarios.
  6. Use el próximo periodo de mantenimiento programado para agregar los demás usuarios al grupo de usuarios procesados por la versión 5. Deje suficiente tiempo para que se propaguen los cambios de la directiva de grupo de AD y luego permita que los usuarios restantes inicien sesiones.

Estrategia 2: Migración por fases

Este escenario asume que no puede mover todos sus equipos o usuarios a la nueva versión en un solo paso, de manera que debe seleccionar subconjuntos de usuarios para la migración por lotes. Es ideal para implementaciones con varios centros de datos (Datacenters) o usuarios distribuidos geográficamente por todo el mundo.

La estrategia de migración es:

  1. Sustituya el archivo ADM de la versión 2 con el archivo de la versión 5. Esta última versión es compatible con la versión anterior, de manera que los equipos con la versión 2 siguen funcionando normalmente.
  2. Asegúrese de que todos los parámetros de la versión 5 estén inhabilitados. No dependa del valor predeterminado No habilitado.
  3. Actualice algunos equipos (el primer lote) a la versión 5. De forma alternativa, instale la versión 5 en equipos nuevos. De forma predeterminada, el grupo de usuarios procesados por la versión 5 contiene un grupo vacío, para que ningún usuario sea procesado por dicha versión. Tenga en cuenta la excepción descrita en la estrategia 1, que también se puede aplicar cuando actualiza equipos en una migración por fases.
  4. Publique aplicaciones nuevas (con XenApp) o escritorios virtuales (con XenApp o XenDesktop) desde los equipos con la versión 5. Estas aplicaciones y escritorios son idénticos a aquellos publicados previamente desde los equipos de la versión 2, excepto por sus nombres. Estos nombres los identifican como recursos para ser utilizados por usuarios de la versión 5.
  5. Los usuarios seleccionados en este lote se conectan a las aplicaciones o escritorios (por ejemplo, con la Interfaz Web), y seleccionan las aplicaciones nuevas. (Utilice la Interfaz Web para forzar este uso, según el nombre de usuario o su pertenencia a un grupo.) Como resultado, sus sesiones se ejecutan en los equipos de la versión 4 pero se procesan con los parámetros de la versión 2.
  6. Asegúrese de haber realizado una copia de seguridad de los perfiles de todos los usuarios.
  7. Mueva los usuarios fuera del grupo de usuarios procesados por la versión 2 al grupo de la versión 4. Espere a que se propaguen los cambios de la directiva de grupo de AD a los equipos de la versión 5. La próxima vez que se conecten, las sesiones de los usuarios se procesarán con los parámetros de la versión 5.
  8. Actualice el lote siguiente de equipos y migre el lote siguiente de usuarios, como se ha descrito anteriormente.