Merge pull request #226294 from MicrosoftDocs/repo_sync_working_branch

rmca14 · web-flow · commit 2235436608d5 · 2023-02-06T10:25:28.000-08:00
Confirm merge from repo_sync_working_branch to main to sync with https://github.com/MicrosoftDocs/azure-docs (branch main)
diff --git a/articles/bastion/bastion-faq.md b/articles/bastion/bastion-faq.md
@@ -46,7 +46,7 @@ You may use a private DNS zone ending with one of the names listed above (ex: pr
 
 Azure Bastion isn't supported with Azure Private DNS Zones in national clouds.
 
-### <a name="dns"></a>Does Azure Bastion support Private Link?"
+### <a name="dns"></a>Does Azure Bastion support Private Link?
 
 No, Azure Bastion doesn't currently support private link.
 
diff --git a/articles/container-apps/application-lifecycle-management.md b/articles/container-apps/application-lifecycle-management.md
@@ -32,7 +32,7 @@ As a container app is updated with a [revision scope-change](revisions.md#revisi
 
 ### Zero downtime deployment
 
-In single revision mode, Container Apps automatically ensures your app does not experience downtime when creating new a revision. The existing active revision is not deactivated until the new revision is ready. If ingress is enabled, the existing revision will continue to receive 100% of the traffic until the new revision is ready.
+In single revision mode, Container Apps automatically ensures your app does not experience downtime when creating a new revision. The existing active revision is not deactivated until the new revision is ready. If ingress is enabled, the existing revision will continue to receive 100% of the traffic until the new revision is ready.
 
 > [!NOTE]
 > A new revision is considered ready when one of its replicas starts and becomes ready. A replica is ready when all of its containers start and pass their [startup and readiness probes](./health-probes.md).
diff --git a/articles/defender-for-cloud/includes/defender-for-containers-enable-plan-aks.md b/articles/defender-for-cloud/includes/defender-for-containers-enable-plan-aks.md
@@ -145,12 +145,6 @@ Request body parameters:
     > [!IMPORTANT]
     > Ensure that you use the same subscription ID for ``<your-subscription-id>`` as the one associated with your AKS cluster.
 
-1. Enable the feature flag in the CLI:
-
-    ```azurecli
-    az feature register --namespace Microsoft.ContainerService --name AKS-AzureDefender
-    ```
-
 1. Enable the Defender profile on your containers:
 
     - Run the following command to create a new cluster with the Defender profile enabled:
diff --git a/articles/energy-data-services/faq-energy-data-services.yml b/articles/energy-data-services/faq-energy-data-services.yml
@@ -34,11 +34,11 @@ sections:
       questions:
         - question: Where can I learn about the pricing for Microsoft Energy Data Services?
           answer: >
-            Pricing for Microsoft Energy Data Services will be made available by February 2023. 
+            Pricing for Microsoft Energy Data Services will be made available on Azure.com via the Product Pricing Page. 
 
         - question: When will billing begin for Microsoft Energy Data Services Preview?
           answer: >
-            Microsoft Energy Data Services is currently free and billing will begin starting December 1, 2022.
+            Microsoft Energy Data Services is currently free and billing will begin February 15th, 2023.
 
     - name: Support policies
       questions:
diff --git a/articles/event-hubs/event-hubs-geo-dr.md b/articles/event-hubs/event-hubs-geo-dr.md
@@ -157,6 +157,10 @@ Note the following considerations to keep in mind:
 
 5. Synchronizing entities can take some time, approximately 50-100 entities per minute.
 
+6. Some aspects of the management plane for the secondary namespace become read-only while geo-recovery pairing is active.
+
+7. The data plane of the secondary namespace will be read-only while geo-recovery pairing is active. The data plane of the secondary namespace will accept GET requests to enable validation of client connectivity and access controls.
+
 ## Availability Zones 
 Event Hubs supports [Availability Zones](../availability-zones/az-overview.md), providing fault-isolated locations within an Azure region. The Availability Zones support is only available in [Azure regions with availability zones](../availability-zones/az-region.md#azure-regions-with-availability-zones). Both metadata and data (events) are replicated across data centers in the availability zone. 
 
diff --git a/articles/iot-dps/tutorial-custom-hsm-enrollment-group-x509.md b/articles/iot-dps/tutorial-custom-hsm-enrollment-group-x509.md
@@ -771,6 +771,19 @@ To add the root CA certificate to your DPS instance, follow these steps:
   
     :::image type="content" source="./media/tutorial-custom-hsm-enrollment-group-x509/verify-root-certificate.png" alt-text="Screenshot that shows the verified root C A certificate in the list of certificates.":::
 
+## (Optional) Manual verification of root certificate
+If you didn't choose to automatically verify the certificate during upload, you manually prove possession:
+
+1. Select the new CA certificate.
+
+1. Select Generate Verification Code in the Certificate Details dialog.
+
+1. Create a certificate that contains the verification code. For example, if you're using the Bash script supplied by Microsoft, run `./certGen.sh create_verification_certificate "<verification code>"` to create a certificate named `verification-code.cert.pem`, replacing `<verification code>` with the previously generated verification code. For more information, you can download the [files](https://github.com/Azure/azure-iot-sdk-c/tree/main/tools/CACertificates) relevant to your system to a working folder and follow the instructions in the [Managing CA certificates readme](https://github.com/Azure/azure-iot-sdk-c/blob/main/tools/CACertificates/CACertificateOverview.md) to perform proof-of-possession on a CA certificate.
+ 
+1. Upload `verification-code.cert.pem` to your provisioning service in the Certificate Details dialog.
+
+1. Select Verify.
+
 ## Update the certificate store on Windows-based devices
 
 On non-Windows devices, you can pass the certificate chain from the code as the certificate store.
diff --git a/articles/machine-learning/how-to-attach-kubernetes-anywhere.md b/articles/machine-learning/how-to-attach-kubernetes-anywhere.md
@@ -73,7 +73,7 @@ Train model in cloud, deploy model on-premises | Cloud | Make use of cloud compu
 
 ## KubernetesCompute and legacy AksCompute
 
-With AzureML CLI/Python SDK v1, you can deploy models on AKS using AksCompute target. Both KubernetesCompute target and AksCompute target support AKS integration, however they support it differently. Following table shows key differences.
+With AzureML CLI/Python SDK v1, you can deploy models on AKS using AksCompute target. Both KubernetesCompute target and AksCompute target support AKS integration, however they support it differently. The following table shows their key differences:
 
 |Capabilities  |AKS integration with AksCompute (legacy)  |AKS integration with KubernetesCompute|
 |--|--|--|
@@ -84,7 +84,7 @@ With AzureML CLI/Python SDK v1, you can deploy models on AKS using AksCompute ta
 |Batch inference | No | Yes |
 |Real-time inference new features | No new features development | Active roadmap |
 
-With these key differences and overall AzureML evolves to use SDK/CLI v2, AzureML recommends you to use Kubernetes compute target to deploy models if you decide to use AKS for model deployment.
+With these key differences and overall AzureML evolution to use SDK/CLI v2, AzureML recommends you to use Kubernetes compute target to deploy models if you decide to use AKS for model deployment.
 
 ## Next steps
 
@@ -107,4 +107,4 @@ For any AzureML example, you only need to update the compute target name to your
 * Explore model deployment with online endpoint samples with CLI v2 - [https://github.com/Azure/azureml-examples/tree/main/cli/endpoints/online/kubernetes](https://github.com/Azure/azureml-examples/tree/main/cli/endpoints/online/kubernetes)
 * Explore batch endpoint samples with CLI v2 - [https://github.com/Azure/azureml-examples/tree/main/cli/endpoints/batch](https://github.com/Azure/azureml-examples/tree/main/cli/endpoints/batch)
 * Explore training job samples with SDK v2 -[https://github.com/Azure/azureml-examples/tree/main/sdk/python/jobs](https://github.com/Azure/azureml-examples/tree/main/sdk/python/jobs)
-* Explore model deployment with online endpoint samples with SDK v2 -[https://github.com/Azure/azureml-examples/tree/main/sdk/python/endpoints/online/kubernetes](https://github.com/Azure/azureml-examples/tree/main/sdk/python/endpoints/online/kubernetes)
+* Explore model deployment with online endpoint samples with SDK v2 -[https://github.com/Azure/azureml-examples/tree/main/sdk/python/endpoints/online/kubernetes](https://github.com/Azure/azureml-examples/tree/main/sdk/python/endpoints/online/kubernetes)
diff --git a/articles/mysql/flexible-server/concepts-service-tiers-storage.md b/articles/mysql/flexible-server/concepts-service-tiers-storage.md
@@ -136,7 +136,7 @@ Remember that storage once auto-scaled up, cannot be scaled down.
 
 Azure Database for MySQL – Flexible Server supports the provisioning of additional IOPS. This feature enables you to provision additional IOPS above the complimentary IOPS limit. Using this feature, you can increase or decrease the number of IOPS provisioned based on your workload requirements at any time. 
 
-The minimum IOPS is 360 across all compute sizes and the maximum IOPS is determined by the selected compute size. To learn more about the maximum IOPS per compute size refer to the [table].(#compute-tiers-size-and-server-types) 
+The minimum IOPS is 360 across all compute sizes and the maximum IOPS is determined by the selected compute size. To learn more about the maximum IOPS per compute size refer to the [table](#service-tiers-size-and-server-types).
 
 The maximum IOPS is dependent on the maximum available IOPS per compute size. Refer to the column *Max uncached disk throughput: IOPS/MBps* in the [B-series](../../virtual-machines/sizes-b-series-burstable.md), [Ddsv4-series](../../virtual-machines/ddv4-ddsv4-series.md), and [Edsv4-series](../../virtual-machines/edv4-edsv4-series.md)/ [Edsv5-series](../../virtual-machines/edv5-edsv5-series.md)] documentation.
 
@@ -181,4 +181,4 @@ If you would like to optimize server cost, you can consider following tips:
 ## Next steps
 
 - Learn how to [create a MySQL server in the portal](quickstart-create-server-portal.md).
-- Learn about [service limitations](concepts-limitations.md).
+- Learn about [service limitations](concepts-limitations.md).
diff --git a/articles/reliability/migrate-app-service-environment.md b/articles/reliability/migrate-app-service-environment.md
@@ -19,7 +19,7 @@ This guide describes how to migrate an App Service Environment from non-availabi
 
 Azure App Service Environment can be deployed across [availability zones (AZ)](../reliability/availability-zones-overview.md) to help you achieve resiliency and reliability for your business-critical workloads. This architecture is also known as zone redundancy.
 
-When you configure to be zone redundant, the platform automatically spreads the instances of the Azure App Service plan across all three zones in the selected region. This means that the minimum App Service Plan instance count will always be three. If you specify a capacity larger than three, and the number of instances is divisible by three, the instances are spread evenly. Otherwise, instance counts beyond 3*N are spread across the remaining one or two zones.
+When you configure to be zone redundant, the platform automatically spreads the instances of the Azure App Service plan across three zones in the selected region. This means that the minimum App Service Plan instance count will always be three. If you specify a capacity larger than three, and the number of instances is divisible by three, the instances are spread evenly. Otherwise, instance counts beyond 3*N are spread across the remaining one or two zones.
 
 ## Prerequisites
 
@@ -44,7 +44,7 @@ If you want your App Service Environment to use availability zones, redeploy you
 
 Traffic is routed to all of your available App Service instances. In the case when a zone goes down, the App Service platform will detect lost instances and automatically attempt to find new replacement instances and spread traffic as needed. If you have [autoscale](../app-service/manage-scale-up.md) configured, and if it decides more instances are needed, autoscale will also issue a request to App Service to add more instances. Note that [autoscale behavior is independent of App Service platform behavior](../azure-monitor/autoscale/autoscale-overview.md) and that your autoscale instance count specification doesn't need to be a multiple of three. It's also important to note there's no guarantee that requests for additional instances in a zone-down scenario will succeed since back filling lost instances occurs on a best-effort basis. The recommended solution is to create and configure your App Service plans to account for losing a zone as described in the next section.
 
-Applications that are deployed in an App Service Environment that has availability zones enabled will continue to run and serve traffic even if other zones in the same region suffer an outage. However it's possible that non-runtime behaviors including App Service plan scaling, application creation, application configuration, and application publishing may still be impacted from an outage in other Availability Zones. Zone redundancy for App Service Environments only ensures continued uptime for deployed applications.
+Applications that are deployed in an App Service Environment that has availability zones enabled will continue to run and serve traffic if a single zone becomes unavailable.  However it's possible that non-runtime behaviors including App Service plan scaling, application creation, application configuration, and application publishing may still be impacted from an outage in other Availability Zones. Zone redundancy for App Service Environments only ensures continued uptime for deployed applications.
 
 When the App Service platform allocates instances to a zone redundant App Service plan, it uses [best effort zone balancing offered by the underlying Azure Virtual Machine Scale Sets](../virtual-machine-scale-sets/virtual-machine-scale-sets-use-availability-zones.md#zone-balancing). An App Service plan will be "balanced" if each zone has either the same number of VMs, or +/- one VM in all of the other zones used by the App Service plan.
 
@@ -101,4 +101,4 @@ There's a minimum charge of nine App Service plan instances in a zone redundant
 ## Next steps
 
 > [!div class="nextstepaction"]
-> [Azure services and regions that support availability zones](availability-zones-service-support.md)
+> [Azure services and regions that support availability zones](availability-zones-service-support.md)
diff --git a/articles/sentinel/connect-microsoft-purview.md b/articles/sentinel/connect-microsoft-purview.md
@@ -80,7 +80,8 @@ To disconnect the Azure Information Protection connector:
 1. In the **Data connectors** blade, in the search bar, type *Azure Information Protection*. 
 1. Select **Azure Information Protection**.
 1. Below the connector description, select **Open connector page**.
-1. Under **Configuration**, select **Disconnect**.
+1. Under **Configuration**, select **Connect Azure Information Protection logs**.
+1. Select the configured workspace and select **Ok**.
 
 ## Known issues and limitations
 
@@ -109,4 +110,4 @@ In this article, you learned how to set up the Microsoft Purview Information Pro
 
 - Learn how to [get visibility into your data, and potential threats](get-visibility.md).
 - Get started [detecting threats with Microsoft Sentinel](detect-threats-built-in.md).
-- [Use workbooks](monitor-your-data.md) to monitor your data.
+- [Use workbooks](monitor-your-data.md) to monitor your data.
