Condividi tramite

Prerequisiti per Desktop virtuale Azure

  • Articolo

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

A livello generale, sarà opportuno:

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

Account Azure con una sottoscrizione attiva

Per distribuire Desktop virtuale Azure, è necessario un account Azure con una sottoscrizione attiva. Se non se ne ha già uno, è possibile creare un account gratuitamente.

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

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

Importante

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

  1. Accedere al portale di Azure.

  2. Selezionare Sottoscrizioni.

  3. Selezionare il nome della sottoscrizione.

  4. Selezionare Provider di risorse.

  5. Cercare Microsoft.DesktopVirtualization.

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

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

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 gestione delle identità cloud centralizzato di Microsoft che consente tale 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 tramite Active Directory Domain Services o Microsoft Entra Domain Services, il che offre una scelta di opzioni di configurazione flessibili.

Host di sessione

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

Nota

Per Azure Stack HCI, è possibile aggiungere solo gli host di sessione a un dominio di Active Directory Domain Services. È possibile aggiungere host di sessione solo in Azure Stack HCI a un dominio Dominio di Active Directory Services (AD DS). Ciò include l'uso di Microsoft Entra hybrid join, in cui è possibile trarre vantaggio da alcune delle funzionalità fornite da Microsoft Entra ID.

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 in grado di 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 Host di sessione aggiunti a Microsoft Entra.

  • Per un dominio di Active Directory, è necessario un account di dominio in grado di aggiungere computer al dominio. Per Microsoft Entra Domain Services, è necessario essere membri del gruppo AAD DC Administrators.

Utenti

Gli utenti necessitano di account che si trovano in Microsoft Entra ID. Se si usano anche Active Directory Domain Services o Microsoft Entra Domain Services nella distribuzione di Desktop virtuale Azure, questi account devono essere identità ibride, il che significa che gli account utente sono sincronizzati. È necessario tenere presente quanto segue in base al provider di identità utilizzato:

  • Se si usa Microsoft Entra ID con Active Directory Domain Services, è necessario configurare Microsoft Entra Connect per sincronizzare i dati di identità utente tra Active Directory Domain Services e Microsoft Entra ID.
  • Se si usa Microsoft Entra ID con Microsoft Entra Domain Services, gli account utente vengono sincronizzati in un'unica direzione 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 utilizzato per Desktop virtuale Azure. Desktop virtuale Azure non supporta gli account B2B, B2Co personali di Microsoft.

Quando si utilizzano identità ibride, il nome dell'entità utente (UPN, UserPrincipalName) o l'ID di sicurezza (SID, Security Identifier) deve corrispondere tra Active Directory Domain Services e Microsoft Entra ID. Per altre informazioni, vedere Identità supportate e metodi di autenticazione.

Scenari di identità supportati

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

Scenario di gestione delle identità Host sessione Account utente
Utenti di Microsoft Entra ID e Active Directory Domain Services Aggiunto ad Active Directory Domain Services In Microsoft Entra ID e Active Directory Domain Services, sincronizzati
Utenti di Microsoft Entra ID e Active Directory Domain Services Aggiunto a Microsoft Entra ID In Microsoft Entra ID e Active Directory Domain Services, sincronizzati
Microsoft Entra ID e Microsoft Entra Domain Services Aggiunto a Microsoft Entra Domain Services In Microsoft Entra ID e Microsoft Entra Domain Services, sincronizzati
Microsoft Entra ID, Active Directory Domain Services e Microsoft Entra Domain Services Aggiunto a Microsoft Entra Domain Services In Microsoft Entra ID e Active Directory Domain Services, sincronizzati
Microsoft Entra ID e Microsoft Entra Domain Services Aggiunto a Microsoft Entra ID In Microsoft Entra ID e Microsoft Entra Domain Services, sincronizzati
Solo Microsoft Entra ID Aggiunto a Microsoft Entra ID In Microsoft Entra ID

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

Contenitore del profilo FSLogix

Per usare 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 di Contenitore di profili FSLogix con vari scenari di identità, vedere gli articoli seguenti:

Parametri di distribuzione

Quando si distribuiscono gli host di sessione, è necessario immettere i parametri di identità seguenti:

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

Importante

L'account usato per l'aggiunta a un dominio non può avere l'autenticazione a più fattori abilitata.

Sistemi operativi e licenze

Si dispone di una scelta di sistemi operativi (OS) che è possibile utilizzare per fornire desktop e applicazioni agli host di sessione. Per offrire flessibilità agli utenti, è possibile usare sistemi operativi diversi con pool di host differenti. I sistemi operativi e gli SKU a 64 bit sono supportati nelle 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 scopo commerciale:

Sistema operativo
(solo 64 bit)		 Metodo di licenza
(Scopi commerciali interni)		 Metodo di licenza
(Scopi commerciali esterni)
  • Microsoft 365 E3, E5, A3, A5, F3, Business Premium, Vantaggio Utilizzo da parte degli studenti
  • Windows Enterprise E3, E5
  • Windows Education A3, A5
  • Windows VDA per utente
  • Licenza CAL (Client Access License) di Servizi Desktop remoto (RDS) con Software Assurance (per utente o per dispositivo)
  • Licenze per le sottoscrizioni utente di Servizi Desktop remoto.
  • Licenza di accesso di sottoscrittore (SAL) Servizi Desktop remoto Windows Server 2022.

