Anexar Aplicação no Azure Virtual Desktop

A Anexação de Aplicações permite-lhe anexar dinamicamente aplicações de um pacote de aplicação a uma sessão de utilizador no Azure Virtual Desktop. As aplicações não são instaladas localmente em anfitriões ou imagens de sessão, facilitando a criação de imagens personalizadas para os anfitriões de sessões e a redução da sobrecarga operacional e dos custos para a sua organização. As aplicações são executadas em contentores, que separam os dados do utilizador, o sistema operativo e outras aplicações, aumentando a segurança e facilitando a resolução de problemas.

Seguem-se alguns dos principais benefícios da Anexação de Aplicações:

• As aplicações são fornecidas com o RemoteApp ou como parte de uma sessão de ambiente de trabalho. As permissões são aplicadas por aplicação por utilizador, o que lhe dá um maior controlo sobre as aplicações às quais os seus utilizadores podem aceder numa sessão remota. Os utilizadores do ambiente de trabalho só veem as aplicações anexadas à Aplicação atribuídas.
• O mesmo pacote de aplicação pode ser utilizado em vários conjuntos de anfitriões.
• As aplicações podem ser executadas em qualquer anfitrião de sessão que execute um sistema operativo cliente Windows na mesma região do Azure que o pacote de aplicações.
• As aplicações podem ser atualizadas para uma nova versão da aplicação com uma nova imagem de disco sem a necessidade de uma janela de manutenção.
• Os utilizadores podem executar várias versões da mesma aplicação em simultâneo no mesmo anfitrião de sessão.
• A telemetria para utilização e estado de funcionamento está disponível através do Azure Log Analytics.

Pode utilizar os seguintes tipos de pacotes de aplicações e formatos de ficheiro:

Tipo de pacote	Formatos de arquivo
Pacote MSIX e MSIX	.msix .msixbundle
Pacote Appx e Appx	.appx .appxbundle
App-V	.appv

O MSIX e o Appx são formatos de pacotes de aplicações do Windows que proporcionam uma experiência de empacotamento moderna para aplicações do Windows. As aplicações são executadas em contentores, que separam os dados do utilizador, o sistema operativo e outras aplicações, aumentando a segurança e facilitando a resolução de problemas. O MSIX e o Appx são semelhantes, em que a diferença main é que o MSIX é um superconjunto do Appx. O MSIX suporta todas as funcionalidades do Appx, além de outras funcionalidades que o tornam mais adequado para utilização empresarial.

O Microsoft Application Virtualization (App-V) para Windows fornece aplicações Win32 aos utilizadores como aplicações virtuais. As aplicações virtuais são instaladas em servidores geridos centralmente e entregues aos utilizadores 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 as mesmas como se estivessem instaladas localmente.

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 utilizador obtém uma aplicação

Pode atribuir aplicações diferentes a diferentes utilizadores no mesmo conjunto de anfitriões ou no mesmo anfitrião de sessão. Durante o início de sessão, os três requisitos seguintes têm de ser cumpridos para que o utilizador obtenha a aplicação correta no momento certo:

• A aplicação tem de ser atribuída ao conjunto de anfitriões. Atribuir a aplicação ao conjunto de anfitriões permite-lhe ser seletivo sobre os conjuntos de anfitriões nos quais a aplicação está disponível para garantir que os recursos de hardware corretos estão disponíveis para utilização pela aplicação. Por exemplo, se uma aplicação utilizar gráficos intensivos, pode garantir que só é executada num conjunto de anfitriões com anfitriões de sessão otimizados para GPU.

• O utilizador tem de conseguir iniciar sessão nos anfitriões de sessão no conjunto de anfitriões, pelo que tem de estar num grupo de aplicações de Ambiente de Trabalho ou RemoteApp. Para um grupo de aplicações RemoteApp, a aplicação Anexar Aplicação tem de ser adicionada ao grupo de aplicações, mas não precisa de adicionar a aplicação a um grupo de aplicações de ambiente de trabalho.

• A aplicação tem de ser atribuída ao utilizador. Pode utilizar um grupo ou uma conta de utilizador.

Se todos estes requisitos forem cumpridos, o utilizador obtém a aplicação. Este processo fornece controlo sobre quem obtém uma aplicação em que conjunto de anfitriões e também como é possível para os utilizadores dentro de um único conjunto de anfitriões ou até mesmo iniciar sessão no mesmo anfitrião de sessões múltiplas para obter combinações de aplicações diferentes. Os utilizadores que não cumprem os requisitos não obtêm a aplicação.

Imagens da aplicação

