Topologia di rete e connettività per Desktop virtuale Azure

La progettazione e l'implementazione delle funzionalità di rete di Azure in Desktop virtuale Azure è fondamentale per la zona di destinazione di Desktop virtuale Azure. Questo articolo si basa su diversi principi architetturali e raccomandazioni per la gestione della topologia di rete e della connettività su larga scala di Cloud Adoption Framework per le aree di destinazione su scala aziendale.

Le basi di progettazione includono:

• Integrazione ibrida per la connettività tra ambienti locali, multicloud e perimetrali e utenti globali. Per altre informazioni, vedere Supporto di livello aziendale per ambienti ibridi e multi-cloud.
• Prestazioni e affidabilità su larga scala per un'esperienza coerente, a bassa latenza e scalabilità per i carichi di lavoro.
• Sicurezza di rete basata su zero attendibilità per proteggere i perimetri di rete e i flussi di traffico. Per altre informazioni, vedere Strategie per la sicurezza della rete in Azure.
• Estendibilità per espandere facilmente un footprint di rete senza rielaborare la progettazione.

Componenti e concetti relativi alla rete

• Rete virtuale di Azure rappresenta il blocco costitutivo delle reti private in Azure. Con Rete virtuale, molti tipi di risorse di Azure, ad esempio Azure Macchine virtuali, possono comunicare tra loro, Internet e data center locali. Una rete virtuale è simile a una rete tradizionale che si opera nel proprio data center. Tuttavia, una rete virtuale offre i vantaggi dell'infrastruttura di Azure per scalabilità, disponibilità e isolamento.
• Una topologia di rete hub-spoke è un tipo di architettura di rete in cui una rete virtuale hub funge da punto centrale di connettività a diverse reti virtuali spoke. L'hub può anche essere la posizione per la connettività ai data center locali. Peering delle reti virtuali spoke con l'hub e consente di isolare i carichi di lavoro.
• Azure rete WAN virtuale è un servizio di rete che riunisce funzioni di rete, sicurezza e routing in un'unica interfaccia operativa.
• Un'appliance virtuale di rete è un dispositivo di rete che supporta funzioni quali connettività, distribuzione di applicazioni, ottimizzazione della rete WAN (Wide Area Network) e sicurezza. Le appliance virtuali di rete includono Firewall di Azure e Azure Load Balancer.
• In uno scenario di tunneling forzato, tutto il traffico associato a Internet che ha origine nelle macchine virtuali di Azure viene instradato o forzato per eseguire un'ispezione e un'appliance di controllo. L'accesso a Internet non autorizzato può potenzialmente causare la divulgazione di informazioni o altri tipi di violazioni della sicurezza senza l'ispezione o il controllo del traffico.
• I gruppi di sicurezza di rete vengono usati per filtrare il traffico di rete da e verso le risorse di Azure in una rete virtuale di Azure. Un gruppo di sicurezza di rete contiene regole di sicurezza che consentono o rifiutano il traffico di rete in ingresso o in uscita da diversi tipi di risorse di Azure.
• I gruppi di sicurezza delle applicazioni consentono di configurare la sicurezza di rete come estensione naturale della struttura di un'applicazione. È possibile usare i gruppi di sicurezza delle applicazioni per raggruppare le macchine virtuali e definire criteri di sicurezza di rete basati su tali gruppi. È possibile riutilizzare i criteri di sicurezza su larga scala senza dover gestire manualmente gli indirizzi IP espliciti.
• Le route definite dall'utente possono essere usate per eseguire l'override delle route di sistema predefinite di Azure. È anche possibile usare le route definite dall'utente per aggiungere route aggiuntive a una tabella di route della subnet.
• Remote Desktop Protocol Shortpath (RDP Shortpath) è una funzionalità di Desktop virtuale Azure basata su UNIVERSAL Rate Control Protocol (URCP). RDP Shortpath stabilisce un trasporto diretto basato sul protocollo UDP (User Datagram Protocol) tra un client Desktop remoto Di Windows supportato e gli host sessione di Desktop virtuale Azure. URCP migliora le connessioni UDP fornendo il monitoraggio attivo delle condizioni di rete e delle funzionalità QoS (Quality of Service).
• collegamento privato di Azure con Desktop virtuale Azure (anteprima) consente di usare un endpoint privato in Azure per connettere gli host di sessione al servizio Desktop virtuale Azure. Con collegamento privato, il traffico tra la rete virtuale e il servizio Desktop virtuale Azure passa sulla rete backbone Microsoft. Di conseguenza, non è necessario connettersi a Internet pubblico per accedere ai servizi Desktop virtuale Azure.

