Glad that you confirm that resolves. 😊 

This configuration is needed in order for Nginx to properly manage the WebSocket connections.

If the zimbraPublicServiceHostname, Port and Protocol attributes are not properly set, the WebSocket connections will not be initialized on loading causing Team/Connect to fail the loading in the browser or signing in in the Team App.

In case you have, please be sure that they're configured to properly pass WS connections too, for instance, Nginx and Apache require a dedicated configuration to correctly manage WS.

A good test to do is configure a test device to directly connect to the Zimbra proxy forcing the DNS for that device to resolve the zimbraPublicServiceHostname with the local IP of the proxy server, if the Team app on the device can properly connect then the network devices between the external clients and Zimbra should be analyzed, otherwise, I suggest to open a ticket to the Zextras Support Team, please remember to refer to this post in the ticket.

The variable's value should be the URL used to connect to the webmail.
Quite often it's something like webmail.domain.tld.

On a multi-domains servers, you can have a zimbraPublicServiceHostname per domain (that means a SSL certificate per domain) or a single one for every domains (or a mix, of course).

Hello Matt,

Sorry, that didn't work here.

I have set the following settings (anonymized):

$ for dom in $(zmprov gad); do zmprov gd $dom zimbraPublicServiceProtocol zimbraPublicServiceHostname zimbraPublicServicePort; done

# name mail.example.com
zimbraPublicServiceHostname: mail.example.com
zimbraPublicServicePort: 443
zimbraPublicServiceProtocol: https

# name example.de
zimbraPublicServiceHostname: example.de
zimbraPublicServicePort: 443
zimbraPublicServiceProtocol: https

It is also not clear to me at the moment what the "zimbraPublicServiceHostname" value does. The host and DNS name is mail.example.com, but the users are in example.de (for example john.doe@example.de). This works really well in the groupware functions, but not with Connect/Teams.

mail.example.com is set in the internal network by DNS from the internal IP of Zimbra, while it is routed from external to a reverse proxy. Since I had only today again the possibility to test the whole thing from the internal network, I can first exclude that the problem is to be sought in the reverse proxy, since this is not used internally.

At the moment, the original behavior still exists. I also find it amazing that I (externally, internally not yet tested) still receive PUSH messages on the iPhone that messages were sent to me. In the message center I also see the content of the messages. Only the app can not be opened and thus nothing write. This is different on an Android smartphone, there I do not receive PUSH messages.

Best regards

Kai

Thank you for this valuable tip. I see at least with the 1st command that there seems to be a misconfiguration there.

I will fix this tonight using your instructions.

Thanks a lot

BR

Kai

for dom in $(zmprov gad); do zmprov gd $dom zimbraPublicServiceProtocol zimbraPublicServiceHostname zimbraPublicServicePort; done

If not, you can set them by running

zmprov md DOMAIN.TLD zimbraPublicServiceHostname HOSTNAME.DOMAIN.TLD zimbraPublicServicePort 443 zimbraPublicServiceProtocol https

Remember to substitute the uppercase parameters according to your needs. E.g.:

zmprov md example.com zimbraPublicServiceHostname mail.example.com zimbraPublicServicePort 443 zimbraPublicServiceProtocol https

Once done, remember to regenerate the proxy's scripts and reload them by running

/opt/zimbra/libexec/zmproxyconfgen

zmproxyctl restart

If the issue persists, I would check the network, in particular, it could happen that some network devices, such as layer 7 firewalls or external reverse proxies, interfere with the Team/Connect WebSockets connections. In this case, a proper configuration of these devices should resolve.

We use Zimbra as groupware and currently RocketChat as a collaboration tool. The idea was to turn 2 applications into one. Since Zimbra/Synacor and Zextras seem to have entered into a cooperation to integrate the product, it would be practical (from our point of view) to also get extensive support for it. At the moment we have only a comparatively harmless problem in the test phase. But the fact that it comes to a support ping pong, where one company (which sells licenses for the product) shifts the support to the other company, which in turn have sold no product at all is not necessarily confidence inspiring. I think Synacor and Zextras should perhaps reconsider the rules of their partnership. So potential customers are only deterred (no I do not reproach Zextras here, it is just a well-intentioned advice). I think we will postpone the purchase of Zimbra Connect licenses (which would certainly have gone partly to Zextras) and stay with RocketChat for now.

Best Regards

Kai