Tag: vsphere

  • In-Place Upgrade Windows 10 to 11 on vSphere Virtual Machine

    In-Place Upgrade Windows 10 to 11 on vSphere Virtual Machine

    A customer running Horizon with Windows 10 recently inquired about performing in-place upgrades on their templates. Typically, I would recommend building a new template for a major OS upgrade; there’s often many GBs’ worth of redundant bloat that remains dormant in the file system after an in-place upgrade.This can be detrimental for storage, performance, and general housekeeping of the desktop image.

    On this occasion, a new template build wasn’t feasible, so we had to go in-place.

    Before starting, clone the VM and test the process first. It’s easy to break Windows 10 if firmware or BIOS settings are misconfigured in vCenter. The following steps assume prerequisites for Windows 11 are already in place, including a native key provider configured in vCenter.

    For background information on vTPM in vSphere I recommend the Q&A on vTPM from VMware and the Broadcom guidance; albeit the latter doesn’t explain the disk partition issue covered below, so take this into consideration before proceeding.

    Environment: VMware Cloud on AWS

    Scale: This process is for a single VM and doesn’t cover automated/batch upgrading.

    Operating System: Windows 10 Enterprise 22H2 to Windows 11 24H2.

    Convert existing partitions from MBR to GTP

    One of the prerequisites I wasn’t aware of for Windows 11 on vSphere is the need for GPT partitions to enable EFI firmware options. There’s more detail on this here: Windows Setup: Installing using the MBR or GPT partition style | Microsoft Learn

    My early attempts to upgrade were failing with similar errors as described in this Reddit article.

    1. Confirm the existing VM partition style via MMC > Disk Manager > right click OS disk > Properties > Volumes > Partition Style:

    2. If the partition is MBR, it needs to be converted to GTP. If it is GTP, proceed to Step 6.

    3. Follow the steps in this guide: Convert an existing Windows 10 Installation from Legacy BIOS to UEFI

    4. Once the partition type has been converted successfully, shut down the VM. vTPM devices and boot/firmware configuration changes can only be performed on powered-off machines.

    5. Configure secure boot on the VM by browsing vCenter > select the VM > Edit Settings > VM Options > Boot Options and set the Firmware: EFI and Secure Boot: Enable > Save.

    6. To add a vTPM device Virtual Hardware > New Device > Trusted Platform Module. The vTPM will add to the VM and you can see the default VMCA-provided certificates are pre-populated. No further steps are needed.

    7. At this point the vTPM configuration is in place and the VM is ready to upgrade to Windows 11.

    I decided to run the Windows 11 installation assistant to validate the machine configuration, and after the validation the wizard will automatically progress to an online upgrade to Windows 11 at the same build (Enterprise/Professional) as your existing installation.

    Don’t forget to run Omnissa OSOT tool if you plan to use the virtual machine as an Horizon template.

  • Power Down an Omnissa Horizon Workload Cluster using vSAN Cluster Shutdown Wizard!

    Power Down an Omnissa Horizon Workload Cluster using vSAN Cluster Shutdown Wizard!

    I wanted to share the maintenance procedure I used recently for a customer. We needed to power down their Horizon workload clusters and gracefully place all instant clone desktops into a maintenance state. I wasn’t aware of the vSAN Shutdown Cluster wizard feature and the magic that it performs. It saved me a lot of time. Several of my colleagues weren’t aware of the feature either. I’ve shared the process below.

    Environment: vSphere 8.0U3 with vSAN, Horizon 8 2406, 100% Instant Clone.

    Prepare Omnissa Horizon for Maintenance

    The next steps explain how to power off instant clone pools, desktops, vCenter, and parent VMs. The process assumes all user sessions can be logged off and the pod will be unavailable. This is useful if you need to undertake cluster maintenance requiring a total power down of all ESXi hosts and Horizon workloads.

    1. Log off any active user sessions
      • via Horizon Admin console > Sessions > select all available sessions > Logoff Session. Await completion and make sure no active sessions are in use.
    2. Place all desktop pools into Disabled state:
      • via Horizon Admin console, select Desktops > select all pools > Disable Desktop Pools.

    At this point, all desktop pools are unavailable for use and there are no users logged onto the platform.

    The next step is to disable the Parent VMs. Although this step is optional, I include it here for awareness. From my testing, I found it prevented the instant clone VM’s from rebuilding when you shut them down.

    1. Disable Parent VMs
      • via Horizon Admin console > Servers > select the vCenter instant > More > Disable ParentVMs.

    This next step prepares the Horizon agent for powering off on an instant clone.

    1. Place all instant clone pool desktops into maintenance mode
      • Select Desktops > target pool > Machines > select all > More Commands > Enter Maintenance Mode

    By disabling provisioning, we avoid any new machines being rebuilt and generating problem VMs. We then power off all Horizon-managed VMs and the cluster hosts, and vSAN can be prepared for power down.

    1. Disable provisioning on all pools:
      • via Horizon Admin Console > Desktops > select all pools > Disable Provisioning.
    2. Shutdown all instant clone pool VMs
      • Select Desktops > target pool > Machines > select all > More Commands > Shutdown. Monitor the progress in vCenter.

    At this stage, all Horizon desktops and RDS hosts should be powered off, with vCenter performing no provisioning or Horizon-related actions.

    We can now continue with preparing the vSAN cluster and all hosts to shut down. The shutdown wizard will:

    • Turn off HA
    • Power off all system VMs
    • Disable cluster member updates from vCenter for all hosts in the cluster
    • Pause state changes of vSAN objects
    • Put each host into maintenance mode
    • Power off each host

    vSAN Cluster Shutdown Wizard

    1. Right click the Cluster object in vCenter > vSAN > Shutdown Cluster.

    Note, if Shutdown Cluster is greyed out, browse to Configure > vSAN > Services > Shutdown Cluster

    vSAN Restart Cluster

    After successful maintenance, power the hosts back on via their iDRAC/iLO/Management interface.

    All the hosts will power on and reconnect to vCenter in maintenance mode. To reinitialize vSAN and power the Horizon workloads back on, follow the below steps:

    1. Right click the cluster object vSAN > Restart Cluster.
    2. Once all hosts are participating in the cluster, select the cluster object > vSAN > Skyline Health > Test. Remediate any issues.

    Power on Horizon Workloads

    1. Enable ParentVMs for all desktop pool
      • via Horizon Admin Console > Servers > vCenter > More > Enable ParentVMs.
    2. Enable provisioning on all pools:
      • via Horizon Admin Console > Desktops > select all pools > Enable Provisioning.
    3. Exit Maintenance Mode for all desktop pools
      • Select Desktops > target pool > Machines > select all > More Commands > Exit Maintenance Mode
    4. Enable all desktop pools:
      • via Horizon Admin console > Desktops > select all pools > Enable Desktop Pools.

    At this stage all Horizon workloads should be powered on and healthy. Review the Problem vCenter VMs for any issues and test provisioning by deleting some instant clone VMs.

    Summary

    There was some trial and error involved when I initially approached this procedure. The majority of cluster maintenance rarely requires a full power down, so Horizon workloads can be vMotioned between operational hosts. In this instance, we can gracefully shut down all the instant clones. vCenter can manage the vSAN and host power down. There is no need to log on to the hardware until bring-up. I love getting feedback or other tips, so please comment below.

    aria cloud dem euc horizon linux microsoft nsx omnissa security vcf vmware vsan vsphere

    Leave a comment