Antes de poder utilizar pacotes de aplicações MSIX com o Azure Virtual Desktop, tem de Criar uma imagem MSIX a partir dos pacotes de aplicações existentes. Em alternativa, pode utilizar um pacote App-V. Em seguida, tem de armazenar cada imagem MSIX ou pacote app-V numa partilha de ficheiros acessível pelos anfitriões de sessão. Para obter mais informações sobre os requisitos de uma partilha de ficheiros, consulte Partilha de ficheiros.

Tipos de imagem de disco

Para imagens de disco MSIX e Appx, pode utilizar o Sistema de Ficheiros de Imagem Composta (CimFS),VHDX ou VHD, mas não recomendamos a utilização do VHD. Montar e desmontar imagens CimFS é mais rápido do que as imagens VHD e VHDX e também consome menos CPU e memória. Só recomendamos a utilização do CimFS para as imagens da sua aplicação se os anfitriões de sessão estiverem a ser executados Windows 11.

Uma imagem cimFS é uma combinação de vários ficheiros: um ficheiro tem a .cim extensão de ficheiro e contém metadados, juntamente com pelo menos dois outros ficheiros, um começando com objectid_ e o outro começando com region_ que contêm os dados reais da aplicação. Os ficheiros que acompanham o .cim ficheiro não têm uma extensão de ficheiro. A tabela seguinte é uma lista de ficheiros de exemplo que encontrará 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 seguinte é uma comparação de desempenho entre VHDX e CimFS. Estes números foram o resultado de uma execução de teste com 500 ficheiros de 300 MB cada por formato e os testes foram realizados numa máquina virtual do Azure DSv4.

Indicador	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)	Limite máximo de várias vezes	Nenhum efeito

Cuidado

Atualmente, um problema afeta imagens CimFS com Windows 11, versão 24H2, que impede que as imagens sejam montadas. Estamos a trabalhar ativamente numa correção que se estima estar disponível em junho de 2025. Em alternativa, as soluções alternativas utilizam imagens VHDX ou utilizam uma versão do Windows 11 anterior a 24H2.

Registro de aplicativo

A aplicação Anexar monta imagens de disco ou pacotes app-V que contêm as suas aplicações de uma partilha de ficheiros para a sessão de um utilizador durante o início de sessão e, em seguida, um processo de registo disponibiliza as aplicações ao utilizador. Existem dois tipos de registo:

• A pedido: as aplicações só são parcialmente registadas no início de sessão e o registo completo de uma aplicação é adiado até que o utilizador inicie a aplicação. A pedido é o tipo de registo que recomendamos que utilize, uma vez que não afeta o tempo que demora a iniciar sessão no Azure Virtual Desktop. A pedido é o método de registo predefinido.

• Bloqueio de início de sessão: cada aplicação que atribuir a um utilizador está totalmente registada. O registo ocorre enquanto o utilizador inicia sessão na respetiva sessão, o que pode afetar o tempo de início de sessão no Azure Virtual Desktop.

Importante

Todos os pacotes de aplicações MSIX e Appx incluem um certificado. É responsável por garantir que os certificados são fidedignos no seu ambiente. Os certificados autoassinados são suportados com a cadeia de confiança adequada.

A Anexação de Aplicações não limita o número de aplicações que os utilizadores podem utilizar. Deve considerar o débito de rede disponível e o número de identificadores abertos por ficheiro (cada imagem) suportado pela partilha de ficheiros, uma vez que pode limitar o número de utilizadores ou aplicações que pode suportar. Para obter mais informações, consulte Partilha de ficheiros.

Estado da aplicação

Os pacotes de aplicações são definidos como ativos ou inativos. Os pacotes definidos como ativos disponibilizam a aplicação aos utilizadores. O Azure Virtual Desktop ignora os pacotes definidos como inativos e não são adicionados quando um utilizador inicia sessão.

Novas versões de aplicações

Pode adicionar uma nova versão de uma aplicação ao fornecer uma nova imagem que contém a aplicação atualizada. Pode utilizar esta nova imagem de duas formas:

• Lado a lado: crie uma nova aplicação com a nova imagem de disco e atribua-a aos mesmos conjuntos de anfitriões e utilizadores que a aplicação existente.

• No local: crie uma nova imagem onde o número da versão da aplicação seja alterado e, em seguida, atualize a aplicação existente para utilizar a nova imagem. O número da versão pode ser superior ou inferior, mas não pode atualizar uma aplicação com o mesmo número de versão. Não elimine a imagem existente até que todos os utilizadores a utilizem.

Depois de atualizados, os utilizadores recebem a versão da aplicação atualizada da próxima vez que iniciarem sessão. Os utilizadores não precisam de parar de utilizar a versão anterior para adicionar uma nova versão.

Provedores de Identidade

Eis os fornecedores de identidade que pode utilizar com a Anexação de Aplicações:

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

Compartilhamento de arquivos

