Category Archives: Windows Server

Hotpatching in Windows Server: a revolution in virtual machine management

In the digital age, ensuring business continuity is essential, no longer just an added value. For many companies, frequent interruptions, even of short duration, are unacceptable for their critical workloads. However, ensuring that continuity can be complex, whereas the management of virtual machines (VM) with Windows Server operating system is in some respects complex, especially in relation to applying security patches and updates. With the advent of the hotpatching feature from Microsoft, a new chapter in VM management has opened: a more efficient approach that minimizes disruption, guaranteeing servers that are always up-to-date and protected. This article looks at the features and benefits of this innovative solution.

What is Hotpatching?

Hotpatching, introduced by Microsoft, is an advanced technique that allows you to update Windows Server operating systems without the need to restart. Imagine you can “change tires” of your moving car without having to stop it. This is the "magic" of hotpatching.

Where you can use Hotpatching

Hotpatch functionality is supported on “Windows Server 2022 Datacenter: Azure Edition”, that you can use it for VMs running in Azure and Azure Stack HCI environment.

The Azure images available for this feature are:

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

Note that Hotpatch is enabled by default on Server Core images and that Microsoft recently extended hotpatching support to include Windows Server with Desktop Experience, further expanding the scope of this feature.

Updates supported

Hotpatch covers Windows security updates and maintains an alignment with the content of security updates issued in the regular Windows update channel (non hotpatch).

There are some important considerations for running a Windows Server Azure Edition VM with hotpatch enabled:

  • reboots are still required to install updates that are not included in the hotpatch program;
  • reboots are also required periodically after a new baseline has been installed;
  • reboots keep the VM in sync with non-security patches included in the latest cumulative update.

Patches not currently included in the hotpatch program include non-security updates released for Windows, .NET updates and non-Windows updates (as driver, firmware updates, etc.). These types of patches may require a reboot during the Hotpatch months.

Benefits of Hotpatching

The benefits of this technology are many:

  • Better security: with hotpatching, security patches are applied quickly and efficiently. This reduces the window of vulnerability between the release of a patch and its application, offering fast protection against threats.
  • Minimization of downtime: one of the main benefits of hotpatching is the ability to apply updates without the need to restart the server. This means fewer outages and higher availability for applications and services.
  • More flexible management: system administrators have the freedom to decide when to apply patches, without the worry of having to do careful planning to ensure that running processes are not interrupted while applying updates.

How hotpatching works

During a hotpatching process, the security patch is injected into the operating system's running code in memory, updating the system while it is still running.

Hotpatch works by first establishing a baseline with the current Cumulative Update for Windows Server. Periodically (on a quarterly basis), the baseline is updated with the latest Cumulative Update, after which they are released hotpatch for the next two months. For example,, if a Cumulative Update is released in January, February and March would see the release of hotpatch. For the hotpatch release schedule, you can consult the Release Notes for Hotpatch in Azure Automanage for Windows Server 2022.

The hotpatch contain updates that do not require a restart. Because Hotpatch fixes the in-memory code of running processes without the need to restart the process, applications hosted on the operating system are not affected by the patching process. This action is separate from any performance and functionality implications of the patch itself.

The following image shows an example of an annual update release schedule (including examples of unplanned baselines due to zero-day corrections).

Figure 1 – Outline of a sample yearly schedule for releasing Hotpatch updates

There are two types of baselines:

  • Planned Baselines: are released on a regular basis, with hotpatch releases in between. Planned Baselines include all updates in a newer Cumulative Update and require a restart.
  • Unplanned Baselines: they are released when a major update is released (like a zero-day correction) and that particular update cannot be released as a hotpatch. When unscheduled baselines are released, a hotpatch release is replaced with an unplanned baseline in that month. Unplanned Baselines also include all updates in a newer Cumulative Update and require a restart.

The programming shown in the example image illustrates:

  • four baseline releases planned in a calendar year (five total in the diagram) and eight hotpatch releases;
  • two unplanned baselines that would replace the hotpatch releases for those months.