Scenari di rete

Per stabilire la zona di destinazione di Desktop virtuale Azure, la progettazione e l'implementazione delle funzionalità di rete è fondamentale. I prodotti e i servizi di rete di Azure supportano un'ampia gamma di funzionalità. L'architettura scelta e il modo in cui si strutturano i servizi dipendono dai carichi di lavoro, dalla governance e dai requisiti dell'organizzazione.

I requisiti e le considerazioni chiave seguenti influiscono sulle decisioni relative alla distribuzione di Desktop virtuale Azure:

• Requisiti di ingresso e uscita internet.
• L'appliance virtuale di rete viene usata nell'architettura corrente.
• Connettività di Desktop virtuale Azure a una rete virtuale hub standard o a un hub rete WAN virtuale.
• Modello di connessione host sessione. È possibile usare un modello nativo o RDP Shortpath.
• Requisiti di ispezione del traffico per:
  • Uscita Internet da Desktop virtuale Azure.
  • Ingresso Internet in Desktop virtuale Azure.
  • Traffico di Desktop virtuale Azure verso data center locali.
  • Traffico di Desktop virtuale Azure ad altre istanze di Rete virtuale.
  • Traffico all'interno della rete virtuale Desktop virtuale Azure.

Lo scenario di rete più comune per Desktop virtuale Azure è una topologia hub-spoke con connettività ibrida.

Scenario 1: Hub e spoke con connettività ibrida

Questo scenario usa il modello di connessione host sessione standard.

Profilo cliente

Questo scenario è ideale nei casi seguenti:

• Non è necessaria l'ispezione del traffico tra reti Desktop virtuale Azure e altre reti virtuali di Azure.
• Non è necessaria l'ispezione del traffico tra le reti di Desktop virtuale Azure e i data center locali.
• Non è necessaria l'ispezione del traffico del traffico in uscita da reti Desktop virtuale Azure.
• Non è necessario controllare gli indirizzi IP pubblici usati durante la conversione degli indirizzi di rete di origine (SNAT) per le connessioni Internet in uscita di Desktop virtuale Azure.
• Non si applica il traffico interno della rete di Desktop virtuale Azure.
• Si dispone di connettività ibrida preesistente agli ambienti locali, tramite Azure ExpressRoute o una rete privata virtuale da sito a sito (VPN).
• Sono presenti server personalizzati Dominio di Active Directory Services (AD DS) e DNS (Domain Name System) preesistenti.
• Desktop virtuale Azure viene usato usando un modello di connessione standard, non RDP Shortpath.

Componenti dell'architettura

È possibile implementare questo scenario con:

• Server Active Directory Domain Services e server DNS personalizzati.
• Gruppi di sicurezza di rete.
• Azure Network Watcher.
• Internet in uscita tramite un percorso di rete virtuale di Azure predefinito.
• ExpressRoute o un gateway di rete virtuale VPN per la connettività ibrida ai sistemi locali.
• Una zona DNS privata di Azure.
• Endpoint privati di Azure.
• File di Azure account di archiviazione.
• Azure Key Vault.

Scaricare un file di Visio dell'architettura resiliente completa di Desktop virtuale Azure in più aree.

Considerazioni

