Adding API Version 2026-11-01 for Site Recovery

[sisunkar]

Adding SiteRecovery api-version 2026-11-01

Adds a new stable api-version 2026-11-01 to recoveryservicessiterecovery, covering two independent A2A feature areas: Confidential VM (CVM) disk encryption and IPv6 dual-stack networking. The change is purely additive (new version folder + @added(Versions.v2026_11_01)-guarded models); no existing version is modified.

The two Site Recovery feature areas share one API version. This PR also includes matching versioned contracts for vault management and Backup, with no new functionality in those two areas.

What's included

A2A Confidential VM (CVM) disk encryption

• models.tsp: ConfidentialDiskEncryptionInfo, UpdateConfidentialDiskEncryptionInfo models and the confidentialDiskEncryptionInfo / recoveryConfidentialDataDiskEncryptionIdentity properties

A2A IPv6 dual-stack networking

• ipVersion on NIC ip-configs: new IPVersion extensible enum (IPv4 / IPv6, modelAsString: true) surfaced as ipVersion on IPConfigDetails. Declares the address family of a recovery NIC ip-config, orthogonal to the existing static/dynamic allocation type. A missing value is treated as IPv4, so existing clients are unaffected. The leaf is response-only: an ip-config's address family is derived from the source NIC during discovery, and the service update path resolves it from the stored configuration rather than from caller input, so it is deliberately not exposed on IPConfigInputDetails.
• Vault-level recovery-network auto-sync: new RecoveryNetworkConfigAutoSyncPolicy extensible enum (Disabled / Enabled) surfaced as recoveryNetworkConfigAutoSync on VaultSettingProperties (response) and VaultSettingCreationInputProperties (input). Controls whether the A2A recovery network configuration is automatically kept in sync as the source VM's network configuration changes. On the creation input an omitted value leaves the stored policy unchanged.
• Examples: ReplicationVaultSetting_Create / _Get / _List updated to show the new auto-sync leaf. New ReplicationProtectedItems_Update_A2ADualStack shows an A2A NIC carrying both an IPv4 and an IPv6 ip-config, on the update input and on the response, so the ipVersion wire shape is demonstrated end to end.

Both enums use modelAsString: true in line with the Azure ARM guidelines for new enums, so that a future service-side value does not break already-generated SDKs. This governs SDK/response forward-compatibility only, and is not a statement about request validation: the service validates supplied values and rejects an unrecognized recoveryNetworkConfigAutoSync with InvalidParameter (HTTP 400), which is the intended behaviour for a request enum.

Shared / version plumbing

• main.tsp: v2026_11_01 version enum entry
• readme.md: package-2026-11-01 tag + default-tag update
• service.yaml: 2026-11-01 typespec entry
• stable/2026-11-01/service.json + examples/ (158) and stable/2026-11-01/examples/ (158)

Vault management and Backup version alignment

• recoveryServices: adds 2026-11-01, carrying forward the stable 2026-07-01 vault-management contract and its 45 examples without new fields or operations.
• recoveryServicesBackup: adds 2026-11-01, carrying forward the stable 2026-08-01 Backup contract and its 116 examples without new fields or operations.
• Both areas include TypeSpec version declarations, source and emitted examples, generated-contract files, README tags/defaults, and service.yaml entries. Existing published versions and the ASR files are unchanged by this follow-up.
• Follows the sibling-version pattern of PR [RecoveryServicesBackup] Add AFS Managed Identity support (accessType, identityInfo) for 2026-05-31-preview #43641 and supplies all three Swagger references requested for RegionalRP PR 17243711.
• The sibling Swagger files were carried forward from the checked-in stable contracts. Local TypeSpec compilation was not run because npm execution is restricted; the PR automated checks must confirm generated output matches the committed files.

Notes for reviewers

• stable/2026-11-01/service.json is fully regenerated from the TypeSpec sources. This also picks up the pending ReplicationProtectedItems_AddDisks x-ms-examples rename that was already present in the .tsp source but missing from the committed swagger — that drift was previously failing TypeSpec Validation on this branch.
• The version alignment preserves the latest PR contract and examples, including response-only ipVersion; previously published API versions are unchanged.

Contribution checklist

• I have reviewed the contribution guidelines.
• Purely additive new api-version (no breaking changes to existing versions).
• Examples added and referenced by service.json.

[azure-pipelines]

Azure Pipelines:
Successfully started running 10 pipeline(s).
2 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.

[github-actions]

