Archivi autore: Francesco Molfese

Informazioni su Francesco Molfese

Francesco is a consultant, trainer, technical writer and Microsoft MVP focusing on public cloud, hybrid cloud, virtualization and datacenter management. Francesco has over 10 years of experience in architecting, implementing and managing IT solutions and he is currently employed as a Senior Consultant at Progel Spa an IT consulting company and Microsoft Certified Partner. Francesco is the Community Lead of the Italian User Group of System Center and Operations Management Suite (ugisystemcenter.org) and he is a frequent speaker at leading IT Pro conferences in Italy.

Azure Backup: come evolve la soluzione

Microsoft ha recentemente annunciato importanti novità riguardanti la protezione delle macchine virtuali tramite Azure Backup. Grazie ad un aggiornamento dello stack di backup si possono infatti ottenere consistenti miglioramenti della soluzione che la rendono più performante e ne estendono le potenzialità. In questo articolo verranno approfonditi i benefici che si ottengono dall’aggiornamento e sarà esaminata la procedura da seguire per passare al nuovo stack di backup.

Funzionalità introdotte dal nuovo stack di backup

Recovery point istantanei e miglioramenti nelle performance

Il job di Azure Backup per la protezione delle macchine virtuali può essere suddiviso in due fasi distinte:

  1. Creazione della snapshot della VM.
  2. Trasferimento della snapshot verso il Recovery Service vault.

Figura 1 – Fasi del job di backup

Aggiornando lo stack di backup, il recovery point viene reso disponibile immediatamente al termine della creazione della snapshot della macchina virtuale (Fase 1), ed è utilizzabile per le operazioni di ripristino secondo le modalità note. A differenza di prima che era possibile utilizzarlo solo al termine della Fase 2. Dal portale Azure è possibile distinguere la tipologia di recovery point, in quanto al termine della Fase 1, il recovery point type viene definito come “snapshot”, mentre al termine del trasferimento della snapshot verso il vault di backup, il recovery point type viene marcato come “snapshot and vault”.

Le snapshot effettuate durante il processo di backup vengono mantenute per 7 giorni. Grazie a questa modifica vengono ridotti notevolmente i tempi di esecuzione dei restore, effettuati utilizzando le snapshot, le quali sono utilizzabili in modo del tutto analogo ai checkpoint creati da Hyper-V oppure da VMware.

Supporto per dischi di grosse dimensioni

Il nuovo stack di backup consente inoltre di proteggere i dischi di dimensione fino ai 4TB, sia di tipologia managed che unmanaged. Il limite in precedenza nella dimensione massima dei dischi protetti era di un 1TB.

Distribuzione dei dischi durante il ripristino delle macchine virtuali

Dopo aver effettuato l’aggiornamento dello stack di backup si ha la possibilità di scegliere dove posizionare i dischi unmanaged delle macchine virtuali durante i processi di restore. Questo riduce le configurazioni che sarebbero necessarie, post attività di restore, mettendo tutti i dischi all’interno dello stesso storage account.

Il processo di Upgrade

Per poter usufruire dei benefici introdotti dal nuovo stack di backup è necessario effettuare manualmente l’upgrade della subscription che detiene i Recovery Service Vault secondo le modalità in seguito descritte.

Considerazione pre-Upgrade

Prima di affrontare l’aggiornamento dello stack è opportuno considerare i seguenti aspetti:

  • Dal momento che l’upgrade viene attivato a livello di subscription Azure, la metodologia di esecuzione dei backup viene modificata per tutte le macchine virtuali protette, presenti nella subscription specifica. In futuro sarà possibile avere un controllo più granulare di questo processo di upgrade.
  • Le snapshot vengono salvate localmente per velocizzare il processo di creazione dei recovery point e per aumentare la velocità dei processi di restore. Questo comporta che saranno previsti dei costi per lo storage utilizzato dalle snapshot mantenute per 7 giorni.
  • Le snapshot incrementali vengono salvate come page blob. Per coloro che utilizzano managed disk non sono previsti costi aggiuntivi, mentre chi utilizza dischi unmanaged deve considerare anche il costo delle snapshot salvate (durante i 7 giorni) nello storage account locale.
  • In caso di ripristino di una VM premium, partendo da uno snapshot recovery point, sarà presente, durante la creazione della VM effettuata dal processo di restore, una location temporanea per lo storage.
  • Per gli storage account premium è necessario considerare un’allocazione di 10 TB di spazio, per le snapshot create a fini di instant recovery.

Come effettuare l’upgrade

L’upgrade può essere effettuato direttamente dal portale Azure oppure tramite comandi PowerShell.

Accedendo dal portale Azure al Recovery Service vault, comparirà la notifica che segnala la possibilità di effettuare l’aggiornamento dello stack di backup.

Figura 2 – Notifica di upgrade dello stack di backup

Selezionando la notifica comparirà la seguente segnalazione che consente di avviare il processo di upgrade.

Figura 3 – Avvio del processo di upgrade dello stack di backup

La medesima operazione può essere svolta utilizzando i seguenti comandi Powershell:

Figura 4 – Comandi Powershell per registrare la subscription al processo di upgrade

L’aggiornamento dello stack di backup richiede generalmente diversi minuti (massimo due ore), ma non ha nessun impatto sulle operazioni di backup schedulate.

Considerazioni

Questo importante aggiornamento dello stack di Azure Backup dimostra che la soluzione è in continua evoluzione per ampliare le sue potenzialità e per garantire maggiori livelli di performance. Per portare il proprio contributo con nuove idee o per votare le funzionalità che si ritengono maggiormente importanti per Azure Backup è possibile accedere a questa pagina. Per maggiori dettagli in merito ad Azure Backup è possibile consultare la documentazione ufficiale Microsoft.

Windows Server 2019: il nuovo servizio per la migrazione dello storage (Storage Migration Service)

Un problema noto che ruota da tempo intorno a Windows Server è la mancanza di una metodologia efficace per la migrazione dei dati presenti sui sistemi operativi e sugli storage più vecchi. A causa del fatto che gli upgrade in-place del sistema operativo non sono fattibili e che le migrazioni manuali sono spesso lente e richiedono importanti interruzioni del servizio, la tendenza è di continuare ad utilizzare versioni obsolete di Windows Server. In questo articolo saranno presentate le caratteristiche del nuovo servizio Storage Migration Service (SMS), incluso in Windows Server 2019, e sarà esaminato come questo servizio può effettuare la migrazione dello storage presente sulle vecchie piattaforme Windows Server per agevolarne la relativa dismissione.

