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.