Merge pull request #266033 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: v-alje

articles/aks/azure-cni-overlay.md

@@ -173,11 +173,7 @@ az aks update --name $clusterName \
 The `--pod-cidr` parameter is required when upgrading from legacy CNI because the pods need to get IPs from a new overlay space, which doesn't overlap with the existing node subnet. The pod CIDR also can't overlap with any VNet address of the node pools. For example, if your VNet address is *10.0.0.0/8*, and your nodes are in the subnet *10.240.0.0/16*, the `--pod-cidr` can't overlap with *10.0.0.0/8* or the existing service CIDR on the cluster.
 
 
-### Kubenet Cluster Upgrade (Preview)
-
-[!INCLUDE [preview features callout](includes/preview/preview-callout.md)]
-
-You must have the latest aks-preview Azure CLI extension installed and register the `Microsoft.ContainerService` `AzureOverlayPreview` feature flag.
+### Kubenet Cluster Upgrade
 
 Update an existing Kubenet cluster to use Azure CNI Overlay using the [`az aks update`][az-aks-update] command.
 
@@ -192,7 +188,7 @@ az aks update --name $clusterName \
 --network-plugin-mode overlay 
 ```
 
-Since the cluster is already using a private CIDR for pods, you don't need to specify the `--pod-cidr` parameter and the Pod CIDR will remain the same.
+Since the cluster is already using a private CIDR for pods which doesn't overlap with the VNet IP space, you don't need to specify the `--pod-cidr` parameter and the Pod CIDR will remain the same.
 
 > [!NOTE]
 > When upgrading from Kubenet to CNI Overlay, the route table will no longer be required for pod routing. If the cluster is using a customer provided route table, the routes which were being used to direct pod traffic to the correct node will automatically be deleted during the migration operation. If the cluster is using a managed route table (the route table was created by AKS and lives in the node resource group) then that route table will be deleted as part of the migration.

articles/aks/ingress-basic.md

@@ -68,6 +68,10 @@ helm install ingress-nginx ingress-nginx/ingress-nginx `
   --set controller.service.externalTrafficPolicy=Local
 ```
 
+> [!NOTE]
+> In this tutorial, "service.beta.kubernetes.io/azure-load-balancer-health-probe-request-path" is being set to "/healthz". This means if the response code of the requests to "/healthz" is not "200", the whole ingress controller will be down. You can modify the value to other URI in your own scenario. You cannot delete this part or unset the value, or the ingress controller will still be down.
+> The package "ingress-nginx" used in this tutorial, which is provided by [Kubernetes official](https://github.com/kubernetes/ingress-nginx), will always return "200" response code if requesting "/healthz", as it is designed as "[default backend](https://kubernetes.github.io/ingress-nginx/user-guide/default-backend/)" for users to have a quick start, unless it is being overwritten by ingress rules.
+
 ---
 
 ## Customized configuration

articles/azure-arc/kubernetes/cluster-connect.md

@@ -224,6 +224,12 @@ On the existing Arc-enabled cluster, create the ClusterRoleBinding with either M
     ```console
     $TOKEN = ([System.Text.Encoding]::UTF8.GetString([System.Convert]::FromBase64String((kubectl get secret demo-user-secret -o jsonpath='{$.data.token}'))))
     ```
+    
+1. Get the token to output to console.
+  
+     ```console
+     echo $TOKEN
+     ```
 
 ---
 

articles/azure-monitor/essentials/platform-logs-overview.md

@@ -18,7 +18,7 @@ The following table lists the platform logs that are available at different laye
 
 | Log | Layer | Description |
 |:---|:---|:---|
-| [Resource logs](./resource-logs.md) | Azure Resources | Resource logs provide an insight into operations that were performed within an Azure resource. This is know as the *data plane*. Examples include getting a secret from a key vault, or making a request to a database. The contents of resource logs varies according to the Azure service and resource type.<br><br>*Resource logs were previously referred to as diagnostic logs.*  |
+| [Resource logs](./resource-logs.md) | Azure Resources | Resource logs provide an insight into operations that were performed within an Azure resource. This is known as the *data plane*. Examples include getting a secret from a key vault, or making a request to a database. The contents of resource logs varies according to the Azure service and resource type.<br><br>*Resource logs were previously referred to as diagnostic logs.*  |
 | [Activity logs](../essentials/activity-log.md) | Azure Subscription |Activity logs provide an insight into the operations performed *on* each Azure resource in the subscription from the outside, known as the *management plane*. in addition to updates on Service Health events. Use the Activity log to determine *what*, *who*, and *when* for any write operation (PUT, POST, DELETE) executed on the resources in your subscription. There's a single activity log for each Azure subscription. |
 | [Microsoft Entra logs](../../active-directory/reports-monitoring/overview-reports.md) | Azure Tenant |  Microsoft Entra logs contain the history of sign-in activity and an audit trail of changes made in Microsoft Entra ID for a particular tenant.   |
 

articles/communication-services/quickstarts/email/send-email-smtp/includes/send-email-smtp-smtpclient.md

@@ -102,6 +102,6 @@ try
 }
 catch (Exception ex)
 {
-    Console.WriteLine($"Smtp failed the the exception: {ex.Message}.");
+    Console.WriteLine($"Smtp send failed with the exception: {ex.Message}.");
 }
 ```

