powered by Jive Software

Openfire-service not working on IIS

We ran openfire-service /install and openfire-service /start and the service was installed and started, but we cannot connect to the server using spark or the admin control on port 9090

The GUI for Openfire works great and we can connect to the server just fine with spark while it is running, but of course we are not logged into the server 24/7 so we need to get the service running.

The GUI and the service are not running at the same time so I know that’s not the issue.

This is driving me crazy today. How can something so simple be such a PITA?

Forgot to add, we are running 3.6.0a and it’s a brand new install.

So since the GUI startup allows connections just fine, but the openfire-service does not, what could be the problem?

Check error log in Openfire\Logs folder after you start it as service. Maybe just copy error log here and someone will look through. Also try netstat command in Windows cmd and check if Openfire is listening on port 9090.

IIS is not needed for openfire. I would try removing the service and readding it.

After starting the openfire-service the error log is blank. Here is the output of netstat -a and it looks like openfire is listening on 9090 and 9091

(Other ports have been removed from the list)

Active Connections

Proto Local Address Foreign Address State
TCP 117592-APP1:9090 117592-APP1:0 LISTENING
TCP 117592-APP1:9091 117592-APP1:0 LISTENING

Sory, should have stated a windows box, not an iis box.

The service has been uninstalled and reinstalled multiple times. Still no luck.

Are you running the Windows firewall ? If so, are you allowing acess to the ports ? Is the service, once running, a System Service ?

Not running the windows firewall. We have an outside firewall. I know the ports are accessable from the outside because if we use the regular program startup we can connect to it just fine, only the service has a problem.

Yes, after install it is listed as a system service and is started and running. We just can connect to it when it is started as a service.

As a apoint of interest, if you RDP onto the machine or directly on the console, if you run IE or Firefox locally, can you connect to either http://:9090 or http://127.0.0.1:9090 ?

Good point! Never thought about that. Yes, using http://127.0.0.1:9090 on the box we can connect to the admin.

So why is it not accepting connections from the outside through port 9090 using the service option, but it works using the exe file startup?

Any ideas?

What about on the box connecting to http://:9090 as well as http://127.0.0.1:0:9090 - can you get on that ? What happens if you try and telnet onto 9090 ? Can you get a connection ? Do you have multiple NIC’s in the server ?

The http://ip:9090 and http://domain:9090 both work from the box itself. Telnet to port 9090 fails from outside the box.

Only one NIC on the box.

This sounds network or firewall related - have you tried this a machine within your Corporate network, or at least within the same subnet as your server ?

Is there something different about the setup on the server such that the OF service may not have permissions to get at the network ? I assume that when you run the EXE you’re an admin when logged in.

Does the OF user (if applicable) have the right permissions ?

Do you have anything McAffee IDS running ?

McAffe? Oh God no.

Do you run any intrusion detection S/W ? It’s clear the app works when run as the EXE - I’m assuming you login as an admin to do that. Just wondering why it won’t run on the network.

Have you tried openfire-service /uninstall and then reinstall it - ensuring that you are admin on the machine ?

The machine is co-located so we cannot trying it on our corp network.

openfire-service install setup up the service to run on the local system account. (Photo attached)

No intrusion detection s/w running. The service has been uninstalled and reinstalled many times (all while logged in as admin).

That is the correct configuration. My guess is that there is something with your network config that is blocking. If you can access the admin page with the service running from the server itself but not external to the server then there must be something blocking the transports.