Unable to Register Monitor Agent

[JeffGarcia]

I have a multi-machine deployment and am attempting to register the monitor agent (2024.1.1) for the various enterprise (11.3) components. When attempting to register the agent, I am given the following error message: 
[ error ] Cannot access ArcGIS Monitor agent: CLI commands require the agent to be running.

I have confirmed the agent is up and running on my portal and server machines and am able to reach the monitor server endpoint 30443/arcgis via web browser. I have also modified my pg_hba.config file to include the proper IP addresses for the various machines in my network. Any suggestions or advice is greatly appreciated.

Thank you,

Jeffrey Garcia

[ErikLash_HiCo]

Test on my dev env which is in a canned domain config (nothing special/unique) - first agent registration attempt after registering the servers agent. Error saying that the agent is already registered.

This is a clean monitor server installation, new VM, patched installer from this week. The target vm has never been registered with it before and is not showing up as a registered host on the server.

Haven't tested any workarounds yet but so far not off to a great start.

Edit -

Found issue to be that  "C:\Users\[ArcGISMonitorServiceAccount]\AppData\Local\ESRI\ArcGISMonitor\config-store-client"  from the previously installed version of the software was left as a remnant after uninstallation and no longer editable? by the ESRI installer. 

Workaround was to craft a PowerShell script to delete that folder from all of my servers prior to installing the new agent software.

New agent installed on all of my production VMs including the ones in the DMZ. Note that it registered the DMZ machines by their IP instead of name, which is fine by me.

[CalvinHarmin]

I'm not sure if my issue is exactly matching others in this thread but I figure I ought to see if anyone has any pointers. I have a Windows Server 2019 VM with ArcMonitor Server and just upgraded 2025.0.1 and upgraded all of my Agents.

My federated Arc* machines are Portal, Server (my main/hosting server), Datastore, GeoEvent Server. I also have a postgres server and Cityworks server that I monitor.

All of my these machines have no trouble registering with Monitor except for my (hosting) Server machine. I have had 2023.x and 2024.x previously, and even tried a Linux VM instead of Windows hosting Monitor Server in the beginning. In all cases, all my machines register exactly as they are supossed to, but my Server machine cannot register with Monitor server. The registration makes the initial authentication call [success]! ... but then nothing else happens. Monitor site logs also record the two entries for the authentication call from my Server machine's IP (message 'API request started', 'API request ended'), but nothing else related to the registration event is logged (debug level enabled).

I had a months-long ESRI ticket that went nowhere. We went so far as to use wireshark and log the traffic happening -- it seems the connection is simply closed after the initial authentication call, with no other logs or indication of what is happening to cause the connection to close, whether it's being aborted by the Server or the Agent side. We have disabled anti-virus on both the Server and Monitor machines to test if that had any effect (nope), we've updated all of our machines with CA SSL certs for the backend communication just in case that had any effect (nope).

I've carefully followed every step in the documention to ensure the domain account running the ArcGIS Monitor Agent service has access to the bin, framework, and appdata config-store-agent directories. This account is also a local Administrator account, and it's in the Perfomance Monitoring Group.

Mind you -- no additional actions like this whatsoever were required when registering the Agents with Monitor on my other machines, which are all essentially the exact same in terms of VM/Windows base image, domain accounts as local admin, networking, etc.

Does anyone have *any* potential clue what might (not) be happening here?

[JeffGarcia]

Not sure if this is related since I was seeing a different error. We were able to resolve the issue I had originally posted about just yesterday with ESRI support. Our environment required us to set proxy environment variables for AWS CLI use which is what was blocking the monitor agent from registering with the monitor server. By adding the FQDN of the monitor server machine and localhost to the NO_PROXY variables this resolved the issue we had been encountering. May be worth checking on your end. Go to settings > advanced system settings > environment variables.

[Tim_White]

Had a very similar experience - and finally found the cause about an hour ago, which is that Powershell was missing from the PATH environment variable on that specific server (coincidentally our hosting server too). I believe the Agent attempts to take an inventory of the host it's running on prior to attempting the registration, and uses Powershell to do that.

Hope that helps!

[CalvinHarmin]

You hoped that helps! Omg… holy $&@!

I could kiss you. I want to buy you lunch. I praise your name and the names of your ancestors. Your little comment just solved a mystery that has plagued me for a year or more, and fruitless support cases that wasted literal days to weeks of my life.

I fully expected my server machine already had the path… but it didn't… my hopes began to rise…

I added the default powershell path

%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\

And closed the env var menus, tried to register… it didn't work.

I logged out logged back in to Windows… didn't work.

Almost gave up then realized I should restart the Agent Service since it maybe runs that powershell inventory on startup… and that finally did the trick.

A thousand thanks!

[Tim_White]

On behalf of me and my ancestors, you're welcome!

[CalvinHarmin]

By the way, how in the world did you figure that out? I couldn’t find any documentation or logs to point to anything like that, where some expected Agent component or process/procedure was not running as expected. I was in total darkness.

[Tim_White]

I definitely didn't figure it out on my own. My support ticket went through the local distributor here in NZ, which was escalated to Esri. I was sent a copy of the Agent that had more verbose logging, which showed where things were stalling, then a comparison with processes running on a host that had registered successfully revealed PS not running on the problem host. It ran fine manually using the service account credentials, but when I first looked I saw the PSModulePath variable was correct. Took a second look today and found the difference in the PATH variable.

So very much a team effort - but I'll take the lunch if you ever make it down this way! 🙂

[ChrisSchofield]

Thanks @Tim_White this helped me massively too 🙂

[ErikLash_HiCo]

Distributed network configurations rely on machine level configurations and  the challenges of his new approach to Monitor agents became too much for us.

Having to deploy agents them to a "Local User" app environment is definitely not a best practice for agentic monitoring. Beyond the obvious security problems related to deploying software to a users profile there are systemic issues with managing and configuring a software deployed like that.

We gave up on the entire ArcGIS Monitor platform and returned to basic log analysis of Web Server logs (System Log Parser) + regex of the IIS logs combined with PowerShell and Windows Admin Center.

Much simpler than trying to get ArcGIS Monitor installed, configured, and operating consistently.