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

A Anexação de Aplicativo permite anexar dinamicamente aplicativos de um pacote de aplicativos a uma sessão de usuário na Área de Trabalho Virtual do Azure. Os aplicativos não são instalados localmente em hosts de sessão ou imagens, facilitando a criação de imagens personalizadas para os hosts da 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.

Aqui estão alguns dos principais benefícios do App Attach:

• Os aplicativos são entregues usando RemoteApp ou como parte de uma sessão da área de trabalho. As permissões são aplicadas por aplicativo por usuário, dando a você maior controle sobre quais aplicativos seus usuários podem acessar em uma sessão remota. Os usuários de desktop só veem os aplicativos App Attach atribuídos a eles.

• O mesmo pacote de aplicativos pode ser usado em vários pools de host.

• Os aplicativos podem ser executados em qualquer host de sessão executando um cliente Windows ou sistema operacional Windows Server com suporte na mesma região do Azure que o pacote do aplicativo.

• 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 podem executar várias versões do mesmo aplicativo simultaneamente no mesmo host de sessão.

• A telemetria para uso e integridade está disponível por meio do Análise de Logs do Azure.

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

MSIX e Appx são formatos de pacote de aplicativos do Windows que fornecem uma experiência de empacotamento moderna para aplicativos 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 dá suporte a 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 com base na necessidade. Os usuários iniciam aplicativos virtuais em pontos de acesso conhecidos e interagem com eles como se fossem instalados localmente.

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 é MSIX?.

Como um usuário obtém um aplicativo

Você pode atribuir diferentes aplicativos a diferentes usuários no mesmo pool de hosts ou no mesmo host de sessão. Durante a entrada, 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 host. Atribuir o aplicativo ao pool de hosts permite que você seja seletivo sobre em quais pools de host 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 seja executado apenas em um pool de hosts com host de sessão otimizado para GPU.

• O usuário deve ser capaz de entrar nos hosts de sessão no pool de hosts, portanto, eles devem estar em um grupo de aplicativos da área de trabalho ou RemoteApp. Para um grupo de aplicativos RemoteApp, o aplicativo Anexo de 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 terá acesso ao aplicativo. Esse processo fornece controle sobre quem obtém um aplicativo em qual pool de hosts e também como é possível para os usuários em um único pool de hosts ou até mesmo conectados ao mesmo host de sessão de várias sessões obter diferentes combinações de aplicativos. Os usuários que não atendem aos requisitos não obtêm o aplicativo.

Imagens do aplicativo

Antes de usar pacotes de aplicativos MSIX com a Área de Trabalho Virtual do Azure, você precisa Criar uma imagem MSIX de seus pacotes de aplicativos existentes. Como alternativa, você pode usar um pacote do 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 de um compartilhamento de arquivos, consulte Compartilhamento de arquivos.

Tipos de imagem de disco

Para imagens de disco MSIX e Appx, você pode usar CimFS (Sistema de Arquivos de Imagem Composta),VHDX ou VHD, mas não recomendamos usar VHD. A montagem e desmontagem de imagens CimFS é mais rápida do que as imagens VHD e VHDX e também consome menos CPU e memória. Recomendamos usar o CimFS apenas para suas imagens de 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 extensão de .cim 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 arquivos que acompanham o .cim arquivo não têm uma extensão de arquivo. A tabela a seguir é uma lista de arquivos de exemplo que você encontraria para uma imagem CimFS:

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

Registro de aplicativo

O App Attach monta imagens de disco ou pacotes do App-V que contêm seus aplicativos de um compartilhamento de arquivos para a sessão de um usuário durante a entrada 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 apenas parcialmente no momento da entrada e o registro completo de um aplicativo é adiado até que o usuário inicie o aplicativo. Sob demanda é 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. Sob demanda é o método de registro padrão.

