SolarWinds Additional Polling Engine vs. Platform Remote Collector: Which Polling Architecture Fits?

When SolarWinds monitoring spans multiple sites, network zones, or a DMZ, two different polling approaches become relevant: the Additional Polling Engine (APE) and the SolarWinds Platform Remote Collector.

Both move monitoring closer to the monitored systems, but they are not interchangeable versions of the same architecture. An APE is a full SolarWinds scalability engine with broad feature coverage and high polling capacity. A Remote Collector is intentionally lighter: it is designed for remote, bandwidth-constrained, or strongly segmented networks and reduces central communication at the cost of capacity and feature coverage.

That distinction matters especially in a DMZ. The design question is not only what can be monitored, but also which systems may communicate across the security boundary, whether direct database connectivity is acceptable, and how many firewall rules must be maintained long term.

The values and support statements in this article reflect SolarWinds documentation available in September 2026. Actual limits depend on product, license, version, polling protocol, polling intervals, and hardware. Always validate the exact version against the current support and port documentation before implementation.

The short version

The practical decision is therefore rarely “which poller is better?” It is usually: Do I need the feature breadth and scale of an APE, or is the Remote Collector's reduced communication model more important?

Additional Polling Engine: full platform integration

An Additional Polling Engine extends the polling capacity of a SolarWinds deployment. It is tightly integrated with the central SolarWinds Platform and can cover a much broader feature set than a Remote Collector.

Typical strengths include:

• high polling capacity;
• broad support across SolarWinds products and monitoring functions;
• suitability for large NPM, SAM, and other platform workloads;
• load distribution across multiple polling engines;
• the ability to move nodes between polling engines;
• support for High Availability designs around APEs;
• license or polling-engine stacking in supported licensing models.

The trade-off is tighter platform coupling. According to the current SolarWinds Port Requirements, an APE requires, depending on version and enabled features, platform communication such as:

• TCP 1433 to the SolarWinds Platform database;
• TCP 5671 for encrypted RabbitMQ/AMQP messaging;
• TCP 17777 for SolarWinds service and platform communication;
• additional service ports in newer platform versions, for example TCP 17734;
• the monitoring protocols required to reach monitored systems, such as SNMP, WMI/WinRM, HTTPS, or SSH.

UDP 1434 is only needed when SQL Server Browser or dynamic SQL ports are used.

Inside a trusted server network this communication is often straightforward. In a DMZ, direct SQL access becomes a relevant design issue because a compromised polling server has a direct network path to an internal database service.

APE scalability: 12,000 elements is a baseline, not a universal maximum

SolarWinds is often associated with a figure of 12,000 elements per polling engine. That remains a useful generic planning baseline for classic NPM deployments at standard polling intervals. SolarWinds also recommends considering redistribution or additional engines around 10,000 elements or when polling rate exceeds roughly 85 percent.

But it is not a universal technical maximum.

For current SolarWinds Observability Self-Hosted Enterprise Scale scenarios, SolarWinds documents much higher protocol-dependent figures. For the documented 2025.4 generation, examples include up to roughly:

• 100,000 SNMPv2 elements per polling engine;
• 72,000 SNMPv3 elements per polling engine;
• 20,000 WMI/WinRM elements with a maximum of 2,000 nodes;

subject to CPU resources, licensing, and standard polling frequencies. Some limits increase further with additional CPU cores.

The key point is that APE capacity must be sized against the actual product and licensing model. A simple “12,000 versus 1,000” comparison is too crude for modern Enterprise Scale deployments.

Platform Remote Collector: a smaller trust path

The SolarWinds Platform Remote Collector takes a different approach. It is based on SolarWinds agent technology, but it executes polling jobs locally on behalf of other devices. Systems in the remote network can still be monitored agentlessly through WMI or SNMP, while central communication uses the agent connection.

The most important difference is that a Remote Collector does not require a direct connection to the SolarWinds Platform database.

SolarWinds documents TCP 17778 outbound from the Collector to the SolarWinds Platform for central communication. The connection is agent-initiated. The Collector is NAT-friendly and supports authenticated proxy traversal. SolarWinds explicitly positions it for DMZs, branch offices, cloud networks, and low-bandwidth/high-latency links.

