Archivi categoria: Windows Server

WSUS Retirement: Impact and Strategies for Server System Updates

With Microsoft’s announcement regarding the retirement of Windows Server Update Services (WSUS), a new chapter begins in managing updates for server systems. After almost 20 years since its release, WSUS will no longer be actively developed, creating uncertainty among IT administrators who have relied on this tool to distribute updates in enterprise environments. In this article, we will analyze the impact of this decision and possible migration strategies, with a particular focus on server systems.

What is WSUS and What Does Its Retirement Mean?

Windows Server Update Services (WSUS) has been the go-to tool for managing and distributing Microsoft product updates within enterprise networks for years. IT administrators can approve, schedule, and control the distribution of updates, deciding which devices receive them. WSUS also offers automation capabilities via PowerShell and integrates with Group Policy, making centralized management easier.

With the retirement announcement, Microsoft specified that WSUS will not be removed immediately, but it will no longer receive future developments or enhancements. The current functionality will be maintained, and Microsoft will continue to release updates through WSUS, but no new features will be introduced.

Implications for IT Administrators and Migration Strategies

The announcement has sparked doubts among IT administrators, especially regarding the continuity of support and the need to find alternative solutions. While WSUS will continue to be available in in-market versions of Windows Server, including the upcoming Windows Server 2025, it is crucial for administrators to start planning a transition to new solutions.

One important aspect to consider regarding the retirement of WSUS is its impact on Microsoft Configuration Manager. Although WSUS is being gradually retired, its deprecation will not directly impact the existing functionalities of Microsoft Configuration Manager, which will continue to use WSUS as a mechanism for managing and distributing updates. In other words, Configuration Manager will remain a viable option for organizations that rely on it to manage updates, with WSUS still serving as the distribution channel.

However, it is essential to note that even though WSUS will still be usable within Configuration Manager, Microsoft recommends planning a transition to cloud-based solutions such as Azure Update Manager to leverage new capabilities and improve the efficiency of update management in the long term. Migrating to the cloud is not only a natural evolution but also an opportunity to ensure more flexible and efficient server update management in line with modern business needs. This shift reflects the move towards a more cloud-oriented update management model, consistent with Microsoft’s strategy of simplifying Windows management through cloud-based solutions.

Azure Update Manager: A Worthy Replacement, But…

Azure Update Manager is a service that helps manage and govern updates for all machines, whether in Azure, on-premises, or on other cloud platforms connected via Azure Arc. From a single management console, it is possible to monitor update compliance for Windows and Linux servers, apply updates in real-time, or schedule them in defined maintenance windows.

With Azure Update Manager, you can:

Control and distribute security or critical updates to protect machines.
Enable periodic assessments to check for updates.
Use flexible patching options, such as scheduling updates in custom time windows.
Monitor update compliance for all machines, including hybrid or other cloud environments connected via Azure Arc.

Azure Update Manager offers several advantages, but there are some aspects to consider carefully.

Azure Update Manager respects the update source already configured on the machine, whether it is Windows Update for OS updates, Microsoft Update for product updates, or WSUS for a combination of both. In this context, WSUS can still be used in parallel with Azure Update Manager to provide additional capabilities, such as storing or caching updates locally.

The critical point concerns organizations with a large number of on-premises servers, where managing updates exclusively through Azure Update Manager requires further evaluation. The main concern is related to the bandwidth needed to download updates directly from the Internet to each server, which could saturate the network. Additionally, the micro-segmentation typical of server security policies makes it difficult to use peer-to-peer technologies such as Delivery Optimization.

Currently, if you want to explore a long-term strategy for enterprise companies and avoid this pain point, it’s necessary to evaluate solutions like Microsoft Connected Cache or explore options from other vendors.

Another relevant aspect is the cost associated with Azure Update Manager for servers managed through Azure Arc. While the service is free for systems residing in Azure, servers enabled for Azure Arc are subject to a cost of around €4.48 per server per month. However, there are cases where there are no charges for Azure Update Manager when the servers are:

Enabled for Extended Security Updates (ESU).
Managed through Defender for Servers Plan 2.
Hosted on Azure Stack HCI, when these machines are enabled for Azure benefits and managed via Azure Arc.

Conclusion

The retirement of WSUS will bring significant changes in the long term for IT administrators, especially in large environments with a high number of servers. While WSUS will continue to be available, companies should start considering long-term strategies to ensure efficient and secure update management. Azure Update Manager is a viable alternative but requires careful analysis of the economic and operational implications of this change.

For those interested in a more comprehensive approach in terms of security and centralized management, combining Azure Update Manager with Defender for Cloud (Plan 2) offers an interesting solution. This combination not only allows for update management but also provides advanced features for server system protection, ensuring a higher level of security.

In conclusion, although WSUS will remain available for a few more years, Microsoft’s direction is clear: the future of update management is moving towards the cloud, and organizations must prepare to face this transition in a strategic and proactive manner.

Windows Server 2025: the arrival of a new era of innovation and security for server systems

Microsoft is set to redefine the future of server operating systems with the announcement of its next major release: Windows Server 2025. This release will represent an evolutionary leap in the field of server operating systems, thanks to the introduction of innovative features that promise to revolutionize server management, their security, and performance. The new version is packed with improvements aimed at increasing operational efficiency and meeting the increasingly complex needs of modern IT environments. In this article, we will explore in detail the key features of Windows Server 2025, analyze its expected launch date, and evaluate its positioning in relation to Azure Stack HCI.

What’s New in Windows Server 2025

The latest version of Windows Server, named “Windows Server 2025,” marks a turning point in the evolution of server operating systems, introducing a wide range of innovations and improvements aimed at meeting the most pressing needs of users and introducing new features to optimize performance, security, and server management. Here is a detailed overview of the main new features integrated into this version:

Hot Patching: one of the most anticipated features, hot patching, will be available to all users of Windows Server 2025. This technology allows for updates to be applied in-memory, avoiding the restarts of the traditional patching process, which can disrupt operations. Originally welcomed with enthusiasm by the Xbox team for managing their Azure servers, hot patching has proven to drastically reduce update times. The expansion of hot patching will be linked to the Azure Arc management tool, and will also be accessible for the upcoming Standard and Datacenter editions of Windows Server, on a paid basis, although it is currently available at no additional cost for Azure Edition and Azure Stack HCI users.
Next-Generation Active Directory: Windows Server 2025 introduces significant improvements to Active Directory, increasing scalability through the adoption of larger database pages (32k) and improving support for systems with a high number of cores. Numerous security reinforcements have also been implemented, including support for LDAP over TLS 1.3 and a new replication priority feature, making Active Directory more robust and secure.
Improved Storage Performance and Flexibility: the new operating system brings significant optimizations for NVMe storage, promising an increase in IOPS of up to 90% compared to the previous version. Support for NVMe over Fabric, improvements for Storage Replica, and a new native deduplication mechanism for ReFS, optimized for active data, have also been introduced.
Hyper-V and Artificial Intelligence: with the introduction of GPU partitioning (GPU-P), Windows Server 2025 allows for the sharing of a GPU across multiple virtual machines, ensuring full support for real-time migration and clustering. Improved support for direct device assignment (DDA) and the introduction of GPU pools for high availability further elevate Hyper-V’s capabilities.
Modernized Server Experience: the upgrade to Windows Server 2025 is made simpler through the ability to perform it directly from Windows Update, ensuring a smooth and seamless transition, in line with the commitment to an improved user experience.
Enhanced Security and Networking: new security measures have been introduced, including mandatory SMB Signing by default and improvements in protection against brute force attacks on SMB. Advanced networking features have also been introduced, such as intent-based ATC and significant performance improvements to the SDN gateway.
Containers and AKS: significant improvements have been made in container management, including reducing the size of the base image and improvements in application compatibility, especially for Nano Server, simplifying and making container use more efficient.
Next-Generation File Services: access to SMB over QUIC, previously limited to the Azure edition of Windows Server 2022, is now extended to all editions of Windows Server 2025. This facilitates secure remote access to file servers without the need for VPN, using an always-encrypted protocol that leverages TLS 1.3 for connections, improving security and accessibility.
New Pay as You Go Option: Microsoft is planning to sell Windows Server 2025 not only through the traditional perpetual license but also via a pay-as-you-go subscription option. This option will be enabled through Azure Arc, Microsoft’s cloud service management tool, and will be billed through “Azure Commerce.” The subscription-based offering could be used by organizations that have seasonal or burst workloads, offering flexibility in payment based on actual usage.

These innovations reflect Microsoft’s commitment to meeting user needs and driving the technological evolution of servers, with Windows Server 2025 poised to be a milestone in the history of server operating systems.

Windows Server 2025 vs Azure Stack HCI

Azure Stack HCI and Windows Server 2025 represent two fundamental pillars in Microsoft’s virtualization solution offering, each designed to meet different needs within the IT landscape. While Azure Stack HCI positions itself as the cutting-edge solution for hybrid environments, offering advanced integrations with Azure services for optimized management and scalability, Windows Server 2025 continues to be a solid choice for organizations that require more traditional virtualized solutions, with a particular focus on flexibility and management in disconnected scenarios. The choice between these two solutions depends on the specific virtualization needs, the organization’s cloud strategy, and the need for access to advanced management and security features.

In summary:

Azure Stack HCI represents Microsoft’s flagship virtualization platform, offering significant hybrid value not present in Windows Server. Its features include Azure Virtual Desktop, free Extended Security Updates (ESU), the Azure edition (with hotpatching), the ability to provision virtual machines directly from the Marketplace, and management through Azure. Azure Stack HCI also stands out for the speed with which it introduces new improvements and features.
For customers needing disconnected solutions, Microsoft proposes Windows Server as a virtualization platform. Although it does not have all the advanced features of Azure Stack HCI, Windows Server remains a feature-rich and absolutely valid solution.

Release Date of Windows Server 2025

The new version of Windows Server, named “Windows Server 2025,” is expected in the fall of this year. Although Microsoft has not yet announced an official release date, it is possible to make some predictions based on previous release cycles. The company’s last product, Windows Server 2022, was made available to the public on September 1, 2021. If Microsoft were to follow a similar schedule for its next product, then we could expect Windows Server 2025 to be released in the fall of this year.

Conclusions

Windows Server 2025 represents a significant step forward in Microsoft’s vision for the future of server management, offering a wide range of improvements and new features that promise to optimize the IT infrastructure of companies. The introduction of technologies such as hot patching, next-generation Active Directory, and improvements in the field of storage and artificial intelligence not only enhance security and performance but also management and operational efficiency. With its release expected in the fall of this year, Windows Server 2025 is poised to be a milestone in the evolution of server operating systems, ready to meet the needs of modern IT environments and set new standards for the industry.

Hotpatching di Windows Server: una rivoluzione nella gestione delle macchine virtuali

Nell’era digitale, assicurare una continuità operativa è essenziale, non più solo un valore aggiunto. Per molte aziende, interruzioni frequenti, anche di breve durata, sono inaccettabili per i loro workload critici. Tuttavia, garantire tale continuità può risultare complesso, considerando che la gestione delle macchine virtuali (VM) con sistema operativo Windows Server è per certi aspetti complessa, soprattutto in relazione all’applicazione di patch di sicurezza e aggiornamenti. Con l’avvento della funzionalità di hotpatching da parte di Microsoft, si è aperto un nuovo capitolo nella gestione delle VM: un approccio più efficiente che minimizza le interruzioni, garantendo server sempre aggiornati e protetti. Questo articolo esamina le caratteristiche e i vantaggi di questa innovativa soluzione.

Cos’è l’Hotpatching?

L’hotpatching, introdotto da Microsoft, è una tecnica avanzata che consente di aggiornare sistemi operativi Windows Server senza la necessità di effettuare un riavvio. Immagina di poter “cambiare le gomme” della tua auto in movimento senza doverla fermare. Questa è la “magia” dell’hotpatching.

Dove è possibile utilizzare l’Hotpatching

La funzionalità Hotpatch è supportata sul sistema operativo “Windows Server 2022 Datacenter: Azure Edition”, che è possibile utilizzarlo per le VM che girano in ambiente Azure ed Azure Stack HCI.

Le immagini Azure disponibili per questa funzionalità sono:

Windows Server 2022 Datacenter: Azure Edition Hotpatch (Desktop Experience)
Windows Server 2022 Datacenter: Azure Edition Core

Da notare che Hotpatch è attivato di default sulle immagini Server Core e che Microsoft ha recentemente esteso il supporto all’hotpatching per includere Windows Server con Desktop Experience, ampliando ulteriormente il campo di applicazione di questa funzionalità.

