vSphere 8 Update 3 and VVF for VDI licensing: what changes

Why this matters now

If you run Omnissa Horizon on vSphere 8 Update 3 with VMware vSphere Foundation for VDI (VVF for VDI) licenses, you are probably wondering whether the vSphere 8 end of general support on October 11, 2027 applies to you. Reading the dedicated Broadcom KB and the Omnissa FAQ on the combined offering, my interpretation is that this date does not apply to VVF for VDI.

With about a year to go, many customers are planning renewals and migrations. In this post I share how I interpret the official Broadcom and Omnissa documentation and what I would do in practice. I also use the acronyms VVF (VMware vSphere Foundation, the per-core offering sold by Broadcom) and VCF (VMware Cloud Foundation).

Links to all the official documents cited are at the end of the article.

The vSphere 8 deadline (and therefore 8.0 Update 3)

General support for vSphere 8 ends on October 11, 2027, followed by technical guidance until October 11, 2029. Update 3, released in July 2024, is the last update in this branch and follows the same dates.

Milestone

Date

vSphere 8.0 general availability

October 11, 2022

vSphere 8.0 Update 3 GA

Jun 25, 2024

End of general support

October 11, 2027

End of technical guidance

October 11, 2029

.

These dates apply to “classic” editions such as vSphere Enterprise Plus 8. For VVF for VDI, in my view, the picture is different, and the reference is Broadcom KB 428674.

As I read it, the KB states that the end-of-support date announced for vSphere Enterprise Plus 8 does not cover VVF for VDI or its vSphere component. As of the KB date (February 9, 2026), Broadcom states it has made no EOS or EOL announcements for VVF for VDI or any of its components.

The stated reason is formal but, in my opinion, important: Broadcom describes VVF for VDI as a standalone product with its own lifecycle and roadmap, not as a bundle of separate products. Any future dates should appear in the Broadcom Lifecycle Matrix.

The Omnissa FAQ (KB 6000381) points the same way. As I interpret it, the October 11, 2027 date does not affect vSphere 8 support for customers who bought Horizon with VVF for VDI, because its lifecycle is independent of vSphere Enterprise Plus purchased from Broadcom. As of this post (October 12, 2026), I have found no later KBs that change the picture.

I also checked the Broadcom Lifecycle Matrix: as of this post, it shows no end-of-support or end-of-life dates for VVF for VDI.

VVF for VDI licensing

VMware vSphere Foundation for VDI (VVF for VDI) is the infrastructure component of the combined offerings that Omnissa has sold alongside Horizon since May 2024. The reference is the Omnissa FAQ KB 6000381.

The points that matter most, in my reading of the FAQ:

•Contents: vSphere Enterprise Plus (per user), vCenter Standard, vSAN Enterprise and Tanzu. It does not include NSX, SDDC Manager or Aria Operations.
•Metric: per user, Named User or Concurrent User, with terms from 1 to 5 years. Each user nominally equals one VM, but you can run as many VMs as needed to serve the licensed users.
•vSAN: 100 GiB of raw capacity per physical core in the vSAN cluster, with no option to buy extra capacity. For more space you need to assign more cores or move to VVF/VCF. Broadcom’s VVF, by comparison, includes 250.
•Permitted use: virtual desktops, RDSH and the infrastructure VMs Horizon needs (Connection Servers, App Volumes Managers, events database, domain controllers for VDI users). Third-party applications and databases used by end users do not qualify.
•Support: Omnissa is always the first point of contact and escalates to Broadcom when needed.
•Separate product: despite the name, VVF for VDI and Broadcom’s VVF are different, independent SKUs.

Watch out for vSphere 9

From the Omnissa FAQ I understand that VVF for VDI includes only vSphere 8. Horizon 8 already supports VCF and VVF 9.x from releases 2503 and 2506, but to move to vSphere 9 the FAQ says you must buy VCF or VVF separately from Broadcom. Broadcom KB 439672 seems to confirm this: it lists only VVF and VCF as eligible for a 9.x upgrade.

What about VCF 9.1?

VCF 9.1 has been available since May 25, 2026, and version 9.1 also ships as VVF 9.1. As far as I understand, then, “standard” VVF licenses can be used on the 9.1 platform (Broadcom announcement).

What I took from the Broadcom documentation:

•One installer, two products: the VCF Installer deploys both VCF and VVF 9.1. Customers with a VCF entitlement can choose to install full VCF or just VVF (KB 440630).
•New License Server: in 9.1 licenses are managed by a dedicated appliance, mandatory for both VCF and VVF. Without the License Server and VCF Management Services, upgraded hosts stay in evaluation mode (KB 442133).
•Mixed licenses in one vCenter: 9.1 lets you manage several license types under a single vCenter, where separate instances were needed before (VMware blog).

On the Horizon side, according to the Omnissa Interoperability Matrix, vCenter Server 9.1 and ESX 9.1 are supported starting with Horizon 8 2603. Earlier releases, including 2512.1, are not listed as compatible with 9.1.

Horizon version

Supported vCenter Server

Supported ESX/ESXi

Horizon 2606

9.1, 9.0, 8.0 (GA, U1, U2, U3), 7.0 (GA, U1, U2, U3)

9.1, 9.0, 8.0 (GA, U1, U2, U3), 7.0 (GA, U1, U2, U3)

Horizon 2603

9.1, 9.0, 8.0 (GA, U1, U2, U3), 7.0 (GA, U1, U2, U3)

9.1, 9.0, 8.0 (GA, U1, U2, U3), 7.0 (GA, U1, U2, U3)

.

