Partilhar via

Anexar aplicativo e anexar aplicativo MSIX na Área de Trabalho Virtual do Azure

  • Artigo

Há dois recursos na Área de Trabalho Virtual do Azure que permitem anexar dinamicamente aplicativos de um pacote de aplicativo a uma sessão de usuário na Área de Trabalho Virtual do Azure - anexar aplicativo e anexar aplicativo MSIX. Com a anexação de aplicativos e a anexação de aplicativos MSIX, os aplicativos não são instalados localmente em hosts de sessão ou imagens, facilitando a criação de imagens personalizadas para seus hosts de sessão e reduzindo a sobrecarga operacional e os custos para sua organização. Os aplicativos são executados em contêineres, que separam os dados do usuário, o sistema operacional e outros aplicativos, aumentando a segurança e facilitando a solução de problemas.

A tabela a seguir compara a anexação do aplicativo MSIX com o anexo do aplicativo:

Anexação da aplicação MSIX Anexar aplicações
Os aplicativos são entregues usando o RemoteApp ou como parte de uma sessão da área de trabalho. As permissões são controladas pela atribuição a grupos de aplicativos, no entanto, todos os usuários da área de trabalho veem todos os aplicativos anexados ao aplicativo MSIX no grupo de aplicativos da área de trabalho. Os aplicativos são entregues usando o RemoteApp ou como parte de uma sessão da área de trabalho. As permissões são aplicadas por aplicativo por usuário, oferecendo maior controle sobre quais aplicativos seus usuários podem acessar em uma sessão remota. Os utilizadores de ambiente de trabalho veem apenas as aplicações anexadas à aplicação que lhes estão atribuídas.
Os aplicativos só podem ser executados em um pool de hosts. Se quiser que ele seja executado em outro pool de hosts, você deve criar outro pacote. O mesmo pacote de aplicativos pode ser usado em vários pools de hosts.
Os aplicativos só podem ser executados no pool de hosts no qual foram adicionados. Os aplicativos podem ser executados em qualquer host de sessão que execute um sistema operacional cliente Windows na mesma região do Azure que o pacote do aplicativo.
Para atualizar o aplicativo, você deve excluir e recriar o aplicativo com outra versão do pacote. Você deve atualizar o aplicativo em uma janela de manutenção. Os aplicativos podem ser atualizados para uma nova versão do aplicativo com uma nova imagem de disco sem a necessidade de uma janela de manutenção.
Os usuários não podem executar duas versões do mesmo aplicativo no mesmo host de sessão. Os usuários podem executar duas versões do mesmo aplicativo simultaneamente no mesmo host de sessão.
A telemetria para uso e integridade não está disponível por meio do Azure Log Analytics. A telemetria para uso e integridade está disponível por meio do Azure Log Analytics.

Você pode usar os seguintes tipos de pacote de aplicativo e formatos de arquivo:

Tipo de embalagem Formatos de ficheiro Disponibilidade de caraterísticas
Pacote MSIX e MSIX .msix
.msixbundle		 Anexação da aplicação MSIX
Anexar aplicações
Pacote Appx e Appx .appx
.appxbundle		 Apenas anexar aplicações
Aplicativo-V .appv Apenas anexar aplicações

MSIX e Appx são formatos de pacotes de aplicativos do Windows que fornecem uma experiência de empacotamento moderna para aplicativos do Windows. Os aplicativos são executados em contêineres, que separam os dados do usuário, o sistema operacional e outros aplicativos, aumentando a segurança e facilitando a solução de problemas. MSIX e Appx são semelhantes, onde a principal diferença é que MSIX é um superconjunto de Appx. O MSIX suporta todos os recursos do Appx, além de outros recursos que o tornam mais adequado para uso corporativo.

O Microsoft Application Virtualization (App-V) para Windows fornece aplicativos Win32 aos usuários como aplicativos virtuais. Os aplicativos virtuais são instalados em servidores gerenciados centralmente e entregues aos usuários como um serviço em tempo real e conforme necessário. Os utilizadores iniciam aplicações virtuais a partir de pontos de acesso familiares e interagem com eles como se estivessem instalados localmente.

