The Agent Was Installed and Running. It Had Never Connected.

ServiceNow ACC not connected: that was the state of one of our servers for months, while the Agent Client Collector service showed Running the whole time. The cause was one config line: backend-url pointed at 127.0.0.1, because DNS could not resolve the MID server address during install.

The symptom: Running, but never connected

On the surface, nothing was wrong. The ACC agent was installed, and its service showed Running. No alert fired. All we had checked was that the service was running. We never confirmed that the agent showed up in the console or was communicating.

But when we looked from the ServiceNow side, the picture was different: ITOM had no healthy connection from this server, and there was no record of a successful console connection in the months since install.

The agent was alive. It was just talking to nobody.

Root cause: a silent fallback to localhost

The answer was in the agent’s config file, acc.yml. The backend-url setting did not hold the MID server address. It held 127.0.0.1.

That explains everything. The backend URL pointed at the server itself, so the agent never established a working connection to ITOM. This server had no DNS settings, which most likely meant the MID server hostname could not be resolved when the agent was installed, and the value ended up as localhost. The service started anyway and reported Running.

Looking back, the sequence was probably something like this:

1. The server had no DNS configured.
2. At install time, the MID server hostname could not be resolved.
3. backend-url was written as 127.0.0.1.
4. The service started normally, with no error.
5. The backend URL pointed to the server itself, so the agent never established a working connection to ITOM.

We did not read the installer’s code, so we cannot say exactly where the fallback happens. What we can say is that nothing in the install or the service status warned us.

The agent was installed. The service was running. The config file contained what looked like a valid backend URL. What none of those showed was that the URL pointed back at the server itself.

Every check that is easy to run said the agent was fine. The one that mattered, a successful connection to the backend, had never happened.

The fix: point the agent at the real MID server

The actual fix was straightforward once we understood what was wrong. The hard part was finding out that the backend URL pointed back at the server itself.

1. On a healthy server with a working ACC, open its config and note the MID server URL.
2. Confirm the URL format. Ours looked like this, with the host masked here:

wss://<mid-server-fqdn>:443/ws/events

3. On the broken server, edit acc.yml and replace the 127.0.0.1 value in backend-url with that URL (simplified view):

# before
backend-url: 127.0.0.1

# after
backend-url: wss://<mid-server-fqdn>:443/ws/events

4. Make the hostname resolvable. This server had no DNS, so we added an entry to the hosts file:

<mid-server-ip>    <mid-server-fqdn>

5. Restart the ACC service so it reads the new config.

The hosts entry is a workaround for a server with no DNS. If you can, fix the DNS settings instead, so the next reinstall does not hit the same problem.

Verification: the log said it, then the checks agreed

After the restart, the agent log showed the line we had been missing:

keepalive response received from the backend

That line means the agent reached the backend and got an answer. We then checked the rest:

• The ACC service was running normally.
• Port 443 traffic to the MID server worked.
• The backend connection was healthy.
• The agent received its Discovery Policy.
• The agent received its CI ID.

The last two matter most. A Discovery Policy and a CI ID only arrive from the platform, so receiving them proves the agent is registered and working, not just alive.

Why we missed it for so long

Nothing on the server looked wrong. The service was running, the install had finished without complaint, and the config file held what looked like a normal URL.

There was no error to follow and no alert. We had checked that the service was running, and we never checked whether the agent actually appeared in the console or was communicating. From the operating system’s side, the agent was healthy.

The only place the problem was visible was ITOM, where the server had never connected. Checking the service status alone would never have found it.

Takeaways: verify the connection, not the service

This is a close cousin of the Rapid7 case from an earlier post, The Agent Was Running. Rapid7 Said It Was Offline. In both, a Running service hid a missing connection. The cause is what differs.

	Rapid7 agent	ServiceNow ACC
Service status	Running	Running
Console / ITOM	Offline	Never connected
Cause	A required setup step was skipped	A bad backend URL (127.0.0.1), most likely after DNS failed at install

The difference is what made this incident interesting. In the Rapid7 case, we missed a required step. In the ACC case, the installation completed successfully and the service started normally, but the backend configuration ended up unusable. One is a process problem. The other is a bad value you only find by checking for it.

A short checklist for any agent install:

• Confirm the server can resolve the backend hostname before you install.
• After install, open the config and read the backend URL yourself.
• Look for a success line from the backend in the agent log, not only a Running service.
• Confirm on the platform side that the server reports in and has received its policy.
• Alert on installed but not reporting, instead of on service state.

Running only tells you the process started. Connected tells you the agent is doing its job.