rss.livelink.threads-in-node

SAP + Microsoft 365: A Unified AI Experience That Works Where You Work

ssanjay27 — Mon, 09 Feb 2026 18:26:20 GMT

Coauthors: Angel Zhu, Senior Product Manager, M365 Copilot Agent Ecosystem and Christoph Ruehle, Principal Product Manager, Joule/SAP Business AI at SAP

We’ve all experienced it: you’re reviewing data, a message pings, an email comes in, and suddenly you’re juggling inboxes, chats, and screens just to finish one workflow. Those small interruptions feel routine — yet employees switch between apps over 1,200 times per day, adding up to weeks of lost productivity each year (estimate based on productivity and context-switching research, Harvard Business Review, 2022)

It’s not the work that’s slowing us down. It’s the constant friction of moving between where the data lives and where communication happens.

That’s why, building on SAP and Microsoft’s long-standing partnership, the new bi-directional integration between Joule and Microsoft 365 Copilot — now generally available — is designed to help people stay focused and get more done in the tools they already use.

By bringing SAP business context and Microsoft 365 collaboration together into a unified experience, work can now keep flowing wherever it starts. Customers are already seeing an impact.

“The integration of Microsoft 365 Copilot and Joule is central to Vodafone’s vision of creating an end-to-end, AI-enabled user experience,” said Andrea Schiavi, Vodafone, AI Product Lead.

"By unifying SAP business data with the Microsoft 365 productivity tools, we will create a seamless, intelligent workflow that accelerates decision making and boosts productivity. It will elevate our agentic assistant, AskHR, with shared context across apps so it can guide employees more effectively and resolve tasks faster.”

One AI that follows the work — not the other way around

When you’re in Microsoft 365, Copilot can access SAP processes and data through Joule.
When you’re in SAP, Joule can draw on information from Microsoft 365 through Copilot. No switching apps, just continuity.

For example, a finance manager working in Microsoft Excel can use Microsoft 365 Copilot and Joule to review a purchase order directly in the spreadsheet. Joule retrieves real-time SAP business data behind the scenes, enabling a confident decision — without opening another screen.

Later, reviewing that purchase order inside SAP, the same finance manager can ask Joule whether any recent emails or Teams messages contain information that should be considered before confirming the approval. Copilot brings that context into SAP automatically, so nothing gets missed.

Wherever the task begins, the right assistant shows up with the context needed to finish it.

How it works

In Microsoft 365 Copilot — within Teams, Word, PowerPoint, Excel, and OneNote: Joule to instantly access SAP insights and complete SAP tasks — with prompts, feedback, and citations.
In SAP apps: ask Joule your question; when Microsoft 365 context is relevant, Joule automatically routes to Microsoft 365 Copilot — bringing in data from email, Teams, SharePoint, or OneDrive.

No new interface to learn. The right assistant answers based on where you are. See Joule and Microsoft 365 Copilot integration in action!

Why this matters and why it’s here now

Work has evolved. SAP remains the trusted source of business truth, and Microsoft 365 is where collaboration happens. Bringing AI assistance across both environments simply helps people work the way they already do — with fewer interruptions, faster decisions, and the confidence that every action is grounded in the right business and communication context.

Get started today

To begin using the Joule and Microsoft 365 Copilot integration, start by downloading the SAP Joule app from Microsoft Marketplace and configuring the connection between SAP Cloud Identity Services on SAP BTP and Microsoft Entra.

You'll need Joule Base and a Microsoft 365 license to enable the integration. A Microsoft 365 Copilot license is required only when using Copilot skills within Joule.

To learn more about the Joule and Microsoft 365 Copilot integration, visit the SAP Discovery Center.

M-Series Sets a New Remote Storage on Mbv4 Demo

MingJiong_Zhang — Thu, 20 Nov 2025 21:44:41 GMT

As we released Mbv3 Series (Mbsv3 and Mbdsv3 Series)last year, demonstrating 650K IOPS and 10GBps throughput of remote disk storage with Premium SSD v2 and Ultra Disk on our 2-socket Azure Boost platform—already a major milestone for cloud performance, now, we’re thrilled to announce to the community another leap forward with the coming Standard_M304bs_4_v4 VM size from new Mbv4 Series on the 6th generation Intel® Xeon® Scalable processors, which delivers 20% higher IOPS and 60% more bandwidth throughput than Mbv3, reaching 780K IOPS and 16 GBps throughput on remote storage. Below is the demo result from our lab for this new VM series,

The new Mbv4 series, built on Azure Boost, delivers exceptional IOPS and throughput to power the most mission-critical enterprise workloads. As part of the Azure M-series portfolio, Mbv4 is designed for memory-intensive and storage–intensive workloads, making it an ideal choice for relational databases, large-scale analytics, and other mission-critical data workloads. The Standard_M304bs_4_v4 preview is coming soon. Stay tuned to this blog site for the latest updates and announcements.

Designing, Migrating and Managing a 15+1-Node SAP BW Scale-Out Landscape on Microsoft Azure

jitendrasingh — Thu, 04 Dec 2025 11:36:18 GMT

This blog outlines the implementation of SAP BW Scale-Out with 15+1 nodes using virtual machines on the Azure platform, representing one of the early and pioneering examples of SAP BW at this scale on a hyperscale public cloud.

It also highlights the technical considerations and work carried out by the Microsoft Customer & Partners team to understand and validate the performance characteristics of SAP BW, both on-premises and on Azure.

The underlying platform used memory-optimised Mv2-Series virtual machines to support large in-memory databases and demanding workloads. Specifically, the landscape comprised 16 × M416s_v2 (416 vCPU / 5.7 GiB memory), architected across:

Database nodes
(A)SCS nodes
Application server nodes

The customer had previously operated SAP HANA on-premises with 20 nodes [18+2 scale-out] and decided to move critical business systems—including SAP BW, SAP Warehouse Management and SAP IQ (Near-Line Storage)—to Azure as part of a data centre exit.

As part of this migration, the partner proposed the modernisation of selected business processes to take advantage of Azure-native architecture components and improve the end-user experience, including:

Increased system availability by deploying the SAP system across Azure zones within the region to enhance the availability SLA.
Automated failover of access points using Azure Standard Load Balancer.
Optimisation of the scale-out setup using Azure NetApp Files.

The move to Azure not only delivered high availability, it also improved how database connectivity is managed, removing the dependency on DNS for routing to the HANA database.

Implementing SAP BW Scale-Out for Very Large Databases (VLD) can be time-consuming, especially where there is limited prior experience at this scale. The architecture required careful review of critical design aspects, and the target design was tested in a lower environment to validate all technical tests. During this process, important insights were gained, particularly around Load Balancer configuration and the fine-tuning needed to align with customer business expectations.

1. Source Landscape: On-Premises (AS-IS)

The on-premises SAP BW landscape operated with 20 nodes [18+2] to support OLAP workloads.

For any migration programme, it is essential to understand the database growth pattern to inform a 3–5-year growth plan. Unlike on-premises environments, the cloud does not require pre-allocation of infrastructure for a fixed growth trajectory. However, understanding growth trends and resource usage remains vital to:

Design an appropriate target solution.
Avoid subsequent minor or major projects just to handle unexpected growth.

For this system:

The average peak consumption was assumed to be approximately 800,000 SAPS.
The overall measured peak reached around 993,480 SAPS.

Workspace is another critical factor when projecting memory usage and growth for SAP systems. Typically, customers estimate workspace at 50% or 70% on top of the data and code footprint.

2. Key AS-IS Information

2.1 User Load

Concurrent users must be taken into account, along with any expected changes as part of the migration roadmap. Additional capacity should be considered if significant changes in user load are anticipated on the target platform.

The User Activity view (diagram not shown here) illustrates how users interact with the system over time:

Total Users – total number of users who logged on during one week.
Active Users – users who performed more than 400 transaction steps in one week.

2.2 System Performance

Monitoring the size and growth of the HANA database is crucial for ongoing system stability and performance.

2.3 Log Throughput Requirement / Usage on the On-Premises System

One of the critical design considerations is the performance of the on-premises system, as this becomes the baseline for designing the target environment.

3. Target Architecture: 15+1 Scale-Out on Azure (To-Be)

The target architecture is based on SAP BW Scale-Out with 15+1 nodes in each Azure zone:

SAP BW Scale-Out 15+1 using M416s_v2 in Zone 1.
SAP BW Scale-Out 15+1 using M416s_v2 in Zone 2.

To provide a consistent access experience across zones:

A zone-redundant Standard Load Balancer is used to maintain a single point of access.
Two frontend IP addresses are configured, with two backend pools for Production and DR nodes respectively.

4. Key Target Design Consideration for Scale-Out

4.1 SAP HANA Cloud Measurement Tool (HCMT)

SAP mandates execution of the HANA Cloud Measurement Tool (HCMT) as part of validating the configuration.

4.2 Compute – SAP on Azure Certification

The Azure compute platform (hardware) is required to have a valid SAP HANA hardware certification at the point of deployment. The selected SKU must be listed in the Certified and Supported SAP HANA® Hardware Directory.

Microsoft Cloud offers multiple SKUs that are certified by SAP to run SAP and HANA workloads. The same directory maintains certified hardware SKUs across all providers. SAP HANA, as an in-memory database, must meet specific certification criteria to be supported by SAP. The Microsoft engineering team works closely with SAP to bring new SKUs into the list of Microsoft Cloud hardware supported for HANA workloads.

For HANA workloads, M-Series (Mv1 & Mv2) are preferred SKUs, though Microsoft also offers E-Series and HLI [HANA Large Instances], which are supported for HANA workloads.

In this design:

Compute: 16 × M416s_v2 in Zone 1 and 16 × M416s_v2 in Zone 2.

4.3 Network Considerations

Network configuration at both the OS and virtual network (VNET) layers plays a critical role in achieving the required throughput and latency between components. For Scale-Out, there must be additional focus on host-based routing and the selection of the right NIC for HSR (HANA System Replication).

The Load Balancer configuration is designed to maintain the same logical hostname for applications and third parties connecting to the database, regardless of the database location across zones.

There are key differences between Scale-Up and Scale-Out:

In Scale-Up, the entire database runs on a single VM/SKU.
In Scale-Out, the database is split and distributed across multiple VMs/SKUs.

The communication between VMs/SKUs in a scale-out configuration directly affects database performance. It is therefore highly recommended to have a dedicated NIC and subnet to support internode traffic.

Another key consideration is compute-to-storage communication. To ensure direct connectivity from compute to storage, host-based routing is recommended and is one of the design aspects to meet SAP HANA KPI targets during HCMT execution.

Different connection types can be summarised as:

Internode traffic (scale-out communication) – recommended to use a dedicated NIC and subnet.
Compute–storage traffic – should use host-based routing to reach storage directly.
Client connection / user traffic.
Additional traffic, depending on configuration, which can be merged with either client or internode traffic based on system requirements during peak periods and should be reviewed during performance and stress testing before go-live.

4.3.1 Network layout

Three subnets created:

One for Client Network (NIC)
One for Inter-Node communication & HSR
One for Storage Network (NIC)

Additionally, a delegated Azure NetApp Files (ANF) subnet.

4.4 Azure Standard Load Balancer with Scale-Out Design

A special requirement from the customer was to manage third-party connections to the HANA database across zones.

To ensure seamless connectivity from third-party systems regardless of the active zone:

An Azure Standard Load Balancer is configured in front of the scale-out nodes across zones.

This Load Balancer:

Handles connections to the HANA database.
Supports the DR failover scenario, maintaining connectivity across zones.

4.5 Storage Considerations

Storage selection is simplified by the fact that only Azure NetApp Files is supported for scale-out configurations with a standby node. Scale-out without a standby node provides more options.

In all cases, storage must be configured to achieve the required IOPS and throughput without driving cost up unnecessarily.

For scale-out with a standby node, Azure NetApp Files is the only supported storage as of June 2022. Alongside this, Azure NetApp Files provides several features that should be carefully evaluated in the target design.

4.5.1 ANF Storage Tier

Ultra / Premium tiers are used as appropriate.

4.5.2 ANF Features

Application Volume Group (AVG): The Application Volume Group for SAP HANA enables customers and partners to deploy all volumes required to install and operate an SAP HANA database according to best practices in a single, optimised workflow. It includes the use of Proximity Placement Group (PPG) with VMs to achieve automated, low-latency deployments.

Manual QoS: With manual QoS volumes, customers and partners do not need to overprovision volume quota to achieve higher throughput, because throughput can be assigned to each volume independently. Total available throughput is defined at the capacity pool level and depends on the size and type of storage.

Dynamic Tiering: Azure NetApp Files provides three performance tiers: Standard, Premium and Ultra. Dynamic Tiering allows customers and partners to use a higher service level for better performance or a lower service level for cost optimisation without waiting time.

ANF Files Backup: The ANF backup feature allows customers and partners to offload Azure NetApp Files snapshots to Azure Blob Storage in a fast and cost-effective way, further protecting data from accidental deletion.

4.5.3 Selected Layout

ANF Ultra tier selected for HANA data, log and shared mount points.
ANF Premium selected to host offline transaction log backups.
Azure Blob Storage used to store AzAcSnap HANA data snapshots and offline transaction log backups.

4.6 Backup and Restore Approach

Backup and restore runtime can be a critical blocker if it does not meet business RPO/RTO requirements.

With Azure NetApp Files, most customers implement the AzAcSnap tool to manage HANA database snapshots, followed by AzCopy to transfer snapshots to Blob Storage for long-term retention.

In this design:

AzAcSnap is defined as the primary backup, running every 6 hours.
The first backup is transferred to Blob Storage for long-term retention.
Transaction log backups run every 15 minutes and are written to an ANF Premium mount.
AzCopy jobs then transfer these backups to Blob for long-term retention.
A dedicated server is used to manage AzCopy transfers from ANF volumes to Blob Storage as a temporary measure until ANF Files backup is available in the required region.

4.6 Run Operations and Monitoring

Run, or Business As Usual (BAU), marks the transition from the migration programme to the support project. It is critical that monitoring and configuration are in place to capture alerts and collect sufficient logs for investigation during issue resolution.

Key elements include:

Proper configuration of monitoring and kdump to ensure logs and dumps are available to analyse unforeseen issues related to the OS or SKU.
Use of Zabbix together with Azure Monitor for Virtual Machines for ongoing monitoring.
Kdump configured and enabled on all VMs to capture critical information for troubleshooting unexpected issues.

5. New: Azure NetApp Files Flexible service level (2025 update)

Since this project was originally designed, Azure NetApp Files has introduced a new Flexible service level, which is particularly relevant for SAP BW and SAP HANA workloads on Azure.

5.1 What is the Flexible service level?

The Flexible service level is a new Azure NetApp Files throughput service level that decouples throughput from capacity. It is available for new manual QoS capacity pools. You configure pool throughput (MiB/s) and capacity (TiB) independently instead of being bound to a fixed MiB/s-per-TiB ratio.

This makes it easier to right-size storage for high-throughput, low-capacity workloads (for example, HANA log volumes) and high-capacity, moderate-throughput workloads (for example, BW cold data or shared file systems).

5.2 128 MiB/s baseline throughput at no extra charge

A key benefit of the Flexible service level is the included baseline throughput:

The minimum throughput you can assign to a Flexible capacity pool is 128 MiB/s, regardless of pool size.
The first 128 MiB/s of throughput is included in the service level—often referred to as the baseline throughput—and is available at no additional performance surcharge.

In practice, this means every Flexible capacity pool you create automatically includes 128 MiB/s of throughput, and you only pay for any additional throughput configured beyond that baseline.

5.3 Throughput scaling for demanding workloads

With Flexible service level, throughput can scale significantly. The maximum throughput is documented as up to 640 MiB/s per TiB per pool, with an upper bound defined as 5 × 128 MiB/s × pool size (TiB). Throughput can be increased when needed (for example, during peak loads or migration cutovers) and reduced later, subject to a documented cool-down period between downward adjustments.

This flexibility is especially useful for SAP BW and SAP HANA systems with variable peak and off-peak windows, and for migration phases where temporary higher throughput is required for data loads, initial syncs or cutovers, with the option to optimise cost afterwards.

6. Where to learn more

Service levels for Azure NetApp Files – detailed description of Standard, Premium, Ultra and Flexible service levels, including throughput formulas and examples

What’s new in Azure NetApp Files – latest feature announcements and regional availability updates

Service levels for Azure NetApp Files | Microsoft Learn

Azure NetApp Files solution architectures for SAP HANA – reference architectures and best practices for SAP HANA on ANF

Azure delivers the first cloud VM with Intel Xeon 6 and CXL memory - now in Private Preview

Elyse_Ge_Hylander — Thu, 20 Nov 2025 22:20:32 GMT

Intel released their new Intel Xeon 6 6500/6700 series processor with P-cores this year. Intel Xeon 6 processors provide performance and scalability by delivering outstanding performance for transactional and analytical workloads and provide scale-up capacities of up to 64TB of memory.

In addition, Intel Xeon 6 supports the new Compute Express Link (CXL) standard that enables memory expansion to accommodate larger data sets in a cost-effective manner. CXL Flat Memory Mode is a unique Intel Xeon 6 capability that enhances the ability to right-size the compute-to-memory ratio and improve scalability without sacrificing performance. This enhanced ability can help run SAP S/4HANA more efficiently and help enable greater flexibility for configurations so they can better align with business needs and improve the total cost of ownership.

In collaboration with SAP and Intel, Microsoft is delighted to announce private preview of CXL technology on Azure M-series family of VMs. We believe that, when combined with advancements in the new Intel Xeon 6 processors, it can tackle the challenges of managing the growing volume of data in SAP software, meet the increased demand for faster compute performance and reduce overall TCO.

Stefan Bäuerle, SVP, Head of BTP, HANA & Persistency at SAP noted:
“Intel Xeon 6 helps deliver system scalability to support the growing demand for high-performance computing and growing database capacity among SAP customers.”

Elyse Ge Hylander, Senior Director, Azure SAP Compute stated:
“At Microsoft, we are continually exploring new technological innovations to improve our customer experience. We are thrilled about the potential of Intel’s new Xeon 6 processors with CXL and Flat Memory Mode. This is a big step forward to deliver the next-level performance, reliability, and scalability to meet the growing demands of our customers.”

Bill Pearson, Vice President of Data Center and Artificial Intelligence at Intel states:
“Intel Xeon 6 represents a significant advancement for Intel, opening up exciting business opportunities to strengthen our collaboration with Microsoft Azure and SAP. The innovative instance architecture featuring CXL Flat Memory Mode is designed to enhance cost efficiency and performance optimization for SAP software and SAP customers.”

If you are interested in joining our CXL private preview in Azure, contact Mseries_CXL_Preview@microsoft.com

###

Co-author: Phyllis Ng - Senior Director of Hardware Strategic Planning (Memory and Storage) - Microsoft

