Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 4 replies
  • Subscribers 2 subscribers
  • Views 3600 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

Message Relay Clarification

Eric Meinders

Background/Goal:

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):

Questions/Issues:

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:

  • Section 1.1 on the Message Relay instructions states "You must create a new distribution point" to set up a new update location for the message relay.  The instructions state to create this new update location, but doesn't necessarily clarify what that is, or how to go about this.  I assume the distribution point/update location is where the message relay pulls policies, updates, etc.  If that's the case, can I just use my existing management server as the distribution point/update location?  If so, does this require any additional package creation, or do I just use my existing S000\SAVSCFXP location?
  • If I can use my main management server as the update location/distribution point, my next question is after I drop the mrinit.conf file into the "rms" subfolder located in "\\[Management Server]\SophosUpdate\CIDs\S000\SAVSCFXP" and insert my message relay [IP-address],[FQDN-address],[NETBIOS-address] into the ParentRouterAddress field -- where do I run the ConfigCID.exe?  The KB mentions to run this "On the server with the Sophos Management Service" so I would assume my management server, but then mentions to enter "configcid \\[servername]\SophosUpdate\CIDs\S000\SAVSCFXP\" with the "path to the distribution folder".  If I use my management server as the distribution point, would that just be my management server path?  -- \\[Management Server\SophosUpdate\CIDs\S000\SAVSCFXP

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?

Specifications:

Sophos Enterprise Console 5.5.1 on Windows Server 2012 R2

Message Relay is Windows Server 2012 R2



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

    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 when
    a) dieploying (the Distribution tab in Configure update manager) software and updates
    b) creating the updating policies
    The 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?

    Christian 

Reply
  • 0

    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 when
    a) dieploying (the Distribution tab in Configure update manager) software and updates
    b) creating the updating policies
    The 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?

    Christian 

Children
No Data
Unfiltered HTML