Figura 1 – Panoramica di Storage Migration Server

Storage Migration Service, in questa prima versione, è in grado di trasferire i contenuti tramite il protocollo SMB (qualsiasi versione) verso target differenti, quali: hardware tradizionale e macchine virtuali on-prem, IaaS VMs in esecuzione su Azure o in Azure Stack, ed Azure File Sync.

La sorgente della migrazione può avere un sistema operativo dei seguenti:

  • Windows Server 2003
  • Windows Server 2008
  • Windows Server 2008 R2
  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows Server 2016
  • Windows Server 2019 Preview

Il nuovo ruolo Storage Migration Service (SMS) è possibile attivarlo sia nella Standard che nella Datacenter edition di Windows Server 2019, tramite Windows Admin Center, Powershell oppure Server Manager.

Figura 2 – Installazione, da Windows Admin Center, delle funzionalità relative a SMS

La funzionalità SMS è composta da un servizio orchestratore (Storage Migration Service Orchestrator Node) e da uno o più servizi proxy. L’orchestratore gestisce le migrazioni e mantieni i vari risultati in un repository, mentre i sistemi proxies arricchiscono con ulteriori funzionalità il processo di migrazione e consentono di ottenere maggiori performance.

La gestione del workflow di migrazione, reso possibile dal ruolo SMS, può essere totalmente orchestrato attraverso Windows Admin Center (conosciuto anche con il nome di Project Honolulu). Grazie a questo strumento di gestione, si ha la possibilità di migrare simultaneamente lo storage, che risiede su più sistemi, verso nuovi target presenti nell’ambiente on-premises oppure in Azure.

Storage Migration Service è in grado di gestire i problemi più comuni che si hanno quando si devono affrontare migrazioni storage, tra i quali: file in uso, impostazioni delle share, impostazioni di security, nomi e indirizzi di rete, local security principals ed encrypted data. Tutte queste operazioni sono facilmente gestibili da una interfaccia grafica intuitiva, che maschera le robuste automazioni necessarie, basate su PowerShell.

Per poter gestire Storage Migration Service da Windows Admin Center è necessario installare la specifica extension ad oggi in preview.

Figura 3 – Installazione in Windows Admin Center dell’Extension di SMS

Dopo aver aggiunto l’Extension specifica sarà possibile creare nuovi job di migrazione.

Figura 4 – Aggiunta di un job di SMS

Storage Migration Service consente di approcciare la procedura di migrazione dello storage in 3 differenti fasi:

  1. Inventory di server esistenti (sorgente), al fine di recuperare informazioni in merito ai dati presenti, alla relativa security, alle share SMB e alle impostazioni di rete.

Figura 5 –  Fase di Inventory

 

  1. Migrazione, tramite il protocollo SMB, dei dati, della security e delle impostazioni di rete verso un nuovo sistema (target).

 

Figura 6 –  Fase di Transfer

  1. Gestione dell’identità, effettuando il decommissioning della vecchia sorgente, in modo da rendere la migrazione trasparente agli utenti e alle applicazioni, e senza generare disservizi. In questa fase verrà trasferita l’identità al nuovo server, gestendo le impostazioni di rete, la join al dominio e il rename del server sorgente. Questa fase, definita di Cutover, ad oggi (maggio 2018) non è ancora disponibile al pubblico.

Conclusioni

Storage Migration Server è un nuovo strumento presente in Windows Server 2019, tuttora in fase di pieno sviluppo, che sarà arricchito nei prossimi rilasci con funzionalità innovative. Il potenziale mostrato è davvero interessante e certamente in futuro sarà un servizio ampliamente utilizzato per affrontare agilmente la migrazione di contenuti da piattaforme obsolete, favorendone così la loro dismissione. Per chi volesse testare in anteprima le novità di Windows Server 2019 può partecipare al programma Windows Insider. Si ricorda infine che le versioni in preview di Windows Server 2019 e Storage Migration Service non sono ufficialmente supportate in ambienti di produzione.

OMS e System Center: novità di Aprile 2018

Microsoft annuncia in modo costante novità riguardanti Operations Management Suite (OMS) e System Center. La nostra community rilascia mensilmente questo riepilogo, che consente di avere una panoramica complessiva delle principali novità del mese, in modo da rimanere sempre aggiornati su questi argomenti ed avere i riferimenti necessari per condurre eventuali approfondimenti.

Operations Management Suite (OMS)

Log Analytics

Microsoft ha deciso di estendere gli Alerts presenti in Log Analytics dal portale OMS verso il portale Azure, facendoli confluire in Azure Monitor. Questo processo avverrà in modo automatico a partire dal 14 Maggio 2018 (la data è stata posticipata, inizialmente era prevista per il 23 Aprile), non comporterà nessun tipo di modifica alla configurazione degli Alerts e delle relative query, e non prevede nessun downtime per la sua attuazione. Per maggiori informazioni a riguardo è possibile consultare l’articolo specifico “L’estensione degli Alerts di Log Analytics in Azure Monitor“.

Figura 1 – Notifica estensione alerts nel portale OMS

Per evitare situazioni dove, le risorse gestite in Log Analytics inviino in modo inaspettato un elevato volume dei dati verso il Workspace OMS, è stata introdotta la possibilità di fissare un Daily Volume cap. Questo consente di limitare la data ingestion giornaliera per il proprio workspace. Il Data volume cap è possibile configurarlo in tutte le regions, accedendo nella sezione Usage and estimated costs:

Figura 2 – Impostazione del Daily volume cap

Il portale mostra inoltre il trend del volume dei dati negli ultimi 31 giorni e il totale del volume dei dati, suddiviso per solution:

Figura 3 – Data ingestion per solution (ultimi 31 giorni e totale)

L’utilizzo della Log Search API, utilizzata dal vecchio linguaggio di query di Log Analytics, è stato deprecato a partire dal 30 Aprile 2018. La Log Search API è stata sostituita con l’Azure Log Analytics REST API, la quale supporta il nuovo linguaggio di query e introduce una maggiore scalabilità rispetto ai risultati che è in grado di restituire. Per maggiori dettagli a riguardo è possibile consultare l’annuncio ufficiale.

Agente

Questo mese la nuova versione dell’agente OMS per sistemi Linux risolve un importante numero di bug e introduce nuove versioni dei vari componenti. Viene inoltre introdotto il supporto per Debian 9, AWS 2017 e Open SSL 1.1. Per ottenere la versione aggiornata dell’agente OMS è possibile accedere alla pagina ufficiale GitHub OMS Agent for Linux Patch v1.6.0-42.

