Error: U00003447 Connection to SNMP agent could not be established (Code '10060').

Products

CA Automic Workload Automation - Automation Engine

Issue/Introduction

The PWP not connecting to SNMP subagent. The Windows SNMP Subagent (ucsnmp1.dll), loaded as a Windows SNMP Extension Agent inside the Windows SNMP Service (snmp.exe), stops responding to SNMP requests for the UC4/Automic MIB subtree. MIB data is not updated and no traps referencing current Automation Engine job/workload data are generated.

Diagnostic symptoms observed:

The PWP logs shows an error saying that it cannot connect to the SNMP Agent and times out after 21 seconds:

20260713/032651.750 - U00003447 Connection to SNMP agent could not be established (Code '10060').
20260713/032651.750 -          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.
20260713/032651.750 - U00003369 ===> Time critical SNMP call. Communication with agent required '21,016' seconds.

ucsnmp1_00.log with traces activated (snmp=9, stream=) shows a clean startup and the reader thread entering its listen loop (--> uc4::ByteStream::read), then no further activity.
The command netstat -ano | findstr :<stream_Port> (default port 7777) shows the socket correctly in LISTENING state, owned by snmp.exe.
A packet capture on the loopback interface shows repeated TCP SYN retransmissions from 127.0.0.1 to 127.0.0.1:<stream_Port> with no SYN-ACK and no RST — the connection is never established, and no error is returned to the caller.

Environment

Automic Automation Windows Agent, SNMP subagent component (agent-snmp, built as ucsnmp1.dll)
Modern Windows platform like Windows 2022

Cause

This is a Windows operating system network-security restriction, not a defect in the Automic SNMP Subagent (ucsnmp1.dll).

Windows Service Hardening (WSH), a Windows platform security feature restricts several built-in Windows services to a predefined ("hardened") network behavior profile, enforced directly in the Windows Filtering Platform (WFP) kernel driver. These restrictions:

Take priority over ordinary Windows Firewall rules — an enabled Allow rule in the standard Windows Firewall rule set (created via the Windows Firewall GUI, netsh advfirewall, or New-NetFirewallRule in its default policy store) has no effect on them.
Apply even to purely local/loopback traffic.
Are stored and evaluated from a separate configuration store than ordinary firewall rules (RestrictedServices\Configurable vs. the standard firewall rule store), which is why they are easy to overlook during troubleshooting.

The built-in Windows SNMP Service snmp.exe is one of the services covered by this hardened profile, and its default profile permits UDP traffic only (matching classic SNMP's use of UDP 161/162). The Automic SNMP Subagent extends snmp.exe with its own custom TCP listener (default port 7777, configurable via stream_Port in ucsnmp1.ini) used to exchange MIB and trap data with the Automation Engine. This TCP listener falls outside the SNMP service's hardened network profile, so Windows silently drops every inbound connection attempt to it — without an RST, which is why the connection appears to simply hang rather than being actively refused.

This was confirmed via the Windows Security Event Log (Event ID 5157, Windows Filtering Platform Connection auditing), which reported:

Filter Origin: WSH Default
Layer Name:    Receive/Accept
Application:   \device\harddiskvolume2\windows\system32\snmp.exe
Direction:     Inbound
Is Loopback:   True

...and by dumping the live Windows Filtering Platform filter table (netsh wfp show filters), which showed only pre-existing UDP allow filters for snmp.exe — no TCP filter existed, even after adding a correctly-scoped Windows Firewall Allow rule and rebooting.

Resolution

Standard Windows Firewall configuration cannot resolve this — including rules scoped to the specific service via New-NetFirewallRule -Service SNMP. The fix requires adding an explicit Windows Service Hardening allow rule to the dedicated ConfigurableServiceStore policy store, which is the store Windows Service Hardening actually consults for protected services (this is the same, documented mechanism Microsoft uses internally — for example, to grant Hyper-V's vmms service a custom port exception).

Open an elevated PowerShell prompt and add the WSH-aware allow rule for the SNMP service and the configured stream port (default 7777 — substitute your configured stream_Port value from ucsnmp1.ini):

$HT = @{
    DisplayName   = "Automic SNMP Subagent WSH Inbound"
    Direction     = "Inbound"
    InterfaceType = "Any"
    Action        = "Allow"
    Protocol      = "TCP"
    Service       = "SNMP"
    Program       = "$env:systemroot\System32\snmp.exe"
    Enabled       = "True"
    LocalPort     = "7777"
    PolicyStore   = "ConfigurableServiceStore"
}
New-NetFirewallRule @HT

Verify the rule was created in the correct store (it will not appear via a plain Get-NetFirewallRule call or in -PolicyStore ActiveStore — that is expected):Confirm Protocol: TCP and LocalPort: 7777 (or your configured port) are shown.
```
Get-NetFirewallRule -PolicyStore ConfigurableServiceStore -DisplayName "Automic SNMP Subagent WSH Inbound" | Get-NetFirewallPortFilter
```
Reboot the server, so the Windows Filtering Platform recompiles the Windows Service Hardening filter set for the SNMP service with the new rule included.
Confirm the fix:
- netstat -ano | findstr :7777 still shows LISTENING.
- The Automation Engine successfully connects, and ucsnmp1_00.log shows Server new connection accepted....
- Optionally, re-run netsh wfp show filters and confirm a TCP allow filter for snmp.exe is now present alongside the pre-existing UDP ones.

Additional Information

This restriction is independent of Windows Firewall profile settings, third-party antivirus/EDR software, the SNMP service's Service SID type, and Group Policy firewall-rule-merge settings. All of which were individually ruled out during investigation of this issue.
Any third-party SNMP extension agent that hosts its own custom TCP listener inside the Windows SNMP Service process is expected to be affected identically on any Windows version with Windows Service Hardening enabled (which is the default and cannot generally be disabled without materially reducing OS security posture).
For background on Windows Service Hardening and the WSH Default filter origin, see: