Citrix Virtual Apps and Desktops

Migrar la configuración a Citrix Cloud™

La Herramienta de Configuración Automatizada (ACT) permite la migración de la configuración de Citrix Virtual Apps and Desktops™ (directivas, aplicaciones, catálogos, roles de administrador, ámbitos y otros) desde uno o varios sitios locales a Citrix DaaS alojado en Citrix Cloud. También se puede usar para migrar información entre diferentes regiones o inquilinos de la nube.

Esta herramienta detecta y exporta uno o varios sitios locales como una colección de archivos de configuración, que puede editar opcionalmente. La configuración de estos archivos se puede importar después a Citrix DaaS. La migración se realiza por etapas ejecutando la herramienta varias veces, lo que le permite lograr fácilmente el estado de configuración deseado.

ACT no es solo una herramienta de migración de un solo uso. Puede usarla para administrar sus operaciones diarias en la nube, como:

  • Automatizar la transferencia de cuentas de nube de prueba o de ensayo a cuentas de nube de producción
  • Realizar copias de seguridad y restaurar su configuración
  • Dividir un entorno de nube en varias nubes

El siguiente vídeo de 2 minutos ofrece un recorrido rápido por la Configuración Automatizada.

Para obtener información adicional sobre la Configuración Automatizada, consulte Prueba de concepto: Herramienta de configuración automatizada en Tech Zone.

Para obtener una visión más detallada de cómo trasladar su implementación y preparar su configuración local para la migración, consulte Guía de implementación: Migración de Citrix Virtual Apps and Desktops de local a Citrix Cloud en Tech Zone.

Limitaciones conocidas

Requisitos previos para migrar su configuración

Para exportar su configuración de Citrix Virtual Apps and Desktops, necesita:

  • Citrix Virtual Apps and Desktops: versión actual y su predecesora inmediata o Citrix Virtual Apps and Desktops, XenApp y XenDesktop® LTSR: todas las versiones
  • Una máquina unida a un dominio con .NET Framework 4.7.2 o posterior y el SDK de Citrix PowerShell. Esto se instala automáticamente en el Delivery Controller. (Para ejecutarlo en una máquina que no sea el Delivery Controller local, debe instalarse Citrix Studio, ya que Studio instala los complementos de PowerShell correctos. El instalador de Studio se encuentra en los medios de instalación de Citrix Virtual Apps and Desktops).

Para importar su configuración a Citrix DaaS, necesita:

  • Una máquina con acceso a Citrix Cloud. No tiene por qué ser un Delivery Controller™ ni una máquina unida a un dominio.
  • Citrix DaaS aprovisionado.
  • Una ubicación de recursos activa con Connector instalado y unida al mismo dominio que la configuración local.
  • La conectividad a los sitios que acceden a Citrix Cloud debe estar permitida y disponible. Para obtener más información, consulte Requisitos del sistema y de conectividad.

Nota:

Automated Configuration no se puede instalar en un sistema Cloud Connector.

Pasos clave

  1. Descargue la herramienta Automated Configuration y revise los requisitos del sistema. Consulte Descargar Automated Configuration.
  2. Rellene el archivo CustomerInfo.yml con sus valores de CustomerName, CustomerID y SecretKey generados desde el portal de Citrix Cloud. Consulte Generar el ID de cliente, el ID de cliente y la clave secreta y Rellenar el archivo de información del cliente.
  3. Si el sitio local contiene varias zonas, actualice el archivo ZoneMapping.yml para asignar las zonas a las ubicaciones de recursos de Citrix DaaS. Consulte Rellenar el archivo de asignación de zonas.
  4. Si el sitio contiene varias conexiones de alojamiento, actualice el archivo CvadAcSecurity.yml con la información de conexión para cada tipo de host que se migra a Citrix DaaS. Si solo hay una conexión de host, actualice el archivo CvadACSecurity.yml con la información de conexión para esa conexión de host. Consulte Actualizar el archivo de seguridad para las conexiones de host.
  5. Abra ACT y exporte su sitio local mediante el comando Export-CvadAcToFile. Consulte Objetos de migración admitidos para ver la lista de componentes admitidos para la migración. Para obtener información sobre los pasos para exportar, consulte Exportar la configuración local.
  6. Importe los componentes por fases mediante el comando Merge-CvadAcToSite. Alternativamente, migre todo el sitio a la vez. Asegúrese de migrar los componentes en el orden que se indica en Orden de migración de componentes. Para obtener información sobre los pasos para importar, consulte Ejecutar una importación.
  7. Active el sitio en la nube. Consulte Activar sitios.

