Guest User!

You are not Sophos Staff.

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

DFS-R Replication Issues

We recently switched from ESET to Sophos for our antivirus protection.  We're seeing an issue with DFS-R replication though.  I've put in all the exclusions recommended by Microsoft, but replication is extremely slow.  We're trying to replicate a new 70GB repository to a new server.  After nearly 2 weeks, it had only replicated about 1GB (and this is with preseeding the files with robocopy).  I finally uninstalled Sophos from both servers and the replication completed in less than 2 hours.  We use DFS-R quite a bit to sync between our remote sites and our data center, so I'm concerned that things will begin to get out of sync due to replication taking so long with Sophos running.  I have the special "System Volume Information" folders excluded as well as the actual folder paths, but that didn't seem to help.  Does anyone have any hints or tips on this?



This thread was automatically locked due to age.
Parents
  • Hello Jason Lester,

    Sophos for our antivirus protection
    which product (and potential optional features) exactly? There are more components in Central than in the on-premise managed SESC. Which of the components are enabled?

    70GB [...] in less than 2 hours - 1GB [after 2 weeks]
    wouldn't call this "base speed" extremely fast but anyway AV scanning (especially with the exclusions in place) shouldn't slow it down that much. Even if you specified the exclusions incorrectly this is way too much degradation. Was it just slow and no errors in the logs?
    While apparently related to Sophos the issue seems to be with a component other than basic AV scanning.

    I think it's be necessary to recreate the situation and analyze what's happening.

    Christian   

  • We're using "Intercept X Advanced for Server" on all of our Windows 2012R2 servers.

     

    I did an exclusion for the dfsrs.exe process this morning.  I have several more servers to replicate, so I'll see if that makes a difference.  I'm also going to have Process Monitor running just to confirm what is causing it.

     

Reply
  • We're using "Intercept X Advanced for Server" on all of our Windows 2012R2 servers.

     

    I did an exclusion for the dfsrs.exe process this morning.  I have several more servers to replicate, so I'll see if that makes a difference.  I'm also going to have Process Monitor running just to confirm what is causing it.

     

Children
  • Did you ever get down to the bottom of this?  I'm also using Intercept X on prem / endpoint protection SEC and wanting to implement DFS-R and namespaces across our remote locations as well.

     

    Thanks!

  • They've admitted it is a bug, but keep pushing the fix back further and further.  The last I heard from them was in April and they said the fix is scheduled for the Q4 2019 release.

     

    The workaround is to create a special group just for DFSR servers and set a custom policy to turn off CryptoGuard and MBR Ransomware.

  • My god man! I'm sure glad I found your post then.  I guess I shouldn't use my main file servers since I wouldn't want to turn off CryptoGuard and MBR Ransomware on those.

    Any other pro tips?  I happened to look up Sophos + DFSR because part of the checklist is to make sure to verify with your A/V software that it is supported and how to set it up properly with A/V.

    Do you have any additional documentation on the bug and workaround?

     

    Thanks again!

  • In looking back through my e-mails, I see they listed more details and another workaround:

    ---

    Development confirmed there is a Bug due to DFS Replication service starting earlier than HitmanProAlert service.

    As a workaround until a fix is available I suggest you set a service dependency so that the DFS Replication service
    is started after the HitManProAlert service.

    ---

    I don't know that I have tried that workaround though.