• Questo scenario non supporta la connettività di rete diretta tra un client e un host di sessione pubblico o privato. In questo scenario non è possibile usare RDP Shortpath.
• Il gateway del piano di controllo di Desktop virtuale Azure, che usa un endpoint pubblico, gestisce le connessioni client. Di conseguenza, i client desktop virtuale Azure possono creare connessioni in uscita agli URL di Desktop virtuale Azure necessari. Per altre informazioni sugli URL necessari, vedere la sezione Internet di questo articolo e URL necessari per Desktop virtuale Azure.
• Non sono necessari indirizzi IP pubblici o altri percorsi in ingresso pubblici per gli host di sessione. Il traffico dai client agli host sessione passa attraverso il gateway del piano di controllo di Desktop virtuale Azure.
• Non esiste alcun peering di rete virtuale tra gli spoke di Desktop virtuale Azure. Tutto il traffico passa attraverso l'hub di connettività.
• Le connessioni Internet in uscita dagli host sessione di Desktop virtuale Azure passano attraverso il processo NAT (Network Address Translation) predefinito di Azure. Vengono usati indirizzi IP pubblici dinamici di Azure. I clienti non hanno alcun controllo sugli indirizzi IP pubblici in uscita usati.
• Le connessioni dagli host di sessione agli account di archiviazione File di Azure vengono stabilite tramite endpoint privati.
• Le zone DNS private di Azure vengono usate per risolvere gli spazi dei nomi degli endpoint privati per i servizi seguenti:
  • File di Azure account di archiviazione, che usano il nomeprivatelink.file.core.windows.net
  • Insiemi di credenziali delle chiavi, che usano il nome privatelink.vaultcore.azure.net
• Il filtro di rete non viene applicato per questo scenario. Tuttavia, i gruppi di sicurezza di rete vengono posizionati in tutte le subnet in modo da poter monitorare il traffico e ricavare informazioni dettagliate. In Network Watcher, l'analisi del traffico e la funzionalità di registrazione del flusso del gruppo di sicurezza di rete vengono usate per questi scopi.

Scenario 2: Hub e spoke con connettività ibrida su reti gestite tramite RDP Shortpath

Per indicazioni dettagliate sulla distribuzione, vedere Connettività SHORTPATH RDP per le reti gestite.

Profilo cliente

Questo scenario è ideale nei casi seguenti:

• Si vuole limitare il numero di connessioni Over-the-Internet agli host di sessione di Desktop virtuale Azure.
• Si dispone di connettività ibrida preesistente da un ambiente locale ad Azure, tramite ExpressRoute o una VPN da punto a sito o da punto a sito.
• È disponibile una connettività di rete direct line-of-sight tra i client RDP e gli host di Desktop virtuale Azure. In genere, in questo scenario viene usata una delle seguenti configurazioni:
  • Reti locali instradate alle reti Di Azure di Desktop virtuale Azure
  • Connessioni VPN client instradate alle reti virtuali di Desktop virtuale Azure
• È necessario limitare l'utilizzo della larghezza di banda degli host vm su reti private, ad esempio una VPN o ExpressRoute.
• Si vuole assegnare priorità al traffico di Desktop virtuale Azure nella rete.
• Non è necessaria l'ispezione del traffico tra reti Desktop virtuale Azure e altre reti virtuali di Azure.
• Non è necessaria l'ispezione del traffico tra le reti di Desktop virtuale Azure e i data center locali.
• Sono presenti server personalizzati di Active Directory Domain Services o DNS preesistenti.

Componenti dell'architettura

È possibile implementare questo scenario con:

• ExpressRoute o un gateway di rete virtuale VPN per la connettività ibrida agli ambienti locali con larghezza di banda sufficiente.
• Server Active Directory Domain Services e server DNS personalizzati.
• Gruppi di sicurezza di rete.
• Internet in uscita tramite un percorso di rete virtuale di Azure predefinito.
• Oggetti Criteri di gruppo di dominio o oggetti Criteri di gruppo locali.
• File di Azure account di archiviazione.
• Endpoint privati di Azure.
• Una zona DNS privata di Azure.

Considerazioni

• La connettività ibrida deve essere disponibile, tramite una VPN o ExpressRoute, con connettività di rete diretta del client RDP agli host vm privati sulla porta 3390.

