Prerequisiti per Desktop virtuale Azure

È necessario iniziare a usare Desktop virtuale Azure per alcune cose. Qui è possibile trovare i prerequisiti che è necessario completare per fornire agli utenti desktop e applicazioni.

A livello generale, è necessario:

  • Un account Azure con una sottoscrizione attiva
  • Un provider di identità supportato
  • Un sistema operativo supportato per le macchine virtuali host sessione
  • Licenze appropriate
  • Connettività di rete
  • Un client desktop remoto

Account di Azure con una sottoscrizione attiva

Per distribuire Desktop virtuale Azure è necessario un account di Azure con una sottoscrizione attiva. Se non si ha già un account, è possibile crearne uno gratuitamente.

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

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

Importante

È necessario disporre dell'autorizzazione per registrare un provider di risorse, che richiede l'operazione di */register/action. Questa opzione è inclusa se all'account è assegnato il ruolo di collaboratore o proprietario nella sottoscrizione.

  1. Accedere al portale di Azure.

  2. Seleziona Abbonamenti.

  3. Seleziona il nome dell'abbonamento.

  4. Selezionare Provider di risorse.

  5. Cercare Microsoft.DesktopVirtualization.

  6. Se lo stato è NotRegistered, selezionare Microsoft.DesktopVirtualization, quindi selezionare Register.

  7. Verificare che lo stato di Microsoft.DesktopVirtualization sia registrato.

Identità

Per accedere a desktop e applicazioni dagli host di 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 Desktop virtuale Azure. Gli host di sessione possono essere aggiunti allo stesso tenant di 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 di Microsoft Entra degli utenti o a un dominio Active Directory (AD DS o Microsoft Entra Domain Services).

Nota

Per Azure Localee, è possibile aggiungere solo host di sessione a un dominio di Active Directory Domain Services. È possibile aggiungere solo host sessione in Azure locale a un dominio di Active Directory Domain Services (AD DS). Ciò include l'utilizzo dell'unione ibrida Microsoft Entra, dove è possibile beneficiare di alcune delle funzionalità fornite da Microsoft Entra ID.

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

Utenti

Gli utenti devono avere account in Microsoft Entra ID. Se si usa anche Servizi di dominio Active Directory o Microsoft Entra Domain Services nella distribuzione di Desktop virtuale di Azure, questi account devono essere identità ibride e cioè sincronizzati. In base al provider di identità utilizzato, è necessario tenere presente quanto segue:

  • Se si usa Microsoft Entra ID con Servizi di dominio Active Directory, è necessario configurare Microsoft Entra Connect per sincronizzare i dati relativi all'identità degli utenti 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 modo unidirezionale da Microsoft Entra ID a Microsoft Entra Domain Services. Questo processo di sincronizzazione è automatico.

Importante

L'account utente deve esistere nel tenant di Microsoft Entra usato per Desktop virtuale Azure. Desktop virtuale Azure non supporta gli account Microsoft personali.

Quando si usano identità ibride, UserPrincipalName (UPN) o l'identificatore di sicurezza (SID) deve corrispondere tra Active Directory Domain Services e Microsoft Entra ID. Per ulteriori informazioni, consulta Identità e metodi di autenticazione supportati.

Scenari di identità supportati

Nella tabella seguente sono riepilogati gli scenari di identità attualmente supportati da Desktop virtuale Azure:

Scenario di identità Host sessione Account utente
Microsoft Entra ID + AD DS Aggiunta ad Active Directory Domain Services In Microsoft Entra ID e AD DS, sincronizzato
Microsoft Entra ID + AD DS Aggiunto a Microsoft Entra ID In Microsoft Entra ID e AD DS, sincronizzato
Microsoft Entra ID + Microsoft Entra Domain Services Aggiunta a Microsoft Entra Domain Services In Microsoft Entra ID e Microsoft Entra Domain Services, sincronizzato
Microsoft Entra ID + Microsoft Entra Domain Services + AD DS Aggiunta a Microsoft Entra Domain Services In Microsoft Entra ID e AD DS, sincronizzato
Microsoft Entra ID + Microsoft Entra Domain Services Aggiunto a Microsoft Entra ID In Microsoft Entra ID e Microsoft Entra Domain Services, sincronizzato
Solo Microsoft Entra Aggiunto a Microsoft Entra ID In Microsoft Entra ID (incluse le identità esterne)

