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

New to Sophos, would like to confirm some understanding

Shuurajou

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.

:57443


This thread was automatically locked due to age.
  • 0

    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
  • 0

    Hi Christian,

    Thanks for your reply. Looking at your example a bit further to validate my understanding...

    If you were looking to use XML to configure unmanaged endpoints and didn't want to impact managed endpoints, would I be right in thinking you'd need to have a seperate CID that unmanaged endpoints would check in with? My thinking being that if I was to put this XML in a centrally shared CID then those same settings would impact the managed clients with a detremental affect to my ability to manage them using policies that live within the console.

    I assume that the explicit 'comply with' step isn't normally required for an endpoints to pick up the policy.

    In a scenario where a managed endpoint somehow ended up with any config defined by xml, would I be able observe this by looking at the status in the 'policy compliance' column when viewing managed computers specifically?

    Thanks again,

    Kirk

    :57447
  • 0

    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
  • 0

    Wonderful. Thanks Christian!

    :57449
Unfiltered HTML