Next Steps to Merge

Next steps that must be taken to merge this PR:

• ❌ This PR is in purview of the ARM review (label: ARMReview). This PR must get ARMSignedOff label from an ARM reviewer.
  This PR is not ready for ARM review (label: NotReadyForARMReview). This PR will not be reviewed by ARM until relevant problems are fixed. Consult the rest of this Next Steps to Merge comment for details.
  Once the blocking problems are addressed, add to the PR a comment with contents /azp run. Automation will re-evaluate this PR and if everything looks good, it will add WaitForARMFeedback label which will put this PR on the ARM review queue.
  For details of the ARM review, see aka.ms/azsdk/pr-arm-review
  
• ❌ This PR is NotReadyForARMReview because it has the BreakingChangeReviewRequired label.
  
• ❌ This PR has at least one breaking change (label: BreakingChangeReviewRequired).
  To unblock this PR, follow the process at aka.ms/brch.
• ❌ The required check named Breaking Change(Cross-Version) has failed. To unblock this PR, follow the process at aka.ms/brch.

Comment generated by summarize-checks workflow run.

[github-actions]

API Change Check

APIView identified API level changes in this PR and created the following API reviews

Language	API Review for Package
Swagger	Microsoft.RecoveryServices-SiteRecovery
Go	sdk/resourcemanager/recoveryservices/armrecoveryservicessiterecovery
JavaScript	@azure/arm-recoveryservices-siterecovery
Python	azure-mgmt-recoveryservicessiterecovery
Java	com.azure.resourcemanager:azure-resourcemanager-recoveryservicessiterecovery
C#	Azure.ResourceManager.RecoveryServicesSiteRecovery
Swagger	Microsoft.RecoveryServices-RecoveryServices
Swagger	Microsoft.RecoveryServices-RecoveryServicesBackup
Python	azure-mgmt-recoveryservices
Python	azure-mgmt-recoveryservicesbackup
JavaScript	@azure/arm-recoveryservices
JavaScript	@azure/arm-recoveryservicesbackup
Go	sdk/resourcemanager/recoveryservices/armrecoveryservicesbackup
Java	com.azure.resourcemanager:azure-resourcemanager-recoveryservicesbackup

---

Comment generated by After APIView workflow run.

[Razvan Badea (razvanbadea-msft)]

ARM API Review

Posting findings from the ARM API Reviewer agent (critic-verified, 3 iteration(s), converged) against commit bf7a74a. Findings SR-1, SR-2, and SR-6 concern lines outside the PR diff and are posted as top-level PR comments rather than inline comments. SR-4 was clarified in its existing review thread. Other findings remain unposted pending human review.

Approval labels observed: none.

[Razvan Badea (razvanbadea-msft)]

[EXISTING] 🔴 Blocking [SEC-SECRET-DETECT] models.tsp — line 5534 — BitLocker key data lacks secret metadata.

Issue: BEKDetails.secretData is explicitly documented as BitLocker encryption-key data but has no @secret; emitted bms.json, line 7695, JSON path $.definitions.BEKDetails.properties.secretData, lacks x-ms-secret. The recovery-point GET and LIST response schemas both reach this field through IaasVMRecoveryPoint.keyAndSecret.bekDetails. Perspective: Security Skeptic; structural data-flow analysis. This is a specification handling defect, not proof of a runtime leak.

Classification reasoning: The same unannotated field is present in the previous preview, line 10114, and previous GA, line 7695; not introduced in this batch.

Suggested fix: Annotate the TypeSpec leaf and regenerate; verify x-ms-secret: true in output. Independently ensure the service omits/redacts this key on GET/LIST and uses a separately authorized POST if key retrieval is needed; the annotation alone does not implement server-side redaction.

/** BEK data. */
@secret
secretData?: string;

[Razvan Badea (razvanbadea-msft)]

[EXISTING] 🔴 Blocking [SEC-SECRET-DETECT] models.tsp — lines 5954–5967 — Export-result SAS credentials suppress secret detection instead of declaring secrets.

Issue: ExportJobsOperationResultInfo.blobSasKey and .excelFileBlobSasKey are documented as SAS credentials granting blob access for 15 minutes. Both use a TODO secret-prop suppression and neither has @secret. Emitted bms.json, lines 9798 and 9806, JSON paths $.definitions.ExportJobsOperationResultInfo.properties.blobSasKey and $.definitions.ExportJobsOperationResultInfo.properties.excelFileBlobSasKey, also lack x-ms-secret. ExportJobsOperationResults_Get returns this shared result schema. Perspective: Security Skeptic; structural data-flow analysis. Two leaves in the same shared result construct are one finding.

