Openfire is installed on our Windows SBS 2011 Server and Spark on my PC
The Windows server is our domain server as well as exchnage. Ive given the name of the Openfire server “openfire” which I can ping from my PC with success and I can ping the SBS server as well. I’ve allowed access through the firewalls, both ways. There aren’t any Access Lists blocking any internal traffic. Everything is on the same subnet.
Unlock these ports you are communicating through… e.g 9090,9091,7070,7071 and other if you are using.
9090 and 9091 are the web admin interface ports. Nothing to do with Spark
7070 and 7071 I have no idea what…
Spark connects via port 5222 by default. Openfire is using 5222 by default as well.
Openfire admin GUI has a page in server settings where it shows all port ranges it wants to use, it’s best to refer to that page.
If I had to diagnose Spark login, I would have started by checking what user name and domain were provided (user name has to be user@domain.suffix and domain has to be <domain.suffix>, then if that <domain.suffix> cannot be resolved from the client, then override it with of the server in the settings).
Hi. Did you manage to solve this? I have the same issue. I am able to run Spark on the actual server (and authenticate users) but clients are unable to contact it via the LAN.
I’m running an additional member server as well as the SBS domain controller and the Openfire server is on that.
I have opened the required ports on the second server but still no joy. Do I have to open the ports on both the additional server AND the domain controller to make this work (surely not…)? The DC is on address 10.0.0.2 and the other one is on 10.0.0.30
I’ve tried adding the ip address of the (10.0.0.30) server too but that doesn’t allow it to connect either.
I must be missing something fundamental here… If my Openfire server is server2.company.local then what address do I put in the server field of the Spark client? I’ve tried 10.0.0.30, server2.company.local and just server2. None allow connection. I’ve even opened all the ports on the server but that doesn’t work either.
Is there a way to “TEST” communication that will reliably state that the comms are present? My SBS server will TELNET to the Exchange Server on the DC (port 25) but that’s it. It doesn’t seem to communicate with anything else. Seems like a port issue but even opening all ports doesn’t solve it. Ideas anyone?
Moving on, I have found that turning off Windows Firewall (DOMAIN) on the server allows me to connect. I didn’t do this originally as I had already created incoming ALLOW rules for ports 5222, 5223, 7070, 7443, 9090, 9091 and 5229. I’ve since re-checked all these rules (all configured for TCP and UDP) and all seem to be correct. Does anyone have an example of the exact format for a rule for the Openfire server. I’m creating it against the .exe file in the \bin directory. I’m assuming that this is correct. - Or is it?
And again… but this time I have solved it. I thought it wise to post the solution as I’m sure others will have this identical problem and be tearing their hair out like I was.
To recap, I was installing Openfire on an SBS2010 network and had the Openfire Server on a member server attached to the network. Workstation clients on the LAN could not connect.
This is what I did to make it work:
Installed Openfire server as a service on the server. Installed Spark on a workstation. Created the SQL database on the server. Once the service was running I was able to get into admin, create users and set everything up. All seemed to be ok. I then installed the Spark client on the server and I found that I could connect. So far so good. However, when I ran Spark on a workstation and tried to connect I got the “Could not connect” message. I found that disabling the Server Firewall made it work so I knew it was a Firewall issue.
I then created Inbound rules for the Windows Firewall to open ports 5222, 5223, 7070, 7071, 9090, 9091, 5229, 5269, 7443 for both TCP and UDP. Tried it again and it still would not work. Everything seemed to be correct. Even posts on the forum here seemed to indicate everything was correct - but it would not connect.
It then dawned on me that I had not given the program access to the SQL server! There was already a rule set up for the SQL server TCP port on port 1433, so I added ports 5222 and 7070 to this rule, tried again and it worked!
Job done. Probably worth mentioning that depending on how you are connecting, the port ranges may need to be extended for the SQL rule but this definitely points to the solution to the problems. This may well prove to be the pointer for other types of database access too. So beware, this doesn’t seem to be mentioned in any of the documentation.