nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Najděte více příspěvků označených jako

Accepted answers

All comments

marceloctorres

I'm experiencing the same issue with Monitor Agent 2025.0. I tried to check the Agent service logs at C:\Users\arcgis\AppData\Local\ESRI\ArcGISMonitor\config-store-agent\logs (where arcgis is the local account running the Monitor Agent service) and noticed the folder C:\Users\arcgis\AppData\Local\ESRI does not exist. I uninstalled and reinstalled the software using different local accounts, but the behavior remains the same. I even manually created the folders, granted Full Control permissions to the local account, and also copied the folders and files from another working Agent service at other machine, but it still doesn't work.

LachlanWainwright

Hi @marceloctorres

Based on where us poor souls can't even get the agent to start 😁 Monitor 2025 Agent service not starting on server

Maybe change the logging to see what comes up when the agent is started, these are @JeffMertzXcel instructions. I have just changed to the agent exe, bolded bit.

Something might appear that could help....

PS C:\Users\Administrator> cd \
PS C:\> cd esri
PS C:\esri> cd .\ArcGIS\Monitor\Server\bin\
PS C:\esri\ArcGIS\Monitor\Server\bin> $env:LOG_LEVEL='debug'
PS C:\esri\ArcGIS\Monitor\Server\bin> .\arcgis-monitor-agent.exe --serve

Also, just poking about, try running some of these to see what appears that may help....

Note, this is for a working 2024.1.1 agent,
arcgis-monitor-agent.exe -help

StevenB1

Hi Marcelo and Jeffrey

Can you test and confirm if either of the two issues I came across with another client might also be the reason why you are having issues registering your 2025.0 ArcGIS Monitor Agent with the Monitor Server and report back?

Reverse DNS Lookup (PTR Record) Issue:

2025.0 ArcGIS Monitor Agents seem to now require machines to have a Reverse DNS Lookup (PTR Record).

This has been captured in the AGM forums by an end user.

From what I tested, what seems to be happening is without a PTR Record, the monitor agents don't create their config-store directories under their service accounts. After a PTR Record was created for these machines, the monitor agent successfully created its config-store, and would successfully register with the monitor server.

gMSA Issue:

Another similar issue found was with the 2025.0 ArcGIS Monitor Agents when trying to change the local service account to a gMSA.

The Monitor Server had no issues having its service account changed from a local account to a gMSA. The 2025.0 Monitor Agents on the other hand, once I changed its local account to a gMSA, again we didn't have their config-store directories created so for a temporary workaround, we left these to either a local account or domain service account.

JeffGarcia

Hi Steven,

I am using Monitor 2024.1.1 so I believe my issue is a bit different. The config-store directories were successfully created and do exist under the service account user.

marceloctorres

Hello!

I did what you suggested and these are the results:

Additionally, these are the contents of the file arcgis-monitor-agent-service.wrapper.log:

StevenB1

Hi Marcelo
Because the nslookup command failed, if you can try having your IT group create a Reverse DNS Lookup Zone and PTR Records for each of your servers. See if this fixes your problem.

You can test with the nslookup command and see if a PTR Record does not exists for your servers.

marceloctorres

Hi Steven

These are the results:

StevenB1

Hi Jeff, sorry I missed the 2024.1.1 detail.

Can you run the Debug Log Level command as noted by Lachlan ?
This command and other troubleshooting steps were well documented by Esri in the ArcGIS Monitor User Group #3: Troubleshooting Strategies webinar.

Does your ArcGIS Monitor Agent account have the correct permissions to the config-store directories? Can you confirm if an an Administrative Account was used to install the Monitor Agents?

DerekLaw

All,

In ArcGIS Monitor 2025, we’ve identified a regression in the DNS lookup logic run in AM Server and AM Agent when they boot up. We’ve seen this manifest in certain environments with no DNS available or under certain DNS lookup/name resolution configurations.

We understand this is a critical issue and we are working on a fix to address this issue ASAP.

------------------------

@JeffGarcia - I realize you're using a different Monitor release, can you please try some of the suggestions posted by @StevenBeothy to help resolve your issue?

DerekLaw

UPDATE:

The Monitor Dev team just finished work on the patch for BUG-000177693. It is now in final test certification and we expect it to be available by mid to late August.

The underlying cause is related to DNS resolution (e.g., nslookup command) on the network, which is assessed when the ArcGIS Monitor software loads. This can be an issue for network environments without DNS or, in some unique network configurations where these DNS resolution commands fail.

We apologize for the inconvenience and thank you for your patience.

Hope this helps,

DerekLaw

UPDATE 2:

I've been informed by the release team that the ArcGIS Monitor 2025.0.1 patch was just published on MyEsri and is available for download now.

Hope this helps,

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!

Chris_Schofield

Thanks @Tim_White this helped me massively too 🙂

N8-CORR

I'm seeing the same issue on 2025.0 @marceloctorres. When I use a domain service account (not gMSA) the config-store directory is not created after installation. Thus resulting in the same error as OP.

StevenB1

I have fixed this issue in the past by

#1. I granted permission to the gMSA or Domain Service account to the "C:\Program Files\ArcGIS\Monitor" folder

#2. Manually updated the file (C:\Program Files\ArcGIS\Monitor\Agent\bin\.env) to include the gMSA or Domain Service user AppData folder path.

Another issue can be Tim_White's post on pg.3 of this thread Re: Unable to Register Monitor Agent
"Powershell was missing from the PATH environment variable on that specific server"

Please also be aware of this AGM 2025.0.1 patch.

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.

Připojte se ke konverzaci

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.