Skip to content

Commit 68f9ed3

Browse files
authored
Merge pull request #308078 from MicrosoftDocs/repo_sync_working_branch
Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)
2 parents 2adb39d + a6bc502 commit 68f9ed3

3 files changed

Lines changed: 8 additions & 2 deletions

File tree

articles/backup/azure-elastic-san-backup-overview.md

Lines changed: 5 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -25,7 +25,11 @@ Elastic SAN backup includes the following key features:
2525

2626
- **Region availability**: The feature is currently [available in specific regions](azure-elastic-storage-area-network-backup-support-matrix.md#supported-regions) only.
2727
- **Snapshot export**: Exports the selected Elastic SAN to an independent managed disk incremental snapshot (operational tier) at a given point in time.
28-
- **Storage and resiliency**: Managed Disk incremental snapshot is stored in Locally redundant storage (LRS) resiliency (in LRS-[supported regions](azure-elastic-storage-area-network-backup-support-matrix.md#supported-regions)), independent of the Elastic SAN lifecycle.
28+
- **Storage and resiliency**: Managed Disk incremental snapshot can be stored in Zonally redundant storage (ZRS) or Locally redundant storage (LRS) resiliency (in supported regions), independent of the Elastic SAN lifecycle.
29+
30+
> [!NOTE]
31+
> ZRS snapshot storage applies only to new Backup instances created in regions that support ZRS, and only when no managed disk incremental snapshot is already exported from the volume snapshot. In these scenarios, snapshots are stored in ZRS by default. Existing Backup instances and regions that don't support ZRS continue to store snapshots as LRS.
32+
2933
- **Recovery points**: Supports up to **450** recovery points, which allows you customize **daily** or **weekly** schedules to align your backup strategy with business continuity and compliance needs.
3034
- **Backup tier**: Supports operational tier.
3135

articles/container-apps/custom-domains-managed-certificates.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -32,6 +32,8 @@ The requirements are:
3232

3333
- Establish a CNAME record for subdomains that maps directly to the container app's generated domain name. Mapping to an intermediate CNAME value blocks certificate issuance and renewal. Examples of CNAME values are traffic managers, Cloudflare, and similar services.
3434

35+
- If any [Certification Authority Authorization (CAA) domain record](https://wikipedia.org/wiki/DNS_Certification_Authority_Authorization) exists on the root domain, you must explicitly allow DigiCert as a certificate issuer by creating a CAA domain record with the value `0 issue digicert.com`. Without this setting, the certificate issuance and **renewal** will fail.
36+
3537
> [!NOTE]
3638
> To ensure the certificate issuance and subsequent renewals proceed successfully, all requirements must be met at all times when the managed certificate is assigned.
3739

articles/logic-apps/enterprise-integration/create-integration-account.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -136,7 +136,7 @@ For this task, you can use the Azure portal, [Azure CLI](/cli/azure/resource#az-
136136

137137
```azurecli
138138
az logic integration-account create --resource-group myresourcegroup \
139-
--name integration_account_01 --location westus --sku name=Standard
139+
--name integration_account_01 --location westus --sku Standard
140140
```
141141

142142
Your integration account name can contain only letters, numbers, hyphens (-), underscores (_), parentheses (()), and periods (.).

0 commit comments

Comments
 (0)