USM Anywhere provides automatic repeatable actions that are collectively called jobs, which you can run in your environment. The jobs are initiated on a schedule stored in your provisioned USM Anywhere cloud instance. All jobs are directly assigned to a source, and acted upon by the assigned sensor or cloud connector. The cloud instance doesn’t perform job activities; it only schedules them and collects the output of the job for processing. Go to Settings > Scheduler to open the Scheduler page and display all jobs by default. The scheduler specifies when a job is sent to the assigned sensor or cloud connector for processing based on the job schedule. Preloaded log collection jobs can’t be edited. These jobs don’t have the icon associated with it, but they can be enabled () or disabled (). These jobs have settings that are created and managed by USM Anywhere.
Log Collection jobs run endpoint-specific API calls against target systems. Some log collection jobs are source-type specific because they query endpoints specific to the sensor or cloud connector type in use. For example, the Scan Azure Audit Sharepoint Events job is only active for Azure Sensors. Many of these jobs are associated with an BlueApp selection. Go to Data Source > BlueApps to view the available BlueApps. See The USM Anywhere BlueApps Guide for more information. Assigning multiple sensors to perform API calls to the same endpoint can cause unnecessary duplication of data and effort, therefore must be avoided.
Note: You can enable BlueApps on the BlueApp page, but it does not automatically enable the job to run. See USM Anywhere Scheduler for more information.
Asset Scans are used for asset discovery. This app has multiple actions and scan profiles. See Scheduling Asset Scans from Assets and Scheduling Asset Scans from the Job Scheduler Page for more information. The Asset Scans section also include asset discoveries performed through API calls. Some examples of this include the discover S3 buckets job for AWS Sensors, the discover virtual machines job for VMware Sensors, and the scan Azure IIS log locations job for Azure Sensors. Asset Group Scans are performed for vulnerability scanning. This app also has multiple scan profiles. See Scheduling Asset Group Scans from Asset Groups and Scheduling Asset Groups Scans from the Job Scheduler Page for more information. Asset Scans and Asset Group Scans are user-created jobs. No such jobs come pre-loaded into a system image. All of these jobs can be edited, enabled and disabled.

​
Performance Issues Associated with Scheduled Jobs

Log Collection jobs are initially preset at installation and can’t be modified by a user, regardless of the role. They can only be enabled or disabled. Additional Log Collection jobs can be user defined and their action and time frames are set by a user at that time. These settings can be edited. Keep in mind the following points when scheduling your jobs because they have a direct impact on the performance of a sensor and USM Anywhere cloud instance:
  • When specifying a Classless Inter-Domain Routing (CIDR) block for jobs that require it, limit it to a /24 or smaller network segment. Avoid using a /16 CIDR block size. The smaller the CIDR block number used, the larger the network IP address range it will process. These are some sample IP ranges:
    • /16 notation will access 64,000 IP addresses
    • /24 notation will access 256 IP addresses
    • /28 notation will access 16 IP addresses
  • If multiple user-defined scheduled jobs are required for the environment, spread them over a 24-hour period, and avoid having more than one scan job type running at any given time. This holds true for all jobs regardless of the sensor or sensors in use. Although the scan jobs may be readily run on any given sensor, all sensor data is forwarded to the USM Anywhere cloud instance and can, cumulatively, cause performance issues.
  • Scheduling an Asset Scan or Asset Group Scan job to run more than once a day is counterproductive and directly affects system performance. This is also true for AD Scanner jobs. The best practice is to run them, at most, no more than once a day, or, every other day, and overlap them on alternate days. Additionally, initiate the job at off-hours where sensor and USM Anywhere cloud instance activity is lowest.
  • Vulnerability scans should be run weekly or at even larger intervals. This job checks for software vulnerabilities on installed servers. Unless continuous software updates are being performed in the environment, scanning no more than once a week is sufficient. This job can also be initiated manually if immediate results are required.
  • Try to space jobs at least one hour apart on any given day. At least two hours is recommended. Do not “stack” more than two to three jobs for any start time.
  • Ensure job start time intervals are larger than the time it takes for the job to complete. If not, this will cause the job to continuously run and put a constant load on the sensor.
  • If multiple AWS Sensors are in the same account subscription, only one AWS log collection job is required as any given AWS Sensor has visibility to all AWS regions associated with the account. AWS log collection jobs that explicitly span all regions and streams are noted in the description field of the job. Although not noted there, all AWS EC2 Scan jobs will traverse all regions as well. The processing of multiple regions by such a job can’t be limited in the job settings.