Thread Info
  • State Verified Answer
  • +7 person also asked this people also asked this
  • Locked Locked
  • Replies 123 replies
  • Answers 2 answers
  • Subscribers 46 subscribers
  • Views 288488 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

anybody seeing issues with XG17 causing Outlook desktop client losing "sync" with Office365.

wpajack

We've starting seeing issues in the last month or so with Outlook desktop client losing sync with Office365 when it will just stop syncing the cached mailbox.  no errors and it will say all folders up to date.  It takes restarting Outlook for it to get back in sync and it will stay synced for a random period of time at which time it will stop syncing again.

 

I'm thinking the issue is linked with the upgrade from XG16 to XG17 that happened around the same time.  i waited until MR3 to upgrade to XG17.  I did the MR5 upgrade to see it that would help but it doesn't appear so.



This thread was automatically locked due to age.
Parents
  • 0

    Hi, if it helps our office365 is running smooth from few months ago as attached Rule and FQDN Groups.... after opening support cases regarding the office365 outlook clients connection problems, sometime with clients syncs, sometime with certificates error and others for first time client setup problems. (i used it with V16 also until V16MR7)

    what i found that behavior change with SFOS version releases (as always expected with this creepy XG appliance firewall  )

    Same rule worked some times with decrypt and scan HTTPS checked and other times without it due to firmware upgrades (of course i always have debate with support regarding changes per firmware but hopeless argument)... also sometimes worked with web exceptions and sometimes without it

    "I will not pay Sophos again on renewal to use our money for developing and testing their XG product on us"

    Currently Running V17.0.6 MR6 and clients are Outlook 2010 SP2 and using below settings.

  • 0 in reply to Haytham Mestekawy1

    Hi,

    i am using a FQDN "Exception" Network based rule on top of my rule set for O365.

    https://support.office.com/en-us/article/office-365-urls-and-ip-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2

    Using the FQDN destination urls als FQDN hosts and it works fine (Because i do not try to scan the https traffic). 

     

    Cheers

Reply Children
  • 0 in reply to LuCar Toni

    This sounds similar to recommendation we has received from Sophos GES. Eg: Basic LAN to WAN rule to O365 Destinations with nothing touching it.

    Our issue is its simply not practical to manually implement (let alone manage) that massive list of domains etc across 30+ XG devices.

    Anyone know a "smarter" way of achieving this?

  • 0 in reply to Adam Rippon

    I have done all of this and i still have the issue.  I have a huge list of CIDR and FQDN`added to my exceptions and firewall rules.  Nothing has resolved this issue. Sophos at this point is going to lose us as a customer as soon as our contract is up. Way too many issues with these firewalls. I can`t believe this is being sold as an enterprise solution. 

  • 0 in reply to Charles Johnson

    Charles, 

     

    I am right there with you - I have attempted all suggestions here no luck. Last week I created a support ticket - Spent an hour with level 1 (who had no idea what he was doing) now still waiting to hear back from them. 

    In the mean time my client's C level management are considering terminating our support contract because they cannot reliably get emails from Outlook! How is such a common, mainstream business application not fully supported!

  • 0 in reply to Joe Plunkett

    Hey  

    Apologies for your negative experience with our support team. Would it be possible to PM me with your support case number so I can look into this for you?

    Thanks!

  • 0 in reply to FloSupport

    Hello ,

     

    My case number is #8086232   - and I should point out that the case is not that old. The support person was really not bad either - he just wasn't grasping the issue.