Merge pull request #313863 from MicrosoftDocs/main

Auto Publish – main to live - 2026-03-30 11:00 UTC

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

articles/app-service/app-service-hybrid-connections.md

@@ -296,7 +296,7 @@ After you edit the configuration file, restart the Hybrid Connection Manager ser
 - **Windows**: Restart the service through **Services** from the **Start Menu**.
 - **Linux**: Run `systemctl restart hybridconnectionmanager.service`.
 
-Configuring a proxy server routes requests from the Hybrid Connection Manager through the selected proxy server before reaching the destination. Ensure your proxy server supports HTTP/HTTPS traffic so that the Hybrid Connection Manager can communicate with the Azure Relay Service.
+Configuring a proxy server routes requests from the Hybrid Connection Manager through the selected proxy server before reaching the destination. Ensure your proxy server supports HTTP/HTTPS and WebSocket traffic over port 443 so that the Hybrid Connection Manager can communicate with Azure Relay. If your proxy supports DNS allowlisting, allow `*.servicebus.windows.net`. If you can't use a wildcard, allow the specific Relay namespace hostname and the gateway hostnames for that namespace.
 
 > [!NOTE]
 > All addresses set in `appsettings.json` (`ProxyAddress`, `BypassList`) should be in RegEx format if not an exact match.
@@ -387,7 +387,7 @@ The status of **Connected** means that at least one Hybrid Connection Manager is
 - Does your host have outbound access to Azure on port 443? You can test from your Hybrid Connection Manager host using the PowerShell command `Test-NetConnection Destination -P Port`.
 - Is your Hybrid Connection Manager potentially in a bad state? Try restarting the **Azure Hybrid Connection Manager Service** local service.
 - Do you have conflicting software installed? Hybrid Connection Manager can't coexist with Biztalk Hybrid Connection Manager or Service Bus for Windows Server. When you install the Hybrid Connection Manager, you should remove any versions of these packages first.
-- Do you have a firewall between your Hybrid Connection Manager host and Azure? If so, you need to allow outbound access to both the Service Bus endpoint URL *AND* the Service Bus gateways that service your Hybrid Connection.
+- Do you have a firewall between your Hybrid Connection Manager host and Azure? If so, allow outbound HTTPS and WebSocket traffic over port 443. If your firewall supports DNS allowlisting, allow `*.servicebus.windows.net`, which is the preferred configuration. If you can't use a wildcard, allow the Relay namespace hostname and the gateway hostnames for that namespace. IP allowlists aren't recommended because the Relay gateway IP addresses can change.
 
   - You can find the Service Bus endpoint URL in the Hybrid Connection Manager GUI.
 
@@ -397,31 +397,33 @@ The status of **Connected** means that at least one Hybrid Connection Manager is
   
     :::image type="content" source="media/app-service-hybrid-connections/hybrid-connections-service-bus-endpoint-cli.png" alt-text="Screenshot of Hybrid Connection Service Bus endpoint in the CLI.":::
 
-  - The Service Bus gateways are the resources that accept the request into the Hybrid Connection and pass it through the Azure Relay. You need to allow list all of the gateways. The gateways are in the format: `G#-prod-[stamp]-sb.servicebus.windows.net` and `GV#-prod-[stamp]-sb.servicebus.windows.net`. The number sign, `#`, is a number between 0 and 127 and `stamp` is the name of the instance within your Azure data center where your Service Bus endpoint exists.
+  - The Service Bus gateways are the resources that accept the request into the Hybrid Connection and pass it through Azure Relay. The gateway hostnames are in the format `G#-prod-[stamp]-sb.servicebus.windows.net` and `GV#-prod-[stamp]-sb.servicebus.windows.net`. The number sign, `#`, is a number between 0 and 127 and `stamp` is the name of the instance within your Azure datacenter where your Service Bus endpoint exists.
 
-  - If you can use a wildcard, you can allow list *\*.servicebus.windows.net*.
-  - If you can't use a wildcard, you must allow list all 256 of the gateways.
+  - If your firewall or proxy supports DNS allowlisting, allow `*.servicebus.windows.net`. This approach is simpler to maintain and avoids relying on changing IP addresses.
+  - If your firewall or proxy doesn't support wildcard DNS rules, allow the namespace hostname shown in the Hybrid Connection Manager and all gateway hostnames for that namespace. Use hostnames, not IP addresses.
 
     You can find out the stamp using *nslookup* on the Service Bus endpoint URL.
 
     :::image type="content" source="media/app-service-hybrid-connections/hybrid-connections-stamp-name.png" alt-text="Screenshot of terminal showing where to find the stamp name for the Service Bus.":::
 
-    In this example, the stamp is `sn3-010`. To allow list the Service Bus gateways, you need the following entries:
-
-    G0-prod-sn3-010-sb.servicebus.windows.net  
-    G1-prod-sn3-010-sb.servicebus.windows.net  
-    G2-prod-sn3-010-sb.servicebus.windows.net  
-    G3-prod-sn3-010-sb.servicebus.windows.net  
-    ...  
-    G126-prod-sn3-010-sb.servicebus.windows.net  
-    G127-prod-sn3-010-sb.servicebus.windows.net  
-    GV0-prod-sn3-010-sb.servicebus.windows.net  
-    GV1-prod-sn3-010-sb.servicebus.windows.net  
-    GV2-prod-sn3-010-sb.servicebus.windows.net  
-    GV3-prod-sn3-010-sb.servicebus.windows.net  
-    ...  
-    GV126-prod-sn3-010-sb.servicebus.windows.net  
+    In this example, the stamp is `sn3-010`. If you need namespace-specific DNS rules instead of `*.servicebus.windows.net`, allow the namespace hostname and the following gateway hostnames:
+
+    ```text
+    G0-prod-sn3-010-sb.servicebus.windows.net
+    G1-prod-sn3-010-sb.servicebus.windows.net
+    G2-prod-sn3-010-sb.servicebus.windows.net
+    G3-prod-sn3-010-sb.servicebus.windows.net
+    ...
+    G126-prod-sn3-010-sb.servicebus.windows.net
+    G127-prod-sn3-010-sb.servicebus.windows.net
+    GV0-prod-sn3-010-sb.servicebus.windows.net
+    GV1-prod-sn3-010-sb.servicebus.windows.net
+    GV2-prod-sn3-010-sb.servicebus.windows.net
+    GV3-prod-sn3-010-sb.servicebus.windows.net
+    ...
+    GV126-prod-sn3-010-sb.servicebus.windows.net
     GV127-prod-sn3-010-sb.servicebus.windows.net
+    ```
 
 If your status says **Connected** but your app can't reach your endpoint then:
 

articles/app-service/configure-authentication-provider-aad.md