A Anexação da Aplicação requer que as imagens da aplicação sejam armazenadas numa partilha de ficheiros SMB, que é depois montada em cada anfitrião de sessão durante o início de sessão. A Anexação da Aplicação não tem dependências no tipo de recursos de infraestrutura de armazenamento que a partilha de ficheiros utiliza. Recomendamos que utilize Arquivos do Azure, uma vez que é compatível com Microsoft Entra ID ou Active Directory Domain Services e oferece um grande valor entre custos e custos gerais de gestão.

Também pode utilizar Azure NetApp Files, mas isso requer que os anfitriões de sessão sejam associados ao Active Directory Domain Services.

As secções seguintes fornecem algumas orientações sobre as permissões, o desempenho e a disponibilidade necessários para a partilha de ficheiros.

Permissões

Cada anfitrião de sessão monta imagens da aplicação a partir da partilha de ficheiros. Tem de configurar o NTFS e partilhar permissões para permitir que cada objeto de computador anfitrião de sessões leia o acesso aos ficheiros e à partilha de ficheiros. A forma como configura a permissão correta depende do fornecedor de armazenamento e do fornecedor de identidade que está a utilizar para os anfitriões de sessão e partilha de ficheiros.

• Para utilizar Arquivos do Azure quando os anfitriões de sessão se associaram ao Microsoft Entra ID, tem de atribuir a função de controlo de acesso baseado em funções (RBAC) do Azure e do Acesso a Dados ao Azure Virtual Desktop e aos principais de serviço do Fornecedor de ARM do Azure Virtual Desktop. Esta atribuição de função RBAC permite que os anfitriões de sessão acedam à conta de armazenamento através de chaves de acesso ou Microsoft Entra.

• Para saber como atribuir uma função RBAC do Azure aos principais de serviço do Azure Virtual Desktop, veja Atribuir funções RBAC aos principais de serviço do Azure Virtual Desktop. Numa atualização futura, não terá de atribuir o principal de serviço do Fornecedor arm do Azure Virtual Desktop .

  Para obter mais informações sobre como utilizar Arquivos do Azure com anfitriões de sessão associados a Microsoft Entra ID, Active Directory Domain Services ou Microsoft Entra Domain Services, consulte Descrição geral de Arquivos do Azure opções de autenticação baseada em identidade para acesso SMB.

  Aviso

  Atribuir o principal de serviço do Fornecedor arm do Azure Virtual Desktop à conta de armazenamento concede o serviço Azure Virtual Desktop a todos os dados dentro da conta de armazenamento. Recomendamos que apenas armazene aplicações para utilizar com a Anexação de Aplicações nesta conta de armazenamento e rode as chaves de acesso regularmente.

• Para Arquivos do Azure com Active Directory Domain Services, tem de atribuir a função de controlo de acesso baseado em funções (RBAC) do Leitor de PartilhaS SMB de Dados de Armazenamento do Azure como permissão de nível de partilha predefinida e configurar permissões NTFS para conceder acesso de leitura ao objeto de computador de cada anfitrião de sessão.

  Para obter mais informações sobre como utilizar Arquivos do Azure com anfitriões de sessão associados a Microsoft Entra ID, Active Directory Domain Services ou Microsoft Entra Domain Services, consulte Descrição geral de Arquivos do Azure opções de autenticação baseada em identidade para acesso SMB.

• Por Azure NetApp Files, pode criar um volume SMB e configurar permissões NTFS para conceder acesso de leitura ao objeto de computador de cada anfitrião de sessão. Os anfitriões de sessão têm de estar associados a Active Directory Domain Services ou Microsoft Entra Domain Services.

Pode verificar se as permissões estão corretas através do PsExec. Para obter mais informações, consulte Verificar o acesso à partilha de ficheiros.

Desempenho

Os requisitos podem variar bastante consoante o número de aplicações em pacote armazenadas numa imagem e tem de testar as suas aplicações para compreender os seus requisitos. Para imagens maiores, tem de alocar mais largura de banda. A tabela seguinte dá um exemplo dos requisitos de uma única imagem de 1 GB ou pacote app-V que contém uma aplicação requer por anfitrião de sessão:

Recurso	Requisitos
IOPs de estado estável	Um IOP
Início de sessão de arranque do computador	10 IOPs
Latência	400 ms

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

• A partilha de ficheiros deve estar na mesma região do Azure que os anfitriões de sessão. Se estiver a utilizar Arquivos do Azure, a sua conta de armazenamento tem de estar na mesma região do Azure que os anfitriões de sessão.

• Exclua as imagens de disco que contêm as aplicações das análises antivírus, uma vez que são só de leitura.

• Certifique-se de que o armazenamento e os recursos de infraestrutura de rede podem proporcionar um desempenho adequado. Deve evitar utilizar a mesma partilha de ficheiros com contentores de perfil do FSLogix.

