Merging changes synced from https://github.com/MicrosoftDocs/azure-docs-pr (branch live)

Author: Learn Build Service GitHub App

articles/expressroute/design-architecture-for-resiliency.md

@@ -25,7 +25,7 @@ Users of ExpressRoute rely on the availability and performance of edge sites, WA
 There are three ExpressRoute resiliency architectures that can be utilized to ensure high availability and resiliency in your network connections between on-premises and Azure. These architecture designs include:
 
 * [Maximum resiliency](#maximum-resiliency)
-* [High resiliency](#high-resiliency---in-preview)
+* [High resiliency](#high-resiliency)
 * [Standard resiliency](#standard-resiliency)
 
 ### Maximum resiliency
@@ -34,7 +34,7 @@ The Maximum resiliency architecture in ExpressRoute is structured to eliminate a
 
 :::image type="content" source="./media/design-architecture-for-resiliency/maximum-resiliency.png" alt-text="Diagram illustrating a pair of ExpressRoute circuits, configured at two distinct peering locations, between an on-premises network and Microsoft.":::
 
-### High resiliency - In Preview
+### High resiliency
 
 High resiliency, also referred to as ExpressRoute Metro, enables the use of multiple sites within the same metropolitan (Metro) area to connect your on-premises network through ExpressRoute to Azure. High resiliency offers site diversity by splitting a single circuit across two sites. The first connection is established at one site and the second connection at a different site. The objective of ExpressRoute Metro is to mitigate the effect of edge-sites isolation and failures by introducing capabilities to enable site diversity. Site diversity is achieved by using a single circuit across paired sites within a metropolitan city, which offers resiliency to failures between edge and region. ExpressRoute Metro provides a higher level of site resiliency than Standard resiliency, but not as much as Maximum resiliency. ExpressRoute Metro architecture can be used for business and mission-critical workloads within a region. For more information, see [ExpressRoute Metro](metro.md)
 

articles/extended-zones/request-access.md

@@ -1,11 +1,11 @@
 ---
 title: Request access to Azure Extended Zones
-description: Learn how to request and gain access to Azure Extended Zone using PowerShell or Azure CLI.
+description: Learn how to request and gain access to an Azure Extended Zone by using Azure PowerShell or Azure CLI.
 author: halkazwini
 ms.author: halkazwini
 ms.service: azure-extended-zones
 ms.topic: how-to
-ms.date: 08/02/2024
+ms.date: 10/18/2024
 ---
 
 # Request access to an Azure Extended Zone
@@ -22,7 +22,7 @@ In this article, you learn how to request and gain access to an Azure Extended Z
 
 # [**PowerShell**](#tab/powershell)
 
-- An Azure account with an active subscription. [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).
+- A billable Azure account.
 
 - Azure Cloud Shell or Azure PowerShell.
 
@@ -32,7 +32,7 @@ In this article, you learn how to request and gain access to an Azure Extended Z
 
 # [**Azure CLI**](#tab/cli)
 
-- An Azure account with an active subscription. [Create an account for free](https://azure.microsoft.com/free/?WT.mc_id=A261C142F).
+- A billable Azure account.
 
 - Azure Cloud Shell or Azure CLI.
 
@@ -96,6 +96,9 @@ In this section, you register resource provider **Microsoft.EdgeZones** to your
 
 To register for an Azure Extended Zone, you must select the subscription that you wish to register Azure Extended Zones for and specify the Extended Zone name.
 
+> [!NOTE]
+> The Azure account that you're using to register for Azure Extended Zones must be a billable account. To share your feedback or ask questions about Azure Extended Zones, contact [Azure Extended Zones support](mailto:[email protected]).
+
 # [**PowerShell**](#tab/powershell)
 
 1. Use [Get-AzEdgeZonesExtendedZone](/powershell/module/az.edgezones/get-azedgezonesextendedzone) cmdlet to list all Azure Extended Zones available to your subscription.

articles/healthcare-apis/availability-zones.md

@@ -36,15 +36,14 @@ Here's a list of the availability zones for Azure Health Data Services.
 - UK South
 - Sweden Central
 - Germany West Central*
-- Qatar Central*
 - East US*
 - East US 2
 - South Central US*
 - West US 2*
 - West US 3*
 - Canada Central
 
-Zones marked with a star ("*") have quota issues due to high demand. Enabling AZ features in these zones may take longer.
+Regions marked with a star ("*") have quota issues due to high demand. Enabling AZ features in these regions may take longer.
 
 ### Limitations
 
@@ -74,4 +73,4 @@ To enable the availability zone on a specific instance, customers need to submit
 
 More information can be found at [Create an Azure support request](/azure/azure-portal/supportability/how-to-create-azure-support-request).
 
-[!INCLUDE [FHIR trademark statement](includes/healthcare-apis-fhir-trademark.md)]
+[!INCLUDE [FHIR trademark statement](includes/healthcare-apis-fhir-trademark.md)]

articles/iot-operations/manage-mqtt-broker/howto-configure-authentication.md

@@ -30,10 +30,10 @@ To link a BrokerListener to a *BrokerAuthentication* resource, specify the `auth
 
 ## Default BrokerAuthentication resource
 
-Azure IoT Operations Preview deploys a default *BrokerAuthentication* resource named `default` linked with the *default* listener in the `azure-iot-operations` namespace. It's configured to only use Kubernetes Service Account Tokens (SATs) for authentication. To inspect it, run:
+Azure IoT Operations Preview deploys a default *BrokerAuthentication* resource named `authn` linked with the *default* listener named `listener` in the `azure-iot-operations` namespace. It's configured to only use Kubernetes Service Account Tokens (SATs) for authentication. To inspect it, run:
 
 ```bash
-kubectl get brokerauthentication default -n azure-iot-operations -o yaml
+kubectl get brokerauthentication authn -n azure-iot-operations -o yaml
 ```
 
 The output shows the default *BrokerAuthentication* resource, with metadata removed for brevity:
@@ -42,7 +42,7 @@ The output shows the default *BrokerAuthentication* resource, with metadata remo
 apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
 kind: BrokerAuthentication
 metadata:
-  name: default
+  name: authn
   namespace: azure-iot-operations
 spec:
   authenticationMethods:
@@ -79,7 +79,7 @@ With multiple authentication methods, MQTT broker has a fallback mechanism. For
 apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
 kind: BrokerAuthentication
 metadata: 
-  name: default
+  name: authn
   namespace: azure-iot-operations
 spec:
   authenticationMethods:

articles/iot-operations/manage-mqtt-broker/howto-configure-brokerlistener.md

@@ -26,7 +26,7 @@ Each listener port can have its own authentication and authorization rules that
 
 Listeners have the following characteristics:
 
-- You can have up to three listeners. One listener per service type of `loadBalancer`, `clusterIp`, or `nodePort`. The default *BrokerListener* named *default* is service type `clusterIp`.
+- You can have up to three listeners. One listener per service type of `loadBalancer`, `clusterIp`, or `nodePort`. The default *BrokerListener* named *listener* is service type `clusterIp`.
 - Each listener supports multiple ports
 - BrokerAuthentication and BrokerAuthorization references are per port
 - TLS configuration is per port
@@ -59,7 +59,7 @@ To view or edit the listener:
 To view the default *BrokerListener* resource, use the following command:
 
 ```bash
-kubectl get brokerlistener default -n azure-iot-operations -o yaml
+kubectl get brokerlistener listener -n azure-iot-operations -o yaml
 ```
 
 The output should look similar to this, with most metadata removed for brevity:
@@ -68,14 +68,14 @@ The output should look similar to this, with most metadata removed for brevity:
 apiVersion: mqttbroker.iotoperations.azure.com/v1beta1
 kind: BrokerListener
 metadata:
-  name: default
+  name: listener
   namespace: azure-iot-operations
 spec:
   brokerRef: default
   serviceName: aio-broker
   serviceType: ClusterIp
   ports:
-  - authenticationRef: default
+  - authenticationRef: authn
     port: 18883
     protocol: Mqtt
     tls:
@@ -94,7 +94,7 @@ To learn more about the default BrokerAuthentication resource linked to this lis
 The default *BrokerListener* uses the service type *ClusterIp*. You can have only one listener per service type. If you want to add more ports to service type *ClusterIp*, you can update the default listener to add more ports. For example, you could add a new port 1883 with no TLS and authentication off with the following kubectl patch command:
 
 ```bash
-kubectl patch brokerlistener default -n azure-iot-operations --type='json' -p='[{"op": "add", "path": "/spec/ports/", "value": {"port": 1883, "protocol": "Mqtt"}}]'
+kubectl patch brokerlistener listener -n azure-iot-operations --type='json' -p='[{"op": "add", "path": "/spec/ports/", "value": {"port": 1883, "protocol": "Mqtt"}}]'
 ```
 
 ---
@@ -146,7 +146,7 @@ spec:
   - port: 1883
     protocol: Mqtt
   - port: 18883
-    authenticationRef: default
+    authenticationRef: authn
     protocol: Mqtt
     tls:
       mode: Automatic

articles/modeling-simulation-workbench/disaster-recovery.md

@@ -3,7 +3,7 @@ title: "Disaster recovery: Azure Modeling and Simulation Workbench"
 description: This article provides an overview of disaster recovery for Azure Modeling and Simulation Workbench.
 author: meaghanlewis
 ms.author: mosagie
-ms.service: modeling-simulation-workbench
+ms.service: azure-modeling-simulation-workbench
 ms.topic: conceptual
 ms.date: 08/21/2024
 ---

articles/modeling-simulation-workbench/refresh-remote-connection-keys.md

@@ -3,7 +3,7 @@ title: Refresh remote connection keys in Azure Modeling and Simulation Workbench
 description: Learn how to refresh remote connection keys in Azure Modeling and Simulation Workbench.
 author: meaghanlewis
 ms.author: mosagie
-ms.service: modeling-simulation-workbench
+ms.service: azure-modeling-simulation-workbench
 ms.topic: how-to
 ms.date: 09/05/2024
 # Customer intent: As a Chamber User in Azure Modeling and Simulation Workbench, I want to refresh remote connection keys.

articles/modeling-simulation-workbench/shared-storage.md

@@ -3,7 +3,7 @@ title: "Shared storage: Azure Modeling and Simulation Workbench"
 description: This article provides an overview of shared storage for Azure Modeling and Simulation Workbench workbench component.
 author: meaghanlewis
 ms.author: mosagie
-ms.service: modeling-simulation-workbench
+ms.service: azure-modeling-simulation-workbench
 ms.topic: conceptual
 ms.date: 08/21/2024
 ---

articles/network-watcher/media/vnet-flow-logs-overview/vnet-flow-log-format.png

@@ -6,7 +6,7 @@ author: halkazwini
 ms.author: halkazwini
 ms.service: azure-network-watcher
 ms.topic: concept-article
-ms.date: 08/29/2024
+ms.date: 10/20/2024
 
 #CustomerIntent: As an Azure administrator, I want to learn about virtual network flow logs so that I can log my network traffic to analyze and optimize network performance.
 ---
@@ -59,7 +59,9 @@ Virtual network flow logs also avoid the need to enable multiple-level flow logg
 In addition to existing support to identify traffic that [network security group rules](../virtual-network/network-security-groups-overview.md) allow or deny, Virtual network flow logs support identification of traffic that [Azure Virtual Network Manager security admin rules](../virtual-network-manager/concept-security-admins.md) allow or deny. Virtual network flow logs also support evaluating the encryption status of your network traffic in scenarios where you're using [virtual network encryption](../virtual-network/virtual-network-encryption-overview.md?toc=/azure/network-watcher/toc.json).
 
 > [!IMPORTANT]
-> We recommend disabling network security group flow logs before enabling virtual network flow logs on the same underlying workloads to avoid duplicate traffic recording and additional costs. If you enable network security group flow logs on the network security group of a subnet, then you enable virtual network flow logs on the same subnet or parent virtual network, you might get duplicate logging (both network security group flow logs and virtual network flow logs generated for all supported workloads in that particular subnet).
+> We recommend disabling network security group flow logs before enabling virtual network flow logs on the same underlying workloads to avoid duplicate traffic recording and additional costs.
+> 
+> If you enable network security group flow logs on the network security group of a subnet, then you enable virtual network flow logs on the same subnet or parent virtual network, you might get duplicate logging or only virtual network flow logs.
 
 ## How logging works
 
@@ -133,15 +135,15 @@ In the following example of virtual network flow logs, multiple records follow t
             "time": "2022-09-14T09:00:52.5625085Z",
             "flowLogVersion": 4,
             "flowLogGUID": "66aa66aa-bb77-cc88-dd99-00ee00ee00ee",
-            "macAddress": "00224871C205",
+            "macAddress": "112233445566",
             "category": "FlowLogFlowEvent",
-            "flowLogResourceID": "/SUBSCRIPTIONS/00000000-0000-0000-0000-000000000000/RESOURCEGROUPS/NETWORKWATCHERRG/PROVIDERS/MICROSOFT.NETWORK/NETWORKWATCHERS/NETWORKWATCHER_EASTUS2EUAP/FLOWLOGS/VNETFLOWLOG",
-            "targetResourceID": "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVNet",
+            "flowLogResourceID": "/SUBSCRIPTIONS/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/RESOURCEGROUPS/NETWORKWATCHERRG/PROVIDERS/MICROSOFT.NETWORK/NETWORKWATCHERS/NETWORKWATCHER_EASTUS2EUAP/FLOWLOGS/VNETFLOWLOG",
+            "targetResourceID": "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/myResourceGroup/providers/Microsoft.Network/virtualNetworks/myVNet",
             "operationName": "FlowLogFlowEvent",
             "flowRecords": {
                 "flows": [
                     {
-                        "aclID": "00000000-1234-abcd-ef00-c1c2c3c4c5c6",
+                        "aclID": "00aa00aa-bb11-cc22-dd33-44ee44ee44ee",
                         "flowGroups": [
                             {
                                 "rule": "DefaultRule_AllowInternetOutBound",
@@ -161,7 +163,7 @@ In the following example of virtual network flow logs, multiple records follow t
                         ]
                     },
                     {
-                        "aclID": "01020304-abcd-ef00-1234-102030405060",
+                        "aclID": "00aa00aa-bb11-cc22-dd33-44ee44ee44ee",
                         "flowGroups": [
                             {
                                 "rule": "BlockHighRiskTCPPortsFromInternet",
@@ -196,15 +198,15 @@ In the following example of virtual network flow logs, multiple records follow t
 
 :::image type="content" source="media/vnet-flow-logs-overview/vnet-flow-log-format.png" alt-text="Table that shows the format of a virtual network flow log."lightbox="media/vnet-flow-logs-overview/vnet-flow-log-format.png"
 
-Here's an example bandwidth calculation for flow tuples from a TCP conversation between `203.0.113.105:35370` and `10.2.0.4:23`:
+Here's an example bandwidth calculation for flow tuples from a TCP conversation between `203.0.113.105:35370` and `10.0.0.5:23`:
 
-`1493763938,203.0.113.105,10.2.0.4,35370,23,6,I,B,NX,,,,`
-`1493695838,203.0.113.105,10.2.0.4,35370,23,6,I,C,NX,1021,588096,8005,4610880`
-`1493696138,203.0.113.105,10.2.0.4,35370,23,6,I,E,NX,52,29952,47,27072`
+`1708978215,203.0.113.105,10.0.0.5,35370,23,6,I,B,NX,,,,`
+`1708978215,203.0.113.105,10.0.0.5,35370,23,6,I,C,NX,1021,588096,8005,4610880`
+`1708978215,203.0.113.105,10.0.0.5,35370,23,6,I,E,NX,52,29952,47,27072`
 
 For continuation (`C`) and end (`E`) flow states, byte and packet counts are aggregate counts from the time of the previous flow's tuple record. In the example conversation, the total number of packets transferred is 1,021 + 52 + 8,005 + 47 = 9,125. The total number of bytes transferred is 588,096 + 29,952 + 4,610,880 + 27,072 = 5,256,000.
 
-## Storage account considerations for virtual network flow logs 
+## Storage account considerations for virtual network flow logs
 
 - **Location**: The storage account must be in the same region as the virtual network.
 - **Subscription**: The storage account must be in the same subscription of the virtual network or in a subscription associated with the same Microsoft Entra tenant of the virtual network's subscription.