Infrastruttura dispositivo virtuale persistente (VDI) e dispositivi clonati con immagine Gold

La VDI persistente consente al team IT di eseguire il provisioning di desktop virtuali che conservano la configurazione, le applicazioni e i dati utente dati tra le sessioni, a differenza delle istanze VDI non persistenti, che vengono ripristinate a ogni riavvio. Ciò si applica a qualsiasi altro dispositivo, fisico o virtuale, clonato o fornito da un'immagine Gold standard e quindi eseguito come proprio endpoint univoco, anziché essere ripristinato tra una sessione e l'altra.

Poiché ciascuno di questi dispositivi mantiene la propria identità nel tempo, l'Ivanti Neurons Agent può essere installato e gestito utilizzando uno dei due metodi seguenti, a seconda della quantità di automazione richiesta.

Flusso di lavoro funzione

Opzioni di distribuzione agente:

I desktop virtuali persistenti e altri dispositivi clonati da un'immagine dorata possono avere l'agente installato come parte del processo di creazione dell'immagine di base e quindi registrato manualmente per ciascuna istanza clonata utilizzando il comando di registrazione standard con una chiave di registrazione.
In alternativa, una volta che l'immagine clonata è in esecuzione, l'agente può esservi inviato tramite push in remoto, allo stesso modo in cui verrebbe inviato tramite push a qualsiasi endpoint fisico o virtuale standard.

Gestione continua:

Poiché le immagini clonate persistenti conservano la loro identità e configurazione dell'agente durante i reboot, non richiedono le fasi di sigillatura, di rimozione sigillatura o di registrazione delle immagini di base utilizzate per VDI non persistenti.
Ogni immagine clonata persistente viene trattata come un endpoint univoco a lungo termine in Ivanti Neurons una volta registrata.

Metodo 1: gestione manuale

Utilizzare questa metodica per controllare direttamente il processo di creazione dell'immagine di base, registrando immediatamente l'agente all'avvio di ciascuna istanza clonata o pre-popolando l'immagine con i motori in anticipo.

Preinstallazione dell'agente sull'immagine di base senza registrazione o pre-popolazione dei motori

Per preparare l'immagine di base senza registrare l'agente o scaricare i motori in anticipo, attenersi alla seguente procedura:

Eseguire il programma di installazione dell'agente sull'immagine di base senza un file .options associato.
Quando viene visualizzata la chiave di attivazione o l'opzione Cookie, fare clic su Annulla.
Questo installa l'agente sull'endpoint senza registrarlo al tenant e non è presente alcun file .options per attivare la registrazione automatica.
Una volta che ogni istanza è stata spostata da questa immagine di base, eseguire il comando di registro stagentctl (senza le opzioni di sigillatura o di rimozione della sigillatura utilizzate per VDI non persistenti) al fine di registrare l'agente utilizzando una chiave di registrazione come segue:
stagentctl register --enrollmentkey "%enrollmentkey%" --baseurl https://agentreg.ivanticloud.com
Nel comando precedente, %enrollmentkey% è una combinazione di tenantid_activationkey trovata nel file .options associato e scaricato dalla pagina Distribuzione agente.
Questo processo registra l'agente con il tenant e recupera i motori collegati al criterio associato alla chiave di registrazione. Poiché questa istanza è permanente, l'identità e la configurazione dell'agente impostate durante questo passaggio rimarranno intatte anche dopo il riavvio. Di conseguenza, la registrazione deve avvenire solo una volta per istanza.

Pre-installazione dei motori agente e pre-popolazione utilizzando lo strumento di preparazione offline

Per evitare di scaricare i motori sulla rete la prima volta che ogni istanza clonata persistente effettua il check-in, è possibile installare l'agente senza registrarlo. Quindi, precompilare l'immagine con i motori utilizzando lo strumento Ivanti Neurons Offline Prep, disponibile sull'Ivanti Innovators Hub.

Per maggiori informazioni e download degli strumenti, visitare la Guida all'installazione e alla configurazione offline di Ivanti Neurons per UWM Hybrid su Ivanti Innovators Hub.

Metodo 2: gestione remota

Utilizzare questa metodica per il trattamento di ogni istanza VDI o altro dispositivo clonato con immagine Gold nello stesso modo in cui si tratterebbe qualsiasi altro endpoint gestito, piuttosto che creare la registrazione nell'immagine di base.

Per la gestione dispositivo remota di un'istanza VDI permanente o di un altro dispositivo clonato con immagine Gold, attenersi alla seguente procedura:

Eseguire lo spin-up o il provisioning del dispositivo.
Dalla console Ivanti Neurons, installare l'agente sull'istanza in esecuzione utilizzando il metodo standard di installazione Agent Push, allo stesso modo in cui si esegue il push dell'agente a un dispositivo fisico o virtuale standard.
Dopo l'installazione, l'agente si registra con il tenant e scarica i motori relativi al criterio assegnato. Quindi, l'istanza viene visualizzata in Ivanti Neurons come endpoint standard gestito.

Poiché questo metodo non richiede la registrazione o la sigillatura delle immagini di base, ogni istanza persistente viene gestita in modo indipendente. Gli aggiornamenti, le modifiche ai criteri e le installazioni del motore vengono elaborati tramite il normale comportamento di check-in dell'agente, invece di fare affidamento sull'ereditarietà dell'immagine di base.

Cose da notare

Le istanze VDI persistenti e gli altri dispositivi clonati da un'immagine Gold non utilizzano le opzioni di sigillatura, di rimozione sigillatura o di registrazione asBaseImage utilizzate per VDI non persistenti, poiché ogni istanza conserva la propria identità di agente durante i riavviamenti.
La ricertificazione dell'agente si comporta normalmente su istanze VDI persistenti e altri dispositivi clonati con immagine Gold, poiché non esiste un'associazione di sicurezza delle immagini di base condivisa da proteggere.
La scelta tra Gestisci manualmente e Gestisci in remoto dipende dal controllo necessario sul processo di creazione delle immagini di base rispetto a quanto si desidera che ogni istanza venga gestita come un endpoint standard dopo la distribuzione.