Aggiornamenti supportati

Hotpatch copre gli aggiornamenti di sicurezza di Windows e mantiene un allineamento con il contenuto degli aggiornamenti di sicurezza emessi nel canale di aggiornamento Windows regolare (non hotpatch).

Ci sono alcune considerazioni importanti per l’esecuzione di una VM Windows Server Azure Edition con hotpatch abilitato:

i riavvii sono ancora necessari per installare gli aggiornamenti che non sono inclusi nel programma hotpatch;
i riavvii sono anche richiesti periodicamente dopo che è stata installata una nuova baseline;
i riavvii mantengono la VM sincronizzata con le patch non di sicurezza incluse nell’ultimo aggiornamento cumulativo.

Le patch attualmente non incluse nel programma hotpatch includono aggiornamenti non di sicurezza rilasciati per Windows, aggiornamenti .NET e aggiornamenti non-Windows (come driver, aggiornamenti firmware, ecc.). Questi tipi di patch potrebbero richiedere un riavvio durante i mesi di Hotpatch.

Benefici dell’Hotpatching

I benefici di questa tecnologia sono molteplici:

Migliore sicurezza: con l’hotpatching, le patch di sicurezza vengono applicate in modo rapido ed efficiente. Questo riduce la finestra di vulnerabilità tra il rilascio di una patch e la sua applicazione, offrendo una protezione rapida contro le minacce.
Minimizzazione del downtime: uno dei principali vantaggi dell’hotpatching è la capacità di applicare aggiornamenti senza la necessità di riavviare il server. Ciò significa meno interruzioni e una maggiore disponibilità per le applicazioni e per i servizi.
Gestione più flessibile: gli amministratori di sistema hanno la libertà di decidere quando applicare le patch, senza la preoccupazione di dover effettuare una attenta pianificazione per garantire che i processi in esecuzione non vengano interrotti durante l’applicazione degli aggiornamenti.

Come funziona l’Hotpatching

Durante un processo di hotpatching, la patch di sicurezza viene iniettata nel codice in esecuzione del sistema operativo in memoria, aggiornando il sistema mentre è ancora in funzione.

Hotpatch funziona stabilendo prima una baseline con l’attuale Aggiornamento Cumulativo per Windows Server. Periodicamente (con cadenza trimestrale), la baseline viene aggiornata con l’ultimo Aggiornamento Cumulativo, dopodiché vengono rilasciati hotpatch per i due mesi successivi. Ad esempio, se a gennaio viene rilasciato un Aggiornamento Cumulativo, febbraio e marzo vedrebbero il rilascio di hotpatch. Per il calendario di rilascio degli hotpatch, è possibile consulta le note di rilascio per Hotpatch in Azure Automanage per Windows Server 2022.

Gli hotpatch contengono aggiornamenti che non richiedono un riavvio. Poiché Hotpatch corregge il codice in memoria dei processi in esecuzione senza la necessità di riavviare il processo, le applicazioni ospitate sul sistema operativo non sono influenzate dal processo di patching. Questa azione è separata da eventuali implicazioni sulle prestazioni e sulle funzionalità della patch stessa.

L’immagine seguente riporta un esempio di un programma annuale di rilascio degli aggiornamenti (inclusi esempi di baseline non pianificate a causa di correzioni zero-day).

Figura 1 – Schema di una programmazione annuale di esempio per il rilascio degli aggiornamenti Hotpatch

Ci sono due tipi di baseline:

Baseline Pianificate: vengono rilasciate con una cadenza regolare, con rilasci di hotpatch nel mezzo. Le Baseline Pianificate includono tutti gli aggiornamenti in un Aggiornamento Cumulativo più recente e richiedono un riavvio.
Baseline Non Pianificate: vengono rilasciate quando viene rilasciato un aggiornamento importante (come una correzione zero-day) e quel particolare aggiornamento non può essere rilasciato come hotpatch. Quando vengono rilasciate le baseline non pianificate, un rilascio di hotpatch viene sostituito con una baseline non pianificata in quel mese. Anche le Baseline Non Pianificate includono tutti gli aggiornamenti in un Aggiornamento Cumulativo più recente e richiedono un riavvio.

La programmazione riportata nell’immagine di esempio illustra:

quattro rilasci di baseline pianificate in un anno solare (cinque in totale nel diagramma) e otto rilasci di hotpatch;
due baseline non pianificate che sostituirebbero i rilasci di hotpatch per quei mesi.

Processo di orchestrazione delle patch

Hotpatch è da considerate come un’estensione di Windows Update e gli strumenti di orchestrazione delle patch variano a seconda della piattaforma in uso.

Orchestrazione di Hotpatch in Azure

Le macchine virtuali create in Azure sono abilitate di default per il patching automatico se utilizzata un’immagine supportata di “Windows Server Datacenter: Azure Edition”:

le patch classificate come Critiche o di Sicurezza vengono automaticamente scaricate e applicate sulla VM;
le patch vengono applicate durante le ore di minore attività considerando il fuso orario della VM;
Azure gestisce l’orchestrazione delle patch e le patch vengono applicate seguendo i principi di disponibilità;
lo stato di salute della macchina virtuale, determinato attraverso i segnali di salute della piattaforma Azure, viene monitorato per rilevare fallimenti nel patching.

Orchestrazione di Hotpatch in Azure Stack HCI

Gli aggiornamenti Hotpatch per le macchine virtuali attive in ambiente Azure Stack HCI possono essere orchestrati utilizzando:

Group Policy per configurare le impostazioni del client Windows Update;
le impostazioni del client Windows Update oppure SCONFIG per Server Core;
una soluzione di gestione delle patch di terze parti.

Considerazioni e limitazioni

Tuttavia, come ogni tecnologia, anche l’hotpatching ha le sue sfumature. Non tutte le patch sono adatte per l’hotpatching; alcune potrebbero ancora richiedere un riavvio tradizionale. Inoltre, prima di applicare qualsiasi patch, rimane fondamentale testarla in un ambiente controllato per evitare potenziali problemi.

L’installazione di aggiornamenti Hotpatch non supporta il rollback automatico. Infatti, se una VM riscontra un problema durante o dopo un aggiornamento, risulta necessario disinstallare l’aggiornamento e installare l’ultimo aggiornamento baseline noto come valido. In seguito al rollback sarà necessario riavviare la VM.

Conclusione

