Migrar la configuración a Citrix Cloud™

La herramienta Automated Configuration Tool (ACT) permite migrar la configuración de Citrix Virtual Apps and Desktops™ (directivas, aplicaciones, catálogos, roles de administrador, ámbitos y otros) de uno o varios sitios locales a Citrix DaaS alojado en Citrix Cloud. También se puede utilizar 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 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 utilizarla 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
• Hacer copias de seguridad y restaurar la configuración
• Dividir un entorno de nube en varias nubes

El siguiente vídeo de 2 minutos ofrece un recorrido rápido por Automated Configuration.

Para obtener información adicional sobre Automated Configuration, consulte Proof of Concept: Automated Configuration Tool en Tech Zone.

Para un análisis más detallado sobre cómo trasladar su implementación y preparar su configuración local para la migración, consulte Deployment Guide: Migrating Citrix Virtual Apps and Desktops from on-premises to Citrix Cloud en Tech Zone.

Limitaciones conocidas

• Los catálogos de máquinas aprovisionados mediante Machine Creation Services™ tienen consideraciones especiales. Para obtener más información sobre MCS, consulte Understand migrating Machine Creation Services provisioned catalogs.

Requisitos previos para migrar la configuración

Para exportar la 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 los valores 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 migre 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 de una vez. Asegúrese de migrar los componentes en el orden indicado 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 Citrix Downloads.

Actualizar Automated Configuration

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

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

1. Haga doble clic en el icono de Auto Config. Aparece una ventana de PowerShell.

2. Ejecute el siguiente comando para comprobar el número de versión.

   Get-CvadAcStatus
   <!--NeedCopy-->
   

3. Compruebe la versión de su herramienta con la versión que aparece en Citrix Downloads. La versión más reciente de la herramienta se encuentra allí.
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 la Papelera y cree otros nuevos.
• La clave secreta no se puede recuperar si se pierde u olvida; se debe 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 archivo 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 de recursos. Si se utilizan espacios en el nombre de la zona o de la ubicación de recursos, 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 claro
• 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 export PowerShell, 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 administrador
• Catálogos de máquinas
  • Ámbitos de administrador
  • Máquinas
  • Acceso con PC remoto, Físico, Agrupado, Aprovisionado, MCS, Asignado
• StoreFront™
• Grupos de entrega
  • Directiva de acceso
  • Asociación de ámbito de administrador
  • Directiva de acceso a aplicaciones
  • Directiva de asignación
  • Directiva de derechos/escritorio
  • Programaciones de energía
  • Persistencia de sesión
  • Inicio previo 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 configurados por el Broker
  • Etiquetas
• Directivas de grupo
• Preferencias de zona de usuario

Exportar 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 y los registros .yml. 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 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 con el icono de Configuración automática.

Si encuentra algún error o excepción, consulte la sección Correcciones del 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 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 OU no son visibles en Web Studio. El motor de directivas de Citrix aplica las GPO de dominio y 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 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 en su lugar antes de que pueda importarse o fusionarse. Si falta una dependencia, puede provocar que el comando de importación o fusión falle. 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 .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 de forma precisa, 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 estado 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 más.
• 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 utilizarlos, consulte Parámetros de migración granular.

Activar sitios

El Delivery Controller, tanto en sitios locales como en la nube, controla recursos como la intermediación de escritorios, aplicaciones y el reinicio de máquinas. Surgen problemas 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 tanto los Delivery Controllers locales como los de la nube administren el mismo conjunto de recursos. Esta administración dual puede provocar que los recursos dejen de estar disponibles e inmanejables, y puede ser difícil de diagnosticar.

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

La activación de sitios 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 de sitios no afecta ni gestiona el registro de VDA ni los catálogos de máquinas.

• Set-CvadAcSiteActiveStateCloud
• Set-CvadAcSiteActiveStateOnPrem

Todos los cmdlets admiten el filtrado de IncludeByName y ExcludeByName. 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 un entorno local a la nube en esta situación, establezca el sitio local como inactivo usando Set-CvadAcSiteActiveStateOnPrem. Luego, establezca el sitio en la nube como activo usando 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 y 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 usando 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 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 de catálogo en Citrix Studio y observando el valor de “Datos de usuario:” del catálogo.

Nota:

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

Catálogos de VDI agrupados/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 lo mantiene el sitio desde el que se importa, lo que significa que cada vez que se encienden las máquinas, su estado podría 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, se crean metadatos del catálogo y se 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 de MCS y no espera a que finalice. Una vez completada la importación, supervise el progreso de la creación del catálogo mediante 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 la capacidad se consumiría 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 agregar máquinas al catálogo importado y, a continuación, los usuarios pueden iniciar sus recursos.

Nota:

Utilice los mismos comandos disponibles en 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 (#activate-sites) para activar el sitio en la nube, de modo que el programa de reinicio, 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 la VM y la cuenta de AD. De lo contrario, se eliminarán y el sitio en la nube quedaría apuntando a la VM eliminada.

Actualizar las etiquetas de 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 del 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.