The sore point, in my view, remains VVF for VDI: from the KBs I have read, it does not entitle you to 9.x licenses, not even for 9.1. In my reading, running Horizon 2603 or later on vSphere 9.1 today requires a VVF or VCF entitlement purchased from Broadcom, with Horizon licensed without the VVF for VDI component.

What I would do in practice

1.Check the license type on every ESXi host: VVF for VDI, VVF, VCF or perpetual vSphere. The October 11, 2027 date means different things depending on the license.
2.With VVF for VDI, stay on vSphere 8.0 Update 3 and keep it patched; don’t plan a vSphere 9 upgrade without a VVF or VCF entitlement purchased from Broadcom.
3.Renew before the earliest expiration date: Horizon and VVF for VDI dates can differ. VVF for VDI keys have no grace period and Omnissa’s “do not deny” policy does not cover them: if they expire, the Horizon environment may stop working.
4.Separate non-VDI workloads: VMs that don’t directly serve Horizon need VVF or VCF licenses, even in the same cluster.
5.Check vSAN and monitoring: make sure you stay under 100 GiB per core, and remember that Aria Operations is not included and cannot be borrowed from a VVF or VCF license.
6.Check Horizon too: confirm in the Omnissa compatibility matrix that your Horizon 8 release is supported on the vSphere version you run and is not close to end of support.
7.Keep an eye on the KBs: the Broadcom Lifecycle Matrix and KBs 428674 and 6000381 are where any changes will appear.

Conclusions

As I interpret the KBs, Horizon customers on VVF for VDI can keep treating vSphere 8.0 Update 3 as their reference platform: I see no announced end-of-support date and, for now, it is also the only version included. The paradox is that the same license that seems to shield you from the 2027 deadline also blocks the move to vSphere 9.

Customers on traditional vSphere licenses, on the other hand, should circle October 11, 2027 in red. Either way, it is worth keeping an eye on the KBs cited, as they may be updated over time.

Sources

vSphere 8 Update 3 and VVF for VDI licensing: what changes

vSphere 8 Update 3 e licenze VVF for VDI: cosa cambia

Perché parlarne adesso

Chi gestisce Omnissa Horizon su vSphere 8 Update 3 con licenze VMware vSphere Foundation for VDI (VVF for VDI) si sta probabilmente chiedendo se la fine del supporto di vSphere 8, fissata all’11 ottobre 2027, valga anche per lui. Leggendo il KB Broadcom dedicato e la FAQ Omnissa sull’offerta combinata, la mia interpretazione è che quella data non si applichi a VVF for VDI.

Manca circa un anno alla scadenza e molti clienti stanno pianificando rinnovi e migrazioni. In questo post riporto come interpreto la documentazione ufficiale di Broadcom e Omnissa e cosa farei in pratica. Nel testo uso anche le sigle VVF (VMware vSphere Foundation, l’offerta per core venduta da Broadcom) e VCF (VMware Cloud Foundation).

I link a tutti i documenti ufficiali citati sono in fondo all’articolo.

La scadenza di vSphere 8 (e quindi di 8.0 Update 3)

Il supporto generale di vSphere 8 termina l’11 ottobre 2027, seguito dalla technical guidance fino all’11 ottobre 2029. Update 3, uscito a luglio 2024, è l’ultimo update di questo ramo e segue le stesse date.

Fase

Data

General availability vSphere 8.0

11 ottobre 2022

GA vSphere 8.0 Update 3

25 giugno 2024

Fine supporto generale

11 ottobre 2027

Fine technical guidance

11 ottobre 2029

.

Queste date valgono per le edizioni “classiche” come vSphere Enterprise Plus 8. Per VVF for VDI, a mio modo di vedere, il discorso è diverso, e il riferimento è il KB Broadcom 428674.

Per come lo leggo, il KB dice che la data di fine supporto annunciata per vSphere Enterprise Plus 8 non riguarda VVF for VDI né la sua componente vSphere. Alla data del KB (9 febbraio 2026) Broadcom dichiara di non aver fatto annunci di EOS o EOL per VVF for VDI o per i suoi componenti.

Il motivo indicato è formale ma, secondo me, importante: Broadcom descrive VVF for VDI come un prodotto a sé, con ciclo di vita e roadmap propri, e non come un insieme di prodotti separati. Eventuali date future dovrebbero comparire nella Broadcom Lifecycle Matrix.

Anche la FAQ Omnissa (KB 6000381) va nella stessa direzione. Per come la interpreto, la data dell’11 ottobre 2027 non tocca il supporto vSphere 8 per chi ha acquistato Horizon con VVF for VDI, perché il suo ciclo di vita è indipendente da quello di vSphere Enterprise Plus acquistato da Broadcom. Alla data di questo post (12 ottobre 2026) non ho trovato KB successivi che cambino il quadro.

Ho controllato anche la Broadcom Lifecycle Matrix: alla data di questo post non risultano date di fine supporto o di fine vita per VVF for VDI.

Le licenze VVF for VDI

VMware vSphere Foundation for VDI (VVF for VDI) è la componente infrastrutturale delle offerte combinate che Omnissa vende insieme a Horizon dal maggio 2024. Il riferimento è la FAQ Omnissa KB 6000381.

I punti che, dalla mia lettura della FAQ, contano di più:

•Contenuto: vSphere Enterprise Plus (per utente), vCenter Standard, vSAN Enterprise e Tanzu. Non include NSX, SDDC Manager né Aria Operations.
•Metrica: per utente, Named User o Concurrent User, con durate da 1 a 5 anni. Ogni utente vale nominalmente una VM, ma si possono usare tutte le VM necessarie a servire gli utenti licenziati.
•vSAN: 100 GiB di capacità raw per core fisico del cluster vSAN, senza possibilità di acquistare capacità aggiuntiva. Per avere più spazio bisogna assegnare più core o passare a VVF/VCF. La VVF di Broadcom, per confronto, ne include 250.
•Uso consentito: desktop virtuali, RDSH e le VM infrastrutturali che servono a Horizon (Connection Server, App Volumes Manager, database eventi, domain controller degli utenti VDI). Applicazioni e database di terze parti usati dagli utenti non rientrano.
 •Supporto: il primo punto di contatto è sempre Omnissa, che scala a Broadcom quando serve.
•Prodotto distinto: nonostante il nome, VVF for VDI e la VVF di Broadcom sono SKU diversi e indipendenti.

Attenzione a vSphere 9

Dalla FAQ Omnissa capisco che VVF for VDI include solo vSphere 8. Horizon 8 supporta già VCF e VVF 9.x dalle release 2503 e 2506, ma per passare a vSphere 9 la FAQ indica di acquistare VCF o VVF separatamente da Broadcom. Il KB Broadcom 439672 mi sembra confermarlo: per l’upgrade a 9.x indica come idonee solo VVF e VCF.

E VCF 9.1?

VCF 9.1 è disponibile dal 25 maggio 2026 e la versione 9.1 esiste anche come VVF 9.1. Per quanto ho capito, quindi, le licenze VVF “standard” si possono usare sulla piattaforma 9.1 (annuncio Broadcom).

Cosa ho ricavato dalla documentazione Broadcom:

•Stesso installer, due prodotti: il VCF Installer distribuisce sia VCF sia VVF 9.1. Chi ha un entitlement VCF può scegliere se installare VCF completo o solo VVF (KB 440630).
•Nuovo License Server: in 9.1 le licenze sono gestite da un’appliance dedicata, obbligatoria sia per VCF sia per VVF. Senza License Server e VCF Management Services gli host aggiornati restano in licenza di valutazione (KB 442133).
•Licenze miste nello stesso vCenter: 9.1 permette di gestire più tipi di licenza sotto un unico vCenter, mentre prima servivano istanze separate (blog VMware).

Lato Horizon, secondo la Interoperability Matrix di Omnissa, vCenter Server 9.1 ed ESX 9.1 sono supportati a partire da Horizon 8 2603. Le release precedenti, inclusa la 2512.1, non risultano compatibili con la 9.1.

Versione Horizon

vCenter Server supportati

ESX/ESXi supportati

Horizon 2606

9.1, 9.0, 8.0 (GA, U1, U2, U3), 7.0 (GA, U1, U2, U3)

9.1, 9.0, 8.0 (GA, U1, U2, U3), 7.0 (GA, U1, U2, U3)

Horizon 2603

9.1, 9.0, 8.0 (GA, U1, U2, U3), 7.0 (GA, U1, U2, U3)

9.1, 9.0, 8.0 (GA, U1, U2, U3), 7.0 (GA, U1, U2, U3)

.

La nota dolente, a mio avviso, resta VVF for VDI: dalle KB che ho letto non dà diritto a licenze 9.x, nemmeno per la 9.1. Secondo la mia lettura, per portare Horizon 2603 o successivo su vSphere 9.1 oggi serve un entitlement VVF o VCF acquistato da Broadcom, con Horizon licenziato senza la componente VVF for VDI.

Cosa farei in pratica

1.Verifica il tipo di licenza di ogni host ESXi: VVF for VDI, VVF, VCF o vSphere perpetuo. La scadenza dell’11 ottobre 2027 cambia significato a seconda della licenza.
2.Con VVF for VDI resta su vSphere 8.0 Update 3 e mantienilo aggiornato con le patch correnti; non pianificare l’upgrade a vSphere 9 senza un entitlement VVF o VCF acquistato da Broadcom.
3.Rinnova prima della scadenza più vicina: le date di Horizon e di VVF for VDI possono essere diverse. Le chiavi VVF for VDI non hanno periodo di grazia e la policy “do not deny” di Omnissa non le copre: se scadono, l’ambiente Horizon può smettere di funzionare.
4.Separa i carichi non VDI: le VM che non servono direttamente Horizon vanno coperte con licenze VVF o VCF, anche nello stesso cluster.
5.Controlla vSAN e monitoraggio: verifica di stare sotto i 100 GiB per core e ricorda che Aria Operations non è incluso né può essere preso in prestito da una licenza VVF o VCF.
6.Controlla anche Horizon: verifica nella matrice di compatibilità Omnissa che la tua release di Horizon 8 sia supportata sulla versione di vSphere che usi e che non sia vicina alla fine del supporto.
7.Tieni d’occhio i KB: la Broadcom Lifecycle Matrix e i KB 428674 e 6000381 sono i punti in cui comparirà qualsiasi novità.

Conclusioni

Per come interpreto le KB, chi usa Horizon con VVF for VDI può continuare a considerare vSphere 8.0 Update 3 la piattaforma di riferimento: non vedo una data di fine supporto annunciata e, per ora, è anche l’unica versione inclusa. Il paradosso è che la stessa licenza che sembra mettere al riparo dalla scadenza del 2027 impedisce il passaggio a vSphere 9.

Chi ha licenze vSphere tradizionali, invece, ha l’11 ottobre 2027 come data da cerchiare in rosso. In ogni caso vale la pena tenere d’occhio le KB citate, che possono essere aggiornate nel tempo.

Fonti

vSphere 8 Update 3 e licenze VVF for VDI: cosa cambia

Converge vSphere 8 to VMware vSphere Foundation 9.1.x

