Merge pull request #251265 from MicrosoftDocs/main

Publish to Live Wednesday 4AM PST, 09/13

Author: PMEds28

.openpublishing.publish.config.json

@@ -1039,6 +1039,12 @@
       "url": "https://github.com/Azure/Azure-Proactive-Resiliency-Library",
       "branch": "main",
       "branch_mapping": {}
+    },
+    {
+      "path_to_root": "azure-reference-other-repo",
+      "url": "https://github.com/MicrosoftDocs/azure-reference-other-pr",
+      "branch": "main",
+      "branch_mapping": {}
     }
   ],
   "branch_target_mapping": {

articles/aks/planned-maintenance.md

@@ -308,6 +308,14 @@ az aks maintenanceconfiguration delete -g myResourceGroup --cluster-name myAKSCl
 
   Yes, you can run all three configurations i.e `default`, `aksManagedAutoUpgradeSchedule`, `aksManagedNodeOSUpgradeSchedule`simultaneously.  In case the windows overlap AKS decides the running order. 
 
+* I configured a maintenance window, but upgrade didn't happen - why?
+
+  AKS auto-upgrade needs a certain amount of time to take the maintenance window into consideration. We recommend at least 6 hours between the creation/update of the maintenance configuration, and when it's scheduled to start.
+
+* AKS auto-upgrade didn't upgrade all my agent pools - or one of the pools was upgraded outside of the maintenance window?
+
+  If an agent pool fails to upgrade (eg. because of Pod Disruption Budgets preventing it to upgrade) or is in a Failed state, then it might be upgraded later outside of the maintenance window. This scenario is called "catch-up upgrade" and avoids letting Agent pools with a different version than the AKS control plane.
+
 *  Are there any best practices for the maintenance configurations?
 
   We recommend setting the [Node OS security updates][node-image-auto-upgrade] schedule to a weekly cadence if you're using `NodeImage` channel since a new node image gets shipped every week and daily if you opt in for `SecurityPatch` channel to receive daily security updates. Set the [auto-upgrade][auto-upgrade] schedule to a monthly cadence to stay on top of the kubernetes N-2 [support policy][aks-support-policy]. 

articles/azure-app-configuration/reference-kubernetes-provider.md

@@ -162,7 +162,7 @@ The `spec.keyValues.refresh.monitoring.keyValues` is an array of objects, which
 #### Use Connection String
 
 1. Create a Kubernetes Secret in the same namespace as the `AzureAppConfigurationProvider` resource and add Azure App Configuration connection string with key *azure_app_configuration_connection_string* in the Secret.
-2. Set the `spec.connectionStringReference` property to the name of the Secret in the following sample `AzureAppConfigurationProvider` resource and deploy it to the Kubernetes cluster.
+1. Set the `spec.connectionStringReference` property to the name of the Secret in the following sample `AzureAppConfigurationProvider` resource and deploy it to the Kubernetes cluster.
 
     ``` yaml
     apiVersion: azconfig.io/v1beta1
@@ -174,7 +174,6 @@ The `spec.keyValues.refresh.monitoring.keyValues` is an array of objects, which
       target:
         configMapName: configmap-created-by-appconfig-provider
     ```
-
 ### Key-value selection
 
 Use the `selectors` property to filter the key-values to be downloaded from Azure App Configuration.

articles/azure-monitor/alerts/alerts-create-new-alert-rule.md

@@ -217,8 +217,7 @@ To edit an existing alert rule:
         |---------|---------|
         |Number of violations|The number of violations that trigger the alert.|
         |Evaluation period|The time period within which the number of violations occur. |
-        |Override query time range| If you want the alert evaluation period to be different than the query time range, enter a time range here.<br> The alert time range is limited to a maximum of two days. Even if the query contains an **ago** command with a time range of longer than two days, the two-day maximum time range is applied. For example, even if the query text contains **ago(7d)**, the query only scans up to two days of data.<br> If the query requires more data than the alert evaluation you can change the time range manually.
-If the query contains **ago** command in the query, it will be cahnged automatically to 2 days (48 hours).|
+        |Override query time range| If you want the alert evaluation period to be different than the query time range, enter a time range here.<br> The alert time range is limited to a maximum of two days. Even if the query contains an **ago** command with a time range of longer than two days, the two-day maximum time range is applied. For example, even if the query text contains **ago(7d)**, the query only scans up to two days of data. If the query requires more data than the alert evaluation you can change the time range manually. If the query contains **ago** command, it will be changed automatically to 2 days (48 hours).|<br> 
 
         > [!NOTE]
         > If you or your administrator assigned the Azure Policy **Azure Log Search Alerts over Log Analytics workspaces should use customer-managed keys**, you must select **Check workspace linked storage**. If you don't, the rule creation will fail because it won't meet the policy requirements.

articles/azure-monitor/logs/azure-monitor-data-explorer-proxy.md

@@ -23,7 +23,7 @@ To run a cross-service query, you need:
 
 ## Function supportability
 
-Azure Monitor cross-service queries support functions for Application Insights, Log Analytics, Azure Data Explorer, and Azure Resource Graph.
+Azure Monitor cross-service queries support **only ".show"** functions for Application Insights, Log Analytics, Azure Data Explorer, and Azure Resource Graph.
 This capability enables cross-cluster queries to reference an Azure Monitor, Azure Data Explorer, or Azure Resource Graph tabular function directly.
 The following commands are supported with the cross-service query:
 

articles/azure-monitor/vm/vminsights-enable-hybrid.md

@@ -39,8 +39,8 @@ You can download the Dependency agent from these locations:
 
 | File | OS | Version | SHA-256 |
 |:--|:--|:--|:--|
-| [InstallDependencyAgent-Windows.exe](https://aka.ms/dependencyagentwindows) | Windows | 9.10.16.22650 | BE537D4396625ADD93B8C1D5AF098AE9D9472D8A20B2682B32920C5517F1C041    |
-| [InstallDependencyAgent-Linux64.bin](https://aka.ms/dependencyagentlinux) | Linux | 9.10.16.22650 | FF86D821BA845833C9FE5F6D5C8A5F7A60617D3AD7D84C75143F3E244ABAAB74  |
+| [InstallDependencyAgent-Windows.exe](https://aka.ms/dependencyagentwindows) | Windows | 9.10.17.3860 | BA3D1CF76E2BCCE35815B0F62C0A18E84E0459B468066D0F80F56514A74E0BF6  |
+| [InstallDependencyAgent-Linux64.bin](https://aka.ms/dependencyagentlinux) | Linux | 9.10.17.3860 | 22538642730748F4AD8688D00C2919055825BA425BAAD3591D6EBE0021863617  |
 
 ## Install the Dependency agent on Windows
 

articles/cosmos-db/.openpublishing.redirection.cosmos-db.json

@@ -6161,9 +6161,9 @@
       "redirect_document_id": false
     },
     {
-      "source_path_from_root": "/articles/cosmos-db/mongodb/introduction.md",
-      "redirect_url": "/azure/cosmos-db/mongodb/ru/introduction",
-      "redirect_document_id": true
+      "source_path_from_root": "/articles/cosmos-db/mongodb/overview.md",
+      "redirect_url": "/azure/cosmos-db/mongodb/introduction",
+      "redirect_document_id": false
     }
   ]
 }

articles/cosmos-db/mongodb/TOC.yml

@@ -1,5 +1,5 @@
 - name: What is Azure Cosmos DB for MongoDB?
-  href: overview.md
+  href: introduction.md
 - name: Choose your model
   href: choose-model.md
 - name: Comparing MongoDB Atlas

articles/cosmos-db/mongodb/choose-model.md

@@ -33,7 +33,7 @@ Here are a few key factors to help you decide which is the right option for you.
 ### Choose vCore-based if
 
 - You're migrating (lift & shift) an existing MongoDB workload or building a new MongoDB application.
-- Your workload has more point reads (fetching a single item by its ID and shard key value) and few long-running queries and complex aggregation pipeline operations.
+- Your workload has more long-running queries, complex aggregation pipelines, distributed transactions, joins, etc.
 - You prefer high-capacity vertical and horizontal scaling with familiar vCore-based cluster tiers such as M30, M40, M50 and more.
 - You're running applications requiring 99.995% availability.