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 quando una macchina virtuale passa attraverso un processo di arresto/riavvio/ripristino del sistema operativo.
È 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.
Importante
La mancata gestione dei dispositivi non aggiornati può comportare un aumento eccessivo dell'uso della quota del tenant e il potenziale rischio di interruzione del servizio, se si esaurisce tale quota. Usare le indicazioni seguenti quando si distribuiscono ambienti VDI non persistenti per evitare questa situazione.
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 più recente, Windows Server 2016 v1803 o più recente, e Windows Server 2019 o più recente.
Tipo di identità del dispositivo | Infrastruttura delle identità | Dispositivi Windows | Versione piattaforma VDI | Supportata |
---|---|---|---|---|
Aggiunto a Microsoft Entra ibrido | Federato3 | Windows corrente | Persistente | Sì |
Windows corrente | Non persistente | Sì5 | ||
Gestito4 | Windows corrente | Persistente | Sì | |
Windows corrente | Non persistente | Limitato6 | ||
Aggiunto a Microsoft Entra | Federato | Windows corrente | Persistente | Limitato8 |
Non persistente | No | |||
Gestito | Windows corrente | Persistente | Limitato8 | |
Non persistente | No | |||
Registrato in Microsoft Entra | Federato/gestito | Windows corrente | Persistente/non persistente | Non applicabile |
4 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.
5Il 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
6Il 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.
8Il supporto per l'unione a Microsoft Entra è disponibile con Azure Virtual Desktop, Windows 365e 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 gli amministratori distribuiscono VDI non persistenti, Microsoft consiglia 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 i dispositivi Windows 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, è necessario eliminare i dispositivi con ApproximateLastLogonTimestamp di più di 15 giorni.
Nota
Quando si usa una VDI non persistente, per impedire l'aggiunta di un account aziendale o di un istituto di istruzione, assicurarsi che la seguente chiave del Registro di sistema sia correttamente configurata: HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin: "BlockAADWorkplaceJoin"=dword:00000001
.
Assicurarsi di eseguire Windows 10, versione 1803 o successiva.
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 ignorare le cartelle e le chiavi seguenti:
%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
Quando gli amministratori distribuiscono VDI persistente, Microsoft consiglia di implementare le indicazioni seguenti. 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