Citrix DaaS™

Migrar a configuração para o Citrix Cloud™

A Ferramenta de Configuração Automatizada (ACT) permite a migração da configuração do Citrix Virtual Apps and Desktops™ (políticas, aplicativos, catálogos, funções de administrador, escopos e outros) de um ou mais sites locais para o Citrix DaaS hospedado no Citrix Cloud. Ela também pode ser usada para migrar informações entre diferentes regiões ou locatários da nuvem.

Esta ferramenta descobre e exporta um ou mais sites locais como uma coleção de arquivos de configuração, que você pode editar opcionalmente. A configuração desses arquivos pode então ser importada para o Citrix DaaS. A migração é feita em etapas, executando a ferramenta várias vezes, permitindo que você alcance facilmente o estado de configuração desejado.

A ACT não é apenas uma ferramenta de migração única. Você pode usá-la para gerenciar suas operações diárias na nuvem, como:

  • Automatizar a transferência de contas de nuvem de teste ou de preparo para contas de nuvem de produção
  • Fazer backup e restaurar sua configuração
  • Dividir um ambiente de nuvem em várias nuvens

O vídeo de 2 minutos a seguir oferece um tour rápido pela Configuração Automatizada.

Para obter informações adicionais sobre a Configuração Automatizada, consulte Prova de Conceito: Ferramenta de Configuração Automatizada na Tech Zone.

Para uma análise mais aprofundada sobre como mover sua implantação e preparar sua configuração local para a migração, consulte Guia de Implantação: Migrando Citrix Virtual Apps and Desktops do local para o Citrix Cloud na Tech Zone.

Limitações conhecidas

Pré-requisitos para migrar sua configuração

Para exportar sua configuração do Citrix Virtual Apps™ and Desktops, você precisa:

  • Citrix Virtual Apps and Desktops: versão atual e sua antecessora imediata ou Citrix Virtual Apps and Desktops, XenApp e XenDesktop® LTSRs: todas as versões
  • Uma máquina ingressada no domínio com .NET Framework 4.7.2 ou posterior e o Citrix PowerShell SDK. Isso é instalado automaticamente no Delivery Controller. (Para executar em uma máquina diferente do Delivery Controller local, o Citrix Studio deve ser instalado, pois o Studio instala os snap-ins corretos do PowerShell. O instalador do Studio pode ser encontrado na mídia de instalação do Citrix Virtual Apps and Desktops.)

Para importar sua configuração para o Citrix DaaS, você precisa:

  • Uma máquina com acesso ao Citrix Cloud. Não precisa ser um Delivery Controller™ ou uma máquina ingressada no domínio.
  • Citrix DaaS provisionado.
  • Um local de recurso ativo com o Connector instalado e ingressado no mesmo domínio da configuração local.
  • A conectividade com sites que acessam o Citrix Cloud deve ser permitida e disponível. Para obter mais informações, consulte Requisitos de Sistema e Conectividade.

Nota:

A Configuração Automatizada não pode ser instalada em um sistema Cloud Connector.

Etapas principais

  1. Baixe a Ferramenta de Configuração Automatizada e revise os requisitos do sistema. Consulte Baixar Configuração Automatizada.
  2. Preencha o arquivo CustomerInfo.yml com seus valores de CustomerName, CustomerID e SecretKey gerados no portal do Citrix Cloud. Consulte Gerar o ID do cliente, ID do cliente e chave secreta e Preencher o arquivo de informações do cliente.
  3. Se o site local contiver várias zonas, atualize o arquivo ZoneMapping.yml para mapear as zonas para os locais de recurso do Citrix DaaS. Consulte Preencher o arquivo de mapeamento de zona.
  4. Se o site contiver várias conexões de hospedagem, atualize o arquivo CvadAcSecurity.yml com as informações de conexão para cada tipo de host que está sendo migrado para o Citrix DaaS. Se houver apenas uma única conexão de host, atualize o arquivo CvadACSecurity.yml com as informações de conexão para a conexão de host. Consulte Atualizar o arquivo de segurança para conexões de host.
  5. Abra a ACT e exporte seu site local usando o comando Export-CvadAcToFile. Consulte Objetos de migração suportados para a lista de componentes suportados para migração. Para obter informações sobre as etapas para exportar, consulte Exportar configuração local.
  6. Importe os componentes em etapas usando o comando Merge-CvadAcToSite. Alternativamente, migre o site inteiro de uma vez. Certifique-se de migrar os componentes na ordem listada em Ordem de migração de componentes. Para obter informações sobre as etapas para importar, consulte Executar uma importação.
  7. Ative o site da nuvem. Consulte Ativar sites.

Baixar Configuração Automatizada

Baixe e instale a ferramenta de Configuração Automatizada em Citrix Downloads.

Atualizar Configuração Automatizada

Para evitar erros de funcionalidade, use sempre a versão mais recente disponível da ACT.

Para saber a versão da sua ferramenta, faça o seguinte:

  1. Dê um clique duplo no ícone “Auto Config”. Uma janela do PowerShell será exibida.
  2. Execute o seguinte comando para verificar o número da sua versão.

    Get-CvadAcStatus
    <!--NeedCopy-->
    
  3. Verifique a versão da sua ferramenta em relação à versão listada em Citrix Downloads. A versão mais recente da ferramenta está lá.
  4. Baixe e instale a versão mais recente da ferramenta. Você não precisa desinstalar a versão antiga para atualizar a Configuração Automatizada.

Nota:

Ao executar cmdlets para acessar a nuvem na Configuração Automatizada, a ferramenta o alertará quando houver uma versão mais recente disponível para download. Para obter mais informações sobre cmdlets, consulte Cmdlets da ferramenta de Configuração Automatizada.

Gerar o ID do cliente, ID do cliente e chave secreta

Para migrar o site local para o Citrix DaaS, preencha o arquivo CustomerInfo.yml com o ID do cliente, ID do cliente e chave secreta do portal do Citrix Cloud.

Para recuperar o ID do cliente:

  1. Entre em sua conta do Citrix Cloud e selecione o cliente.
  2. Clique no ícone de grade e selecione “Identity and Access Management”.
  3. Navegue até “API access” > “Secure clients”. O ID do cliente é exibido na página.

Para recuperar o ID do cliente e a chave secreta:

  1. Na página “Secure clients”, insira um nome na caixa. Esse nome é usado para diferenciar entre vários IDs de cliente e chaves secretas.
  2. Clique em “Create Client” para criar o ID do cliente e a chave secreta.
  3. Copie o ID do cliente e a chave secreta para um local seguro e baixe o arquivo .csv contendo essas informações. Use o arquivo .csv para preencher o arquivo CustomerInfo.yml.

Nota:

  • O ID do cliente e a chave secreta não expiram. Se forem comprometidos, remova-os imediatamente usando o ícone “Lixeira” e crie novos.
  • A chave secreta não pode ser recuperada se for perdida ou esquecida; um novo ID do cliente e uma nova chave secreta devem ser criados.

Preencher o arquivo de informações do cliente

O arquivo CustomerInfo.yml elimina a necessidade de fornecer parâmetros de informações do cliente toda vez que o cmdlet é executado. Qualquer uma das informações do cliente pode ser substituída usando parâmetros de cmdlet.

Use o cmdlet New-CvadAcCustomerInfoFile para criar o arquivo CustomerInfo.yml.

Importante:

Não edite manualmente o arquivo CustomerInfo.yml. Isso pode causar erros de formatação inadvertidos.

O cmdlet New-CvadAcCustomerInfoFile tem os seguintes parâmetros obrigatórios.

  • CustomerId – ID do cliente.
  • ClientId – ID do cliente criado no Citrix Cloud.
  • Secret – segredo do cliente criado no Citrix Cloud.

Exemplo:

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

