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

Scripted push of the "Comply with Policy" task

I have several humdered machines on site that state they are "Differs from Policy" this is because of a change to the AV policy since the build of the "Gold Image", I can, from the Sophos Enterprise Console, select all machines with the Differs from Policy issue and Right-Click and "Comply with AV/HIPS Policy", however I would like this to be an automated process once an hour.

i.e. a winodws scheduled task on the sophos sec server that communicates with the Management Server and perfoms the "comply with " RMS message

Can you Help?


This thread was automatically locked due to age.
  • Hello SHIGGS,

    are the computers reset upon reboot or were they just built from the image or is this a virtualized environment? If the policies applied from SEC persist it should not be necessary to repeatedly force compliance.


  • Thanks for getting back Christian

    In this case, the computers are reset on reboot. The policies that are applied get wiped when the machines is logged off as the virtual machine is powered down overnight, then powered up again with the gold build.


  • Hello SHIGGS,

    you will rather sooner than later have to rebuild the image to incorporate one of the major updates. Your image should resemble the desired configuration as closely as possible.
    There are reasons for not having SEC shoving down policies automatically and unconditionally. Virtual environments are still rather new and need a different solution. I can imagine that the clients request the current policies when starting - but you'd need a way to turn this off before it starts in case you want to collect some evidence for example.

  • Christian

    The Image is "Built" every month, but as the Console remembers the machine listing in AD there is no Pull, or Push of the policy. So the clients do not request the current policy when starting, hence the need for a scripted solution to push the policy to all "Differs from policy" without the need for an administrator being logged onto the console.

    Idealy this solution can send just the SAU, SAV or DevC policy out or a combination of the three.

  • I'm not aware of anything available to interface with the Sophos Management Service to initiate a push of policies.

    You could however, remove the adapter storage files ("\ProgramData\Sophos\Remote Management System\3\Agent\AdapterStorage \") from the client and stop the agent service before creating the image.  This way, when the client starts up, the service will start and it will send back to the management service a no-ref status, which will force the management server to send the machine policies it is missing.  This is essentially what happens to enable the client to get its original policies.

    Maybe you could leverage this behavior.




    I have no idea how this could be hacked into the current implementation (apart from the fact that this would be a somewhat dangerous feature). There is no interface available.
    A client does not request the policies once it is installed. SEC pushes a policy when a different policy is assigned (this includes the client being moved to another group with a different policy), the assigned policy changed or "comply with" is requested.

    Anyway IMO the "correct" behaviour would be that imaged clients request the policies from the console when they start. Maybe this could be done but I don't know the details. I suggest you contact Support directly.
    [edit:] just read your post, Jak. Thought along the same lines but was reluctant to suggest it as I don't know how reliable it is. That is, for a significant number of clients the "Awaiting policy transfer" after install does not change unless compliance is enforced. No problem for me but here this would be.

  • Christian.

    I like the idea of removing the adapter storage files, if you are sure that a client sending a "no-ref" rms message will result in the management server replying with all the policies.

    It's a shame that there is no interface with the management service to automate these daily tasks. how about a direct SQL injection into the "Poicy" table's xml?

    I'll put the "remove adapter starage" suggestion  forward and see if it closes htis tread.


  • Hello SHIGGS,

    credit where credit is due - it was Jak who first suggested removing these files. As I said I haven't tested whether this will result in successful request and transfer of the policies "in all cases". I've just verified that the status changes to Awaiting policy from console after clearing the storage and rebooting. The client next performed an update (which took in this case several minutes) after which the policies were received and applied and the adapter storage populated.

    It's a shame that there is no interface with the management service to automate these daily tasks

    Re-applying the policy is not (or hasn't been) a daily task. Clients get notified of policy changes and if they can't be reached the message is queued. Admittedly these messages eventually time out when the client is offline for an extended period. But then you don't change policies on a regular basis. Now and then you'd check for non-compliant clients (SEC assists you in selecting them), you force compliance and that's it.

    SEC (and the underlying database) is not designed to do these things on its own (or to assist automated operation beyond that what's already there). There's a whole lot of things you could mess up. Most of the "daily work" is IMO dealing with alerts and from time to time "problem cases". You neither need automation there nor would you want some automated task to interfere. It's running fine as it is - at least that's what I've come to think after several years.

    Admittedly virtualization is a new challenge. I can see two ways how this could be addressed:

    1. A special setting where clients request policies after reboot
    2. A group attribute (indirectly a computer attribute) which causes policies to be supplied after a router logon from a client which belongs to this group (note that "pushing down" policies at regular intervals could severely impact performance)

    I strongly advise against any attempt to fiddle with policy tables (apart from the fact that IIRC changing the xml will not fire a trigger) or the database in general except with the provided tools or in the documented ways (or when instructed by Support of course).


  • Had a same problem on citrix. after reading multiple articles i have found a solution.

    Computer GPO > scheduled task


    .bat script 

    cd "C:\ProgramData\Sophos\Remote Management System\3\Agent\AdapterStorage\SAV\"
    del * /q
    net stop "Sophos Agent"
    net start "Sophos Agent