Scripted push of the "Comply with Policy" task

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

Christian

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

Christian