Você também pode criar o CustomerInfo.yml usando o parâmetro SecurityCsvFileSpec que aponta para o arquivo security.csv baixado. Você também deve especificar o CustomerId.

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

Use o cmdlet Set-CvadAcCustomerInfoFile para atualizar o arquivo CustomerInfo.yml. Este cmdlet altera apenas o Client ID.

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

A seguir, um exemplo do arquivo CustomerInfo.yml.

            # 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

Preencher o arquivo de mapeamento de zona

Uma zona local é o equivalente ao local de recurso da nuvem. Ao contrário de outros componentes do site, você não pode importar a zona local para a nuvem automaticamente. Em vez disso, ela deve ser mapeada manualmente usando o arquivo ZoneMapping.yml. Falhas de importação podem ocorrer se o nome da zona não estiver associado a um nome de local de recurso existente.

Se os sites locais tiverem apenas uma zona e os sites da nuvem tiverem apenas um local de recurso, a ferramenta de Configuração Automatizada fará a associação correta, eliminando a necessidade de gerenciar manualmente o arquivo ZoneMapping.yml.

No entanto, se os sites locais tiverem várias zonas ou os sites da nuvem tiverem vários locais de recurso, atualize manualmente o arquivo ZoneMapping.yml para refletir o mapeamento correto das zonas locais para os locais de recurso da nuvem.

O arquivo ZoneMapping.yml está localizado em %HOMEPATH%\Documents\Citrix\AutoConfig. O conteúdo do arquivo .yml é um dicionário com o nome da zona como chave e o nome do local de recurso como valor.

Por exemplo, um site local do Citrix Virtual Apps and Desktops com uma zona primária chamada “Zone-1” e uma zona secundária chamada “Zone-2” é migrado para uma implantação do Citrix DaaS com dois locais de recurso de nuvem recém-criados chamados “Cloud-RL-1” e “Cloud-RL-2”. Neste caso, o ZoneMapping.yml seria configurado da seguinte forma:

            Zone-1: Cloud-RL-1

            Zone-2: Cloud-RL-2

Nota:

Adicione um espaço entre os dois pontos e o nome do local de recurso. Se forem usados espaços no nome da zona ou do local de recurso, coloque o nome entre aspas.

Atualizar o arquivo de segurança para conexões de host

As conexões de host e seus hipervisores associados podem ser exportados e importados usando a ACT.

Adicionar um hipervisor a uma conexão de host requer informações de segurança específicas para o tipo de hipervisor. Essas informações não podem ser exportadas do site local por considerações de segurança. Você deve fornecer as informações manualmente para que a Configuração Automatizada possa importar com sucesso as conexões de host e os hipervisores para o site da nuvem.

O processo de exportação cria o arquivo CvadAcSecurity.yml em %HOMEPATH%\Documents\Citrix\AutoConfig contendo espaços reservados para cada item de segurança necessário para o tipo de hipervisor específico. Você deve atualizar o arquivo CvadAcSecurity.yml antes de importar para o site da nuvem. As atualizações do administrador são retidas em várias exportações com novos espaços reservados de segurança adicionados conforme necessário. Os itens de segurança nunca são removidos. Para obter mais informações, consulte Atualizar manualmente o arquivo CvadAcSecurity.yml

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

Informações de segurança por hipervisor

A seguir, a lista de informações de segurança necessárias para cada tipo de hipervisor.

  • XenServer, Hyper-V, VMware
    • Nome de usuário
    • Senha em texto claro
  • Microsoft Azure
    • ID da Assinatura
    • ID do Aplicativo
    • Segredo do Aplicativo
  • AWS
    • ID da Conta de Serviço
    • Segredo do Aplicativo
    • Região

Considerações especiais de segurança

Todas as informações de segurança são inseridas como texto claro. Se o texto claro não for recomendado, as conexões de host e os hipervisores associados podem ser criados manualmente usando o Studio. Os nomes das conexões de host e dos hipervisores devem corresponder exatamente aos seus equivalentes locais para que os catálogos de máquinas que usam as conexões de host possam ser importados com sucesso.

