From 11fc8be1532cebabf34f4a2ce1d5b24acb523024 Mon Sep 17 00:00:00 2001 From: natasha-moore-elastic <137783811+natasha-moore-elastic@users.noreply.github.com> Date: Mon, 6 Jan 2025 14:44:56 +0000 Subject: [PATCH 1/2] Document how to troubleshoot Defend's self-healing feature on Windows (#6361) * Document how to troubleshoot Defend self-healing * Adds serverless docs * Adds compatibility issues * Apply suggestions from code review Co-authored-by: Nastasha Solomon <79124755+nastasha-solomon@users.noreply.github.com> --------- Co-authored-by: Nastasha Solomon <79124755+nastasha-solomon@users.noreply.github.com> (cherry picked from commit c4db057f3b8be86decc090be7ff732aaeeac26e6) # Conflicts: # docs/serverless/troubleshooting/troubleshoot-endpoints.asciidoc --- .../troubleshoot-endpoints.asciidoc | 252 ++++++++++++++++++ docs/troubleshooting/ts-management.asciidoc | 28 ++ 2 files changed, 280 insertions(+) create mode 100644 docs/serverless/troubleshooting/troubleshoot-endpoints.asciidoc diff --git a/docs/serverless/troubleshooting/troubleshoot-endpoints.asciidoc b/docs/serverless/troubleshooting/troubleshoot-endpoints.asciidoc new file mode 100644 index 0000000000..707ea7edfb --- /dev/null +++ b/docs/serverless/troubleshooting/troubleshoot-endpoints.asciidoc @@ -0,0 +1,252 @@ +[[security-troubleshoot-endpoints]] += Troubleshoot {elastic-defend} + +// :keywords: serverless, security, troubleshooting + +++++ +Elastic Defend +++++ + + +This topic covers common troubleshooting issues when using {elastic-defend}'s <>. + +[discrete] +[[ts-endpoints]] +== Endpoints + +.Unhealthy {agent} status +[%collapsible] +===== +In some cases, an `Unhealthy` {agent} status may be caused by a failure in the {elastic-defend} integration policy. In this situation, the integration and any failing features are flagged on the agent details page in {fleet}. Expand each section and subsection to display individual responses from the agent. + +[TIP] +==== +Integration policy response information is also available from the **Endpoints** page in the {security-app} (**Assets** → **Endpoints**, then click the link in the **Policy status** column). +==== + +[role="screenshot"] +image::images/ts-management/-troubleshooting-unhealthy-agent-fleet.png[Agent details page in {fleet} with Unhealthy status and integration failures] + +Common causes of failure in the {elastic-defend} integration policy include missing prerequisites or unexpected system configuration. Consult the following topics to resolve a specific error: + +* <> (macOS) +* <> (macOS) +* <> (Linux) + +[TIP] +==== +If the {elastic-defend} integration policy is not the cause of the `Unhealthy` agent status, refer to {fleet-guide}/fleet-troubleshooting.html[{fleet} troubleshooting] for help with the {agent}. +==== +===== + +.Disabled to avoid potential system deadlock (Linux) +[%collapsible] +===== +If you have an `Unhealthy` {agent} status with the message `Disabled due to potential system deadlock`, that means malware protection was disabled on the {elastic-defend} integration policy due to errors while monitoring a Linux host. + +You can resolve the issue by configuring the policy's <> related to **fanotify**, a Linux feature that monitors file system events. By default, {elastic-defend} works with fanotify to monitor specific file system types that Elastic has tested for compatibility, and ignores other unknown file system types. + +If your network includes nonstandard, proprietary, or otherwise unrecognized Linux file systems that cause errors while being monitored, you can configure {elastic-defend} to ignore those file systems. This allows {elastic-defend} to resume monitoring and protecting the hosts on the integration policy. + +[CAUTION] +==== +Ignoring file systems can create gaps in your security coverage. Use additional security layers for any file systems ignored by {elastic-defend}. +==== + +To resolve the potential system deadlock error: + +. Go to **Assets** → **Policies**, then click a policy's name. +. Scroll to the bottom of the policy and click **Show advanced settings**. +. In the setting `linux.advanced.fanotify.ignored_filesystems`, enter a comma-separated list of file system names to ignore, as they appear in `/proc/filesystems` (for example: `ext4,tmpfs`). Refer to <> for more on determining the file system names. +. Click **Save**. ++ +Once you save the policy, malware protection is re-enabled. +===== + +.Required transform failed +[%collapsible] +===== +If you encounter a `“Required transform failed”` notice on the Endpoints page, you can usually resolve the issue by restarting the transform. Refer to {ref}/transforms.html[Transforming data] for more information about transforms. + +[role="screenshot"] +image::images/ts-management/-troubleshooting-endpoints-transform-failed.png[Endpoints page with Required transform failed notice] + +To restart a transform that’s not running: + +. Go to **Project settings** → **Management** → **Transforms**. +. Enter `endpoint.metadata` in the search box to find the transforms for {elastic-defend}. +. Click the **Actions** menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) and do one of the following for each transform, depending on the value in the **Status** column: ++ +** `stopped`: Select **Start** to restart the transform. +** `failed`: Select **Stop** to first stop the transform, and then select **Start** to restart it. ++ +[role="screenshot"] +image::images/ts-management/-troubleshooting-transforms-start.png[Transforms page with Start option selected] +. On the confirmation message that displays, click **Start** to restart the transform. +. The transform’s status changes to `started`. If it doesn't change, refresh the page. +===== + +.{agent} and Endpoint connection issues +[%collapsible] +===== +After {agent} installs Endpoint, Endpoint connects to {agent} over a local relay connection to report its health status and receive policy updates and response action requests. If that connection cannot be established, the {elastic-defend} integration will cause {agent} to be in an `Unhealthy` status, and Endpoint won't operate properly. + +[discrete] +[[security-troubleshoot-endpoints-identify-if-the-issue-is-happening]] +=== Identify if the issue is happening + +You can identify if this issue is happening in the following ways: + +* Run {agent}'s status command: ++ +** `sudo /opt/Elastic/Agent/elastic-agent status` (Linux) +** `sudo /Library/Elastic/Agent/elastic-agent status` (macOS) +** `c:\Program Files\Elastic\Agent\elastic-agent.exe status` (Windows) ++ +If the status result for `endpoint-security` says that Endpoint has missed check-ins or `localhost:6788` cannot be bound to, it might indicate this problem is occurring. +* If the problem starts happening right after installing Endpoint, check the value of `fleet.agent.id` in the following file: ++ +** `/opt/Elastic/Endpoint/elastic-endpoint.yaml` (Linux) +** `/Library/Elastic/Endpoint/elastic-endpoint.yaml` (macOS) +** `c:\Program Files\Elastic\Endpoint\elastic-endpoint.yaml` (Windows) ++ +If the value of `fleet.agent.id` is `00000000-0000-0000-0000-000000000000`, this indicates this problem is occurring. ++ +[NOTE] +==== +If this problem starts happening after Endpoint has already been installed and working properly, then this value will have changed even though the problem is happening. +==== + +[discrete] +[[security-troubleshoot-endpoints-examine-endpoint-logs]] +=== Examine Endpoint logs + +If you've confirmed that the issue is happening, you can look at Endpoint log messages to identify the cause: + +* `Failed to find connection to validate. Is Agent listening on 127.0.0.1:6788?` or `Failed to validate connection. Is Agent running as root/admin?` means that Endpoint is not able to create an initial connection to {agent} over port `6788`. +* `Unable to make GRPC connection in deadline(60s). Fetching connection info again` means that Endpoint's original connection to {agent} over port `6788` worked, but the connection over port `6789` is failing. + +[discrete] +[[security-troubleshoot-endpoints-resolve-the-issue]] +=== Resolve the issue + +To debug and resolve the issue, follow these steps: + +. Examine the Endpoint diagnostics file named `analysis.txt`, which contains information about what may cause this issue. {agent} diagnostics automatically include Endpoint diagnostics. +. Make sure nothing else on your device is listening on ports `6788` or `6789` by running: ++ +** `sudo netstat -anp --tcp` (Linux) +** `sudo netstat -an -f inet` (macOS) +** `netstat -an` (Windows) +. Make sure `localhost` can be resolved to `127.0.0.1` by running: ++ +** `ping -4 -c 1 localhost` (Linux) +** `ping -c 1 localhost` (macOS) +** `ping -4 localhost` (Windows) +===== + +.{elastic-defend} deployment issues +[%collapsible] +===== +After deploying {elastic-defend}, you might encounter warnings or errors in the endpoint's **Policy status** in {fleet} if your mobile device management (MDM) is misconfigured or certain permissions for {elastic-endpoint} aren't granted. The following sections explain issues that can cause warnings or failures in the endpoint's policy status. + +[discrete] +[[security-troubleshoot-endpoints-connect-kernel-has-failed]] +=== Connect Kernel has failed + +This means that the system extension or kernel extension was not approved. Consult the following topics for approving the system extension, either with MDM or without MDM: + +* <> +* <> + +You can validate the system extension is loaded by running + +[source,txt] +---- +sudo systemextensionsctl list | grep co.elastic.systemextension +---- + +In the command output, the system extension should be marked as "active enabled". + +[discrete] +[[security-troubleshoot-endpoints-connect-kernel-has-failed-and-the-system-extension-is-loaded]] +=== Connect Kernel has failed and the system extension is loaded + +If the system extension is loaded and kernel connection still fails, this means that Full Disk Access was not granted. {elastic-endpoint} requires Full Disk Access to subscribe to system events via the {elastic-defend} framework, which is one of the primary sources of eventing information used by {elastic-endpoint}. Consult the following topics for granting Full Disk Access, either with MDM or without MDM: + +* <> +* <> + +You can validate that Full Disk Access is approved by running + +[source,txt] +---- +sudo /Library/Elastic/Endpoint/elastic-endpoint test install +---- + +If the command output doesn't contain a message about enabling Full Disk Access, the approval was successful. + +[discrete] +[[security-troubleshoot-endpoints-detect-network-events-has-failed]] +=== Detect Network Events has failed + +This means that the network extension content filtering was not approved. Consult the following topics for approving network content filtering, either with MDM or without MDM: + +* <> +* <> + +You can validate that network content filtering is approved by running + +[source,txt] +---- +sudo /Library/Elastic/Endpoint/elastic-endpoint test install +---- + +If the command output doesn't contain a message about approving network content filtering, the approval was successful. + +[discrete] +[[security-troubleshoot-endpoints-full-disk-access-has-a-warning]] +=== Full Disk Access has a warning + +This means that Full Disk Access was not granted for one or all {elastic-endpoint} components. Consult the following topics for granting Full Disk Access, either with MDM or without MDM: + +* <> +* <> + +You can validate that Full Disk Access is approved by running + +[source,txt] +---- +sudo /Library/Elastic/Endpoint/elastic-endpoint test install +---- + +If the command output doesn't contain a message about enabling Full Disk Access, the approval was successful. +===== + +[discrete] +[[disable-self-healing]] +.Disable {elastic-defend}'s self-healing feature on Windows +[%collapsible] +==== + +[discrete] +[[self-healing-vss-issues]] +=== Volume Snapshot Service issues + +{elastic-defend}'s self-healing feature rolls back recent filesystem changes when a prevention alert is triggered. This feature uses the Windows Volume Snapshot Service. Although it's uncommon for this to cause issues, you can turn off this {elastic-defend} feature if needed. + +If issues occur and the self-healing feature is enabled, you can turn it off by setting `windows.advanced.alerts.rollback.self_healing.enabled` to `false` in the integration policy advanced settings. Refer to <> for more information. + +{elastic-defend} may also use the Volume Snapshot Service to ensure the feature works properly even when it's turned off. To opt out of this, set `windows.advanced.diagnostic.rollback_telemetry_enabled` to `false` in the same settings. + +[discrete] +[[self-healing-compatibility-issues]] +=== Known compatibility issues + +There are some known compatibility issues between {elastic-defend}'s self-healing feature and filesystem replication features, including https://learn.microsoft.com/en-us/windows-server/storage/dfs-replication/dfsr-overview[DFS Replication] and Veeam Replication. This may manifest as `DFSR Event ID 1102`: + +`The DFS Replication service has temporarily stopped replication because another application is performing a backup or restore operation. Replication will resume after the backup or restore operation has finished.` + +There are no known workarounds for this issue other than to turn off the self-healing feature. + +==== \ No newline at end of file diff --git a/docs/troubleshooting/ts-management.asciidoc b/docs/troubleshooting/ts-management.asciidoc index 596b4827f5..b228523328 100644 --- a/docs/troubleshooting/ts-management.asciidoc +++ b/docs/troubleshooting/ts-management.asciidoc @@ -222,4 +222,32 @@ sudo /Library/Elastic/Endpoint/elastic-endpoint test install If the command output doesn't contain a message about enabling Full Disk Access, the approval was successful. +==== + +[discrete] +[[disable-self-healing]] +.Disable {elastic-defend}'s self-healing feature on Windows +[%collapsible] +==== + +[discrete] +[[self-healing-vss-issues]] +==== Volume Snapshot Service issues + +{elastic-defend}'s self-healing feature rolls back recent filesystem changes when a prevention alert is triggered. This feature uses the Windows Volume Snapshot Service. Although it's uncommon for this to cause issues, you can turn off this {elastic-defend} feature if needed. + +If issues occur and the self-healing feature is enabled, you can turn it off by setting `windows.advanced.alerts.rollback.self_healing.enabled` to `false` in the integration policy advanced settings. Refer to <> for more information. + +{elastic-defend} may also use the Volume Snapshot Service to ensure the feature works properly even when it's turned off. To opt out of this, set `windows.advanced.diagnostic.rollback_telemetry_enabled` to `false` in the same settings. + +[discrete] +[[self-healing-compatibility-issues]] +==== Known compatibility issues + +There are some known compatibility issues between {elastic-defend}'s self-healing feature and filesystem replication features, including https://learn.microsoft.com/en-us/windows-server/storage/dfs-replication/dfsr-overview[DFS Replication] and Veeam Replication. This may manifest as `DFSR Event ID 1102`: + +`The DFS Replication service has temporarily stopped replication because another application is performing a backup or restore operation. Replication will resume after the backup or restore operation has finished.` + +There are no known workarounds for this issue other than to turn off the self-healing feature. + ==== \ No newline at end of file From 81d194a694a7d936c09d427596a4335e13509d25 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" Date: Mon, 6 Jan 2025 14:46:57 +0000 Subject: [PATCH 2/2] Delete docs/serverless directory and its contents --- .../troubleshoot-endpoints.asciidoc | 252 ------------------ 1 file changed, 252 deletions(-) delete mode 100644 docs/serverless/troubleshooting/troubleshoot-endpoints.asciidoc diff --git a/docs/serverless/troubleshooting/troubleshoot-endpoints.asciidoc b/docs/serverless/troubleshooting/troubleshoot-endpoints.asciidoc deleted file mode 100644 index 707ea7edfb..0000000000 --- a/docs/serverless/troubleshooting/troubleshoot-endpoints.asciidoc +++ /dev/null @@ -1,252 +0,0 @@ -[[security-troubleshoot-endpoints]] -= Troubleshoot {elastic-defend} - -// :keywords: serverless, security, troubleshooting - -++++ -Elastic Defend -++++ - - -This topic covers common troubleshooting issues when using {elastic-defend}'s <>. - -[discrete] -[[ts-endpoints]] -== Endpoints - -.Unhealthy {agent} status -[%collapsible] -===== -In some cases, an `Unhealthy` {agent} status may be caused by a failure in the {elastic-defend} integration policy. In this situation, the integration and any failing features are flagged on the agent details page in {fleet}. Expand each section and subsection to display individual responses from the agent. - -[TIP] -==== -Integration policy response information is also available from the **Endpoints** page in the {security-app} (**Assets** → **Endpoints**, then click the link in the **Policy status** column). -==== - -[role="screenshot"] -image::images/ts-management/-troubleshooting-unhealthy-agent-fleet.png[Agent details page in {fleet} with Unhealthy status and integration failures] - -Common causes of failure in the {elastic-defend} integration policy include missing prerequisites or unexpected system configuration. Consult the following topics to resolve a specific error: - -* <> (macOS) -* <> (macOS) -* <> (Linux) - -[TIP] -==== -If the {elastic-defend} integration policy is not the cause of the `Unhealthy` agent status, refer to {fleet-guide}/fleet-troubleshooting.html[{fleet} troubleshooting] for help with the {agent}. -==== -===== - -.Disabled to avoid potential system deadlock (Linux) -[%collapsible] -===== -If you have an `Unhealthy` {agent} status with the message `Disabled due to potential system deadlock`, that means malware protection was disabled on the {elastic-defend} integration policy due to errors while monitoring a Linux host. - -You can resolve the issue by configuring the policy's <> related to **fanotify**, a Linux feature that monitors file system events. By default, {elastic-defend} works with fanotify to monitor specific file system types that Elastic has tested for compatibility, and ignores other unknown file system types. - -If your network includes nonstandard, proprietary, or otherwise unrecognized Linux file systems that cause errors while being monitored, you can configure {elastic-defend} to ignore those file systems. This allows {elastic-defend} to resume monitoring and protecting the hosts on the integration policy. - -[CAUTION] -==== -Ignoring file systems can create gaps in your security coverage. Use additional security layers for any file systems ignored by {elastic-defend}. -==== - -To resolve the potential system deadlock error: - -. Go to **Assets** → **Policies**, then click a policy's name. -. Scroll to the bottom of the policy and click **Show advanced settings**. -. In the setting `linux.advanced.fanotify.ignored_filesystems`, enter a comma-separated list of file system names to ignore, as they appear in `/proc/filesystems` (for example: `ext4,tmpfs`). Refer to <> for more on determining the file system names. -. Click **Save**. -+ -Once you save the policy, malware protection is re-enabled. -===== - -.Required transform failed -[%collapsible] -===== -If you encounter a `“Required transform failed”` notice on the Endpoints page, you can usually resolve the issue by restarting the transform. Refer to {ref}/transforms.html[Transforming data] for more information about transforms. - -[role="screenshot"] -image::images/ts-management/-troubleshooting-endpoints-transform-failed.png[Endpoints page with Required transform failed notice] - -To restart a transform that’s not running: - -. Go to **Project settings** → **Management** → **Transforms**. -. Enter `endpoint.metadata` in the search box to find the transforms for {elastic-defend}. -. Click the **Actions** menu (image:images/icons/boxesHorizontal.svg[Actions menu icon]) and do one of the following for each transform, depending on the value in the **Status** column: -+ -** `stopped`: Select **Start** to restart the transform. -** `failed`: Select **Stop** to first stop the transform, and then select **Start** to restart it. -+ -[role="screenshot"] -image::images/ts-management/-troubleshooting-transforms-start.png[Transforms page with Start option selected] -. On the confirmation message that displays, click **Start** to restart the transform. -. The transform’s status changes to `started`. If it doesn't change, refresh the page. -===== - -.{agent} and Endpoint connection issues -[%collapsible] -===== -After {agent} installs Endpoint, Endpoint connects to {agent} over a local relay connection to report its health status and receive policy updates and response action requests. If that connection cannot be established, the {elastic-defend} integration will cause {agent} to be in an `Unhealthy` status, and Endpoint won't operate properly. - -[discrete] -[[security-troubleshoot-endpoints-identify-if-the-issue-is-happening]] -=== Identify if the issue is happening - -You can identify if this issue is happening in the following ways: - -* Run {agent}'s status command: -+ -** `sudo /opt/Elastic/Agent/elastic-agent status` (Linux) -** `sudo /Library/Elastic/Agent/elastic-agent status` (macOS) -** `c:\Program Files\Elastic\Agent\elastic-agent.exe status` (Windows) -+ -If the status result for `endpoint-security` says that Endpoint has missed check-ins or `localhost:6788` cannot be bound to, it might indicate this problem is occurring. -* If the problem starts happening right after installing Endpoint, check the value of `fleet.agent.id` in the following file: -+ -** `/opt/Elastic/Endpoint/elastic-endpoint.yaml` (Linux) -** `/Library/Elastic/Endpoint/elastic-endpoint.yaml` (macOS) -** `c:\Program Files\Elastic\Endpoint\elastic-endpoint.yaml` (Windows) -+ -If the value of `fleet.agent.id` is `00000000-0000-0000-0000-000000000000`, this indicates this problem is occurring. -+ -[NOTE] -==== -If this problem starts happening after Endpoint has already been installed and working properly, then this value will have changed even though the problem is happening. -==== - -[discrete] -[[security-troubleshoot-endpoints-examine-endpoint-logs]] -=== Examine Endpoint logs - -If you've confirmed that the issue is happening, you can look at Endpoint log messages to identify the cause: - -* `Failed to find connection to validate. Is Agent listening on 127.0.0.1:6788?` or `Failed to validate connection. Is Agent running as root/admin?` means that Endpoint is not able to create an initial connection to {agent} over port `6788`. -* `Unable to make GRPC connection in deadline(60s). Fetching connection info again` means that Endpoint's original connection to {agent} over port `6788` worked, but the connection over port `6789` is failing. - -[discrete] -[[security-troubleshoot-endpoints-resolve-the-issue]] -=== Resolve the issue - -To debug and resolve the issue, follow these steps: - -. Examine the Endpoint diagnostics file named `analysis.txt`, which contains information about what may cause this issue. {agent} diagnostics automatically include Endpoint diagnostics. -. Make sure nothing else on your device is listening on ports `6788` or `6789` by running: -+ -** `sudo netstat -anp --tcp` (Linux) -** `sudo netstat -an -f inet` (macOS) -** `netstat -an` (Windows) -. Make sure `localhost` can be resolved to `127.0.0.1` by running: -+ -** `ping -4 -c 1 localhost` (Linux) -** `ping -c 1 localhost` (macOS) -** `ping -4 localhost` (Windows) -===== - -.{elastic-defend} deployment issues -[%collapsible] -===== -After deploying {elastic-defend}, you might encounter warnings or errors in the endpoint's **Policy status** in {fleet} if your mobile device management (MDM) is misconfigured or certain permissions for {elastic-endpoint} aren't granted. The following sections explain issues that can cause warnings or failures in the endpoint's policy status. - -[discrete] -[[security-troubleshoot-endpoints-connect-kernel-has-failed]] -=== Connect Kernel has failed - -This means that the system extension or kernel extension was not approved. Consult the following topics for approving the system extension, either with MDM or without MDM: - -* <> -* <> - -You can validate the system extension is loaded by running - -[source,txt] ----- -sudo systemextensionsctl list | grep co.elastic.systemextension ----- - -In the command output, the system extension should be marked as "active enabled". - -[discrete] -[[security-troubleshoot-endpoints-connect-kernel-has-failed-and-the-system-extension-is-loaded]] -=== Connect Kernel has failed and the system extension is loaded - -If the system extension is loaded and kernel connection still fails, this means that Full Disk Access was not granted. {elastic-endpoint} requires Full Disk Access to subscribe to system events via the {elastic-defend} framework, which is one of the primary sources of eventing information used by {elastic-endpoint}. Consult the following topics for granting Full Disk Access, either with MDM or without MDM: - -* <> -* <> - -You can validate that Full Disk Access is approved by running - -[source,txt] ----- -sudo /Library/Elastic/Endpoint/elastic-endpoint test install ----- - -If the command output doesn't contain a message about enabling Full Disk Access, the approval was successful. - -[discrete] -[[security-troubleshoot-endpoints-detect-network-events-has-failed]] -=== Detect Network Events has failed - -This means that the network extension content filtering was not approved. Consult the following topics for approving network content filtering, either with MDM or without MDM: - -* <> -* <> - -You can validate that network content filtering is approved by running - -[source,txt] ----- -sudo /Library/Elastic/Endpoint/elastic-endpoint test install ----- - -If the command output doesn't contain a message about approving network content filtering, the approval was successful. - -[discrete] -[[security-troubleshoot-endpoints-full-disk-access-has-a-warning]] -=== Full Disk Access has a warning - -This means that Full Disk Access was not granted for one or all {elastic-endpoint} components. Consult the following topics for granting Full Disk Access, either with MDM or without MDM: - -* <> -* <> - -You can validate that Full Disk Access is approved by running - -[source,txt] ----- -sudo /Library/Elastic/Endpoint/elastic-endpoint test install ----- - -If the command output doesn't contain a message about enabling Full Disk Access, the approval was successful. -===== - -[discrete] -[[disable-self-healing]] -.Disable {elastic-defend}'s self-healing feature on Windows -[%collapsible] -==== - -[discrete] -[[self-healing-vss-issues]] -=== Volume Snapshot Service issues - -{elastic-defend}'s self-healing feature rolls back recent filesystem changes when a prevention alert is triggered. This feature uses the Windows Volume Snapshot Service. Although it's uncommon for this to cause issues, you can turn off this {elastic-defend} feature if needed. - -If issues occur and the self-healing feature is enabled, you can turn it off by setting `windows.advanced.alerts.rollback.self_healing.enabled` to `false` in the integration policy advanced settings. Refer to <> for more information. - -{elastic-defend} may also use the Volume Snapshot Service to ensure the feature works properly even when it's turned off. To opt out of this, set `windows.advanced.diagnostic.rollback_telemetry_enabled` to `false` in the same settings. - -[discrete] -[[self-healing-compatibility-issues]] -=== Known compatibility issues - -There are some known compatibility issues between {elastic-defend}'s self-healing feature and filesystem replication features, including https://learn.microsoft.com/en-us/windows-server/storage/dfs-replication/dfsr-overview[DFS Replication] and Veeam Replication. This may manifest as `DFSR Event ID 1102`: - -`The DFS Replication service has temporarily stopped replication because another application is performing a backup or restore operation. Replication will resume after the backup or restore operation has finished.` - -There are no known workarounds for this issue other than to turn off the self-healing feature. - -==== \ No newline at end of file