• Per abilitare UDP su reti gestite, è necessario usare un oggetto Criteri di gruppo di dominio o un oggetto Criteri di gruppo locale.
• La connettività ibrida deve avere una larghezza di banda sufficiente per consentire connessioni dirette UDP agli host vm.
• La connettività ibrida deve avere un routing diretto per consentire le connessioni agli host vm.
• Il gateway del piano di controllo di Desktop virtuale Azure, che usa un endpoint pubblico, gestisce le connessioni client. Di conseguenza, i client desktop virtuale Azure possono creare connessioni in uscita agli URL di Desktop virtuale Azure necessari. Per altre informazioni sugli URL necessari, vedere la sezione Internet di questo articolo e URL necessari per Desktop virtuale Azure.
• Non sono necessari indirizzi IP pubblici o altri percorsi in ingresso pubblici per gli host di sessione. Il traffico dai client agli host sessione passa attraverso il gateway del piano di controllo di Desktop virtuale Azure.
• La connessione Internet in uscita dagli host sessione di Desktop virtuale Azure passa attraverso il processo NAT in uscita di Azure predefinito. Vengono usati indirizzi IP pubblici dinamici di Azure. I clienti non hanno alcun controllo sugli indirizzi IP pubblici in uscita usati.
• Le connessioni dagli host di sessione agli account di archiviazione File di Azure vengono stabilite tramite endpoint privati.
• Le zone DNS private di Azure vengono usate per risolvere gli spazi dei nomi degli endpoint privati.
• Il filtro di rete non viene applicato per questo scenario. Tuttavia, i gruppi di sicurezza di rete vengono posizionati in tutte le subnet in modo da poter monitorare il traffico e ricavare informazioni dettagliate. In Network Watcher, l'analisi del traffico e la funzionalità di registrazione del flusso del gruppo di sicurezza di rete vengono usate per questi scopi.

Scenario 3: Hub e spoke con reti pubbliche tramite RDP Shortpath

Per indicazioni dettagliate sulla distribuzione, vedere Connettività a shortpath RDP per le reti pubbliche.

Profilo cliente

Questo scenario è ideale nei casi seguenti:

• Le connessioni client di Desktop virtuale Azure attraversano la rete Internet pubblica. Gli scenari tipici includono utenti di lavoro da casa, utenti di succursali remote che non sono connessi alle reti aziendali e utenti terzisti remoti.
• Sono presenti connessioni a latenza elevata o a larghezza di banda ridotta agli host di sessione di Desktop virtuali di Azure.
• È necessario limitare l'utilizzo della larghezza di banda degli host sessione di Desktop virtuale Azure tramite i criteri di rete QoS.
• Si vuole classificare in ordine di priorità il traffico di Desktop virtuale Azure nella rete tramite i criteri QoS.
• Le connessioni RDP client iniziano da reti con larghezza di banda e velocità incoerenti.
• Si dispone di connettività in uscita diretta dagli host di sessione di Desktop virtuale Azure. Non si usa un routing tunnel forzato tramite reti locali.
• Non è necessaria l'ispezione del traffico tra reti Desktop virtuale Azure e altre reti virtuali di Azure.
• Non è necessaria l'ispezione del traffico tra le reti di Desktop virtuale Azure e i data center locali.
• Sono presenti server personalizzati di Active Directory Domain Services o DNS preesistenti.

Componenti dell'architettura

È possibile implementare questo scenario con:

• ExpressRoute o un gateway di rete virtuale VPN per la connettività ibrida agli ambienti locali. Questa configurazione è appropriata quando è disponibile una larghezza di banda sufficiente per supportare le connessioni ad applicazioni, dati o connessioni di Active Directory Domain Services locali. Non è consigliabile usare il tunneling forzato per inviare il traffico di Desktop virtuale Azure tramite router locali.
• Server Active Directory Domain Services e server DNS personalizzati.
• Gruppi di sicurezza di rete.
• Network Watcher.
• Internet in uscita tramite un percorso di rete virtuale di Azure predefinito.
• Oggetti Criteri di gruppo di dominio o oggetti Criteri di gruppo locali.
• File di Azure account di archiviazione.
• Endpoint privati di Azure.
• Una zona DNS privata di Azure.

Considerazioni

• Consentire i tipi di connessioni seguenti:

  • Connessioni UDP in uscita dagli host sessione di Desktop virtuale Azure alle utilità di attraversamento sessione di Desktop virtuale Azure per NAT (STUN) e attraversamento tramite servizi NAT (TURN) di inoltro sulla porta 3478
  • Connessioni UDP dai client RDP nell'intervallo di porte 49152-65535

  L'impostazione che configura queste connessioni è attivata per impostazione predefinita e mantiene lo stesso livello di crittografia della connessione inversa di Transmission Control Protocol (TCP). Per informazioni sulla limitazione degli intervalli di porte client RDP, vedere Limitare l'intervallo di porte quando si usa RDP Shortpath per le reti pubbliche.

• Il gateway del piano di controllo di Desktop virtuale Azure, che usa un endpoint pubblico, gestisce le connessioni client. Di conseguenza, i client desktop virtuale Azure possono creare connessioni in uscita agli URL di Desktop virtuale Azure necessari. Per altre informazioni sugli URL necessari, vedere la sezione Internet di questo articolo e URL necessari per Desktop virtuale Azure.