SAP on Azure Product Announcements Summary – SAP TechEd 2025

Hiren_Shah_Azure — Tue, 04 Nov 2025 16:00:00 GMT

Today at SAP TechEd 2025, we are excited to share the next evolution of the Microsoft-SAP partnership. Building on decades of collaboration, we continue to advance RISE with SAP on Azure and deepen integrations with SAP S/4HANA Cloud public edition. Our latest innovations deliver enhanced security for SAP and non-SAP workloads, while unified analytics and AI-driven Copilot experiences empower customers to make smarter decisions.

These advancements are designed to help customers accelerate their digital transformation, drive operational excellence, and unlock new business value.

Customer Spotlight: Medline

Medline’s SAP transformation on Microsoft Azure is fueling new levels of agility and intelligence across its operations with SAP on Azure. The company’s migration boosted system resilience, improved key SAP workload transaction times by more than 80% and enabled real-time collaboration and predictive analytics for clinicians and business users - laying the groundwork to extend these insights through Copilot and Azure AI.

“When we partnered on the migration, it ushered in a completely new way in which Microsoft and Medline work together. It became a partnership, with the cloud migration becoming a stepping stone to bigger and brighter, more business-outcome–driven engagements.”

— Jason Kaley, SVP, IT Operations & Architecture, Medline

Customer Spotlight: Commerz Real

Commerz Real, a German financial services firm specializing in real estate, infrastructure, and leasing, modernized its SAP infrastructure by migrating its complete SAP landscape to SAP RISE on Azure. Built to address stringent regulatory, security, and performance demands, the platform delivers high scalability, real-time monitoring, and faster, more stable operations.

“The decision to use Microsoft Azure was a deliberate one. In the past, security concerns and strict regulatory requirements kept us from moving SAP to the cloud. Today we say: If you don’t do that, you won’t survive in the market.”

— Nadine Felderer, Head of SAP Services, Commerz Real

We are pleased to announce additional SAP with Microsoft product updates and details to further help customers innovate on the most trusted cloud for SAP.

Bi-directional Agent to Agent communication between Microsoft Copilot and SAP Joule. Enterprise-ready SAP API enablement for AI through MCP in Azure API Management.
General Availability of our agentless Sentinel for SAP data connector with significantly simpler onboarding through SAP Integration Suite. Ready for the future.
SAP released S/4HANA Cloud public edition for our Sentinel Solution for SAP.
Microsoft Entra ID advances SAP identity governance with new OAuth 2.0 support, SAP IAG integration preview, and expanded SAP Access Control migration for unified, secure access.
Advanced support for High Availability with SAP ASE (Sybase) database backup on Azure Backup.
SAP Deployment Automation Framework now supports highly available scale-out architectures with HANA System Replication for large-scale resilient configurations.
SAP Testing Automation Framework enhances high availability testing with offline Pacemaker cluster validation for RHEL/SUSE, and native Linux-based validation tools quality checks
Enhanced SAP Inventory and Observability Dashboard to reduce operational risk, and supports production-ready SAP systems, along with a customizable Windows Quality Checks PowerShell template.

Let's dive into the summary details of product updates and services.

Extend and Innovate and Secure

Copilot Studio and SAP Joule

Since the release of the Joule and Copilot integration earlier this year, we have seen great interest and adoption with customers and partners. The Joule as a host integration is planned to be released later this year. Integrating Joule with Microsoft 365 Copilot | SAP Help Portal

For customers on their journey towards RISE and GROW, we also worked on the Azure API Management team to enable the exposure of SAP OData Services from your SAP Systems as an MCP server which then can be consumed in Copilot using Microsoft Copilot Studio. This enables the interaction of end-users with their SAP system based on any OData services. For more details, check out Expose REST API in API Management as MCP server and Copilot + SAP: Azure API Management, MCP and SAP OData.

To simplify the integration and help customers and partners get started faster, we are releasing preconfigured Copilot Studio Agent that can orchestrate over other agents like SAP, Fabric and Microsoft 365. Customers can use these agents out of the box or use them as a foundation to extend and build their own Copilot Agents.

Microsoft Security for SAP

Security is being reengineered for the AI era - moving beyond static, rule-bound controls and after-the-fact response toward platform-led, machine-speed defense.

Attackers think in graphs - Microsoft does too. We are bringing relationship-aware context to Microsoft Security suite - so defenders and AI can see connections, understand the impact of a potential compromise (blast radius), and act faster across pre-breach and post-breach scenarios.

SAP S/4HANA Cloud public edition Add-on for Microsoft Sentinel for SAP (preview): Enables deep, native integration of SAP telemetry with Sentinel, bringing advanced threat detection, investigation, and response to SAP workloads running in the cloud.
Microsoft Sentinel for SAP Agentless Data Connector: Now generally available, the agentless connector significantly simplifies deployment while delivering secure, high-fidelity ingestion of SAP audit and application logs into Sentinel.
Expanded Security Guidance: Enhanced guidance for Microsoft Defender, Ransomware Protection, and Cyber Defense for SAP, helping customers implement best practices for hardening SAP environments and responding to evolving threats.
Cost-Efficient Long-Term Log Storage: Organizations can now take advantage of Sentinel Data Lake to retain SAP logs for 12 years at scale for compliance (NIS2, DORA) and forensic use cases - at a fraction of traditional storage costs.
Purview shipping most requested features updates for our existing SAP connectors (SNC mode support in preview, CDS view support, and scoped metadata scanning) and a new connector for BW/4HANA.

SAP has reiterated end of maintenance for SAP Identity Management (SAP IDM) by end of 2027 and is collaborating with Microsoft so customers can migrate identity scenarios to Microsoft Entra ID as the recommended successor approach.

Provisioning backbone in place: Microsoft Entra released new features for the built‑in connector for SAP Cloud Identity Services (CIS) to support authentication with OAuth 2.0, and provisioning of groups to streamline authorization management in downstream SAP targets like SAP S/4HANA and SAP BTP, enabling HR‑driven, end‑to‑end identity lifecycles.
Private Preview: Microsoft Entra Integration with SAP IAG: The private preview for Microsoft Entra integration with SAP Identity Access Governance (IAG) is now underway. Selected customers are testing Entra ID Governance access packages that include SAP IAG roles as resources, routing of access approvals through SAP IAG, and provisioning of roles across both systems. Sign-Up here.
Enhanced Integration Scope with SAP Access Control (AC): Driven by direct customer feedback, Microsoft and SAP are expanding the migration and integration scope to include SAP Access Control (AC). This enhancement will enable comprehensive access management, risk analysis, and policy enforcement on-premises, leveraging Microsoft Entra’s governance capabilities for improved security and compliance.

Together, these innovations give customers end-to-end visibility and protection across SAP landscapes—spanning public cloud, hybrid, and on-premises deployments.

SAP on Azure Software Products and Services

Azure Backup for SAP

We are committed to expanding backup support for additional SAP workloads. Following the general availability of ASE backup, we have further enhanced its capabilities with the introduction of high availability configuration support. This enhancement delivers automatic backup support for SAP systems setup with Replication Server, ensuring seamless protection after failover or failback events without the need for manual intervention. As a result, users benefit from immediate and continuous data protection, along with a simplified restore process using a single backup chain.

We have expanded our Snapshot backup capability for SAP HANA by adding Recovery Services Vault support. This will help customers store their snapshot backups with long term retention, while gaining protection from Ransomware attacks. Vault support brings in capabilities like immutability, soft-delete enablement, multi-user-authorization to further safeguard the data.

We have also launched the preview for “Scale-out” support configurations for SAP HANA streaming backup, expanding our overall topology support.

SAP Deployment Automation Framework

We are releasing updates to the SAP Deployment Automation Framework (SDAF) and SAP Testing Automation Framework (STAF) that expand testing coverage, improve reliability, and provide additional deployment flexibility for SAP environments on Azure.

SAP Deployment Automation Framework (SDAF)

SDAF deployment and configuration scenarios now include scale-out architectures with HANA System Replication (HSR). This enhancement addresses resiliency requirements for large-scale deployments requiring multi-node scale-out configurations with built-in replication capabilities.

SDAF now supports GitHub Actions in addition to existing deployment methods including Azure DevOps pipelines, CLI scripts, and the WebApp interface. Organizations using GitHub for source control and infrastructure management can now deploy and manage SAP environments using their existing workflows and tooling preferences.

SAP Testing Automation Framework (STAF)

STAF now supports offline validation for SAP Pacemaker clusters. This capability enables testing of resource agent failover mechanisms without executing live cluster operations, reducing risk during validation cycles and allowing for pre-deployment verification of high availability configurations.

The high availability testing suite has been updated to include SAPHanaSr-ANGI tests, ensuring compatibility with SUSE Linux Enterprise Server 15 and SAP HANA 2.0 SP5 environments. This update addresses the requirements of organizations running current SAP HANA releases on modern SUSE distributions.

Configuration checks in preview, represents a rewrite of the open-source Quality Checks tool, now integrated as a native capability within STAF. This tool validates SAP on Azure installations against Microsoft reference architecture and configuration guidance.

Azure Center and Azure Monitor for SAP Solutions

We are pleased to share that Azure Center for SAP solutions (ACSS) is now available in Italy North, providing end-to-end SAP workload management to more customers across Europe.

Additionally, Azure Monitor for SAP solutions (AMS) is now available in Italy North. AMS continues to help SAP customers reliably monitor their mission-critical workloads on Azure with comprehensive insights.

Get started:

Azure Center for SAP solutions Tools and Frameworks

We have refreshed our SAP on Azure Well-Architected Framework and the accompanying SAP on Azure Assessment to reflect the latest platform guidance. The update aligns with recent Azure innovations—including VMSS Flex, Premium SSD v2, Capacity Reservation Groups, Mv3-series, and NVMe-based SKUs—so architects and admins can plan and deploy with current best practices. The assessment is also now surfaced on the main Assessments hub for easier access and can be used as a repeatable checkpoint throughout your SAP deployment lifecycle.

Quality Checks (PowerShell) for windows: We have published a lightweight, read-only script for customers running SAP on Windows and SQL Server on Microsoft Azure. It performs post-provisioning health checks and outputs a color-coded HTML report plus JSON. Use it as a baseline template—customize the thresholds to your environment, and feel free to contribute enhancements to cover your configuration requirements.

Observability Dashboard: Based on customer feedback, we have expanded the dashboard to surface design-impacting signals for running specialized workloads on Azure. It now offers Overview, Security, Networking, and Inventory views, plus extended reports for managers and hands-on engineers. Updates make it easier to review VM redundancy, spot orphaned resources, see Capacity Reservation Groups with their associated VMs in the primary region, and count Public IPs on the Basic SKU—helping you stay on top of infrastructure hygiene and avoid unsupported configurations.

SAP + Microsoft Co-Innovations

Microsoft and SAP are always working on new solutions to help our customers adapt and grow their businesses in several areas including AI, Business Suite, Data, Cloud ERP, Security, SAP BTP, among others. Recently, we started a new era of Agentic AIOps collaboration between SAP and Microsoft with fully orchestrated multi-agent ecosystem for mission critical workload. Please check out this blog to learn more.

Evolving SAP Testing on Azure: What’s New in the SAP Testing Automation Framework

DevanshJain — Tue, 04 Nov 2025 06:00:00 GMT

We're announcing the general availability (GA) of the SAP Testing Automation Framework (STAF), an open-source orchestration tool that automates validation of SAP deployments on Microsoft Azure.

With this release, High Availability (HA) function testing is now available for SAP HANA scale-up databases and SAP Central Services (ASCS/ERS) running in two-node Pacemaker clusters. In addition, we're introducing Configuration Checks (in preview) that helps in validating SAP system configurations against Azure best practices across infrastructure, storage, OS parameters, and cluster resources.

How STAF Works?

STAF uses a hub-and-spoke architecture where a centralized management server orchestrates validation across your SAP landscape using ansible. The framework code resides on a management server that connects remotely to SAP systems via SSH. System-specific details (hostnames, credentials, topology) are stored in configuration files on the management server or in source-controlled configuration repository (in case of SDAF). This separation means no agents or framework components need to be installed on SAP virtual machines.

Setting up workspace configurations is a one-time activity. Once defined, the same configuration can be used repeatedly for pre-go-live validation, change verification, or periodic compliance audits without reconfiguration.

High Availability Functional Testing

High Availability functional testing executes controlled failure scenarios to verify that Pacemaker clusters, HANA System Replication, and SAP Central Services respond correctly when failures occur. Each test follows a pattern: capture baseline state, inject failure, monitor cluster reaction, validate failover, and restore to stable state.

Failure Scenarios Included

HANA Database: The functional test cases include Indexserver kill, network isolation, node crashes, storage freezes (in case of ANF filesystem), SBD fencing events etc. These test cases are part of the guidance outlined in the official document. 
SAP Central Services: The function test cases include ASCS/ERS process termination, message server failures, network isolation, and planned resource migration etc. These test cases are part of the guidance outlined in the official document.

Key Metrics Captured

For every test, the framework records:

Failure detection time: Duration from failure injection to Pacemaker detecting the issue through resource agent monitor operations.
Fencing duration: Time from failure detection to successful node isolation.
Failover completion time: End-to-end duration from failure injection to full-service availability on the secondary node. For HANA, this includes takeover decision, log replay, and indexserver startup. For ASCS/ERS, it includes enqueue table replication and service restart.

Reports include pass/fail status, detailed timelines with millisecond-level precision, diagnostic logs for troubleshooting failed scenarios, and execution logs for troubleshooting framework failures.

Offline Validation of High Availability Configuration

Offline validation in STAF enables assessment of SAP HANA and Central Services high availability cluster configurations without requiring a live SSH connection to production systems. By comparing exported cluster information base (CIB) XML files from each node with best practices, STAF delivers non-intrusive validation, making it ideal for environments with restricted connectivity. To learn more about setup and usage, check out the documentation here.

Configuration Checks (Preview)

Configuration checks provide read-only validation of SAP system settings against documented Azure best practices and SAP Notes. The framework executes Azure infrastructure validations using Azure CLI from the management server, while OS and SAP-level checks use SSH connections to target systems. Integrating data from the management server and SAP virtual machine inspections enable comprehensive validation of the infrastructure deployed to run SAP systems.

STAF automates validation of SAP infrastructure on Azure by checking VM, storage, and network configurations using Azure CLI, and ensures compliance with best practices for HANA and Azure Files/ANF. It also verifies OS/kernel parameters, SAP profile settings, high availability cluster configurations, and database-specific settings for both HANA and Db2, providing a comprehensive compliance check across all critical system layers.

Findings are categorized as Passed, Failed, Critical, Warning, or Informational with reference links to SAP Notes and Azure documentation for remediation.

Getting Started with STAF

STAF is fully open source, available on GitHub, providing complete transparency into test logic, Ansible playbooks, and Python modules. The repository includes comprehensive setup documentation, sample workspace configurations.

Setup Options

For standalone SAP systems, follow the Setup Guide to configure a management server with the framework code and workspace definitions.

For environments already using SAP Deployment Automation Framework (SDAF), STAF integrates seamlessly into existing pipelines via the SDAF Integration Guide.

The framework supports SLES and RHEL distributions across multiple HA configurations: HANA scale-up, SAP Central Services with ENSA1/ENSA2, Azure Fence Agent or SBD-based fencing, and supports storage options including Azure Managed Disks, Azure Files, and Azure NetApp Files. For SLES environments, both SAPHanaSR and SAPHanaSR-angi topologies are supported.

Community and Contributions

Contributions are welcome. Whether it's reporting issues, suggesting new test scenarios, or submitting pull requests, community feedback helps improve the framework for all SAP on Azure users. Visit the GitHub repository to explore the code, review existing issues, or open new ones. For questions or discussions, engage through GitHub Issues.

Start validating SAP systems today and ensure clusters are ready when it matters most.

SAP Business Data Cloud Now Available on Microsoft Azure

Hiren_Shah_Azure — Thu, 09 Oct 2025 23:08:48 GMT

We’re thrilled to announce that SAP Business Data Cloud (SAP BDC) including SAP Databricks is now available on Microsoft Azure marking a major milestone in our strategic partnership with SAP and Databricks and our commitment to empowering customers with cutting-edge Data & AI capabilities.

SAP BDC is a fully managed SaaS solution designed to unify, govern, and activate SAP and third-party data for advanced analytics and AI-driven decision-making. Customers can now deploy SAP BDC on Azure in US East, US West and Europe West, with additional regions coming soon, and unlock transformative insights from their enterprise data with the scale, security, and performance of Microsoft’s trusted cloud platform.

Why SAP BDC on Azure Is a Game-Changer for Data & AI

Deploying SAP BDC on Azure enables organizations to accelerate their Data & AI initiatives by modernizing their SAP Business Warehouse systems and leveraging a modern data architecture that includes SAP HANA Cloud, data lake files and connectivity to Microsoft technology. Whether it’s building AI-powered intelligent applications, enabling semantically rich data products, or driving predictive analytics, SAP BDC on Azure provides the foundation for scalable, secure, and context-rich decision-making.
Running SAP BDC workloads on Microsoft Azure unlocks the full potential of enterprise data by integrating SAP systems with non-SAP data using Microsoft’s powerful Data & AI services - enabling customers to build intelligent applications grounded in critical business context.

Why Azure is an Ideal Platform for Running SAP BDC

Microsoft Azure stands out as a leading cloud platform for hosting SAP solutions, including SAP BDC. Azure’s global infrastructure, high-performance networking, and powerful Data & AI capabilities make it an ideal foundation for large-scale SAP workloads. When organizations face complex data environments and need seamless interoperability across tools, Azure’s resilient backbone and enterprise-grade services provide the scalability and reliability essential for building a robust SAP data architecture.

Under the Hood: SAP Databricks in SAP BDC is Powered by Azure Databricks

A key differentiator of SAP BDC on Azure is that SAP Databricks, a core component of BDC, runs on Azure Databricks—Microsoft’s first-party service.

Azure Databricks is a fully managed first party service making Microsoft Azure the optimal cloud for running Databricks workloads. It uniquely offers:

Native integration with Microsoft Entra ID for seamless access control.
Optimized performance with Power BI, delivering unmatched analytics speed.
Enterprise-grade security and compliance, inherent to Azure’s first-party services.
Joint engineering and unified support from Microsoft and Databricks.
Zero-copy data sharing between SAP BDC and Azure Databricks, enabling frictionless collaboration across platforms.

This deep integration ensures that customers benefit from the full power of Azure’s AI, analytics, and governance capabilities while running SAP workloads.

Expanding Global Reach: What’s Next

While SAP BDC is now live in three Azure regions US East, US West and Europe - we’re just getting started. Over the next few months, availability will expand to additional Azure regions such as Brazil and Canada.

