Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 2 replies
  • Subscribers 1 subscriber
  • Views 828 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

Question on SEC structure

nduda78

So I've been managing a SEC 4.7 and SEPP 9.7 setup for sometime now. I'm starting to question if I can build it out better.

- Currently, we have one server with the SEC and SUM on it. Its the "only" SEC server in the org.

- We have about 10 remote sites globally. Each site can range from 50 to 600 users. The total environment is about 2,000 systems.

- Each of these 10 sites have a local file server, with a shared folder called "SophosRepository"

- In SEC, there are 10 Update policies. Each policy is assigned to an office, and points to the local file share for the primary update. The secondary update is Sophos directly.

How is this for effectivness? My understanding is that the primary SUM server, being configured to get its updates every 60 minutes, will then connect to each remote file share and update the files in the CID folder (if any updates are available).

Should I be running more than one SUM server? 

- one in each site?

What is a typical structure for a 2,000 endpoint SEPP/SEC setup? 

:15867


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

    Hi,

    The main thing you could do is as you suggest, install SUMs at each site which create local update locations. The benefits being that:
     

    1. The remote sites would be "pulling" updates from either the main SEC server or Sophos or both for failover.  These "pull updates" could happen in parallel also.  At the moment the main SUM is pushing updates to the various locations in turn so a slow link could delay other update locations.  

      That being said do you know how long an update to all update locations take for a minor IDE update and for a major version update?
       
    2. Having the other SUMs pull updates from a HTTP location, could also tighten security in terns of firewalls? 
       
    3. The clients at all sites are currently dependent on the site where your SUM is always being available in order for them to get the latest updates.  If your SEC SUM stopped updating or was unable to push an update to a update location,  the clients at a remote site would still find the local update location share and wouldn't fail over, they just wouldn't suspect anything was wrong.  If they were updating from locations locally maintained by local SUMs potentially updating from Sophos if the connection to the primary failed, that could offer some resilience to this problem.

    I hope this offers something to think about.  I would suggest if you think this is an possible change you would make, test with 1 pilot site first using a remote SUM and see how you go.  I would suggest that all SUMs should use the same subscriptions rather than creating separate subscriptions for each SUM.

    Regards,

    Jak

    :15869
Reply
  • 0

    Hi,

    The main thing you could do is as you suggest, install SUMs at each site which create local update locations. The benefits being that:
     

    1. The remote sites would be "pulling" updates from either the main SEC server or Sophos or both for failover.  These "pull updates" could happen in parallel also.  At the moment the main SUM is pushing updates to the various locations in turn so a slow link could delay other update locations.  

      That being said do you know how long an update to all update locations take for a minor IDE update and for a major version update?
       
    2. Having the other SUMs pull updates from a HTTP location, could also tighten security in terns of firewalls? 
       
    3. The clients at all sites are currently dependent on the site where your SUM is always being available in order for them to get the latest updates.  If your SEC SUM stopped updating or was unable to push an update to a update location,  the clients at a remote site would still find the local update location share and wouldn't fail over, they just wouldn't suspect anything was wrong.  If they were updating from locations locally maintained by local SUMs potentially updating from Sophos if the connection to the primary failed, that could offer some resilience to this problem.

    I hope this offers something to think about.  I would suggest if you think this is an possible change you would make, test with 1 pilot site first using a remote SUM and see how you go.  I would suggest that all SUMs should use the same subscriptions rather than creating separate subscriptions for each SUM.

    Regards,

    Jak

    :15869
Children
No Data