Uncategorized

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

fabio1975Leave a comment

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

fabio1975Leave a comment

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

Checking Horizon Cloud Services Connectivity from Horizon Edge Gateway

fabio1975, , , , , , Leave a comment

It is important to remember that the Horizon Edge Gateway is not only used for enabling integration with Horizon Cloud Services, but it is also required in many environments for Horizon subscription licensing.

In modern deployments of Omnissa Horizon, subscription licenses are delivered through the Horizon Cloud control plane rather than through traditional license keys. To enable this mechanism, each Horizon pod must be connected to the cloud service using a Horizon Edge Gateway appliance.

When using subscription-based licensing:

• The Horizon Edge Gateway connects the Horizon pod to Horizon Cloud Services.
• The control plane synchronizes and delivers the Horizon license entitlement.
• No manual license key entry is required on the Connection Server.

For this reason, outbound connectivity to the Horizon Cloud endpoints is critical, not only for cloud services but also for maintaining a valid licensing state in subscription-based environments.

If the Edge Gateway cannot reach the required endpoints due to firewall restrictions, proxy configuration, or SSL inspection, administrators may experience issues such as:

• License synchronization failures
• Horizon services reporting licensing errors
• Problems during onboarding or control plane communication

In contrast, environments using term/perpetual license keys entered directly in the Horizon Console do not require a Horizon Edge Gateway, because licensing is handled locally within the pod.

 

Checking the connectivity

When deploying environments based on Omnissa Horizon integrated with Horizon Cloud Services (HCS), proper outbound connectivity from the Horizon Edge Gateway is critical.

This is the link for Port and Protocol Requirements for Deploying Horizon 8 Edge:

Port and Protocol Requirements for Deploying Horizon 8 Edge

In many enterprise environments, outbound communication toward the internet is tightly controlled through firewalls, proxies, or SSL inspection systems. While this is perfectly reasonable from a security perspective, it often introduces connectivity issues if the required endpoints are not properly allowed.

Even more commonly, the configuration works initially but breaks later because firewall rules are modified, security appliances are upgraded, or SSL inspection policies change over time.

For this reason, whenever issues arise with Horizon Cloud integration, the first thing to verify is whether the Edge Gateway can still reach the required Horizon Cloud Services endpoints.

Fortunately, the Edge Gateway provides a built-in diagnostic tool to help with exactly this scenario.

.

.

.

Using diagnostic.sh to Test Connectivity

The Horizon Edge Gateway includes a script called diagnostic.sh

This script performs a series of connectivity checks toward the Horizon Cloud Services endpoints required for proper operation.

The script validates:

• DNS resolution
• HTTPS connectivity
• Reachability of the required Horizon Cloud endpoints
• TLS handshake validation

This makes it extremely useful when troubleshooting issues caused by:

• Missing firewall rules
• SSL inspection interfering with TLS connections
• DNS resolution problems
• Proxy misconfigurations

.

Running the Diagnostic Script

Log in to the Horizon Edge Gateway via VM Web Console with the root account:

And run this command:

The script will test connectivity against multiple Horizon Cloud endpoints and return the results directly to the console.

A successful test typically shows results like:

If a problem exists, the script will clearly indicate which test failed.

.

Why This Check Is Important

Connectivity to Horizon Cloud Services is essential for several platform features, including:

• Edge Gateway registration
• Horizon control plane communication
• Monitoring and service updates
• Validate the Horizon License

Because firewall and security policies frequently evolve in enterprise environments, it’s a good practice to periodically validate connectivity using the diagnostic tool.

Running the diagnostic script can quickly confirm whether the issue is related to networking or to another component of the Horizon environment.

.

.

.

.

 Spoiler:

There may be proxy problems. For which proxy it is used, you can read this configuration file:

/opt/horizon/var/data/proxy.conf

.

.

.

Checking Horizon Cloud Services Connectivity from Horizon Edge Gateway

Add icon to App Pool

fabio1975Leave a comment

 

# --- Step 1: Get admin credentials securely ---
$cred = Get-Credential
$domain = "yourdomain"