Patch orchestration process

Hotpatch is to be considered as an extension of Windows Update and patch orchestration tools vary depending on the platform in use.

Hotpatch orchestration on Azure

Virtual machines created in Azure are enabled by default for automatic patching when using a supported image of "Windows Server Datacenter: Azure Edition”:

  • patches classified as Critical or Security are automatically downloaded and applied to the VM;
  • patches are applied during off-peak hours considering the time zone of the VM;
  • Azure handles patch orchestration and patches are applied following the availability principles;
  • the health status of the virtual machine, determined through Azure platform health signals, is monitored for patching failures.

Hotpatch orchestration on Azure Stack HCI

Hotpatch updates for active VMs in Azure Stack HCI environment can be orchestrated using:

  • Group Policy to configure Windows Update client settings;
  • Windows Update client settings or SCONFIG per Server Core;
  • a third-party patch management solution.

Considerations and Limitations

However, like any technology, even hotpatching has its nuances. Not all patches are suitable for hotpatching; some may still require a traditional restart. Furthermore, before applying any patches, it remains crucial to test it in a controlled environment to avoid potential problems.

Installing Hotpatch updates does not support automatic rollback. In fact,, if a VM experiences a problem during or after an upgrade, you need to uninstall the update and install the latest known good baseline update. After the rollback you will need to restart the VM.

Conclusion

The introduction of hotpatching by Microsoft represents a significant step forward in the management of VMs running Windows Server operating system. With the ability to apply security patches and updates non-disruptively, administrators can ensure that their servers are protected and updated in a faster and more effective way. In a world where safety is paramount and where every second counts, hotpatching is positioned as a valuable solution for any company that uses Windows Server in an Azure environment or in an Azure Stack HCI environment.

Azure by your side: new solutions for Windows Server 2012/R2 end of support

In the era of Artificial Intelligence and native services for the cloud, organizations continue to rely on Windows Server as a secure and reliable platform for their mission-critical workloads. However, it is important to note that support for Windows Server 2012/R2 will end on 10 October 2023. After that date, Windows Server 2012/R2 systems will become vulnerable if action is not taken, as they will no longer receive regular security updates. Recently, Microsoft has announced that Azure offers new solutions to better manage the end of support of Windows Server 2012/R2. These solutions will be examined in detail in this article, after a brief summary to set the context.

The impact of end of support for Windows Server 2012 R2: what it means for companies?

Microsoft has announced the end of support for Windows Server 2012 and 2012 R2, fixed for 10 October 2023. This event represents a turning point for many organizations that rely on these servers to access applications and data. But what exactly does end of support mean (EOL) and what are the implications for companies?

Understanding end of support

Microsoft has a lifecycle policy that provides support for its products, including Windows Server 2012 and 2012 R2. End of support refers to when a product is no longer supported by Microsoft, which means no more security updates will be provided, patches or technical support.

Why companies should care

Without regular updates and patches, companies using Windows Server 2012 and 2012 R2 are exposed to security vulnerabilities, such as ransomware attacks and data breaches. Furthermore, using an unsupported product such as Windows Server 2012 or 2012 R2 can lead to non-compliance issues. Finally, outdated software can cause compatibility issues with newer applications and hardware, hampering efficiency and productivity.

An opportunity to review IT strategy

Companies should use the EOL event as an opportunity to review their IT strategy and determine the desired business goals for their technology. In this way, they can align the technology with their long-term goals, leveraging the latest cloud solutions and improving operational efficiency.

The strategies that can be adopted to deal with this situation, thus avoiding exposing your IT infrastructure to security issues, have already been addressed in the article: How the End of Support of Windows Server 2012 can be a great opportunity for CTOs.

About this, Microsoft has introduced two new options, provided through Azure, to help manage this situation:

  • updating servers with Azure Migrate;
  • distribution on Azure Arc-enabled servers of updates deriving from the ESU (Extended Security Updates).

The following paragraphs describe the characteristics of these new options.

Updating Windows servers in end of support phase (EOS) with Azure Migrate

