Collegamento di app in Desktop virtuale di Azure

Il collegamento di app consente di collegare dinamicamente le applicazioni da un pacchetto dell'applicazione a una sessione utente in Desktop virtuale di Azure. Le applicazioni non vengono installate localmente sugli host di sessione o sulle immagini, semplificando la creazione di immagini personalizzate per gli host di sessione e riducendo il sovraccarico operativo e i costi per l'organizzazione. Le applicazioni vengono eseguite all'interno di contenitori, che separano i dati dell'utente, il sistema operativo e altre applicazioni, aumentando la sicurezza e semplificando la risoluzione dei problemi.

Ecco alcuni dei principali vantaggi di App Attach:

• Le applicazioni vengono distribuite tramite RemoteApp o come parte di una sessione desktop. Le autorizzazioni vengono applicate per applicazione, per utente, offrendo un maggiore controllo sulle applicazioni a cui gli utenti possono accedere in una sessione remota. Gli utenti desktop vedono solo le applicazioni collegate ad app a loro assegnate.

• Lo stesso pacchetto dell'applicazione può essere utilizzato in più pool host.

• Le applicazioni possono essere eseguite in qualsiasi host sessione che esegue un client Windows o un sistema operativo server Windows supportato nella stessa area di Azure del pacchetto dell'applicazione.

• Le applicazioni possono essere aggiornate a una nuova versione dell'applicazione con una nuova immagine del disco senza la necessità di una finestra di manutenzione.

• Gli utenti possono eseguire più versioni della stessa applicazione contemporaneamente nello stesso host di sessione.

• La telemetria per l'utilizzo e l'integrità è disponibile tramite Log Analytics di Azure.

È possibile utilizzare i seguenti tipi di pacchetti dell'applicazione e formati di file:

MSIX e Appx sono formati di pacchetti di applicazioni Windows che offrono un'esperienza di creazione di pacchetti moderna per le applicazioni Windows. Le applicazioni vengono eseguite all'interno di contenitori, che separano i dati dell'utente, il sistema operativo e altre applicazioni, aumentando la sicurezza e semplificando la risoluzione dei problemi. MSIX e Appx sono simili, e la differenza principale è che MSIX è un superset di Appx. MSIX supporta tutte le funzionalità di Appx, oltre ad altre che lo rendono più adatto all'uso aziendale.

Microsoft Application Virtualization (App-V) per Windows offre agli utenti applicazioni Win32 come applicazioni virtuali. Le applicazioni virtuali sono installate in server centralizzati e vengono fornite agli utenti come un servizio in tempo reale e in base alle esigenze. Gli utenti avviano le applicazioni virtuali da punti di accesso familiari e interagiscono con loro come se fossero installate localmente.

È possibile ottenere i pacchetti MSIX dai fornitori di software oppure creare un pacchetto MSIX da un programma di installazione esistente. Per altre informazioni su MSIX, vedere Che cos'è MSIX?.

Come un utente ottiene un'applicazione

È possibile assegnare applicazioni diverse a utenti diversi nello stesso pool di host o nello stesso host di sessione. Per consentire all'utente di ottenere l'applicazione giusta al momento giusto, devono essere soddisfatti tutti e tre i requisiti seguenti:

• L'applicazione deve essere assegnata al pool di host. L'assegnazione dell'applicazione al pool di host consente di essere selettivi rispetto ai pool di host in cui l'applicazione è disponibile per garantire che le risorse hardware appropriate siano disponibili per l'utilizzo da parte dell'applicazione. Ad esempio, se un'applicazione richiede un utilizzo intensivo della grafica, è possibile assicurarsi che venga eseguita solo in un pool di host con host di sessione ottimizzati per GPU.

• L'utente deve essere in grado di accedere agli host di sessione nel pool di host, quindi devono trovarsi in un gruppo di applicazioni Desktop o RemoteApp. Per un gruppo di applicazioni RemoteApp, l'applicazione collegata di app deve essere aggiunta al gruppo di applicazioni, ma non è necessario aggiungere l'applicazione a un gruppo di applicazioni desktop.