Gorjeta

Selecione um botão na parte superior deste artigo para escolher entre anexar aplicativo e anexar aplicativo MSIX para ver a documentação relevante.

Você pode obter pacotes MSIX de fornecedores de software ou pode criar um pacote MSIX a partir de um instalador existente. Para saber mais sobre o MSIX, consulte O que é o MSIX?

Como um usuário obtém um aplicativo

Você pode atribuir aplicativos diferentes a usuários diferentes no mesmo pool de hosts ou no mesmo host de sessão. Durante o login, todos os três requisitos a seguir devem ser atendidos para que o usuário obtenha o aplicativo certo no momento certo:

  • O aplicativo deve ser atribuído ao pool de hosts. A atribuição do aplicativo ao pool de hosts permite que você seja seletivo sobre em quais pools de hosts o aplicativo está disponível para garantir que os recursos de hardware corretos estejam disponíveis para uso pelo aplicativo. Por exemplo, se um aplicativo tiver uso intensivo de gráficos, você poderá garantir que ele só seja executado em um pool de hosts com hosts de sessão otimizados para GPU.

  • O usuário deve ser capaz de entrar em hosts de sessão no pool de hosts, portanto, eles devem estar em um grupo de aplicativos Desktop ou RemoteApp. Para um grupo de aplicativos RemoteApp, o aplicativo anexado ao aplicativo deve ser adicionado ao grupo de aplicativos, mas você não precisa adicionar o aplicativo a um grupo de aplicativos da área de trabalho.

  • O aplicativo deve ser atribuído ao usuário. Você pode usar um grupo ou uma conta de usuário.

Se todos esses requisitos forem atendidos, o usuário receberá o aplicativo. Esse processo fornece controle sobre quem obtém um aplicativo em qual pool de hosts e também como é possível que os usuários dentro de um único pool de hosts ou até mesmo conectados ao mesmo host de sessão de várias sessões obtenham diferentes combinações de aplicativos. Os usuários que não atendem aos requisitos não recebem o aplicativo.

Como um usuário obtém um aplicativo

Você pode atribuir aplicativos diferentes a usuários diferentes no mesmo pool de hosts. Com o aplicativo MSIX anexado, você adiciona pacotes MSIX a um pool de hosts e controla a atribuição de aplicativos usando grupos de aplicativos da área de trabalho ou do RemoteApp. Durante o login, os seguintes requisitos devem ser atendidos para que o usuário obtenha o aplicativo certo no momento certo:

  • O usuário deve ser capaz de entrar em hosts de sessão no pool de hosts, portanto, eles devem estar em um grupo de aplicativos Desktop ou RemoteApp.

  • A imagem MSIX deve ser adicionada ao pool de hosts.

Se esses requisitos forem atendidos, o usuário receberá o aplicativo. A atribuição de aplicativos usando um grupo de aplicativos da área de trabalho os adiciona ao menu Iniciar do usuário. Os usuários que não atendem aos requisitos não recebem o aplicativo.

Imagens de aplicação

Antes de poder usar pacotes de aplicativos MSIX com a Área de Trabalho Virtual do Azure, você precisa Criar uma imagem MSIX a partir de seus pacotes de aplicativos existentes. Como alternativa, você pode usar um pacote App-V. Em seguida, você precisa armazenar cada imagem MSIX ou pacote do App-V em um compartilhamento de arquivos acessível pelos hosts da sessão. Para obter mais informações sobre os requisitos para um compartilhamento de arquivos, consulte Compartilhamento de arquivos.

Antes de poder usar pacotes de aplicativos MSIX com a Área de Trabalho Virtual do Azure, você precisa Criar uma imagem MSIX a partir de seus pacotes de aplicativos existentes. Em seguida, você precisa armazenar cada imagem de disco em um compartilhamento de arquivos acessível pelos hosts de sessão. Para obter mais informações sobre os requisitos para um compartilhamento de arquivos, consulte Compartilhamento de arquivos.

Tipos de imagem de disco