Azure Migrate is a service offered by Microsoft Azure that allows you to assess and migrate on-premises resources, as virtual machines, applications and databases, towards the Azure cloud infrastructure. Recently, Azure Migrate has introduced support for in-place upgrades for Windows Server 2012 and later, when moving to Azure. This allows organizations to move their legacy applications and databases to a fully supported operating system, compatible and compliant as Windows Server 2016, 2019 or 2022.

Key benefits of Azure Migrate's OS update feature

Risk mitigation: Azure Migrate creates a replica of the original server in Azure, allowing the OS to be updated on the replica while the source server remains intact. In case of problems, customers can easily go back to the original operating system.

Compatibility Test: Azure Migrate provides the ability to perform a test migration in an isolated environment in Azure. This is especially useful for OS updates, allowing customers to evaluate the compatibility of their operating system and updated applications without impacting production. This way you can identify and fix any problems in advance.

Reduced effort and downtime: integrating OS updates with cloud migration, customers can significantly save time and effort. With only one additional data, the version of the target operating system, Azure Migrate takes care of the rest, simplifying the process. This integration further reduces downtime of the server and applications hosted on it, increasing efficiency.

No separate Windows licenses: with the Azure Migrate OS update, you do not need to purchase an operating system license separately to upgrade. That the customer uses Azure Hybrid Benefits (AHB) o PAYG, is covered when migrating to an Azure VM using Azure Migrate.

Large-scale server upgrade: Azure Migrate supports large-scale server OS upgrades, allowing customers to upgrade up to 500 server in parallel when migrating to Azure. Using the Azure portal, you will be able to select up to 10 VMs at a time to set up replicas. To replicate multiple VMs you can use the portal and add VMs to be replicated in multiple batches of 10 VMs, or use the Azure Migrate PowerShell interface to configure replication.

Supported OS versions

Azure Migrate can handle:

  • Windows Server 2012: supports upgrading to Windows Server 2016;
  • Windows Server 2012 R2: supports upgrading to Windows Server 2016, Windows Server 2019;
  • Windows Server 2016: supports upgrading to Windows Server 2019, Windows Server 2022;
  • Windows Server 2019: supports upgrading to Windows Server 2022.

Deployment of ESU-derived updates on Azure Arc-enabled servers

Azure Arc is a set of Microsoft solutions that help businesses manage, govern and protect assets in various environments, including on premise, edge e multi-cloud, extending the management capabilities of Azure to any infrastructure.

For organizations unable to modernize or migrate before Windows Server 2012/R2 end of support date, Microsoft has announced Extended Security Updates (ESU) enable Azure Arc. With Azure Arc, organizations will be able to purchase and distribute Extended Security Updates seamlessly (ESU) in on-premises or multicloud environments, direct from the Azure Portal.

To get Extended Security Updates (ESU) for Windows Server 2012/R2 and SQL Server 2012 enable Azure Arc, you need to follow the steps below:

  • Preparing the Azure Arc environment: first of all, you need an Azure environment and a working Azure Arc infrastructure. Azure Arc can be installed on any server running Windows Server 2012/R2 or SQL Server 2012, provided that the connectivity requirements are met.
  • Server registration in Azure Arc: once the Azure Arc environment is set up, you need to register your Windows servers or SQL Server systems in Azure Arc. This process allows systems to become managed resources in Azure, making them eligible for ESUs.
  • Purchase of ESUs: once the servers are registered in Azure Arc, ESUs can be purchased, for each server you want to protect, through Azure.
  • ESU activation: after the purchase of the ESUs, you need to activate them on the servers. This process involves installing a license key and downloading security updates from Windows Update or your local update distribution infrastructure.
  • Installing updates: finally, once the ESUs are activated, you can install security updates on servers. This process can be managed manually or by automating it through update management tools.

Note: ESUs only provide critical and important security updates, they do not include new features or performance improvements. Furthermore, ESUs are only available for a limited time after Microsoft's end of support. Therefore, we recommend that you consider migrating to newer versions of servers to have access to all features, in addition to security updates.

Conclusions

This year, Microsoft celebrates the 30th anniversary of Windows Server, a goal achieved thanks to relentless innovation and customer support. However, customers must commit to keeping their Windows Server systems up-to-date near the end of support. In particular, the end of support for Windows Server 2012 and 2012 R2 poses a significant risk to companies, but it also presents an opportunity to review and improve their IT strategy. Identifying desired business goals, engaging in strategic planning e, if necessary, using these new solutions offered by Azure, companies can ensure a smooth and successful transition, optimizing their IT infrastructure to achieve their long-term goals.

How the End of Support of Windows Server 2012 can be a great opportunity for CTOs

The end of support for operating systems Windows Server 2012 and 2012 R2 is fast approaching and, for Chief Technology Officer (CTO) of companies, this aspect must be carefully evaluated as it has significant impacts on the IT infrastructure. At the same time, end of support can be an important opportunity to modernize the IT environment in order to ensure greater security, new features and improved business continuity. This article outlines the strategies you can adopt to deal with this situation, thus avoiding exposing your IT infrastructure to security issues caused by this situation.

When does Windows Server 2012/2012R2 support end and what does it mean?

The 10 October 2023 marks the end of extended support for Windows Server 2012 and Windows Server 2012 R2. Without the support of Microsoft, Windows Server 2012 and Windows Server 2012 R2 will no longer receive security patches, unless you take certain actions below. This means that any vulnerabilities discovered in the operating system will no longer be fixed and this could make systems vulnerable to cyber attacks. Furthermore, this condition would result in a state of non-compliance with specific regulations, such as the General Data Protection Regulation (GDPR).

Furthermore, users will no longer receive bug fixes and other updates needed to keep the operating system in line with the latest technology, which could lead to compatibility issues with newer software and introduce potential performance issues.

On top of all that, Microsoft will no longer provide online technical support and technical content updates for this operating system.

All these aspects have a significant impact on the IT organizations that still use these operating systems.

Possible strategies and opportunities related to the end of support

This situation is certainly not very pleasant for those who find themselves facing it now, given the limited time, but it can also be seen as an important opportunity for renewal and innovation of its infrastructure. The following paragraphs show the possible strategies that can be implemented.

Upgrading on-premises systems

This strategy involves moving to a new version of Windows Server in an on-premises environment. The advice in this case is to approach at least Windows Server 2019, but it is preferable to adopt the latest version, Windows Server 2022, that can provide the latest security innovations, application performance and modernization.

Furthermore, where technically possible it is preferable not to proceed with in place updates of the operating system, but to manage migration in side-by-side.

This method usually requires the involvement of the application provider, to ensure software compatibility with the new version of the operating system. Since the software is not recent, often it require the adoption of updated versions of the same, which may comprise architecture adjustment and an in-depth phase of testing for the new release . By adopting this upgrade process, the time and effort are considerable, but the result you get is critical to complying with the technological renewal.

Maintaining Windows Server 2012/2012 R2, but with security updates for others 3 years

To continue receiving security updates for Windows Server 2012\2012 R2 hosted on on-premises environment, one option is to join the programExtended Security Update (ESU). This paid program guarantees the provisioning of Security Updates classified as "critical" and "important" for an additional three years, in the specific case until 13 October 2026.

The Extended Security Update program (ESU) is an option for customers who need to run some legacy microsoft products beyond the end of support and who are not in a position to undertake other strategies. The updates included in the ESU program do not include new features and non-security related updates.

Azure adoption

Migrating systems to Azure

Migrating Windows Server Systems 2012 and Windows Server 2012 R2 on-premises in Azure environment will continue to receive security updates for another three years, classified as critical and important, without having to join the ESU program. This scenario is not only useful to ensure compliance with its systems, but it opens the way towards hybrid architectures where you can get the cloud advantages. In this regard, Microsoft offers a great solution that can provide a large set of tools needed to best deal with the most common migration scenarios: Azure Migrate, that structure the migration process in different phase (discovery, assessment, and migration).

