Prerequisiti per Azure Desktop virtuale

È necessario iniziare a usare Azure Desktop virtuale. Qui è possibile trovare i prerequisiti necessari per fornire correttamente agli utenti desktop e applicazioni.

A livello generale, è necessario:

Azure account con una sottoscrizione attiva

È necessario un account Azure con una sottoscrizione attiva per distribuire Azure Desktop virtuale. Se non ne hai già uno, puoi creare un account gratuitamente.

Per distribuire Azure Desktop virtuale, è necessario assegnare i ruoli pertinenti Azure controllo degli accessi in base al ruolo. I requisiti specifici del ruolo sono illustrati in ognuno degli articoli correlati per la distribuzione Azure Desktop virtuale, elencati nella sezione Passaggi successivi.

Assicurarsi anche di aver registrato il provider di risorse Microsoft.DesktopVirtualization per la sottoscrizione. Per controllare lo stato del provider di risorse e registrarsi, se necessario, selezionare la scheda pertinente per lo scenario e seguire la procedura.

Identità

Per accedere a desktop e applicazioni dagli host sessione, gli utenti devono essere in grado di eseguire l'autenticazione. Microsoft Entra ID è il servizio di identità cloud centralizzato di Microsoft che abilita questa funzionalità. Microsoft Entra ID viene sempre usato per autenticare gli utenti per Azure Desktop virtuale. Gli host di sessione possono essere aggiunti allo stesso tenant Microsoft Entra o a un dominio di Active Directory usando Active Directory Domain Services (AD DS) o Microsoft Entra Domain Services, offrendo una scelta di opzioni di configurazione flessibili.

Host sessione

È necessario aggiungere host di sessione che forniscono desktop e applicazioni allo stesso tenant Microsoft Entra degli utenti o a un dominio di Active Directory (AD DS o Microsoft Entra Domain Services).

Per aggiungere host di sessione a Microsoft Entra ID o a un dominio di Active Directory, sono necessarie le autorizzazioni seguenti:

• Per Microsoft Entra ID, è necessario un account che possa aggiungere computer al tenant. Per altre informazioni, vedere Gestire le identità dei dispositivi. Per altre informazioni sull'aggiunta di host di sessione a Microsoft Entra ID, vedere Microsoft Entra host sessione aggiunti.

• Per un dominio di Active Directory, è necessario un account di dominio che possa aggiungere computer al dominio. Per Microsoft Entra Domain Services, è necessario essere un membro del gruppo Amministratori del controller di dominio AAD.

Utenti

Gli utenti hanno bisogno di account in Microsoft Entra ID. Se si usa anche Servizi di dominio Active Directory o Microsoft Entra Domain Services nella distribuzione di desktop virtuale Azure, questi account devono essere identità ibride, ovvero gli account utente sono sincronizzati. È necessario tenere presente quanto segue in base al provider di identità usato:

• Se si usa Microsoft Entra ID con Active Directory Domain Services, è necessario configurare Microsoft Entra Connetti per sincronizzare i dati delle identità utente tra Servizi di dominio Active Directory e Microsoft Entra ID.
• Se si usa Microsoft Entra ID con Microsoft Entra Domain Services, gli account utente vengono sincronizzati in un modo da Microsoft Entra ID a Microsoft Entra Domain Services. Questo processo di sincronizzazione è automatico.

Scenari di identità supportati

La tabella seguente riepiloga gli scenari di identità attualmente supportati da Desktop virtuale Azure:

Per informazioni più dettagliate sugli scenari di identità supportati, tra cui l'accesso Single Sign-On e l'autenticazione a più fattori, vedere Identità supportate e metodi di autenticazione.

Contenitore profili FSLogix

Per usare il contenitore di profili FSLogix durante l'aggiunta degli host di sessione a Microsoft Entra ID, è necessario archiviare i profili in File di Azure o Azure NetApp Files e gli account utente devono essere identità ibride. È necessario creare questi account in Active Directory Domain Services e sincronizzarli con Microsoft Entra ID. Per altre informazioni sulla distribuzione del contenitore di profili FSLogix con scenari di identità diversi, vedere gli articoli seguenti:

• Configurare il contenitore di profili FSLogix con File di Azure e Active Directory Domain Services o Microsoft Entra Domain Services.
• Configurare il contenitore di profili FSLogix con File di Azure e Microsoft Entra ID.
• Configurare il contenitore di profili FSLogix con Azure NetApp Files

Parametri di distribuzione

Quando si distribuiscono gli host sessione, è necessario immettere i parametri identity seguenti:

• Nome di dominio, se si usa Servizi di dominio Active Directory o Microsoft Entra Domain Services.
• Credenziali per aggiungere host di sessione al dominio.
• Unità organizzativa (OU), che è un parametro facoltativo che consente di inserire gli host di sessione nell'unità organizzativa desiderata in fase di distribuzione.

