Merge pull request #5495 from MicrosoftDocs/main

6/12/2025 AM Publish

Author: Taojunshen

articles/machine-learning/concept-machine-learning-registries-mlops.md

@@ -8,7 +8,7 @@ ms.subservice: mlops
 ms.author: larryfr
 author: Blackmist
 ms.reviewer: kritifaujdar
-ms.date: 06/06/2024
+ms.date: 06/12/2025
 ms.topic: concept-article
 ms.custom: build-2023
 ---

articles/machine-learning/how-to-high-availability-machine-learning.md

@@ -9,7 +9,7 @@ ms.topic: how-to
 ms.author: larryfr
 author: Blackmist
 ms.reviewer: andyaviles
-ms.date: 06/28/2024
+ms.date: 06/12/2025
 monikerRange: 'azureml-api-2'
 ---
 
@@ -25,9 +25,9 @@ Microsoft strives to ensure that Azure services are always available. However, u
 * Initiate a failover to another region.
 
 > [!IMPORTANT]
-> Azure Machine Learning itself does not provide automatic failover or disaster recovery. Backup and restore of workspace metadata such as run history is unavailable.
+> Azure Machine Learning itself doesn't provide automatic failover or disaster recovery. Backup and restore of workspace metadata such as run history is unavailable.
 
-In case you have accidentally deleted your workspace or corresponding components, this article also provides you with currently supported recovery options.
+In case you accidentally deleted your workspace or corresponding components, this article also provides you with currently supported recovery options.
 
 ## Understand Azure services for Azure Machine Learning
 
@@ -80,7 +80,7 @@ A multi-regional deployment relies on creation of Azure Machine Learning and oth
     * __Hot/cold__: Primary region active, secondary region has Azure Machine Learning and other resources deployed, along with needed data. Resources such as models, model deployments, or pipelines would need to be manually deployed.
 
 > [!TIP]
-> Depending on your business requirements, you may decide to treat different Azure Machine Learning resources differently. For example, you might want to use hot/hot for deployed models (inference), and hot/cold for experiments (training).
+> Depending on your business requirements, you might decide to treat different Azure Machine Learning resources differently. For example, you might want to use hot/hot for deployed models (inference), and hot/cold for experiments (training).
 
 Azure Machine Learning builds on top of other services. Some services can be configured to replicate to other regions. Others you must manually create in multiple regions. The following table provides a list of services, who is responsible for replication, and an overview of the configuration:
 
@@ -143,7 +143,7 @@ By keeping your data storage isolated from the default storage the workspace use
 ### Manage machine learning assets as code
 
 > [!NOTE]
-> Backup and restore of workspace metadata such as run history, models and environments is unavailable. Specifying assets and configurations as code using YAML specs, will help you re-recreate assets across workspaces in case of a disaster.
+> Backup and restore of workspace metadata such as run history, models and environments is unavailable. Specifying assets and configurations as code using YAML specs, helps you re-recreate assets across workspaces in case of a disaster.
 
 Jobs in Azure Machine Learning are defined by a job specification. This specification includes dependencies on input artifacts that are managed on a workspace-instance level, including environments and compute. For multi-region job submission and deployments, we recommend the following practices:
 
@@ -167,7 +167,7 @@ Azure Machine Learning can't sync or recover artifacts or metadata between works
 :::image type="content" source="./media/how-to-high-availability-machine-learning/bcdr-resource-configuration-v2.png" alt-text="Diagram of failover between paired regions." lightbox="./media/how-to-high-availability-machine-learning/bcdr-resource-configuration-v2.png":::
 
 > [!NOTE]
-> Any jobs that are running when a service outage occurs will not automatically transition to the secondary workspace. It is also unlikely that the jobs will resume and finish successfully in the primary workspace once the outage is resolved. Instead, these jobs must be resubmitted, either in the secondary workspace or in the primary (once the outage is resolved).
+> Any jobs that are running when a service outage occurs won't automatically transition to the secondary workspace. It's also unlikely that the jobs will resume and finish successfully in the primary workspace once the outage is resolved. Instead, these jobs must be resubmitted, either in the secondary workspace or in the primary (once the outage is resolved).
 
 ### Moving artifacts between workspaces
 

articles/machine-learning/how-to-move-workspace.md

@@ -9,7 +9,7 @@ ms.service: azure-machine-learning
 ms.subservice: enterprise-readiness
 ms.reviewer: deeikele
 ms.topic: how-to
-ms.date: 06/13/2024
+ms.date: 06/12/2025
 ---
 
 # Move Azure Machine Learning workspaces between subscriptions (preview)
@@ -44,7 +44,7 @@ Moving the workspace enables you to migrate the workspace and its contents as a
 
     - You need permissions to __delete__ resources from the source location.
     - You need permissions to __create__ resources in the destination location.
-    - Thee move mustn't violate Azure Policies in the destination location.
+    - The move mustn't violate Azure Policies in the destination location.
     - Any role assignments to the source workspace scope aren't moved; you must recreate them in the destination.
 
 - The destination subscription must be registered for required resource providers. The following table contains a list of the resource providers required by Azure Machine Learning:
@@ -70,7 +70,7 @@ Moving the workspace enables you to migrate the workspace and its contents as a
 - The [Azure CLI](/cli/azure/install-azure-cli).
 
     > [!TIP]
-    > The move operation does not use the Azure CLI extension for machine learning.
+    > The move operation doesn't use the Azure CLI extension for machine learning.
 
 ## Supported scenarios
 
@@ -95,7 +95,7 @@ Moving the workspace enables you to migrate the workspace and its contents as a
 * The workspace mustn't be in use during the move operation. Verify that all experiment jobs, data profiling jobs, and labeling projects have completed. Also verify that inference endpoints aren't being invoked.
 * The workspace becomes unavailable during the move.
 * Before to the move, you must delete or detach computes and inference endpoints from the workspace.
-* Datastores may still show the old subscription information after the move. For steps to manually update the datastores, see [Scenario: Move a workspace with nondefault datastores](#scenario-move-a-workspace-with-nondefault-datastores).
+* Datastores might still show the old subscription information after the move. For steps to manually update the datastores, see [Scenario: Move a workspace with nondefault datastores](#scenario-move-a-workspace-with-nondefault-datastores).
 
 The following scenarios __are not__ supported:
 
@@ -125,15 +125,15 @@ The following scenarios __are not__ supported:
     az group create -g destination-rg -l my-region --subscription destination-sub-id                  
     ```
 
-5. The following command demonstrates how to validate the move operation for workspace. You can include associated resources such as storage account, container registry, key vault, and application insights into the move by adding them to the ```resources``` list. The validation may take several minutes. In this command, `origin-rg` is the origin resource group, while `destination-rg` is the destination. The subscription IDs are `origin-sub-id` and `destination-sub-id`, while the workspace is `origin-workspace-name`:
+5. The following command demonstrates how to validate the move operation for workspace. You can include associated resources such as storage account, container registry, key vault, and application insights into the move by adding them to the ```resources``` list. The validation might take several minutes. In this command, `origin-rg` is the origin resource group, while `destination-rg` is the destination. The subscription IDs are `origin-sub-id` and `destination-sub-id`, while the workspace is `origin-workspace-name`:
 
     ```azurecli-interactive
     az resource invoke-action --action validateMoveResources --ids "/subscriptions/origin-sub-id/resourceGroups/origin-rg" --request-body "{  \"resources\": [\"/subscriptions/origin-sub-id/resourceGroups/origin-rg/providers/Microsoft.MachineLearningServices/workspaces/origin-workspace-name\"],\"targetResourceGroup\":\"/subscriptions/destination-sub-id/resourceGroups/destination-rg\" }"
     ```
 
 ## Move the workspace
 
-Once the validation has succeeded, move the workspace. You may also include any associated resources into move operation by adding them to the ```ids``` parameter. This operation may take several minutes.
+Once the validation has succeeded, move the workspace. You might also include any associated resources into move operation by adding them to the ```ids``` parameter. This operation might take several minutes.
 
 ```azurecli-interactive
 az resource move --destination-group destination-rg --destination-subscription-id destination-sub-id --ids "/subscriptions/origin-sub-id/resourceGroups/origin-rg/providers/Microsoft.MachineLearningServices/workspaces/origin-workspace-name"