Merge branch 'main' of https://github.com/MicrosoftDocs/azure-docs-pr into rolyon-mto-configuration-delete-steps

Author: rolyon

articles/active-directory/fundamentals/1-secure-access-posture.md

@@ -1,94 +1,98 @@
 ---
-title: Determine your security posture for external collaboration with Azure Active Directory 
-description: Before you can execute an external access security plan, you must determine what you are trying to achieve.
+title: Determine your security posture for external access with Azure Active Directory 
+description: Learn about governance of external access and assessing collaboration needs, by scenario
 services: active-directory
-author: janicericketts
+author: jricketts
 manager: martinco
 ms.service: active-directory
 ms.workload: identity
 ms.subservice: fundamentals
 ms.topic: conceptual
-ms.date: 08/19/2022
+ms.date: 02/03/2023
 ms.author: jricketts
 ms.reviewer: ajburnle
 ms.custom: "it-pro, seodec18"
 ms.collection: M365-identity-device-management
 ---
 
-# Determine your security posture for external access 
+# Determine your security posture for external access with Azure Active Directory 
 
-As you consider governing external access, you’ll need to assess the security and collaboration needs for your organization overall, and within each scenario. At the organizational level, consider the amount of control you need your IT team to have over day-to-day collaboration. Organizations in regulated industries may require more IT control. For example, a defense contractor may be required to positively identify and document each external user, their access, and the removal of access. This requirement may be on all access, or on specific scenarios or workloads. On the other end of the spectrum, a consulting firm may generally allow end users to determine the external users they need to collaborate with, within certain IT guard rails. 
+As you consider the governance of external access, assess your organization's security and collaboration needs, by scenario. You can start with the level of control the IT team has over the day-to-day collaboration of end users. Organizations in highly regulated industries might require more IT team control. For example, defense contractors can have a requirement to positively identify and document external users, their access, and access removal: all access, scenario-based, or workloads. Consulting agencies can use certain features to allow end users to determine the external users they collaborate with. 
 
-![IT versus end-user control of collaboration](media/secure-external-access/1-overall-control.png)
+  ![Bar graph of the span from full IT team control, to end-user self service.](media/secure-external-access/1-overall-control.png)
 
-> [!NOTE]
-> Overly tight control on collaboration can lead to higher IT budgets, reduced productivity, and delayed business outcomes. When official collaboration channels are perceived as too onerous, end users tend to go around IT provided systems to get their jobs done, by for example emailing unsecured documents.
-
-## Think in terms of scenarios
+   > [!NOTE]
+   > A high degree of control over collaboration can lead to higher IT budgets, reduced productivity, and delayed business outcomes. When official collaboration channels are perceived as onerous, end users tend to evade official channels. An example is end users sending unsecured documents by email.
 
-In many cases IT can delegate partner access, at least in some scenarios, while providing guard rails for security. The IT guard rails can be help ensure that intellectual property stays secure, while empowering employees to collaborate with partners to get work done.
+## Scenario-based planning
 
-As you consider the scenarios within your organization, assess the need for employee versus business partner access to resources. A bank may have compliance needs that restrict access to certain resources, like user account information, to a small group of internal employees. Conversely, the same bank may enable delegated access for partners working on a marketing campaign.
+IT teams can delegate partner access to empower employees to collaborate with partners. This delegation can occur while maintaining sufficient security to protect intellectual property.
 
-![continuum of governance per scenario](media\secure-external-access\1-scenarios.png)
+Compile and assess your organizations scenarios to help assess employee versus business partner access to resources. Financial institutions might have compliance standards that restrict employee access to resources such as account information. Conversely, the same institutions can enable delegated partner access for projects such as marketing campaigns.
 
-In each scenario, consider 
+   ![Diagram of a balance of IT team goverened access to partner self-service.](media/secure-external-access/1-scenarios.png)
 
-* the sensitivity of the information at risk
+### Scenario considerations
 
-* whether you need to restrict what partners can see about other users
+Use the following list to help measure the level of access control.
 
-* the cost of a breach vs the weight of centralized control and end-user friction
+* Information sensitivity, and associated risk of its exposure
+* Partner access to information about other end users
+* The cost of a breach versus the overhead of centralized control and end-user friction
 
- You may also start with centrally managed controls to meet compliance targets and delegate control to end users over time. All access management models may simultaneously coexist within an organization. 
+Organizations can start with highly managed controls to meet compliance targets, and then delegate some control to end users, over time. There can be simultaneous access-management models in an organization. 
 