• I router consumer che si trovano in genere nelle reti utente domestiche devono avere Plug and Play universale (UPnP) abilitato.

• Non sono necessari indirizzi IP pubblici o altri percorsi in ingresso pubblici per gli host di sessione. Il traffico dai client agli host sessione passa attraverso il gateway del piano di controllo di Desktop virtuale Azure.

• La connessione Internet in uscita dagli host sessione di Desktop virtuale Azure passa attraverso il processo NAT in uscita di Azure predefinito. Vengono usati indirizzi IP pubblici dinamici di Azure. I clienti non hanno alcun controllo sugli indirizzi IP pubblici in uscita usati.

• È necessario configurare il contrassegno DSCP (Differentiated Services Code Point) negli host di sessione. Usare oggetti Criteri di gruppo locali o oggetti Criteri di gruppo di dominio per questa configurazione. Quando si usano marcatori DSCP, i dispositivi di rete possono applicare criteri QoS per il traffico di Desktop virtuale Azure. Per altre informazioni, vedere Implementare la qualità del servizio (QoS) per Desktop virtuale Azure.

• Le connessioni dagli host di sessione agli account di archiviazione File di Azure vengono stabilite usando endpoint privati.

• Le zone DNS private di Azure vengono usate per risolvere gli spazi dei nomi degli endpoint privati.

• Il filtro di rete non viene applicato per questo scenario. Tuttavia, i gruppi di sicurezza di rete vengono posizionati in tutte le subnet in modo da poter monitorare il traffico e ricavare informazioni dettagliate. In Network Watcher, l'analisi del traffico e la funzionalità di registrazione del flusso del gruppo di sicurezza di rete vengono usate per questi scopi.

Considerazioni e raccomandazioni generali sulla progettazione

Le sezioni seguenti forniscono considerazioni generali sulla progettazione e consigli per la topologia e la connettività della rete di Desktop virtuale Azure.

Hub e spoke e topologia di rete rete WAN virtuale

rete WAN virtuale supporta la connettività di transito tra VPN ed ExpressRoute, ma non supporta topologie hub-spoke.

Servizi di gestione delle identità

I requisiti di connettività dei servizi di identità negli host di sessione di Desktop virtuale Azure dipendono dal modello di identità.

• Per le macchine virtuali aggiunte a Microsoft Entra Domain Services: le reti di Desktop virtuale Azure devono avere connettività alla rete in cui è ospitato il servizio di gestione delle identità.
• Per le macchine virtuali aggiunte a Microsoft Entra ID: gli host di sessione di Desktop virtuale Azure creano connessioni in uscita agli endpoint pubblici di Microsoft Entra ID. Di conseguenza, non sono necessarie configurazioni di connettività privata.

DNS

Gli host di sessione di Desktop virtuale Azure hanno gli stessi requisiti di risoluzione dei nomi di qualsiasi altro carico di lavoro IaaS (Infrastructure as a Service). Di conseguenza, è necessaria la connettività ai server DNS personalizzati o all'accesso tramite un collegamento di rete virtuale alle zone DNS private di Azure. Le zone DNS private di Azure aggiuntive sono necessarie per ospitare gli spazi dei nomi degli endpoint privati di determinati servizi PaaS (Platform as a Service), ad esempio account di archiviazione e servizi di gestione delle chiavi.

Per altre informazioni, vedere Configurazione DNS dell'endpoint privato di Azure.

Per facilitare la configurazione client di Desktop virtuale Desktop virtuale Azure, inclusa la sottoscrizione al feed Servizi Desktop remoto, è consigliabile configurare l'individuazione della posta elettronica. È necessario configurare l'individuazione della posta elettronica nel dominio DNS pubblico e quindi sottoscrivere il feed di Servizi Desktop remoto. Per altre informazioni, vedere Configurare l'individuazione della posta elettronica per sottoscrivere il feed di Servizi Desktop remoto.

Larghezza di banda e latenza

Desktop virtuale Azure usa RDP. Per altre informazioni su RDP, vedere Requisiti di larghezza di banda rdp (Remote Desktop Protocol).