Figura 4 – Elenco Bug Fix e novità del nuovo agente OMS per Linux

Azure Backup

Per quanto riguarda Azure Backup sono stati annunciati i seguenti miglioramenti nella scalabilità del servizio:

  • Possibilità di creare fino a 500 recovery services vaults in ogni subscription per region (in precedenza il limite era di 25).
  • Il numero di macchine virtuali che può essere registrato in ogni vault è aumentato a 1000 (precedentemente era 200).

Azure Backup, per la protezione delle Azure Iaas VM, ora supporta gli storage account messi in sicurezza utilizzando storage firewalls and Virtual Networks. Per maggiori dettali a riguardo è possibile consultare il blog ufficiale Microsoft.

Figura 5 – Protezione Azure Iaas VM in scenari di storage protetti

Cambiano le modalità previste per abilitare il backup long-term per gli Azure SQL Database. La procedura, per consentire di mantenere il backup degli Azure SQL DB fino a 10 anni, prevedeva il salvataggio all’interno di un Azure Recovery Service Vault. Grazie all’introduzione di questa nuova funzionalità, si ha la possibilità di mantenere il backup long-term direttamente all’interno di un Azure Blob Storage e viene a decadere l’esigenza di un Recovery Service Vault. Tutto ciò consente di avere più flessibilità e un maggiore controllo dei costi. Per maggiori dettagli a riguardo è possibile consultare l’articolo SQL Database: Long-term backup retention preview includes major updates.

System Center

System Center Configuration Manager

Per System Center Configuration Manager è stata rilasciata la versione 1804 per il branch Technical Preview. Oltre che improvements generici nella soluzione vengono introdotte novità riguardanti l’OSD, il Software Center e l’infrastruttura di Configuration Manager. Tutte le nuove funzionalità incluse in questo update possono essere consultate nell’articolo Update 1804 for Configuration Manager Technical Preview Branch. Si ricorda che i rilasci nel Technical Preview Branch consentono di valutare in anteprima le nuove funzionalità di SCCM ed è consigliato applicare questi aggiornamenti solo in ambienti di test.

System Center Operations Manager

Microsoft ha rilasciato l’Update Rollup 5 (UR5) per System Center 2016 Long-Term Servicing Channel (LTSC). Questo aggiornamento non introduce nuove funzionalità, ma risolve diversi bug.

In seguito, si riportano i riferimenti, riguardanti questo aggiornamento, per ogni prodotto System Center:

Non sono presenti invece aggiornamenti riguardanti Service Provider Foundation.

System Center Operations Manager 1801 introduce il supporto per la Kerberos authentication quando il protocollo WS-Management viene utilizzato dal management server per la comunicazione con i sistemi UNIX e Linux. Questo consente di avere un maggiore Livello di sicurezza, eliminando la necessità di abilitare la basic authentication per Windows Remote Management (WinRM).

Inoltre in System Center Operations Manager 1801 sono stati introdotti i seguenti miglioramenti riguardanti la gestione del monitor dei file di log di Linux:

  • Supporto per caratteri Wild Card nel nome e nel percorso del file di log.
  • Supporto per nuovi match patterns che consentono ricerche personalizzate dei log.
  • Supporto per pluging Fluentd pubblicati dalla community fluentd.

In seguito si riportano le novità riguardanti i Management Pack di SCOM:

  • MP per Windows Server Operating System 2016 e 1709 Plus 10.0.19.0
  • MP per SQL Server 2008-2012 7.0.4.0
  • MP per SQL Server 2014 7.0.4.0
  • MP per SQL Server 2016 7.0.4.0
  • MP per Microsoft Azure SQL Database 7.0.4.0
  • MP per SQL Server Dashboards 7.0.4.0
  • MP per UNIX e Linux 7.6.1085.0

Valutazione di OMS e System Center

Si ricorda che per testare e valutare in modo gratuito Operations Management Suite (OMS) è possibile accedere a questa pagina e selezionare la modalità che si ritiene più idonea per le proprie esigenze.

Per provare i vari componenti di System Center 2016 è possibile accedere a l’Evaluation Center e dopo essersi registrati è possibile avviare il periodo di trial.

Storage Replica: le novità di Windows Server 2019 e la gestione con Windows Admin Center

Storage Replica, in casa Microsoft, è una tecnologia introdotta in Windows Server 2016 che consente di replicare, in modo sincrono oppure asincrono, volumi tra server o cluster, a fini di disaster recovery. Questa tecnologia consente inoltre di realizzare dei stretch failover cluster con nodi dislocati su due site differenti, mantenendo in sync lo storage. In questo articolo saranno presentate le novità, riguardanti Storage Replica, che verranno introdotte in Windows Server 2019 e verrà mostrato come attivare Storage Replica utilizzando il nuovo strumento di gestione Windows Admin Center.

 

Le novità di Storage Replica in Windows Server 2019

In Windows Server 2016 c’è la possibilità di utilizzare Storage Replica solamente se si utilizza la versione Datacenter Edition del sistema operativo, mentre in Windows Server 2019 ci sarà la possibilità di attivare Storage Replica anche adottando la Standard Edition, ma al momento con le seguenti limitazioni:

  • Sarà possibile replicare un singolo volume anziché un numero illimitato di volumi.
  • La dimensione massima del volume replicato non dovrà superare i 2 TB.
  • Il volume in replica potrà avere una sola partnership, invece che un numero illimitato di partners.

Grazie all’adozione di un nuovo formato di Log utilizzato da Storage Replica (Log v1.1), vengono introdotti importati miglioramenti di performance riguardanti il throughput e la latenza. Sarà possibile beneficiare di questi miglioramenti se tutti i sistemi coinvolti nel processo di replica saranno Windows Server 2019 e saranno in particolar modo evidenti su array all-flash e in cluster Storage Spaces Direct (S2D).

Per validare l’efficacia del processo di replica è stata introdotta la possibilità di effettuare un Test Failover. Attraverso questa nuova funzionalità è possibile effettuare il mount di una writable snapshot dello storage replicato. Per poter compiere questa operazione, a fini di test o backup, è necessario disporre di un volume, non coinvolto nel processo di replica, sul server di destinazione. Il Test Failover non ha impatto sul processo di replica, il quale continuerà a garantire la protezione del dato e le modifiche apportate alla snapshot rimarranno circoscritte al volume di test. Al termine dei test è opportuno effettuare un discard della snapshot.

Storage Replica in Windows Admin Center

Windows Admin Center, conosciuto anche con il nome di Project Honolulu, consente tramite una console web basata su HTML5, di gestire la propria infrastruttura in modo centralizzato.

Tramite Windows Admin Center è possibile installare sui server la feature Storage Replica e il relativo modulo PowerShell.

Figura 1 – Aggiunta della feature Storage Replica da Windows Admin Center

Figura 2 – Conferma installazione di Storage Replica e delle relative dipendenze

Figura 3 – Notifica dell’installazione avvenuta con successo

Al termine dell’installazione è richiesto un riavvio del server.

Giunti a questo punto è possibile configurare, tramite Windows Admin Center, una nuova partnership di replica. La stessa operazione potrebbe essere compiuta utilizzando il cmdlet Powershell New-SRPartnership.

Figura 4 – Aggiunta nuova partnership di Storage Replica tra due replication Group

Figura 5 – Impostazioni richieste per la configurazione della Partnership

Windows Admin Center riporta, al termine della configurazione, i dettagli della partnership.

Figura 6 – Dettagli della partnership di replica

Inoltre, è possibile gestire lo stato della replica (suspend \ resume), invertire la direzione della sincronizzazione e modificare le configurazioni (aggiunta \ rimozione dei volumi di replica e impostazioni della partnership).

Figura 7 – Switch della direzione della replica

Figura 8 – Modifica delle impostazioni della partnership di replica

Conclusioni

Windows Server 2019 introdurrà significativi cambiamenti nel servizio di Storage Replica che, oltre ad evolverlo in termini di performance ed efficacia, lo renderanno anche maggiormente accessibile. Il tutto viene arricchito dalla possibilità offerta da Windows Admin Center di gestire in modo semplice, rapido e completo anche Storage Replica. Microsoft sta facendo importanti investimenti in ambito storage e i risultati sono evidenti e tangibili. Per chi volesse testare in anteprima le novità di Windows Server 2019 può partecipare al programma Windows Insider.

 

 

Azure Monitor: come controllare lo stato di salute dei servizi Azure

Azure Monitor, tramite il servizio Azure Service Health, è in grado di fornire indicazioni dettagliate nel caso dovessero verificarsi condizioni che influenzano il funzionamento dei propri servizi presenti nel cloud Microsoft. In questo articolo si approfondirà come Azure Service Health può essere di aiuto per identificare l’impatto dei problemi, inviare notifiche e mantenere gli amministratori dell’ambiente aggiornati man mano che il problema si risolve. Verrà inoltre approfondito come questo servizio può essere di aiuto per prepararsi a manutenzioni programmate e per capire come queste potrebbero influire sulla disponibilità delle proprie risorse.

Per avere una visuale sullo stato globale di salute di Azure, Microsoft mette a disposizione la relativa pagina di stato, che riporta in tempo reale la situazione dei vari prodotti e servizi, suddivisi per area geografica. In questa pagina vengono riportati tutti i problemi, anche quelli che non influiscono direttamente sullo stato dei propri servizi.

Per ottenere una vista personalizzata, che contempla solamente le proprie risorse, si può utilizzare Azure Service Health. In questo modo viene favorita l’individuazione tempestiva delle informazioni riguardanti i seguenti aspetti:

  • Problemi sui servizi: vengono riportati i problemi relativi ai servizi Azure che impattano sulle proprie risorse.
  • Manutenzioni programmate: sono elencate le future manutenzioni che interessano la disponibilità dei propri servizi.
  • Health advisories: si tratta dei cambiamenti nei servizi Azure che richiedono attenzione. Possibili esempi a riguardo possono essere segnalazioni in merito al superamento di determinate quote di utilizzo oppure quando determinate funzionalità di Azure vengono deprecate.

Figura 1 – Sezioni di Azure Service Health presenti nel portale Azure

Accedendo alla sezione Azure Service Health – Service issues, presente in Azure Monitor, è possibile effettuare la creazione di dashboard personalizzate. Al fine di ricevere le notifiche solamente per le risorse di proprio interesse, viene richiesto di selezionare le subsbription, le region e i servizi opportuni. Al termine di questa selezione è possibile salvare i filtri impostati assegnandogli un nome.

Figura 2 – Selezione delle regions

Figura 3 – Selezione dei servizi Azure

Figura 4 – Salvataggio del filtro e assegnazione del nome

Selezionando il pulsante “Pin filtered world map to dashboard” è possibile visualizzare la mappa personalizzata nella dashboard del portale Azure, in modo da avere istantaneamente un impatto visivo sullo stato di salute delle subscription, dei servizi e delle regions prescelte.

Figura 5 – Mappa, con i filtri applicati, riportata nella dashboard

Nel caso dovessero emergere problematiche che impattano le proprie risorse su Azure, accedendo al portale, si riceverà una notifica analoga alla seguente:

Figura 6 – Segnalazione di una problematica in atto che impatta i propri servizi

Selezionando la mappa personalizzata si viene rimandati nella sezione Azure Service Health di Azure Monitor. In questa dashboard vengono riportati i relativi dettagli e l’elenco delle proprie risorse, che potenzialmente potranno essere impattate dalla problematica, oltre che i relativi aggiornamenti di stato.

Figura 7 – Summary della problematica

Da questa pagina sarà possibile anche scaricare la documentazione in formato PDF (in alcuni casi anche in formato CSV) che descrive la problematica, per poter essere inviata a chi non ha accesso diretto al portale Azure. Sono presenti inoltre i link utili per poter contattare il supporto Microsoft nel caso persistano delle condizioni di errore dopo che il problema viene segnalato come risolto.

Figura 8 – Risorse potenzialmente impattate dalla problematica

Nella sezione Health history vengono riportati i problemi passati riscontrati sui servizi Azure e che hanno avuto un impatto sullo stato di salute delle proprie risorse.

Figura 9 – Elenco dei problemi riportati nella Health history

Azure Service Health, nella sezione Resource health, consente inoltre di visualizzare lo stato di salute delle proprie risorse suddividendole per tipologia.

Figura 10 – Stato di salute delle risorse per tipologia

Selezionando il singolo servizio Azure è possibile consultare sia lo stato di salute attuale che eventuali problemi accaduti in passato su una determinata risorsa.

Figura 11 – Stato di salute attuale ed eventi passati di una specifica risorsa Virtual Machine