Also Azure Arc can be very useful for inventory digital assets in heterogeneous and distributed environments.

Adopting this strategy can be faster than upgrading systems and allows you to have more time to deal with software renewal. In this regard, the cloud allows you to have excellent flexibility and agility in testing applications in parallel environments.

Before starting the migration path to Azure, it is also essential to structure the networking of the hybrid environment appropriately and evaluate the iterations with the other infrastructure components, to see whether the application can also work well in the cloud.

Migration to Azure can take place to IaaS virtual machines or, in the presence of a large number of systems to be migrated in a VMware environment, Azure VMware Solution can be a solution to consider to face a massive migration quickly and minimizing the interruption of the services provided.

Extending Azure in your datacenter with Azure Stack HCI

Azure Stack HCI is the Microsoft solution that allows you to create a hyper-converged infrastructure (HCI) for running workloads in an on-premises environment and that provides a strategic connection to various Azure services. Azure Stack HCI was specifically designed by Microsoft to help customers modernize their hybrid datacenter, offering a complete and familiar Azure experience in an on-premises environment. For more information on the Microsoft Azure Stack HCI solution, I invite you to readthis article or to viewthis video.

Azure Stack HCI allows you to get free, just like in Azure, important security patches for Microsoft's legacy products that are past their end of support, through the Extended Security Update program (ESU). For further information you can consult this Microsoft's document. This strategy allows you to have more time to undertake an application modernization process, without neglecting security aspects.

Application modernization

Under certain circumstances, an application modernization process could be undertaken, maybe focused on the public cloud, with the aim of increasing innovation, agility and operational efficiency. Microsoft Azure offers the flexibility to choose from a wide range of options to host your applications, covering the spectrum of Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), Container-as-a-Service (CaaS) and serverless. In a journey to move away from legacy operating systems, customers can use containers even for applications not specifically designed to use microservices-based architectures. In these cases, it is possible to implement a migration strategy for existing applications that only involves minimal changes to the application code or changes to configurations. These are strictly necessary changes to optimize the application in order to be hosted on PaaS and CaaS solutions. To get some ideas about it, I invite you to read on this article.

Steps to a successful transition

For companies intending to undertake one of the strategies listed, there are some important steps that need to be taken to ensure a successful transition.

Regardless of the strategy you decide to adopt, the advice is to make a detailed assessment, so you can categorize each workload by type, criticality, complexity and risk. This way you can prioritize and proceed with a structured migration plan.

Furthermore, it is necessary to carefully evaluate the most suitable transition strategy considering how to minimize any disruption to company activities. This may include scheduling tests and creating adequate backup sets before migration.

Finally, once the migration is complete, It is important to activate a modern monitor system to ensure that the application workload is stable and working as expected.

Conclusions

Windows Server end of support 2012 and Windows Server 2012 R2 presents a challenge for many companies that still use these operating systems. However, it can also be seen as an opportunity for companies to start an infrastructure or application modernization process. In this way you will have more modern resources, also taking advantage of the opportunities they offer in terms of security, scalability and performance.

Disaster Recovery Solutions: Storage Replica vs DFS Replication

Microsoft Storage Replica is a technology introduced starting with Windows Server 2016 which among the main usage scenarios involves volume replication, synchronously or asynchronously, between servers or clusters, for disaster recovery purposes. Nowadays, several Microsoft customers continue to use DFS Replication (DFS-r) as a Disaster Recovery solution for unstructured data such as home folders and departmental shares. The question many are asking is whether the recent Storage Replica technology really takes the place of the well-established DFS-r mechanism. In this article the characteristics of the two solutions will be explored in order to clarify when it is convenient to use Storage Replica and when DFS Replication (DFS-r).

DFS Replication (DFS-r)