• L'applicazione deve essere assegnata all'utente. È possibile usare un account utente o di gruppo.

Se tutti questi requisiti sono soddisfatti, l'utente ottiene l'applicazione. Questo processo consente di controllare chi ottiene un'applicazione in quale pool di host e anche come è possibile per gli utenti all'interno di un singolo pool di host o anche accedere allo stesso host di sessioni multisessione ottenere diverse combinazioni di applicazioni. Gli utenti che non soddisfano i requisiti non ottengono l'applicazione.

Immagini dell'applicazione

Prima di poter usare i pacchetti dell'applicazione MSIX con Desktop virtuale Azure, è necessario creare un'immagine MSIX dai pacchetti dell'applicazione esistenti. In alternativa, è possibile usare un pacchetto App-V. È quindi necessario archiviare ogni immagine MSIX o pacchetto App-V in una condivisione file accessibile dagli host di sessione. Per ulteriori informazioni sui requisiti per una condivisione di file, consulta Condivisione di file.

Tipi di immagine disco

Per le immagini disco MSIX e Appx è possibile usare CimFS (Composite Image File System),VHDX o VHD, ma non è consigliabile usare VHD. Il montaggio e lo smontaggio delle immagini CimFS è più veloce rispetto alle immagini VHD e VHDX e consuma anche meno CPU e memoria. È consigliabile usare CimFS per le immagini dell'applicazione solo se gli host della sessione eseguono Windows 11.

Un'immagine CimFS è una combinazione di diversi file: un file ha l'estensione e .cim contiene metadati, insieme ad almeno altri due file, uno che inizia con objectid_ e l'altro che inizia con region_ che contengono i dati effettivi dell'applicazione. I file che accompagnano il .cim file non hanno un'estensione. La tabella seguente è un elenco di file di esempio che potresti trovare per un'immagine CimFS:

La tabella seguente è un confronto delle prestazioni tra VHDX e CimFS. Questi numeri sono stati il risultato di un test eseguito con 500 file da 300 MB ciascuno per formato e i test sono stati eseguiti su una macchina virtuale di Azure DSv4.

Registrazione dell'applicazione

Il collegamento di app monta le immagini disco o i pacchetti App-V contenenti le applicazioni da una condivisione file a una sessione utente durante l'accesso, quindi un processo di registrazione rende disponibili le applicazioni all'utente. Esistono due tipi di registrazione:

• Su richiesta: le applicazioni vengono registrate solo parzialmente al momento dell'accesso e la registrazione completa di un'applicazione viene posticipata fino a quando l'utente non avvia l'applicazione. Il tipo di registrazione su richiesta è consigliabile usare perché non influisce sul tempo necessario per accedere a Desktop virtuale Azure. On-demand è il metodo di registrazione predefinito.

• Blocco dell'accesso: ogni applicazione assegnata a un utente è completamente registrata. La registrazione viene eseguita durante l'accesso dell'utente alla sessione e potrebbe influire sul tempo di accesso a Desktop virtuale Azure.

Il collegamento di app non limita il numero di applicazioni che gli utenti possono utilizzare. È consigliabile considerare la velocità effettiva di rete disponibile e il numero di handle aperti per file (ogni immagine) supportata dalla condivisione file, in quanto potrebbe limitare il numero di utenti o applicazioni che è possibile supportare. Per ulteriori informazioni, consulta Condivisione file.

Stato dell'applicazione

I pacchetti dell'applicazione sono impostati come attivi o inattivi. Pacchetti impostati su attivo rende disponibile l'applicazione agli utenti. Desktop virtuale Azure ignora i pacchetti impostati su inattivi e non vengono aggiunti quando un utente accede.

Nuove versioni delle applicazioni

È possibile aggiungere una nuova versione di un'applicazione fornendo una nuova immagine contenente l'applicazione aggiornata. È possibile usare questa nuova immagine in due modi:

• Fianco a fianco: crea una nuova applicazione utilizzando la nuova immagine del disco e assegnala agli stessi pool di host e utenti dell'applicazione esistente.

