Merge pull request #303081 from MicrosoftDocs/main

Auto Publish – main to live - 2025-07-22 05:00 UTC

Author: learn-build-service-prod[bot]

.openpublishing.redirection.json

@@ -6894,6 +6894,11 @@
       "redirect_url": "/azure/governance/policy/samples/hipaa-hitrust",
       "redirect_document_id": false
     },
+    {
+      "source_path": "articles/reliability/migrate-workload-aks-mysql.md",
+      "redirect_url": "/azure/reliability/availability-zones-migration-overview",
+      "redirect_document_id": true
+    },
     {
        "source_path": "articles/private-5g-core/disconnected-mode.md",
        "redirect_url": "/azure/private-5g-core/azure-stack-edge-disconnects",
@@ -6904,6 +6909,7 @@
       "redirect_url": "/azure/signups/overview",
       "redirect_document_id": false
     }
+    
   ]
 }
 

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

@@ -13,7 +13,7 @@ zone_pivot_groups: azure-cli-or-portal
 
 # Custom domain names and free managed certificates in Azure Container Apps
 
-Azure Container Apps allows you to bind one or more custom domains to a container app. You can automatically configure a free managed certificate for your custom domain.
+Azure Container Apps allows you to bind one or more custom domains to a container app. You can automatically configure a free managed certificate for your custom domain when your container app is publicly accessible.
 
 If you want to set up a custom domain using your own certificate, see [Custom domain names and certificates in Azure Container Apps](custom-domains-certificates.md).
 
@@ -177,10 +177,8 @@ Container Apps supports apex domains and subdomains. Each domain type requires a
         --query "properties.customDomainVerificationId"
     ```
 
-1. Using the DNS provider that is hosting your domain, create DNS records based on the record type you selected using the values shown in the *Domain validation* section. The records point the domain to your container app and verify that you own it. The setup depends on whether you're using custom domains with the private endpoint (preview) feature:
+1. Using the DNS provider that is hosting your domain, create DNS records based on the record type you selected using the values shown in the *Domain validation* section. The records point the domain to your container app and verify that you own it.
 
-    # [General](#tab/general)
-    
     - If you selected *A record*, create the following DNS records:
 
         | Record type | Host | Value |
@@ -195,26 +193,6 @@ Container Apps supports apex domains and subdomains. Each domain type requires a
         | CNAME | The subdomain (for example, `www`) | The generated domain of your container app. |
         | TXT | `asuid.` followed by the subdomain (for example, `asuid.www`) | The domain verification code. |
 
-    # [Private endpoint](#tab/private-endpoint)
-
-    When using a private endpoint for your incoming traffic, you need to [create a private DNS zone](how-to-use-private-endpoint.md#configure-the-private-dns-zone).
-
-    - If you selected *A record*, create the following DNS records:
-
-        | Record type | Host | Value |
-        |--|--|--|
-        | A | `@` | The Private IP of your private endpoint on your container apps environment. |
-        | TXT | `asuid` | The domain verification code. |
-
-    - If you selected *CNAME*, create the following DNS records:
-
-        | Record type | Host | Value |
-        |--|--|--|
-        | CNAME | The subdomain (for example, `www`) | The generated domain of your container app. |
-        | TXT | `asuid.` followed by the subdomain (for example, `asuid.www`) | The domain verification code. |
-
-    ---
-
 1. Add the domain to your container app.
 
     ```azurecli

articles/data-factory/connector-azure-database-for-postgresql.md

@@ -7,7 +7,7 @@ author: jianleishen
 ms.subservice: data-movement
 ms.topic: conceptual
 ms.custom: synapse
-ms.date: 06/27/2025
+ms.date: 07/21/2025
 ---
 
 # Copy and transform data in Azure Database for PostgreSQL using Azure Data Factory or Synapse Analytics
@@ -324,7 +324,8 @@ Example:
 }
 ```
 
-
+> [!NOTE]
+> Microsoft Entra ID authentication using service principal and user-assigned managed identity is supported on the self-hosted integration runtime version 5.50 or above.
 
 
 ### Version 1.0

articles/energy-data-services/release-notes.md

@@ -23,6 +23,14 @@ This page is updated with the details about the upcoming release approximately a
 
 <hr width = 100%>
 
+## July 2025
+### Azure Data Manager for Energy available in two new regions
+Azure Data Manager for Energy is now available in two new regions: **Central India** and **Indonesia Central**. This expansion allows customers and partners in these regions to deploy and manage energy data solutions closer to their operations, supporting improved performance and compliance with local regulations. Both Standard and Developer tiers are supported.
+
+Central India is available for select customers and partners only. Please reach out to your designated Microsoft account team member to unlock access. Once access is provided, you can select "Central India" as your preferred region when creating Azure Data Manager for Energy resource, using the Azure portal or your preferred provisioning method.
+
+For more information on region reliability, refer to [Azure Data Manager for Energy reliability](../reliability/reliability-energy-data-services.md).
+
 ## April 2025
 ### Azure Data Manager for Energy available in four new regions
 Azure Data Manager for Energy is now available in four new regions: **South Africa North**, **Southeast Asia**, **Sweden Central**, and **UAE North**. This expansion allows customers and partners in these regions to deploy and manage energy data solutions closer to their operations, supporting improved performance and compliance with local regulations. Both Standard and Developer tiers are supported. 

articles/iot-edge/how-to-install-iot-edge-ubuntuvm-bicep.md

@@ -6,16 +6,16 @@ ms.service: azure-iot-edge
 ms.custom: devx-track-azurecli, devx-track-bicep
 services: iot-edge
 ms.topic: how-to
-ms.date: 06/10/2024
+ms.date: 07/21/2025
 ms.author: patricka
 ---
-# Run Azure IoT Edge on Ubuntu Virtual Machines by using Bicep
+# Run Azure IoT Edge on Ubuntu virtual machines by using Bicep
 
 [!INCLUDE [iot-edge-version-all-supported](includes/iot-edge-version-all-supported.md)]
 
-The Azure IoT Edge runtime is what turns a device into an IoT Edge device. The runtime can be deployed on devices as small as a Raspberry Pi or as large as an industrial server. Once a device is configured with the IoT Edge runtime, you can start deploying business logic to it from the cloud.
+The Azure IoT Edge runtime turns a device into an IoT Edge device. You can deploy the runtime on devices as small as a Raspberry Pi or as large as an industrial server. After you set up the IoT Edge runtime, deploy business logic to the device from the cloud.
 
-To learn more about how the IoT Edge runtime works and what components are included, see [Understand the Azure IoT Edge runtime and its architecture](iot-edge-runtime.md).
+To learn more about how the IoT Edge runtime works and what components it includes, see [Understand the Azure IoT Edge runtime and its architecture](iot-edge-runtime.md).
 
 ## Deploy from Azure CLI
 
@@ -40,9 +40,9 @@ You can't deploy a remote Bicep file. Save a copy of the [Bicep file](https://ra
       az account list --output table
       ```
 
-   1. Copy the SubscriptionID field for the subscription you'd like to use.
+   1. Copy the *SubscriptionID* field for the subscription you want to use.
 
-   1. Set your working subscription with the ID that you copied:
+   1. Set your working subscription with the ID you copied:
 
       ```azurecli
       az account set -s <SubscriptionId>
@@ -69,7 +69,7 @@ You can't deploy a remote Bicep file. Save a copy of the [Bicep file](https://ra
    --parameters adminPasswordOrKey="<REPLACE_WITH_SECRET_PASSWORD>"
    ```
 
-   To authenticate with an SSH key, you may do so by specifying an **authenticationType** of `sshPublicKey`, then provide the value of the SSH key in the **adminPasswordOrKey** parameter. For example:
+   To authenticate with an SSH key, specify an **authenticationType** of `sshPublicKey`, then provide the value of the SSH key in the `adminPasswordOrKey` parameter. For example:
 
    ```azurecli
    #Generate the SSH Key
@@ -86,9 +86,9 @@ You can't deploy a remote Bicep file. Save a copy of the [Bicep file](https://ra
    --parameters adminPasswordOrKey="$(< ~/.ssh/iotedge-vm-key.pub)"
    ```
 
-1. Verify that the deployment completed successfully. A virtual machine resource should be deployed into the selected resource group. Take note of the machine name, this should be in the format `vm-0000000000000`. Also, take note of the associated **DNS Name**, which should be in the format `<dnsLabelPrefix>`.`<location>`.cloudapp.azure.com.
+1. Check that the deployment completed successfully. A virtual machine resource is deployed into the selected resource group. Note the machine name, which is in the format `vm-0000000000000`. Also, note the associated **DNS Name**, which is in the format `<dnsLabelPrefix>`.`<location>`.cloudapp.azure.com.
 
-    The **DNS Name** can be obtained from the JSON-formatted output of the previous step, within the **outputs** section as part of the **public SSH** entry. The value of this entry can be used to SSH into to the newly deployed machine.
+    You can get the **DNS Name** from the JSON-formatted output of the previous step, in the **outputs** section as part of the **public SSH** entry. Use this value to SSH into the newly deployed machine.
 
     ```bash
     "outputs": {
@@ -99,9 +99,9 @@ You can't deploy a remote Bicep file. Save a copy of the [Bicep file](https://ra
     }
     ```
 
-    The **DNS Name** can also be obtained from the **Overview** section of the newly deployed virtual machine within the Azure portal.
+    You can also get the **DNS Name** from the **Overview** section of the newly deployed virtual machine in the Azure portal.
 
-    :::image type="content" source="./media/how-to-install-iot-edge-ubuntuvm/iotedge-vm-dns-name.png" alt-text="Screenshot showing the DNS name of the I o T Edge virtual machine." lightbox="./media/how-to-install-iot-edge-ubuntuvm/iotedge-vm-dns-name.png":::
+    :::image type="content" source="./media/how-to-install-iot-edge-ubuntuvm/iotedge-vm-dns-name.png" alt-text="Screenshot showing the DNS name of the IoT Edge virtual machine." lightbox="./media/how-to-install-iot-edge-ubuntuvm/iotedge-vm-dns-name.png":::
 
 1. If you want to SSH into this VM after setup, use the associated **DNS Name** with the command:
     `ssh <adminUsername>@<DNS_Name>`
@@ -110,7 +110,7 @@ You can't deploy a remote Bicep file. Save a copy of the [Bicep file](https://ra
 
 Now that you have an IoT Edge device provisioned with the runtime installed, you can [deploy IoT Edge modules](how-to-deploy-modules-portal.md).
 
-If you are having problems with the IoT Edge runtime installing properly, check out the [troubleshooting](troubleshoot.md) page.
+If you're having problems with the IoT Edge runtime installing properly, check out the [troubleshooting](troubleshoot.md) page.
 
 To update an existing installation to the newest version of IoT Edge, see [Update the IoT Edge security daemon and runtime](how-to-update-iot-edge.md).
 

articles/logic-apps/.openpublishing.redirection.logic-apps.json

