After Upgrading or Migrating vCenter Server

After you upgrade to vCenter Server, consider the post-upgrade options and requirements.

• Complete any component reconfigurations that might be required for changes during upgrade.
• Verify that you understand the authentication process and identify your identity sources.
• If you migrated vCenter Server on Windows to a target vCenter Server appliance and you use any local OS user names to log in to the vCenter Single Sign-On, you must recreate them and reassign permissions.
• If you performed an upgrade, upgrade any additional modules that are linked to this instance of vCenter Server, such as Update Manager. If you performed a migration from vCenter Server for Windows to a vCenter Server appliance, the Update Manager module is migrated as well into vSphere Lifecycle Manager.
• Optionally, upgrade or migrate the ESXi hosts in the vCenter Server inventory to the same version as the vCenter Server instance.
• If you use Update Manager in your vCenter Server deployment, and Update Manager and vCenter Server were running on separate machines prior the migration, consider to shut down or delete the Update Manager host machine after the migration is complete. Before disposing of the Update Manager host machine, take into account the following:
  • You might need the host machine for rolling back purposes of your upgraded or migrated environment.
  • You might have other software that runs on that machine.
• If you are using smart card authentication, ensure to keep the smart card port open in the client environment. By default, the smart card port is open in vCenter Server. For details about the smart card port, see the VMware Ports and Protocols Tool™ at https://ports.vmware.com
• If you plan to install Windows 11 as a guest operating system on a virtual machine, you must configure a key provider. Installing Windows 11 requires a Trusted Platform Module (TPM) 2.0. When installing Windows 11 as a guest operating system on a virtual machine, instead of using a physical TPM, you can use a virtual Trusted Platform Module (vTPM). A vTPM is a software-based representation of a physical TPM 2.0 chip. A vTPM depends on virtual machine encryption to secure vital TPM data, and so requires that you configure a key provider. For information about the key providers supported by vSphere, see the Virtual Machine Encryption chapter in the vSphere Security documentation. The easiest way is to configure a VMware vSphere^® Native Key Provider™. vSphere Native Key Provider is included in all vSphere editions and does not require an external key server. For information about configuring a vSphere Native Key Provider, see Configuring and Managing vSphere Native Key Provider chapter in the vSphere Security documentation. As with all security solutions, consider the system design, implementation considerations, and tradeoffs of using vSphere Native Key Provider.

• If you had modified the DRS cluster automation level before upgrade, you can either continue to use the modified settings or revert the automation level to fully automated.