Exportar sua configuração local do Citrix Virtual Apps and Desktops

Usando um comando export do PowerShell, você pode exportar sua configuração local existente e obter os arquivos .yml necessários. Esses arquivos são usados para importar sua configuração desejada para o Citrix Cloud.

Objetos de migração suportados

A Configuração Automatizada suporta a movimentação da configuração dos seguintes componentes:

  • Tags
  • Administrador Delegado
    • Escopos
    • Funções
  • Conexões de Host
    • Um Único Pool de Recursos
    • Escopos de Administrador
  • Catálogos de Máquinas
    • Escopos de Administrador
    • Máquinas
    • Acesso Remoto a PC, Físico, Agrupado, Provisionado, MCS, Atribuído
  • StoreFront™
  • Grupos de Entrega
    • Política de Acesso
    • Associação de Escopo de Administrador
    • Política de Acesso a Aplicativos
    • Política de Atribuição
    • Política de Direito/Desktop
    • Agendamentos de Energia
    • Persistência de Sessão
    • Pré-lançamento de Sessão
    • Agendamentos de Reinicialização
    • Tags
  • Grupos de Aplicativos
    • Associação de Escopo de Administrador
    • Grupos de Entrega
    • Usuários e Grupos
  • Aplicativos
    • Pastas de Aplicativos
    • Ícones
    • Aplicativos
    • FTAs Configurados pelo Broker
    • Tags
  • Políticas de Grupo
  • Preferências de Zona do Usuário

Exportar configuração local

  1. Dê um clique duplo no ícone “Auto Config”. Uma janela do PowerShell será exibida.
  2. Execute o seguinte comando para exportar todos os componentes. Exportar sua configuração local não a altera de forma alguma.

    Export-CvadAcToFile
    <!--NeedCopy-->
    

Depois de executar qualquer cmdlet pela primeira vez, uma pasta de exportação com os arquivos de configuração .yml e logs é criada. A pasta está em %HOMEPATH%\Documents\Citrix\AutoConfig. Cada exportação sucessiva cria uma subpasta. A pasta pai %HOMEPATH%\Documents\Citrix\AutoConfig sempre contém os arquivos exportados da exportação mais recente.

Nota:

Se a Configuração Automatizada não estiver instalada no Delivery Controller, execute import-module Citrix.AutoConfig.Commands antes de usar a ferramenta via PowerShell. Esta etapa não é necessária se você abrir a Configuração Automatizada usando o ícone “Auto Config”.

Se você encontrar quaisquer erros ou exceções, consulte a seção “Fixups” no arquivo de log.

Importar sua configuração para o Citrix DaaS

Importante:

  • Ao migrar uma implantação local para a nuvem, certifique-se de que os GPOs de domínio e OU que contêm as configurações do Citrix sejam migrados para a nuvem. O Citrix Web Studio™ não suporta GPMC e, portanto, os GPOs de domínio e OU não são visíveis no Web Studio. O mecanismo de política do Citrix impõe os GPOs de domínio e OU em VDAs e usuários que estão nos domínios e OUs. Após o login em um VDA, um usuário pode ver que as políticas dos GPOs de domínio e OU são aplicadas à sua sessão. No entanto, os administradores não podem ver essas políticas e configurações, o que pode levar a confusões.

Ordem de migração de componentes

Os componentes e suas dependências estão listados aqui. As dependências de um componente devem estar em vigor antes que ele possa ser importado ou mesclado. Se uma dependência estiver faltando, isso pode fazer com que o comando de importação ou mesclagem falhe. A seção “Fixups” do arquivo de log mostra as dependências ausentes se uma importação ou mesclagem falhar.

  1. Tags
    • Sem pré-dependências
  2. Administrador Delegado
    • Sem pré-dependências
  3. Conexões de Host
    • Informações de Segurança em CvadAcSecurity.yml
  4. Catálogos de Máquinas
    • Máquinas presentes no Active Directory
    • Conexões de Host
    • Tags
  5. StoreFront
  6. Grupos de Entrega
    • Máquinas presentes no Active Directory
    • Usuários presentes no Active Directory
    • Catálogos de Máquinas
    • Tags
  7. Grupos de Aplicativos
    • Grupos de Entrega
    • Tags
  8. Aplicativos
    • Grupos de Entrega
    • Grupos de Aplicativos
    • Tags
  9. Políticas de Grupo
    • Grupos de Entrega
    • Tags
  10. Preferências de Zona do Usuário