articles/iot-operations/manage-mqtt-connectivity/howto-configure-tls-manual.md

@@ -58,15 +58,21 @@ Here, `mqtts-endpoint` and `localhost` are the Subject Alternative Names (SANs)
 
 Both EC and RSA keys are supported, but all certificates in the chain must use the same key algorithm. If you import your own CA certificates, ensure that the server certificate uses the same key algorithm as the CAs.
 
-## Import server certificate as a Kubernetes secret
+## Import server certificate chain as a Kubernetes secret
 
-Create a Kubernetes secret with the certificate and key using kubectl.
+1. Create a full server certificate chain, where the order of the certificates matters: the server certificate is the first one in the file, the intermediate is the second.
 
-```bash
-kubectl create secret tls server-cert-secret -n azure-iot-operations \
---cert mqtts-endpoint.crt \
---key mqtts-endpoint.key
-```
+    ```bash
+    cat  mqtts-endpoint.crt intermediate_ca.crt  > server_chain.pem
+    ```
+
+1. Create a Kubernetes secret with the server certificate chain and server key using kubectl.
+
+    ```bash
+    kubectl create secret tls server-cert-secret -n azure-iot-operations \
+    --cert server_chain.crt \
+    --key mqtts-endpoint.key
+    ```
 
 ## Enable TLS for a listener
 
@@ -94,26 +100,23 @@ Once the BrokerListener resource is created, the operator automatically creates
 
 ## Connect to the broker with TLS
 
-1. To test the TLS connection with mosquitto, first create a full certificate chain file with Step CLI.
+To test the TLS connection with mosquitto client, publish a message and pass the root CA certificate in the parameter `--cafile`.
 
-    ```bash
-    cat root_ca.crt intermediate_ca.crt > chain.pem
-    ```
-
-1. Use mosquitto to publish a message.
-
-    ```console
-    $ mosquitto_pub -d -h localhost -p 8885 -i "my-client" -t "test-topic" -m "Hello" --cafile chain.pem
-    Client my-client sending CONNECT
-    Client my-client received CONNACK (0)
-    Client my-client sending PUBLISH (d0, q0, r0, m1, 'test-topic', ... (5 bytes))
-    Client my-client sending DISCONNECT
-    ```
+```console
+$ mosquitto_pub -d -h localhost -p 8885 -i "my-client" -t "test-topic" -m "Hello" --cafile root_ca.crt
+Client my-client sending CONNECT
+Client my-client received CONNACK (0)
+Client my-client sending PUBLISH (d0, q0, r0, m1, 'test-topic', ... (5 bytes))
+Client my-client sending DISCONNECT
+```
 
 > [!TIP]
 > To use localhost, the port must be available on the host machine. For example, `kubectl port-forward svc/mqtts-endpoint 8885:8885 -n azure-iot-operations`. With some Kubernetes distributions like K3d, you can add a forwarded port with `k3d cluster edit $CLUSTER_NAME --port-add 8885:8885@loadbalancer`.
 
