Merge pull request #288608 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: Taojunshen

articles/app-service/app-service-key-vault-references.md

@@ -102,13 +102,13 @@ A key vault reference is of the form `@Microsoft.KeyVault({referenceString})`, w
 > [!div class="mx-tdBreakAll"]
 > | Reference string                                                            | Description                                                                                                                                                                                 |
 > |-----------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-> | SecretUri=_secretUri_                                                       | The **SecretUri** should be the full data-plane URI of a secret in the vault, optionally including a version, e.g., `https://myvault.vault.azure.net/secrets/mysecret/` or `https://myvault.vault.azure.net/secrets/mysecret/ec96f02080254f109c51a1f14cdb1931`  |
+> | SecretUri=_secretUri_                                                       | The **SecretUri** should be the full data-plane URI of a secret in the vault, for example `https://myvault.vault.azure.net/secrets/mysecret`. Optionally, include a version, such as `https://myvault.vault.azure.net/secrets/mysecret/ec96f02080254f109c51a1f14cdb1931`.  |
 > | VaultName=_vaultName_;SecretName=_secretName_;SecretVersion=_secretVersion_ | The **VaultName** is required and is the vault name. The **SecretName** is required and is the secret name. The **SecretVersion** is optional but if present indicates the version of the secret to use. |
 
-For example, a complete reference would look like the following string:
+For example, a complete reference without a specific version would look like the following string:
 
 ```
-@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret/)
+@Microsoft.KeyVault(SecretUri=https://myvault.vault.azure.net/secrets/mysecret)
 ```
 
 Alternatively:

articles/app-service/configure-common.md

