⬡ Part 3 · Topic 5
Agent Client Collector (ACC) — Agent-Based Discovery for Modern Environments
Traditional Discovery connects to devices from the outside — it needs network access, credentials, and open ports. The Agent Client Collector (ACC) flips this model: a lightweight agent installed on each server proactively reports its own data to ServiceNow. No network scan needed, no credentials required, and it works even in cloud environments with strict security groups.
Section 1
The Agentless Discovery Problem
Traditional ServiceNow Discovery (covered in the previous topics) is agentless — it reaches into devices from the outside using SSH, WMI, or SNMP credentials. This is powerful, but has real-world limitations:
- Credential management at scale: In large environments (thousands of servers), managing SSH keys or WMI passwords for every server is operationally complex. When passwords rotate, Discovery breaks until credentials are updated.
- Cloud security group constraints: Cloud providers encourage locking down inbound SSH (port 22) to specific sources only. Allowing Discovery to SSH in from the MID Server requires firewall rule exceptions that many security teams resist.
- NAT and private IP environments: In some cloud configurations, servers have private IPs only. The MID Server can't route to them.
- Laptop and endpoint discovery: Laptops roam between networks, use VPNs, and have dynamic IPs. Agentless Discovery can't reliably find them.
- Real-time data requirements: Agentless Discovery is periodic (runs every few hours). For real-time visibility of rapidly changing data (processes, connections), periodic scans miss the current state.
Key Concept — Agent-Based vs. Agentless Discovery
Agentless Discovery (standard Discovery): External scan. MID Server
connects to target. Needs network access + credentials. Periodic.
Agent-Based Discovery (ACC): Lightweight agent installed on target.
Agent reports to ServiceNow. No external scan needed. Continuous.
Both result in CI records in the CMDB. They can be used together for maximum coverage.
Section 2
What Is the Agent Client Collector?
The Agent Client Collector (ACC) is a lightweight software agent installed on servers and endpoints. Once installed, it:
- Continuously collects configuration data from the host it's running on
- Makes outbound connections to ServiceNow (or a MID Server) to report this data
- Receives instructions from ServiceNow for on-demand data collection
- Sends collected data through IRE for CMDB update
The "Client" in the name refers to the fact that the agent acts as a client — it initiates outbound connections, just like a browser connecting to a website. This means no inbound firewall rules are needed on the target server.
Analogy — ACC as a Health App on Your Phone
Agentless Discovery is like a doctor examining you from the outside —
they can observe what's visible and measurable without your cooperation.
ACC is like a fitness app on your phone that constantly monitors your
heart rate, steps, and sleep — then sends the data to your doctor on demand.
The app (agent) runs on the device and reports outward.
The doctor (ServiceNow) receives rich, continuous data without needing
to "visit" the device.
ACC Editions
ServiceNow offers two ACC editions:
- ACC-D (Discovery): Focused on collecting CI configuration data for the CMDB. Replaces credential-based Discovery for supported platforms.
- ACC-M (Monitoring): Focused on real-time performance metrics collection for ITOM Event Management and AIOps. Sends CPU, memory, disk, process metrics continuously.
Both can run simultaneously on the same server. For the CIS-DF exam, ACC-D (Discovery) is most relevant.
Section 3
ACC Architecture — How It Connects
The ACC agent communicates with ServiceNow in two possible ways, depending on your network topology:
Direct Connection (Cloud-to-Cloud)
Server + ACC Agent
Cloud VM (EC2, Azure…)
›
ServiceNow Instance
Outbound HTTPS :443
The simplest topology. Works for cloud servers (AWS EC2, Azure VMs) that have outbound internet access. No MID Server needed.
MID Server Relay (Isolated Networks)
Server + ACC Agent
Private subnet (no internet)
›
MID Server
Internal relay (LAN access)
›
ServiceNow Instance
Outbound HTTPS :443
When the server is on a private subnet without direct internet access, the ACC agent connects to the MID Server (which is on the private network and can reach the internet). The MID Server relays ACC data to ServiceNow.
Exam Key — ACC Always Makes Outbound Connections
Both in direct and relay mode, the ACC agent makes outbound connections only.
No inbound ports need to be opened on the server running ACC.
This is a critical distinction from agentless Discovery (which needs inbound SSH/WMI access).
Section 4
ACC vs. Agentless Discovery — Full Comparison
| Dimension | Agentless Discovery (MID Server) | Agent-Based Discovery (ACC) |
|---|---|---|
| How it works | MID Server connects to target externally | Agent on target reports to ServiceNow |
| Credentials required on target | Yes — SSH, WMI, SNMP | No — agent is pre-installed with ServiceNow identity |
| Inbound ports on target | Yes — port 22 (SSH), 135 (WMI), 161 (SNMP) | No — agent makes outbound connections only |
| Data freshness | Periodic (scan interval — every few hours) | Continuous / near real-time |
| Works for roaming laptops? | No — needs fixed IP/network access | Yes — agent reports from wherever the laptop is |
| Works for strict security groups? | Limited — requires inbound SSH exceptions | Yes — only outbound HTTPS needed |
| Requires agent installation? | No — no software on target | Yes — agent must be deployed to each target |
| Scale of management | Credential management + network access rules | Agent deployment + auto-update management |
| What it discovers | Deep OS + hardware + software (depends on credentials) | OS + hardware + software + processes + connections (from inside) |
| CI goes through IRE? | Yes | Yes |
Key Concept — Neither Approach Is "Better" — Use Both
Agentless Discovery covers network devices (switches, routers) where you can't
install agents. ACC covers servers and endpoints where agent installation is
practical. Most large environments use both: ACC for servers/endpoints where
credentials are hard to manage, agentless Discovery for network infrastructure.
Section 5
What ACC Collects — Data and CI Types
The ACC agent has a rich collection capability because it runs on the target from the inside.
Hardware and OS Data
- CPU model, core count, speed
- RAM total and available
- Disk partitions, size, free space, mount points
- OS name, version, kernel (Linux) / build number (Windows)
- System serial number, BIOS version, manufacturer
- Network interfaces with IPs, MACs, interface names
- Domain membership (Windows)
Installed Software
- All installed packages (rpm, dpkg, Windows MSI + registry-based)
- Software versions
- Java, Python, Node.js runtimes and versions
Running Processes and Services
- All currently running processes with PIDs and users
- Active network connections (local and remote port/IP)
- Windows services (running/stopped/disabled)
- Linux systemd units
Cloud-Specific Data
When running on cloud instances, ACC can read the cloud instance metadata API:
- Cloud instance ID, region, availability zone
- Instance type
- Tags assigned to the instance in AWS/Azure/GCP
- IAM role / managed identity
This cloud metadata enriches the CI record beyond what OS-level collection can provide.
Tip — ACC Enriches CIs Already Created by SGC
A common pattern: SGC for AWS creates an EC2 instance CI with cloud-level properties
(instance type, tags, AMI). ACC running on that same instance adds OS-level properties
(kernel version, installed software, running processes). IRE reconciles both datasets
onto the same CI record. The result is the most complete CI possible.
Section 6
Deploying the ACC Agent
Unlike the MID Server (one per network segment), the ACC agent must be deployed to every server or endpoint you want to discover. At scale, this requires automation tools.
Deployment Methods
- Manual installation: Download the ACC installer from ServiceNow (Windows MSI or Linux RPM/DEB), run it on each server. Only practical for very small environments.
- Chef/Puppet/Ansible: Write infrastructure-as-code to deploy the ACC agent across your server fleet. ServiceNow provides documentation for major configuration management tools.
- Cloud-init / User Data: For cloud instances, embed ACC installation in the instance's user data script. Every new instance gets the agent automatically as it boots.
- Microsoft SCCM / Intune: For Windows endpoints (laptops, workstations), deploy via SCCM software push or Intune MDM policy.
- Docker / Kubernetes sidecar: For containerized environments, ACC can run as a sidecar container or as a DaemonSet in Kubernetes to monitor all nodes.
ACC Agent Registration
When the ACC agent starts for the first time, it registers with ServiceNow:
- Agent connects to the configured ServiceNow endpoint (instance URL or MID Server relay)
- Agent sends a registration payload with a unique identifier
- ServiceNow creates a pending agent record
- Admin approves the agent in ServiceNow (or auto-approval can be enabled)
- Agent begins sending discovery data
Warning — Auto-Approval Creates Security Risk
ACC agents with auto-approval enabled will start reporting data to your CMDB
immediately without admin review. In environments with strict controls,
require manual approval for all new agents. This prevents rogue or
misconfigured agents from polluting CMDB data.
Section 7
ACC in the Full Discovery Ecosystem
The complete ServiceNow discovery ecosystem uses multiple ingestion methods simultaneously. Here's how they work together:
| CI Type | Primary Discovery Method | Secondary Enrichment |
|---|---|---|
| AWS EC2 instances | SGC for AWS (API-based) | ACC agent for OS-level data |
| On-premise Linux servers | ACC agent OR agentless SSH Discovery | Service Mapping for application connections |
| Windows workstations / laptops | ACC agent (works everywhere) | Agentless Discovery when on corporate network |
| Cisco switches / routers | Agentless Discovery (SNMP) | No ACC — agents can't run on network OS |
| VMware VMs | SGC for VMware (vCenter API) | ACC agent for guest OS data |
| Kubernetes clusters | ACC DaemonSet on nodes | Service Mapping for microservice connections |
Key Concept — IRE Reconciles All Sources
When SGC, agentless Discovery, and ACC all report data about the same server,
IRE's Reconciliation Rules determine which source wins for each field.
For example: SGC for AWS is authoritative for instance_type;
agentless Discovery is authoritative for cpu_name;
ACC is authoritative for running_processes.
The CI record becomes a union of the best data from all sources.
Exam Quick Reference
Agent Client Collector — Key Facts
- ACC = lightweight agent installed on each server/endpoint. Reports outward to ServiceNow.
- No inbound ports needed. ACC makes outbound HTTPS only. Works through strict firewalls and security groups.
- No credentials needed on the target. Agent is pre-authenticated. Contrast with SSH/WMI in agentless Discovery.
- Works for roaming endpoints (laptops) — reports from wherever the device is connected.
- Near real-time data — continuous collection vs. periodic agentless scans.
- Direct mode: Agent → ServiceNow (cloud servers with internet access).
- Relay mode: Agent → MID Server → ServiceNow (private subnets).
- ACC-D = Discovery (CI data). ACC-M = Monitoring (performance metrics). Can run together.
- Deployed at scale via Chef, Puppet, Ansible, SCCM, cloud-init. Not practical manually at large scale.
- Works alongside SGC and agentless Discovery. IRE reconciles all sources.
- Agent must be approved/validated after registration (similar to MID Server validation).
Term Grid
Agent Client Collector (ACC)
Lightweight agent installed on servers/endpoints. Proactively reports configuration and performance data to ServiceNow via outbound HTTPS.
ACC-D
ACC Discovery edition. Collects CI configuration data (hardware, OS, software, processes). Populates CMDB via IRE.
ACC-M
ACC Monitoring edition. Collects real-time performance metrics (CPU, memory, disk, network). Feeds ITOM Event Management.
Agentless Discovery
Standard Discovery where the MID Server connects to targets externally using SSH, WMI, or SNMP credentials. No agent installed on target.
MID Server Relay
ACC deployment topology for private networks. Agent connects to MID Server, which relays data to ServiceNow. Target server needs no internet access.
ACC Registration
First-time connection of ACC agent to ServiceNow. Creates a pending agent record. Admin must approve (or auto-approve enabled) before data flows.
Exam Checkpoint
Practice Questions
Click any question to reveal the answer and explanation.
1. A security team refuses to open inbound SSH (port 22) from the MID Server to production servers, blocking agentless Discovery. Which alternative approach allows ServiceNow to collect CI data from those servers?
💡 What Discovery method requires no inbound ports on the target?
Answer: B — ACC is specifically designed for this scenario. The agent installed on each server makes outbound HTTPS connections to ServiceNow — no inbound SSH, WMI, or any other port needs to be opened on the server. The security team's restriction is fully respected. This is one of the primary use cases for ACC over agentless Discovery.
2. A company wants to discover CI data from company-issued laptops that roam between office networks, home networks, and VPN. Which Discovery approach is best suited?
💡 Laptops have dynamic IPs and move between networks. What works regardless of network location?
Answer: C — ACC is ideal for roaming endpoints. Because the agent makes outbound connections from wherever the laptop is (home network, office, VPN), it consistently reports to ServiceNow regardless of the current IP or network. Agentless Discovery (A) requires knowing the IP and having network access, which fails for roaming devices.
3. An AWS EC2 instance is in a private subnet with no direct internet access. You want to deploy ACC on this instance. What architecture enables ACC to reach ServiceNow?
💡 ACC has two connection modes. Which one handles private networks?
Answer: C — ACC supports a MID Server relay mode for private networks. The ACC agent connects to the MID Server (which is deployed in the same private network or in a network that can reach ServiceNow). The MID Server relays ACC data to ServiceNow. This is exactly the architecture for EC2 instances in private subnets.
4. What is the primary difference between ACC-D and ACC-M?
💡 D = Discovery. M = Monitoring.
Answer: B — ACC-D (Discovery) collects configuration inventory data (hardware, OS, software, network interfaces) and populates the CMDB through IRE. ACC-M (Monitoring) collects real-time performance metrics (CPU usage, memory, disk I/O, network throughput) and feeds them to ITOM Event Management and AIOps. Both can run on the same server simultaneously.
5. After deploying ACC agents to 500 new cloud servers, no new CI records appear in the CMDB despite the agents showing as connected. What is the most likely cause?
💡 What gate exists between agent registration and data flow?
Answer: B — When ACC agents register with ServiceNow for the first time, they enter a "pending approval" state. Data does not flow until the admin approves each agent (or auto-approval is enabled). This is analogous to MID Server validation. Check the ACC Agent records in ServiceNow and approve them. ACC does not use SSH credentials (A) or Import Sets (D).
6. Network switches and routers need to be discovered in ServiceNow. You already have ACC agents deployed on all servers. Can ACC be used for network device discovery?
💡 Can you install a software agent on a Cisco IOS switch?
Answer: B — Network devices like Cisco switches and routers run specialized firmware (IOS, Junos, etc.) that doesn't support installing third-party software agents. ACC requires an installable agent, which is not possible on network hardware. For network devices, agentless Discovery using SNMP is the correct approach — it queries the device externally without requiring any software installation.
Exam Checkpoint
Practice Questions
4 questions · Select an answer to see the explanation immediately.
Agent Client Collector Quiz
1 / 4
A security team refuses to open inbound SSH (port 22) from the MID Server to production Linux servers. Which approach lets ServiceNow discover these servers without requiring inbound ports?
💡 Explanation
B is correct. ACC is specifically designed for environments where inbound connections are restricted. The agent installed on the server makes outbound HTTPS connections to ServiceNow — the server doesn't need any inbound ports opened. This is one of ACC's primary advantages over agentless Discovery. SNMP (D) still requires inbound port 161 on the device; it doesn't solve the security team's concern.