VMware Horizon 8 2303

At the end of March 2023, new versions of the products that make up the Horizon suite were released. (Connection Server, Volume App, DEM, and Unified Access Gateway)

There are several interesting features, below I report the link to each release note.

I bring to your attention the presence of AppVolume in a preview solution related to the use of AppVolume in the Azure environment. (This deployment option is intended for applications packages and not Writable Volumes)


VMware Horizon 8 2303 Release Notes

App Volume on Azure

VMware App Volumes Manager Deployment Guide for Azure –

App Volume 

VMware App Volumes 4, version 2303 Release Notes


VMware Dynamic Environment Manager 2303 Release Notes

Unified Access Gateway

Unified Access Gateway 2303 Release Notes (vmware.com)

VMware Horizon 8 2303

Ingest your VMware ESXi logs into Azure Sentinel

The VMware ESXi connector is currently in PREVIEW

What is Azure Sentinel?

Microsoft Azure Sentinel is a scalable, cloud-native, security information event management (SIEM) and security orchestration automated response (SOAR) solution. Azure Sentinel delivers intelligent security analytics and threat intelligence across the enterprise, providing a single solution for alert detection, threat visibility, proactive hunting, and threat response.

Azure Sentinel ingests data from services and apps by connecting to the service and forwarding the events and logs to Azure Sentinel. For physical and virtual machines, you can install the Log Analytics agent that collects the logs and forwards them to Azure Sentinel. For Firewalls and proxies, Azure Sentinel installs the Log Analytics agent on a Linux Syslog server, from which the agent collects the log files and forwards them to Azure Sentinel.

How connect  VMware ESXi to Azure Sentinel?

Integration between VMware ESXi and Azure Sentinel makes use of a Syslog server with the Log Analytics agent installed. It also uses a custom-built log parser based on a Kusto function.

For the onboarding of ESXi on Azure Sentinel, these are the step:

  • Have up and running a  Azure Sentinel service.
  • Prepare a Linux Syslog Server
  • Install Log Analytics Agent
  • Create the VMwareESXi Kusto function
  • Configure your ESXi Hosts to forward log to Syslog server

Create a Azure Sentinel Service 

This example is related to a basic configuration of the Azure Sentinel infrastructure, for more information and details for sizing and costs check in the respective guides from Microsoft.

Login to Azure Portal (How to get an Azure subscription?)

Prepare Linux Syslog

I have installed a virtual machine with Ubuntu Guest OS

I have checked if rsyslog is installed and running

if rsyslog is not installed run the following installation command

 apt-get install rsyslog

Configure rsyslog

Verify the tcp port used from syslog server

Cat  /etc/rsyslog.conf

Configure Kusto function alias

On log analytics workspace

 create this function:

/ Title:           VMWare ESXi
// Author:          Microsoft
// Version:         1.0
// Last Updated:    11/13/2020
// Comment:         Inital Release
// This parser takes raw VMWare ESXi logs from a Syslog stream and parses the logs into a normalized schema.
// 1. Open Log Analytics/Azure Sentinel Logs blade. Copy the query below and paste into the Logs query window. 
// 2. In the query window, on the second line of the query, enter the hostname(s) of your VMWare ESXi device(s) and any other unique identifiers for the logstream. 
//    For example: | where Computer in ("server1", "server2")
// 3. Click the Save button above the query. A pane will appear on the right, select "as Function" from the drop down. Enter a Function Name.
//    It is recommended to name the Function Alias, as VMwareESXi
// 4. Kusto Functions can typically take up to 15 minutes to activate. You can then use Function Alias for other queries.
// Using functions in Azure monitor log queries: https://docs.microsoft.com/azure/azure-monitor/log-query/functions
// This parser assumes the raw log are formatted as follows:
// info vpxa[D089B70] [Originator@6876 sub=vpxLro opID=HB-host-89929@3678594-5d55f348-40] [VpxLRO] -- BEGIN session[52908bc7-673e-dc2f-8726-70d13fe8ef72]521881cd-707e-cf9b-01c4-f0fd16d7444d -- vpxa -- vpxapi.VpxaService.retrieveChanges -- 52908bc7-673e-dc2f-8726-70d13fe8ef72
// warning hostd[191C2B70] [Originator@6876 sub=VigorStatsProvider(409264032)] AddVirtualMachine: VM '67' already registered
// cpu25:1040586)WARNING: vmw_psp_rr: psp_rrSelectPathToActivate:1101: Could not select path for device "Unregistered Device".
let LogHeader = Syslog
| where Computer in ("ESXiserver1", "ESXiserver2") // ESXiserver1 and ESXiserver2 are examples, replace this list with your ESXi devices
| extend Parser = extract_all(@"^(\w+)?\s?(\w+)\[(\w+)\]\s([\s\S]+)", dynamic([1,2,3,4]), SyslogMessage)
| mv-expand Parser
| extend Substring = tostring(Parser[3])
| project-away Parser;
| extend Sub = extract(@"sub=([\w\d\(\)\-\.]+)\]?",1, Substring),
	 OpId = extract(@"opID=([\w\d\(\)\-@]+)\s?\]?",1, Substring),
         UserName = extract(@"\suser=([\w\d\(\)\-]+)\]",1, Substring)
