Merge pull request #265878 from MicrosoftDocs/main

02/09 AM Publishing

Author: v-alje

.openpublishing.redirection.json

@@ -10640,6 +10640,16 @@
             "redirect_url": "/azure/orbital/overview",
             "redirect_document_id": false
         },
+        {
+            "source_path_from_root": "/articles/load-balancer/cross-region-overview.md",
+            "redirect_url": "/azure/reliability/reliability-load-balancer",
+            "redirect_document_id": false
+        },
+        {
+            "source_path_from_root": "/articles/load-balancer/load-balancer-standard-availability-zones.md",
+            "redirect_url": "/azure/reliability/reliability-load-balancer",
+            "redirect_document_id": false
+        },
         {
             "source_path_from_root": "/articles/load-balancer/upgrade-basic-standard-virtual-machine-scale-sets.md",
             "redirect_url": "/azure/load-balancer/upgrade-basic-standard-with-powershell",

articles/ai-services/openai/concepts/use-your-data.md

@@ -598,7 +598,6 @@ You can use Azure OpenAI on your data with an Azure OpenAI resource in the follo
 * South India
 * Sweden Central
 * Switzerland North
-* UAE North
 * UK South
 * West Europe
 * West US

articles/ai-services/openai/how-to/assistant.md

@@ -373,14 +373,6 @@ print(image_file_id)  # Outputs: assistant-1YGVTvNzc2JXajI5JU9F0HMD
 ### Download image
 
 ```python
-from openai import AzureOpenAI
-    
-client = AzureOpenAI(
-    api_key=os.getenv("AZURE_OPENAI_KEY"),  
-    api_version="2024-02-15-preview",
-    azure_endpoint = os.getenv("AZURE_OPENAI_ENDPOINT")
-    )
-
 content = client.files.content(image_file_id)
 
 image= content.write_to_file("sinewave.png")

articles/ai-services/openai/whats-new.md

@@ -55,9 +55,8 @@ Azure OpenAI Service now supports text to speech APIs with OpenAI's voices. Get
 
 ### New regional support for Azure OpenAI on your data
 
-You can now use Azure OpenAI on your data in the following Azure regions:
+You can now use Azure OpenAI on your data in the following Azure region:
 * South Africa North
-* UAE North
 
 ## December 2023
 

articles/aks/TOC.yml

@@ -409,6 +409,8 @@
               href: control-kubeconfig-access.md
             - name: Define API server authorized IP ranges
               href: api-server-authorized-ip-ranges.md
+            - name: Manage cluster certificates and rotation
+              href: certificate-rotation.md
             - name: Use custom certificate authorities
               href: custom-certificate-authority.md
             - name: Use Azure Policy

articles/azure-arc/resource-bridge/upgrade.md

@@ -64,7 +64,7 @@ Arc resource bridge can be manually upgraded from the management machine. You mu
 
 Manual upgrade generally takes between 30-90 minutes, depending on network speeds. The upgrade command takes your Arc resource bridge to the next appliance version, which might not be the latest available appliance version. Multiple upgrades could be needed to reach a [supported version](#supported-versions). You can check your appliance version by checking the Azure resource of your Arc resource bridge.
 
-To manually upgrade your Arc resource bridge, make sure you're using the latest `az arcappliance` CLI extension by running the extension upgrade command from the management machine:
+Before upgrading, you'll need the latest Azure CLI extension for `arcappliance`:
 
 ```azurecli
 az extension add --upgrade --name arcappliance 
@@ -78,7 +78,7 @@ az arcappliance upgrade <private cloud> --config-file <file path to ARBname-appl
 
 For example, to upgrade a resource bridge on VMware, run: `az arcappliance upgrade vmware --config-file c:\contosoARB01-appliance.yaml`
 
-To upgrade a resource bridge on System Center Virtual Machine Manager (SCVMM), run: `az arcappliance upgrade scvmm --config-file c:\contosoARB01-appliance.yaml`
+To upgrade a resource bridge on SCVMM, run: `az arcappliance upgrade scvmm --config-file c:\contosoARB01-appliance.yaml`
 
 To upgrade a resource bridge on Azure Stack HCI, please transition to 23H2 and use the built-in upgrade management tool. More info available [here](/azure-stack/hci/update/about-updates-23h2).
 

articles/azure-monitor/app/convert-classic-resource.md

@@ -25,12 +25,9 @@ Workspace-based resources:
 > [!IMPORTANT]
 > * On February 29, 2024, continuous export will be deprecated as part of the classic Application Insights deprecation.
 > 
-
-> 
->    * You can enable [diagnostic settings on classic Application Insights]() before you [migrate to a workspace-based Application Insights resource](convert-classic-resource.md).All [workspace-based Application Insights resources](./create-workspace-resource.md) must use [diagnostic settings](./create-workspace-resource.md#export-telemetry).
->    
+> * [Workspace-based Application Insights resources](./create-workspace-resource.md) are not compatible with continuous export. We recommend migrating to  [diagnostic settings](../essentials/diagnostic-settings.md) on classic Application Insights resources before transitioning to a workspace-based Application Insights. This ensures continuity and compatibility of your diagnostic settings.
+>
 > * Diagnostic settings export might increase costs. For more information, see [Diagnostic settings-based export](export-telemetry.md#diagnostic-settings-based-export).
-> 
 
 ## New capabilities
 
@@ -327,21 +324,30 @@ No. There's no impact to [Live Metrics](live-stream.md#live-metrics-monitor-and-
 
 ### What happens with continuous export after migration?
 
-To continue with automated exports, you will need to migrate to [diagnostic settings](/previous-versions/azure/azure-monitor/app/continuous-export-diagnostic-setting) before migrating to workspace-based resource.  The diagnostic setting will carry over in the migration to workspace-based Application Insights.
+To continue with automated exports, you'll need to migrate to [diagnostic settings](/previous-versions/azure/azure-monitor/app/continuous-export-diagnostic-setting) before migrating to workspace-based resource.  The diagnostic setting carries over in the migration to workspace-based Application Insights.
 
 ### How do I ensure a successful migration of my App Insights resource using Terraform?
 
-If you are using Terraform to manage your Azure resources, it is important to use the latest version of the Terraform azurerm provider before attempting to upgrade your App Insights resource. Using an older version of the provider, such as version 3.12, may result in the deletion of the classic component before creating the replacement workspace-based Application Insights resource. This can cause the loss of previous data and require updating the configurations in your monitored apps with new connection string and instrumentation key values.
+If you're using Terraform to manage your Azure resources, it's important to use the latest version of the Terraform azurerm provider before attempting to upgrade your App Insights resource. Using an older version of the provider, such as version 3.12, may result in the deletion of the classic component before creating the replacement workspace-based Application Insights resource. It can cause the loss of previous data and require updating the configurations in your monitored apps with new connection string and instrumentation key values.
 
 To avoid this issue, make sure to use the latest version of the Terraform [azurerm provider](https://registry.terraform.io/providers/hashicorp/azurerm/latest), version 3.89 or higher, which performs the proper migration steps by issuing the appropriate ARM call to upgrade the App Insights classic resource to a workspace-based resource while preserving all the old data and connection string/instrumentation key values.
 
+### Can I still use the old API to create Application Insights resources programmatically?
+Yes, calls to the old API for creating Application Insights resources continue to work as before. The old API version doesn't include a reference to the Log Analytics resource. However, when you trigger a legacy API call, it automatically creates a resource and the required association between Application Insights and Log Analytics.
+
+### Should I migrate diagnostic settings on classic Application Insights before moving to a workspace-based AI?
+Yes, we recommend migrating diagnostic settings on classic Application Insights resources before transitioning to a workspace-based Application Insights. It ensures continuity and compatibility of your diagnostic settings.
+
+### What is the migration process for Application Insights resources?
+The migration of Application Insights resources to the new format isn't instantaneous on the day of deprecation. Instead, it occurs over time. We'll gradually migrate all Application Insights resources, ensuring a smooth transition with minimal disruption to your services.
+
 ## Troubleshooting
 
 This section offers troubleshooting tips for common issues.
 
 ### Access mode
 
-**Error message:** "The selected workspace is configured with workspace-based access mode. Some APM features may be impacted. Select another workspace or allow resource-based access in the workspace settings. You can override this error by using CLI."
+**Error message:** "The selected workspace is configured with workspace-based access mode. Some Application Performance Monitoring (APM) features may be impacted. Select another workspace or allow resource-based access in the workspace settings. You can override this error by using CLI."
 
 For your workspace-based Application Insights resource to operate properly, you need to change the access control mode of your target Log Analytics workspace to the **Resource or workspace permissions** setting. This setting is located in the Log Analytics workspace UI under **Properties** > **Access control mode**. For instructions, see the [Log Analytics configure access control mode guidance](../logs/manage-access.md#access-control-mode). If your access control mode is set to the exclusive **Require workspace permissions** setting, migration via the portal migration experience remains blocked.
 
@@ -351,9 +357,9 @@ If you can't change the access control mode for security reasons for your curren
 
 **Error message:** "Continuous Export needs to be disabled before continuing. After migration, use Diagnostic Settings for export."
 
-The legacy **Continuous export** functionality isn't supported for workspace-based resources. Prior to migrating, you need to enable diagnostic settings and disable continuous export.
+The legacy **Continuous export** functionality isn't supported for workspace-based resources. Before migrating, you need to enable diagnostic settings and disable continuous export.
 
-1. [Enable Diagnostic Settings](/previous-versions/azure/azure-monitor/app/continuous-export-diagnostic-setting) on you classic Application Insights resource.
+1. [Enable Diagnostic Settings](/previous-versions/azure/azure-monitor/app/continuous-export-diagnostic-setting) on your classic Application Insights resource.
 1. From your Application Insights resource view, under the **Configure** heading, select **Continuous export**.
 
     :::image type="content" source="./media/convert-classic-resource/continuous-export.png" lightbox="./media/convert-classic-resource/continuous-export.png" alt-text="Screenshot that shows the Continuous export menu item.":::

articles/azure-monitor/app/java-standalone-upgrade-from-2x.md

@@ -21,7 +21,7 @@ There are typically no code changes when upgrading to 3.x. The 3.x SDK dependenc
 | `applicationinsights-web-auto` | Replace with `3.4.3` or later of `applicationinsights-web` |                                                                                                                                                                                             |
 | `applicationinsights-logging-log4j1_2` | Remove the dependency and remove the Application Insights appender from your log4j configuration. | No longer needed since Log4j 1.2 is autoinstrumented in the 3.x Java agent.                                                                                                                |
 | `applicationinsights-logging-log4j2` | Remove the dependency and remove the Application Insights appender from your log4j configuration. | No longer needed since Log4j 2 is autoinstrumented in the 3.x Java agent.                                                                                                                  |
-| `applicationinsights-logging-log4j1_2` | Remove the dependency and remove the Application Insights appender from your logback configuration. | No longer needed since Logback is autoinstrumented in the 3.x Java agent.                                                                                                                  |
+| `applicationinsights-logging-logback` | Remove the dependency and remove the Application Insights appender from your logback configuration. | No longer needed since Logback is autoinstrumented in the 3.x Java agent.                                                                                                                  |
 | `applicationinsights-spring-boot-starter` | Replace with `3.4.3` or later of `applicationinsights-web` | The cloud role name will no longer default to `spring.application.name`, see the [3.x configuration docs](./java-standalone-config.md#cloud-role-name) for configuring the cloud role name. |
 
 ## Step 2: Add the 3.x Java agent

articles/azure-monitor/essentials/prometheus-metrics-overview.md

@@ -27,7 +27,7 @@ Azure Monitor managed service for Prometheus can currently collect data from any
 ## Enable
 The only requirement to enable Azure Monitor managed service for Prometheus is to create an [Azure Monitor workspace](azure-monitor-workspace-overview.md), which is where Prometheus metrics are stored. Once this workspace is created, you can onboard services that collect Prometheus metrics.
 
-- To collect Prometheus metrics from your Kubernetes cluster, see [Enable monitoring for Kubernetes clusters](../containers/kubernetes-monitoring-enable.md).
+- To collect Prometheus metrics from your Kubernetes cluster, see [Enable monitoring for Kubernetes clusters](../containers/kubernetes-monitoring-enable.md#enable-prometheus-and-grafana).
 - To configure remote-write to collect data from your self-managed Prometheus server, see [Azure Monitor managed service for Prometheus remote write - managed identity](prometheus-remote-write-managed-identity.md).
 
 ## Grafana integration

articles/backup/backup-azure-database-postgresql-troubleshoot.md

@@ -107,7 +107,7 @@ The Azure Backup service uses the credentials mentioned in the key-vault to acce
 
 The Azure Backup service uses the credentials mentioned in the key-vault to access the database as a database user. The relevant key vault and the secret are [provided during configuration of backup](backup-azure-database-postgresql.md#configure-backup-on-azure-postgresql-databases). The key-vault associated with this backup instance can be found by accessing the backup instance and selecting the JSON view. You'll see the key-vault name and secret details listed under the **datasourceAuthCredentials** section as shown in the below screenshot.
 
- 
+:::image type="content" source="./media/backup-azure-database-postgresql-troubleshoot/key-vault-secret-name.png" alt-text="Screenshot showing how to search for key vault by using secret name." lightbox="./media/backup-azure-database-postgresql-troubleshoot/key-vault-secret-name.png":::
 
 ## UserErrorSecretValueInUnsupportedFormat