Additional characteristics include:

• no direct SQL connection;
• one central communication port for the Collector itself;
• local execution of polling jobs;
• buffering of polling results for up to 24 hours during connectivity loss;
• automatic plugin deployment when supported SolarWinds products are installed;
• automatic Collector upgrades together with the Main Polling Engine;
• upgrades using the same TCP 17778 communication path;
• the ability to move nodes between Remote Collectors and APEs.

From a security perspective, this reduces the number of trust paths significantly. Operationally, it also means a short WAN outage does not immediately have to become a monitoring data gap.

A Remote Collector is still not a reverse proxy. It is an independent poller with a local Job Engine and an agent-initiated return channel to the platform.

Why Remote Collector is often a strong DMZ option

In a DMZ, the question is usually not whether an APE works technically. It does. The more important question is whether its connections to the internal SolarWinds stack are acceptable.

A simplified view looks like this:

Additional Polling Engine in the DMZ
    -> SQL / TCP 1433
    -> Main Polling Engine / TCP 5671
    <-> SolarWinds Platform / TCP 17777
    -> monitored systems

Remote Collector in the DMZ
    -> SolarWinds Platform / TCP 17778
    -> monitored systems

That is why a Remote Collector is often the first architecture option worth evaluating for a DMZ. Not because it provides more features, but because the central attack and communication surface can be constrained more easily.

One caveat remains: the Remote Collector still initiates TCP 17778 from its network toward the internal SolarWinds Platform. If a security policy prohibits all DMZ-initiated traffic to internal systems without exception, the Remote Collector does not satisfy that requirement either. It does, however, reduce the path to a clearly defined agent-based channel and removes direct SQL connectivity.

Remote Collector limits: 1,000 elements is a hard planning boundary

The current SolarWinds Scalability Engine Guidelines specify:

• maximum 1,000 elements per Remote Collector;
• maximum 100 Remote Collectors per polling engine;
• maximum 48,000 elements per polling engine across all assigned Remote Collectors.

The 1,000-element limit does not mean 1,000 devices. A switch can contribute one node plus dozens or hundreds of monitored interfaces. A server can add volumes and other monitored objects.

A simple sizing example:

These are planning examples, not SolarWinds licensing calculations. They show why device count alone is not enough for Remote Collector sizing.

SolarWinds also recommends sizing a Collector close to the 1,000-element ceiling more like a small SolarWinds Platform deployment. A “lightweight Collector” is therefore not automatically a tiny VM when heavily loaded.

An often-overlooked point: operating system and agent foundation

The Remote Collector currently runs on Windows. SolarWinds lists Windows Server 2012 R2 through 2025 and Windows 10/11 among supported platforms; Linux and AIX are not supported for the Remote Collector. The host also requires:

• a unique hostname;
• .NET Framework 4.8 or later;
• a SolarWinds Platform Agent using agent-initiated communication.

Server-initiated agent communication is explicitly not supported for Remote Collectors.

For a DMZ design, that means the simpler network model reduces firewall relationships but still requires a maintained Windows host in the zone.

Feature coverage: the most important part of the decision

SolarWinds explicitly states that a Remote Collector does not support every metric and function available through an Additional Polling Engine.

The current support matrix lists Remote Collector support for:

• Network Automation Manager (NAM);
• SAM with node-based licensing;
• SolarWinds Observability Self-Hosted.

Supported common platform metrics include:

• node CPU;
• node memory;
• node status and response;
• volumes.

For NPM, SolarWinds additionally documents support for capabilities such as:

• interfaces;
• Device Studio and Device View;
• routing/VRF;
• VLANs;
• wireless and wireless heatmaps;
• topology;
• Universal Device Pollers (UnDP);
• multicast, Nexus, switch stacks, and other NPM functions.

For SAM, SolarWinds lists support including:

• AppInsight for Active Directory;
• AppInsight for IIS;
• AppInsight for SQL;
• AppInsight for Exchange;
• most application monitor templates;
• asset inventory;
• Hardware Health with limitations.

Explicitly unsupported examples

The current SAM Remote Collector documentation lists examples such as:

• API Poller monitoring;
• Container Monitoring;
• JMX Monitoring;
• Hardware Health for UCS or Nutanix;
• JMX Monitor;
• Nagios Script Monitor;
• NNTP Monitor;
• Oracle User Experience Monitor;
• RADIUS User Experience Monitor;
• TACACS+ User Experience Monitor.

The SolarWinds API Poller Requirements also explicitly state that API Poller does not support agent polling or Remote Collectors.

“NAM supports Remote Collector” does not mean complete module parity

A common architecture mistake is to read “NAM supports Remote Collector” as meaning that every function of NPM, NCM, NTA, IPAM, UDT, and VNQM automatically runs through the Collector.

The SolarWinds support matrix is more specific: it lists common SolarWinds Platform metrics for NAM and then enumerates concrete NPM functions. Specialized module workflows need separate verification.

The better design-review question is therefore not:

“Does our product support Remote Collector?”

but:

“Does the Remote Collector support the exact polling method, monitor type, and module workflow we need at this site?”

That matters especially for configuration management, flow collection, specialist application monitors, and custom checks.

Agent-polled nodes are a special case

Remote Collectors use agent technology for their own platform communication, but they cannot be combined arbitrarily with agent-based node monitoring.

SolarWinds documents that:

• a Remote Collector cannot poll nodes that are themselves monitored through a SolarWinds Platform Agent;
• an Agent installed on the Main Polling Engine or an APE cannot be promoted to a Remote Collector;
• a Collector requires agent-initiated communication.

For SAM, licensing matters as well: Remote Collector is supported with node-based licensing.

If an environment already uses many agent-polled nodes, this needs to be considered early in the architecture design.

There is also a less obvious capacity detail: SolarWinds states that each Remote Collector reduces the Agent scalability of its assigned polling engine by the equivalent of ten SolarWinds Platform Agents. In deployments with very large Agent populations, that can matter.

Migration: no in-place conversion from an APE

Migration planning contains an important practical trap.

An Agent installed on a Main Polling Engine or Additional Polling Engine cannot be promoted to a Remote Collector. An existing APE therefore cannot simply be converted into a Remote Collector in place.

The reverse path is not symmetric either. A Remote Collector cannot be directly demoted back into a normal SolarWinds Platform Agent. SolarWinds describes a removal process instead:

1. remove or reassign all nodes assigned to the Collector;
2. remove the Remote Collector polling engine;
3. delete the Collector Agent;
4. then promote another Agent or deploy a new Collector host.

For DMZ migration projects, a new Collector host running in parallel with the existing APE is therefore often the lower-risk pilot approach. Nodes can then be moved in a controlled way between APE and Remote Collector.

WAN and latency: the architectures behave differently

SolarWinds explicitly positions Remote Collectors for low-bandwidth and high-latency scenarios. The local poller runs jobs at the site and forwards results centrally afterward.

With an APE, the traffic pattern is different. SolarWinds notes that relatively little monitoring traffic flows between the Main Polling Engine and a remote APE, while most monitoring-related traffic is between the APE and the SolarWinds database.

That matters for site design. An APE on the far side of a slow or unstable WAN link may poll local devices efficiently, but it still depends heavily on database connectivity. The Remote Collector removes that direct database dependency and can buffer results for up to 24 hours during communication loss.

The 24-hour buffer is not a substitute for High Availability or disaster recovery. It helps with temporary network interruptions, not with the permanent loss of the Collector host.

Upgrade and lifecycle behavior

Operationally, the Remote Collector is tied closely to the Agent lifecycle:

• Collector plugins are deployed automatically;
• platform upgrades update Remote Collectors automatically;
• upgrade communication uses the same TCP 17778 path.

This reduces separate upgrade effort across many small remote sites.

An APE, by contrast, is a full scalability engine and part of the central SolarWinds upgrade path. It requires more platform components, resources, and network communication, but provides the broader feature set in return.

Direct comparison

When is an APE the better choice?

An Additional Polling Engine is usually the more robust option when:

• a site requires far more than 1,000 elements;
• the broadest possible SolarWinds feature coverage is required;
• API Poller, JMX, Container Monitoring, or unsupported specialist monitors are needed;
• the site relies on substantial module-specific workflows;
• high polling density and short intervals are required;
• central platform and SQL communication from the site is acceptable;
• High Availability for the polling engine is part of the design.

For large data centers and complex monitoring zones, the APE is therefore often the more predictable platform component.

When is a Remote Collector the better choice?

A Remote Collector deserves particular consideration when:

• monitoring is required in a DMZ, branch office, or cloud network;
• the design should minimize firewall connections to the central platform;
• direct SQL connectivity from the remote network should be avoided;
• NAT or an authenticated proxy is part of the architecture;
• no more than 1,000 elements per Collector are required;
• all required monitoring functions are covered by the support matrix;
• WAN links are slow, high-latency, or intermittently unreliable;
• many small sites need monitoring without full APE infrastructure.

For SNMP-based infrastructure monitoring and many classic SAM scenarios, this model can fit very well.

Hybrid is often better than an all-or-nothing decision

APEs and Remote Collectors do not have to be mutually exclusive. SolarWinds supports moving nodes between Remote Collectors and APEs.

A typical hybrid design can use:

• Remote Collectors for standard monitoring in DMZs or small remote sites;
• APEs for large sites;
• APEs for specialist functions not supported by Remote Collector;
• central APEs for API Poller or module-specific workflows;
• Collector pilots for new security zones before broader rollout.

The trade-off is that if an APE is still required in the same DMZ for exceptions, some of the simplified security model is lost. Exceptions should therefore be identified during template and monitor inventory, not after deployment.

Ten questions for an architecture review

Before choosing an architecture, answer ten concrete questions:

1. How many elements will actually be monitored, including nodes, interfaces, and volumes?
2. Which polling protocols are required: SNMPv3, WMI/WinRM, Agent, HTTPS, SSH?
3. Which SAM component monitors and templates are in use?
4. Are API Poller, JMX, or Container Monitoring required?
5. Are any nodes already monitored through SolarWinds Platform Agents?
6. Are direct connections to SQL and central platform services allowed from the target zone?
7. Is outbound TCP 17778 allowed from the target zone?
8. Is NAT, a proxy, high latency, or unreliable WAN connectivity involved?
9. Which SAM/NAM/Observability licensing model is in use?
10. Which functions must be proven in a pilot before architecture approval?

These questions usually produce a reliable decision faster than a purely theoretical product comparison.

A pragmatic pilot strategy

For a DMZ or remote site, use a small but representative pilot. For example:

• one traditional SNMPv3 network device;
• one Windows server with the planned SAM monitors;
• one Linux server;
• one device with several volumes or many interfaces for element sizing;
• at least one more demanding application monitor;
• one intentionally unsupported specialist case to define how exceptions will be handled later.

The pilot should validate more than metrics. Also test:

• firewall flows;
• behavior during WAN interruption;
• forwarding of buffered data after reconnect;
• alerting;
• discovery and node reassignment;
• upgrade behavior;
• Collector CPU/RAM load;
• actual element consumption.

Conclusion

Additional Polling Engine and Platform Remote Collector solve different problems.

An APE provides much higher capacity and broader feature coverage, but requires tighter integration with the central SolarWinds Platform and database. A Remote Collector reduces those trust paths significantly and is therefore particularly attractive for DMZs, branch offices, cloud networks, and high-latency/low-bandwidth scenarios. In return, it has a clear 1,000-element-per-Collector limit and functional restrictions.

For DMZ projects, the Remote Collector is therefore often the first architecture to evaluate from both a functional and security perspective. The final decision should only be made after element counts, exact monitor types, Agent usage, licensing, and security rules have been checked against the actual support matrix.

If you want to review your SolarWinds polling architecture, DMZ segmentation, or existing monitoring landscape, see Observability & Monitoring. For a concrete architecture review, contact heureka.

Sources and further reading

• SolarWinds Scalability Engine Guidelines
• SolarWinds Port Requirements
• SolarWinds Platform Optimization Checklist
• Use SolarWinds Platform Remote Collector with SAM
• SolarWinds API Poller Requirements
• SolarWinds Platform Requirements