L’introduzione dell’hotpatching da parte di Microsoft rappresenta un passo avanti significativo nella gestione delle VM con sistema operativo Windows Server. Con la capacità di applicare patch di sicurezza e aggiornamenti senza interruzioni, gli amministratori possono garantire che i loro server siano protetti e aggiornati in un modo più rapido ed efficace. In un mondo in cui la sicurezza è di primaria importanza e in cui ogni secondo conta, l’hotpatching si posiziona come una soluzione di valore per ogni azienda che utilizza Windows Server in ambiente Azure oppure in ambiente Azure Stack HCI.

Azure al tuo fianco: nuove soluzioni per la fine del supporto di Windows Server 2012/R2

Nell’era dell’Intelligenza Artificiale e dei servizi nativi per il cloud, le organizzazioni continuano a fare affidamento su Windows Server come piattaforma sicura e affidabile per i loro workload mission-critical. Tuttavia, è importante ricordare che il supporto per Windows Server 2012/R2 terminerà il 10 ottobre 2023. Dopo tale data, i sistemi Windows Server 2012/R2 diventeranno vulnerabili se non si intraprenderanno dei provvedimenti, poiché non riceveranno più regolarmente gli aggiornamenti di sicurezza. Recentemente, Microsoft ha annunciato che Azure offre nuove soluzioni per gestire al meglio la fine del supporto di Windows Server 2012/R2. Queste soluzioni saranno esaminate nel dettaglio in questo articolo, dopo un breve riepilogo per definire il contesto.

L’impatto del termine del supporto per Windows Server 2012 R2: cosa significa per le aziende?

Microsoft ha annunciato la fine del supporto per Windows Server 2012 e 2012 R2, fissata per il 10 ottobre 2023. Questo evento rappresenta un punto cruciale per molte organizzazioni che si affidano a questi server per accedere alle applicazioni e ai dati. Ma cosa significa esattamente la fine del supporto (EOL) e quali sono le implicazioni per le aziende?

Comprendere la fine del supporto

Microsoft ha una politica di ciclo di vita che fornisce supporto per i suoi prodotti, tra cui Windows Server 2012 e 2012 R2. La fine del supporto si riferisce al momento in cui un prodotto non è più supportato da Microsoft, il che significa che non verranno più forniti aggiornamenti di sicurezza, patch o supporto tecnico.

Perché le aziende dovrebbero preoccuparsi

Senza aggiornamenti e patch regolari, le aziende che utilizzano Windows Server 2012 e 2012 R2 sono esposte a vulnerabilità di sicurezza, come attacchi ransomware e violazioni dei dati. Inoltre, l’utilizzo di un prodotto non supportato come Windows Server 2012 o 2012 R2 può portare a problemi di non conformità. Infine, il software obsoleto può causare problemi di compatibilità con applicazioni e hardware più recenti, ostacolando l’efficienza e la produttività.

Un’opportunità per rivedere la strategia IT

Le aziende dovrebbero utilizzare l’evento di EOL come un’opportunità per rivedere la loro strategia IT e determinare gli obiettivi aziendali desiderati dalla loro tecnologia. In questo modo, possono allineare la tecnologia con i loro obiettivi a lungo termine, sfruttando le ultime soluzioni cloud e migliorando l’efficienza operativa.

Le strategie che è possibile adottare per affrontare questa situazione, evitando così di esporre la propria infrastruttura IT a problematiche di security, sono già state affrontate nell’articolo: Come la fine del supporto di Windows Server 2012 può essere una grande opportunità per i CTO.

A questo proposito, Microsoft ha introdotto due nuove opzioni, fornite tramite Azure, per agevolare la gestione di questa situazione:

aggiornamento dei server con Azure Migrate;
distribuzione sui server abilitati ad Azure Arc degli aggiornamenti derivanti dall’ESU (Extended Security Updates).

Nei paragrafi seguenti vengono descritte le caratteristiche di queste nuove opzioni.

Aggiornamento dei server Windows in fase di fine supporto (EOS) con Azure Migrate

Azure Migrate è un servizio offerto da Microsoft Azure che consente di valutare e migrare le risorse locali, come macchine virtuali, applicazioni e database, verso l’infrastruttura cloud di Azure. Recentemente, Azure Migrate ha introdotto il supporto per gli aggiornamenti in-place di Windows Server 2012 e versioni successive, durante il passaggio ad Azure. Questo permette alle organizzazioni di spostare le loro applicazioni e i loro database legacy su un sistema operativo completamente supportato, compatibile e conforme come Windows Server 2016, 2019 oppure 2022.

Vantaggi chiave della funzionalità di aggiornamento del sistema operativo di Azure Migrate

Mitigazione del rischio: Azure Migrate crea una replica del server originale in Azure, permettendo l’aggiornamento del sistema operativo sulla replica mentre il server di origine rimane intatto. In caso di problemi, i clienti possono facilmente tornare al sistema operativo originale.

Test di compatibilità: Azure Migrate offre la possibilità di eseguire una migrazione di prova in un ambiente isolato in Azure. Questo è particolarmente utile per gli aggiornamenti del sistema operativo, permettendo ai clienti di valutare la compatibilità del loro sistema operativo e delle applicazioni aggiornate senza impattare la produzione. In questo modo è possibile identificare e risolvere eventuali problemi in anticipo.

Riduzione dello sforzo e del downtime: integrando gli aggiornamenti del sistema operativo con la migrazione al cloud, i clienti possono risparmiare significativamente tempo e sforzo. Con un solo dato aggiuntivo, la versione del sistema operativo di destinazione, Azure Migrate si occupa del resto, semplificando il processo. Questa integrazione riduce ulteriormente il downtime del server e delle applicazioni su di esso ospitate, aumentando l’efficienza.

Nessuna licenza Windows separata: con l’aggiornamento del sistema operativo di Azure Migrate, non è necessario acquistare separatamente una licenza del sistema operativo per effettuare l’aggiornamento. Che il cliente utilizzi Azure Hybrid Benefits (AHB) o PAYG, risulta coperto quando migrerà a un VM Azure utilizzando Azure Migrate.

Aggiornamento dei server su larga scala: Azure Migrate supporta aggiornamenti del sistema operativo dei server su larga scala, permettendo ai clienti di aggiornare fino a 500 server in parallelo durante la migrazione ad Azure. Utilizzando il portale Azure, sarà possibile selezionare fino a 10 VMs alla volta per configurare le repliche. Per replicare più VMs è possibile utilizzare il portale e aggiungere le VMs da replicare in più lotti di 10 VMs, oppure utilizzare l’interfaccia PowerShell di Azure Migrate per configurare la replica.