Para imagens de disco MSIX e Appx, você pode usar Composite Image File System (CimFS), VHDX ou VHD, mas não recomendamos o uso de VHD. Montar e desmontar imagens CimFS é mais rápido do que arquivos VHD e VHDX e também consome menos CPU e memória. Só recomendamos o uso do CimFS para as imagens do seu aplicativo se os hosts da sessão estiverem executando o Windows 11.

Uma imagem CimFS é uma combinação de vários arquivos: um arquivo tem a .cim extensão de arquivo e contém metadados, juntamente com pelo menos dois outros arquivos, um começando com objectid_ e outro começando com region_ que contêm os dados reais do aplicativo. Os ficheiros que acompanham o .cim ficheiro não têm uma extensão de ficheiro. A tabela a seguir é uma lista de arquivos de exemplo que você encontraria para uma imagem CimFS:

Nome de ficheiro Tamanho
MyApp.cim 1 KB
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_0 27 KB
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_1 20 KB
objectid_b5742e0b-1b98-40b3-94a6-9cb96f497e56_2 42 KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_0 428 KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_1 217 KB
region_b5742e0b-1b98-40b3-94a6-9cb96f497e56_2 264.132 KB

A tabela a seguir é uma comparação de desempenho entre VHDX e CimFS. Esses números foram o resultado de uma execução de teste com 500 arquivos de 300 MB cada por formato e os testes foram realizados em uma máquina virtual DSv4 Azure.

Métrica VHD CimFS
Tempo médio de montagem 356 ms 255 ms
Tempo médio de desmontagem 1615 ms 36 ms
Consumo de memória 6% (de 8 GB) 2% (de 8 GB)
CPU (pico de contagem) Esgotado várias vezes Nenhum efeito

Registo de aplicação

A anexação de aplicativos monta imagens de disco ou pacotes do App-V contendo seus aplicativos de um compartilhamento de arquivos para a sessão de um usuário durante o login e, em seguida, um processo de registro disponibiliza os aplicativos para o usuário. Existem dois tipos de registo:

O MSIX app attach monta imagens de disco contendo seus aplicativos de um compartilhamento de arquivos para a sessão de um usuário durante o login e, em seguida, um processo de registro disponibiliza os aplicativos para o usuário. Existem dois tipos de registo:

  • A pedido: as aplicações são apenas parcialmente registadas no momento do início de sessão e o registo completo de uma aplicação é adiado até que o utilizador inicie a aplicação. On-demand é o tipo de registro que recomendamos que você use, pois não afeta o tempo necessário para entrar na Área de Trabalho Virtual do Azure. On-demand é o método de registro padrão.

  • Bloqueio de logon: cada aplicativo que você atribui a um usuário é totalmente registrado. O registo acontece enquanto o utilizador inicia sessão na sessão, o que pode afetar o tempo de início de sessão no Ambiente de Trabalho Virtual do Azure.

Importante

Todos os pacotes de aplicativos MSIX e Appx incluem um certificado. Você é responsável por garantir que os certificados sejam confiáveis em seu ambiente. Os certificados autoassinados são suportados com a cadeia de confiança apropriada.

A anexação de aplicativos não limita o número de aplicativos que os usuários podem usar. Você deve considerar sua taxa de transferência de rede disponível e o número de identificadores abertos por arquivo (cada imagem) que seu compartilhamento de arquivos suporta, pois isso pode limitar o número de usuários ou aplicativos que você pode suportar. Para obter mais informações, consulte Compartilhamento de arquivos.

Importante

Todos os pacotes de aplicativos MSIX incluem um certificado. Você é responsável por garantir que os certificados sejam confiáveis em seu ambiente. Há suporte para certificados autoassinados.

A anexação de aplicativos MSIX não limita o número de aplicativos que os usuários podem usar. Você deve considerar sua taxa de transferência de rede disponível e o número de identificadores abertos por arquivo (cada imagem) que seu compartilhamento de arquivos suporta, pois isso pode limitar o número de usuários ou aplicativos que você pode suportar. Para obter mais informações, consulte Compartilhamento de arquivos.

Estado do aplicativo