La latenza della connessione varia a seconda della posizione degli utenti e delle macchine virtuali. I servizi Desktop virtuale Azure vengono continuamente implementati in nuove aree geografiche per migliorare la latenza. Per ridurre al minimo la latenza usata dai client di Desktop virtuale Azure, usare lo strumento di stima dell'esperienza desktop virtuale Azure. Questo strumento fornisce esempi di tempo di round trip (RTT) dai client. È possibile usare queste informazioni per inserire gli host di sessione nell'area più vicina agli utenti finali e avere il valore RTT più basso. Per informazioni sull'interpretazione dei risultati dello strumento di stima, vedere Analizzare la qualità della connessione in Desktop virtuale Azure.

QoS con percorso breve RDP

RDP Shortpath per le reti gestite fornisce un trasporto diretto basato su UDP tra un client Desktop remoto e un host di sessione. RDP Shortpath per le reti gestite consente di configurare i criteri QoS per i dati RDP. QoS in Desktop virtuale Azure consente il traffico RDP in tempo reale sensibile ai ritardi di rete al "taglio in linea" davanti al traffico meno sensibile.

È possibile usare RDP Shortpath in due modi:

• Nelle reti gestite, in cui viene stabilita la connettività diretta tra il client e l'host sessione quando si usa una connessione privata, ad esempio una connessione ExpressRoute o una VPN.
• Nelle reti pubbliche, in cui viene stabilita la connettività diretta tra il client e l'host sessione quando si usa una connessione pubblica. Esempi di connessioni pubbliche includono reti domestico, reti di caffè e reti alberghiere. Esistono due possibili tipi di connessione quando si usa una connessione pubblica:

  • Connessione UDP diretta tra un client e un host di sessione che usa il protocollo STUN.

  • Connessione UDP indiretta che usa il protocollo TURN con un inoltro tra un client RDP e un host di sessione. Questa opzione viene usata se il gateway o il router non consente connessioni UDP dirette.

    Nota

    L'uso di RDP Shortpath per le reti pubbliche con TURN per Desktop virtuale Azure è attualmente in anteprima. Per altre informazioni, vedere RDP Shortpath per Desktop virtuale Azure.

Il percorso RDP estende le funzionalità di trasporto multi-trasporto RDP. Non sostituisce il trasporto di connessione inversa, ma lo integra.

Il brokering di sessioni iniziale viene gestito tramite il servizio Desktop virtuale Azure e il trasporto di connessione inversa, che è basato su TCP. Tutti i tentativi di connessione vengono ignorati a meno che non corrispondano prima alla sessione di connessione inversa.

RDP Shortpath, basato su UDP, viene stabilito dopo l'autenticazione. Se la connessione RDP Shortpath viene stabilita correttamente, il trasporto di connessione inverso viene eliminato. Quindi, tutti i flussi di traffico su uno dei metodi Shortpath RDP elencati in precedenza in questa sezione.

Per altre informazioni, vedere Implementare la qualità del servizio (QoS) per Desktop virtuale Azure.

Internet

Le risorse di calcolo e i client di Desktop virtuale Azure richiedono l'accesso a endpoint pubblici specifici, quindi necessitano di connessioni associate a Internet. Gli scenari di rete, ad esempio il tunneling forzato per migliorare la sicurezza e il filtro, sono supportati quando vengono soddisfatti i requisiti di Desktop virtuale Azure.

Per informazioni sui requisiti per gli host di sessione e i dispositivi client di Desktop virtuale Azure, vedere URL necessari per Desktop virtuale Azure.

Requisiti relativi a porte e protocolli

I modelli di connessione di Desktop virtuale Azure usano le porte e i protocolli seguenti:

• Modello standard: 443/TCP
• Modello Shortpath RDP: 443/TCP e 3390/UDP o 3478/UDP per il protocollo STUN o TURN

Continuità aziendale e ripristino di emergenza

Per la continuità aziendale e il ripristino di emergenza, è necessaria una determinata configurazione di rete. In particolare, per distribuire e ripristinare le risorse in un ambiente di destinazione, usare una delle configurazioni seguenti:

• Configurazione di rete con le stesse funzionalità dell'ambiente di origine
• Configurazione di rete con connettività a servizi DNS e identità

Passaggi successivi

Informazioni sull'organizzazione delle risorse per uno scenario su scala aziendale di Desktop virtuale Azure.