New to Sophos, would like to confirm some understanding

Question

Hi All,

I've inherited an existing Sophos deployment in a new job role. Been trying to familiarise myself with our implementation and look at the documentation and kb articles available online to understand what I'm dealing with and how/why it's been configured the way it has (nothing wrong with it, just want to understand it intimitely as I'll be running it now). I wanted to validate a little bit of what I think I've grasped... hopefully this is the right sub-forum for it. Currently using SEC 5.2.1 R2.

A Central Installation Directory (CID) is essentially what SEC will use as 'bootstrap location', meaning the place where it stages all the software client assets for whatever software subscriptions I have setup.
Clients will also refer to the CID to pull down their updates (including ides?).
You can have more than one CID if you desire.

An area where I'm struggling to understand at the moment is regarding exporting policies as xml and then the use of ConfigCID. Reading the kb articles, my takeaway is:

A vanilla out of the can CID would not contain any xml files.
The XML files need to originate from policies in the SEC and are exported using ExportConfig.exe.
Once the XML is exported, it will need to be named correctly and placed into the correct CID subdir as per the kb article.
ConfigCID will need to be run against the CID where the xml was placed, so that the next time a client phones home for updates, it will pull down the XML.

I'm trying to understand what the use case for the xml files are. As I understand it, Sophos AV clients will periodically download the policies specified in the console anyway - so why the need for the xml? Do unmanaged clients not pull down the console and thus the xml is used in this case? Perhaps the xml can be used for the initial baseline configuration, but then policy from console will take precedence if they are different?

Thanks for reading! Hopefully I make some vague sense.

This thread was automatically locked due to age.

QC · Accepted Answer

Hello Shuurajou, quite correct. As to XML policies: They are usually not needed for managed endpoints (although there are a few arcane uses like Centrally configuring the filtering of messages from workstations ). They can be used to make changes to the settings on unmanaged endpoints (e.g. if for some reason the CID location has to be changed). Changes on managed computers effected by XML files will not automatically be overridden by central policies though. A change in the central policy assigned to an endpoint (edit, assignment of a different policy, move to another group) and an explicit Comply with ... will cause the policy to be sent. Christian :57446

QC · Answer

Hello Kirk, a seperate CID is one way Once an endpoint has cached (and processed) an XML policy it is only applied again when it changes. Thus if you change the policy in SEC the managed endpoints will not revert to the XML policy in the CID. Also if the XML policy is the export from that assigned to the endpoints the compliance status will naturally be Same . If the XML policy is different and a managed endpoint has for some reason applied it you will see Differs from policy . You'd not lose your ability to manage this endpoint. Christian  :57448