Secondary update location?

Hello Louis-M,

as the endpoints communicate using RMS you'd need a message relay (or otherwise a perhaps NATed connection to your management server). jak would recommend to consider Sophos Central (and eventually moving the management completely to the Cloud) but SEC and Central would be independent.

Christian

I'm leaning towards putting a message relay server in a DMZ.

Would doing this allow the external clients to communicate with the Sophos server and then receive updates etc from Sophos (secondary update location) when they are remote?

So that any policy change is applied to remote clients and the clients report back to the internal Sophos server to say they are compliant etc?

Hello Louis-M,

a message relay would enable the remote endpoints to report back their status regardless of where they're updating from. Please note that if they are updating from Sophos they will report updating errors for RMS. The Primary is checked first and if it fails an error (it's rather a warning) will be reported even if the Secondary succeeds (AutoUpdate usually sends only one error per cycle, i.e. only for one of the products). Furthermore RMS can only be updated from the associated management server and thus it won't get updated at all - as this is the most severe error in the cycle this is the one that gets reported (endpoints will also show the red cross). This is the expected behaviour. Actual minimum updating interval with Sophos as source is one hour, if the policy specifies a shorter interval it's ignored. Even though you'll always get an error for RMS the Up to date column will indicate otherwise successful updates.

Endpoints will receive policies, please note that if the "parent router" (relay or management server) can't connect to the endpoint's port 8194 policies and commands can't be pushed but can only be sent in response to a message from the endpoint thus there'll be some latency (but normally less than one hour) when applying policies.

Last but not least: As the (occasionally or usually) remote endpoints always communicate via the relay they need to be able to connect to the relay when they are on the LAN.

Christian

Hi Christian,

good info there. Would I be barking up the wrong tree if I:

1. Created an MRS in the DMZ
2. Create an IIS update site on the MRS and expose it to the web with an external dns of sophosupdate.myexternaldomain.com = 4.4.4.4
3. Change internal update server to http rather than smb suing IIS and use the the above dns name but change the ip on the internal dns server to 192.168.100.1

This way, all hosts (internal & external) will update at sophosupdate.myexternaldomain.com (which in effect is the internal server for internal clients and the DMZ update server for external clients)

All hosts will then be able to report back to the primary update server as well as the MRS

Hello Louis-M.

didn't dare to mention it but split-DNS is indeed an option. BTW: You also will install SUM on the MRS, won't you? The tricky part is the relay and mrinit.conf. Hm ...

A computer determines its role (endpoint, relay, server) and its upstream router from mrinit.conf. Quoting myself (with the author's permission): Please note that there is an MRParentAddress and a ParentRouterAddress in mrinit.conf. These are used by RMS to determine its Router-type by comparing the specified addresses with the respective local values. If there is a match in MRParentAddress it's server (i.e. the management server), else if there is a match in ParentRouterAddress it's message relay, otherwise (there is no match) it's Endpoint, thus you have to make sure that server and relays correctly recognize of the "addresses" as their own.

Endpoints use ParentRouterAddress to find their router, thus putting just sophosupdate.myexternaldomain.com there is probably the right thing as also (provided the relay also uses the external DNS) the MRS should be able to correctly determine its role. MRParentAddress must uniquely point to the management server though. Using the internal address 192.168.100.1 should give the desired results, a name is more flexible but the MRS must be able to resolve it correctly.
It's not documented (and probably unsupported) but I'd suggest that you modify the mrinit.conf in %ProgramFiles(x86)%\Sophos\Update Manager\, this will get copied to the root of the CIDs when SUM updates them. Do this and make sure it's copied to %ProgramFiles(x86)%\Sophos\Enterprise Console\SUMInstaller\ (the SUMInstallSet share) before installing SUM on the MRS (as you won't use a custom mrinit.conf you can install directly from the share though) .

I have not done this, it's not tested. You might want to check what your management server returns as IOR. RMS works like this: A client first tries port 8192 on the ParentRouterAddress addresses until it receives an IOR. telnet address 8192 should return a string which you can parse with the ILU IOR Parser. The actual connection is then made to port 8194 on the hostname returned in the IOR. If necessary the returned hostname can be modified - please see the MR article for the finicky details.

One more thing: If your Primary is HTTP it can't be used to Protect Computers from the console. Protect Computers requires SMB and if necessary you can specify an appropriate location under Initial Install Source in the updating policy.

Christian

Hi Christian,

happy xmas by the way. All very good info there. I didn't realise the caveat with http as the primary update. I'm not keen on using smb for external clients either although the sum would be in a dmz.

I'm wondering if the following would suffice:

SMB for primary

MRS with SUM installed in DMZ with http of SUM set as secondary?

Seems to be slightly complex just to have clients report back and update when they are remote without reporting update errors or last seen etc?

Hello Louis,

thanks, same to you [:)]

SMB as primary
the default share is always there, you don't have to use it in the policies but if you want to Protect Computers it must be specified in the Initial Install location. HTTP as Primary with a name that resolves to the desired server depending in the endpoint's location is fine.

Christian