The old rpc problem but with a twist!

[ianternet]

I have recently installed and configured LANSweeper, and everything seemed to be working fine. However one server yesterday failed to scan and on checking the error, it was the "The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)" one.

Ever since, any new PC logging on and being scanned for the first time seems to come up with this error. I have used the testconnection utility and it indicates everything fine. Also, the ping tests and dcom are all ok.

I can sort of get round the problem by disabling the firewall, running the testconnection.exe, running the lsclient on the client, and then re-enabling the firewall. However, some machines are remote which makes this rather difficult, and also impractical as more and more PC's are scanned for the first time.

I'm not really sure if any of the above actually resolved the problem, as there can be a slight delay in the scannign being updated.

Anyone any clues what may be happening?

Ian

[tstock]

Enabling the Remote Admin (using netsh firewall set service RemoteAdmin enable) seemed to do the trick for me. I will now push it out with KixStart or GP. Thanks!

[ianternet]

Thank you ever so much, it's resolved my problems.

And I know now why it did stop working, because I remember that one of the exceptions I had to do for SCE was remote administration!

Oh well, time for a cuppa

:t)

[Hemoco]

On your clients you need to change the domain policy for the firewall to allow remote administration.
You can change the group policy or you can do it manually using :

netsh firewall set service RemoteAdmin enable

Source: http://msdn2.microsoft.com/en-us/library/aa389286.aspx

[ianternet]

It seems to be that the port from the server can change.

The only way I can get it working is to turn off the local firewall, which is not really a solution. Unfortunately, with Windows firewall, you can't specify a range of ports!

However, this is somewhat confusing, as initially the clients were updating fine, but now they will populate all date except Software and OS on the scan, unless firewall is turned off.

Any ideas?

[ianternet]

Forget the above. What seemed to be working after repeated testing, has now failed again!

[ianternet]

Right, after quite extensive testing I have found a workaround on my network.

I noticed that there was an entry in the server firewall log from the client blocking port 139. I unblocked this, but it made no difference. This as it happened turned out to be a red herring. I turned the server firewall off, still no joy.

I recreated the service just in case it had somehow got corrupted....still no good!

Concentrating on the client, there was a dropped connection on port 135 from the server. Adding a rule for this made no difference. I turned the firewall off on the client and after a slight delay the client updated itself.

At each stage of testing I was removing the client from the database so that everything was being scanned in.

I turned the firewall back on the server, and client still updated fine. so turning my attention back to the client, I turned the firewall back on, with port 135 still open, and now noticed a second port being blocked on 1261. Opening that on the client too seems to have done the trick.

I was under the impression from the installation notes, that we only needed to open port 9524 on the server (unless it is assumed that the client firewalls aren't on of course).

I think one of the reasons why some of my clients may have been ok to begin with, is that port 135 was open at least from the legacy SCE group policy settings that I removed recently.

Should the above be necessary or could there be something else on my network that is causing these problems indirectly and only the above workaround resolves it?

Ian

[ianternet]

Nope. nothing I'm afraid.

[Hemoco]

yep

[ianternet]

Is this the error log that appears under the service directory on the server?