Descargar Automated Configuration

Descargue e instale la herramienta Automated Configuration desde Descargas de Citrix.

Actualizar Automated Configuration

Para evitar errores de funcionalidad, utilice siempre la versión más reciente de ACT.

Para saber la versión de su herramienta, haga lo siguiente:

  1. Haga doble clic en el icono Auto Config. Aparecerá una ventana de PowerShell.
  2. Ejecute el siguiente comando para comprobar su número de versión.

    Get-CvadAcStatus
    <!--NeedCopy-->
    
  3. Compruebe la versión de su herramienta con la versión que aparece en Descargas de Citrix. Allí se encuentra la versión más reciente de la herramienta.
  4. Descargue e instale la versión más reciente de la herramienta. No es necesario desinstalar la versión anterior para actualizar Automated Configuration.

Nota:

Cuando ejecuta cmdlets para acceder a la nube en Automated Configuration, la herramienta le avisa cuando hay una versión más reciente disponible para descargar. Para obtener más información sobre los cmdlets, consulte Cmdlets de la herramienta Automated Configuration.

Generar el ID de cliente, el ID de cliente y la clave secreta

Para migrar el sitio local a Citrix DaaS, rellene el archivo CustomerInfo.yml con el ID de cliente, el ID de cliente y la clave secreta del portal de Citrix Cloud.

Para recuperar el ID de cliente:

  1. Inicie sesión en su cuenta de Citrix Cloud y seleccione el cliente.
  2. Haga clic en el icono de cuadrícula y seleccione Administración de identidades y accesos.
  3. Vaya a Acceso a la API > Clientes seguros. El ID de cliente se muestra en la página.

Para recuperar el ID de cliente y la clave secreta:

  1. En la página Clientes seguros, introduzca un nombre en el cuadro. Este nombre se utiliza para diferenciar entre varios ID de cliente y claves secretas.
  2. Haga clic en Crear cliente para crear el ID de cliente y la clave secreta.
  3. Copie el ID de cliente y la clave secreta en una ubicación segura y descargue el archivo .csv que contiene esta información. Utilice el archivo .csv para rellenar el archivo CustomerInfo.yml.

Nota:

  • El ID de cliente y la clave secreta no caducan. Si se ven comprometidos, elimínelos inmediatamente con el icono de Papelera y cree otros nuevos.
  • La clave secreta no se puede recuperar si se pierde u olvida; se deben crear un nuevo ID de cliente y una nueva clave secreta.

Rellenar el archivo de información del cliente

El archivo CustomerInfo.yml elimina la necesidad de proporcionar parámetros de información del cliente cada vez que se ejecuta el cmdlet. Cualquier información del cliente se puede anular mediante el uso de parámetros de cmdlet.

Utilice el cmdlet New-CvadAcCustomerInfoFile para crear el archivo CustomerInfo.yml.

Importante:

No edite manualmente el archivo CustomerInfo.yml. Hacerlo puede causar errores de formato involuntarios.

El cmdlet New-CvadAcCustomerInfoFile tiene los siguientes parámetros obligatorios.

  • CustomerId: ID del cliente.
  • ClientId: ID de cliente del cliente creado en Citrix Cloud.
  • Secret: secreto del cliente creado en Citrix Cloud.

Ejemplo:

New-CvadAcCustomerInfoFile -CustomerId markhof123 -ClientId 6813EEA6-46CC-4F8A-BC71-539F2DAC5984 -Secret TwBLaaaaaaaaaaaaaaaaaw==
<!--NeedCopy-->

También puede crear el CustomerInfo.yml utilizando el parámetro SecurityCsvFileSpec que apunta al archivo security.csv descargado. También debe especificar el CustomerId.

New-CvadAcCustomerInfoFile -SecurityCsvFileSpec C:\Users\my_user_name\downloads/security.csv -CustomerId markhof123
<!--NeedCopy-->

Utilice el cmdlet Set-CvadAcCustomerInfoFile para actualizar el archivo CustomerInfo.yml. Este cmdlet solo cambia el ID de cliente.

Set-CvadAcCustomerInfoFile -ClientId C80487EE-7113-49F8-85DD-2CFE30CC398E
<!--NeedCopy-->

A continuación, se muestra un archivo CustomerInfo.yml de ejemplo.

            # Created/Updated on 2020/01/29 16:46:47
            CustomerId: ‘markhof123’
            ClientId: ‘6713FEA6-46CC-4F8A-BC71-539F2DDK5384’
            Secret: ‘TwBLaaabbbaaaaaaaaaaw==’
            Environment: Production
            AltRootUrl: ‘’
            StopOnError: False
            AlternateFolder: ‘’
            Locale: ‘en-us’
            Editor: ‘C:\Program Files\Notepad++\notepad++.exe’
            Confirm: True
            DisplayLog: True

Rellenar archivo de asignación de zonas

Una zona local es el equivalente de la ubicación de recursos en la nube. A diferencia de otros componentes del sitio, no se puede importar la zona local a la nube automáticamente. En su lugar, debe asignarse manualmente mediante el archivo ZoneMapping.yml. Pueden producirse errores de importación si el nombre de la zona no está asociado a un nombre de ubicación de recursos existente.

Si los sitios locales tienen solo una zona y los sitios en la nube tienen solo una ubicación de recursos, la herramienta de configuración automatizada realiza la asociación correcta, eliminando la necesidad de administrar manualmente el archivo ZoneMapping.yml.

Sin embargo, si los sitios locales tienen varias zonas o los sitios en la nube tienen varias ubicaciones de recursos, actualice manualmente el archivo ZoneMapping.yml para reflejar la asignación correcta de las zonas locales a las ubicaciones de recursos en la nube.

El archivo ZoneMapping.yml se encuentra en %HOMEPATH%\Documents\Citrix\AutoConfig. El contenido del archivo .yml es un diccionario con el nombre de la zona como clave y el nombre de la ubicación de recursos como valor.

Por ejemplo, un sitio local de Citrix Virtual Apps and Desktops con una zona principal llamada «Zone-1» y una zona secundaria llamada «Zone-2» se migra a una implementación de Citrix DaaS con dos ubicaciones de recursos en la nube recién creadas llamadas «Cloud-RL-1» y «Cloud-RL-2». En este caso, el ZoneMapping.yml se configuraría de la siguiente manera:

            Zone-1: Cloud-RL-1

            Zone-2: Cloud-RL-2

Nota:

Añada un espacio entre los dos puntos y el nombre de la ubicación del recurso. Si se utilizan espacios en el nombre de la zona o de la ubicación del recurso, encierre el nombre entre comillas.

Actualizar el archivo de seguridad para las conexiones de host

Las conexiones de host y sus hipervisores asociados se pueden exportar e importar mediante ACT.

Agregar un hipervisor a una conexión de host requiere información de seguridad específica del tipo de hipervisor. Esta información no se puede exportar desde el sitio local por motivos de seguridad. Debe proporcionar la información manualmente para que la Configuración automatizada pueda importar correctamente las conexiones de host y los hipervisores al sitio en la nube.

El proceso de exportación crea el archivo CvadAcSecurity.yml en %HOMEPATH%\Documents\Citrix\AutoConfig que contiene marcadores de posición para cada elemento de seguridad necesario para el tipo de hipervisor específico. Debe actualizar el archivo CvadAcSecurity.yml antes de importarlo al sitio en la nube. Las actualizaciones del administrador se conservan en varias exportaciones con nuevos marcadores de posición de seguridad agregados según sea necesario. Los elementos de seguridad nunca se eliminan. Para obtener más información, consulte Actualizar manualmente el archivo CvadAcSecurity.yml

            HostConn1:
            ConnectionType: XenServer®
            UserName: root
            PasswordKey: rootPassword
            HostCon2:
            ConnectionType: AWS
            ApiKey: 78AB6083-EF60-4D26-B2L5-BZ35X00DA5CH
            SecretKey: TwBLaaaaaaaaaaaaaaaaaw==
            Region: East

Información de seguridad por hipervisor