Versioni del sistema operativo supportate

Azure Migrate è in grado di gestire:

Windows Server 2012: supporta l’aggiornamento a Windows Server 2016;
Windows Server 2012 R2: supporta l’aggiornamento a Windows Server 2016, Windows Server 2019;
Windows Server 2016: supporta l’aggiornamento a Windows Server 2019, Windows Server 2022;
Windows Server 2019: supporta l’aggiornamento a Windows Server 2022.

Distribuzione degli aggiornamenti derivanti dall’ESU sui server abilitati ad Azure Arc

Azure Arc è un insieme di soluzioni Microsoft che consentono alle aziende di gestire, governare e proteggere le risorse in vari ambienti, tra cui on-premise, edge e multi-cloud, estendendo le capacità di gestione di Azure a qualsiasi infrastruttura.

Per le organizzazioni che non sono in grado di modernizzare oppure migrare prima della data di fine del supporto di Windows Server 2012/R2, Microsoft ha annunciato gli Extended Security Updates (ESU) abilitati da Azure Arc. Con Azure Arc, le organizzazioni saranno in grado di acquistare e distribuire senza problemi gli Extended Security Updates (ESU) in ambienti on-premise o multicloud, direttamente dal portale Azure.

Per ottenere gli Extended Security Updates (ESU) per Windows Server 2012/R2 e SQL Server 2012 abilitati da Azure Arc, è necessario seguire i passaggi seguenti:

Preparazione dell’ambiente Azure Arc: innanzitutto, è necessario un ambiente Azure e un’infrastruttura Azure Arc funzionante. Azure Arc può essere installato su qualsiasi server che esegue Windows Server 2012/R2 oppure SQL Server 2012, a condizione che vengano rispettati i requisiti di connettività.
Registrazione del server in Azure Arc: una volta predisposto l’ambiente Azure Arc, è necessario registrare i server Windows o i sistemi SQL Server in Azure Arc. Questo processo consente ai sistemi di diventare risorse gestite in Azure, rendendoli idonei per gli ESU.
Acquisto degli ESU: una volta che i server sono registrati in Azure Arc, è possibile acquistare gli ESU, per ogni server che desideri proteggere, attraverso Azure.
Attivazione degli ESU: dopo l’acquisto degli ESU, è necessario attivarli sui server. Questo processo comporta l’installazione di una chiave di licenza e il download degli aggiornamenti di sicurezza da Windows Update o dall’infrastruttura locale di distribuzione degli aggiornamenti.
Installazione degli aggiornamenti: infine, una volta attivati gli ESU, è possibile effettuare l’installazione degli aggiornamenti di sicurezza sui server. Questo processo può essere gestito manualmente o automatizzandolo attraverso strumenti di gestione degli aggiornamenti.

NOTA: gli ESU forniscono solo aggiornamenti di sicurezza critici e importanti, non includono nuove funzionalità o miglioramenti delle prestazioni. Inoltre, gli ESU sono disponibili solo per un periodo limitato dopo la fine del supporto di Microsoft. Pertanto, si consiglia di prendere in considerazione la migrazione a versioni più recenti dei server per avere accesso a tutte le funzionalità, oltre agli aggiornamenti di sicurezza.

Conclusioni

Quest’anno, Microsoft celebra il 30° anniversario di Windows Server, un traguardo raggiunto grazie all’incessante innovazione e al sostegno dei clienti. Tuttavia, i clienti si devono impegnare a mantenere aggiornati i loro sistemi Windows Server prossimi alla fine del supporto. In particolare, la fine del supporto per Windows Server 2012 e 2012 R2 rappresenta un rischio significativo per le aziende, ma presenta anche un’opportunità per rivedere e migliorare la loro strategia IT. Identificando gli obiettivi aziendali desiderati, impegnandosi nella pianificazione strategica e, se necessario, utilizzando queste nuove soluzioni offerte da Azure, le aziende possono garantire una transizione fluida e di successo, ottimizzando la loro infrastruttura IT per raggiungere i loro obiettivi a lungo termine.

Come la fine del supporto di Windows Server 2012 può essere una grande opportunità per i CTO

La fine del supporto dei sistemi operativi Windows Server 2012 e 2012 R2 sta avvicinandosi rapidamente e, per i Chief Technology Officer (CTO) delle aziende, questo aspetto deve essere attentamente valutato in quanto ha degli impatti significativi sull’infrastruttura IT. Allo stesso tempo, la fine del supporto può rappresentare un’occasione importante per modernizzare l’ambiente IT al fine di garantire una maggiore sicurezza, nuove funzionalità e un miglioramento della continuità del business. In questo articolo vengono riportate le strategie che è possibile adottare per affrontare questa situazione, evitando così di esporre la propria infrastruttura IT a problematiche di security causate da questa situazione.

Quando termina il supporto di Windows Server 2012/2012R2 e cosa comporta?

Il 10 ottobre 2023 segna la fine del supporto esteso di Windows Server 2012 e Windows Server 2012 R2. Senza il supporto di Microsoft, Windows Server 2012 e Windows Server 2012 R2 non riceveranno più patch di sicurezza, a meno che non vengano svolte determinate azioni riportate in seguito. Ciò significa che eventuali vulnerabilità scoperte nel sistema operativo non saranno più corrette e questo potrebbe rendere i sistemi vulnerabili ad attacchi informatici. Inoltre, questa condizione comporterebbe lo stato di non conformità rispetto a specifici regolamenti, come ad esempio il General Data Protection Regulation (GDPR).

Inoltre, gli utenti non riceveranno più correzioni di bug e altri aggiornamenti necessari per mantenere il sistema operativo in linea con le ultime tecnologie, il che potrebbe comportare problemi di compatibilità con i software più recenti e introdurre potenziali problemi di prestazioni.

Oltre a tutto ciò, Microsoft non garantirà più un supporto tecnico e un aggiornamento dei contenuti tecnici disponibili online per questo sistema operativo.

Tutti questi aspetti comportano un impatto significativo sulle realtà IT che utilizzano ancora questi sistemi operativi.

Possibili strategie e opportunità legate alla fine del supporto