Classification reasoning: Both defects exist in the previous preview, lines 12503 and 12511, and previous GA, lines 9798 and 9806. The TODO suppressions also exist in base TypeSpec at lines 5937 and 5949.

Approval context: Checked Approved-TypeSpecSuppression; none was present at the session SHA. Confirm whether approval covers these suppressions. If already approved, apply the appropriate label and resolve this conversation; otherwise obtain approval or address the finding.

Suggested fix: Replace both secret-prop suppressions with native annotations and regenerate. Verify x-ms-secret: true for both leaves. Ensure GET export polling omits/redacts SAS credentials; if retrieval is required, expose a separately authorized POST. Annotation does not itself enforce runtime redaction.

/** SAS key to access the blob. It expires in 15 mins. */
@secret
blobSasKey?: string;

/** SAS key to access the blob. It expires in 15 mins. */
@secret
excelFileBlobSasKey?: string;

[Razvan Badea (razvanbadea-msft)]

[EXISTING] 🔴 Blocking [SEC-SECRET-DETECT] models.tsp — lines 3273–3285 — Security PIN response credentials lack secret annotations.

Issue: TokenInformation.token suppresses secret-prop with a TODO instead of using @secret; the same returned model's securityPIN is also documented as a Security PIN but is unannotated. The POST SecurityPINs_Get action explicitly retrieves the security PIN. Emitted bms.json, lines 15035 and 15044, JSON paths $.definitions.TokenInformation.properties.token and $.definitions.TokenInformation.properties.securityPIN, lack x-ms-secret. POST retrieval is appropriate; the defect is missing secret classification, not the HTTP method. Perspective: Security Skeptic.

Classification reasoning: Both unmarked leaves exist in the previous preview, lines 18060 and 18069, and previous GA, lines 15035 and 15044. Base TypeSpec has the same token suppression at line 3267.

Approval context: Checked Approved-TypeSpecSuppression; none was present at the session SHA. Confirm whether approval covers this suppression. If already approved, apply the appropriate label and resolve this conversation; otherwise obtain approval or address the finding.

Suggested fix: Remove the secret-prop suppression on token, annotate both credential leaves and regenerate. Keep the POST retrieval action and the existing PIN wire name; retain the separate legacy casing suppression if it is still needed.

/** Token value. */
@secret
token?: string;

/** Security PIN */
#suppress "@azure-tools/typespec-azure-core/casing-style" "FIXME: Update justification, follow aka.ms/tsp/conversion-fix for details"
@secret
securityPIN?: string;

Note: Expanded after critic review to include the adjacent securityPIN credential in the same response model; classification and severity are unchanged.

[Razvan Badea (razvanbadea-msft)]

ARM API Review

Posting findings from the ARM API Reviewer agent (critic-verified, 3 iteration(s), converged) against commit bf7a74a. Findings B-1, B-2, and B-3 concern lines outside the PR diff and are posted as top-level PR comments rather than inline comments. These are existing Backup secret-handling findings, not regressions introduced by this PR. Other unapproved findings remain unposted pending human review.

Approval labels observed: none.

[Razvan Badea (razvanbadea-msft)]

ARM API Review

Posting findings from the ARM API Reviewer agent (critic-verified, 3 iteration(s), converged) against commit bf7a74a. See inline comments for findings RS-1 through RS-11.

At the human reviewer's request, all eleven are non-blocking Suggestions concerning pre-existing Recovery Services contract debt, not regressions introduced by this PR. Compatibility-sensitive remediation is follow-up work, not a condition of merging this version update. No breaking changes are requested without the applicable service/SDK review and API approval.

Approval labels observed: none.

[sisunkar]

Re: SR-1 — ExportJobDetails.sasToken