A continuación, se muestra la información de seguridad necesaria para cada tipo de hipervisor.

  • XenServer, Hyper-V, VMware
    • Nombre de usuario
    • Contraseña de texto no cifrado
  • Microsoft Azure
    • ID de suscripción
    • ID de aplicación
    • Secreto de aplicación
  • AWS
    • ID de cuenta de servicio
    • Secreto de aplicación
    • Región

Consideraciones especiales de seguridad

Toda la información de seguridad se introduce como texto sin formato. Si no se recomienda el texto sin formato, las conexiones de host y los hipervisores asociados se pueden crear manualmente mediante Studio. Los nombres de las conexiones de host y de los hipervisores deben coincidir exactamente con sus homólogos locales para que los catálogos de máquinas que utilizan las conexiones de host se puedan importar correctamente.

Exportar la configuración local de Citrix Virtual Apps and Desktops

Mediante un comando de PowerShell export, puede exportar su configuración local existente y obtener los archivos .yml necesarios. Estos archivos se utilizan para importar la configuración deseada a Citrix Cloud.

Objetos de migración admitidos

Automated Configuration admite la migración de la configuración de los siguientes componentes:

  • Etiquetas
  • Administración delegada
    • Ámbitos
    • Roles
  • Conexiones de host
    • Un único grupo de recursos
    • Ámbitos de administración
  • Catálogos de máquinas
    • Ámbitos de administración
    • Máquinas
    • Acceso con PC remoto, Físicas, Agrupadas, Aprovisionadas, MCS, Asignadas
  • StoreFront™
  • Grupos de entrega
    • Directiva de acceso
    • Asociación de ámbito de administración
    • Directiva de acceso a aplicaciones
    • Directiva de asignación
    • Directiva de derechos/escritorio
    • Programaciones de energía
    • Persistencia de sesión
    • Preinicio de sesión
    • Programaciones de reinicio
    • Etiquetas
  • Grupos de aplicaciones
    • Asociación de ámbito de administrador
    • Grupos de entrega
    • Usuarios y grupos
  • Aplicaciones
    • Carpetas de aplicaciones
    • Iconos
    • Aplicaciones
    • FTA configuradas por el Broker
    • Etiquetas
  • Directivas de grupo
  • Preferencias de zona de usuario

Exportar la configuración local

  1. Haga doble clic en el icono de Configuración automática. Aparece una ventana de PowerShell.
  2. Ejecute el siguiente comando para exportar todos los componentes. La exportación de la configuración local no la modifica de ninguna manera.

    Export-CvadAcToFile
    <!--NeedCopy-->
    

Después de ejecutar cualquier cmdlet por primera vez, se crea una carpeta de exportación con los archivos de configuración .yml y los registros. La carpeta se encuentra en %HOMEPATH%\Documents\Citrix\AutoConfig. Cada exportación sucesiva crea una subcarpeta. La carpeta principal %HOMEPATH%\Documents\Citrix\AutoConfig siempre contiene los archivos exportados de la exportación más reciente.

Nota:

Si la Configuración automática no está instalada en el Delivery Controller, ejecute import-module Citrix.AutoConfig.Commands antes de usar la herramienta a través de PowerShell. Este paso no es necesario si abre la Configuración automática con el icono de Configuración automática.

Si encuentra algún error o excepción, consulte la sección Correcciones en el archivo de registro.

Importar la configuración a Citrix DaaS

Importante:

  • Al migrar una implementación local a la nube, asegúrese de que las GPO de dominio y de OU que contienen la configuración de Citrix se migren a la nube. Citrix Web Studio™ no es compatible con GPMC y, por lo tanto, las GPO de dominio y de OU no son visibles en Web Studio. El motor de directivas de Citrix aplica las GPO de dominio y de OU a los VDA y a los usuarios que se encuentran en los dominios y las OU. Después de iniciar sesión en un VDA, un usuario podría ver que las directivas de las GPO de dominio y de OU se aplican a su sesión. Sin embargo, los administradores no pueden ver estas directivas y configuraciones, lo que podría generar confusiones.

Orden de migración de componentes

Aquí se enumeran los componentes y sus dependencias. Las dependencias de un componente deben estar implementadas antes de que se pueda importar o fusionar. Si falta una dependencia, el comando de importación o fusión puede fallar. La sección Correcciones del archivo de registro muestra las dependencias que faltan si una importación o fusión falla.

  1. Etiquetas
    • Sin dependencias previas
  2. Administración delegada
    • Sin dependencias previas
  3. Conexiones de host
    • Información de seguridad en CvadAcSecurity.yml
  4. Catálogos de máquinas
    • Máquinas presentes en Active Directory
    • Conexiones de host
    • Etiquetas
  5. StoreFront
  6. Grupos de entrega
    • Máquinas presentes en Active Directory
    • Usuarios presentes en Active Directory
    • Catálogos de máquinas
    • Etiquetas
  7. Grupos de aplicaciones
    • Grupos de entrega
    • Etiquetas
  8. Aplicaciones
    • Grupos de entrega
    • Grupos de aplicaciones
    • Etiquetas
  9. Directivas de grupo
    • Grupos de entrega
    • Etiquetas
  10. Preferencias de zona de usuario

Ejecutar una importación

  1. Haga doble clic en el icono de Configuración automática. Aparece una ventana de PowerShell.
  2. Ejecute el siguiente comando para importar todos los componentes.

    Merge-CvadAcToSite
    <!--NeedCopy-->
    

Verifique el estado esperado con el nuevo estado actual. Varias opciones de importación controlan si los resultados de la importación son idénticos o un subconjunto del sitio local.

Después de ejecutar el cmdlet, se crea una carpeta de exportación con los archivos de configuración y los registros de .yml. La carpeta se encuentra en %HOMEPATH%\Documents\Citrix\AutoConfig.

Si encuentra algún error o excepción, consulte la sección Correcciones en el archivo de registro.

Nota:

Si la Configuración automatizada no está instalada en el Delivery Controller, ejecute import-module Citrix.AutoConfig.Commands antes de usar la herramienta a través de PowerShell. Este paso no es necesario si abre la Configuración automatizada usando el icono de Configuración automática.

Para revertir a su configuración original de Citrix DaaS, consulte Copia de seguridad de su configuración de Citrix DaaS.

Comprender la operación de importación

El proceso de importación está diseñado para realizar actualizaciones con precisión, realizar solo las actualizaciones necesarias y verificar que todas las actualizaciones se hayan realizado correctamente. Los pasos que se siguen en todas las operaciones de importación son:

  1. Leer el archivo .yml exportado (estado esperado).
  2. Leer la nube (estado actual).
  3. Hacer una copia de seguridad del estado de la nube anterior a la importación en archivos .yml (la copia de seguridad previa se puede restaurar si es necesario).
  4. Evaluar las diferencias entre el estado esperado y el actual. Esto determina qué actualizaciones realizar.
  5. Realizar las actualizaciones.
  6. Volver a leer la nube (nuevo estado actual).
  7. Hacer una copia de seguridad del estado de la nube posterior a la importación en archivos .yml (la copia de seguridad posterior se puede restaurar si es necesario).
  8. Comparar el nuevo estado actual con el estado esperado.
  9. Informar los resultados de la comparación.

Migración granular

Importante:

Para obtener más información sobre el orden de migración de componentes, consulte Orden de migración de componentes.

Puede migrar selectivamente solo componentes o incluso solo nombres de componentes.

  • Los parámetros de componente admitidos incluyen MachineCatalogs, Tags y otros.
  • Los parámetros de nombre de componente admitidos incluyen los parámetros IncludeByName y ExcludeByName, entre otros.

Para obtener más información sobre los parámetros y cómo usarlos, consulte Parámetros de migración granular.

Activar sitios

El controlador de entrega tanto en sitios locales como en la nube controla recursos como la intermediación de escritorios, aplicaciones y el reinicio de máquinas. Los problemas ocurren cuando un conjunto común de recursos es controlado por dos o más sitios. Esta situación puede ocurrir al migrar de un sitio local a un sitio en la nube. Es posible que los controladores de entrega locales y en la nube administren el mismo conjunto de recursos. Dicha administración dual puede provocar que los recursos dejen de estar disponibles e inmanejables, y puede ser difícil de diagnosticar.

La activación del sitio le permite controlar dónde se controla el sitio activo.

La activación del sitio se gestiona mediante el modo de mantenimiento del grupo de entrega. Los grupos de entrega se ponen en modo de mantenimiento cuando el sitio está inactivo. El modo de mantenimiento se elimina de los grupos de entrega para los sitios que están activos.

