After you upgrade the AppManager agent, existing jobs on the managed client computer are not automatically upgraded to use the latest script functionality. Use this Knowledge Script to upgrade all child jobs for one or more parent jobs.
NOTE:The functionality provided in the latest version of the script may not be supported by older agents with older managed objects. For this reason, you should upgrade your managed clients to the latest version of the AppManager agent before you upgrade jobs running on those agents.
Upgrading jobs to use the latest script version allows the jobs to take advantage of the latest script logic while maintaining existing parameter values for the job, along with the associated graph data and event information. If the latest version of a script has been modified to have new parameters, for example, to create different events or datastreams, the default values in the latest script for the new parameters are used.
This script upgrades all child jobs for one or more parent jobs. You can select the parent jobs you want to upgrade based on the following:
Knowledge Script — Select this option to upgrade all ad hoc jobs started by the specified script. This option upgrades ad hoc jobs started by a particular script and ad hoc jobs started by a Knowledge Script Group member. This option does not upgrade policy-based jobs.
Knowledge Script category — Select this option to upgrade all ad hoc jobs started by the specified script category. This option does not upgrade policy-based jobs.
Parent job identifier — Select this option to upgrade all ad hoc child jobs that belong to the specified Parent Job ID. This option does not upgrade policy-based jobs.
Monitoring policy — All policy-based jobs started by the specified Knowledge Script Group are upgraded. If you are using a Knowledge Script Group in one or more monitoring policies, all affected monitoring policies are updated. This option does not upgrade ad hoc jobs started by a Knowledge Script Group.
NOTE:This script does not upgrade AppManager report Knowledge Script jobs, nor does it return a list of report Knowledge Scripts in an instant check query.
To upgrade ad-hoc jobs on a version 7.0 UNIX agent, you must first upgrade the UNIX agent to the latest version. If you attempt to upgrade jobs on a version 2 UNIX agent, this script runs successfully, but the child jobs on version 2 UNIX agents are not upgraded.
This script upgrades the following:
AppManager jobs on a version 7.0 (or later) Windows agent
Version 7.0 (or later) AppManager jobs on a version 8.0 (or later) UNIX agent
Before you attempt to upgrade jobs using this script, you should identify jobs that have not yet been upgraded by performing an instant check query.
The instant check query provides a list of jobs to upgrade and jobs that have already been upgraded. You should use the instant check query to identify the jobs to upgrade and to develop a strategy for upgrading existing jobs.
The instant check query identifies jobs by AppManager version and displays both Windows and UNIX jobs. Use the name of the script category to identify Windows or UNIX jobs.
The query results for each job also include the version of the AppManager agent.
To perform an instant check query, use the Instant Check Query parameters on the Values tab. Use the Select query parameter to select the type of query you want. Then click Browse (...) in the Display query parameter to see the results of the selected query. To save the query results to a file, click Finish. You can run the following query types:
|
Query Type |
Description |
|---|---|
|
Out-of-date parent jobs |
This query returns a list of parent IDs that you should upgrade. Note that some parent jobs may contain two different versions of a script. If that is the case, and either one of them is not the latest, the KS Build ID field reads “multiple build IDs.” |
|
Up-to-date parent jobs |
This query returns a list of parent job IDs that are presently using the latest script in the repository and cannot be updated. |
|
Old parent jobs with no upgrade |
This query returns a list of jobs with an old script but for which there is no newer version in the repository. If this query returns any parent job IDs, it means the script has either been discontinued in later versions of AppManager, or it is a script you created or customized under a new name and for which you have yet to create a new version in the repository. When this query returns no values, then there are no parent jobs using out-of-date scripts. No further upgrading is required. |
|
Child jobs on v6.x agents |
This query returns a list of child jobs running on AppManager version 6.x agents. |
|
Agent build IDs |
This query returns a list of the agent build number on each computer. You can use this list to identify agents that you may want to upgrade. |
|
Monitoring-policy jobs |
This query returns a list of the jobs that are currently part of a monitoring policy. The jobs are listed according to the view or server group associated with the monitoring policy and then sorted by script group. Note that the Knowledge Script Group names (KSGName field) all have the prefix “KSG_.” If you want to upgrade a Knowledge Script Group, add this prefix to the group name. You cannot upgrade any UNIX jobs that are policy-based. After you upgrade the backlevel UNIX agent to the latest version, remove the existing backlevel policy-based jobs and recreate them. |
After you run an instant check query to identify the jobs you want to upgrade, you can generate a report that previews the jobs that would be upgraded. For more information, see Viewing Job Upgrade Reports.
If you have written a custom script, you do not need to upgrade existing jobs created by that script unless you have made changes to the script. In most cases, existing custom scripts can be run successfully on AppManager 7.0 (and later) agents.
Before you can upgrade jobs created by a copy of a script, you must update the copy of the script in the AppManager repository:
To update a copy of a script:
On the repository computer, use Windows Explorer to open the \netiq\appmanager\qdb\kp folder and click the folder that contains the new version of the original script upon which the copy is based.
Copy the script and rename it to use the same name as the script copy.
Check the updated script copy into the repository. You are now ready to upgrade existing jobs.
To verify that a job has been upgraded, view the job properties.
To verify a job upgrade:
In the List pane in the Operator Console, double-click a child job on the Jobs tab.
In the Properties dialog box, click View KS.
In the Script for Job dialog box, verify the AppManID is Select 7.0.
In some rare cases, running the AMAdmin_UpgradeJobs script replaces the existing password for your environment with the default password specified in the original script properties. After these jobs are upgraded, they no longer run because the password is incorrect. This problem occurs for the following scripts:
NTADMIN_AddUser
NTADMIN_ChangePassword
SQL_Bcp
If you upgrade any of these script jobs, update the job properties to restore the correct password information.
Run this script on a managed Windows computer with the AppManager 7.0 (or later) agent where the “Log On As” account for the AppManager agent Client Resource Monitor (NetIQmc) service is a valid domain user account that belongs to the AppManager Administrator role.
To verify that the Windows user account that the AppManager agent uses belongs to the AppManager Administrator role, in AppManager Security Manager expand AppManager Roles in the Navigation pane or the TreeView and click Administrator to see a list of valid AppManager administrators.
The default interval for this script is Run once.
Set the following parameters as needed:
|
Parameter |
How to Set It |
|---|---|
|
Instant Check Query |
|
|
Select query |
The instant-check query provides a list of jobs to upgrade and jobs that have already been upgraded. You should use the instant check query to identify the jobs to upgrade and to develop a strategy for upgrading existing jobs. For more information, see Performing an Instant Check Query before Running this Knowledge Script. |
|
Display query |
Click Browse [...] to see a list of Knowledge Script jobs found by the instant check query. |
|
Job Options |
After you use Instant check query to identify the jobs you want to upgrade, use these parameters to generate a preview of the changes to the script that will be applied to existing jobs and to actually apply those changes and upgrade the jobs. |
|
Upgrade jobs, or generate report? |
Select one of the following options:
The default is Generate report. For more information, see Viewing Job Upgrade Reports. |
|
Force, or restricted upgrade? |
Select an option for upgrading parent jobs:
Note that in some cases, the functionality provided in the latest version of the script logic may not be supported by older agents with older managed objects. The default is Restricted. |
|
Override job build version? |
Set to y to upgrade jobs regardless of the job build version (force job upgrade). This option is required to upgrade jobs that have a build version that is the same or earlier than the script build version. The job upgrade process uses all numbers of the build version to compare versions. For example, if the build version for an AppManager job is 7.0.2 and the build version of the newer script is 7.0.112, the job upgrade mechanism would not upgrade the job unless you enabled this option. The default is y. Tip To view the build version:
|
|
Job selection criterion |
Specify how to select the jobs you want to upgrade. You can select jobs by:
Warning If you are using a Knowledge Script Group in more than one monitoring policy, all affected monitoring policies are updated. |
|
Job selection specification |
Select the jobs you want to upgrade from a list, based on a job selection criterion. Click Browse (...) to see the list. If your job selection criterion is:
Warning If you are using a Knowledge Script Group in one or more monitoring policies, all monitoring policies are updated. |
Each time you run this script, job upgrade reports are created under:
\netiq\temp\netiq_debug\computer\jobupgrade
where computer is the name of the computer where you ran the report. The following reports are always generated regardless of whether you configure this job to generate a report or upgrade jobs:
Upgradejob_id.txt, where id is the UpgradeJobs ID, provides information about which jobs are upgraded.
Upgradejob_id.rpt, where id is the UpgradeJobs job ID, provides detailed information about each job.
HINT:Upgradejob_id.log, where id is the UpgradeJobs ID, lists the Job IDs that are upgraded and references the corresponding .rpt file and .log files for more information.
If the child of a specified parent job is running on an agent that has not been upgraded to the latest version, and you specified the Restricted upgrade option, the UpgradeJob_<id>.txt file displays information similar to the following:
Connected to SQL Server : RACKR14 repository QDB. Time stamp: 03/03/07 14:20:47 [Child Job] [Parent Job] [Build ID] [Computer\KS] 2 4.3 agent(s) found. 2 5.0 agent(s) found. 1 5.0.1 agent(s) found. Parent job 436 is skipped because under restricted mode, there cannot be any non-7.0 agents. Upgrade is finished. Please check upgradejob_1343.rpt and upgradejob_1343.log located in D:\NetIQ\Temp\NetIQ_Debug\RACKR14\jobupgrade. Time stamp: 03/03/07 14:20:47
If the child of a specified parent job can be upgraded with parameter changes, the UpgradeJob_<id>.rpt file displays information similar to the following:
Connected to SQL Server : RACKR14 repository QDB. Time stamp: 03/03/07 15:14:30 *************************************************************** Parent job 54 can be upgraded under force mode. 2 4.3 agent(s) found. 2 5.0 agent(s) found. 2 5.0.1 agent(s) found. 1) Child job ID = 55 Parent job ID = 54 KS name = NT_CpuLoaded Machine name = RACKN08 Version = 4.6 Job 55 can be upgraded. The following parameters in the existing job are not found in the new version of the KS: 1) Event? (y/n) Existing value is y. 2) Collect Data? (y/n) Existing value is y. 3) Overall Load? (y/n) Existing value is y. 4) Cpu Threshold > Existing value is 0 5) Cpu Queue Length > Existing value is 0 6) Event Severity Existing value is 5 7) Severity for an unexpected KS error Existing value is 35 The following parameters in the new version of the KS are not found in the existing job: 1) Event Notification Default value is NULL. 2) Create event if total system CPU is high? Default value is y. 3) Severity - Total system CPU Default value is 5 4) Create event if any individual CPU is high? Default value is n. 5) Severity - Individual CPU Default value is 15 6) Severity - Job failure Default value is 35 7) Data Collection Default value is NULL. 8) Collect total system utilization data? Default value is y. 9) Collect individual processor utilization data? Default value is n. 10) Collect processor queue data? Default value is y. 11) Monitoring Default value is NULL. 12) Threshold - Total system CPU Default value is 0 13) Threshold - Individual CPU Default value is 98 14) Threshold - Processor queue length Default value is 0 Check for OldParameter tag 1) Create event if total system CPU is high? Default value is y OldParameter tag value = ?DO_EVENT="y" ((AND)) DO_OVERALL="y":"y":"n". New StringValue = "y" 2) Severity - Total system CPU Default value is 5 OldParameter tag value = ?DO_EVENT="y" ((AND)) DO_OVERALL="y":Severity:$default$. New IntValue = "5" 3) Create event if any individual CPU is high? Default value is n OldParameter tag value = ?DO_EVENT="y" ((AND)) DO_OVERALL="n":"y":"n". New StringValue = "n" 4) Severity - Individual CPU Default value is 15 OldParameter tag value = ?DO_EVENT="y" ((AND)) DO_OVERALL="n":Severity:$default$. No matching value, will keep original. 5) Severity - Job failure Default value is 35 OldParameter tag value = PRM_KSERR. New IntValue = "35" 6) Collect total system utilization data? Default value is y OldParameter tag value = ?DO_DATA="y" ((AND)) DO_OVERALL="y":"y":"n". New StringValue = "y" 7) Collect individual processor utilization data? Default value is n OldParameter tag value = ?DO_DATA="y" ((AND)) DO_OVERALL="n":"y":"n". New StringValue = "n" 8) Collect processor queue data? Default value is y OldParameter tag value = DO_DATA. New StringValue = "y" 9) Threshold - Total system CPU Default value is 0 OldParameter tag value = ?DO_OVERALL="y":TH_UTIL:$default$. New IntValue = "0" 10) Threshold - Individual CPU Default value is 98 OldParameter tag value = ?DO_OVERALL="n":TH_UTIL:$default$. No matching value, will keep original. 11) Threshold - Processor queue length Default value is 0 OldParameter tag value = TH_QLEN. New IntValue = "0"
If the child of a specified parent job cannot be upgraded because the UNIX agent on which it is running is version 6.5, the entry looks like this:
Parent job 1536 cannot be upgraded under restricted mode. 29 6.5 agents are found. Please upgrade these agents and restart the upgrade process.
In this case, upgrade the agent or use the Force upgrade parameter to upgrade the jobs on the older agent.