• Bloqueio de logon: cada aplicativo que você atribui a um usuário é totalmente registrado. O registro acontece 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.

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 de rede disponível e o número de identificadores abertos por arquivo (cada imagem) ao qual seu compartilhamento de arquivos dá suporte, 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 tornam o aplicativo disponível para os usuários. A Área de Trabalho Virtual do Azure ignora pacotes definidos como inativos e não são adicionados quando um usuário entra.

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

• No local: crie uma nova imagem em que o número de versão do aplicativo seja alterado e, em seguida, 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.

Depois de atualizado, os usuários obterã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.

Provedores de Identidade

Aqui estão os provedores de identidade que você pode usar com o App Attach:

Compartilhamento de arquivos

O Anexo de Aplicativo exige que as imagens do aplicativo sejam armazenadas em um compartilhamento de arquivo SMB, que é montado em cada host de sessão durante a entrada. O App Attach não tem dependências do tipo de malha de armazenamento que o compartilhamento de arquivos usa. Recomendamos o uso de Arquivos do Azure, pois é compatível com o Microsoft Entra ID ou o Active Directory Domain Services e oferece grande valor entre custo e sobrecarga de gerenciamento.

Você também pode usar o Azure NetApp Files, mas isso exige que os hosts da sessão ingressem no Active Directory Domain Services.

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 aplicativo do compartilhamento de arquivos. Você precisa configurar o NTFS e as permissões de compartilhamento para permitir que cada sessão de objeto de computador host tenha acesso de leitura aos arquivos e ao compartilhamento de arquivos. A maneira 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 os hosts da sessão ingressarem no Microsoft Entra ID, você precisa atribuir a função RBAC (controle de acesso baseado em função) do Azure de Leitor e Acesso a Dados à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 os hosts da 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 no Microsoft Entra ID, no Active Directory Domain Services ou no Microsoft Entra Domain Services, confira Visão geral da Arquivos do Azure opções de autenticação baseada em identidade para acesso SMB.

  Aviso

  Atribuir a entidade de serviço do Provedor ARM da Área de Trabalho Virtual do Azure à conta de armazenamento concede o serviço da Á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 Aplicativo nesta conta de armazenamento e alterne as chaves de acesso regularmente.

• Para Arquivos do Azure com o Active Directory Domain Services, você precisa atribuir a função de RBAC (controle de acesso baseado em função) do Leitor de Compartilhamento SMB de Dados de Arquivo de Armazenamento do Azure como a permissão padrão no nível do compartilhamento e configurar as permissões NTFS para fornecer acesso de leitura ao objeto de computador de cada host de sessão.

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

• Para o Azure NetApp Files, você pode criar um volume SMB e configurar permissões NTFS para conceder acesso de leitura ao objeto de computador de cada host de sessão. Os hosts da sua sessão precisam estar 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, consulte Verificar acesso ao compartilhamento de arquivos.

User and Deployment Configuration Files

Para pacotes do App-V entregues por meio do App Attach, você pode usar arquivos de Configuração Dinâmica do App-V para personalizar o comportamento do aplicativo. O Anexo de Aplicativo detecta automaticamente os arquivos de configuração padrão que seguem a convenção de nomenclatura esperada. Se eles estiverem na mesma pasta que o pacote de Anexo de Aplicativo e o xml for prefixado com o nome do arquivo App-V, esses arquivos serão associados automaticamente ao pacote do aplicativo durante o processamento. Se o caminho do arquivo for \share\folder\filename.appv, os exemplos abaixo serão automaticamente detectados e usados com o pacote.

• \share\folder\filename_UserConfig.xml

• \share\folder\filename_DeploymentConfig.xml

$a = Get-AzWvdAppAttachPackage -SubscriptionId blahblah -ResourceGroupName blahblahrg -Name contosoPackage

$dependencyType = $a.GetType().Assembly.GetTypes() |
    Where-Object {
        $_.Name -eq 'MsixPackageDependencies' -and
        $_.Namespace -like '*DesktopVirtualization*'
    } |
    Select-Object -First 1

