RPC server is unavailable

[Scott Elgram]

Hello,
I have recently been experiencing a problem on many of the computers on
my network. All these affected systems are having trouble logging off.
From what I have been able to find out I believe that this problem is some
how related to similar errors like this:
-------------------------------------------
The COM+ Event System failed to fire the Logoff method on subscription
{AAD1D51F-1279-4831-8684-D99F99B3CC62}. The subscriber returned HRESULT
800706BA.
-------------------------------------------
After some research into these problems I found that 800706BA refers to
0x800706BA which means "The RPC server is unavailable". This is where I'm
stuck......if I am understanding this right it's a problem with my Win2k
Server and or the communication between the server and the affected
machines. I also found that this is a side effect from the MSBlaster virus
because it utilizes DCom and the RPC server for it self. So I ran scans but
found nothing.

Any suggestions on how I may resolve this please?

 

[Steven L Umbach]

See the link below for more details as this is often a name resolution or
network connectivity problem. Your domain clients should be able to ping the
domain controller by it's IP address and fully qualified domain name as in
dc1.mydomain.com as an example of a FQDN. The domain controller should be
able to do the same for the domain clients. Look in Event Viewer on the
domain controller to see if any related events are being recorded that may
help you resolve the problem such as failed services,etc. The support tool
netdiag and dcdiag are also very helpful in tracking down domain
configuration/network connectivity problems. Use netdiag on any computer and
dcdiag on just domain controllers. Dns misconfiguration in the domain for
domain clients [Windows 2000/XP/2003] and/or domain controllers also is
often the cause of such problems. If you are using downlevel clients in the
domain, netbios name resolution also needs to be correctly configured with
domain controllers also being wins clients. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q224370
http://support.microsoft.com/default.aspx?scid=kb;en-us;321708 --- netdiag
and how to install support tools.
http://support.microsoft.com/default.aspx?scid=kb;en-us;291382 -- AD
dns FAQ.

 

[Scott Elgram]

I ran NetDiag on some of the affected machines and received pass on all
tests performed, additionally, I ran DcDiag on the domain controller and
received a pass on all tests performed except
-------------------------------------------------------------------------
Starting test: MachineAccount
* MAINSERVER is not trusted for account delegation
......................... MAINSERVER failed test MachineAccount
-------------------------------------------------------------------------
If I am reading this right the above failed test doesn't matter because my
DC is the only one on the network. Is this correct?, any other thoughts on
this matter?

-Scott

See the link below for more details as this is often a name resolution or
network connectivity problem. Your domain clients should be able to ping the
domain controller by it's IP address and fully qualified domain name as in
dc1.mydomain.com as an example of a FQDN. The domain controller should be
able to do the same for the domain clients. Look in Event Viewer on the
domain controller to see if any related events are being recorded that may
help you resolve the problem such as failed services,etc. The support tool
netdiag and dcdiag are also very helpful in tracking down domain
configuration/network connectivity problems. Use netdiag on any computer and
dcdiag on just domain controllers. Dns misconfiguration in the domain for
domain clients [Windows 2000/XP/2003] and/or domain controllers also is
often the cause of such problems. If you are using downlevel clients in the
domain, netbios name resolution also needs to be correctly configured with
domain controllers also being wins clients. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q224370
http://support.microsoft.com/default.aspx?scid=kb;en-us;321708 --- netdiag
and how to install support tools.
http://support.microsoft.com/default.aspx?scid=kb;en-us;291382 -- AD
dns FAQ.

 

[Steven L Umbach]

Did netdiag show a pass for everything on the domain controller?? The error
below is significant. Find the computer account for the DC in AD Users and
Computers and look in properties and make sure "trust computer for
delegation" is checked which domain controllers should be. I don't know if
that is the krux of the problem but that would be a good start and then see
if that error goes away with dcdiag or not. I don't know if the domain
controller needs to be restarted after enabling for delegation. If the error
in dcdiag persists it would be a good idea to restart it if it will not
cause too much disruption. Also see if there are any pertinent events in
Event Viewer on the domain controller that may be helpful. --- Steve

I ran NetDiag on some of the affected machines and received pass on all
tests performed, additionally, I ran DcDiag on the domain controller and
received a pass on all tests performed except
-------------------------------------------------------------------------
Starting test: MachineAccount
* MAINSERVER is not trusted for account delegation
......................... MAINSERVER failed test MachineAccount
-------------------------------------------------------------------------
If I am reading this right the above failed test doesn't matter because my
DC is the only one on the network. Is this correct?, any other thoughts
on
this matter?

-Scott

See the link below for more details as this is often a name resolution or
network connectivity problem. Your domain clients should be able to ping the
domain controller by it's IP address and fully qualified domain name as
in
dc1.mydomain.com as an example of a FQDN. The domain controller should be
able to do the same for the domain clients. Look in Event Viewer on the
domain controller to see if any related events are being recorded that
may
help you resolve the problem such as failed services,etc. The support
tool
netdiag and dcdiag are also very helpful in tracking down domain
configuration/network connectivity problems. Use netdiag on any computer and
dcdiag on just domain controllers. Dns misconfiguration in the domain for
domain clients [Windows 2000/XP/2003] and/or domain controllers also is
often the cause of such problems. If you are using downlevel clients in the
domain, netbios name resolution also needs to be correctly configured
with
domain controllers also being wins clients. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q224370
http://support.microsoft.com/default.aspx?scid=kb;en-us;321708 --- netdiag
and how to install support tools.
http://support.microsoft.com/default.aspx?scid=kb;en-us;291382 --
AD
dns FAQ.

Hello,
I have recently been experiencing a problem on many of the computers on
my network. All these affected systems are having trouble logging off.
From what I have been able to find out I believe that this problem is some
how related to similar errors like this:
-------------------------------------------
The COM+ Event System failed to fire the Logoff method on subscription
{AAD1D51F-1279-4831-8684-D99F99B3CC62}. The subscriber returned
HRESULT
800706BA.
-------------------------------------------
After some research into these problems I found that 800706BA refers to
0x800706BA which means "The RPC server is unavailable". This is where I'm
stuck......if I am understanding this right it's a problem with my
Win2k
Server and or the communication between the server and the affected
machines. I also found that this is a side effect from the MSBlaster
virus
because it utilizes DCom and the RPC server for it self. So I ran
scans
but
found nothing.

Any suggestions on how I may resolve this please?

 

[Scott Elgram]

Yes, Netdiag showed Pass on the DC too. I checked the "Trust computer for
delegation" and re-ran DCDiag and now all tests pass. But the problem is
still showing up in the logs of some machines. I have not rebooted the DC
yet and probably will not be able to for some time.
Last week I went through the Event log of every computer on the network
and discovered that all the affected systems have MSN Messenger installed
and the unaffected machines do not. This lead me to think maybe it could be
a problem between the machines and the MSN server because of my firewall.
After looking into it some more I remembered that this issue did not start
until about a month ago and there have been no significant changes made to
it that could affect communication between a computer on the network and the
internet. Just for kicks though I checked the log and could not find any
entry coinciding with the messages in the event logs.

-Scott

Did netdiag show a pass for everything on the domain controller?? The error
below is significant. Find the computer account for the DC in AD Users and
Computers and look in properties and make sure "trust computer for
delegation" is checked which domain controllers should be. I don't know if
that is the krux of the problem but that would be a good start and then see
if that error goes away with dcdiag or not. I don't know if the domain
controller needs to be restarted after enabling for delegation. If the error
in dcdiag persists it would be a good idea to restart it if it will not
cause too much disruption. Also see if there are any pertinent events in
Event Viewer on the domain controller that may be helpful. --- Steve

I ran NetDiag on some of the affected machines and received pass on all
tests performed, additionally, I ran DcDiag on the domain controller and
received a pass on all tests performed except
-------------------------------------------------------------------------
Starting test: MachineAccount
* MAINSERVER is not trusted for account delegation
......................... MAINSERVER failed test MachineAccount
-------------------------------------------------------------------------
If I am reading this right the above failed test doesn't matter because my
DC is the only one on the network. Is this correct?, any other thoughts
on
this matter?

-Scott

See the link below for more details as this is often a name resolution or
network connectivity problem. Your domain clients should be able to

ping
the

domain controller by it's IP address and fully qualified domain name as
in
dc1.mydomain.com as an example of a FQDN. The domain controller should be
able to do the same for the domain clients. Look in Event Viewer on the
domain controller to see if any related events are being recorded that
may
help you resolve the problem such as failed services,etc. The support
tool
netdiag and dcdiag are also very helpful in tracking down domain
configuration/network connectivity problems. Use netdiag on any

computer
and

dcdiag on just domain controllers. Dns misconfiguration in the domain for
domain clients [Windows 2000/XP/2003] and/or domain controllers also is
often the cause of such problems. If you are using downlevel clients

in
the

domain, netbios name resolution also needs to be correctly configured
with
domain controllers also being wins clients. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q224370
http://support.microsoft.com/default.aspx?scid=kb;en-us;321708 --- netdiag
and how to install support tools.
http://support.microsoft.com/default.aspx?scid=kb;en-us;291382 --
AD
dns FAQ.


Hello,
I have recently been experiencing a problem on many of the

computers
on

my network. All these affected systems are having trouble logging off.
From what I have been able to find out I believe that this problem is some
how related to similar errors like this:
-------------------------------------------
The COM+ Event System failed to fire the Logoff method on subscription
{AAD1D51F-1279-4831-8684-D99F99B3CC62}. The subscriber returned
HRESULT
800706BA.

refers
to

0x800706BA which means "The RPC server is unavailable". This is

where
I'm

stuck......if I am understanding this right it's a problem with my
Win2k
Server and or the communication between the server and the affected
machines. I also found that this is a side effect from the MSBlaster
virus
because it utilizes DCom and the RPC server for it self. So I ran
scans
but
found nothing.

Any suggestions on how I may resolve this please?

 

[Steven L Umbach]

Well it looks like you found a common link though I can not think of why MSN
Messenger would cause the problem. Another thing to check is that the
computers that are having the problem are configured correctly as far as dns
in that they point ONLY to domain controllers as their preferred dns server
and never include an ISP dns server in the list of preferred dns servers for
a domain computer. If an ISP dns server is listed, even second or third in
the list, if it responds because of a lag in dns response from a domain
controller then you certainly will have RPC problems. I doubt that the
domain controller is the problem since this seems to be related to only a
certain group of computers. It may be worth a try to remove MSN Messenger
from a problem computer to see what happens. As another test from one of
the problem computers, try to navigate to the sysvol share of the domain
controller they are using for dns in Network Places or use \\dcname\sysvol
in the run box. It should be able to access the sysvol share. Also check to
see if the computers are current with critical security updates that have
been approved for your network [if you require updates to be tested and
approved before applying].--- Steve

Yes, Netdiag showed Pass on the DC too. I checked the "Trust computer for
delegation" and re-ran DCDiag and now all tests pass. But the problem is
still showing up in the logs of some machines. I have not rebooted the DC
yet and probably will not be able to for some time.
Last week I went through the Event log of every computer on the network
and discovered that all the affected systems have MSN Messenger installed
and the unaffected machines do not. This lead me to think maybe it could
be
a problem between the machines and the MSN server because of my firewall.
After looking into it some more I remembered that this issue did not start
until about a month ago and there have been no significant changes made to
it that could affect communication between a computer on the network and
the
internet. Just for kicks though I checked the log and could not find any
entry coinciding with the messages in the event logs.

-Scott

Did netdiag show a pass for everything on the domain controller?? The error
below is significant. Find the computer account for the DC in AD Users
and
Computers and look in properties and make sure "trust computer for
delegation" is checked which domain controllers should be. I don't know
if
that is the krux of the problem but that would be a good start and then see
if that error goes away with dcdiag or not. I don't know if the domain
controller needs to be restarted after enabling for delegation. If the error
in dcdiag persists it would be a good idea to restart it if it will not
cause too much disruption. Also see if there are any pertinent events in
Event Viewer on the domain controller that may be helpful. --- Steve

I ran NetDiag on some of the affected machines and received pass on all
tests performed, additionally, I ran DcDiag on the domain controller
and
received a pass on all tests performed except
-------------------------------------------------------------------------
Starting test: MachineAccount
* MAINSERVER is not trusted for account delegation
......................... MAINSERVER failed test MachineAccount
-------------------------------------------------------------------------
If I am reading this right the above failed test doesn't matter because my
DC is the only one on the network. Is this correct?, any other
thoughts
on
this matter?

-Scott

See the link below for more details as this is often a name resolution or
network connectivity problem. Your domain clients should be able to ping
the
domain controller by it's IP address and fully qualified domain name
as
in
dc1.mydomain.com as an example of a FQDN. The domain controller should be
able to do the same for the domain clients. Look in Event Viewer on
the
domain controller to see if any related events are being recorded that
may
help you resolve the problem such as failed services,etc. The support
tool
netdiag and dcdiag are also very helpful in tracking down domain
configuration/network connectivity problems. Use netdiag on any computer
and
dcdiag on just domain controllers. Dns misconfiguration in the domain for
domain clients [Windows 2000/XP/2003] and/or domain controllers also
is
often the cause of such problems. If you are using downlevel clients in
the
domain, netbios name resolution also needs to be correctly configured
with
domain controllers also being wins clients. --- Steve

http://support.microsoft.com/default.aspx?scid=kb;en-us;Q224370
http://support.microsoft.com/default.aspx?scid=kb;en-us;321708 ---
netdiag
and how to install support tools.

tp://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B291382 --
AD
dns FAQ.


Hello,
I have recently been experiencing a problem on many of the computers
on
my network. All these affected systems are having trouble logging off.
From what I have been able to find out I believe that this problem
is
some
how related to similar errors like this:
-------------------------------------------
The COM+ Event System failed to fire the Logoff method on subscription
{AAD1D51F-1279-4831-8684-D99F99B3CC62}. The subscriber returned
HRESULT
800706BA.
-------------------------------------------
After some research into these problems I found that 800706BA refers
to
0x800706BA which means "The RPC server is unavailable". This is where
I'm
stuck......if I am understanding this right it's a problem with my
Win2k
Server and or the communication between the server and the affected
machines. I also found that this is a side effect from the
MSBlaster
virus
because it utilizes DCom and the RPC server for it self. So I ran
scans
but
found nothing.

Any suggestions on how I may resolve this please?