Questa situazione è certamente poco piacevole per chi si ritrova ad affrontarla ora, visti i tempi ristretti, ma può anche essere vista come una importante opportunità di rinnovo e innovazione della propria infrastruttura. Nei paragrafi seguenti vengono riportate le possibili strategie che si possono attuare.

Aggiornamento dei sistemi on-premises

Questa strategia prevede il passaggio a una nuova versione di Windows Server in ambiente on-premises. Il consiglio in questo caso è di approcciare come piattaforma almeno Windows Server 2019, ma è preferibile adottare la versione più recente, Windows Server 2022, che può fornire le ultime innovazioni in materia di sicurezza, prestazioni e modernizzazione delle applicazioni.

Inoltre, laddove tecnicamente possibile è preferibile non procedere con aggiornamenti in place del sistema operativo, ma di gestire la migrazione in side-by-side.

Questo metodo solitamente richiede un coinvolgimento del fornitore applicativo, per garantire la compatibilità software con la nuova versione del sistema operativo. Trattandosi di software non recenti, spesso viene richiesta l’adozione di versioni aggiornate degli stessi, che possono prevedere un adeguamento dell’architettura e una fase approfondita di test della nuova release. Adottando questo processo di upgrade i tempi e l’effort sono considerevoli, ma il risultato che si ottiene è fondamentale per rispettare il rinnovo tecnologico.

Mantenimento dei sistemi Windows Server 2012/2012 R2, ma con aggiornamenti di security per altri 3 anni

Per continuare a ricevere gli update di security per i sistemi Windows Server 2012\2012 R2 ospitati in ambiente on-premises, una possibilità è quella di aderire al programma Extended Security Update (ESU). Tale programma a pagamento garantisce il provisioning degli Update di Security classificati come “critical” e “important” per ulteriori tre anni, nel caso specifico fino al 13 ottobre 2026.

Il programma Extended Security Update (ESU) è un’opzione per i clienti che hanno bisogno di eseguire alcuni prodotti Microsoft legacy oltre la fine del supporto e che non sono nelle condizioni di intraprendere altre strategie. Gli aggiornamenti inclusi nel programma ESU non includono nuove funzionalità e aggiornamenti non legati agli aspetti di sicurezza.

Adozione di Azure

Migrazione dei sistemi in Azure

Migrando i sistemi Windows Server 2012 e Windows Server 2012 R2 presenti on-premises in ambiente Azure si continueranno a ricevere per altri tre anni i security update, classificati come critici e importanti, senza dover aderire al programma ESU. Questo scenario non solo è utile per garantire il rispetto della compliance dei propri sistemi, ma apre la strada verso architetture ibride dove sarà possibile ottenere i vantaggi dati dal cloud. A questo proposito Microsoft offre un’ottima soluzione in grado di fornire un ampio set di strumenti necessari per affrontare al meglio i più comuni scenari di migrazione: Azure Migrate, che struttura il processo di migrazioni in fase differenti (discovery, assessment, e migrazione).

Anche Azure Arc può risultare molto utile per inventariare il patrimonio digitale in ambienti eterogenei e distribuiti.

L’adozione di questa strategia può risultare più veloce rispetto all’aggiornamento dei sistemi e consente di avere più tempo a disposizione per affrontare il rinnovo software. A questo proposito il cloud consente di avere un’ottima flessibilità e agilità nel testare gli applicativi in ambienti paralleli.

Prima di iniziare il percorso di migrazione verso Azure è fondamentale anche strutturare il networking dell’ambiente ibrido in modo opportuno e valutare le iterazioni con gli altri componenti dell’infrastruttura, per constatare se l’applicativo può funzionare bene anche in ambiente cloud.

La migrazione in Azure può avvenire verso macchine virtuali IaaS oppure, in presenza di un numero elevato di sistemi da migrare in ambiente VMware, Azure VMware Solution può essere una soluzione da tenere in considerazione per affrontare una migrazione massiva in tempi rapidi e riducendo al minimo l’interruzione dei servizi erogati.

Estensione di Azure nel proprio datacenter con Azure Stack HCI

Azure Stack HCI è la soluzione Microsoft che permette di realizzare una infrastruttura hyper-converged (HCI) per l’esecuzione di workload in ambiente on-premises e che prevede una strategica connessione a vari servizi di Azure. Azure Stack HCI è stato appositamente progettato da Microsoft per aiutare i clienti a modernizzare il proprio datacenter ibrido, offrendo un’esperienza Azure completa e familiare in ambiente on-premises. Per un approfondimento sulla soluzione Microsoft Azure Stack HCI vi invito a leggere questo articolo oppure a visualizzare questo video.

Azure Stack HCI consente di ottenere gratuitamente, proprio come in Azure, importanti patch di sicurezza per i prodotti legacy di Microsoft che hanno superato il termine del supporto, tramite il programma Extended Security Update (ESU). Per maggiori informazioni a riguardo è possibile consultare questo documento Microsoft. Questa strategia consente di avere più tempo per intraprendere un percorso di modernizzazione applicativa, senza trascurare gli aspetti legati alla sicurezza.

Modernizzazione applicativa

In determinate circostanze si potrebbe intraprendere un percorso di modernizzazione applicativa, magari incentrato sul cloud pubblico, con l’obiettivo di aumentare l’innovazione, l’agilità e l’efficienza operativa. Microsoft Azure offre la flessibilità di scegliere tra un’ampia gamma di opzioni per ospitare le proprie applicazioni, coprendo lo spettro di Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), Container-as-a-Service (CaaS) e serverless. In un percorso per abbandonare sistemi operativi legacy i clienti possono utilizzare i container anche per le applicazioni non appositamente progettate per utilizzare architetture basate su microservizi. In questi casi è possibile attuare una strategia di migrazione delle applicazioni esistenti che prevede solo modifiche minimali del codice dell’applicazione oppure modifiche alle configurazioni. Si tratta di modifiche strettamente necessarie per ottimizzare l’applicazione al fine di essere ospitata su soluzioni PaaS e CaaS. Per ottenere alcuni spunti a riguardo vi invito a leggere questo articolo.

Passaggi per una transizione di successo

Per le imprese che intendono intraprendere una delle strategie riportate, ci sono alcuni passaggi importanti che devono essere presi per garantire una transizione di successo.

Indipendentemente dalla strategia che si decide adottare il consiglio è di fare un assessment dettagliato, in modo da poter categorizzare ciascun workload per tipologia, criticità, complessità e rischio. In questo modo è possibile dare delle priorità e procedere con un piano di migrazione strutturato.

Inoltre, è necessario valutare attentamente la strategia di transizione più idonea considerando come minimizzare eventuali interruzioni delle attività aziendali. Ciò può includere la pianificazione dei test e la creazione di set di backup adeguati prima della migrazione.

Infine, una volta completata la migrazione, è importante attivare un moderno sistema di monitor per garantire che il workload applicativo sia stabile e che funzioni come previsto.

Conclusioni

La fine del supporto di Windows Server 2012 e Windows Server 2012 R2 rappresenta una sfida per molte aziende che utilizzano ancora questi sistemi operativi. Tuttavia, può anche essere vista come un’opportunità per le imprese di avviare un percorso di modernizzazione dell’infrastruttura oppure applicativa. In questo modo si potrà disporre di risorse più moderne, sfruttando anche le opportunità che offrono in termini di sicurezza, scalabilità e prestazioni.

Soluzioni di Disaster Recovery: Storage Replica vs DFS Replication

Microsoft Storage Replica è una tecnologia introdotta a partire da Windows Server 2016 che tra i principali scenari di utilizzo prevede la replica di volumi, in modo sincrono oppure asincrono, tra server o cluster, a fini di disaster recovery. Al giorno d’oggi diversi clienti Microsoft continuano ad utilizzare DFS Replication (DFS-r) come soluzione di Disaster Recovery per i dati non strutturati come home folders e share dipartimentali. Il quesito che molti si pongono è se la recente tecnologia Storage Replica prende davvero il posto dell’ormai consolidato meccanismo DFS-r. In questo articolo saranno approfondite le caratteristiche delle due soluzioni in modo da chiarire quando conviene utilizzare Storage Replica e quando DFS Replication (DFS-r).

DFS Replication (DFS-r)

DFS Replication è una soluzione attivabile tramite un ruolo presente in Windows Server che consente di replicare le cartelle su differenti server e siti geografici. La soluzione è basata su un efficiente motore di replica, che contempla la presenza di più master, il quale è possibile utilizzarlo per mantenere le cartelle sincronizzate tra differenti server, anche attraverso connessioni di rete con larghezza di banda limitata. DFS-r utilizza un algoritmo di compressione noto come Remote Differential Compression (RDC), in grado di rilevare le modifiche di un file e di replicare solo i blocchi modificati anziché l’intero file. Ormai da tempo DFS-r ha sostituito il servizio File Replication Service (FRS) ed è anche utilizzato per la replica della cartella SYSVOL di Active Directory Domain Services (AD DS) nei domini dove il functional level è almeno Windows Server 2008.

L’attivazione di DFS-r prevede la creazione di gruppi di replica che contengono i file e le cartelle da replicare:

Figura 1 – Processo di replica di DFS-r

Per maggiori informazioni sul servizio DFS Replication (DFS-r) è possibile consultare la relativa documentazione Microsoft.

Storage Replica

Storage Replica è una tecnologia introdotta a partire da Windows Server 2016 e consente la replica di volumi tra server o cluster a fini di Disaster Recovery.

Figura 2 – Scenari di replica storage Server-to-server e Cluster-to-cluster

Questa tecnologia consente inoltre di realizzare dei stretch failover cluster con nodi dislocati su due site differenti, mantenendo lo storage sincronizzato.

Figura 3 – Scenari di replica storage in stretch cluster

In Windows Server 2016 la possibilità di utilizzare Storage Replica c’è solamente se si utilizza la versione Datacenter Edition del sistema operativo, mentre in Windows Server 2019 c’è la possibilità di attivare Storage Replica anche adottando la Standard Edition, ma 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.

Per maggiori informazioni su Storage Replica è possibile consultare la relativa documentazione Microsoft.

Confronto tra le soluzioni

La soluzione DFS-r risulta particolarmente efficace in ambienti con una banda di rete limitata e dove è necessario replicare su differenti nodi dei contenuti per i quali sono previste un numero limitato di modifiche. Tuttavia, DFS-r presenta notevoli limiti come soluzione di replica dei dati, tra i quali:

Non è in grado di replicare file in uso oppure aperti.
Non prevede un meccanismo di replica sincrona.
La latenza per la replica asincrona può essere di durata considerevole (minuti, ore o persino giorni).
Si basa su un database che può richiedere controlli di consistenza onerosi in seguito ad eventuali interruzioni del sistema.
L’onere di gestione dell’ambiente è elevato.

La soluzione Storage Replica non presenta le limitazioni sopra elencate, ma è bene tenere in considerazione i seguenti aspetti che la differenziano dalla soluzione DFS-r e che in alcuni scenari potrebbero essere considerati come elementi di criticità:

La replica avviene a livello di volume ed è consentita solo la replica uno a uno tra i volumi. Risulta comunque possibile replicare diversi volumi tra più server.
Consente di replicare in modo sincrono oppure asincrono, ma non è progettata per reti con larghezza di banda ridotta e latenza elevata.
Non è consentito l’accesso degli utenti ai dati protetti sul server di destinazione mentre la replica è in corso.
- Per validare l’efficacia del processo di replica è comunque possibile effettuare un Test Failover, che consente di 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.

Come sostituire DFS Replication (DFS-r) con Storage Replica?

Se le caratteristiche di Storage Replica non vengono considerati bloccanti, questa più recente tecnologia è possibile adottarla per sostituire la soluzione DFS Replication (DFS-r). Il processo ad alto livello prevede i seguenti passaggi:

Installare i nuovi sistemi almeno Windows Server 2016, facendo attenzione a valutare i limiti imposti dalla Standard Edition, e configurare lo storage. Per approfondire i miglioramenti introdotti in ambito Storage Replica con Windows Server 2019 è possibile consultare questo articolo.
Migrare i dati che si desidera replicare su uno o più volumi di dati (ad esempio tramite Robocopy).
Abilitare la replica di Storage Replica e completare la sincronizzazione iniziale.
Si consiglia di abilitare le snapshot tramite Volume Shadow Copies, in particolare nel caso di replica asincrona. Le snapshots vengono anch’esse replicate insieme ai file. In caso di emergenza, sarà così possibile ripristinare i file dagli snapshot sul server di destinazione che potrebbero essere stati replicati solo parzialmente in modo asincrono.
Condividere i dati presenti sul server di origine e renderli accessibili tramite un DFS namespace. Questo aspetto è importante per garantire che gli utenti possano comunque accedere ai dati nel momento in cui cambia il nome del server durante l’attivazione del piano di Disaster Recovery. Sul server target della replica (sito di DR) è possibile creare le share (non accessibili durante le normali operazioni). Il server sul sito di DR potrà essere aggiunto al DFS Namespaces mantenendo le folder target disabilitate.

Nel caso risulti necessario attivare lo scenario di Disaster Recovery, utilizzando la soluzione Storage Replica, è opportuno procedere nel modo seguente:

Rendere principale il server dislocato nel site di DR, in modo che sia in grado di mostrare i volumi replicati agli utenti.
In caso di replica sincrona, non sarà necessario alcun ripristino dei dati, a meno che durante la perdita del server di origine l’utente non stesse utilizzando un’applicazione che scriveva dati senza protezione delle transazioni.
In caso di replica asincrona, può essere necessario effettuare il mount di una snapshot per garantire la consistenza dei dati a livello applicativo.
Attivare le folder target nel DFS Namespaces per consentire agli utenti di accedere ai propri dati.

Conclusioni

Microsoft sta continuando ad effettuare importanti investimenti in ambito storage e Storage Replica è il risultato tangibile che permette ai clienti di adottare un efficace e performante soluzione di replica dello storage. In ambito Disaster Recovery sono diversi gli scenari dove Storage Replica può andare a sostituire il servizio DFS Replication (DFS-r), ma è opportuno valutare attentamente le caratteristiche di entrambe le soluzioni per scegliere quella più adatta al proprio scenario d’uso.

Come affrontare la fine del ciclo di vita di Windows Server 2008\2008 R2

La fine del supporto Microsoft per i sistemi operativi Windows Server 2008 e Windows Server 2008 R2 è imminente e prevista per il 14 gennaio 2020. A partire da questa data Microsoft non rilascerà più update di security in modo gratuito per queste piattaforme in ambiente on-premises. Purtroppo, sono ancora molti i sistemi in ambiente di produzione che adottano queste versioni di sistema operativo. In questo articolo vengono affrontati gli approcci che è possibile adottare per affrontare questa situazione, evitando di esporre la propria infrastruttura a problematiche di security causate dall’indisponibilità degli aggiornamenti necessari.

La fine del periodo extended support per queste piattaforme implica che Microsoft, a meno che non vengano svolte determinate azioni, non rilascerà più i relativi security update. In queste condizioni l’esposizione ad attacchi di security è notevole e comporterebbe lo stato di non compliance rispetto a specifici regolamenti, come ad esempio il General Data Protection Regulation (GDPR). Questa condizione, sicuramente poco piacevole per chi si ritrova ad affrontarla ora, visti i tempi ristretti, può anche essere vista come una importante opportunità di rinnovo e innovazione della propria infrastruttura.

Per continuare a ricevere gli update di security per i sistemi Windows Server 20082008 R2 ospitati in ambiente on-premises, l’unica possibilità è quella di aderire al programma Extended Security Update (ESU). Tale programma a pagamento è disponibile solo per i clienti in Software Assurance e garantisce il provisioning di Update di Security classificati come “critical” e “important” per ulteriori tre anni, a partire dal 14 gennaio 2020.

Qualora il programma ESU non lo si ritenga adeguato alle proprie esigenze si possono valutare due percorsi di upgrade totalmente differenti.

Upgrade on-premises

Questo percorso prevede il passaggio a una nuova versione di Windows Server in ambiente on-premises. Il consiglio in questo caso è di approcciare come piattaforma almeno Windows Server 2016 e di non procedere, qualora possibile, con aggiornamenti in place del sistema operativo, ma di gestire la migrazione in side-by-side. Questo metodo solitamente richiede un coinvolgimento del fornitore applicativo, per garantire la compatibilità software con la nuova versione del sistema operativo. Trattandosi di software non recenti, spesso viene richiesta l’adozione di versioni aggiornate degli stessi, che possono prevedere un adeguamento dell’architettura e una fase approfondita di test della nuova release. Adottando questo processo di upgrade i tempi e l’effort sono considerevoli, ma il risultato che si ottiene è fondamentale per rispettare il rinnovo tecnologico.

Migrazione verso Azure

Migrando i sistemi Windows Server 2008 e Windows Server 2008 R2 presenti on-premises in ambiente Azure si continueranno a ricevere per altri tre anni i security update, classificati come critici e importanti, senza dover aderire al programma ESU. Questo scenario non solo è utile per garantire il rispetto della compliance dei propri sistemi, ma apre la strada verso architetture ibride dove sarà possibile ottenere i vantaggi dati dal cloud. A questo proposito Microsoft offre un’ottima soluzione in grado di fornire un ampio set di strumenti necessari per affrontare al meglio i più comuni scenari di migrazione: Azure Migrate, che struttura il processo di migrazioni in fase differenti (discovery, assessment, e migrazione). Questo approccio può risultare più immediato rispetto all’upgrade dei sistemi e consente di avere più tempo a disposizione per affrontare il rinnovo software. A questo proposito il cloud consente di avere un’ottima flessibilità e agilità nel testare gli applicativi in ambienti paralleli. Prima di iniziare il percorso di migrazione verso Azure è fondamentale strutturare il networking dell’ambiente ibrido in modo opportuno e valutare le iterazioni con gli altri componenti dell’infrastruttura, per constatare se l’applicativo può funzionare bene anche in ambiente cloud.

Indipendentemente dal percorso di upgrade che si decide adottare il consiglio è di fare un assessment dettagliato, in modo da poter categorizzare ciasun workload per tipologia, criticità, complessità e rischio. In questo modo è possibile dare delle priorità e procedere con un piano strutturato di migrazione.

Conclusioni

Per tutti coloro che all’interno del proprio datacenter dispongono di sistemi Windows Server 2008 oppure Windows Server 2008 R2 è opportuno gestire la condizione che Microsoft a breve non rilascerà più update di security in modo gratuito, esponendo così i sistemi a potenziali problemi di sicurezza. Allo stesso tempo sono diverse le possibilità offerte da Microsoft per affrontare nel migliore dei modi questa situazione. Il percorso di migrazione verso Azure è sicuramente un’opzione molto interessante che consente di iniziare il percorso per espandere il proprio datacenter nel cloud pubblico di Microsoft.