Video Screencast Help

SEPM - Policy refresh

Created: 26 Apr 2012 • Updated: 30 Jun 2012 | 2 comments
This issue has been solved. See solution.


I have a question regarding how SEPM policy refresh works.

Looking at some documents, it seems at heartbeat interval, it does a "security policy" update. So what are the security policies?

To test, i made a reghack to enable manual liveupdate from a client. (i.e. previously, the liveupdate button was grayed out.. but now it is available).

Our heartbeat is set for 5min, and the policy has not been restored. Does that mean, the liveupdate lockdown is not classified as "security policy"?

Is there an option in SEPM to restore all the policies set in the clients? (policies updated at set interval, or a manual blanket update, such as gpupdate /force in Windows).



Comments 2 CommentsJump to latest comment

P_K_'s picture

The SEP client heartbeat interval is normally controlled by communications policies set at the Symantec Endpoint Protection Manager (SEPM). In certain situations, the SEP client will decrease its heartbeat interval to a value between 0 and 60 seconds. The purpose of this accelerated heartbeat is to ensure that critical updates and content are delivered to clients in as timely a manner as possible. Once the client is able to download the content update or package requested, the client will then re-apply the heartbeat interval configured at the SEPM level. It is not possible to configure clients' Accelerated Heartbeat intervals.

The SEP client can enter an accelerated heartbeat period for several reasons:

  1. While waiting for content to be prepared by the SEPM for download
  2. When the client's configuration has changed
  3. When the client has resumed from hibernation
  4. After the SEP client's profile is updated
  5. After an Internet exception occurs while trying to get an updated index2.xml file from the SEPM

MCT MCSE-2012 Symantec Technical Specialist (SCTS)

Beppe's picture


the product works in this way:

1) change a policy in the SEPM
2) the SEPM publishes the new policy and update an index file with the new hash of the policy
3) at the heartbeat, SEP client checks the index file in the SEPM and compare it with the one it already has
4) in case of differences, the new policy is downloaded and applied, otherwise nothing happens

ALL policies are managed in the same way.

If you manually change a registry key in the SEP client, nothing changes in the index files hence nothing is reapplied. You cannot reapply/force a policy already applied. The trick is to modify a policy in a non-significative way (like the description) and save it, this will change the hash and force the policy to be reapplied.

Now, what can you do to prevent SEP policy tampering?
Users should not have enough privileges to change the registry leys;
In SEP 11.0 you can enable the Application & Device Control Policy to lock down SEP registry keys and files;
SEP 12.1 has registry and file protection enabled by default.