Anexação de aplicativo MSIX e anexação de aplicativo na Área de Trabalho Virtual do Azure

  • Artigo

Importante

A anexação de aplicativo está atualmente em VERSÃO PRÉVIA. Veja os Termos de Uso Complementares para Versões Prévias do Microsoft Azure para obter termos legais que se aplicam aos recursos do Azure que estão em versão beta, versão prévia ou que, de outra forma, ainda não foram lançados em disponibilidade geral.

Existem dois recursos na Área de Trabalho Virtual do Azure que permitem que você anexe dinamicamente aplicativos de um pacote de aplicativos a uma sessão de usuário na Área de Trabalho Virtual do Azure: anexação de aplicativo MSIX e anexação de aplicativo (versão prévia). A anexação de aplicativo MSIX está em disponibilidade geral, mas a anexação de aplicativo agora está disponível em versão prévia, o que aprimora a experiência administrativa e do usuário. Com a anexação de aplicativo MSIX e a anexação de aplicativo, os aplicativos não são instalados localmente em hosts de sessão ou imagens, o que facilita a criação de imagens personalizadas para seus hosts de sessão e reduz a sobrecarga operacional e os custos para a 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 de aplicativo MSIX à anexação de aplicativo:

Anexação de aplicativo MSIX Anexação de aplicativo
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 de anexação de 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, proporcionando maior controle sobre quais aplicativos seus usuários podem acessar em uma sessão remota. Os usuários da área de trabalho veem somente os aplicativos de anexação de aplicativo que lhes foram atribuídos.
Os aplicativos talvez sejam executados em apenas um pool de hosts. Se quiser que sejam executados em outro pool de hosts, você precisará 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 ao qual são adicionados. Os aplicativos podem ser executados em qualquer host de sessão executando um sistema operacional do cliente Windows na mesma região do Azure que o pacote de aplicativos.
Para atualizar o aplicativo, você precisa 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 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 de uso e integridade agora está disponível por meio do Log Analytics do Azure. A telemetria de uso e integridade está disponível por meio do Log Analytics do Azure.

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

Tipo de pacote Formatos de arquivo Disponibilidade de recursos
MSIX e Pacote MSIX .msix
.msixbundle		 Anexação de aplicativo MSIX
Anexação de aplicativo
Appx e Pacote Appx .appx
.appxbundle		 Somente anexação de aplicativo

MSIX e Appx são os formatos de pacote de aplicativos do Windows que fornecem uma experiência moderna de empacotamento 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. Os formatos MSIX e Appx são semelhantes; a principal diferença é que o MSIX é um superconjunto do Appx. O MSIX dá suporte a todos os recursos do Appx e também a outros recursos que o tornam mais adequado para uso corporativo.

Dica

Selecione um botão na parte superior deste artigo para optar entre a anexação de aplicativo MSIX (atual) e a anexação de aplicativo (versão prévia) e ver a documentação relevante.

Você pode obter pacotes MSIX de fornecedores de software ou criar um pacote MSIX a partir de um instalador existente. Para saber mais sobre MSIX, confira O que é 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 precisam ser cumpridos para que o usuário obtenha o aplicativo certo no momento certo:

  • O aplicativo precisa ser atribuído ao pool de hosts. Atribuir o 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 certos estejam disponíveis para serem usados pelo aplicativo. Por exemplo, se um aplicativo tiver um uso intensivo de recursos gráficos, você poderá garantir que seja executado apenas em um pool de hosts com hosts de sessão otimizados para GPU.

  • O usuário precisa ser capaz de entrar em hosts de sessão no pool de hosts, então ele precisa estar em um grupo de aplicativos de área de trabalho ou RemoteApp. Para um grupo de aplicativos do RemoteApp, o aplicativo de anexação de aplicativo precisa ser adicionado ao grupo de aplicativos, mas você não precisa adicionar o aplicativo a um grupo de aplicativos de área de trabalho.

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

Se todos esses requisitos forem cumpridos, o usuário obterá o aplicativo. Esse processo fornece controle sobre quem obtém um aplicativo em qual pool de hosts e também como é possível que usuários em um único pool de hosts ou até mesmo conectados ao mesmo host de sessão multissessão obtenham combinações de aplicativos diferentes. Os usuários que não cumprirem os requisitos não obterão 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 a anexação de aplicativo MSIX, você adiciona pacotes MSIX a um pool de hosts e controla a atribuição de aplicativos usando grupos de aplicativos de área de trabalho ou do RemoteApp. Durante o login, os seguintes requisitos precisam ser cumpridos para que o usuário obtenha o aplicativo certo no momento certo:

  • O usuário precisa ser capaz de entrar em hosts de sessão no pool de hosts, então ele precisa estar em um grupo de aplicativos de área de trabalho ou RemoteApp.

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

Se esses requisitos forem cumpridos, o usuário obterá o aplicativo. Atribuir aplicativos usando um grupo de aplicativos de área de trabalho os adiciona ao menu iniciar do usuário. Os usuários que não cumprirem os requisitos não obterão o aplicativo.

Imagens de aplicativo

Antes de usar seus pacotes de aplicativos com a Área de Trabalho Virtual do Azure, você precisa Criar uma imagem MSIX de seus pacotes de aplicativos existentes usando a ferramenta MSIXMGR. Em seguida, você precisa armazenar cada imagem de disco em um compartilhamento de arquivo que possa ser acessado pelos seus hosts de sessão. Para obter mais informações sobre os requisitos de um compartilhamento de arquivos, confira Compartilhamento de arquivos.

Tipos de imagem de disco

Você pode usar o Sistema Composto de Arquivos de Imagem (CimFS), VHDX ou VHD para as imagens de disco, mas não recomendamos usar o VHD. Montar e desmontar imagens CimFS é mais rápido do que arquivos VHD e VHDX e também consome menos CPU e menos memória. Recomendamos usar o CimFS para suas imagens de aplicativo somente se os hosts de sessão estiverem executando o Windows 11.

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

Nome do arquivo 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; os testes foram executados em uma máquina virtual DSv4 do Azure.

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

Registro de aplicativo

A anexação de aplicativo monta imagens de disco contendo seus aplicativos a partir de um compartilhamento de arquivos em uma sessão de usuário durante o login e, em seguida, um processo de registro disponibiliza os aplicativos para o usuário. Existem dois tipos de registro:

A anexação de aplicativo MSIX monta imagens de disco contendo seus aplicativos a partir de um compartilhamento de arquivos em uma sessão de usuário durante o login e, em seguida, um processo de registro disponibiliza os aplicativos para o usuário. Existem dois tipos de registro:

  • Sob demanda: os aplicativos são registrados no login apenas parcialmente e o registro completo de um aplicativo é adiado até o momento em que o usuário inicia o aplicativo. O registro sob demanda é o tipo que recomendamos que você use, já que não afeta o tempo necessário para entrar na Área de Trabalho Virtual do Azure. Sob demanda é o método de registro padrão.

  • Bloqueio de login: cada aplicativo que você atribui a um usuário é registrado totalmente. O registro ocorre enquanto o usuário está entrando em sua sessão, o que pode afetar o tempo de entrada na Área 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 considerados de confiança no seu ambiente. Os certificados autoassinados são corroborados pela cadeia de confiança apropriada.

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

Importante

Todos os pacotes de aplicativos MSIX incluem um certificado. Você é responsável por garantir que os certificados sejam considerados de confiança no seu ambiente. Os certificados autoassinados têm suporte.

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

Estado do aplicativo

Os pacotes MSIX e Appx são configurados como ativos ou inativos. Os pacotes configurados como ativos tornam o aplicativo disponível para os usuários. Os pacotes configurados como inativos são ignorados pela Área de Trabalho Virtual do Azure e não são adicionados quando um usuário faz login.

Um pacote MSIX é configurado como ativo ou inativo. Os pacotes MSIX configurados como ativos tornam o aplicativo disponível para os usuários. Os pacotes MSIX configurados como inativos são ignorados pela Área de Trabalho Virtual do Azure e não são adicionados quando um usuário faz login.

Novas versões de aplicativos

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 o atribua aos mesmos pools de hosts e usuários que o aplicativo existente.

  • Em vez de: crie uma nova imagem em que o número da versão do aplicativo é alterado e, a seguir, atualize o aplicativo existente para usar a nova imagem. O número de versão pode ser maior ou menor, mas você não pode atualizar um aplicativo com o mesmo número de versão. Não exclua a imagem existente até que todos os usuários tenham terminado de usá-la.

Após terem sido atualizados, os usuários obterão a versão atualizada do aplicativo na próxima vez em que fizerem login. Os usuários não precisam parar de usar a versão anterior para adicionar uma nova versão.

Novas versões de aplicativos

Com a anexação de aplicativo MSIX, 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. Você não pode atualizar a opção "em vez de" como ocorre com a anexação de aplicativo. Os usuários obterão a nova imagem com o aplicativo atualizado na próxima vez em que fizerem login. Você deve executar essas tarefas durante uma janela de manutenção.

Provedores de identidade

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

Provedor de identidade Status
Microsoft Entra ID Com suporte
Active Directory Domain Services (AD DS) Com suporte
Serviços de Domínio do Microsoft Entra Sem suporte

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

Provedor de identidade Status
Microsoft Entra ID Sem suporte
Active Directory Domain Services (AD DS) Com suporte
Microsoft Entra Domain Services (Azure AD DS) Sem suporte

Compartilhamento de arquivo

A anexação de aplicativo requer que as imagens do aplicativo sejam armazenadas em um compartilhamento de arquivos SMB, que, a seguir, é montado em cada host de sessão durante o login. A anexação de aplicativo MSIX não tem dependências no tipo de malha de armazenamento que o compartilhamento de arquivos usa. Recomendamos que você use o serviço Arquivos do Azure, já que é compatível com o Microsoft Entra ID ou com o Active Directory Domain Services e oferece uma grande vantagem em termos de custos e gastos com gerenciamento.

Você também pode usar o Azure NetApp Files, mas o serviço requer que seus hosts de sessão sejam ingressados no Active Directory Domain Services.

A anexação de aplicativo MSIX requer que as imagens do aplicativo sejam armazenadas em um compartilhamento de arquivos SMB versão 3, que, a seguir, é montado em cada host de sessão durante o login. A anexação do aplicativo MSIX não tem dependências do tipo de malha de armazenamento que o compartilhamento de arquivos usa. Recomendamos que você use o serviço Arquivos do Azure, já que é compatível com os provedores de identidade com suporte que você pode usar para a anexação de aplicativo MSIX e oferece uma grande vantagem em termos de custos e gastos com gerenciamento. Você também pode usar o Azure NetApp Files, o serviço requer que seus hosts de sessão sejam ingressados no Active Directory Domain Services.

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

Permissões

Cada host de sessão monta imagens de aplicativo a partir do compartilhamento de arquivos. Você precisa configurar o NTFS e compartilhar permissões para permitir que cada objeto de computador host de sessão leia o acesso 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 o seu compartilhamento de arquivos e seus hosts de sessão.

  • Para usar o serviço Arquivos do Azure quando seus hosts de sessão forem ingressados no Microsoft Entra ID, você precisa atribuir a função do controle de acesso baseado em função (RBAC) do Azure Leitor e Acesso a Dados às entidades de serviço da Área de Trabalho Virtual do Azure e do Provedor do 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. A conta de armazenamento precisa estar na mesma assinatura do Azure que seus hosts de sessão. Para saber como atribuir uma função RBAC do Azure às entidades de serviço da Área de Trabalho Virtual do Azure, confira Atribuir funções RBAC às entidades de serviço da Área de Trabalho Virtual do Azure.

    Para obter mais informações sobre como usar o serviço Arquivos do Azure com hosts de sessão ingressados no Microsoft Entra ID, no Active Directory Domain Services ou no Microsoft Entra Domain Services, confira Visão geral das opções de autenticação baseada em identidade do Arquivos do Azure para acesso SMB.

    Aviso

    Ao atribuir a entidade de serviço do Provedor do ARM da Área de Trabalho Virtual do Azure à conta de armazenamento, você concede o serviço da Área de Trabalho Virtual do Azure a todos os dados dentro da conta de armazenamento. Recomendamos que você armazene nessa conta de armazenamento apenas aplicativos a serem usados com a anexação de aplicativo e rotacione as chaves de acesso regularmente.

  • No caso do serviço Azure NetApp Files, você pode criar um volume SMB e configurar permissões do NTFS para dar acesso de leitura ao objeto de computador de cada host de sessão. Seus hosts de sessão precisam ser ingressados no Active Directory Domain Services ou no Microsoft Entra Domain Services.

