Merge branch 'WI397895-readding-release-notes-for-february-2025' of https://github.com/DeCohen/defender-docs-pr into WI397895-readding-release-notes-for-february-2025

Author: DeCohen

ATPDocs/health-alerts.md

@@ -39,6 +39,12 @@ This section describes all the health issues for each component, listing the cau
 
 Sensor-specific health issues are displayed in the **Sensor health issues** tab and domain related or aggregated health issues are displayed in the **Global health issues** tab as detailed in the following tables:
 
+### Network configuration mismatch for sensors running on VMware
+
+|Alert|Description|Resolution|Severity|Displayed in|
+|----|----|----|----|----|
+|The virtual machines that the listed Defender for Identity sensors are installed on has a network configuration mismatch. This issue may affect the performance and reliability of the sensors.|Review the network interface settings, including disabling the Large Send Offload (LSO), and follow the instructions in [here](https://aka.ms/mdi/vmware-sensor-issue).|High|Sensors health issues tab|
+
 ### A domain controller is unreachable by a sensor
 
 |Alert|Description|Resolution|Severity|Displayed in|

ATPDocs/notifications.md

@@ -19,18 +19,19 @@ This article describes how to configure Defender for Identity notifications so t
 
 ## Configure email notifications
 
-This section describes how to configure email notifications for Defender for Identity health issues or security alerts.
+This section describes how to configure email notifications for Defender for Identity health issues.
 
 1. In [Microsoft Defender XDR](https://security.microsoft.com), select **Settings** > **Identities**. 
 
-1. Under **Notifications**, select **Health issues notifications** or **Alert notifications** as needed.
+1. Under **Notifications**, select **Health issues notifications**.
 
 1. In the **Add recipient email**, enter the email address(es) where you want to receive email notifications, and select **+ Add**.
 
-Whenever Defender for Identity detects a health issue or security alert, configured recipients receive an email notification with the details, with a link to Microsoft Defender XDR for more details.
+Whenever Defender for Identity detects a health issue, configured recipients receive an email notification with the details, with a link to Microsoft Defender XDR for more details.
 
 > [!NOTE]
-> *Alert notifications* page will be deprecated by January 15, 2025. Please use the '[Email Notifications](https://security.microsoft.com/securitysettings/defender/email_notifications)' page under Defender XDR settings for new and existing notifications rules. [Learn more](https://aka.ms/IncidentsNotificationsDefenderXdr)
+> To receive email notifications about Incidents, please use the [Email Notifications](https://security.microsoft.com/securitysettings/defender/email_notifications) page under Defender XDR Settings for new and existing notifications rules. [Learn more](https://aka.ms/IncidentsNotificationsDefenderXdr).
+
 ## Configure Syslog notifications
 
 This section describes how to configure Defender for Identity to send health issues and security events to a Syslog server through a configured sensor. 
@@ -41,13 +42,13 @@ Events aren't sent from the Defender for Identity service to your Syslog server
 
 1. In [Microsoft Defender XDR](https://security.microsoft.com), select **Settings** > **Identities**.
 
-1. Under **Notifications**, select **Syslog notifications** and then toggle on the **Syslog service** option.
+1. Under **Notifications**, select **Syslog notifications**, and then toggle on the **Syslog service** option.
 
 1. Select **Configure service** to open the **Syslog service** pane.
 
 1. Enter the following details:
 
-    - **Sensor**: Select the sensor you want to send notifications to the Syslog server
+    - **Sensor**: Select the sensor you want to send notifications to the Syslog server.
     - **Service endpoint** and **Port**: Enter the IP address or fully qualified domain name (FQDN) for the Syslog server, and then enter the port number. You can configure only one Syslog endpoint.
     - **Transport**: Select the **Transport** protocol (TCP or UDP).
     - **Format**: Select the format (RFC 3164 or RFC 5424).

ATPDocs/troubleshooting-known-issues.md

@@ -224,7 +224,7 @@ Suggested possible workarounds:
 
 ## VMware virtual machine sensor issue
 
-If you have a Defender for Identity sensor on VMware virtual machines, you might receive the health alert **Some network traffic is not being analyzed**. This can happen because of a configuration mismatch in VMware.
+If you have a Defender for Identity sensor on VMware virtual machines, you might receive one or both of the following health alerts **Some network traffic is not being analyzed** and **Network configuratuin mismatch for sensors running on VMware**. This can happen because of a configuration mismatch in VMware.
 
 To resolve the issue:
 
@@ -273,8 +273,6 @@ The domain controller hasn't been granted permission to retrieve the password of
 
 Validate that the computer running the sensor has been granted permissions to retrieve the password of the gMSA account. For more information, see [Grant permissions to retrieve the gMSA account's password](deploy/create-directory-service-account-gmsa.md#prerequisites-grant-permissions-to-retrieve-the-gmsa-accounts-password).
 
-
-
 ### Cause 2
 
 The sensor service runs as *LocalService* and performs impersonation of the Directory Service account.
@@ -446,16 +444,16 @@ Ensure that the sensor can browse to \*.atp.azure.com directly or through the co
 For more information, see [Run a silent installation with a proxy configuration](install-sensor.md#run-a-silent-installation-with-a-proxy-configuration) and [Install the Microsoft Defender for Identity sensor](deploy/install-sensor.md).
 
 > [!IMPORTANT]
-> Microsoft recommends that you use the most secure authentication flow available. The authentication flow described in this procedure requires a very high degree of trust in the application, and carries risks that are not present in other flows. You should only use this flow when other more secure flows, such as managed identities, aren't viable.
+> Microsoft recommends that you use the most secure authentication flow available. The authentication flow described in this procedure requires a very high degree of trust in the application, and carries risks that aren't present in other flows. You should only use this flow when other more secure flows, such as managed identities, aren't viable.
 >
 
-## Sensor service could not run and remains in Starting state
+## Sensor service couldn't run and remains in Starting state
 
 The following errors will appear in the **System log** in **Event viewer**:
 
 - The Open procedure for service ".NETFramework" in DLL "C:\Windows\system32\mscoree.dll" failed with error code Access is denied. Performance data for this service won't be available.
-- The Open procedure for service "Lsa" in DLL "C:\Windows\System32\Secur32.dll" failed with error code Access is denied. Performance data for this service will not be available.
-- The Open procedure for service "WmiApRpl" in DLL "C:\Windows\system32\wbem\wmiaprpl.dll" failed with error code "The device is not ready". Performance data for this service won't be available.
+- The Open procedure for service "Lsa" in DLL "C:\Windows\System32\Secur32.dll" failed with error code Access is denied. Performance data for this service won't be available.
+- The Open procedure for service "WmiApRpl" in DLL "C:\Windows\system32\wbem\wmiaprpl.dll" failed with error code "The device isn't ready". Performance data for this service won't be available.
 
 The Microsoft.TriSensorError.log will contain an error similar to this:
 

CloudAppSecurityDocs/network-requirements.md

@@ -49,8 +49,7 @@ To use Defender for Cloud Apps in the Microsoft Defender Portal:
     static2.sharepointonline.com
     *.blob.core.windows.net
     discoveryresources-cdn-prod.cloudappsecurity.com
-    discoveryresources-cdn-gov.cloudappsecurity.com
-    
+    discoveryresources-cdn-gov.cloudappsecurity.us    
     ```
 
 1. Allow the following items based on your data center:

defender-endpoint/api/isolate-machine.md

@@ -14,7 +14,7 @@ ms.topic: reference
 ms.subservice: reference
 ms.custom: api
 search.appverid: met150
-ms.date: 02/28/2025
+ms.date: 03/11/2025
 ---
 
 # Isolate machine API
@@ -36,7 +36,7 @@ Isolates a device from accessing external network.
 
 ## Limitations
 
-1. Rate limitations for this API are 100 calls per minute and 1500 calls per hour.
+1. Rate limitations for this API are 100 calls per minute and 1,500 calls per hour.
 
 [!include[Device actions note](../../includes/machineactionsnote.md)]
 
@@ -45,8 +45,7 @@ Isolates a device from accessing external network.
 > - Full isolation is available for all supported Linux devices. See [Microsoft Defender for Endpoint on Linux](/defender-endpoint/microsoft-defender-endpoint-linux).
 > - Selective isolation is available for devices on Windows 10, version 1709 or later, and on Windows 11.
 > - 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.
-> - Calling this API on unmanaged devices triggers the [contain device from the network](../respond-machine-alerts.md#contain-devices-from-the-network) action.
-
+> - Calling this API on unmanaged devices triggers the [contain device from the network](../respond-machine-alerts.md#contain-devices-from-the-network) action. The IsolationType value should be set to 'UnManagedDevice.'
 
 ## Permissions
 
@@ -59,10 +58,9 @@ Delegated (work or school account)|Machine.Isolate|'Isolate machine'
 
 > [!NOTE]
 > When obtaining a token using user credentials:
->
-> - The user needs to have at least the following role permission: 'Active remediation actions' (See [Create and manage roles](../user-roles.md) for more information)
-> - The user needs to have access to the device, based on device group settings (See [Create and manage device groups](../machine-groups.md) for more information)
->
+> - The user needs to have at least the following role permission: 'Active remediation actions.' For more information, see [Create and manage roles](../user-roles.md).
+> - The user needs to have access to the device, based on device group settings. See [Create and manage device groups](../machine-groups.md) for more information.
+> 
 > Device group creation is supported in Defender for Endpoint Plan 1 and Plan 2. 
 
 ## HTTP request
@@ -82,15 +80,16 @@ Content-Type|string|application/json. **Required**.
 
 In the request body, supply a JSON object with the following parameters:
 
-Parameter|Type|Description
-:---|:---|:---
-Comment|String|Comment to associate with the action. **Required**.
-IsolationType|String|Type of the isolation. Allowed values are: 'Full' or 'Selective'.
+|Parameter|Type|Description|
+|:---|:---|:---|
+|Comment|String|Comment to associate with the action. **Required**.|
+|IsolationType|String|Type of the isolation. Allowed values are: **Full**, **Selective**, or **UnManagedDevice**.|
 
 **IsolationType** controls the type of isolation to perform and can be one of the following:
 
-- Full: Full isolation
-- Selective: Restrict only limited set of applications from accessing the network (see [Isolate devices from the network](../respond-machine-alerts.md#isolate-devices-from-the-network) for more details)
+- Full: Full isolation. Works for managed devices.
+- Selective: Restrict only limited set of applications from accessing the network on managed devices. For more information, see [Isolate devices from the network](../respond-machine-alerts.md#isolate-devices-from-the-network).
+- UnManagedDevice: The isolation targets unmanaged devices only.
 
 ## Response
 
@@ -100,7 +99,7 @@ If successful, this method returns 201 - Created response code and [Machine Acti
 
 ### Request
 
-Here is an example of the request.
+Here's an example of the request.
 
 ```http
 POST https://api.securitycenter.microsoft.com/api/machines/1e5bc9d7e413ddd7902c2932e418702b84d0cc07/isolate

defender-endpoint/configure-endpoints-vdi.md

@@ -14,7 +14,7 @@ ms.collection:
 - tier2
 ms.custom: admindeeplinkDEFENDER
 ms.topic: conceptual
-ms.date: 03/04/2025
+ms.date: 03/11/2025
 ms.subservice: onboard
 ---
 
@@ -55,8 +55,8 @@ Defender for Endpoint supports non-persistent VDI session onboarding. There migh
 - In a VDI environment, VDI instances can have short lifespans. VDI devices can appear in the Microsoft Defender portal as either single entries for each VDI instance or multiple entries for each device. 
 
    - Single entry for each VDI instance. If the VDI instance was already onboarded to Microsoft Defender for Endpoint, and at some point deleted, and then recreated with the same host name, a new object representing this VDI instance is NOT be created in the portal. In this case, the *same* device name must be configured when the session is created, for example using an unattended answer file.
-
    - Multiple entries for each device - one for each VDI instance.
+   - For all VDI machines, when they onboard for the first time, there's a client delay of approximately 3-4 hours.
 
 > [!IMPORTANT]
 > If you're deploying non-persistent VDIs through cloning technology, make sure that your internal template VMs are not onboarded to Defender for Endpoint. This recommendation is to avoid cloned VMs from being onboarded with the same senseGuid as your template VMs, which could prevent VMs from showing up as new entries in the Devices list.