Per informazioni più dettagliate sugli scenari di identità supportati, tra cui l'autenticazione Single Sign-on e multifattore, vedere Identità e metodi di autenticazione supportati.

Contenitore di profili FSLogix

Per usare il contenitore di profili FSLogix quando si uniscono gli 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 Servizi di dominio Active Directory 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:

Parametri di distribuzione

È necessario immettere i seguenti parametri di identità durante la distribuzione degli host di sessione:

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

Importante

Per l'account usato per l'aggiunta a un dominio non può essere abilitata l'autenticazione a più fattori (MFA).

Sistemi operativi e licenze

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

Sistema operativo
(Solo 64 bit)
Metodo di gestione delle licenze
(Scopi commerciali interni)
Metodo di gestione delle licenze
(Finalità commerciali esterne)
  • Microsoft 365 E3, E5, A3, A5, F3, Business Premium, Student Use Benefit
  • Windows Enterprise E3, E5
  • Windows Education A3, A5
  • Windows VDA per utente
Prezzi dell'accesso per utente registrando una sottoscrizione di Azure.
  • Licenza CAL (Client Access License) di Servizi Desktop remoto (RDS) con Software Assurance (per utente o per dispositivo)
  • Licenze di sottoscrizione utente di Servizi Desktop remoto.
Non supportate. Il prezzo dell'accesso per utente non è disponibile per i sistemi operativi Windows Server.

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

Importante

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

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

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

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

Per gli host di sessione in Azure locale, è necessario concedere in licenza e attivare le macchine virtuali usate prima di usarle con Desktop virtuale di Azure. Per l'attivazione di Windows 10 e Windows 11 Enterprise multisessione e Windows Server 2022 Datacenter: Azure Edition, usare la verifica di 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), dovresti continuare a usare i metodi di attivazione esistenti. Per altre informazioni, vedere Attivare macchine virtuali Windows Server in Azure locale.

Nota

Per garantire la continuità delle funzionalità con l'ultimo aggiornamento della sicurezza, aggiornare le macchine virtuali in Azure Localee all'ultimo aggiornamento cumulativo entro il 17 giugno 2024. Questo aggiornamento è essenziale per consentire alle macchine virtuali di continuare a usare i vantaggi di Azure. Per altre informazioni, vedere Verifica di Azure per le macchine virtuali.

Consiglio

Per semplificare i diritti di accesso degli utenti durante le fasi iniziali di sviluppo e test, Desktop virtuale Azure supporta i prezzi di sviluppo/test di Azure. Se si distribuisce Desktop virtuale Azure in una sottoscrizione di sviluppo/test di Azure, gli utenti finali possono connettersi a tale distribuzione senza diritti di licenza distinti per eseguire test di accettazione o fornire feedback.

Rete

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

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

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

  • Sono necessarie una rete virtuale e una subnet per gli host di sessione. Se si creano gli host di 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 di Azure dell'host della sessione.

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

  • Gli host e gli utenti della sessione devono essere in grado di connettersi al servizio Desktop virtuale di Azure. Queste connessioni utilizzano 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 da filtri 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 della sessione possano connettersi agli endpoint di Microsoft 365.

Tenere inoltre presenti gli aspetti seguenti:

  • Gli utenti potrebbero avere la necessità di accedere ad applicazioni e dati ospitati su reti diverse, quindi assicurarsi che gli host di sessione possano connettersi a loro.

  • La latenza del tempo di round trip (RTT) dalla rete del client all'area di Azure che contiene i pool di host deve essere inferiore a 150 ms. Per vedere quali sono le posizioni con la latenza migliore, cercare la posizione desiderata nelle statistiche sulla latenza di andata e ritorno della rete di Azure. Per ottimizzare le prestazioni di rete, è consigliabile creare host sessione nell'area di Azure più vicina agli utenti.

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

  • Per proteggere l'ambiente di Desktop virtuale Azure in Azure, è consigliabile non aprire la porta 3389 in ingresso negli host di sessione. Desktop virtuale Azure non richiede che una porta in ingresso aperta sia aperta. Se è necessario aprire la porta 3389 a scopo di risoluzione dei problemi, è consigliabile usare l'accesso JIT alla macchina virtuale. È 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.