• Sul posto: creare una nuova immagine in cui cambia il numero di versione dell'applicazione, quindi aggiornare l'applicazione esistente per usare la nuova immagine. Il numero di versione può essere maggiore o minore, ma non è possibile aggiornare un'applicazione con lo stesso numero di versione. Non eliminare l'immagine esistente finché tutti gli utenti non hanno finito di usarla.

Una volta aggiornata, gli utenti ottengono la versione aggiornata dell'applicazione al successivo accesso. Gli utenti non devono interrompere l'uso della versione precedente per aggiungere una nuova versione.

Provider di identità

Ecco i provider di identità che è possibile usare con App:

Condivisione file

Il collegamento di app richiede che le immagini dell'applicazione siano archiviate in una condivisione file SMB, che viene quindi montata in ogni host di sessione durante l'accesso. Il collegamento dell'app non ha dipendenze dal tipo di infrastruttura di archiviazione utilizzata dalla condivisione file. È consigliabile usare File di Azure perché è compatibile con Microsoft Entra ID o Active Directory Domain Services e offre un ottimo rapporto qualità-prezzo tra costi e costi generali di gestione.

È anche possibile usare Azure NetApp Files, ma ciò richiede l'aggiunta degli host di sessione ad Active Directory Domain Services.

Le sezioni seguenti forniscono alcune indicazioni sulle autorizzazioni, le prestazioni e la disponibilità necessarie per la condivisione file.

Autorizzazioni

Ogni host di sessione monta le immagini dell'applicazione dalla condivisione file. È necessario configurare NTFS e condividere le autorizzazioni per consentire a ogni oggetto computer host sessione l'accesso in lettura ai file e alla condivisione file. La modalità di configurazione dell'autorizzazione corretta dipende dal provider di archiviazione e dal provider di identità in uso per gli host di condivisione file e sessione.

• Per usare File di Azure quando gli host di sessione sono aggiunti a Microsoft Entra ID, è necessario assegnare il ruolo di controllo degli accessi in base al ruolo di lettura e accesso ai dati di Azure sia alle entità servizio del provider ARM di Desktop virtuale Azure che a quello del provider ARM di Desktop virtuale Azure. Questa assegnazione di ruolo RBAC consente agli ospitanti di accedere all'account di archiviazione usando i tasti di scelta o Microsoft Entra.

• Per informazioni su come assegnare un ruolo Controllo dell'accesso in base al ruolo di Azure alle entità servizio di Desktop virtuale Azure, vedere Assegnare ruoli di controllo dell'accesso in base al ruolo alle entità servizio di Desktop virtuale Azure. In un aggiornamento futuro non sarà necessario assegnare l'entità servizio Provider ARM di Desktop virtuale Azure.

  Per altre informazioni sull'uso di File di Azure con host di sessione aggiunti a Microsoft Entra ID, Active Directory Domain Services o Microsoft Entra Domain Services, vedere Panoramica di Opzioni di autenticazione basata su identità di File di Azure per l'accesso SMB.

  Avviso

  L'assegnazione dell'entità servizio Provider ARM di Desktop virtuale Azure all'account di archiviazione concede il servizio Desktop virtuale Azure a tutti i dati all'interno dell'account di archiviazione. È consigliabile archiviare in questo account di archiviazione solo le app da usare con il collegamento di app e di ruotare regolarmente i tasti di scelta.

• Per i File di Azure con Active Directory Domain Services, è necessario assegnare il ruolo di controllo degli accessi in base al ruolo di controllo degli accessi in base al ruolo di controllo degli accessi in base al ruolo di Azure di controllo degli accessi in base al ruolo di archiviazione dei dati SMB come autorizzazione predefinita a livello di condivisione e configurare le autorizzazioni NTFS per concedere l'accesso in lettura all'oggetto computer dell'host di ogni sessione.

  Per altre informazioni sull'uso di File di Azure con host di sessione aggiunti a Microsoft Entra ID, Active Directory Domain Services o Microsoft Entra Domain Services, vedere Panoramica di Opzioni di autenticazione basata su identità di File di Azure per l'accesso SMB.