Sistemi operativi e licenze

È possibile scegliere tra i sistemi operativi che è possibile usare per gli host di sessione per fornire desktop e applicazioni. È possibile usare sistemi operativi diversi con pool di host diversi per offrire flessibilità agli utenti. I sistemi operativi e gli SKU a 64 bit sono supportati negli elenchi di tabelle seguenti (in cui le versioni e le date supportate sono in linea con i criteri relativi al ciclo di vita di Microsoft), insieme ai metodi di licenza applicabili per ogni scopo commerciale:

Per altre informazioni sulle licenze che è possibile usare, inclusi i prezzi di accesso per utente, vedere Licenze Azure Desktop virtuale.

Per Azure, è possibile usare le immagini del sistema operativo fornite da Microsoft nel Marketplace Azure oppure creare immagini personalizzate archiviate in una raccolta di calcolo Azure o come immagine gestita. L'uso di modelli di immagine personalizzati per Azure Desktop virtuale consente di creare facilmente un'immagine personalizzata che è possibile usare durante la distribuzione di macchine virtuali (VM) dell'host sessione. Per altre informazioni su come creare immagini personalizzate, vedere:

• Modelli di immagine personalizzati in Desktop virtuale Azure
• Archiviare e condividere immagini in una raccolta di calcolo Azure.
• Creare un'immagine gestita di una macchina virtuale generalizzata in Azure.

In alternativa, per Azure Localee è possibile usare immagini del sistema operativo da:

• Azure Marketplace. Per altre informazioni, vedere Creare un'immagine di macchina virtuale Azure Localee usando Azure immagini del Marketplace.
• Azure account di archiviazione. Per altre informazioni, vedere Creare Azure Localee'immagine della macchina virtuale usando l'immagine nell'account di archiviazione Azure.
• Una condivisione locale. Per altre informazioni, vedere Creare Azure Localee'immagine della macchina virtuale usando immagini in una condivisione locale.

È possibile distribuire macchine virtuali (VM) da usare come host di sessione da queste immagini con uno dei metodi seguenti:

• Automaticamente, come parte del processo di installazione del pool di host nel portale di Azure.
• Manualmente aggiungendo host di sessione a un pool di host esistente nel portale di Azure.
• A livello di codice, con Azure'interfaccia della riga di comando o Azure PowerShell.

Se la licenza consente di usare Azure Desktop virtuale, non è necessario installare o applicare una licenza separata, tuttavia se si usano prezzi di accesso per utente per utenti esterni, è necessario registrare una sottoscrizione Azure. È necessario assicurarsi che la licenza di Windows usata negli host sessione sia assegnata correttamente in Azure e che il sistema operativo sia attivato. Per altre informazioni, vedere Applicare la licenza di Windows alle macchine virtuali dell'host di sessione.

Per gli host di sessione in Azure Localee, è necessario concedere in licenza e attivare le macchine virtuali usate prima di usarle con Azure Desktop virtuale. Per attivare Windows 10 e Windows 11 Enterprise multisessione e Windows Server 2022 Datacenter: Azure Edition, usare la verifica Azure per le macchine virtuali. Per tutte le altre immagini del sistema operativo, ad esempio Windows 10 e Windows 11 Enterprise e altre edizioni di Windows Server, è consigliabile continuare a usare i metodi di attivazione esistenti. Per altre informazioni, vedere Attivare le macchine virtuali Windows Server in Azure Localee.

Rete

Esistono diversi requisiti di rete che è necessario soddisfare per distribuire correttamente Azure Desktop virtuale. Ciò consente agli utenti di connettersi ai desktop e alle applicazioni, offrendo al tempo stesso la migliore esperienza utente possibile.

Gli utenti che si connettono a Azure Desktop virtuale stabiliscono in modo sicuro una connessione inversa al servizio, il che significa che non è necessario aprire porte in ingresso. Il protocollo TCP (Transmission Control Protocol) sulla porta 443 viene usato per impostazione predefinita, tuttavia il percorso breve RDP può essere usato per le reti gestite e le reti pubbliche che stabiliscono un trasporto diretto basato su UDP (User Datagram Protocol).

Per distribuire correttamente Azure Desktop virtuale, è necessario soddisfare i requisiti di rete seguenti:

• Sono necessari una rete virtuale e una subnet per gli host di sessione. Se si creano gli host sessione contemporaneamente a un pool di host, è necessario creare questa rete virtuale in anticipo affinché venga visualizzata nell'elenco a discesa. La rete virtuale deve trovarsi nella stessa area Azure dell'host della sessione.

