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

Ports and UNC paths

CDEvans

8192 is used for the clients to report back to the enterprise server (according to Sophos telephone support), would that port be displayed on the client as a remote port or a local one.

A number of clients are displaying it as a local port, but not a remote one, they are also not reporting back to the EC, and I'm trying to find out why.

Another issue is.

How can I force Sophos EC to use IP's rather then machines names, Sophos refuses to allow me to use \\<ip> and insist on me using \\<machinename>

One other thing,

On the main screen of the EC it tells me that :

An update manager has not updated since 04 march 2011 16:31

However, looking at the update managers of which are 3, only the one with the EC has an error of "Software delivery failed" which only deliveres to itself and updates direct from Sophos just like the other two.

So as far as I understand it, it's failing to update itself but quite happy to update what little clients it wants to respond to, how would this even be possible, the UM should download the update and place it into the share that the clients use, this it is doing according to the clients but it isn't according to the server?

:11229


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

    I see (and I already started to suspect this).

    What could you protect against with this setup?

    1. Let's start with the management server (the SEC): If it goes belly up (hardware or OS) your installation (all three sites) will be unmanaged until you get it working again. There's no built-in failover mechanism (like, say, a clustered or a stand-by SEC) although with some preparation you can implement a stand-by solution. Given that with careful planning (and spare hardware) you can "restore" your SEC within a few hours at most I think it's not worth the effort.
    2. If a secondary SUM similarly fails you wouldn't be able to write to its share anyway - so here too your proposed wouldn't help.
    3. Assuming one of the SUM components fails and doesn't write to the share. You could of course instruct one of the remaining two to manage the failing ones share(s) (there's no mechanism for concurrent updating of a CID - concurrent updating will cause serious troubles). But what next? You can't restore or debug this SUM as it must not write to its default share. On way to implement redundancy is to not actually use the default share (the SUMs will always distribute to it so you will "waste" this space) and let the clients update from the additional share. In case of a failure you can then let another SUM write to it.
    4. If a SUM fails to download from Sophos this can have two distinct causes: Internal failure or network problems. In the latter case inter-site connectivity might also suffer but in principle you can use the other SUMs as additional sources. Letting my imagination run wild I can think of a possible race condition in this case though (Sophos correct me). In case of an internal error updating will likely fail from any source - so nothing gained here.  

     All in all you can address only a subset of potential problems and you need manual intervention in case of a failure. I think that only the third scenario offers some benefit.

    Christian

    P.S.: There is a simple way to distribute to another SUMs default share - but I strongly recommend against it (see above)  

    :11391
Reply
  • 0

    I see (and I already started to suspect this).

    What could you protect against with this setup?

    1. Let's start with the management server (the SEC): If it goes belly up (hardware or OS) your installation (all three sites) will be unmanaged until you get it working again. There's no built-in failover mechanism (like, say, a clustered or a stand-by SEC) although with some preparation you can implement a stand-by solution. Given that with careful planning (and spare hardware) you can "restore" your SEC within a few hours at most I think it's not worth the effort.
    2. If a secondary SUM similarly fails you wouldn't be able to write to its share anyway - so here too your proposed wouldn't help.
    3. Assuming one of the SUM components fails and doesn't write to the share. You could of course instruct one of the remaining two to manage the failing ones share(s) (there's no mechanism for concurrent updating of a CID - concurrent updating will cause serious troubles). But what next? You can't restore or debug this SUM as it must not write to its default share. On way to implement redundancy is to not actually use the default share (the SUMs will always distribute to it so you will "waste" this space) and let the clients update from the additional share. In case of a failure you can then let another SUM write to it.
    4. If a SUM fails to download from Sophos this can have two distinct causes: Internal failure or network problems. In the latter case inter-site connectivity might also suffer but in principle you can use the other SUMs as additional sources. Letting my imagination run wild I can think of a possible race condition in this case though (Sophos correct me). In case of an internal error updating will likely fail from any source - so nothing gained here.  

     All in all you can address only a subset of potential problems and you need manual intervention in case of a failure. I think that only the third scenario offers some benefit.

    Christian

    P.S.: There is a simple way to distribute to another SUMs default share - but I strongly recommend against it (see above)  

    :11391
Children
No Data
Unfiltered HTML