Period: last 7 days · Items: 10 · Source: Azure official updates RSS
This week’s Azure updates have a fairly clear pattern. On one side, developer productivity and AI agent integration capabilities for SQL and PostgreSQL have moved into GA/Preview. On the other, retirement notices continued for Batch VM series, storage accounts, and network clients—items where “you need to start with inventory right now.” In short, this is a week where new features are ready for PoCs, while the Retirement items may look far off but can create significant operational risk if not cleaned up early.
· The D-series, Ds-series, Dv2-series, Dsv2-series, and Ls-series VM series used in Azure Batch pools are scheduled to retire on May 1, 2028.
· After that date, you will no longer be able to create new Batch pools using these VM series.
· Existing Batch pools are also affected, and over time will need to transition to alternative VM series.
· Because the impact is limited to Azure Batch pools, inventorying Batch assets is important regardless of whether you use these VMs for general-purpose workloads.
What you get: Customers running Batch operations can identify early which pools are candidates for mid- to long-term replacement. This is especially valuable for planning capacity for HPC, rendering, and large-scale parallel processing workloads.
What to do now: If you use Azure Batch, extract the current list of VM sizes in your pools, inventory whether D/Dv2/Ls families are in use, and begin evaluating replacement series.
Why now: Even though the retirement date may still seem far away, Batch migrations have long lead times because images, node performance, cost, and quotas all need to be reviewed together. Starting early is the only way to transition without operational disruption.
Source: https://azure.microsoft.com/updates?id=564772
· The Av2-series, F-series, Fs-series, Fsv2-series, G-series, Gs-series, and Lsv2-series VM series used in Azure Batch pools are scheduled to retire on November 15, 2028.
· After retirement, you will no longer be able to create new Batch pools based on these VM series.
· Existing configurations will also require long-term transition to alternative VM series.
· In particular, for workloads designed around specific CPU or storage characteristics such as F/Fsv2 and Lsv2, performance validation is critical.
What you get: Teams operating performance-sensitive Batch workloads can narrow down replacement VM candidates early and prepare PoCs. It also creates an opportunity to address cost optimization and performance revalidation at the same time.
What to do now: Check whether your Batch pools use Av2/F/Fsv2/G/Lsv2 families, and plan a next-generation VM size performance comparison PoC based on representative jobs.
Why now: If you look at retirement notices too late, they can appear to be simple replacements, but in practice differences in node scaling behavior and disk/memory performance make advance testing essential.
Source: https://azure.microsoft.com/updates?id=564774
· SQL MCP Server is now GA.
· It supports building agentic solutions while providing controlled access to operational data.
· It is designed for SQL and is also described as compatible with PostgreSQL and Azure Cosmos DB.
· It supports AI/agent scenarios connected to production data in a way that considers both security and performance.
What you get: Data platform teams and AI teams can design agent/tool integration architectures in a more controlled manner instead of allowing unrestricted direct connections to production databases. This expands your options for balancing production data usage with governance.
What to do now: Teams operating SQL/PostgreSQL/Cosmos DB should identify applicable SQL MCP Server scenarios and begin agent integration PoCs in non-production environments.
Why now: For enterprise customers, data access control is often a bigger obstacle than AI adoption itself. GA is a signal that this is ready for serious evaluation.
Source: https://azure.microsoft.com/updates?id=564734
· Microsoft Entra server principals (logins) in Azure SQL Database are now GA.
· You can use CREATE LOGIN ... FROM EXTERNAL PROVIDER in the virtual master database.
· It provides an operating model for Microsoft Entra ID-based logins similar to SQL logins.
· This update moves Azure SQL Database toward greater consistency in authentication and authorization management.
What you get: DBAs and security teams can manage Entra-based server logins in Azure SQL Database in a more standardized way. This helps improve consistency in account management and access control.
What to do now: Azure SQL Database operations teams should compare this with existing SQL login/contained user configurations, assess whether Entra server principals can be adopted, and validate the permission model in a test environment.
Why now: The more you streamline your authentication model, the better your operational convenience and security audit readiness become. This is especially worth immediate review for customers standardizing around Entra.
Source: https://azure.microsoft.com/updates?id=565154
· GitHub Copilot Agent mode is available in Public Preview in SSMS.
· Included scenarios cover investigating performance issues, query tuning, maintenance/configuration reviews, identifying security issues, error analysis, and support for operational tasks.
· The feature is intended to improve database operations productivity for DBAs and developers.
· Because it is currently in Preview, validation is required before applying it to production environments.
What you get: DBAs and development teams gain an assistive tool for speeding up repetitive diagnostic, tuning, and review tasks. This is especially meaningful for organizations with limited access to experienced DBAs, where it can help reduce productivity gaps.
What to do now: Organizations using SSMS should enable Copilot Agent mode in non-production databases and draft internal guidance for performance analysis, query tuning, and security review scenarios.
Why now: During Preview, it is more important to define “how far our organization will allow this to go” than to focus only on the feature itself. Reviewing it now enables faster adoption after GA.
Source: https://azure.microsoft.com/updates?id=562637
· PostgreSQL Hub for Azure Developers is now GA.
· It is a hub that brings together Azure resources for PostgreSQL-based AI and application development.
· It provides sample apps, solution accelerators, tutorials, and structured learning paths.
· It is intended to improve development productivity for PostgreSQL on Azure.
What you get: Development teams can quickly find PostgreSQL on Azure reference materials and learning resources, reducing the time required for initial architecture reviews. It also helps improve team onboarding and PoC speed.
What to do now: Customers using PostgreSQL should review the Hub’s sample apps and learning paths, and use them as starting points for internal standard architectures or new service PoCs.
Why now: PostgreSQL is increasingly being chosen for new apps and AI-connected workloads. With an official hub now available, this is a good time to organize previously scattered reference materials across teams.
Source: https://azure.microsoft.com/updates?id=562084
· Starting March 31, 2026, Azure Synapse Link can no longer be enabled for new Azure Cosmos DB NoSQL accounts.
· Existing customers will be supported through March 31, 2029, when Azure Synapse Link reaches end of life.
· Microsoft recommends that customers begin preparing for migration.
· Because the timing of impact differs between new and existing accounts, you need to assess current usage separately.
What you get: Customers using Cosmos DB integrated with analytics can recognize early that an architectural transition will be needed in the future. It is particularly important that planning can distinguish between new deployments and existing operations.
What to do now: If you use Cosmos DB NoSQL + Synapse Link, separately review plans for new account creation and the current state of existing account usage, and begin evaluating migration to alternative architectures.
Why now: New accounts will face restrictions starting in 2026, and existing customers now have a confirmed 2029 end date. Data analytics pipeline transitions have significant downstream impact, so they need to be designed in advance.
Source: https://azure.microsoft.com/updates?id=558560
· As part of simplifying the Azure Storage portfolio and improving performance, scalability, and cost efficiency, retirement of all General purpose v1 (GPv1) storage accounts has been announced.
· This also includes legacy Blob storage accounts.
· The core message of the announcement is the end of new account creation and encouragement to use modernized storage account types.
· Be sure to review the original source for the detailed migration scope and timeline.
What you get: Storage operations teams can clarify the decision criteria for whether to continue carrying legacy account types or consolidate on standard account types. It also creates opportunities for improvement in performance, cost, and operational simplification.
What to do now: Customers using storage should inventory GPv1 and legacy Blob accounts in their subscriptions, and review policies for new account creation as well as upgrade/migration plans.
Why now: Once storage accounts are standardized, it becomes much easier to streamline backup, security, and network policies afterward. The longer legacy account types remain, the greater the operational complexity and exception handling burden.
Source: https://azure.microsoft.com/updates?id=564441
· Compared with the previous announcement, the scope has been adjusted, and this retirement is now limited to Inbound NAT rule version 1 for Azure VMSS, that is, Inbound NAT Pools.
· Importantly, this is not a retirement covering all NAT rules, including those for single VMs.
· The affected configurations are those using legacy Inbound NAT Pools in Virtual Machine Scale Sets.
· To determine the exact impact, you need to review both Load Balancer and VMSS resource configurations together.
What you get: Network operations teams can more clearly identify “whether our environment is actually affected.” Rather than broad, unnecessary remediation, they can focus specifically on VMSS-based legacy NAT pool configurations.
What to do now: Teams using VMSS and Azure Load Balancer should check whether Inbound NAT Pools (v1) are in use and establish a transition plan to the current method.
Why now: A narrower retirement scope does not mean the impact has disappeared. If your environment still relies on VMSS-based remote access or operational port structures, your actual operations access model may need to change.
Source: https://azure.microsoft.com/updates?id=565482
· Azure VPN Client for Linux (Preview) is scheduled to retire on August 31, 2026.
· It has remained in Public Preview, and it was explicitly stated that there is no path to GA.
· The reason given for retirement is alignment of Azure networking services with current security and reliability standards.
· Linux users and operational environments need to evaluate alternative connection methods.
What you get: Organizations using Linux-based remote access can identify early the need to reduce Preview dependency and shift to a more stable VPN connectivity strategy. This is especially helpful for tightening policies around developer endpoints and operational jump hosts.
What to do now: Teams using Azure VPN Client (Preview) on Linux should investigate user and device status and create a migration plan to an alternative VPN connectivity method.
Why now: For end-user client transitions, user communication, deployment, and support models often take longer than the technical work itself. This Preview retirement notice also needs early action from a security standardization perspective.
Source: https://azure.microsoft.com/updates?id=565393
CREATE LOGIN ... FROM EXTERNAL PROVIDER) can be adopted in Azure SQL Database, and refine the existing SQL login/permission model