vCenter Discovery: Unable to establish connection

[danielherre]

Hi community, a question about VMware Discovery.

We have 3 ServiceNow instances (DEV, PRE, PRO) which need to discover the same 2 VMware vCenters.
Each of the instances has an independent MID server, for all of them we have checked and confirmed network traffic is allowed in the firewall on TCP ports 443, 5480 y 9443.
VMware credential de VMware is the unique, has been configured on the three instances and Test Credential is successful for both vCenters, on th three instances.

From the DEV instance, we can successfully discover VMware CIs using a configuration items type discovery schedule.
But in PRE and PRO instances, using similar configuration and specifying the correct MID server, we are getting error message:
15/12/2025 17:23:25 Warning Unable to establish connection to https://<vCENTER_IP_ADDRESS>/sdk

From PRE MID Server, accessing https://<vCENTER_IP_ADDRESS>/mob from a browser is successful and the user pass grants us access.

Setting the MID server on debug log level, we only see one difference.
On the failing instance:
2025-12-12 14:53:06+0100 DEBUG (Worker-Standard:VMWareProbe-bdef6b011bf5b2501b92a9b1604bcb27) [MIDScriptIncludes:144] MID Script Include cache miss for name=VMWarevCenterDatacentersProbe
Whereas on a successful discpovery on the DEV instance we see:
2025-12-12 16:35:44+0100 DEBUG (Worker-Standard:VMWareProbe-4567c8d587b93e107356113e3fbb359b) [MIDScriptIncludes:104] MID Script Include cache hit for name=VMWarevCenterDatacentersProbe

Thanks!!

[SP22]

https://noderegister.service-now.com/kb?id=kb_article_view&sysparm_article=KB0830993

[danielherre · Accepted solution]

So I reply to myself. 
Although it was already done, we came again over setting  'Applies to: Specific MID servers' on the credential record, matching the MID server specified in the Discovery Schedule and it worked.

I don't have the confirmation but I guess this happened because the credential was manually added, but the Discovery Schedule was created using an Update Set, and because it has a specific MID Server defined something related to the sysid may have conflicted.

I mark the question as solved then, hope it helps for systematic troubleshooting approach in case it happens to anyone else.