| extend Message = extract(@"\[([\S\s]+)\]\s([\S\s]+)",2, Substring)
| extend Message = iif(isempty(Message),SyslogMessage,Message)
| extend Message = trim(@"^-- ", Message)
| project-away Substring

Install Log Analytics Agent

Go to Vmware ESXi Connector on Azure Sentinel

Go to linux syslog server and paste it the code for onboard agent to sentinel

For troubleshooting


In my installation was missing :

And i have installed it

apt-get install gdb

If the installation is ok

now we set which logs the linux agent must send to our workspace

And add local4 e auth

automatically this information will be sent to our agent

Configure ESXi to send data to Linux Syslog Gateway (Where is installed the Log Analytics Agent)

We configure our esxi hosts to send logs to our linux syslog with this powercli script:

$vmHosts = Get-VMHost
$remoteSyslog = 'tcp://<linuxlogserver>'
$syslogport = '514'
# Show current config
$vmHosts | ForEach-Object {
    Write-Host $_.Name
    Get-VMHostSysLogServer -VMHost $_
# Set syslog config in hypervisors
$vmHosts | ForEach-Object {
    Write-Host $_.Name
    Set-VMHostSysLogServer -SysLogServer $remoteSyslog":"$syslogPort -VMHost $_
# Restart syslog and set the allow rules in the ESXi
$vmHosts | ForEach-Object {
    Write-Host $_.Name
    (Get-Esxcli -v2 -VMHost $_).system.syslog.reload.Invoke()
    (Get-Esxcli -v2 -VMHost $_).network.firewall.ruleset.set.Invoke(@{rulesetid='syslog'; enabled=$true})
    (Get-Esxcli -v2 -VMHost $_).network.firewall.refresh.Invoke()
# Show current config
$vmHosts | ForEach-Object {
    Write-Host $_.Name
    Get-VMHostSysLogServer -VMHost $_

Check if ESXi Sentinel Connector is UP

Query to view log

Ingest your VMware ESXi logs into Azure Sentinel

Integrazione VMware Unified Access Gateway con autenticazione Azure MFA

 Per procedere all’integrazione  con Azure MFA è necessario eseguire delle configurazioni su Azure Active Directory  (non entrerò nel dettaglio di queste configurazioni) ma per procedere nell’abilitazione dell’autenticazione a più fattori sull’UAG è necessario accedere all’Enterprise Application creata e scarica il file XML con i metadata. Inoltre verificare che nella Basic SAML Configuration ci siano i riferimenti alla mia infrastruttura UAG pubblica.


Scarico il file XML con i metadata da utilizzare per configurare l’UAG

Importo il file XML nella infrastruttura UAG nelle configurazioni manuali in Identity Bridging Settings


Importo il file XML contenente i metadata selezionado Select


Una volta caricato sull’UAG il file XML con i metadata vado negli edge service settings ed entro nei nelle configurazioni

E configuro l’Auth Methods e l’identity Provider (che mi compare in automatico dopo aver caricato il file XML)


A questo punto posso procedere ad accedere e testare l’accesso con MFA.

Integrazione VMware Unified Access Gateway con autenticazione Azure MFA

Azure Load Balancer Change SKU (Basic to Standard)

For increise SLA  I need to change Azure LoadBalancer SKU,

Azure LB Basic don’t have SLA, different is for Standard SKU. 

Don’t is possibile to change the sku with a upgrade, the only solution is create a new LoadBalancer (Standard)  e  configure it with the configuration of old LoadBalancer (Basic).

Luckily Microsoft have release a procedure for made it. 


We need check if our LoadBalancer is Public or Internal (No Outbound or With Outbound)

For any choose we have a script to use. Very easy. 

What are the steps of the script?

1- Save and change (with new free IPs) the frontend IPs of Basic LoadBalancer (the script support only 5 Frontend IPs, for more IPs you manually pass the IPs)

2- Create a new Standard LoadBalancer with the configuration of basic loadbalancer  (Frontend IP, Probe ecc..)

3- Migrate the backend pool 

In my upgrade we have been  a ten minutes of downtime.

Azure Load Balancer Change SKU (Basic to Standard)

AKS – Aggiornamento in arrivo a inzio Luglio

Come ogni 3 Mesi sono in arrivo degli aggiornamenti per il servio AKS (Azure Kubernetes Services):

  • Nuova versione la 1.17  disponibile dal 1 Luglio (Sempre da quella data non saranno più in supporto le versioni 1.14)
  • L’annuncio che a breve verranno rilasciati i nodi AKS con ubuntu 18.04 (Una volta rilasciata la nuova versione dei nodi tutti i successivi aggiornamenti di AKS si porteranno dietro anche l’aggiornamento di versione di Ubuntu)
Tutti i dettagli in questo link
AKS – Aggiornamento in arrivo a inzio Luglio

Horizon Cloud on Azure 1 di 5

Attualmente è disponibile la possibilità di utilizzare una  trial della soluziona Horizon Cloud di VMware su cloud AZURE. 

La trial è disponibile per 90 giorni (prima del covid-19 erano meno estesa). 
Per procedere nell’utilizzo della trial è necessario eseguire una serie di semplici step:
  1. Acquire Horizon Cloud Service on Microsoft Azure
  2. Prepare Microsoft Networking and AD
  3. Azure Deploy Horizon Cloud Service On Microsoft Azure 
  4. Deploy Microsoft Azure-Based RDS Host and VDI Desktop 
  5. Install Applications and Assign Users 
Procediamo con ordine e partiamo da Acquire Horizon Cloud Service on Microsft Azure  dove:
– Attiviamo le licenze Trial e gli step che consiglio sono:
  • Crearsi un account GMAIL 
  • Registrarsi al sito  MyVMware con il nuovo account GMAIL 
  • Compilare l’apposito FORM (Request Form-Horizon Universal License Free Trial*)

       Le credenziali create per accedere MyVMware saranno anche quelle che ci permetteranno l’accesso al portale https://cloud.horizon.vmware.com

Nell’apposito FORM verrà richiesto:
– Tipologia di trial (Azure, On-Premises, AWS, Azure VMware Solutions, Google Cloud VMware Engine)
– Numero e tipologia (Concurrent o user) delle licenze Horizon Universal 
– Location della VMware Horizon Panel (America, Europa ecc..)
– Azure Region del deploy dell’ambiente 
 Utilizziamo una Microsoft Azure Subscription 

 Dal portale azure attiviamo la nostra Subscription dove andremo a crare i servizi necessarei per il deploy dei componenti (Horizon, VM ecc)
*Horizon Universal License sono le nuove licenze Horizon che posso essere utilizzate sia per ambienti on-premises o su cloud
Horizon Cloud on Azure 1 di 5

AKS upgrade come verificare se dobbiamo aggiornare

Cluster Kubernetes, ormai sappiamo tutti di che cosa stiamo parlando.

Questa tipologia di cluster possiamo trovarla in tanti ambienti.. Cloud o on-prem, su VMware ecc.

Come tutte le infrastrutture si devono però mantenere ed è molto importante tenerle aggiornate …anche sotto questo aspetto l’idea del “funziona e quindi perchè aggiornarla” è ormai obsoleta.


Mi è capitato ultimamente di confrontarmi con la soluzione AKS (Azure Kubernetes Services) ed essendo un servizio PaaS  è necessario rimanere al passo delle versioni che Microsoft rilascia per il suo cloud.


Quindi entriamo nel dettaglio:


Ogni 3 mesi vengono rilasciate delle versioni minori (La struttura  d[major].[minor].[patch])  e l’attuale 1.16.x è stata rilasciata a Marzo  2020 per cui:

·         La 1.17 mi aspetto che venga rilasciata a Giugno 2020

·         La 1.18 mi aspetto che venga rilasciata a Settembre 2020

Per verificare che versioni sono disponibili nella region su cui abbiamo il nostro cluster  il comando è il seguente:


   az aks get -versions –location <Region>  –output table





Se ad esempio la nostra infrastruttura è alla versione 1.15.7 e posso verificarlo con il seguente comando:


   az aks get-upgrades –resource-group  <Resource Group>  –name <nome del cluster AKS> –output table



Per la regola del N-2 la nostra versione va fuori supporto a Settembre 2020


A settembre come detto esce la 1.18, la regola del N-2 si applicata alla minor e quinti 18-2 = 16  quindi fino alla 1.16  siamo in supporto per quelle precedenti ( per cui la 1.15) siamo fuori supporto.


Per aggiornare una infrastruttura AKS  da  una versione fuori supporto a una in supporto…..  bisogna reinstallare il nostro cluster !


AKS upgrade come verificare se dobbiamo aggiornare

Veeam Backup for Microsoft Azure

Veeam ha rilasciato  una soluzione di backup per proteggere  le Microsoft Azure VM ,  gli aspetti interessanti della soluzione sono:

·       Gratuita fino a proteggere 10 Azure VM

·       integrazione con le snapshot di Azure

·       La possibilità di avere un stima dei costi  relativamente allo spazio dei container dell’Azure Storage Account  in base alla VM da Proteggere e alla policy implementata.


La  virtual appliance è disponbiile nel MarketPlace di Azure




L’installazione, come tutte le soluzioni Veeam e le infrastrutture Azure sono deployate e configurabili veramente in breve tempo  sopo 15 minuti (Deploy e configurazione) siamo pronti a eseguire il primo backup.


Alcune considerazione relativamente all’installazione:

·      Necessità di tutte le informazioni  che richiedere un deploy di una Azure VM (vNet, Resource Group ecc.)

·       Richieste un’ Azure Storage Account su cui andare ad salvare i dati dei backup.


Aclune considerazioni relative all’implementazione delle policy di backup

·     Differenzazione tra retention per  Snapshot e per Backup 

·     Come la versione di Veeam Backup & Replication v10  oltre al numero di versioni per i backup è presente anche la retention per numero di giorni

·      Come anticipavo precedentemente è possibile sapere in anticipo i costi di utilizzo dell’infrastruttura Azure per lo spazio relativo ai backup (Il costo della Azure VM di Veeam Backup for MIcrosoft Azure è quello del size della VM scelto durante il deploy)




Veeam Backup for Microsoft Azure

Azure SQL server – Database copy

Alla fine del 2019 ho postato nel Blog alcune indicazioni come effettaure un allineamento di un Azure SQL DB da un ambiente di Sviluppo a un ambiente di Produzione, a quel tempo (si sembra passato molto tempo..) avevo utilizzato il bpac.

In questi giorni ho dovuto eseguire la stessa attività su un’altro cliente (DB di Produzione  su DB di Dev su azure SQL server differenti  anche in sottoscrizioni Azure differenti) in questo caso ho provato un comando T-SQL. 
Il comando è:
CREATE DATABASE <nome del DB nella Destinazione> AS COPY <nome Azure SQL server> .<nome del DB sorgente>
Nel dettaglio sono necessarie alcune attività propedeutiche di annotazione e permessi:
– Sul server di destinazione la presenza di una security con Username e Password uguali al DB owner del DB sorgente. (con permessi sull’Azure SQL di destinazione di DBmanager e loginmanager)
– Memorizzare le security del DB di destinazione che andremo a rimuovere 
– Avere un Sql Server Management Studio (SSMS) installato su un client che può accedere ad entrambi gli Azure SQL Server (Ricordarsi di abilitare l’accesso sul firewall dell’Azure SQL server)
Se abbiamo fatto tutte le attività propedeutiche procediamo:
– Accesiamo via SSMS all’ Azure SQL server di destinazione con l’utente comune ai due Server SQL.
– Lanciamo il comando T-SQL:
CREATE DATABASE <nome del DB nella Destinazione> AS COPY <nome Azure SQL server> .<nome del DB sorgente>
  •  ricordiamoci che il nome dell’Azure SQL server necessita solamente dell’hostname e se abbiamo caratteri particola nel nome (come un meno) di includerlo in “”. Es. “server-sql-azure-01”.<nome DB>
  • conviene, caso di una sostituzione di un DB esistente sulla destinazione, copiarno con un nome differente es <nome DB>NEW e poi procedere in un secondo momento con la rimozione del vecchio DB e la rinomina del nuovo.
al termine avremo il nuovo DB
– Modifichiamo l’owner del DB 

– Rimuoviamo eventuali permessi dell’infrastruttura sorgente.
– Assegniamo al DB i permessi degli utenti (che se abbiamo fatto le azioni propedeutiche ci siamo segnati, oppure se siamo stati furbi possiamo recuperarli dal DB che non abbiamo ancora cancellato)
– Rinominiamo il DB con il nome definitivo
– Cancelliamo la login che avevamo creato  per procedere alla copia (ovviamente solo dal server di destinazione)
Attenzione !!! Ricordiamoci  se presente un backup ( NON MI DITE CHE NON FATE I BACKUP DEI DB …) di andare ad assegnare la policy  che preferite. 
Questo è tutto!!!
Riferimenti Microsoft 
Azure SQL server – Database copy