SA DR Rights — The Licence Benefit That Eliminates Redundant DR Licence Purchasing

Software Assurance Disaster Recovery (DR) rights are one of the most financially significant and least understood SA benefits for organisations with on-premises server infrastructure and formal DR environments. The right allows organisations with qualifying SA-covered licences to run a passive cold-standby replica of a production server — in a separate physical location, in a hosted environment, or in Azure — without purchasing additional production licences for the DR instance. For enterprises that have purchased separate production licences for each DR server (a common compliance error driven by misunderstanding of the SA DR provision), correcting this represents significant licence cost elimination at the next EA renewal.

The financial scale is significant. A typical enterprise with 200 Windows Server Datacenter cores in a production data centre may have purchased 200 equivalent DR cores at a separate DR site — a cost of approximately $54,000/year in SA on the duplicate DR licences (at $270/core/year SA rate for Datacenter). With SA DR rights correctly activated, those DR instances are covered by the production licence's SA at zero additional licence cost. The $54,000/year in duplicate DR SA disappears. The production SA cost remains — but it now covers both production and one passive DR instance per production server, making the SA ROI materially stronger.

1:1
The SA disaster recovery entitlement ratio: for each server with active SA coverage, one passive cold-standby failover server instance can be run at the same or separate location without additional production licence cost. The DR instance must remain passive (no production workloads, no active user services) unless a failover event is in progress. Source: Microsoft Product Terms, March 2026.

Products Covered by SA DR Rights

SA DR rights apply to qualifying Microsoft server products where SA is active on the production licences. The primary qualifying products relevant to large enterprise DRenvironments are: Windows Server (Standard and Datacenter editions — 1:1 passive DR instance per production licence without additional Windows Server licence cost); SQL Server (Enterprise, Standard, and Developer editions — passive AG replicas count as qualifying DR instances under SA DR rights for Enterprise, with specific replica count limits; Standard allows 1 passive replica); System Center suite products; Exchange Server (per server licence with SA — passive DAG member servers qualify); and SharePoint Server (per server licence with SA — warm standby farm servers qualify as passive DR).

Products that do not qualify for SA DR rights include: CAL-based server access components (where the per-user/device CAL structure does not have a passive DR equivalent), most client software (Office, Windows OS on client devices), and cloud-based subscription services (M365, Azure services — these have built-in availability and redundancy and do not use on-premises DR rights constructs).

The Passive vs Active Boundary — The Critical Compliance Line

SA DR rights apply strictly to passive standby servers. The product terms define "passive" as: the server exists for DR purposes only, runs the software in a cold or warm standby state, and does not serve active production requests, execute active batch jobs, process user transactions, or serve any purpose other than DR replication and failover readiness while the production system is operational. The moment a DR server is used for any production workload — load balancing, dev/test, reporting, batch processing, backup jobs, or any active workload — it ceases to qualify as a passive DR instance under SA DR rights and requires its own production licence.

The most common compliance error in SA DR rights deployment is using DR servers for development, testing, or reporting workloads during normal operations — justifying it as "the DR environment isn't being used for anything right now." This is a licence compliance violation. A SQL Server DR replica used for read-only reporting (even via secondary read routing) requires its own SQL Server licence, separate from the DR rights coverage. SQL Server Always On Availability Groups with read-scale secondaries are a specific high-risk area: the passive failover secondary (no read queries routed, no active workloads) qualifies for SA DR rights; the readable secondary (reporting queries routed to it) does not. For organisations running AG readable secondaries on DR hardware and relying on SA DR rights as coverage, this is a material compliance gap.

ProductSA DR EntitlementPassive ConditionCommon Compliance Trap
Windows Server Standard1 passive DR instance per production licenceNo active user services, roles, or production workloadsDev/test use on DR servers negates DR rights
Windows Server Datacenter1 passive DR instance per production licence (unlimited VMs on DR host under SA)Host must remain passive; VMs must remain passiveLive migration / HA clustering ≠ passive DR — both nodes must have production licences
SQL Server EnterprisePassive AG replicas covered for non-readable secondariesSecondary replica: no read queries, no active reportingReadable AG secondary requires its own production SQL licence
SQL Server Standard1 passive failover instance under SA DR rightsStrictly passive — no always-on readable secondaryStandard allows only basic Always On FCI or AG with 1 passive DR replica
Exchange ServerPassive DAG member servers covered by SA on production server licencesDAG members must not handle active mail flowClear passive definition — DAG passive members well-understood
SharePoint ServerWarm standby farm servers covered by production SAFarm must not serve active user requestsUsing DR farm for lower-priority site collections = active use

Azure DR Under Software Assurance Rights