DFS Replication is a solution that can be activated through a role in Windows Server that allows you to replicate folders on different servers and geographic sites. The solution is based on an efficient replication engine, that contemplates the presence of more masters, which can be used to keep folders synchronized between different servers, even through network connections with limited bandwidth. DFS-r uses a compression algorithm known as Remote Differential Compression (RDC), able to detect changes in a file and replicate only the changed blocks instead of the entire file. DFS-r has long since replaced the File Replication Service (FRS) and it is also used for Active Directory Domain Services SYSVOL folder replication (AD DS) in domains where the functional level is at least Windows Server 2008.

The activation of DFS-r involves the creation of replication groups that contain the files and folders to be replicated:

Figure 1 – DFS-r Replication Process

For more information about the DFS Replication service (DFS-r) you can see the related Microsoft documentation.

Storage Replica

Storage Replica is a technology introduced from Windows Server 2016 and it allows the replication of volumes between servers or clusters for Disaster Recovery purposes.

Figure 2 – Server-to-server and Cluster-to-cluster storage replication scenarios

This technology also allows you to create stretch failover cluster with nodes spread over two different site, keeping storage in sync.

Figure 3 – Stretch clustered storage replication scenarios

In Windows Server 2016 the ability to use storage replication is only available if you use the Datacenter Edition of the operating system, while in Windows Server 2019 there is the possibility to activate Storage Replica also by adopting the Standard Edition, but with the following limitations:

  • You can replicate a single volume instead of an unlimited number of volumes.
  • The maximum size of the replicated volume should not exceed 2 TB.

For more information on Storage Replica, please consult the related Microsoft documentation.

Comparison of the solutions

The DFS-r solution is particularly effective in environments with limited network bandwidth and where it is necessary to replicate content on different nodes for which a limited number of changes are expected. However, DFS-r has significant limitations as a data replication solution, including:

  • Cannot replicate files in use or open.
  • It does not have a synchronous replication mechanism.
  • The latency for asynchronous replication can be of considerable duration (minutes, hours or even days).
  • It is based on a database that may require costly consistency checks as a result of any system outages.
  • The burden of environmental management is high.

The Storage Replica solution does not have the limitations listed above, but it is good to take into consideration the following aspects that differentiate it from the DFS-r solution and that in some scenarios could be considered as critical elements:

  • Replication occurs at the volume level and only one-to-one replication between volumes is allowed. However, it is possible to replicate different volumes between multiple servers.
  • Allows you to replicate synchronously or asynchronously, but it is not designed for low-bandwidth, high-latency networks.
  • Users are not allowed to access protected data on the target server while replication is in progress.
    • To validate the effectiveness of the replication process, it is still possible to carry out a Failover Test, which allows you to mount a writable snapshot of the replicated storage. To perform this operation, for testing purposes or backup, you must have a volume, not involved in replication, on the destination server. The Failover Test has no impact on the replication process, which will continue to ensure the protection of the data and the changes to the snapshot will remain circumscribed to the test volume.

How to replace DFS Replication (DFS-r) with Storage Replica?

If the characteristics of Storage Replica are not considered blocking, this latest technology can be adopted to replace the DFS Replication solution (DFS-r). The high-level process involves the following steps:

  • Install new systems at least Windows Server 2016, paying attention to evaluate the limits imposed by the Standard Edition, and configure storage. To learn more about improvements in Storage Replication with Windows Server 2019 you can consult this article.
  • Migrate the data that you want to replicate to one or more volumes of data (for example through Robocopy).
  • Enable Storage Replica replication and complete initial synchronization.
  • We recommend enabling snapshots through Volume Shadow Copies, in particular in the case of asynchronous replication. Snapshots are also replicated along with the files. In case of emergency, this will allow you to restore files from snapshots on the target server that may have only been partially replicated asynchronously.
  • Share the data on the source server and make it accessible through a DFS namespace. This aspect is important to ensure that users can still access the data when the server name changes during the activation of the Disaster Recovery plan. On the replication target server (DR site) you can create shares (not accessible during normal operations). The server on the DR site can be added to the DFS Namespaces keeping the target folders disabled.

