To troubleshoot and resolve the issue, please follow these steps:
Verify the Agent Service:
Ensure the Agent service is running. Restart it if necessary.
Check Port 8006 Availability:
Run the following command to confirm port 8006 is in use:netstat -aon | find "8006"
If port 8006 is not listed, restart the Agent service and check again.
Identify Port Conflicts:
Stop the Agent service.
Re-run the netstat command to ensure no other application is using port 8006.
Restart the Agent service.
Verify IP Binding:
The netstat output should show port 8006 bound to 0.0.0.0. If it shows ::1 or the server's specific IP:
For ::1 (IPv6 loopback):
Prioritize IPv4 over IPv6:
Open regedit.
Navigate to HKLM\System\CurrentControlSet\Services\TCPIP6\Parameters.
Create a DWORD value named DisabledComponents and set it to 32 (decimal) or 0x20 (hex).
Reboot the server.
For specific IP bindings without 0.0.0.0:
Modify the ListenOnlyList:
Open regedit.
Navigate to HKLM\System\CurrentControlSet\Services\HTTP\Parameters.
If ListenOnlyList exists, modify it to include only 0.0.0.0.
Reboot the server.
Test Local Port Connectivity
Option 1 – Using Telnet (requires installation):
Command: telnet localhost 8006
A blank screen indicates a successful connection.
To install Telnet (if missing), run:dism /online /Enable-Feature /FeatureName:TelnetClient
Option 2 – Using PowerShell:
Command: Test-NetConnection -ComputerName localhost -Port 8006
If TcpTestSucceeded is True, the port is open and listening.
If False, the port is blocked or not in use.
Test Local Agent API Response:
Open a browser and navigate to:https://127.0.0.1:8006/apprecovery/api/agent/pair/connect
You should receive an XML response with the agent ID.
If not, check Event Viewer for SCHANNEL or TLS-related errors.
Verify Agent Hostname Resolution:
In the Core Console, go to the agent's Settings and note the hostname.
Run: ping <agent_hostname>
Verify it resolves to the correct IPv4 address.
Test Remote Port Connectivity:
Command: telnet <agent_hostname> 8006
A blank screen indicates the port is reachable.
If it fails, check for firewall blocks between Core and Agent.
Test Remote Agent API Response:
Open a browser on the Core and navigate to:https://<agent_hostname>:8006/apprecovery/api/agent/pair/connect
You should receive an XML response with the agent ID.
If it fails, consider using IIS Crypto on the Agent:
Launch IIS Crypto
Click “Best Practices”
Reboot the Agent server
Re-test the API endpoint
If all steps were completed successfully, but the agent still cannot be protected or remains offline, review the agent's Event Viewer for WMI errors.
WMI repository corruption can prevent the Agent software from communicating with the Core.
Note: In some cases, the Agent service may not start because port 8006 is already in use by another application (such as Exchange).
Even if netstat does not show port 8006 as in use, the Agent log may contain a "file is already in use" error from the .NET framework, indicating a port bind conflict.
NTLM Authentication Restrictions:
In some environments, NTLM authentication may be restricted by local or domain policies, which can prevent the Core from pairing with the Agent.
For details and resolution steps, see:
KB 4378979 – Unable to Protect Rapid Recovery Agent Due to NTLM Restrictions Enforced by Local or Domain Policy
When protecting an agent, consider the following best practices:
Use the machine name instead of the IP address.
Format credentials as <domain>\<administrator> when the machine is domain-joined.
(The <domain> should be the NetBIOS name, not the FQDN.)
If you are still experiencing issues after following the steps in this article, please contact Quest Support for further assistance:
