Identità del dispositivo e virtualizzazione del desktop

Gli amministratori distribuiscono in genere piattaforme VDI (infrastruttura di desktop virtuale) che ospitano sistemi operativi Windows nelle organizzazioni. Gli amministratori distribuiscono VDI per:

• Semplificare la gestione.
• Ridurre i costi attraverso il consolidamento e la centralizzazione delle risorse.
• Fornire agli utenti finali la mobilità e la libertà di accedere ai desktop virtuali in qualsiasi momento, da qualsiasi luogo, su qualsiasi dispositivo.

Esistono due tipi principali di desktop virtuali:

• Persistente
• Non persistente

Le versioni persistenti usano un'immagine desktop univoca per ogni utente o per un pool di utenti. Questi desktop univoci possono essere personalizzati e salvati per un uso futuro.

Le versioni non persistenti usano una raccolta di desktop a cui gli utenti possono accedere in base alle esigenze. Questi desktop non persistenti vengono ripristinati allo stato originale, in Windows corrente ¹ questa modifica si verifica quando una macchina virtuale passa attraverso un processo di arresto/riavvio/ripristino del sistema operativo, mentre in Windows di livello inferiore ² si verifica quando un utente si disconnette.

È importante assicurarsi che le organizzazioni gestiscano i dispositivi non aggiornati creati a causa della registrazione frequente dei dispositivi senza una strategia appropriata per la gestione del ciclo di vita dei dispositivi.

Per un'esecuzione corretta di alcuni scenari, è importante avere nomi di dispositivo univoci nella directory. Questa operazione può essere ottenuta tramite una corretta gestione dei dispositivi non aggiornati oppure è possibile garantire l'univocità del nome del dispositivo usando un modello di denominazione dei dispositivi.

Questo articolo illustra le indicazioni Microsoft destinate agli amministratori in merito al supporto per l'identità del dispositivo e per VDI. Per altre informazioni sull'identità del dispositivo, consultare Informazioni sulle identità del dispositivo.

Scenari supportati

Prima di configurare le identità dei dispositivi in Microsoft Entra ID per l'ambiente VDI, acquisire familiarità con gli scenari supportati. Nella tabella seguente vengono illustrati gli scenari di provisioning supportati. Il provisioning in questo contesto implica che un amministratore può configurare le identità dei dispositivi su larga scala senza richiedere alcuna interazione con l'utente finale.

¹I dispositivi Windows correnti rappresentano Windows 10 o versione successiva, Windows Server 2016 v1803 o versione successiva e Windows Server 2019 o versione successiva.

²I dispositivi Windows di livello inferiore rappresentano Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 e Windows Server 2012 R2. Per informazioni sul supporto per Windows 7, consultare Il supporto per Windows 7 sta terminando. Per informazioni sul supporto per Windows Server 2008 R2, consultare Prepararsi per la fine del supporto per Windows Server 2008.

³ Un ambiente dell'infrastruttura di identità federato rappresenta un ambiente con un provider di identità, ad esempio AD FS o un altro provider di identità di terze parti. In un ambiente dell'infrastruttura di gestione delle identità federato, i computer seguono il flusso di registrazione del dispositivo gestito in base alle impostazioni del punto di connessione del servizio Active Directory di Microsoft Windows Server.

⁴ Un ambiente di infrastruttura dell'identità gestito rappresenta un ambiente con Microsoft Entra ID come provider di identità distribuito, con la sincronizzazione dell'hash delle password (PHS) o l'autenticazione pass-through (PTA) con Single Sign On facile.

⁵Il supporto di non persistenza per Windows corrente richiede altre considerazioni, come documentato nella sezione Indicazioni. Questo scenario richiede Windows 10 1803 o versione successiva, Windows Server 2019 o Windows Server (canale semestrale) a partire dalla versione 1803

⁶Il supporto di non persistenza per Windows corrente in un ambiente dell'infrastruttura di gestione delle identità è disponibile solo con Citrix gestito dal cliente locale e gestito dal servizio cloud. Per qualsiasi query correlata al supporto, contattare direttamente il supporto di Citrix.

⁷Il supporto di non persistenza per Windows di livello inferiore richiede altre considerazioni, come documentato nella sezione Indicazioni.

⁸Il supporto per l'aggiunta di Microsoft Entra è disponibile con Desktop virtuale Azure, Windows 365 e Amazon WorkSpaces. Per eventuali query correlate al supporto con Amazon WorkSpaces e all'integrazione di Microsoft Entra, contattare direttamente il supporto di Amazon.

Indicazioni Microsoft

Gli amministratori devono fare riferimento agli articoli seguenti, in base all'infrastruttura di gestione delle identità, per informazioni su come configurare l'aggiunta di Microsoft Entra ibrido.

• Configurare l'aggiunta di Microsoft Entra ibrido in ambienti federati
• Configurare l'aggiunta di Microsoft Entra ibrido in ambienti gestiti