Executar uma importação

  1. Dê um clique duplo no ícone “Auto Config”. Uma janela do PowerShell será exibida.
  2. Execute o seguinte comando para importar todos os componentes.

    Merge-CvadAcToSite
    <!--NeedCopy-->
    

Verifique o estado esperado com o novo estado atual. Várias opções de importação controlam se os resultados da importação são idênticos ou um subconjunto do site local.

Depois de executar o cmdlet, uma pasta de exportação com os arquivos de configuração .yml e logs é criada. A pasta está em %HOMEPATH%\Documents\Citrix\AutoConfig.

Se você encontrar quaisquer erros ou exceções, consulte a seção “Fixups” no arquivo de log.

Nota:

Se a Configuração Automatizada não estiver instalada no Delivery Controller, execute import-module Citrix.AutoConfig.Commands antes de usar a ferramenta via PowerShell. Esta etapa não é necessária se você abrir a Configuração Automatizada usando o ícone “Auto Config”.

Para reverter para sua configuração original do Citrix DaaS, consulte Fazendo backup de sua configuração do Citrix DaaS.

Entender a operação de importação

O processo de importação foi projetado para realizar atualizações com precisão, executar apenas as atualizações necessárias e verificar se todas as atualizações foram feitas corretamente. As etapas são seguidas em todas as operações de importação:

  1. Leia o arquivo .yml exportado (estado esperado).
  2. Leia a nuvem (estado atual).
  3. Faça backup do estado da nuvem pré-importação para arquivos .yml (o pré-backup pode ser restaurado se necessário).
  4. Avalie as diferenças entre o estado esperado e o estado atual. Isso determina quais atualizações fazer.
  5. Faça as atualizações.
  6. Releia a nuvem (novo estado atual).
  7. Faça backup do estado da nuvem pós-importação para arquivos .yml (o pós-backup pode ser restaurado se necessário).
  8. Compare o novo estado atual com o estado esperado.
  9. Relate os resultados da comparação.

Migração granular

Importante:

Para obter mais informações sobre a ordem de migração de componentes, consulte Ordem de migração de componentes.

Você pode migrar seletivamente apenas componentes ou até mesmo apenas nomes de componentes.

  • Os parâmetros de componente suportados incluem MachineCatalogs, Tags e outros.
  • Os parâmetros de nome de componente suportados incluem os parâmetros IncludeByName e ExcludeByName, entre outros.

Para obter mais informações sobre parâmetros e como usá-los, consulte Parâmetros de migração granular.

Ativar sites

O Delivery Controller em sites locais e na nuvem controla recursos como a intermediação de desktops, aplicativos e a reinicialização de máquinas. Problemas ocorrem quando um conjunto comum de recursos é controlado por dois ou mais sites. Essa situação pode ocorrer ao migrar de um site local para um site na nuvem. É possível que os Delivery Controllers locais e da nuvem gerenciem o mesmo conjunto de recursos. Tal gerenciamento duplo pode levar a recursos indisponíveis e incontroláveis, e pode ser difícil de diagnosticar.

A ativação do site permite que você controle onde o site ativo é controlado.

A ativação do site é gerenciada usando o modo de manutenção do grupo de entrega. Os grupos de entrega são colocados em modo de manutenção quando o site está inativo. O modo de manutenção é removido dos grupos de entrega para sites que estão ativos.

