Help diagnosing MID Server connection error

Refocused Dad
Kilo Expert

We have an integration that runs a series of queries against a database through the MID Server. The MID is on a linux host. It's been running fine. However, it suddenly started failing to connect to the database. We did not find any changes on the network that couldv'e caused it and eventually the MID Server itself went down after trying to restart in hopes to clear the problem. Looking at the logs revealed this error at the time the connection stopped working.

04/27/20 08:00:48 (965) RefreshMonitor.65 WARNING *** WARNING *** Method failed: (https://*****.servicenowservices.com/ecc_agent_property.do?SOAP&displayvalue=all&redirectSupported=true)HTTP/1.1 500 Internal Server Error with code: 500
04/27/20 08:00:48 (966) RefreshMonitor.65 SEVERE *** ERROR *** getRecords failed (com.glide.processors.soap.SOAPProcessingException: Field(s) present in the query do not have permission to be read com.glide.processors.soap.SOAPProcessingException: Field(s) present in the query do not have permission to be read)

Any tips on where else to look? Permissions did not change mid-stream, it literally starting failing within minutes of a previously successful query. 
1 ACCEPTED SOLUTION

Refocused Dad
Kilo Expert

Closing the loop on this. It was an ACL issue. The sys_metadata ACLs which cascade down to ecc_agent_property were modified by another admin to require a particular role which the mid did not have. So if you see a similar issue, check your ACLs. You can first validate by give your mid admin role to see if the problem goes away. If it does go away, you know it's ACL related and you can begin researching to find out which ACL is causing the issue. 

View solution in original post

4 REPLIES 4

Ashutosh Munot1
Kilo Patron
Kilo Patron
Hi, Check this. https://hi.service-now.com/kb_view.do?sysparm_article=KB0779697 https://community.servicenow.com/community?id=community_question&sys_id=265803eddb1cdbc01dcaf3231f9619b7 Thank you, Ashutosh

Thanks for trying Ashutosh. Those were unrelated. I have created a ticket with HI. 

HI,

Great. Keep us posted.


Thanks,
Ashutosh

Refocused Dad
Kilo Expert

Closing the loop on this. It was an ACL issue. The sys_metadata ACLs which cascade down to ecc_agent_property were modified by another admin to require a particular role which the mid did not have. So if you see a similar issue, check your ACLs. You can first validate by give your mid admin role to see if the problem goes away. If it does go away, you know it's ACL related and you can begin researching to find out which ACL is causing the issue.