When deciding which components to upgrade, it is important to consider the features available with version 9.2 and the requirements for using those features.
AppManager 9.2 introduces the concept of base and derived Knowledge Scripts. A base Knowledge Script is checked in to the AppManager repository (QDB) and holds all of the Knowledge Script settings (the schedule, parameters, and Advanced tab) and the script logic. A derived Knowledge Script is a copy of a base Knowledge Script (a direct copy or a member of a Knowledge Script Group) and shares the logic with the base Knowledge Script but has its own settings. For example, a base Knowledge Script might have a default threshold of 10 for a certain parameter while the derived Knowledge Script has a default threshold of 20. The two Knowledge Scripts share the script logic, but the settings are different.
Because a base Knowledge Script and a derived Knowledge Script share logic, when the logic for a base Knowledge Script changes, AppManager can automatically update the logic for the derived Knowledge Script without updating the settings.
With AppManager 9.2, when you install a new version of a module, AppManager can automatically update the logic of the derived Knowledge Scripts without changing any defaults or settings. For new QDB installations, this is the default behavior. For upgrades, you must enable the automatic propagation feature. To enable the feature, in the Knowledge Scripts options in the Control Center console, select Automatically update Derived KS properties for checked in Base KSs.
The automatic propagation feature includes monitoring policy jobs but not ad-hoc jobs. For ad-hoc jobs, you must manually propagate changes from the base Knowledge Script to the derived Knowledge Script. With both automatic and manual propagation, the target Knowledge Script or job retains its settings (such as thresholds and schedule). If a base Knowledge Script includes new values or removed values, AppManager also propagates those changes to the derived Knowledge Scripts.
If you do not enable the automatic propagation option, when you log in to the AppManager consoles and base Knowledge Scripts have been updated, AppManager informs you that Knowledge Scripts are pending propagation to running jobs and provides the option to start the Knowledge Script Propagation Wizard to select which Knowledge Scripts to propagate. The wizard includes options to propagate to both derived Knowledge Scripts and to ad-hoc jobs. In Control Center, when you select a Knowledge Script on the Propagation to Ad Hoc Jobs tab, you can see the QDBs where the job is running and can choose to propagate to ad-hoc jobs in specific QDBs.
For more information about automatic and manual propagation, see the Control Center User Guide for AppManager.
To allow you to more easily diagnose issues with remote deployment, AppManager 9.2 includes the ability to view deployment rule processing details in the Control Center console.
After you create and enable a deployment rule, AppManager evaluates the rule for processing and displays the status in the Control Center console. To view the evaluation history, click Rule History in the Deployment view of the Navigation pane.
The Rule Processing History portion of the pane indicates whether processing was successful. If AppManager was not able to create a deployment task for the rule, it provides details about the error in the Task Comment column.
If the evaluation status changes the next time that AppManager evaluates the rule, AppManager updates the rule history. AppManager does not update the rule history if the evaluation status does not change.
Version 9.2 incorporates data scalability improvements from version 9.1 into the user interface for improved console performance. In test environments, improved response times were observed in large environments.
To eliminate the requirement for a Microsoft SQL Server license, for small environments with all components on one computer, AppManager 9.2 supports hosting the AppManager repository (QDB) and Control Center repository (CCDB) on Microsoft SQL Server Express.
AppManager 9.2 reduces the amount of disk space that the QDB requires by implementing a streamlined method of collecting and storing data.
Previously, AppManager stored collected data for use in short-term charts and graphs in the Data table for eight days, and stored data for long-term reporting in the ArchiveData table indefinitely (by default). If a Knowledge Script generated data details in addition to data points, AppManager automatically stored the details in the Data table.
Now, AppManager stores all of the data that it collects on a given day in Data_yyyymmdd tables for immediate display in real-time charts and graphs for 30 days (by default), and each day removes tables that are more than 30 days old. A new option in the Control Center console, Remove old data after, allows you to change the default retention period. For more information, see Global Preferences Options in the Control Center User Guide for AppManager. For long-term reporting needs, NetIQ Corporation recommends using NetIQ Analysis Center.
In addition, AppManager no longer automatically collects data details with data points. The Collect data details with data point repository preference in the Operator Console allows you to select whether to collect data details by default. If you do collect data details, AppManager stores them in the Data_yyyymmdd tables.
NOTE:When you upgrade, the upgrade does not change the current setting for Collect data details with data point. If you previously collected details and no longer want to collect them, you must manually change the setting.
Previously, it was necessary to periodically archive and aggregate data in the QDB to prevent the ArchiveData table from becoming too large. With this streamlined method of collecting and storing data, archiving is no longer necessary.
AppManager 9.2 includes a command line tool, MigrateQ.exe, that automates migrating existing Windows and UNIX agents to a new QDB and allows you to migrate multiple agents simultaneously, if needed. You can migrate version 7.0.4 and later agents to new QDBs. For more information about using the tool, see Migrating an Agent to a New QDB.