For the remaining regions, a continuously updated roadmap can be found on the SAP Roadmap Explorer website

Final Thoughts

This launch reinforces Microsoft Azure’s longstanding partnership with SAP, backed by over 30 years of trusted partnership and co-innovation. With SAP BDC now available on Azure, customers can confidently modernize their data estate, unlock AI-driven insights, and drive business transformation at scale.

Stay tuned as we continue to expand availability and bring even more Data & AI innovations to our joint customers over the next few months.

Announcing Public Preview for Business Process Solutions

Hiren_Shah_Azure — Tue, 16 Sep 2025 08:30:00 GMT

In today’s AI powered enterprises, success hinges on access to reliable, unified business information. Whether you are deploying AI-augmented workflows or fully autonomous agentic solutions, one thing is clear: trusted, consistent data is the fuel that drives intelligent outcomes. Yet in many organizations, data remains fragmented across best of breed applications – creating blind spots in cross-functional processes and throwing roadblocks in the path of automation. Microsoft is dedicated to tackle these challenges, delivering a unified data foundation that accelerates AI adoption, simplifies automation and reduces risk – empowering businesses to unlock the full potential of unified data analytics and agentic intelligence.

Our new solution offers cross-functional insights across previously siloed environments and includes:

Prebuilt data models for enterprise business applications in Microsoft Fabric
Source system data mappings and transformations
Prebuilt dashboards and reports in Power BI
Prebuilt AI Agents in Copilot Studio (coming soon)
Integrated Security and Compliance

By unifying Microsoft’s Fabric and AI solutions we can rapidly accelerate transformation and derisk AI rollout through repeatable, reliable, prebuilt solutions.

Functional Scope

Our new solution currently supports a set of business applications and functional areas, enabling organizations to break down silos and drive actionable insights across their core processes. The platform covers key domains such as:

Finance: Delivers a comprehensive view of financial performance, integrating data from general ledger, accounts receivable, and accounts payable systems. This enables finance teams to analyze trends, monitor compliance, and optimize cash flow management all from within Power BI. The associated Copilot agent provides not only access to this data via natural language but will also enable financial postings.
Sales: Provides a complete perspective on customers’ opportunity to cash journeys, from initial opportunity through invoicing and payment via Power BI reports and dashboards. The associated Copilot agent can help improve revenue forecasting, by connecting structured ERP and CRM data with unstructured data from Microsoft 365, also tracking sales pipeline health and identify bottlenecks.
Procurement: Supports strategic procurement and supplier management, consolidating purchase orders, goods receipts, and vendor invoicing data into a complete spend dashboard. This empowers procurement teams to optimize sourcing strategies, manage supplier risk, and control spend.
Manufacturing: (coming soon): Will extend coverage to manufacturing and production processes, enabling organizations to optimize resource allocation and monitor production efficiency.

Each item within Business Process Solutions is delivered as a complete, business-ready offering. These models are thoughtfully designed to ensure that organizations can move seamlessly from raw data to actionable execution. Key features include:

Facts and Dimensions: Each model is structured to capture both transactional details (facts) and contextual information (dimensions), supporting granular analysis and robust reporting across business processes.
Transformations: Built-in transformations automatically prepare data for reporting and analytics, making it compatible with Microsoft Fabric. For example, when a business user needs to compare sales results from Europe, Asia, and North America, the solution transformations handle currency conversion behind the scenes. This ensures that results are consistent across regions, making analysis straightforward and reliable—without the need for manual intervention or complex configuration.
Insight to Action: Customers will be able to leverage prebuilt Copilot Agents within Business Process Solutions to turn insight into action. These agents are deeply integrated not only with Microsoft Fabric and Microsoft Teams, but also connected source applications, enabling users to take direct, contextual actions across systems based on real-time insights. By connecting unstructured data sources such as emails, chats, and documents from Microsoft 365 apps, the agents can provide a holistic and contextualized view to support smarter decisions.

With embedded triggers and intelligent agents, automated responses could be initiated based on new insights -- streamlining decision-making and enabling proactive, data-driven operations. Ultimately, this will empower teams to not just understand what is happening on a wholistic level, but to also take faster and smarter actions, and with greater confidence.

Authorizations: Data models are tailored to respect organizational security and access policies, ensuring that sensitive information is protected and only accessible to authorized users. The same user credential principles apply to the Copilot agents when interacting with/updating the source system in the user-context.

Behind the scenes, the solution automatically provisions the required objects and infrastructure to build the data warehouse, removing the usual complexity of bringing data together. It guarantees consistency and reliability, so organizations can focus on extracting value from their data rather than managing technical details. This reliable data foundation serves as one of the key informants of the agentic business processes.

Accelerated Insights with Prebuilt Analytics

Building on these robust data models, Business Process Solutions offer a suite of prebuilt Power BI reports tailored to common business processes. These reports provide immediate access to key metrics and trends, such as financial performance, sales effectiveness, and procurement efficiency.

Designed for rapid deployment, they allow organizations to:

Start analyzing data from day one, without lengthy setup or customization.
Adapt existing reports for your organization’s exact business needs.
Demonstrate best practices for leveraging data models in analytics and decision-making.

This approach accelerates time-to-value and also empowers users to explore new analytical scenarios and drive continuous improvement.

Extensibility and Customization

Every organization is unique and our new solution is designed to support this, allowing you to adapt analytics and data models to fit your specific processes and requirements. You can customize scope items, bring in your own tables and views, integrate new data sources as your business evolves, and combine data across Microsoft Fabric for deeper insights.

Similarly, the associated agents will be customizable from Copilot Studio to adapt to your specific Enterprise apps configuration.

This flexibility ensures that, no matter how your organization operates, Business Process Solutions helps you unlock the full value of your data.

Data integration

Business Process Solutions uses the same connectivity options as Microsoft Fabric and Copilot Studio but goes further by embedding best practices that make integration simpler and more effective. We recognize that no single pattern can address the diverse needs of all business applications. We also understand that many businesses have already invested in data extraction tools, which is why our solution supports a wide range of options, from native connectivity to third-party options that bring specialized capabilities to the table. With Business Process Solutions we ensure data can be interacted with in a reliable and high-performant way, whether working with massive volumes or complex data structures.

Getting started

If your organization is ready to unlock the value of unified analytics, getting started is simple. Just send us a request using the form at: https://aka.ms/JoinBusAnalyticsPreview. Our team will guide you through the next steps and help you begin your journey.

New Mbv3 Size, Standard_M416bs_v3, General Availability

MingJiong_Zhang — Fri, 05 Sep 2025 01:20:32 GMT

As we launched memory-optimized M-series family with high remote storage performance, Mb Family, in Sep ’24, there’s been strong demand for more computing optimization, especially from healthcare organizations. Today, we're excited to expand the Mbv3 portfolio to better support large-scale, mission-critical database workloads—especially for healthcare organizations operating EHR (Electronic Health Records) database on Azure. We’re pleased to announce the general availability of the new Mbv3 size, Standard_M416bs_v3.

This new SKU offers increased vCPU cores along with enhanced memory and remote storage performance, making it ideal for high-performance database scenarios that require consistent throughput, scalability, and reliability.

Key features

The Mbv3 series are based on the 4th generation Intel® Xeon® Scalable processors, scale for workloads up to 4TB, and deliver with NVMe interface for higher remote disk storage performance.
This VM size, newly added to the Mbv3 series, Standard_M416bs_v3, offers 416 vCPU which is over 2x the vCPU of the largest launched Mbv3 VM.
The Standard_M416bs_v3 offers high remote storage performance with up to 550,000 IOPS and 10 GBps of remote disk storage bandwidth.
The increased remote storage performance of Mbv3 series is ideal for storage throughput-intensive workloads such as relational databases and data analytics applications.

Mbsv3 series (NVMe)

Size	vCPU	Memory: GiB	Max data disks	Max uncached Premium SSD: IOPS/Throughput(MBps)	Max uncached Ultra Disk and Premium SSD V2 disk: IOPS/Throughput(MBps)	Max NICs	Max network bandwidth (Mbps)
Standard_M416bs_v3	416	3800	64	240,000/8,000	550,000/10,000	8	50,000

Regional Availability and Pricing

The VMs are now available in Central US, East US 2, East US, West US 2.

For pricing details, please refer to Pricing Calculator | Microsoft Azure

Backup SAP Oracle Databases Using Azure VM Backup Snapshots

Vamshi Polasa — Mon, 30 Jun 2025 20:35:42 GMT

This blog article provides a comprehensive step-by-step guide for backing up SAP Oracle databases using Azure VM backup snapshots, ensuring data safety and integrity.

Installation of CIFS Utilities: The process begins with the installation of cifs-utils on Oracle Linux, which is the recommended OS for running Oracle databases in the cloud.
Setting Up Environment Variables: Users are instructed to define necessary environment variables for resource group and storage account names.
Creating SMB Credentials: The guide explains how to create a folder for SMB credentials and retrieve the storage account key, emphasizing the need for appropriate permissions.
Mounting SMB File Share: Instructions are provided for checking the accessibility of the storage account and mounting the SMB file share, which will serve as a backup location for archived logs.
Preparing Oracle Database for Backup:Users must place the Oracle database in hot backup mode to ensure a consistent backup while allowing ongoing transactions.
Initiating Snapshot Backup: Once the VM backup is configured, users can initiate a snapshot backup to capture the state of the virtual machine, including the Oracle database.
Restoration Process: The document outlines the steps for restoring the Oracle database from the backup, including updating IP addresses and starting the database listener.
Final Steps and Verification: Users are encouraged to verify the configuration and ensure that all necessary backups are completed successfully, including the SMB file share.

Moving Linux and Windows from SCSI to NVMe with one easy command

phleiten — Mon, 30 Jun 2025 18:08:43 GMT

Introduction

In the ever-evolving world of cloud computing, maximizing performance and efficiency is crucial for businesses leveraging virtual machines (VMs) on platforms like Microsoft Azure, especially for high I/O workloads like SAP on Azure or database applications. One significant upgrade that can yield substantial performance improvements is converting your Azure VM from a SCSI (Small Computer System Interface) disk setup to NVMe (Non-Volatile Memory Express) using Azure Boost. This blog post will guide you through the process of making this conversion and explore the numerous advantages of NVMe over SCSI.

In previous posts you had to prepare the OS yourself and it was a complex process for Linux and Windows.

Now you can move to NVMe with just one simple easy command and the script will take care about everything including the preparation of your operating system.

Advantages of Azure Boost

Azure Boost is a powerful enhancement tool for Azure VMs, offering the following advantages:

Accelerated Disk Performance: Azure Boost optimizes disk I/O operations, significantly increasing the speed and efficiency of your VM's storage.
Seamless Integration: Easily integrates with existing Azure infrastructure, allowing for a smooth transition and immediate performance benefits.
Cost-Effective Optimization: By enhancing the performance of existing VMs, Azure Boost helps reduce the need for more expensive hardware upgrades or additional resources.

What is changing for your VM?

Changing the host interface from SCSI to NVMe will not change the remote storage (OS disk or data disks), but change the way the operating systems sees the disks. The way the devices are shown depends on the varios VM size with v6 SKUs now also having up to 4 temporary disks using NVMe.

	SCSI enabled VM	NVMe enabled VM (v5 and Mv3)	NVMe enabled v6
OS disk	/dev/sda	/dev/nvme0n1	/dev/nvme0n1
Temp Disk	/dev/sdb	/dev/sda	/dev/nvme1n1
First Data Disk	/dev/sdc	/dev/nvme0n2	/dev/nvme0n2

In the following sections, we'll provide a step-by-step guide to converting your Azure VM from SCSI to NVMe using Azure Boost, ensuring you can take full advantage of these performance improvements and maintain a competitive edge in the cloud computing landscape.

Preparing your virtual machine (VM) from SCSI to NVMe

To migrate from SCSI to NVMe and benefit from higher performance some prerequisites need to be in place:

Your Azure VM Generation needs to be V2, you can check it using e.g. the portal on your VM
Check VM generation on Azure Portal
Windows
1. On Windows 3rdparty software like Antivirus can influence the behavior after the migration, if you see a bluescreen please convert back to SCSI and try disabling your Antivirus/Security solution
2. When you run e.g. a v6 VM you can get up to 4 tempdisks, all of them will be RAW and not preformated with NTFS
Linux
1. Previously you were able to identify the Data Disks using LUN IDs in /dev/disk/azure/scsi1/lunX, as we migrate to NVMe those udev rules are not valid anymore. You can install the azure-vm-utils package or manually deploy a udev rule available on GitHub
2. When you run e.g. a v6 VM you can get up to 4 tempdisks, all of them will be RAW, you can use e.g. cloud-init to run initializtion of those disks everytime the operating system starts

Conversion from VMs with tempdisk (e.g. Standard_D4ds_v5) to Intel or AMD v6 SKUs (e.g. Standard_D4ds_v6) is currently not supported. The only possible migration is through disk snapshots.

You can convert VMs without tempdisk (e.g. Standard_D4s_v5) to v6 SKUs.

Prepare your environment (required for local PowerShell)

When running local PowerShell you need to make sure to have all the requirements installed and configured

Set-ExecutionPolicy Unrestricted

Install PowerShell modules for Azure

Install-Module Az -Force

Download the script:

Invoke-WebRequest -Uri "https://raw.githubusercontent.com/Azure/SAP-on-Azure-Scripts-and-Utilities/refs/heads/main/Azure-NVMe-Utils/Azure-NVMe-Conversion.ps1" -OutFile "Azure-NVMe-Conversion.ps1"

Logon to Azure and select the correct subscription

Connect-AzAccount Select-azsubscription -Subscription [Your-Subscription-Id]

Migrate your VM

You can always revert the migration back to SCSI

To migrate your VM you need to know some parameters

ResourceGroupName of the VM you want to convert
VMName of the VM you want to convert
NewControllerType will be SCSI or NVMe
VMSize is the new VM SKU, can also be the same SKU if it supports both Controller Types

Optional Parameters:

StartVM automatically starts withe VM after the migration
WriteLogFile stores the output in a local file
IgnoreSKUCheck does not check if the required VM Size is available in the region/zone
FixOperatingSystemSettings automatically prepares your Windows or Linux system using Azure RunCommands
IgnoreOSCheck does not run the OS check, the VM can be shutdown, you need to make sure your VM is prepared

Sample Command and Output

PS /home/philipp> ./NVMe-Conversion.ps1 -ResourceGroupName testrg -VMName testvm -NewControllerType NVMe -VMSize Standard_E4bds_v5 -StartVM -FixOperatingSystemSettings 00:00 - INFO - Starting script Azure-NVMe-Conversion.ps1 00:00 - INFO - Script started at 06/27/2025 15:41:39 00:00 - INFO - Script version: 2025062704 00:00 - INFO - Script parameters: 00:00 - INFO - ResourceGroupName -> testrg 00:00 - INFO - VMName -> testvm 00:00 - INFO - NewControllerType -> NVMe 00:00 - INFO - VMSize -> Standard_E4bds_v5 00:00 - INFO - StartVM -> True 00:00 - INFO - FixOperatingSystemSettings -> True 00:00 - INFO - Script Version 2025062704 00:00 - INFO - Module Az.Compute is installed and the version is correct. 00:00 - INFO - Module Az.Accounts is installed and the version is correct. 00:00 - INFO - Module Az.Resources is installed and the version is correct. 00:00 - INFO - Connected to Azure subscription name: AG-GE-CE-PHLEITEN 00:00 - INFO - Connected to Azure subscription ID: 232b6759-xxxx-yyyy-zzzz-757472230e6c 00:00 - INFO - VM testvm found in Resource Group testrg 00:01 - INFO - VM testvm is running 00:01 - INFO - VM testvm is running Linux 00:01 - INFO - VM testvm is running SCSI 00:02 - INFO - Running in Azure Cloud Shell 00:02 - INFO - Authentication token is a SecureString 00:02 - INFO - Authentication token received 00:02 - INFO - Getting available SKU resources 00:02 - INFO - This might take a while ... 00:06 - INFO - VM SKU Standard_E4bds_v5 is available in zone 1 00:06 - INFO - Resource disk support matches between original VM size and new VM size. 00:06 - INFO - Found VM SKU - Checking for Capabilities 00:06 - INFO - VM SKU has supported capabilities 00:06 - INFO - VM supports NVMe 00:06 - INFO - Pre-Checks completed 00:06 - INFO - Entering Linux OS section 00:37 - INFO - Script output: Enable succeeded: 00:37 - INFO - Script output: [stdout] 00:37 - INFO - Script output: [INFO] Operating system detected: sles 00:37 - INFO - Script output: [INFO] Checking if NVMe driver is included in initrd/initramfs... 00:37 - INFO - Script output: [INFO] NVMe driver found in initrd/initramfs. 00:37 - INFO - Script output: [INFO] Checking nvme_core.io_timeout parameter... 00:37 - INFO - Script output: [INFO] nvme_core.io_timeout is set to 240. 00:37 - INFO - Script output: [INFO] Checking /etc/fstab for deprecated device names... 00:37 - INFO - Script output: [INFO] /etc/fstab does not contain deprecated device names. 00:37 - INFO - Script output: 00:37 - INFO - Script output: [stderr] 00:37 - INFO - Script output: 00:37 - INFO - Errors: 0 - Warnings: 0 - Info: 7 00:37 - INFO - Shutting down VM testvm 01:18 - INFO - VM testvm stopped 01:18 - INFO - Checking if VM is stopped and deallocated 01:19 - INFO - Setting OS Disk capabilities for testvm_OsDisk_1_165411276cbe459097929b981eb9b3e2 to new Disk Controller Type to NVMe 01:19 - INFO - generated URL for OS disk update: 01:19 - INFO - https://management.azure.com/subscriptions/232b6759-xxxx-yyyy-zzzz-757472230e6c/resourceGroups/testrg/providers/Microsoft.Compute/disks/testvm_OsDisk_1_165411276cbe459097929b981eb9b3e2?api-version=2023-04-02 01:19 - INFO - OS Disk updated 01:19 - INFO - Setting new VM Size from Standard_E4s_v3 to Standard_E4bds_v5 and Controller to NVMe 01:19 - INFO - Updating VM testvm 01:54 - INFO - VM testvm updated 01:54 - INFO - Start after update enabled for VM testvm 01:54 - INFO - Waiting for 15 seconds before starting the VM 02:09 - INFO - Starting VM testvm 03:31 - INFO - VM testvm started 03:31 - INFO - As the virtual machine got started using the script you can check the operating system now 03:31 - INFO - If you have any issues after the conversion you can revert the changes by running the script with the old settings 03:31 - IMPORTANT - Here is the command to revert the changes: 03:31 - INFO - .\Azure-NVMe-Conversion.ps1 -ResourceGroupName testrg -VMName testvm -NewControllerType SCSI -VMSize Standard_E4s_v3 -StartVM 03:31 - INFO - Script ended at 06/27/2025 15:45:11 03:31 - INFO - Exiting PS /home/philipp>

Reverting back

The output shows a PowerShell command that will revert back your VM to SCSI at the end of the script:

.\Azure-NVMe-Conversion.ps1 -ResourceGroupName testvg -VMName testvm -NewControllerType SCSI -VMSize Standard_E4s_v3 -StartVM

Manually preparing Windows

To manually prepare Windows you just need to run one command. It will set the NVMe driver back to early start.

Everytime you boot Windows will evaluate the required drivers. If you set NVMe driver to the correct state, reboot and then check again, it will be started later during boot.

sc.exe config stornvme start=boot

Manually preparing Linux

To manually prepare Linux you need to make sure that

NVMe drivers are part of initrd/initramfs
have the NVMe I/O timeout set to 240 seconds (nvme_core.io_timeout=240) in grub
check /etc/fstab for any references to device names (e.g. /dev/sda) or old udev rule entries (e.g. /dev/disk/azure/scsi1/lun0)

Please refer to your Linux providers documentation how to adjust the required settings.

Azure Files NFS Encryption In Transit for SAP on Azure Systems

AnjanBanerjee — Mon, 30 Jun 2025 16:40:58 GMT

Azure Files NFS volumes now support encryption in-transit via TLS. With this enhancement, Azure Files NFS v4.1 offers the robust security that modern enterprises require, without compromising performance by ensuring all traffic between clients and servers is fully encrypted. Now Azure Files NFS data can be encrypted end-to-end: at rest, in transit, and across the network.

Using Stunnel, an open-source TLS wrapper, Azure Files encrypts the TCP stream between the NFS client and Azure Files with strong encryption using AES-GCM, without needing Kerberos. This ensures data confidentiality while eliminating the need for complex setups or external authentication systems like Active Directory.

The AZNFS utility package simplifies encrypted mounts by installing and setting up Stunnel on the client (Azure VMs). The AZNFS mount helper mounts the NFS shares with TLS support. The mount helper initializes dedicated stunnel client process for each storage account’s IP address. The stunnel client process listens on a local port for inbound traffic and then redirects encrypted nfs client traffic to the 2049 port where NFS server is listening on.

The AZNFS package runs a background job called aznfswatchdog. It ensures that stunnel processes are running for each storage account and cleans up after all shares from the storage account are unmounted. If for some reason a stunnel process is terminated unexpectedly, the watchdog process restarts it.

For more details, refer to the following document: How to encrypt data in transit for NFS shares

Availability in Azure Regions

All regions that support Azure Premium Files now support encryption in transit.

Supported Linux releases

For SAP on Azure environment, Azure Files NFS Encryption in Transit (EiT) is available for the following Operating System releases.

SLES for SAP 15 SP4 onwards
RHEL for SAP 8.6 onwards (EiT is currently not supported for file systems managed by Pacemaker clusters on RHEL.)

Refer to SAP Note 1928533 for Operating system supportability for SAP on Azure systems.

How to deploy Encryption in Transit (EiT) for Azure Files NFS Shares

Refer to the SAP on Azure deployment planning guide about Using Azure Premium Files NFS and SMB for SAP workload

As described in the planning guide, for SAP workloads, following are the supported uses of Azure Files NFS shares and EiT can be used for all the scenarios:

- sapmnt volume for a distributed SAP systems
- transport directory for SAP landscape
- /hana/shared for HANA scale-out. Review carefully the considerations for sizing /hana/shared, as appropriately sized /hana/shared volume contributes to system's stability
- file interface between your SAP landscape and other applications

Deploy the Azure File NFS storage account. Refer to the standard documentation for creating the Azure Files storage account, file share and private endpoint.

Create an NFS Azure file share

Note : We can enforce EiT for all the file shares in the Azure Storage account by enabling ‘secure transfer required’ option.

Deploy the mount helper (AZNFS) package on the Linux VM.

Follow the instructions for your Linux distribution to install the package.

Create the directories to mount the file shares.

mkdir -p <full path of the directory>

Mount the NFS File share.

Refer to the section for mounting the Azure Files NFS EiT file share in Linux VMs.

To mount the file share permanently by adding the mount commands in ‘/etc/fstab’.

vi /etc/fstab sapnfs.file.core.windows.net:/sapnfsafs/sapnw1/sapmntNW1 /sapmnt/NW1 aznfs noresvport,vers=4,minorversion=1,sec=sys,_netdev 0 0 # Mount the file systems mount -a

o File systems mentioned above are an example to explain the mount command syntax.

o When adding nfs mount entry to /etc/fstab, the fstype is "nfs". However, to use AZNFS mount helper and EiT, we need to use the fstype as "aznfs" which is not known to the Operating System, so at boot time the server tries to mount these entries before the watchdog is active, and they may fail. Users should always add "_netdev" option to their /etc/fstab entries to make sure shares are mounted on reboot only after the required services (like network) are active.

o We can add “notls” option in the mount command, if we don’t want to use the EiT but just want to use AZNFS mount helper to mount the file system. Also , we cannot mix EiT and no-EiT methods for different file systems using Azure Files NFS in the same Azure VM. Mount commands may fail to mount the file systems if EiT and no-EiT methods are used in the same VM

o Mount helper supports private-endpoint based connections for Azure Files NFS EiT.

o If SAP VM is custom domain joined, then we can use custom DNS FQDN OR short names for file share in the ‘/etc/fstab’ as its defined in the DNS. To verify the hostname resolution, check using ‘nslookup <hostname>’ and ‘getent host <hostname>’ commands.

Mount the NFS File share as pacemaker cluster resource for SAP Central Services.

In high availability setup of SAP Central Services, we may use file system as a resource in pacemaker cluster and it needs to be mounted using pacemaker cluster command. In the pacemaker commands to setup file system as cluster resource, we need to change the mount type to ‘aznfs’ from ‘nfs’. Also it’s recommended to use ‘_netdev’ in the options parameter.

Following are the SAP Central Services setup scenarios in which Azure Files NFS is used as pacemaker resource agent, and we can use Azure Files NFS EiT.

- Azure VMs high availability for SAP NW on SLES with NFS on Azure Files
- Azure VMs high availability for SAP NW on RHEL with NFS on Azure Files

For SUSE Linux:

SUSE 15 SP4 (for SAP) and higher releases recognise the ‘aznfs’ as file system type in the pacemaker resource agent.

SUSE recommends using simple mount approach for high availability setup of SAP Central services, in which all file systems are mounted using ‘/etc/fstab’ only.

For RHEL Linux:

RHEL 8.6 (for SAP) and higher releases will be recognising ‘aznfs’ as file system type in pacemaker resource agent.

At the time of writing the blog, ‘aznfs’ as file system type is not yet recognised by the FileSystem resource agent(RS) on RHEL, hence this setup can’t be used at this moment.

For SAP HANA scale-out with HSR setup

We can use Azure Files NFS EiT for SAP HANA scale-out with HSR setup as described in the below docs.

- SAP HANA scale-out with HSR and Pacemaker on SLES
- SAP HANA scale-out with HSR and Pacemaker on RHEL

We need to mount ‘/hana/shared’ File system with EiT by defining the filesystem type as ‘aznfs’ in ‘/etc/fstab’. Also it’s recommended to use ‘_netdev’ in the options parameter.

For SUSE Linux:

In the Create File system resource section with SAP HANA high availability “SAPHanaSR-ScaleOut” package, in which we create a dummy file system cluster resource, which will monitor and report failures for ‘/hana/shared’ file system, we can continue to follow the steps as it is in the above document with ‘fstype=nfs4’. ‘/hana/shared’ file system will still be using EiT as defined in ‘/etc/fstab’.

For SAP HANA high availability “SAPHanaSR-angi”, there are no further actions needed to use Azure File NFS EiT.

For RHEL Linux:

In the Create File system resource section, we can replace the file system type to ‘aznfs’ from ‘nfs’ in the pacemaker resource configuration for ‘/hana/shared’ file systems.

Validation of in-transit data Encryption for Azure Files NFS.

Refer to Verify that the in-transit data encryption succeeded section to check and confirm if EiT is successfully working.

Summary

Go ahead with EiT!! Simplified deployment of Encryption in Transit of Azure Files Premium NFS (Locally redundant Storage / Zonal redundant Storage) will strengthen the security footprint of Production and non-Production SAP on Azure environments.

SAP Web Dispatcher on Linux with High Availability Setup on Azure

AnjanBanerjee — Thu, 05 Jun 2025 03:54:07 GMT

1. Introduction

The SAP Web Dispatcher component is used for load balancing SAP web HTTP(s) traffic among the SAP application servers. It works as “reverse proxy” and the entry point for HTTP(s) requests into SAP environment, which consists of one or more SAP NetWeaver system.

This blog provides detailed guidance about setting up high availability of standalone SAP Web Dispatcher on Linux operating system on Azure. There are different options to set up high availability for SAP Web Dispatcher.

Active/Passive High Availability Setup using a Linux pacemaker cluster (SUSE or Red Hat) with a virtual IP/hostname defined in Azure Load Balancer.
Active/Active High Availability Setup by deploying multiple parallel instances of SAP Web Dispatcher across different Azure Virtual Machines (running either SUSE or Red Hat) and distributing traffic using Azure Load Balancer.

We will walk through the configuration steps for both high availability scenarios in this blog.

2. Active/Passive HA Setup of SAP Web Dispatcher

2.1. System Design

Following is the high level architecture diagram of HA SAP Production environment on Azure. SAP Web Dispatcher (WD) standalone HA setup is highlighted in the SAP architecture design.

In this setup as active/passive node design, primary node of the SAP Web Dispatcher will be receiving the user's requests and transferring (and load balancing) it to the backed SAP Application Servers. In case of unavailability of primary node, Linux pacemaker cluster will perform the failover of SAP Web Dispatcher to the secondary node. Users will connect to the SAP Web Dispatcher using the virtual hostname(FQDN) and virtual IP Address as defined in the Azure Loadbalancer. Azure Loadbalancer health probe port will be activated by pacemaker cluster on the primary node, so all the user connections to the virtual IP/hostname will be redirected by Azure Loadbalancer to the active SAP Web Dispatcher.

Also, SAP Help documentation describes this HA architecture as “High Availability of SAP Web Dispatcher with External HA Software”.

The following are the advantages of active-passive SAP WD setup.

Linux pacemaker cluster will continuously monitor the SAP WD active node and services running on it. In case of any error scenario, the active node will be fenced by pacemaker cluster and secondary node will be made active. This will ensure best user experience round the clock.
Complete automation of error detection and start/stop functionality of SAP WD. Its would be less challenging to define application-level SLA when pacemaker managing the SAP WD. Azure provides VM level SLA of 99.99% , if VMs are deployed in Availability Zones.

We need following components to setup HA SAP Web Dispatcher on Linux.

A pair of SAP Certified VMs on Azure with supported Linux Operating System. Cross Availability Zone deployment is recommended for higher VM level SLA.
Azure Fileshare (Premium) for ‘sapmnt’ NFS share which will be available/mounted on both VMs for SAP Web Dispatcher.
Azure Load Balancer for configuring virtual IP and hostname (in DNS) of the SAP Web Dispatcher.
Configure Linux pacemaker cluster.
Installation of SAP Web Dispatcher on both the VMs with same SID and system number. It is recommended to use the latest version of SAP Web Dispatcher.
Configure the pacemaker resource agent for SAP Web Dispatcher application.

2.2. Deployment Steps

This section provides detailed steps for HA active/passive SAP Web Dispatcher deployment for both the supported Linux operating systems (SUSE and Red Hat). Please refer to SAP Note 1928533 for SAP on Azure certified VMs, SAPS values and supported operating systems versions for SAP environment.

In the below steps, ‘For SLES’ is applicable to SLES operating system and ‘For RHEL’ is applicable to RHEL operating system. If for any step, operating system is not mentioned then its applicable to both the operating system.

Also following items are prefixed with:

[A]: Applicable to all nodes.

[1]: Applicable to only node 1.

[2]: Applicable to only node 2.

Deploy the VMs (of the desired SKU) in the availability zones and choose operating system image as SLES/RHEL for SAP. In this blog, below VM names are used:
- Node1: webdisp01
- Node2: webdisp02
- Virtual Hostname: eitwebdispha
Follow the standard SAP on Azure document for base pacemaker setup for the SAP Web Dispatcher VMs. We can either use SBD device or Azure fence agent for setting up fencing in the pacemaker cluster.
- For SLES: Set up Pacemaker on SUSE Linux Enterprise Server (SLES) in Azure
- For RHEL: Set up Pacemaker on Red Hat Enterprise Linux in Azure
The rest of the below setup steps are derived from the below SAP ASCS/ERS HA setup document and SUSE/RHEL blog on SAP WD setup. It's highly recommended to read the following documents.
- For SLES:
  - High availability for SAP NetWeaver on Azure VMs on SUSE Linux Enterprise Server with NFS on Azure Files.
  - SUSE Blog: SAP Web Dispatcher High Availability on Cloud with SUSE Linux.
- For RHEL:
  - High availability for SAP NetWeaver on VMs on RHEL with NFS on Azure Files
  - RHEL Blog: How to manage standalone SAP Web Dispatcher instances using the RHEL HA Add-On - Red Hat Customer Portal

Deploy the Azure standard load balancer for defining the virtual IP of the SAP Web Dispatcher. In this example, the following setup is used in deployment.

Frontend IP

Backend Pool

Health Probe Port

Load Balancing Rule

10.50.60.45

(Virtual IP of SAP Web Dispatcher)

Node 1 & Node 2 VMs

62320 (set probeThreshold=2)

HA Port: Enable

Floating IP: Enable

Idle Timeout: 30 mins

Don't enable TCP time stamps on Azure VMs placed behind Azure Load Balancer. Enabling TCP timestamps will cause the health probes to fail. Set the “net.ipv4.tcp_timestamps” OS parameter to '0'. For details, see Load Balancer health probes.

Run the following command to set this parameter, and to set up value permanently add or update the parameter in /etc/sysctl.conf.

sudo sysctl net.ipv4.tcp_timestamps=0

When VMs without public IP addresses are placed in the back-end pool of an internal (no public IP address) Standard Azure load balancer, there will be no outbound internet connectivity unless you perform additional configuration to allow routing to public endpoints. For details on how to achieve outbound connectivity, see Public endpoint connectivity for virtual machines using Azure Standard Load Balancer in SAP high-availability scenarios.

Configure NFS for ‘sapmnt’ and SAP WD instance Filesystem on Azure Files. Deploy the Azure Files storage account (ZRS) and create fileshares for ‘sapmnt’ and ‘SAP WD instance (/usr/sap/SID/Wxx)’. Connect it to the vnet of the SAP VMs using private endpoint.
- For SLES: Refer to the Deploy an Azure Files storage account and NFS shares section for detailed steps.
- For RHEL: Refer to the Deploy an Azure Files storage account and NFS shares section for detailed steps.
Mount NFS volumes.
- [A] For SLES: NFS client and other resources come pre-installed.
- [A] For RHEL: Install the NFS Client and other resources.
  sudo yum -y install nfs-utils resource-agents resource-agents-sap
- [A] Mount the NFS file system on both VMs. Create shared directories.
  sudo mkdir -p /sapmnt/WD1 sudo mkdir -p /usr/sap/WD1/W00 sudo chattr +i /sapmnt/WD1 sudo chattr +i /usr/sap/WD1/W00
- [A] Mount the File system that will not be controlled by pacemaker cluster.
  echo "sapnfsafs.privatelink.file.core.windows.net:/sapnfsafs/webdisp-sapmnt /sapmnt/WD1 nfs noresvport,vers=4,minorversion=1,sec=sys 0 2" >> /etc/fstab mount -a
Prepare for SAP Web Dispatcher HA Installation.
- [A] For SUSE: Install the latest version of the SUSE connector.
  sudo zypper install sap-suse-cluster-connector
- [A] Set up host name resolution (including virtual hostname).
  - We can either use a DNS server or modify /etc/hosts on all nodes.
- [A] Configure the SWAP file. Edit ‘/etc/waagent.conf’ file and change the following parameters.
  ResourceDisk.Format=y ResourceDisk.EnableSwap=y ResourceDisk.SwapSizeMB=2000
- [A] Restart the agent to activate the change
  sudo service waagent restart
- [A] For RHEL: Based on RHEL OS version follow SAP Notes.
  - SAP Note 2002167 for RHEL 7.x
  - SAP Note 2772999 for RHEL 8.x
  - SAP Note 3108316 for RHEL 9.x
Create the SAP WD instance Filesystem, virtual IP, and probe port resources for SAP Web Dispatcher.
- [1] For SUSE:
  # Keep node 2 in standby sudo crm node standby webdisp02 # Configure file system, virtual IP, and probe resource sudo crm configure primitive fs_WD1_W00 Filesystem device=' sapnfsafs.privatelink.file.core.windows.net:/sapnfsafs/webdisp-su-usrsap' directory='/usr/sap/WD1/W00' fstype='nfs' options='noresvport,vers=4,minorversion=1,sec=sys' \ op start timeout=60s interval=0 \ op stop timeout=60s interval=0 \ op monitor interval=20s timeout=40s sudo crm configure primitive vip_WD1_W00 IPaddr2 \ params ip=10.50.60.45 \ op monitor interval=10 timeout=20 sudo crm configure primitive nc_WD1_W00 azure-lb port=62320 \ op monitor timeout=20s interval=10 sudo crm configure group g-WD1_W00 fs_WD1_W00 nc_WD1_W00 vip_WD1_W00
  Make sure that all the resources in the cluster are in started status and running on Node 1. Check the status using the command ‘crm status’.
- [1] For RHEL:
  # Keep node 2 in standby sudo pcs node standby webdisp02 # Create file system, virtual IP, probe resource sudo pcs resource create fs_WD1_W00 Filesystem device='sapnfsafs.privatelink.file.core.windows.net:/sapnfsafs/webdisp-rh-usrsap' \ directory='/usr/sap/WD1/W00' fstype='nfs' force_unmount=safe options='sec=sys,nfsvers=4.1' \ op start interval=0 timeout=60 op stop interval=0 timeout=120 op monitor interval=200 timeout=40 \ --group g-WD1_W00 sudo pcs resource create vip_WD1_W00 IPaddr2 \ ip=10.50.60.45 \ --group g-WD1_W00 sudo pcs resource create nc_WD1_W00 azure-lb port=62320 \ --group g-WD1_W00
  Make sure that all the resources in the cluster are in started status and running on Node 1. Check the status using the command ‘pcs status’.
[1] Install SAP Web Dispatcher on the first Node.
- For RHEL: Allow access to SWPM. This rule is not permanent. If you reboot the machine, you should run the command again.
  sudo firewall-cmd --zone=public --add-port=4237/tcp
- Run the SWPM.
  ./sapinst SAPINST_USE_HOSTNAME=<virtual hostname>
  - Enter the virtual hostname and Instance number.
  - Provide the S/4 HANA message server details for backend connections.
  - Continue with SAP Web Dispatcher installation.
- Check the status of SAP WD.
[1] Stop the SAP WD and disable the systemd service. This step is only if SAP startup framework is managed by systemd as per SAP Note 3115048.
# login as sidadm user sapcontrol -nr 00 -function Stop # login as root user systemctl disable SAPWD1_00.service
[1] Move the Filesystem, virtual IP, and probe port resources for SAP Web Dispatcher to second Node.
- For SLES:
  sudo crm node online webdisp02 sudo crm node standby webdisp01
- For RHEL:
  sudo pcs node unstandby webdisp02 sudo pcs node standby webdisp01
- NOTE: Before proceeding to the next steps, check that resources successfully moved to Node 2.
[2] Setup SAP Web Dispatcher on the second Node.
- To setup the SAP WD on Node 2, we can copy the following files and directories from Node 1 to Node 2. Also perform the other tasks in Node 2 as mentioned below.
- Note: Please ensure that permissions, owner, and group names are same in Node 2 for all the copied items as in Node 1. Before copying, save a copy of the existing files in Node 2.
- Files to copy
  # For SLES and RHEL /usr/sap/sapservices /etc/system/system/SAPWD1_00.service /etc/polkit-1/rules.d/10-SAPWD1-00.rules /etc/passwd /etc/shadow /etc/group # For RHEL /etc/gshadow
- Folders to copy
  # After copying, Rename the ‘hostname’ in the environment file names. /home/wd1adm /home/sapadm /usr/sap/ccms /usr/sap/tmp
- Create the 'SYS' directory in the /usr/sap/WD1 folder
  - Create all subdirectories and soft links as available in Node 1.
[2] Install the saphostagent
- Extract the SAPHOSTAGENT.SAR file
- Run the command to install it
  ./saphostexec -install
- Check if SAP hostagent is running successfully
  /usr/sap/hostctrl/exe/saphostexec -status
[2] Start SAP WD on node 2 and check the status

sapcontrol -nr 00 -function StartService WD1 sapcontrol -nr 00 -function Start sapcontrol -nr 00 -function GetProcessStatus
[1] For SLES: Update the instance profile

vi /sapmnt/WD1/profile/WD1_W00_wd1webdispha # Add the following lines. service/halib = $(DIR_EXECUTABLE)/saphascriptco.so service/halib_cluster_connector = /usr/bin/sap_suse_cluster_connector
[A] Configure SAP users after the installation

sudo usermod -aG haclient wd1adm
[A] Configure keepalive parameter and add the parameter in /etc/sysctl.conf to set the value permanently

sudo sysctl net.ipv4.tcp_keepalive_time=300
Create SAP Web Dispatcher resource in cluster
- For SLES:
  sudo crm configure property maintenance-mode="true" sudo crm configure primitive rsc_sap_WD1_W00 SAPInstance \ op monitor interval=11 timeout=60 on-fail=restart \ params InstanceName=WD1_W00_wd1webdispha \ START_PROFILE="/usr/sap/WD1/SYS/profile/WD1_W00_wd1webdispha" \ AUTOMATIC_RECOVER=false MONITOR_SERVICES="sapwebdisp" sudo crm configure modgroup g-WD1_W00 add rsc_sap_WD1_W00 sudo crm node online webdisp01 sudo crm configure property maintenance-mode="false"
- For RHEL
  sudo pcs property set maintenance-mode=true sudo pcs resource create rsc_sap_WD1_W00 SAPInstance \ InstanceName=WD1_W00_wd1webdispha START_PROFILE="/sapmnt/WD1/profile/WD1_W00_wd1webdispha" \ AUTOMATIC_RECOVER=false MONITOR_SERVICES="sapwebdisp" \ op monitor interval=20 on-fail=restart timeout=60 \ --group g-WD1_W00 sudo pcs node unstandby webdisp01 sudo pcs property set maintenance-mode=false
[A] For RHEL: Add firewall rules for SAP Web Dispatcher and Azure load balancer health probe ports on both nodes.

sudo firewall-cmd --zone=public --add-port={62320,44300,8000}/tcp --permanent sudo firewall-cmd --zone=public --add-port={62320,44300,8000}/tcp
Verify SAP Web Dispatcher Cluster is running successfully
Check "insights" blade of Azure load balancer in portal. It would show connections are redirected to one of the nodes.
Check the backend S/4 HANA connection is working using the SAP Web Dispatcher Administration link.
Run the sapwebdisp config check

sapwebdisp pf=/sapmnt/WD1/profile/WD1_W00_wd1webdispha -checkconfig
Test the cluster setup
- For SLES
  - Pacemaker cluster testing for SAP Web Dispatcher can be derived from the document Azure VMs high availability for SAP NetWeaver on SLES (for ASCS/ERS Cluster)
  - We can run the following test cases (from the above link), which can be applicable for SAP WD component.
    - Test HAGetFailoverConfig and HACheckFailoverConfig
    - Manually migrate the SAP Web Dispatcher resource
    - Test HAFailoverToNode
    - Simulate node crash
    - Blocking network communication
    - Test manual restart of SAP WD instance
- For RHEL
  - Pacemaker cluster testing for SAP Web Dispatcher can be derived from the document Azure VMs high availability for SAP NetWeaver on RHEL (for ASCS/ERS Cluster)
  - We can run the following test cases (from the above link), which can be applicable for SAP WD component.
    - Manually migrate the SAP Web Dispatcher resource
    - Simulate a node crash
    - Blocking network communication
    - Kill the SAP WD process

3. Active/Active HA Setup of SAP Web Dispatcher

3.1. System Design

In this Active/Active setup of SAP Web Dispatcher (WD), we can deploy and run parallel standalone WD on individual VMs with share nothing designs and have different SID. To connect to the SAP Web Dispatcher, Users will be using the one virtual hostname (FQDN)/IP as defined in the front-end IP of Azure Load balancer. Virtual IP to hostname/FQDN mapping needs to be performed in AD/DNS. Incoming traffic will be distributed to either of the WD by the Azure Internal Load balancer. No Operating system cluster setup is required in this scenario. This architecture can be deployed in either Linux or Windows operating systems.

In ILB configuration, Session persistence settings will ensure that user’s successive requests always be routed from Azure Load balancer to same WD as long as its active and ready to receive connections.

Also, SAP Help documentation describes this HA architecture as “High availability with several parallel Web Dispatchers”.

The following are the advantages of the active-active SAP WD setup.

Simpler design no need to set up Operating System Cluster
We have 2 WD instances to handle the requests and distribute the workload.
If one of the nodes fail, Load balancer will forward request to another and stop sending requests to failed node. So, it means SAP WD setup is highly available.

We need the following components to setup active/active SAP Web Dispatcher on Linux.

A pair of SAP Certified VMs on Azure with supported Linux Operating System. Cross Availability Zone deployment is recommended for higher VM level SLA.
Azure managed disk of required size on each VM to create Filesystems for ‘sapmnt’ and ‘/sar/sap’.
Azure Load Balancer for configuring virtual IP and hostname (in DNS) of the SAP Web Dispatcher.
Installation of SAP Web Dispatcher on both the VMs with different SID. It is recommended to use the latest version of SAP Web Dispatcher.

3.2. Deployment Steps

This section provides detailed steps for HA active/active SAP Web Dispatcher deployment for both the supported Linux operating systems (SUSE Linux and Redhat Linux). Please refer to SAP Note 1928533 for SAP on Azure certified VMs, SAPS values and supported operating systems versions for SAP environment.

3.2.1. For SUSE and RHEL Linux

Deploy the VMs (of the desired SKU) in the availability zones and choose operating system image as SUSE/RHEL Linux for SAP. Add managed data disk on each of the VMs and create ‘/usr/sap’ and ‘/sapmnt/<SID> Filesystem in it.
Install the SAP Web Dispatcher using SAP SWPM on both VMs. Both SAP WD are completely independent of each other and should have separate SID.
Perform the basic configuration check for both SAP web dispatchers using “sapwebdisp pf=<profile> -checkconfig”. We should also check if SAP WD Admin URL is working for both WD.

Deploy the Azure standard load balancer for defining the virtual IP of the SAP Web Dispatcher. As a reference, the following setup is used in deployment.

Front-end IP

Backend Pool

Health Probe Port

Load Balancing Rule

10.50.60.99

(Virtual IP of SAP Web Dispatcher)

Node1 & Node2 VM

Protocol: HTTPS

Port: 44300 (WD https port)

Path: /sap/public/icman/ping

Interval: 5 seconds

(set probeThreshold=2 using azure CLI)

Port & Backend Port: 44300

Floating IP: Disable,

TCP Reset: Disable,

Idle Timeout: Max (30 Minutes)

Icman/ping is a way to ensure that SAP web dispatcher is successfully connected to backend SAP S/4 HANA or SAP ERP based application servers. This check is also part of the basic configuration check of SAP web dispatcher using “sapwebdisp pf=<profile> -checkconfig”.
If we use HTTP(s) based health probe, ILB connection will be redirected to SAP WD only when connection between SAP WD and S/4 HANA OR ERP Application is working.
If we have Java based SAP system as backend environment, then ‘icman/ping’ will not be available, and HTTP(S) path can’t be used in health probe. In that case, we can use TCP based health probe (protocol value as ‘tcp’) and use SAP WD tcp port (like port 8000) in the health probe configuration.
In this setup, we used https port 44300 as port & backend port value as that is the only port number used by incoming/source URL. If there are multiple ports to be used/allowed in incoming URL, then we can enable ‘HA Port’ in Load balancing rule instead of specifying the used port.
Note: As per SAP Note 2941769, we need to set SAP web dispatcher parameter wdisp/filter_internal_uris=FALSE. Also we need to verify if icman ping URL is working for both the SAP Web dispatchers with their actual hostnames.
Define the front-end IP (virtual IP) and hostname mapping in the DNS or /etc/hosts file.

Check if Azure Loadbalancer is routing traffic to both WD. In the ‘Insights’ section for Azure loadbalancer, connection health to the VMs should be green.
Validate the SAP Web Dispatcher URL is accessible using virtual hostname.
Perform high availability tests for SAP WD.
Stop first SAP WD and verify WD connections are working.
Then start the first WD and stop the second WD and verify that the WD connections are working.
Simulate node crash of each of the WD VMs and verify that the WD connections are working.

3.3. SAP Web Dispatcher (active/active) for Multiple Systems

We can use the SAP WD (active/active) pair to connect to multiple backend SAP systems rather than setting up separate SAP WD for each SAP backend environment.

Based on the unique URL of the incoming request with different virtual hostname/FQDN and/or port of the SAP WD, user request will be directed to any one of the SAP WD and then SAP WD will determine the backend system to redirect and load balance the requests.

SAP documents describe the design and SAP specific configurations steps for this scenario.

In Azure environment, SAP Web Dispatcher architecture will be as below.

We can deploy this setup by defining an Azure standard load balancer with multiple front-end IPs attached to one backend-pool of SAP WD VMs and configuring health-probe and load balancing rules to associate it.

When configuring Azure Load Balancer with multiple frontend IPs pointing to the same backend pool/port, floating IP must be enabled for each load balancing rule. If floating IP is not enabled on the first rule, Azure won’t allow the configuration of additional rules with different frontend IPs on the same backend port. Refer to the article Multiple frontends - Azure Load Balancer

With floating IPs enabled on multiple load balancing rules, the frontend IP must be added to the network interface (e.g., eth0) on both SAP Web Dispatcher VMs.

3.3.1. Deployment Steps

Deploy the VMs (of the desired SKU) in the availability zones and choose operating system image as SUSE/RHEL Linux for SAP. Add managed data disk on each of the VMs and create ‘/usr/sap’ and ‘/sapmnt/<SID> Filesystem in it.
Install the SAP Web Dispatcher using SAP SWPM on both VMs. Both SAP WD are completely independent of each other and should have separate SID.

Deploy Azure Standard Load Balancer with configuration as below

Front-end IP

Backend Pool

Health Probe Port

Load Balancing Rule

10.50.60.99

(Virtual IP of SAP Web Dispatcher for redirection to S/4 or Fiori SID E10)

Node1 & Node2 VMs

Protocol: TCP

Port: 8000 (WD tcp port)

Interval: 5 seconds

(set probeThreshold=2 using azure CLI)

Protocol: TCP

Port & Backend Port: 44300

Floating IP: Enable,

TCP Reset: Disable,

Idle Timeout: Max (30 Minutes)

10.50.60.101

(Virtual IP of SAP Web Dispatcher for redirection to S/4 SID or Fiori E60)

Protocol: TCP

Port & Backend Port: 44300

Floating IP: Enable,

TCP Reset: Disable,

Idle Timeout: Max (30 Minutes)

As described above, we are defining 2 front-end IPs, 2 load-balancing rules, 1 back-end pool and 1 health probe.
In this setup, we used https port 44300 as port & backend port value as that is the only port number used by incoming/source URL. If there are multiple ports to be used/allowed in incoming URL, then we can enable ‘HA Port’ in Load balancing rule instead of specifying the used port.
Define the front-end IP (virtual IP) and hostname mapping in the DNS or /etc/hosts file.

Add both the virtual IPs to the SAP WD VMs network interface. Make sure the additional IPs are added permanently and do not disappear after VM reboot.
- For SLES, refer to “alternative workaround” section in Automatic Addition of Secondary IP Addresses in Azure
- For RHEL, refer to the solution provided using “nmcli” command in the How to add multiple IP range in RHEL9
- Displaying the "ip addr show" for SAP WD VM1:
  >>ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 60:45:bd:73:bd:14 brd ff:ff:ff:ff:ff:ff inet 10.50.60.87/26 brd 10.50.60.127 scope global eth0 valid_lft forever preferred_lft forever inet 10.50.60.99/26 brd 10.50.60.127 scope global secondary eth0 valid_lft forever preferred_lft forever inet 10.50.60.101/26 brd 10.50.60.127 scope global secondary eth0 valid_lft forever preferred_lft forever inet6 fe80::6245:bdff:fe73:bd14/64 scope link valid_lft forever preferred_lft forever
- Displaying the "ip addr show" for SAP WD VM2:
  >> ip addr show 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 60:45:bd:73:b1:92 brd ff:ff:ff:ff:ff:ff inet 10.50.60.93/26 brd 10.50.60.127 scope global eth0 valid_lft forever preferred_lft forever inet 10.50.60.99/26 brd 10.50.60.127 scope global secondary eth0 valid_lft forever preferred_lft forever inet 10.50.60.101/26 brd 10.50.60.127 scope global secondary eth0 valid_lft forever preferred_lft forever inet6 fe80::6245:bdff:fe73:b192/64 scope link valid_lft forever preferred_lft forever
Update the Instance profile of SAP WDs.
#----------------------------------------------------------------------- # Back-end system configuration #----------------------------------------------------------------------- wdisp/system_0 = SID=E10, MSHOST=e10ascsha, MSPORT=8100, SSL_ENCRYPT=1, SRCSRV=10.50.60.99:* wdisp/system_1 = SID=E60, MSHOST=e60ascsha, MSPORT=8100, SSL_ENCRYPT=1, SRCSRV=10.50.60.101:*
- Stop and Start the SAP WD on VM1 and VM2.
- Note: With the above SRCSRV parameter value, only incoming request from “.99 (or its hostname)” for E10 or “.101 (or its hostname)” for E60 will be sent to SAP backend environment. If we also want to use SAP WD actual IP or hostname-based request to be also connected to SAP Backend systems, then we need to add those IP or hostnames in the value (separated by semicolon) of SRCSRV parameter.
Perform the basic configuration check for both SAP web dispatcher using “sapwebdisp pf=<profile> -checkconfig”. We should also check if SAP WD Admin URL is working for both WD.
In the Azure Portal, in the ‘Insights’ section of Azure load balancer, we can see that connection status to the SAP WD VMs are healthy.

SAP on Azure Product Announcements Summary – SAP Sapphire 2025

Hiren_Shah_Azure — Tue, 20 May 2025 14:00:00 GMT

Introduction

Today at Sapphire, we made an array of exciting announcements that strengthen the Microsoft-SAP partnership. I'd like to share additional details that complement these announcements as well as give updates on further product innovation. With over three decades of close collaboration and co-innovation with SAP, we continue to deliver RISE with SAP on Azure and integrations with SAP S/4HANA Public Cloud, allowing customers to innovate with services from both SAP BTP and Microsoft. Our new integrations enhance security through multi-layer cloud protection for SAP and non-SAP workloads, while our AI and Copilot platform provides unified analytics to improve decision-making for customers.

Samsung C&T's Engineering & Construction Group is a leader in both the domestic and international construction industries. It recently embarked on the ERP Cloud transformation with RISE with SAP on Azure to enhance its existing ERP System, which is optimized for local environment, to support the global business expansion by transitioning to RISE with SAP on Azure.

“Samsung C&T’s successful transition to RISE with SAP on Azure serves as a best practice for other Samsung Group affiliates considering cloud-based ERP adoption. It also demonstrates that even highly localized operations can be integrated into a cloud-based environment that supports global standards.”

Aidan Nam, Former Vice President, Corporate System Team, Samsung C&T

SAP on Azure also offers AI, Data, and Security solutions that enhance customers' investments and help unlock valuable information stored within ERP systems. When Danfoss, a global leader in energy-efficient solutions, began searching for new security tools for business-critical SAP infrastructure, it quickly leveraged Microsoft Sentinel solution for SAP applications, to find potential malicious activity and deploy multilayered protection around its expanding core infrastructure thereby achieving scalable security visibility.

“With Microsoft Sentinel and the Microsoft Sentinel solution for SAP applications, we’ve centralized our security logs and gained a single pane of glass with which we can monitor our SAP systems,”

Kevin Cai, IT Specialist in the Security Operations Center at Danfoss

We are pleased to announce additional SAP on Azure product updates and details to further help customers innovate on the most trusted cloud for SAP.

Simplified onboarding of SAP BTP estate with the new agentless data connector for Microsoft Sentinel Solution for SAP
Microsoft Defender for Endpoint for SAP applications is now fully SAP HANA aware offering unparalleled protection for SAP S/4HANA environments.
Public Preview of SAP OData as a knowledge source making it easy to add content from SAP systems to Copilot Studio.
The new storage and memory optimized Medium Memory Mbv3 VM Series (Mbsv3 and Mbdsv3) is now SAP certified, delivering compute capabilities with IOPs performance of up to 650K.
The Mv3 Very High Memory series now features an expanded range of SAP-certified VM sizes, spanning from 24TB to 32TB of memory and scaling up to 1,792 vCPUs.
General Availability of SAP ASE (Sybase) database backup support on Azure Backup.
SAP Deployment Automation Framework now supports validation of SAP deployments on Azure with public preview of SAP Testing Automation Framework (STAF), automating high availability testing process to ensure SAP systems reliability and availability.
The Inventory Checks for SAP Workbook in Azure Center for SAP Tools now comes with New Dashboards for Enhanced Visibility.

