Merge pull request #278623 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: PhilKang0704

articles/azure-arc/multicloud-connector/onboard-multicloud-vms-arc.md

@@ -24,7 +24,7 @@ In addition to the [general prerequisites](connect-to-aws.md#prerequisites) for
 - You must have **AmazonEC2FullAccess** permissions in your public cloud.
 - EC2 instances must meet the [general prerequisites for installing the Connected Machine agent](../servers/prerequisites.md).
 - EC2 instances must have the SSM agent installed. Most EC2 instances have this preconfigured.
-- EC2 instances must have a tag with the key of `arc` (case-sensitive) and empty value. This tag can be assigned manually or via a policy.
+- EC2 instances must have a tag with the key of `arc` and any value. This tag can be assigned manually or via a policy.
 - The **ArcForServerSSMRole** IAM role [attached on each EC2 instance](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role). This role attachment must be done after you upload your Cloud Formation Template in the Connector creation steps.
 
 ## AWS resource representation in Azure
@@ -48,4 +48,4 @@ If you prefer, you can turn periodic sync off when configuring this solution. If
 ## Next steps
 
 - Learn more about [managing connected servers through Azure Arc](../servers/overview.md).
-- Learn about the [Multicloud Connector **Inventory** solution](view-multicloud-inventory.md).
+- Learn about the [Multicloud Connector **Inventory** solution](view-multicloud-inventory.md).

articles/container-instances/container-instances-managed-identity.md

@@ -176,6 +176,12 @@ Output:
 {"access_token":"xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSIsImtpZCI6Imk2bEdrM0ZaenhSY1ViMkMzbkVRN3N5SEpsWSJ9......xxxxxxxxxxxxxxxxx","refresh_token":"","expires_in":"28799","expires_on":"1539927532","not_before":"1539898432","resource":"https://vault.azure.net/","token_type":"Bearer"}
 ```
 
+For Windows containers, metadata server (169.254.169.254) is not available. Run the following or equivalent commands to get an access token.
+
+```console
+curl -G -v %IDENTITY_ENDPOINT% --data-urlencode resource=https://vault.azure.net --data-urlencode principalId=<principal id> -H secret:%IDENTITY_HEADER%
+```
+
 To store the access token in a variable to use in subsequent commands to authenticate, run the following command:
 
 ```bash
@@ -289,6 +295,8 @@ The value of the secret is retrieved:
 "Hello Container Instances"
 ```
 
+For Windows containers, the 'az login' command will not work because the metadata server is unavailable. Additionally, a managed identity token cannot be generated in a Windows VNet container.
+
 ## Enable managed identity using Resource Manager template
 
 To enable a managed identity in a container group using a [Resource Manager template](container-instances-multi-container-group.md), set the `identity` property of the `Microsoft.ContainerInstance/containerGroups` object with a `ContainerGroupIdentity` object. The following snippets show the `identity` property configured for different scenarios. See the [Resource Manager template reference](/azure/templates/microsoft.containerinstance/containergroups). Specify a minimum `apiVersion` of `2018-10-01`.

articles/iot-operations/deploy-iot-ops/howto-manage-secrets.md

@@ -125,7 +125,7 @@ When following the guide [Deploy Azure IoT Operations extensions](./howto-deploy
 The following example shows how to prepare the cluster for Azure IoT Operations without fully deploying it by using `--no-deploy` flag. You can also run the command without this argument for a default Azure IoT Operations deployment.
 
 ```bash
-az iot ops init --name "<your unique key vault name>" --resource-group "<the name of the resource group>" \
+az iot ops init --cluster "<your cluster name>" --resource-group "<the name of the resource group>" \
     --kv-id <Key Vault Resource ID> \
     --sp-app-id <Application registration App ID (client ID) from Microsoft Entra ID> \
     --sp-object-id <Object ID copied from Enterprise Application in Microsoft Entra ID> \

articles/synapse-analytics/spark/apache-spark-34-runtime.md

@@ -26,13 +26,11 @@ Azure Synapse Analytics supports multiple runtimes for Apache Spark. This docume
 | Python | 3.10     |
 | R | 4.2.2    |
 
->[!TIP]
-> For up-to-date information, a detailed list of changes, and specific release notes for Spark runtimes, check and subscribe [Spark Runtimes Releases and Updates](https://github.com/microsoft/synapse-spark-runtime).
-
+> [!TIP]
+> For up-to-date information, a detailed list of changes, and specific release notes for Spark runtimes, check and subscribe [Spark Runtimes Releases and Updates](https://github.com/microsoft/synapse-spark-runtime/tree/main/Synapse/spark3.4).
 ## Libraries
 
-To check the libraries included in Azure Synapse Runtime for Apache Spark 3.4 for Java/Scala, Python and R go to [Azure Synapse Runtime for Apache Spark 3.4 Releases Notes]              (https://github.com/microsoft/synapse-spark-runtime/blob/main/Synapse/spark3.4/Official-Spark3.4-Rel-2024-03-27.2-rc.1.md).
-
+To check the libraries included in Azure Synapse Runtime for Apache Spark 3.4 for Java/Scala, Python and R go to [Azure Synapse Runtime for Apache Spark 3.4 Releases Notes](https://github.com/microsoft/synapse-spark-runtime/tree/main/Synapse/spark3.4).             
 
 ## Related content
 - [Migration between Apache Spark versions - support](./apache-spark-version-support.md#migration-between-apache-spark-versions---support)

articles/virtual-machine-scale-sets/virtual-machine-scale-sets-scale-in-policy.md

@@ -26,8 +26,13 @@ The scale-in policy feature provides users a way to configure the order in which
 ### Default scale-in policy
 
 #### Flexible orchestration 
-With this policy, virtual machines are scaled-in after balancing across availability zones (if the scale set is in zonal configuration), and the oldest virtual machine as per `createdTime` is scaled-in first. 
-Balancing across fault domain isn't available in Default policy with flexible orchestration mode. 
+By default, Virtual Machine Scale Set applies this policy to determine which instance(s) will be scaled in. With the *Default* policy, VMs are selected for scale-in in the following order:
+
+1. Balance virtual machines across availability zones (if the scale set is deployed in zonal configuration)
+2. Balance virtual machines across fault domains (best effort)
+3. Delete virtual machine with the highest instance ID
+
+Users don't need to specify a scale-in policy if they just want the default ordering to be followed.
 
 #### Uniform orchestration 
 By default, Virtual Machine Scale Set applies this policy to determine which instance(s) will be scaled in. With the *Default* policy, VMs are selected for scale-in in the following order: