We'd love to hear about it! Click here to go to the product suggestion community
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?
Hi Eric Meinders
Distribution point should be the message relay server as the outside client will only be able to receive the update from Message relay, not from the Management Server.
For config CID, please run the command on management server with configcid \\messagerelay server\SophosUpdate\CIDs\Sxxx\SAVSCFXP.
You can refer for this video your configuration.
In reply to Jasmin:
That video was extremely helpful, and I was able to create the Message Relay, created the Distribution Point shared folder, added it to Distribution from [Management Server], successfully ran ConfigCID.exe. Everything in the video worked.
My only question/issue, is the very last section of that video -- after creating the Message Relay group, and Message Relay policy to that group, then adding the [Message Relay] server into the group.
Our issue, is that we are using AD Synchronization, and our [Message Relay] is obviously in one of our OU containers -- since it's domain-joined and needs to talk to our [Management Server] -- so, when I go to move the [Message Relay] into the newly created Message Relay group I created, it can't be moved since it's part of a synchronized group. From what I see, any machine in a synchronized group, cannot be moved.
So, I guess my question(s) are:
In reply to Eric Meinders:
Please refer to the below answers for your questions:
1. If moving the server to different OU in its own OU, it is good because we need to apply the policy to make it working as Message relay.
2. Please refer to this KB, I think you have already referred it before as well. You need to choose the scenario which you are going to implement. Also, I'd like to know whether the computers in another company is going to use a VPN to connect to your network or not. You can deploy the protection to external clients through deployment packager as well but first, need to make sure MR is working on DMZ.
For the group, you can create a group out of your AD sync for those new endpoints.
3. If you use the scenario 2 in the above mentioned KB, then you need to configure the mrinit.conf as below. MR.domain.com should be resolvable on the internet as mentioned in the above KB. "MRParentAddress"="192.168.0.3,[Console-FQDN],[Console-HOSTNAME]" "ParentRouterAddress"="MR.domain.com"