La activación del sitio no afecta ni gestiona el registro de VDA ni los catálogos de máquinas.

  • Set-CvadAcSiteActiveStateCloud
  • Set-CvadAcSiteActiveStateOnPrem

Todos los cmdlets admiten el IncludeByName y el ExcludeByName filtrado. Este parámetro le permite seleccionar qué grupos de entrega pueden cambiar su modo de mantenimiento. Los grupos de entrega se pueden cambiar selectivamente según sea necesario.

Importar y transferir el control a la nube

A continuación, se ofrece una descripción general de cómo importar y transferir el control del sitio local al sitio en la nube.

  1. Exporte e importe el sitio local a la nube. Asegúrese de que el parámetro –SiteActive no esté presente en ninguno de los cmdlets de importación. El sitio local está activo y el sitio en la nube inactivo. De forma predeterminada, los grupos de entrega del sitio en la nube están en modo de mantenimiento.
  2. Verifique el contenido y la configuración de la nube.
  3. Fuera del horario laboral, establezca el sitio local como inactivo. El parámetro –SiteActive debe estar ausente. Todos los grupos de entrega del sitio local están en modo de mantenimiento.
    • Set-CvadAcSiteActiveStateOnPrem
  4. Establezca el sitio en la nube como activo. El parámetro –SiteActive debe estar presente. Ningún grupo de entrega del sitio en la nube está en modo de mantenimiento.
    • Set-CvadAcSiteActiveStateCloud –SiteActive
  5. Verifique que el sitio en la nube esté activo y que el sitio local esté inactivo.

Transferir el control de nuevo al sitio local

Para transferir el control del sitio en la nube al sitio local:

  1. Fuera del horario laboral, establezca el sitio en la nube como inactivo. Todos los grupos de entrega del sitio en la nube están en modo de mantenimiento.
    • Set-CvadAcSiteActiveStateCloud
  2. Establezca el sitio local como activo. Ningún grupo de entrega del sitio local está en modo de mantenimiento.
    • Set-CvadAcSiteActiveStateOnPrem -SiteActive

Información adicional sobre la activación del sitio

  • Si no hay máquinas con administración de energía y no hay programaciones de reinicio (lo que normalmente significa que tampoco hay conexiones de host), todos los grupos de entrega en la nube se pueden importar como activos. Agregue -SiteActive a Merge-CvadAcToSite/Import-CvadAcToSite o ejecute Set-CvadAcSiteActiveStateCloud -SiteActive después de la importación.
  • Si las máquinas tienen administración de energía o hay programaciones de reinicio, se necesita un proceso diferente. Por ejemplo, al cambiar de local a la nube en esta situación, establezca el sitio local como inactivo mediante Set-CvadAcSiteActiveStateOnPrem. Luego, establezca el sitio en la nube como activo mediante Set-CvadAcSiteActiveStateCloud -SiteActive.
  • Los cmdlets Set-CvadAcSiteActiveStateCloud y Set-CvadAcSiteActiveStateOnPrem también se utilizan para revertir el proceso. Por ejemplo, ejecute Set-CvadAcSiteActiveStateCloud sin el parámetro -SiteActive, luego ejecute Set-CvadAcSiteActiveStateOnPrem con el parámetro -SiteActive.

Comprender la migración de catálogos aprovisionados por Machine Creation Services

Nota:

Esta función solo está disponible en las versiones 3.0 y posteriores. Compruebe su versión utilizando Get-CvadAcStatus dentro de la Configuración automatizada.

Los catálogos de Machine Creation Services (MCS) crean dos tipos diferentes de catálogos:

  • Cuando los cambios realizados en una máquina se pierden o se revierten (comúnmente SO de servidor, donde se publican las aplicaciones) – este es un caso de uso de VDI agrupado / multisesión
  • Cuando los cambios realizados en una máquina se conservan después de un reinicio (comúnmente SO de cliente con un usuario dedicado) – este es un caso de uso de VDI estático

El tipo de catálogo se puede confirmar en el nodo del catálogo en Citrix Studio y observando el valor “Datos de usuario:” del catálogo.

Nota:

MCS no se puede respaldar desde la nube utilizando la Configuración automatizada.

Catálogos de VDI agrupado / multisesión

