Merge pull request #233490 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)

Author: huypub

articles/azure-vmware/set-up-backup-server-for-azure-vmware-solution.md

@@ -37,7 +37,7 @@ This article helps you prepare your Azure VMware Solution environment to back up
 
 ## Limitations
 
-- Update Rollup 1 for Azure Backup Server v3 must be installed.
+- Update Rollup 2 for Azure Backup Server v3 must be installed.
 - You can't backup user snapshots before the first Azure Backup Server backup. After Azure Backup Server finishes the first backup, then you can back up user snapshots.
 - Azure Backup Server can't protect VMware vSphere VMs with pass-through disks and physical raw device mappings (pRDMs).
 - Azure Backup Server can't detect or protect VMware vSphere vApps.
@@ -316,9 +316,9 @@ If you downloaded the software package to a different server, copy the files to
 
 1. After the installation step finishes, select **Close**.
 
-### Install Update Rollup 1
+### Install Update Rollup 2
 
-Installing the Update Rollup 1 for Azure Backup Server v3 is mandatory before you can protect the workloads.  You can find the bug fixes and installation instructions in the [knowledge base article](https://support.microsoft.com/en-us/help/4534062/).
+Installing the Update Rollup 2 for Azure Backup Server v3 is mandatory before you can protect the workloads.  You can find the bug fixes and installation instructions in the [knowledge base article](https://support.microsoft.com/help/5004579/).
 
 ## Add storage to Azure Backup Server
 

articles/event-grid/delivery-and-retry.md

@@ -54,6 +54,9 @@ You can customize the retry policy when creating an event subscription by using
 
 For sample CLI and PowerShell command to configure these settings, see [Set retry policy](manage-event-delivery.md#set-retry-policy).
 
+> [!NOTE]
+> If you set both `Event time to live (TTL)` and `Maximum number of attempts`, Event Grid uses the first to expire to determine when to stop event delivery. For example, if you set 30 minutes as time-to-live (TTL) and 5 max delivery attempts. When an event isn't delivered after 30 minutes (or) isn't delivered after 5 attempts, whichever happens first, the event is dead-lettered. If you set max delivery attempts to 10, with respect to [exponential retry schedule](#retry-schedule), max 6 number of delivery attempts happen before 30 minutes TTL will be reached, therefore setting max number of attempts to 10 will have no impact in this case and events will be dead-lettered after 30 minutes.
+
 ## Output batching 
 Event Grid defaults to sending each event individually to subscribers. The subscriber receives an array with a single event. You can configure Event Grid to batch events for delivery for improved HTTP performance in high-throughput scenarios. Batching is turned off by default and can be turned on per-subscription.
 

articles/event-grid/manage-event-delivery.md

@@ -119,7 +119,7 @@ az eventgrid event-subscription create \
 ```
 
 > [!NOTE]
-> If you set both `event-ttl` and `max-deliver-attempts`, Event Grid uses the first to expire to determine when to stop event delivery. For example, if you set 30 minutes as time-to-live (TTL) and 10 max delivery attempts. When an event isn't delivered after 30 minutes (or) isn't delivered after 10 attempts, whichever happens first, the event is dead-lettered.  
+> If you set both `event-ttl` and `max-deliver-attempts`, Event Grid uses the first to expire to determine when to stop event delivery. For example, if you set 30 minutes as time-to-live (TTL) and 5 max delivery attempts. When an event isn't delivered after 30 minutes (or) isn't delivered after 5 attempts, whichever happens first, the event is dead-lettered. If you set max delivery attempts to 10, with respect to [exponential retry schedule](delivery-and-retry.md#retry-schedule), max 6 number of delivery attempts happen before 30 minutes TTL will be reached, therefore setting max number of attempts to 10 will have no impact in this case and events will be dead-lettered after 30 minutes.
 
 ### PowerShell
 
@@ -148,7 +148,7 @@ New-AzEventGridSubscription `
 ```
 
 > [!NOTE]
-> If you set both `event-ttl` and `max-deliver-attempts`, Event Grid uses the first to expire to determine when to stop event delivery. For example, if you set 30 minutes as time-to-live (TTL) and 10 max delivery attempts. When an event isn't delivered after 30 minutes (or) isn't delivered after 10 attempts, whichever happens first, the event is dead-lettered.  
+> If you set both `event-ttl` and `max-deliver-attempts`, Event Grid uses the first to expire to determine when to stop event delivery. For example, if you set 30 minutes as time-to-live (TTL) and 5 max delivery attempts. When an event isn't delivered after 30 minutes (or) isn't delivered after 5 attempts, whichever happens first, the event is dead-lettered. If you set max delivery attempts to 10, with respect to [exponential retry schedule](delivery-and-retry.md#retry-schedule), max 6 number of delivery attempts happen before 30 minutes TTL will be reached, therefore setting max number of attempts to 10 will have no impact in this case and events will be dead-lettered after 30 minutes. 
 
 ## Next steps
 

articles/expressroute/expressroute-faqs.md

@@ -185,7 +185,7 @@ If your service provider can establish two Ethernet virtual circuits over the ph
 
 No. We don't support layer 2 connectivity extensions into Azure.
 
-### Can I've more than one ExpressRoute circuit in my subscription?
+### Can I have more than one ExpressRoute circuit in my subscription?
 
 Yes. You can have more than one ExpressRoute circuit in your subscription. The default limit is set to 50. You can contact Microsoft Support to increase the limit, if needed.
 

articles/governance/policy/samples/nist-sp-800-53-r5.md

@@ -33,6 +33,16 @@ initiative definition.
 > definitions for this compliance standard may change over time. To view the change history, see the
 > [GitHub Commit History](https://github.com/Azure/azure-policy/commits/master/built-in-policies/policySetDefinitions/Regulatory%20Compliance/NIST_SP_800-53_R5.json).
 
+>[!IMPORTANT]
+> These Azure Policies are an opinionated view of implementing the NIST 800-53 Rev. 5 controls. Not
+> every policy may be required to meet the controls for your organization. This initiative assumes
+> your orgnization is using Microsoft tools and properties. Some policies may prefer some Azure features
+> over other Azure features that equally implement the security required to meet the controls.
+> This is a choice the Enterprise can make by creating their own initiative.
+> 
+> As such, most enterprises will need to create their own version of this initative and tailor it 
+> to their environment and replace some polices with custom versions to implement the controls required. 
+
 ## Access Control
 
 ### Policy and Procedures