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

Having issue in some machines, they are not getting Automatically Policies and status shows "Awaiting Policy Transfer"

Having some of the machines issue with Automatically Applying Policy. The message is "Awaiting Policy Transfer". I manually need to push comply with All Group Policies and then Update Manually to take effect.

This is causing issue in some applications and accesses to network for the machines having this message.

How often the policies should refresh and if this is not automated how to figure it out and resolve the issue.

 

Thanks in well Adv.

Regards

Faisal



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

    when a policy is changed and can't be sent to a machine the message is enqueued, next time the machine('s RMS) connects the policy is sent. The messages aren't kept forever though, usually they have a TTL of 96 hours (4 days). After that they are discarded, SEC will still show Awaiting ... though. As you correctly said, you have to use Comply with ... (requesting an Update isn't necessary).

    Thus it should only be an issue with machines that aren't online (or at the site) for longer periods. You could increase the TTL but this might cause a buildup in the Envelopes folder.

    Christian

  • Hello QC,

     

    Based on the link shared, we don't have any key defined in Registry. Should there be any value or it has no value defined by default setup.

    What's the best practice value if we need to create. Please see the screenshot of our current setup.

    Thanks

    Regards

    Faisal Raza

  • Hello Faisal,

    the article says create so the key is not there by default. As said, consider the potential buildup of queued messages when you increase the TTL.

    Christian

  • Hello QC,

    Thanks for your ever quick and best reply.

    What's the best practice value to set for TTL? I've 4 update servers.

    Thanks

    Regards

    Faisal

  • Hello Faisal,

    as you can read in the article the value used to be two weeks until SEC 4.5. Apparently four days is deemed a reasonable compromise, IMO there's not a best practice as a suitable value depends on several factors. If you have a significant number of endpoints that are "inside" (and thus manageable) just once a week a TTL of eight or more days might be convenient. If OTOH a larger portion of your endpoints checks in very infrequently and you also change your policies several times a week then the buildup of envelopes might have an adverse effect on performance.
    Thus generally I'd say the TTL should be long enough so that the majority of endpoints will check in before it expires. If one or more of your policies change very frequently the TTL and many endpoints don't check in on a regular basis a shorter TTL should be chosen to avoid enqueuing of several versions of a policy.

    4 update servers
    you mean SUMs (and possible message relays) but only one management server? Please note that the setting only applies to the management server.

    Christian     

  • Hello QC,

     

    Yes there are 3 SUM and 1 Management and 1 out of 3 SUM is Message relay. We have approximately 1500+ machines and the policies are not frequently changing, just like once in a quarter year in case if there is any change require.

    It will be in seconds and to maintain well there's no harm for setting up the TTL to 604800 Seconds? which are equal to 7 days.

     

    Thanks

    Regards

    Faisal Raza

  • Hello Faisal,

    7 days should do no harm, just watch the envelopes folders (both management server and relay).

    Christian

  • Thanks QC,

     

    Really always helpful response from your side. So by default it is 2 weeks TTL. I'll firstly try with 7 days or 4 days and will see the affect.

     

    Thanks again,

    Regards

    Faisal

  • Hello Faisal,

    by default it is 2 weeks TTL
    no - it was 2 weeks until SEC 4.7 which changed it to 4 days.

    Christian