Los catálogos con “Datos de usuario: Descartar” son catálogos de VDI agrupados y solo pueden migrar la imagen principal y la configuración. Las máquinas virtuales de estos catálogos no se migran. Esto se debe a que el ciclo de vida de la máquina virtual es mantenido por el sitio desde el que se importa, lo que significa que cada vez que se encienden las máquinas, su estado puede cambiar. Esto hace que la importación sea imposible, ya que los datos de importación de las máquinas virtuales se desincronizan rápidamente.

Cuando migra estos catálogos utilizando la herramienta, esta crea metadatos del catálogo e inicia la creación de la imagen principal, pero no se importan máquinas.

Dado que este proceso puede tardar un tiempo en crearse en función del tamaño de la imagen principal, el comando de importación dentro de la herramienta solo inicia la creación del catálogo MCS y no espera a que finalice. Una vez completada la importación, supervise el progreso de la creación del catálogo utilizando Studio en la implementación en la nube.

Una vez creada la imagen principal, puede aprovisionar máquinas. Tenga en cuenta las consideraciones de capacidad, ya que tendría capacidad consumida de su uso local.

Todos los demás objetos (grupos de entrega, aplicaciones, directivas, etc.) que utilizan ese catálogo se pueden importar y no tienen que esperar a la creación de la imagen principal. Cuando el catálogo haya terminado de crearse, se pueden añadir máquinas al catálogo importado y, a continuación, los usuarios pueden iniciar sus recursos.

Nota:

Utilice los mismos comandos disponibles dentro de la herramienta para migrar catálogos y todos los demás objetos.

Catálogos VDI estáticos

Nota:

Dado que esta operación importa detalles de bajo nivel que se almacenan en la base de datos, este proceso debe ejecutarse desde una máquina con acceso a la base de datos.

Los catálogos VDI estáticos migran la imagen principal, las configuraciones y todas las máquinas virtuales. A diferencia del caso de uso de VDI agrupado, no es necesario crear imágenes.

Los VDA deben apuntar al conector para que se registren en la nube.

Consulte la sección Activación de sitios para activar el sitio en la nube, de modo que la programación de reinicios, la administración de energía y otros elementos sean controlados por la nube.

Una vez completada la migración, si desea eliminar este catálogo de su sitio local, debe seleccionar dejar VM y cuenta de AD. De lo contrario, se eliminarán y el sitio en la nube quedaría apuntando a la VM eliminada.

Actualizar etiquetas MCS para detectar recursos huérfanos después de la migración

Después de migrar de una configuración local a un sitio en la nube, o de su configuración en la nube a otro sitio en la nube, debe actualizar las etiquetas de ID de sitio de MCS en el caso de las VM persistentes para que los recursos huérfanos se puedan detectar correctamente. Para ello, utilice el comando de PowerShell Set-ProvResourceTags. Actualmente, esta función es aplicable a Azure.

Los pasos detallados son los siguientes:

  1. Actualice las etiquetas de ID de sitio de MCS desde el nuevo sitio de Citrix mediante el comando de PowerShell Set-ProvResourceTags. Por ejemplo:

    Set-ProvResourceTags -ProvisioningSchemeUid xxxxx  [-VMName <String>] [-VMBatchSize XX] [-ResourceType XX]
    <!--NeedCopy-->
    

    O bien,

    Set-ProvResourceTags -ProvisioningSchemeName xxxxx  [-VMName <String>] [-VMBatchSize XX] [-ResourceType XX]
    <!--NeedCopy-->
    

Los detalles de los parámetros son los siguientes:

  • ProvisioningSchemeUid o ProvisioningSchemeName es un parámetro obligatorio.
  • VMName es un parámetro opcional. Si no se especifica VMName, se actualizan las etiquetas de todas las máquinas virtuales de este catálogo de máquinas.
  • VMBatchSize es un parámetro opcional para dividir todas las máquinas virtuales en lotes. Si no se especifica VMBatchSize, se aplica el valor predeterminado (10). El rango es de 1 a 60.
  • ResourceType puede ser uno de los siguientes:

    • MachineCatalog: Para actualizar las etiquetas de los recursos del catálogo de máquinas.
    • VirtualMachine: Para actualizar las etiquetas de los recursos relacionados con las máquinas virtuales.
    • All: (ResourceType predeterminado): Para actualizar las etiquetas de los recursos del catálogo de máquinas y de los recursos relacionados con las máquinas virtuales.