Os pacotes de aplicativos são definidos como ativos ou inativos. Os pacotes definidos como ativos disponibilizam o aplicativo para os usuários. Os pacotes definidos como inativos são ignorados pela Área de Trabalho Virtual do Azure e não são adicionados quando um usuário entra.

Um pacote MSIX é definido como ativo ou inativo. Os pacotes MSIX definidos como ativos disponibilizam o aplicativo para os usuários. Os pacotes MSIX definidos como inativos são ignorados pela Área de Trabalho Virtual do Azure e não são adicionados quando um usuário entra.

Novas versões de aplicações

Você pode adicionar uma nova versão de um aplicativo fornecendo uma nova imagem contendo o aplicativo atualizado. Você pode usar essa nova imagem de duas maneiras:

  • Lado a lado: crie um novo aplicativo usando a nova imagem de disco e atribua-o aos mesmos pools de hosts e usuários que o aplicativo existente.

  • In-loco: crie uma nova imagem onde o número da versão do aplicativo seja alterado e, em seguida, atualize o aplicativo existente para usar a nova imagem. O número da versão pode ser maior ou menor, mas não é possível atualizar um aplicativo com o mesmo número de versão. Não exclua a imagem existente até que todos os usuários terminem de usá-la.

Uma vez atualizados, os usuários receberão a versão atualizada do aplicativo na próxima vez que entrarem. Os usuários não precisam parar de usar a versão anterior para adicionar uma nova versão.

Novas versões de aplicações

Com o MSIX app attach, você precisa excluir o pacote do aplicativo e, em seguida, criar um novo aplicativo usando a nova imagem de disco e atribuí-lo aos mesmos pools de hosts. Não é possível atualizar in-loco como é possível com o app attach. Os usuários receberão a nova imagem com o aplicativo atualizado na próxima vez que entrarem. Você deve executar essas tarefas durante uma janela de manutenção.

Fornecedores de identidade

Aqui estão os provedores de identidade que você pode usar com o aplicativo anexado:

Fornecedor de identidade Status
Microsoft Entra ID Suportado
Serviços de Domínio Ative Directory (AD DS) Suportado
Microsoft Entra Domain Services Não suportado

Aqui estão os provedores de identidade que você pode usar com o aplicativo MSIX anexado:

Fornecedor de identidade Status
Microsoft Entra ID Não suportado
Serviços de Domínio Ative Directory (AD DS) Suportado
Serviços de Domínio do Microsoft Entra (Azure AD DS) Não suportado

Partilha de ficheiros

A anexação de aplicativos requer que as imagens do aplicativo sejam armazenadas em um compartilhamento de arquivos SMB, que é montado em cada host de sessão durante o login. A anexação de aplicativos não tem dependências do tipo de malha de armazenamento usada pelo compartilhamento de arquivos. Recomendamos o uso dos Arquivos do Azure, pois ele é compatível com o Microsoft Entra ID ou os Serviços de Domínio Ative Directory e oferece um ótimo valor entre custo e sobrecarga de gerenciamento.

Você também pode usar os Arquivos NetApp do Azure, mas isso exige que seus hosts de sessão sejam associados aos Serviços de Domínio Ative Directory.

A anexação do aplicativo MSIX requer que as imagens do aplicativo sejam armazenadas em um compartilhamento de arquivos SMB versão 3, que é montado em cada host de sessão durante o login. A anexação de aplicativos MSIX não tem dependências no tipo de malha de armazenamento usada pelo compartilhamento de arquivos. Recomendamos o uso dos Arquivos do Azure, pois é compatível com os provedores de identidade suportados que você pode usar para anexar aplicativos MSIX e oferece um ótimo valor entre custo e sobrecarga de gerenciamento. Você também pode usar os Arquivos NetApp do Azure, mas isso requer que seus hosts de sessão estejam associados aos Serviços de Domínio Ative Directory.

As seções a seguir fornecem algumas orientações sobre as permissões, o desempenho e a disponibilidade necessários para o compartilhamento de arquivos.

Permissões

Cada host de sessão monta imagens de aplicativos a partir do compartilhamento de arquivos. Você precisa configurar o NTFS e as permissões de compartilhamento para permitir que cada objeto de computador host da sessão tenha acesso de leitura aos arquivos e ao compartilhamento de arquivos. A forma como você configura a permissão correta depende de qual provedor de armazenamento e provedor de identidade você está usando para seu compartilhamento de arquivos e hosts de sessão.

  • Para usar os Arquivos do Azure quando seus hosts de sessão ingressaram na ID do Microsoft Entra, você precisa atribuir a função RBAC (controle de acesso baseado em função) do Azure Reader and Data Access às entidades de serviço da Área de Trabalho Virtual do Azure e do Provedor ARM da Área de Trabalho Virtual do Azure. Essa atribuição de função RBAC permite que seus hosts de sessão acessem a conta de armazenamento usando chaves de acesso ou o Microsoft Entra.

  • Para saber como atribuir uma função RBAC do Azure às entidades de serviço da Área de Trabalho Virtual do Azure, consulte Atribuir funções RBAC às entidades de serviço da Área de Trabalho Virtual do Azure. Em uma atualização futura, você não precisará atribuir a entidade de serviço do Provedor ARM da Área de Trabalho Virtual do Azure .

    Para obter mais informações sobre como usar os Arquivos do Azure com hosts de sessão que ingressaram na ID do Microsoft Entra, nos Serviços de Domínio Ative Directory ou nos Serviços de Domínio Microsoft Entra, consulte Visão geral das opções de autenticação baseada em identidade dos Arquivos do Azure para acesso SMB.

    Aviso

    A atribuição da entidade de serviço do Provedor ARM da Área de Trabalho Virtual do Azure à conta de armazenamento concede o serviço Área de Trabalho Virtual do Azure a todos os dados dentro da conta de armazenamento. Recomendamos que você armazene apenas aplicativos para usar com a anexação de aplicativos nesta conta de armazenamento e gire as chaves de acesso regularmente.

  • Para Arquivos NetApp do Azure, você pode criar um volume SMB e configurar permissões NTFS para dar acesso de leitura ao objeto de computador de cada host de sessão. Seus hosts de sessão precisam estar associados aos Serviços de Domínio Ative Directory ou aos Serviços de Domínio Microsoft Entra.

Você pode verificar se as permissões estão corretas usando PsExec. Para obter mais informações, consulte Verificar o acesso ao compartilhamento de arquivos.

Desempenho

Os requisitos podem variar muito, dependendo de quantos aplicativos empacotados são armazenados em uma imagem e você precisa testar seus aplicativos para entender seus requisitos. Para imagens maiores, você precisa alocar mais largura de banda. A tabela a seguir fornece um exemplo dos requisitos que uma única imagem de 1 GB ou pacote App-V contendo um aplicativo requer por host de sessão:

Recurso Requisitos
IOPs em estado estacionário Uma PIO
Login de inicialização da máquina 10 PIO
Latência 400 ms

Para otimizar o desempenho das suas aplicações, recomendamos:

  • Seu compartilhamento de arquivos deve estar na mesma região do Azure que seus hosts de sessão. Se você estiver usando o Arquivos do Azure, sua conta de armazenamento precisará estar na mesma região do Azure que seus hosts de sessão.

  • Exclua as imagens de disco que contêm seus aplicativos das verificações antivírus, pois elas são somente leitura.

  • Certifique-se de que sua malha de armazenamento e rede possa fornecer desempenho adequado. Você deve evitar usar o mesmo compartilhamento de arquivos com contêineres de perfil FSLogix.

Disponibilidade

Qualquer plano de recuperação de desastres para a Área de Trabalho Virtual do Azure deve incluir a replicação do compartilhamento de arquivos para seu local de failover secundário. Você também precisa garantir que seu caminho de compartilhamento de arquivos esteja acessível no local secundário. Por exemplo, você pode usar Namespaces DFS (Sistema de Arquivos Distribuídos) com Arquivos do Azure para fornecer um único nome de compartilhamento em diferentes compartilhamentos de arquivos. Para saber mais sobre a recuperação de desastres para a Área de Trabalho Virtual do Azure, consulte Configurar um plano de continuidade de negócios e recuperação de desastres.

Ficheiros do Azure