@@ -443,7 +443,7 @@ Here, you can configure some common settings for the app. Some settings require
     > [!NOTE]
     > Most modern browsers support HTTP/2 protocol over TLS only, while non-encrypted traffic continues to use HTTP/1.1. To ensure that client browsers connect to your app with HTTP/2, secure your custom DNS name. For more information, see [Secure a custom DNS name with a TLS/SSL binding in Azure App Service](configure-ssl-bindings.md).
     - **Web sockets**: For [ASP.NET SignalR] or [socket.io](https://socket.io/), for example.
-    - **Always On**: Keeps the app loaded even when there's no traffic. When **Always On** isn't turned on (default), the app is unloaded after 20 minutes without any incoming requests. The unloaded app can cause high latency for new requests because of its warm-up time. When **Always On** is turned on, the front-end load balancer sends a GET request to the application root every five minutes. The continuous ping prevents the app from being unloaded.
+    - **Always On**: Keeps the app loaded even when there's no traffic. When **Always On** isn't turned on (default), the app is unloaded after 20 minutes without any incoming requests. The unloaded app can cause high latency for new requests because of its warm-up time. When **Always On** is turned on, the front-end load balancer sends a GET request to the application root every five minutes. It's important to ensure this request receives a 200 OK response to ensure any re-imaging operations are performed correctly. The continuous ping prevents the app from being unloaded.
 
         Always On is required for continuous WebJobs or for WebJobs that are triggered using a CRON expression.
     - **Session affinity**: In a multi-instance deployment, ensure that the client is routed to the same instance for the life of the session. You can set this option to **Off** for stateless applications.

articles/app-service/deploy-github-actions.md

@@ -196,7 +196,7 @@ To use [user-level credentials](#1-generate-deployment-credentials), paste the e
 When you configure the GitHub workflow file later, you use the secret for the input `creds` of the [Azure/login](https://github.com/marketplace/actions/azure-login). For example:
 
 ```yaml
-- uses: azure/login@v1
+- uses: azure/login@v2
   with:
     creds: ${{ secrets.AZURE_CREDENTIALS }}
 ```
@@ -301,4 +301,4 @@ Check out references on Azure GitHub Actions and workflows:
 - [Azure/k8s-deploy action](https://github.com/Azure/k8s-deploy)
 - [Actions workflows to deploy to Azure](https://github.com/Azure/actions-workflow-samples)
 - [Starter Workflows](https://github.com/actions/starter-workflows)
-- [Events that trigger workflows](https://docs.github.com/en/actions/reference/events-that-trigger-workflows)
+- [Events that trigger workflows](https://docs.github.com/en/actions/reference/events-that-trigger-workflows)

articles/app-service/deploy-staging-slots.md

@@ -124,7 +124,7 @@ When you swap two slots (usually from a staging slot *as the source* into the pr
 
 1. Now that the source slot has the pre-swap app previously in the target slot, perform the same operation by applying all settings and restarting the instances.
 
-At any point of the swap operation, all work of initializing the swapped apps happens on the source slot. The target slot remains online while the source slot is being prepared and warmed up, regardless of where the swap succeeds or fails. To swap a staging slot with the production slot, make sure that the production slot is always the target slot. This way, the swap operation doesn't affect your production app.
+At any point of the swap operation, all work of initializing the swapped apps happens on the source slot. The target slot remains online while the source slot is being prepared and warmed up, regardless of whether the swap succeeds or fails. To swap a staging slot with the production slot, make sure that the production slot is always the target slot. This way, the swap operation doesn't affect your production app.
 
 > [!NOTE]
 > The instances in your former production instances (those that will be swapped into staging after this swap operation) will be recycled quickly in the last step of the swap process. In case you have any long running operations in your application, they will be abandoned, when the workers recycle. This also applies to function apps. Therefore your application code should be written in a fault tolerant way. 

articles/batch/batch-linux-nodes.md

@@ -24,9 +24,9 @@ When you create a virtual machine image reference, you must specify the followin
 
 | **Image reference property** | **Example** |
 | --- | --- |
-| Publisher |Canonical |
-| Offer |UbuntuServer |
-| SKU |20.04-LTS |
+| Publisher |canonical |
+| Offer |0001-com-ubuntu-server-focal |
+| SKU |20_04-lts |
 | Version |latest |
 
 > [!TIP]
@@ -89,9 +89,9 @@ new_pool.start_task = start_task
 # Create an ImageReference which specifies the Marketplace
 # virtual machine image to install on the nodes
 ir = batchmodels.ImageReference(
-    publisher="Canonical",
-    offer="UbuntuServer",
-    sku="20.04-LTS",
+    publisher="canonical",
+    offer="0001-com-ubuntu-server-focal",
+    sku="20_04-lts",
     version="latest")
 
 # Create the VirtualMachineConfiguration, specifying
@@ -118,8 +118,8 @@ images = client.account.list_supported_images()
 image = None
 for img in images:
   if (img.image_reference.publisher.lower() == "canonical" and
-        img.image_reference.offer.lower() == "ubuntuserver" and
-        img.image_reference.sku.lower() == "20.04-lts"):
+        img.image_reference.offer.lower() == "0001-com-ubuntu-server-focal" and
+        img.image_reference.sku.lower() == "20_04-lts"):
     image = img
     break
 
@@ -157,9 +157,9 @@ List<ImageInformation> images =
 ImageInformation image = null;
 foreach (var img in images)
 {
-    if (img.ImageReference.Publisher == "Canonical" &&
-        img.ImageReference.Offer == "UbuntuServer" &&
-        img.ImageReference.Sku == "20.04-LTS")
+    if (img.ImageReference.Publisher == "canonical" &&
+        img.ImageReference.Offer == "0001-com-ubuntu-server-focal" &&
+        img.ImageReference.Sku == "20_04-lts")
     {
         image = img;
         break;
@@ -187,9 +187,9 @@ Although the previous snippet uses the [PoolOperations.istSupportedImages](/dotn
 
 ```csharp
 ImageReference imageReference = new ImageReference(
-    publisher: "Canonical",
-    offer: "UbuntuServer",
-    sku: "20.04-LTS",
+    publisher: "canonical",
+    offer: "0001-com-ubuntu-server-focal",
+    sku: "20_04-lts",
     version: "latest");
 ```
 ::: zone-end

articles/firewall/firewall-faq.yml

@@ -180,7 +180,7 @@ sections:
 
       - question: Does Azure Firewall outbound SNAT between private networks?
         answer: |
-          Azure Firewall doesn't SNAT when the destination IP address is a private IP range per [IANA RFC 1918](https://tools.ietf.org/html/rfc1918). If your organization uses a public IP address range for private networks, Azure Firewall SNATs the traffic to one of the firewall private IP addresses in AzureFirewallSubnet. You can configure Azure Firewall to **not** SNAT your public IP address range. For more information, see [Azure Firewall SNAT private IP address ranges](snat-private-range.md).
+          Azure Firewall doesn't SNAT when the destination IP address is a private IP range per [IANA RFC 1918](https://tools.ietf.org/html/rfc1918) or [IANA RFC 6598](https://datatracker.ietf.org/doc/html/rfc6598) for private networks. If your organization uses a public IP address range for private networks, Azure Firewall SNATs the traffic to one of the firewall private IP addresses in AzureFirewallSubnet. You can configure Azure Firewall to **not** SNAT your public IP address range. For more information, see [Azure Firewall SNAT private IP address ranges](snat-private-range.md).
 
           In addition, traffic processed by application rules are always SNAT-ed. If you want to see the original source IP address in your logs for FQDN traffic, you can use network rules with the destination FQDN.
       - question: Is forced tunneling/chaining to a Network Virtual Appliance supported?

articles/firewall/monitor-firewall-reference.md

@@ -119,6 +119,8 @@ There are a few ways to verify the update was successful, but you can navigate t
 
 To create a diagnostic setting and enable Resource Specific Table, see [Create diagnostic settings in Azure Monitor](/azure/azure-monitor/essentials/create-diagnostic-settings).
 
+## Flow trace
+
 The firewall logs show traffic through the firewall in the first attempt of a TCP connection, known as the *SYN* packet. However, such an entry doesn't show the full journey of the packet in the TCP handshake. As a result, it's difficult to troubleshoot if a packet is dropped, or asymmetric routing occurred. The Azure Firewall Flow Trace Log addresses this concern.
 
 > [!TIP]

articles/firewall/rule-processing.md

@@ -45,7 +45,7 @@ Here's an example policy:
 Assuming BaseRCG1 is a rule collection group priority (200) that contains the rule collections: DNATRC1, DNATRC3,NetworkRC1.\
 BaseRCG2 is a rule collection group priority (300) that contains the rule collections: AppRC2, NetworkRC2.\
 ChildRCG1 is a rule collection group priority (300) that contains the rule collections: ChNetRC1, ChAppRC1.\
-ChildRCG2 is a rule collection group that contains the rule collections: ChNetRC2, ChAppRC2,ChDNATRC3.
+ChildRCG2 is a rule collection group priority (650) that contains the rule collections: ChNetRC2, ChAppRC2,ChDNATRC3.
 
 As per following table:
 
@@ -66,14 +66,14 @@ As per following table:
 |ChAppRC2      |     Application rule collection    |2000         |7         |-|
 |ChDNATRC3     | DNAT rule collection        | 3000        |  2       |-|
 
-Initial Processing:
+Initial Iteration for DNAT Rules:
 
 The process begins by examining the rule collection group (RCG) with the lowest number, which is BaseRCG1 with a priority of 200. Within this group, it searches for DNAT rule collections and evaluates them according to their priorities. In this case, DNATRC1 (priority 600) and DNATRC3 (priority 610) are found and processed accordingly.\
-Next, it moves to the next RCG, BaseRCG2 (priority 200), but finds no DNAT rule collection.\
+Next, it moves to the next RCG, BaseRCG2 (priority 300), but finds no DNAT rule collection.\
 Following that, it proceeds to ChildRCG1 (priority 300), also without a DNAT rule collection.\
 Finally, it checks ChildRCG2 (priority 650) and finds the ChDNATRC3 rule collection (priority 3000).
 
-Iteration Within Rule Collection Groups:
+Iteration for NETWORK Rules:
 
 Returning to BaseRCG1, the iteration continues, this time for NETWORK rules. Only NetworkRC1 (priority 800) is found.\
 Then, it moves to BaseRCG2, where NetworkRC2 (priority 1300) is located.\