@@ -1,5 +1,15 @@
 {
     "redirections": [
+        {
+            "source_path_from_root": "/articles/logic-apps/update-workflow-definition-language-schema.md",
+            "redirect_url": "/azure/logic-apps/workflow-definition-language-schema",
+            "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/logic-apps/logic-apps-workflow-definition-language.md",
+            "redirect_url": "/azure/logic-apps/workflow-definition-language-schema",
+            "redirect_document_id": true
+        },
         {
             "source_path_from_root": "/articles/connectors/connectors-create-api-informix.md",
             "redirect_url": "/azure/logic-apps/connectors/informix",
@@ -247,12 +257,12 @@
         },
         {
             "source_path_from_root": "/articles/logic-apps/update-consumption-workflow-schema.md",
-            "redirect_url": "/azure/logic-apps/update-workflow-definition-language-schema",
+            "redirect_url": "/azure/logic-apps/workflow-definition-language-schema",
             "redirect_document_id": false
         },
         {
             "source_path_from_root": "/articles/logic-apps/logic-apps-schema-2016-04-01.md",
-            "redirect_url": "/azure/logic-apps/update-workflow-definition-language-schema",
+            "redirect_url": "/azure/logic-apps/workflow-definition-language-schema",
             "redirect_document_id": false
         },
         {

articles/logic-apps/error-exception-handling.md

@@ -187,21 +187,36 @@ For the exponential interval retry policy, the following table shows the general
 
 ## Manage the "run after" behavior
 
-When you add actions in the workflow designer, you implicitly declare the order to use for running those actions. After an action finishes running, that action is marked with a status such as **Succeeded**, **Failed**, **Skipped**, or **TimedOut**. By default, an action that you add in the designer runs only after the predecessor completes with **Succeeded** status. In an action's underlying JSON definition, the `runAfter` property specifies that the predecessor action that must first finish and the statuses permitted for that predecessor before the successor action can run.
+When you add actions in the workflow designer, you implicitly declare the sequence for running those actions. After an action finishes running, that action is marked with a status such as **Succeeded**, **Failed**, **Skipped**, or **TimedOut**. In other words, the predecessor action must first finish with any of the permitted statuses before the successor action can run.
+
+By default, an action that you add in the designer runs only if the preceding action completes with **Succeeded** status. This *run after* behavior precisely specifies the run order for actions in a workflow. 
+
+In the designer, you can change the default "run after" behavior for an action by [editing the action's **Run after** setting](#change-run-after-designer). This setting is available only on subsequent actions that follow the first action in a workflow. The first action in a workflow always runs after the trigger successfully runs. So, the **Run after** setting isn't available and doesn't apply to the first action.
+
+In an action's underlying JSON definition, the **Run after** setting is the same as the `runAfter` property. This property specifies one or more predecessor actions that must first finish with the specific permitted statuses before the successor action can run. The `runAfter` property is a JSON object that provides flexibility by letting you specify all the predecessor actions that must finish before the successor action runs. This object also defines an array of acceptable statuses.
+
+For example, to have an action run after action A succeeds and also after action B succeeds or fails when you're working on an action's JSON definition, set up the following `runAfter` property:
+
+```json
+{
+   // Other parts in action definition
+   "runAfter": {
+      "Action A": ["Succeeded"],
+      "Action B": ["Succeeded", "Failed"]
+    }
+}
+```
+
+### "Run after" behavior for error handling
 
 When an action throws an unhandled error or exception, the action is marked **Failed**, and any successor action is marked **Skipped**. If this behavior happens for an action that has parallel branches, the Azure Logic Apps engine follows the other branches to determine their completion statuses. For example, if a branch ends with a **Skipped** action, that branch's completion status is based on that skipped action's predecessor status. After the workflow run completes, the engine determines the entire run's status by evaluating all the branch statuses. If any branch ends in failure, the entire workflow run is marked **Failed**.
 
-![Conceptual diagram with examples that show how run statuses are evaluated.](./media/error-exception-handling/status-evaluation-for-parallel-branches.png)
+:::image type="content" source="media/error-exception-handling/status-evaluation-for-parallel-branches.png" alt-text="Conceptual diagram with examples that show how run statuses are evaluated." lightbox="media/error-exception-handling/status-evaluation-for-parallel-branches.png":::
 
 To make sure that an action can still run despite its predecessor's status, you can change an action's "run after" behavior to handle the predecessor's unsuccessful statuses. That way, the action runs when the predecessor's status is **Succeeded**, **Failed**, **Skipped**, **TimedOut**, or all these statuses.
 
 For example, to run the Office 365 Outlook **Send an email** action after the Excel Online **Add a row into a table** predecessor action is marked **Failed**, rather than **Succeeded**, change the "run after" behavior using either the designer or code view editor.
 
-> [!NOTE]
->
-> In the designer, the "run after" setting doesn't apply to the action that immediately 
-> follows the trigger. The trigger must successfully run before the first action can run.
-
 <a name="change-run-after-designer"></a>
 
 ### Change "run after" behavior in the designer
@@ -214,7 +229,7 @@ For example, to run the Office 365 Outlook **Send an email** action after the Ex
 
    - **Standard**
 
-     1. Under **Workflows**, select **Workflows**.
+     1. On the resource sidebar, under **Workflows**, select **Workflows**.
 
      1. From the **Workflows** page, select your workflow.