.

ATTENTION!!

This is a document that was created from a Home Lab.

My Home Lab:

vSphere 8u3i

One vCenter

Two ESXi hosts (Nested)

One NFS datastore (TrueNAS)

Official Documentation

Source Converge a vCenter Instance and ESX Hosts to vSphere Foundation

Verify upgrade path from Product Interoperability Matrix

Requirements

Prepare a temporary IP for vCenter

Prepare five FQDNs and register on DNS (with reverse) for:

1 VCF Operation

3 VCF Management Services

1 VCF License server

And ten IP addresses (minimum) for Management Services

.

UPGRADE STEP

• vCenter Upgrade
• Install VCF Installer
◦ Install VCF Operations
◦ Install VCF Management Services
• Upgrade ESXi
◦ Upgrade ESXi Hosts
◦ Upgrade vDS
◦ Upgrade VMware Tools
◦ Upgrade Virtual HW

.

vCenter Upgrade

You must deploy the new vCenter in the vSphere Cluster that you need to upgrade at VVF. In my test, I deployed the new vCenter in another vSphere infrastructure, and the VCF Installer reports an error.

The vCenter upgrade process is a classic vCenter upgrade.

.

Download vCenter 9.1 from the Broadcom Support Portal

Dedicate a temp IP address and FQDN name (need to register in DNS) for deployment

Mount the downloaded ISO on a bridge PC or Virtual Machine

Start the UI installer

 .

Select upgrade

 .

Start the deployment

.

Deploy the VCF Installer appliance.

I covered this installation in another Post; read this post:

Start a New vSphere Foundation Deployment by Using the VCF Installer Deployment Wizard – BIOLNX

Deploy VCF Operations

Log in to VCF Installer

Download bundles for the VCF Installer appliance (Read this post: Start a New vSphere Foundation Deployment by Using the VCF Installer Deployment Wizard – BIOLNX)

Use VCF Installer to deploy your vSphere Foundation platform.

.

.

Select I have an existing vCenter

Select the network infrastructure for the Management Services and Operations component in my Home Lab. I choose the network where the VM is deployed (otherwise, create a dedicated network; check the firewall configuration in the official documentation)

.

.

Dedicate IP address and FQDN (with reverse)

VVFOPUP.pollaio.lan 192.168.80.110

VVFMNGSUP01.pollaio.lan 192.168.80.111

VVFMNGSUP02.pollaio.lan 192.168.80.112

VVFMNGSUP03.pollaio.lan 192.168.80.113

VVFLICUP01 192.168.80.114

.

.

We enter the FQDN names of the objects; if entered correctly in the DNS (with the reverse), they have a green tick

.

In my case, if the new vCenter is not deployed in the cluster that we want upgrade, we see an error.

.

After vCenter migrating to the vSphere cluster object for the upgrade

.

Save the Password!!!!

Start the VCF Operation appliance installation

.

At the end of VCF operation Installation, we can log in to the VCF Operations UI

Now we can configure the License (See this post)

Register VCF Operations and Your License Server in Connected Mode – BIOLNX

.

Upgrade ESXi

Log in to vCenter and select the Lifecycle Manager

After some time, under Software Depot, the new ESXi version appears

Now we create a new Image; go to Image Library and select Create Image

 

Validate and save

.

Go to Inventory

Select the cluster and after updates

.

Now the upgrade will start if the cluster is correctly configured

Upgrade Virtual Distributed Switch

.

.

Next step

Upgrade VMware Tools

Upgrade Virtual Hardware

.

Converge vSphere 8 to VMware vSphere Foundation 9.1.x

Register VCF Operations and Your License Server in Connected Mode

