UPDATE! The community will be go into read-only on April 19, 8am Pacific in preparation for migration on April 21. Read more.
UPDATE! The community will be go into read-only on April 19, 8am Pacific in preparation for migration on April 21.Read more.
Absent Member.
Absent Member.
985 views

RemoteLoaderSvc.exe (.Net Remote Loader) loads but doesn't work

I'm configuring my second .Net RemoteLoader here on a Windows server. The
first one is working fine, and the second is basically the same, just
with different ports specified.

The working one is configured for ports 8095 / 8005. On startup, using
SysInternals ProcMon, I see it open TCP communication to the local host
on port 288, then 289, then it opens a listener on 8095.

The not-working one is configured for ports 8096 / 9006. On startup, I
see it open comms to 288, 289, then it just dies. The RemoteLoaderSvc.exe
is still loaded and running, but it never opens the listener on 8096.

Both of these remoteloaders are being configured for Office365 drivers.
This isn't the problem where the RL console configures the driver wrong
and puts the SharePoint.dll in there. I've already checked that, and the
correct DLL is configured.

Anybody seen this before? Any ideas on what I'm missing or where I can
look to see why the service isn't opening its listener?


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
Labels (1)
0 Likes
15 Replies
Absent Member.
Absent Member.

David Gersic wrote:

> I'm configuring my second .Net RemoteLoader here on a Windows server. The
> first one is working fine, and the second is basically the same, just
> with different ports specified.
>
> The working one is configured for ports 8095 / 8005. On startup, using
> SysInternals ProcMon, I see it open TCP communication to the local host
> on port 288, then 289, then it opens a listener on 8095.


Do you know what those 288, 289 ports are for? I can't recall ever seeing anything that is officially assigned to those ports.

> The not-working one is configured for ports 8096 / 9006. On startup, I
> see it open comms to 288, 289, then it just dies. The RemoteLoaderSvc.exe
> is still loaded and running, but it never opens the listener on 8096.


Is anything hogging the 8096 port? Have you tried a reboot?

> Anybody seen this before? Any ideas on what I'm missing or where I can
> look to see why the service isn't opening its listener?


I have a customer with 2 .Net RLs on one server. (they need to sync to two separate o365 tenants), it works for him (though there have been the occasional issues that necessitated a restart to fix).
So it is possible. In this case, the customer set these up themselves, so I have no more tips to give, aside from that.

--
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Absent Member.
Absent Member.

On 09/19/2014 02:29 PM, Alex McHugh wrote:
> David Gersic wrote:
>
>> I'm configuring my second .Net RemoteLoader here on a Windows server. The
>> first one is working fine, and the second is basically the same, just
>> with different ports specified.
>>
>> The working one is configured for ports 8095 / 8005. On startup, using
>> SysInternals ProcMon, I see it open TCP communication to the local host
>> on port 288, then 289, then it opens a listener on 8095.


Old Novell Audit ports. 288 was lcache's port, and 289 was the LogHost.
They are not 1288 and 1289. Fixing your logevent.conf (or equivalent)
file to refer to these new ports should at least cause this RL to properly
reach those sockets, which may help with other things. On the other hand,
I've never heard of the .net RL actually being audited, so no idea if any
of that really works.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Absent Member.
Absent Member.

On Fri, 19 Sep 2014 20:43:58 +0000, ab wrote:

> On 09/19/2014 02:29 PM, Alex McHugh wrote:
>> David Gersic wrote:
>>
>>> I'm configuring my second .Net RemoteLoader here on a Windows server.
>>> The first one is working fine, and the second is basically the same,
>>> just with different ports specified.
>>>
>>> The working one is configured for ports 8095 / 8005. On startup, using
>>> SysInternals ProcMon, I see it open TCP communication to the local
>>> host on port 288, then 289, then it opens a listener on 8095.

>
> Old Novell Audit ports. 288 was lcache's port, and 289 was the LogHost.
> They are not 1288 and 1289. Fixing your logevent.conf (or equivalent)
> file to refer to these new ports should at least cause this RL to
> properly reach those sockets, which may help with other things. On the
> other hand, I've never heard of the .net RL actually being audited, so
> no idea if any of that really works.


Hm. On configuration, I see the RL Console fire off a command prompt that
says it's starting a new lcache session. On changing configuration, I see
RL Console fire off a command prompt that says that it's using an
existing lcache session. On startup, RemoteLoaderSvc.exe starts cmd.exe
as a sub process, which starts lcache.exe as a sub process. So that kinda
makes all sense, I guess, but then it dies before opening the listener.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
0 Likes
Absent Member.
Absent Member.

On Fri, 19 Sep 2014 20:29:47 +0000, Alex McHugh wrote:

> David Gersic wrote:
>
>> I'm configuring my second .Net RemoteLoader here on a Windows server.
>> The first one is working fine, and the second is basically the same,
>> just with different ports specified.
>>
>> The working one is configured for ports 8095 / 8005. On startup, using
>> SysInternals ProcMon, I see it open TCP communication to the local host
>> on port 288, then 289, then it opens a listener on 8095.

>
> Do you know what those 288, 289 ports are for? I can't recall ever
> seeing anything that is officially assigned to those ports.


No idea. They're officially undefined, as far as I can tell.


>> The not-working one is configured for ports 8096 / 9006. On startup, I
>> see it open comms to 288, 289, then it just dies. The
>> RemoteLoaderSvc.exe is still loaded and running, but it never opens the
>> listener on 8096.

