ACC Application migration from one instance to another Instance using the same mid server host.

[VinjiPrak]

Dear Colleagues,

The goal is to migrate the ACC (Agent Client Collector framework from one instance to another without altering the configuration on the agents. Currently, there's a host with a mid server installed that connects to Instance A and successfully collects data from the agents. The plan is to migrate everything to Instance B.

Here's what has been done so far:

1. New Mid Server Installation: A new mid server has been installed on the same host. The original mid server, which was connected to Instance A, has been turned off.

2. Stopping Services on Instance A: The listener and websocket endpoint on Instance A have been stopped to prevent further data collection.

3. Configuring ACC Listener on Instance B: The next step is to set up the ACC listener on Instance B. This involves configuring the mid server to connect to Instance B using port 443.

However, an error is occurring during the ACC listener on the Instance B 'Error - Failed to setup the agent client collector. MID web server creation didnt succeed'

[Doci1]

OK, so the result of the UI Action is "Failed to setup the agent client collector.... " I would start to check what is the exact reason based on ecc_queue. Because the error is just generic... but before that, I would restart the machine on which is MID server running and try it again.

[VinjiPrak]

Hi @Doci1 

I tried restarting the mid server host, but the result remains same. 

Thanks

[AJ-TechTrek]

Hi @VinjiPrak ,

As per my understanding, below might help to provide the solution steps.

What’s happening:


The ACC listener on the MID server needs to open a local web server (by default on port 443 or 4443).
If:
* the port is already in use
* there’s a permission issue
* or an incomplete cleanup from the old MID/ACC setup
then the ACC listener startup will fail.

Solution steps
1. Clean up previous MID & ACC services
Even if you turned off the MID for Instance A:
* Make sure the old ACC listener service (Java process) is fully stopped
* Check your MID server logs on the host and verify there isn’t an old process still binding to the port
Tip:
On Windows:
netstat -aon | findstr :443
tasklist /fi "pid eq <PID>"
Stop any process using port 443 (or whichever ACC listener port).

2. Confirm the new MID has correct permissions
The MID server needs permission to:
* Open a local web server on the chosen port (typically requires Administrator or elevated permissions if <1024)
* Bind to the port
On Windows: run the MID service as Local System or an account with the correct permission.

3. Avoid using port 443 for local ACC listener
Port 443 is often already used by IIS, Apache, Nginx, or Windows services.
Instead:
* Edit the new MID server config (in service-now.xml or from the MID server properties in ServiceNow)
* Set the ACC listener to run on a non‑conflicting port, e.g. 4443 or 8443.
In MID server properties:
mid.acc.listener.port=4443
Note: This is the port the MID listens on locally to receive data from agents; the MID still sends data to the ServiceNow instance over outbound port 443.

4. Restart MID server & validate
* Restart the new MID service
* Check logs in:
<mid install dir>\agent\logs\agent.log
and specifically:
<mid install dir>\agent\logs\acc.log

Look for Successfully started ACC listener on port .

5. Confirm instance-side ACC configuration
* On Instance B, make sure you have the ACC plugin activated: com.snc.acc
* Go to:
MID Server → Agent Client Collector → Listeners
and confirm the new MID is registered and listener status shows as Up.

6. Verify WebSocket and connectivity
* Instance B must allow inbound WebSocket connection from MID server (the MID always initiates the connection outbound to ServiceNow, so usually no firewall issues)
* Make sure no outbound restrictions for MID → Instance B on port 443

7. Migrate agent binding (very important!)
ACC agents installed on endpoints register to the MID server and instance by:
* MID server GUID & instance URL
If you want to migrate without reinstalling agents:
* Export the ACC binding file from Instance A
* Import into Instance B
ServiceNow docs: Migrate ACC framework between instances
If skipped, agents may keep trying to send data to Instance A.

Summary – why your error happens
* Old MID or process is still binding to port 443
* Permission issue: MID can’t bind to port <1024
* Port conflict (443 already used by web server)

Best fix:
* Use a new port (4443 / 8443)
* Ensure only one ACC listener runs on the host
* Confirm correct permissions

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025