Merge branch 'main' into docs-editor/mde-plugin-wsl-1751324403

Author: denisebmsft

defender-endpoint/isolation-exclusions.md

@@ -14,7 +14,7 @@ ms.collection:
 ms.topic: how-to
 ms.subservice: edr
 search.appverid: met150
-ms.date: 06/22/2025
+ms.date: 07/01/2025
 ---
 
 # Isolation exclusions (preview)
@@ -57,7 +57,7 @@ There are two steps to using isolation exclusion: defining isolation exclusion r
 
 ### Prerequisites
 
-* Isolation exclusion is available on Windows (minimum client version 10.8470) and macOS (minimum client version 101.240902).
+* Isolation exclusion is available on Windows 11, Windows 10 version 1703 or later, Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, and macOS.
 * Isolation exclusion must be enabled. Enabling isolation exclusion requires Security Admin or Manage Security settings permissions or above. To enable isolation exclusion, sign in to the [Microsoft Defender portal](https://security.microsoft.com) and go to **Settings** > **Endpoints** > **Advanced features** and enable **Isolation Exclusion Rules** feature.
 
    :::image type="content" source="./media/isolation-exclusions/enable-exclusions.png" alt-text="Screenshot showing how to enable isolation exclusions." lightbox="./media/isolation-exclusions/enable-exclusions.png":::

defender-endpoint/media/isolation-exclusions/add-new-exclusion-rule.png

@@ -5,7 +5,7 @@ ms.service: defender-endpoint
 ms.author: diannegali
 author: diannegali
 ms.localizationpriority: medium
-ms.date: 04/09/2025
+ms.date: 07/01/2025
 manager: deniseb
 audience: ITPro
 ms.collection:
@@ -216,7 +216,7 @@ Depending on the severity of the attack and the sensitivity of the device, you m
    - `iptables`
    - `ip6tables`
    - Linux kernel with `CONFIG_NETFILTER`, `CONFID_IP_NF_IPTABLES`, and `CONFIG_IP_NF_MATCH_OWNER`
-- Selective isolation is available for devices running Windows 10, version 1709 or later, and Windows 11. For more information about selective isolation, see [Isolation exclusions](./isolation-exclusions.md).
+- Selective isolation is available for devices running on Windows 11, Windows 10 version 1703 or later, Windows Server 2025, Windows Server 2022, Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, and macOS. For more information about selective isolation, see [Isolation exclusions](./isolation-exclusions.md).
 - When isolating a device, only certain processes and destinations are allowed. Therefore, devices that are behind a full VPN tunnel won't be able to reach the Microsoft Defender for Endpoint cloud service after the device is isolated. We recommend using a split-tunneling VPN for Microsoft Defender for Endpoint and Microsoft Defender Antivirus cloud-based protection-related traffic.
 - The feature supports VPN connection.
 - You must have at least the `Active remediation actions` role assigned. For more information, see [Create and manage roles](user-roles.md).

defender-endpoint/media/isolation-exclusions/apply-exclusion-rule.png

@@ -94,6 +94,9 @@
           href: investigate-incidents.md
         - name: Move alerts to another incident
           href: move-alert-to-another-incident.md
+        - name: Merge incidents manually
+          href: merge-incidents-manually.md
+        - name: Alerts
         - name: Investigate alerts
           href: investigate-alerts.md
         - name: Investigate entity pages

defender-endpoint/respond-machine-alerts.md

@@ -37,19 +37,19 @@ When alerts are generated by the various detection mechanisms in the Microsoft D
 
 The criteria used by the Defender portal to correlate alerts together in a single incident are part of its proprietary, internal correlation logic. This logic is also responsible for giving an appropriate name to the new incident.
 
-### Alert correlation by workspace
+### Alert correlation by Microsoft Sentinel workspace
 
-The Defender portal allows you to connect to one primary workspace and multiple secondary workspaces for Microsoft Sentinel. A primary workspace's alerts are correlated with Microsoft Defender XDR data. So, incidents include alerts from Microsoft Sentinel's primary workspace and Defender XDR in a unified queue. All other onboarded workspaces are considered secondary workspaces. For secondary workspaces, incidents are created based on the workspace’s data and won't include Defender XDR data. The Defender portal keeps incident creation and alert correlation separate between the Microsoft Sentinel workspaces. For more information, see [Multiple Microsoft Sentinel workspaces in the Defender portal](https://go.microsoft.com/fwlink/p/?linkid=2310579).
+When the Defender portal is configured to include Microsoft Sentinel as a data source, each Microsoft Sentinel workspace is considered its own separate data source. If you have multiple workspaces for Microsoft Sentinel, the Defender portal allows you to configure one of those workspaces as the *primary workspace*. The alerts that come from the primary workspace can be correlated with Microsoft Defender XDR alerts, and they can be included together in incidents. <!-- XDR data? Or data from any other sources in the portal? In other words, are Sentinel alerts from secondary workspaces ON AN ISLAND? They can be correlated amongst themselves, right? --> Any other onboarded Microsoft Sentinel workspaces are considered *secondary workspaces*. Alerts from these secondary workspaces are *not* correlated with alerts from Defender XDR or any other Defender portal data sources, including other Microsoft Sentinel workspaces. The Defender portal keeps incident creation and alert correlation separate between the Microsoft Sentinel workspaces. For more information, see [Multiple Microsoft Sentinel workspaces in the Defender portal](/azure/sentinel/workspaces-defender-portal).
 
 ### Manual correlation of alerts
 
-While Microsoft Defender already uses advanced correlation mechanisms, you might want to decide differently whether a given alert belongs with a particular incident or not. In such a case, you can unlink an alert from one incident and link it to another. Every alert must belong to an incident, so you can either link the alert to another existing incident, or to a new incident that you create on the spot.
+While Microsoft Defender already uses advanced correlation mechanisms, you might want to decide differently whether a given alert belongs with a particular incident. In such a case, you can unlink an alert from one incident and link it to another. Every alert must belong to an incident, so you can either link the alert to another existing incident, or to a new incident that you create on the spot.
 
 For more information on moving an alert from one incident to another, see [Move alerts from one incident to another in the Microsoft Defender portal](move-alert-to-another-incident.md).
 
 ## Incident correlation and merging
 
-The Defender portal's correlation activities don't stop when incidents are created. Defender continues to detect commonalities and relationships between incidents and alerts across incidents. When two or more incidents are determined to be sufficiently alike, Defender merges the incidents into a single incident.
+The Defender portal's correlation activities don't stop when incidents are created. Defender continues to detect commonalities and relationships between incidents and alerts across incidents. When multiple incidents are determined to be sufficiently alike, Defender merges the incidents into a single incident.
 
 ### Criteria for merging incidents
 
@@ -66,7 +66,7 @@ When two or more incidents are merged, a new incident is *not* created to absorb
 
 #### Merge direction
 
-The direction of the incident merge refers to which incident is the source and which is the target. This direction is determined by Microsoft Defender, based on its own internal logic, with the goal of maximizing information retention and access. The user doesn't have any input into this decision.
+The direction of the incident merge refers to which incident is the source and which is the target. This direction is determined by Microsoft Defender, based on its own internal logic, with the goal of maximizing information retention and access. The user doesn't have any input into this decision, even when merging incidents manually.
 
 #### Incident contents
 
@@ -77,20 +77,32 @@ The contents of the incidents are handled in the following ways:
 - A **`Redirected`** tag is added to the source incident.
 - Entities (assets etc.) follow the alerts they're linked to.
 - Analytics rules recorded as involved in the creation of the source incident are added to the rules recorded in the target incident.
-- Currently, comments and activity log entries in the source incident are *not* moved to the target incident.
-
-To see the source incident's comments and activity history, open the incident in Microsoft Sentinel in the Azure portal. The activity history includes the closing of the incident and the adding and removal of alerts, tags, and other items related to the incident merge. These activities are attributed to the identity *Microsoft Defender XDR - alert correlation*.
+- Currently, comments and activity log entries in the source incident are *not* moved to the target incident.<br>To see the source incident's comments and activity history, open the incident in Microsoft Sentinel in the Azure portal. The activity history includes the closing of the incident and the adding and removal of alerts, tags, and other items related to the incident merge. These activities are attributed to the identity *Microsoft Defender XDR - alert correlation*.
 
 ### When incidents aren't merged
 
 Even when the correlation logic indicates that two incidents should be merged, Defender doesn't merge the incidents under the following circumstances:
 
 - One of the incidents has a status of "Closed". Incidents that are resolved don't get reopened.
 - The source and target incidents are assigned to two different people.
-- The source and target incidents have two different classifications (for example, true positive and false positive).
+- The source and target incidents have two different classifications (for example, true positive and false positive) or two different determinations (the subcategories of classifications).
 - Merging the two incidents would raise the number of entities in the target incident above the allowed maximum.
 - The two incidents contain devices in different [device groups](/defender-endpoint/machine-groups) as defined by the organization. <br>(This condition is not in effect by default; it must be enabled.)
 
+### Manual merging of incidents (Preview)
+
+If two incidents should be merged, but aren't merged for any of the reasons listed in the [previous section](#when-incidents-arent-merged), you can now merge the incidents manually after you fix the underlying reasons.
+
+For example, if the incidents weren't merged because they were assigned to two different people, you can remove the assignment of one of the incidents and then merge the incidents manually.
+
+Merging incidents together is preferable to unlinking alerts from one incident and linking them to another, because all the incident information (for example, the activity log) is preserved.
+
+Currently, five incidents at a time can be merged manually.
+
+Other rules governing manual merging are the same as automatic merging. See [Details of the merge process](#details-of-the-merge-process) above.
+
+For instructions and more information on how to merge incidents manually, see [Merge incidents manually in the Microsoft Defender portal](merge-incidents-manually.md).
+
 ## Next steps
 
 To learn more about prioritizing and managing incidents, see the following articles: