Running SAP Applications on the Microsoft Platform articles

SAP on Azure Product Announcements Summary – SAP Sapphire 2026

Hiren_Shah_Azure — Mon, 11 May 2026 13:00:00 GMT

Introduction

Today at SAP Sapphire, we announced a new wave of innovations deepening the Microsoft–SAP partnership – advancing RISE with SAP on Azure, our SAP S/4HANA integrations, and our shared AI platform. With more than three decades of co-engineering, Microsoft and SAP continue to help customers modernize their ERP estate and build new value on top of it.

Below is a look at the latest product updates, alongside customer evidence of what is possible when SAP and Microsoft come together.

Customer Evidence

AI: From ERP Data to Intelligence in the Flow of Work

KONE is running an AI-driven contract workflow on Power Platform that validates documents against SAP records and auto-creates contracts in SAP — processing 54,000+ contracts per year with a 33% reduction in handling time. To support their 3,000+ citizen developers, KONE developed an agent with Microsoft Copilot Studio that guides makers through building solutions, generating prompts and surfacing existing apps to avoid duplication.

"Power Platform is enabling us to integrate highly effective AI models into our automation solutions and that is helping us streamline increasingly complex processes — efficiently and at scale."

— Lulu Zhang, Director, Head of Technology & Services, KONE

Security: Protecting the SAP Core

MAIRE, a global engineering group operating across 50 countries, deployed Microsoft Sentinel for SAP to secure its accounts payable environment — the heartbeat of over 10,000 employees. With 50+ active detection rules and cross-environment event correlation now automated, MAIRE has shifted from reactive incident response to continuous, AI-ready threat intelligence.

"SAP generates an impressive amount of logs, and with the Microsoft solution, we are able to detect suspicious events before they can become a problem."

— Andrea Sgarlata, Identity Manager, Tecnimont Services, MAIRE Group

Cenibra replaced SAP Identity Management with Microsoft Entra ID Governance, integrating 80+ systems and achieving a 46% operational gain — with 60–70% of manual IAM effort projected to be eliminated as automation expands.

Running SAP at Scale: Migration as a Strategic Foundation

Maersk migrated 500 SAP servers and a petabyte of data to Azure in six months — with near 100% uptime and zero incidents — and is now using Azure OpenAI with SAP to let teams query invoice and shipment data in natural language.

"This wasn't just a migration. It was a mindset shift. We needed to move from managing infrastructure to driving engineering innovation."

— Roman Kulczykowski, Senior Director, SAP Technology Platform, Maersk

We're pleased to share the product updates behind these outcomes:

From SAP Joule + Microsoft Copilot to agent-to-agent workflows, SAP and Microsoft are turning SAP processes into reusable AI-powered building blocks.
Microsoft Fabric’s SAP footprint just grew: SAP BDC Data Connect, Datasphere replication, certified partners.
Microsoft Sentinel for SAP:Expanded SAP detections, richer SAP ETD cross-signal correlation, and upcoming LogServ/ASIM integration bring SAP telemetry natively into your XDR workflows.
SAP Deployment Automation Framework expands support for highly available SAP architectures with HANA scale-out and HSR capabilities, enabling GitHub-native deployments and centralized configuration management.
SAP Testing Automation Framework advances high availability validation with scale-out HANA testing, backup validation, and integrated configuration checks to enable continuous reliability assurance.
Extended the Observability Dashboard with additional infrastructure checks and introduced a reusable AIOps pattern to move from observability insights to governed operational action.

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

Extend and Innovate

Copilot Studio & Power Platform

Joule & Microsoft Copilot: Adoption and Enablement

The Joule and Microsoft 365 Copilot integration reached general availability in late 2025, and we now see hundreds of customers actively exploring and onboarding the solution. To accelerate adoption, SAP and Microsoft are delivering:

Updated onboarding guidance such as the SAP Discovery Center Mission – Integrate Joule and Microsoft 365 Copilot
Dedicated SAP services to support customers getting started.

First Agent-to-Agent (A2A) Scenarios with Nestlé

We are continuing to evolve the integration beyond chat-based experiences toward true agent interoperability. At SAPPHIRE, Nestlé is showcasing early Agent-to-Agent (A2A) scenarios, where:

SAP services are exposed via the agent gateway
Copilot Studio acts as the orchestration layer, consuming Joule services using an open, vendor-neutral A2A protocol.

This marks an important step toward a multi-agent ecosystem across SAP and Microsoft.

Easier SAP Integration with Copilot Studio

Many SAP customers expose standard and custom APIs using the SAP Business Technology Platform connected via SAP Cloud Connector to their SAP systems like SAP S/4HANA or even older SAP ECC systems. Using SAP API Management customers can already today expose these SAP OData Services and soon also MCP Servers which can be consumed in Copilot Studio.

More information about SAP with Microsoft can be found on Microsoft Learn.

Microsoft Fabric

We continue to deepen the integration between Microsoft Fabric and SAP solutions by evolving our strategy to offer options to leverage their SAP data in Fabric:

We are expanding aligned integration options with Mirroring for SAP Datasphere, generally available since March 2026. This technology integrates SAP Datasphere replications flows into the mirroring capabilities of Microsoft Fabric. With these technologies you can seamlessly integrate the data integration tools of SAP with the power of Microsoft Fabric.
In addition, we are collaborating closely with SAP to make SAP Business Data Cloud Connect for Microsoft Fabric available for customers in the second half of 2026. This will allow bi-directional, zero-copy sharing between SAP Business Data Cloud and Microsoft Fabric, significantly simplifying many use cases that previously required moving and managing copies of data.

Sentinel Solution for SAP

Microsoft Sentinel for SAP continues to expand coverage of the SAP core, SAP BTP, SAP LogServ and the broader SAP ecosystem — giving SOC teams broader, deeper, and more contextualized SAP signal inside their existing Microsoft XDR workflows.

New SAP detections — catalog of out-of-the-box detection expanded to high profile targets such as Integration Suite, Build WorkZone, and Cloud Identity Services
SAP Logserv roadmap — solution will allow re-use of Microsoft’s Advanced Security Information Model (ASIM) and other standard tables so customers and partners can profit from black-box detections apply existing XDR investments directly to their SAP telemetry.
SAP ETD correlation with Microsoft XDR — the SAP Enterprise Threat Detection solution now ships email artifacts alongside IP and host, enabling deeper cross-signal correlation across SAP and Microsoft Defender (previously limited to IP and host only)

The result: more out-of-the-box coverage, better re-use of existing Microsoft and partner detection investments, and richer correlation between SAP and the rest of the Microsoft Defender estate.

Microsoft Entra

Microsoft Entra ID and Entra ID Governance extend identity lifecycle and entitlement management into SAP via integration with SAP Cloud Identity Services (SCI), SAP Identity Access Governance (IAG), and SAP Access Control (AC). Microsoft and SAP have significantly deepened their collaboration in identity governance — delivering an end-to-end solution that extends Microsoft Entra into SAP landscapes at enterprise scale.

End-to-end integration with SAP Identity Access Governance (IAG) now available in public preview, enabling customers to:

o Publish SAP business roles into Entra entitlement catalogs and assign SAP access through Entra access packages

o Enforce approval workflows and Separation of Duties (SoD) policies natively

o Integration with SAP IAG also supports environments still relying on SAP AC, providing a phased migration path toward cloud-first governance.

General availability of the improved SAP Cloud Identity Services Connector in Microsoft Entra featuring SCIM 2.0 support, provisioning of Groups & Group Memberships and OAuth 2.0-based authentication replacing basic authentication
Day-zero visibility through account discovery allowing customers to correlate SAP accounts with Entra identities via SAP Cloud Identity Services and get immediate transparency into existing SAP identities. It also accelerates onboarding into governance workflows

The result is a modern, cloud-based identity governance platform for SAP, combining Microsoft’s identity lifecycle automation with SAP-native compliance controls, and a clear migration path as SAP IDM approaches end of maintenance.

Purview

Microsoft Purview allows uniform data governance and compliance across the enterprise including SAP sources. Purview released several notable updates for SAP since the last edition:

SAP Calculation View support for metadata scans, relevant for HANA DB and a major customer ask is now generally available.
Scoped scanning (configure exactly which metadata to scan) for ECC and S/4HANA is now in Public Preview
BW/4HANA connector is also now generally available

Modern Authentication for SAP Integrations

As the ecosystem evolves away from legacy authentication models, Microsoft and SAP are enabling secure, cloud-native integrations by replacing Basic Authentication with OAuth 2.0-based patterns across key scenarios. These innovations establish best security practices by replacing Basic Authentication with the secure OAuth 2.0 protocol and avoid the use of shared credentials that have an expiration. The outcome: A modern, secure integration layer for SAP, aligned with Zero Trust principles and ready for AI-driven and API-based enterprise architectures.

Secure Email Integration: SAP ↔ Exchange Online

With the deprecation of Basic Authentication, SAP systems now integrate with Exchange Online using OAuth 2.0 and Microsoft Entra ID for outbound email scenarios. The SAP ABAP systems authenticate using client credentials or certificate-based (JWT) flows. Also communication is secured via SMTP OAuth 2.0, eliminating password-based authentication. This modern approach ensures authentication without the need for password for SAP outbound communication and alignment with SAP and Microsoft.

Extending Modern Authentication to SAP SuccessFactors APIs

Beyond infrastructure scenarios, modern authentication is also being adopted across SAP SaaS integrations with new integration patterns using OAuth-secured access to SAP SuccessFactors OData APIs the Microsoft Entra ID acts as the central identity provider and token issuer enabling secure, governed API access without credential-based authentication.

SAP on Azure Software Products and Services

