Condividi tramite

App Attach e MSIX App Attach in Desktop virtuale Azure

  • Articolo

In Desktop virtuale Azure sono disponibili due funzionalità che consentono di allegare in modo dinamico le applicazioni da un pacchetto applicativo a una sessione utente in Desktop virtuale Azure: App Attach e MSIX App Attach. Le applicazioni App Attach e MSIX App Attach non vengono installate in locale negli host di sessione o nelle immagini, semplificando così 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 utente, il sistema operativo e altre applicazioni, aumentando la sicurezza e semplificando la risoluzione dei problemi.

La tabella seguente confronta MSIX App Attach con App Attach:

Connessione all'app MSIX Montaggio app
Le applicazioni vengono distribuite tramite RemoteApp o come parte di una sessione desktop. Le autorizzazioni sono controllate dall'assegnazione ai gruppi di applicazioni; tuttavia, tutti gli utenti desktop vedono tutte le applicazioni MSIX App Attach nel gruppo di applicazioni desktop. Le applicazioni vengono distribuite tramite RemoteApp o come parte di una sessione desktop. Le autorizzazioni vengono applicate per ogni applicazione per utente, consentendo un maggiore controllo sulle applicazioni a cui gli utenti possono accedere in una sessione remota. Gli utenti desktop visualizzano solo le applicazioni App Attach loro assegnate.
Le applicazioni possono essere eseguite solo in un pool di host. Se si desidera eseguirlo in un altro pool di host, è necessario creare un altro pacchetto. Lo stesso pacchetto dell'applicazione può essere usato in più pool di host.
Le applicazioni possono essere eseguite solo nel pool di host in cui vengono aggiunte. Le applicazioni possono essere eseguite in qualsiasi host di sessione che esegue un sistema operativo client Windows nella stessa area di Azure del pacchetto dell'applicazione.
Per aggiornare l'applicazione, è necessario eliminare e ricreare l'applicazione con un'altra versione del pacchetto. È consigliabile aggiornare l'applicazione in una finestra di manutenzione. Le applicazioni possono essere aggiornate a una nuova versione dell'applicazione con una nuova immagine disco senza la necessità di una finestra di manutenzione.
Gli utenti non possono eseguire due versioni della stessa applicazione nello stesso host di sessione. Gli utenti possono eseguire due versioni della stessa applicazione contemporaneamente nello stesso host di sessione.
I dati di telemetria per l'utilizzo e l'integrità non sono disponibili tramite Azure Log Analytics. I dati di telemetria per l'utilizzo e l'integrità sono disponibili tramite Azure Log Analytics.

È possibile usare i tipi di pacchetto e i formati di file dell'applicazione seguenti:

Tipo di pacchetto Formati di file Disponibilità di funzionalità
Bundle MSIX e MSIX .msix
.msixbundle		 Connessione all'app MSIX
Montaggio app
Bundle Appx e Appx .appx
.appxbundle		 Solo App Attach
App-V .appv Solo App Attach

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

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

Suggerimento

Selezionare un pulsante nella parte superiore di questo articolo per scegliere tra montaggio app e montaggio app MSIX e visualizzare la documentazione pertinente.

È possibile ottenere 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?

Modalità di ottenimento di un'applicazione

È possibile assegnare applicazioni diverse a utenti diversi nello stesso pool di host o nello stesso host di sessione. Durante l'accesso, tutti e tre i requisiti seguenti devono essere soddisfatti affinché l'utente ottenga l'applicazione corretta al momento giusto:

  • L'applicazione deve essere assegnata al pool di host. L'assegnazione dell'applicazione al pool di host consente di essere selettivi sui pool di host su cui è disponibile l'applicazione per assicurarsi che le risorse hardware corrette siano disponibili per l'uso 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 sessione nel pool di host, per cui deve trovarsi in un gruppo di applicazioni Desktop o RemoteApp. Per un gruppo di applicazioni RemoteApp, l'applicazione App Attach deve essere aggiunta al gruppo di applicazioni; tuttavia, non è necessario aggiungere l'applicazione a un gruppo di applicazioni desktop.

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

Se tutti questi requisiti sono soddisfatti, l'utente ottiene l'applicazione. Questo processo fornisce il controllo su chi ottiene un'applicazione su quale pool di host e come è possibile consentire agli utenti all'interno di un singolo pool di host o persino di accedere allo stesso host di sessione multisessione per ottenere combinazioni di applicazioni diverse. Gli utenti che non soddisfano i requisiti non ottengono l'applicazione.

