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

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