Grazie alla completa integrazione di Service Health in Azure Monitor, il quale detiene il motore di alerting di Azure, è possibile configurare degli Alerts specifici qualora ci siano problemi lato Azure, che impattano sul funzionamento delle risorse presenti sulle proprie subscription. La notifica avviene tramite Action Groups, che comprende ad oggi queste possibili azioni:

  • Chiamata vocale (al momento solo USA) oppure invio di SMS (per i paesi abilitati).
  • Invio di una mail.
  • Chiamata a un webhook.
  • Invio di dati verso ITSM.
  • Richiamo di una Logic App.
  • Invio di una notifica push sulla mobile app di Azure.
  • Esecuzione di un runbook di Azure Automation.

Figura 12 – Aggiunta di un Service Health Alert

Figura 13 – Configurazione di un Service Health Alert

Conclusioni

La recente disponibilità di Azure Service Health, ha introdotto la possibilità di ricevere informazioni personalizzate e mirate sullo stato di salute delle proprie risorse Azure, senza dover ricercare i potenziali problemi di Azure a livello globale accedendo alla relativa pagina di stato. Questo consente di risparmiare tempo e di capire facilmente, a fronte di problematiche oppure di manutenzioni programmate, qual è l’impatto sui propri servizi.

L’estensione degli Alerts di Log Analytics in Azure Monitor

Poter usufruire di un servizio centralizzato ed efficace per la gestione degli Alerts della propria infrastruttura è sicuramente un aspetto importante e fondamentale nella strategia di monitor. A questo scopo Microsoft ha introdotto una nuova experience nella gestione degli Alerts tramite la soluzione Azure Monitor. In questo articolo verrà presentato come evolverà la gestione degli Alerts in Log Analytics e quali sono i benefici introdotti da questo cambiamento.

In Log Analytics c’è la possibilità di generare degli Alerts quando, a fronte di una ricerca che avviene con frequenza schedulata nel repository di OMS, si ottengono dei risultati che fanno match con i criteri stabiliti. Nel momento in cui viene generato un Alert in Log Analytics si possono configurare le seguenti azioni:

  • Notifica via email.
  • Invocazione di un webhook.
  • Esecuzione di un runbook di Azure Automation.
  • Attività di IT Service Management (richiede la presenza del connettore per la solution ITSM).

Figura 1 – Alerts in Log Analytics

Fino ad oggi questo tipo di configurazione è stata gestita dal portale OMS.

Azure Monitor è un servizio che oltre a consente di monitorare tutte le risorse Azure borne, detiene l’engine di “alerting” per l’intera piattaforma cloud. Accedendo al servizio dal portale Azure si avranno infatti a disposizione, in una unica location, tutti gli Alerts della propria infrastruttura, provenienti da Azure Monitor, Log Analytics, e Application Insights. Si potrà quindi usufruire di una experience unificata sia per quanto riguarda la consultazione degli Alerts che per il relativo authoring.

Allo stato attuale gli Alerts creati in Log Analytics vengono già riportati nella dashboard di Azure Monitor, ma l’eventuale modifica comporta l’accesso al portale OMS. Per agevolare questa gestione Microsoft ha quindi deciso di estendere gli Alerts presenti in Log Analytics dal portale OMS verso il portale Azure. Questo processo avverrà in modo automatico a partire dal 23 Aprile 2018, non comporterà nessun tipo di modifica alla configurazione degli Alerts e delle relative query, e non prevede nessun downtime per la sua attuazione.

Ne consegue che, dopo questa operazione, le eventuali azioni associate agli Alerts saranno effettuate tramite Action Groups, i quali saranno creati automaticamente dal processo di estensione.

L’estensione degli Alerts di Log Analytics nel portale Azure, oltre al vantaggio di poter consentire la gestione degli stessi da un unico portale, consente di usufruire dei seguenti benefici:

  • Non esiste più il limite dei 250 Alerts.
  • Si ha la possibilità di gestire, enumerare e visualizzare non solo gli Alerts di Log Analytics, ma anche quelli provenienti da altre fonti.
  • Si ha una maggiore flessibilità nelle azioni che si possono intraprendere a fronte di un Alerts, grazie all’utilizzo degli Action Groups, come ad esempio la possibilità di inviare SMS oppure di effettuare delle chiamate vocali.

Nel caso non si voglia attendere il processo automatico è possibile forzare la migrazione via API oppure dal portale OMS, secondo gli step in seguito documentati:

Figura 2 – Avvio del processo di “Extend into Azure” dal portale OMS

Figura 3 – Step 1: mostra i dettagli del processo di estensione.

Figura 4 – Step 2: summary delle modifiche proposte

Figura 5 – Step 3: conferma del processo di estensione

Specificando un indirizzo email è possibile ricevere una notifica al termine del processo di migrazione, contenente il summary report.

Figura 6 – Notifica dell’estensione degli Alerts pianificata

Durante il processo di estensione degli Alerts di Log Analytics in Azure non sarà possibile apportare delle modifiche agli Alerts esistenti e la creazione di nuovi Alerts dovrà avvenire da Azure Monitor.

Al termine del processo di estensione gli Alerts saranno comunque visibili anche dal portale OMS e si riceverà la notifica via mail, all’indirizzo specificato durante il wizard di migrazione:

Figura 7 – Mail di notifica al termine del processo di estensione

Dal portale Azure, nella sezione “Monitor – Alerts”, si avrà una gestione completa degli Alerts di Log Analytics:

Figura 8 – Esempio di modifica di una Alert Rule da Azure Monitor

L’estensione degli Alerts di Log Analytics in Azure Monitor non comporta dei costi, ma è opportuno tenere in considerazione che, l’utilizzo degli Azure Alerts generati da query di Log Analytics, non è soggetta a fatturazione solamente se rientra nei limiti e nelle condizioni riportati nella pagina dei costi di Azure Monitor.

Conclusioni

Grazie a questa attività di estensione degli Alerts di Log Analytics, Azure Monitor si conferma il nuovo engine di gestione di tutti gli Alerts, mettendo a disposizione degli amministratori una semplice e intuitiva interfaccia centralizzata ed arricchendo le possibili azioni di notifica a fronte di un alert.

OMS e System Center: novità di Marzo 2018

Nel mese di marzo ci sono state diverse novità annunciate da parte di Microsoft riguardanti Operations Management Suite (OMS) e System Center. In questa serie di articoli, che realizziamo con cadenza mensile, vengono elencate tutte le principali novità del mese corrente, accompagnate dai riferimenti necessari per poter effettuare ulteriori approfondimenti in merito.

Operations Management Suite (OMS)

Azure Automation

In Azure Automation sono state ufficialmente rilasciate le nuove funzionalità che consentono di:

  • Gestire la distribuzione degli aggiornamenti (Update management).
  • Raccogliere informazioni di inventario relative alle applicazioni installate sui sistemi (Inventory).
  • Tenere traccia delle modifiche apportare sulle macchine (Change tracking).

