Une fois que vous avez effectué la mise à niveau vers vCenter Server, étudiez les options et conditions de post-mise à niveau requises.

  • Procédez aux reconfigurations de composants qui peuvent être nécessaires suite aux modifications apportées lors de la mise à niveau.
  • Assurez-vous que vous comprenez le processus d'authentification et identifiez vos sources d'identité.
  • Si vous avez migré vCenter Server sur Windows vers une instance cible de vCenter Server Appliance et que vous utilisez des noms d'utilisateur du système d'exploitation local pour vous connecter à vCenter Single Sign-On, il vous faut les recréer et leur réaffecter des autorisations.
  • Si vous avez effectué une mise à niveau, mettez à niveau tout module supplémentaire lié à cette instance de vCenter Server, tel que Update Manager. Si vous avez effectué une migration à partir de vCenter Server pour Windows vers une instance de vCenter Server Appliance, le module Update Manager est également migré vers vSphere Lifecycle Manager.
  • Vous pouvez également mettre à niveau ou migrer les hôtes ESXi répertoriés dans l'inventaire vCenter Server vers la même version que l'instance de vCenter Server.
  • Si vous utilisez Update Manager dans votre déploiement vCenter Server et que Update Manager et vCenter Server étaient exécutés sur des machines différentes avant la migration, pensez à éteindre ou supprimer la machine Update Manager hôte une fois la migration terminée. Avant de supprimer la machine Update Manager hôte, tenez compte des éléments suivants :
    • Vous pourriez avoir besoin de la machine hôte pour récupérer une version précédente de l'environnement mis à niveau ou migré.
    • Il se peut que vous ayez d'autres logiciels exécutés sur cette machine.
  • Si vous utilisez l'authentification par carte à puce, veillez à maintenir le port de carte à puce ouvert dans l'environnement client. Par défaut, le port de carte à puce est ouvert dans vCenter Server. Pour plus d'informations sur le port de carte à puce, reportez-vous à l'outil VMware Ports and Protocols™ sur https://ports.vmware.com
  • Si vous prévoyez d'installer Windows 11 en tant que système d'exploitation invité sur une machine virtuelle, vous devez configurer un fournisseur de clés. L'installation de Windows 11 nécessite un module de plate-forme sécurisée (TPM) 2.0. Lors de l'installation de Windows 11 en tant que système d'exploitation invité sur une machine virtuelle, au lieu d'utiliser un TPM physique, vous pouvez utiliser un vTPM (Virtual Trusted Platform Module). Un vTPM est une représentation logicielle d'une puce TPM 2.0 physique. Un vTPM dépend du chiffrement des machines virtuelles pour sécuriser les données TPM essentielles et nécessite donc que vous configuriez un fournisseur de clés. Pour plus d'informations sur les fournisseurs de clés pris en charge par vSphere, reportez-vous au chapitre Chiffrement des machines virtuelles de la documentation Sécurité vSphere. La méthode la plus simple consiste à configurer un VMware vSphere® Native Key Provider™. vSphere Native Key Provider est inclus dans toutes les éditions de vSphere et ne nécessite pas de serveur de clés externe. Pour plus d'informations sur la configuration d'un vSphere Native Key Provider, reportez-vous au chapitre Configuration et gestion de vSphere Native Key Provider dans la documentation Sécurité vSphere. Comme pour toutes les solutions de sécurité, tenez compte de la conception du système, des éléments à prendre en compte pour la mise en œuvre et des compromis liés à l'utilisation d'un vSphere Native Key Provider.

  • Si vous avez modifié le niveau d'automatisation du cluster DRS avant la mise à niveau, vous pouvez continuer à utiliser les paramètres modifiés ou rétablir le niveau d'automatisation sur Entièrement automatisé.