none
DCOM was unable to communicate with the computer SQL9 using any of the configured protocols; requested by PID 46a8 (C:\Windows\system32\ServerManager.exe).

    Întrebare

  • We are running a Windows Server 2012 cluster and I see the following error in the System folder of Event Viewer.

    "DCOM was unable to communicate with the computer SQL9 using any of the configured protocols; requested by PID     46a8 (C:\Windows\system32\ServerManager.exe)."

    SQL9 was in the cluster at one point, but it had hardware issues so it was removed from the cluster in the cluster admin.  Because it had bad hardware, SQL9 was taken off the network and salvaged for parts.  

    I have searched the registry for any reference to SQL9 and did not find anything.  I have searched the C: drive of all servers in the cluster and not found anything.

    I would like to eliminate this error, does anyone know how to?

    joi, 2 mai 2013 15:37

Răspunsuri

  • I experienced the same problem after removing a node (Node3) from my failover cluster. I tried different ways to resolve this issue but no luck. At the end, the error message itself provided me the hint: "DCOM was unable to communicate with the computer Node3 using any of the configured protocols; request by PID ???? (c:\Windows\System32\ServerManager.exe)" I thought this must be related to servermanager.exe.

    Launching Windows Manager (type servermanager.exe at prompt), and opening All Servers, I noticed Node3 was still listed there. Right-click it and select Remove Server. After removing it from Server Manager, this error (Event ID 10028) no longer occurs.

    Node3 was automatically added to All Servers in Server Manager at all other cluster nodes in Windows Server 2012 when Node3 joined the cluster. After removing Node3 from the cluster, the Server Manager at other cluster nodes still continue monitoring Node3. When Node 3 was turned off (as Lawrence mentioned above), Server Manager will report Event ID 10028 at all other cluster nodes.

    miercuri, 22 mai 2013 16:11
  • Thank you GongW:

    I did find the answer, when I remote desktop to one of the servers in the cluster and open "Server manager" and see that "Server manager" has a red item refering to the server that was retired and off the network in a planned fashion.  I removed it from "Server manager" and the event logs stopped filling up with errors.  The sad news is I have to do it on each server that was aware of SQL9.  Without your comment GongW, I am not sure I would have looked at it this way.  Thanks again.

    miercuri, 22 mai 2013 20:32

Toate mesajele

  • Hi,

    The reason why DCOM 10009 is logged is that: local RPCSS service can’t reach the remote RPCSS service of remote target server. There are many possibilities which can cause this issue.

    • The remote target server happens to be offline for a short time, for example, just for maintenance.
    • Both servers are online. However, there RPC communication issue exists between these two servers, for example:  server name resolution failure, port resources for RPC communication exhaustion, firewall configuration.
    • Even though the TCP connection to remote server has no any problem, but if the communication of RPC authentication gets problem, we may get the error status code like 0x80070721 which means “A security package specific error occurred” during the communication of RPC authentication, DCOM 10009 will also be logged on the client side.
    • The target DCOM |COM+ service failed to be activated due to permission issue. Under this kind of situation, DCOM 10027 will be logged on the server side at the same time.

    Of course, it’s caused by reason 1 in your scenario. You can ignore the event ID. If you want to prevent the event ID error messages from being logged in the system log, you can refer to this article to configure that. But I’m not sure which service you should to configure, you may explorer each service in DCOM Config and find the one related to SQL9.

    Event ID error messages 10016 and 10017 are logged in the System log after you install Windows SharePoint Services 3.0
    http://support.microsoft.com/kb/920783

    For more information please refer to following MS articles:

    Event ID 10009 — COM Remote Service Availability
    http://technet.microsoft.com/en-us/library/cc774368(v=WS.10).aspx
    Windows SBS 2008 Known Post Installation Event Errors
    http://support.microsoft.com/kb/957713

    Lawrence

    TechNet Community Support

    vineri, 3 mai 2013 07:57
    Moderator
  • I experienced the same problem after removing a node (Node3) from my failover cluster. I tried different ways to resolve this issue but no luck. At the end, the error message itself provided me the hint: "DCOM was unable to communicate with the computer Node3 using any of the configured protocols; request by PID ???? (c:\Windows\System32\ServerManager.exe)" I thought this must be related to servermanager.exe.

    Launching Windows Manager (type servermanager.exe at prompt), and opening All Servers, I noticed Node3 was still listed there. Right-click it and select Remove Server. After removing it from Server Manager, this error (Event ID 10028) no longer occurs.

    Node3 was automatically added to All Servers in Server Manager at all other cluster nodes in Windows Server 2012 when Node3 joined the cluster. After removing Node3 from the cluster, the Server Manager at other cluster nodes still continue monitoring Node3. When Node 3 was turned off (as Lawrence mentioned above), Server Manager will report Event ID 10028 at all other cluster nodes.

    miercuri, 22 mai 2013 16:11
  • Thank you GongW:

    I did find the answer, when I remote desktop to one of the servers in the cluster and open "Server manager" and see that "Server manager" has a red item refering to the server that was retired and off the network in a planned fashion.  I removed it from "Server manager" and the event logs stopped filling up with errors.  The sad news is I have to do it on each server that was aware of SQL9.  Without your comment GongW, I am not sure I would have looked at it this way.  Thanks again.

    miercuri, 22 mai 2013 20:32
  • Hi GongW,

    I did find the answer too.

    Thanks for your comment , GongW.

    Thanks a lot.


    Love SQL

    miercuri, 29 iulie 2015 07:26
  • I was having this issues as well, but it was a bit different.  My failover cluster was having continuous communication errors between nodes, part of it had to do with a memory leak in the switch they were plugged into and the other part had to do with DNS.  One of my 6 nodes could not do a lookup on another node and after investigating the issue it appeared that one of the Failover Cluster Nodes had been removed from DNS in AD.  So after re-adding the node in the DNS of the Active directory structure and re-adding the server in the Server Manager, resolved the issues with the cluster and is communicating again normally.
    miercuri, 17 mai 2017 19:22
  • I had a cluster with a failed node, once i have removed the cluster role the entries remains on the Server Manager as reference.

    I right click and removed them and issue resolved.

    miercuri, 16 mai 2018 19:35
  • Thanks i got the same problem.
    luni, 23 iulie 2018 03:40