# --- Step 2: Build login payload ---
$loginBody = @{
    username = $cred.UserName
    password = $cred.GetNetworkCredential().Password
    domain   = $domain
} | ConvertTo-Json

# --- Step 3: API base URL and cert bypass for testing ---
$restApiBaseUrl = "https://horizon.domain.com/rest"
Add-Type @"
    using System.Net;
    using System.Security.Cryptography.X509Certificates;
    public class TrustAllCertsPolicy : ICertificatePolicy {
        public bool CheckValidationResult(ServicePoint srvPoint, X509Certificate certificate,
                                          WebRequest request, int certificateProblem) {
            return true;
        }
    }
"@
[System.Net.ServicePointManager]::CertificatePolicy = New-Object TrustAllCertsPolicy

# --- Step 4: Authenticate and get token ---
$tokenResponse = Invoke-RestMethod -Method POST -Uri "$restApiBaseUrl/login" -Body $loginBody -ContentType "application/json"
$token = $tokenResponse.access_token
$headers = @{ "Authorization" = "Bearer $token" }

# --- Step 5: Load and encode icon file ---
$iconFilePath = "C:\path\file.png"
$iconBytes = [System.IO.File]::ReadAllBytes($iconFilePath)
$base64Icon = [System.Convert]::ToBase64String($iconBytes)

# --- Step 6: Upload the icon ---
$iconBody = @{
    data = $base64Icon
    height = 256
    width = 256
} | ConvertTo-Json -Depth 2

$response = Invoke-RestMethod -Method POST -Uri "$restApiBaseUrl/inventory/v1/application-icons" -Headers $headers -Body $iconBody -ContentType "application/json"

# --- Step 7: Retrieve the icon ID from the uploaded base64 data ---
$iconId = ((Invoke-RestMethod -Method GET -Uri "$restApiBaseUrl/inventory/v1/application-icons/custom-icons" -Headers $headers -ContentType "application/json") | Select-Object data,id | Where-Object {$_.data -eq $base64Icon}).id

# --- Step 8: Get application ID by name (e.g., Notepad) ---
$appFilterJSON = @{
    type = "Equals"
    name = "name"
    value = "Notepad"
}
$appFilterURLEncoded = [System.Web.HttpUtility]::UrlEncode(($appFilterJSON | ConvertTo-Json -Depth 2 -Compress))
$appId = (Invoke-RestMethod -Method GET -Uri "$restApiBaseUrl/inventory/v4/application-pools?filter=$appFilterURLEncoded" -Headers $headers).id

# --- Step 9: Associate the custom icon with the application ---
$appIconAssocBody = @{
    application_pool_ids = @("$appId")
    icon_id = "$iconId"
} | ConvertTo-Json -Depth 2

Invoke-RestMethod -Method POST -Uri "$restApiBaseUrl/inventory/v1/application-pools/action/associate" -Headers $headers -Body $appIconAssocBody -ContentType "application/json"

 

Add icon to App Pool

Script to export and import Application Pools e i loro entitlements

fabio1975Leave a comment

 

# Script per esportare e importare Application Pools e le loro entitlements da un HCS ad un altro.
# Si basa sulle API REST di Omnissa (HCS) e richiede le credenziali di un utente con privilegi di amministratore.
# Il file JSON esportato contiene i pool e le entitlements associate, che possono essere importati in un altro HCS.
# Le API utilizzate sono documentate nella sezione "API Reference" della documentazione di Omnissa. 
# https://developer.omnissa.com/horizon-apis/
# https://retouw.nl/2021/10/02/horizon-rest-api-powershell-7-paging-and-filtering-with-samples/

# === LOGIN & TOKEN ===
function Get-HRToken {
    param([string]$Server, [string]$Domain, [string]$User, [string]$Password)
    $body = @{ domain=$Domain; username=$User; password=$Password } | ConvertTo-Json
    $uri  = "https://$Server/rest/login"   # POST /rest/login :contentReference[oaicite:0]{index=0}
    (Invoke-RestMethod -Method Post -Uri $uri -Body $body -ContentType 'application/json' `
                       -SkipCertificateCheck).access_token
}

# === UTILITY: rimuove campi read-only non clonabili ===
function Sanitize-Pool {
    param($Pool)
    $Pool | Select-Object * -ExcludeProperty id, avm_shortcut_id, global_application_entitlement_id
}


function Export-AppPoolsWithEntitlements {
    param(
        [string]$SrcServer,  [string]$Domain,
        [string]$User,       [string]$Password,
        [string]$OutFile 
    )

    $token = Get-HRToken $SrcServer $Domain $User $Password

    # Lista completa dei pool (max 1000) – GET /inventory/v4/application-pools :contentReference[oaicite:1]{index=1}
    $pools = Invoke-RestMethod -Method Get `
              -Uri "https://$SrcServer/rest/inventory/v3/application-pools?size=1000" `
              -Headers @{Authorization="Bearer $token"} -SkipCertificateCheck

    $export = foreach ($p in $pools) {
        # Entitlement del singolo pool – GET /entitlements/v1/application-pools/{id} :contentReference[oaicite:2]{index=2}
        $ents = Invoke-RestMethod -Method Get `
                -Uri "https://$SrcServer/rest/entitlements/v1/application-pools/$($p.id)" `
                -Headers @{Authorization="Bearer $token"} -SkipCertificateCheck

        [PSCustomObject]@{
            pool         = Sanitize-Pool $p
            entitlements = $ents.ad_user_or_group_ids
        }
    }

    $export | ConvertTo-Json -Depth 15 | Out-File $OutFile -Encoding UTF8
    Write-Host "✓ Esportati $($export.Count) pool in $OutFile"
}




function Import-AppPoolsWithEntitlements {
    param(
        [string]$DstServer,  [string]$Domain,
        [string]$User,       [string]$Password,
        [string]$JsonFile 
    )

    $token = Get-HRToken $DstServer $Domain $User $Password
    $data  = Get-Content $JsonFile | ConvertFrom-Json

    foreach ($item in $data) {
    Write-Host "Singolo item $item"
    $item.pool
    Read-Host -Prompt "Press Enter to continue"
        # 4.1  Crea il nuovo Application Pool – POST /inventory/v1/application-pools :contentReference[oaicite:3]{index=3}
        $bodyPool = $item.pool | ConvertTo-Json -Depth 15
        $newPool  = Invoke-RestMethod -Method Post `
                     -Uri "https://$DstServer/rest/inventory/v1/application-pools" `
                     -Headers @{Authorization="Bearer $token"} `
                     -ContentType 'application/json' -Body $bodyPool -SkipCertificateCheck 
        Write-Host "Pool creato $newPool"
        $nomepool = $($item.pool.name)
        Write-Host "Nome del application $nomepool"
        $poolid = Invoke-RestMethod -Method Get `
                     -Uri "https://hcs01.pollaio.lan/rest/inventory/v1/application-pools?filter=%7B%0A%09%22type%22%3A%20%22Equals%22%2C%0A%09%22name%22%3A%20%22name%22%2C%0A%09%22value%22%3A%20%22$nomepool%22%0A%7D" `
                     -Headers @{Authorization="Bearer $token"} `
                     -ContentType 'application/json' -SkipCertificateCheck
        $poolid
        $poolid.id

    Read-Host -Prompt "Press Enter to continue"
        Write-Host "✓ Creato pool '$($item.pool.name)' (nuovo id $($poolid.id))"

        # 4.2  Ripristina entitlement (se presenti) – POST /entitlements/v1/application-pools (bulk) :contentReference[oaicite:4]{index=4}
        if ($item.entitlements.Count) {
            $Psobj=New-Object -Type psobject
            $Psobj | Add-Member -MemberType NoteProperty -Name "id" -Value $poolid.id -Force
            $Psobj | Add-Member -MemberType NoteProperty -Name "ad_user_or_group_ids" -Value $item.entitlements -Force
            $entSpec ="["
            $entSpec += $Psobj | ConvertTo-Json
            $entSpec += "]"
        
            Invoke-RestMethod -Method Post `
                -Uri "https://$DstServer/rest/entitlements/v1/application-pools" `
                -Headers @{Authorization="Bearer $token"} `
                -ContentType 'application/json' -Body $entSpec -SkipCertificateCheck

            Write-Host "  └─► Entitlement ripristinati: $($item.entitlements.Count) SID - APP ID $($newPool.id)"
        }
    }
}
function DestListFarmsID {
    param(
        [string]$DstServer,  [string]$Domain,
        [string]$User,       [string]$Password,
        [string]$FarmDest
    )
    
    $token = Get-HRToken $DstServer $Domain $User $Password
    $FARMDETAILDST = Invoke-RestMethod -Method Get `
                -Uri "https://$DstServer/rest/inventory/v7/farms?filter=%7B%0A%09%22type%22%3A%20%22Equals%22%2C%0A%09%22name%22%3A%20%22name%22%2C%0A%09%22value%22%3A%20%22$FarmDest%22%0A%7D" `
                -Headers @{Authorization="Bearer $token"} `
                -ContentType 'application/json' 
    Write-host $FARMDETAILDST.id
}

function SourceListFarmsID {
    param(
        [string]$SrcServer,  [string]$Domain,
        [string]$User,       [string]$Password,
        [string]$FarmSrc
    )
$filterhashtable = [ordered]@{}
$filterhashtable.filters = @()
$userfilter= [ordered]@{}
$userfilter.add('type','Equals')
$userfilter.add('name','name')
$userfilter.add('value',$FarmSrc)
$filterhashtable.filters+=$userfilter
$filterflat = $filterhashtable | ConvertTo-Json -Compress
    $token = Get-HRToken $SrcServer $Domain $User $Password
    $FARMDETAILSRC = Invoke-RestMethod -Method Get `
               -Uri "https://$SrcServer/rest/inventory/v3/farms?$filterflat" `
                -Headers @{Authorization="Bearer $token"} `
                -ContentType 'application/json' -skipCertificateCheck
    Write-host $FARMDETAILSRC.id
}
######MAIN PROGRAM###
# Insert Source HCS
$SrcServer = Read-Host -Prompt "Insert Source HCS Server Name"
#$SrcServer = "hcs2111.pollaio.lan"
# Insert Dest HCS
$DstServer = Read-Host -Prompt "Insert Destination HCS Server Name"
#$DstServer = "hcs01.pollaio.lan"
#Insert Domain
$Domain = Read-Host -Prompt "Insert Domain Name (e.g. POLLAIO)"
#$Domain = "pollaio"
# Insert Path to JSON file
$JsonFile = Read-Host -Prompt "Insert Path to JSON file (e.g. c:\attimo\AppPoolsWithEntitlements.json)"
# Insert Credentials 
$Credentials = Get-Credential -Message "Insert Domain Credentials for $SrcServer and $DstServer"
$Username = $Credentials.UserName
$Pass = $Credentials.GetNetworkCredential().Password