In my previous post, I walked through the process of deploying VMware vSphere Foundation (VVF) in my Home Lab using the VCF Installer, from infrastructure preparation to the initial bring-up of the environment. [If you missed it, you can find it here:

Start a New vSphere Foundation Deployment by Using the VCF Installer Deployment Wizard – BIOLNX

With the deployment up and running, the next step is licensing the environment. In this post, I cover how I activated the VVF licenses, the options available, and a few gotchas I ran into along the way — useful if you’re following the same path in your own lab and want to move from a freshly deployed environment to a fully licensed one.

 

Log in to VCF Operations

From the navigation bar at the top, click Manage and in the left navigation pane, click Licensing -> Licenses & Registration

 

In the Register & License VCF Operations pane, click Continue

 

 

The Register and License VCF Operations workflow appears.
The first step of the procedure is complete because a license server is automatically deployed during a new VCF Operations 9.1 deployment and an upgrade to VCF Operations 9.1.

In the Select Connection Mode card, select
Start, and click Continue.

 

 

Navigate to the Registration section.

Get an activation code for your registration. In the Get Activation Code from VCF Business Services console card, click Start

 


The VCF Business Services console opens in a new tab.

 

 

Log in to the VCF Business Services console by using your Broadcom Support Portal credentials.

Select the Site ID to which you want to register this VCF Operations instance, and click
Next. If you have only one site, it is selected by default.

In the VCF Business Services console, оn the Register & License VCF Operations page, navigate to the Registration part of the registration workflow.

In the Name VCF Operations pane, click Start, enter a unique display name for your
VCF Operations instance, and click Save

The FQDN is only saved if you do not enter another display name. If you change the FQDN with another display name, the connectivity between
VCF Operations
and the VCF Business Services console is not impacted. You can change the display name at any time after the registration.

In the Generate Activation Code card, click Start

 

.

A dialog box with the activation code appears.

 

 

Click Copy (and save the info into a notepad file) Verify that you copied the code, and click Finish

Navigate to the VCF Operations instance, and upload the activation code. In VCF Operations, in the Enter Activation Code card, click Start

 


A dialogue box appears.

In the text field, paste the activation code, and click Activate

 

 

 

In the Add Licenses from VCF Business Services console card, click Start

 

 

The VCF Business Services console opens in a new tab.

In the VCF Business Services console, add licenses to your license servers.

 

To complete the registration process, you must first add licenses to each license server.

In the Add Licenses section of the registration workflow, in the card for the respective license server, click Start
On the Allocate Licenses page, enter a display name for the license server.

If you want to split the default license or change a license’s capacity before assigning it, click the vertical ellipsis next to the license. To split the default license, select it from the list and click Create. Enter a name and license capacity for the split license. To change the capacity of a split license, enter the capacity for the license in the New Capacity column. Click Save.

Select licenses from the table to add to the license server, and click Confirm.
To license your environment, you must add at least one primary license to the license servers. You can add licenses during the registration process, or at any time after that.

 

   

 

Download the license file in the VCF Operations instance.

Navigate to the Licenses page.

In the Add Licenses to License Servers section, in the Download card, click
Download.

 

 

On the Register and License VCF Operations page, click Finish

 

 

 

Now we can assign the license to vCenter. Select Assign Primary License after checking the vCenter instance to assign the license.

 

 

 

Select the license to assign and click Assign

 

 

 

Now the assigned license Core Count and Host Count are Green (if you have sufficient licenses to assign)

 

 

 

From vCenter, by accessing from the vSphere client, we can show the license status under Administration -> License -> Version 9+ License

 

 

 

.

Register VCF Operations and Your License Server in Connected Mode

Start a New vSphere Foundation Deployment by Using the VCF Installer Deployment Wizard

For a long time, I wanted to get my hands on VMware vSphere Foundation (VVF) and understand closely how the deployment process has changed with the introduction of the VCF Installer. Thanks to a few days off and a desire to experiment, I decided to dedicate my Home Lab to this project, retracing the entire installation process step by step, from preparing the infrastructure to the first boot of the environment.

In this post, I tell you how I set up the deployment, what hardware and network resources I used, the configuration choices made along the way and, of course, the difficulties encountered (and how I solved them) during the installation via VCF Installer. The goal is to share a practical experience useful to those who want to approach VVF starting from a laboratory environment, without the complexity (and costs) of an enterprise deployment.

In this first post, we will see the installation; in the next posts, we will install/activate the licenses and install the Log component

.

Being a home lab, my environment will consist of nested ESXi Hosts; here are some details:

Physical HW

ESXi Nested

Two VMs where I install my ESXi to 9.1

Check the Machine Certificate for each ESXi; the certificate needs to trust the ESXi FQDN name.

Storage 

As NFS, I created a TrueNAS VM that resides on SSD disks

Network of ESXI nested:

–One connected to my physical network cards of the server where the port group (VM Network) is present, where I will put the Management and Workload VM part of my ESXi servers
–One that is not connected to physical network cards and where I create a port group for the vMotion part
–One not connected to physical network cards and where I create a port group (NFS) for the NFS part (where, in addition to ESXi, I attach a network card for my TrueNAS)

.

Required resources

.

.

.

.

.

.

As you can see, we have, in addition to the vCenter add-ons, which are:

License Server

A part of VCF Operations. Provides secure and integrated license management for your platform.

vCenter

To say that we all know him well

VCF Operation

VMware Cloud Foundation Operations® (formerly VMware Aria Operations) or VCF Operations helps your organisation build, manage, operate, and secure your private cloud infrastructure by deploying and maintaining its fleet-level components, providing visibility and enhanced performance across the workload and infrastructure stack, and helping your organisation stay compliant with regulatory standards and organisational guidelines.

VCF Management Services

VCF 9.1 introduces VCF management services to provide a unified architecture for centralised lifecycle and operational functionalities. The VCF services runtime instance of the first VCF Instance hosts the fleet-level VCF management services components that perform global operations and the instance-level components for that VCF Instance. Every VCF Instance has a VCF services runtime instance that hosts the instance-level VCF management services that run local tasks. This foundation allows for a unified architecture, simplified lifecycle management, and streamlined backup and recovery of all hosted components.

For the VVF in management servers, we have:

Fleet lifecycle

Log management (to be installed in DAY+1)

SDDC lifecycle

Software depot

Telemetry

VCF services runtime

More details: Components in VCF and vSphere Foundation

.

.

.

.

The steps we’ll take are:

1-Installing ESXi (we won’t cover it in this post)
2-Deploying the VCF installer
3-Configuring the DEPOT
4-Deploying VVF

VCF installer installation

.

Log in to Broadcom Support Portal https://support.broadcom.com/ and Download VCF Installer

.

The next step is to deploy the OVA to ESXi or VMware Workstation

.

.

.

.

.

.

 Once the installation of the OVA is finished, access the URL with the IP or FQDN and log in with the admin@local account and password you set during the deployment

.

 

Configure Depot Connection and download the installation Binaries

.

.

.

.

.

Configuration of the repository for downloading the software for installation (vCenter, ESXi, etc.)

A token must be generated from the portal vcf.broadcom.com

To log in from the Support Portal, select Version 9. Licenses can be found

.

.

.

1.Log in to the VCF Business Services console (vcf.broadcom.com)

.

.

Go to the VCF Installer and create the ID of the depot to upload to the portal

.

.

.

Return to the portal and upload the depot ID to the page that opened

.

.

Copy the Activation code and enter it on the vcf installer screen

.

Let’s download the binaries of the VMware vSphere fountadion

.

.

Once the download is complete, we will see everything “Success”

.

Now I have two ESXi Hosts (in my case, nested vvfesxi01.pollaio.lan and vvfesxi02.pollaio.lan) at version 9.1.0, just installed with no particular configuration (No Storage and more)

Deploy VVF

Let’s proceed with the deployment, selecting “Deployment Wizard” from the VCF Installer

.

.

Let’s define the FQDNs for the various components (vCenter…), and I must obviously have already entered the association with the IP in my DNS (always remember the reverse of the DNS)

.

I run the validate all

.

.

.

Now let’s save and continue

.

Select the version of VVF and DNS, NTP server and DNS suffix

.

We add the ESXi hosts

.

Caution: Verify the certificates correctly on the ESXi hosts, and that the hostname is populated correctly

.

Let’s configure the network, where we will enter the configurations for the VVF management, vMotion and NFS part.

Start a New vSphere Foundation Deployment by Using the VCF Installer Deployment Wizard

SaaS License Activation for Omnissa Horizon without EDGE Gateway

In the latest versions of Horizon, it is recommended to use the SaaS subscription, which requires the installation of an EDGE Gateway component generated by the Omnissa Connect portal under Horizon in the customer section.

This involves the need to install a Linux VM on our vSphere environment; not for everyone is this feasible:

–Need not have connections with Cloud services
–Resource savings (CPU, RAM and disk space)
–Test environments and any POCs
–Or, as in my case, I must test the new versions of Horizon

For this last point and since I need to install version 2606 as a test, I decided to explain how to do it… step by step.

Installed my connection server on a Windows Server 2025. The first thing to do is access the administration console and activate the license:

.

.

.

Verify that you have received the activation email or that you have a Horizon SaaS subscription and that you have access to the Connect Omnissa portal

So you must log in to the Omnissa Connect portal (by opening a TAB from the Browser you are using to access the Horizon console) and authenticate on connect.omnissa.com and keep the tab open.

.

.

Enter accounts, passwords and if necessary, do MFA

.

.

A new tab will automatically open with the login already made

.

Now run

The following message will appear

.

.

And on the Horizon console, the license status will be as follows

.

.

Two important points

–Mark your calendar to reactivate your license (in the same way) before 90 days have passed
–You can switch to a license via the EDGE Gateway by simply installing the EDGE Gateway (Follow the specific procedure)

.

.

.

.

SaaS License Activation for Omnissa Horizon without EDGE Gateway

App Volumes: VHD in-Guest vs Standard Mode

Technical comparison and recommended use cases

.

.

INTRODUCTION

Omnissa App Volumes provides two distinct modes for delivering applications to Horizon users: the standard mode (VMDK/VMFS-based) and VHD in-guest mode, introduced to support non-persistent OS scenarios and advanced Instant Clone environments.

The choice between the two modes directly affects performance, scalability, and infrastructure requirements.

MODE COMPARISON

Standard Mode (VMDK)

• VMDK disk attach via vCenter API

• Mandatory needs a vSphere infrastructure as a prerequisite

• Limited support for multi-hypervisor environments

• Dependency on shared vSphere datastores

• Compatible with all Horizon desktop types

VHD in-Guest

• VHD mounted directly inside the guest OS

• Hypervisor-independent

• Compatible with Azure, AVD and physical environments

• VHD exposed via SMB share or UNC path

• Application packages and writable volumes are stored in a high-performance file share

• Compatible with all Horizon desktop types

TAKE NOTE! We can select the mode (VMDK or VHD) when installing the first App Volumes Manager. We can’t switch from VMDK to VHD mode, or from VHD to VMDK mode, after the first configuration.

VHD IN GUEST ARCHITECTURE

In this mode, the App Volumes Agent inside the guest mounts the VHD file from the configured UNC path using native Windows APIs. The AppStack content is then layered onto the filesystem via the App Volumes kernel filter driver, making applications available without extraction.

.

.

Note: In VHD in guest mode, the AppStack .vhd file must be reachable via UNC path from the guest. Network latency to the share directly affects mount times.

WHEN TO CHOOSE VHD IN-GUEST

1

Reducing vCenter dependency

Environments with restrictive policies on vCenter API access or multi-cloud architectures.

.

2

Physical desktops or RDSH

Scenarios where the workload runs on bare metal or RDS servers without vSphere hypervisor.

.

3

Azure Virtual Desktop (AVD) environments

Non-vSphere infrastructure; inability to attach VMDK via vCenter.

.

.

App Volumes: VHD in-Guest vs Standard Mode

Microsoft Azure Edge and Omnissa-Managed Enterprise App Registration

My Initial Experience

During the preparation activities for deploying a new Horizon Cloud on Azure environment, I was reading the official documentation at

https://docs.omnissa.com/bundle/UsingManagingHorizonCloud/page/DeployingaMicrosoftAzureEdge.html

and discovered the presence of a new and recommended deployment method: the “Omnissa-managed” mode.

I immediately wanted to test it, but in my Omnissa Connect console, this option wasn’t yet available.

.

I contacted support and they informed me that the feature would be released soon, but if I wanted to use it immediately, they could enable it through a Feature Flag. Obviously, I couldn’t say no to that opportunity! Once they provided my ORG ID and enabled the flag, the new option appeared while I was creating the EDGE in the Primary Provider section.

This is my journey with the Omnissa-managed method, and I’d like to share what I learned about this game-changing approach.

.

.

Introduction

Horizon Cloud on Microsoft Azure is evolving, and Omnissa has introduced a significant security enhancement that every administrator should know about. The new Omnissa-managed Enterprise App registration method represents a paradigm shift in how organizations handle service principal credentials. If you’re planning a Horizon Cloud deployment on Azure, understanding the difference between this new approach and the traditional manual method could be crucial for your security posture.

The Security Challenge

Historically, deploying Horizon Edge in Horizon Cloud on Azure required organizations to create and manage their own Azure Enterprise Applications. This approach meant handling sensitive service principal secrets—credentials that need to be carefully managed, rotated, and protected. The more systems that have access to these secrets, the higher the security risk.

The traditional single-tenant deployment method (Manual Enterprise App registration) placed the responsibility of secret management squarely on the customer organization. While this approach continues to be supported, it introduces additional operational overhead and potential security vulnerabilities.

Enter Omnissa-Managed

Omnissa has introduced a new Enterprise App registration method that fundamentally changes who manages the service principal secrets.

Key Benefits

1. Enhanced Security

Organizations no longer need to provide their sensitive secrets key information to Omnissa or manage it themselves in the context of Horizon Cloud deployment. The credentials remain under Omnissa’s direct management, reducing the attack surface and potential points of compromise.

2. Simplified Administration

Say goodbye to manual Enterprise Application creation and complex permission configurations. With Omnissa-managed registration, the setup process is streamlined. Omnissa handles the heavy lifting—you focus on deployment.

3. Reduced Operational Overhead

No more worrying about secret rotation schedules, credential lifecycle management, or complex authentication flows. Omnissa manages these operational concerns, freeing your team for other critical tasks.

4. Enterprise-Grade Security

By centralizing secret management with Omnissa, organizations benefit from enterprise-grade security practices, regular audits, and dedicated security expertise that Omnissa brings to the table.

Manual Registration: Still Available

For organizations with specific requirements or legacy configurations, the traditional single-tenancy method remains available. This manual Enterprise App registration approach allows organizations to maintain full control over their authentication setup if needed. However, unless you have specific compliance or architectural reasons, the manual approach introduces unnecessary complexity.

The Recommendation

Omnissa-managed is the recommended method for all new Horizon Cloud deployments on Azure. Omnissa has taken the guesswork out of enterprise app management and elevated the security baseline for everyone using Horizon Cloud.

If you’re currently on the manual registration path, consider planning a migration to the Omnissa-managed approach. The transition offers immediate security benefits with reduced administrative overhead.

Getting Started

Ready to leverage Omnissa-managed registration for your deployment? The process is straightforward:

1.Initiate your Horizon Edge deployment in Omnissa Connect
2.Select the Omnissa-managed option during the Primary Provider setup

3.Link your Azure subscription using the consent flow (click Consent Link)

4.Authorize Omnissa to create the Enterprise Application

Insert Azure Subscription credentials (in my case Global Admin User)

Now we can see the new enterprise application with Omnissa Logo.

.

.

.

5.Assign necessary roles (Contributor or appropriate custom roles) to the subscription

First, verify the role assignment status in Omnissa Connect:

.

.

Get the Object ID from the Omnissa Enterprise App:

.

.

Go to your subscription and select IAM (Identity & Access Management):

.

Select add role assignment

Search Contributor in Previleged admnistrator Role

Select Member and ad the Enterprise Application Object ID or name

6.Refresh and verify the role assignment in Omnissa Connect

Return to the Omnissa Connect wizard. If the role is still showing as “Role not Assigned”

.

Go back to the previous step and return to refresh (Omnissa Engineer should add a refresh button)

.

.

.

At this point, you’re ready to choose whether your EDGE will be an AKS (Azure Kubernetes Service) or a Virtual Machine.

The Omnissa-managed Enterprise Application has been successfully created and configured with the naming convention omnissa-horizoncloud-app-1, marked with Omnissa’s branding for easy identification.

.

.

Conclusion

The shift to Omnissa-managed Enterprise App registration represents a meaningful step forward in cloud security practices. By removing the burden of service principal secret management from customer organizations, Omnissa enables secure, simplified, and scalable Horizon Cloud deployments on Microsoft Azure.

Whether you’re planning a new deployment or evaluating your current infrastructure, the Omnissa-managed method deserves your attention. It’s security and simplicity working in harmony—exactly what modern cloud deployments should be.

Microsoft Azure Edge and Omnissa-Managed Enterprise App Registration

Streamline Your Enterprise with Omnissa Connect and Microsoft Entra ID

A guide to enterprise federation, single sign-on, and modern identity management

What is Omnissa Connect?

Omnissa Connect is a centralized platform service that provides IT administrators and users with a single sign-on (SSO) gateway to access and manage all Omnissa services, such as Workspace ONE and Horizon. It streamlines workflows by unifying access, identity management, and service onboarding into one intuitive interface.

Key features of Omnissa Connect include:

•Unified Identity: Single sign-on capabilities and seamless integration with third-party identity providers like Microsoft Entra ID and Okta through the Omnissa Identity Service
•Centralized Administration: IT owners can securely assign roles, set multi-factor authentication (MFA) policies, and manage OAuth applications or API tokens across the entire Omnissa ecosystem
•Subscription Management: Visibility into all Omnissa service subscriptions from a single location

What is Microsoft Entra ID?

Microsoft Entra ID (formerly Azure Active Directory) is Microsoft’s cloud-based identity and access management service. It’s the foundation that millions of organizations use to manage employee identities, secure access to applications, and protect their digital assets.

Entra ID is likely already at the heart of your organization if you use:

•Microsoft 365 (Office 365, Teams, SharePoint)
•Azure cloud services
•Dynamics 365 or other enterprise applications
•Single sign-on (SSO) solutions for SaaS applications

Why Integrate Omnissa Connect with Microsoft Entra ID?

Connecting Omnissa Connect with Microsoft Entra ID through enterprise federation creates a powerful identity ecosystem. Here’s what you gain:

Single Sign-On (SSO)

Your users log in once with their corporate credentials and automatically gain access to Omnissa Connect—no separate usernames or passwords to remember.

Automatic User Provisioning

When you add or remove users in Entra ID, they’re automatically synced to Omnissa Connect. No manual account creation, no forgotten deprovisioning, no stale user accounts cluttering your systems.

Centralized Security

Manage all user access, permissions, and security policies from one central location. Apply multi-factor authentication (MFA), enforce password policies, and monitor access across your entire organization from Entra ID.

Reduced IT Overhead

Your IT team spends less time managing separate identity systems, resetting passwords, and troubleshooting access issues. Everything is automated and synchronized.

Improved Compliance

Maintain detailed audit logs of who accessed what and when. Meet regulatory requirements for access control and identity management with confidence.

A Real-World Example

Before Federation:

Sarah joins your company. The IT team manually creates accounts in Omnissa Connect, Microsoft 365, and four other systems. Sarah has to memorize 5 different passwords. When Sarah leaves three years later, the team forgets to deactivate her Omnissa Connect account, leaving a security gap.

After Federation:

Sarah’s first day: HR adds her to Entra ID. Omnissa Connect automatically creates her account and grants the right permissions. She logs in with her corporate email and password—the same one she uses for everything else. On her last day: HR removes her from Entra ID. Within seconds, Omnissa Connect and all other connected systems automatically deactivate her access. No manual steps. No forgotten accounts. No security gaps.

Is This Right for Your Organization?

Enterprise federation between Omnissa Connect and Entra ID is ideal if your organization:

•Already uses Microsoft Entra ID or Azure Active Directory
•Wants to simplify identity management and reduce IT burden
•Has multiple employees and wants to automate user provisioning
•Needs strong security controls and audit capabilities
•Is undergoing digital transformation and standardizing on cloud-based identity solutions

What’s Involved?

Configuring enterprise federation requires several steps—from verifying your domain to setting up the connection between systems to testing everything works smoothly. The process typically involves:

•Domain verification to prove your organization owns the domain
•Creating and configuring an Enterprise Application in Microsoft Entra ID
•Setting up authentication protocols and user attribute mapping
•Testing the setup before activating federation for all users
•Notifying users and helping them transition to the new authentication method

The Complete Step-by-Step Guide

While this overview covers the benefits and concepts, implementing enterprise federation involves detailed technical configuration. The complete guide is a comprehensive document with in-depth instructions, detailed screenshots, and step-by-step walkthroughs for both Omnissa Connect and Microsoft Entra ID configuration. Due to its length and technical depth, I share it directly with clients and organizations ready to implement the solution.

The complete guide includes:

•Detailed screenshots and instructions for each configuration step
•Exact fields to fill in on both Omnissa Connect and Entra ID

.

Ready to streamline your organization’s identity management?

If your organization is ready to implement enterprise federation between Omnissa Connect and Microsoft Entra ID, I’m here to help. Whether you need guidance on setup, troubleshooting during configuration, or best practices for managing the transition, I can provide a complete, step-by-step implementation guide tailored to your needs.

Get in touch to request the full technical guide and start your journey toward simplified, centralized identity management.

.

📧 Contact me for the complete implementation guide

Let’s simplify your organization’s identity and access management together.

Streamline Your Enterprise with Omnissa Connect and Microsoft Entra ID

Horizon 2603 is here!

A new version of Omnissa Horizon has just been released, and 2603 is not just another update — it’s an ESB (Extended Service Branch) release and marks an important transition point for many environments.

🔗 Release Notes:
https://docs.omnissa.com/bundle/horizon8-rnV2603/page/Horizon8-ReleaseNotes.html


First things first: end of support for vSphere 7

Let’s start with something critical:

Horizon 2603 ESB no longer supports vSphere 7.x

  • Horizon 2512 was the last release supporting vSphere 7
  • Starting from 2603, vSphere 8 is the required platform

This means one thing:
If you’re planning to move to this ESB, your vSphere upgrade is no longer optional — it’s mandatory

This is a key architectural checkpoint, especially for environments that have been delaying the jump to vSphere 8. (vSphere 7 is end of support)


Event Database + Integrated Authentication (finally!)

Now, let’s talk about one of my favorite new features.

Horizon 2603 introduces the ability to configure the Event Database on Microsoft SQL Server using Active Directory identities (Domain User with Integrated Authentication).

No more SQL authentication.

Why this matters:

  • Eliminates stored SQL credentials
  • Aligns with enterprise security best practices
  • Simplifies credential lifecycle management
  • Improves compliance and auditability

From a design perspective, this is a very welcome step toward a more secure-by-default architecture.

 Final thoughts

This release is not just about new features — it’s about setting a new baseline:

  • ✔️ ESB = long-term stability
  • ✔️ vSphere 8 as the standard
  • ✔️ Stronger security integration

If you were waiting for the “right moment” to modernize your Horizon platform… this is probably it.


 In the next posts, I’ll dive deeper into the other new features and changes introduced in Horizon 2603 — stay tuned 👀


Need help testing or upgrading?

If you’re planning to:

  • Test Horizon 2603
  • Upgrade your existing environment
  • Move from vSphere 7 to vSphere 8 or 9

Feel free to reach out — happy to help with assessments, design, and upgrade strategies.


Have you already started testing Horizon 2603?
Or are you still planning your vSphere 8 migration?

Let’s discuss 

Horizon 2603 is here!