• Per Azure NetApp Files, è possibile creare un volume SMB e configurare le autorizzazioni NTFS per concedere l'accesso in lettura all'oggetto computer dell'host di ogni sessione. Gli host di sessione devono essere aggiunti ad Active Directory Domain Services o a Microsoft Entra Domain Services.

È possibile verificare che le autorizzazioni siano corrette usando PsExec. Per ulteriori informazioni, consulta Controllare l'accesso alla condivisione file.

Files di configurazione di utenti e distribuzione

Per i pacchetti App-V recapitati tramite il collegamento di app è possibile usare i file di configurazione dinamica di App-V per personalizzare il comportamento dell'applicazione. Il collegamento di app rileva automaticamente i file di configurazione standard che seguono la convenzione di denominazione prevista. Se si trovano nella stessa cartella del pacchetto di collegamento di app e il prefisso xml è preceduto dal nome del file App-V, questi file vengono automaticamente associati al pacchetto dell'applicazione durante l'elaborazione. Se il percorso del file è \share\folder\nomefile.appv, gli esempi seguenti verranno rilevati e usati automaticamente con il pacchetto.

• \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
 

I file di configurazione utente vengono valutati a livello di utente, consentendo a utenti diversi di ricevere impostazioni diverse dell'applicazione. I file di configurazione della distribuzione, al contrario, vengono applicati a livello di computer e sono condivisi da tutti gli utenti nell'host della sessione. Al momento, la configurazione utente è supportata solo nelle connessioni desktop, non nelle connessioni alle app remote.

Gli scenari avanzati possono richiedere più file di configurazione utente per la stessa applicazione. In questi casi, i file di configurazione utente aggiuntivi devono essere associati in modo esplicito al pacchetto dell'applicazione tramite PowerShell.

Il collegamento di app controlla l'oggetto dipendenza

• Abbia un percorso del file specificato nel campo DependencyName che termina con UserConfig.xml

• Contiene un campo Publisher che identifica il gruppo di sicurezza di Microsoft Entra che deve ricevere tale configurazione. Il valore del campo Publisher del pacchetto dell'app deve essere impostato sull'ID oggetto del gruppo di sicurezza di destinazione.

Durante l'accesso, il collegamento di app valuta l'appartenenza al gruppo dell'utente e applica la configurazione utente appropriata in base al gruppo associato.

Gli amministratori devono usare più file di configurazione utente solo quando popolazioni di utenti diverse richiedono impostazioni di applicazioni distinte; Le distribuzioni standard possono continuare a basarsi sul file di configurazione utente singolo rilevato automaticamente.

Prestazioni

I requisiti possono variare notevolmente a seconda del numero di applicazioni in pacchetto archiviate in un'immagine ed è necessario testare le applicazioni per comprendere i requisiti. Per immagini più grandi, devi allocare più larghezza di banda. Nella tabella seguente viene fornito un esempio dei requisiti richiesti da una singola immagine da 1 GB o pacchetto App-V contenente un'applicazione per ogni host di sessione:

Per ottimizzare le prestazioni delle applicazioni, è consigliabile:

• La condivisione file deve trovarsi nella stessa area di Azure degli host di sessione. Se si usa File di Azure, l'account di archiviazione deve trovarsi nella stessa area di Azure degli host sessione.

• Escludere le immagini disco contenenti le applicazioni dalle analisi antivirus in quanto sono di sola lettura.

• Assicurarsi che l'infrastruttura di archiviazione e rete sia in grado di fornire prestazioni adeguate. È consigliabile evitare di usare la stessa condivisione file con i contenitori di profili FSLogix.

Disponibilità

Qualsiasi piano di ripristino di emergenza per Desktop virtuale Azure deve includere la replica della condivisione file nella posizione di failover secondaria. È anche necessario assicurarsi che il percorso della condivisione file sia accessibile nella posizione secondaria. Ad esempio, è possibile usare gli spazi dei nomi DFS (Distributed File System) con File di Azure per fornire un singolo nome di condivisione su diverse condivisioni file. Per altre informazioni sul ripristino di emergenza per Desktop virtuale Azure, vedere Configurare un piano di continuità aziendale e ripristino di emergenza.