Você pode verificar se as permissões estão corretas usando o PsExec. Para obter mais informações, confira 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 MSIX de 1 GB contendo um único aplicativo requer por host de sessão:

Recurso Requirements
IOPS de criação contínua Uma IOP
Entrada de inicialização do computador 10 IOPS
Latency 400 ms

Para otimizar o desempenho de seus aplicativos, recomendamos:

  • O compartilhamento de arquivos deve estar na mesma região do Azure que seus hosts de sessão. Se você estiver usando o serviç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 contendo seus aplicativos de verificações antivírus, já que são somente leitura.

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

Disponibilidade

Os planos de recuperação de desastre para a Área de Trabalho Virtual do Azure precisam incluir a replicação do compartilhamento de arquivos da anexação de aplicativo MSIX para o seu local de failover secundário. Você também precisa garantir que o caminho do compartilhamento de arquivos esteja acessível no local secundário. Você pode usar Namespaces do Sistema de Arquivos Distribuído (DFS) com o serviço Arquivos do Azure para fornecer um único nome de compartilhamento nos diferentes compartilhamentos de arquivos. Para saber mais sobre a recuperação de desastre para Área de Trabalho Virtual do Azure, confira Configurar um plano de continuidade dos negócios e recuperação de desastre.

Arquivos do Azure

O Arquivos do Azure limita o número de identificadores abertos por diretório raiz, diretório e arquivo. Quando você usa a anexação de aplicativo MSIX ou a anexação de aplicativo, as imagens de disco VHDX ou CimFS são montadas usando a conta de computação do host de sessão, o que significa que é aberto um identificador 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, confira Metas de escalabilidade e desempenho do serviço Arquivos do Azure e Diretrizes de dimensionamento do serviço 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 autenticação de código válido. Para usar esses pacotes com anexação de aplicativo, você precisa garantir que toda a cadeia de certificados seja confiável em seus hosts de sessão. Um certificado de autenticação de código tem o identificador de objeto 1.3.6.1.5.5.7.3.3. Você pode obter um certificado de autenticação de código para seus pacotes de:

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

  • Uma empresa interna ou uma autoridade de certificação autônoma, como Serviços de Certificados do Active Directory. Você precisa exportar o certificado de autenticação 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ê precisará assinar digitalmente seus pacotes MSIX ou Appx com o certificado. Você pode usar a Ferramenta de Empacotamento MSIX para assinar seus pacotes ao criar um pacote MSIX. Para obter mais informações, consulte Criar um pacote MSIX de qualquer instalador de área de trabalho.

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

  • AC pública: certificados de uma AC pública são confiáveis por padrão no Windows e no Windows Server.

  • AC Corporativa Interna:

    • Para hosts de sessão ingressados no Active Directory, com o AD CS configurado como a AC corporativa interna, são confiáveis por padrão e armazenados no contexto de nomenclatura de configuração do Active Directory Domain Services. Quando o AD CS é configurado como uma AC autônoma, você precisa configurar a Política de Grupo para distribuir os certificados raiz e intermediários para hosts de sessão. Para obter mais informações, consulte Distribuir certificados para dispositivos Windows usando a Política de Grupo.

    • Para hosts de sessão ingressados no 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ável para o Microsoft Intune.

    • Para hosts de sessão que usam o ingresso no Microsoft Entra híbrido, você pode usar qualquer um dos métodos anteriores, dependendo de seus requisitos.

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

Importante

Você deve usar o carimbo de data/hora no seu pacote para que sua validade possa ultrapassar a data de expiração do seu certificado. Caso contrário, depois que o certificado tiver 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óximas etapas

Saiba como Adicionar e gerenciar aplicativos de anexação de aplicativo na Área de Trabalho Virtual do Azure.