-The use of [partner managed credentials](../external-identities/what-is-b2b.md) provides your organization with an essential signal that terminates access to your resources once the external user has lost access to the resources of their own company.
+> [!NOTE]
+> Partner-managed credentials are a method to signal the termination of access to resources, when an external user loses access to resources in their own company. Learn more: [B2B collaboration overview](../external-identities/what-is-b2b.md)
 
-## Goals of securing external access
+## External-access security goals
 
-The goals of IT-governed and delegated access differ.
+The goals of IT-governed and delegated access differ. The primary goals of IT-governed access are:
 
-**The primary goals of IT-governed access are to:**
+* Meet governance, regulatory, and compliance (GRC) targets
+* High level of control over partner access to information about end users, groups, and other partners
 
-* Meet governance, regulatory, and compliance (GRC) targets. 
+The primary goals of delegating access are:
 
-* Tightly control partner access and what partners can see about member users, groups, and other partners.
+* Enable business owners to determine collaboration partners, with security constraints
+* Enable partners to request access, based on rules defined by business owners
 
-**The primary goals of delegating access are to:**
+### Common goals 
 
-* Enable business owners to govern who they collaborate with, within IT constraints.
+#### Control access to applications, data, and content
 
-* Enable business partners to request access based on rules defined by business owners.
+Levels of control can be accomplished through various methods, depending on your version of Azure AD and Microsoft 365.
 
-Whichever you enact for your organization and scenarios you'll need to: 
+* [Azure AD plans and pricing](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing)
+* [Microsoft 365](https://www.microsoft.com/microsoft-365/compare-microsoft-365-enterprise-plans). 
 
-* **Control access to applications, data, and content**. This can be accomplished through a variety of methods, depending on your versions of [Azure AD](https://www.microsoft.com/security/business/identity-access-management/azure-ad-pricing) and [Microsoft 365](https://www.microsoft.com/microsoft-365/compare-microsoft-365-enterprise-plans). 
+#### Reduce attack surface
 
-* **Reduce the attack surface**. [Privileged identity management](../privileged-identity-management/pim-configure.md), [data loss prevention (DLP),](/exchange/security-and-compliance/data-loss-prevention/data-loss-prevention) and [encryption capabilities](/exchange/security-and-compliance/data-loss-prevention/data-loss-prevention) reduce the attack surface.
+* [What is Azure AD Privileged Identity Management?](../privileged-identity-management/pim-configure.md) -  manage, control, and monitor access to resources in Azure AD, Azure, and other Microsoft Online Services such as Microsoft 365 or Microsoft Intune
+* [Data loss prevention in Exchange Server](/exchange/policy-and-compliance/data-loss-prevention/data-loss-prevention?view=exchserver-2019&preserve-view=true)
 
-* **Regularly review activity and audit log to confirm compliance**. IT can delegate access decisions to business owners through entitlement management while access reviews provide a way to periodically confirm continued access. Automated data classification with sensitivity labels helps to automate encryption of sensitive content making it easy for employee end users to comply.
+#### Confirm compliance with activity and audit log reviews
 
-## Next steps 
+IT teams can delegate access decisions to business owners through entitlement management, while access reviews help confirm continued access. You can use automated data classification with sensitivity labels to automate the encryption of sensitive content, easing compliance for end users.
 
-See the following articles on securing external access to resources. We recommend you take the actions in the listed order.
+## Next steps
 
-1. [Determine your security posture for external access](1-secure-access-posture.md) (You are here.)
+See the following articles to learn more about securing external access to resources. We recommend you follow the listed order.
 
-2. [Discover your current state](2-secure-access-current-state.md)
+1. [Determine your security posture for external access with Azure AD](1-secure-access-posture.md) (You're here)
 
-3. [Create a governance plan](3-secure-access-plan.md)
+2. [Discover the current state of external collaboration in your organization](2-secure-access-current-state.md)
 
-4. [Use groups for security](4-secure-access-groups.md)
+3. [Create a security plan for external access](3-secure-access-plan.md)
 
-5. [Transition to Azure AD B2B](5-secure-access-b2b.md)
+4. [Secure external access with groups in Azure AD and Microsoft 365](4-secure-access-groups.md)
 
-6. [Secure access with Entitlement Management](6-secure-access-entitlement-managment.md)
+5. [Transition to governed collaboration with Azure AD B2B collaboration](5-secure-access-b2b.md)
 
-7. [Secure access with Conditional Access policies](7-secure-access-conditional-access.md)
+6. [Manage external access with Azure AD entitlement management](6-secure-access-entitlement-managment.md)
 
-8. [Secure access with Sensitivity labels](8-secure-access-sensitivity-labels.md)
+7. [Manage external access with Conditional Access policies](7-secure-access-conditional-access.md)
 
-9. [Secure access to Microsoft Teams, OneDrive, and SharePoint](9-secure-access-teams-sharepoint.md)
- 
+8. [Control external access to resources in Azure AD with sensitivity labels](8-secure-access-sensitivity-labels.md) 
 
-​
+9. [Secure external access to Microsoft Teams, SharePoint, and OneDrive with Azure AD](9-secure-access-teams-sharepoint.md)

articles/machine-learning/concept-azure-machine-learning-v2.md

@@ -278,5 +278,5 @@ An Azure Machine Learning [component](concept-component.md) is a self-contained
 
 ## Next steps
 
-* [How to migrate from v1 to v2](how-to-migrate-from-v1.md)
+* [How to upgrade from v1 to v2](how-to-migrate-from-v1.md)
 * [Train models with the v2 CLI and SDK](how-to-train-model.md)

articles/machine-learning/concept-v2.md

@@ -112,7 +112,7 @@ The Azure Machine Learning Python SDK v1 doesn't have a planned deprecation date
 
 ## Next steps
 
-* [How to migrate from v1 to v2](how-to-migrate-from-v1.md)
+* [How to upgrade from v1 to v2](how-to-migrate-from-v1.md)
 * Get started with CLI v2
 
     * [Install and set up CLI (v2)](how-to-configure-cli.md)

articles/machine-learning/how-to-migrate-from-v1.md

@@ -1,7 +1,7 @@
 ---
-title: 'Migrate from v1 to v2'
+title: 'Upgrade from v1 to v2'
 titleSuffix: Azure Machine Learning
-description: Migrate from v1 to v2 of Azure Machine Learning REST APIs, CLI extension, and Python SDK.
+description: Upgrade from v1 to v2 of Azure Machine Learning REST APIs, CLI extension, and Python SDK.
 services: machine-learning
 ms.service: machine-learning
 ms.subservice: core
@@ -77,9 +77,9 @@ This section gives an overview of specific resources and assets in Azure ML. See
 
 ### Workspace
 
-Workspaces don't need to be migrated with v2. You can use the same workspace, regardless of whether you're using v1 or v2. 
+Workspaces don't need to be upgraded with v2. You can use the same workspace, regardless of whether you're using v1 or v2. 
 
-If you create workspaces using automation, do consider migrating the code for creating a workspace to v2. Typically Azure resources are managed via Azure Resource Manager (and Bicep) or similar resource provisioning tools. Alternatively, you can use the [CLI (v2) and YAML files](how-to-manage-workspace-cli.md#create-a-workspace).
+If you create workspaces using automation, do consider upgrading the code for creating a workspace to v2. Typically Azure resources are managed via Azure Resource Manager (and Bicep) or similar resource provisioning tools. Alternatively, you can use the [CLI (v2) and YAML files](how-to-manage-workspace-cli.md#create-a-workspace).
 
 For a comparison of SDK v1 and v2 code, see [Workspace management in SDK v1 and SDK v2](migrate-to-v2-resource-workspace.md).
 
@@ -107,9 +107,9 @@ For a comparison of SDK v1 and v2 code, see [Compute management in SDK v1 and SD
 
 ### Endpoint and deployment (endpoint and web service in v1)
 
-With SDK/CLI v1, you can deploy models on ACI or AKS as web services. Your existing v1 model deployments and web services will continue to function as they are, but Using SDK/CLI v1 to deploy models on ACI or AKS as web services is now consiered as **legacy**. For new model deployments, we recommend migrating to v2. In v2, we offer [managed endpoints or Kubernetes endpoints](./concept-endpoints.md). The following table guides our recommendation:
+With SDK/CLI v1, you can deploy models on ACI or AKS as web services. Your existing v1 model deployments and web services will continue to function as they are, but Using SDK/CLI v1 to deploy models on ACI or AKS as web services is now consiered as **legacy**. For new model deployments, we recommend upgrading to v2. In v2, we offer [managed endpoints or Kubernetes endpoints](./concept-endpoints.md). The following table guides our recommendation:
 
-|Endpoint type in v2|Migrate from|Notes|
+|Endpoint type in v2|Upgrade from|Notes|
 |-|-|-|
 |Local|ACI|Quick test of model deployment locally; not for production.|
 |Managed online endpoint|ACI, AKS|Enterprise-grade managed model deployment infrastructure with near real-time responses and massive scaling for production.|
@@ -118,7 +118,7 @@ With SDK/CLI v1, you can deploy models on ACI or AKS as web services. Your exist
 |Azure Arc Kubernetes|N/A|Manage your own Kubernetes cluster(s) in other clouds or on-premises, giving flexibility and granular control at the cost of IT overhead.|
 
 For a comparison of SDK v1 and v2 code, see [Upgrade deployment endpoints to SDK v2](migrate-to-v2-deploy-endpoints.md).
-For upgrade steps from your existing ACI web services to managed online endpoints, see our [upgrade guide article](migrate-to-v2-managed-online-endpoints.md) and [blog](https://aka.ms/acimoemigration).
+For migration steps from your existing ACI web services to managed online endpoints, see our [upgrade guide article](migrate-to-v2-managed-online-endpoints.md) and [blog](https://aka.ms/acimoemigration).
 
 ### Jobs (experiments, runs, pipelines in v1)
 
@@ -171,7 +171,7 @@ For details about Key Vault, see [Use authentication credential secrets in Azure
 
 ## Scenarios across the machine learning lifecycle
 
-There are a few scenarios that are common across the machine learning lifecycle using Azure ML. We'll look at a few and give general recommendations for migrating to v2.
+There are a few scenarios that are common across the machine learning lifecycle using Azure ML. We'll look at a few and give general recommendations for upgrading to v2.
 
 ### Azure setup
 
@@ -203,7 +203,7 @@ The solution accelerator for MLOps with v2 is being developed at https://github.
 
 ### A note on GitOps with v2
 
-A key paradigm with v2 is serializing machine learning entities as YAML files for source control with `git`, enabling better GitOps approaches than were possible with v1. For instance, you could enforce policy by which only a service principal used in CI/CD pipelines can create/update/delete some or all entities, ensuring changes go through a governed process like pull requests with required reviewers. Since the files in source control are YAML, they're easy to diff and track changes over time. You and your team may consider shifting to this paradigm as you migrate to v2.
+A key paradigm with v2 is serializing machine learning entities as YAML files for source control with `git`, enabling better GitOps approaches than were possible with v1. For instance, you could enforce policy by which only a service principal used in CI/CD pipelines can create/update/delete some or all entities, ensuring changes go through a governed process like pull requests with required reviewers. Since the files in source control are YAML, they're easy to diff and track changes over time. You and your team may consider shifting to this paradigm as you upgrade to v2.
 
 You can obtain a YAML representation of any entity with the CLI via `az ml <entity> show --output yaml`. Note that this output will have system-generated properties, which can be ignored or deleted.
 

articles/machine-learning/migrate-to-v2-command-job.md

@@ -19,7 +19,7 @@ In SDK v2, "experiments" and "runs" are consolidated into jobs.
 
 A job has a type. Most jobs are command jobs that run a `command`, like `python main.py`. What runs in a job is agnostic to any programming language, so you can run `bash` scripts, invoke `python` interpreters, run a bunch of `curl` commands, or anything else.
 
-To upgrade, you'll need to change your code for submitting jobs to SDK v2. What you run _within_ the job doesn't need to be migrated to SDK v2. However, it's recommended to remove any code specific to Azure ML from your model training scripts. This separation allows for an easier transition between local and cloud and is considered best practice for mature MLOps. In practice, this means removing `azureml.*` lines of code. Model logging and tracking code should be replaced with MLflow. For more details, see [how to use MLflow in v2](how-to-use-mlflow-cli-runs.md).
+To upgrade, you'll need to change your code for submitting jobs to SDK v2. What you run _within_ the job doesn't need to be upgraded to SDK v2. However, it's recommended to remove any code specific to Azure ML from your model training scripts. This separation allows for an easier transition between local and cloud and is considered best practice for mature MLOps. In practice, this means removing `azureml.*` lines of code. Model logging and tracking code should be replaced with MLflow. For more details, see [how to use MLflow in v2](how-to-use-mlflow-cli-runs.md).
 
 This article gives a comparison of scenario(s) in SDK v1 and SDK v2.
 

articles/machine-learning/migrate-to-v2-execution-automl.md

@@ -1,7 +1,7 @@
 ---
 title: Upgrade AutoML to SDK v2
 titleSuffix: Azure Machine Learning
-description: Migrate AutoML from v1 to v2 of Azure Machine Learning SDK
+description: Upgrade AutoML from v1 to v2 of Azure Machine Learning SDK
 services: machine-learning
 ms.service: machine-learning
 ms.subservice: core