Network Management
NCM Config Change Report has different information if done via a job vs. the web
This addresses a possible reason why one would see changes over a greater time period in the Web Based Config Change Report Vs the results produced via a Job to run a Config Change Report
First published date
Last published date
Overview
Product section
Cause
Resolution
Example of an issue:
From Configuration Management or from a Nodes Detail page, configs tab, one selects to see a config change report for the last 6 months:
The report generates and displays results dating back a full 6 months.
When running the same criteria for the config change report via an NCM job:
The report only shows results dating able 1 month.
The reason for the difference may be because the source of the pool that NCM gets results from.
When we run the report via the web, NCM will utilize the configs stored in the NCM_ConfigArchive table, and do a real-time comparison based on configs there. As long as the node has configs in this table dating back that far, the report should show the diff results. When the Config Change Report is run via a job, NCM will utilize the information in the NCM_CacheDiffResults table. This table is populated at the time the configs are downloaded and the comparison criteria is applied.
The results of the Report is dependent on how long the data is retained in the database, and if the two tables have different retention settings. Then results can differ.
There are NCM jobs one can, and should, run on a routine basis to make sure the tables do not get so large it impact performance.
Default Purge Configs -- This job will trim the Config Archive table of old configs from the database.
Deafult Database and Archive Maintenance - This job can be set up to do several database cleanups as well as the Config Archive folder stored on the NCM Servers (or share that may be set up).
The Default Database and Archive Maintenance job is what is used to trim the NCM_CacheDiffResults table in the database.
The default is 6 months, but is routinely set to a lower value since this table can grow large quickly based on Number of Nodes, how many config types there are, how often config changes are made, and how often configs are downloaded.
Other contributing factors will include the NCM setting for how many lines are stored for before and after the change.
The key take away on this is to check the value in the job if it is running on the retention set for Purge config cache data older than line in the Default Database and Archive Maintenance job