Nota

Per mantenere Desktop virtuale Azure affidabile e scalabile, vengono aggregati i modelli e l'utilizzo del traffico per controllare l'integrità e le prestazioni del piano di controllo dell'infrastruttura. Queste informazioni vengono aggregate da tutte le posizioni in cui si trova l'infrastruttura di servizio, quindi le inviamo all'area geografica degli Stati Uniti. I dati inviati all'area geografica degli Stati Uniti includono i dati eliminati, ma non i dati dei clienti. Per altre informazioni, vedere Percorsi dei dati per Desktop virtuale Azure.

Gestione dell'host sessione

Quando si gestiscono gli host di sessione, tenere presenti 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 di sessione e gli host di sessione non funzioneranno correttamente.

  • Se si aggiungono host di sessione a un dominio di Servizi di dominio Active Directory e si desidera gestirli con Intune, è necessario configurare Microsoft Entra Connect per abilitare l'accesso ibrido a Microsoft Entra.

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

  • Se si usa l'aggiunta a Microsoft Entra con Windows Server per gli host di sessione, non è possibile registrarli in Intune perché Windows Server non è supportato con Intune. È necessario usare l'unione ibrida e i Criteri di gruppo di Microsoft Entra da un dominio Active Directory o i Criteri di gruppo locali in ogni host di sessione.

Aree di Azure

È possibile distribuire pool di host, aree di lavoro e gruppi di applicazioni nelle aree di Azure seguenti. Questo elenco di aree è la posizione in cui è possibile archiviare i metadati per il pool di host quando l'ambito di distribuzione del pool di host è geografico.

Vedere Percorsi dati per Desktop virtuale Azure per l'elenco delle aree per l'archiviazione dei metadati del pool di host quando l'ambito di distribuzione del pool di host è regionale.

Tuttavia, gli host di sessione per le sessioni utente possono essere ubicati in qualsiasi area di Azure e in locale quando si usa Desktop virtuale di Azure in locale di Azure, consentendo di distribuire risorse di calcolo vicino agli utenti. Per altre informazioni sui tipi di dati e posizioni, vedere Percorsi dei dati per Desktop virtuale Azure.

Importante

West US 3 non è supportato per i pool host automatizzati (pool host che usano la configurazione host sessione). Altre informazioni sulla configurazione dell'host sessione negli approcci di gestione del pool di host.

  • Australia orientale

  • Canada centrale

  • Canada orientale

  • India centrale

  • Stati Uniti centrali

  • Asia orientale

  • Stati Uniti orientali

  • Stati Uniti orientali 2

  • Giappone orientale

  • Giappone occidentale

  • Stati Uniti centro-settentrionali

  • Europa settentrionale

  • Sudafrica settentrionale

  • Stati Uniti centro-meridionali

  • Asia sudorientale

  • Regno Unito meridionale

  • Regno Unito orientale

  • Stati Uniti centro-occidentali

  • Europa occidentale

  • Stati Uniti occidentali

  • Stati Uniti occidentali 2

  • Stati Uniti occidentali 3

Desktop virtuale Azure è 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 Architettura e resilienza del servizio Desktop virtuale Azure.

Connessione a una sessione remota

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

  • Windows
  • macOS
  • iOS/iPadOS
  • Android/Chrome OS
  • Web browser

Per ulteriori informazioni, vedi Introduzione all'app di app di Windows per connetterti a dispositivi e app.

Importante

Desktop virtuale Azure non supporta le connessioni dal client RemoteApp and Desktop Connections (RADC) o dal client Connessione Desktop remoto (MSTSC).

Per sapere quali URL usano i client per connettersi e quali URL è necessario consentire tramite firewall e filtri Internet, vedere l'elenco URL obbligatori.

Passaggi successivi