Fixed in 87574667f5. From 2026-11-01, sasToken uses a secret SecretString scalar (@typeChangedFrom(Versions.v2026_11_01, string)), so the emitted service.json has format: password and x-ms-secret: true. The secret-prop suppression is removed. Earlier published versions (2025-08-01 to 2026-07-01) are byte-identical. The same pattern is already used in this spec for agentReinstallState (#41618).

On redaction: the annotation classifies the value; whether GET/LIST return it is service behavior, and the token is only produced by the existing ReplicationJobs_Export POST action. We will track response redaction with the service team separately.

[sisunkar]

Re: SR-2 — KEK certificate PFX properties

Fixed in 87574667f5. From 2026-11-01, primaryKekCertificatePfx and secondaryKekCertificatePfx on all five input models (HyperVReplicaAzureApplyRecoveryPointInput, HyperVReplicaAzurePlannedFailoverProviderInput, HyperVReplicaAzureTestFailoverInput, HyperVReplicaAzureUnplannedFailoverInput, RecoveryPlanHyperVReplicaAzureFailoverInput) use the secret SecretString scalar and emit x-ms-secret: true. These are request-only inputs. Earlier published versions are unchanged.

[sisunkar]

Requesting breaking-change review for the Cross-Version TypeFormatChanged errors (11). These come from marking 11 existing SiteRecovery secret properties (ExportJobDetails.sasToken and 10 primary/secondaryKekCertificatePfx properties) as x-ms-secret / format: password in 2026-11-01 only, to address the ARM reviewer's SR-1/SR-2 secret-detection findings. The wire type stays string; older API versions are unchanged. Could a breaking-change reviewer apply BreakingChange-Approved-Security?

[sisunkar]

Re: B-1 — secretData

Razvan Badea (@razvanbadea-msft), this is an existing item and is not introduced or changed by this PR. secretData is unmarked in the published recoveryservicesbackup 2026-08-01 and 2026-10-01 contracts as well. This PR only carries recoveryservicesbackup forward to 2026-11-01 because the API version is registered for the whole Microsoft.RecoveryServices namespace; its 2026-11-01 bms.json is generated from the same TypeSpec as the published 2026-10-01 (#46044) and is identical apart from the version string.

[sisunkar]

Re: B-2 — blobSasKey, excelFileBlobSasKey

Razvan Badea (@razvanbadea-msft), this is an existing item and is not introduced or changed by this PR. The two secret-prop suppressions are unchanged from the published recoveryservicesbackup versions and were approved on #46044 with typespec-suppressions-approved. Could you apply the same label here?

[sisunkar]

Re: B-3 — token, securityPIN

Razvan Badea (@razvanbadea-msft), this is an existing item and is not introduced or changed by this PR. The secret-prop suppression on token is unchanged from the published recoveryservicesbackup versions and was approved on #46044 with typespec-suppressions-approved; securityPIN is unmarked in the published 2026-08-01 and 2026-10-01 contracts as well. Could you apply the same label here?

[sisunkar]

Re: SR-6 — default error responses

Razvan Badea (@razvanbadea-msft), this is an existing item and is not introduced or changed by this PR. As noted in the finding, the same 137 operations have no default error response in the previous published versions; the SiteRecovery 2026-11-01 contract carries them forward unchanged, and the existing R4010 suppression in the readme still applies.

[sisunkar]

Razvan Badea (@razvanbadea-msft), following up on the Avocado discussion: after merging the latest main, Swagger Avocado now passes on the current head c0dbc0940a with 0 errors, so no override is needed.

[sisunkar]

Mushegh Malkhasyan (@MushMal), could you review the Cross-Version TypeFormatChanged errors (11) per the request above? They come from marking existing SiteRecovery secret properties (ExportJobDetails.sasToken and 10 primary/secondaryKekCertificatePfx properties) as x-ms-secret in 2026-11-01 only, to address the ARM reviewer's SR-1/SR-2 findings. The wire type stays string and older API versions are unchanged. This is the same pattern as #44639, where BreakingChange-Approved-Security was applied. Thanks!

[github-actions]

ARM API Review

Posting findings from the ARM API Reviewer agent (critic-verified, 3 iterations, converged) against commit c0dbc0940a76df3eb4b2747d66ac41944b427d61. No new actionable findings were identified in the scoped high-risk review, and no inline findings were posted.

Scoped review: 13 of 667 changed specification/ files reviewed (PR exceeds the automated-review size cap). Not reviewed: the remaining generated/example files and lower-risk duplicated examples outside the selected TypeSpec, configuration, and generated-contract surfaces.

Approval labels observed: BreakingChange-Go-Sdk-Approved, BreakingChange-JavaScript-Sdk-Approved.

Category	Count
🔴 Blocking	0
🟠 Warning	0
🔵 Suggestion	0

No issues found in the reviewed scope. Existing prior findings were reconciled and were not reposted as new regressions.

🔍 ARM API review by ARM API Review: Automated Workflow