Let's dive into the summary of product updates and services.

Extend and Innovate

Microsoft Sentinel Solution for SAP

Business applications pose a unique security challenge with highly sensitive information that can make them prime targets for attacks. Attackers can compromise newly discovered unprotected SAP systems within three hours. Microsoft offers best in class security solutions support for SAP business applications with Microsoft Sentinel.

The new agentless data connector is our first party solution that re-uses customers’ SAP BTP estate for drastically simplified onboarding. In addition, new strategic third-party solutions have been added to the Microsoft Sentinel content hub by SAP SE and other ISVs making Sentinel the most effective SIEM for SAP workloads:

SAP LogServ: RISE, addon for SAP ECS internal logs -infra, database, etc. (Generally Available)
SAP Enterprise Threat Detection (Preview)
SecurityBridge (Generally Available)

Microsoft Defender for Endpoint for SAP applications

We are thrilled to announce a major milestone made possible through the deep collaboration between SAP and Microsoft: Microsoft Defender for Endpoint (MDE) is now the first NextGen antivirus solution that is SAP HANA aware. This joint innovation allows organizations like COFCO International to protect their SAP landscapes seamlessly and securely, without disruption.

This groundbreaking capability sets MDE apart in the cybersecurity landscape, offering unparalleled protection for SAP S/4HANA environments — all without interfering with mission-critical operations.
Thanks to close engineering collaboration, MDE has been carefully trained to recognize SAP HANA binaries and data files. Specialized detection training ensures MDE accurately identifies these critical components and treats them as known, trusted entities — combining world-class cybersecurity with SAP-native awareness.

API Management

SAP Principal Propagation (for simplicity often also referred to as SSO) is the gold standard for app integration – especially when it comes to 3rd party apps such as Microsoft Power Platform. We proudly announce that SSO is now password-less with Azure. Microsoft Entra ID Managed Identity works seamlessly with SAP workloads such as RISE, SuccessFactors and more. Cut your maintenance efforts for SAP SSO in half and become more secure in doing so.

Find more details on this blog.

Teams Integration

In addition to the availability of the SAP Joule agent in Teams and Copilot, the “classic” integration of Teams with products like SAP S/4HANA Public Cloud is available as well. What started as “Share links to the business context (apps) in chats” has now evolved to Adaptive Card-based Loop components, Chat, Voice and Video calls integrations in contact cards and To Dos in Teams.

Users of SAP S/4HANA Public Cloud can stay in their flow of work and access their business-critical data from with SAP S/4HANA Public Cloud or connected Teams applications.

Copilot Studio – SAP OData Support in Knowledge Sources

Knowledge Sources in Copilot Studio enhance generative answers by using data from Power Platform, Dynamics 365, websites, and external systems. This enables agents to offer relevant information and insights to customers.

Today, we announce the Public Preview of SAP OData as a new knowledge source. Customers and partners can now add content from SAP systems to Copilot Studio. Users can query the latest status of Sales Orders in SAP S/4HANA, view pending Invoices from ECC, or query information about employees from SAP SuccessFactors.

All you need to do is connect to the relevant SAP OData services as a knowledge source in Copilot Studio. Copilot Studio will not duplicate the data but analyze the data structure and create the relevant queries on demand whenever a user asks a related question. The user context is always kept ensuring roles and permissions in the SAP system are taken into account.

Head over to product documentation to read more and get started.

New SAP Certified Compute and Storage

Thousands of organizations today trust the Azure M-series virtual machines to run some of their largest mission-critical SAP workloads, including SAP HANA.

Very High Memory Mv3 VM Series

We are excited to unveil updates to our Mv3 Very High Memory (VHM) series with the addition of a 24TB VM, a testament to our ongoing commitment to innovation. Building on our past successes, this series integrates customer insights and industry advancements to deliver unmatched performance and efficiency. It features advanced capabilities for diverse workloads, powered by the 4th generation Intel® Xeon® Platinum 8490H processors, which offer faster processing speeds and better price-performance. You can learn more about our new Mv3 VHM here link. Below is the summary of the recently released Mv3 VHM SKUs.

(New) Standard_M896ixds_24_v3: Designed for S/4HANA workloads, with 896 cores and SMT disabled for optimal SAP performance. It is SAP certified for OLTP (S/4HANA) Scale-Up/4-node Scale-Out, and OLAP (BW4H) Scale-Up operations.
Standard_M896ixds_32_v3: Designed for S/4HANA workloads, with 896 cores and SMT disabled for optimal SAP performance. It is SAP certified for OLTP (S/4HANA) Scale-Up/4-node Scale-Out, and OLAP (BW4H) Scale-Up operations.
Standard_M1792ixds_32_v3: Designed for S/4HANA workloads, with 1792 cores. It is SAP certified for OLTP (S/4HANA) Scale-Up/2-node Scale-Out, and OLAP (BW4H) Scale-Up operations.

The new VM Size provides robust memory and CPU power, ensuring exceptional handling of large-scale in-memory databases. With 200 Gbps bandwidth and adaptable storage options such as Premium Disk and Azure NetApp Files (ANF), these VMs deliver speed and flexibility for SAP HANA configurations.

Medium Memory Mbv3 VM Series

The new Mbv3 series (Mbsv3 and Mbdsv3), released in September 2024, featuring both storage-optimized and memory-optimized are now certified as SAP certified compute VM as of March 2025. The new Mbv3 VMs are based on the 4th generation Intel® Xeon® Scalable processors, scale for workloads up to 4TB, and deliver with NVMe interface for higher remote disk storage performance. It offers up to 650,000 IOPS providing a 5x improvement in network throughput over the previous M-series families and up to 10GBps of remote disk storage bandwidth, providing a 2.5x improvement in remote storage bandwidth over the previous M-series families.

Details of SAP Certified Compute Mbv3 VMs are here link.

SAP on Azure Software Products and Services

Azure Backup for SAP

We are pleased to announce the general availability of backup support for SAP ASE database running on Azure virtual machines using Azure Backup. SAP ASE databases are mission critical workloads that require a low recovery point objective (RPO) and a fast recovery time objective (RTO). This backup service offers zero-infrastructure backup and restore of SAP ASE databases with Azure Backup enterprise management capabilities.

Key benefits of SAP ASE database backup

15-minute RPO with point-in-time recovery capability.
Striping to increase the backup throughput between ASE Virtual Machine (VM) and Recovery services vault
Support for cost-effective backup policies and ASE Native compression to lower backup storage costs.
Multiple databases restore options including Alternate Location Restore (System refresh), Original Location Restore and Restore as Files.
Recovery Services Vault that provides security capabilities like Immutability, Soft Delete and Multiuser Authentication.

SAP Testing Automation Framework (STAF)

While deployment automation frameworks like SAP Deployment Automation Framework (SDAF) have streamlined system implementation, the critical testing phase has largely remained a manual bottleneck – until now. We are introducing the SAP Testing Automation Framework (STAF), a new framework (currently in public preview) that automates high-availability (HA) testing for SAP deployments on Azure. STAF currently focuses on testing HA configurations for SAP HANA and SAP Central Services. Importantly, STAF is a cross-distribution solution supporting both SUSE Linux Enterprise Server (SLES) and RedHat Enterprise Linux (RHEL), reflecting our commitment to serve the diverse SAP on Azure customer base..

STAF uses modular architecture with Ansible for orchestration and custom modules for validation. It ensures business continuity by validating configurations and recovery mechanisms before systems go live, reducing risks, boosting efficiency, and ensuring compliance with standards.

You can start leveraging its capabilities today by visiting the project on GitHub at https://github.com/azure/sap-automation-qa. To know more about the framework please visit our blog: Introducing SAP Testing Automation Framework (STAF)

Azure Center for SAP solutions Tools and Frameworks

We are pleased to introduce three new dashboards for Azure Inventory Checks for SAP, enhancing visibility into Azure infrastructure and security. These dashboards offer a more structured, visual approach to monitoring health and compliance.

Here are the new dashboards at a glance

Summary Dashboard: Offers a snapshot of your Azure landscape with results from 21 key infrastructure checks critical for SAP workloads. It highlights your environment’s readiness and identifies areas needing attention.
Extended Report Dashboard: This view presents the Inventory Checks for SAP in a user-friendly dashboard layout, with enhanced navigation and filtering.
AzSecurity Dashboard: This dashboard presents 10 key Azure security checks to provide insights into configurations and identify vulnerabilities, ensuring compliance and safety.

These dashboards transform raw data into actionable insights, allowing customers to quickly assess SAP infrastructure on Azure, identify misconfigurations, track improvements, and prepare confidently for audits and reviews.

SAP + Microsoft Co-Innovations

Microsoft and SAP are continually innovating to facilitate business transformation for our customers. This year, we are strengthening our partnership in several areas including Business Suite, AI, Data, Cloud ERP, Security, SAP BTP, among others. Please ensure that you check out our blog to learn more about the significant announcements we are making this year at SAP Sapphire.

Introducing the SAP Testing Automation Framework: Elevating SAP System Testing on Azure

hdamecharla — Mon, 19 May 2025 15:00:00 GMT

In today’s fast-paced digital landscape, ensuring that enterprise systems perform flawlessly is non-negotiable. As businesses increasingly rely on SAP systems to run their critical operations, testing becomes an essential pillar of operational excellence. Traditionally, SAP system testing has been manual, time-consuming, and prone to gaps. Addressing these critical aspects, Microsoft has introduced the SAP Testing Automation Framework (STAF), an open-source orchestration tool developed to validate SAP deployments on Microsoft Azure. It enables you to assess system configurations against SAP on Azure best practices and to automate various testing scenarios, with an initial focus on high availability (HA) testing.

What is the SAP Testing Automation Framework?

The SAP Testing Automation Framework is an open-source orchestration tool engineered to validate SAP deployments on the Microsoft Azure platform. Its core purpose is to help customers ensure their SAP systems run smoothly by proactively identifying potential issues. It achieves this by simulating system failures, verifying that configurations adhere to best practices, and automating the entire testing process to save time and improve accuracy.

The framework is built on a modular, configuration‑as‑code model using standard tools. The tests are defined in version‑controlled Ansible playbooks, and custom Python modules handle in‑depth checks of both your SAP systems and Azure resources.

Key Features:

Configuration Validation: It checks whether the configurations of SAP HANA scale-up or SAP Central Services align with established SAP on Azure best practices and guidelines.
High Availability Functional Testing: It simulates multiple test cases to ensure that the failover mechanisms are effective. With SAP HANA databases and SAP Central Services as prime examples, this testing validates that when a component fails, the system can gracefully recover without disruption. This helps identify potential issues during new system deployments.
Detailed Reporting: The framework collects detailed telemetry from SAP components and test execution where it captures event sequences, detection timings, failover durations, and system responses. It compiles this data into a comprehensive HTML report with clear pass/fail outcomes and timestamps. Optionally, you can stream logs to Azure Log Analytics or Data Explorer.
Extensible and Pipeline-ready: All framework operations, Ansible playbooks, and custom python modules are defined as code, making them ideal for integration with CI/CD pipelines. You can invoke STAF immediately after your deployment and installation step via SAP Deployment Automation Framework, running comprehensive HA tests before promoting changes.

SAP System High Availability Functional Testing

The initial and most prominent capability of the SAP Testing Automation Framework is its comprehensive High Availability (HA) functional testing for critical SAP components hosted on Microsoft Azure. The framework targets scenarios involving SAP HANA scale-up database and SAP Central Services (ASCS/SCS) deployed in a two-node cluster on SUSE Linux Enterprise Server (SLES) or Red Hat Enterprise Linux (RHEL), providing a cross-distribution solution for our diverse SAP on Azure customer base. For supported configuration, see support matrix.

The SAP Testing Automation Framework employs a systematic approach to validate the robustness of SAP system HA setup. It verifies the configuration and captures the entire sequence of events in an HA scenario: from initial failure detection, through isolation of the faulty component (including fencing), to resource migration, service recovery on the standby node, and implicitly, the consistency of data upon successful recovery. Upon completion of the tests run, STAF compiles results into a clear, HTML‑based report that details configuration compliance checks and functional test outcomes, complete with timestamps and pass/fail statuses. The report also includes logs from /var/log/messages to provide context.

HTML Report after completion of the run

This comprehensive validation of the HA process flow is fundamental to building confidence in the resilience of the SAP system on Azure.

Getting Started with the SAP Testing Automation Framework

The SAP Testing Automation Framework is available as an open-source project on GitHub for the community to use and contribute. You can find the code and documentation in the official repository: Azure/sap-automation-qa: This is the repository supporting the quality assurance for SAP systems running on Azure.. The project is currently in a public preview stage. So, feedback and contributions are welcome to help improve its capabilities.

To start using the framework, you have a couple of options depending on your environment:

SAP system manually deployed (not using SDAF): If you want to validate manually configured high availability of SAP system, you can run the framework in a standalone mode. This involves deploying the management server (for example, an Ubuntu VM that will orchestrate the tests), configuring it with details of your SAP landscape (cluster nodes, IPs, etc.), and then executing the provided playbooks or scripts to run the HA tests. The repository provides guidance on how to configure the necessary variables and run the test scenarios for a Pacemaker cluster environment.
Integration with Deployment Pipelines: For those who already use automated deployment tools like the SAP Deployment Automation Framework (SDAF) for Azure, the testing framework can integrate directly into those pipelines. The framework is designed as a natural extension to SDAF, so it can leverage the same configuration context and Azure resources defined during deployment. This allows you to embed HA testing into your continuous delivery process, every time you deploy or update an SAP environment, the pipeline can automatically run the HA tests and surface any issues before you even hand the system over to end-users or application teams.

Call to Action & Community Engagement

The SAP Testing Automation Framework, in public preview stage, is a significant step forward in reducing misconfigurations and manual effort in high availability deployment of SAP system on Azure. We encourage you to explore the framework, share your feedback, or contribute. During this public preview, we recommend using framework for new greenfield production high availability deployments that are not yet live, or on non-production environments.

Appendix and References

Join Microsoft at SAP Sapphire 2025

Hiren_Shah_Azure — Tue, 13 May 2025 15:00:00 GMT

I’m thrilled to be back at SAP Sapphire this year alongside my colleagues from Microsoft! Sapphire is an event I always look forward to as it provides a great opportunity to celebrate the successes of our customers and partners as well as share big announcements and product updates. Whether you’re joining us for pre-day events, engaging in sessions during Sapphire, or enjoying the networking opportunities, there’s something for everyone. Read on to learn more about what’s in store:

Previewing exciting innovation for SAP on the Microsoft Cloud

Data & AI: At Sapphire, we will be sharing key updates on SAP Business Data Cloud (BDC) on Azure and how you can use Azure Databricks with SAP BDC. We will also be sharing the progress on the joint integration between Microsoft Copilot and SAP Joule, helping accelerate business outcomes and increase end-user productivity.

SAP BTP on Azure: Together with SAP, we are ensuring our customers can use the latest SAP Business Technology (BTP) services on Microsoft Azure in their preferred regions. We are excited to share the launch of two new datacenter regions for SAP BTP on Azure – Canada (Toronto) and China (Hebei). With this announcement, SAP BTP is now available in 10 Azure datacenter regions, including Brazil, launched late last year. Thanks to incredible demand from our joint customers, SAP has also added several additional BTP services on Azure. New services include SAP Build Apps, SAP Build Code, SAP AI Core and Joule. You can view all the existing BTP services and regions on Azure on the SAP Discovery Center. To stay up-to-date on future plans for service and region roll-out, visit the SAP roadmap explorer.

RISE with SAP Customer Spotlight – Nestlé: This multinational organization with over 2,000 brands in 188 countries has operations that are as large as they are complex. Nestlé executed one of the largest RISE with SAP migrations in the world on Azure where they could build a future-ready enterprise, leveraging AI-driven solutions. Their need for a platform that could deliver innovation and reliability at scale along with a robust infrastructure made Azure the clear choice. To hear more about their transformation story, make sure to attend the session at Sapphire: Nestlé’s journey from SAP on-premises to RISE with SAP on Microsoft Azure.

Join us at SAP Sapphire 2025

Sessions you don’t want to miss

We’re bringing a dynamic lineup of 10 in-person sessions across both Orlando and Madrid, featuring insights from Microsoft and SAP experts. Don’t miss the chance to dive into the latest on RISE with SAP, SAP Business Suite, SAP BTP, and Data and AI on the Microsoft Cloud—plus hear real-world stories from customers who are already driving results through the Microsoft and SAP partnership. Register now using the links below.

Session

Number

Date and Time

Nestlé’s journey from SAP on-premises to RISE with SAP on Microsoft Azure

PAR1165

Wednesday, May 21

2:30pm-2:50pm EDT

Microsoft Federal’s cloud landscape transformation with SAP NS2

SER2695

Tuesday, May 20

4:30pm-4:50pm EDT

Unlock innovation for SAP ERP with AI, SAP BTP, and more on Microsoft Azure

PAR1166

Wednesday, May 21

2:00pm-2:20pm EDT

Accelerating procurement transformation with SAP Ariba solutions

SPM2624

Wednesday, May 21

2:00pm-2:20pm EDT

Joule and Microsoft 365 Copilot: AI-enabled productivity in action

BAI2594

Tuesday, May 20

11:30am-11:50am EDT

(Madrid) - Modernizing the SAP Software Landscape at ANDRITZ

PAR1307

Wednesday, May 28

11:30am - 11:50am CEST

ASUG Pre-Day Sessions

Harnessing SAP's AI Innovations: Joule, Generative AI, and Business AI

ASUG104

Location:

S320GH

Monday, May 19

1:00pm-5:00pm EDT

ASUG Power Peer Group

Unlock the value of SAP BTP: Lessons learned from ASUG members

BTP3093

Location:

ASUG Booth Theater

Tuesday, May 20

2:00pm-2:40pm EDT

Celebration night!

We are excited to be the exclusive sponsor of the celebration night concert, which is always a highlight at Sapphire. The evening will feature two special performances by the Zac Brown Band at the American Garden Theatre at Epcot®, scheduled for 8:15 PM and 9:45 PM. Come celebrate with us!

Come find us at our booth!

Microsoft and SAP are at the forefront of AI transformation and are excited to showcase the interoperability of our AI agents at Sapphire. The video below shows a sneak peek of what’s possible but if you’d like to learn more, come talk to our subject matter experts from Microsoft on-site to help address any questions and foster connections.

Find us at Booth #409 in Orlando and Booth #9.333 in Madrid

Networking Events