SA DR rights extend to Azure — organisations can run passive DR instances in Azure for qualifying SA-covered on-premises server products without purchasing Azure marketplace SQL Server or Windows Server VM images (which include the Microsoft software licence cost in the PAYG rate). This is a distinct benefit from Azure Hybrid Benefit (AHB), which applies to active Azure workloads. SA DR rights in Azure cover passive DR instances specifically: a cold or warm standby Azure VM running Windows Server or SQL Server that exists to receive failover traffic from an on-premises production environment, with no active workloads in steady state.

The commercial implication: an Azure VM running SQL Server Enterprise as a passive AG replica for an on-premises Always On deployment can use the organisation's production SQL Server Enterprise SA to cover the licence component of the Azure VM, without purchasing a separate Azure SQL licence or consuming a separate SQL Server Core licence. The Azure VM compute cost (the IaaS compute rate) is still payable — the SA DR right covers the software licence component, not the Azure infrastructure cost. For a 16-vCore passive SQL AG replica in Azure running on a D16s_v5 ($0.768/hour compute), the SA DR right eliminates the SQL Server Enterprise licence equivalent cost (~$5.96/hour at Azure PAYG rates for SQL Enterprise) — a saving of approximately $52,200/year for a single passive replica VM. For organisations with multiple passive AG replicas in Azure, the SA DR rights are financially significant justification for maintaining SQL Server Enterprise SA.

SA DR Rights Compliance Review
We audit your DR environment against SA DR rights coverage requirements, identify passive/active boundary violations, and calculate the licence cost saving from correct DR rights activation.
Request a Review

Documentation Requirements — The Gap Most Organisations Miss

SA DR rights do not require formal activation through VLSC or a Microsoft portal — they are automatically available to qualifying SA-covered licences. However, the documentation requirement is the element most organisations overlook. Microsoft's product terms require that organisations be able to demonstrate, during a Software Asset Management (SAM) engagement or licence audit, that DR servers claimed under SA DR rights meet the passive criteria. The documentation that supports this demonstration includes: an inventory of production licences with SA coverage (from VLSC) mapping to specific DR server instances; a written DR policy document confirming the DR servers' passive status and purpose; network diagram or configuration documentation showing no active workload routing to DR servers in steady state; and (for SQL Server AG configurations) replication configuration documentation confirming passive replica settings (no read-scale routing for replicas claimed under DR rights).

In the majority of Microsoft SAM engagements that review DR environments, the organisations using SA DR rights have the configuration correct but cannot produce the documentation. The outcome in a SAM engagement without documentation is that Microsoft's auditors treat the DR servers as production instances requiring licences — generating a finding that is commercially resolvable but requires negotiation rather than simple documentation review. Maintaining the DR rights documentation is a low-cost, high-protection practice that takes approximately one day per year to maintain. For organisations already producing SAM documentation for other compliance purposes (ISO 27001, SOX IT controls), the DR rights documentation is an addendum to the existing licence management framework.

SA DR Rights Documentation Checklist

Production-to-DR mapping document: List each production server (hostname, OS, product, edition, core count) → mapped to its passive DR counterpart (hostname, location, DR technology: AG replica / DAG member / VM replica). Date-stamped and signed off by IT asset management.

DR policy statement: Written statement confirming: DR servers are passive standby, not used for production workloads, development, testing, or batch processing in steady state. Includes failover activation protocol and SA DR coverage assertion.

SQL Server AG configuration export: For SQL Server AG deployments, export the AG configuration confirming secondary replica connection type (No = no active connections; Read-intent only may create risk; All = definitely active use).

SA coverage confirmation: VLSC export confirming active SA coverage on each production licence mapped to a DR instance. SA expiry date must be current for DR rights to be active.

Review cadence: Annual review to capture infrastructure changes — new DR servers, changed AG configurations, or SA renewal status updates.

Using DR Rights in EA Renewal Negotiations

SA DR rights have two roles in EA renewal negotiations. First, they are a positive SA ROI justification: for organisations with substantial passive DR environments in Azure or on-premises, the SA DR rights represent tangible licence cost avoidance that strengthens the case for SA renewal on Windows Server and SQL Server lines. A DR environment with 300 passive SQL Server Enterprise cores in Azure — covered by SA DR rights — represents $1.07M/year in avoided Azure SQL Enterprise licence costs. This is the SA ROI justification that makes SQL Server Enterprise SA commercially non-negotiable for cloud DR environments.

Second, SA DR rights are a boundary for the SA removal decision — for product lines with active Azure DR configurations relying on SA DR rights, removing SA eliminates DR rights coverage and creates immediate licence exposure in the Azure DR environment. The cost of replacing SA-based Azure DR coverage with Azure SQL licences or Windows Server Azure marketplace rates typically exceeds the SA cost — creating a floor below which SA removal is economically irrational regardless of other benefit activation rates. For the full SA ROI framework including DR rights valuation methodology, see our Software Assurance complete guide and our SA ROI calculation.