Reorganize Threat Prevention KB into categorized folders with sidebar navigation

docs/kb/threatprevention/_category_.json

@@ -1,6 +1,10 @@
 {
-  "label": "Troubleshooting Articles",
+  "label": "Knowledge Base",
   "position": 999,
   "collapsed": true,
-  "collapsible": true
+  "collapsible": true,
+  "link": {
+    "type": "doc",
+    "id": "index"
+  }
 }

docs/kb/threatprevention/agent-installation-and-deployment/agent_not_detected_and_reinstallation_fails_with_error_agent_is_already_installed.md

@@ -0,0 +1,41 @@
+---
+description: >-
+  This article addresses the issue of the Threat Prevent Agent being unresponsive on a Domain Controller and provides steps to resolve the installation failure due to an existing agent.
+keywords:
+  - Threat Prevent Agent
+  - installation failure
+  - Domain Controller
+sidebar_label: Agent Not Detected
+tags: []
+title: "Agent Not Detected and Reinstallation Fails With Error: Agent Is Already Installed"
+knowledge_article_id: kA0Qk0000002dbZKAQ
+products:
+  - threat-prevention
+---
+
+# Agent Not Detected and Reinstallation Fails With Error: Agent Is Already Installed
+
+## Related Query
+
+- "I have an Agent on one DC that is unresponsive. The Agent is installed. However, the Netwrix Threat Prevent Agents screen shows **No Agent**. When I try to reinstall the Agent via the Threat Prevent interface, I get a message that says it **Failed because the Agent is already installed.**"
+
+## Symptoms
+
+- The Threat Prevent Agent on a Domain Controller is unresponsive.
+- The Threat Prevent Agent's interface displays **No Agent** for the affected server.
+- Attempts to reinstall the agent via the Threat Prevent interface fail with the message: `Failed because the Agent is already installed`.
+
+## Causes
+
+- An older version of the Threat Prevent Agent (e.g., 7.4) remains installed on the server, causing a version conflict.
+- Residual configuration files, such as those in the `CertsInfo` folder, may prevent proper detection or reinstallation of the Agent.
+
+## Resolution
+
+1. Open **Programs and Features** (`appwiz.cpl`) on the affected server.
+2. Manually uninstall any older versions of the Threat Prevent Agent (e.g., version 7.4) that are still listed.
+3. Navigate to the Agent installation directory, typically `C:\Program Files\Netwrix\Netwrix Threat Prevention\SIWindowsAgent`.
+4. Rename the **CertsInfo** folder to **CertsInfo_old** or another unique name.
+5. Return to the Threat Prevent console and push the latest Agent version (e.g., 7.5.0.188) to the server.
+
+> **IMPORTANT:** Renaming the **CertsInfo** folder ensures that any corrupted or outdated certificate information does not interfere with the new Agent installation. Upon successful installation, you can delete the renamed folder as it is no longer necessary.

docs/kb/threatprevention/agent-installation-and-deployment/is-ntlm-authentication-required-for-netwrix-threat-prevention.md

@@ -0,0 +1,37 @@
+---
+description: >-
+  Explains whether NTLM authentication is required for Netwrix Threat Prevention
+  agents and provides an alternative manual installation link if NTLM is
+  unavailable.
+keywords:
+  - NTLM
+  - authentication
+  - Netwrix Threat Prevention
+  - NTP
+  - agent deployment
+  - manual install
+  - agent upgrade
+products:
+  - threat-prevention
+sidebar_label: Is NTLM Authentication Required for Netwrix Threat
+tags: []
+title: "Is NTLM Authentication Required for Netwrix Threat Prevention?"
+knowledge_article_id: kA0Qk00000021ODKAY
+---
+
+# Is NTLM Authentication Required for Netwrix Threat Prevention?
+
+## Question
+
+Is NTLM authentication required for Netwrix Threat Prevention (NTP)?
+
+## Answer
+
+Yes, NTP uses NTLM authentication for deploying and upgrading its agents.  
+If NTLM is unavailable, the agents can be installed or upgraded manually following the instructions in our Help Center: Manual SI Agent Deployment.
+
+**NOTE:** The next major release of NTP v7.5 will remove all use of NTLM.
+
+## Related Article
+
+- Manual SI Agent Deployment

docs/kb/threatprevention/agent-installation-and-deployment/set-up-eset-hips-rules-to-allow-threat-prevention-si-agent-hook.md