Disponibilidade

Todos os planos de recuperação após desastre do Azure Virtual Desktop têm de incluir a replicação da partilha de ficheiros para a localização de ativação pós-falha secundária. Também tem de garantir que o caminho da partilha de ficheiros está acessível na localização secundária. Por exemplo, pode utilizar Espaços de Nomes do Sistema de Ficheiros Distribuído (DFS) com Arquivos do Azure para fornecer um único nome de partilha em diferentes partilhas de ficheiros. Para saber mais sobre a recuperação após desastre do Azure Virtual Desktop, veja Configurar um plano de continuidade de negócio e recuperação após desastre.

Arquivos do Azure

Arquivos do Azure tem limites no número de identificadores abertos por diretório, diretório e ficheiro de raiz. As imagens de disco VHDX ou CimFS são montadas com a conta de computador do anfitrião da sessão, o que significa que uma alça é aberta por anfitrião de sessão por imagem de disco, em vez de por utilizador. Para obter mais informações sobre os limites e orientações de dimensionamento, veja Arquivos do Azure metas de escalabilidade e desempenho e orientações de dimensionamento de Arquivos do Azure para o Azure Virtual Desktop.

Certificados de pacotes MSIX e Appx

Todos os pacotes MSIX e Appx requerem um certificado de assinatura de código válido. Para utilizar estes pacotes com a Anexação de Aplicações, tem de garantir que toda a cadeia de certificados é fidedigna nos anfitriões de sessão. Um certificado de assinatura de código tem o identificador 1.3.6.1.5.5.7.3.3do objeto . Pode obter um certificado de assinatura de código para os seus pacotes a partir de:

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

• Uma empresa interna ou uma autoridade de certificação autónoma, como os Serviços de Certificados do Active Directory. Tem de exportar o certificado de assinatura de código, incluindo a respetiva chave privada.

• Uma ferramenta como o cmdlet do PowerShell New-SelfSignedCertificate que gera um certificado autoassinado. Só deve utilizar certificados autoassinados num ambiente de teste. Para obter mais informações sobre como criar um certificado autoassinado para pacotes MSIX e Appx, veja Criar um certificado para assinatura de pacotes.

Depois de obter um certificado, tem de assinar digitalmente os pacotes MSIX ou Appx com o certificado. Pode utilizar a Ferramenta de Empacotamento MSIX para assinar os pacotes quando criar um pacote MSIX. Para obter mais informações, consulte Criar um pacote MSIX a partir de qualquer instalador de ambiente de trabalho.

Para garantir que o certificado é fidedigno nos anfitriões de sessão, precisa que os anfitriões de sessão confiem em toda a cadeia de certificados. A forma como os anfitriões de sessão confiam na cadeia de certificados depende de onde obteve o certificado e de como gere os anfitriões de sessão e o fornecedor de identidade que utiliza. A tabela seguinte fornece algumas orientações sobre como garantir que o certificado é considerado fidedigno nos anfitriões de sessão:

• AC pública: os certificados de uma AC pública são considerados fidedignos por predefinição no Windows e Windows Server.

• AC Empresarial Interna:

  • Para anfitriões de sessão associados ao Active Directory, com o AD CS configurado como a AC empresarial interna, são considerados fidedignos por predefinição e armazenados no contexto de nomenclatura de configuração do Active Directory Domain Services. Quando o AD CS está configurado como uma AC autónoma, tem de configurar Política de Grupo para distribuir os certificados de raiz e intermediários para anfitriões de sessão. Para obter mais informações, consulte Distribuir certificados para dispositivos Windows com Política de Grupo.

  • Para anfitriões de sessão associados a Microsoft Entra ID, pode utilizar Microsoft Intune para distribuir os certificados de raiz e intermediários para anfitriões de sessão. Para obter mais informações, veja Perfis de certificado de raiz fidedigna para Microsoft Intune.

  • Para anfitriões de sessão que utilizem Microsoft Entra associação híbrida, pode utilizar qualquer um dos métodos anteriores, consoante os seus requisitos.

• Autoassinado: instale a raiz fidedigna no arquivo autoridades de certificação de raiz fidedigna em cada anfitrião de sessão. Não recomendamos a distribuição deste certificado com Política de Grupo ou Intune, uma vez que só deve ser utilizado para testes.

Importante

Deve carimbo de data/hora do pacote para que a respetiva validade possa superar a data de expiração do certificado. Caso contrário, assim que o certificado expirar, terá de atualizar o pacote com um novo certificado válido e, mais uma vez, garantir que os anfitriões de sessão confiam na cadeia de certificados.

Próximas etapas

Saiba como Adicionar e gerir aplicações anexadas a aplicações no Azure Virtual Desktop.