# --- EXPORT ---
Export-AppPoolsWithEntitlements `
    -SrcServer $SrcServer -Domain $Domain `
    -User $Username -Password $Pass -OutFile $JsonFile

#
$FarmSrc = Read-Host -Prompt "Insert Source Farm Name"
$SFARM=SourceListFarmsID `
     -SrcServer $SrcServer -Domain $Domain `
    -User $Username -Password $Pass -FarmSrc $FarmSrc 6>&1

$SFARM


$FarmDest = Read-Host -Prompt "Insert Destination Farm Name"
$DFARM=DestListFarmsID `
     -DstServer $DstServer -Domain $Domain `
    -User $Username -Password $Pass -FarmDest $FarmDest 6>&1

$DFARM
(Get-Content -Path $JsonFile) -replace "$($SFARM)", "$($DFARM)" | Set-Content -Path $JsonFile

Read-Host -Prompt "WARNING!! If you import the application in the same HCS change the Name and diplay name in the Json file.  Press Enter to continue"

# --- IMPORT ---
Import-AppPoolsWithEntitlements `
    -DstServer $DstServer -Domain $Domain `
    -User $Username -Password $Pass -JsonFile $JsonFile

 

Script to export and import Application Pools e i loro entitlements

vCenter Server Preupgrade check result error: “VMDir Replication between partners is not working”

