Citrix DaaS

Migrar a configuração para o Citrix Cloud

Por que usar a Configuração Automatizada

Os administradores de TI responsáveis por ambientes grandes ou complexos geralmente consideram as migrações um processo tedioso. Frequentemente, eles acabam escrevendo suas próprias ferramentas para realizar essa tarefa com sucesso, pois ela tende a ser específica para seus casos de uso.

A Citrix quer ajudar a facilitar esse processo automatizando o processo de migração usando a ferramenta Automated Configuration. Os administradores podem testar facilmente as configurações atuais no Citrix Cloud e aproveitar os benefícios oferecidos pelo Citrix DaaS (anteriormente Citrix Virtual Apps and Desktops Service), mantendo seus ambientes atuais intactos. Também não há impacto no usuário final, pois a Configuração Automatizada funciona perfeitamente em segundo plano. Esses benefícios incluem sobrecarga administrativa reduzida quando a Citrix gerencia parte do back-end e do plano de controle, atualizações automáticas e personalizáveis de componentes do Citrix Cloud e outros.

A Citrix usa a configuração padrão do setor como código para fornecer um mecanismo para ajudar a automatizar os processos de migração. A Configuração Automatizada descobre e exporta um ou mais sites locais como uma coleção de arquivos de configuração. A configuração desses arquivos pode ser importada para o Citrix DaaS.

A Configuração Automatizada também permite que os administradores mesclem vários sites locais em um único site, o que evita conflitos de nomes. Os administradores podem controlar se a configuração local ou na nuvem controla os recursos.

A Configuração Automatizada não é apenas uma ferramenta de migração única, mas também pode automatizar sua configuração diária no Citrix Cloud. Mover a configuração do Citrix DaaS pode ser benéfico por vários motivos:

  • Sincronizar seu site do teste ou do estágio para a produção
  • Fazer Backup e restauração da sua configuração
  • Atingir limites de recursos
  • Migrar de uma região para outra

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

Para obter informações adicionais sobre Configuração Automatizada, consulte Proof of Concept: Automated Configuration Tool na Tech Zone.

Para uma análise mais aprofundada sobre como mover sua implantação e preparar sua configuração local para migração, consulte Deployment Guide: Migrating Citrix Virtual Apps and Desktops from on-premises to Citrix Cloud na Tech Zone.

Baixar a Configuração Automatizada

Baixe e instale a ferramenta Automated Configuration do Citrix Downloads.

Importante:

Para evitar erros na funcionalidade, use sempre a versão mais recente disponível da Configuração Automatizada.

Atualizando a Configuração Automatizada

Ao executar cmdlets que acessam a nuvem na Configuração Automatizada, a ferramenta alerta quando há uma versão mais recente disponível para download.

Atualização da Configuração Automatizada

Você pode ter certeza de que tem a versão mais recente seguindo as etapas abaixo:

  1. Clique duas vezes no ícone Configuração Automatizada. Uma janela do PowerShell é exibida.
  2. Execute o seguinte comando para verificar o número da versão.

    Get-CvadAcStatus

  3. Verifique a versão da ferramenta em relação à versão listada no alerta ou em Citrix Downloads. A versão mais recente da ferramenta está localizada ali.
  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:

O alerta aparece sempre que você executa um cmdlet que acessa a nuvem. Para obter mais informações sobre cmdlets, consulte Cmdlets da ferramenta Automated Configuration.

Limitações conhecidas

Objetos de migração compatíveis

A Configuração Automatizada oferece suporte à movimentação da configuração dos seguintes componentes:

  • Marcas
  • Administrador delegado
    • Escopos
    • Funções
  • Conexões de host
    • Um único pool de recursos
    • Escopos de administração
  • Catálogos de máquinas
    • Escopos de administração
    • Máquinas
    • Acesso ao PC remoto, físico, em pool, provisionado, MCS, atribuído
  • StoreFronts
  • Grupos de entrega
    • Política de acesso
    • Associação de escopo de administração
    • Política de acesso a aplicativos
    • Política de atribuição
    • Política de direitos/área de trabalho
    • Programações de energia
    • Persistência de sessão
    • Pré-lançamento da sessão
    • Agendas de reinicialização
    • Marcas
  • Grupos de aplicativos
    • Associação de escopo de administração
    • Grupos de entrega
    • Usuários e grupos
  • Aplicativos
    • Pastas de aplicativos
    • Ícones
    • Aplicativos
    • FTAs configurados por agente
    • Marcas
  • Políticas de grupo
  • Preferências de zona de usuário

Ordem de migração de componentes

