Merge pull request #198064 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: huypub

articles/active-directory/conditional-access/howto-conditional-access-apis.md

@@ -31,6 +31,9 @@ Many of the following examples use tools like [Managed Identities](../managed-id
 
 ### PowerShell
 
+> [!IMPORTANT]
+> Due to the planned deprecation of PowerShell modules (MSOL & AAD) after December 2022, no further updates are planned for these modules to support new Conditional Access features. See recent announcements for more information: https://aka.ms/AzureADPowerShellDeprecation. New Conditional Access features may not be available or may not be functional within these PowerShell modules as a result of this announcement. Please consider [migrating to Microsoft Graph PowerShell](https://aka.ms/MigrateMicrosoftGraphPowerShell). Additional guidance and examples will be released soon.
+
 For many administrators, PowerShell is already an understood scripting tool. The following example shows how to use the [Azure AD PowerShell module](https://www.powershellgallery.com/packages/AzureAD) to manage Conditional Access policies.
 
 - [Configure Conditional Access policies with Azure AD PowerShell commands](https://github.com/Azure-Samples/azure-ad-conditional-access-apis/tree/main/01-configure/powershell)

articles/active-directory/reports-monitoring/reference-azure-ad-sla-performance.md

@@ -55,8 +55,8 @@ For each month, we truncate the SLA attainment at three places after the decimal
 | ---       | ---     | ---     |
 | January   |         | 99.999% |
 | February  | 99.999% | 99.999% |
-| March     | 99.568% |         |
-| April     | 99.999% |         |
+| March     | 99.568% | 99.999% |
+| April     | 99.999% | 99.999% |
 | May       | 99.999% |         |
 | June      | 99.999% |         |
 | July      | 99.999% |         |
@@ -89,4 +89,4 @@ All incidents that seriously impact Azure AD performance are documented in the [
 
 * [Azure AD reports overview](overview-reports.md)
 * [Programmatic access to Azure AD reports](concept-reporting-api.md)
-* [Azure Active Directory risk detections](../identity-protection/overview-identity-protection.md)
+* [Azure Active Directory risk detections](../identity-protection/overview-identity-protection.md)

articles/api-management/how-to-configure-local-metrics-logs.md

@@ -190,12 +190,12 @@ Now we have everything deployed and configured, the self-hosted gateway should r
 
 Make some API calls through the self-hosted gateway, if everything is configured correctly, you should be able to view below metrics:
 
-| Metric  | Description |
+| Metric        | Description |
 | ------------- | ------------- |
-| Requests  | Number of API requests in the period |
-| DurationInMS | Number of milliseconds from the moment gateway received request until the moment response sent in full |
-| BackendDurationInMS | Number of milliseconds spent on overall backend IO (connecting, sending and receiving bytes)  |
-| ClientDurationInMS | Number of milliseconds spent on overall client IO (connecting, sending and receiving bytes)  |
+| requests_total  | Number of API requests in the period |
+| request_duration_seconds | Number of milliseconds from the moment gateway received request until the moment response sent in full |
+| request_backend_duration_seconds | Number of milliseconds spent on overall backend IO (connecting, sending and receiving bytes)  |
+| request_client_duration_seconds | Number of milliseconds spent on overall client IO (connecting, sending and receiving bytes)  |
 
 ## Logs
 

articles/azure-app-configuration/manage-feature-flags.md

@@ -64,7 +64,7 @@ In the **Feature manager**, you can also change the state of a feature flag by c
 
 ## Access feature flags
 
-In the **Operations** menu, select **Feature manager**. You can select **Edits Columns** to add or remove columns, and change the column order.
+In the **Operations** menu, select **Feature manager**. You can select **Edit Columns** to add or remove columns, and change the column order.
 create a label, lock or delete the feature flag.
 :::image type="content" source="media/edit-columns-feature-flag.png" alt-text="Screenshot of the Azure platform. Edit feature flag columns." lightbox="media/edit-columns-feature-flag-expanded.png":::
 

articles/iot-edge/tutorial-deploy-function.md

@@ -39,7 +39,7 @@ The Azure Function that you create in this tutorial filters the temperature data
 Before beginning this tutorial, you should have gone through the previous tutorial to set up your development environment for Linux container development: [Develop IoT Edge modules using Linux containers](tutorial-develop-for-linux.md). By completing that tutorial, you should have the following prerequisites in place:
 
 * A free or standard-tier [IoT Hub](../iot-hub/iot-hub-create-through-portal.md) in Azure.
-* A device running Azure IoT Edge with Linux containers. You can use the quickstarts to set up a [Linux device](quickstart-linux.md) or [Windows device](quickstart.md).
+* An AMD64 device running Azure IoT Edge with Linux containers. You can use the quickstarts to set up a [Linux device](quickstart-linux.md) or [Windows device](quickstart.md).
 * A container registry, like [Azure Container Registry](../container-registry/index.yml).
 * [Visual Studio Code](https://code.visualstudio.com/) configured with the [Azure IoT Tools](https://marketplace.visualstudio.com/items?itemName=vsciot-vscode.azure-iot-tools).
 * [Docker CE](https://docs.docker.com/install/) configured to run Linux containers.
@@ -86,13 +86,13 @@ The IoT Edge extension tries to pull your container registry credentials from Az
 >[!NOTE]
 >This tutorial uses admin login credentials for Azure Container Registry, which are convenient for development and test scenarios. When you're ready for production scenarios, we recommend a least-privilege authentication option like service principals. For more information, see [Manage access to your container registry](production-checklist.md#manage-access-to-your-container-registry).
 
-### Select your target architecture
+### Set target architecture to AMD64
 
-Currently, Visual Studio Code can develop C modules for Linux AMD64 and Linux ARM32v7 devices. You need to select which architecture you're targeting with each solution, because the container is built and run differently for each architecture type. The default is Linux AMD64.
+Running Azure Functions modules on IoT Edge is supported only on Linux AMD64 based containers. The default target architecture for Visual Studio Code is Linux AMD64, but we will set it explicitly to Linux AMD64 here.
 
 1. Open the command palette and search for **Azure IoT Edge: Set Default Target Platform for Edge Solution**, or select the shortcut icon in the side bar at the bottom of the window.
 
-2. In the command palette, select the target architecture from the list of options. For this tutorial, we're using an Ubuntu virtual machine as the IoT Edge device, so will keep the default **amd64**.
+2. In the command palette, select the AMD64 target architecture from the list of options.
 
 ### Update the module with custom code
 

articles/iot-hub/iot-hub-node-node-file-upload.md

@@ -241,6 +241,8 @@ In this section, you create a Node.js console app that receives file upload noti
       }
     });
     ```
+    > [!NOTE]
+    > If you want to receive disconnect notifications while you are listening to file upload notifications, you need to register `'error'` by using `receiver.on`. To continue to receive file upload notifications, you need to reconect to IoT Hub by using the `serviceClient.open` method.
 
 1. Save and close the **FileUploadNotification.js** file.
 

articles/machine-learning/how-to-deploy-mlflow-models.md

@@ -60,8 +60,7 @@ model_path = "model"
 
 # define the model path and the name is the service name
 # the model gets registered automatically and a name is autogenerated using the "name" parameter below 
-client.create_deployment(model_uri='runs:/{}/{}'.format(run.id, model_path),
-                         name="mlflow-test-aci")
+client.create_deployment(name="mlflow-test-aci", model_uri='runs:/{}/{}'.format(run.id, model_path))
 ```
 
 ### Customize deployment configuration

includes/virtual-machines-disks-shared-limitations.md

@@ -28,7 +28,7 @@ Shared ultra disks are available in all regions that support ultra disks by defa
 - Can only be enabled on data disks, not OS disks.
 - Host caching isn't available for premium SSDs with `maxShares>1`.
 - Disk bursting isn't available for premium SSDs with `maxShares>1`.
-- When using Availability sets and virtual machine scale sets with Azure shared disks, [storage fault domain alignment](../articles/virtual-machines/availability.md) with virtual machine fault domain isn't enforced for the shared data disk.
+- When using Availability sets or virtual machine scale sets with Azure shared disks, [storage fault domain alignment](../articles/virtual-machines/availability.md) with virtual machine fault domain isn't enforced for the shared data disk.
 - When using [proximity placement groups (PPG)](../articles/virtual-machines/windows/proximity-placement-groups.md), all virtual machines sharing a disk must be part of the same PPG.
 - Only basic disks can be used with some versions of Windows Server Failover Cluster, for details see [Failover clustering hardware requirements and storage options](/windows-server/failover-clustering/clustering-requirements).
 - Azure Site Recovery support isn't yet available.