We'd love to hear about it! Click here to go to the product suggestion community
Currently validating our Exchange design in our pre-production environment and having issues "post-install" with Puremessage.
Reference environment is 4x servers. All 4 are running Server 2016 Standard Edition, Exchange 2016 CU7 and then Puremessage 4.0.3. Installation was to a MS SQL Server instance.
Installation was successful on all servers.
-- The Sophos Puremessage service wouldn't start - This was corrected by allowing the account to run as a service and adding it to the local administrators group on each server.
-- Launching the console on the first server (Server1) succeeds, and the other servers are listed in the Dashboard view, but with red "exclamation" marks on them and no data in the rows beside their names.
-- Launching the console on another one of the servers (Server2 for example) presents the error "Could not connect to the master synchronization server. Server: Server1". Clicking ok continues to launch the console. Once opened, the dashboard view lists all the other servers but with red "exclamation" marks on them and no data in the rows beside their names.
Essentially, wherever the console is launched from, the server can see itself but no one else in the Server Group.
Work arounds tried -
1) Allowing the processes through the Windows Firewall (Ref: https://community.sophos.com/kb/en-us/109664, and when that didn't work, temporarily disabling the Windows Firewall on Servers 1-4 and the SQL server. No change in behaviour, and error still occurring.
2) Through DCOMCNFG, checked permissions on the Puremessage Service object, ensuring that the SophosPureMessage user was on it (https://community.sophos.com/kb/en-us/37990)
3) Added local administrators group to the DCOM permissions per https://community.sophos.com/products/puremessage/f/sophos-puremessage/92930/sophos-puremessage-4-0-3-on-exchange-2016-with-cu5/336782
Tracing the network between Server1 and Server2 doesn't really reveal anything obvious, and Sophos doesn't really have (or I can't find) anything specific on how the communcation between the Servers and SQL works (ports/calls/requirements).
If anyone has and ideas on how to correct the console issue, it'd be appreciated.
Take a good look at your rpc behaviour. We have just resolved these exact symptoms though on release 3.1.4. RPC needs port 135 and high ports, so wireshark your servers and check, with probe software if necessary, they are not rejecting 135. You are reading the db so that does not look like the problem. Likewise sounds like your windows firewalls are down, but there could be a network firewall.
In our case it turned out the preceding install of Sophos standalone AV inhibited RPC and hence COM operations. Even though servers appeared to be netstat listening on port 135 a port scan showed they were not. A reboot ,followed for DAG members by a pm reinstall, fixed it.
The red arrows indicate an error of some kind, could just be this failure to contact other servers.