Well, i’m out of ideas now. You can save the current install and try completely fresh install, create one user and try logging with a Spark. This will show if this is a problem with your Openfire or the server/connection/network maybe.
The issue has been “resolved”, more to the point I found a workaround.
Since Openfire appeared to be rejecting credentials from any Spark user on any of our computers I uninstalled Openfire and installed in on a spare box. As it happens the boxes name is user10000 (the one we want it on is user1000)
It worked! Spark Clients are able to login to the new server at user10000
Something must be blocking inbound requests on user1000 even though port 5222 is open, there is no active firewall or antivirus either.
Strange but at least we have Spark & Openfire back on speaking terms. Eventually I need to find another box to put openfire on because user10000 is powered on solely for openfire and will eventually need to be placed into service as a production machine.
BTW: after installing and testing the setup on the new box I then copied the embedded-db files to the new setup and it’s running with all of the old settings, users and groups.
I think the issue with the first box was not a firewall/av blocking the incoming connections, but rather some other app already using 5222 port. Anyway. Yeah, it should work when copying old database into new installation. Just make sure to use same domain name for your server. If your old domain was user1000 and now your users login using user10000 as a login server/domain, then it can create problems when wanting to use encryption (SSL\TLS). Certificates won’t match domain name used to login. This will cause “Certificate hostname verification failed” error with Spark 2.8.x.
P.S. frontline firewall won’t protect against malware which is already inside your network. Having firewalls inside is also a good thing
It does sound like something grabbed and is using Port 5222 on the original box.
Unfortunately the machine name of user1000 assigned to the first box must remain there. If we changed it two other mission critical applications would fail to work.
We’ll have to take our chances but for now at least Spark / Openfire is working okay. We are only using it as an internal chat so I do not see an issue with certificates. Currently our Spark clients are running version 2.7.7. I will need to keep the information in mind.
Thanx.
BTW: we have end point protection for client protection. it may not have firewall turned on but as long as a user does not willfully deactivate end point we should be safe. much appreciated.