Ports and UNC paths

So port 8194 would be the port that stops a client reporting back to the server it's status

As some clients do report the port is obviously open on the server. A firewall (client or on the network path) or access list might of course be blocking this port.  If you telnet server 8194 from a not reporting client and get a connection (which closes after a few seconds) then it's not the network or a firewall.

First thing to check is the Sophos Network Communications Report (accessible from the Programs menu). If it doesn't show an obvious error (or no error at all) then the ClientMRInit log (in %Windir%\Temp) and/or the router logs ([Appdata|ProgramData]\Sophos\Remote Management System\3\Router\Logs) will help resolving the problem.

Christian

Sophos is the only location it searches for updates from, but it failes to update the distribution share with the information it gets from the source (if that makes sence)

I think I've found the issue with reporting, If I remove it from the server, and remove (from the client) every sophos product, restart, remove the sophos directory, restart, install it from teh server share, it works fine :) it installs and reports back fine, or at least, I've not found one that hasn't of yet... maybe some old files are messing it about.

I need the IP due to an issue with DNS\wins we are having that server support are unable to track down:smileymad:

Accross the three sites, I can find machines via IP but not via Name, I've got all three update servers updating from Sophos right now but no backup of each other for updates or distribution shares.

Across the three sites, I can find machines via IP but not via Name, I've got all three update servers updating from Sophos right now but no backup of each other for updates or distribution shares

So your SUMs are independent and full management servers? And you want them to be able to update each others CIDs (the SophosUpdate share)  "just in case" so that their respective clients will continue to receive updates?

Christian

One server is a Enterprise Console , the other two are just update servers(CIDs) (which as far as I can tell is managed by the EC for the GUI)

All 3 update only from Sophos.

All 3 only deploy the update themselves.

What I'd like,

All 3 update from sophos and each other for backup.

All 3 deploy the update to themselves and each other for backup.

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)  

but it fails to update the distribution share with the information it gets from the source

It's you who has the logs available so of course I can't prove you wrong. Still - the little evidence you shared makes me think it fails to download. Basically there are four steps:

1. Fetching metainformation from the parent warehouse (if you see the expected list of products when editing a subscription this part works) to the SUM's warehouse
2. Downloading the encoded files for the selected products to the warehouse
3. Decoding to the Working folder
4. Deploying from Working to the CIDs

Assuming your SUMs have identical subscriptions the contents of the warehouse folders should be practically identical (same is true for the working folder).

And once more, the LogViewer will help in determining at which step it fails.

Christian

I've had a look over the logs, and the latest udpated made the following logs

Cannot create stream <path>

Decoding of product release <name or program> <software distribution name> because the sync failed.

verion not gathered by Dispatcher due to sync fail

decoding of product release wasn't done due to sync fail

From what I can gather from that, it cannot write to a file in the C:/Programdata/sophos/update manager/update manager/ warehouse/randomnumber

I'll assume that the path slashes being backwards is a bug in the log viewer and not an "issue" with the program.

1 - If the SEC goes belly up, it's restored from a backup made every hour onto another VM machine, that's ready. (which would only effect the one site, not all 3)

2 - if the a SUM goes down the clients are instructioned to fall back to Sophos direct via the 2nd update location.

Its not ideal but all I got to work with, which isn't much.