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)
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.
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
//
// DESCRIPTION:
// This parser takes raw VMWare ESXi logs from a Syslog stream and parses the logs into a normalized schema.
//
// USAGE:
// 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.
//
// REFERENCES:
// Using functions in Azure monitor log queries: https://docs.microsoft.com/azure/azure-monitor/log-query/functions
//
// LOG SAMPLES:
// 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;
LogHeader
| 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
/opt/microsoft/omsagent/bin/troubleshooter
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:
Connect-ViServer
$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 $_
}
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.
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.
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)
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.
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 !
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)
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>
attenzione:
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
ALTER AUTHORIZATION ON DATABASE::<nome DB> to <nuovo Owner>;
– 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.