fabio1975, , Leave a comment

vCenter upgrade Pre-Check fail with “VMDir replication is not working correctly”

When I tried to upgrade my vCenter to the last version of 8u3 on the pre-check command, I found this error

A screenshot of a computer error message AI-generated content may be incorrect.

Because I attached another vCenter at the same PSC, it is now broken.

For deleting the missed vCenter:

Take a vCenter snapshot

Check the vCenter name:

The name is vcenter02.pollaio.lan

Remove the old vCenter:

A computer screen with white text AI-generated content may be incorrect.

After automatic service restart

Now the upgrade pre-check does not have an alert message

A screenshot of a computer AI-generated content may be incorrect.

Reference

vCenter Server Preupgrade check result error: “VMDir Replication between partners is not working”

vCenter Server Preupgrade check result error: “VMDir Replication between partners is not working”

How to differentiate Horizon Smart Policies with Unified Access Gateway Location information

fabio1975Leave a comment

There is a Unified Access Gateway (UAG) configuration that can help to apply different Horizon Smart Policies (Like clipboard) to Horizon VDI Sessions

A screenshot of a computer Description automatically generated

Normally I can suggest using UAG not only for external access (Home Worker) but also for internal access (Office Worker)* and I deploy a UAG group (two or plus UAG) for external and another for internal.

The Gateway location can Help us for example to enable Clipboard for internal access and disable for external access, It is possible to integrate this information (Gateway location) with a Dynamic Environment Manager Condition

In my example, I have configured two Horizon Smart Policies:

Clipboard_From_Internet 🡪 Where I disabled the clipboard with this condition:

A screenshot of a computer Description automatically generated

Clipboard_From_Internal 🡪 Where I enabled the clipboard with this condition:

A screenshot of a computer Description automatically generated

With those values, I can configure different functions depending on where the client is trying to connect to the VDIs

*The use of UAG on internal access can help to not deploy an Internal Load balancing (We can use UAG HA) and not use a balancing for Horizon Connection Servers. (I always suggest to map 1:1 the UAG with Connection Server)

How to differentiate Horizon Smart Policies with Unified Access Gateway Location information

Configure Proxy Server for Horizon for SAML integration

fabio1975, , , , , , , , , Leave a comment

When we need to integrate a Horizon infrastructure to the cloud identity provider (like Workspace One Access SaaS solution) sometimes we need to manage firewall and proxy configuration.

For the Firewall rule, there is much information (KB link) while for the proxy server, we are not able to use Windows server configuration because Horizon ignores it.

To use a proxy server to permit communication to the IdP URL from Horizon Connection servers we need to configure some values on ADAM DB:

pae-SAMLProxyName

pae-SAMLProxyPort

To connect to ADAM DB and where modify the correct value

  • Connect with RDP session to Connection Server OS
  • Start from PowerShell adsedit

A close-up of a computer screen Description automatically generated

  • In the console tree select Connect to..

A screenshot of a computer Description automatically generated

  • Configure the connection with this information.

dc=vdi,dc=vmware,dc=int

localhost:389

A screenshot of a computer Description automatically generated

  • Expand ADAM ADSI tree under the object path: dc=vdi,dc=vmware,dc=int,ou=Properties,ou=Global
  • Click on value Common and modify the following value

pae-SAMLProxyName -> With Proxy URL

pae-SAMLProxyPort -> With Proxy Port

Now we can configure the SAML integration from Horizon and IdP

Some information about why we need to integrate and use Workspace One Access with Horizon:

Integration between VMware Horizon and VMware Workspace ONE Access (formerly called Workspace ONE) uses the SAML 2.0 standard to establish mutual trust, which is essential for single sign-on (SSO) functionality. When SSO is enabled, users who log in to VMware Workspace ONE Access or Workspace ONE with Active Directory credentials can launch remote desktops and applications without having to go through a second login procedure.

Configure Proxy Server for Horizon for SAML integration