If disaster recovery scenario needs to be activated, using the storage replica solution, you should do the following:

  • Make the server located on the DR site primary, so that it can show replicated volumes to users.
  • In case of synchronous replication, no data recovery will be required, unless during the loss of the origin server the user was using an application that wrote data without transaction protection.
  • In case of asynchronous replication, you may need to mount a snapshot to ensure application-wide data consistency.
  • Enable the target folders in DFS Namespaces to allow users to access their data.

Conclusions

Microsoft is continuing to make major investments in storage and Storage Replica is the tangible result that allows customers to adopt an effective and performing storage replication solution. In the Disaster Recovery field, there are several scenarios where Storage Replica can replace the DFS Replication service (DFS-r), however you should carefully evaluate the characteristics of both solutions to choose the one that best suits your usage scenario.

How to address the end of lifecycle for Windows Server 2008\2008 R2

The end of Microsoft support for Windows Server 2008 and Windows Server 2008 R2 is imminent and planned for 14 January 2020. As of this date, Microsoft will no longer release free security updates for these platforms in an on-premises environment. Unfortunately, there are still many systems in production that adopt these operating system versions. This article discusses the approaches you can take to address this situation, avoiding exposing your infrastructure to security issues caused by the unavailability of the necessary updates.

The end of the extended support for these platforms implies that Microsoft, unless certain actions are taken, will no longer release its security updates. Under these conditions the exposure to security attacks is considerable and would result in the state of non-compliance with respect to specific regulations, such as the General Data Protection Regulation (GDPR). This condition, certainly not very pleasant for those who find themselves to face it now, given the limited time, it can also be seen as an important opportunity for renewal and innovation of the infrastructure.

To continue receiving security updates for Windows Server 20082008 R2 hosted on on-premises environment, the only possibility is to join to the program Extended Security Update (ESU). The fee program is only available for customers in Software Assurance and ensures the provision of Security Update classified as "critical" and "important" for a further three years, from 14 January 2020.

If the ESU program is not appropriate to their needs you can be assessed two totally different upgrade paths.

Upgrade on-premises

This path provides for the transition to a new version of Windows Server environment on-premises. The advice in this case is to approach at least Windows Server 2016 and not to proceed, whenever possible, with upgrade in place of the operating system, but to manage migration in side-by-side. This method usually requires the involvement of the application provider, to ensure software compatibility with the new version of the operating system. Since the software is not recent, often it require the adoption of updated versions of the same, which may comprise architecture adjustment and an in-depth phase of testing for the new release . By adopting this upgrade process, the time and effort are considerable, but the result you get is critical to complying with the technological renewal.

Migrating to Azure

Migrating Windows Server Systems 2008 and Windows Server 2008 R2 on-premises in Azure environment will continue to receive security updates for another three years, classified as critical and important, without having to join the ESU program. This scenario is not only useful to ensure compliance with its systems, but it opens the way towards hybrid architectures where you can get the cloud advantages. In this regard, Microsoft offers a great solution that can provide a large set of tools needed to best deal with the most common migration scenarios: Azure Migrate,  that structure the migration process in different phase (discovery, assessment, and migration). This approach may be more immediate than upgrading systems and gives you more time to deal with software renewal. In this regard, the cloud allows you to have excellent flexibility and agility in testing applications in parallel environments. Before starting the migration path towards Azure is fundamental to structure the hybrid networking environment in a timely manner and evaluate the iterations with the other infrastructure components, to see whether the application can also work well in the cloud.

Regardless of the upgrade path you decide to take the advice is to make a detailed assessment, so you can categorize workloads by type, criticality, complexity and risk. In this way it is possible to prioritize, and proceed with a structured migration plan.

Conclusions

For all those who, inside their own datacenter have Windows Server 2008 or Windows Server 2008 R2 is appropriate to manage the condition that Microsoft will not release more security updates, free of charge, exposing systems to potential security issues. At the same time there are various possibilities offered by Microsoft to address this situation in the best possible ways. The migration path to Azure is definitely a very interesting option to start the journey to expand your datacenter into the Microsoft public cloud.