Il nostro articolo, pubblicato nei mesi scorsi, mostra come configurare l’Azure Automation Account per poter usufruire di queste nuove funzionalità e ne riporta le principali caratteristiche.

Figura 1 – Relative solution presenti in Log Analytics


Azure Backup

In Azure Backup sono state introdotte diverse novità che riguardano i seguenti aspetti:

  • Large disk support: possibilità di proteggere dischi di dimensione fino ai 4TB, sia di tipologia managed che unmanaged. Il limite in precedenza era di un 1TB.
  • Backup and Restore performance improvements: per ridurre i tempi di esecuzione dei backup e dei restore verranno mantenute le snapshot, effettuate durante il processo di backup, per 7 giorni.
  • Instant recovery point: i recovery point vengono resi disponibili istantaneamente nel momento della creazione della snapshot effettuata dal job di backup, in modo del tutto analogo ai checkpoint creati da Hyper-V oppure da VMware.
  • Distribute the disks of restored VM: durante i processi di restore viene fornita la possibilità di scegliere dove posizionare i dischi unmanaged delle macchine virtuali. Questo riduce le configurazioni, post attività di restore, che sarebbero necessarie mettendo tutti i dischi all’interno dello stesso storage account.

Per poter usufruire di questi improvements è necessario effettuare l’upgrade della subscription che detiene i Recovery Service Vault. L’upgrade può essere effettuato direttamente dal portale Azure (sarà presente una apposita notifica nella dashboard dei Recovery Service vault) oppure tramite comandi PowerShell. Per maggiori informazioni a riguardo è possibile consultare l’annuncio ufficiale Microsoft.

Figura 2 – Avvio del processo di upgrade della subscription al nuovo stack

Microsoft ha inoltre annunciato che il servizio Azure Backup è ora disponibile anche nelle region Azure della Francia (France Central e France South).

 

System Center

Microsoft ha ufficializzato il rilascio di Windows Server 2019 che sarà disponibile al pubblico nella seconda parte del 2018. Contestualmente verrà reso disponibile anche System Center 2019 che avrà il pieno supporto per Windows Server 2019 fin dal primo giorno del rilascio.

System Center Configuration Manager

Nel corso del mese è stata rilasciata la versione 1802 per il Current Branch (CB) di System Center Configuration Manager che introduce nuove funzionalità e importanti miglioramenti nel prodotto.

Queste in sintesi gli ambiti impattati da questo aggiornamento:

Modern Management

  • Endpoint Protection workload transition in co-management
  • Management insights
  • Co-management reporting

Figura 3 –  Co-management reporting

Microsoft 365 Adoption

  • Phased deployments
  • Windows AutoPilot Device Information report
  • Support for Windows 10 ARM64 devices
  • Surface Device Dashboard
  • Microsoft Edge browser policies
  • Report to show default browser for client machines
  • Windows 10 Servicing for a specific collection report
  • Improvements to Office 365 client management dashboard
  • Improvements for Windows Defender Exploit Guard
  • New settings for Windows Defender Application Guard

Streamlined Infrastructure

  • Configure Windows 10 Delivery Optimization to use Configuration Manager boundary groups
  • Add management points to your boundary group fallback relationships
  • Moving Distribution Points between sites

Improvements in Cloud Management Gateway

  • Cloud management gateway support for Azure Resource Manager
  • Install user-available applications on Azure AD-joined devices
  • Windows 10 in-place upgrade task sequence over the Internet

Improvements in Software Center

  • Approve application requests for users per device
  • Improvements to client settings for Software Center

Improvements in OSD

  • Improvements to Windows 10 in-place upgrade task sequence
  • Deployment Template for Task Sequences

Miscellaneous Improvements

  • Support for hardware inventory strings greater than 255 characters in length
  • Run scripts

Figura 4 –  Run Script status

Per consultare la lista completa delle nuove funzionalità e per avere maggiori dettagli a riguardo è possibile accedere alla documentazione ufficiale Microsoft.

L’aggiornamento verrà reso disponibile in queste settimane a livello globale e sarà riportato nel nodo “Updates and Servicing” della console di SCCM. Per forzare la disponibilità di questo aggiornamento è possibile utilizzare questo script PowerShell.

Per System Center Configuration Manager è stata rilasciata la versione 1803 per il branch Technical Preview. Oltre che improvements generici nella soluzione vengono introdotte utili modifiche che possono migliorare l’infrastruttura di Configuration Manager. Inoltre, sono stati apportati interessanti miglioramenti riguardanti il Software Center. Tutte le nuove funzionalità incluse in questo update possono essere consultate nell’articolo Update 1803 for Configuration Manager Technical Preview Branch.

Si ricorda che i rilasci nel Technical Preview Branch consentono di valutare in anteprima le nuove funzionalità di SCCM ed è consigliato applicare questi aggiornamenti solo in ambienti di test.

System Center Updates Publisher

System Center Updates Publisher (SCUP)  è la soluzione Microsoft che consente di gestire custom update di terze parti. Questo mese una nuova versione di SCUP è stata rilasciata ufficialmente e può essere scaricata a questo indirizzo. La nuova release introduce il supporto per Windows 10 e Windows Server 2016. Tutti i dettagli in merito a questo rilascio possono essere consultati nell’annuncio ufficiale.

System Center Operations Manager

In seguito, si riportano le novità riguardanti i Management Pack di SCOM:

Valutazione di OMS e System Center

Si ricorda che per testare e valutare in modo gratuito Operations Management Suite (OMS) è possibile accedere a questa pagina e selezionare la modalità che si ritiene più idonea per le proprie esigenze.

Per provare i prodotti System Center è possibile accedere all’Evaluation Center e in seguito alla registrazione è possibile avviare il periodo di trial.

Azure SQL Database: come gestire la connettività con i vNet Service Endpoints

Per avere un maggiore controllo sugli accessi che vengono effettuati sugli Azure SQL Database, lo scorso mese, Microsoft ha rilasciato pubblicamente la possibilità di abilitare i Virtual Network (vNet) Service Endpoints per i SQL Database. In questo articolo verrà spiegato il principio di funzionamento, con i benefici che ne derivano, e verrà mostrata la relativa configurazione.

Caratteristiche e principi di funzionamento

