SEPM Communication Settings Change
In either mode, the client computer takes the corresponding action, based on the change in the status of the management server. Because it requires a constant connection, push mode requires a large amount of network bandwidth. Client computers that are configured to use pull mode require less bandwidth.
The heartbeat protocol defines the frequency at which client computers upload data such as log entries and download policies. The first heartbeat occurs immediately after the client starts. The next heartbeat occurs at the heartbeat frequency that you set.
The heartbeat frequency is a key factor in the number of clients that each Symantec Endpoint Protection Manager can support. If you set a heartbeat frequency to 30 minutes or less, it limits the total number of clients that Symantec Endpoint Protection Manager can support. For deployments of 1,000 clients or more, Symantec recommends that you set the heartbeat frequency to the maximum length of time possible. Symantec recommends that you use the longest interval that still meets your company's security requirements. For example, if you want to update policies and gather logs on a daily basis, then you might set the heartbeat frequency to 24 hours. Assess the proper configuration, hardware, and network architecture necessary for your network environment.
PUSH mode existed in the product long before it was SEP. It is carry over from the Sygate days. Back then, the manager was just a Policy Manager and didn't distribute definitions or content. The manager only handed out new Firewall policies. When we brought in AV/AS and other protection technologies and merged the products "Protection Definitions were added". This notification didn't exist in Sygate or even early SEP.
Because of some ugly growing pains and defects with the product and definition creation, delta, client side bugs requesting the wrong definitions, etc, it was a feature\enhancement request that was added to help give a SEPM admin a heads up that something might be wrong.Â
The report doesn't take into consideration if you are in PULL or PUSH mode. It doesn't account for machines that were OFF or unable to communicate with manager while traveling, or users that are on leave or vacation (all conditions where they would be more inclined to need to pull down full definitions. It also doesn't account that a large portion of the workforce may go home, shutdown and then come into work roughly the same time of day (shift changes) where again machines could all come online at the same time and ask for full.zips.  It is only looking at simple terms did the client request a full.zip of any content and if so how many requests in x minutes.
Additionally all the logic is client side for download randomization, however before that happens, the client does have to make a request to the SEPM for the content before it is added to the queue and randomized. The SEPM will log this first event (which is used in the alert) Even with enabling that setting their exists the chance that a few clients could trigger the event because "download randomization" happens after at least one request to the manager for content. Also the logic for download randomization is psudo random. Each client has no idea that another client randomized or how many clients are generating a random time. The algorithm only states that the client needs to defer trying to download content after the first request for some random time (30 minutes). A client could decide to immediately check-in and download the next second or minute or even wait 10 minutes or up to 30 minutes (whatever maximum value you set in your case it looks like 120 minutes). Download randomization can actually make this report trigger more frequently, because you will have the initial request for content, it will be added to the download queue to download later and then at some point later it will ask again. So for each download of content type, date and revision, you will generate minimum of 2 requests and depending on how it randomizes has the potential to be very close together.
Being in PUSH mode really invalidates the usefulness of the report because regardless of the randomization setting, in your case you will have 1200 machines becoming aware that SEPM has some new definitions to download and they will all try to update.Â
SEPM DB Automatic Maintenance
After you install the management server, the space in the database grows continually. The management server slows down after a few weeks or months. To reduce the database size and to improve the response time with the database, the management server performs the following database maintenance tasks:
- Truncates the transaction log.The transaction log records almost every change that takes place within the database. The management server removes unused data from the transaction log.
- Rebuilds the index.The management server defragments the database table indexes to improve the time it takes to sort and search the database.
By default, the management server performs these tasks on a schedule. You can perform the maintenance tasks immediately, or adjust the schedule so that it occurs when users are not on their computers.
To run database maintenance tasks on demand
- In the console, click , and then click .
- Under Servers, click the icon that represents the database.
- Under Tasks, select either of the following options:
- Click .
- After the task completes, click .
To schedule database maintenance tasks to run automatically
- In the console, click , and then click .
- Under Servers, click the icon that represents the database.
- Under Tasks, click .
- On the General tab, check either or both of the following options, then click  and specify the schedule for each task.
![[5 Mins Docker] Deploy FreshRSS Using Docker Run Command and Deploy To Fly.io](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_u2WQB-3oKJ3Lo5V2zlF--VaqWT-3q8MYXwoWvG4V8T8RGr6EaU_0EBx5vwFNBw1XdBVd2DdWSYB8ZYgXEudc3Cz4qOifxvZXGulUee6b8I0A)
No comments:
Post a Comment