[Zenoss-dev] Re: V2.1 - RPC_S_CALL_FAILED - WMI Error - zenwinmodeler failure

[crosse]

I have a box that, as soon as I added it to Zenoss, it would generate RPC_S_CALL_FAILED errors.  Of course, every time the error would occur my event command (see earlier in this thread) would fire and restart zenwinmodeler, which would then start modeling devices again, and then die when it got to the newly-added device, get restarted, etc.  The difference between this device and others is that we are beginning to use host-based firewalling and this device had the Windows Firewall turned on.  

In a nutshell remote WMI needs tcp port 135 to be open, which was in the exceptions list.  However, remote WMI also needs a random high port which is assigned at run-time, which was obviously not in the exceptions list.  (This is how the MS Endpoint Mapper works...you connect to port 135 and ask the mapper which port the service is actually listening on, then do all your conversing over that high port.)  After finding out where WMI and WBEM were listening and adding that to the firewall, I could initiate a remote WMI connection.

I know that the real issue here is in how Zenoss handles the RPC_S_CALL_FAILED error (which in my case was caused by the error NT_STATUS_IO_TIMEOUT) and not what causes the error, but I think this may shed some light on why the error happens in the first place.  For remote WMI to work both ports 135 and the dynamically assigned high port have to be open to the Zenoss monitor.  Cases where this may be an issue are:
	When the remote server has Windows Firewall turned on.  If the firewall is on, you must add port 135 as an exception (note: this is NOT included in the "File and Print" exception).  You must also make program exceptions for svchost.exe and lsass.exe since the dynamic ports are not known and are not guaranteed to be the same every time the service starts.

	When the remote device and the Zenoss server are on different subnets and there are router ACLs in the way.  Basically the same as above, but one level removed.  You'll need to make sure that Zenoss can contact the remote device on port 135 and the high port.  Read the following guides to restrict RPC to use only the port range you specify, and add the port range to your firewall ACLs:  http://support.microsoft.com/default.aspx?scid=kb;en-us;154596 and http://msdn2.microsoft.com/en-us/library/ms809327.aspx.


With that said, I'm not really crazy about adding program exceptions to the Windows Firewall for svchost.exe and lsass.exe; it just doesn't seem to be what I would call a "best practice".  If you do have to go this route, I would restrict the scope of the firewall exceptions to only the IPs of the Zenoss server and whatever other device needs access.  I would definitely not leave the scope wide-open.  As a last note, I have not tried adding the program exceptions for svchost and lsass to the Windows Firewall so I can not state whether or not it fixes the issue.

Just my two cents.  Oh...and how is development coming along on the Zenoss side of this issue?

--seth




-------------------- m2f --------------------

Read this topic online here:
http://community.zenoss.com/forums/viewtopic.php?p=15053#15053

-------------------- m2f --------------------