I vNet Service Endpoints per gli Azure SQL Database consentono di isolare maggiormente i SQL Server logici presenti nel cloud Microsoft, garantendo l’accesso solamente da una o più subnet definite nelle proprie Virtual Network di Azure. Questa funzionalità garantisce che tutto il traffico generato dalle proprie vNet verso l’Azure SQL Database rimarrà sempre all’interno della rete di backbone di Azure. Si tratta di una funzionalità disponibile in tutte le region di Azure e non sono previsti costi aggiuntivi per il relativo utilizzo.

Figura 1 – Schema di sintesi dell’architettura

Sul firewall degli Azure SQL Database rimane la possibilità di abilitare la comunicazione da parte dei servizi Azure e di filtrare gli accessi sulla base di un range di IP Pubblici.

Figura 2 – Impostazioni firewall di Azure SQL Server

Abilitando l’impostazione “Allow access to Azure services” viene consentito l’accesso al SQL Server da tutti gli indirizzamenti IP pubblici di Azure e da tutte le subnet di Azure, comprese quelle non di propria appartenenza. Andando ad applicare ulteriori filtri sulla base dell’IP pubblico che si deve connettere può diventare di difficile gestione e richiedere la configurazione di indirizzi IP pubblici statici sulle risorse di Azure.

Grazie all’introduzione dei Virtual Network (vNet) Service Endpoints per SQL Server è possibile avere un maggiore controllo sulle potenziali comunicazioni e un minor effort di gestione delle risorse. Il principio di funzionamento dei vNet Service Endpoints non si estende al mondo on-premises anche in presenza di connettività con Azure (VPN oppure ExpressRoute), ma per consentire l’accesso da sistemi presenti on-premises è necessario continuare ad utilizzare le regole firewall per limitare la connettività solamente agli IP pubblici di propria appartenenza.

I Virtual Network (vNet) Service Endpoints sono disponibili, con lo stesso principio di funzionamento, anche per Azure Storage e per Azure SQL Datawarehouse (al momento in preview).

Come effettuare la configurazione

L’abilitazione dei vNet Service Endpoints richiede l’attivazione sulla subnet della virtual network di Azure, dalla quale ci si intende connettere al SQL Server, dell’Enpoint di SQL Server (Microsoft.SQL).

Figura 3 – Abilitazione del SQL Server Service Endpoint sulla subnet

Figura 4 – Service Endpoint di SQL Server abilitato con successo sulla subnet

Successivamente è necessario aggiungere lato SQL Database la virtual network, con il Service Endpoint abilitato, nella sezione Firewall and virtual networks.

Figura 5 – Aggiunta Virtual Network con Service Endpoint di SQL Server abilitato

Ogni Virtual Network Rule viene applicata a livello di Azure SQL Database server e non a livello di singolo database.

Questo tipo di configurazione comporta che collegandosi ai DB ospitati dall’Azure SQL Server da una macchina attestata su una vNet con i Service Endpoint abilitati, verrà utilizzato come source IP un indirizzo appartenente all’address space della vNet. Questo aspetto è da tenere in considerazione, in configurazioni esistenti, per evitare che quando si attiva il SQL Server Service Endpoint sulla subnet, venga bloccato l’accesso al SQL Server. A questo scopo è possibile evitare il blocco consentendo temporaneamente l’accesso tramite l’impostazione “Allow access to Azure services”, oppure definendo la vNet nelle firewall rule del SQL Server prima di abilitare il Service Endpoint sulla subnet. Per farlo è necessario utilizzando il flag IgnoreMissingServiceEndpoint oppure selezionare il flag seguente presente nel portale Azure:

Figura 6 – Aggiunta Virtual Network senza Service Endpoint di SQL Server abilitato

Conclusioni

I Virtual Network (vNet) Service Endpoints sono in grado di estendere le proprie virtual network di Azure e la relativa identità verso determinati servizi di Azure, come Azure SQL Server, tramite una connessione diretta. Questo consente di aumentare il livello di sicurezza dei propri servizi presenti nel cloud Microsoft, di ottimizzare il routing per accedere alle risorse Azure dalle proprie vNet e di diminuire l’effort di gestione, il tutto con pochi semplici passaggi.

Come monitora le attività di rete nel cloud Azure con Traffic Analytics

Le reti nel mondo cloud presentano differenze sostanziali rispetto a quelle presenti in ambiente on-premises, ma sono accomunate dalla necessità di essere costantemente monitorate, gestite e analizzate. Tutto ciò è importante per poterle conoscere al meglio, al fine di proteggerle ed ottimizzarle. Microsoft ha introdotto in Azure la soluzione Traffic Analytics, totalmente cloud-based, che consente di avere una visibilità complessiva sulle attività di rete che vengono intraprese nell’ambiente cloud. Questo articolo analizza le caratteristiche della soluzione e spiega come è possibile attivarla.

Principi di funzionamento della soluzione

In Azure per poter consentire o negare la comunicazione di rete verso le risorse connesse alle Azure Virtual Networks (vNet) vengono utilizzati i Network Security Group (NSG), che contengono una lista di regole di accesso. I NSG vengono applicati alle interfacce di rete connesse alle macchine virtuali oppure direttamente alle subnet. La platform utilizza i NSG flow logs per mantenere la visibilità del traffico di rete in ingresso e in uscita dai Network Security Group. Traffic Analytics si basa sull’analisi dei NSG flow logs e dopo una opportuna aggregazione dei dati, inserendo l’intelligence necessaria relativamente a security, topologia e mappa geografica, è in grado di fornire informazioni dettagliate sul traffico di rete del proprio ambiente cloud Azure.

Figura 1 – Data flow di Traffic Analytics

Funzionalità della soluzione

Utilizzando Traffic Analytics si possono effettuare le seguenti operazioni:

  • Visualizzare le attività di rete cross Azure subscriptions e identificare hotspots.
  • Intercettare potenziali minacce di security lato network, per poi poter adottare le giuste operazioni correttive. Questo viene reso possibile grazie alle informazioni riportate dalla soluzione: quali porte sono aperte, quali applicazioni tentano di accedere verso Internet e quali macchine virtuali si connettono a reti non autorizzate.
  • Comprendere i flussi di rete presenti tra le varie region Azure e Internet, al fine di ottimizzare il proprio deployment di rete in termini di performance e capacità.
  • Individuare configurazioni di rete non corrette che portano ad avere tentativi di comunicazione errati.

Come abilitare la soluzione

Per poter analizzare il traffico di rete è necessario disporre di un Network Watcher in ogni region dove sono presenti i NSG per i quali si intente analizzare il traffico. Il Network Watcher è un servizio regionale grazie al quale è possibile monitorare e diagnosticare il networking di Azure. L’abilitazione del Network Watcher può essere fatta dal portale Azure, tramite Powershell oppure via REST API. Creandolo dal portale non è possibile stabilire il nome del Network Watcher e il relativo Resource Group, ma viene assegnato un nome di default a entrambe le entità.