Modalità di ottenimento di un'applicazione

È possibile assegnare applicazioni diverse a utenti diversi nello stesso pool di host. Con MSIX App Attach, si aggiungono pacchetti MSIX a un pool di host e si controlla l'assegnazione di applicazioni usando gruppi di applicazioni desktop o RemoteApp. Durante l'accesso, è necessario soddisfare i requisiti seguenti per consentire all'utente di ottenere l'applicazione corretta al momento giusto:

  • L'utente deve essere in grado di accedere agli host sessione nel pool di host, per cui deve trovarsi in un gruppo di applicazioni Desktop o RemoteApp.

  • L'immagine MSIX deve essere aggiunta al pool di host.

Se questi requisiti sono soddisfatti, l'utente ottiene l'applicazione. L'assegnazione di applicazioni tramite un gruppo di applicazioni desktop li aggiunge al menu Start dell'utente. Gli utenti che non soddisfano i requisiti non ottengono l'applicazione.

Immagini dell'applicazione

Prima di poter usare i pacchetti applicativi con Desktop virtuale Azure, è necessario creare un'immagine MSIX dai pacchetti di applicazioni esistenti usando lo strumento MSIXMGR. È quindi necessario archiviare ogni immagine del disco in una condivisione file accessibile dagli host di sessione. Per altre informazioni sui requisiti per la condivisione file, vedere Condivisione file.

::: zone-pivot="app-attach" Se si usa App-V, vedere Creazione e gestione di applicazioni virtualizzate app-V. ::: zone-end

Tipi di immagine del disco

Per le immagini del disco MSIX e Appx, è possibile usare CimFS (Composite Image File System), VHDX o VHD, ma non è consigliabile usare il disco rigido virtuale. Il montaggio e lo smontaggio delle immagini CimFS sono più veloci rispetto ai file VHD e VHDX e utilizzano anche meno CPU e memoria. È consigliabile usare CimFS solo per le immagini dell'applicazione se gli host di sessione eseguono Windows 11.

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

File name Dimensione
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

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

Metric VHD CimFS
Tempo medio di montaggio 356 ms 255 ms
Tempo medio di smontaggio 1615 ms 36 ms
Utilizzo della memoria 6% (di 8 GB) 2% (di 8 GB)
CPU (picco di conteggio) Numero massimo di volte Nessun effetto

Registrazione dell'applicazione

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

MSIX App Attach monta immagini disco contenenti le applicazioni da una condivisione file alla sessione di un utente durante l'accesso, dopodiché un processo di registrazione rende le applicazioni disponibili per l'utente. Esistono due tipi di registrazione:

  • Su richiesta: le applicazioni vengono registrate solo parzialmente all'accesso e la registrazione completa di un'applicazione viene posticipata fino all'avvio dell'applicazione da parte dell'utente. Su richiesta è il tipo di registrazione che è consigliabile usare perché non influisce sul tempo necessario per accedere a Desktop virtuale Azure. Su richiesta è il metodo di registrazione predefinito.

  • Blocco dell'accesso: ogni applicazione assegnata a un utente è pienamente registrata. La registrazione avviene durante l'accesso dell'utente alla sessione, che potrebbe influire sul tempo di accesso a Desktop virtuale Azure.

Importante

Tutti i pacchetti di applicazioni MSIX e Appx includono un certificato. L'utente è responsabile di assicurarsi che i certificati siano attendibili nell'ambiente. I certificati autofirmati sono supportati con la catena di certificati appropriata.

App Attach non limita il numero di applicazioni che gli utenti possono usare. È consigliabile prendere in considerazione la velocità effettiva di rete disponibile e il numero di handle aperti per ogni file (singola immagine) supportati dalla condivisione file, in quanto potrebbe limitare il numero di utenti o applicazioni che è possibile supportare. Per altre informazioni, vedere Condivisione file.

Importante

Tutti i pacchetti dell'applicazione MSIX includono un certificato. L'utente è responsabile di assicurarsi che i certificati siano attendibili nell'ambiente. I certificati autofirmati sono supportati.

MSIX App Attach non limita il numero di applicazioni che gli utenti possono usare. È consigliabile prendere in considerazione la velocità effettiva di rete disponibile e il numero di handle aperti per ogni file (singola immagine) supportati dalla condivisione file, in quanto potrebbe limitare il numero di utenti o applicazioni che è possibile supportare. Per altre informazioni, vedere Condivisione file.

Stato dell'applicazione

I pacchetti dell'applicazione vengono impostati come attivi o inattivi. I pacchetti impostati su attivo rendono l'applicazione disponibile agli utenti. I pacchetti impostati su inattivi vengono ignorati da Desktop virtuale Azure e non aggiunti quando un utente accede.

Un pacchetto MSIX è impostato come attivo o inattivo. I pacchetti MSIX impostati su attivo rendono l'applicazione disponibile agli utenti. I pacchetti MSIX impostati su inattivi vengono ignorati da Desktop virtuale Azure e non aggiunti quando un utente accede.

Nuove versioni delle applicazioni

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

  • Affiancato: creare una nuova applicazione usando la nuova immagine del disco e assegnarla agli stessi pool di host e utenti dell'applicazione esistente.

  • Sul posto: creare una nuova immagine in cui viene modificato il numero di versione dell'applicazione, quindi aggiornare l'applicazione esistente per usare la nuova immagine. Il numero di versione può essere superiore o inferiore, ma non è possibile aggiornare un'applicazione con lo stesso numero di versione. Non eliminare l'immagine esistente fino al termine dell'uso di tutti gli utenti.

Dopo l'aggiornamento, gli utenti riceveranno la versione aggiornata dell'applicazione al successivo accesso. Gli utenti non devono smettere di usare la versione precedente per aggiungere una nuova versione.

Nuove versioni delle applicazioni

Con MSIX App Attach è necessario eliminare il pacchetto dell'applicazione, quindi creare una nuova applicazione usando la nuova immagine del disco e assegnarla agli stessi pool di host. Non è possibile eseguire l'aggiornamento sul posto come si fa con App Attach. Gli utenti riceveranno la nuova immagine con l'applicazione aggiornata al successivo accesso. È consigliabile eseguire queste attività durante una finestra di manutenzione.

Provider di identità

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

Provider di identità Status
Microsoft Entra ID Supportata
Active Directory Domain Services (AD DS) Supportata
Microsoft Entra Domain Services Non supportato

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

Provider di identità Status
Microsoft Entra ID Non supportato
Active Directory Domain Services (AD DS) Supportata
Microsoft Entra Domain Services (Azure AD DS) Non supportato

Condivisione file

App Attach richiede che le immagini dell'applicazione vengano archiviate in una condivisione file SMB, che viene quindi montata in ogni host di sessione durante l'accesso. App Attach non ha dipendenze dal tipo di infrastruttura di archiviazione usato dalla condivisione file. È consigliabile usare File di Azure perché è compatibile con Microsoft Entra ID o Active Directory Domain Services e offre un ottimo valore tra costi e overhead di gestione.

È anche possibile usare Azure NetApp Files, ma richiede che gli host di sessione siano aggiunti a Active Directory Domain Services.

MSIX App Attach richiede che le immagini dell'applicazione vengano archiviate in una condivisione file SMB versione 3, che viene quindi montata in ogni host di sessione durante l'accesso. MSIX App Attach non ha dipendenze dal tipo di infrastruttura di archiviazione usato dalla condivisione file. È consigliabile usare File di Azure perché è compatibile con i provider di identità supportati che è possibile usare per MSIX App Attach e offre un ottimo valore tra costi e overhead di gestione. È anche possibile usare Azure NetApp Files, ma è necessario che gli host di sessione siano aggiunti a 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 le autorizzazioni NTFS e condividere per consentire a ogni oggetto computer host sessione l'accesso in lettura ai file e alla condivisione file. La configurazione dell'autorizzazione corretta dipende dal provider di archiviazione e dal provider di identità in uso per la condivisione file e gli host di sessione.

  • Per usare File di Azure dopo aver aggiunto gli host di sessione a Microsoft Entra ID, è necessario assegnare il ruolo di controllo degli accessi in base al ruolo di Azure di Lettore e accesso ai dati sia all'entità servizio di Desktop virtuale Azure che a quella del provider ARM di Desktop virtuale Azure. Questa assegnazione di ruolo controllo degli accessi in base al ruolo consente agli host di sessione di accedere all'account di archiviazione usando chiavi di accesso o Microsoft Entra.

  • Per informazioni su come assegnare un ruolo di controllo degli accessi in base al ruolo di Azure alle entità servizio di Desktop virtuale Azure, vedere Assegnare ruoli di controllo degli accessi in base al ruolo alle entità servizio di Desktop virtuale Azure. In un aggiornamento futuro non è necessario assegnare l'entità servizio del 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 delle opzioni di autenticazione basate sull'identità di File di Azure per l'accesso SMB.

    Avviso

    L'assegnazione dell'entità servizio del 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 solo le app da usare con App in questo account di archiviazione e ruotare regolarmente le chiavi di accesso.

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

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

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 le immagini di dimensioni maggiori, è necessario allocare più larghezza di banda. La tabella seguente fornisce un esempio dei requisiti di una singola immagine da 1 GB o di un pacchetto App-V contenente un'applicazione necessaria per ogni host di sessione:

Conto risorse Requisiti
Operazioni di I/O al secondo con stato stabile Un IOP
Accesso all'avvio del computer 10 operazioni di I/O al secondo
Latenza 400 ms

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 di sessione.

  • Escludere le immagini del disco contenenti le applicazioni dalle analisi antivirus perché sono di sola lettura.

  • Assicurarsi che l'archiviazione e l'infrastruttura di rete possano offrire prestazioni adeguate. È consigliabile evitare di usare la stessa condivisione file con i contenitori del profilo FSLogix.

Disponibilità

Tutti i piani di ripristino di emergenza per Desktop virtuale Azure devono includere la replica della condivisione file nel percorso di failover secondario. È anche necessario assicurarsi che il percorso della condivisione file sia accessibile nel percorso secondario. Ad esempio, è possibile usare spazi dei nomi File system distribuito (DFS) con File di Azure per fornire un singolo nome di condivisione tra condivisioni file differenti. 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 prevede limiti per il numero di handle aperti per directory radice, directory e file. Quando si usano App Attach o MSIX App Attach, le immagini del disco VHDX o CimFS vengono montate usando l'account computer dell'host sessione, per cui viene aperto un handle per ogni host di sessione per singola immagine del disco, anziché per utente. Per altre informazioni sui limiti e le linee guida sul ridimensionamento, vedere Obiettivi di scalabilità e prestazioni di File di Azure e Linee guida per il dimensionamento di File di Azure per Desktop virtuale Azure.

Certificati del pacchetto MSIX e Appx

Tutti i pacchetti MSIX e Appx richiedono un certificato di firma del codice valido. Per usare questi pacchetti con App Attach, è necessario assicurarsi che l'intera catena di certificati sia considerata attendibile negli host di sessione. Un certificato di firma del codice ha l'identificatore dell'oggetto 1.3.6.1.5.5.7.3.3. È possibile ottenere un certificato di firma del codice per i pacchetti da:

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

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

  • Uno strumento come il cmdlet di PowerShell New-SelfSignedCertificate che genera un certificato autofirmato. È consigliabile usare solo i certificati autofirmato in un ambiente di test. 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 lo Strumento MSIX Packaging 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 assicurarsi che il certificato sia attendibile negli host di sessione, è necessario che gli host di sessione considerino attendibile l'intera catena di certificati. Il modo in cui si esegue questa operazione dipende dalla posizione da cui è stato ottenuto il certificato e dal modo in cui si gestiscono gli host di sessione e il provider di identità usato. La tabella seguente fornisce alcune indicazioni su come assicurarsi che il certificato sia attendibile negli host di sessione:

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

  • Autorità di certificazione globale Enterprise 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 di denominazione della configurazione di Active Directory Domain Services. Quando Servizi certificati Active Directory è configurato come CA autonoma, è necessario configurare Criteri di gruppo per distribuire i certificati radice e intermedi agli host sessione. Per altre informazioni, vedere Distribuire i certificati ai dispositivi Windows tramite Criteri di gruppo.

    • Per gli host di sessione aggiunti all'ID Microsoft Entra, è possibile usare Microsoft Intune per distribuire i certificati radice e intermedi agli host di sessione. Per altre informazioni, vedere Profili certificato radice trusted per Microsoft Intune.

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

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

Importante

È necessario eseguire il timestamp del pacchetto in modo che la sua validità possa durare fino alla data di scadenza del certificato. In caso contrario, una volta scaduto il certificato, è necessario aggiornare il pacchetto con un nuovo certificato valido e verificare che sia attendibile negli host di sessione.

Passaggi successivi

Informazioni su come Aggiungere e gestire le applicazioni App Attach in Desktop virtuale Azure.