Beyond the sessions and booth experiences, our partners are hosting special social and networking events you can join:

We are looking forward to a great Sapphire and I hope to see you there!

SAP Content Server 7.54 on Windows with FileServer as Document Store

AnjanBanerjee — Wed, 25 Mar 2026 20:59:26 GMT

1. Introduction

This blog provides the deployment procedure for setting up High Availability (HA) and Disaster Recovery (DR) for SAP Content Server 7.54 on Windows Server. The SAP Content Server offers document storage either in an SAP MaxDB database or in the file system. When opting to store documents in the file system, the installation of SAP MaxDB is not required. In this guide, we will use FileServer as the document store and configure it using Azure Shared Disk.

2. System Design

Following is the overall high-level design of the SAP Content Server environment with HA & DR which is described in this blog.

The above design is based on Availability zones and provide VM level availability SLA of 99.99% for the HA pair in the Azure Primary region. For Disaster Recovery setup, we can choose the desired secondary Azure region and setup the Azure Site Recovery to continuously replicate the primary region HA setup of SAP Content Server with Shared disk as File Server.

Following are the details for each of the components of the setup:

2.1 SAP Content Server

SAP Content Server 7.54 is the latest version and used for this setup. It is recommended to always use the latest released version and patch level of SAP Content Server for new installations. Refer to SAP Note 719971 to get latest information on SAP Content Server release strategy and product version.

2.1.1 HA Setup – This is achieved by installing SAP Content Server in Windows WSFC Clustered environment between two VMs across Availability Zones. Virtual IP for the SAP Content Server Instance is maintained as frontend IP in Azure Load balancer. SAP Content Server will have one premium data disk for local ‘usr_sap’ files and one premium shared disk for ‘sapmnt’ and ‘global’ shares. To configure quorum for WSFC failover cluster, Cloud Witness should be created in ZRS Storage account. In the Windows firewall of both VMs, open the load balancer probe ports and SAP content server ports. Refer to TCP/IP ports of All SAP Products.

2.1.2 DR Setup – Azure Site Recovery is used to continuously replicate the VMs, all the configurations and the data in it, to another region. To replicate VMs using ASR for DR, review supported regions. Its recommended to build the azure landing zone in the DR region including Vnets, subnets, IP ranges before configuration of ASR replication. Azure load balancer and cloud witness must be pre-deployed for DR failover.

As of time this blog was written , ASR for VMs with azure shared disk on Windows Server is in public preview. Please refer to the link for updates on GA. Using Azure Site Recovery for Azure shared disks, you can replicate and recover your WSFC-clusters as a single unit throughout the disaster recovery lifecycle, while creating cluster-consistent recovery points that are consistent across all the disks (including the shared disk) of the cluster. For more information, see Shared disks in Azure Site Recovery.

ASR create recovery points (both application and crash) that are consistent across all the virtual machines and disks within the cluster. However, during public preview only crash consistent and the latest recovery processed recovery points are supported. For more details on some of common concerns, see FAQs - Shared disks in Azure Site Recovery

Also, default settings for Defender including Realtime scan should work well with Content Server. If high CPU utilization due to Defender is observed, open a support case with Microsoft via the Defender Portal.

2.2 Fileserver for Document Store

This setup is using Azure Shared disk – Premium SSD ZRS as Fileserver to store documents. Zone redundant storage (ZRS) replicates managed disk across all the three availability zones. It is advised to choose the right size of the disk as Azure Shared disk resizing requires shutting down of associated VMs. Also refer to limitations of premium Azure shared disks .

2.2.1 HA Setup – We will be creating File server role in WSFC Cluster for this shared disk so that its highly available as Windows Fileserver. Fileserver name will be mapped to Load balancer virtual IP, to make it available on either of the VMs. File Server ports do not need to be exposed outside the SAP Content Server cluster nodes. SAP Content Server must be able to access highly available FileServer using port 445.

2.2.2 DR Setup – ASR for Azure shared disk will be used for continuously replicating the documents to the DR region and available as highly available fileserver during DR failover. ASR will also perform the reverse copy from DR region to primary region and then failback the environment once primary region is available. Azure loadbalancer in the DR region is to be used for configuring the virtual IP.

3. Overview of Deployment Steps

Following are the high-level steps which are described in the blog.

Preparations
WSFC Cluster setup and configuration
SAP Content Server Setup
WFSC Fileserver setup
Connect SAP Content Server with S/4 HANA or Business Suite 7
High Availability Test
Disaster Recovery Setup with ASR and
DR failover and failback

4. Preparations

Read the required Installation Guide, SAP Notes, SAP on Azure docs and download the installation media.
Deploy the VMs (of desired SKU) in Availability Zones and Choose Operating System as Windows Server 2022.
Add data disk of required size to each of the VMs.
Create 2 Azure Shared disks and attach it to both VMs.
Disk 1 for SAP Content Server
Disk 2 for FileServer as document store
Join the SAP Content Server VMs to the Domain.
Define Page File in Temp Disk (D Drive).
Check that necessary Ports (including ILB Probe ports) are open in Windows firewall.
Disable the Continuous Availability Feature in Windows using the instructions in this link.
Create an Azure Storage account ZRS for cloud witness.

5. WSFC Cluster Setup and Configuration

Create load balancer for virtual IPs of SAP Content Server Instance and File Server. Create A-record in DNS for virtual IPs and virtual hostnames.

Front-end IP

Backend Pool

Health probe port

Load balancing rule

10.90.95.15

(Virtual IP of SAP Content Server)

VM1 & VM2 hosts

62400

Enable HA Port,

Enable Floating IP,

Idle Timeout (30 Minutes)

10.90.95.16

(Virtual IP of Fileserver)

VM1 & VM2 hosts

62450

Enable HA Port,

Enable Floating IP,

Idle Timeout (30 Minutes)

Refer to the section Create Azure Internal Load Balancer

Add the KeepAlive registry entries

Refer to the section Add registry entries on both cluster nodes

Deploy WSFC Cluster and add cloud witness

Refer to the section Install and Configure Windows Failover Cluster

Specify the SID of Content Server, VM names in the PowerShell script to Install and Configure cluster.
Specify the Azure Storage account and Access Key to Configure Cluster cloud quorum
Alternatively, we can perform deploy WSFC Cluster and add cloud witness from Failover Cluster Manager.
Update cluster parameters

Adjust the following WSFC Cluster parameters

- SameSubNetDelay = 2000
- SameSubNetThreshold = 15
- RouteHistoryLength = 30

Refer to section Tune the Windows Failover Cluster thresholds.

Verify that Azure Shared disk is added to the cluster and status is online.

If the Azure Shared disk are not added to the WSFC Cluster then we can add them either by ‘Add Disk’ option in Failover Cluster Manager or by using PowerShell commands as described in Format the shared disk with Powershell.

6. SAP Content Server Setup

Run SWPM on 1^st VM

Start the installation of SAP Content Server on First Cluster Node.

Choose the local disk’s drive letter

Enter the virtual hostname of the content server as defined in the DNS with the virtual IP. Apart from entering SID for SAP Content Server, also select the azure shared disk for SAP Content Server which is already part of WSFC cluster disk.

Continue with other SWPM input parameters to install SAP Content Server on First Cluster Node.

Choose SAP Content Server to be installed.

Provide the instance number of SAP Content Server

Specify the SAP Content Server basic parameter values

And complete the installation on First Node.

Add probe port to the cluster parameter

Probe port defined in the Azure Load balancer for SAP Content Server need to be updated for SAP Content server SID Role in the WSFC Cluster configuration. This will enable virtual IP connection to the SAP Content Server. Follow the instructions in section “Add a probe port” in the link Install SAP NetWeaver HA on a Windows failover cluster and shared disk for an SAP ASCS/SCS instance in Azure

Validate the probe port in the cluster configuration (as shown in the below example screenshot)

Stop and Start the SAP Content Server Role in WSFC cluster.

In case not performed earlier, Add windows firewall rule to allow inbound connection to probe port on both VMs.
SWPM setup for SAP Content Server second Node

Choose the local disk’s drive letter

And continue with SWPM installation steps.

7. WSFC File Server Setup

Create the File Server in WSFC Cluster
In the ‘Actions’ section in ‘Roles’ tab, click on ‘Configure Role’.

Choose ‘File Server’ as Role and click ‘Next’.

In next screen for File Server Type, choose ‘File Server for general Use’ and click ‘Next’.
Enter the name of the fileserver as defined in the DNS (along with Virtual IP). Click Next.
In the ‘select storage’ screen, choose the cluster disk(azure shared disk) for FileServer. Click ‘Next’ and continue with the setup.
Update the cluster settings in the File Server Role.

Change the Name to ‘<File Server Role Name> IP’. Choose the Network from drop-down. Update the static IP address field with virtual IP defined for File Server.

Stop and start the Role.

Update the probe port parameter in the Cluster settings. Follow the probe port changing steps in the ‘Add a probe port’ section in the ‘SAP Content Server Setup’ in this blog.

Make sure that in this step we change the probe port for FileServer Role/IP in the cluster and not for SAP Content Server Role/IP.

Stop and Start the File Server Role.

Validate that File Server role is online.

8. Connect the SAP Content Server with S/4 HANA System

Update the connection details in content repository.

In the S/4 HANA or Business Suite 7 system, run the tr. Code OAC0. Select the content repository name for SAP Content Server.

Update the HTTP Server, port numbers.

Ensure content server related inbound ports are open in windows firewall.

For HTTPS setup, export the PSE of content server from ‘SAP Content Server Administration’ portal and import it in S/4 HANA system under certificate list in ‘System PSE’ and ‘SSL Server Standard’ section.

Update the repository settings

Click on ‘CS Admin’ as in the previous screenshot. Add/update the parameters (as below) to specify the document storage location as File Server.

Check that connection tests are successful.
Refer to SAP Note 2457912 – How to create Content Server Repository in OAC0.

9. High Availability Tests

We can perform following WSFC failover tests for SAP Content Server and File Server for document storage.

For all the below tests, we should validate that

- Cluster Roles are online after failover,
- SAP Content server is running using the link

https://<virtual hostname>:1091/sapcs?serverInfo

- In S/4HANA tr code OAC0, connections test is working after failover.

Test Scenarios:

SAP Content Server system and File Server can successfully fail over from node 1 to node 2 and vice-versa. We can use Failover Cluster Manager to perform the failover (move the role to another node) and check the status after failover.
Restart the Windows guest operating system in which SAP Content Server is active. This initiates an automatic failover of the SAP Content Server cluster group from active node to second node. Perform the same action for active node for File Server.
Restart the VM from Azure portal and using Azure PowerShell, in which SAP Content Server is active. This initiates an automatic failover of the SAP Content Server cluster group from active node to second node. Perform the same action for active node for File Server.

10. Disaster Recovery Setup with ASR

To configure ASR for VMs running SAP Content Server with Azure shared disk, you need to follow below steps :

Set up Resource Group, Virtual Network, Subnet and Recovery Service Vault in the secondary site that you would use in setting up your DR. To learn more about networking, see prepare networking for Azure VM disaster recovery.
Before enabling ASR on SAP Content Server VMs, it is essential that WSFC is configured, and Azure shared disks are managed by the cluster.
Configure ASR for SAP Content Server with Azure shared disk by following the steps in the Shared disks in Azure Site Recovery document. Follow Configure replication for Azure VMs in Azure Site Recovery to configure ASR for SAP application servers.
When you use ASR to set up DR for VMs, the VM’s OS, data disks, and Azure shared disk (for SAP Content Server VMs) are copied to the DR site.
NOTE: With Azure shared disk, SAP Content Server VMs will be grouped together in ASR. This way, the VMs in the group will replicate together to have consistent recovery snapshot. In the event of a failover, the VMs will fail over as a group.
After the VMs are replicated, the status of protected cluster and SAP Content Server VMs would turn into “Protected” and the replication health would be “Healthy”.
Deploy Azure Load Balancer without backend pools as SAP Content Servers VMs are not available in DR region. Keep the health probe ports same as primary site health probe ports.

Front-end IP

Backend Pool

Health probe port

Load balancing rule

10.72.76.15

(Virtual IP of SAP Content Server)

VM1 & VM2 hosts

62400

Enable HA Port,

Enable Floating IP,

Idle Timeout (30 Minutes)

10.72.76.16

(Virtual IP of Fileserver)

VM1 & VM2 hosts

62450

Enable HA Port,

Enable Floating IP,

Idle Timeout (30 Minutes)

Deploy Cloud Witness Storage account of ZRS type in the DR region.
When VMs without public IP addresses are placed in the backend pool of the internal standard load balancer, there would not be any outbound connectivity from these VMs, unless additional configuration is performed to allow routing to public end point. For details on how to achieve outbound connectivity see public endpoint connectivity for Azure VMs & Standard ILB in SAP HA scenarios.

Tip: Based on your DR strategy, you can either execute the step to deploy load balancer and cloud witness step when you are preparing your DR site like setting up ASR or you can execute at the time of the DR failover process.

11. Disaster Recovery Failover and Failback

We will perform the failover to the DR region of the SAP Content Server and File Server, start the cluster services for SAP Content Server and File Server, verify its configuration and connection. Then we will ‘commit’ the Failover in ASR.

Afterwards we will re-protect the VMs to start the ASR replication process from DR region to primary region, Failover (failback) VMs from DR region to primary region, start the cluster services for SAP Content Server and File Server and verify its configuration and connection.

Finally, with ASR, we will re-protect the VMs in primary region to continue with the ASR replication process from primary to DR region.

11.1 Failover to DR Region

Before triggering the failover of SAP Content server, ensure the Domain Controller could be accessed from the DR region.
Initiate the Failover for recovery group of the SAP Content Server.
If the VMs were online on the primary site then ASR will show same consistent recovery point for both VMs. Select the Recovery point for the cluster/recovery group and continue with the failover. Refer to the documentation for Recovery point is consistent across all the virtual machines.
If one of the VM in the recovery group is unavailable for some time, then Select an individual recovery point for the VM that are not part of the cluster recovery point. Refer to the documentation for Recovery point is consistent only for a few virtual machines
After the failover, the status of replicated items will be ‘Failover Completed’. VMs will be online on the DR region and primary site VMs will be shutdown (if the shutdown checkbox is selected during failover).

Update the backend pool of DR region’s Azure Load Balancer with the VM details.
Update the DNS entries for SAP Content Server VMs and virtual hostname for SAP SID and File Server, with the new IP address in the DR region.

Virtual Hostname	Description	Virtual IP Address in Primary region	Virtual IP Address in DR region
cs9ha	for SAP content server	10.90.95.15	10.72.76.15
cs9fileserver	for FileServer	10.90.95.16	10.72.76.16

Change the Cluster quorum to the cloud witness storage account created on the DR site. Use Failover Cluster Manager tool to update the Cloud Witness details.
Update the virtual network and virtual IP of the SAP Content SID and File Server in the Failover cluster Manager.

Restart the Cluster Roles.
Update the SAP Content Server virtual IP into the DNS used S/4 HANA or ECC system.

Virtual Hostname	Description	Virtual IP Address in Primary region	Virtual IP Address in DR region
cs9ha	for SAP content server	10.90.95.15	10.72.76.15

Perform the WSFC Cluster Failover tests and connect tests in tr code OAC0. Refer to SAP Note 2457912 for testing connections to SAP content server in tr code OAC0.
Once all checks are successfully completed, ‘commit’ the failover in replicated items in recovery service vault.

11.2 Failback to Primary Region

Once the former Primary Region is available, we can ‘Re-protect’ the recovery group in the recovery services vault. This step will start replication of all the components of ASR recovery group from DR region to former Primary region.
Once status of the replicated items is ‘protected’, we can plan to failback the SAP Content Server. Follow the same steps as described in the previous section to ‘failover’ to former primary region like checking the DNS settings and update the cluster setting.

Once the failover to former primary region is successfully completed, ‘re-protect’ the replicated items in the recovery services vault to restart the replication from primary to DR region.

Simplifying Vertex Tax Software Deployment with Oracle Database@Azure

anbugovi — Mon, 17 Mar 2025 15:00:00 GMT

Co-Authors

Scott Gamble, Frank Kassanits, Suresh Devarajan, Momin Qureshi, Venkat Ramakrishnan, Ross Sponholtz & Anbu Govindasamy

In this blog, we will explore how to leverage Oracle Database@Azure for Vertex Tax Software, which is part of the SAP solution. Oracle Database@Azure is an Oracle database service that runs Oracle databases on Oracle Cloud Infrastructure (OCI) within Microsoft datacenters, ensuring the fastest possible access to Azure resources and applications.

Oracle database can be deployed on Azure VM as an IaaS solution or as an Oracle Database@Azure service just like other Azure services. Each approach has its own merits. In this blog, we will discuss the Oracle Database@Azure solution and how it simplifies and accelerates the deployment and maintenance of Oracle Databases on Azure. While Oracle Database@Azure is not currently supported solution for running SAP systems, at the same time, Oracle Database@Azure can be leveraged with non-SAP products.

Oracle Database@Azure - Architecture of the implemented Vertex Tax solution

Please find below the implementation architecture corresponding to the Vertex Tax solution implementation on Oracle Database@Azure – Oracle Exadata database service, followed by focus on Networking, Architectural considerations for coming up with a similar architecture for your needs.

Oracle Database@Azure - Networking Considerations

When you design your network topology for the Oracle Exadata Database service on Oracle Database@Azure, please refer to the Microsoft Cloud Adoption Framework – Landing Zone Accelerator.
It is critical to understand the core networking design considerations and recommendations applicable for your environment along with the best practices for configuring and managing the Azure network as required for connecting your applications to the database.
In the above architecture, each application virtual network is directly peered to the database virtual network. Application and database virtual networks connect to a hub network for shared services like firewalls or Domain Name System (DNS).
This design helps ensure low-latency direct communication while enabling centralized traffic inspection and management. Reference diagram provided below as well.

Oracle Database@Azure - Architectural Considerations

Deployment Approach: The Vertex Oracle Database is deployed on Oracle Database@Azure Exadata database service, while the Vertex Application Servers are hosted on Azure as an Infrastructure as a Service (IaaS) solution.
Landing Zone: The Azure Landing Zone architecture implements a hub-and-spoke network pattern. Both SAP and Vertex share a single landing zone and subscription, while Oracle Database@Azure is deployed to its own separate landing zone and subscription.
Network: The database VNET is peered with the application VNET hosting Vertex, allowing communication between the Oracle database and Vertex application. The database VNET is also peered with Hub VNET for migrating data from on-prem and setting up DR with DR region.
Migration: Oracle Data Guard is used for one time database migration, ensuring minimal downtime and seamless transition.
HA/DR: High Availability setup between zones by leveraging Oracle Data Guard (ODG) with FSFO. ODG is also part of DR solution.
Existing Oracle Database software customers can use the Bring Your Own License (BYOL) option or Unlimited License Agreements (ULAs).

Oracle Database@Azure Benefits

Given that you can now deploy and use Oracle database services running on OCI within the native Azure portal and APIs, you benefit from an OCI-in-Azure-like experience. Here are some of the key benefits of Oracle Database@Azure.

Optimized performance and sub millisecond latency between app and data by running Oracle Databases on Oracle Cloud Infrastructure (OCI) hosted in Azure datacenters.
SLA, Feature and Price parity with Oracle Cloud Infrastructure, along with a collaborative support model with Oracle.
Native integration with Azure services like Microsoft Entra ID for identity and access management, Azure Kubernetes Service (AKS), and Azure AI/ML services. Azure vnet provides secure connectivity.
Seamless integration with existing applications and infrastructure, maintaining operational consistency.
Exadata provides extensive automation for installation, upgrades, and patching, reducing manual efforts.
The Exadata database service allows for co-management and scale-out of infrastructure with ultra-low lead times while the customer continues to benefit from database-optimized compute, networking, storage associated with Exadata.
On-premises operational procedures, automation, and best practices can be ported to Azure without losing any knowledge base, ensuring quicker adoption.

QuickStart - Oracle Database@Azure – Exadata service

To begin your Oracle Database@Azure journey, reach out to the Oracle sales team or your Oracle sales representative. They will assist you in creating a private offer for the Oracle Exadata database service on the Azure Marketplace. Once the offer is ready, you can accept it and complete the purchase directly through the Azure Marketplace in the Azure Portal.

After completing the purchase, you can provision the Oracle Exadata Database service for Oracle Database@Azure using the Azure portal, Azure APIs, SDKs, and Terraform.

For more detailed information on additional Azure region availability, design consideration and onboarding details please refer to Getting Started.

Conclusion

The deployment of the Exadata Database service on Oracle Database@Azure for Vertex Tax Software simplifies Oracle database deployment, management and operation. In our experience, On-premises operational procedures, automation, and best practices can be ported to Azure without losing any knowledge base, ensuring quicker adoption.

Use Premium SSD v2 with SAP

RobertBiro — Fri, 07 Mar 2025 17:37:29 GMT

Premium SSD v2 is available to Azure customers with a broad set of features and benefits. In this article we will highlight the options available to best use Premium SSD v2 disks for SAP workloads.

Premium SSD v2 basics

Different storage options are available depending on the requirements. Premium SSD v2 differs from the long-established Premium SSD by providing you with more options and modified pricing for each of these options. The main differences over Premium SSD are:

Up to 1200 MB/s throughput, low latency, up to 80k IOPS and 64 TiB in size
Any disk size from 1 GiB to 64 TiB in 1 GiB increments with per GiB pricing
Throughput and IOPS configurable and adjustable online
125 MB/s and 3000 IOPS provided as baseline
No disk bursting, no host caching and no Write Accelerator with Premium SSD v2
Cost based on selected size + IOPS + throughput

While with Premium SSD you have set disk sizes or SKUs, which combine billed capacity with set throughput and IOPS limits, with Premium SSD v2 you can freely set each of the three parameters independently. You want a 20 GiB disk with 1000MB/s throughput and 20k IOPS? No problem. You want a 5 TiB disk with 200 MB/s and 3k IOPS? Just set the values and Azure will bill you accordingly. If you compare with Premium SSD, Premium SSD v2 will be cheaper if configured with identical size and throughput.

This means for your SAP workloads, you can provide both faster overall performance and tune the storage parameters to match your requirements, while adding flexibility. See the Azure documentation for details on Premium SSD v2.

One important aspect to consider is that current time Premium SSD v2 can only be attached to zonal VMs, that is VMs with a set zonal deployment. If your SAP landscape is deployed with regional VMs – with or without availability sets – this is not supported at publish time of this blog post. See the documentation details for updates.

SAP use cases with Premium SSD v2

Where can you use Premium SSD v2 with your SAP workloads? In short, for all situations. Premium SSD v2 is certified for use with SAP workloads – SAP note 2015553 – and also noted in individual SAP certification for SAP HANA. It can be used for your application layer such as (A)SCS and application servers, your database servers and any infrastructure servers.

Premium SSD v2 for SAP applications and infrastructure servers

For SAP application layer and any generic infrastructure servers (such as DNS, saprouter, etc.), you can utilize Premium SSD v2 for all data disks. One expected benefit is that you can configure disk sizes with 1 GiB increments, no longer x2 increases in size. If you need an 80 GiB disk containing /usr/sap physical volume, you set and pay for 80 GiB. Set IOPS and throughput as needed, if more than baseline is required.

Premium SSD v2 for SAP HANA

For SAP HANA, Azure documentation provides a recommended starting configuration with Premium SSD v2. As this is a starting configuration, you might need to modify the parameters for size, throughput and IOPS to fit your needs.

As there is no host caching available with Premium SSD v2, host (VM) caching setting for disk must be set to None. This also means that write accelerator caching for HANA log disk(s) is neither available nor should it be needed to meet SAP’s HANA I/O requirements.

No host caching means no write accelerator, which in turn opens a very easy way to use E-series VMs for SAP HANA for smaller memory sizes with only this disk type. Premium SSD v2 performs with low latency for IO, which fulfil SAP HANA requirements.

Premium SSD v2 for non-HANA databases

Every supported SAP database vendor is fully supported and documentation is available with a recommended starting configuration and DB specifics, if any apply.

You can right-size every filesystem of an SAP database, to the exact GiB required and without any fixed disk sizes. Same for IOPS and throughput requirements. Databases often have many different filesystems with different growth and performance requirements, such as archive logs, temporary tablespace locations, undo data , etc. depending on database deployed.

Non-HANA databases with Premium SSD disks can greatly benefit in specific situations from available host caching type readOnly. Host caching can accelerate many I/O requests on these databases. Host caching is not available for Premium SSD v2, which can require you to adjust the needed disk IOPS or throughput sizing for some disks. There is no one-size-fits-all solution. Analyze the workload, see the available Azure documentation for your database vendor and tune managed disk parameters.

Azure provides numerous performance metrics on the used infrastructure, giving you a very transparent view into any existing bottlenecks. For a database centric view, create an Azure Monitor dashboard or workbook to view the VM and individual disk data.

As an example, below is a workbook of a DB VM, with metrics for the VM and disk.

For storage performance evaluation, look at the following metrics:

VM
- IOPS and bandwidth consumed percentage for VM overall
  cached | uncached | disk overall
Disk
- Disk read/write IOPS and throughput
  for multi-disk stripe sets, a single disk indicates same usage level of all members
  Several Premium SSD disks metrics include IOPS/bytes from the cache

If you have SAP running in Azure already, it’s likely using Premium SSD and you can see caching usage. You can also leverage machine learning to analyse your disk performance. You can also use Copilot to troubleshoot your disk performance and display disk bottlenecks. As with any AI generated advice, consider if the findings are appropriate.

Premium SSD v2 single disk vs striping

For SAP workloads when using Premium SSD, to reach the necessary performance for database VMs, many customers deploy multiple disks and stripe over them using lvm or Windows storage spaces. Such stripe set combines the throughput and IOPS of individual disk members. With Premium SSD, without depending on bursting, the disk SKU sets the throughput and IOPS limits and can be insufficient on some filesystems.

With Premium SSD v2, you have much higher limits for a single disk – 1200 MB/s throughput and upto 80k IOPS – and can specify the values independent of the disk size. The choice of using a single disk or split the aggregate performance requirements between multiple disks in a stripe sets is yours to make.

With striping, you have to correctly set logical volume manager’s volume group settings on stripe size and count and keep all disks equal in size and performance. You do have the following advantages with this

VM storage limits are increasing with every generation
Premium SSD v2 gives each disk a baseline of 125 MB/s and 3000 IOPS

As an example, consider the situation of wanting /hana/data filesystem to provide 2 TiB size, 1000 MB/s and 20000 IOPS.

As option 1, you can deploy a single disk with required parameters.

As option 2, using striping you:

Deploy 4 disks, set up a volume group
Each disk 500 GiB
As baseline over the 4 disks, you have 12k IOPS and 500 MB/s in aggregate
Add to each of the 4 disks an additional +2k IOPS, for a total of 5k and +375 MB/s for a total of 500MB/s, on each of the 4 disks. Giving you the required performance and size.

The choice to-stripe-or-not is yours to make, as per your workload needs. Consider the support for Premium SSD v2 overall, how does this affect services like backup or disaster recovery and if using striped disks breaks such support.

If striping, keep the number of disks in volume group to a sensible number. Common choice is four disks for data and two for log areas. Such disk counts should be sufficient even for large databases, for very large (>20TB sizes) do not use more than 8 disks for database data and 4 disks for data log areas or other disks, unless recommended by Microsoft. These are recommended maximum disk counts for any stripe set in Azure for SAP, which should only be exceeded in exceptional circumstances only.

Start using Premium SSD v2 for SAP

You want to use Premium SSD v2. Great. How do you best do it for SAP workloads?

Decide first on your migration path from the three options available:

With the first option (01) of building new VMs with Premium SSD v2, you are either new to Azure or want to build a new SAP environment for a clean start. Maybe using own automation pipeline to deploy Azure resources, such as SDAF. Once the new VMs are created, copy the SAP workloads through application means – backup/restore, system copy etc.

This approach allows you to right-size your disk capacity and performance parameters from the start and set everything according to best practices, starting fresh with Premium SSD v2.

---------------------------------------------------------------------------------------------------------

The second option (02), you already are using Premium SSD or other storage type in Azure and want to switch to Premium SSD v2. But you want to make some architectural changes. Maybe you want to resize disks smaller than currently. As you can online increase managed disks (see blog post for details), you can’t reduce size. Maybe you want a different storage setup.

This approach uses the above steps and gives you the following benefits:

OS and software configuration needs no changes
Fix / Update on past storage architecture
Right-size disks and disk count, often reducing storage size

Copying the data from old to new disks is a downtime activity for databases. Consider temporarily upsizing the Azure VM, if limited by total VM storage throughput. Once copy is completed, the source disks should not be needed. Adapt your disk mounts, ensure all data was copied and unmount and eventually delete the source disks.
---------------------------------------------------------------------------------------------------------

The third option (03) is to change the existing disks into Premium SSD v2. This option has its own benefits and drawbacks. While it is a downtime activity – you can’t convert a disk when it is attached to a running VM – you get to keep the same resource name and OS setup. At same time, as you convert existing disks, you can’t reduce the disk size in any case, neither can you reduce the disk count for multi-disk volume groups.

Use the disk change option via any means – portal, API or CLI – you need to be aware of any additional limitations for Premium SSD v2. The key points, current at the time of publishing, are:

Limit of 50 active conversions at same time per subscription and region
Host (VM) caching needs to be disabled for the disk
Conversion process is a background activity. You will have degraded performance for the duration of this background copy on the specific disk. CompletionPercetage property is available to check on status on each disk.

A combination of options (02) and (03) is the creation of new Premium SSD v2 disks from snapshots. A snapshot of another disk is taken as source, be it a Standard or Premium HDD/SSD or another Premium SSD v2 disk. Then a new Premium SSD v2 disk is created, with the snapshot as the source instead of creating an empty disk. This method duplicates a disk of the same size without you needing to copy data within the OS. You can’t reduce the disk size or disk count. As a new disk is created, you have to make OS changes to unmount old and mount new disks. However, there is no data movement inside the VM/OS necessary, as the new disks contain all data from the source snapshot.

The same limitations apply as noted for disk conversion in option (03).

Logical sector sizes

Premium SSD v2 and Ultra Disks introduced the option to specify logical sector sizes. The default value is 4096 bytes, or 4k, both disk types support 512e sector size as well. This is important for some older database versions, as they might require the use of 512e sector size. Examples are Oracle Database version 12.1 and lower and Db2 LUW versions lower than 11.5. See respective DB documentation for any details.

A converted existing disk, whether from a snapshot or through disk type change, will result in a Premium SSD v2 disk with 512e sector size. This has, in our tests and experience, no measurable performance impact. For new Premium SSD v2 disks the recommendation is to use 4k logical sector size, where possible.

Recommended migration to Premium SSD v2

Carefully consider which migration option fits best to your requirements and specifications. Customers which want to renew their SAP landscapes in Azure, such as VM Gen2 deployment, OS major version updates or using VMs without temporary storage will likely consider deploying new VMs with Premium SSD v2 and migrate the application data through backup/restore or DB replication.

We expect many customers will want to adjust disk sizes or align disk striping with updated documentation recommendations. In such case, option (02) with new disks and copying data to new disks gives you the best choice. Especially for database VMs with large disks.

For smaller VMs, application VMs and infrastructure servers with often just one or two managed disks, size changes are not necessary and thousands of small files might have to be moved. Here disk conversion options are likely the most suitable tool, to move to Premium SSD v2.

Select the combination of migration options that works best for your business.

Deploying new or converting to Premium SSD v2 disks will consume Azure quota for this resource type. By default, up to 100 TiB per region and per subscription is available. A second quota type for the number of Premium SSD v2 disks exists. The technical names for the relevant quotas are PremiumV2DiskCount and PremiumV2DiskSizeInGB. Check both quotas on your Azure subscription(s) and create a support request to raise, if necessary.

Summary

Premium SSD v2 has been available in Azure for some time and is fully supported for productive SAP systems. It opens new options with its increased performance, fine grained and uncoupled sizing for disk size, throughput and IOPS. Use of E-series for SAP HANA (observe SAP certified VM sizes) is simplified.

Independent settings for size | IOPS | MBps on each disk.
While OS disks are currently not supported, all managed data disks in an SAP system can use Premium SSD v2.
Determine which deployment / migration scenario best applies to your use case.
Clarify if existing limitations might block your deployment scenario.
Host caching for disk access is not available with Premium SSD v2. This includes write accelerator. Write accelerator not necessary for SAP HANA with Premium SSD v2.
Some workloads might benefit with read cache and require additional IOPS/throughput with Premium SSD v2. Monitor usage and limits on both individual disk and VM level for storage operations before using migrating.
In general, do not combine different storage types on single VM. Such combinations – for example few disks Premium SSD and others using Premium SSD v2, or with Ultra Disk – should be limited to exceptional workloads only.
Logical sector size 4k | 512e available – migrated disks will show 512e but expect no application performance impact. Old database versions might require 512e.
Converting existing disks to Premium SSD v2 uses a background copy process for both disk change and create new disk from snapshot. Check completionPercent on disk, reduced performance while active.
Check Azure quotas for Premium SSD v2 (#disks, overall size) and supported regions.

Premium SSD v2 information and limitations

Premium SSD v2 snapshot and limitations

Disk caching on Azure

SAP HANA and Premium SSD v2

SQL Server on Azure VMs

Db2 on Azure VMs

Oracle on Azure VMs

SAP ASE on Azure VMs

Using Azure Chaos Studio to Fortify SAP Systems Testing and Resiliency

anbugovi — Wed, 05 Mar 2025 16:00:00 GMT

Co-Authors

Anbu Govindasamy, Jay Witt Rosen Yanev and Ross Sponholtz

Azure Chaos Studio is an Azure service that allows you to inject faults into your service to see how it responds to disruptions. In this blog, we will discuss how to introduce Azure Chaos Studio for SAP use cases by introducing additional resource pressure or failure scenarios.

SAP Testing Requirement and Challenges

Qualifying Azure Environment: Customers often need to finalize the sizes of Azure VMs, storage, and network for specific SAP systems. Simulating production peak workloads to test and finalize the Azure environment and SKU is an important step in this process.
Application Test Plans: Developing and executing end-to-end application testing for one-time migrations, additional country onboarding, or business transformation projects can be complex. While some customers have established test plans, others are still looking for ways to achieve.
Time-Consuming Process: Testing is time-intensive and requires significant effort from various SAP teams. It involves preparing test cases, developing test data, and conducting the tests. Repeated testing for fine-tuning further increases the required man-hours.

SAP Traditional Testing Approaches

Custom Test Scripts and Partner Solutions: Customers often rely on custom-written test scripts or partner solutions to generate volume and perform stress tests. This helps in developing solutions and mitigation plans.
Oracle and HANA Testing: For Oracle, Oracle RAT testing can be leveraged, and for HANA, HANA capture and replay can be used. However, both approaches require substantial investment in preparing the environment.

SAP customers are constantly looking for solutions to address peak workload situation and failure scenarios.

Introducing Azure Chaos Studio for SAP Use Case

Azure Chaos Studio offers a comprehensive list of fault and action library, and we have selected specific set of faults and actions to test with SAP, recognizing that Azure Chaos Studio has a broader potential. We have divided our test scenarios into two main categories: Stress Testing and Failure Testing with HA/DR use case. These tests aim to measure, understand, and enhance application resilience. Azure Chaos Studio compliments SAP testing but Chaos Studio is not meant to replace end to end SAP business process testing.

Stress Testing: In the following scenarios, we introduce additional pressure to CPU, Network and Memory while performing SAP end to end load testing. We continue the test with different pressure points to learn and address configuration and resilience related findings.

CPU Pressure
Network Packet Loss
Physical Memory Pressure

CPU Pressure Example: In below screenshot, showing Azure Chaos Studio Configuration for setting up 50% CPU Pressure:

In the screenshot below showing CPU Spike after triggering CPU Pressure activity:

Failure Testing: For testing failure scenarios, we used the following faults with SAP process High Availability solution to validate the proper function of the cluster and failovers:

Kill Process
Network Disconnect

"Kill Process" Example: In below screenshot, showing Azure Chaos Studio Configuration for killing HANA Index process:

Next Steps

QuickStart guide: Leverage QuickStart guide to get started on Azure Chaos Studio https://learn.microsoft.com/en-us/azure/chaos-studio/chaos-studio-quickstart-azure-portal
Scenario Building: With Azure Chaos Studio’s steps and branches, you can build complex repeatable scenarios that can then be used on whole landscapes. Each step would include a fault that would be tested, and branches describe which steps can be run in parallel and which one are run serially. Creating scenarios doesn’t require a lot of technical knowledge and making changes to specific settings is easy given the intuitive interface.
Azure Chaos Studio region availability can be found in this link Regional availability of Azure Chaos Studio | Microsoft Learn

Benefits of Azure Chaos Studio

In our testing, Azure Chaos Studio enabled us to explore test and resilience use cases that were not achievable with SAP application test suites alone. By introducing additional resource pressure, we were able to push the boundaries more effectively and uncover failure scenarios that were previously undetectable.

Summary

Azure Chaos Studio can be used to introduce additional resource pressure or simulate failure scenarios. We recommend that customers enhance their existing SAP test cases with Azure Chaos Studio techniques to add scenarios that are currently not possible, thereby improving resilience and failure handling.

Useful Links:

What is Azure Chaos Studio? | Microsoft Learn