Infrastructure de périphériques virtuels persistants (VDI) et périphériques clonés avec image Gold

Le VDI persistant permet à votre équipe IT de provisionner des postes virtuels qui conservent leur configuration, leurs applications et leurs données utilisateur d'une session à l'autre, contrairement aux instances VDI non persistantes, qui se réinitialisent à chaque redémarrage. Cela s'applique à tous les autres périphériques, physiques ou virtuels, clonés ou provisionnés à partir d'une image Gold commune, puis exécutés comme poste client unique au lieu de se réinitialiser entre deux sessions.

Comme chacun de ces périphériques conserve son identité au fil du temps, il est possible d'installer et de gérer l'agent Ivanti Neurons avec l'une des deux méthodes suivantes, en fonction du niveau d'automatisation requis pour votre environnement.

Workflow de fonctions

Options Agent Deployment (Déploiement d'agent) :

L'agent peut être installé sur les postes de travail virtuels persistants et autres périphériques clonés à partir d'une image Gold, dans le cadre du processus de création de l'image de base. Il est ensuite inscrit manuellement pour chaque instance clonée, avec la commande d'inscription standard et une clé d'inscription.
Sinon, une fois l'image clonée en cours d'exécution, il est possible de transmettre l'agent en mode Push à distance, comme vous le feriez pour n'importe quel poste client physique ou virtuel standard.

Gestion en continu :

Comme les images clonées persistantes conservent leur identité d'agent et leur configuration lors des redémarrages, elles ne nécessitent aucune des étapes de scellement, descellement ou inscription d'image de base utilisées pour le VDI non persistant.
Chaque image clonée persistante est traitée comme un poste client unique à long terme dans Ivanti Neurons après son inscription.

Méthode 1 : Gestion manuelle

Utilisez cette méthode pour contrôler directement le processus de création d'image de base, soit en inscrivant immédiatement l'agent au démarrage de chaque instance clonée, soit en préremplissant l'image à l'avance avec des moteurs.

Préinstaller l'agent dans l'image de base sans inscription ni préremplissage de moteurs

Pour préparer l'image de base sans inscrire l'agent ni télécharger des moteurs à l'avance, procédez comme suit :

Exécutez le programme d'installation de l'agent sur l'image de base sans aucun fichier .options associé.
Lorsque l'option Clé d'activation ou Cookie s'affiche, cliquez sur Annuler.
Cela installe l'agent sur le poste client sans l'inscrire auprès du locataire, et aucun fichier .options n'est présent pour déclencher l'inscription automatique.
Une fois que chaque instance a été générée à partir de cette image de base, exécutez la commande stagentctl register (sans les options de scellement/descellement utilisées pour le VDI non persistant) pour inscrire l'agent avec une clé d'inscription, comme suit :
stagentctl register --enrollmentkey "%enrollmentkey%" --baseurl https://agentreg.ivanticloud.com
Dans la commande ci-dessus, %enrollmentkey% est une combinaison de la clé tenantid_activationkey figurant dans le fichier .options associé téléchargé depuis la page Agent Deployment (Déploiement d'agent).
Ce processus inscrit l'agent auprès du locataire et récupère les moteurs liés à la stratégie associée à la clé d'inscription. Comme cette instance est persistante, l'identité et la configuration de l'agent, définies pendant cette étape, restent intactes même après un redémarrage. Par conséquent, vous n'avez besoin d'effectuer l'inscription qu'une seule fois par instance.

Préinstaller l'agent et préremplir les moteurs à l'aide de l'outil Préparation hors ligne

Pour éviter de télécharger des moteurs sur le réseau lors de la première prise de contact de chaque instance clonée persistante, vous pouvez installer l'agent sans l'inscrire. Ensuite, préremplissez l'image avec des moteurs, à l'aide de l'outil Préparation hors ligne Ivanti Neurons, disponible dans le hub Ivanti Innovators.

Pour en savoir plus et télécharger l'outil, consultez le Guide d'installation et de configuration hors ligne Ivanti Neurons pour UWM hybride dans le Ivanti Innovators.

Méthode 2 : Gestion à distance

Utilisez cette méthode pour traiter chaque instance VDI persistante ou autre périphérique cloné avec image Gold comme vous traitez tous les autres postes client gérés, au lieu de créer une inscription dans l'image de base.

Pour gérer à distance une instance VDI persistante ou un autre périphérique cloné avec image Gold, procédez comme suit :

Générez ou provisionnez le périphérique.
Dans la console Ivanti Neurons, installez l'agent sur l'instance en cours d'exécution, avec la méthode standard d'installation Push de l'agent, comme vous le feriez pour transmettre l'agent en mode Push à un périphérique physique ou virtuel standard.
Après l'installation, l'agent s'inscrit auprès du locataire et télécharge les moteurs liés à la stratégie affectée. Ensuite, l'instance apparaît dans Ivanti Neurons en tant que poste client géré standard.

Comme cette approche ne nécessite pas d'inscription ni de scellement de l'image de base, chaque instance persistante est gérée indépendamment. Les mises à jour, les changements de stratégie et les installations de moteur sont traités via le comportement de prise de contact régulier de l'agent, plutôt que de s'appuyer sur l'héritage de l'image de base.

Éléments à noter

Les instances VDI persistantes et les autres périphériques clonés avec image Gold n'utilisent pas les options de scellement, descellement ou inscription comme image de base (asBaseImage) utilisées pour le VDI non persistant. En effet, chaque instance conserve sa propre identité d'agent lors des redémarrages.
La recertification des agents se comporte normalement sur les instances VDI persistantes et autres périphériques clonés avec image Gold, car il n'y a aucune association de sécurité d'image de base partagée à protéger.
Le choix entre la gestion manuelle et la gestion à distance dépend du niveau de contrôle nécessaire sur le processus de création de l'image de base, comparé à la nécessité de gérer chaque instance comme un poste client standard après le déploiement.