- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
Framework
Agent Client Collector is an agent that is installed on infrastructure components. The Agent Client Collector executes commands on the machines it is installed on and sends output data to the ServiceNow instance.
Use Case
Helps Track server inventory, software installations and usage continuously with non-admin access and minimal network communication
ServiceNow Applications/Licensing
- Agent Client Collector for Visibility
- ITOM Cloud Services [For MID Less Approach]
- Will consume SU’s (subscription units) that are part of ITOM Entitlements
Architecture with MID Servers
- Inventory Data collection
- Push-based Discovery via agent for Windows, Linux, and macOS
- Credential-less Discovery
- Foundation for automation across Technology Workflows (ITSM, ITAM,ITOM, SecOps)
- Single TCP connection to a MID remains established with keep-alive allows bidirectional communication
(Agent Client Collector Framework Data Distribution)
Architecture without MID Servers
Framework
Agent Client Collector for DEX collects endpoint information for DEX. ACC, when used for DEX, does not use a MID server and connects directly to the ServiceNow Cloud via ITOM Cloud Services.
Agent Client Collector – Framework Architecture
- How does it work?
- After the installation, ACC is registered on your organization's ServiceNow instance and required certificates are downloaded from the instance. All the communication between ACC and your instance happens over secured HTTPs.
- After the ACC registration, a connection with the ServiceNow shared services is established. The agent is authenticated with the shared services via the downloaded certificates.
- The ACC opens a bi-directional communication with the ServiceNow shared services using gRPC Remote Procedure Calls (gRPC) connection. gRPC connection is a secure and encrypted channel to send and receive data from the endpoints. The channel is secured via mutual Transport Layer Security (mTLS).
- The ACC sends various devices and application performance metrics to the shared services.
- The ServiceNow shared services use the ServiceNow Hermes Messaging Service and Stream Connect to isolate the organization’s data.
- Raw metrics collected from endpoints are processed further using the shared services and eventually pushed to the ServiceNow instance.
When using ACC with DEX or ACC-V (MID-less), mTLS authentication is used to establish a secure connection between ACC and the ServiceNow Cloud. This is a multiple step process that involves several steps. If any step fails due to network or instance configuration, the agent will not successfully register. See "Special network considerations" below for more information.
The Agent registration process involves the following steps.
- On the customer instance, a registration key is automatically generated for the Agent Client Collector (Agent).
- The Agent is installed in the customer instance using the registration key, instance URL, and public endpoint.The instance URL corresponds to the INSTANCE_URL variable in the one-line installer command. The public endpoint refers to the DNS name of the nearest ServiceNow Cloud Services endpoint, which is represented by the value of the ACC_CNC variable in the one-line installer command. For information on the command and the parameters, see Install Agent Client Collector on Windows using ITOM Cloud Services and Perform a single-line Agent Client Collector installation on macOS by using ITOM Cloud Services.
- The Agent sends registration request to the customer instance.
- The Agent is registered in the customer instance and issued a certificate.
- The Agent saves both the issued certificate and the public key used for verifying code signing signatures.
- The Agent communicates with the customer instance through the ServiceNow Cloud Services by sending messages.
- ServiceNow Cloud Services determine the correct customer instance to which agent messages must be sent.
With this approach since the data is managed in ServiceNow's shared infra, data isolation and access becomes a prominent question. Here is how its done,
Data isolation
Your data is stored in a separate topic when the Hermes Messaging Service and Stream Connect persist in the file system while data is sent and received. The agent client certificate issued by your ServiceNow instance holds the instance name for your organization. After the agent is authenticated, the instance name from the agent certificate is used to keep data isolated within a shared services cluster. mTLS is used for a secure communication between the agent and server components. The agent authenticates itself using a client certificate with the following parameters:
- Public Key Algorithm: id-ecPublicKey (ECDSA)
- Key Size: 256-bit
- Elliptic Curve: NIST Curve P-256
The setup promotes strong encryption and efficient key exchange using elliptic curve cryptography.
Data access
All collected data is transformed and presented on the customer ServiceNow instance. Any data collected in the context of DEX is visible to users only with appropriate DEX roles. For more information about the DEX roles, see Installed with DEX. When following the standard ServiceNow practices on data governance, no special handling is required for DEX.
Data retention
All the raw metrics collected from devices are stored in the ServiceNow instance for a maximum of seven days. Aggregated metrics are stored for a longer duration based on the type of aggregation. Aggregation metrics are used to show trend lines for various metrics. Hermes Messaging Service stores data for 36 hours by default. No other ServiceNow shared services store any metric data in transit.
Considerations while choosing either approach
| MID Server Based Asset Discovery | MID Less Asset Discovery |
|
|
The Agent Client Collector (ACC) framework represents a significant evolution in ServiceNow’s approach to asset discovery and endpoint visibility. By offering both MID Server–based and MID-less architectures, ACC provides flexibility for organizations to choose the model that best aligns with their infrastructure, security posture, and operational goals. Its secure, certificate-driven communication using mTLS ensures data integrity and isolation, while leveraging ServiceNow shared services for scalability and resilience.
Whether deployed for ITOM Visibility or Digital Employee Experience (DEX), ACC simplifies discovery, reduces dependency on credentials, and enables continuous inventory tracking with minimal network overhead. This foundation not only streamlines IT operations but also sets the stage for advanced automation across ITSM, ITAM, ITOM, and SecOps workflows. As organizations move toward cloud-first strategies and zero-trust environments, ACC’s architecture ensures compliance, security, and efficiency—making it a cornerstone for modern enterprise service management.
Helpful References
- Agent Client Collector FAQs: https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB0815247#mcetoc_1fqda79ft2f
- Detailed overview of ACC‑V capabilities, supported OS, and push-based discovery : https://www.servicenow.com/docs/bundle/xanadu-it-operations-management/page/product/agent-client-col...
- Installing MID-less Agent Client Collector (ITOM Cloud Services) : https://www.servicenow.com/docs/bundle/yokohama-it-operations-management/page/product/agent-client-c...
- KBs on TLS, certificates, troubleshooting, and more : https://support.servicenow.com/kb?id=kb_article_view&sysparm_article=KB1122613
- ITOM Academy webinar demo on ACC-V server/endpoint discovery : https://www.youtube.com/watch?v=bP-VOCBiLKQ
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.