SAP Deployment and Testing Automation Framework

The first half of 2026 marks the most significant release cycle for both the SAP Deployment Automation Framework (SDAF) and the SAP Testing Automation Framework (STAF) since their inception. The latest releases deliver broad platform expansion, deeper high-availability coverage, and a matured testing capability that extends well beyond initial scope.

Highlights at a glance:

SDAF now supports GitHub Actions as a first-class deployment path alongside Azure DevOps and CLI
Azure App Configuration integration provides centralized, single-source-of-truth configuration management
Deep investment in HANA scale-out with Pacemaker and HSR, including SAPHanaSR-angi support for SLES
Platform coverage expanded to RHEL 10, OracleLinux9, and newer SLES release.
STAF adds scale-out HSR testing, and Azure Backup Testing integration for SAP HANA
Configuration Checks capability, a rewrite of the open-source Quality Checks tool, now ships natively within STAF. Introduced scheduling support for both HA functional tests and configuration checks

SAP Deployment Automation Framework (SDAF)

SDAF now supports GitHub Actions end-to-end, including automated workflow setup, container-based execution, and built-in secret management; providing deployment experience on GitHub equivalent to Azure DevOps. Azure App Configuration integration centralizes deployment parameters across control planes and workload zones, eliminating parameter configuration drift across environments.

High-availability infrastructure coverage has seen its deepest investment to date. HANA scale-out with Pacemaker and HSR now supports SAPHanaSR-angi on SLES, adds conditional resource movement based on instance name and Pacemaker version, and enhances replication stability with improved retry and error-clearing logic. Additional updates include Azure Files NFS encryption in transit, hardened Oracle Data Guard automation with idempotent post-processing and dynamic SID handling, and improved networking logic for both greenfield and brownfield scenarios.

SAP Testing Automation Framework (STAF)

STAF continues to expand its SAP workload validation coverage and automation capabilities - making it easier to validate high availability designs, schedule tests at scale, and verify backup and restore readiness in Azure.

STAF has introduced three major capabilities in the past few months:

Expanded high availability validation for SAP HANA with scale-out HANA System Replication (HSR) support (including the SAPHanaSR-ScaleOut provider and updated HA test coverage for scale-out topologies)
Test scheduling and run management via REST API and CLI (with containerized deployment improvements to simplify operating the service).
Azure Backup validation and functional testing for HANA through a dedicated Ansible module that enables end-to-end backup discovery and restore workflows (including restore monitoring and cross-VM restore scenarios).

The Configuration Checks capability, integrated natively into STAF from the open-source Quality Checks tool previewed in November 2025, now includes enhanced telemetry with duration tracking, updated disk performance thresholds, and improved HTML reporting.

Azure Center for SAP solutions Tools and Frameworks

We continue to enhance our scripts and supporting tools and frameworks outside the core product experience. These updates are designed to help customers and partners bridge the gap between evolving operational needs and available product capabilities.

The Observability Dashboard has evolved into a more actionable operational view for Azure workload reviews, bringing security, network, and infrastructure signals into one place to improve visibility, reduce manual follow-ups, and support faster decision-making.

o The Security Dashboard now highlights key exposure and hygiene risks such as public inbound access, orphaned public IPs, storage accounts without Private Endpoint, and Basic tier load balancers.

o The Network Dashboard now includes VNet peering status, helping teams quickly validate connectivity posture alongside ExpressRoute, gateway, public IP SKU, UDR, subnet, and remote access checks. The Infrastructure Summary Dashboard helps identify configuration gaps such as VMs that support NVMe but are still using SCSI, failed VM extensions, and disabled Accelerated Networking.

o The extended dashboard also adds visibility into AFS subnet configuration, giving teams a clearer view of platform readiness and operational consistency across customer environments.

Operation Excellence AIOps Custom Agent: As part of our AIOps work, we are exploring how AI can move beyond generic operational insights and help customers think differently about managing complex Azure workloads. The focus is on enabling customer-specific AI agents to use cases that reflect real operational challenges, business priorities, and environment-specific patterns, rather than applying a one-size-fits-all model. By combining observability, automation, Azure resource insights, operational telemetry, and approval-driven actions, customers can identify risks earlier, reduce manual investigation effort, and accelerate decision-making across their estate. This approach creates a practical path for customers to experiment safely, address targeted operational scenarios, and shape AI-enabled operations around the needs of their own workloads, teams, and governance models. For more, see From Observability to Action: Building an AI-Powered AIOps Agent for Customer-Specific Operations

To learn more, visit the Microsoft sessions at SAP Sapphire 2026 and check out our SAP on Azure learning page.

From Observability to Action: Building an AI-Powered AIOps Agent for Customer-Specific Operations

jitendrasingh — Fri, 08 May 2026 14:30:00 GMT

Modern cloud operations are no longer just about collecting metrics and reacting to alerts. Customers are running increasingly complex, business-critical workloads where every environment has its own architecture, performance profile, operational constraints, approval process, and risk tolerance.

This means a generic monitoring dashboard is not enough. What customers demand is a controlled operating model that can turn platform signals into explainable recommendations, route those recommendations through the right approval path, execute only within agreed guardrails, and preserve a complete audit trail.

In many customer environments, an observability dashboard is used to review platform summaries, operational signals, health trends, and deep-dive assessments across critical Azure workloads. The next opportunity is to take one of those observations and turn it into a governed AIOps workflow.

In this example, I use Premium SSD v2 performance tuning to show how a customer can begin with one measurable operational signal, apply clear policy, use AI to generate an explainable recommendation, request human approval, and then perform controlled execution using Azure-native automation.

The goal is not to automate every operational scenario on day one. The goal is to establish a safe, repeatable pattern:

Observe → Assess → Recommend → Approve → Execute → Validate → Learn

This pattern can later be extended to other operational scenarios such as VM rightsizing, backup failure triage, capacity risk detection, configuration drift, application health checks, and workload-aware performance recommendations.

Why this matters

Most operations teams already have monitoring. The challenge is turning monitoring insight into safe, repeatable, governed operational action.

For example, a platform team may observe that a disk repeatedly crosses an IOPS threshold. In a traditional model, an engineer reviews metrics, checks disk configuration, validates policy, raises a change, waits for approval, applies the update, and then validates the result. That process is reliable, but it can be manual, inconsistent, and slow.

A customer-specific AI Operational Agent can help convert that process into a controlled workflow. The agent does not need to own the full change lifecycle from the beginning. A safer first step is for the agent to collect evidence, calculate utilisation, generate a recommendation, explain the rationale, request approval, and only then trigger execution through a governed automation path.

Scenario: Premium SSD v2 performance tuning

Premium SSD v2 is a useful first scenario because disk size, IOPS, and throughput can be adjusted independently, making it a practical candidate for performance-efficiency automation when used with appropriate guardrails. Microsoft documentation describes Premium SSD v2 as a managed disk type where performance can be configured flexibly, including IOPS and throughput characteristics. (Microsoft Learn)

The objective is to identify tagged Premium SSD v2 disks, review recent performance, detect disks crossing configured utilisation thresholds, generate an explainable recommendation, and route the decision through a human-in-the-loop approval process before any change is applied.

A practical reference implementation should support these outcomes:

Select only approved disks using tags. Read disk IOPS and throughput from Azure Monitor Metrics. Compare observed utilisation against policy thresholds. Generate a recommendation, such as ScaleUpRecommended, ScaleDownCandidate, or NoChange. Send a daily/weekly operational summary with threshold observations and charts. Trigger approval only for actionable candidates. Capture approval or rejection through Teams and/or email. Execute immediately or schedule the change based on policy. Record decisions, execution status, and audit data. Validate post-change impact and feed the outcome back into the process.

This keeps the design focused. It does not try to build a generic “auto-fix everything” agent. It starts with one measurable operational scenario and builds a reusable pattern.

High-level architecture

A high level architecture for custom AIOps Agent scenario:

Reference Architecture: Premium SSD v2 Customer AIOps Agent Workflow

The key design principle is that the agent can recommend, explain, and orchestrate, but the change path remains governed. Policy controls what can be changed, approval controls when it can be changed, and audit records why the change was made.

Model used in the example

In this reference implementation, the AI explanation layer uses an Azure OpenAI GPT-4o [gpt-4o, mini, gpt-4.1 or new version can be leveraged based on the requirement] deployment to generate the natural-language recommendation summary, risk statement, approval text, and daily operational summary.

The important design point is that the model is not the only decision-maker. The recommendation is generated through a combination of deterministic policy logic and AI-assisted explanation.

The recommended split is:

Deterministic policy engine: - Discovers eligible disks. - Reads Azure Monitor metrics. - Calculates IOPS and throughput utilisation. - Applies customer thresholds. - Determines whether the disk is NoChange, ScaleUpRecommended, or ScaleDownCandidate. - Enforces tags, policy caps, approval requirement, dry-run mode, and execution mode. AI model: - Converts technical evidence into a clear recommendation narrative. - Explains why the recommendation was generated. - Summarises impact, risk, and required approval. - Produces email or Teams approval text. - Generates daily or weekly operational summaries. - Does not directly execute Azure changes. - Does not override customer policy.

This separation is important for enterprise trust. The model helps operations teams understand the recommendation, but the actual eligibility, threshold crossing, and execution guardrails remain deterministic and auditable.

Step 1: Select disks using tags

The agent should not scan and act on every disk in a subscription by default. A safer pattern is to require explicit tagging.

Example tag model:

az tag update ` --resource-id "<disk-resource-id>" ` --operation Merge ` --tags ` aiops-enabled=true ` aiops-profile=database ` aiops-approval-required=true ` aiops-max-iops=5000 ` aiops-max-mbps=250 ` aiops-report-threshold-pct=80 ` aiops-execution-mode=immediate-after-approval ` aiops-apply-dry-run=true

Suggested meaning:

aiops-enabled=true Allows the disk to be included in the AIOps workflow. aiops-profile=database Groups disks by workload profile or operational policy. aiops-approval-required=true Requires human approval before execution. aiops-max-iops Defines the maximum IOPS policy cap. aiops-max-mbps Defines the maximum throughput policy cap. aiops-report-threshold-pct Defines when a disk should appear in the threshold report. aiops-execution-mode Controls whether approval leads to immediate or scheduled execution. aiops-apply-dry-run=true Allows safe validation without changing the disk.

For early testing, keep aiops-apply-dry-run=true. Move to real execution only after the recommendation logic, approval flow, audit trail, and rollback process have been validated.

Step 2: Discover eligible disks

The daily summary function can use Azure Resource Graph or Azure Resource Manager to discover tagged disks. The query should return only resources explicitly opted into the workflow.

Example Resource Graph query:

Resources | where type =~ 'microsoft.compute/disks' | where tostring(tags['aiops-enabled']) =~ 'true' | where tostring(tags['aiops-profile']) =~ 'database' | project id, name, resourceGroup, location, sku, properties, tags

This makes the design scalable. Adding a disk to the agent does not require changing workflow code. Operations teams apply the approved tag set, and the next scheduled run discovers the resource.

Step 3: Collect disk metrics

For each selected disk, the agent queries Azure Monitor Metrics. Azure Monitor provides a Metrics REST API that lists metric values for a resource through the Microsoft.Insights/metrics endpoint. (Microsoft Learn)

Example resource-level pattern:

GET https://management.azure.com/<resource-id>/providers/Microsoft.Insights/metrics ?api-version=2023-10-01 &timespan=<start-time>/<end-time> &interval=PT1H &metricnames=<metric-list> &aggregation=Average,Maximum

Typical disk metrics for this scenario include:

Composite Disk Read Operations/sec Composite Disk Write Operations/sec Composite Disk Read Bytes/sec Composite Disk Write Bytes/sec

For larger estates, consider the Azure Monitor Metrics Batch API. Microsoft documents that the batch API can list metric values for multiple resources, which is useful when querying many resources in the same subscription, region, and resource type. (Microsoft Learn)

The agent should collect metrics over a practical time window, such as the last 24 hours, and aggregate into time buckets. This avoids making recommendations based on a single short spike.

Example approach:

Metric window: Last 24 hours Aggregation: Average and Maximum Bucket size: 5 minutes or 15 minutes Signal required: Sustained threshold crossing across multiple buckets

Step 4: Calculate utilisation

The agent calculates total observed IOPS and throughput, then compares those values against the current provisioned settings and customer-defined thresholds.

Example calculations:

Total IOPS = Read IOPS + Write IOPS IOPS utilisation % = Peak Total IOPS / Provisioned IOPS × 100 Total throughput MiB/s = Read MiB/s + Write MiB/s Throughput utilisation % = Peak Total MiB/s / Provisioned MBps × 100

Example output:

{ "diskName": "<disk-name>", "resourceGroup": "<resource-group>", "provisionedIops": 3000, "provisionedMbps": 125, "peakTotalIops": 3059.6, "iopsUtilisationPercent": 102.0, "peakTotalMiBps": 42.95, "throughputUtilisationPercent": 34.4, "thresholdObservation": "IOPS crossed the configured threshold", "recommendation": "ScaleUpRecommended", "approvalRequired": true }

Step 5: Generate a recommendation

The recommendation should be generated using transparent policy logic first. For a first implementation, avoid complex or opaque decision-making. Start with simple rules and make the reason visible.

Example deterministic logic:

If IOPS utilisation is above threshold: Mark as threshold crossed. If throughput utilisation is above threshold: Mark as threshold crossed. If threshold is crossed and policy allows a higher target: Recommend scale-up. If utilisation remains low for a sustained period: Mark as a scale-down candidate. Otherwise: Recommend no change.

Example recommendation rule:

def generate_disk_recommendation( peak_iops, provisioned_iops, peak_mbps, provisioned_mbps, threshold_pct, max_iops, max_mbps, sustained_bucket_count ): iops_utilisation = (peak_iops / provisioned_iops) * 100 if provisioned_iops else 0 mbps_utilisation = (peak_mbps / provisioned_mbps) * 100 if provisioned_mbps else 0 threshold_crossed = ( iops_utilisation >= threshold_pct or mbps_utilisation >= threshold_pct ) if threshold_crossed and sustained_bucket_count >= 3: target_iops = min(max_iops, int(provisioned_iops * 1.25)) target_mbps = min(max_mbps, int(provisioned_mbps * 1.25)) return { "recommendation": "ScaleUpRecommended", "reasonCode": "SustainedThresholdCrossing", "currentIops": provisioned_iops, "recommendedIops": target_iops, "currentMbps": provisioned_mbps, "recommendedMbps": target_mbps, "approvalRequired": True } return { "recommendation": "NoChange", "reasonCode": "WithinPolicyThreshold", "approvalRequired": False }

The output from this policy logic becomes the grounded input to the AI model.

Example AI prompt pattern:

You are an Azure operations assistant helping explain a disk performance recommendation. Use only the evidence provided in the JSON payload. Do not invent missing metrics. Do not recommend a change if approvalRequired is false. Explain the recommendation in a concise operational style. Include: 1. Recommendation summary 2. Evidence 3. Risk or operational consideration 4. Approval request 5. Validation step after execution Input JSON: <recommendation_payload>

Example AI-generated recommendation narrative:

Recommendation: Scale up Premium SSD v2 performance for <disk-name>. Reason: The disk crossed the configured IOPS utilisation threshold across multiple observed time buckets. Peak IOPS reached 3,596 against the current provisioned value of 3,000, representing 120% utilisation. Throughput utilisation remained within the configured policy range. Proposed action: Increase provisioned IOPS within the approved customer policy cap. No throughput increase is recommended at this stage. Risk consideration: The change should follow the approved maintenance or execution policy for this workload. Post-change validation should confirm that IOPS pressure has reduced and no negative workload signal is observed. Approval required: Yes.

Example recommendation result:

{ "recommendation": "ScaleUpRecommended", "reason": "IOPS utilisation exceeded the configured threshold for multiple time buckets.", "approvalRequired": true, "executionMode": "immediate-after-approval", "dryRun": true, "executionBlockers": [ "ApprovalRequired" ] }

This is important for trust. Operations teams should be able to see why a recommendation was made and which policy guardrails apply.

Step 6: Send a daily operational summary

The daily summary workflow should run on a schedule, call the summary function, and send a concise email to the operations team.

The email should include:

Eligible disk count Disks crossing threshold Actionable recommendations Approvals in the last 24 hours Rejections in the last 24 hours Scheduled actions Completed actions Failed actions

For the disk summary table, keep the content compact:

Disk Resource group Provisioned IOPS Provisioned throughput Peak total IOPS IOPS utilisation Peak total MiB/s Throughput utilisation Threshold observation Recommendation

Avoid putting every raw metric value into the email. Instead, attach or link charts only for disks that crossed the threshold, or for the top N disks by utilisation.

Step 7: Trigger approval only for actionable candidates

The summary function can return an approvalCandidates array. The daily workflow should trigger the approval workflow only for those candidates.

Example candidate payload:

{ "diskResourceId": "<disk-resource-id>", "diskName": "<disk-name>", "resourceGroup": "<resource-group>", "triggerSource": "DailySummaryThresholdDetection", "assessmentMode": "recommendation-only", "alertContext": { "thresholdObservation": "IOPS crossed the configured threshold", "peakTotalIops": 3059.6, "iopsUtilisationPercent": 102.0 } }

This avoids sending unnecessary approvals for resources that do not need action.

Step 8: Use human-in-the-loop approval

The approval workflow should perform a fresh assessment before asking for approval. This prevents stale decisions if metrics, tags, or policy have changed since the daily summary was generated.

A practical design can support both:

Primary channel: Teams Adaptive Card Fallback channel: Email approval links

Microsoft Teams supports actions that post an adaptive card and wait for a response, allowing a workflow to pause until a user responds. (Microsoft Learn)

The Teams card should include:

Disk name Resource group Recommendation Reason Peak utilisation Execution mode Execution blockers Approve / Reject buttons Optional comments

The approval flow should use first-decision-wins semantics:

If Teams approval is received first: Record the Teams decision. Ignore later email link clicks. If email approval is received first: Record the email decision. Ignore later Teams responses. If a duplicate response is received: Return AlreadyProcessed and do not execute again.

This avoids duplicate execution and gives a clean audit model.

Step 9: Capture who approved or rejected

Every decision should be written to an audit store.

Example approval record:

{ "assessmentId": "<assessment-id>", "diskResourceId": "<disk-resource-id>", "approvalStatus": "Approved", "approverEmail": "<approver@contoso.com>", "approvalSource": "TeamsAdaptiveCard", "comments": "Approved for the agreed maintenance window.", "processedUtc": "<timestamp-utc>", "executionStatus": "Scheduled" }

For production, prefer authenticated approval channels such as Teams Adaptive Cards or an authenticated approval workflow rather than relying only on email links with query-string identity.

Step 10: Execute immediately or schedule

After approval, the agent checks execution policy.

Example immediate execution policy:

aiops-execution-mode=immediate-after-approval aiops-apply-dry-run=true

Example scheduled execution policy:

aiops-execution-mode=schedule-in-change-window aiops-change-window-utc=22:00-02:00 aiops-apply-dry-run=true

Execution behaviour:

Approved + immediate-after-approval: Execute now if dry-run is false. Otherwise record a dry-run execution. Approved + schedule-in-change-window: Store a scheduled action. Execute when the approved window opens. Rejected: Record rejection. Do not execute. Duplicate response: Return AlreadyProcessed.

Premium SSD v2 performance should only be adjusted within documented limits and customer-defined policy. The workflow should validate the target IOPS and throughput before calling Azure Resource Manager. Microsoft documentation describes Premium SSD v2 performance characteristics and configuration considerations, including IOPS and throughput behaviour. (Microsoft Learn)

Step 11: Use managed identity and least privilege

The Function App or workflow should use managed identity where possible. Azure Logic Apps supports managed identities for authenticating to Microsoft Entra-protected Azure resources, which avoids storing credentials or access tokens in workflow definitions. (Microsoft Learn)

A reference implementation needs permissions for:

Resource discovery Metric query Tag read Disk read Disk update, only if controlled execution is enabled Audit write

For a proof of concept, a broad role might be used temporarily in a test environment. For production, use a custom least-privilege role that allows only the specific read and update operations required.

Step 12: Store audit state

The agent should maintain an audit table or equivalent state store.

Suggested fields:

AssessmentId DiskResourceId DiskName ResourceGroup Recommendation ApprovalRequired ApprovalStatus ApproverEmail ApprovalSource ExecutionMode ExecutionStatus DryRun CreatedUtc ProcessedUtc ExecutionResult

This state is useful for:

Daily/Weekly reporting Duplicate decision prevention Scheduled execution Audit review Operational troubleshooting Post-change validation

Step 13: Validate post-change impact

Execution is not the end of the workflow. The agent should validate whether the change produced the expected operational outcome.

Post-change checks may include:

Was the disk update successful? Did provisioned IOPS or throughput change as expected? Did observed utilisation reduce? Did latency or queue depth improve? Was there any negative workload signal? Should the recommendation logic be adjusted?

This closes the loop:

Action → Validation → Learning → Improved recommendation

Technical reference flow

A simplified end-to-end flow:

Scheduled workflow runs every 24 hours. Workflow calls the summary function. Function selects disks by approved tags. Function queries Azure Monitor Metrics. Function calculates utilisation and threshold crossings. Deterministic policy logic generates the recommendation. Azure OpenAI generates the explanation, summary, and approval text. Daily summary email or Teams message is sent. Approval workflow is triggered only for actionable candidates. Approval workflow performs a fresh assessment. Teams and/or email approval is sent. First valid approval or rejection is recorded. Approved actions are executed immediately or scheduled. Audit state is updated. Post-change validation is performed. Next daily summary reports decisions and outcomes.

Why this pattern is reusable

Premium SSD v2 tuning is only one example. The same pattern can be reused for other customer-specific operational scenarios:

VM rightsizing recommendations Disk latency investigation Backup failure triage Capacity threshold management Configuration drift detection Network health assessment Application health checks Workload-aware operational recommendations

The reusable pattern is:

Customer-specific signal + Policy-aware recommendation + AI-generated explanation + Human-in-the-loop approval + Controlled execution + Audit and feedback

Test the flow (Start with Dry-Run)

1. Set disk tags for safe dry-run

$diskId = "/subscriptions/xxxxx-xx-xx-xxxxx/resourceGroups/jtrg-sap-prod/providers/Microsoft.Compute/disks/jtdisk-aiops-pssdv2-test-001" az tag update ` --resource-id $diskId ` --operation Merge ` --tags ` aiops-enabled=true ` aiops-profile=database ` aiops-approval-required=true ` aiops-report-threshold-pct=80 ` aiops-target-utilisation-pct=70 ` aiops-max-iops=5000 ` aiops-max-mbps=250 ` aiops-execution-mode=immediate-after-approval ` aiops-apply-dry-run=true

2. Trigger the approval Logic App

Replace <PASTE_LogicApp_AIOPS_APPROVAL_HTTP_TRIGGER_URL> with the HTTP trigger URL for your Logic App URL.

$logicAppUrl = "<PASTE_LogicApp_AIOPS_APPROVAL_HTTP_TRIGGER_URL>" $payload = @{ schemaId = "aiops-premiumssd-v2-approval-test-v1" diskResourceId = "/subscriptions/xxxxx-xx-xx-xxxxxx/resourceGroups/jtrg-sap-prod/providers/Microsoft.Compute/disks/jtdisk-aiops-pssdv2-test-001" diskName = "jtdisk-aiops-pssdv2-test-001" resourceGroup = "jtrg-sap-prod" triggerSource = "ManualApprovalWorkflowTest" assessmentMode = "recommendation-only" alertContext = @{ alertRule = "Manual test - Premium SSD v2 IOPS threshold" severity = "Sev3" monitorCondition = "Fired" thresholdPercent = 80 peakTotalIops = 3059.6 peakTotalMiBps = 42.95 iopsUtilisationPercent = 102.0 throughputUtilisationPercent = 34.4 thresholdObservation = "Manual test: IOPS crossed 80% threshold" } } $response = Invoke-RestMethod ` -Method Post ` -Uri $logicAppUrl ` -ContentType "application/json" ` -Body ($payload | ConvertTo-Json -Depth 10) $response | ConvertTo-Json -Depth 20

3. Expected result

In the approval Logic App run history, you should see:

Run Disk Assessment → Succeeded Send Approval Email → Succeeded If Teams Approval Enabled → True Post Teams Approval Card And Wait → Running / Waiting

4. Test real disk update only after dry-run works

Change only this tag:

az tag update ` --resource-id $diskId ` --operation Merge ` --tags aiops-apply-dry-run=false

