Issue with the Firewall configuration after problems with updates

Question

Dear All, 
 maybe I have a problem to understand the features of Sophos Endpoint. 
 
 I have been working with other products and never had the same issues that I am currently facing. 
 I have found some clients which have issues to update the patterns, some for quite some time. With recent products I have: 
 a) tried to force the update on the remote client via the Management Console 
 b) if that failed set command to remote clients to comply with "all Group policies" b1) wait for up to 5-10 minutes to complete 
 c) run force update again 
 d) if fails again, protect computers and select all company default settings (i.e. enable Firewall) d1) as I have already send the "comply with all gpos" it should set the permission correctly e) with other products: after up to 5 minutes the client completes the installation and is up to date F) now the situation is, that those 20 remote clients are finally up to date, BUT are not comply with the GPOs I have send before. F1) instead the FW config did not enable "primary location: grant all network access" - which results in issues to connect to network ressources. F2) should the FW client also with SOPHOS pull the FW policy that I have deployed before? 
 Some clients still fail to connect to the update source, as the information is missing... (does not make sense to me). I am trying to find out, where my workflow failed. 
 Any help is highly appreciated. Thank you.

QC · Accepted Answer

Hello Markus Hartmann , 
 to continue where I've left off yesterday. 
 If you get the Awaiting policy from console the install succeeded and the endpoint is communicating. As said, this status should change after a short while provided the server can connect to the endpoint's port 8194 ("downstream"). Otherwise it requires a message from the endpoint that will arrive sooner or later. As Comply with ... results in the same action as the Awaiting ... , namely sending the policy immediately if the downstream path is available or enqueuing it to supply it in a response, it won't make a difference. 
 If the endpoint seems stuck in the awaiting check if the downstream path is there (assuming it should). If it's not you can test whether the policies are indeed still enqueued and are supplied and processed as designed by forcing the endpoint to send a message. Simply disable on-access scanning, the console show reflect this change after a few seconds, the endpoint should receive the policies and re-enable on-access. 
 If there's no change then it might be (as said, I don't use SCF and I have no experience with 3.x on Windows 10) that upon receiving the FW policy the endpoint blocks the connection. While I think that SCF permits the Sophos processes I won't rule out that "something" is not right as you've mentioned enable primary location . There's a known issue (WINEP-1758) where bluntly or use Windows Firewall instead is suggested as workaround. Anyway, the Firewall log should tell when it blocks communication. The Router and Agent logs ( %ProgramData%\Sophos\Remote Management System\ ) will show whether policies have been received and status messages could be sent or not. 
 Last but not least I want to point out that SCF is doomed . 3.x (on Windows 8 and newer) has already lost some functionality (not exactly Sophos' fault), has the mentioned issue on Windows 10, and I wouldn't bet that it will survive all Windows 10 updates and last the full two years. 
 Christian