Os Arquivos do Azure têm limites no número de identificadores abertos por diretório, diretório e arquivo raiz. Ao usar a anexação de aplicativos ou a anexação de aplicativos MSIX, as imagens de disco VHDX ou CimFS são montadas usando a conta de computador do host da sessão, o que significa que um identificador é aberto por host de sessão por imagem de disco, em vez de por usuário. Para obter mais informações sobre os limites e as diretrizes de dimensionamento, consulte Metas de escalabilidade e desempenho dos Arquivos do Azure e Diretrizes de dimensionamento dos Arquivos do Azure para a Área de Trabalho Virtual do Azure.

Certificados de pacote MSIX e Appx

Todos os pacotes MSIX e Appx exigem um certificado de assinatura de código válido. Para usar esses pacotes com o app attach, você precisa garantir que toda a cadeia de certificados seja confiável em seus hosts de sessão. Um certificado de assinatura de código tem o identificador 1.3.6.1.5.5.7.3.3de objeto . Você pode obter um certificado de assinatura de código para seus pacotes de:

  • Uma autoridade de certificação (CA) pública.

  • Uma empresa interna ou uma autoridade de certificação autônoma, como os Serviços de Certificados do Ative Directory. Você precisa exportar o certificado de assinatura de código, incluindo sua chave privada.

  • Uma ferramenta como o cmdlet do PowerShell New-SelfSignedCertificate que gera um certificado autoassinado. Você só deve usar certificados autoassinados em um ambiente de teste. Para obter mais informações sobre como criar um certificado autoassinado para pacotes MSIX e Appx, consulte Criar um certificado para assinatura de pacote.

Depois de obter um certificado, você precisa assinar digitalmente seus pacotes MSIX ou Appx com o certificado. Você pode usar a MSIX Packaging Tool para assinar seus pacotes ao criar um pacote MSIX. Para obter mais informações, consulte Criar um pacote MSIX a partir de qualquer instalador de desktop.

Para garantir que o certificado seja confiável em seus hosts de sessão, você precisa que seus hosts de sessão confiem em toda a cadeia de certificados. Como você faz isso depende de onde você obteve o certificado e como você gerencia seus hosts de sessão e o provedor de identidade que você usa. A tabela a seguir fornece algumas orientações sobre como garantir que o certificado seja confiável em seus hosts de sessão:

  • CA pública: os certificados de uma autoridade de certificação pública são confiáveis por padrão no Windows e no Windows Server.

  • AC Empresarial Interna:

    • Para hosts de sessão ingressados no Ative Directory, com o AD CS configurado como a autoridade de certificação corporativa interna, são confiáveis por padrão e armazenados no contexto de nomenclatura de configuração dos Serviços de Domínio Ative Directory. Quando o AD CS é configurado como uma autoridade de certificação autônoma, você precisa configurar a Diretiva de Grupo para distribuir os certificados raiz e intermediários aos hosts de sessão. Para obter mais informações, consulte Distribuir certificados para dispositivos Windows usando a Diretiva de Grupo.

    • Para hosts de sessão associados ao Microsoft Entra ID, você pode usar o Microsoft Intune para distribuir os certificados raiz e intermediários para hosts de sessão. Para obter mais informações, consulte Perfis de certificado raiz confiáveis para o Microsoft Intune.

    • Para hosts de sessão usando a associação híbrida do Microsoft Entra, você pode usar qualquer um dos métodos anteriores, dependendo de seus requisitos.

  • Autoassinado: instale a raiz confiável no armazenamento de Autoridades de Certificação Raiz Confiáveis em cada host de sessão. Não recomendamos a distribuição desse certificado usando a Política de Grupo ou o Intune, pois ele só deve ser usado para testes.

Importante

Você deve carimbo de data/hora do seu pacote para que sua validade possa durar mais do que a data de validade do seu certificado. Caso contrário, uma vez que o certificado tenha expirado, você precisará atualizar o pacote com um novo certificado válido e, mais uma vez, garantir que ele seja confiável em seus hosts de sessão.

Próximos passos

Saiba como Adicionar e gerir aplicações de anexação de aplicações no Ambiente de Trabalho Virtual do Azure.