VDI non persistente

Quando si distribuisce una VDI non persistente, Microsoft consiglia alle organizzazioni di implementare le indicazioni seguenti. In caso contrario, nella directory saranno presenti numerosi dispositivi ibridi aggiunti a Microsoft Entra, non aggiornati e registrati dalla piattaforma VDI non persistente. Questi dispositivi non aggiornati comportano una maggiore pressione sulla quota del tenant e il rischio di interruzione del servizio a causa dell'esaurimento della quota del tenant.

• Nel caso in cui si utilizzi Utilità preparazione sistema (sysprep.exe) e un'immagine pre-Windows 10, versione 1809 per l'installazione, è importante assicurarsi che l'immagine non provenga da un dispositivo già registrato come dispositivo ibrido aggiunto a Microsoft Entra ID.
• Se si fa affidamento su uno snapshot di macchina virtuale (VM) per creare più macchine virtuali, assicurarsi che lo snapshot non provenga da una macchina virtuale già registrata con Microsoft Entra ID come aggiunta a Microsoft Entra ibrido.
• Active Directory Federation Services (AD FS) supporta l'aggiunta istantanea per l'aggiunta di VDI non persistente e Microsoft Entra ibrido.
• Creare e usare un prefisso per il nome visualizzato (ad esempio, NPVDI-) del computer che indica il desktop come basato su VDI non persistente.
• Per Windows di livello inferiore:
  • Implementare il comando autoworkplacejoin /leave come parte dello script di disconnessione. Questo comando deve essere attivato nel contesto dell'utente e deve essere eseguito prima che l'utente si sia disconnesso completamente, in presenza di connettività di rete.
• Per Windows corrente in un ambiente federato (ad esempio, AD FS):
  • Implementare dsregcmd /join come parte della sequenza/ordine di avvio della macchina virtuale e prima che l'utente esegua l'accesso.
  • NON eseguire dsregcmd /leave come parte del processo di arresto/riavvio della macchina virtuale.
• Definire e implementare il processo per la gestione dei dispositivi non aggiornati.
  • Dopo aver definito una strategia per identificare i dispositivi ibridi aggiunti a Microsoft Entra non persistenti (ad esempio usando il prefisso del nome visualizzato del computer), è consigliabile adottare un approccio più incisivo nella rimozione di tali dispositivi, al fine di evitare che la directory si riempia di dispositivi non aggiornati.
  • Per le distribuzioni VDI non persistenti su versioni correnti o precedenti di Windows, è consigliabile eliminare i dispositivi con un valore di ApproximateLastLogonTimestamp superiore a 15 giorni.

Il roaming dei dati nel percorso %localappdata% non è supportato. Se si decide di spostare il contenuto in %localappdata%, assicurarsi che il contenuto delle seguenti cartelle e chiavi del Registro di sistema non lasci mai il dispositivo, in nessuna circostanza. Ad esempio, gli strumenti di migrazione del profilo devono escludere le seguenti cartelle e chiavi:

• %localappdata%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy
• %localappdata%\Packages\Microsoft.Windows.CloudExperienceHost_cw5n1h2txyewy
• %localappdata%\Packages\<any app package>\AC\TokenBroker
• %localappdata%\Microsoft\TokenBroker
• %localappdata%\Microsoft\OneAuth
• %localappdata%\Microsoft\IdentityCache
• HKEY_CURRENT_USER\SOFTWARE\Microsoft\IdentityCRL
• HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\AAD
• HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WorkplaceJoin

Il roaming del certificato del dispositivo per gli account aziendali non è supportato. Il certificato rilasciato da "MS-Organization-Access" viene memorizzato sia nell'archivio certificati personale (MY) dell'utente corrente sia nel computer locale.

VDI persistente

Durante la distribuzione di una VDI persistente, Microsoft raccomanda agli amministratori IT di seguire le indicazioni riportate di seguito. In caso contrario, potrebbero insorgere problemi legati alla distribuzione e all'autenticazione.

• Nel caso in cui si utilizzi Utilità preparazione sistema (sysprep.exe) e un'immagine pre-Windows 10, versione 1809 per l'installazione, è importante assicurarsi che l'immagine non provenga da un dispositivo già registrato come dispositivo ibrido aggiunto a Microsoft Entra ID.
• Se si fa affidamento su uno snapshot di macchina virtuale (VM) per creare più macchine virtuali, assicurarsi che lo snapshot non provenga da una macchina virtuale già registrata con Microsoft Entra ID come aggiunta a Microsoft Entra ibrido.

È consigliabile implementare il processo per la gestione dei dispositivi non aggiornati. Questo processo garantisce che la directory non venga sovraccaricata da dispositivi non aggiornati, soprattutto quando le macchine virtuali vengono reimpostate periodicamente.

Passaggi successivi

Configurazione dell'aggiunta ibrida a Microsoft Entra per ambienti federati