Figura 2 – Abilitazione del Network Watcher dal portale

Figura 3 – Abilitazione del Network Watcher tramite PowerShell

Trattandosi di un servizio in preview per poterlo utilizzare è necessario effettuare nuovamente la registrazione del network resource provider sulla subscription Azure interessata. Inoltre è necessario registrare il provider Azure Insights.

Figura 4 – Registrazione dei provider tramite PowerShell

Per poter abilitare la raccolta degli NSG Flow Logs è necessario dotarsi di uno storage account sul quale memorizzarli. Inoltre è necessario disporre di un workspace OMS Log Analytics sul quale Traffic Analytics consoliderà i dati aggregati e indicizzati. Le informazioni presenti in Log Analytics verranno poi utilizzate per generare la relativa analisi.

Primo step di configurazione delle impostazioni dei NSG flow logs:

Figura 5 – Selezione dei NSG sui quali abilitare la raccolta dei flow logs

Scelta dello storage account e del workspace OMS Log Analytics per ogni NSG:

Figura 6 – Abilitazione della raccolta dei NSG flow logs e del consolidamento in OMS Log Analytics

Gli step precedentemente riportati dovranno essere ripetuti per ogni NSG per il quale si desidera abilitare Traffic Analytics.

Figura 7 – Lista dei NSGs con le impostazioni abilitate

Entro alcuni minuti dall’abilitazione, tempo necessario per avere un quantitativo di dati aggregati sufficientemente indicativo, viene popolata la relativa dashboard con le informazioni di Traffic Analytics.

Figura 8 – Dashboard di Traffic Analytics

Dalla dashboard di Traffic Analytics sono facilmente reperibili le informazioni quali: gli host con un livello elevato di comunicazione, i protocolli applicativi maggiormente utilizzati, le comunicazioni che avvengono in modo più frequente e i flussi relativi al traffico di rete nel cloud.

Selezionando la sezione di interesse viene mostrata la query di Log Analytics che estrapola i dati:

Figura 9 – Esempio di query Log Analytics che mostra il traffico malicious consentito

Per avere una panoramica completa dei possibili scenari di utilizzo di Traffic Analytics è possibile consultare questo documento Microsoft.

Conclusioni

Traffic Analytics è una nuova funzionalità, al momento in preview, introdotta in Azure. Si tratta di uno strumento efficace e di facile utilizzo che consente di tenere sotto controllo lo stato della rete in Azure riportando dati molto utili, come chi si sta collegando e dove, quali porte sono esposte verso internet, quale traffico di rete viene generato e molto altro. Si tratta di informazioni fondamentali per individuare eventuali anomalie e apportare le dovute azioni correttive. Tutte operazioni di difficile raggiungimento senza questo strumento totalmente integrato nella platform.

Virtual Machine Manager 1801: il processo di upgrade e la possibile problematica

A partire da quest’anno per Virtual Machine Manager, così come per altri prodotti System Center, verrà rilasciata una versione aggiornata ogni 6 mesi (semi-annual channel). Nel mese di febbraio è stata annunciata la versione 1801 di System Center Virtual Machine Manager e l’aggiornamento è consigliato per poter usufruire delle nuove funzionalità introdotte e per avere una maggiore integrazione con Microsoft Azure. In questo articolo viene descritta una problematica che è possibile riscontrare in fase di upgrade, riportando nel dettaglio le cause e come è possibile risolverla.

Per poter passare alla versione 1801 di System Center Virtual Machine Manager (SCVMM 1801) non è possibile fare un upgrade in place, ma è necessario disinstallare completamente SCVMM mantenendo il database, ed effettuare una nuova installazione utilizzando il database esistente. La procedura dettagliata è descritta in questo documento Microsoft e richiede una attenta verifica preliminare dei requisiti oltre che di disporre, a fini precauzionali, di un backup del database di SCVMM. Nel caso si stiano utilizzando più prodotti System Center è importante procedere con l’aggiornamento secondo la sequenza riportata nel documento.

Figura 1 – Step del Wizard di installazione con utilizzo del DB esistente di VMM

Durante il setup l’installazione di Virtual Machine Manager 1801 potrebbe fallire con il seguente errore: “Unable to connect to the VMM database because of a general database failure. Ensure that the SQL Server is running and configured correctly, then try the operation againg“.

Figura 2 – Errore in fase di upgrade alla versione 1801

Come si può notare si tratta di un errore generico e per ottenere maggiori dettagli è necessario consultare il log del Wizard (“C:ProgramDataVMMLogsSetupWizard.log“) che riporta i seguenti dettagli:

Figura 3 – Errore riportato nel log di installazione

L’errore rimanda a una problematica nota documentata nelle release notes di VMM 1801:

Figura 4 –  Problema noto documentato

Il problema viene generato se nell’attuale installazione di Virtual Machine Manager è stato modificato il nome di una delle port classification presenti di default. Nel caso specifico, controllando la tabella “[dbo].[tbl_NetMan_PortClassification]” del database di Virtual Machine Manager, risulta presente una entry, con l’ID riportato nell’errore, avente il nome “Management” anziché “Host management” (nome di default).

Figura 5 –  Entry con nome non di default nella tabella “tbl_NetMan_PortClassification”

La difficoltà quando si presenta questo errore è nel conoscere con precisione quali sono i nomi di default delle port classification. Per questo motivo si riportano in seguito le default port classification che è necessario che non siano modificate nel nome per consentire l’upgrade a SCVMM 1801.

Figura 6 – Port classification presenti di default

Se ci si trova in questa condizione è necessario modificare i nomi delle port classification, sopra riportate, portandoli tutti al default ed in seguito ripetere il setup di installazione di SCVMM 1801.

Al termine di questa operazione il setup di SCVMM 1801 non terminerà con l’errore precedentemente descritto.

Figura 7 – Upgrade di SCVMM 1801 completato con successo

La modifica alle port classification può essere temporanea e in seguito all’aggiornamento è possibile valutare se necessario di nominarle a proprio piacimento.

Conclusioni

Questa specifica condizione di errore si presenta in modo sistematico se ci si trova nella situazione descritta, quindi è bene considerarla se possibile prima di procedere con l’upgrade di SCVMM 1801, in modo da evitarla. Nel caso si dovesse riscontrare l’errore è comunque possibile risolverlo facilmente con le informazioni riportate nell’articolo.