All things IT, EUC and Virtualization

Tag: horizon

  • 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

  • How to completely uninstall Horizon 8 Connection Server

    How to completely uninstall Horizon 8 Connection Server

    I’ve used the below process several times during failed upgrades or downsizing of a Horizon pod. I’ve become strangely well versed with this procedure after working with a customer using Horizon 2111.2 and seeing various errors during upgrades that gave us no fix-forward choice, despite Omnissa support involvement.

    The process combines the Omnissa guidance and some tips from Omnissa GSS.

    Before Starting: Check FSMO Schema role owner

    This prerequisite ensures you don’t see replication errors between the remaining healthy pod members. This can happen if you were to accidentally uninstall a connection server that was holding the local/global schema roles. If required, seize the role owner to another connection server instance.

    Check the configuration and schema role owner and seize it to another connection server

    1. From a connection server instance, open LDP.exe > Connection > Connect > localhost
    2. Connection > Bind > Select Bind as currently logged on user
    3. Click View > Tree > select CN=Schema, CN=configuration from the drop-down menu.

    4. Search for the output for the text string “fsMORoleOwner “. The hostname of the owner will be displayed.

    5. To seize the role to another connection server, first log onto the server you wish to seize the role.

    Run the below command from an elevated command prompt. If the horizon pod has CPA enabled, there will be a Schema master for the local ADAM database. There will also be one for the global ADAM database. Remember to assign both roles to a different server.

    cd c:\Program Files\VMware\VMware View\Server\tools\bin\

vdmadmin -x -seizeSchemaMaster 
vdmadmin -x -seizeSchemaMaster -global

    Uninstall Connection Server

    6. Disable the connection server in Horizon Administration console by logging into https://ConnectionServer.domain.com/admin > Servers > Connection Servers > select target > Disable

    7. Uninstall the components from appwiz.cpl or Add/Remove Programs: Horizon Connection Server, HTML Component, VMwareVDMDS and VMwareVDMDSG.

    8. Remove VDM registry keys.

    Right click HKLM\Software\VMWare…\VDM> Permissions > Advanced > select ‘Replace all child object permission entries with inheritable permission entries from this object’ > Apply > Ok.

    Delete the parent key: HKLM\Software\VMWare…\VDM

    9. Open the local Certificate Store > Personal > VMware View Connection Server > Delete all certificates within the store.

    10. Reboot the server.

    Remove references to unwanted connection server via vdmadmin

    11. Use the below vdmadmin command to remove references to the unwanted connection server in the ADAM database. This command must be run from another connection server instance and is case sensitive.

    cd C:\Program Files\VMware\VMware View\Server\tools\bin\

vdmadmin -S -r -s <NetBIOSName>

    Check replication health

    11. From any connection server instance command prompt, check replication health on the local ADAM database. The local ADAM database uses port 389. You can also check the global ADAM database, which uses port 22389.

    repadmin /showrepl localhost:389
repadmin /showreplc localhost:22389

    The output should display replication connections between the existing local pod members, and for CPA, remote pods.

    12. Login to the connection server administration console and verify the node has been removed from the list of connection servers.

    Summary

    After removing the connection server, the installation directory in Program Files will still contain some configuration files. This is intentional. It can be useful if you choose to rebuild the installation. It is also helpful if you need to back up the old configuration.