Os componentes e suas dependências estão listados aqui. As dependências de um componente devem existir antes que ele possa ser importado ou mesclado. Se uma dependência estiver ausente, isso pode fazer com que o comando import ou merge não funcione. A seção Fixups do arquivo de log mostra as dependências ausentes se uma importação ou mesclagem não funcionar.

  1. Marcas
    • 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
    • Marcas
  5. StoreFronts
  6. Grupos de entrega
    • Máquinas presentes no Active Directory
    • Usuários presentes no Active Directory
    • Catálogos de máquinas
    • Marcas
  7. Grupos de aplicativos
    • Grupos de entrega
    • Marcas
  8. Aplicativos
    • Grupos de entrega
    • Grupos de aplicativos
    • Marcas
  9. Políticas de grupo
    • Grupos de entrega
    • Marcas
  10. Preferências de zona de usuário

Pré-requisitos comuns

A seguir estão alguns pré-requisitos comuns que são necessários para que a Configuração Automatizada funcione corretamente. Esses pré-requisitos são usados tanto em migrações locais para nuvem quanto de nuvem para nuvem.

Geração do ID do consumidor, o ID do cliente e a chave secreta

Antes de iniciar a migração usando a Configuração Automatizada, você precisa do seu ID de consumidor do Citrix Cloud e deve criar um ID de cliente e uma chave secreta para importar sua configuração para o Citrix Cloud. Todos os cmdlets que acessam a nuvem exigem esses valores.

As etapas a seguir permitem recuperar o ID de consumidor e criar o ID do cliente e a chave secreta.

Para recuperar a ID do consumidor:

  1. Faça login na sua conta do Citrix Cloud e selecione o consumidor.

    imagem do ID do consumidor 1

  2. Clique no menu de hambúrguer e selecione Identity and Access Management no menu suspenso.

    imagem de ID do consumidor 2

  3. A ID do consumidor está localizada na página Identity and Access Management.

    imagem de ID do consumidor 35

Para recuperar o ID do cliente e a chave secreta:

  1. Na página Identity and Access Management, clique na guia API Access.

    imagem de ID do cliente 3

  2. Digite um nome na caixa. Esse nome é usado para diferenciar entre vários IDs de cliente e chaves secretas. Clique em Create Client para criar o ID do cliente e a chave secreta.

    imagem de ID do cliente 4

  3. A caixa de diálogo a seguir aparece depois que você cria com êxito o ID do cliente e a chave secreta. Tenha o cuidado de copiar os dois valores para um local seguro e baixar o arquivo.csv que contém essas informações. O arquivo .csv pode ser usado para criar o arquivo CustomerInfo.yml.

    imagem de ID do cliente 5

  4. O ID do cliente e a chave secreta são criados com êxito.

    imagem de ID do cliente 6

Coloque esses valores em um local seguro e compartilhe somente com membros confiáveis da empresa que precisam acessar a ferramenta ou acessar as APIs Rest da nuvem. O ID do cliente e a chave secreta não expiram. Se eles forem comprometidos, remova-os imediatamente usando o ícone de Lixeira e crie novos.

Nota:

A chave secreta não pode ser recuperada se for perdida ou esquecida; devem ser criados um novo ID de cliente e chave secreta.

Preenchendo o arquivo de informações do cliente

O uso do arquivo CustomerInfo.yml elimina a necessidade de fornecer parâmetros de informações do cliente com a execução de cada cmdlet. Qualquer uma das informações do cliente pode ser substituída usando parâmetros de cmdlet.

Crie o arquivo CustomerInfo.yml usando o cmdlet New-CvadAcCustomerInfoFile.

Importante:

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

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

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

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

Você também pode criar o CustomerInfo.yml usando o SecurityCsvFileSpec parâmetro 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

Atualize o arquivo CustomerInfo.yml usando o cmdlet Set-CvadAcCustomerInfoFile. Esse cmdlet altera apenas o ID do cliente.

Set-CvadAcCustomerInfoFile -ClientId C80487EE-7113-49F8-85DD-2CFE30CC398E

Veja a seguir um exemplo de 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

Preenchimento do arquivo de mapeamento de zona

Uma zona local é o equivalente ao local do 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, ele deve ser mapeado 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 recursos existente.

Para sites locais com apenas uma zona e sites de nuvem apenas um local de recursos, a ferramenta Automated Configuration faz a associação correta, eliminando a necessidade de gerenciar manualmente o arquivo ZoneMapping.yml.

No caso de sites locais com várias zonas ou sites de nuvem com vários locais de recursos, o arquivo ZoneMapping.yml deve ser atualizado manualmente para refletir o mapeamento correto de zonas locais para locais de recursos na nuvem. Isso deve ser feito antes de tentar qualquer operação de importação para a 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 do recurso como o valor.

Como 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 recursos de nuvem recém-criados chamados “Cloud-RL-1” e “Cloud-RL-2”. Nesse caso, o ZoneMapping.yml seria configurado da seguinte forma:

            Zone-1: Cloud-RL-1

            Zone-2: Cloud-RL-2

Nota:

Deve haver um espaço entre os dois pontos e o nome do local do recurso. Se forem usados espaços na zona ou no nome do local do recurso, escreva o nome entre aspas.

Conexões de host

As conexões de host e seus hipervisores associados podem ser exportados e importados usando a Configuração Automatizada.

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 questões de segurança. Você deve fornecer as informações manualmente para que a Configuração Automatizada possa importar com êxito conexões de host e 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 mantidas em várias exportações com novos espaços reservados de segurança adicionados conforme necessário. 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

O seguinte lista as informações de segurança necessárias para cada tipo de hipervisor.

  • XenServer, Hyper-V, VMware
    • Nome de usuário
    • Senha com texto não criptografado
  • Microsoft Azure
    • ID de assinatura
    • ID do aplicativo
    • Segredo do aplicativo
  • Amazon Web Services
    • ID de 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 não criptografado. Se o texto não criptografado não for recomendado, as conexões de host e os hipervisores associados poderão ser criados manualmente usando a interface Manage > Full Configuration. As conexões de host e os nomes do hipervisor devem corresponder exatamente às suas contrapartes locais para que os catálogos de máquinas que usam as conexões de host possam ser importados com êxito.

Ativação de sites

O Delivery Controller em sites locais e na nuvem controla recursos como intermediação de desktops, aplicativos e reinicialização de máquinas. Os 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 no local e na nuvem gerenciem o mesmo conjunto de recursos. Esse gerenciamento duplo pode fazer com que os recursos se tornem 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 no 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 nem gerencia o registro do VDA ou os catálogos de máquinas.

  • Set-CvadAcSiteActiveStateCloud
  • Set-CvadAcSiteActiveStateOnPrem

Todos os cmdlets oferecem suporte à IncludeByName e à ExcludeByName filtragem. Esse 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

Veja a seguir uma descrição de alto nível sobre como importar e transferir o controle do site local para o site na nuvem.

  1. Exporte e importe o site local para a nuvem. Verifique se o parâmetro –SiteActive não está 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 de sites na nuvem estão no modo de manutenção.
  2. Verifique o conteúdo e a configuração da nuvem.
  3. Fora do horário de expediente, defina o site local como inativo. O parâmetro –SiteActive deve estar ausente. Todos os grupos de entrega no 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 de site na nuvem está no modo de manutenção.
    • Set-CvadAcSiteActiveStateCloud –SiteActive
  5. Verifique se o site da nuvem está ativo e se o site local está inativo.

Transferência do 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 de sites em nuvem estão em modo de manutenção.
    • Set-CvadAcSiteActiveStateCloud
  2. Defina o site local como ativo. Nenhum grupo de entrega no local está em modo de manutenção.
    • Set-CvadAcSiteActiveStateOnPrem -SiteActive

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

  • Se nenhuma máquina tiver gerenciamento de 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 na 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 tiverem gerenciamento de energia ou houver agendamentos de reinicialização, será necessário um processo diferente. Por exemplo, ao alternar do local para a nuvem nessa situação, defina o site local como inativo usando Set-CvadAcSiteActiveStateOnPrem. Em seguida, defina o site da nuvem como ativo usando Set-CvadAcSiteActiveStateCloud -SiteActive.
  • O 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.

Como é a migração de catálogos provisionados do Machine Creation Services

Nota:

Esse recurso está disponível somente nas versões 3.0 e posteriores. Verifique sua versão usando Get-CvadAcStatus na 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/revertidas (normalmente OS Server, onde os aplicativos são publicados) — este é um caso de uso de VDI em pool/multissessão
  • Quando as alterações feitas em uma máquina são preservadas durante a reinicialização (geralmente sistema operacional cliente com um usuário dedicado) — este é um caso de uso estático de VDI

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

Nota:

Não é possível fazer backup do MCS da nuvem usando a Configuração Automatizada.

Catálogos VDI/multissessão em pool

Catálogos com “User data: Discard” são catálogos VDI em pool e só podem migrar a imagem principal e a configuração. As máquinas virtuais nesses catálogos não são migradas. Isso ocorre porque o ciclo de vida da máquina virtual é mantido pelo site do qual 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 ficam rapidamente fora de sincronia.

Quando você está migrando 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 import 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 a interface de gerenciamento Full Configuration na implantação da nuvem.

Depois que a imagem principal for criada, você poderá provisionar máquinas. As considerações de capacidade precisam ser levadas em consideração, pois você teria capacidade consumida pelo 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 aguardar a criação da imagem principal. Quando o catálogo terminar de criar, as máquinas poderão ser adicionadas ao catálogo importado e, em seguida, os usuários poderão iniciar seus recursos.

Nota:

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

Catálogos VDI estáticos

Nota:

Como essa operação importa detalhes de baixo nível armazenados no banco de dados, esse processo deve ser executado em uma máquina com acesso ao banco de dados.

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

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

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

Quando a migração for concluída, se você quiser excluir esse catálogo do site local, selecione sair da VM e da conta do AD. Caso contrário, eles serão excluídos e o site da nuvem será deixado apontando para a VM excluída.

Migrar a configuração para o Citrix Cloud