Merge branch 'main' of https://github.com/microsoftdocs/azure-docs-pr into app1

v-thepet · v-thepet · commit b87fd7acd37e · 2025-06-16T15:09:50.000-07:00
diff --git a/articles/application-gateway/configuration-listeners.md b/articles/application-gateway/configuration-listeners.md
@@ -1,12 +1,17 @@
 ---
 title: Azure Application Gateway listener configuration
-description: This article describes how to configure Azure Application Gateway listeners.
+description: Learn how Application Gateway listeners handle incoming web requests efficiently. Configure protocols, certificates, HTTP2 support, and WebSocket connectivity for optimal performance.
+#customer intent: As a network administrator, I want to understand how to configure Application Gateway listeners so that I can properly handle incoming web requests for my organization's applications.
 services: application-gateway
 author: mbender-ms
 ms.service: azure-application-gateway
 ms.topic: concept-article
-ms.date: 07/19/2023
-ms.author: mbender 
+ms.date: 06/16/2025
+ms.author: mbender
+ms.custom:
+  - ai-gen-docs-bap
+  - ai-gen-description
+  - ai-seo-date:06/16/2025
 ---
 
 # Application Gateway listener configuration
@@ -23,7 +28,7 @@ When you create a new listener, you choose between [*basic* and *multi-site*](./
 
 - If you want all of your requests (for any domain) to be accepted and forwarded to backend pools, choose basic. Learn [how to create an application gateway with a basic listener](./quick-create-portal.md).
 
-- If you want to forward requests to different backend pools based on the *host* header or host names, choose multi-site listener. Application Gateway relies on HTTP 1.1 host headers to host more than one website on the same public IP address and port.  To differentiate requests on the same port, you must specify a host name that matches with the incoming request. To learn more, see [hosting multiple sites using Application Gateway](multiple-site-overview.md).
+- If you want to forward requests to different backend pools based on the *host* header or host names, choose multi-site listener. Application Gateway relies on HTTP 1.1 host headers to host more than one website on the same public IP address and port. To differentiate requests on the same port, you must specify a host name that matches with the incoming request. To learn more, see [hosting multiple sites using Application Gateway](multiple-site-overview.md).
 
 ### Order of processing listeners
 
@@ -88,6 +93,8 @@ Set-AzApplicationGateway -ApplicationGateway $gw
 > [!IMPORTANT]
 > When creating an application gateway resource through the Azure portal, the default option for **HTTP2** is set as enabled. You can choose **Disabled** during creation, and re-enabled HTTP2 support using the Azure portal by selecting **Enabled** under **HTTP2** in **Application gateway > Configuration**.
 >
+> In instances where HTTP2 isn't supported by a client, HTTP1.1 will be used. Enabling HTTP2 doesn't disable HTTP1.1; it allows support for both.
+>
 
 ### WebSocket support
 
diff --git a/articles/communication-services/quickstarts/email/handle-email-events.md b/articles/communication-services/quickstarts/email/handle-email-events.md
@@ -99,13 +99,16 @@ Check out the full list of [events that Communication Services supports](../../.
 
 After you generate an event, notice that `Email Delivery Report Received` and `Email Engagement Tracking Report Received` events are sent to your endpoint. These events show up in the [Event Grid viewer](/samples/azure-samples/azure-event-grid-viewer/azure-event-grid-viewer/) that we set up at the beginning of this quickstart. Select the eye icon next to the event to see the entire payload. Events should look similar to the following data:
 
+#### Microsoft.Communication.EmailDeliveryReportReceived event
 :::image type="content" source="./media/handle-email-events/email-delivery-report-received.png" alt-text="Screenshot of the Azure Event Grid viewer that shows the Event Grid schema for an EMAIL delivery report received event.":::
 
+#### Microsoft.Communication.EmailEngagementTrackingReportReceived event
 :::image type="content" source="./media/handle-email-events/email-engagementtracking-report-received.png" alt-text="Screenshot of the Azure Event Grid viewer that shows the Event Grid schema for an EMAIL engagement tracking report event.":::
 
 - `EngagementContext` refers to the link clicked when the engagementType is `Click`.
 - `UserAgent` refers to the User-Agent from which this email engagement event originated. For example, if the user interacted on Microsoft Edge using a Win10 machine: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36 Edge/12.246
 - `EngagementType` refers to the type of engagement. Possible values are `View` or `Click`.
+- `Recipient` refers to the recipient who engaged with the email. Note that this field is empty when the original email was sent to multiple recipients at a time.
 
 For more information, see [event schemas and other eventing concepts](../../../event-grid/event-schema-communication-services.md).
 
diff --git a/articles/communication-services/quickstarts/email/media/handle-email-events/email-delivery-report-received.png b/articles/communication-services/quickstarts/email/media/handle-email-events/email-delivery-report-received.png
diff --git a/articles/communication-services/quickstarts/email/media/handle-email-events/email-engagementtracking-report-received.png b/articles/communication-services/quickstarts/email/media/handle-email-events/email-engagementtracking-report-received.png
diff --git a/articles/healthcare-apis/deidentification/configure-private-endpoints.md b/articles/healthcare-apis/deidentification/configure-private-endpoints.md
@@ -1,7 +1,7 @@
 ---
 title: Configure Private Endpoint network access to Azure Health Data Services de-identification service
 description: Learn how to restrict network access to your de-identification service.
-ms.date: 10/22/2024
+ms.date: 06/16/2025
 ms.topic: how-to
 author: jovinson-ms
 ms.author: jovinson
diff --git a/articles/healthcare-apis/deidentification/manage-access-rbac.md b/articles/healthcare-apis/deidentification/manage-access-rbac.md
@@ -6,7 +6,7 @@ ms.author: jovinson
 ms.service: azure-health-data-services
 ms.subservice: deidentification-service
 ms.topic: how-to
-ms.date: 07/16/2024
+ms.date: 06/16/2025
 ---
 
 # Use Azure role-based access control with the de-identification service
diff --git a/articles/healthcare-apis/deidentification/managed-identities.md b/articles/healthcare-apis/deidentification/managed-identities.md
@@ -6,7 +6,7 @@ ms.author: jovinson
 ms.service: azure-health-data-services
 ms.subservice: deidentification-service
 ms.topic: how-to
-ms.date: 07/17/2024
+ms.date: 06/16/2025
 ---
 
 # Use managed identities with the de-identification service
diff --git a/articles/healthcare-apis/deidentification/monitor-deidentification-service-reference.md b/articles/healthcare-apis/deidentification/monitor-deidentification-service-reference.md
@@ -1,7 +1,7 @@
 ---
 title: Monitoring data reference for the De-identification service in Azure Health Data Services
 description: This article contains important reference material you need when you monitor the De-identification service in Azure Health Data Services.
-ms.date: 09/05/2024
+ms.date: 06/16/2025
 ms.custom: horz-monitor
 ms.topic: reference
 author: jovinson-ms
@@ -32,4 +32,4 @@ Microsoft.HealthDataAIServices/deidServices
 ## Related content
 
 - See [Monitor the Azure Health Data Services de-identification service](monitor-deidentification-service.md) for a description of monitoring the Azure Health Data Services de-identification service.
-- See [Monitor Azure resources with Azure Monitor](/azure/azure-monitor/essentials/monitor-azure-resource) for details on monitoring Azure resources.
+- See [Monitor Azure resources with Azure Monitor](/azure/azure-monitor/essentials/monitor-azure-resource) for details on monitoring Azure resources.
diff --git a/articles/healthcare-apis/deidentification/monitor-deidentification-service.md b/articles/healthcare-apis/deidentification/monitor-deidentification-service.md
@@ -1,7 +1,7 @@
 ---
 title: Monitor the De-identification service in Azure Health Data Services
 description: Start here to learn how to monitor De-identification service in Azure Health Data Services.
-ms.date: 09/05/2024
+ms.date: 06/16/2025
 ms.custom: horz-monitor
 ms.topic: conceptual
 author: jovinson-ms
@@ -66,4 +66,4 @@ The following table lists some suggested alert rules for the de-identification s
 ## Related content
 
 - See [the de-identification service monitoring data reference](monitor-deidentification-service-reference.md) for a reference of the metrics, logs, and other important values created for the de-identification service.
-- See [Monitoring Azure resources with Azure Monitor](/azure/azure-monitor/essentials/monitor-azure-resource) for general details on monitoring Azure resources.
+- See [Monitoring Azure resources with Azure Monitor](/azure/azure-monitor/essentials/monitor-azure-resource) for general details on monitoring Azure resources.
diff --git a/articles/healthcare-apis/deidentification/overview.md b/articles/healthcare-apis/deidentification/overview.md
@@ -5,7 +5,7 @@ author: kimiamavon
 ms.service: azure-health-data-services
 ms.subservice: deidentification-service
 ms.topic: overview
-ms.date: 7/17/2024
+ms.date: 06/16/2025
 ms.author: kimiamavon
 ---
 
diff --git a/articles/healthcare-apis/deidentification/redaction-format.md b/articles/healthcare-apis/deidentification/redaction-format.md
@@ -6,7 +6,7 @@ ms.author: kimiamavon
 ms.service: azure-health-data-services
 ms.subservice: deidentification-service
 ms.topic: tutorial
-ms.date: 12/05/2024
+ms.date: 06/16/2025
 ---
 
 # Tutorial: Use a custom redaction format with the de-identification service
diff --git a/articles/healthcare-apis/deidentification/transparency-note.md b/articles/healthcare-apis/deidentification/transparency-note.md
@@ -5,7 +5,7 @@ author: kimiamavon
 ms.service: azure-health-data-services
 ms.subservice: deidentification-service
 ms.topic: legal
-ms.date: 8/16/2024
+ms.date: 06/16/2025
 ms.author: kimiamavon
 ---
 # The basics of Azure Health Data Services’ de-identification service
diff --git a/articles/reliability/concept-redundancy-replication-backup.md b/articles/reliability/concept-redundancy-replication-backup.md
@@ -89,7 +89,7 @@ A cloud environment's physical location as whole can be organized into physical
 | A group of datacenters, which in Azure is called an *availability zone* | City-wide electrical storm |
 | The wider geographical area that the datacenter is in, such as a city, which is an Azure *region* | Widespread natural disaster |
 
-From a reliability perspective, an important way to mitigate the risks associated with a physical scope is to spread instances of a component across different physical scopes. Azure services with build-in redundancy may offer you one or more of the following three ways to deploy redundant instances:
+From a reliability perspective, an important way to mitigate the risks associated with a physical scope is to spread instances of a component across different physical scopes. Azure services with built-in redundancy may offer you one or more of the following three ways to deploy redundant instances:
 
 - *Local redundancy* places instances in multiple parts of a single Azure datacenter and protects against hardware failures that might affect a single instance. Local redundancy typically provides the lowest cost and latency. However, a datacenter failure could mean that all of the instances are unavailable.
 
diff --git a/articles/storage/files/storage-files-planning.md b/articles/storage/files/storage-files-planning.md
@@ -68,9 +68,9 @@ To access an Azure file share, the user of the file share must be authenticated
 - **Microsoft Entra Domain Services**: Microsoft Entra Domain Services provides a Microsoft-managed domain controller that can be used for Azure resources. Domain joining your storage account to Microsoft Entra Domain Services provides similar benefits to domain joining it to a customer-owned AD DS. This deployment option is most useful for application lift-and-shift scenarios that require AD-based permissions. Since Microsoft Entra Domain Services provides AD-based authentication, this option also uses the Kerberos authentication protocol.
 - **Microsoft Entra Kerberos for hybrid identities**: Microsoft Entra Kerberos allows you to use Microsoft Entra ID to authenticate [hybrid user identities](../../active-directory/hybrid/whatis-hybrid-identity.md), which are on-premises AD identities that are synced to the cloud. This configuration uses Microsoft Entra ID to issue Kerberos tickets to access the file share with the SMB protocol. This means your end users can access Azure file shares over the internet without requiring network connectivity to domain controllers from Microsoft Entra hybrid joined and Microsoft Entra joined VMs.
 - **Active Directory authentication over SMB for Linux clients**: Azure Files supports identity-based authentication over SMB for Linux clients using the Kerberos authentication protocol through either AD DS or Microsoft Entra Domain Services.
-- **Azure storage account key**: Azure file shares may also be mounted with an Azure storage account key. To mount a file share this way, the storage account name is used as the username and the storage account key is used as a password. Using the storage account key to mount the Azure file share is effectively an administrator operation, because the mounted file share has full permissions to all of the files and folders on the share, even if they have ACLs. When using the storage account key to mount over SMB, the NTLMv2 authentication protocol is used. If you intend to use the storage account key to access your Azure file shares, we recommend using private endpoints or service endpoints as described in the [Networking](#networking) section.
+- **Azure storage account key**: Although it's not recommended for security reasons, you can also mount Azure file shares using an Azure storage account key instead of using an identity. To mount a file share using the storage account key, the storage account name is used as the username and the storage account key is used as a password. Using the storage account key to mount the Azure file share is effectively an administrator operation, because the mounted file share has full permissions to all of the files and folders on the share, even if they have ACLs. When using the storage account key to mount over SMB, the NTLMv2 authentication protocol is used. In nearly all cases, we recommend using [identity-based authentication](storage-files-active-directory-overview.md) instead of the storage account key to access SMB Azure file shares. However, if you must use the storage account key, we recommend using private endpoints or service endpoints as described in the [Networking](#networking) section.
 
-For customers migrating from on-premises file servers, or creating new file shares in Azure Files intended to behave like Windows file servers or NAS appliances, domain joining your storage account to **Customer-owned AD DS** is the recommended option. To learn more about domain joining your storage account to a customer-owned AD DS, see [Overview - on-premises Active Directory Domain Services authentication over SMB for Azure file shares](storage-files-identity-ad-ds-overview.md).
+For customers migrating from on-premises file servers or creating new file shares in Azure Files intended to behave like Windows file servers or NAS appliances, domain joining your storage account to **Customer-owned AD DS** is recommended. To learn more about domain joining your storage account to a customer-owned AD DS, see [Overview - on-premises Active Directory Domain Services authentication over SMB for Azure file shares](storage-files-identity-ad-ds-overview.md).
 
 ## Networking
 