@@ -0,0 +1,67 @@
+---
+description: >-
+  Shows how to create ESET HIPS rules to allow the Threat Prevention SI Agent
+  hook (SIWindowsAgent.exe) so the agent can operate without interference.
+keywords:
+  - ESET HIPS
+  - ESET PROTECT
+  - HIPS rules
+  - SI Agent
+  - SIWindowsAgent.exe
+  - Netwrix Threat Prevention
+  - allow rule
+  - endpoint security
+products:
+  - threat-prevention
+sidebar_label: 'Set Up ESET HIPS Rules to Allow Threat Prevention '
+tags: []
+title: "Set Up ESET HIPS Rules to Allow Threat Prevention SI Agent Hook"
+knowledge_article_id: kA04u0000011191CAA
+---
+
+# Set Up ESET HIPS Rules to Allow Threat Prevention SI Agent Hook
+
+## Question
+
+How to set up ESET HIPS rules to allow Threat Prevention SI Agent hook?
+
+## Answer
+
+1. In the left pane of your **ESET PROTECT Web Console**, select **Policies**. Select the **Detection Engine** tab > **HIPS**.
+2. Under the **Rules** section, click **Edit**.
+
+   ![Step 2](../0-images/ka0Qk000000DZET_0EM4u000008M9O8.png)
+
+3. In the **HIPS Rules** window, click **Add**.
+4. Specify the **Rule name**, select **Allow** for the **Action** type, and proceed by clicking **Next**.
+
+   ![Steps 3-4](../0-images/ka0Qk000000DZET_0EM4u000008M9OD.png)
+
+5. Select **Specific applications** in the dropdown list, and click **Add** to add the path to `SIWindowsAgent.exe`. Refer to the following code block for a default path:
+
+   ```text
+   C:\Program Files\STEALTHbits\StealthINTERCEPT\SIWindowsAgent\
+   ```
+
+   Proceed to the next step by clicking **Next**.
+
+   ![Step 5](../0-images/ka0Qk000000DZET_0EM4u000008M9OI.png)
+
+6. Switch the **All file operations** switch to the on position, and proceed by clicking **Next**. Click **OK** to save changes.
+
+   ![Step 6](../0-images/ka0Qk000000DZET_0EM4u000008M9OS.png)
+
+7. Once the configuration steps are completed, proceed to the **Assign** tab. Assign the new rule to corresponding systems.
+
+   ![Step 7](../0-images/ka0Qk000000DZET_0EM4u000008M9OX.png)
+
+8. The rule should become visible in your ESET host. Refer to the **Advanced Setup** menu > **HIPS** tab > **Basic** section > **Rules** tab.
+
+   ![Step 8](../0-images/ka0Qk000000DZET_0EM4u000008M9Oc.png)
+
+> **NOTE:** Once the rule is applied, SI Agent should be restarted.
+
+## Related articles
+
+- [Create a HIPS rule and enforce it on a client workstation using ESET PROTECT (8.x – 10.x) ⸱ ESET 🛡️](https://support.eset.com/en/kb8018-create-a-hips-rule-and-enforce-it-on-a-client-workstation-using-eset-protect)
+- [Enable or disable HIPS in ESET products (15.x–16.x) ⸱ ESET 🛡️](https://support.eset.com/en/kb2811-enable-or-disable-hips-in-eset-products)

docs/kb/threatprevention/agent-installation-and-deployment/threat-prevention-agent-install-fails-with-error-643.md

@@ -0,0 +1,71 @@
+---
+description: >-
+  Agent deployment from the Netwrix Threat Prevention Console fails with
+  "Installer error 643" due to TLS/connection failures during certificate
+  retrieval. This article shows verbose log examples, verification steps, and
+  the recommended resolution.
+keywords:
+  - installer error 643
+  - agent install
+  - Netwrix Threat Prevention
+  - port 3741
+  - OpenSSL
+  - SSL inspection
+  - firewall
+products:
+  - threat-prevention
+sidebar_label: Threat Prevention Agent Install Fails With Error 6
+tags: []
+title: "Threat Prevention Agent Install Fails With Error 643"
+knowledge_article_id: kA04u0000000HvvCAE
+---
+
+# Threat Prevention Agent Install Fails With Error 643
+
+## Symptom
+Agent deployment from the Netwrix Threat Prevention Console fails with "Installer error 643".
+
+Error 643 information found in the verbose installer log on the agent (`C:\Windows\Temp\SIAenbt-install-{date}_MainPackage64.log`) will show the following error if the installer is set to verbose logging:
+
+```
+RequestCertsCA:  Getting root cert from EM
+RequestCertsCA: Exception:  System.IO.IOException: Unable to read data from the transport connection: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. ---> System.Net.Sockets.SocketException: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond
+   at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)
+   --- End of inner exception stack trace ---
+   at Org.BouncyCastle.Crypto.Tls.TlsProtocol.SafeReadRecord()
+   at Org.BouncyCastle.Crypto.Tls.TlsProtocol.BlockForHandshake()
+   at SI_Agent_CustomActions.Certificates.RemoteTlsCertificateRetrieval.RetrieveCertificatesFromTlsHost(String serverHostName, Int32 serverPort)
+   at SI_Agent_CustomActions.CustomActions.RetrieveCertificates(String serverHostName, Int32 serverPort)
+   at SI_Agent_CustomActions.CustomActions.RequestCertsCA(Session session)
+RequestCertsCA: Ended
+```
+
+## Further Verification Steps
+
+- Use `telnet` or `Test-NetConnection` to confirm port `3741` is accessible from the host where the Agent is being installed.
+- Run the following OpenSSL command to test TLS connectivity (execute as a command, preserve the placeholder):
+  - `OpenSSL.exe s_client -connect \{INTERCEPT IP ADDRESS\} -port 3741`
+  - Notes:
+    - This works from another machine but not on the one with the error.
+    - On the failing host, OpenSSL does not connect to the server and shows output similar to the following:
+
+```
+CONNECTED(0000011C)
+write:errno=10060
+---
+no peer certificate available
+---
+No client certificate CA names sent
+---
+SSL handshake has read 0 bytes and written 293 bytes
+Verification: OK
+---
+New, (NONE), Cipher is (NONE)
+Secure Renegotiation IS NOT supported
+No ALPN negotiated
+Early data was not sent
+Verify return code: 0 (ok)
+```
+
+## Resolution
+Contact your network/firewall team. This issue most commonly results from a firewall blocking communication on port `3741` from the host where the Agent is being installed to the Netwrix Threat Prevention host. It may also be caused by SSL inspection between the Netwrix Threat Prevention host and the host where the Agent is being installed.

docs/kb/threatprevention/agent-installation-and-deployment/unable-to-upgrade-si-agents.md

@@ -0,0 +1,84 @@
+---
+description: >-
+  Describes how to resolve SI Agents that cannot self-upgrade due to missing
+  certificates, with manual and GPO-based certificate installation steps.
+keywords:
+  - SI Agent
+  - upgrade
+  - certificates
+  - DigiCert
+  - Trusted Root
+  - GPO
+  - mmc
+  - import
+products:
+  - threat-prevention
+sidebar_label: Unable to Upgrade SI Agents
+tags: []
+title: "Unable to Upgrade SI Agents"
+knowledge_article_id: kA04u000000wnqgCAA
+---
+
+# Unable to Upgrade SI Agents
+
+## Symptoms
+
+- When attempting to upgrade a SI Agent, no updates are available.
+- The message `You're using the latest version` is prompted while an upgrade is expected to occur.
+
+## Cause
+
+The upgrade will fail for previous versions of SI Agents in servers without required certificates.
+
+## Resolution
+
+Refer to the following steps to allow SI Agents to self-upgrade to future versions:
+
+1. Uninstall the previous version of installed SI Agent.
+2. Install the latest SI Agent.
+3. Install required certificates.
+
+### Install required certificates − Preparation
+
+1. Download the following certificates:
+
+```
+https://cacerts.digicert.com/DigiCertAssuredIDRootCA.crt.pem
+https://cacerts.digicert.com/DigiCertTrustedRootG4.crt.pem
+https://cacerts.digicert.com/DigiCertTrustedG4CodeSigningRSA4096SHA3842021CA1.crt.pem
+```
+
+2. Put the certificates in a shared folder.
+
+### Install required certificates − Manually import certificates to the local certificate store
+
+1. Launch Microsoft Management Console (e.g., via **Run** > **mmc.exe**).
+2. Select **File** > **Add/Remove Snap-ins**.
+3. Select **Certificates** > **Add**.
+4. Select **Computer account** > **Local computer** > **Finish** > **OK**.
+5. Expand the **Certificates (Local Computer)** node in the left pane.
+6. Right-click **Trusted Root Certification Authorities** > **All tasks** > **Import...**.
+7. Click **Next** > **Browse** to locate the certificates downloaded previously, and select the appropriate certificate.
+
+> IMPORTANT: In case the certificates are not showing in the target folder, switch the extension filter to show **All files**, and select the certificate.
+
+8. Select the **Place all certificates in the following store** option with the certificate store being **Trusted Root Certification Authorities**. Click **Next** > **Finish**.
+9. Wait for the **The import was successful** message to pop up.
+10. Repeat the steps for all certificates in all servers.
+
+### Install required certificates − GPO
+
+1. In your domain controller, launch the **Group Policy Management** snap-in.
+2. Locate an existing Group Policy Object (GPO) or create a new GPO to specify the certificate settings.
+3. Right-click the GPO, and click **Edit**.
+4. In the left pane, locate **Computer Configuration** > **Policies** > **Windows Settings** > **Security Settings** > **Public Key Policies**.
+5. Right-click **Trusted Root Certification Authorities**, and click **Import...**.
+6. Click **Next** > **Browse** to locate the certificates downloaded previously, and select the appropriate certificate.
+
+> IMPORTANT: In case the certificates are not showing in the target folder, switch the extension filter to show **All files**, and select the certificate.
+
+7. Select the **Place all certificates in the following store** option with the certificate store being **Trusted Root Certification Authorities**. Click **Next** > **Finish**.
+8. Wait for the **The import was successful** message to pop up.
+9. Repeat the steps for all certificates.
+
+> TIP: Force GPO update in remote servers using the GPO Management console or scripts.

docs/kb/threatprevention/agent-management-and-connectivity/agent-connection-lost-after-upgrading.md

@@ -0,0 +1,63 @@
+---
+description: >-
+  After upgrading or patching to a new build, the Netwrix Threat Prevention
+  Agent may show as Lost Connection in the Threat Prevention Console due to
+  duplicate host entries in the NVMonitorConfig database. This article explains
+  how to identify and resolve the issue.
+keywords:
+  - agent
+  - connection
+  - upgrade
+  - NVMonitorConfig
+  - Server table
+  - CertsInfo
+  - Enterprise Manager
+  - SQL Server
+  - uninstall
+  - duplicate host
+products:
+  - threat-prevention
+sidebar_label: Agent Connection Lost After Upgrading
+tags: []
+title: "Agent Connection Lost After Upgrading"
+knowledge_article_id: kA0Qk00000024IrKAI
+---
+
+# Agent Connection Lost After Upgrading
+
+## Symptom
+
+After upgrading or patching to a new build, the Netwrix Threat Prevention Agent is listed as **Lost Connection** in the Threat Prevention Console.
+
+## Cause
+
+Within the Threat Prevention Console, the host may be listed without domain details. This can occur if the host was replaced with a new server that was named to match the original.
+
+In the `NVMonitorConfig` database, the host may appear multiple times within the **Server** table, both with and without the domain prefix.
+
+> **NOTE:** You can confirm this in SQL Server Management Studio by running the following query:
+>
+> ```sql
+> SELECT * FROM [NVMonitorConfig].[dbo].[Server] WHERE name LIKE '%<Host Name>%'
+> ```
+>
+> ![Query results in SSMS showing duplicate host entries in the Server table](../0-images/ka0Qk000000FNHF_0EMQk00000E8sBH.png)
+
+## Resolution
+
+1. Stop the **Netwrix Threat Prevention Enterprise Manager (EM)** service from the Windows Services screen.
+2. In SQL Server Management Studio, run the following command to remove duplicate or incorrect host entries:
+   ```sql
+   DELETE FROM [NVMonitorConfig].[dbo].[Server] WHERE name LIKE '%<Host Name>%'
+   ```
+3. Rename the `CertsInfo` folder in the agent's install path. It is recommended to collect this folder when stopping the EM service.
+
+   > **NOTE:** The default path may vary depending on the Threat Prevention version:
+   >
+   > - New default path: `C:\Program Files\Netwrix\Netwrix Threat Prevention\SIWindowsAgent\CertsInfo`
+   > - Old default path: `C:\Program Files\STEALTHbits\StealthINTERCEPT\SIWindowsAgent\CertsInfo`
+
+4. Manually uninstall the agent from the affected host.
+5. Push the installer back out from the Threat Prevention Console.
+
+The agent should now be listed as **Active**.