Then trigger the same payload again and approve the new Teams card.

An email notification will also be sent, with approval handled on a first-approval basis, as discussed earlier.

5. Validate the disk after approval

az disk show ` --ids $diskId ` --query "{name:name, iops:diskIOPSReadWrite, mbps:diskMBpsReadWrite, sku:sku.name}" ` -o table

Expected result after real approval:

{ "approvalStatus": "Approved", "executionStatus": "Executed" }

Daily Summary email example

Conclusion

Customer specific AIOps should not start with an expectation of full automation across every operational scenario. A safer and more sustainable approach is to start with one measurable signal, clear guardrails, human-in-the-loop approval, and controlled execution.

Premium SSD v2 performance tuning is a practical first use case because it has clear metrics, configurable performance settings, and measurable post-change outcomes. By combining Azure Monitor, Azure Functions, Azure Logic Apps, Teams approval, Azure OpenAI, managed identity, and audit storage, platform teams can move from passive visibility to safe, governed operational action.

The outcome is not just a disk tuning workflow. It is a reusable operating model for building customer-specific AI Operational Agents that improve performance efficiency while preserving control, compliance, and trust.

Aligning SAP application servers with the HANA primary zone on Azure (Public Preview) — Part 1

sanoopt — Tue, 28 Apr 2026 14:15:00 GMT

Many SAP on Azure customers improve resilience by deploying critical SAP tiers across two distinct Azure Availability Zones. A common pattern for the SAP application layer in cross-zone designs is Active/Passive:

One set of SAP application servers is active in the same zone as the database primary.
A second, identical set is passive in another zone, ready to be activated when needed.

This pattern is described in Microsoft guidance (and is often the starting point for cross-zone SAP discussions): https://learn.microsoft.com/en-us/azure/sap/workloads/high-availability-zones

The operational challenge is what happens after a failover.

When the HANA primary moves to another zone, customers typically want the SAP application layer to follow so that the active application servers remain co-located with the database primary. In many environments, cross-zone network performance is well within acceptable ranges; however, for latency-sensitive workloads and specific regional topologies, keeping application and database tiers in the same zone can be a useful optimization. As always, validate with measurements for your own workload and region.

This post introduces a new Pacemaker resource agent for SAP on Azure deployments, that helps automate the Active/Passive application-server alignment. The resource agent is currently in a public preview.

Why align the SAP application tier?

In SAP HANA deployments on Azure, it's common to place the HANA primary and secondary VMs, as well as the SAP application VMs in different availability zones to improve resilience.

SAP workloads are sensitive to latency, and while cross-zone latency is often acceptable for SAP workloads, it can become a factor in certain regional topologies - especially when application-to-database round trips are frequent. Keeping the active application tier in the same zone as the HANA primary reduces those cross-zone hops and helps make performance more consistent during steady state and after a failover.

To achieve minimal latency, many customers choose to:

Keep application servers deployed across zones for resiliency, and
When the HANA primary changes zones, switch which application-server set is active, so it runs in the same zone as the primary.

Doing this manually is possible, but it adds steps during an already time-sensitive event and increases the chance of running "active" application capacity in the wrong zone longer than intended. This pacemaker resource agent addresses this gap: it keeps the application tier aligned with the current HANA primary in a predictable way after failovers, while preserving an active/passive design across zones.

Introducing the resource agent

Azure SAP Zone Resource Agent is a Pacemaker resource agent that aligns SAP application server VMs with the current HANA primary VM.

At a high level, the agent:

Detects where HANA primary is running (Azure Availability Zone, or a customer-provided logical group)
Ensures the "same zone" SAP application server VMs are running.
Starts SAP on those VMs.
Deactivates or stops SAP on application servers in the other availability zone and optionally stops or deallocates the corresponding VMs.

This gives you an automated way to keep the application tier aligned with the database tier after failovers, while preserving the active/standby design across zones.

Architecture at a glance

The resource agent is designed for an Active/Passive application tier across zones: Only one availability zone should have active application servers at any given time.

What the agent automates

Automates application-server alignment to the HANA primary zone for Active/Passive application-tier designs.
Provides clear operational choices (fast "passive mode" vs "stop/deallocate" for cost management)

Supported placement patterns

This Resource Agent targets cross-zone SAP deployments for Active-Passive deployment patterns:

Explicit zone assignment: where VM zone information is available (the agent can read the HANA primary VM's and application server VMs' zone and align the application tier accordingly).
Zone placement achieved indirectly: in some architectures using Proximity Placement Groups (PPG) and Availability Sets, the deployment achieves cross-zone separation, but the VM zone metadata isn't available to the agent. In those cases, you can provide the zone/group as an input by mapping HANA VMs and application server VMs into logical groups.

How it works (conceptually)

Think of Azure SAP Zone Alignment Resource Agent as an orchestration layer that sits alongside your existing Pacemaker-managed HANA high availability setup:

Signal: Pacemaker knows which HANA node is primary.
Decision: determine the target zone/group of the HANA primary.
Action: interact with Azure to start/stop VMs and invoke SAP start/stop actions remotely.

Under the hood, the agent uses:

Azure Instance Metadata Service (IMDS) to understand VM context.
Azure Resource Manager APIs to manage application VMs (start/stop/deallocate) and run remote commands.
Standard SAP control operations to start/stop or make instances inactive.

You do not need to change how HANA failover is handled. HANA failover decisions remain exclusively managed by the SAPHANA-SR-* agents. This Resource Agent focuses solely on ensuring the application tier follows the database tier in a predictable and repeatable manner.

Two operational modes: fast recovery vs cost optimization

Customers have different priorities during failovers. The preview supports two modes so you can choose the trade-off that best matches your operational goals.

Option 1: Deactivate (passive mode)

In this mode, SAP instances in the non-primary zone are placed into an inactive/passive state (so they don't take new workload), while the VMs remain running.

Best for: fastest "swing back" during failover

Trade-off: the inactive-zone VMs are still running (no compute cost reduction)

Option 2: Soft shutdown + stop/deallocate.

In this mode, the agent initiates a graceful stop of SAP Application Servers in the non-primary zone and then stops/deallocates the VMs.

Best for: reducing compute usage of SAP application servers in the inactive zone in Pay as You Go model.

Trade-off: reactivation takes longer (VM boot + SAP start)

What you need (high level)

This Pacemaker resource agent assumes a specific but common topology:

Two identical sets of SAP application server VMs (one set per zone/group)
A Pacemaker cluster managing HANA system replication (primary/secondary)
Application-side routing configured so users and jobs can run on either set when activated.

Operationally, you'll also need:

A managed identity with permissions to perform the required VM operations against the application VMs.
Azure Linux Agent installed and running on the SAP application VMs (for remote command execution)

Note on operating system.

This public preview focuses on SUSE Linux Enterprise Server (SLES), specifically SLES 15 SP5 and later.

Current scope and limitations

This preview is intentionally focused so we can learn quickly and make improvements based on customer feedback.

Supported: SAP ABAP systems on HANA scale-up running on SLES
Not supported: SAP Java, HANA scale-out, multi-SID environments

Getting started

If you'd like to evaluate the preview, start here:

The resource agent is available upstream in the ClusterLabs resource-agents repository.

For detailed technical guidance - including prerequisites, installation steps, configuration examples, and troubleshooting - see Part 2 of this blog series.

If you encounter issues or have suggestions, please file them via GitHub Issues so we can track and respond.

What's next

This post covered the concepts, features, and operational modes of the Azure SAP Zone Resource Agent. In Part 2 of this series, we go hands-on with the technical details - architecture deep dive, prerequisites, step-by-step installation, cluster configuration examples, and troubleshooting guidance.

Public preview expectations

During public preview:

This solution is provided as a Public Preview for evaluation and feedback.
It is not covered by a formal support commitment.
The design, configuration, and behaviors may evolve based on learnings.

Because of that, we recommend using this in non-production environments while it is in preview.

If you're interested in piloting the preview, your feedback will help shape what becomes generally available and supported.

Disclaimer

This post describes a public preview capability. It is shared for informational purposes only and is subject to change. It is not a substitute for your organization's validation, testing, and operational readiness reviews.

Azure SAP Zone Resource Agent (Public Preview) — Technical Deep Dive (Part 2)

sanoopt — Tue, 28 Apr 2026 14:15:00 GMT

Overview

In Part 1, we discussed why keeping the SAP application tier aligned with the HANA primary zone matters for latency-sensitive workloads, and how the Azure SAP Zone Resource Agent automates this alignment after failovers. In this post, we get into the specifics - how the agent is structured, what it needs to run, and how to set it up in your Pacemaker cluster.

The azure-sap-zone resource agent is a Pacemaker resource agent designed to manage the alignment of SAP application Azure Virtual Machines (VMs) with the primary HANA Azure VM. This agent ensures that SAP application servers are started in the same Azure availability zone as the HANA primary VM to maintain high availability and optimal performance.

Key Benefits

Reduced Latency: Minimizes cross-zone network latency between application and database tiers
High Availability: Maintains SAP system availability during failover scenarios
Automated Management: Automatically handles VM and SAP instance lifecycle during zone transitions
Cost Optimization: Enables efficient resource utilization across availability zones

Architecture

The following diagram illustrates how the resource agent manages SAP application server alignment with the primary HANA database across Azure availability zones:

Key Components:

HANA Cluster: Primary and secondary HANA VMs are deployed in separate availability zones with System Replication configured
Pacemaker Cluster: Runs across both zones with the azure-sap-zone resource agent deployed on both nodes. The SAP application server VMs are not Pacemaker cluster members - they are managed remotely by the agent via Azure APIs.
Application Servers: Identical sets of SAP application VMs deployed in both availability zones
Azure Management API: Used by the resource agent to control VM lifecycle and execute remote commands
Managed Identity: Provides authentication for Azure API operations

Current State (Zone 1 Primary):

Zone 1: HANA Primary is active, SAP application servers are ACTIVE
Zone 2: HANA Secondary is in standby, SAP application servers are STANDBY (VMs may be running but SAP instances deactivated, or VMs stopped based on stop_vms parameter)

Failover Scenario (Zone 2 becomes Primary):

HANA failover occurs from Zone 1 to Zone 2
Pacemaker detects the failover and the azure-sap-zone resource agent triggers
Agent starts VMs and SAP instances in Zone 2 (same zone as new primary HANA)
Agent stops/deactivates SAP instances and optionally stops VMs in Zone 1
Result: Zone 2 becomes the active zone with both HANA Primary and active SAP application servers

How It Works

Background

In Azure deployments of SAP systems with scale-up HANA configurations, optimizing latency between SAP application servers and the HANA database server can significantly enhance performance. In typical zonal deployments, primary and secondary HANA servers are located in different availability zones, with SAP application servers distributed across these zones. In certain Azure regions, cross-zonal latency may be higher, affecting performance for processes involving significant data transfer between application and database tiers.

Solution Overview

This resource agent addresses latency concerns by placing critical application servers in the same availability zone as the primary HANA database server. The solution provisions identical SAP application server VMs in both availability zones, with only one set active at any given time.

Execution Workflow

During a database failover, the resource agent executes the following phases in sequence:

start_vms_in_same_zone: Initiates virtual machines in the same zone as the primary HANA VM
wait_for_vms_in_same_zone_to_start: Waits for VMs in the same zone to start successfully
start_sap_in_same_zone: Starts SAP instances in the same zone (parallel execution supported)
wait_for_sap_in_same_zone_to_start: Waits for SAP instances in the same zone to start successfully
stop_sap_in_diff_zone: Stops or deactivates SAP instances in different zones (behavior depends on stop_vms parameter)
wait_for_sap_in_diff_zone_to_stop: Waits for SAP instances in different zones to shut down (skipped when stop_vms=false)
stop_vms_in_diff_zone: Stops VMs in different zones (skipped when stop_vms=false)

The resource agent supports both SAPHanaSR and SAPHanaSR-angi (A Next Generation Interface) resource agents for HANA state detection.

Each phase includes built-in timeout management (controlled by the wait_time parameter) and retry logic. The stop_vms parameter determines whether the agent fully stops and deallocates VMs or just deactivates SAP instances in the non-primary zone.

Cluster Attributes

The resource agent uses the following cluster node attributes to track execution state:

Attribute	Description
azure_sap_zone_current_phase	Stores the current phase of execution
azure_sap_zone_phase_start_time	Records the start time for each phase (used for timeout detection)

Configuration Parameters

The following cluster resource parameters configure the resource agent's behavior:

Name	Description	Type	Default	Required	Example
sid	SAP System ID (SID) name	string	-	✓	S4H
hana_sid	HANA System ID (if different from SAP SID)	string	sid value	✗	HDB
hana_vm_zones	Mapping of HANA VM name to logical zone group (optional; for non-zonal/PPG scenarios)	string	-	✗	hanavm1:1,hanavm2:2
verbose	Enable verbose logging	boolean	false	✗	true
soft_shutdown_timeout	Soft shutdown timeout (seconds). Used as the timeout argument for SAP stop operations when stop_vms=true	integer	600	✗	600
app_vm_names	Comma-separated list of SAP application server VM names	string	-	✗*	sapapp01,sapapp02,sapapp03,sapapp04
app_vm_name_pattern	Regex pattern to identify SAP application server VM names	string	-	✗*	sapapp.*
resource_group	Azure resource group for SAP application servers	string	HANA VMs RG	✗	sap-app-rg
hana_resource	Name of the HANA resource in Pacemaker cluster	string	-	✓	rsc_SAPHana_S4H_HDB00
client_id	Client ID of user-assigned managed identity (optional for system identity)	string	-	✗	a1b2c3d4-e5f6-7890-abcd-ef1234567890
stop_vms	Stop VMs in different zones (true) or just deactivate SAP instances (false)	boolean	false	✗	false
wait_before_stop_sap	Wait time before stopping SAP instances in different zones (seconds)	integer	300	✗	300
wait_time	Wait time for phases to complete (seconds)	integer	600	✗	600
retry_count	Azure API retry count	integer	3	✗	3
retry_wait	Wait time between retries (seconds)	integer	20	✗	20
app_vm_zones	Mapping of app VM name to logical zone group (optional; for non-zonal/PPG scenarios)	string	-	✗*	sapapp01:1,sapapp02:1,sapapp03:2,sapapp04:2

Note: Provide at least one of app_vm_names, app_vm_name_pattern, or app_vm_zones. If multiple are specified, the effective VM list is the union of:

app_vm_names (explicit list),
VMs matching app_vm_name_pattern (when app_vm_names is not provided), and
VM names present in app_vm_zones.

If app_vm_zones is provided but neither app_vm_names nor app_vm_name_pattern are set, the agent treats app_vm_zones as the authoritative source of application VM names.

If both app_vm_names and app_vm_name_pattern are set, app_vm_names is used (pattern matching is skipped). app_vm_zones is still merged in.

app_vm_zones is a supplemental mapping primarily intended for non-zonal/PPG scenarios; it can be used just for the subset of VMs that have no Azure zone metadata.

Non-zonal/PPG Note: In proximity placement group (PPG) or other non-zonal deployments, Azure VM metadata and ARM VM properties may not include an Availability Zone. In that case:

Set hana_vm_zones to map each HANA VM name to a logical group label (e.g. hanavm1:1,hanavm2:2).
Set app_vm_zones to map each SAP application VM (or just the subset missing zone metadata) to a logical group label. These are logical labels used for alignment, not necessarily Azure Availability Zones.

Warning (zone/group mappings): Be very careful when setting hana_vm_zones and app_vm_zones (sometimes referred to as “hana zone” / “app VM zone” parameters). In deployments where Azure zone metadata is unavailable, these mappings fully determine which application VMs are considered “same group” vs “different group”.

If the grouping is wrong, the agent can take action on the wrong servers:

With stop_vms=false, it may deactivate (make passive) SAP instances on the wrong app VMs.
With stop_vms=true, it may soft-shutdown SAP and stop/deallocate the wrong app VMs.

Double-check the VM name → group assignments and keep them consistent across the HANA and app tiers.

Parameter interactions and practical notes

hana_sid is used when the HANA Pacemaker attributes are named using a different SID than the SAP application SID.
When stop_vms=true, the agent:
- waits wait_before_stop_sap seconds before initiating shutdown (to reduce churn during rapid failovers),
- calls sapcontrol -function Stop <soft_shutdown_timeout> on the "different-zone" app VMs (soft shutdown with a configurable timeout),
- waits for process dispstatus to become GRAY (stopped) before deallocating VMs.
When stop_vms=false, the agent:
- calls sapcontrol -function ABAPSetServerInactive on the "different-zone" app VMs,
- leaves the SAP instances running but in inactive/passive mode, and
- does not stop/deallocate the Azure VMs.
Timeouts:
- Most phases use wait_time.
- The stop/wait-for-stop window effectively needs to cover both wait_time and soft_shutdown_timeout.

app_vm_zones format

Use a comma-separated mapping: vm_name:group.

Example: app_vm_zones="sapapp01:1,sapapp02:1,sapapp03:2,sapapp04:2"

Start-time validation

If you provide app_vm_zones or hana_vm_zones in a deployment where Azure zone metadata is available, the agent validates on every start that the provided values match Azure. It will fail to start if they do not match.

Prerequisites

Topology requirement (critical)

This solution assumes you have two equivalent sets of SAP application server VMs, one set placed/aligned with each HANA VM zone (or logical group in non-zonal/PPG deployments). Only one set is expected to be active at a time.

Zonal deployments: provision the same application server capacity in each Availability Zone used by the HANA primary/secondary VMs.
Non-zonal / PPG deployments: provision two equivalent application server sets and map them consistently using hana_vm_zones and app_vm_zones.

“Equivalent/identical” here means the VMs are prepared to run the same SAP application workload (same SAP installation/SID/instance layout and configuration as applicable for your landscape), so the agent can start SAP on the “same-zone” set and deactivate/stop SAP on the “different-zone” set during failover.

SAP workload routing/groups (required)

To ensure workloads continue seamlessly when the active application-server set switches zones/groups, configure your SAP group/routing settings to include both application server sets as appropriate for your landscape, including:

SAP logon groups: SMLG
RFC server groups: RZ12
Background/batch server groups: SM61
Spool server groups: SPAD
Update configuration/groups: SM14

System Requirements

Operating System Support

SUSE Linux Enterprise Server (SLES): 15 SP5 and above

Network Requirements

HANA VMs must have outbound access to Azure API endpoints
Required for VM management operations (start, stop, execute commands)

Azure Linux VM Agent

Must be installed on all SAP application server VMs
Pre-installed on Azure Marketplace images
Manual installation required for custom/non-Marketplace images
Installation Guide

Python Environment

Python 3.x installed on HANA cluster nodes
Required Python packages: requests (all other imports are Python standard library)

Verification Command:

python3 -c 'import os, sys, time, subprocess, re, requests, shlex, random; from typing import Dict, List, Optional'

HANA Resource Agent Compatibility

SAPHanaSR: Traditional SAP HANA System Replication resource agent
SAPHanaSR-angi: SAP HANA System Replication A Next Generation Interface resource agent

The azure-sap-zone resource agent automatically detects which HANA resource agent is in use and adapts accordingly.

Azure Permissions

The resource agent requires either a user-assigned managed identity (via client_id) or a system-assigned managed identity with specific Azure permissions:

Required Azure Role Actions

{ "permissions": [ { "actions": [ "Microsoft.Compute/*/read", "Microsoft.Compute/virtualMachines/start/action", "Microsoft.Compute/virtualMachines/restart/action", "Microsoft.Compute/virtualMachines/powerOff/action", "Microsoft.Compute/virtualMachines/deallocate/action", "Microsoft.Compute/virtualMachines/runCommand/action", "Microsoft.Compute/virtualMachines/runCommands/read", "Microsoft.Compute/virtualMachines/runCommands/write" ], "notActions": [], "dataActions": [], "notDataActions": [] } ] }

Identity Assignment Requirements

User-assigned managed identity must be assigned to both HANA servers
Identity must have Virtual Machine Contributor role (or custom role with above actions)
Role assignment scope: SAP application server VMs' resource group (recommended) or individual VMs

Limitations

Supported SAP Systems: ABAP systems on HANA scale-up only
Not Supported: SAP JAVA, HANA scale-out, multi-SID environments

Installation

Step 1: Azure Configuration

Configure Azure resources using Azure CLI. Install Azure CLI if not already available.

PowerShell Script for Azure Setup

# Define parameters - Update these values for your environment $subscriptionId = "Your-Subscription-ID" $hanaResourceGroup = "HANA-VMs-Resource-Group" $hanaVMNames = @("hana-vm1", "hana-vm2") $managedIdentityName = "sap-azure-zone-alignment" $customAzureRole = "Azure SAP Zone Alignment" # Resource group scope assignment (recommended) $sapAppResourceGroup = "SAP-Application-Servers-Resource-Group" # Alternative: Direct VM assignment $sapAppVMNames = @("sap-app1", "sap-app2", "sap-app3", "sap-app4") # Login to Azure az login # Verify Azure Linux Agent and run-command capability on application servers $sapAppVMNames | ForEach-Object -ThrottleLimit $sapAppVMNames.Count -Parallel { $vmName = $_ $result = az vm run-command invoke ` --resource-group $using:sapAppResourceGroup ` --name $vmName ` --command-id RunShellScript ` --scripts "systemctl is-active waagent" ` --output json 2>&1 | ConvertFrom-Json $msg = $result.value[0].message if ($msg -match '\[stdout\]\s*active') { Write-Host "[$vmName] OK - waagent active, run-command working" } else { Write-Host "[$vmName] FAIL - unexpected output: $msg" } } # Create custom Azure role $roleDefinition = @{ Name = $customAzureRole IsCustom = $true Description = "Custom Azure role for sap-azure-zone pacemaker resource agent" Actions = @( "Microsoft.Compute/*/read", "Microsoft.Compute/virtualMachines/start/action", "Microsoft.Compute/virtualMachines/restart/action", "Microsoft.Compute/virtualMachines/powerOff/action", "Microsoft.Compute/virtualMachines/deallocate/action", "Microsoft.Compute/virtualMachines/runCommand/action", "Microsoft.Compute/virtualMachines/runCommands/read", "Microsoft.Compute/virtualMachines/runCommands/write" ) NotActions = @() AssignableScopes = @("/subscriptions/$subscriptionId") } | ConvertTo-Json -Depth 3 $roleDefinition | Out-File -FilePath "$env:TEMP\az-role.json" -Encoding utf8 az role definition create --role-definition "$env:TEMP\az-role.json" # Recommendation: Use a user-assigned managed identity for authentication. # System-assigned managed identities are also supported; if you choose this option, # ensure that system-assigned managed identity is enabled on both HANA VMs and that # the required roles (listed below) are assigned to each system identity. # Create user-assigned managed identity $managedIdentityResourceId = az identity create ` --resource-group $hanaResourceGroup ` --name $managedIdentityName ` --query id --output tsv # Assign managed identity to HANA VMs foreach ($vmName in $hanaVMNames) { az vm identity assign ` --resource-group $hanaResourceGroup ` --name $vmName ` --identities $managedIdentityResourceId } # Alternative: Enable system-assigned managed identity (uncomment if preferred) # foreach ($vmName in $hanaVMNames) { # az vm identity assign ` # --resource-group $hanaResourceGroup ` # --name $vmName # } # Assign role to managed identity (resource group scope) $managedIdentityPrincipalId = az identity show ` --resource-group $hanaResourceGroup ` --name $managedIdentityName ` --query principalId --output tsv az role assignment create ` --assignee-object-id $managedIdentityPrincipalId ` --assignee-principal-type ServicePrincipal ` --role $customAzureRole ` --scope "/subscriptions/$subscriptionId/resourceGroups/$sapAppResourceGroup" # Display the client ID (needed for cluster configuration) Write-Host "Managed Identity Client ID:" az identity show ` --resource-group $hanaResourceGroup ` --name $managedIdentityName ` --query clientId --output tsv