File di Azure

File di Azure ha limiti per il numero di handle aperti per directory radice, directory e file. Le immagini disco VHDX o CimFS vengono montate utilizzando l'account computer dell'host di sessione, ovvero viene aperto un handle per host di sessione per immagine del disco, anziché per utente. Per altre informazioni sui limiti e sulle linee guida per il dimensionamento, vedere File di Azure le destinazioni di scalabilità e prestazioni e File di Azure linee guida per il ridimensionamento per Azure Desktop virtuale.

Certificati dei pacchetti MSIX e Appx

Tutti i pacchetti MSIX e Appx richiedono un certificato di firma del codice valido. Per utilizzare questi pacchetti con il collegamento all'app, è necessario assicurarsi che l'intera catena di certificati sia attendibile negli host di sessione. Un certificato di firma del codice ha l'identificatore 1.3.6.1.5.5.7.3.3dell'oggetto . Puoi ottenere un certificato di firma del codice per i tuoi pacchetti da:

• Un'autorità di certificazione (CA) pubblica.

• Un'autorità di certificazione interna dell'organizzazione o autonoma, come Servizi certificati Active Directory. È necessario esportare il certificato di firma del codice, inclusa la chiave privata.

• Uno strumento come il cmdlet di PowerShell New-SelfSignedCertificate che genera un certificato autofirmato. In un ambiente di test è consigliabile usare solo certificati autofirmati. Per altre informazioni sulla creazione di un certificato autofirmato per i pacchetti MSIX e Appx, vedere Creare un certificato per la firma del pacchetto.

Dopo aver ottenuto un certificato, è necessario firmare digitalmente i pacchetti MSIX o Appx con il certificato. È possibile usare MSIX Packaging Tool per firmare i pacchetti quando si crea un pacchetto MSIX. Per altre informazioni, vedere Creare un pacchetto MSIX da qualsiasi programma di installazione desktop.

Per garantire che il certificato sia attendibile sugli host di sessione, è necessario che gli host di sessione considerino attendibile l'intera catena di certificati. Il modo in cui gli host di sessione considerano attendibile la catena di certificati dipende dalla provenienza del certificato e dal modo in cui si gestiscono gli host di sessione e il provider di identità utilizzato. La tabella seguente fornisce alcune indicazioni su come verificare che il certificato sia attendibile negli host di sessione:

• CA pubblica: i certificati di una CA pubblica sono considerati attendibili per impostazione predefinita in Windows e Windows Server.

• CA aziendale interna:

  • Per gli host di sessione aggiunti ad Active Directory, con Servizi certificati Active Directory configurati come CA aziendale interna, sono considerati attendibili per impostazione predefinita e archiviati nel contesto dei nomi di configurazione di Active Directory Domain Services. Quando Servizi certificati Active Directory viene configurato come CA autonoma, è necessario configurare i criteri di gruppo per distribuire i certificati radice e intermedi agli host di sessione. Per altre informazioni, vedere Distribuire i certificati ai dispositivi Windows usando i criteri di gruppo.

  • Per gli host di sessione aggiunti a Microsoft Entra ID, è possibile utilizzare Microsoft Intune per distribuire i certificati radice e intermedi agli host di sessione. Per altre informazioni, vedere Profili di certificati radice attendibili per Microsoft Intune.

  • Per gli host di sessione che usano l'unione ibrida Microsoft Entra, è possibile usare uno dei metodi precedenti, a seconda dei requisiti.

• Autofirmato: installare la radice attendibile nell'archivio Autorità di certificazione radice attendibili in ogni host di sessione. Non è consigliabile distribuire questo certificato usando Criteri di gruppo o Intune perché dovrebbe essere usato solo per i test.

Passaggi successivi

Informazioni su come aggiungere e gestire applicazioni di collegamento di app in Desktop virtuale di Azure.