@@ -80,6 +80,8 @@ To use an existing registration, select either:
 
     You can also configure the application to [use an identity instead of a client secret][fic-config]. Support for using an identity is currently in preview.
   - **Issuer URL**. This URL takes the form `<authentication-endpoint>/<tenant-id>/v2.0`. Replace `<authentication-endpoint>` with the authentication endpoint [value that's specific to the cloud environment](/entra/identity-platform/authentication-national-cloud#azure-ad-authentication-endpoints). For example, a workforce tenant in global Azure would use `https://login.microsoftonline.com` as its authentication endpoint.
+
+      You can find this value in the Microsoft Entra admin center. Go to **App registrations**, select your app, and then select **Endpoints**. Copy the **OpenID Connect metadata document** endpoint for your tenant, and then remove `/.well-known/openid-configuration` from the end of the URL. For example, if the metadata endpoint is `https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration`, use `https://login.microsoftonline.com/<tenant-id>/v2.0` as the issuer URL.
 
     > [!NOTE]
     > If you created your identity provider using the express setup (Option 1), the issuer URL is automatically set to use the legacy `https://sts.windows.net` endpoint. To align with current Microsoft Entra ID best practices, edit your identity provider and update the issuer URL to use `https://login.microsoftonline.com/<tenant-id>/v2.0` instead.
@@ -169,7 +171,7 @@ To use an existing registration, select **Provide the details of an existing app
 
 - **Application (client) ID**
 - **Client secret**
-- **Issuer URL**
+- **Issuer URL**. In the Microsoft Entra admin center, go to **App registrations**, select your app, and then select **Endpoints**. Copy the **OpenID Connect metadata document** endpoint for your tenant, and then remove `/.well-known/openid-configuration` from the end of the URL. For example, if the metadata endpoint is `https://login.microsoftonline.com/<tenant-id>/v2.0/.well-known/openid-configuration`, use `https://login.microsoftonline.com/<tenant-id>/v2.0` as the issuer URL.
 
 If you need to manually create an app registration in an external tenant, see [Register an app in your external tenant](/entra/external-id/customers/how-to-register-ciam-app?tabs=webapp#register-your-web-app).
 
@@ -219,6 +221,8 @@ For **Tenant requirement**, choose whether to:
 - Allow requests from specific tenants.
 - Use default restrictions based on the app registration's tenant.
 
+For **Allowed token audiences**, add any audience values that your app should accept in the `aud` claim of incoming access tokens. You commonly need this setting when clients request tokens by using the app registration's **Application ID URI**, such as `api://<application-client-id>` or a custom URI like `https://contoso.com/api`. The app registration's client ID is already accepted by default, so you typically add values here only if your app accepts another audience format.
+
 Your app might still need to make other authorization decisions in code. For more information, see [Use a built-in authorization policy](#use-a-built-in-authorization-policy) later in this article.
 
 ## Configure authentication settings

articles/databox/data-box-deploy-ordered.md

@@ -221,9 +221,6 @@ For detailed information on how to sign in to Azure using Windows PowerShell, se
 
 ## Order Data Box
 
-> [!NOTE]
-> Azure Data Box currently does not support Azure Files Provisioned v2 Storage Accounts. For on-premises to Azure migration scenarios, you can explore [Azure Storage Mover](/azure/storage-mover/service-overview).
-
 To order a device, perform the following steps:
 
 # [Portal](#tab/portal)

articles/databox/data-box-security.md

@@ -144,16 +144,44 @@ The following security guidelines are implemented in Data Box:
 
 ## Secure erase media sanitization details
 
-The secure erasure process performed on our devices is compliant with [NIST SP 800-88r1](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r1.pdf) and following are the details of the implementation:
+The secure erasure process performed on our devices is compliant with [NIST SP 800-88 Revision 2](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-88r2.pdf). Customers also receive a Secure Erasure Certificate which is auto-generated as part of the cleanup process and is available directly from the Azure portal once the order is completed. The certificate is downloadable and confirms all data on the device has been securely erased along with the implementation details required by NIST standards, thus enhancing security assurance and simplifying compliance for  highly regulated and sensitive scenarios.
+The table below covers the details of the implementation:
 
 |Device   |Data Erasure type   |Tool used   |
 |----------------|------------|-------------|
-|Azure Data Box | In Public cloud: Crypto Erase <br> In Gov cloud: Crypto Erase + Disk overwrite |ARCCONF tool | 
-|Azure Data Box 120  | In Public and Gov cloud: Block Erase |ARCCONF tool | 
-|Azure Data Box 525  | In Public and Gov cloud: Block Erase |ARCCONF tool | 
-|Azure Data Box Disk   | In Public and Gov cloud: Block Erase |MSECLI tool | 
-
-
+|Azure Data Box 120  | Block Erase |ARCCONF 4.17.00 tool | 
+|Azure Data Box 525  | Block Erase |ARCCONF 4.17.00 tool | 
+|Azure Data Box Disk   |Block Erase |MSECLI tool | 
+
+Below is a sample certificate for a Data Box 120 device:
+```Sample Secure Erasure Certificate
+Microsoft Azure Data Box Certificate of Erasure  
+SubscriptionName: <> 
+ResourceGroupName: <> 
+JobName: <> 
+{ 
+  "MediaInformation": { 
+  "Model": "Azure Data Box 120", 
+  “Manufacturer”:XXXXX 
+  "SerialNumber": "XXXXXXX", 
+  "Disks": ["ABC1", "ABC2"], 
+  "MediaType": "Flash Memory SSDs", 
+  "DataBackedUp": "No backup created before erasure" 
+  } 
+  "SanitizationDetails": { 
+  "ErasureMethodType": "NIST 800-88 Purge", 
+  "MethodUsed": "Block Erase", 
+  "ToolsUsed": "ARCCONF tool", 
+  "Verification Methods": "Random 10% sampling + Secondary 2% Sampling" 
+  } 
+  "MediaDestination": "Azure Inventory" 
+  "Signature": { 
+  "Details": "We hereby state that the data erasure and validation process has been carried out in accordance with the NIST 800-88r2 standards. ", 
+  "SanitizedBy": "Azure Data Box team", 
+  "Date": "YYYY-MM-DD HH:MM:SS" 
+  }
+}
+```
 ## Next steps
 
 - Review the [Data Box requirements](data-box-system-requirements.md).

articles/iot-operations/discover-manage-assets/overview-opc-ua-connector.md

@@ -43,7 +43,7 @@ The connector for OPC UA supports the following features as part of Azure IoT Op
 | Feature | Supported | Notes |
 |---------|:---------:|-------|
 | Username/password authentication | Yes | |
-| X.509 client certificates | No | |
+| X.509 client certificates | Yes | |
 | Anonymous access | Yes | For testing purposes |
 | Certificate trust list | Yes | For secure, encrypted OPC UA connections |
 | OpenTelemetry integration | Yes | |

articles/migrate/how-to-build-a-report.md

@@ -0,0 +1,79 @@
+---
+title: Build an Azure Migrate Report 
+description: Build Azure Migrate reports to analyze discovered on-premises servers and workloads and generate insights for migration planning.
+author: habibaum
+ms.author: v-uhabiba
+ms.topic: how-to
+ms.service: azure-migrate
+ms.date: 03/25/2026
+monikerRange:
+# Customer intent: As an IT administrator managing migration resources, I want to tag workloads with relevant attributes, so that I can enhance resource organization and visibility during the migration process.
+---
+
+# Build a report (preview) 
+
+This article explains how to build a report (preview) for on‑premises servers and workloads by using Azure Migrate. After completing this article, you’ll be able to generate a report by selecting the appropriate report type, migration preferences, and configuration options in an Azure Migrate project.  
+
+In this article, you’ll learn how to:
+
+- Create a report on Azure Migrate.
+- Select the appropriate report type, migration preferences, and configuration options.
+- Generate the report to review insights about your discovered servers and workloads.
+- After completing this section, you can generate migration and modernization reports.
+
+## Prerequisites 
+
+Before you build a report, ensure the following:
+
+- You’ve created an Azure Migrate project. You can use an existing project if it is available.
+After the project is created, the Azure Migrate: Discovery and assessment tool is automatically added. 
+- You’ve discovered your IT estate using one of the supported discovery sources for your scenario. 
+- All discovery errors are resolved.
+
+### Recommendation
+
+To improve the report accuracy, we recommend the following actions:
+
+- Enrich your data by defining the environment, migration intent, and application.
+- Define environment and migration for your [workloads to enrich your data](resource-tagging.md).
+- Specify [associated applications](define-manage-applications.md).
+- Enable application auto‑discovery and review the [discovered applications](resource-tagging.md) for accuracy.
+
+## Build report
+
+To build a report, follow these steps:
+
+1. From **All projects**, select your project. 
+
+    :::image type="content" source="./media/how-to-build-a-report/migrate-projects.png" alt-text="The screenshot shows how to select your project from the Migrate projects." lightbox="./media/how-to-build-a-report/migrate-projects.png":::
+
+1. On the left pane go to **Manage**, and then select **Reports** (Preview).
+
+    :::image type="content" source="./media/how-to-build-a-report/manage-section.png" alt-text="The screenshot shows how to access and select reports." lightbox="./media/how-to-build-a-report/manage-section.png":::
+
+1. On the **Generate Report** page, do the following:
+    1. **Name**: Enter a name for the report. The report name must be unique within the project.  
+
+    :::image type="content" source="./media/how-to-build-a-report/generate-report.png" alt-text="The screenshot shows how to generate report." lightbox="./media/how-to-build-a-report/generate-report.png":::
+
+    1. **Type**: Select the report type to generate. For more information, see the [supported report types](reports-overview.md#types-of-reports). 
+    1. **Migration preference**: Select the required migration preference. For more information, see [migration preferences](reports-overview.md#migration-preferences-in-azure-migrate-reports).
+    1. **Configuration**: Choose the required configuration to generate the report. For more information, see [report configuration](reports-overview.md#report-configuration).
+    1. Review your selections, and then select **Build report**. 
+
+1. Creating a report by using configurations from an existing assessment takes approximately 15 minutes. Creating a report by defining configurations from scratch takes approximately 1 hour.
+
+### Download the report
+
+To download a report, follow these steps:
+
+1. Go to the **Reports** section to view the list of reports created so far.
+1. For the report you want to download, select **Download**.  
+
+    :::image type="content" source="./media/how-to-build-a-report/download-report.png" alt-text="The screenshot shows how to download report." lightbox="./media/how-to-build-a-report/download-report.png":::
+
+1. Select the required report type, and then select **Download**.
+
+    :::image type="content" source="./media/how-to-build-a-report/report-types.png" alt-text="The screenshot shows how to select the report types and download." lightbox="./media/how-to-build-a-report/report-types.png":::
+
+