I prezzi di accesso per utente non sono disponibili per i sistemi operativi Windows Server.

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

Importante

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

In alternativa, per Azure Stack HCI è possibile utilizzare le immagini del sistema operativo da:

È possibile distribuire una macchina virtuale da usare come host di sessione da queste immagini con uno dei metodi seguenti:

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

Per gli host di sessione in Azure Stack HCI, è necessario concedere in licenza e attivare le macchine virtuali utilizzate, prima di usarle con Desktop virtuale Azure. Per attivare 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), è consigliabile continuare a utilizzare i metodi di attivazione esistenti. Per altre informazioni, vedere Attivare macchine virtuali Windows Server in Azure Stack HCI.

Nota

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

Suggerimento

Per semplificare i diritti di accesso utente durante lo sviluppo iniziale e il 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 la necessità di diritti di licenza separati, così da poter eseguire test di accettazione o fornire commenti e suggerimenti.

Rete

Esistono diversi requisiti di rete che è necessario soddisfare per distribuire correttamente Desktop virtuale Azure. In questo modo gli utenti si connettono ai desktop e alle applicazioni, ricevendo al tempo stesso la migliore esperienza utente possibile.

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

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

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

  • Se si usano Active Directory Domain Services o Microsoft Entra Domain Services, assicurarsi che questa rete virtuale possa connettersi ai controller di dominio e ai server DNS pertinenti, poiché è necessario aggiungere gli 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 utilizzano anche TCP sulla porta 443 per un elenco specifico di URL. Per altre informazioni, vedere Elenco di URL necessari. Affinché la distribuzione funzioni correttamente e sia supportata, occorre assicurarsi che questi URL non siano bloccati dal filtro di rete o da un firewall. Se gli utenti devono accedere a Microsoft 365, assicurarsi che gli host di sessione possano connettersi agli endpoint di Microsoft 365.

Tenere inoltre in considerazione quanto segue:

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

  • La latenza 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 località hanno la latenza migliore, cercare la posizione desiderata nelle Statistiche sulla latenza round trip della rete di Azure. Per ottimizzare le prestazioni di rete, è consigliabile creare gli host di sessione nell'area di Azure più vicina agli utenti.

  • Usare 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 l'apertura di una porta in ingresso. Se è necessario aprire la porta 3389 per la risoluzione dei problemi, è consigliabile usare l'accesso Just-In-Time alla VM. È 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 affidabile e scalabile Desktop virtuale Azure, aggreghiamo i modelli di traffico e utilizzo 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 del servizio, quindi le inviamo all'area degli Stati Uniti. I dati inviati all'area degli Stati Uniti includono i dati eliminati, ma non quelli dei clienti. Per altre informazioni, vedere Percorsi dei dati per Desktop virtuale Azure.

Gestione host sessione

Quando si gestiscono gli host di sessione, tenere presente quanto segue:

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

  • Se si aggiungono host di sessione a un dominio di Active Directory Domain Services e si vuole gestirli tramite Intune, è necessario configurare Microsoft Entra Connect per abilitare l'aggiunta ibrida a Microsoft Entra.

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

  • Se si utilizza il join di Microsoft Entra con Windows Server per gli host di sessione, non è possibile registrarli in Intune perché Windows Server non è supportato da Intune. È necessario usare il join ibrido di Microsoft Entra e i Criteri di gruppo da un dominio di Active Directory oppure 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 seguenti aree di Azure. Questo elenco di aree è la posizione in cui è possibile archiviare i metadati per il pool di host. Tuttavia, gli host di sessione per le sessioni utente possono trovarsi in qualsiasi area di Azure e in locale quando si utilizza Desktop virtuale Azure in Azure Stack HCI, consentendo di distribuire risorse di calcolo vicine agli utenti. Per altre informazioni sui tipi di dati e posizioni, vedere Posizioni dei dati per Desktop virtuale Azure.

  • Australia orientale
  • Canada centrale
  • Canada orientale
  • India centrale
  • Stati Uniti centrali
  • Stati Uniti orientali
  • Stati Uniti orientali 2
  • Giappone orientale
  • Stati Uniti centro-settentrionali
  • Europa settentrionale
  • Stati Uniti centro-meridionali
  • Regno Unito meridionale
  • Regno Unito occidentale
  • Stati Uniti centro-occidentali
  • Europa occidentale
  • Stati Uniti occidentali
  • West US 2
  • Stati Uniti occidentali 3

Desktop virtuale Azure è disponibile anche nei 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.

Client Desktop remoto

Gli utenti necessitano di un client Desktop remoto per connettersi a desktop e applicazioni. I client seguenti supportano Desktop virtuale Azure:

Importante

Desktop virtuale Azure non supporta le connessioni dal client RemoteApp e Desktop Connections (RADC) o dal client MSTSC (Remote Desktop Connection).

Per informazioni sugli URL usati per connettersi e che è necessario consentire tramite firewall e filtri Internet, vedere Elenco di URL necessari.

Passaggi successivi