Note: Due to personnel changes, I am assuming responsibility for our Sophos infrastructure, and I am in no way a SME on this.
My organization recently acquired a new company's infrastructure, in a remote location, on a separate domain. We are using Sophos Enterprise Console 5.5.1 for our internal assets, and the goal is to install Sophos on their devices, and manage them from our internal management server. It's worth noting we will only be managing a very small handful of their devices -- roughly 10-20.
I was led to believe that creating a message relay which is publicly accessible for their domain, within our DMZ, is the correct way to accomplish this task - as illustrated in the following KB (https://community.sophos.com/kb/en-us/50832):
I've created a Windows 2012 R2 message relay and installed Sophos Endpoint Security and Control on it. After reading through this KB on creating the message relay, and this KB on using the ConfigCID.exe, I am a little fuzzy on the following details:
TL;DR -- Can I use my existing management server as the distribution point/update location, and if so, do I run ConfigCID.exe from the management server with configcid \\[Management Server]\SophosUpdate\CIDs\S000\SAVSCFXP as the command?
configcid \\[Management Server]\SophosUpdate\CIDs\S000\SAVSCFXP
Sophos Enterprise Console 5.5.1 on Windows Server 2012 R2
Message Relay is Windows Server 2012 R2
Hello Eric Meinders,
I'll address the various aspects individually before trying to put everything together.
a distribution point is a CID, and a CID contains amongst other things the mrinit.conf. If you have a group of endpoints that doesn't use a relay and another one that does they have to use different mrinit.confs. Thus you can't use the same CID for them.
CIDs follow a certain naming convention that is applied by SEC/SUM whena) dieploying (the Distribution tab in Configure update manager) software and updatesb) creating the updating policiesThe naming convention is \\share\CIDs\Stag\product, where share is arbitrary (the default \\SERVER\SophosUpdate is always present and distributed to), CIDs is a constant, Stag is the subscription short tag that starts with a constant S followed by a number that identifies a certain Software Subscription (Recommended has usually S000, if you add another one it gets S001 and so on), finally the preassigned product part (the platform specific SAVSCFXP, ESCOSX, savlinux and potential extra products like OPMHMPA or the meanwhile withdrawn ENCRYPTION).
Same rules apply to updating policies. You can choose the (Primary and optionally Secondary) Address and select a subscription. SEC then builds the full address that AutoUpdate uses.
Insertion: As you intend to use a Message Relay your endpoints will likely not update directly from the management server, will they? You might consider setting up the relay also as SUM.
Obviously you need two different update locations - different address, different subscription, or both. Consequently you need two updating policies, one for each location
ConfigCID.exe is needed to integrate changed or additional files into the CID and its catalog that is signed with a key from the CertAuthStore. This key exists only on the management server and therefore the tool is usually run from the Management Server. Though the CertAuthStore can be imported on another computer if necessary. Note: Putting mrinit.conf into the \rms subfolder is not required when you set up the relay and distribution point before installing the remote endpoints. When existing managed endpoints detect a new or changed mrinit.conf in the \rms folder they will reconfigure RMS accordingly. If they have the correct configuration from the start this is obviously not necessary. There's a gotcha: Endpoints preserver the original mrinit.conf, if they happen to update from an unconfigured CID they fall back to the original that might no longer be valid.
Summary:I'd suggest an MR/SUM combination with mrinit.conf set up appropriately (ConfigCID.exe not needed). If the MR/SUM is in your DMZ and not at the remote site you'll probably use an HTTP update location. In this case you won't be able to use Protect, a custom package is likely the best method. If you configure a secondary update location make sure it contains the correct mrinit.conf (or use Sophos).
Anything I forgot?