Pull instead of push msg?

Hello DanZi,

If there's an update, the console floods the envelopes folder
I'm not sure if I understand you correctly, you seem to use update with different meanings: In this sentence you are referring to a policy update made in the console whereas in pick it up after the next update it's the software/detection data update the endpoint performs. Is this correct?

Christian

Hi Christian,

Sorry, meant to use the word 'change'. So I mean if you change the policy (e.g. application control) and add another white listed or black listed app - in this case the console will present a warning pop-up and let you know that 'hey, these 5 groups are affected by this policy' - then u click ok, and the console tries to force those machines to pick up the policy - flooding the Envelopes folder.

I was just wondering if this is the only way a new policy would reach the endpoint. Or, when the client is due to check for an vdl or an ide update - it could pick up the policy too.

The latter would allow for the console to just mark the clients as out of sync, but allow them to update the policy at the next scheduled time when they check for AV update...

DanZi

Hello DanZi,

I'll start with a description how it's supposed to work, but first of all - updating and communication are independent. If a local admin disables updating you'd no longer be able to manage the endpoint.
When an endpoint is started up RMS establishes a connection to port 8194 on the server (or relay). The server attempts to connect to the endpoint's port 8194. If this connection can be established it is used to push policies and commands to the endpoint. Otherwise the messages are queued and sent on the upstream connection in response to a message from the endpoint. It's by design that the management service does not directly communicate with the endpoints (won't go into details here).
If you make a change that affects hundreds or thousands of endpoint you'll see the flooding even if all endpoints are active and have a downstream connection. Usually the queue is worked off within minutes but messages to disconnected endpoints stay. They are discarded when they expire (usually after 4 days). Unless you frequently make changes and a larger part of your endpoints is disconnected for longer periods the queued messages shouldn't really cause a problem.

Maybe RMS on the server can't establish these downstream connections (it's possible that RMS on the server is "running out of ports" - if an endpoint doesn't log off correctly the socket on the server side isn't freed. It's a good idea to restart the Message Router at regular intervals).

Actually it's the store and forward mechanism that causes this (seeming) problem. Arguably it is no longer needed with today's networks and processing power (MCS, RMS's counterpart for the Central/Cloud product has a different design), IMO (judging from posts in this forum) it's not yet obsolete though.

Christian     

Christian,

That's the problem I face at a client's site. Basically the recommendation is to use less than 4K clients. I'd use 3K tops, but in this case the number of clients connecting directly to the management server is waaaaay beyond the recommended value. I don't even dare to day by how much. So any update on the console renders it pretty much useless, I doubt it would have the free bandwidth (in RMS' terms) to even report an outbreak. 

It takes 24-36 hours for the messages to come down to a reasonable value in the queue...

So I was hoping to find an interim solution for proper management as modification in the environment is unlikely at this point in time.

While policies still need to change on a regular basis (e.g. when Sophos adds a newly controlled app) I'd like to be able to rely on the console's status reports, but I feel I am out of sync with what's really out there on the network.

DanZi

Christian,

That's the problem I face at a client's site. Basically the recommendation is to use less than 4K clients. I'd use 3K tops, but in this case the number of clients connecting directly to the management server is waaaaay beyond the recommended value. I don't even dare to day by how much. So any update on the console renders it pretty much useless, I doubt it would have the free bandwidth (in RMS' terms) to even report an outbreak. 

It takes 24-36 hours for the messages to come down to a reasonable value in the queue...

So I was hoping to find an interim solution for proper management as modification in the environment is unlikely at this point in time.

While policies still need to change on a regular basis (e.g. when Sophos adds a newly controlled app) I'd like to be able to rely on the console's status reports, but I feel I am out of sync with what's really out there on the network.

DanZi

Christian,

Am I right believing that EM-SetConfiguration type messages do not just get created randomly. They are only spawned by the Console in case there's a policy change and it needs to propagate the new policies to the clients in the affected groups?

Many thanks,

DanZi

Hello DanZi,

yes, AFAIK. The management server sends/enqueues them when a policy's settings are changed, a policy is applied (changed with View/Edit Group Policy Details ... or endpoint moved to another group), or Comply with ... is used. Enqueued messages eventually time out. There's no mechanism that resends the messages until an endpoint accepts them.

Christian