This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Remove From My Forums

Event 21006 - Error code is 10061L on SCOM Agents

Question
0

Sign in to vote
Scenario:

Ver: SCOM 2019

Agents OS: Windows Server 2012R2

There are total 52 SCOM agents that are configured to report to their Gateway server. Gateway server is communicating well with its Management Server. Gateway server and SCOM agents are in different Domain than Management Server. Agents and Gateway server are Domain Joined (same).

Problem:

50 out of 52 agents are greyed out in the console. Following event is appearing frequently on troubled agents:

EventID 21006

The OpsMgr Connector could not connect to abc.com:5723. The error code is 10061L(No connection could be made because the target machine actively refused it.). Please verify there is network connectivity, the server is running and has registered it's listening port, and there are no firewalls blocking traffic to the destination.

Steps Tried:

1. Agents can communicate with the gateway server on port 5723 via IP but not Domain Name

2. Verified: Management Group and Gateway servers are configured correctly on the agents

3. Reinstalled the agent on few servers

Please help me in resolving this issue.

Be Vanmost!
- Edited by Pauciloquent Tuesday, July 28, 2020 8:01 AM
Tuesday, July 28, 2020 7:56 AM

All replies

0

Sign in to vote
The agents must be able communicate with the gateway using its domain name, so I would start by troubleshooting dns resolution.

What server is "abc.com:5723"? The gateway?
- Edited by CyrAz Tuesday, July 28, 2020 9:43 AM
Tuesday, July 28, 2020 9:43 AM
0

Sign in to vote
Hi,

SCOM uses the DNS/domain hostname to communicate, so you need to make sure the DNS/domain names are resolvable.

Best regards,
Leon

Blog: https://thesystemcenterblog.com LinkedIn:
- Edited by Leon Laude Tuesday, July 28, 2020 9:45 AM
Tuesday, July 28, 2020 9:44 AM
0

Sign in to vote

Yes, it's a Gateway server
Be Vanmost!

Tuesday, July 28, 2020 10:11 AM
0

Sign in to vote

Yeah y'all are right because if I run tracert to the gateway using domain name, it tries with IPv6 but if I force it to use ipv4, it works.

I have already informed my network team that they need to check if domain name resolution is working.

Thanks a heap. I will keep y'all posted.

Thy Fere
Be Vanmost!

Tuesday, July 28, 2020 3:46 PM
0

Sign in to vote
Hi,

If we want to check if a host can be resolved, we may use the nslookup command, as shown below

assuming cm16 is the gatetway server. From any affected agents, run the nslookup command.

Hope the above information helps.

Regards,

Alex Zhu
-----------------------------------------------
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com.
- Edited by AlexZhu_775Microsoft contingent staff Wednesday, July 29, 2020 7:26 AM
Wednesday, July 29, 2020 7:24 AM
0

Sign in to vote

So upon further troubleshooting, here is update:

As we know that traceroute and port query via IP works from affected computers to gateway server. But FQDN doesn't work. Interestingly, if I run nslookup from affected computers, it works.

If traceroute to gateway server from the affected computers via FQDN, it prefers ipv6 and fails. Same happens in case of port query too but not NSLOOKUP.
Be Vanmost!

Wednesday, July 29, 2020 12:30 PM
0

Sign in to vote

If you're not using IPv6, you could try disabling it on the affected computers.

You could also add the hostnames & IP addresses to the Hosts file so they are resolving correctly.
Blog: https://thesystemcenterblog.com LinkedIn:

Wednesday, July 29, 2020 12:34 PM
0

Sign in to vote
If you're not using IPv6, you could try disabling it on the affected computers.

You could also add the hostnames & IP addresses to the Hosts file so they are resolving correctly.

Blog: https://thesystemcenterblog.com LinkedIn:

It's however not a good practice to disable IPv6, so I would avoid it except for troubleshooting.

Having nslookup work is not a very good indication that general system resolution works : nslookup doesn't rely on system DNS client, it's a tool that explicitely send DNS queries to a DNS Server. Said otherwise, it's a DNS client itself and not the one used by the rest of the system. It also bypasses the DNS resolution cache for the same reason.

So we're still at the same point : you need to find why these computers are unable to properly resolve DNS names.
- Edited by CyrAz Wednesday, July 29, 2020 12:51 PM
Wednesday, July 29, 2020 12:50 PM
0

Sign in to vote

Thanks CyrAz. Very well-explained. I will keep y'all posted.
Be Vanmost!

Wednesday, July 29, 2020 12:57 PM
0

Sign in to vote

Thanks Leon.

In fact, we know that there is some issue with ipv6 along with DNS resolution; therefore, let's see what network folks find. Yes, host file is the workaround but these machines are domain joined and gateway server is also in the same domain; therefore, I expect everything should work perfectly.
Be Vanmost!

Wednesday, July 29, 2020 12:59 PM
0

Sign in to vote

Thanks Leon.

In fact, we know that there is some issue with ipv6 along with DNS resolution; therefore, let's see what network folks find. Yes, host file is the workaround but these machines are domain joined and gateway server is also in the same domain; therefore, I expect everything should work perfectly.

Be Vanmost!

If they are domain-joined then yes you should definitely work out on the DNS resolving issues.

One question: Has this issue started recently or did you just recently configure the agents to communicate to the Gateway servers?

Just curious if this has worked previously without any issues, or if any changes have been made, for example change of server/migration/upgrade...
Blog: https://thesystemcenterblog.com LinkedIn:

Wednesday, July 29, 2020 1:11 PM