Remote WMI Query Fails

[Todd Eichmann]

First off, if this is not the right group to post in, please direct me
accordingly. I've looked through the groups and this seemed to fit my
situation best.

I have a server that simply will not allow a connection/query via WMI (using
wbemtest, for example) from a remote machine. Locally (also using wbemtest),
I can connect just fine. The resulting error is as follows:

Number: 0x800706ba
Facility: Win32
Description: The RPC server is unavailable.

I'm frankly at an loss to provide an explanation for this behavior. The RPC
service is running fine. There are no errors in the event log(s) to tell
otherwise. Registry settings are identical to other servers in my
environment.

This particular server is a Windows Server 2003 R2 Enterprise x64 Edition
with SP2 installed. It is a member of a two-node windows cluster hosting SQL
Server 2005. Both nodes are of the same version and are at the same patch
level.

The weird part: Upon executing "netstat -an" I'm informed that there are
literally thousands of connections from the other node in the cluster to port
135 as shown below (172.16.28.190 is the server that I *cannot* connect to;
172.1.6.28.191 is the second node in the cluster which I can connect to just
fine):

Proto Local Address Foreign Address State
TCP 172.16.28.190:135 172.16.28.191:1026 TIME_WAIT
TCP 172.16.28.190:135 172.16.28.191:1027 TIME_WAIT
TCP 172.16.28.190:135 172.16.28.191:1028 TIME_WAIT
and so on....
TCP 172.16.28.190:135 172.16.28.191:4998 TIME_WAIT
TCP 172.16.28.190:135 172.16.28.191:4999 TIME_WAIT
TCP 172.16.28.190:135 172.16.28.191:5000 TIME_WAIT
...until the above which is the last connection.

My first inclination is that this is a worm of some sort, but why would it
only manifest on these two servers and why would it only be confined to one
node talking to the other node? TCPView reveals it as running under the
"system process" (PID 0) and I cannot find a running process that looks
suspicious.

Any advice on this would be met with great joy because, quite frankly, I'm
running out of ideas.

Thank you all for your time.

[Dave Sellars]

Todd

You could try running 'wireshark' on the network (an Ethernet packet
sniffer), which has some support for decoding MS-RPC and DCOM packets.
You might be able to determine whether the server is rejecting your
client passively (i.e. not allowing TCP connections) or whether it is
actively rejecting it in some way.

Sorry this isn't much detail to go on, but it's been a while since I
delved into the internals of the RPC packet-level protocol.

Dave.

Post by Todd Eichmann
First off, if this is not the right group to post in, please direct me
accordingly. I've looked through the groups and this seemed to fit my
situation best.
I have a server that simply will not allow a connection/query via WMI (using
wbemtest, for example) from a remote machine. Locally (also using wbemtest),
Number: 0x800706ba
Facility: Win32
Description: The RPC server is unavailable.
I'm frankly at an loss to provide an explanation for this behavior. The RPC
service is running fine. There are no errors in the event log(s) to tell
otherwise. Registry settings are identical to other servers in my
environment.
This particular server is a Windows Server 2003 R2 Enterprise x64 Edition
with SP2 installed. It is a member of a two-node windows cluster hosting SQL
Server 2005. Both nodes are of the same version and are at the same patch
level.
The weird part: Upon executing "netstat -an" I'm informed that there are
literally thousands of connections from the other node in the cluster to port
135 as shown below (172.16.28.190 is the server that I *cannot* connect to;
172.1.6.28.191 is the second node in the cluster which I can connect to just
Proto Local Address Foreign Address State
TCP 172.16.28.190:135 172.16.28.191:1026 TIME_WAIT
TCP 172.16.28.190:135 172.16.28.191:1027 TIME_WAIT
TCP 172.16.28.190:135 172.16.28.191:1028 TIME_WAIT
and so on....
TCP 172.16.28.190:135 172.16.28.191:4998 TIME_WAIT
TCP 172.16.28.190:135 172.16.28.191:4999 TIME_WAIT
TCP 172.16.28.190:135 172.16.28.191:5000 TIME_WAIT
...until the above which is the last connection.
My first inclination is that this is a worm of some sort, but why would it
only manifest on these two servers and why would it only be confined to one
node talking to the other node? TCPView reveals it as running under the
"system process" (PID 0) and I cannot find a running process that looks
suspicious.
Any advice on this would be met with great joy because, quite frankly, I'm
running out of ideas.
Thank you all for your time.

[Todd Eichmann]

Hi Dave -

Thanks for the reply!

I did try using Wireshark and I captured a bunch of traffic, but I'm not
educated enough to make heads or tails of the information. Given the
messages that I'm seeing, I'm under the impression that "something just ain't
right". I'm seeing messages like "Local Limit Exceeded" and "Bind not
acknowledged" repeated over and over. In addition, I'm getting a lot of
header checksum errors in the packets.

Given this, I'm of the opinion that the server is receiving the
communication, but it's not understanding it or something similar - it's not
actively denying it.

Again, thanks for thought!
-Todd

Post by Dave Sellars
Todd
You could try running 'wireshark' on the network (an Ethernet packet
sniffer), which has some support for decoding MS-RPC and DCOM packets.
You might be able to determine whether the server is rejecting your
client passively (i.e. not allowing TCP connections) or whether it is
actively rejecting it in some way.
Sorry this isn't much detail to go on, but it's been a while since I
delved into the internals of the RPC packet-level protocol.
Dave.