-Remember to specify username, password, etc. if authentication is enabled.
+> [!NOTE]
+> To connect to the broker you need to distribute root of trust to the clients, also known as trust bundle. In this case the root of trust is the self-signed root CA created Step CLI. Distribution of root of trust is required for the client to verify the server certificate chain. If your MQTT clients are workloads on the Kubernetes cluster you also need to create a ConfigMap with the root CA and mount it in your Pod.
+
+Remember to specify username, password, etc. if MQ authentication is enabled.
 
 ### Use external IP for the server certificate
 

articles/machine-learning/how-to-setup-customer-managed-keys.md

@@ -30,7 +30,7 @@ In the [customer-managed keys concepts article](concept-customer-managed-keys.md
     | Resource provider | Why it's needed |
     | ----- | ----- |
     | Microsoft.MachineLearningServices | Creating the Azure Machine Learning workspace.
-    | Microsoft.Storage    Azure | Storage Account is used as the default storage for the workspace.
+    | Microsoft.Storage | Storage Account is used as the default storage for the workspace.
     | Microsoft.KeyVault |Azure Key Vault is used by the workspace to store secrets.
     | Microsoft.DocumentDB/databaseAccounts | Azure Cosmos DB instance that logs metadata for the workspace.
     | Microsoft.Search/searchServices | Azure Search provides indexing capabilities for the workspace.

articles/storage/files/storage-files-migration-robocopy.md

@@ -215,6 +215,18 @@ You should be prepared to run multiple rounds of RoboCopy against a given namesp
 
 `/R:5 /W:5` is a reasonable setting that you can adjust to your liking. In this example, a failed file will be retried five times, with five-second wait time between retries. If the file still fails to copy, the next RoboCopy job will try again. Often files that failed because they are in use or because of timeout issues might eventually be copied successfully this way.
 
+### Estimating storage transaction charges
+
+As you begin your migration to Azure Files, RoboCopy copies your files and folders into Azure. Depending on your billing model for Azure Files, transaction charges might apply. See [Understanding billing](understanding-billing.md).
+
+If you're using a pay-as-you-go billing model for standard Azure file shares, it might be difficult to estimate the number of transactions your migration will generate.
+
+- It's not possible to estimate the number of transactions based on the utilized storage capacity of the source. The number of transactions scales with the number of namespace items (files and folder) and their properties that are migrated, not their size. For example, more transactions are required to migrate 1 GiB of small files than 1 GiB of larger files.
+- In order to minimize downtime, you might need to run copy operations several times from source to target. All source and target items are processed during each copy operation, though subsequent runs finish faster. After the initial operations, only the differences introduced between copy runs are transported over the network. It's important to understand that although less data is being transported, the number of transactions required might remain the same.
+- Copying the same file twice might not result in the same number of transactions. Processing an item migrated in a previous copy run might result in only a few read transactions. In contrast, changes to metadata or content between copy runs might require a larger number of transactions to update the target. Each file in your namespace might have unique requirements, resulting in a different number of transactions.
+
+It's advisable to run some initial tests on your own data to better understand how many transactions are incurred. This will give you a better idea of the total number of transactions a file migration might generate. 
+
 ## Next steps
 
 The following articles will help you understand advanced options and best practices.

articles/virtual-network/virtual-network-peering-overview.md

@@ -62,7 +62,7 @@ Addresses can be resized in the following ways:
 
 - Resizing of address space is supported cross-tenant
 
-Synching of virtual network peers can be performed through the Azure portal or with Azure PowerShell. We recommend that you run sync after every resize address space operation instead of performing multiple resizing operations and then running the sync operation. To learn how to update the address space for a peered virtual network, see [Updating the address space for a peered virtual network](./update-virtual-network-peering-address-space.md).
+Syncing of virtual network peers can be performed through the Azure portal or with Azure PowerShell. We recommend that you run sync after every resize address space operation instead of performing multiple resizing operations and then running the sync operation. To learn how to update the address space for a peered virtual network, see [Updating the address space for a peered virtual network](./update-virtual-network-peering-address-space.md).
 
 > [!IMPORTANT]
 > This feature doesn't support scenarios where the virtual network to be updated is peered with: