Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 3 replies
  • Subscribers 5 subscribers
  • Views 17894 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

Sophos blocking Skype For Business / Lync

BrandanKusser

Hey all, I am posting this question here and on the Office 365 forums.  This is an issue we are having company wide.  

For a long time, we ran office 365 and sophos together here with no issues at all.  Then all of a sudden, sophos started blocking Skype for Business (which rolls back to lync for us) for seemingly no reason.  Skype for business and Lync are both on the do not block list on our server.  The fix we have found is to simply close out of lync, update sophos(even though nothing updates), then reopen and it seems fine, but there is a little yellow box above the contact list that says "Exchange needs your credentials".  You can X out of the box and use normally, but typically the same thing happens over and over again for users and they keep having to do the same fix over and over.  Also the yellow box appears every time you open Lync now.    Has anyone else had this problem?  Thanks! 



This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to lcdb

    Hello, I wouldn't suggest just deleting the LSP Dlls.  If the entries for Sophos are still in the Winsock catalog and the files don't exist, when a process makes a Winsock call they won't be loaded but I'm not sure of the behaviour but it could be unpredictable.

    To unload the Sophos LSPs from Winsock, I would suggest to disable the following features on the endpoint:

    1. Web Control (may not be in use)

    2. Download scanning + block access to malicious websites.  (these can be found under Configure - Anti-Virus-Web protection)

    With all 3 features disabled there is nothing for the LSP to do so it will be unloaded from Winsock on the next system restart.  It is deferred to the next reboot by:

    1. A registry key (hklm\software\[wow6432node]\sophos\web intelligence\) called swiupdateaction is set to 3.

    2. When the Sophos Web Intelligence Update service is started (at next boot) it sees the new action key with a value of 3 and removes the LSP from the catalog.

    It's done early at reboot to prevent too many applications that use Winsock from loading in the LSP before it can be removed.  You may even need to restart twice to guarantee that all processes on the system haven't loaded the LSP but typically not required as the update service is part of an early start group.

    Note: you can just start the swiupdate service once the swiupdateaction key is there and the LSP will be removed.  As all the opened applications that use Winsock already have it loaded you need to start restarting processes etc.. So it might be as easy to reboot.

    With the LSP removed ("netsh winsock show catalog" to prove it.) does the application work?

    If you enable just one of the above 3 features the LSP will be put back and you can see it return in the catalog.

    The LSP is only uses up to Windows 7/2008 R2, for Windows 8 and 2012+, the LSP is replaces by a WFP callout driver.

    To troubleshoot this, I would suggest making Procdump (https://technet.microsoft.com/en-gb/sysinternals/dd996900.aspx) the default postmortem debugger on a test computer by running:
    procdump -ma -i c:\dumps
    Note: Create the C:\dumps directory manually.

    Reproduce the problem and you should have a full dump of the crashing processes memory.

    Then install Windbg as part of the Debugging Tools for Windows which is part of the SDK (https://dev.windows.com/en-us/downloads/windows-10-sdk).

    Configure Sysmbols - https://msdn.microsoft.com/en-gb/library/windows/desktop/ee416588(v=vs.85).aspx

    Then open the crash dump file in Windbg and run:

    !analyze -v

    This might give you a clue as to what the failing stack/thread was doing.  Hoprefully the function names are quite descriptive and points you in the right direction.

    Failing this, the dump file should be useful for Sophos Support as a starting point. 

    Note: The -u switch will remove the registry keys that makes procdump the default postmortem dubugger.

    Regards,

    Jak

  • 0 in reply to jak

    Jak,

    I have not yet tried any debugging, but I disabled the download +malicious site scanning as suggested above (web control was already disabled) and for the past 2 weeks I have had next to no crashes. Nothing else on the network has changed, no updates have been rolled out to the Lync software.

Unfiltered HTML