A ativação do site não afeta ou gerencia o registro de VDA ou catálogos de máquinas.

  • Set-CvadAcSiteActiveStateCloud
  • Set-CvadAcSiteActiveStateOnPrem

Todos os cmdlets suportam a filtragem por IncludeByName e ExcludeByName. Este parâmetro permite que você selecione quais grupos de entrega podem ter seu modo de manutenção alterado. Os grupos de entrega podem ser alterados seletivamente conforme necessário.

Importar e transferir o controle para a nuvem

A seguir, uma descrição de alto nível sobre como importar e transferir o controle do site local para o site da nuvem.

  1. Exporte e importe o site local para a nuvem. Certifique-se de que o parâmetro –SiteActive não esteja presente em nenhum dos cmdlets de importação. O site local está ativo e o site da nuvem inativo. Por padrão, os grupos de entrega do site da nuvem estão em modo de manutenção.
  2. Verifique o conteúdo e a configuração da nuvem.
  3. Durante o horário de folga, defina o site local como inativo. O parâmetro –SiteActive deve estar ausente. Todos os grupos de entrega do site local estão em modo de manutenção.
    • Set-CvadAcSiteActiveStateOnPrem
  4. Defina o site da nuvem como ativo. O parâmetro –SiteActive deve estar presente. Nenhum grupo de entrega do site da nuvem está em modo de manutenção.
    • Set-CvadAcSiteActiveStateCloud –SiteActive
  5. Verifique se o site da nuvem está ativo e o site local está inativo.

Transferir o controle de volta para o site local

Para transferir o controle do site da nuvem para o site local:

  1. Durante o horário de folga, defina o site da nuvem como inativo. Todos os grupos de entrega do site da nuvem estão em modo de manutenção.
    • Set-CvadAcSiteActiveStateCloud
  2. Defina o site local como ativo. Nenhum grupo de entrega do site local está em modo de manutenção.
    • Set-CvadAcSiteActiveStateOnPrem -SiteActive

Informações adicionais de ativação do site

  • Se nenhuma máquina for gerenciada por energia e não houver agendamentos de reinicialização (o que geralmente significa que também não há conexões de host), todos os grupos de entrega da nuvem podem ser importados como ativos. Adicione -SiteActive a Merge-CvadAcToSite/Import-CvadAcToSite ou execute Set-CvadAcSiteActiveStateCloud -SiteActive após a importação.
  • Se as máquinas forem gerenciadas por energia ou houver agendamentos de reinicialização, um processo diferente será necessário. Por exemplo, ao alternar do local para a nuvem nesta situação, defina o site local como inativo usando Set-CvadAcSiteActiveStateOnPrem. Em seguida, defina o site da nuvem como ativo usando Set-CvadAcSiteActiveStateCloud -SiteActive.
  • Os cmdlets Set-CvadAcSiteActiveStateCloud e Set-CvadAcSiteActiveStateOnPrem também são usados para reverter o processo. Por exemplo, execute Set-CvadAcSiteActiveStateCloud sem o parâmetro -SiteActive e, em seguida, execute Set-CvadAcSiteActiveStateOnPrem com o parâmetro -SiteActive.

Entender a migração de catálogos provisionados pelo Machine Creation Services

Nota:

Este recurso está disponível apenas nas versões 3.0 e posteriores. Verifique sua versão usando Get-CvadAcStatus dentro da Configuração Automatizada.

Os catálogos do Machine Creation Services (MCS) criam dois tipos diferentes de catálogos:

  • Quando as alterações feitas em uma máquina são perdidas ou revertidas (comumente SO de Servidor, onde os aplicativos são publicados) – este é um caso de uso de VDI agrupado / multi-sessão
  • Quando as alterações feitas em uma máquina são preservadas após a reinicialização (comumente SO de cliente com um usuário dedicado) – este é um caso de uso de VDI estático

O tipo de catálogo pode ser confirmado no nó do catálogo no Citrix Studio e observando o valor “User data:” do catálogo.

Nota:

O MCS não pode ser feito backup da nuvem usando a Configuração Automatizada.

Catálogos de VDI agrupado / multi-sessão

Catálogos com “User data: Discard” são catálogos de VDI agrupado e só podem migrar a imagem principal e a configuração. Nenhuma máquina virtual nesses catálogos é migrada. Isso ocorre porque o ciclo de vida da máquina virtual é mantido pelo site de onde você está importando, o que significa que toda vez que as máquinas são ligadas, seu estado pode mudar. Isso torna a importação impossível, pois os dados de importação para as máquinas virtuais rapidamente ficam fora de sincronia.

Ao migrar esses catálogos usando a ferramenta, ela cria metadados de catálogo e inicia a criação da imagem principal, mas nenhuma máquina é importada.

Como esse processo pode levar algum tempo para ser criado com base no tamanho da imagem principal, o comando de importação dentro da ferramenta apenas inicia a criação do catálogo MCS e não espera que ele termine. Após a conclusão da importação, monitore o progresso da criação do catálogo usando o Studio na implantação da nuvem.

Uma vez que a imagem principal é criada, você pode provisionar máquinas. Considere as considerações de capacidade, pois você teria capacidade consumida do seu uso local.

Todos os outros objetos (grupos de entrega, aplicativos, políticas e assim por diante) que usam esse catálogo podem ser importados e não precisam esperar pela criação da imagem principal. Quando o catálogo terminar de ser criado, as máquinas podem ser adicionadas ao catálogo importado e, então, os usuários podem iniciar seus recursos.

Nota:

Use os mesmos comandos disponíveis na ferramenta para migrar catálogos e todos os outros objetos.

Catálogos de VDI estático

Nota:

Como esta operação importa detalhes de baixo nível que são armazenados no banco de dados, este processo deve ser executado a partir de uma máquina com acesso ao banco de dados.

Os catálogos de VDI estático migram a imagem principal, as configurações e todas as máquinas virtuais. Ao contrário do caso de uso de VDI agrupado, nenhuma imagem precisa ser criada.

Os VDAs devem ser apontados para o conector para que se registrem na nuvem.

Consulte a seção Ativando sites para tornar o site da nuvem ativo, de modo que o agendamento de reinicialização, o gerenciamento de energia e outros itens sejam controlados pela nuvem.

Uma vez concluída a migração, se você quiser excluir este catálogo do seu site local, você deve selecionar “manter VM e conta AD”. Caso contrário, eles serão excluídos e o site da nuvem ficaria apontando para a VM excluída.

Atualizar tags MCS para detectar recursos órfãos após a migração

Depois de migrar da configuração local para um site na nuvem, ou da sua configuração da nuvem para outro site na nuvem, você deve atualizar as tags de ID do site MCS no caso de VMs persistentes para que os recursos órfãos possam ser detectados corretamente. Para fazer isso, use o comando PowerShell Set-ProvResourceTags. Atualmente, este recurso é aplicável ao Azure.

As etapas detalhadas são as seguintes:

  1. Atualize as tags de ID do site MCS do novo site Citrix usando o comando PowerShell Set-ProvResourceTags. Por exemplo:

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

    Ou,

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

Os detalhes dos parâmetros são os seguintes:

  • ProvisioningSchemeUid ou ProvisioningSchemeName é um parâmetro obrigatório.
  • VMName é um parâmetro opcional. Se nenhum VMName for especificado, as tags de todas as VMs deste catálogo de máquinas serão atualizadas.
  • VMBatchSize é um parâmetro opcional para dividir todas as VMs em lotes. Se nenhum VMBatchSize for especificado, o valor padrão (10) será aplicado. O intervalo é de 1 a 60.
  • ResourceType pode ser um dos seguintes:
    • MachineCatalog: Para atualizar tags de recursos de catálogo de máquinas.
    • VirtualMachine: Para atualizar tags de recursos relacionados a VM.
    • All: (ResourceType padrão): Para atualizar tags de recursos de catálogo de máquinas e relacionados a VM.