>
> Is anything hogging the 8096 port? Have you tried a reboot?


Nothing seems to be hogging 8096. I've tried 8097 and 8098, to see if
that would help. Have not yet tried the magic Windows reboot fix.


>> Anybody seen this before? Any ideas on what I'm missing or where I can
>> look to see why the service isn't opening its listener?

>
> I have a customer with 2 .Net RLs on one server. (they need to sync to
> two separate o365 tenants), it works for him


I have two configured on my dev server, so I know it can be done. It
seems to just be this one that's being a problem.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
0 Likes
Absent Member.
Absent Member.

On Fri, 19 Sep 2014 20:00:02 +0000, David Gersic wrote:

> I'm configuring my second .Net RemoteLoader here on a Windows server.
> The first one is working fine, and the second is basically the same,
> just with different ports specified.


Something is very weird here. I took the working one, changed it's ports
to 8195 / 8105, now it won't start correctly either. I took the non-
working one, changed it to 8095 / 8005, and it starts fine. Changed the
now working one back to 8096 / 8006, and it won't start. Changed the now
not-working one back to 8095 / 8005, and it starts fine again.

So I went back to my dev server, which has two working .Net RemoteLoaders
configured and running fine. I configured a third one. It won't start
correctly, with the same symptoms. The process starts, but never opens
the listeners on the configured TCP ports.

I'm starting to think there's something wrong with the OS at this point.
Maybe the magic Windows fix of "reboot it" will help. I'll try that next
week.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
0 Likes
Absent Member.
Absent Member.

Have you checked the windows firewall settings? I've seen similar things
with the regular RL, though only on windows, where the system was blocking
ports until they were explicitly opened. Perhaps that process only has
rights to the xxx5 ports right now.

--
Good luck.

If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Absent Member.
Absent Member.

On Sat, 20 Sep 2014 14:30:30 +0000, ab wrote:

> Have you checked the windows firewall settings? I've seen similar
> things with the regular RL, though only on windows, where the system was
> blocking ports until they were explicitly opened. Perhaps that process
> only has rights to the xxx5 ports right now.


Yes, checked there. Supposedly the RemoteLoaderSvc.exe has Any/Any/Any
set to "Allow".


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
0 Likes
Absent Member.
Absent Member.

On Sat, 20 Sep 2014 14:30:30 +0000, ab wrote:

> Have you checked the windows firewall settings? I've seen similar
> things with the regular RL, though only on windows, where the system was
> blocking ports until they were explicitly opened. Perhaps that process
> only has rights to the xxx5 ports right now.


Checked, and re-checked. Rebooted, too. No joy. Same symptoms. The
RemoteLoaderSvc.exe process starts, plays with ports 288 and 289, then
just stops doing anything with TCP/IP. It doesn't open its listeners on
the configured 8096 and 8006 ports like the working one does.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
0 Likes
Absent Member.
Absent Member.

On Sat, 20 Sep 2014 14:30:30 +0000, ab wrote:

> Have you checked the windows firewall settings?


Firewall, IPSec, and McAfee disabled, with no change.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
0 Likes
Absent Member.
Absent Member.

David Gersic wrote:

> On Sat, 20 Sep 2014 14:30:30 +0000, ab wrote:
>
> > Have you checked the windows firewall settings?

>
> Firewall, IPSec, and McAfee disabled, with no change.


How did you disable the firewall? Microsoft's firewall has become harder to *fully* disable.
There is a thing called "Windows Service Hardening firewall rules" which normally remain enabled even if the regular firewall is deactivated.

Try the following from a powershell session.

(New-Object -ComObject HNetCfg.FwPolicy2).ServiceRestriction.Rules

That will show any hardening rules (which are always tied to a windows service if I understand correctly).

Other than this, I can only suggest poking aorund with procmon and debugview or raising a SR.

--
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Absent Member.
Absent Member.

On Mon, 22 Sep 2014 20:57:55 +0000, Alex McHugh wrote:

> David Gersic wrote:
>
>> On Sat, 20 Sep 2014 14:30:30 +0000, ab wrote:
>>
>> > Have you checked the windows firewall settings?

>>
>> Firewall, IPSec, and McAfee disabled, with no change.

>
> How did you disable the firewall?


By calling the Windows admin and having him disable it. 😉


> Microsoft's firewall has become harder
> to *fully* disable. There is a thing called "Windows Service Hardening
> firewall rules" which normally remain enabled even if the regular
> firewall is deactivated.
>
> Try the following from a powershell session.
>
> (New-Object -ComObject HNetCfg.FwPolicy2).ServiceRestriction.Rules


Ran this, it shows nothing.

And, even if the firewall is running, that doesn't (as far as I know)
prevent a service from setting up a listener on a port. It blocks
connections to that port, but the listener is still there. In this case,
it seems like the service can't even open the listener on the port.


> That will show any hardening rules (which are always tied to a windows
> service if I understand correctly).
>
> Other than this, I can only suggest poking aorund with procmon and
> debugview or raising a SR.


ProcMon shows what isn't happening, but that's about all I've been able
to find with it. DebugView doesn't show anything, so I don't think the
RemoteLoaderSvc.exe is debug enabled (sadly).

I guess I'm going to have to burn an SR to find out what's up with this
goofy service.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.
If you find this post helpful, please click on the star below.
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.