azure arc
261 TopicsGenerally Available: Transition to WS2012 / R2 ESUs enabled by Azure Arc from Volume Licensing
Customers that have enrolled in WS2012/ R2 ESUs through Volume Licensing for Year 1 can transition to Azure Arc for Year 2 of the program by specifying their Volume Licensing entitlements (Invoice Ids) in provisioning new Azure Arc WS2012/R2 ESU licenses. Extended Security Updates afford customers with critical security patches for end of support Windows Server 2012/R2 machines.6KViews3likes4CommentsFive Key Updates on WS2012 ESUs enabled by Azure Arc
We’re excited to announce the public preview of the Azure Arc ESU Usage View and Transition Scenario from Year 1 Volume Licensing. Additionally, we have made a breadth of improvements to pre-requisites, billing service, and included capabilities.4KViews4likes3CommentsWindows Server 2012/R2 Extended Security Updates Licensing and Billing
While more and more organizations are moving towards cloud they are all using cloud in their own way depending on size and scale. Some have adopted cloud native model using Microsoft Azure, but some decided to use cloud services while still maintaining their on-premises footprint. The latter approach is known as Hybrid model. Hybrid also means having presence in more than one cloud provider. While the Hybrid model comes with some advantages and flexibility it has certain challenges too. One of the biggest challenges is the added management complexity. In a Hybrid model as the workload grows, organizations might struggle to control the growing complex environments which could be extending across data centers, multiple clouds and even the edge. One common struggle which we will be covering in this blog post today is… the ability to protect your end-of-support Windows Servers which are either in multi-cloud environment or on-premises. What options do Customers have for end-of-support Windows Servers 2012/R2? It’s not always easy for clients to upgrade all older Windows Servers to Win2016 or later. As the on-premises or multi-cloud environment servers reach the end of support, it also means end of security updates which can put business applications running on the server at security risk and can cause compliance issues. The Extended Security Updates (ESU) program is an option that can be used by customers to run Windows servers past the end of support for a maximum period but not indefinitely. The updates provided through ESUs are only Security updates as well as critical and important rated bulletins. Below are options for customers to use ESU: Migrate workload to Azure: Migrate existing affected Windows Server workloads as-is to Azure Virtual Machines which will automatically provide ESU for a defined period without being additionally charged for these updates on top of Azure VM's cost. Migrating workloads to Azure VMware Solution (AVS) also makes them eligible for free ESUs. Get ESU through Azure Stack HCI: On-premises Windows Server 2012/ 2012 R2 virtual machines connected to cloud via Azure Stack HCI can get free ESUs through Azure verification of VMs. Purchase ESU license outside of Azure: By purchasing ESU, they can protect them until they decide to upgrade them to a more recent version or migrate them to cloud. Purchase ESU License Options If workload running outside of Azure and not connected to cloud through Azure Stack HCI, customers have below options for licensing ESU. Azure Arc-enabled Servers: Their on-premises servers or in a hosted environment should be connected through Azure Arc service to have Arc-enabled servers. If they are Arc enabled, they can enroll their Windows Server 2012 and 2012 R2 servers for ESU via the Azure portal. They will be billed monthly on their subscription. Non-Arc enabled physical and virtual machines – For these servers they can enable ESU by acquiring ESU licenses through Microsoft Volume Licensing program. These ESU licenses are valid for annual coverage periods and each license is entitled to a specific server or operating system for the duration it has been purchased. They can acquire license for later years only if they have acquired licenses for prior years. Purchase ESU License Eligibility Criteria To be eligible for ESU licenses, their server/operating system must qualify one of the following: Customers should have Software Assurance to purchase ESUs on-premises or in hosted environment. Windows Server 2012/2012 R2 machines are licensed through Services Provider License Agreement (SPLA) and not using their own licenses. Windows Server 2012/2012 R2 machines are licensed with a Server Subscription where Software Assurance is not required. ESU Licensing with Azure Arc enabled Windows Server 2012/2012 R2 To deliver ESU for Windows Server 2012, customers should provision Windows Server Arc ESU licenses and then apply/link those licenses to Azure Arc enabled servers. These can be done via Azure portal. Before we progress to understand how to provision WS2012 ESU license and to link licenses to Arc enabled servers it is good to be aware about below: Standard vs Datacenter Edition: When standard edition of license selected, it will be limited to 2 virtual instances but with Datacenter Edition, it can be applied to unlimited virtual instances. vCore Vs pCore Licensing: vCore (Virtual Core ) Licensing: When this licensing is chosen, they will pay based on the number of virtual cores (vCores) being used by the OS. It requires a minimum of 8 cores per Virtual machine when selected. It uses the standard edition rate for billing. pCore ( Physical Core) Licensing: If they choose to license based on physical cores (pCores), then they pay based on the number of physical cores (pCores) utilized by the host operating system. It requires a minimum of 16 cores per server when selected. Customers have the flexibility to use this licensing with either edition. NOTE: vCore Licensing cannot be used on physical servers. They can select either licensing options or can also select a mix of pCore and vCore licensing for their virtual machines within the remit of their virtualization entitlements. Create a new ESU WS2012 license: Step 1: Sign in to the Azure portal Step 2: On the Azure Arc service page, select Extended Security Updates in the left pane under Management section. Step 3: Under Licenses tab, select Create. Step 4: Provide the information required in Create an Extended Security Updates license page to configure the license. Resource group: The ESU license will be billed to. License name: You can create multiple licenses. It may be helpful following a naming convention for license name. SKU and Core Type: Select the value based on licensing option chosen. Core Packs: Enter the value based on cores count required. You can modify the number of cores associated with a license later after creation. Step 5: Review the information provided and then select Create. License created from above will appear in the list under Licenses tab. Licenses can be linked to Arc-enabled servers following steps in next section. ESU license can be provisioned in a deactivated state during creation to avoid initiation of billing. Link ESU licenses to Arc-enabled servers: Each license can be linked to one or more Arc-enabled servers. Step 1: Sign in to the Azure portal Step 2: On the Azure Arc service page, select Extended Security Updates in the left pane under Management section. Step 3: Select Eligible Resources tab. This will give you the list of all Arc-enabled servers which are running Windows Server 2012/2012 R2 and eligible for ESU updates. ESU Status column tells us whether the machine is ESU enabled. Step 4: Select the machines from the list (with ESU Status = Not enabled) and then select Enable ESUs. Step 5: Next page Enable Extended Security Updates shows the count of machines selected for enabling ESU and lists the available licenses. Select the license that needs to be linked to these machines and then click on Enable at bottom of page. It will take some time but later the status of machine in ESUs Status column changes to Enabled. NOTE: A Windows Server is eligible to receive ESU updates once linked to an activated ESU license. ESU Licensing limits: Customer can include up to 10,000 cores within each WS2012 ESU license and if needed for more cores then can split the cores across multiple licenses. However, there is a limitation of only 800 licenses per resource group. ESU Billing: Billing for ESU is mainly dependent on three factors: Number of cores provisioned Selection of license edition Any eligible discounts While above three factors sound simple, below are few good to know points before we proceed to understand on how to estimate monthly cost: Is the Customer planning to decommission any servers? Do not include the core counts for servers, which need to be decommissioned and do not require extended security updates applied. Back-billing for sign-ups after the end of support dates: For customers who enroll in ESUs enabled by Azure Arc after the end of support date October 10, 2023, for Windows Server 2012/R2, they will be billed a one-time upfront charge for the months they missed after the end of support date, with billing coming in at the end of the first month when they signed-up. Example: XYZ Corp has decided to enroll for ESU for Windows Server 2012/R2 in February 2024. In that case they will receive a one- time back-bill for October (starting from 11th of the month), November, December 2023, and January 2024 at the end of February month. After February, for the later months, XYZ Corp billing will only be based on the current month. Back-billing applies even if a customer intermittently deactivates ESUs. Example: If XYZ Corp, unenrolls in March 2024 and then decides to re-enrolls in June 2024, the re-enrollment will trigger back-billing for April and May 2024. When ESU enabled by Azure Arc, Customers can link their already paid extended security updates to their eligible Disaster Recovery Benefit servers. Billing is monthly. Decrementing, deactivating, or deleting a license will result in charges for up to five more calendar days from the time of decrement, deactivation, or deletion. Reduction in billing isn't immediate. There is no cost for non-production workloads that need ESU updates. Examples of Cost-Effective ESU Licensing: It is recommended to refer to the Azure Pricing calculator for calculating estimated monthly cost. Let us take some examples (based on public pricing) to understand cost effective ESU licensing. Example 1 *: XYZ Corp. has currently got a VMware cluster containing 28 hosts with 736 physical cores on-premises. There are 90 VMs on the cluster and they are running Windows Server 2012 R2 consuming all 736 cores. Based on above information, public pricing for Arc Enabled ESU for both the licensing option would be: pCore (Physical Core) Licensing: 46 x Windows Server 2012 DC – 16 Core (£341) = ~ £15K / month vCore (Virtual Core) Licensing: 92 x Windows Server Standard – 8 Core (£30) = ~ £3K / month They can either license the entire cluster with 736 Windows Server 2012 Datacenter ESU physical cores or license each VM individually with a total of 736 standard edition virtual cores. In the above case, it's cheaper to purchase an Arc ESU Windows Server 2012 Standard edition license associated with 736 virtual cores if all other factors align with the option. NOTE: In the above example it was assumed that ESU vCore/pCore licensing requirements for the machines were achieved. Example 2 *: ABC Corp has currently got 64 cores of Datacenter Edition and 128 cores of standard edition physical hosts running Windows 2012 and eligible for ESU. When buying licenses, they can buy in 2 or 16 core packs with not much difference in cost. 8 packs of 2 cores costs almost the same as 1 pack of 16 core. When buying 16 core packs then pricing calculation will be: 64 cores of Datacenter Edition = 4x Windows Server 2012 DC – 16 core (£341) = ~ £1.3 K /month 128 cores of Standard Edition = 8 x Windows Server Standard – 16 core (£60) = £480/month When calculating with 2 core packs, calculation will look like: 64 cores of Datacenter Edition = 32 x Windows Server 2012 DC – 2 core (£43) = ~ £1.3 K /month 128 cores of Standard Edition = 64 x Windows Server Standard – 2 core (£7.4) = £473.6 /month As seen in the above calculations, buying multiple packs of lesser core, or buying a smaller count of packs with larger core size does not bring much cost difference. However, for situations where they need granular control on activation of licenses, it might help with the flexibility in buying multiple packs of required cores. * This example is only for illustration purposes. Scenario and factors to consider for cost effective ESU licensing option may vary based on Customer requirements. Summary Extended Security Updates for Windows Server includes security updates, critical and important bulletins for a period after end of extended support. ESUs do not include new features, customer-requested non-security updates, or design change requests. After the period of ESU ends, Microsoft will stop providing updates. It is recommended to upgrade your version of Windows Server to the current version or more recent version as soon as possible for the most advanced security, performance and innovation. Where updates are not immediately possible, migrating your on-premises Windows servers Infrastructure (that has past the end of extended support or almost reaching to it) to Azure or connecting them to cloud using Azure Stack HCI is also an option (for a defined period) as they're eligible for free ESUs. ESU Availability and End dates information for Windows Server 2012/2012 R2 are: End of Extended Support/ESU Start Date: October 10, 2023 ESU End Date Year 1: October 8, 2024 ESU End Date Year 2: October 14, 2025 ESU End Date Year 3: October 13, 2026 Type of Security Update: Critical, Important Learn More Search Product and Services Lifecycle Information - Microsoft Lifecycle | Microsoft Learn Overview of Extended Security Updates for Windows Server 2008, 2008 R2, 2012, and 2012 R2 | Microsoft Learn Product Lifecycle FAQ - Extended Security Updates | Microsoft Learn Extended Security Updates (ESU) on Azure Stack HCI - Azure Stack HCI | Microsoft Learn Manage Azure Arc-enabled Servers using Windows Admin Center in Azure preview | Microsoft Learn Overview of Windows Server upgrades | Microsoft Learn Perform an in-place upgrade of Windows Server | Microsoft Learn16KViews7likes12CommentsGenerally Available: Windows Server 2012 and 2012 R2 Extended Security Updates enabled by Azure Arc
Secure your End-of-Life Windows Server infrastructure on your own terms with Azure Arc. Benefit from the flexibility of a monthly Azure billed service and free access to Azure management services by leveraging Extended Security Updates enabled by Azure Arc for your Windows Server 2012 and 2012 R2 machines.44KViews3likes4CommentsThe first Windows Server 2012/R2 ESU Patches are out! Are you protected?
Receive critical security patches for your WS2012/R2 machines enrolled in ESUs enabled by Azure Arc. Follow these detailed instructions outlining all of the enrollment and prerequisites, so you are protecting your EOL infrastructure.10KViews1like6CommentsWhat’s new for small form factor infrastructure
At Microsoft Build, we introduced smaller form factor infrastructure in public preview. Today, we’re refreshing that preview with version 2607, available right now in the Azure portal. This release introduces several new features: Expanded support for multiple network interfaces (NICs) and additional disks Just-in-Time (JIT) device access through the new Connect experience Cloud-managed operating system updates and recovery using an A/B image model These new capabilities give operators greater flexibility in how edge devices are configured, accessed, and maintained throughout their lifecycle. Let’s look at what each capability delivers and what it looked like in practice when I deployed the release on an OnLogic Helix 521. Greater networking and storage flexibility Small form factor infrastructure now supports multiple network interfaces (NICs) and disks on a single device. To give you full control, each NIC appears natively in Azure Resource Manager (ARM) as a child resource of the Machine, which you can view and configure through Azure portal and Azure CLI. Distributed infrastructure often faces unique and challenging requirements: for example, a device on a factory floor may need one network for management traffic and a separate, isolated network for operational technology (OT) or workload traffic, while a retail or robotics deployment may need additional local storage for AI models, video, or sensor data that shouldn’t leave the site. Support for multiple NICs allows a single device to connect to more than one network for segmentation, redundancy, or reaching equipment on a dedicated segment, while support for additional disks lets customers size local capacity to the workload rather than constraining the workload to fit the device. From Azure, you can configure each network interface individually, applying values like IP address, DNS server, and more. Azure also automatically detects and flags configuration drift to help maintain consistency with the desired state. resolve. This is an exciting step forward since the initial preview. Previously, each device was limited to a single network path and its built-in storage, forcing customers to compromise on network separation, add external hardware, or offload data sooner than they would like. Now the same compact device can support real-world network topologies and larger local datasets, without stepping up to larger, more costly infrastructure. Together, these enhancements allow Azure Local devices to align more closely with real-world edge deployment requirements without requiring additional infrastructure. Secure access when you need it: Just-in-Time (JIT) access Connecting to a distributed edge device for maintenance has traditionally required a difficult trade-off. Troubleshooting a device requires administrative access and granting that access permanently means standing permissions that remain in place on the resource whether or not anyone is using them. Across a fleet of hundreds or thousands of devices, often deployed in physically exposed locations such as store back rooms, remote sites, or factory floors, those always-on credentials become a persistent and hard-to-audit part of the attack surface. Just-In-Time (JIT) access, delivered through the new Connect experience, eliminates standing access. Rather than holding permanent permissions, users are granted eligible roles through Microsoft Entra Privileged Identity Management (PIM) and activate them only when access is actually needed. Activation requires a business justification and administrator approval, is bound to a defined duration of up to eight hours and connects the user to the device over SSH using a short-lived certificate. When the window expires, the role is deactivated automatically. The result is a model where access is the exception rather than the default: every session is requested, justified, approved, time-bound, and logged. For organizations operating critical infrastructure at the edge, administrators retain the ability to reach any device the moment they need to, without maintaining persistent access on every device for the rest of the time. Simplified OS lifecycle management with A/B image updates Last month’s preview introduced a novel capability: provisioning a bare metal OS onto an edge machine from Azure. With 2607, we’re building on that capability with the capability to update a bare metal OS using an image-swap approach. Updates now use an A/B image-swap model, one of the most impactful reliability improvements in this release. The new image is installed on an inactive partition while the current operating system continues running. During reboot, the device switches to the updated image. If the new image fails to boot successfully, the device automatically rolls back to the last known-good version. This design keeps the risk of a failed update tightly contained. Because the update is staged in the inactive slot while the current image stays live, workload downtime is minimal, and because the previous image is always preserved, a failed update rolls back on its own rather than leaving a device stranded. Every device either comes up healthy on the new image or returns to the one that was working. For organizations managing thousands of devices in locations with no on-site IT, this safeguard can be very helpful because a failed update has historically been one of the most costly failures to recover from: a device that does not come back online can require a costly on-site visit or a physical replacement. Putting it to the test on an OnLogic Helix 521 To see how these capabilities come together in practice, I deployed the release on an OnLogic Helix 521, one of the validated small form factor devices for Azure Local. The Helix 521 is great for exercising the new networking features, with its I/O dense design featuring four Ethernet ports on its front side. These new features move small form factor infrastructure closer to what production edge deployments require: the flexibility to match real network and storage needs, access that is secure by default, and updates that can be rolled out across an entire fleet with confidence. To try preview version 2607 for yourself, visit Microsoft Learn for information about supported hardware and https://learn.microsoft.com/azure/azure-local/small-form-factor/small-form-factor-overview in Azure portal. The preview is free of charge and typically takes about an hour to set up.594Views2likes1CommentEpisode 1: Onboarding Azure Arc at Scale | The Azure Arc Check-In
Once a month the Azure Arc team will release an episode covering a variety of topics. To request a topic or view additional episodes please visit: aka.ms/the-azure-arc-check-in Episode 1: Onboarding Azure Arc at Scale Scenario: Imagine your organization has 1,000 Windows and Linux servers spread across multiple locations. You want them all in Azure Arc, but first you need to deploy the Azure Connected Machine agent at scale. Try now in Azure aka.ms/aaci-episode1 Why onboarding strategy matters Interactive sign-in works well for testing and proof-of-concepts, but it quickly becomes impractical when you’re onboarding large server estates. At scale, organizations need a deployment model that can: Automate onboarding across many machines Align with existing management tooling Apply consistent configuration and governance from day one Minimize manual effort and human error This episode focuses on using non-interactive authentication and automation to onboard large server fleets efficiently. One of the key recommendations is to use a dedicated authentication mechanism designed for scale rather than relying on interactive administrator sign-ins. Onboard a Linux fleet with Ansible The Ansible deployment begins with an Ansible node that is already connected to Azure Arc. The deployment uses the credential on the Ansible node to deploy the Azure Connected Machine agent to the Linux fleet. To enable this, the managed identity of the Ansible node has the Azure Connected Machine Onboarding role in Azure assigned. Below are the steps for role assignment in the Azure portal: Open the resource group where the servers will be deployed. In Access control, add a role assignment. Select the Azure Connected Machine Onboarding role. Choose managed identities, select Machine - Azure Arc, and find the Ansible node. Review and assign the role. Configure the Ansible playbook With the permissions in place, the deployment uses three files: inventory.ini: Represents the machines configured by the playbook. arc-vars.yml: Contains non-secret configuration, including the resource group name, subscription and tenant IDs, location, and tags. arc-onboard.yml: References arc-vars.yml and configures the playbook to use managed identity, or MSI, for authentication. After the playbook runs, Ansible deploys the Azure Connected Machine agent to the Linux fleet. You can return to the resource group, refresh the view, and verify that your Linux machines appear as Azure Arc connected servers. Onboard Windows machines with Group Policy For Windows Server environments joined to Active Directory, Group Policy remains one of the simplest and most scalable deployment mechanisms. The process includes: Creating the required onboarding identity Preparing a shared location for deployment assets Downloading the Azure Arc GPO deployment package Generating a Group Policy Object with the required settings Linking that GPO to the appropriate organizational unit (OU) Allowing targeted servers to automatically onboard during policy refresh cycles For organizations that already manage Windows Server through Active Directory, this approach enables onboarding at scale without introducing additional management infrastructure. FAQs What is the best way to onboard servers to Azure Arc at scale? For large Windows and Linux server environments, use automated deployment with non-interactive authentication rather than signing in interactively on each machine. This approach lets you deploy the Azure Connected Machine agent consistently across many servers while reducing manual effort and human error. Azure Connected Machine Agent Deployment Options - Azure Arc Can I use Ansible to onboard Linux servers to Azure Arc? Yes. You can use an Azure Arc-enabled Ansible node to deploy the Azure Connected Machine agent across a Linux server fleet. In the approach demonstrated here, the Ansible node uses its managed identity, which is assigned the Azure Connected Machine Onboarding role, to authenticate the deployment. Connect machines to Azure Arc at scale using Ansible - Azure Arc Can I use Group Policy to onboard Windows servers to Azure Arc? Yes. Group Policy can automate Azure Arc onboarding for Windows Server machines that are joined to Active Directory. The process uses a Group Policy Object linked to the appropriate organizational unit, allowing targeted servers to onboard automatically during Group Policy refresh cycles. Connect machines at scale using Group Policy with a PowerShell script - Azure Arc What files are needed to onboard Linux servers to Azure Arc with Ansible? The Ansible deployment shown in this episode uses three files: inventory.ini to identify the target machines, arc-vars.yml to store non-secret configuration such as subscription, tenant, resource group, location, and tags, and arc-onboard.yml to run the onboarding playbook using managed identity authentication. Should I use Ansible or Group Policy for Azure Arc onboarding? Use Ansible when onboarding Linux servers in an environment that already uses Ansible playbooks and automation. Use Group Policy when onboarding domain-joined Windows servers managed through Active Directory. Both approaches help organizations automate Azure Connected Machine agent deployment by using tools already present in their server-management environment. Additional options are available for onboarding servers at scale. See Azure Connected Machine Agent deployment options.297Views1like0CommentsGenerally Available: Windows Server 2016 Extended Security Updates enabled by Azure Arc
Today, the Azure Arc team is pleased to announce that Extended Security Updates (ESUs) enabled by Azure Arc is now generally available for Windows Server 2016. By connecting your Windows Server 2016 machines to Azure Arc-enabled servers, you can enroll in ESUs and receive security updates. Enroll machines into ESUs through the Azure portal, a streamlined, cloud-connected experience that protects your on-premises and multicloud workloads while you plan your upgrade or migration journey. Extended Security Updates give you access to Critical and Important security updates for Windows Server 2016 for up to three years after end of support, covering January 12, 2027 through January 2030. They provide a supported bridge for business-critical applications that need more time to migrate, without new features or non-security fixes, and without leaving systems exposed while you plan your move. Extended Security Updates enabled by Azure Arc Once your servers are connected to Azure Arc, ESUs enabled by Azure Arc provide flexible pricing and simpler delivery. Key benefits include: Pay-as-you-go billing means a monthly subscription you can stop when a server is migrated or decommissioned, so you only pay for the coverage you use. Azure-billed pricing draws down from your existing Microsoft Azure Consumption Commitment (MACC) and lets you analyze spend with Microsoft Cost Management and Billing. Built-in asset inventory shows the coverage and enrollment status of your machines directly in the Azure portal, highlighting gaps at a glance. Keyless delivery removes the need to acquire, install, or activate keys on each server. Access to Azure management services When you enroll eligible Azure Arc-enabled servers in Windows Server 2016 ESUs or you have Windows Server Software Assurance, you also gain free access to a set of Azure services that help you manage and secure those machines from the Azure portal: Azure Update Manager is a unified service which provides assessing, scheduling, deploying and managing OS updates across Azure and hybrid machines, including visibility into ESU patch compliance for your Windows Server 2016 estate. Change Tracking and Inventory provides a centralized asset inventory and tracks changes to servers hosted in Azure, on-premises, and other public cloud environments. Azure Policy guest configuration helps define, enforce, and audit compliance rules for Azure resources and guest OS settings across hybrid environments. It includes out of the box policy rules to help meet standards like CIS Benchmark. How to get started Everything starts by connecting your servers to Azure Arc, whether they run on-premises or in other public clouds. Getting started takes only a few steps: Connect your Windows Server 2016 machines to Azure Arc by installing the Azure Connected Machine agent. Enroll eligible servers in Extended Security Updates from the Azure portal, or at scale using Azure Policy (no keys required). Check out our click through demo to see how to apply Extended Security Updates using the Azure portal. Deliver ESU patches through Azure Update Manager or your existing patching solution once servers are enrolled. Extended Security Updates support the Standard and Datacenter editions of Windows Server 2016 and generally require Software Assurance through a Volume Licensing program (machines licensed through SPLA or a Server Subscription do not). For larger estates, you can onboard at scale using Configuration Manager, a Group Policy scheduled task, or VMware vCenter and SCVMM integration with Azure Arc. Beyond Extended Security Updates Enrolling in ESUs is often a customer's first step into Azure Arc — and it opens the door to more. Because your Windows Server 2016 machines are now attached to Azure Arc, you can manage, secure, and govern them alongside your wider hybrid and multicloud estate with Azure Policy, Azure Update Manager, and Microsoft Defender for Cloud. That same Arc foundation makes your next step easier when you are ready: upgrading to Windows Server 2025 or migrating to Azure. Learn more To plan for Windows Server 2016 end of support, explore these resources: Extended security updates enabled by Azure Arc guide Planning ahead for Windows Server 2016 end of support Windows Server and SQL Server End of Support | Microsoft Prepare to deliver Extended Security Updates through Azure Arc Join the Azure Arc customer and engineering virtual meetup Fill in this short intake form to join the quarterly Azure Arc and Windows Server customer meetup: https://aka.ms/arcserverforumsignup2.1KViews2likes0Comments