Step 2: Install Resource Agent

Download and Install on Both HANA Cluster Nodes

# Download the resource agent script curl -o azure-sap-zone.in https://raw.githubusercontent.com/ClusterLabs/resource-agents/refs/heads/main/heartbeat/azure-sap-zone.in # Create the resource agent file sudo cp azure-sap-zone.in /usr/lib/ocf/resource.d/heartbeat/azure-sap-zone # Update the interpreter line # Note: the downloaded file typically starts with the placeholder `#!@PYTHON@ -tt`. # Replace it with your actual python3 path. PYTHON3_PATH="$(command -v python3)" echo "python3: ${PYTHON3_PATH}" # Bash note: `!` triggers history expansion inside double-quotes, so use this quoting form. sudo sed -i '1 s|^#!@PYTHON@ -tt$|#!'"${PYTHON3_PATH}"' -tt|' /usr/lib/ocf/resource.d/heartbeat/azure-sap-zone # If you need to force a specific interpreter path, you can also do: # sudo sed -i '1 s|^#!@PYTHON@ -tt$|#!/usr/bin/python3 -tt|' /usr/lib/ocf/resource.d/heartbeat/azure-sap-zone # Convert line endings and set permissions sudo dos2unix /usr/lib/ocf/resource.d/heartbeat/azure-sap-zone sudo chmod +x /usr/lib/ocf/resource.d/heartbeat/azure-sap-zone # Copy to secondary node (alternative: repeat above steps manually) sudo scp /usr/lib/ocf/resource.d/heartbeat/azure-sap-zone <secondary-hana-vm>:/usr/lib/ocf/resource.d/heartbeat/

Configuration

Configuration Options

The resource agent provides two distinct behaviors for application servers in the different zone/group.

Option	Setting	What happens to SAP	Do the “different-zone” servers take new users/jobs/sessions?	What happens to the Azure VMs	Typical trade-off
1) Deactivate (Passive mode)	stop_vms=false	SAP stays running, but the agent calls sapcontrol -function ABAPSetServerInactive to set the instance inactive/passive	No — the server is kept out of service for new workload (e.g., new user logons, new batch/background work, and other new sessions)	VMs stay running	Fastest to make active again, but no Azure compute cost savings for the inactive zone because the VMs keep running
2) Soft shutdown + stop/deallocate	stop_vms=true	Agent calls sapcontrol -function Stop <soft_shutdown_timeout> (graceful stop with a configurable timeout) and waits until the instance is stopped (dispstatus=GRAY)	No — during shutdown the instance is not available for new workload/sessions	After shutdown, VMs are stopped and deallocated	Slower to re-activate (VM boot + SAP start), but can save costs in pay-as-you-go models by deallocating the inactive-zone VMs

Notes:

soft_shutdown_timeout controls how long SAP is given to stop gracefully.
stop_vms=true is the only mode where the agent will stop/deallocate VMs.

Note on capacity: When using stop_vms=true, deallocated VMs are not guaranteed to have capacity available when restarted. Consider using On-Demand Capacity Reservations (ODCR) or Capacity Reservation Groups to ensure VM sizes remain available in both zones. The resource agent does not manage capacity reservations — this is an infrastructure planning consideration.