• Assicurarsi che questa rete virtuale possa connettersi ai controller di dominio e ai server DNS pertinenti se si usa Servizi di dominio Active Directory o Microsoft Entra Domain Services, poiché è necessario aggiungere host di sessione al dominio.

• Gli host di sessione e gli utenti devono essere in grado di connettersi al servizio Desktop virtuale Azure. Queste connessioni usano anche TCP sulla porta 443 per un elenco specifico di URL. Per altre informazioni, vedere Elenco URL obbligatori. È necessario assicurarsi che questi URL non siano bloccati dal filtro di rete o da un firewall affinché la distribuzione funzioni correttamente e sia supportata. Se gli utenti devono accedere a Microsoft 365, assicurarsi che gli host sessione possano connettersi agli endpoint di Microsoft 365.

Considerare anche quanto segue:

• Gli utenti potrebbero avere bisogno di accedere ad applicazioni e dati ospitati in reti diverse, quindi assicurarsi che gli host sessione possano connettersi a tali applicazioni.

• La latenza RTT (Round Trip Time) dalla rete del client all'area Azure che contiene i pool host deve essere inferiore a 150 ms. Per vedere quali posizioni hanno la latenza migliore, cercare la posizione desiderata in Azure statistiche di latenza di round trip di rete. Per ottimizzare le prestazioni di rete, è consigliabile creare host di sessione nell'area Azure più vicina agli utenti.

• Usare Firewall di Azure per Azure distribuzioni di Desktop virtuale per bloccare l'ambiente e filtrare il traffico in uscita.

• Per proteggere l'ambiente desktop virtuale Azure in Azure, è consigliabile non aprire la porta in ingresso 3389 negli host sessione. Azure Desktop virtuale non richiede l'apertura di una porta in ingresso aperta. Se è necessario aprire la porta 3389 per la risoluzione dei problemi, è consigliabile usare l'accesso ji-in-time alle macchine virtuali. È anche consigliabile non assegnare un indirizzo IP pubblico agli host di sessione.

Per altre informazioni, vedere Informazioni sulla connettività di rete di Desktop virtuale Azure.

Gestione host sessione

Quando si gestiscono gli host di sessione, considerare i punti seguenti:

• Non abilitare criteri o configurazioni che disabilitano Windows Installer. Se disabiliti Windows Installer, il servizio non può installare gli aggiornamenti dell'agente negli host sessione e gli host di sessione non funzioneranno correttamente.

• Se si aggiunge host di sessione a un dominio di Active Directory Domain Services e si vuole gestirli usando Intune, è necessario configurare Microsoft Entra Connect per abilitare Microsoft Entra join ibrido.

• Se si aggiunge host di sessione a un dominio Microsoft Entra Domain Services, non è possibile gestirli usando Intune.

• Se si usa Microsoft Entra partecipare con Windows Server per gli host sessione, non è possibile registrarli in Intune perché Windows Server non è supportato con Intune. È necessario usare Microsoft Entra join ibrido e Criteri di gruppo da un dominio di Active Directory o Criteri di gruppo locale in ogni host sessione.

aree Azure

È possibile distribuire pool di host, aree di lavoro e gruppi di applicazioni nelle aree di Azure seguenti. In questo elenco di aree è possibile archiviare i metadati per il pool di host. Tuttavia, gli host sessione per le sessioni utente possono trovarsi in qualsiasi area Azure e in locale quando si usa Azure Desktop virtuale in Azure Localee, consentendo di distribuire risorse di calcolo vicine agli utenti. Per altre informazioni sui tipi di dati e posizioni, vedere Percorsi dei dati per Azure Desktop virtuale.

Azure Desktop virtuale è disponibile anche in cloud sovrani, ad esempio Azure per il governo degli Stati Uniti e Azure gestito da 21Vianet in Cina.

Per altre informazioni sull'architettura e la resilienza del servizio Desktop virtuale Azure, vedere Azure architettura e resilienza del servizio Desktop virtuale.

Connessione a una sessione remota

Gli utenti devono usare app di Windows o il client Desktop remoto per connettersi a desktop e applicazioni. È possibile connettersi da:

• Windows
• macOS
• iOS/iPadOS
• Sistema operativo Android/Chrome
• Web browser

Per altre informazioni, vedere Introduzione a app di Windows per connettersi a dispositivi e app.

Per informazioni sugli URL usati dai client per la connessione e che è necessario consentire tramite firewall e filtri Internet, vedere l'elenco URL obbligatori.

Passaggi successivi

• Quando si è pronti per provare Azure Desktop virtuale, usare la guida introduttiva per distribuire un ambiente desktop virtuale di esempio Azure con Windows 11 Enterprise multisessione.

• Per un approccio più approfondito e adattabile alla distribuzione Azure Desktop virtuale, vedere Distribuire Azure Desktop virtuale.