$newDependency = [System.Activator]::CreateInstance($dependencyType)
$newDependency.DependencyName = "FilePathToUserConfig"
$newDependency.Publisher = "Group Object Id"
$newDependency.MinVersion = 1
$dependencyList = $a.ImagePackageDependency
$dependencyList += $newDependency
Update-AzWvdAppAttachPackage -ImagePackageDependency $dependencyList -SubscriptionId blahblah -ResourceGroupName blahblahrg -Name contosoPackage

# Remove logic
$a = Get-AzWvdAppAttachPackage -SubscriptionId blahblah -ResourceGroupName blahblahrg -Name contosoPackage
$dependencyList = $a.ImagePackageDependency
$dependencyList  = $dependencyList | where-Object {$_.DependencyName -ne "FilePathToUserConfig"}
Update-AzWvdAppAttachPackage -ImagePackageDependency $dependencyList -SubscriptionId blahblah -ResourceGroupName blahblahrg -Name contosoPackage
 

Os arquivos de configuração do usuário são avaliados no nível do usuário, permitindo que diferentes usuários recebam diferentes configurações de aplicativo. Os arquivos de configuração de implantação, por outro lado, são aplicados no nível do computador e são compartilhados por todos os usuários no host da sessão. No momento, a configuração do usuário só é compatível com conexões de área de trabalho, não em conexões de aplicativos remotos.

Cenários avançados podem exigir vários arquivos de configuração do usuário para o mesmo aplicativo. Nesses casos, os arquivos de configuração de usuário adicionais devem ser explicitamente associados ao pacote de aplicativos usando o PowerShell.

A anexação de aplicativo verifica o objeto de dependência

• Tem um caminho de arquivo especificado no campo DependencyName que termina com UserConfig.xml

• Contém um campo Fornecedor que identifica o grupo de segurança do Microsoft Entra que deve receber essa configuração. O valor do campo Publicador do pacote do aplicativo deve ser definido como a ID de Objeto do grupo de segurança de destino.

Durante o logon, o Anexo de Aplicativo avalia as associações de grupo do usuário e aplica a configuração de usuário apropriada com base no grupo associado.

Os administradores devem usar vários arquivos de configuração de usuário somente quando populações de usuários diferentes exigirem configurações de aplicativo distintas; As implantações padrão podem continuar a depender do arquivo de configuração de usuário único detectado automaticamente.

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 do App-V contendo um aplicativo requer por host de sessão:

Para otimizar o desempenho de seus aplicativos, recomendamos:

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

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

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

Disponibilidade

Todos os planos de recuperação de desastre para a Área de Trabalho Virtual do Azure devem incluir a replicação do compartilhamento de arquivos para o local de failover secundário. Você também precisa garantir que o 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 desastre para a Área de Trabalho Virtual do Azure, confira Configurar um plano de continuidade dos negócios e recuperação de desastres.

Arquivos do Azure

Os Arquivos do Azure têm limites para o número de identificadores abertos por diretório raiz, diretório e arquivo. As imagens de disco VHDX ou CimFS são montadas usando a conta de computador do host de 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 limites e diretrizes de dimensionamento, consulte Metas de desempenho e escalabilidade 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 Anexo de Aplicativo, 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 AC (autoridade de certificação) pública.

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

• Uma ferramenta como o cmdlet New-SelfSignedCertificate do PowerShell 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 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 seus hosts de sessão confiem em toda a cadeia de certificados. A forma como os hosts de sessão confiam na cadeia de certificados depende de onde você obteve o certificado e de como gerencia os hosts de sessão e o provedor de identidade usado. A tabela a seguir fornece algumas orientações sobre como garantir que o certificado seja confiável em seus hosts de sessão:

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

• AC Corporativa Interna:

  • Para hosts de sessão ingressados no Active Directory, com o AD CS configurado como a CA 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 autoridade de certificação 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áveis para o Microsoft Intune.

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

• Autoassinado: instale a raiz confiável no repositório de 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 deve ser usado apenas para testes.

Próximas etapas

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