Cluster Configuration Examples

The configuration has two parts:

Create the primitive resource — choose one of the examples below (A–F) based on your deployment pattern.
Create the clone and order constraint — this is required regardless of which example you use (see Step 2 below).

Note on monitor interval: the resource agent advertises a default monitor interval of 300 seconds in its meta-data. The examples below use a shorter interval (e.g. 10s) to detect failovers quickly; choose an interval appropriate for your environment.

Step 1: Create the primitive resource

Choose the example that matches your deployment:

Example A: Zonal deployment (system-assigned managed identity) + explicit VM list

Use this when Azure Availability Zones are present and you want to provide an explicit list of application VMs.

SLES (crmsh):

sudo crm configure primitive azure-sap-zone ocf:heartbeat:azure-sap-zone \ params sid=<SAP_SID> \ hana_resource=<HANA_CLUSTER_RESOURCE_NAME> \ app_vm_names=<app_vm1,app_vm2,app_vm3,app_vm4> \ stop_vms=false \ wait_time=600 \ verbose=true \ meta failure-timeout=120s \ op start start-delay=60s interval=0s timeout=360s \ op monitor interval=10s timeout=360s \ op stop timeout=10s interval=0s on-fail=ignore

Example B: Zonal deployment (user-assigned managed identity) + VM name pattern

Use this when Azure Availability Zones are present and you want the agent to discover application VMs by name.

SLES (crmsh):

sudo crm configure primitive azure-sap-zone ocf:heartbeat:azure-sap-zone \ params sid=<SAP_SID> \ hana_resource=<HANA_CLUSTER_RESOURCE_NAME> \ app_vm_name_pattern=<REGEX_OR_PREFIX_PATTERN> \ client_id=<MANAGED_IDENTITY_CLIENT_ID> \ stop_vms=false \ wait_time=600 \ verbose=true \ meta failure-timeout=120s \ op start start-delay=60s interval=0s timeout=360s \ op monitor interval=10s timeout=360s \ op stop timeout=10s interval=0s on-fail=ignore

Example C: Non-zonal / PPG deployment (logical grouping)

Use this when Azure zone metadata is missing (for example, proximity placement group or other non-zonal deployments).

Key points:

Set hana_vm_zones to map each HANA VM name to a logical group label (for example hanavm1:1,hanavm2:2).
Set app_vm_zones to map each application VM name (or just the subset missing zone metadata) to a logical group label.
If Azure later reports real zone data for those VMs, the agent validates on every start that your mapping matches Azure and fails if it does not.

SLES (crmsh):

sudo crm configure primitive azure-sap-zone ocf:heartbeat:azure-sap-zone \ params sid=<SAP_SID> \ hana_resource=<HANA_CLUSTER_RESOURCE_NAME> \ hana_vm_zones="<hana_vm1>:1,<hana_vm2>:2" \ app_vm_zones="sapapp01:1,sapapp02:1,sapapp03:2,sapapp04:2" \ stop_vms=false \ wait_time=600 \ verbose=true \ meta failure-timeout=120s \ op start start-delay=60s interval=0s timeout=360s \ op monitor interval=10s timeout=360s \ op stop timeout=10s interval=0s on-fail=ignore

Example D: Mixed deployment (mostly zonal, a few VMs missing zone metadata)

Use this when most application VMs have Azure zone metadata, but a small subset does not. Provide the full VM list via app_vm_names (or discovery via app_vm_name_pattern), and provide app_vm_zones only for the VMs that are missing zone metadata.

SLES (crmsh):

Example E: Zonal deployment with stop_vms=true (shutdown + deallocate different-zone VMs)

Use this when you want maximum cost optimization by shutting down and deallocating the application VMs in the non-primary zone.

SLES (crmsh):

sudo crm configure primitive azure-sap-zone ocf:heartbeat:azure-sap-zone \ params sid=<SAP_SID> \ hana_resource=<HANA_CLUSTER_RESOURCE_NAME> \ app_vm_names=<app_vm1,app_vm2,app_vm3,app_vm4> \ stop_vms=true \ wait_before_stop_sap=300 \ soft_shutdown_timeout=600 \ wait_time=600 \ verbose=true \ op start start-delay=60s interval=0s timeout=360s \ op monitor interval=10s timeout=360s \ op stop timeout=10s interval=0s on-fail=ignore

Example F: HANA SID differs from SAP SID (hana_sid)

Use this when the HANA cluster uses a different SID, so the HANA Pacemaker attributes are named hana_<hana_sid>_*.

SLES (crmsh):

sudo crm configure primitive azure-sap-zone ocf:heartbeat:azure-sap-zone \ params sid=<SAP_SID> \ hana_sid=<HANA_SID> \ hana_resource=<HANA_CLUSTER_RESOURCE_NAME> \ app_vm_names=<app_vm1,app_vm2,app_vm3,app_vm4> \ stop_vms=false \ verbose=true

Step 2: Create clone and order constraint

After creating the primitive resource using any of the examples above, run the following commands to create the clone resource and order constraint. This is required for all deployment patterns.

SLES (crmsh):

# Create clone resource (runs on both nodes) sudo crm configure clone cln_azure-sap-zone azure-sap-zone \ meta clone-node-max=1 target-role=Started interleave=true # Create order constraint (start after HANA resource) sudo crm configure order ord_azure-sap-zone Mandatory: <HANA_CLONE_RESOURCE> cln_azure-sap-zone symmetrical=false

Usage

After installation and configuration, the resource agent will automatically:

Monitor HANA primary location: Detects which availability zone hosts the current HANA primary
Manage application servers: Starts/stops or activates/deactivates SAP application servers based on zone alignment
Handle failover scenarios: Automatically adjusts during HANA failover events

Manual Operations

Enable Verbose Logging

# SLES sudo crm_resource --resource azure-sap-zone --set-parameter verbose --parameter-value true

Resource Management

Put resource in maintenance mode (for maintenance):

Setting the resource to unmanaged mode stops Pacemaker from running any operations (start, stop, monitor) on the resource, which prevents the agent from taking action during planned maintenance.

# SLES — enable maintenance mode sudo crm resource maintenance cln_azure-sap-zone on

Resume resource management:

# SLES — disable maintenance mode sudo crm resource maintenance cln_azure-sap-zone off

Validating the Setup with a Test Failover

Once the resource agent is installed and configured, we recommend running through a test failover on a non-production system to confirm everything works end to end. The steps below walk you through the before, during, and after of a validation cycle.

Step 1: Verify the resource agent is running

Before triggering a failover, confirm the resource agent is healthy and the cluster sees it on both nodes:

# Check overall cluster status sudo crm status # Verify the azure-sap-zone clone is started on both nodes sudo crm resource show cln_azure-sap-zone

You should see the clone resource running on both HANA cluster nodes.

Step 2: Check the initial state

Record the current state so you can compare after the failover:

# Which node is the HANA primary? sudo crm status | grep -i "Masters\|Promoted" # What zone/phase does the resource agent report? sudo crm_attribute --name azure_sap_zone_current_phase --query --quiet --node $(hostname) # Check application server VM power state (from Azure CLI, if available) az vm list -g <SAP-App-Resource-Group> -d --query "[].{Name:name, PowerState:powerState, Zone:zones[0]}" -o table

At this point the phase should be all_phases_completed (if the agent has already aligned once) or Started / no_action_required depending on which node you are on.

Step 3: Enable verbose logging (recommended)

Turn on verbose logging before the failover so you can trace every phase in detail:

sudo crm_resource --resource azure-sap-zone --set-parameter verbose --parameter-value true

Step 4: Trigger a test HANA failover

Important: Only perform this on a test/non-production system.

You can trigger a controlled HANA takeover using standard Pacemaker commands. The exact method depends on your HANA resource agent:

# Option A: Migrate the HANA primary to the secondary node sudo crm resource move <HANA_CLONE_RESOURCE> <target-node> force # After the move completes, clear the location constraint so Pacemaker can manage normally sudo crm resource clear <HANA_CLONE_RESOURCE>

Alternatively, if your runbook uses sr_takeover or SAPHanaSR tools, follow your existing takeover procedure. The key point is that the HANA primary ends up on the other node/zone.

Step 5: Monitor the resource agent's progress

After the failover, the resource agent on the new primary node will detect the zone change and begin executing its phases. You can watch it in real time:

# Watch the phase attribute update (run on the new primary node) watch -n 5 'crm_attribute --name azure_sap_zone_current_phase --query --quiet --node $(hostname)'

You should see the phase progress through:

start_vms_in_same_zone
wait_for_vms_in_same_zone_to_start
start_sap_in_same_zone
wait_for_sap_in_same_zone_to_start
stop_sap_in_diff_zone
wait_for_sap_in_diff_zone_to_stop (only when stop_vms=true)
stop_vms_in_diff_zone (only when stop_vms=true)
all_phases_completed

Step 6: Validate the outcome

Once the phase reaches all_phases_completed, verify that the application tier has been aligned correctly.

Check application VMs in the same zone as the new HANA primary:

# Verify VMs are running az vm list -g <SAP-App-Resource-Group> -d --query "[].{Name:name, PowerState:powerState, Zone:zones[0]}" -o table # Verify SAP instances are active (GREEN) — run on a same-zone app VM sapcontrol -nr <instance_number> -function GetProcessList

All SAP processes on the same-zone VMs should show dispstatus: GREEN.

Check application VMs in the different zone:

If stop_vms=false: the VMs should still be running, but SAP instances should be in inactive/passive mode. You can verify this by checking logon groups (SMLG) or the server's active status.
If stop_vms=true: the VMs should be stopped/deallocated in the Azure portal or via az vm list.

Step 7: Review the logs

Check the Pacemaker log to confirm all phases executed without errors:

# View all agent activity sudo grep -i 'azure-sap-zone' /var/log/pacemaker/pacemaker.log | tail -50 # Filter to only INFO/WARNING/ERROR messages (skip routine monitor noise) sudo grep -iE 'azure-sap-zone.*(INFO|WARNING|ERROR):' /var/log/pacemaker/pacemaker.log | grep -v -iE "All phases|monitor: Started"

Example output (filtered):

Apr 23 10:15:32 hanavm1 azure-sap-zone INFO: monitor: Started Apr 23 10:15:32 hanavm1 azure-sap-zone INFO: Executing phase: start_vms_in_same_zone Apr 23 10:15:35 hanavm1 azure-sap-zone INFO: Executing phase: wait_for_vms_in_same_zone_to_start Apr 23 10:15:45 hanavm1 azure-sap-zone INFO: All VMs are started Apr 23 10:15:45 hanavm1 azure-sap-zone INFO: Executing phase: start_sap_in_same_zone Apr 23 10:15:45 hanavm1 azure-sap-zone INFO: Starting SAP on VMs: ['sapapp01', 'sapapp02'] Apr 23 10:16:02 hanavm1 azure-sap-zone INFO: Executing phase: wait_for_sap_in_same_zone_to_start Apr 23 10:16:15 hanavm1 azure-sap-zone INFO: All SAP instances are started Apr 23 10:16:15 hanavm1 azure-sap-zone INFO: Executing phase: stop_sap_in_diff_zone Apr 23 10:16:15 hanavm1 azure-sap-zone INFO: Setting SAP instances to passive mode on VMs: ['sapapp03', 'sapapp04'] Apr 23 10:16:20 hanavm1 azure-sap-zone INFO: All phases have been executed successfully Apr 23 10:16:20 hanavm1 azure-sap-zone INFO: monitor: Finished

Look for:

Phase transitions: confirm each phase started and completed in order
No errors: no ERROR or FAIL messages
Timing: note how long the full cycle took — this is your expected failover alignment time

Step 8: Clean up

After validation, you can disable verbose logging to reduce log volume:

sudo crm_resource --resource azure-sap-zone --set-parameter verbose --parameter-value false

If you triggered the failover using crm resource move, make sure the location constraint was cleared (Step 4) so Pacemaker can manage resources normally going forward.

Troubleshooting

Common Issues

1. Authentication Problems

Verify managed identity is assigned to HANA VMs
Check Azure role assignments
Ensure proper permissions on target application server VMs

2. Network Connectivity

Validate outbound access to Azure API endpoints
Check firewall rules and network security groups

3. Azure Linux Agent Issues

Verify agent status: systemctl status waagent
Check agent logs: /var/log/waagent.log

Log Analysis

View Resource Agent Logs

sudo grep -i 'azure-sap-zone' /var/log/pacemaker/pacemaker.log

Common Log Patterns

Phase transitions: Look for "current_phase" changes
API errors: Search for "Azure API" or "HTTP" error codes
Timeout issues: Check for "timeout" or "wait_time exceeded"

Performance Monitoring

Monitor the following metrics:

Phase execution times: Should complete within configured wait_time
API response times: Azure API calls should be < 30 seconds
VM startup times: Application server boot time affects total failover duration

FAQ

Q: Can I use this with SAP JAVA systems? A: No, this resource agent currently only supports SAP ABAP systems on HANA scale-up configurations.

Q: What HANA resource agents are supported? A: The agent supports both SAPHanaSR and SAPHanaSR-angi (A Next Generation Interface) resource agents and automatically detects which one is in use.

Q: What happens if an application server VM fails to start? A: The resource agent will retry based on the retry_count parameter and eventually fail the phase if the VM doesn't start within the wait_time.

Q: Can I run this in a multi-SID environment? A: No, multi-SID environments are not currently supported.

Q: Can I use different SIDs for SAP and HANA? A: Yes, use the hana_sid parameter if your HANA SID differs from your SAP SID.

Q: Can I use system-assigned managed identity instead of user-assigned? A: Yes, simply omit the client_id parameter and ensure system-assigned managed identity is enabled on both HANA VMs with appropriate permissions.

Important Notes

Resource State Management Upon completion, the cluster attribute azure_sap_zone_current_phase is set to all_phases_completed. The resource agent will not take further action until restarted.

Maintenance Operations When performing maintenance on application servers in different zones (e.g., patching), put the resource in maintenance mode to prevent the agent from taking action:

# SLES sudo crm resource maintenance cln_azure-sap-zone on

Zone Alignment This solution requires identical SAP application server VMs in both availability zones. Only one set should be active at any time.

Wrapping up

With the information in this post, you should have what you need to evaluate the Azure SAP Zone Resource Agent in your environment - from setting up the managed identity and permissions, to installing the agent, configuring the cluster, and troubleshooting common issues. If you haven't already, we recommend reading Part 1 for an introduction to the concepts and features behind this solution.

We welcome your feedback during this public preview. If you encounter issues or have suggestions, please file them via GitHub Issues on the ClusterLabs resource-agents repository.

Public preview expectations

During public preview:

This solution is provided as a Public Preview for evaluation and feedback.
It is not covered by a formal support commitment.
The design, configuration, and behaviors may evolve based on learnings.

Because of that, we recommend using this in non-production environments while it is in preview.

If you're interested in piloting the preview, your feedback will help shape what becomes generally available and supported.

Disclaimer

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!