Merge branch 'WI402856-update-file-monitoring-m365-doc' of https://github.com/DeCohen/defender-docs-pr into WI402856-update-file-monitoring-m365-doc

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/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:
 

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. 

defender-endpoint/linux-preferences.md

@@ -6,7 +6,7 @@ ms.service: defender-endpoint
 ms.author: deniseb
 author: denisebmsft
 ms.localizationpriority: medium
-ms.date: 03/05/2025
+ms.date: 03/11/2025
 manager: deniseb
 audience: ITPro
 ms.collection: 
@@ -662,6 +662,20 @@ Determines whether module load events (file open events on shared libraries) are
 |**Possible values**|disabled (default) <p> enabled|*n/a*|
 |**Comments**|Available in Defender for Endpoint version `101.68.80` or later.||
 
+#### Remediate Infected File feature
+
+Determines whether infected processes that open or load any infected file will get remediated or not.
+
+> [!NOTE]
+> When enabled the processes that open or load any infected file will be remediated in RTP mode. These processes will not appear in the threat list as these are not malicious but are only being terminated because they were loading the threat file in memory. 
+
+|Description|JSON Value|Defender Portal Value|
+|---|---|---|
+|**Key**|remediateInfectedFile|*Not available*|
+|**Data type**|String|*n/a*|
+|**Possible values**|disabled (default) <p> enabled|*n/a*|
+|**Comments**|Available in Defender for Endpoint version `101.24122.0001` or later.||
+
 #### Supplementary sensor configurations
 
 The following settings can be used to configure certain advanced supplementary sensor features.
@@ -963,7 +977,8 @@ The following configuration profile contains entries for all settings described
         "sendLowfiEvents":"disabled"
       },
       "ebpfSupplementaryEventProvider":"enabled",
-      "offlineDefinitionUpdateVerifySig": "disabled"
+      "offlineDefinitionUpdateVerifySig": "disabled",
+      "remediateInfectedFile": "enabled"
    },
    "networkProtection":{
       "enforcementLevel":"disabled",