fixing links

Author: batamig

articles/sentinel/TOC.yml

@@ -1104,7 +1104,7 @@
     - name: Transition your environment to the Defender portal
       href: move-to-defender.md
     - name: Connect Microsoft Sentinel to the Defender portal
-      href: unified-secops-platform/microsoft-sentinel-onboard?toc=/azure/sentinel/TOC.json&bc=/azure/sentinel/breadcrumb/toc.json
+      href: /unified-secops-platform/microsoft-sentinel-onboard?toc=/azure/sentinel/TOC.json&bc=/azure/sentinel/breadcrumb/toc.json
   - name: Manage multiple workspaces 
     items:
     - name: Workspaces in the Defender portal 

articles/sentinel/automation/automation.md

@@ -57,7 +57,7 @@ After onboarding your Microsoft Sentinel workspace to the Defender portal, note
 | --------- | --------- |
 | **Automation rules with alert triggers** | In the Defender portal, automation rules with alert triggers act only on Microsoft Sentinel alerts. <br><br>For more information, see [Alert create trigger](../automate-incident-handling-with-automation-rules.md#alert-create-trigger). |
 | **Automation rules with incident triggers** | In both the Azure portal and the Defender portal, the **Incident provider** condition property is removed, as all incidents have *Microsoft Defender XDR* as the incident provider (the value in the *ProviderName* field). <br><br>At that point, any existing automation rules run on both Microsoft Sentinel and Microsoft Defender XDR incidents, including those where the **Incident provider** condition is set to only *Microsoft Sentinel* or *Microsoft 365 Defender*. <br><br>However, automation rules that specify a specific analytics rule name run only on incidents that contain alerts that were created by the specified analytics rule. This means that you can define the **Analytic rule name** condition property to an analytics rule that exists only in Microsoft Sentinel to limit your rule to run on incidents only in Microsoft Sentinel. <br><br>For more information, see [Incident trigger conditions](../automate-incident-handling-with-automation-rules.md#conditions). |
-|**Latency in playbook triggers** | [It might take up to 5 minutes](../microsoft-sentinel-defender-portal.md#5min) for Microsoft Defender incidents to appear in Microsoft Sentinel. If this delay is present, playbook triggering is delayed too. |
+|**Latency in playbook triggers** | [It might take up to 5 minutes](../move-to-defender.md#5min) for Microsoft Defender incidents to appear in Microsoft Sentinel. If this delay is present, playbook triggering is delayed too. |
 | **Changes to existing incident names** | The Defender portal uses a unique engine to correlate incidents and alerts. When onboarding your workspace to the Defender portal, existing incident names might be changed if the correlation is applied. To ensure that your automation rules always run correctly, we therefore recommend that you avoid using incident titles as condition criteria in your automation rules, and suggest instead to use the name of any analytics rule that created alerts included in the incident, and tags if more specificity is required. |
 | ***Updated by* field** | <li>After onboarding your workspace, the **Updated by** field has a [new set of supported values](../automate-incident-handling-with-automation-rules.md#incident-update-trigger), which no longer include *Microsoft 365 Defender*. In existing automation rules, *Microsoft 365 Defender* is replaced by a value of *Other* after onboarding your workspace. <br><br><li>If multiple changes are made to the same incident in a 5-10 minute period, a single update is sent to Microsoft Sentinel, with only the most recent change. <br><br>For more information, see [Incident update trigger](../automate-incident-handling-with-automation-rules.md#incident-update-trigger). |
 | **Automation rules that add incident tasks** | If an automation rule adds an incident task, the task is shown only in the Azure portal. |
@@ -67,7 +67,7 @@ After onboarding your Microsoft Sentinel workspace to the Defender portal, note
 | **Active playbooks tab** | After onboarding to the Defender portal, by default the **Active playbooks** tab shows a predefined filter with onboarded workspace's subscription. In the Azure portal, add data for other subscriptions using the subscription filter.  <br><br>For more information, see [Create and customize Microsoft Sentinel playbooks from content templates](use-playbook-templates.md). |
 | **Running playbooks manually on demand** | The following procedures aren't currently supported in the Defender portal:  <br><li>[Run a playbook manually on an alert](run-playbooks.md#run-a-playbook-manually-on-an-alert)<br><li>[Run a playbook manually on an entity](run-playbooks.md#run-a-playbook-manually-on-an-entity)    |
 | **Running playbooks on incidents requires Microsoft Sentinel sync** | If you try to run a playbook on an incident from the Defender portal and see the message *"Can't access data related to this action. Refresh the screen in a few minutes."* message, this means that the incident isn't yet synchronized to Microsoft Sentinel. <br><br>Refresh the incident page after the incident is synchronized to run the playbook successfully. |
-| **Incidents: Adding alerts to incidents / <br>Removing alerts from incidents** | Since adding alerts to, or removing alerts from incidents isn't supported after onboarding your workspace to the Defender portal, these actions are also not supported from within playbooks. For more information, see [Capability differences between portals](../microsoft-sentinel-defender-portal.md#capability-differences-between-portals). |
+| **Incidents: Adding alerts to incidents / <br>Removing alerts from incidents** | Since adding alerts to, or removing alerts from incidents isn't supported after onboarding your workspace to the Defender portal, these actions are also not supported from within playbooks. For more information, see [Understand how alerts are correlated and incidents are merged in the Defender portal](../move-to-defender.md#understand-how-alerts-are-correlated-and-incidents-are-merged-in-the-defender-portal). |
 
 ## Related content
 

articles/sentinel/move-to-defender.md

@@ -40,7 +40,7 @@ Review all planning guidance and finish all prerequisites before you start onboa
 - [Deploy unified security operations in the Defender portal](/unified-secops-platform/overview-deploy). While this article is for new customers who don't yet have a workspace for Microsoft Sentinel or other services onboarded to the Defender portal, use it as a reference if you're moving to the Defender portal.
 - [Connect Microsoft Sentinel to the Defender portal](/unified-secops-platform/microsoft-sentinel-onboard). This article lists the prerequisites for onboarding your workspace to the Defender portal. If you plan to use Microsoft Sentinel without Defender XDR, you need to take an extra step to trigger the connection between Microsoft Sentinel and the Defender portal.
 
-Defender supports one or more workspaces across multiple tenants through the [multitenant portal](mto.security.microsoft.com), which serves as a central place to manage incidents and alerts, hunt for threats across tenants, and lets Managed Security Service Partners (MSSPs) see across customers.
+Defender supports one or more workspaces across multiple tenants through the [multitenant portal](https://mto.security.microsoft.com), which serves as a central place to manage incidents and alerts, hunt for threats across tenants, and lets Managed Security Service Partners (MSSPs) see across customers.
 
 In multi-workspace scenarios, the multitenant portal lets you connect one primary workspace and multiple secondary workspaces per tenant. Onboard each workspace to the Defender portal separately for each tenant, just like onboarding for a single tenant.
 
@@ -173,7 +173,7 @@ tasks - still true?-->
 |**Delay just after onboarding your workspace**  <a name="5min"></a>   | It may take up to 5 minutes for Microsoft Defender incidents to fully integrate with Microsoft Sentinel. This doesn't affect features provided directly by Microsoft Defender, such as automatic attack disruption.        |
 |**Security incident creation rules**     | Any active [Microsoft security incident creation rules](create-incidents-from-alerts.md) are deactivated to avoid creating duplicate incidents. The incident creation settings in other types of analytics rules remain as they were, and are configurable in the Defender portal.   |
 |**Incident provider name**     | In the Defender portal, the **Incident provider name** is always Microsoft Defender XDR.        |
-|**Adding / removing alerts from incidents**     | You can no longer add alerts to or remove alerts from incidents in the Azure portal. Removing alerts from incidents in the Defender portal is only supported by linking the alert to another incident, either existing or new.        |
+|**Adding / removing alerts from incidents**     | Adding or removing Microsoft Sentinel alerts to or from incidents is supported only in the Defender portal. To remove an alert from an incident in the Defender portal, you must [add the alert to another incident](/defender-xdr/move-alert-to-another-incident).        |
 |**Editing comments**     |  Add comments to incidents in either the Defender or Azure portal, but editing existing comments isn't supported in the Defender portal. Edits made to comments in the Azure portal aren't synchronized to the Defender portal.       |
 |**Programmatic and manual creation of incidents**     |    Incidents created in Microsoft Sentinel through the API, by a Logic App playbook, or manually from the Azure portal, aren't synchronized to the Defender portal. These incidents are still supported in the Azure portal and the API. See [Create your own incidents manually in Microsoft Sentinel](create-incident-manually.md).     |
 | **Reopening closed incidents** | In the Defender portal, you can't set alert grouping in Microsoft Sentinel analytics rules to reopen closed incidents if new alerts are added. <br>Closed incidents aren't reopened in this case, and new alerts trigger new incidents.|

articles/sentinel/relate-alerts-to-incidents.md

@@ -28,13 +28,13 @@ You can also use this automation to add alerts to [manually created incidents](c
 
 ### Limitations
 
-- Microsoft Sentinel imports both alerts and incidents from Microsoft Defender XDR. For the most part, you can treat these alerts and incidents like regular Microsoft Sentinel alerts and incidents. 
+- **After onboarding Microsoft Sentinel to the Defender portal**, adding or removing Microsoft Sentinel alerts to or from incidents is supported only in the Defender portal. To remove an alert from an incident in the Defender portal, you must [add the alert to another incident](/defender-xdr/move-alert-to-another-incident). For more information, see [Understand how alerts are correlated and incidents are merged in the Defender portal](move-to-defender.md#understand-how-alerts-are-correlated-and-incidents-are-merged-in-the-defender-portal).
 
-    However, you can only add Defender alerts to Defender incidents (or remove them) in the Defender portal, not in the Sentinel portal. If you try doing this in Microsoft Sentinel, you will get an error message. You can pivot to the incident in the Microsoft Defender Portal using the link in the Microsoft Sentinel incident. Don't worry, though - any changes you make to the incident in the Microsoft Defender Portal are [synchronized](microsoft-365-defender-sentinel-integration.md#working-with-microsoft-defender-xdr-incidents-in-microsoft-sentinel-and-bi-directional-sync) with the parallel incident in Microsoft Sentinel, so you'll still see the added alerts in the incident in the Sentinel portal.
+- **When working in the Azure portal, in a workspace not onboarded to the Defender portal**, Microsoft Sentinel imports both alerts and incidents from Microsoft Defender XDR. For the most part, you can treat these alerts and incidents like regular Microsoft Sentinel alerts and incidents.
 
-    You *can* add Microsoft Defender XDR alerts to non-Defender incidents, and non-Defender alerts to Defender incidents, in the Microsoft Sentinel portal.
+    For example, you can add or remove Microsoft Defender XDR alerts to or from non-Defender incidents, and add or remove non-Defender alerts to Defender incidents, directly from Microsoft Sentinel in the Azure portal. 
 
-- If you onboarded Microsoft Sentinel to the unified security operations portal, you can no longer add Microsoft Sentinel alerts to incidents, or remove Microsoft Sentinel alerts from incidents, in Microsoft Sentinel (in the Azure portal). You can do this only in the Microsoft Defender portal. For more information, see [Capability differences between portals](microsoft-sentinel-defender-portal.md#capability-differences-between-portals).
+    However, you can only manage Defender alerts with Defender incidents in the Defender portal. From the Azure portal, pivot to the incident in the Defender portal using the link in the incident. Changes made in the Defender portal are [synchronized](microsoft-365-defender-sentinel-integration.md#working-with-microsoft-defender-xdr-incidents-in-microsoft-sentinel-and-bi-directional-sync) to the Azure portal, so you'll still see the change reflected in both portals.
 
 - An incident can contain a maximum of 150 alerts. If you try to add an alert to an incident with 150 alerts in it, you will get an error message.