NetIQ® AppManager®

Administrator Guide
December 2018
Legal Notice
For information about NetIQ legal notices, disclaimers, warranties, export and other use restrictions, U.S. Government
restricted rights, patent policy, and FIPS compliance, see https://www.netiq.com/company/legal/.

Copyright (C) 2018 NetIQ Corporation. All rights reserved.

Contents

About this Book and the Library 9

About NetIQ Corporation 11

1 Introduction to AppManager Site Administration 13

1.1 Understanding AppManager Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 Understanding the AppManager Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.3 The AppManager Management Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4 Understanding Site Communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.5 Understanding the Site Administrator’s Role . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.6 Developing a Management Site and Site Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.6.1 Managing a Small, Internal Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.6.2 Managing a Mid-size Network with Local and Remote Facilities . . . . . . . . . . . . . . . . . . . . . 23
1.6.3 Monitoring Large Environments with Multiple Management Servers. . . . . . . . . . . . . . . . . . 25
1.6.4 Monitoring a Widely Distributed Enterprise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.6.5 Defining a Management Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.6.6 Planning and Staging a Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.6.7 Defining Site-Level Policies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.7 Managing Multiple Sites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2 Site Communication and Security 31

2.1 AppManager Communication Protocols. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2 Understanding Communication Security Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.3 Understanding FIPS Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3.1 Planning for AppManager FIPS Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.2 FIPS-Compliant and Non-FIPS-Compliant AppManager Components . . . . . . . . . . . . . . . . 34
2.3.3 Management Servers and the FIPS-Only Compliance Flag . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4 Managing Secure Communication for Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.4.1 Changing the Security Level for Management Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4.2 Changing the Security Level for Agents. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.4.3 Generating a Repository Key. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.4.4 Extracting and Sharing Key Information from the Repository . . . . . . . . . . . . . . . . . . . . . . . 37
2.4.5 Extracting the Key File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4.6 Updating the Key File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
2.5 Setting up Primary and Backup Management Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.5.1 Designating the Local Management Server as the Primary Management Server . . . . . . . . 41
2.5.2 Configuring a Primary and Secondary Management Server for Agent Computers . . . . . . . 42
2.5.3 How Failover Works. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.5.4 Distributing Processing Load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.5.5 Verifying the Management Server Assigned to an Agent Computer . . . . . . . . . . . . . . . . . . 44
2.5.6 Changing a Management Server Assigned to an Agent Computer . . . . . . . . . . . . . . . . . . . 44
2.5.7 Adding a New Management Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3 Managing Security for Control Center 45

3.1 Understanding User Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1.1 Using Windows Authentication Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1.2 Using Mixed Mode Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1.3 Managing Users with Windows Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.2 Managing Control Center Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Contents 3
 3.2.1 Configuring Control Center Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.2 Understanding Default User Groups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.2.3 Understanding Types of Permissions for Control Center. . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.2.4 Understanding Permission Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.2.5 Adding a Control Center User . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.2.6 Creating, Copying, Modifying, or Removing a User Group . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.2.7 Creating, Copying, Modifying, or Removing a Permission Set . . . . . . . . . . . . . . . . . . . . . . 53
3.2.8 Setting Global Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.2.9 Granting and Removing Access to Management Groups . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.2.10 Understanding the Interaction Between Control Center Console and Operator
Console Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

4 Managing Jobs 57
4.1 Installing in a Lab Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.2 Deploying to a Pilot Group . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.3 Implementing Core Monitoring Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.3.1 Collecting Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.3.2 Setting and Adjusting Event Thresholds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.3.3 Establishing a Manageable Level of Event Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.3.4 Developing a Data Collection Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.4 Expanding the Scope of Your Deployment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.4.1 Running Additional Knowledge Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.5 Strategies for Managing Systems and Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.5.1 Managing Systems and Applications with the Control Center Console . . . . . . . . . . . . . . . . 64
4.6 Managing Existing Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.6.1 Changing Job Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
4.6.2 Checking Job Status with the JobInfo Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.7 Suspending AppManager Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.7.1 Suspending Remote Monitoring Knowledge Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.7.2 Resource Dependencies and Job Schedules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.8 Reviewing and Refining the Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5 Managing Events 71
5.1 Deciding When to Raise Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.2 Understanding Events and Event Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2.1 Event Collapsing and Duplicate Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.3 Setting Preferences for Event Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.3.1 Acknowledging and Closing Events. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.4 Understanding Event Archiving . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.5 Using Advanced Event-handling Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.5.1 Configuring Event Collapsing for Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.5.2 Adjusting Consecutive Intervals. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.5.3 Raising an Event When a Condition No Longer Exists . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.6 Notifying Individuals of Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.6.1 Sending an Email Event Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.6.2 Sending a Page as an Event Notification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
5.6.3 Sending Event Information to Another Console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.7 Triggering Corrective Actions for Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6 Managing Data 85
6.1 Deciding When to Collect Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.2 Understanding Data Collection for Charts, Graphs, and Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.3 Using Advanced Data-handling Properties for Jobs. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.3.1 Collecting Detail Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

4 Contents
 6.3.2 Modifying the Schedule for Collecting Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.3.3 Collecting Data in Response to an Event . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

7 Managing a QDB 89
7.1 Understanding the AppManager Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
7.1.1 Understanding the Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.1.2 Stored Procedures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.1.3 SQL Server Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
7.2 Configuring the Task Scheduler Service and SQL Server Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
7.3 Managing Data Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
7.4 Managing Event Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.5 Managing Audit Trails. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
7.6 Checking SQL Server Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
7.7 Expanding the Size of a Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
7.8 Checking the Integrity of the Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.9 Backing Up and Restoring the QDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7.10 Removing Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7.11 Moving the QDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
7.12 Using the Repository Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

8 Managing Control Center 103

8.1 Understanding the Control Center Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
8.2 Configuring the Task Scheduler Service and SQL Server Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
8.3 Backing Up the Control Center Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
8.4 Moving the Deployment Service to a New Computer. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
8.5 Moving the Deployment Web Service to a New Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
8.5.1 Updating the Control Center Preferences to Specify the New Deployment Web
Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
8.5.2 Reconfiguring Any Deployment Services That Use the Deployment Web Service as
a Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
8.5.3 Updating Your AppManager Agents to Communicate with the New Deployment Web
Service. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
8.5.4 Uninstall the Existing Deployment Web Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
8.6 Moving the Command Queue Service to a New Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
8.7 Changing the Log Path for the Command Queue Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
8.8 Changing the Log Path for the Deployment Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
8.9 Changing Configuration Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

9 Advanced Configuration for Management Servers 111

9.1 Rules for Management Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
9.1.1 Using Anti-virus Software. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
9.1.2 Checking Management Server Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
9.2 Changing the Polling Interval for Agent Computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
9.2.1 Changing the Interval for Windows Computers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
9.2.2 Changing the Interval for UNIX and Linux Computers. . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
9.3 Changing the Listening Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
9.4 Changing the Level of Detail in Trace Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
9.5 Moving the Management Server to a New Computer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115

10 Advanced Configuration Options for Windows Agents 117

10.1 Understanding the AppManager Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
10.2 Understanding Agent Autonomy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118

Contents 5
 10.2.1 Disabling Autonomous Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
10.2.2 Controlling the Interval for Checking Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
10.3 Using a Windows User Account for Agent Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
10.4 Account Permissions Used to Run AppManager Agent services . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
10.5 Restarting Agent Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
10.5.1 Performing a Cold Startup of the AppManager Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
10.5.2 Setting the Agent Startup Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
10.6 Agent Self Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
10.7 Configuring Agents to Use a Hostname or IP Address. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
10.8 Configuring the Size of a Local Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
10.9 Adjusting the Flow of Network Traffic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
10.10 Scheduling the Transfer of Events and Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
10.11 Configuring Designated Management Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
10.11.1 Changing Agent Failover Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
10.11.2 Removing a Designated Management Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
10.12 Manually Controlling Network Communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
10.13 Controlling Access to an Agent’s Local Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

11 Developing Scripts to Perform AppManager Tasks 129

11.1 Understanding Command-line Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
11.2 About the Sample Command-line Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
11.3 Running AppManager Command-line Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
11.4 Creating a Default Logon Profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
11.5 Creating Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
11.6 Starting, Stopping, Closing, and Deleting Jobs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
11.7 Acknowledging, Closing, and Deleting Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
11.8 Exporting Data Streams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
11.9 Scheduling Scripts to Run . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
11.10 Getting Help for Sample Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136

12 Troubleshooting and Diagnostic Tools 137

12.1 Understanding What AppManager Provides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
12.2 Using the Troubleshooter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
12.2.1 Starting Troubleshooter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
12.2.2 Generating Reports from within Troubleshooter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
12.2.3 Selecting Specific Troubleshooter Reports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
12.2.4 Clearing the Diagnostic Report’s Information Pane . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
12.2.5 Exporting a Diagnostic Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
12.3 Using the Command-line Program NetIQctrl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
12.3.1 Starting NetIQctrl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
12.3.2 Available NetIQctrl Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
12.4 Using the NetIQ Diagnostics Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
12.4.1 Starting the NetIQ Diagnostics Utility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
12.4.2 Viewing NetIQ Diagnostics Output. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
12.5 Enabling Tracing and Viewing Log Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
12.6 Using the Log Analysis Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175

A Additional Site Administration Utilities 177

A.1 Key File Utility for Windows Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
A.2 Key File Utility for UNIX Agents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
A.3 MAPI Mail Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
A.4 SMTP Mail Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183

6 Contents
 A.5 SNMP Trap Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
A.6 Synchronization Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
A.7 Time Conversion Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185

B Registry Keys 187

B.1 Modifying the Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
B.2 Basic NetIQ Registry Folder. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
B.3 Main AppManager Keys and Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
B.4 AgtShared Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
B.5 AMDevCon Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
B.6 NetIQccm Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
B.6.1 Admin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
B.6.2 Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
B.6.3 Tracing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
B.7 NetIQmc Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
B.7.1 Registry Keys in the NetIQmc Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
B.7.2 Admin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
B.7.3 Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
B.7.4 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
B.7.5 Tracing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
B.8 NetIQms Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
B.8.1 Registry Keys in the NetIQms Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
B.8.2 Admin. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
B.8.3 Config . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
B.8.4 RP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
B.8.5 Tracing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
B.9 QDB Folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
B.10 Repository Browser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
B.11 Security Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
B.12 Other Folders . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207

Contents 7
8
About this Book and the Library

The NetIQ AppManager Suite (AppManager) is a comprehensive solution for managing, diagnosing,
and analyzing performance, availability, and server health for a broad spectrum of operating
environments, applications, and server hardware.

AppManager provides system and application administrators with a central, easy-to-use console to
view critical resources across the enterprise. With AppManager, administrative staff can monitor
computer and application resources, check for potential problems, initiate and automate responsive
actions, automate routine tasks, and gather performance data for real-time and historical reporting
and analysis.

Intended Audience
This guide is intended for senior-level system and network administrators who are responsible for
managing one or more AppManager sites. Managing an AppManager site involves tasks such as
configuring and maintaining site communication, setting up and maintaining security roles and user
rights, establishing event and data handling policies, and maintaining and managing the repository
database and data archiving.

This guide assumes that you are already familiar with your operating system, network configuration,
basic database management, and the servers and applications you intend to monitor.

This guide also assumes you have a working knowledge of or access to other documentation for
performing basic system management and AppManager activities. For example, you should be
familiar with AppManager components and terminology and managing user accounts and
permissions for your operating environment.

Other Information in the Library

The library provides the following information resources:

Installation Guide
Provides detailed planning and installation information.

Control Center User Guide

Provides information about managing groups of computers, including running jobs, responding
to events, creating reports, and working with the Control Center console.

Operator Console User Guide

Provides information for system and network administrators working with the AppManager
Operator Console.

Upgrade and Migration Guide

Provides information about upgrading from a previous version of AppManager.

Module management guides

Provide information about installing and monitoring specific applications with AppManager.

About this Book and the Library 9

 NetIQ UNIX Agent documentation
Provides information about installing, upgrading, and configuring the NetIQ UNIX Agent and
UNIX Agent Manager.

10 About this Book and the Library

About NetIQ Corporation

We are a global, enterprise software company, with a focus on the three persistent challenges in your
environment: Change, complexity and risk—and how we can help you control them.

Our Viewpoint
Adapting to change and managing complexity and risk are nothing new
In fact, of all the challenges you face, these are perhaps the most prominent variables that deny
you the control you need to securely measure, monitor, and manage your physical, virtual, and
cloud computing environments.

Enabling critical business services, better and faster

We believe that providing as much control as possible to IT organizations is the only way to
enable timelier and cost effective delivery of services. Persistent pressures like change and
complexity will only continue to increase as organizations continue to change and the
technologies needed to manage them become inherently more complex.

Our Philosophy
Selling intelligent solutions, not just software
In order to provide reliable control, we first make sure we understand the real-world scenarios in
which IT organizations like yours operate — day in and day out. That's the only way we can
develop practical, intelligent IT solutions that successfully yield proven, measurable results. And
that's so much more rewarding than simply selling software.

Driving your success is our passion

We place your success at the heart of how we do business. From product inception to
deployment, we understand that you need IT solutions that work well and integrate seamlessly
with your existing investments; you need ongoing support and training post-deployment; and you
need someone that is truly easy to work with — for a change. Ultimately, when you succeed, we
all succeed.

Our Solutions
 Identity & Access Governance
 Access Management
 Security Management
 Systems & Application Management
 Workload Management
 Service Management

About NetIQ Corporation 11

 Contacting Sales Support
For questions about products, pricing, and capabilities, contact your local partner. If you cannot
contact your partner, contact our Sales Support team.

Worldwide: www.netiq.com/about_netiq/officelocations.asp

United States and Canada: 1-888-323-6768

Email: [email protected]

Web Site: www.netiq.com

Contacting Technical Support

For specific product issues, contact our Technical Support team.

Worldwide: www.netiq.com/support/contactinfo.asp

North and South America: 1-713-418-5555

Europe, Middle East, and Africa: +353 (0) 91-782 677

Email: [email protected]

Web Site: www.netiq.com/support

Contacting Documentation Support

Our goal is to provide documentation that meets your needs. The documentation for this product is
available on the NetIQ website in HTML and PDF formats on a page that does not require you to log
in. If you have suggestions for documentation improvements, click comment on this topic at the
bottom of any page in the HTML versions of the documentation posted at www.netiq.com/
documentation. You can also email [email protected]. We value your input and
look forward to hearing from you.

Contacting the Online User Community

NetIQ Communities, the NetIQ online community, is a collaborative network connecting you to your
peers and NetIQ experts. By providing more immediate information, useful links to helpful resources,
and access to NetIQ experts, NetIQ Communities helps ensure you are mastering the knowledge you
need to realize the full potential of IT investments upon which you rely. For more information, visit
http://community.netiq.com.

12 About NetIQ Corporation

1 Introduction to AppManager Site
1

Administration

This chapter provides an overview of the components that make up an AppManager management
site, the communication between AppManager components, the role of the site administrator, and
examples of ways you can configure the site to suit your organization’s needs.

1.1 Understanding AppManager Components

The AppManager flexible, tiered architecture consists of required and optional components. You can
install components on one computer or on multiple computers.

The following table describes the AppManager components.

Component Description Required/Optional

AppManager SQL Server database that stores management Required

repository (QDB) information, such as jobs, events, data, and Knowledge
Scripts

Management server Windows service called the NetIQ AppManager Required

Management Service (NetIQms) that manages event-
driven communication between AppManager agents
and the QDB

Task Scheduler Windows service that schedules SQL Server jobs for Required
service QDBs and the Control Center repository (CCDB)

Introduction to AppManager Site Administration 13

 Component Description Required/Optional

Agent AppManager software you deploy in your environment Required

that schedules and runs jobs to manage third-party
products and enables communication between
AppManager components

When you run the setup program to install the agent on

Windows computers, the agent consists of the following
components:

 NetIQ AppManager Client Resource Monitor

(NetIQmc) Windows service
 NetIQ AppManager Client Communication
Manager (NetIQccm) Windows service
 Local repository
 AppManager for Microsoft Windows module
When you use Control Center to deploy agents to
remote computers, the AppManager for Microsoft
Windows module is not automatically deployed. You
must also deploy the module to the computers where
you deploy the agent.

These components reside locally on the agent

computer.

For UNIX or Linux computers, the agent is a daemon

and the supporting files and directories that provide
data persistence (equivalent to the local repository) and
access to system statistics (equivalent to modules).
AppManager uses the NetIQ UNIX agent, which can be
used for other NetIQ products. For more information
about how to install the UNIX agent, see the UNIX
agent documentation, which is included in the
AppManager UNIX download package.

Report-enabled Optional supplement to the agent that allows you to Optional

agent create and configure reports on selected computers in
your environment

You discover report-related elements on agent

computers to enable different types of reporting. For
more information about enabling the agent reporting
capability, see the Installation Guide for AppManager,
available on the AppManager Documentation page
(http://www.netiq.com/documentation/appmanager).

Control Center SQL Server database that stores information Control Required
repository (CCDB) Center collects from the QDBs it manages, user
preferences, security settings, and management group
definitions

14 Introduction to AppManager Site Administration

Component Description Required/Optional

Control Center and Control Center components that include: Required

Deployment services
 Command queue service (CQS), a Windows
service that retrieves commands from the CCDB
and sends them to the appropriate QDBs
 Cache Manager, a child process of the command
queue service running on each QDB that runs
Control Center queries
 Deployment Service, which allows you to install
agents and monitoring modules on remote
computers
If the service is across a firewall and you do not
want to open additional ports to allow direct
communication with the CCDB, you can configure
it to use the Deployment Web Service for
communication with the CCDB. During installation,
choose the option that indicates a firewall is active
between the Deployment Service and the CCDB.

 Deployment Web Service, which distributes

deployment packages to the Deployment Service

For Deployment Services that are across a

firewall, the service can also provide a
communication proxy to the CCDB so that you do
not have to open additional ports to allow direct
communication between the Deployment Service
and the CCDB.

NetIQ AppManager Allows NetIQ Aegis to communicate with AppManager Optional

Integration Adapter through its repositories (QDBs and CCDB), and
includes Aegis workflow activities specific to
AppManager

You can install the NetIQ AppManager Integration

Adapter (AppManager adapter) on any computer with
network access to the NetIQ Resource Management
Namespace Provider service and the repository with
which you want NetIQ Aegis to communicate. For more
information about installing the AppManager adapter,
see the NetIQ AppManager Integration Adapter
Installation Guide, available on the Aegis
Documentation page (http://www.netiq.com/
documentation/aegis).

Introduction to AppManager Site Administration 15

 Component Description Required/Optional

Control Center Windows interface that connects to the CCDB and Required
console allows you to run jobs on the systems and applications
you manage across multiple QDBs

The console provides a single user interface for

managing most administrative functions and offers more
powerful monitoring and deployment capabilities than
the Operator Console. You can use the Control Center
console to deploy agents and modules to remote
computers.

The Control Center console also provides access to the

Chart Console, a Windows interface that allows you to
generate and view charts of QDB data.

Operator Console Windows interface that allows you to view and control Optional
the jobs that monitor and manage your computers and
server applications

UNIX Agent Manager Interface that allows you to use the UNIX Agent Optional
console Manager to deploy and manage UNIX agents

Security Manager Windows interface that allows AppManager Optional

Console administrators to control access to views and tasks in
the Operator Console and manages application or
computer-specific security information, such as SNMP
community strings and passwords

Chart Console Interface that allows you to generate and view charts of Optional
QDB data

Developer’s Console Tool for editing Knowledge Scripts and developing Optional
custom Knowledge Scripts

16 Introduction to AppManager Site Administration

1.2 Understanding the AppManager Architecture
AppManager uses a scalable, flexible, tiered architecture that allows components to communicate
efficiently and allows you to distribute process load across multiple components.

The following graphic illustrates the overall AppManager architecture and how components interact,
including both the Operator Console and the Control Center console.

Introduction to AppManager Site Administration 17

 The following graphic illustrates the architecture of the Control Center console.

For information about the options for distributing AppManager components across multiple
computers, see Section 1.6, “Developing a Management Site and Site Policies,” on page 21.

1.3 The AppManager Management Site

In AppManager, a management site always consists of one AppManager repository (QDB), at least
one AppManager management server, the Task Scheduler service, and some number of
AppManager agents on agent computers that report events and data through the management server
to the QDB. A single management site may have multiple management servers to distribute
processing and communication for agent computers, but each management server communicates
with only one QDB. Therefore, the QDB and the management servers that communicate with it define
the management site.

In planning the configuration of your site, decide whether to use a single management server or
multiple management servers. If you install multiple management servers within a given management
site (that is, for a single QDB), you should explicitly designate a primary and secondary management
server for each agent computer to communicate with. Explicitly designating a primary and a
secondary, or backup, management server enables you to distribute processing load, provide failover
support for agent computers, and control which management servers communicate with which
agents based on the constraints of your network, department requirements, or other factors.

Using a single management server might simplify site administration and troubleshooting of your
AppManager environment, but it can overload the management server, inhibiting system
performance.

18 Introduction to AppManager Site Administration

 NOTE: Although you can install multiple management servers in your environment without explicitly
specifying a primary and secondary management server for each agent computer, NetIQ Corporation
does not recommend this practice. Choosing not to designate management servers in the
recommended way can limit the amount of control you have over which management servers
communicate with which agent computers. Always install a single management server and explicitly
designate its agent computers before installing a second management server.

For a review of issues to consider in planning the number of management servers and management
sites, see the Installation Guide for AppManager, available on the AppManager Documentation page
(http://www.netiq.com/documentation/appmanager), and Section 1.6, “Developing a Management
Site and Site Policies,” on page 21.

1.4 Understanding Site Communication

AppManager manages and monitors the availability, performance, and server health of operating
system services, hardware, and applications through jobs. When you run a Knowledge Script on an
agent computer and create a job:

 The Control Center console delivers information about the properties you have set for the
Knowledge Script to the QDB.
 When the management server next checks the QDB, it identifies the new job and collects all of
the information about the job to send it to the appropriate agent computers.

NOTE: In addition to submitting new and changed job information, the management server
periodically polls all of the agent computers it is allowed to communicate with to check the health
of the agents on each agent computer.

 The NetIQ AppManager Client Resource Monitor (NetIQmc) service on the agent computer
receives the job information from the management server, stores the information in a local
repository, then executes the job to begin monitoring.
 When the job runs, the Knowledge Script invokes program objects that collect performance data
or perform tasks by accessing raw system statistics, through APIs, or using other methods.

Introduction to AppManager Site Administration 19

 The following diagram illustrates the basic flow of job information between the Operator Console
or Control Center console and the agent (managed) computer (in this diagram the agent
computer and the managed computer are the same).

 If the job detects an event condition or collects data, the NetIQ AppManager Client
Communication Manager (NetIQccm) service or nqmdaemon daemon sends the event information
or data point to the management server. If the NetIQccm service or nqmdaemon daemon cannot
communicate with the management server, it saves the event information or data point in the
agent computer’s local repository until the management server is available.
 When the management server receives event information or data points from the agent
computer, it forwards this information to the repository server to update the QDB.
 Once the QDB is updated, any new events or data points are sent to Control Center at its next
update interval (for example, in the next 30 seconds for an active view or in five minutes for a
background view).

1.5 Understanding the Site Administrator’s Role

The site administrator, working with an implementation team, senior-level system administrators, and
application experts, is typically responsible for determining site-level policies for managing jobs,
events, and data, and for configuring and maintaining AppManager components.

Ideally, you make most, if not all, of these decisions before installing AppManager in a production
environment, but often these policies and the implications of the decisions you make are not fully
understood until the site is up and running. In most cases, you can make changes and refine policies
after installation but it is always best to perform the planning and pre-installation steps described in
the Installation Guide for AppManager, available on the AppManager Documentation page (http://
www.netiq.com/documentation/appmanager), before you install any AppManager components.

The site administrator should actively participate in the following actions during the planning and pilot
deployment phases:

 Develop a core list of management goals.

20 Introduction to AppManager Site Administration

  Develop a deployment plan that addresses your network and site configuration. For example,
which components you should install together and which you should install separately and
whether your management site requires a single management server or multiple management
servers.
 Develop a security plan to determine the level of security to use, the user authentication mode
you are using for SQL Server, and the number of users and administrators to be given access.
 Verify that pre-installation tasks are complete for the production environment, including a check
of network connections, account requirements, and account permissions. For more information
about performing pre-installation tasks, see the Installation Guide for AppManager, available on
the AppManager Documentation page (http://www.netiq.com/documentation/appmanager).

For large and widely distributed organizations, many of the decisions you need to make are relatively
complex and require a thorough understanding of your own network requirements and constraints of
the AppManager architecture. For these organizations, in particular, NetIQ Corporation recommends
that you review all of this guide and the Installation Guide for AppManager.

After you successfully install all of your AppManager components, you typically perform a variety of
post-installation tasks to properly configure the environment. These tasks include:

 Defining or identifying the SQL Server logins and users who should have access to
AppManager.
 Changing the account information for the agent or the management server.
 Setting event- and data-handling policies and preferences for the site.
 Creating core Knowledge Script groups and monitoring policies for the site.
 Updating application-specific information.

After you install and configure AppManager, you typically monitor the health of AppManager
components, perform periodic database maintenance, optimize communication flow and console
performance, maintain user accounts and security profiles, and troubleshoot problems within the
environment.

For some of the common activities you perform as the site administrator, you use the Operator
Console and Control Center console, but many of the tasks require other tools or programs. For
example, setting up AppManager users might require standard Windows administrative tools, SQL
Server Management Studio, and AppManager Security Manager. You should be familiar with these
administrative tools as well as the basic operation of AppManager.

1.6 Developing a Management Site and Site Policies

As discussed in the Installation Guide for AppManager, available on the AppManager Documentation
page (http://www.netiq.com/documentation/appmanager), a key element successfully deploying
AppManager is understanding the characteristics of your environment and the network you are going
to monitor. Although you typically deploy and refine agents, jobs, and event- and data-handling
policies over time, one of the first issues you must confront is how to configure the core AppManager
components to best suit the current environment and anticipated changes.

To determine whether you need one management site with a single management server, one
management site with multiple management servers, or multiple management sites with multiple
QDBs and multiple management servers, consider several factors:

 The network bandwidth, latency, and topology for the subnets you will be monitoring

Introduction to AppManager Site Administration 21

  The departmental or functional structure of the organization and the expectations and level of
autonomy associated with different groups in the organization
 The granularity of management that will best suit the organization

To help you determine how to configure one or more management sites to suit your environment,
consider the most common deployment scenarios and evaluate how the specific characteristics of
your organization might fit these scenarios. Keep in mind that these scenarios are only a few common
examples of the many possible ways you can deploy and organize your site.

1.6.1 Managing a Small, Internal Network

In smaller organizations, it is common to monitor a networked domain or a simple trusted set of
domains. An organization like this might be primarily interested in monitoring key application and file
and print servers for internal users and a few key business critical services. For example, this
organization might focus on basic monitoring of CPU, memory, and disk space for all servers and
workstations and specific performance statistics, such as response time and system availability, for
important services such as the messaging system and a customer database.

In a small environment like this, with relatively simple monitoring needs for 150 or so servers, a
typical site configuration involves one QDB and one management server, installed together on the
same computer. An environment like this might have a small administrative staff and need to deploy
the core AppManager components on a single computer to simplify maintenance and console
viewing. Also, as the focus is on basic performance and availability, the organization can expect
fewer events and likely only requires a few charts or reports to show status or trends, and therefore
will only collect a few key data streams.

Having the QDB and management server installed together on the same computer has the following
advantages:

 Eliminates network communication problems between the QDB, management server, and
Control Center console
 Eliminates the need for any special account permissions associated with accessing another
computer over the network or through a firewall
 Simplifies maintenance and troubleshooting because components are centrally located
 Reduces the importance of developing carefully considered security-, data-, event-, and job-
handling policies, database management and backup plans, and monitoring strategies

The diagram below illustrates this type of site configuration:

22 Introduction to AppManager Site Administration

 For small organizations or pilot deployments, these benefits can outweigh the disadvantage of
burdening a single computer with the management server’s communication load and the QDB’s
storage and communication requirements.

1.6.2 Managing a Mid-size Network with Local and Remote

Facilities
A small- to mid-size organization might contain from 151 to 600 servers and involve monitoring a local
network and remote facilities. As the number of servers increases, this organization might put strain
on the management server, generate more frequent events, need more sophisticated reports, and
need to collect and save more data, all of which require more database resources and more database
management. In addition, a small- to mid-size organization might have a larger administrative staff
and need multiple Control Center consoles.

For this environment, NetIQ Corporation recommends installing the QDB and management server on
separate computers. In addition, because the organization is monitoring some computers remotely,
you need to evaluate the reliability and bandwidth of the WAN connection and possibly plan for
scheduled communication links between the remote computers and the management server.

Having the QDB and management server installed on different computers offers the following
advantages:

 Eases the workload on the QDB and management server computers by distributing the workload
to two separate computers
 Reduces system requirements for the computers where the components are installed and
provides additional space for database growth
 Provides more flexibility in configuring how and when agent computers communicate with the
management server

Introduction to AppManager Site Administration 23

 This configuration is still relatively straightforward and easy to maintain. The following diagram
illustrates this type of site configuration:

No inherent drawbacks are associated with this configuration for a small or mid-size organization, or
even for larger organizations with basic monitoring needs. However, over time you might place stress
on this environment if you:

 Add a large number of servers.

 Dramatically increase the monitoring you do or the data you collect.
 Add widely distributed facilities to the management site.
 Start to experience network bandwidth, latency, topology, or reliability issues.

If your organization is considering this type of configuration, consider the following potential site
administration improvements:

 More planning and testing to optimize communication channels, particularly for monitoring
remote computers
 Evaluating security and port requirements more carefully, particularly if the management server
is inside a firewall and some number of monitored computers are outside a firewall (which is a
common configuration if you are monitoring more than the organization’s internal network)
 If your organization has a larger administrative staff or more console computers, more planning
for AppManager security roles and profiles to restrict access to some views and activities
 Setting up special domain accounts or trust relationships for certain types of monitoring and to
allow remote installation of the AppManager agent

24 Introduction to AppManager Site Administration

1.6.3 Monitoring Large Environments with Multiple Management
Servers
For organizations that need to monitor more than 600 servers, including remote facilities, it is often
helpful to install additional management servers to distribute the communication workload. Using two
or more management servers in a management site provides the following advantages:

 Reduces the chances of the management server becoming a bottleneck for event and data
handling
 Provides you with a way to balance the communication load between the management servers
to ensure optimum efficiency for your specific network configuration
 Allows you to establish a primary management server and a secondary management server for
each of your agent computers to provide failover support
 Provides better scalability for organizations that need to grow quickly or are expanding their
monitoring requirements

Using more than one management server allows more control and flexibility in managing site
communication but it requires far more planning to implement effectively. For example, you must
decide if a second management server is strictly a backup for a primary management server or if
each management server is responsible for a specific set of agent computers.

You must also decide how many management servers you can reasonably manage within a single
site. Although there is no specific restriction on the number of management servers you can use,
most organizations can handle four management servers before the site becomes too complex to
manage.

Introduction to AppManager Site Administration 25

 The following diagram represents a simple two-management server site configuration:

Each management server has been designated as a primary management server for several agent
computers.

All of the agent computers that send information to the management server ONYX are also configured
to use the management server ENCORE as their secondary, or backup, management server. In this
scenario, the computer ENCORE is a powerful, high-speed computer that can handle the extra load
from the agent computers that the computer ONYX typically manages. If communication with ONYX is
interrupted, its agent computers automatically begin communicating with their secondary
management server, ENCORE.

You could also designate ONYX as a secondary management server for the computers managed by
the computer ENCORE, so that both computers have a secondary management server, or you could
designate a separate management server that does not have any agent computers to be a secondary
management server. In this second scenario, the secondary management server is normally “idle”
and only takes over the communication with agent computers when either of the primary
management servers fails. If you decide to configure a primary management server as a secondary

26 Introduction to AppManager Site Administration

 for another management server, it is good practice to configure this management server so that it can
accommodate its own agents plus the full complement of agents from the management server it is
backing up.

As this example illustrates, installing multiple management servers provides flexibility but can
increase the complexity of site management and requires planning.

1.6.4 Monitoring a Widely Distributed Enterprise

A single management site with one QDB and a small number of management servers is sufficient to
meet the monitoring needs of most organizations. For large-scale, distributed networks, however, a
single site might not be possible, manageable, or desirable. For an enterprise with computer
resources widely distributed across a national or international network, multiple management sites
might be the most practical solution.

Because so many key elements of a monitoring strategy and communication control are defined at a
site level, keeping multiple QDBs synchronized can be difficult. For example, you can establish
consistent monitoring policies for all of the computers in your network. With AppManager Control
Center, you define these policies once, and they are automatically replicated to each management
site. In addition, Control Center lets you assign permissions so that each administrative team
manages its own site.

Introduction to AppManager Site Administration 27

 In a decentralized environment with multiple administrative teams that operate independently,
consistency across multiple QDBs might not present an issue. If your organization is decentralized or
requires only minimal standardization (for example, by establishing a common set of reports for all
sites to use but letting each site define its own event-handling policies), multiple management sites
might best suit your needs.

The following diagram illustrates this type of site configuration:

1.6.5 Defining a Management Site

You define the configuration of an AppManager management site when you install AppManager
components. You start by creating the QDB, then install the management server and identify the QDB
to which the management server connects, and install the Task Scheduler service and add QDBs and
the CCDB to the service.

After you install the core components, you install AppManager agents on the computers you want to
monitor and specify the management server with which each agent computer can communicate. After
you install and discover agents, you can use the UNIX Agent Manager or the
AMAdmin_SetPrimaryMS and AMAdminUNIX_SetPrimaryMS Knowledge Scripts to set or change
the primary and secondary management server for each agent computer.

1.6.6 Planning and Staging a Deployment

In general, the more planning you do before deploying AppManager in a production environment, the
more successful your implementation will be, particularly if your organization is very large with
complex network and security issues. In practice, most of the characteristics of your installation can
be modified after installation, so many organizations deploy a basic monitoring environment and
refine policies and procedures over time. For suggestions about how to stage a deployment of
AppManager components over time, see the Installation Guide for AppManager, available on the
AppManager Documentation page (http://www.netiq.com/documentation/appmanager).

28 Introduction to AppManager Site Administration

1.6.7 Defining Site-Level Policies
In addition to decisions about the basic configuration of your AppManager management site, you will
need to make other policy decisions, from defining security roles for AppManager users to
establishing a database management and backup strategy. The remainder of this guide focuses on
the key issues that you typically need to address.

Some topics, such as setting up security roles and identifying AppManager users, apply for all
environments, regardless of size. Other topics, such as adjusting the flow of data from agent
computers to the management server, only apply to organizations that need to control and customize
the communication to suit their network topology or bandwidth constraints.

1.7 Managing Multiple Sites

Large and widely distributed organizations often require more than one QDB because of the number
of computers being managed, the distribution of computers on the network, or the amount of data
they collect. Using multiple QDBs, however, increases the complexity of managing your environment
and the burden on the administrative staff in performing routine tasks. If you need to use multiple
QDBs, you can:

 Manage each site independently, with each site responsible for deciding its own monitoring,
event-handling, and data-handling policies and managing its own QDB.
 Manage computers, jobs, events, and data collection for some or all of the sites from a single,
central location using Control Center.

Depending on the structure and policies of your organization, there are benefits and drawbacks to
either approach for managing multiple sites. In general, however, the first option works best for
decentralized organizations with distinct functional or departmental units. For organizations that
require centralized and standardized IT management across sites, the second approach provides the
administrator with a single console for managing computer groups, monitoring policies, events, and
data across multiple QDBs. For more information about Control Center, see the Control Center User
Guide for AppManager, available on the AppManager Documentation page (http://www.netiq.com/
documentation/appmanager).

Introduction to AppManager Site Administration 29

30 Introduction to AppManager Site Administration
2 Site Communication and Security
2

This chapter describes ways you can customize the communication between your agent computers
and the management server. It includes a brief overview of the communication protocols for
AppManager components and describes the security and configuration options available.

Customizing site communication is optional. You can tailor the methods and frequency of agent
computer communications with the management server to suit your network requirements,
bandwidth, latency, and operational policies.

2.1 AppManager Communication Protocols

AppManager relies on specific types of network connectivity between the computers where
AppManager components are installed as well as specific port bindings. For more information about
the communication protocols and port bindings that AppManager requires between components, see
the Installation Guide for AppManager, available on the AppManager Documentation page (http://
www.netiq.com/documentation/appmanager).

2.2 Understanding Communication Security Levels

Within any single management site, choose the level of security for communication between the
management server and all of the agent computers. Agent installation offers extra security options to
encrypt agent-to-management server communications, or to encrypt communications and require
agents to authenticate the management server. In most cases, you do not need to use these extra
options, which add some overhead to production servers and the management server.

If you do not choose one of the extra security options, AppManager transmits data between the
management server and agents without encryption, and agents do not authenticate the identity of
management servers. AppManager always encrypts passwords, so even without extra agent security
options, only user names are sent as clear text over the network. If you require a password for access
to a particular application, like SQL, the password is encrypted in a table. That encrypted password is
sent to the agent, which records it locally, still encrypted. Only when a job executes will the password
be unencrypted and used to gain access to the application. This lowest security setting is appropriate
for a closed network environment, but some organizations require greater security to ensure data
privacy and integrity and to help prevent potential attacks from unauthorized, external sources.

When you install agents, the following options are available for securing communications between
management servers and agents:

 Encrypted communications only (security level 1) provides a basic level of security with little
impact on performance. If you select this option, AppManager encrypts data transmissions
between agents and management servers using a session key it generates dynamically when
the management server starts, but does not require agents to authenticate the management
servers with which they communicate.
 Authentication and encrypted communications (security level 2) provides an additional layer of
security, but requires additional steps for managing and distributing keys. If you select this
option, AppManager encrypts data transmissions between agents and management servers and

Site Communication and Security 31

 requires agents to authenticate management servers using a predefined key before they
transmit data. AppManager stores the key information in the QDB and makes a portion of it
available for agent computers to use.
For Windows agents, this option requires the 128-bit Windows High Encryption Pack, which you
might need to install on the agent computer. The High Encryption Pack can be exported from the
U.S. to worldwide destinations, except where expressly restricted.

For either security level, AppManager uses 40-bit RPC encryption.

Although you manage secure communication separately for Windows agents and UNIX agents, all
management servers and agent computers in a management site should use the same level of
security. For either platform, you cannot mix security levels. For example, you cannot set some
Windows agent computers to use clear text or encryption while other Windows agent computers use
authentication and encryption. If you choose Authentication and encrypted communications, all
agents within the same site must use the same key file.

If you choose Encrypted communications only or Authentication and encrypted

communications, AppManager implements FIPS-compliant algorithms. FIPS compliance does not
affect unencrypted communications. For more information about FIPS-compliant security, see
Section 2.3, “Understanding FIPS Compliance,” on page 32.

For more information about installing agents, see the Installation Guide for AppManager, available on
the AppManager Documentation page (http://www.netiq.com/documentation/appmanager).

Although you normally set the security level for a site during installation, you can change the security
level after installation using the NQKeyGenWindows.exe program for Windows agents, or the
NQKeyGenUNIX.exe program for UNIX agents. Changing the security level after installation may
interrupt or prevent communication between the management server and agent computers, at least
temporarily. Therefore, avoid changing the security level, if possible, or plan carefully for any changes
to reduce disruption to your environment.

You can also use the programs any time you need to create and manage key file information for one
of the agent security options. For more information about using the programs, see Section 2.4,
“Managing Secure Communication for Agents,” on page 34.

2.3 Understanding FIPS Compliance

There are two components to AppManager FIPS compliance:

 The FIPS-compliant algorithms that AppManager uses for security levels 1 and 2

FIPS compliance does not affect unencrypted communications.

 The Control Center console FIPS-only compliance flag

AppManager implements FIPS-compliant algorithms for security levels 1 and 2. These algorithms
secure communication between repositories, management servers, and agents. AppManager retains
non-compliant encryption algorithms for backward compatibility with earlier versions of AppManager
and supports a mix of FIPS-compliant and non-FIPS-compliant components. For security levels 1 and
2, FIPS-compliant components communicate with each other using FIPS-compliant algorithms and
communicate with non-FIPS-compliant components using non-FIPS-compliant encryption algorithms.

AppManager FIPS compliance is independent of operating system FIPS compliance.

32 Site Communication and Security

 The Control Center console offers an option to use only FIPS-compliant security algorithms for
security levels 1 and 2. If you choose to implement this option, AppManager no longer supports a
mixed security environment and any non-FIPS-compliant AppManager components are no longer
available. When you enforce FIPS compliance for AppManager, the following restrictions exist:

 QDBs, management servers, and agents that Control Center manages must use FIPS-compliant
algorithms for communication. Non-FIPS-compliant AppManager components are excluded and
unreachable with this option.
 AppManager consoles are no longer able to create SQL user accounts or add QDBs using SQL
authentication.

NOTE: If the computer hosting an AppManager console enables FIPS compliance at the
operating system level, SQL authentication is disabled and you must use Windows
authentication to log on to the console.

Use the Security options to enable the Control Center console FIPS-only compliance flag. Any time
you change this option you must restart the management servers so they will recognize the new
security settings.

2.3.1 Planning for AppManager FIPS Compliance

If you plan to configure AppManager to use FIPS-compliant algorithms, consider the following:

 SQL authentication is not FIPS-compliant under AppManager. If you plan to activate the option
Use only FIPS-compliant security algorithms in your environment with security level 1 or 2,
ensure that you meet the following requirements:
 Install repositories, management servers, and agents to use Windows authentication.
 Configure Kerberos delegation to use Windows authentication. For more information, see
Microsoft article 326089 ( http://support.microsoft.com/kb/326089).
 Earlier AppManager releases are not FIPS-compliant. If you install this AppManager release into
an existing AppManager environment and enable the Control Center option Use only FIPS-
compliant security algorithms with security level 1 or 2, all AppManager components that are
not FIPS-compliant are excluded and unreachable from FIPS-compliant components. For
example:
 Older agents cannot communicate with this management server version.
 This version of the management server cannot access earlier QDB versions.

NetIQ Corporation recommends that if you upgrade an existing AppManager environment to use
FIPS-only compliance, you upgrade all components in the environment to FIPS-compliant versions.

Site Communication and Security 33

 2.3.2 FIPS-Compliant and Non-FIPS-Compliant AppManager
Components
This AppManager version can coexist with earlier AppManager components when FIPS-only
compliance is not enabled. This AppManager version uses FIPS-compliant algorithms to encrypt
communications to FIPS-compliant components and retains legacy algorithms to encrypt
communications to older AppManager components.

Enabling the option Use only FIPS-compliant security algorithms has the following effects on
communications between components:

 For AppManager security level 0, FIPS-compliant and non-FIPS-compliant AppManager

components can coexist. NetIQ Corporation does not recommend this combination of options as
it secures AppManager to use only FIPS-compliant encryption algorithms and disables
encryption. Agents, management servers, and QDBs communicate in clear text.

For more information about clear text information that can be passed in AppManager security
level 0, see NetIQ KnowledgeBase article KB71855.
 For AppManager security levels 1 and 2, non-FIPS-compliant AppManager components are
excluded and unreachable from FIPS-compliant components.

If you do not enable the option Use only FIPS-compliant security algorithms, FIPS-compliant and
non-FIPS-compliant AppManager components can coexist under any AppManager security level. For
AppManager security levels 1 and 2, FIPS-compliant components communicate with each other
using FIPS-compliant algorithms and communicate with non-FIPS-compliant components using
proprietary AppManager encryption algorithms.

By default, the Use only FIPS-compliant security algorithms option is not enabled.

2.3.3 Management Servers and the FIPS-Only Compliance Flag

The Control Center console option Use only FIPS-compliant security algorithms maps to a QDB
flag. When you change the Control Center FIPS-only compliance option, the flag in each QDB you
add to Control Center changes.

If you change FIPS-only compliance in Control Center, you must restart each management server
that reports to the QDB so that it can read the new FIPS flag state. Otherwise, the management
server will not detect the FIPS-only compliance state change and will continue to operate in its
previous mode.

If you enable FIPS-only compliance, jobs already active with older agents continue to forward events.
If you restart the management server as required, you can no longer create new jobs for older agents.
If you do not restart the management server, you can create new jobs for older agents because the
management server will not detect the FIPS-only compliance state change in the QDB.

2.4 Managing Secure Communication for Agents

Although you normally set the security level for a site during installation, you can change the security
level after installation using the NQKeyGenWindows.exe program for Windows agents, or the
NQKeyGenUNIX.exe program for UNIX agents. You can also use the programs any time you need to
create and manage key file information for one of the agent security options.

34 Site Communication and Security

2.4.1 Changing the Security Level for Management Servers
After installation, you can use the NQKeyGenWindows.exe program to change the security level for
communication between the management server and Windows-based agents. For UNIX agents, use
the NQKeyGenUNIX.exe program.

If you change the security setting for the management server, update the security setting for all
agents in the site. Also, if you are changing from no security to security level 1 or 2, generate or
identify a repository key to use before changing the security level. For more information, see
Section 2.4.3, “Generating a Repository Key,” on page 36.

To change the security level for the management server:

1 On a management server computer, open a Command Prompt window and change to the
NetIQ\AppManager\bin directory.
2 Run the appropriate program to set the security level for the management server using the
following format:

NQKeyGenWindows|NQKeyGenUNIX -db database_name:user_name:sql_server\instance

-seclev level

For example, to use your current Windows account name and password and set the security
level to use encryption only (security level 1) with a QDB installed on the server NYC2006, you
would type a command-line similar to this:

NQKeyGenWindows -db qdb::nyc2006 -seclev 1

NOTE
 All management servers that connect to the same repository must use the same security
level.
 For encryption or management server authentication and encryption, use the same key file.

3 Change the security level for all of your agents to match the new security level setting. For more
information, see Section 2.4.2, “Changing the Security Level for Agents,” on page 35.
4 Stop and restart the NetIQ AppManager Management Service (NetIQms). This allows the
management server to receive the new security level information.

2.4.2 Changing the Security Level for Agents

If you change the security level for the management server, you must also update the security setting
for every agent.

For UNIX agents, you can change the security setting from the UNIX Agent Manager console. For
information about UNIX Agent Manager, see the NetIQ UNIX Agent documentation, which is included
in t he AppManager UNIX download package.

To change the security level for a Windows agent:

1 Start the Control Center console.

2 In the Enterprise Layout view of the Navigation pane, select the Knowledge Scripts view of a
management group that includes the agent computer where you want to change the agent
security level.
3 In the view pane, select the AgentConfigSecurityLevel Knowledge Script.
4 In the Tasks pane, click Create New Job.

Site Communication and Security 35

 5 Click the AMAdmin tab in the Knowledge Script pane.
6 In the Select Servers dialog box, select the agent computer where you want to run the
Knowledge Script and then click OK.
7 Click the Values tab, and:
 Select the new security level from the Security level list.
 Set the event notification and event severity parameters as desired.

NOTE: If you change the security level from security level 1 or 2 to unencrypted
communications, the management server ignores the event raised because it is not encrypted.
Therefore, no event indicator is displayed in the Control Center console if you change the
security level to unencrypted communications. If you are changing from unencrypted
communications to security level 1 or 2, you must generate or identify the agent key to use
before changing the security level. For more information, see Section 2.4.3, “Generating a
Repository Key,” on page 36.

8 Click OK to start the job.

9 After updating all of your Windows agents, manually stop and restart each management server
in the management site by stopping and then restarting the NetIQ AppManager Management
Service (NetIQms).

As an alternative, you can run NQKeyGenWindows.exe directly on an agent to set the security level for
the agent or to set the security level for a remote agent. For example, to change the security level on
an agent to use encryption without authentication, type a command similar to this:

NQKeyGenWindows -agentseclev 1

For more information about using NQKeyGenWindows options, see “Key File Utility for Windows
Agents” on page 177.

2.4.3 Generating a Repository Key

If you are using security level 1 or 2 (encryption or authentication and encryption) to secure
communications between the management server(s) and agent computers, generate a new
encryption key and store it in the repository.

To generate a new repository key for agents:

1 On a management server computer, open a Command Prompt window and change to the
NetIQ\AppManager\bin directory.
2 Run the appropriate program to generate a new key and store the key information in the
repository:

NQKeyGenWindows|NQKeyGenUNIX -db database_name:user_name:sql_server/instance -

new

36 Site Communication and Security

 Variable Description

database_name The name of the AppManager repository.

user_name A valid SQL Server login with permission to access the AppManager
repository.

NOTE: If you are using Windows authentication to connect to the

repository, leave the user name blank. If you are using SQL Server
authentication, type a SQL Server user name for connecting to the
repository. The program prompts for the password to use for the SQL
Server account.

sql_server\instance The name of the SQL Server computer and SQL Server instance name (if
applicable) where the AppManager repository is installed.

For example, to run NQKeyGenWindows.exe on a computer named NYC2003 with Windows

authentication, type a command similar to this:

NQKeyGenWindows -db qdb::nyc2003 -new

3 Type a password for the repository key. If you want to extract the key into a file or use this key in
another repository, you need to know this password. For information about sharing a key across
multiple repositories, see Section 2.4.4, “Extracting and Sharing Key Information from the
Repository,” on page 37.
4 Run the appropriate program with the following command-line format to extract the portion of the
key for the agents to use:

NQKeyGenWindows|NQKeyGenUNIX -db database_name:user_name:sql_server\instance

-ckey filelocation

NOTE: If you are using Windows authentication to connect to the repository, leave the user
name blank. For SQL Server authentication, type a SQL Server user name for connecting to the
repository. The program prompts for the password to use for the SQL Server account.

In specifying a path for the file, use a directory that you can access from the computers to be
managed.
5 Stop and restart the NetIQ AppManager Management Service (NetIQms) to register the new key
with the management server.

2.4.4 Extracting and Sharing Key Information from the

Repository
The NQKeyGenWindows.exe and NQKeyGenUNIX.exe programs can extract repository encryption key
information and save it in a password-protected file. Saving this information in a file allows you to
share a single key across multiple repositories.

If you want to create this password-protected file, run the appropriate program using the following
command:

NQKeyGenWindows|NQKeyGenUNIX -db database_name:user_name:sql_server/instance-skey

filelocation

Site Communication and Security 37

 NOTE: If you are using Windows authentication to connect to the repository, leave the user name
blank. To use SQL Server authentication, type a SQL Server user name for connecting to the
repository. The program prompts for the password to use for the SQL Server account.

To check the key into another repository from the file location specified:

1 On a management server computer, open a Command Prompt window and change to the
NetIQ\AppManager\bin directory.
2 Run the appropriate program to import the key pair into the repository.
For example, if you created the key using the password ^myPass and extracted the encrypted
key to the file location C:\Security\AMkey.txt, type the following command to import the key
pair into the repository QDB01 on the computer SFO2003:

NQKeyGenWindows|NQKeyGenUNIX -db QDB01:smithj:SFO2003 -change

C:\Security\AMkey.txt

3 Use the password you used to create the key in the repository. Provide the key file password
^myPass.
4 After you import the key, stop and restart the AppManager Management Service (NetIQms) to
register the new key with the management server.

2.4.5 Extracting the Key File

The NQKeyGenWindows.exe and NQKeyGenUNIX.exe programs can extract a portion of the key
information stored in the repository and save it in a file. You can then make this agent key file
available to all of your agents.

To extract the portion of the key for the agents to use:

1 On a management server, run the appropriate program with the following command-line format:

NQKeyGenWindows|NQKeyGenUNIX -db database_name:user_name:SQL_Server/

instance-ckey filelocation

NOTE: If you are using Windows authentication to connect to the repository, leave the user
name blank. For SQL Server authentication, type a SQL Server user name for connecting to the
repository. The program prompts for the password to use for the SQL Server account

2 Specify a path for the file that you can access from the agent computers.
3 (Conditional) For Windows agents, use the AMAdmin_AgentConfigSecurityKey Knowledge
Script to distribute the agent key file to all of your Windows agents. For more information, see
Section 2.4.6, “Updating the Key File,” on page 39.
4 (Conditional) For UNIX agents, run the AMAdminUNIX_AgentUpdateSecurityLevel Knowledge
Script, replace the old public key file in the UNIX agent data directory with the new public key
file, and restart the UNIX agent. For more information, see the AppManager for UNIX Servers
Management Guide, available on the AppManager Modules Documentation page (http://
www.netiq.com/documentation/appmanager-modules).

38 Site Communication and Security

2.4.6 Updating the Key File
For maximum security and to prevent keys from being compromised over time, periodically create
new keys and distribute new key files to all agent computers. This process, called “re-keying,” applies
when you are using security level 1 or 2 (encryption or management server authentication and
encryption).

Updating the Key File for Windows Agents

You can choose to update the agent key file manually, which is more secure, or you can add a
registry key that allows the agent to automatically detect changes to the key file on the management
server and request the new key file. Both methods are described below, as well as a security risk that
exists with the automatic update detection feature.

To replace the agent key file manually (most secure method):

When changing the agent key file, update all of the agent computers before updating the
management servers. All management servers and agent computers within a management site must
use the same security level and the same key file.

Because manual re-keying requires you to restart all of your management servers, plan carefully. If
you cannot update the key file for some agents, you will experience communication failures between
the management server and those agents. In addition, any time you update the key file, you might
experience a temporary loss of communication between the management server and the agents.
Therefore, consider disabling communication with some agents before updating key files or security.

1 Use the NQKeyGenWindows.exe utility to generate a new key and store the key information in the
repository.
2 Use the NQKeyGenWindows.exe utility to extract the agent portion of the key and save it to a file
location.
3 Use the Control Center console to run the AMAdmin_AgentConfigSecurityKey Knowledge Script
on the agent computers you want to update. When creating the job, click the Values tab and:
 Type the path to the new agent key file in the Location of key file field.
 Type the password for the new agent key file in the Encryption password field.
 Set the event notification and severity parameters.
4 Click OK to start the job.
5 Verify that all jobs complete successfully.
6 After updating all of your Windows agents, manually stop and restart each management server
in the management site by stopping and then restarting the AppManager Management Service
(NetIQms).

To enable the automatic update detection feature (least secure method):

With this method, the agent automatically detects changes to the key file on the management server
and requests the new key file using a checksum of the previous key to identify itself. If the
management server successfully identifies the agent using the checksum, the management server
uses the checksum to encrypt the new key file and sends the new key file to the agent. The agent
uses the checksum to decrypt the new key file.

The automatic update detection feature is disabled by default.

Site Communication and Security 39

 WARNING: With this method, any time the agent or the management servers sends the checksum, it
sends the checksum as clear text. It is possible for rogue software to capture the checksum and
decrypt the new key file.

Be careful when editing your Windows registry. If there is an error in your registry, your computer
might become nonfunctional. If an error occurs, you can restore the registry to its state when you last
successfully started your computer. For more information, see the Help for the Windows Registry
Editor.

1 On the management server, open the Registry Editor and navigate to

HKEY_LOCAL_MACHINE\SOFTWARE\NetIQ\AppManager\4.0\NetIQms\Config (on 32-bit
operating systems) or
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\NetIQ\AppManager\4.0\NetIQms\Config (on
64-bit operating systems).
2 Add a registry key with the following values:
 Name: RPC_KeyMat_AutoUpdate_Enabled
 Type: DWORD
 Data: 1
If you want to disable the feature later, change the Data value to 0.

Updating the Key File for UNIX Agents

If you have more than one management server in your management site, the management server
acting as the current primary management server for the agent must complete the re-keying process.
If communication with the acting primary management server is interrupted before re-keying is
complete, failover to the inactive management server will not take place and communication with the
UNIX agent will be lost.

To prevent this problem, check the status of all management servers and ensure that the agent can
communicate with the management server before you start re-key operations. Never stop the UNIX
agent management server during re-key operations.

To replace the public/private key pair:

1 Use the NQKeyGenUNIX.exe utility to create a new public/private key pair and store it in the
repository.
2 Stop and restart the management server so it picks up the new key pair.

After you restart the management server, the next communication from the UNIX agent fails when the
agent attempts to authenticate the management server using the old public key. The UNIX agent then
uses an encrypted message to request the new public key from the management server by sending a
message that includes a checksum for its current key.

The management server uses the checksum to retrieve the key pair from the repository and to
encrypt the new public key with the previous private key, and then it sends the signature and the new
encrypted public key back to the UNIX agent. The UNIX agent decrypts the new public key using its
old public key, which verifies that the new key is from the appropriate management server and begins
using the new public key.

You can use the NQKeyGenUNIX.exe utility to remove historical keys from the repository at any time. If
you remove the historical keys, however, you must manually replace the public key file on each UNIX
agent when you change the public/private key pair. In this case, the automated re-keying process
fails.

40 Site Communication and Security

 2.5 Setting up Primary and Backup Management
Servers
Within each management site, you can explicitly designate a primary management server and a
backup, or secondary management server for each agent computer. Establishing a primary and
secondary management server for each agent computer provides the following benefits:

 Predictable failover support

For information about how failover works, see Section 2.5.3, “How Failover Works,” on page 43.
 Static load distribution
For information about how load distribution works, see Section 2.5.4, “Distributing Processing
Load,” on page 43.

You can designate the primary and secondary management server when you install the AppManager
agent. You can also run the AMAdmin_SetPrimaryMS Knowledge Script for Windows computers and
the AMAdminUNIX_SetPrimaryMS Knowledge Script for UNIX computers after installation.

After you explicitly designate a primary management server, only the primary management server
sends job requests to the agent and receives corresponding events and data. If communication with
the primary management server is interrupted and you have identified a secondary or backup
management server, communication is automatically transferred to the secondary management
server. If you have not specified a secondary management server, data and events are stored locally
on the agent computer. When communication with the primary management server is restored, the
agent then resumes communication with the management server.

NOTE: For UNIX agents, the management server you identify during installation becomes your
default primary management server. The installation steps also prompt you to specify whether the
UNIX agent can also communicate with other management servers. You can then run the
AMAdminUNIX_SetPrimaryMS Knowledge Script to designate a secondary management server.

If you have multiple management servers in your environment, NetIQ Corporation recommends the
following:

 Designate the local management server as the primary management server. For more
information, see Section 2.5.1, “Designating the Local Management Server as the Primary
Management Server,” on page 41.
 Configure a single management server for remote installation tasks. This configuration avoids
excessive network traffic associated with remote agent installation or upgrade tasks.
 Designate primary and secondary management servers for all agent computers. For more
information, see Section 2.5.2, “Configuring a Primary and Secondary Management Server for
Agent Computers,” on page 42.

2.5.1 Designating the Local Management Server as the Primary

Management Server
When you install the management server component, an AppManager agent is automatically
installed locally on the management server. Configure the local agent to have the local management
server designated as its primary management server.

To designate the primary management server for the agent on the management server:

1 Log on to the Control Center console as a user who has permissions to run Knowledge Scripts.

Site Communication and Security 41

 2 If you have not already done so, run the Discovery_NT Knowledge Script and any additional
Discovery Knowledge Scripts on each management server. For example, if you have installed
the management server component on the computer JUNO, drag and drop the Discovery_NT
Knowledge Script onto JUNO in the Enterprise Layout view of the Navigation pane.
3 After a successful discovery, run the SetPrimaryMS Knowledge Script on the management
server.
4 On the Values tab, specify the local management server as the primary management server.
You do not need to configure a secondary management server.

2.5.2 Configuring a Primary and Secondary Management Server

for Agent Computers
Each agent computer can have only one designated primary management server and one
designated secondary management server. Unless you designate the primary and secondary
management server during agent installation, perform this task manually after you:

 Configure each management server to be its own primary management server

 Configure a single management server to perform remote installation-related tasks

To designate a primary and secondary management server for each agent computer:

1 Log on to the Control Center console with an account that is a member of the Administrator user
group.
2 Ensure that all agent computers have been discovered.
3 Run the AMAdmin_SetPrimaryMS or AMAdminUNIX_SetPrimary MS Knowledge Script on the
agent computer.
4 On the Values tab, specify the primary and secondary management servers for this computer.
5 (Conditional) For Windows agents, set the management server operation to perform to
designate both the primary and secondary management server for this agent computer, and then
click OK.
6 (Conditional) For UNIX agents, select either Set Primary management server or Set secondary
management server to designate a new primary or secondary management server for this agent
computer, and then click OK.
To change both the primary and secondary management server, run the Knowledge Script twice.
By default, if you use the script to specify a new primary management server, the management
server that you specified when you installed the agent becomes the secondary management
server. Use the Unset specified management server option to remove a management server
you no longer want to use.

It can take up to 15 minutes for the QDB to designate the primary and secondary management
servers. To start new jobs after you change the designation for an agent computer, wait until the
repository updates the management server designation.

Once the management server designation is complete, you can run jobs on the agent computer. The
designated primary management server sends job requests.

42 Site Communication and Security

2.5.3 How Failover Works
After you designate a primary and secondary management server for an agent computer, the QDB
and the local repository on the agent store the server information. The agent accepts job requests
from and sends events and data to its primary management server.

If an attempt to communicate with the primary management server fails, the agent waits for one
minute before attempting to reconnect to the primary management server. By default, the agent
attempts to connect three times every minute before failing over to the secondary management
server.

After the third attempt to connect to the primary management server fails, the agent sends events and
data to the secondary management server to store in the QDB. However, the secondary
management server does not immediately send new or changed job requests to the agent computer.

Every 15 minutes, the management server updates its list of agent computers. If a secondary
management server picks up communication with new agent computers because communication
with a primary management server fails, the secondary management server updates itself with that
information after the interval. If there are new jobs or changes to job properties, the secondary
management server can then communicate the changes to the agent computers that failed over.
Because of this delay before the secondary management server recognizes the failed-over agent
computer, it can take up to 15 minutes to communicate job information to the agent computer.

While the secondary management server manages the agent computer, the agent continues trying to
contact its primary management server every minute. After the agent re-establishes communication
with the primary management server, the agent sends events and data to its primary management
server. Each management server updates its list of agent computers and the communication of job
information transfers back to the primary management server one minute later.

For information about modifying the interval and the number of times the agent attempts to contact
the primary management server, see Section 10.11.1, “Changing Agent Failover Configuration,” on
page 126.

For information about changing the interval at which a management server checks its list of agent
computers, see Section 9.2, “Changing the Polling Interval for Agent Computers,” on page 112.

2.5.4 Distributing Processing Load

You can distribute processing load by assigning agent computers to different management servers.
For example, you can assign agent computers in New Zealand to a management server in New
Zealand and agent computers in Sweden to a management server in Sweden. Or you can assign
agent computers to management servers according to functional groups or departments.

If you plan to use multiple management servers to balance processing load, limit the number of
computers each management server is responsible for monitoring. For example, if you have two
management servers, LONDON and PARIS, configure half of your agent computers to use the LONDON
management server as the primary management server and PARIS as the secondary management
server, and half of your agent computers to use PARIS as the primary management server and
LONDON as the secondary management server. The primary/secondary pair should not manage more
than approximately 600 agent computers between them, which means each management server can
manage up to 300 agent computers. This configuration ensures that no single management server is
responsible for more agent computers than it can handle in the event of a failover.

Site Communication and Security 43

 2.5.5 Verifying the Management Server Assigned to an Agent
Computer
You can verify whether a management server that is assigned to an agent computer is the primary
management server or the secondary management server.

To verify the management server assigned to an agent computer:

1 In the Control Center console, click the agent computer in the Enterprise Layout view of the
Navigation pane.
2 The view pane displays the primary and any secondary management server for the agent
computer.

2.5.6 Changing a Management Server Assigned to an Agent

Computer
In some cases, you might want to change the management server assigned to an agent computer.
For example, the management server might not be performing as expected or an agent computer
might move to another network or geographical location. For more information about changing the
management server, see Section 2.5.2, “Configuring a Primary and Secondary Management Server
for Agent Computers,” on page 42.

2.5.7 Adding a New Management Server

You might want to add new management servers to your AppManager management site. Before
adding a new management server, determine whether to use the new management server as a
passive, secondary management server for all agent computers or as a primary management server
for some of your agent computers.

If you plan to use the new management server as a primary management server for some agent
computers to balance processing load, plan to configure 50% of the agent computers to use the first
management server as the primary and to use the new management server as the secondary, and
configure 50% of the agent computers to use the new management server as the primary and to use
the first management server as the secondary.

To add a management server to your management site:

1 If you have not explicitly designated the management server for every agent computer, run the
AMAdmin_SetPrimaryMS or AMAdminUNIX_SetPrimaryMS Knowledge Script on the agent
computers to configure the current management server as the primary management server.
2 Install the new management server and configure it to communicate with the QDB.
3 Run AMAdmin_SetPrimaryMS or AMAdminUNIX_SetPrimaryMS on the new management
server computer and designate the local management server as the primary management server
for the local agent. For more information, see Section 2.5.1, “Designating the Local Management
Server as the Primary Management Server,” on page 41.
4 Run AMAdmin_SetPrimaryMS or AMAdminUNIX_SetPrimaryMS to configure each agent
computer to recognize the new management server.

It can take up to 15 minutes for the management server to identify changes to its list of agent
computers. The agent computer can send information to a newly-designated management server
immediately, but there might be a delay of approximately 15 minutes before a newly-designated
management server sends new job information to the agent computer.

44 Site Communication and Security

3 Managing Security for Control Center
3

Configuring who has access to the Control Center console and defining the tasks each user can
perform is the primary way you ensure security and enforce job-specific access to AppManager. You
configure security settings using the Manage Security option on the Global Tasks tab of the ribbon.

This chapter explains how AppManager works with SQL Server and either Windows authentication or
mixed mode security to define basic security for AppManager. The chapter also describes how to use
the Control Center console to define group-based security for Control Center users, add Control
Center user accounts based on SQL Server login accounts, assign Control Center users to the
groups you create, and manage user rights.

3.1 Understanding User Security

Since both the AppManager repository and Control Center repository are SQL Server databases,
AppManager security relies on SQL Server security. Every user who needs access to the Operator
Console or Control Center console must have a valid SQL Server login name and password for the
SQL Server where the AppManager repository or the Control Center repository database is running.
The creation and authentication of the SQL Server login accounts at connection time depends on the
SQL Server security mode you use.

Control Center console users also need access to the QDBs that connect to the Control Center
repository. Regardless of the authentication method, Control Center users cannot access a QDB if
they are not added as a user in the QDB.

By default, Control Center console users are granted Read Only permissions for every QDB you
register them with in the Control Center console. However, depending on the tasks a user needs to
perform in the Control Center console, you may need to modify the permissions the user has on the
primary QDB. You need to make these modifications using Security Manager. For more information
about defining security for the Control Center console, see Section 3.2, “Managing Control Center
Security,” on page 46.

3.1.1 Using Windows Authentication Security

If you use Windows-only authentication, use Windows administrative tools to create and manage
user and group accounts and then use the Control Center console to map those groups and users to
SQL Server logins. A SQL account can be a Windows group or user.

For more information see Section 3.2.5, “Adding a Control Center User,” on page 50.

3.1.2 Using Mixed Mode Security

If you are using mixed mode security, you can create and maintain SQL Server login accounts
independently of any Windows accounts or groups. With this mode, you can manage login accounts
through SQL Server and authorize which accounts should have access to the AppManager Operator
Console or Control Center console. You can also create new SQL Server logins with access to an
AppManager repository or Control Center repository using the AppManager Security Manager or the
Control Center console.

Managing Security for Control Center 45

 NOTE: You must be a SQL Server administrator to create SQL Server logins using Security Manager
or the Control Center console.

If you are using mixed mode security, inform users whether they should use Windows authentication
or SQL Server authentication to log on to an AppManager or Control Center repository, depending on
how you configured the account.

3.1.3 Managing Users with Windows Groups

In addition to understanding SQL Server security modes, you should also consider using Windows
groups to manage user accounts most effectively. You can create groups using standard Windows
administrative tools, then map an entire group to a single SQL Server login. When you have created
the SQL Server login for the group, all privileges assigned to that login through SQL Server and
AppManager apply to all of the member user accounts within that Windows group.

Once you grant the SQL Server login account permission to access the AppManager repository, you
can use Security Manager or the Control Center console to add the group account as a new
AppManager user.

Although it is common for a user to belong to more than one Windows group, you should avoid this
when using Windows groups for AppManager users. If a user belongs to more than one Windows
group that is mapped to a SQL Server login account and added to AppManager, maintaining security
can become difficult. For example, if the user SPeters belongs to two Windows groups, ExchAdmins
and JrAdmins, that have been given different privileges or assigned different AppManager roles, the
user may have unexpected or conflicting rights or restrictions.

The best way to ensure consistency and manageability is to create new Windows groups specifically
for each Security Manager role or Control Center user group you plan to define. Using Security
Manager, you can specify the individual functional rights for viewing information and performing tasks
you want available for each role. For example, if there are two AppManager roles available, Read-
Only User and SrAdmin, you can create two corresponding Windows groups called AppManager
ReadOnly and AppManager Senior Admins and assign the corresponding role to each group of
users. Using the Control Center console, you can define user groups and then add the Windows
groups to the Control Center user groups. You then assign user groups and permission sets to
management groups to define security for the Control Center console. For more information about
managing security using the Control Center console, see Section 3.2, “Managing Control Center
Security,” on page 46 and Section 3.2.5, “Adding a Control Center User,” on page 50.

NOTE: In creating Windows user accounts and groups to access AppManager, you need to consider
that specific privileges may be required to perform certain tasks. For example, any Windows user
account or group that is used to log on to the Operator Console must be granted Write permission for
the NetIQ\AppManager\bin\cache folder.

3.2 Managing Control Center Security

You use the Control Center console to manage security for the Control Center repository. This section
describes how you use the Control Center console to configure security.

The Control Center administrator controls user access to the Control Center console and the
operations that users can perform. The administrator configures Control Center security in
conjunction with standard Windows and SQL Server login account management. For more
information about Windows and mixed mode authentication, see Section 3.1.1, “Using Windows
Authentication Security,” on page 45 and Section 3.1.2, “Using Mixed Mode Security,” on page 45.

46 Managing Security for Control Center

 NOTE: Members of the Control Center Administrator group have the sysadmin server role on the
SQL Server that hosts the Control Center repository. If the same SQL Server hosts the primary QDB,
members of the Administrator group also have the sysadmin server role on the QDB.

3.2.1 Configuring Control Center Permissions

To configure security permissions in Control Center, you must add users and user groups, define
permission sets, and then assign the user groups and permission sets to management groups. You
must be a member of the Control Center Administrator group to modify the members of a user
group or modify permission sets, but you do not have to be an administrator to assign user groups
and permission sets to management groups.

Most organizations start with a few administrative users and add specialized user groups and
permission sets over time. Initially, NetIQ Corporation recommends allowing only expert-level
administrators to perform most tasks and limiting access to the Control Center console to a small
number of people until you firmly establish user groups and permissions sets that suit your
organization. After your production environment is stable and you refine threshold settings, job
properties, event-handling, and data-handling policies to meet your organization’s needs, you might
want to grant more operators and administrators access to the Control Center console.

In general, after you create the user groups and permissions sets appropriate to your organization,
there is very little account maintenance required for managing user accounts.

To configure Control Center permissions:

1 Add Control Center users. For more information, see Section 3.2.5, “Adding a Control Center
User,” on page 50.
2 Create or choose an existing user group and add the users to a group. For more information, see
Section 3.2.6, “Creating, Copying, Modifying, or Removing a User Group,” on page 53.
3 Create or use an existing permission set. For more information, see Section 3.2.7, “Creating,
Copying, Modifying, or Removing a Permission Set,” on page 53.
4 Associate a user group with a permission set and a management group. For more information,
see Section 3.2.9, “Granting and Removing Access to Management Groups,” on page 54.

3.2.2 Understanding Default User Groups

The Control Center console includes a set of default user groups you can use, modify, copy, or
remove to help implement security for the console. The default user groups include the following:

 Administrator

You cannot copy or delete the Administrator group. For more information about this group, see
“Understanding the Administrator Group” on page 48.
 Executives and Stakeholders
 NOC Tier 1
 NOC Tier 2
 Trusted Application Admins
 Trusted Application Owners

For information about modifying, copying, or removing user groups, see Section 3.2.6, “Creating,
Copying, Modifying, or Removing a User Group,” on page 53.

Managing Security for Control Center 47

 Understanding the Administrator Group
Control Center includes a predefined Administrator user group. Only members of the Administrator
user group can:

 Manage Control Center security, including adding and removing Control Center users and
configuring user groups and permission sets.
 Configure the QDBs that Control Center manages, including adding and removing a QDB.
 Configure Control Center preferences under Options on the Main tab.
 View Control Center commands in the Queue Manager.
 View AppManager license information under View Licenses on the Global Tasks tab.

Control Center users who belong to the Administrator user group have full access to Control Center,
including all management groups. The Administrator user group does not need to be associated with
any management groups or permission sets in order to grant its members access and privileges in
the Control Center console.

By default, the command queue service account that you entered during installation and the netiq
account belong to the Administrator user group.

When you add a user to the Control Center Administrator user group, Control Center automatically
adds the user to the Microsoft SQL Server System Administrators (sysadmin) server role. Therefore,
you should restrict the members of the Administrator group to users you want to belong to the
Microsoft SQL Server System Administrators server role. After you remove a user from the Control
Center Administrator group, Control Center automatically removes the user from the Microsoft SQL
Server System Administrators server role.

3.2.3 Understanding Types of Permissions for Control Center

You can set four types of permissions in Control Center. Three of these pertain to operational
permissions and the fourth pertains to Knowledge Scripts:

 Operational permissions.
 Deployment permissions. These permissions allow you to perform tasks specific to remote
deployment.
 General permissions. These permissions allow you to add computers to the Control Center
repository.
 Management group and view permissions. These permissions allow you to perform tasks
specific to management groups.
 Knowledge Script permissions. These permissions determine which Knowledge Scripts can be
used according to Knowledge Script category.

You can view a complete list of the permissions in the Control Center console.

To view the complete permission list:

1 On the Global Tasks tab, click Manage Security.

2 Click Permission Sets, and then click AppManager Administrator.
3 Click Modify, and then click the tabs to view the permissions.

48 Managing Security for Control Center

3.2.4 Understanding Permission Sets
A permission set is a collection of operational and Knowledge Script permissions that defines a group
of activities that can be performed and Knowledge Scripts that can be used in the Control Center
console. To apply a permission set, you associate the permission set with a user group and a
management group. Users belonging to that particular user group can perform the activities that you
define in the permission set for the associated management group. You can associate the same user
group with different permission sets for different management groups. For more information about
applying permission sets, see Section 3.2.9, “Granting and Removing Access to Management
Groups,” on page 54.

The Control Center Console has a default set of permission sets. You can use these permission sets,
copy or modify them to develop your own permission sets, or delete them if they do not meet your
requirements. The default permission sets are:

 AppManager Administrator
 Deny Management Group Access
 Event Operation
 Management Group Administration
 Monitoring Administration
 Monitoring Operation
 Read Only

You can view details about the specific operational permissions granted in the default permission sets
in the Control Center console.

To view details for the default permission sets:

1 On the Global Tasks tab, click Manage Security.

2 Click Permission Sets, and then click the permission set you want to view.
3 Click Modify, and then click the tabs to view the permissions.

Understanding Granted, Not Granted, and Denied

The same user can belong to more than one user group. Should this be the case, the most restrictive
set of permissions is applied by combining the permissions with a logical OR. For example, if the
same user is a member of two user groups associated with the same management group but with
different permission sets, and is granted rights in one permission set but denied the same rights in the
other permission set, then the rights are denied. If a permission is undefined (neither granted nor
denied) for the same user in two different user groups, then the permission is denied. If a permission
is granted for one user group and either undefined or granted in another group for the same user,
then the permission is granted.

Understanding Global Permissions

A global permission set is a permission set associated with a specific user group that applies to all
management groups managed by the Control Center console. Since global permissions apply to all
management groups, they do not depend on association with a specific management group to take
effect.

You can use global permissions to set a common or base set of permissions for a user group for your
entire environment. You can then refine these permissions by applying specific permission sets for
the same user group to individual management groups.

Managing Security for Control Center 49

 The Control Center console applies any global permissions and any permissions specific to a
management group to determine the security context for any objects in a management group. Control
Center applies any global permissions and any permissions assigned to the management group in
the following order:

 If an operational or Knowledge Script permission is denied either globally or for a management

group, the permission is denied.
 If an operational or Knowledge Script permission is granted either globally or for a management
group, the permission is granted.
 If an operational or Knowledge Script permission is neither granted nor denied, the permission is
denied.

The Control Center console provides a default set of global permissions:

User Group Name Permission Set Name

Executives & Stakeholders Read Only

NOC Tier 1 Event Operation

NOC Tier 2 Monitoring Operation

Trusted Application Admins Monitoring Administration

Trusted Application Owners Management Group Administration

For more information, see Section 3.2.8, “Setting Global Permissions,” on page 54.

Understanding Permission Inheritance

Permissions assigned to a management group are inherited by any children of that management
group, so any user group assigned to the management group will have the same permissions on any
children of the management group. You do not need to assign user groups or permissions sets
individually on each child management group.

If a user group has a global permission set assigned to it and the permission set includes
management group permissions, members of the user group will have those permissions on all
management groups and child management groups associated with the user group.

3.2.5 Adding a Control Center User

To add a Control Center user, you must be a member of the default Administrator user group in
Control Center. You can import Windows user or group accounts, create new SQL Server logins, or
add existing SQL Server logins.

Importing Windows Users and User Groups into Control Center

You can import Windows users and user groups into the Control Center repository from the following
domains:

 Local system domain. You can import all the users and groups that are added in your local
system domain.
 Local domain. You can import users and groups from network domains that are available within
your local area network.

50 Managing Security for Control Center

  One-way trust domain. You can import users and groups from another domain with which your
domain has a one-way trust relationship.
To import user groups from the trusted domain, log in as the Administrator user of the trusted
domain.
You can import user groups from trusted domains in the same forest if the groups are either
global or universal.

Before you import a user group, ensure that all group members have access to SQL Server.

The import process adds the users to the SQL Server and gives the user or group the required
permissions in the Control Center repository. You do not need to manually grant permissions on the
SQL Server.

To import users or user groups into Control Center:

1 On the Global Tasks tab, click Manage Security, and then click the Users or User Groups tab.
2 Click Import, and then click Import again.
3 Click Locations, and then select the domain from which you want to import users or user groups.
4 Click Advanced, and then click Find Now.
5 Select the users or groups you want to add to Control Center, and then click OK.
You can select multiple users or groups.
6 Select the QDBs where you want to register the user or group, and then click OK.
This permits the users to manage the QDBs.

The Manage Security dialog box displays the user or group names along with their respective
domains, and the user type displays Windows User. For example, if you import User1 from domain A
and User2 from domain B, the Manage Security dialog box displays the user names as A\User1 and
B\User2.

NOTE: Windows users who have already logged in to Control Center with a particular set of
permissions can continue to perform all of their assigned activities even if you delete the user account
from the domain. Control Center denies access to such users only when they log out and try to log on
to the Control Center console again.

Adding or Creating SQL Users in Control Center

You can create new SQL Server logins or add existing SQL Server logins. If you enabled FIPs
compliant security in the Control Center console, you cannot create SQL Server logins using Security
Manager.

To create or add a SQL Server login:

1 On the Global Tasks tab, click Manage Security.

2 Click Users, and then click Create New.

Managing Security for Control Center 51

 3 Provide the following information:

Field Action

User Name Specify a new or existing SQL login name.

NOTE:
 You cannot specify login names with certain special characters,
including: \ / * ? : < > | “
 You can specify a case-sensitive user name in a case-sensitive SQL
Server environment.

Password Specify the password of the SQL user account. If the account does not
exist, it is created in the Control Center repository and is given public and
CC_public permission in the Control Center repository.

When you use the Control Center console to create a new SQL user
account:
 Ensure the login name for the user account is less than 29 characters
and the password is less than 32 characters. If the user name or
password is too long, it is truncated and you cannot log in to the
Control Center console.
 If the SQL Server is case-sensitive, do not create the same user name
with a different capitalization.
 If your database has a strong password policy, make sure the
password meets your policy.
 If you add an existing SQL user, specify the same password that the
SQL user uses to log in to the SQL Server.

Register users with the Select the QDBs you want the user to be able to manage. If you do not
selected repositories register a SQL login with a QDB when you first create the account, you
cannot register the account with a QDB later using the Control Center
console. You must use SQL Server Management Studio to give the SQL
login proper permissions for a QDB.

52 Managing Security for Control Center

3.2.6 Creating, Copying, Modifying, or Removing a User Group
You can create a Control Center user group that contains local or domain Windows user accounts or
SQL Server logins. You can create a user group and add SQL Server logins to the group and you can
import Windows users and groups. A user can belong to more than one user group.

You can create new user groups by copying an existing user group and modifying it. When you copy
a user group, all the members of the original user group are added to the duplicate user group. If you
copy a Windows user group, Control Center creates a new user group in Control Center but not in the
Active Directory. You cannot copy the Administrator user group.

You can modify an existing user group to add or remove users from the group or change the name or
description of the group. You can only change user groups you created in the Control Center console.
To modify user groups you imported from Windows, use administrative tools for Active Directory.

Removing a user group from the Control Center console prevents group members from logging in to
the console. However, the group still has Operator Console access on each QDB if you configured
this access. You cannot use the Control Center console to remove a Windows user group from the
Active Directory. If you are removing all members of a user group from the Control Center console,
NetIQ Corporation recommends deleting all members of the group before you delete the user group.

To create, copy, modify, or remove a user group:

1 On the Global Tasks tab, click Manage Security, and then click User Groups.
2 Complete the appropriate action:

To... Do this...

Create a user group 1. Click Create New, provide the required

information, and then click Add.
2. Select the users you want to add to the group, and
then click OK.

Copy or modify a user group 1. Select the desired user group, and then click
Copyor Modify.
2. Make your changes, and then click OK.

Remove a user group Select the user group you want to remove, and then
click Delete.

3.2.7 Creating, Copying, Modifying, or Removing a Permission

Set
You can associate user groups with permission sets when you create a management group and
define the security of the management group. You can also directly associate user groups with
permission sets as global permissions. For more information, see Section 3.2.8, “Setting Global
Permissions,” on page 54.

You can create new permission sets based on a copy of an existing permission set.

You can delete unused permission sets. If the permission set is associated with a management group
or with a user group as a set of global permissions, you cannot delete the permission set.

To create, copy, modify, or remove a permission set:

1 On the Global Tasks tab, click Manage Security, and then click Permission Sets.

Managing Security for Control Center 53

 2 In the Manage Security dialog box, click Permission Sets, and then click Create New.
3 Complete the appropriate action:

To... Do this...

Create a permission set Click Create New, provide the required information,
and then click OK.

Double-click ta permission to deny it. If you do not want

to grant or deny a permission, do not click it.

Copy or modify a permission set 1. Select the desired permission set, and then click
Make Copyor Modify.
2. Make your changes, and then click OK.

Remove a permission set Select the permision set you want to remove, and then
click Delete.

3.2.8 Setting Global Permissions

Global permissions are permission sets that apply to specific user groups for all management groups
in the Control Center console. For more information about global permissions, see “Understanding
Global Permissions” on page 49.

To create, modify, or remove a global permission set:

1 On the Global Tasks tab of the ribbon, click Manage Security.

2 In the Manage Security dialog box, click the Global permissions tab.
3 (Conditional) If you want to create or modify a global permission set:
3a Select the user group for which you want to assign a global permission set, and then click
Assign.
3b In the Assign Permissions dialog box, select a permission set from the Permission Set list,
and then click OK.
4 (Conditional) If you want to remove a global permission set, select the user group you want, and
then click Remove.
5 Click Close.

3.2.9 Granting and Removing Access to Management Groups

Control Center users must be given permission to access a management group. You must be a
member of the Control Center Administrator group to modify the members of a user group or modify
permission sets, but you do not have to be an administrator to assign user groups and permission
sets to management groups.

You can configure each management group to give one or more user groups permissions to objects
in the management group. The permission set that you associate with each user group determines
what the members of the user groups can do with objects in the assigned management group.

AppManager users may be members in more than one user group assigned to a management group.
If this is the case, the resulting set of permissions is based on combining all the applicable permission
sets with a logical OR to produce the most restrictive permissions. That is, if a permission is denied in
any permission set it is denied even if it is granted in another permission set. If a permission is neither
granted nor denied in all the permission sets, the permission is denied.

54 Managing Security for Control Center

 If you assign a user group and a permission set to a management group and that user group also has
a global permission set defined, the resultant set of permissions is also determined by combining the
permissions with a logical OR to produce the most restrictive permissions. For more information
about global permission sets, see “Understanding Global Permissions” on page 49.

You can only assign one permission set at a time to a user group for a management group. You can
assign the same user group to a management group more than once with different permission sets.
However, if you do this the resultant set of permissions for the members of the user group is the result
of a logical OR of all the permissions defined across all associated permission sets to produce the
most restrictive set of permissions.

You can organize management groups into a hierarchy, and permissions you assign to the top-level
management group in the hierarchy are inherited by the children of that top-level management group.
For more information about permission inheritance, see “Understanding Permission Inheritance” on
page 50.

To grant or remove access to a management group:

1 Right-click the management group in the Enterprise Layout pane and choose Management
Group Properties > Security.
2 (Conditional) If you want to grant access:
2a Click Add.
2b In the Assign Permissions dialog box, select a user group from the User Group list.
2c Select a permission set from the Permission Set list.

NOTE: You also have the option to modify an existing permission set by clicking Modify or
creating a new permission set by clicking Create New.

2d Click OK.
3 (Conditional) If you want to remove access, select the user group you want to remove, and then
click Remove.

If you want to change the permission set associated with a user group, you must first remove the user
group and then add it back with the permission set you want.

3.2.10 Understanding the Interaction Between Control Center

Console and Operator Console Security
Permissions in the Control Center console depend on user group, permission set, and management
group assignments in the Control Center console as well as role assignments in Security Manager. In
some instances, the permissions a Control Center console user has for a specific AppManager
repository are limited by the permissions granted to that same user by Security Manager, regardless
of the permissions they are granted in the Control Center console. The permissions granted a Control
Center console user apply on a repository by repository basis. If a Control Center console is
managing more than one AppManager repository, user permissions may need to be set for each
repository in Security Manager.

By default, when you add a user in the Control Center console and register the user with one or more
AppManager repositories, that user is granted Read Only permissions in Security Manager for each
repository. This is true for both Windows users and SQL login accounts. In most cases Read Only
permissions in Security Manager are adequate for any task a Control Center user might perform
other than those performed by Control Center administrators.

Managing Security for Control Center 55

 In some instances, you may need to configure permissions in Control Center that require more than
Read Only and less than full Administrator permissions in Security Manager. The following list
indicates tasks in Control Center that require more than Read Only permissions in Security Manager:

Check in Knowledge Scripts

To check Knowledge Scripts into an AppManager repository, a Control Center console user
requires the Check In a Knowledge Script functional right assigned to them in Security Manager
either through a custom role or by assigning the user to the Standard User role. This permission
only needs to be set on the primary AppManager repository. Knowledge Script synchronization
handles the replication of the new Knowledge Script to any secondary repositories.

Create Job
To create jobs on managed resources, a Control Center user requires the Check In a Knowledge
Script functional right on any AppManager repository where the user wants to create jobs.

Create a Knowledge Script Group

To create a Knowledge Script Group in Control Center, the user requires the Administrator role in
Security Manager on the primary AppManager repository.

Copy a Knowledge Script or Knowledge Script Group

To copy a Knowledge Script or a Knowledge Script Group in Control Center, the user requires
the Administrator role in Security Manager on the primary AppManager repository.

Modify a Knowledge Script Group

To modify a Knowledge Script Group, such as removing Knowledge Scripts from a group, the
user requires the Administrator role in Security Manager on the primary AppManager repository.

The restriction of permissions in the Control Center console based on an assigned role in the
Operator Console does not apply to any user added to the default AppManager Administrator group
in the Control Center console. Members of this group are granted the sysadmin role in SQL Server on
any AppManger repository managed by the Control Center console. The sysadmin role overrides any
limitations set by Operator Console roles on an AppManager repository. For more information about
the Administrator group in the Control Center console, see “Understanding the Administrator Group”
on page 48.

56 Managing Security for Control Center

4 Managing Jobs
4

This chapter provides information on managing AppManager jobs.

As the number of jobs increases, managing your environment becomes more challenging. This
chapter discusses ways to simplify job management. If you have not done so already, review the
Control Center User Guide for AppManager, available on the AppManager Documentation page
(http://www.netiq.com/documentation/appmanager), to familiarize yourself with the basic functionality
of AppManager.

4.1 Installing in a Lab Environment

NetIQ Corporation recommends initially installing AppManager in a lab environment. When you install
AppManager in a lab environment, focus on the following goals:

 Uncovering potential conflicts between AppManager and other applications, such as firewalls

For example, you might have special port requirements or restrictive account policies. If you
uncover problems, you can search the AppManager Knowledge Base on the NetIQ Web site for
information about resolving the problem, or contact Technical Support.
 Quantifying the resource usage requirements of AppManager components
This allows you to safely test your assumptions and verify that the computers where you intend
to install components during the actual deployment meet the requirements.
 Documenting network utilization between components
Even when deploying in a test environment, setting up a realistic sample of scripts and
distribution of components lets you assess your bandwidth and latency assumptions.
 Testing the distribution of AppManager agents to ensure you have reliable account information
and permissions (for example, usable passwords and domain account names)
 Estimating the time required to install components and resolve installation issues

4.2 Deploying to a Pilot Group

Beginning the process of monitoring your environment with a small, pilot group of computers helps
you determine the most critical components to monitor and the most likely source of problems before
you begin monitoring and managing on a large scale. This helps ensure a smooth implementation by
reducing the likelihood of creating too many events or leaving critical gaps in the systems and
applications you are monitoring.

Depending on your organization’s size, the importance of your monitoring needs, your deployment
team’s expertise, and the resources available to you, the pilot deployment might involve a small but
representative number of computers or all of the computers you intend to monitor. NetIQ Corporation
recommends installing on enough computers to get a realistic view of the full-scale deployment. The
pilot deployment should last from two to four weeks and reveal the following information:

 Problems that need immediate attention, such as computers that are low on disk space
 Environmental issues you need to address, such as insufficient privileges or instability
 How closely the computers you want to monitor conform to your expectations

Managing Jobs 57
 During the pilot deployment, focus on the following goals:

 Running the recommended core set of Knowledge Scripts on agent computers

For more information about working with Knowledge Scripts and jobs, see the Control Center
User Guide for AppManager, available on the AppManager Documentation page (http://
www.netiq.com/documentation/appmanager). For more information about the recommended
core set of Knowledge Scripts, see Section 4.3, “Implementing Core Monitoring Support,” on
page 58.
 Identifying and correcting problems with running the core set of jobs
For example, you might find problems with the required accounts and permissions.
 Gaining experience viewing and responding to events
For more information about how AppManager raises events and using the Control Center
console to view and respond to them, see the Control Center User Guide for AppManager,
available on the AppManager Documentation page (http://www.netiq.com/documentation/
appmanager).
 Identifying normal operating values and adjusting thresholds for your environment
For more information about identifying normal operating values, see Section 4.3.2, “Setting and
Adjusting Event Thresholds,” on page 60.

4.3 Implementing Core Monitoring Support

In planning an AppManager deployment, you should first identify a specific set of Knowledge Scripts
you want to run. Although the list is likely to change over time, your initial core set of Knowledge
Scripts should monitor basic server health and availability and your most important application
resources. At a minimum, for example, most organizations monitor CPU and memory usage, disk
space, disk I/O activity, network connections or activity, and the availability of specific computers or
specific processes.

In addition, many organizations monitor computer hardware components and application-specific

resources, such as mailbox size for messaging servers and database connections for database
servers.

TIP: The core set of Knowledge Scripts should consist of the Knowledge Scripts you want to run at
regular intervals for monitoring performance and availability. In general, you should identify a
relatively simple set of scripts to act as the core set. You can then extend the core set with additional
Knowledge Scripts to perform more detailed analysis, assist you in troubleshooting, or collect data for
reports.

In a typical environment, you run approximately 20 jobs on each agent computer at regular intervals
to ensure basic operational health and availability. You run additional jobs less frequently to diagnose
problems or take corrective action. Although running around 20 jobs is typical, the core set of
Knowledge Scripts you initially run might include fewer jobs.

58 Managing Jobs
 NetIQ Corporation recommends initially running a core set of Knowledge Scripts from the General
and NT Knowledge Script categories. The following table describes the recommended core set of
Knowledge Scripts. For more information about using these Knowledge Scripts and setting
parameters, see the AppManager Knowledge Script Reference Guide, available on the AppManager
Documentation page (http://www.netiq.com/documentation/appmanager).

Knowledge Script Description

General_EventLog Monitors and filters information in the Windows Event Log and allows you to
track log entries that match filtering criteria

Initially, NetIQ Corporation recommends monitoring all logs for error events.
You can further filter the log entries to include or exclude other criteria such
as specific IDs, descriptions, user names, or computer names.

General_MachineDown Detects whether the computer on which you run the script can communicate
with one or more specified Windows computers and raises an event if
communication attempts fail

NT_MemUtil Monitors physical and virtual memory and the paging files and raises an
event if a monitored metric exceeds the threshold

NT_DiskSpace Monitors logical drives for disk utilization, the amount of free space
available, and the percentage of disk growth

NT_CpuLoaded Monitors total CPU usage and queue length to determine whether the CPU
is overloaded and raises an event when both the total CPU usage and CPU
queue length exceed the thresholds

NT_LogicalDiskStats Monitors logical disk reads, writes, and transfers per second, disk operation
time, and queue length

NT_PhysicalDiskStats Monitors physical disk reads, writes, and transfers per second, disk
operation time, and queue length

NT_ServiceDown Monitors whether specified Microsoft Windows services are stopped or

started, and, optionally, starts any stopped service

NT_TrustRelationship Tests the domain trust relationship from the computer on which you run the
script to a specified domain and raises an event if a problem exists with the
domain trust

4.3.1 Collecting Data

To identify normal baseline operating values before you set thresholds for events, set all Knowledge
Scripts only to collect data (that is, not to raise events) and run reports for at least one week. From the
reports, you can review the high, low, and average values for core statistics. You can configure
several basic report Knowledge Scripts to create reports.

To create reports about your environment:

1 Install at least one report-enabled agent.

2 Run the Discovery_ReportAgent Knowledge Script on the report-enabled agent computer.
3 In the Report view, click through tabs in the Knowledge Script pane to select the reports to run.

At the end of the collection period, evaluate the information to determine a baseline for a normal
operating environment. After you complete your evaluation, remove the data you collected from the
QDB.

Managing Jobs 59
 When you are ready to raise events, set only those Knowledge Scripts that address critical issues in
your environment to raise events, and set the remaining Knowledge Scripts to collect data. You can
employ this approach enterprise-wide or only on the computers you identify as needing immediate
attention. To help you tune your system later, track the frequency of events and the number of data
points collected.

Based on the data you collect, you can adjust thresholds to more accurately reflect your
environment’s specific characteristics. If you see too many events, the thresholds might be too low for
your environment, the intervals might be too short, or you might need to address critical resource
issues.

Basic AppManager reporting provides detailed information about the computers in a single
management site. When you expand your deployment to multiple management sites with multiple
QDBs, you might want the more sophisticated reporting available with NetIQ Analysis Center.

4.3.2 Setting and Adjusting Event Thresholds

Once you have identified a core set of Knowledge Scripts and baseline operating values for
monitoring basic computer resources, such as CPU, memory, and disk, and critical application
resources, create a Knowledge Script Group from those Knowledge Scripts and run them on a pilot
group of computers.

The servers in your pilot group should have similar configurations and be similarly loaded. For
example, you may want to set different event thresholds for servers that perform transactional
operations than for servers that perform batch operations, so you would organize transactional and
batch servers into separate management groups or views.

With a group of similarly configured and loaded servers, you should run the core set of Knowledge
Scripts to raise events only for critical issues in your environment. You can use the default threshold
values or your own estimation for initial threshold settings based on the results of your initial data
collection.

TIP: Using a monitoring policy may simplify event threshold configuration. With a monitoring policy,
the jobs are started automatically, changes to Knowledge Script group member properties are
automatically propagated to policy-based jobs, and when you remove the policy, the jobs are
automatically stopped and deleted.

The process of establishing effective event thresholds includes several basic steps. By following
these steps with a pilot group of servers, you establish threshold values you can use through the rest
of your enterprise:

 Identify a group of servers that have a similar configuration.

 Identify the event conditions most relevant to you for those servers.
 Identify the Knowledge Scripts you want to run to monitor the event conditions you identified.
 Run monitoring jobs and make adjustments to the event conditions and event thresholds as
needed. The goal is to set event thresholds you believe to be accurate for the servers and
applications most critical to your business.

The purpose of running a core set of jobs on a pilot group of computers is to reveal:

 Serious problems that need immediate attention—for example, computers that are dangerously
low on disk space or that have high CPU usage

60 Managing Jobs
  Any environmental issues you need to address—for example, problems with insufficient account
privileges, network instability, or the availability of SNMP or other services that need to be
installed
 Threshold levels and job properties that are appropriate to your specific environment and which
you can standardize, either across your entire organization or across specific departmental or
functional group

If you are seeing too many events, the thresholds may be set too low for your environment, or the
interval for running the job may be too short. Events should not be raised unless something has
happened that merits a response. Responses include acknowledging the event, running another
Knowledge Script to remotely diagnose the problem, or diagnosing the system in person.

Deploying a core set of Knowledge Scripts also prevents your staff from being overwhelmed by a
sudden barrage of events. By focusing on a limited number of key Knowledge Scripts and the most
critical problems you need to address early in the deployment, you can develop an understanding of
the events generated, implement a methodology for responding to those events, and effectively
troubleshoot any issues that arise.

In your initial deployment, therefore, the core Knowledge Scripts should not perform responsive
actions when events are raised. Avoiding actions in the earliest stages of deployment prevents an
unnecessary surge of e-mail or pager messages being sent for events caused by thresholds that
have been set too high or too low. Once you have determined appropriate thresholds for your
environment, you can test responsive actions and choose an appropriate notification method, such as
MAPI mail, SMTP mail, or a paging system.

4.3.3 Establishing a Manageable Level of Event Activity

If you are receiving too many events, you might need do some or all of the following:

 Adjust thresholds. Whether they need to be higher or lower depends on your environment, on
your reasons for monitoring a particular computer, and on how particular computers are being
used. For example, when monitoring the computers in a lab to determine when you are nearing
capacity, you might set thresholds lower than when monitoring users desktop computers or
computers that store archived information that rarely changes.
 Change the job schedule (increase or decrease the monitoring interval).
 Change the number of consecutive times that a condition must be detected before an event is
raised. For more information, see “Adjusting Consecutive Intervals” on page 77.
 Modify the computer configuration to bring non-conforming computers in line with the benchmark
settings or manage the non-conforming servers using another management group.

4.3.4 Developing a Data Collection Strategy

Once you are monitoring for events on your core systems and applications, you are ready to collect
data for charts and reports. When considering your reporting needs, determine the following
information:

 Standard AppManager reports to generate and the Knowledge Scripts required to generate
those reports
 Who should receive the reports and how frequently
 Whether to generate reports automatically on a scheduled basis or manually on demand
 Who will generate reports

Managing Jobs 61
 For example, you might want to restrict access to the Report view or assign Exchange reports to
an Exchange administrator and SQL Server reports to your DBA group.
 Whether to format reports in table format, in charts, or both
 Whether to deliver reports through e-mail, a Web site, or the Report Viewer

The following table describes report Knowledge Scripts that NetIQ Corporation recommends running
to generate standard reports. For more information about using these Knowledge Scripts and setting
parameters, see the AppManager Knowledge Script Reference Guide, available on the AppManager
Documentation page (http://www.netiq.com/documentation/appmanager).

Knowledge Script Description

ReportAM_EventSummary Summarizes events per computer

ReportAM_SystemUpTime Details the uptime and downtime of monitored computers

ReportAM_CompDeploy Details the number of instances of each AppManager component

installed on computers in an AppManager site

ReportAM_WatchList Details the top or bottom n computers (by number or percent)

generating the selected data streams

NT_Report_CPULoadSummary Summarizes CPU usage and queue length for selected computers

NT_Report_LogicalDiskUsageSummary Summarizes the percentage of disk space used and the amount of
free space (in MB) for selected computers

When collecting data, you should familiarize yourself with how AppManager collects data for charts
and reports. You should set repository preferences and job properties so that you only collect and
maintain the data you need. Storing additional data can quickly consume repository resources and
negatively impact performance. For more information, see “Managing Data” on page 85 and
“Managing a QDB” on page 89.

If you need to report on more than three months’ worth of data, consider using AppManager Analysis
Center. The aggregate reporting capabilities available with Analysis Center are powerful and can
avoid the performance problems potentially associated with storing large amounts of AppManager
data for reports.

4.4 Expanding the Scope of Your Deployment

When you feel comfortable with the core set of Knowledge Scripts and your environment’s stability,
consider expanding your deployment. During the expansion stage, focus on the following goals:

 Deploying AppManager to additional computers

Large or widely distributed organizations typically phase in a full AppManager deployment over a
period of several weeks or even months. For example, if your organization is going to monitor a
group of computers in the United States, Germany, and Spain, you might decide to deploy
AppManager first in Germany, stabilize the environment there, and then expand the deployment
to include computers in Spain and the United States. Or you might decide to expand the
deployment to include the computers in Spain, allow time to uncover problems and stabilize that
environment, and deploy to the computers in the United States later.
 Running additional Knowledge Scripts beyond the core set
For more information about additional recommended Knowledge Scripts, see Section 4.4.1,
“Running Additional Knowledge Scripts,” on page 63.

62 Managing Jobs
  Adding responsive and corrective actions to Knowledge Scripts
AppManager Knowledge Scripts can automatically take corrective actions, notify selected
people in response to certain events, and acknowledge events. To take advantage of Knowledge
Script automation capabilities, you might need to install additional components, such as an agent
that can send email responses to events. For more information about enabling agents to send
email responses to events, see the Installation Guide for AppManager, available on the
AppManager Documentation page (http://www.netiq.com/documentation/appmanager). For
more information about responsive and corrective actions, see the Control Center User Guide
for AppManager.

4.4.1 Running Additional Knowledge Scripts

During the expansion stage, add Knowledge Scripts beyond the core set. The following table
describes Knowledge Scripts that NetIQ Corporation recommends adding. For more information
about using these Knowledge Scripts and setting parameters, see the AppManager Knowledge Script
Reference Guide, available on the AppManager Documentation page (http://www.netiq.com/
documentation/appmanager).

Knowledge Script Description

General_AsciiLog Monitors one or more ASCII text files for specific strings and messages

General_Counter Monitors any System Monitor counter

NT_NetworkBusy Monitors the traffic on network interface cards (NICs) and raises an
event if the bandwidth utilization of the network interface exceeds the
threshold

NT_PagingHigh Monitors reads and writes per second to the pagefile and raises an
event if the number of reads and writes per second exceeds the
threshold

NT_PrinterHealth Monitors printer health and raises an event if the printer is paused, the
queue length exceeds the threshold, or there is some other error such
as a jammed printer

NT_PrinterQueue Monitors printer queue length and raises an event if the number of
queued jobs exceeds the threshold

NT_RunAwayProcesses Detects runaway processes on the specified computer based on

sustained high CPU usage and raises an event if a process exceeds
the CPU usage threshold

NT_SystemUpTime Monitors the number of hours a computer has been operational since it
was last rebooted and raises an event if the computer was rebooted
within the monitoring interval

Once you select a set of Knowledge Scripts for monitoring basic server health and key application
resources, you can plan for and implement policy-based monitoring. For information about
implementing monitoring policies, see the Control Center User Guide for AppManager, available on
the AppManager Documentation page (http://www.netiq.com/documentation/appmanager).

Managing Jobs 63
 4.5 Strategies for Managing Systems and
Applications
Once you have established your core monitoring needs and identified appropriate monitoring
thresholds, you are ready to manage these systems and applications on a daily basis. Depending on
how and where you deploy your core Knowledge Scripts, you may be able to better manage the
resulting jobs now and in the future.

AppManager simplifies the management of your Windows, UNIX, and Linux systems by automatically
managing similarly configured and loaded systems and applications. When the servers in a group are
similarly configured and loaded, they are conformant. By organizing the systems and applications in
your environment into groups of conformant servers, you can easily monitor for event conditions and
collect data on those servers using a standard set of Knowledge Scripts.

Ideally, implement core monitoring using monitoring policies, with ad hoc jobs used only to diagnose
problems detected by these policies. A simple strategy for managing your environment with
AppManager is to:

 Identify the critical systems and applications in your environment and configure jobs that raise an
event if something goes wrong with those systems.
 Organize your critical systems and applications so that you can effectively manage them on a
daily basis.
 Configure jobs to collect data for historical reporting and trend analysis.
 Manage additional systems and applications by organizing conformant systems and applications
under existing monitoring policies.
 Remotely diagnose problems on your policy- systems and applications by running additional
jobs.

4.5.1 Managing Systems and Applications with the Control

Center Console
The Control Center console uses management groups to organize managed computers and
discovered resources. The console has a default Master management group that includes all
managed computers and discovered resources in all QDBs you are managing with the Control Center
console.

You can create additional management groups and determine membership in the management group
in several different ways:

 Ad Hoc membership. Membership is determined by including specific managed computers. This

is similar to a server group in the Operator Console.
 Repository View. Membership is determined by discovered resources on the managed
computer, such as IIS or SQL. This is similar to a standard view in the Operator Console. You
can also define membership based on the Master repository view, which includes all managed
computers and resources.
 Server Group. Membership is determined by membership in an Operator Console server group.
You cannot create server groups in the Control Center console.
 Rule. Membership is determined by one or more rules. Rules evaluate a managed computer and
its discovered resources and either include or exclude the managed computer based on the
criteria defined in the rule.

64 Managing Jobs
You can combine all of these methods to determine membership in a given management group. For
more information about management groups, see the Control Center User Guide for AppManager,
available on the AppManager Documentation page (http://www.netiq.com/documentation/
appmanager).

The following sections outline how you can use the Control Center console to successfully monitor
the systems and applications in your environment.

Managing Systems in the Master Management Group

The Master management group is a default group that displays all managed computers and
discovered resources in all QDBs managed by the Control Center console. You can use the Master
view to discover and monitor all of the resources on a server, including the operating system,
hardware, and application resources. Depending on your environment, you may not want to allow
your operations staff to have access to the Master management group.

Since the Master management group includes all the managed computers in your environment, it is
not recommended that you apply any monitoring policies to this group. Doing so could adversely
affect the performance of AppManager and your ability to manage the resources in your environment.
You should also exercise caution in running any ad hoc jobs in the Master management group since
this will create jobs on every agent computer.

Managing Systems in a Management Group Based on an Ad Hoc

List
A management group can include computers that you identify specifically for inclusion in the
management group. This allows you to create a static set of computers that you want to manage as a
group. You can include any managed computer. Unlike rule-based management groups, any
computer you add to the ad hoc list will remain as a member until you remove it from the list.

Managing Systems in a Management Group Based on a Repository

View
Management groups based on a repository view allow you to view and manage only the resources
that correspond to a particular resource type. For example, the SQL view only displays SQL
resources and SQL-related Knowledge Scripts. To run Knowledge Scripts on NT resources, such as
ASYNC and NTAdmin Knowledge Scripts, you must use another view. You can include more than
one repository view in a management group.

You may find it advantageous to implement a monitoring policy on a repository view when you want to
automatically monitor a particular system or application as it is discovered. For example, a monitoring
policy on the SQL view ensures that as SQL Servers are discovered, they are managed.

If you create a management group based on the Master repository view, the management group
includes all managed computers and discovered resources just as the default Master management
group does.

Managing Systems in a Management Group Based on a Server

Group
Management groups based on an Operator Console server group include only those computers that
are members of the server group. This allows you to take advantage of any server groups you have
already established in the Operator Console for use in the Control Center console.

Managing Jobs 65
 Managing Systems in a Rule-based Management Group
A rule-based management group allows you to discover and monitor servers that match a specific set
of criteria. Unlike other management groups, rule-based management groups uses rules to
dynamically update membership in the management group.

A rule-based management group provides the flexibility to select conforming systems and
applications as well as logically group systems using custom properties. Rule-based groups work well
when you have less information about the system that is being managed and you need to rely on the
rules to select the correct system or you do not want to give access to the Master view.

Rule-based groups are particularly useful when you want to:

 Organize a subset of servers into a group that can be managed by your operations staff. For
example, if you configure a rule-based management group that selects a custom property value,
you can easily control the servers that can be managed by your operations staff.
 Automatically monitor conforming systems and applications. For example, you can configure a
rule-based management group to automatically select similarly configured and loaded systems,
and automatically monitor those systems by policy.
 Implement group-based reporting. For example, you can use a management group to select
similarly configured systems and run a report on the servers in that group.

4.6 Managing Existing Jobs

Once you have implemented your core Knowledge Scripts and have established a data-collection
strategy, you might need to manage existing jobs by adjusting job properties, adding new servers, or
expanding your core set of Knowledge Scripts.

When adding new systems to your environment, plan to run your core Knowledge Scripts to validate
event thresholds before including them in a monitoring policy.

4.6.1 Changing Job Properties

After you implement your core Knowledge Scripts for monitoring and data collection, the job
properties might need adjustment. Changes are propagated automatically to policy-based jobs. For
one-time jobs or those not associated with a monitoring policy, you must manually propagate
changes to job properties.

When manually propagating job properties, make sure the Knowledge Script is configured with the
same action as the running job, if applicable. For more information about manually propagating job
properties, see the Control Center User Guide for AppManager, available on the AppManager
Documentation page (http://www.netiq.com/documentation/appmanager).

If you want to monitor additional systems or applications with a one-time job, manually add the
additional server(s) to the existing parent job by right-clicking the parent job, clicking Add Child Jobs,
and selecting the objects you want to monitor. (A monitoring policy does this for you automatically.)

In the Operator Console, when working with different views that display policy objects, it can be
difficult to identify the view where a monitoring policy was created or the Knowledge Script Groups
that compose the monitoring policy. In the Extended Support section of the NetIQ Technical Support

66 Managing Jobs
 Web site, the AppManager Knowledge Depot features an Operator Console plug-in and a report that
provide information about all existing monitoring policies, such as the view where the policy was
created and the Knowledge Script Group members:

 The Operator Console plug-in, MonitorPolicies.vbs, adds two Extensions menu commands
to display monitoring policy information in a dialog box or write the information to a text file.
 The ReportAM_PolicyInfo Report Knowledge Script creates a report about monitoring policies
with hypertext links to the parameter values of each Knowledge Script Group member.

Use your myNetIQ Account Login to access the Knowledge Depot at http://www.netiq.com/
support/am/extended/knowledgedepot/default.asp.

In the Control Center console, it is easier to identify the monitoring policies that apply to a
management group and the Knowledge Script Groups that the monitoring policies are based on. In
the Enterprise Layout pane, right-click a management group and click Management Group
Properties > Policies. The Policies tab of the Management Group Properties dialog box lists any
Knowledge Script Groups assigned to the management group as a monitoring policy.

4.6.2 Checking Job Status with the JobInfo Report

The JobInfo report is useful for finding out when jobs are stopped, pending, or errored out. NetIQ
Corporation recommends scheduling this report job to run in the morning and to email the report to
your team for review.

When responding to:

 Stopped jobs, restart them if necessary.

 Pending jobs, run NetIQCtrl on the agent computer to verify that the job status is Pending. If the
job is Pending on the agent computer, delete the job, or in the case of a policy-based job, stop
and delete the job by removing the server from the monitoring policy.
 Errored jobs, look at the error message and take an appropriate action.
You can configure the number of times to restart errored jobs within the Properties dialog box of
the monitoring policy or as a repository preference.

For more information about viewing and responding to job results, see the Control Center User Guide
for AppManager, available on the AppManager Documentation page (http://www.netiq.com/
documentation/appmanager).

Managing Jobs 67
 4.7 Suspending AppManager Monitoring
In many environments, you might need to perform unscheduled maintenance on a computer. For
example, an organization might have an Apache Web server that must be shut down immediately. In
this case, you can temporarily block all jobs, events, and data for a particular computer, including jobs
that remotely monitor a computer, by placing the computer in machine maintenance mode.

Maintenance option How it works

Machine maintenance  Administrator manually enables and disables machine maintenance on a

Windows or UNIX agent.
 Machine maintenance blocks all monitoring jobs for a computer, including jobs
that remotely monitor the computer.
 Machine maintenance does not require the agent to be running to enable or
disable maintenance mode.
 Machine maintenance does not block AMAdmin jobs, for example, the
AMAdmin_DBHealth Knowledge Script.

Scheduled  Schedule a maintenance period on a Windows agent using the

maintenance AMAdmin_SchedMaint Knowledge Script. On a UNIX agent, use the
AMAdminUNIX_SchedMaint Knowledge Script.
 Requires the agent to be running to configure, start, and stop maintenance for
the specified period.
 Blocks a particular Knowledge Script category or all Knowledge Scripts
monitoring the computer, including jobs that remotely monitor the computer.

If you intend to shut down a computer that is managed by AppManager, it is always a good idea to
enable machine maintenance before you shut the computer down. In some cases, as the computer is
shutting down, a monitoring job might error out because the resource that the job monitors is not
available.

You must manually enable and disable machine maintenance on the computer. The only exception is
when you enable maintenance on a computer and replace it with a clone. Because the clone does not
have any information about its machine maintenance status, when the computer is brought online
and communicates with the management server, after about 5 minutes, the management server will
automatically disable machine maintenance on the computer. Alternatively, you can manually remove
the machine maintenance from the clone computer.

To enable machine maintenance on a computer, in a Servers view, select a computer and then in the
Tasks pane click Maintenance Mode Tasks > Enter Maintenance Mode. The status of the
Maintenance column changes to indicate the computer is In Maintenance.

To disable machine maintenance and resume all monitoring jobs, in the view pane select the server
you want, and then in the Tasks pane click Maintenance Mode Tasks - Exit Maintenance Mode.

If a managed computer is in maintenance mode, a deployment task configured to run on the

computer will run at its scheduled time. Enabling maintenance mode on a managed computer does
not prevent the deployment task from running. However, updated discovery information for
installation packages will not appear in the Control Center console until after you disable
maintenance mode.

You cannot use ad hoc maintenance to turn off scheduled maintenance. Therefore, it is good
practice to avoid using both at the same time.

68 Managing Jobs
4.7.1 Suspending Remote Monitoring Knowledge Scripts
Knowledge Scripts that remotely monitor a server, such as the NT_RemoteServiceDown Knowledge
Script, continue to monitor a remote server that is in maintenance mode. However, if an event
condition is detected while a remote server is in maintenance mode, it is not displayed in the Operator
Console or Control Center console. Also, if the remote Knowledge Script is configured to run a
responsive action on the management server, the action is suppressed.

Do not configure a Knowledge Script to run a responsive action on the remote computer. If an event
condition is detected, no event will appear in the Operator Console or Control Center console, but the
action will run.

4.7.2 Resource Dependencies and Job Schedules

In certain situations, it’s a good idea to control job scheduling by setting a resource dependency. For
example, if regularly scheduled maintenance periods aren’t reliable or are hard to anticipate, you may
want to specify that jobs only run when required file-system related resources or specific services are
available. Setting a resource dependency is especially useful when running Knowledge Scripts on
MSCS (clustered) resource objects to avoid duplicated events and data.

You can use the AMAdmin_SetResDependency Knowledge Script to specify resources and services
that must be active and available for the jobs to run. If any resource or service is not available, the
jobs are suspended until the specified resource or service becomes available.

For example, if you’re monitoring Exchange Server, you may want to check that the MSExchangeDS,
MSExchangeIS, and MSExchangeSA services are running before running Exchange jobs. Even if you
have established a maintenance period and the maintenance period has expired, if these services
are not running, the Exchange jobs are prevented from restarting if those services are offline. For
more information, see the online Help for the AMAdmin_SchedMaint or
AMAdmin_SetResDependency Knowledge Scripts.

4.8 Reviewing and Refining the Deployment

Once basic monitoring is underway, it becomes easier to fine-tune thresholds and job intervals,
articulate and automate event-response policies, and tailor event notification, data collection, and the
user interface to suit your needs. As you refine your deployment, focus on the following goals:

 Managing events and event notification

For more information about developing and refining your policies for handling events, see the
chapter “Managing Events” on page 71.
 Handling data collection
For more information about developing and refining your data handling policies, see the chapter
“Managing Data” on page 85.
 Controlling communication between agent computers and management servers
For more information about communication between agent computers and management
servers, see the chapter “Site Communication and Security” on page 31.
 Managing security and security roles within AppManager
For more information about controlling access to tasks and configuring security settings, see the
chapter “Managing Security for Control Center” on page 45.
 Adding management servers and configuring primary and secondary management servers for
agent computers

Managing Jobs 69
 For more information about setting up primary and backup management servers, see
“Configuring a Primary and Secondary Management Server for Agent Computers” on page 42.
 Organizing the computers in your network into meaningful groups
For more information about using management groups to manage a group of computers, see the
Control Center User Guide for AppManager, available on the AppManager Documentation page
(http://www.netiq.com/documentation/appmanager).
 Identifying and establishing Knowledge Script Groups and monitoring policies for the computers
in your environment
NetIQ Corporation recommends implementing policy-based monitoring in a test environment
before you implement it in your production environment. For more information about initiating
policy-based monitoring, see the Control Center User Guide for AppManager.

70 Managing Jobs
5 Managing Events
5

Before you deploy AppManager across your enterprise, you need to develop and refine your policies
for handling events. For example, you may want certain events to trigger automated responses, such
as corrective actions or notifications. This chapter addresses the impact of event notification,
strategies for managing events, and the options you should consider when you run Knowledge
Scripts that raise events or perform actions.

In determining how you want to handle events in your organization, you need to consider your internal
procedures, departmental structure, and management goals. You also need to understand how your
event-handling policies relate to AppManager user preferences and the amount of attention you’ll
need to devote to database management.

5.1 Deciding When to Raise Events

Some AppManager events are required for monitoring server health and availability and important
application resources. But if you generate too many events, you risk overwhelming your staff, who
might then ignore or overlook critical events.

Typically, you generate events when you want to find out what is wrong with the computers on your
network and to quickly locate current and potential problems. You might also raise events for visibility
and tracking. Some events let you know that a situation occurred and you intend to address it, either
by acknowledging the event, running another Knowledge Script to remotely diagnose the problem, or
diagnosing the system in person.

Always have a clearly defined purpose when generating events. For example, you may decide to
raise events only for critical issues in your environment that need immediate attention, such as
computers that are dangerously low on disk space or that have dangerously high CPU usage. If you
are unsure of what to expect in your current environment, collect data for a period of time without
raising events to determine a reasonable baseline for the computers you monitor. Once you have a
better understanding of your environment, you can modify threshold settings and begin monitoring
less critical event conditions, servers, and applications. Having a clear purpose and understanding
the impact of the events you are generating helps you make informed decisions about when and how
to generate and display events and can also help prevent your staff from being besieged by a sudden
barrage of events.

Therefore, the first step in defining event-handling policies is to make a list of the specific types of
events you need and your core Knowledge Scripts for monitoring basic computer resources. For
example, most organizations begin by monitoring CPU, memory usage, disk space, disk I/O activity,
network connections or activity, and the availability of specific computers or processes. In addition,
many organizations monitor computer hardware components and application-specific resources,
such as mailbox size for messaging servers and database connections for database servers.
Although your list is likely to change over time, identifying a few specific Knowledge Scripts early on
can help you avoid generating more events than you need.

Once you understand the type of events that require you to be notified, you can identify the
Knowledge Scripts to raise the relevant events and create jobs to display those events.

Managing Events 71
 5.2 Understanding Events and Event Messages
When you run a Knowledge Script that generates events, each time the Knowledge Script runs and
detects that a threshold has been crossed or a process is down it generates a parent and child event
and detailed information about the event and stores the information in the AppManager repository.
Once the information is stored in the repository, you can:

 View event alerts in the Enterprise Layout view of the Navigation pane in the Control Center
console.
 View parent and child events in Events views in the Control Center console.
 View detailed information for events in the Event Properties dialog box.

For more information about viewing and working with events, see the Control Center User Guide for
AppManager, available on the AppManager Documentation page (http://www.netiq.com/
documentation/appmanager).

5.2.1 Event Collapsing and Duplicate Events

When you run a Knowledge Script and enable events, AppManager creates both a parent and child
event for the first occurrence of the event condition. For subsequent occurrences, AppManager
creates additional child events under the parent event and updates an event counter indicating the
number of child events. AppManager can detect unique and duplicate child events. An event is
considered a duplicate when it occurs with the same object name, event message, severity, and job
ID as a previous event within a certain period of time.

Although duplicate events are typically valid, receiving multiple events caused by the same condition
is not useful. For example, if you are monitoring a disk every 10 seconds and at 18:00 the disk
crosses the threshold you specify, AppManager can generate a new event every 10 seconds. In
addition, if you associated an e-mail action with this job, AppManager can send an e-mail message
every 10 seconds containing the same information.

By default, AppManager reduces the number of individual events (and actions) you receive by
collapsing duplicate events into a single event and incrementing the event counter. In this way,
AppManager reduces the “noise” from a recurring or persistent issue. You are still informed that the
event occurred multiple times, but you are not overwhelmed with event messages or redundant e-
mail messages.

AppManager uses a time limit for collapsing these duplicate events. For example, if an event occurs
at 18:00, by default, 20 minutes must elapse in which the condition does not recur before a new event
is generated. If an event occurs every 10 seconds, a new event is never displayed; AppManager
simply increments the event count. If the event occurs at 18:00 and the time frame is 18:20, when the
event occurs again at 18:00:10 the time frame is adjusted to 18:20:10. When the event occurs again
at 18:01 the time frame is adjusted to 18:21, and so on.

For an individual job, you can adjust the time interval by selecting Initial occurrence in the Advanced
tab in the Knowledge Script Properties dialog box. Or you can change the default behavior by setting
the Advanced Properties repository preference. Use this preference if your monitoring is critical and
you want to receive events and actions on a regular basis until the problem has been resolved. For
example, if the event occurs at 18:00 and then again at 18:01, you receive one event showing an
event count of 2. Then, if the event occurs again at 18:20, you receive a new event (and action). By
default, you would have waited until 18:21 for the new event.

NOTE: If you acknowledge or close an event and the condition recurs, a new event is generated.
Event collapsing only occurs while the original event is open.

72 Managing Events
5.3 Setting Preferences for Event Information
AppManager performance and availability information cannot remain available indefinitely. In
addition, displaying too much information in the Operator Console can impede system performance.
AppManager repository preferences therefore can help you determine how long to keep event
information and set options for archiving events. In addition to repository preferences, you can also
set event-handling properties for jobs. For more information about configuring job event settings, see
Section 5.5, “Using Advanced Event-handling Properties,” on page 76.

To help consolidate events and simplify the information displayed in the Operator Console, by default,
AppManager collapses duplicate events (events with the same object name, event message,
severity, job ID) into a single event. For example, after an event is raised instead of creating new child
event entries, duplicate events, associated with the same computer, job, and event condition, are
collapsed into the original child event and the child event count is increased.

AppManager collapses duplicate events within a specified time interval (20 minutes by default). You
can configure this time interval to begin:

 When the first event is raised. All duplicate events within the time interval (static period of time)
are collapsed into one event.
 Each time an event is generated (it is not a static period of time). For example, using the default
time of 20 minutes, if a job generates duplicate events every 5 minutes, the 20 minute interval is
restarted every 5 minutes, meaning it never effectively expires — unless you set an option for
AppManager to ignore events.

After the original child event is closed, or after the event collapsing time interval expires, a new child
event is created if the event condition is detected.

In addition, when event collapsing is enabled and a duplicate event is raised for an event you
previously acknowledged, by default AppManager changes the status of the acknowledged event to
open and increments the event counter. In most cases, this default behavior is appropriate, giving you
visibility that even though an event has been acknowledged by an operator it hasn’t been closed and
the case should be re-opened to resolve the problem. In some cases, however, you may want to
leave an acknowledged event in the acknowledged state to indicate someone has responded to the
problem but still be notified that the event condition has extended beyond the event collapsing
interval. You can choose one of the following AppManager preferences to control this behavior:

 If you want to see a new open child event when the event condition persists beyond the event
collapsing window for an acknowledged event, use the Create a new child event for
acknowledged event during event collapsing preference.
 If you want to increment the child event count only when the event condition persists beyond the
event collapsing window for an acknowledged event, leaving the status of the acknowledge
event unchanged, use the Increment the event count only without changing status event
during event collapsing preference.
 You can change the way AppManager displays event information for duplicate events that are
raised (and collapsed) after you acknowledge an event.

NOTE: These options are not available in the Control Center console, though how you set these
options in the Operator Console also affect how the Control Center console displays event data.

To change the handling of duplicate events when event collapsing is enabled:

1 Click File > Preferences in the Operator Console.

2 Click the Repository tab, then click Event in the Event options group.

Managing Events 73
 3 Click the event handling preference you want to use.
 Click Create a new child event for acknowledged event during event collapsing if you want
AppManager to create a new child event and sets the status of the event to open.
 Click Increment the event count only without changing status event during event
collapsing if you want to leave the status of an event as acknowledged but also to
increment the event count to indicate there has been a new occurrence of the event.

By default, AppManager keeps event information available for display in the TreeView pane, Events
tab, and Message tab indefinitely. Over time, events can accumulate in the Operator Console, which
can affect the performance of the Operator Console, or they can become out-of-sync with your jobs.
For example, if you delete jobs but not their associated events, your Events list will include events for
which no job information is available. While this may not be a problem if you manage a small number
of jobs and events, it can become a problem when the number of jobs and events increases.
Managing the list of events and identifying useful and relevant events can become increasingly
difficult.

To prevent this situation, in most cases you should plan to remove events when you delete the
associated jobs. AppManager provides a repository preference to help you manage event information
for deleted jobs.

NOTE: This option is not available in the Control Center console, though how you set this option in
the Operator Console also determines whether or not events are deleted when deleting jobs in the
Control Center console.

To delete all event information when a job is deleted in the Operator Console:

1 Click File > Preferences in the Operator Console.

2 Click the Repository tab, then click Event in the Event options group.
3 Click Remove associated events when jobs are deleted.
When you delete a job in the Operator Console, AppManager removes the associated event
information from the AppManager repository. However, if you archive events, this information is
still available in the event archive tables in the repository.

NOTE: If you do not remove events when jobs are deleted, you should periodically remove
events from the repository manually. If you do not remove them, these “orphan” events without
jobs associated with them will consume database resources and may impact performance. For
information about removing events from the repository, see “Removing Events” on page 101.

4 Click OK
in the Preference - Event Options dialog box, then click OK in the Preferences dialog box.

74 Managing Events
5.3.1 Acknowledging and Closing Events
To respond to an open event and turn off the event alert, you need to either acknowledge or close the
event. How you respond to an event and use the Acknowledge or Closed status depends on your
system management policies. For example, you might immediately acknowledge the event, check the
server, and try to solve the problem, or you might acknowledge the event and run other Knowledge
Scripts to collect data or to further diagnose the problem.

Acknowledging the event turns off the event alert and changes the status of the event in the Events
tab to “Ack.” When you have resolved the problem that caused an event, you can then close the
event. You do not need to acknowledge an event before closing it. However, to prevent accidental
deletion of open or unresolved events, you must close an event before you can delete it.

To acknowledge or close events, you can:

 Individually acknowledge or close child events in the Events tab (or acknowledge or close all
child events at once by acknowledging or closing a parent event).
 Acknowledge or close all events associated with an application server, a group of servers, or all
servers in a view in the TreeView pane.
 Individually acknowledge or close an event after viewing detailed information in the Message tab
in the Event Properties dialog box.

AppManager also provides a repository preference to automatically close events based on their
severity level. This preference can be useful when:

 You want to save historic information about an informational or diagnostic event but do not want
to manage event status.
 You want to know that an event occurred, but you don’t need to address the issue right away.
You would therefore would like to automatically close, but not delete, the event.

For example, if you are raising an event when a condition no longer exists and you receive an
informational event indicating that the condition ended, you may want to automatically dismiss (close
but not delete) this type of event.

NOTE: This option is not available in the Control Center console, though how you set this option in
the Operator Console also determines whether or not events with a specified severity are closed in
the Control Center console.

To automatically close events:

1 Click File > Preferences in the Operator Console.

2 Click the Repository tab, then click Event in the Event options group.
3 Click Automatically close event when severity is greater than N.

NOTE: Use caution when setting this preference. Depending on the value you set for this
preference, you can accidentally acknowledge and close other events. NetIQ Corporation
recommends setting a unique severity level for this preference (for example, a special value you
do not typically use, such as 40) and if you have other Knowledge Scripts using this severity
level, set their event severity level to another value, such as 39.

4 Click OK
in the Preference - Event Options dialog box, then click OK in the Preferences dialog box.

Managing Events 75
 5.4 Understanding Event Archiving
By default, AppManager keeps event information available for display indefinitely and stores the
event information in the AppManager repository in event and event archive tables. Because this
information can accumulate over time and put a strain on your resources, you should manage the
archiving, purging, and removing of events carefully. For example, moving old events to event archive
tables when events are closed or have been kept for a specified amount of time can help keep the
consoles clear of unimportant information and save you time by dealing with these less severe events
automatically.

QDB preferences in the Operator Console let you change the default period for keeping events
available in the consoles and automate your event handling.

To change the setting for keeping event information:

1 Click File > Preferences in the Operator Console.

2 Click the Repository tab, then click Event in the Event options group.
3 Check Move aged events to archive tables in repository when.
4 Select an option to archive events based on status, severity, or a period of time. You can choose
to archive events:
 When an Event is closed
 When an Event stays open status for a certain number of days
 When an Event stays closed status for a certain number of days
 When a Closed event severity is greater than a specific severity level
For more information on these options, consult the Help.
5 Select the time, in days, for purging archive events from the repository. You can choose to purge
events:
 When the archived Event has been kept for more than a certain number of days in the
repository
 When the Oldest events exceed number of records allowed in the repository
For more information on these options, consult the Help.
6 Click OK in the Preference - Event Options dialog box.
7 Click OK in the Preferences dialog box.

5.5 Using Advanced Event-handling Properties

In addition to the repository preferences for event handling and archiving, AppManager provides
preferences to specify how jobs generate events. You can set these preferences for individual jobs by
clicking the Advanced tab in the Knowledge Script Properties dialog box. Or you can set the default
behavior for these preferences by modifying Advanced Properties repository preferences. These
advanced properties for jobs and events specify preferences for:

 Section 5.5.1, “Configuring Event Collapsing for Jobs,” on page 77

 Section 5.5.2, “Adjusting Consecutive Intervals,” on page 77
 Section 5.5.3, “Raising an Event When a Condition No Longer Exists,” on page 78

76 Managing Events
 NOTE: Any default values you set for how the Operator Console generates events will not apply to
the Control Center console. As a result, if you open the same Knowledge Script in both the Operator
Console and Control Center console, the default values on the Advanced tab of the Knowledge Script
Properties dialog box may not be the same. If you are going to create jobs from the same Knowledge
Script in both the Operator Console and the Control Center console, be sure any settings on the
Advanced tab of the Knowledge Script Properties dialog box are the same in both consoles.

5.5.1 Configuring Event Collapsing for Jobs

When you run a Knowledge Script and raise events, AppManager creates both a parent and child
event for the first occurrence of the event condition. For subsequent occurrences, AppManager
creates additional child events under the parent event and updates an event counter indicating the
number of child events.

To change the default behavior for collapsing duplicate events:

1 Select File > Preferences in the Operator Console.

2 Click the Repository tab, and click Advanced Properties in the Knowledge Script options
group.
3 Click Collapse duplicate events into a single event.
4 Set the time interval for collapsing duplicate events in the Time interval for event collapsing
field.
5 Click Initial occurrence to indicate that you want to use a static period of time to regulate event
collapsing.
6 Click OK
in the Preference - Knowledge Script Advanced Options dialog box. Then click OK in the
Preferences dialog box.

NetIQ Corporation recommends using event collapsing and selectively setting the number of
consecutive occurrences. When setting an event collapsing interval, keep the following in mind:

 The schedule interval must be set to at least 10 minutes.

 If the schedule interval is shorter than the collapsing interval and the job detects an event every
interval, new identical events are collapsed into the same child event.
 If the job schedule is longer than the collapsing interval, you will see multiple child events even
though the events are identical.
 If you set the number of consecutive occurrences to a value greater than 1, be sure to consider
the time schedule interval. For example, if a job runs once every 12 hours and you set the
number of consecutive occurrences to 3, you won’t be notified of the event until the third
occurrence — 36 hours later.
 Child events accumulate in the database. Try to strike a reasonable balance between timely
notification and eliminating trivial or redundant events.

5.5.2 Adjusting Consecutive Intervals

If you only want to receive an event if a condition crosses a threshold a certain number of times, you
can specify the number of times a consecutive duplicate event (events with the same object name,
event message, severity, job ID) must occur before AppManager generates an event message. Using
this approach you can hide trivial spikes that can occur when a Knowledge Script runs at frequent

Managing Events 77
 intervals. Events triggered by these temporary spikes are not always useful and your operations or
administrative staff can spend vital time responding to events for conditions that do not cause any
disruption to your environment.

For example, say you are monitoring CPU and it hits 99%. You might not consider this a problem
because you know the system has a heavy processing load, or because this represents an
uncharacteristic spike in the activity while the system is performing a specific processing task. In this
case, you might not want to receive an event message. However, if CPU is at 99% for 10 minutes,
you might have a problem.

By default, AppManager alerts you every time CPU crosses the threshold you specify. You have two
options for changing this:

 Set the number of times you want the condition to occur and the number of iterations for the job
in the Raise event if condition occurs N times within N job iterations field on the Advanced tab
in the Knowledge Script Properties dialog box for individual jobs.
 Change the default behavior by setting the Advanced Properties repository preference. See the
instructions below.
For this example, you might specify that you want to receive an event only if CPU is over 99% 10
times in 2 job iterations.

NOTE: Typically, the more frequently the job is scheduled to run, the higher you can set the
number of consecutive intervals before raising an event. NetIQ Corporation recommends setting
this preference in the range of 3 to 5 occurrences for volatile performance statistics.

To change the default behavior for consecutive intervals:

1 Select File > Preferences in the Operator Console.

2 Click the Repository tab, and then click Advanced Properties in the Knowledge Script options
group.
3 Specify the number of times you want the condition to occur and the number of iterations for the
job in the Raise event if condition occurs N times within N job iterations field.
4 Click OK
in the Preference - Knowledge Script Advanced Options dialog box. Then click OK in the
Preferences dialog box.

5.5.3 Raising an Event When a Condition No Longer Exists

For some event conditions, it is useful to raise an event when the condition is first detected and then
raise a second event when the condition no longer exists. For example, you can use this option if you
want to be automatically notified when a problem that raised an event has gone away.

To illustrate, suppose you want to receive a severity 5 event when CPU utilization reaches 99% and
then an informational event message with a severity level of 35 when CPU utilization returns to 10%.
In this case, you have two options:

 You can select Generate a new event when original event condition no longer exists and
specify a severity level (for example, 35) in Severity of new event on the Advanced tab in the
Knowledge Script Properties dialog box for an individual job.
 You can change the default behavior by setting the Advanced Properties repository preference.
See below for instructions.

You can also select Automatically close original event to close the original severity 5 event when
CPU utilization falls below the threshold you set.

78 Managing Events
 For example, if a job detects that physical memory usage has exceeded the threshold you set,
AppManager raises an event. This event condition continues until memory usage falls below the
threshold. Because at this point the original event condition no longer exists, AppManager
automatically closes the original event and raises a new informational event with a severity you have
specified.

NOTE: In general, you should set the severity level for the informational event to a unique or rarely-
used severity and use a severity level that is clearly distinguishable from the original event.

To change the default behavior for raising events when an original event condition no longer
exists:

1 Select File > Preferences in the Operator Console.

2 Click the Repository tab, and then click Advanced Properties in the Knowledge Script options
group.
3 Click Generate a new event when original event condition no longer exists and specify a
severity level in Severity of new event.
4 Click Automatically close original event.
5 Click OK
in the Preference - Knowledge Script Advanced Options dialog box, then click OK in the
Preferences dialog box.

5.6 Notifying Individuals of Events

Event notification policies vary from one organization to another. In some cases, it is a restricted
process, in others it is highly automated. In general, it is a good idea to carefully define a notification
strategy tailored to your unique requirements. For example, do you want to:

 Send an e-mail after an event?

 Send a page after an event?
 Redirect a message after an event?

This section describes strategies you should consider before implementing event notification.

5.6.1 Sending an Email Event Notification

AppManager provides several options for sending an e-mail message in response to an event:

 Messaging API (MAPI) mail messages

 Simple Mail Transfer Protocol (SMTP) mail messages
 Lotus Notes mail messages

To determine which type is best for your environment, consider the following:

 Your e-mail software. For example, to send MAPI mail, you must have Microsoft Exchange or
Outlook installed. To send SMTP mail, you must have an SMTP mail server. For Notes mail, you
must have a Lotus Domino server and the Notes mail client installed.

Managing Events 79
  Where you are sending the e-mail. For example, consider how you have set up mailing lists,
aliases, and network connectivity. If you defined e-mail aliases for different groups and the
addresses are all internal, you can use MAPI or Notes mail so that you are not sending
messages through your Internet gateway to deliver internal mail.
 Where the e-mail originates (from a central location or at each monitored server). Consider the
requirements for each type of mail and how those requirements suit your environment. For
example, MAPI mail requires you to install a MAPI client (such as Outlook) on the server that
sends the mail message. Notes mail must be sent from a Domino server, so the mail must be
sent from each server you are monitoring.

In most cases, SMTP mail provides the best method for e-mail notification. It does not require a client
to be installed, so it can be easily configured to run from either the management server or the
managed computers you are monitoring. The major drawback to using SMTP mail is that your SMTP
gateway can have security rules that limit the users who can send mail through the gateway or the
servers from which SMTP mail messages can originate. You should check with your SMTP gateway
administrator to ensure the user account(s) that the AppManager agent services run under have
permission to send mail on the servers from which the mail originates.

Depending on your environment you can use more than one mail method for event notification. For
example, assume you have several Exchange servers you want to monitor on one continent and your
SMTP gateway on another continent and IT staff that supports the Exchange servers is located in the
same location as the Exchange servers, but the main administrative staff is located elsewhere. You
might want the events associated with the Exchange servers forwarded to the IT staff using MAPI
mail to avoid sending mail to another continent to reach the SMTP gateway then back to the local site
for notification. Events that need to reach the main administrative staff might be configured to send
SMTP mail and be routed through the SMTP gateway for distribution.

5.6.2 Sending a Page as an Event Notification

Depending on the paging system you use and the types of messages it can receive, there are several
ways you can use AppManager to forward event information or custom information to the paging
system. In most cases, you can send event information to a pager by:

 “Using the Action_Page Knowledge Script” on page 80

 “Using SMTP Mail Messages” on page 81
 “Using MAPI or Lotus Notes Mail Messages” on page 81
 “Using Log Files or Other Sources to Send Messages” on page 81

Using the Action_Page Knowledge Script

The Action_Page Knowledge Script relies on the %SYSTEMROOT%/NetIQpage.ini file located on
each monitored server. The NetIQpage.ini file is pre-configured with information necessary to send
paging messages to several common paging systems.

To use Action_Page, install the client software for the paging application on the server where you run
Action_Page. You typically install the client software on the AppManager management server and the
management server initiates the paging action.

For more information on how to edit the NetIQpage.ini file and use the Action_Page Knowledge
Script, select the Page Knowledge Script in the Action tab in the Operator Console and press F1.

80 Managing Events
 Using SMTP Mail Messages
Some paging applications accept SMTP mail messages to send pages. If your paging application
accepts SMTP mail, you can configure an action to be initiated on the management server or on the
individual servers being monitored.

To use SMTP, configure the Action_SMTPMail Knowledge Script with the recipient’s name in the
proper format. Different paging applications have their own formatting requirements for SMTP mail
recipients. For example, the recipient’s name parameter can be an individual’s name, alias, group,
pager number, or PIN depending on the paging application (such as, [email protected] or
[email protected]).

For the SMTP server machine name, type the name of the SMTP gateway server. The SMTP server
sends the message to the appropriate paging system domain and the domain delivers the e-mail
message to the pager.

Using MAPI or Lotus Notes Mail Messages

Some paging applications accept MAPI or Lotus Notes mail messages to send pages. As mentioned
in Section 5.6.1, “Sending an Email Event Notification,” on page 79, both MAPI and Notes mail
messages have special requirements for sending mail:

 MAPI mail. To use MAPI mail, you must install and configure client software. It is usually best to
set up MAPI mail as an action that executes on the management server.
 Notes mail. To use Notes mail, you must run Notes from the Domino server(s) you are
monitoring.

Using Log Files or Other Sources to Send Messages

Some paging applications can accept input from other sources such as ASCII log files or the
Windows Event Log. For these applications, you can use the Action_WriteMsgToFile or the
Action_NTEventLog Knowledge Script, respectively. You should review your paging application’s
documentation and the AppManager Help to see how to properly configure these Knowledge Scripts.

In addition, some unsupported Knowledge Scripts that interface with paging applications without
using the NetIQpage.ini are available from the Knowledge Depot on the NetIQ Support Web site.

You can also write custom Knowledge Scripts that use the paging system’s API to perform tasks. If
you decide to write your own scripts and create your own interface, see the Developing Custom
Knowledge Scripts Guide for AppManager, available on the AppManager Documentation page (http:/
/www.netiq.com/documentation/appmanager), for information.

5.6.3 Sending Event Information to Another Console

In larger organizations, administrators often integrate AppManager events into another management
console or redirect events to a Help Desk application or tracking system. To help make this as
transparent as possible, AppManager supports a variety of “connectors” to the most common event
management consoles and help desk applications. For example, AppManager has connectors for:

 Computer Associates Unicenter NSM

 HP OpenView Network Node Manager (NNM)
 HP OpenView Operations
 Micromuse Netcool

Managing Events 81
  Microsoft Operations Manager (MOM)
 Tivoli Enterprise

You can use these connectors to integrate events into the management console applications you
want to use. Connectors are installed on AppManager management servers, and they forward events
to the management console as events are sent from the agents. For more information on
AppManager connectors, visit the NetIQ Web site or contact a NetIQ technical representative.

If NetIQ Corporation does not currently have a connector for your management console application,
you can often use Action Knowledge Scripts to transfer the event information to the application. For
example, you can use Action Knowledge Scripts to:

 Send an SNMP trap

 Save information to the Windows Application Log
 Write information to an ASCII log file

You can also create your own custom Knowledge Scripts and call a COM object or use a command-
line interface to transfer the event information to the application of your choice.

Using SNMP Traps

Sending an SNMP trap is a simple and cost-effective solution for transferring event information to
another application. It does not require any additional client software to configure or maintain or any
additional client licenses for your event console or help desk application. If you use SNMP traps, you
can run them as automated actions associated with a Knowledge Script, and configure two network
paths for events to travel to separate applications.

Using Log Files or Command-line Interfaces

You can configure automated Knowledge Script actions that write to the Windows Event Log or to an
ASCII log file, or send command-line arguments to run on the managed computer or the
management server. These methods usually require you to install, configure, and maintain a client
executable for the product to which you want to connect on each managed computer that will be
raising events. Therefore, you may incur additional licensing costs.

For these reasons, if you decide to forward events through the Windows Event Log, ASCII log files,
COM, or a command-line interface, you may want to configure the event-forwarding action to take
place at the management server to reduce costs.

5.7 Triggering Corrective Actions for Events

Before you set your Knowledge Scripts to perform an action when AppManager raises an event, you
should fine-tune the Knowledge Script threshold settings to determine the appropriate thresholds and
actions for your environment. You don’t want to receive a high volume of e-mails or pages for events
caused by thresholds that have been set too high or too low. When you’re ready to define actions for
events, select a notification method: MAPI mail, SMTP mail, or a third-party paging software.

Most actions involve event notification and visibility. However, Action Knowledge Scripts can also be
used to automatically correct problems. Typically, corrective actions run a command or execute SQL
statements on the managed computer in response to an event. Remember that the corrective action
must take place on the managed computer, not on the management server.

82 Managing Events
The Action_DosCommand, Action_DumpTran, and Action_RunSql Knowledge Scripts are good
examples of Knowledge Scripts that run corrective actions.

To run a corrective action on a specific managed computer:

1 Open the Properties dialog box for the Knowledge Script monitoring job. Click New on the
Actions tab to create a new action.
2 Select an Action Knowledge Script from the Action drop-down list. If you are monitoring a
Windows computer, UNIX actions are not available.
3 Select MC from the Location list to specify that you want AppManager to run the action on the
managed computer.

NOTE: Some actions must be run on the managed computer because they perform an operation
on that computer. Other actions can be run on either the managed computer or the management
server.

4 Configure the action Type to run the first time an event is generated (a unique event), after a
duplicate child event is created a specified number of times, or when the event condition no
longer exists. When monitoring UNIX and Linux computers, the Type is always New Event.
5 Select an action schedule from the Schedule drop-down list to specify the available hours during
which the action can run. When monitoring UNIX and Linux computers, action schedules are not
applicable.
6 Click Properties to set the properties for the Action Knowledge Script.
Most actions require you to set some additional properties. For example, if you select an e-mail
action you need to specify an e-mail recipient. For more information about Action Knowledge
Scripts and their parameters, see the AppManager Help.
7 Click OK in the Action Properties dialog box, and then click OK in the Knowledge Script
Properties dialog box.

When configuring an automated Knowledge Script action, check the following:

 Whether the account the AppManager agent service (NetIQmc) runs under (whether
LocalSystem or a specific user account) has permission to execute the desired action on the
computer where the action runs.
 Whether the action requires environment variables to be set and whether those environment
variables run properly. If your action requires environment variable changes, determine whether
the environment variables are instantiated by the Action Knowledge Script or are preset as
system variables in the System Control Panel for the computer. For example, using
Action_DosCommand to call the Attention! executable (attn.exe) requires you to set the
attnsrv=servername environment variable on the computer running the action.
 Whether the command you want to run requires user interaction, such as input. For example, if
you decide to run a command to delete files, use del /Q rather than just del to ensure that any
wildcard deletions take place without prompting for confirmation.

Managing Events 83
84 Managing Events
6 Managing Data
6

Before you deploy AppManager across your entire enterprise, develop and refine your data handling
policies. In determining how you want to manage AppManager data in your organization, consider
your group’s internal procedures, department structure, and management goals. For example, if your
manager asks you to supply a weekly performance summary for your Network Operations Center
(NOC), you need to collect data for those servers and run reporting Knowledge Scripts at least once
each week. It is important to understand how your data-handling policies will affect the availability of
the specific charts, graphs, and reports you are interested in, as well as the level of database
management you will need to perform.

The topics in this chapter address the impact of data collection and the options you should consider
when planning to run Knowledge Scripts that collect data.

6.1 Deciding When to Collect Data

It is important that you collect only the data you require for an adequate understanding of your
systems or for charts, graphs, and reports. If you collect too much data, it can be hard to manage and
require constant database maintenance.

Typically, you collect data when you want to:

 Identify normal operating environment performance values or baseline performance values

 Diagnose problems (for example, to view the top CPU consumers after finding that processes
are failing)
 Create data streams for real-time charts or graphs to identify short-term trends or compare
performance data
 Store historical information for trend analysis, capacity planning, or service-level reporting

Although most organizations collect data for a combination of these reasons, it’s important to
consider which jobs you use to collect data, how frequently the jobs run, how much data is returned,
and how you will use the data in specific charts, graphs, and reports. Don’t collect data for all jobs;
only collect it from the jobs from which you need charts, graphs, and reports.

As an example, consider a Knowledge Script that checks server connectivity. You might want to run
this monitoring job every 5 minutes to ensure prompt notification if the server connection goes down.
However, with data collection enabled, you could run the script less frequently, or only during
business hours. By adjusting the schedule for data collection, you avoid cluttering the database with
unnecessary information.

In some cases, getting a data point every five minutes is useful. Often, however, frequent data
collection doesn’t really provide you with any more useful information than if you were collecting the
data point at a longer interval. For example, CPU and memory usage can change significantly in a
five-minute period, but logical disk space is not likely to change as frequently and can be effectively
monitored at 12- or 24-hour intervals.

As a general guideline, when you monitor values that can change frequently, collect data more
frequently so that a statistical analysis of the data can provide a realistic picture of activity on the
monitored system. For example, if you collect data on CPU utilization once an hour, or even every 15
minutes, you can capture data spikes or lulls that do not accurately reflect performance, resulting in

Managing Data 85
 reports that provide an inaccurate view. When monitoring values that change more slowly, like logical
disk space or database growth, you can collect data at longer intervals and still achieve an accurate
assessment.

The best practice is to have a clearly defined purpose for collecting the data, such as producing a
weekly report of server availability or the top ten e-mail users. It is also important to keep in mind that
every data point stored in the repository requires more data space and more database management.
Having a clear purpose and understanding the impact of the data you are collecting helps you make
the most intelligent decisions about when and how to collect data.

To illustrate the importance of this point, consider a Knowledge Script such as NT_TopCpuProcs,
which reports the CPU utilization of all processes running on a managed computer. In most cases,
you should only run this job when investigating a problem on the computer. If you enable data
collection, you should not run this job on multiple computers or on a regular schedule because of the
potential overhead in database space and performance involved in returning so much data.

Therefore, the first step in defining your data-handling policies is to make a list of the specific charts,
graphs, and reports you need and the period of time for which you want to view information. For
example, determine whether you are interested in real-time charts and graphs only on a daily basis or
want to keep charts and graphs active for one or two weeks. Similarly, consider whether you are
interested in hourly data or weekly summaries. Although your list is likely to change over time,
identifying a few specific charts, graphs, and reports early on can help you collect only the data you
need.

6.2 Understanding Data Collection for Charts, Graphs,

and Reports
When you run a Knowledge Script that collects data, each time the Knowledge Script runs, it collects
an individual data point and stores the information in the AppManager repository. Once AppManager
stores the information in the repository, you can:

 Display it in real-time charts and graphs using the Operator Console, Control Center console,
or Chart Console. Real-time charts represent active data streams that AppManager visually
updates as it receives new data points.
 View it in static HTML reports, generated using report Knowledge Script templates, using the
Report Viewer. Generated reports represent a snapshot of data from the repository for the period
of time you specify. Generated reports can include charts, but the charts are static and specific to
the report period you define.

By default, AppManager keeps the data points that Knowledge Script jobs collect for a given day in a
data table for immediate display in real-time charts and graphs for 30 days, and each day removes
any data tables that are more than 30 days old. One way to think of this is that every day the oldest
data points “expire” and are no longer available for real-time charting and graphing.

6.3 Using Advanced Data-handling Properties for

Jobs
AppManager provides preferences for you to specify how you want your jobs to collect data. You can
set these preferences for individual jobs by clicking the Advanced tab in the Knowledge Script
Properties dialog box. You can set preferences for collecting detail data, the schedule for collecting
data, and collecting data in response to an event.

86 Managing Data
6.3.1 Collecting Detail Data
By default, every time you run a Knowledge Script and collect data, AppManager returns a data point
value (for example, 50) but does not return a detailed description (for example, CPU utilization is
50%). In general, when you view the data in charts, graphs, and reports, you usually focus on the
value and not the details. However, in some cases, you might want additional information. For
example, the NT_TopCpuProcs Knowledge Script can include a list of the processes consuming the
most CPU in its detail message, but you must enable it to include the additional information.

To reduce the amount of space the data in your repository takes up, use the options available on the
Advanced tab of the Knowledge Script Job Properties window to configure AppManager to collect
data details differently for individual jobs. To collect the value of the monitored resource and detailed
information, such as server name and collection time, enable the Collect data details with data
point preference.

To change the default behavior for data collection for all jobs, use the Operator Console.

NOTE: Changing the default behavior for data collection in the Operator Console does not affect
default settings for the Control Center console.

To change the default behavior for collecting data details:

1 Select File > Preferences in the Operator Console.

2 Click the Repository tab, and then click Advanced Properties in the Knowledge Script options
group.
3 To collect the value of the monitored resource and detailed information, such as server name
and collection time, select Collect data details with data point.
This option only applies to data collection for AppManager graphs and charts.
4 Click OK to save the changes.

6.3.2 Modifying the Schedule for Collecting Data

When you run a Knowledge Script and collect data, AppManager returns a data point value for every
job iteration, storing each data point in the repository--requiring more data space and more database
management.

In some cases, collecting a data point at every job iteration might not provide useful information. If
you want to run a Knowledge Script on a frequent basis (for example, every 5 minutes) but don’t need
to collect and store a data point for each iteration, you can set the Collect data every N job iterations
and Calculate average preferences to reduce overhead and, in some cases, more accurately reflect
real system performance.

Instead of collecting 12 data points per hour (while the Knowledge Script is running every five
minutes), AppManager collects a data point every n iterations and stores fewer data points in your
database. Each data point is an average of all the values AppManager collects in each of the n
iterations. Averaging the values over several iterations provides a more accurate reflection of system
performance.

You can set these preferences on the Advanced tab in the Knowledge Script Properties dialog box
for individual jobs, or you can use the Operator Console to set repository preferences that control the
default behavior for all jobs.

Managing Data 87
 NOTE: Changing the default behavior for data collection in the Operator Console does not affect
default settings for the Control Center console.

To change the default behavior for collecting and averaging data:

1 Select File > Preferences in the Operator Console.

2 Click the Repository tab, and then click Advanced Properties in the Knowledge Script options
group.
3 In the Data options group, set the number of times a job should run before collecting a data point
in the Collect data every N job iterations preference.
4 Select Calculate average.
5 Click OK to save the changes.

6.3.3 Collecting Data in Response to an Event

Each time you run a Knowledge Script and collect data, AppManager returns a data point. However, if
you are more interested in getting information to diagnose a problem and not for charting, graphing,
and reporting, you can set repository preferences to collect data in association with event conditions.
Using these preferences, you can collect data when the server, application, or process you are
monitoring crosses the threshold you specify and raises an event.

For example, you can run the NT_TopCpuProcs Knowledge Script to raise an event if CPU usage on
a computer exceeds a 90% threshold. Set this job to Start collecting data when an event is
generated because when CPU utilization reaches 90%, you want to know what processes are
responsible and create a report that lists the causes of the high CPU. AppManager only creates a
data point when the threshold you specify (in this case, 90%) is exceeded. This prevents your
database from filling up with information you might never use.

You can then use the Stop collecting data when event condition no longer exists preference to
stop data collection after you fix the problem that generated the event.

You can set these preferences on the Advanced tab in the Knowledge Script Properties dialog box
for individual jobs, or you can change the default behavior by setting the Advanced Properties
repository preferences.

NOTE: Changing the default behavior for data collection in the Operator Console does not affect
default settings for the Control Center console.

To change the default behavior for collecting data only when an event condition exists:

1 Select File > Preferences in the Operator Console.

2 Click the Repository tab, and then click Advanced Properties in the Knowledge Script
options group.
3 In the Data options group, select Start collecting data when an event is generated.
4 (Conditional) If you want jobs to stop collecting data when the event condition no longer exists,
select Stop collecting data when event condition no longer exists.
5 Click OK to save the changes.

88 Managing Data
7 Managing a QDB
7

This chapter provides an overview of the information stored in the QDB and describes how to perform
routine database maintenance. For more information about how to perform any of these tasks using
Microsoft SQL Server Management Studio or other SQL Server tools, see your Microsoft SQL Server
documentation.

7.1 Understanding the AppManager Repository

The QDB is a SQL Server database that stores information about the following:

 The jobs you run

 The events and data that AppManager collects
 The managed computers that AppManager monitors
 The options you set for viewing and managing jobs, events, and data
 Stored procedures that AppManager uses in the background to perform the database operations
that you request
 Scheduled jobs to perform certain maintenance tasks at set intervals

The management server, Operator Console, and Control Center send information to and request
information from the database using SQL ODBC connections.

Managing a QDB 89
 7.1.1 Understanding the Tables
The AppManager repository includes more than 100 database tables to store details about the
computers you monitor, the jobs you run on each computer, the job properties you set, the events,
and the data that AppManager collects. In most cases, you only need to be familiar with a few of
these tables to plan your maintenance and backup strategies.

The tables are as follows:

Table Name Information stored

Event Basic event identification, including:

 Numeric identifiers for parent and child events

 Name of Knowledge Script and numeric identifier for job that
raises the event
 Name of computer that raised the event
 Event severity, time of last event occurrence, and short message
associated with the event

Several related tables that are linked to this table through the EventID
field store additional event information. Related tables include:

 EventDetail
 EventDetailAction
 EventHistory
 ArchiveEvent
 ArchiveEventDetail
DataHeader Data stream identification and related properties, including:

 Numeric identifier for the data stream

 Numeric identifiers for the parent and child job collecting the data
 Name of Knowledge Script collecting the data
 Numeric identifier and name for the computer running the job
 Short description (legend) associated with the data stream
 Minimum, maximum, and last values returned
Several related tables that are linked to this table through the DataID
field store additional information, such as the detail message
associated with the data stream. Related tables include:

Data_yyyymmdd
 DataHeaderDeleted
 DataRejected
 ArchiveDataHeader

90 Managing a QDB
 Table Name Information stored

Data_yyyymmdd Data values and timestamps, and short and long detail messages
associated with data points if you set jobs to collect data details

AppManager stores collected data by day, with one table per day.
AppManager deletes the tables when they reach the maximum
retention period that you specify for Remove old data after in the
Control Center console options. The default retention period is 30
days.

For information about setting the console options, see the Control
Center User Guide for AppManager, available on the AppManager
Documentation page (http://www.netiq.com/documentation/
appmanager).

ArchiveDataHeader Data stream identification and related properties for archived data
streams.

Job Basic job identification, including:

 Name of the Knowledge Script and the numeric identifier for the
parent and child job
 Numeric identifier for the computer running the job
 Job status indicator
 Time the job was submitted, last run, last paused, and last
restarted

Related tables that are linked to this table through the JobID field
store additional job information, such as the audit trail associated with
the job. Related tables include:

 JobHistory
 JobObject

7.1.2 Stored Procedures

The AppManager repository includes numerous stored procedures that perform operations when you
use the Operator Console or Control Center console to complete tasks, or when the management
server updates the database. These stored procedures contain the logic that serves as the backbone
for creating jobs, handling events, managing data, and producing reports.

The only stored procedures you can view in their entirety are those used to generate reports. The
stored procedures for reports use a special naming convention (NetIQrp* and rp*). The stored
procedures are not encrypted and you can use them as templates to create new and custom reports.

7.1.3 SQL Server Jobs

The AppManager repository includes predefined SQL Server jobs that run at regular intervals to
perform specific data management tasks. Depending on the task performed, changing the SQL
Server job interval can affect database performance or efficiency. You can change the schedule
through the Task Scheduler Configuration Utility. For more information about changing the job
schedule, see Section 7.2, “Configuring the Task Scheduler Service and SQL Server Jobs,” on
page 93.

AppManager uses the following SQL Server jobs for managing data.

Managing a QDB 91
 Job Description

NetIQ Archive Event QDB Moves events from the Event tables to the ArchiveEvent tables if you set
the repository preference to archive events. The job runs every 3 hours.

NetIQ Dynamic View QDB Ensures that relevant information is shown in any existing dynamic view. Also
ensures that any job affected by parameter overrides restarts with the override
values if the corresponding custom property value has changed. The job runs
every 7 minutes.

NetIQ MS Healthcheck QDB Raises an event if it detects a downed management server. This stored
procedure also closes any events when the management server is restored.
The job runs every 2 minutes.

NetIQ Monitoring Policy Applies monitoring policies defined in Control Center and in the Operator
QDB Console to matching servers. This task creates new monitoring policy jobs
where it detects they are missing and removes existing jobs where it detects
they should no longer be running. The job runs every 3 minutes.

NetIQ Purge Archive Deletes archived event information from the ArchiveEvent and
Event QDB ArchiveEventDetail tables based on the repository preference you have
specified.

For more information about setting the repository preference used by this job,
see “Managing Events” on page 71.

The job runs every day at 2:00 AM.

NetIQ Rule Based Dynamic Ensures that the rule-based dynamic views correctly represent the servers.
View QDB The job runs every 2 minutes.

NetIQ Update MG Server Updates the Control Center tables in the QDB, which enables the information
Membership QDB to be moved into the Control Center repository for display in the Control Center
console. The job runs every 3 minutes.

NetIQ Uphold Parameter Reconciles the overrides for monitoring policy and ad hoc Knowledge Script
Overrides QDB Group parameters with the information configured in Control Center: it
compares job override settings with the settings that the Control Center
repository puts in the ParameterOverride table. The job runs every 2
minutes.

NetIQ Daily QDB Performs internal data maintenance operations, such as removing jobs,
events, actions, objects and data that you mark for deletion during the day and
running a consistency check for frequently used tables. The job runs daily at
1:00 AM.

NetIQ Hourly QDB Performs internal data maintenance operations, such as updating table
statistics for frequently accessed tables and recompiling frequently used
procedures. The job runs every 2 hours.

NetIQ Weekly QDB Performs internal data maintenance operations, such as re-indexing tables
and performing data archiving operations. The job runs every Sunday at 3:00
AM.

NetIQ License Audit QDB Reviews the installed license keys against the information in the AppManager
TreeView pane. The job runs every 3 months on the first day of the month.

92 Managing a QDB
 Job Description

NetIQ Remove Old Data Removes Data_yyyymmdd tables that are older than the number of days you
QDB specify for Remove old data after in the Control Center console options and
updates the consoles to reflect removal of the old data.

The default data retention period is 30 days. If you specify zero days, the job
does not remove any data. The job runs daily at 2:30 a.m.

For information about setting Control Center console options, see the Control
Center User Guide for AppManager, available on the AppManager
Documentation page (http://www.netiq.com/documentation/appmanager).

NetIQ Rebuild Data Views Adds 10 days’ worth of Data_yyyymmdd tables for future use.
QDB
The job runs daily at 3:30 a.m.

NetIQ VSG Modtime Update Updates the modification time in tables related to servers and views. Control
QDB Center uses this information to determine whether to update the Control
Center repository. The job runs every 15 seconds.

NetIQ Daily NQCCDB Removes items marked for deletion from the Event, Job, and Computer
tables. The job runs daily at midnight.

NetIQ Half-Hourly Task Maintains the Queue table, which is used by the command queue service for
NQCCDB tasks submitted by the Control Center console. The job runs every 30 minutes.

NetIQ Hourly NQCCDB Maintains several background tables, such as the ArchiveQueue and Object
tables, and processes custom properties and security configuration
information. The job runs every hour.

NetIQ Manage SQL Jobs This task provides for backward compatibility only. The NQSYNCDB process
NQCCDB now handles actions once taken by this task. The job runs every minute.

NetIQ SMV Hourly Task Deletes information that has been marked for removal from various tables
NQCCDB related to Service Map Views. The job runs every hour.

These jobs require the Task Scheduler service to be running. You can check the status of the jobs in
the Task Scheduler Configuration Utility. If a job did not complete successfully at its last iteration,
check the status of the Task Scheduler service. In addition, you should periodically back up SQL
Server jobs as part of regular database maintenance. For more information about backing up the
repository, see Section 7.9, “Backing Up and Restoring the QDB,” on page 100.

7.2 Configuring the Task Scheduler Service and SQL

Server Jobs
The Task Scheduler Configuration Utility allows you to perform most of the tasks related to
configuring the Task Scheduler service and SQL Server jobs, including:

 Adding repositories to and removing them from the service

 Changing the authentication method the service uses to connect to a repository
 Changing the schedule for SQL Server jobs
 Disabling SQL Server jobs

Because the SQL Server jobs handle internal data management, you should not change the default
schedule or attempt to modify the SQL Server job steps unless a NetIQ Technical Support
representative or implementation consultant instructs you to do so, or unless you fully understand the
impact of making a change.

Managing a QDB 93
 Access the utility from the Start menu.

To add a repository to the service:

1 In the Tasks pane, click Add.

2 Provide the required information about the repository.
If you are using a port other than the default port (1433) for communications with SQL Server,
you must use the format SQL_Server_Name/Instance,Port_Number when you specify the SQL
Server name.
3 Click OK.

To remove a repository from the service:

1 In the Tasks pane, click Remove.

2 Select the repository you want to remove, and then click OK.

To change the authentication method for a repository:

1 In the repository grid, select the repository you want to modify.

2 In the Tasks pane, click Modify.
3 Provide the required account information, and then click OK.

To change the schedule for a job:

1 In the repository grid, select the repository that contains the job you want to modify.
2 In the job grid, select the job you want to modify.
3 In the Tasks pane, click Change Schedule.
4 Select the desired schedule settings, and then click OK.

To disable a job:

1 In the repository grid, select the repository that contains the job you want to disable.
2 In the job grid, select the job you want to disable.
3 In the Tasks pane, click Disable.
To re-enable the job, click Enable.

In slow or busy network environments, you might find that you need to make adjustments to better
adapt communication between the repositories and the service to your environment. A standard .NET
XML configuration file, NetIQTaskScheduler.exe.config, includes parameters that you can change
to address performance and communication issues. The default location for the configuration file is
C:\Program Files\NetIQ\AppManager\TaskScheduler\bin.

Before you edit the file, contact Technical Support.

You can edit the following parameters:

CmdTimeout
The time to wait (in seconds) before terminating an attempt to execute a SQL command and
generating an error.
The default value is 0 seconds, which means that attempts to execute SQL commands will never
time out.

94 Managing a QDB
 ConnTimeout
The time to wait (in seconds) before terminating an attempt to establish a connection to an
instance of SQL Server and generating an error.
The default value is 15 seconds.

SQLJobDiscoveryInterval
The frequency (in minutes) at which the Task Scheduler service checks the repositories to
discover new or removed SQL Server jobs and update the Task Scheduler Configuration Utility.
The default value is 30 minutes.

7.3 Managing Data Streams

In the QDB, current data point information is stored in the DataHeader and Data_yyyymmdd tables.
These two tables provide the information for real-time charts and graphs.

 The DataHeader table stores identifying information about the data stream, such as the job ID,
computer name, script name, maximum days, current points, and the data legend. Each data
stream has a unique identifier, or primary key, which enables the Data_yyyymmdd tables to
reference the information.
 The Data_yyyymmdd tables store individual data point values, the time each data point was
collected, and short and long detail messages associated with data points (if you set jobs to
collect data detail).

The amount of data AppManager collects at each interval can quickly grow unmanageable and affect
database and console performance. By default, the NetIQ Remove Old Data QDB job runs every day
at 2:30 a.m. to remove Data_yyyymmdd tables that are older than the number of days you specify for
Remove old data after in the Control Center console options and updates the consoles to reflect
removal of the old data. The default data retention period is 30 days. If you specify zero days, the job
does not remove any data. For information about setting the console options, see the Control Center
User Guide for AppManager, available on the AppManager Documentation page (http://
www.netiq.com/documentation/appmanager).

If you set the Control Center console options so that the NetIQ Remove Old Data QDB job does not
remove data, you should periodically remove information that you no longer need. The database size
should not expand indefinitely, or database corruption could occur, making your environment unstable
or unusable. Establish a regular backup strategy for saving historical information, or follow a policy of
manually removing data after a certain period of time.

NOTE: If a data stream is deleted from the Graph Data tab in the Operator Console, the record is
deleted from the DataHeader table. You can set the Remove associated data when jobs are deleted
repository preference to delete data from both the Data_yyyymmdd and DataHeader tables when jobs
are deleted, no matter how long the information has remained in the tables. For more information
about deleting data, see the chapter “Managing Data” on page 85.

Managing a QDB 95
 7.4 Managing Event Information
The QDB stores current event information in the Event and EventDetail tables.

 The Event table stores basic event information that corresponds to the columns available in
Events views in the Control Center console.
 The EventDetail table stores the details about events that correspond to the information found
in the Event Properties dialog box.

By default, the tables store event information until you delete an event. Although the event tables do
not typically increase in size or affect database performance as quickly as the Data_yyyymmdd tables,
there are several ways you can manage event information in the repository to ensure database
efficiency.

To keep the Event and EventDetail tables from growing too large, enable the repository preference
Move aged events to archive tables in repository. This preference also lets you specify conditions
for moving event information from the Event and EventDetail tables to the ArchiveEvent and
ArchiveEventDetail tables. For example, you can choose to archive events that remain closed for a
certain number of days or that have a certain severity. This option also allows you to specify
conditions for removing archived events from the database.

Another good practice is to set the Remove associated events when jobs are deleted repository
preference to delete data from both the Event and EventDetail tables when jobs are deleted. This
preference acts independently of your event-archiving settings. For more information about event
settings, see “Managing Events” on page 71.

As with any database application, however, you should periodically remove information that you no
longer need. Regardless of whether you choose to move events to the archive tables, you should
plan for this type of database maintenance. For more information about archiving events, see
Section 7.10, “Removing Events,” on page 101.

7.5 Managing Audit Trails

For security reasons, AppManager automatically collects audit information about when computers
are placed in maintenance mode and about user logon activity. You can also configure AppManager
to collect an audit trail for jobs, events, or actions using the Miscellaneous repository preference.

If you enable auditing for jobs, events, or actions, AppManager records information about every
related operation in the repository. For example, if you enable auditing for job-related operations, the
audit trail includes chronological information about who started each job, changes to job properties,
and changes to job status.

Because the QDB stores audit information and can increase in size continuously, you should
periodically remove the information that you no longer need from the tables that store the audit
information you collect:

Table Type of information stored

ActionHistory Action-related activities

EventHistory Event-related activities

JobHistory Job-related activities

MachineMntHistory Maintenance mode activity

96 Managing a QDB
 Table Type of information stored

‘ Logon and logoff activity

Whether you choose to enable auditing for jobs, events, or actions, you should plan for periodic
maintenance of the MachineMntHistory and QLogonoffHistory tables. For example, you should
plan a regular backup strategy for saving historical information and establish a policy for manually
removing audit information after a certain period of time.

NOTE: Do not remove information from the KSHistory table. The QDB manages the contents of this
table internally.

7.6 Checking SQL Server Configuration

SQL Server includes many configuration options for tuning server and database operations. For most
of these options, SQL Server dynamically adjusts the configuration when needed, for example by
allocating more memory or adding user connections.

In most environments, you do not need to manually set or adjust any of these options. In rare cases,
however, you might find it useful to override SQL Server’s dynamic allocation and manually set the
value of a configuration option. The specific settings you should use can vary greatly, depending on
your deployment and your database management practices.

The following table lists the SQL Server configuration options you are most likely to use for
AppManager. For more information about the options and to determine which options, of any, to
change, see your SQL Server documentation.

SQL Server Option Considerations

locks The internal memory cost of locks is relatively low, so you might want to
manually set this option to avoid running out of locks on busy systems.

In general, you can calculate the value for locks by estimating (user
connections) x (maximum number of tables simultaneously accessed by
any user at the same time) x (maximum rows per table accessed by any
user at the same time). This estimation assumes no lock escalation and
more page activity than is likely to occur, but is a good starting point.

min server memory In general, you should configure SQL Server with as much RAM as you
can without causing Windows to page, but you should also consider the
max server memory size of your SQL Server environment and how your AppManager
components are distributed. For example, if you are using a single server
for both the repository and management server, configure SQL Server to
use less memory--to accommodate Windows and the management server-
-than if the server is a dedicated repository server.

Managing a QDB 97
 SQL Server Option Considerations

open objects To set this value, estimate the maximum number of tables, views, rules,
stored procedures, defaults, and triggers that will be open at any one time
for the SQL Server. It is better to overestimate than underestimate this
value.

A typical configuration in an active environment is 5000 open objects. If you

are collecting or purging a large amount of data, increase the number of
open objects, for example, to 20,000, or even 50,000.

NOTE: Open objects consume memory, so increasing this value reduces

the memory available for other SQL Server operations. It might require a
larger amount of memory dedicated to the server.

user connections To determine the maximum number of user connections that your system
allows, use the following statement:

SELECT @@MAX_CONNECTIONS

Typically, AppManager requires 80-100 user connections. The

AppManager Management Service (NetIQms) uses 40-60 connections.
Each console simultaneously connecting to the repository uses 1-5
connections.

If your organization has several console programs connecting to the same

repository at the same time, you might need to increase this value. For
example, if, on average, you have 12-15 console programs simultaneously
accessing the same repository, you might set the user connections option
to a value of 150 to 200 (depending on the amount of buffer you want for
connections that are blocked and must time out).

In addition to these server-level configuration options, SQL Server includes several database-level
configuration options that you can use to specify the characteristics of each database. These options
help you to control specific behavior for a database, such as automatic operations and recovery
options. In general, these options do not affect AppManager operation or performance. You should,
however, consider these options when planning your backup and database management strategy
and when deciding whether you will do full backups, incremental backups, or both.

7.7 Expanding the Size of a Repository

When you install the AppManager repository, you set the initial size of the repository’s data and log
files. After installation, you can use the Management Studio to expand the size of the data and log
files or add new data and log files for the repository to expand into over time. In planning for
repository growth, consider the following:

 SQL Server is configured by default to automatically grow the database file size without
restriction. NetIQ Corporation recommends that you restrict database file growth so that the
database cannot consume all of the disk’s resources. If the database consumes all available disk
space, you cannot perform any maintenance on it, including deleting or truncating data.
 If you allow SQL Server to grow automatically, you will experience some performance
degradation while SQL Server is in the process of expanding the database.
 You can reduce disk fragmentation by configuring the database file size to expand in larger
increments.
 Increasing the size allotted for the data file or adding data files before a significant amount of
information is stored in the repository helps to maximize performance.

98 Managing a QDB
 To expand the size of a QDB, first increase the size of the database data file. For information about
how to increase the size of the data file, see your SQL Server documentation.

You can also expand the size of the existing log file or add new log files for the repository. For
information about setting a new log file size or adding a log file, see your SQL Server documentation

7.8 Checking the Integrity of the Repository

Periodically, you should check repository integrity to prevent problems such as uncontrolled database
growth, corruption of database tables, or inconsistencies in database structure.

As with other database maintenance tasks, the frequency of database consistency checking depends
on several factors, including the number of jobs you run, the number of events you generate, the
number of data points you collect, and the stability of network communication. In general, the larger
the repository, the more frequently you should check database consistency.

Several SQL Server dbcc commands can be used to check table consistency, segment usage, page
allocation, pointer operations, and index operations. You can also use the AMAdmin_DBHealth
Knowledge Script to perform a more limited check of the syslog system table and the main tables
that store AppManager activity, such as the tables for events, data, and jobs.

NOTE: The AMAdmin_DBHealth Knowledge Script also checks the percentage of data space and
log space used by the QDB, the time it takes a query to execute, and the status of scheduled SQL
Server jobs. For more information about using this Knowledge Script, see the Knowledge Script Help.

The following dbcc commands can be executed in any SQL Server query tool, such as SQL Server
Management Studio or isql. For more information about the syntax to use with these commands,
see the Microsoft Transact-SQL Reference Guide.

Command Description

DBCC CHECKCATALOG Checks the system tables for consistency and display segment information.
This command is highly effective and typically takes less time to complete
than other consistency-checking commands.

DBCC NEWALLOC Ensures that page allocation is correct and that the page structure for the
data and index pages is consistent.

NOTE: Run this command in single-user mode.

DBCC TEXTALL Checks text and image allocation errors for all tables that contain text and
image columns.

DBCC CHECKTABLE Ensures that all pointers and data and index pages in a specified table are
consistent and properly linked.

DBCC CHECKDB Ensures that all pointers and data and index pages for all tables in the
database are consistent and properly linked.

Because most database consistency checks can take several hours to run, you should plan to run
these processes during off-peak hours. You should also include these checks in your overall
database maintenance plan and backup strategy to ensure you always back up a clean database. For
example, if you are nearing maximum capacity on a server, you should check the database
consistency in preparation for backing up.

Managing a QDB 99
 The AM Self Monitoring module, also known as AM Health, includes the
AMHealth_QDBComponentsHealth Knowledge Script for monitoring the health and availability of
SQL Server resources for the QDB. For more information, see the module management guide on the
AppManager Modules Documentation page.

7.9 Backing Up and Restoring the QDB

In planning your database maintenance strategy, evaluate the following:

 Your data collection policies

 Your requirements for producing charts and reports
 How you address event activity

You can then use this information to help you establish a schedule for performing regular backups of
the AppManager repository.

Also back up the QDB if you move the database server to another computer, or if you upgrade from a
32-bit SQL Server installation to a 64-bit SQL Server installation. If you are moving the 32-bit QDB to
a 64-bit SQL Server computer, make sure you have the latest 32-bit hotfixes and modules. After you
move the QDB to the 64-bit SQL Server computer, you cannot install the 32-bit hotfixes and modules.

NOTE: The master database holds all of the device configuration information, SQL Server login
information, and extended stored procedures. Therefore, periodically back up the master database
even if you are not backing up the QDB—especially if you add data devices, databases, or users, or
change any configuration options.

You can achieve the following results if you take regular scheduled backups of the QDB:

 Ensure the integrity of the data stored in the QDB.

 Provide a means for archiving historical information.
 Prevent data loss.
 Facilitate disaster recovery.
 Enable the movement of the QDB from a 32-bit SQL Server computer to another 32-bit or 64-bit
SQL Server computer.

Although you can back up the repository manually at any time using SQL Server Management Studio
or with the SQL_RunSQL Knowledge Script, both SQL Server Management Studio and the RunSQL
script allow you to automate backups by scheduling them to run at set intervals or at specific days
and times.

The frequency of your full or incremental backups depends on the nature of your environment,
including the size of the data and log files, the number of computers you monitor, the number of
Knowledge Scripts you run, how much data you collect, how you use charts and reports, and how
quickly you acknowledge and close events.

As a general rule, perform a complete or incremental backup at least once a week.

For more information about preparing the QDB for backup, backing up the QDB, and restoring the
QDB, see the Upgrade and Migration Guide for AppManager, available on the AppManager
Documentation page (http://www.netiq.com/documentation/appmanager). When preparing to back up
the QDB, if you are only backing up the QDB and not moving it to another computer, only perform the
steps related to the following:

 Noting properties for SQL Server logins

100 Managing a QDB

  Closing open connections
 Verifying that there are no open connections

7.10 Removing Events

In the AppManager Operator Console, you can set repository preferences for archiving events. These
options allow you to move historical event information to archive tables where it is still available for
reporting.

To access the event archiving options:

1 From the File menu, select Preferences.

2 Click the Repository tab.
3 Click Events.
4 Select the appropriate event archiving options.

Over time, these tables increase in size and can eventually threaten database performance and
consistency. As with any database, therefore, you should periodically remove archived information
that it is no longer needed to prevent the database from growing continuously.

7.11 Moving the QDB

This section provides a brief overview of how to move the QDB from one SQL Server computer to
another SQL Server computer.

If you use the repository only as a read-only archive of information, you can typically use SQL Server
backup and restore capabilities to copy the repository to a new SQL Server computer. You cannot,
however, use the basic backup and restore capabilities to move an active AppManager repository
that receives connections from the management server and the Control Center console or the
Operator Console.

You can move the QDB between two 32-bit or 64-bit SQL Server computers or from a 32-bit SQL
Server computer to a 64-bit SQL Server computer.

NOTE

 If you move the QDB from a 32-bit SQL Server to a 64-bit SQL Server computer, you must also
move the Control Center repository to a 64-bit SQL server computer at the same time.
 You must disconnect both the 32-bit repositories when you move them to 64-bit. You can choose
to move any secondary QDBs to 64-bit.

For detailed instructions about moving a QDB, see the Upgrade and Migration Guide for
AppManager, available on the AppManager Documentation page (http://www.netiq.com/
documentation/appmanager).

Managing a QDB 101

 7.12 Using the Repository Browser
The Repository Browser allows you to browse the records in the QDB and use standard SQL
commands to write queries to retrieve the information from the database. As some of the information
stored in the repository may be sensitive, you should consider restricting access to the Repository
Browser through the AppManager Security Manager.

102 Managing a QDB

8 Managing Control Center
8

The Control Center repository is stored in a Microsoft SQL Server database. As with any database,
you need to perform a number of procedures regularly to maintain the database and ensure database
integrity. This chapter provides an overview of the information stored in the Control Center repository
and describes how to perform routine database maintenance and ensure database consistency. For
more detailed information about how to perform any of these tasks using Microsoft SQL Server
Management Studio or other SQL Server tools, see your Microsoft SQL Server documentation.

8.1 Understanding the Control Center Repository

The Control Center repository is a core component of the AppManager architecture. It is a
SQL Server database that stores all Control Center information, including details about all of the jobs
you are running, the events being collected, the managed computers being monitored, and the
options you’ve set for viewing and managing jobs and events. The Control Center repository also
includes stored procedures that Control Center uses in the background to perform the database
operations you request as well as several scheduled jobs to perform certain maintenance tasks at set
intervals.

The AM Self Monitoring module, also known as AM Health, includes the

AMHealth_CComponentsHealth Knowledge Script for monitoring the health and availability of SQL
Server resources for the CCDB. For more information, see the module management guide on the
AppManager Modules Documentation page.

8.2 Configuring the Task Scheduler Service and SQL

Server Jobs
The Task Scheduler Configuration Utility allows you to perform most of the tasks related to
configuring the Task Scheduler service and SQL Server jobs. In addition, a standard .NET XML
configuration file, NetIQTaskScheduler.exe, includes parameters that you can change to address
performance and communication issues. For more information about the utility and the configuration
file, see Section 7.2, “Configuring the Task Scheduler Service and SQL Server Jobs,” on page 93.

8.3 Backing Up the Control Center Repository

In planning your database maintenance strategy, evaluate how you address event activity. You can
then use this information to help you establish a schedule for regularly backing up the Control Center
repository.

Also back up the CCDB if you move the database server to another computer, or if you upgrade from
a 32-bit SQL Server installation to a 64-bit SQL Server installation. If you are moving the 32-bit CCDB
to a 64-bit SQL Server computer, make sure you have the latest 32-bit hotfixes and modules. After
you move the QDB to the 64-bit SQL Server computer, you cannot install the 32-bit hotfixes and
modules.

Managing Control Center 103

 NOTE

 The master database holds all of the device configuration information, SQL Server login
information, and extended stored procedures. Therefore, periodically back up the master
database even if you are not backing up the CCDB—especially if you add data devices,
databases, or users, or change any configuration options.
 If you want to move a 32-bit CCDB to a 64-bit SQL Server, update your current AppManager
installation to AppManager version 7.0.3 and migrate your data. For more information about
updating to AppManager version 7.0.3, contact NetIQ Technical Support.

You can achieve the following results if you take regular, scheduled backups of the Control Center
repository:

 Ensure the integrity of the data stored in the Control Center repository.
 Provide a means for archiving historical information.
 Prevent data loss.
 Facilitate disaster recovery.

Although you can back up the repository manually at any time using SQL Server Management Studio
or with the SQL_RunSQL Knowledge Script, both Management Studio and the RunSQL script allow
you to automate backups by scheduling them to run at set intervals or at specific days and times.

The frequency of your backups depends on the nature of your environment, including the size of the
data and log files, the number of computers you monitor, the number of Knowledge Scripts you run,
and how quickly you acknowledge and close events.

As a general rule, perform a complete or incremental backup at least once a week.

For more information about preparing the CCDB for backup, backing up the CCDB, and restoring the
CCDB, see the Upgrade and Migration Guide for AppManager, available on the AppManager
Documentation page (http://www.netiq.com/documentation/appmanager). When preparing to back up
the CCDB, if you are only backing up the CCDB and not moving it to another computer, only perform
the steps related to the following:

 Noting properties for SQL Server logins

 Closing open connections
 Verifying that there are no open connections

8.4 Moving the Deployment Service to a New

Computer
If you want to move a Control Center Deployment Service to a new computer, after you install the
Deployment Service on the new computer and uninstall the Deployment Service on the old computer,
the old Deployment Service continues to be displayed in the list of Deployment Services in the
Deployment Rule Wizard.

To resolve this issue, in SQL Query Analyzer, run the following SQL statement on the Control Center
repository:

exec dplRemoveService 'Old_DeploymentService'

where Old_DeploymentService is the name of the computer where you uninstalled the Deployment
Service.

104 Managing Control Center

 For information about installing and uninstalling the Deployment Service, see the Installation Guide
for AppManager, available on the AppManager Documentation page (http://www.netiq.com/
documentation/appmanager).

8.5 Moving the Deployment Web Service to a New

Computer
You can move the Deployment Web Service to a new computer.

To move the Deployment Web Service to a new computer:

1 Install the new Deployment Web Service. For more information, see the Installation Guide for
AppManager, available on the AppManager Documentation page (http://www.netiq.com/
documentation/appmanager).
2 Update the Control Center preferences to specify the new Deployment Web Service. For more
information, see “Updating the Control Center Preferences to Specify the New Deployment Web
Service” on page 105.
3 Reconfigure any deployment services that use the Deployment Web Service as a proxy. For
more information, see “Reconfiguring Any Deployment Services That Use the Deployment Web
Service as a Proxy” on page 105.
4 Update your AppManager agents to communicate with the new Deployment Web Service. For
more information, see Section 8.5.3, “Updating Your AppManager Agents to Communicate with
the New Deployment Web Service,” on page 106.
5 Uninstall the existing Deployment Web Service. For more information, see Section 8.5.4,
“Uninstall the Existing Deployment Web Service,” on page 106.

8.5.1 Updating the Control Center Preferences to Specify the New

Deployment Web Service
In the Control Center console, on the Main tab of the ribbon, in the Tools group, click Options >
Deployment > General and update the Web server field to specify the name of the computer where
you installed the new Deployment Web Service.

8.5.2 Reconfiguring Any Deployment Services That Use the

Deployment Web Service as a Proxy
To reconfigure the Deployment Service:

1 Right-click the DeploymentService.exe.config file under <NetIQ-

install_path>\AppManager\Control Center\bin and click Properties.
2 In the Properties dialog box, remove the Read-only setting and click OK.
3 In the DeploymentService.exe.config file, under <appSettings>, change the value of the
ProxyWebService parameter to specify the new name of the Deployment Web Service, for
example:

<add key = "ProxyWebService" value = "DeploymentWebServer"/>

where DeploymentWebServer is the name of the computer where you installed the new
Deployment Web Service.
4 Close and save your changes to the DeploymentService.exe.config file.

Managing Control Center 105

 5 Restart the NetIQ AppManager Deployment Service for your changes to take effect.
6 Repeat these steps for each Deployment Service in your environment that uses the Deployment
Web Service as a proxy.

8.5.3 Updating Your AppManager Agents to Communicate with

the New Deployment Web Service
By default, if an agent does not contact the Deployment Web Service within three days, you cannot
deploy new installation packages to the agent without first restarting the AppManager agent. Until you
reconfigure your agents to communicate with the new Deployment Web Service, the Control Center
console will not display updated software inventory information.

To configure your agents to use the new Deployment Web Service, run the
AMAdmin_SetDeploymentWebService Knowledge Script.

8.5.4 Uninstall the Existing Deployment Web Service

For information about uninstalling the Deployment Web Service, see the Installation Guide for
AppManager, available on the AppManager Documentation page (http://www.netiq.com/
documentation/appmanager).

8.6 Moving the Command Queue Service to a New

Computer
You can move the command queue service to a new computer.

To move the command queue service to a new computer:

1 Run the following SQL statement to delete the command queue service setting from the Control
Center repository:

delete Property where Scope = 'cqs'

2 Install the command queue service on the new computer.

8.7 Changing the Log Path for the Command Queue

Service
You can change the folder location where the command queue service stores its log file.

To change the folder location:

1 On the command queue service computer, open the Services Control Panel and stop the NetIQ
AppManager Control Center Command Queue Service.
2 Right-click the NQCQS.exe.config file under <Netiq_install_path>\AppManager\Control
Center\bin and click Properties.
3 In the Properties dialog box, remove the Read-only setting and click OK.
4 In the NQCQS.exe.config file, under <appSettings>, change the value of the FilePath
parameter to specify the new file path for log file, for example:

<add key = "filepath" value = "e:\NetIQ_debug\CC_CQSTrace\"/>

106 Managing Control Center

 5 Close and save your changes to the NQCQS.exe.config file.
6 Open a Command Prompt and change directories to \NetIQ\AppManager\Control
Center\bin and run the following command:

nqcqs.exe -i

7 Restart NetIQ AppManager Control Center Command Queue Service.

8 Validate the log file exists in the specified folder location.

8.8 Changing the Log Path for the Deployment

Service
You can change the folder location where Deployment Service stores its log file.

To change the folder location:

1 On the Deployment Service computer, open the Services Control Panel and stop the NetIQ
AppManager Deployment Service.
2 Right-click the DeploymentService.exe.config file under
<NetIQ_install_path>\AppManager\Control Center\bin and click Properties.
3 In the Properties dialog box, remove the Read-only setting and click OK.
4 In the DeploymentService.exe.config file, under <appSettings>, change the value of the
FilePath parameter to specify the new name of the deployment web service, for example:

<add key = "filepath" value = "e:\NetIQ_debug\CC_ADTrace\"/>

5 Close and save your changes to the DeploymentService.exe.config file.

6 Restart the NetIQ AppManager Deployment Service for your changes to take effect.

8.9 Changing Configuration Parameters

In slow or busy network environments, you might encounter timeout exception errors in the
communication between the Control Center console and the Control Center repository. You can
change certain SQL connection and command/query parameters to better adapt console and
repository communication to your environment.

You can edit these parameters in standard .NET XML configuration files:

 AMCC.exe.config

AMCC.exe.config controls communication between the Control Center console and the CCDB.
 NQCQS.exe.config
NQCQS.exe.config controls communication between the CCDB and the QDBs you are
managing with Control Center.
 DeploymentService.exe.config
DeploymentService.exe.config controls communication between the Deployment Service
and the CCDB.

Before you edit these configuration files, contact Technical Support.

These configuration files are located in the same directory where the associated application or
service runs. The default location is C:\Program Files\NetIQ\AppManager\Control Center\bin.

Managing Control Center 107

 You can change the following parameters in both the NQCQS.exe.config file and the
AMCC.exe.config file:

Connection timeout (ConnectionTimeOut)

The time to wait (in seconds) before terminating an attempt to establish a connection to an
instance of SQL Server and generating an error.
The default value is 15 seconds.

Command timeout (CommandTimeOut)

The time to wait (in seconds) before terminating an attempt to execute a command and
generating an error.
The default value for NQCQS.exe.config is 600 seconds and for AMCC.exe.config the default
value is 90 seconds.

Packet size (PacketSize)

The size (in bytes) of network packets used to communicate with an instance of SQL Server.
The default value is 8192 bytes.

Retry count (RetryCount)

The number of times to retry a connection or command operation if the operation failed.
The default value is 1.

Log File Size (FileSize)

Specifies the maximum size, in bytes, for the log file. If the log file exceeds this threshold, a new
log file is created.

Number of Logs (NumBackups)

Specifies the maximum number of log files. When the maximum number is reached, the oldest
log file is overwritten.
The default value is 1.

Log File Path (FilePath)

The path on the command queue service computer for the log file.
The default path is: C:\<install
path>\NetIQ\temp\netiq_debug\CC_CQSTrace\CQSLog.txt.

TraceLevel (TraceLevel)
Specifies the level of tracing information you want in the log file. Do not change the trace level
unless instructed to do so by Technical Support. After Technical Support has diagnosed the log
files, return the tracing level to its original value. These are the available tracing levels:
 Off to disable logging for non-Error events.
 Error to log program exceptions to the Windows Event Log and the command queue
service (NQCQS.exe.config) or AMCC.exe.config log file. All critical messages are always
logged to the Windows Event Log. This is the default for NQCQS.exe.config.
 Warning to log program recoverable errors to the command queue service
(NQCQS.exe.config) or AMCC.exe.config log file. This is the default for AMCC.exe.config.
 Info to log program warnings and flow information to the command queue service
(NQCQS.exe.config) or AMCC.exe.config log file.
 Verbose to log program debug and trace information such as variable values and thread
state to the command queue service (NQCQS.exe.config) or AMCC.exe.config log file.

108 Managing Control Center

You can change the following additional parameters in the NQCQS.exe.config file:

ServerName
The name of the CCDB computer.

DBName
The name of the CCDB. You must specify the original SQL Server name and not an alias.
Otherwise, the command queue service will not be able to connect to the CCDB.

HealthCheckPoll
The interval at which AppManager checks the health of the command queue service and the
QDB. The default value is 30.

KSCheckPoll
The interval at which the command queue service looks for Knowledge Scripts in the CCDB that
need to be re-encrypted in an older security format (prior to version 8.0) for use in older QDBs.
The default value is 30

You can change the following parameters in the DeploymentService.exe.config file:

ServerName
Name and instance of the SQL Server that hosts the CCDB to which the Deployment Service
connects

DBName
Name of the CCDB to which the Deployment Service connects

ProxyWebService
Name of the Deployment Web Service computer with which the Deployment Service
communicates
The Deployment Service proxy capability is only active when firewalls are present. If firewalls are
not present, the value is empty.
NetIQ Corporation does not recommend changing this value.

PackagePathSetting
Location for Web Depot packages

NumBackups
Number of trace log backups stored in the
\Program Files\NetIQ\Temp\NetIQ_Debug\CC_ADSTrace folder
For more information about tracing, see the TraceLevel parameter.
The default value is 10.

FileSize
Maximum file size for the trace log files
When the log files reach this size, AppManager backs up the trace log to the
DeploymentServerZ.log file, where Z is an integer from 1 to the NumBackups value.
The default value is 5,000,000 bytes.

Managing Control Center 109

 FilePath
Location of the trace logs
The default value is
Program Files\NetIQ\Temp\NetIQ_Debug\CC_ADSTrace.

NumDeliveryThreads
Number of threads that will be available for executing tasks
The threads deliver and install files simultaneously.
The default value is 50 threads.

TraceLevel
Level of tracing information in the Deployment Service log files
The default value is Warning, which logs errors and warnings generated during Deployment
Service execution.
The following additional values are valid:
 Error
 Info
 Verbose
The default trace level is sufficient for normal testing and use. For troubleshooting, NetIQ
Corporation recommends the Info or Verbose settings.

NotificationEmailFromAddress
Email address for notifications about the success or failure of deployment tasks
Use the Deployment Rule Wizard in Control Center to configure the email settings. For
information about using the Deployment Rule Wizard, see the Control Center User Guide for
AppManager, available on the AppManager Documentation page (http://www.netiq.com/
documentation/appmanager).

In most cases the default settings for these parameters provide optimal performance. Any
adjustments you make to these settings will depend upon your environment and the kinds of
communication issues you are experiencing.

If you make modifications to the AMCC.exe.config file you must restart the Control Center console
for the changes to take effect. If you make modifications to the NQCQS.exe.config file, you must
restart the command queue service for the changes to take effect. If you make changes to the
DeploymentService.exe.config file, you must restart the Deployment Service for the changes to
take effect.

Parameter values you specify in the configuration files override any default values. If a value set in
one of these configuration files cannot be parsed into a number, the default value is used. If a value
falls outside the allowed range, the closest allowed value is used.

The NQCQS.exe.config file contains additional parameters that you can configure. For more
information about these additional parameters, see the Control Center User Guide for AppManager,
available on the AppManager Documentation page (http://www.netiq.com/documentation/
appmanager).

110 Managing Control Center

9 Advanced Configuration for
9

Management Servers

This chapter describes several ways you can customize and configure the operation of the
AppManager management server.

9.1 Rules for Management Servers

Under normal conditions, you should not run any regularly scheduled monitoring jobs or reports on
the computer you are using as the management server. If you avoid running jobs on the management
server, you prevent resource competition between the agent services and the management server
service and may improve management server processing capacity.

Specifically, you should avoid running jobs that perform remote monitoring operations. For example,
you should not run the following jobs on the management server:

 General_MachineDown
 NT_RemoteServiceDown
 General_EventLog and General_ASCIILog
 Any Report Knowledge Scripts

Instead of running these Knowledge Scripts on the management server, you should select a specific
agent computer to handle remote monitoring tasks and a specific agent computer for running reports.

In most cases, you can still use the remote monitoring Knowledge Scripts to monitor the availability of
the management server, for example, by specifying the name of the management server in the list of
computers to monitor when configuring the job, without running the job on the management server
itself. You can also use Troubleshooter and NetIQctrl commands to check the operation of the
management server and to diagnose problems and you can use the AMAdmin_MSHealth Knowledge
Script to monitor the Windows event log for events generated by the management server. For
information about using Troubleshooter and NetIQctrl, see Chapter 12, “Troubleshooting and
Diagnostic Tools,” on page 137.

9.1.1 Using Anti-virus Software

In addition to restricting the monitoring jobs you run directly on the management server, you should
use caution in running anti-virus software on the management server. In particular, you should not
perform any real-time anti-virus scanning of the following NetIQ folders:

 AppManager\dat\pioc
 AppManager\dat\mapqueue
 AppManager\bin\Cache
 Temp\NetIQ_Debug\computer_name

These folders are updated frequently, and real-time scanning can cause resource contention.
Therefore, you should exclude these folders from any anti-virus scanning activity.

Advanced Configuration for Management Servers 111

 9.1.2 Checking Management Server Status
As you increase the number of agents you monitor with a management server, it is also important to
monitor the operational health and performance of the management server itself. The key indicators
you should watch to determine the health of the management server are summarized in the following
table:

Performance Counter What to Look for

Processor: The percentage of processor time should remain less than or

equal to a maximum of 80%. Although occasional spikes can be
% Processor Time (All instances) expected, the average percentage of processor time should not
exceed 80%.

System: The number of threads in the processor queue should remain

less than or equal to a maximum of 3 ready threads per
Processor Queue Length processor.

If the number of threads in the processor queue begins to

increase, it may indicate that the management server is
becoming overloaded, for example, because it is attempting to
process a large number of events or data points or because a
slow connection has created a backlog of information to be
transmitted.

NetIQms: These counters should remain at or near zero (0), which

indicates the queues are not growing.
IOC Coll. Events Queued
The IOC counters refer to disk-based queues that are used to
IOC Data Queued store events and data when the management server is
temporarily busy. Over time these should remain near empty,
IOC Events Queued
indicating events and data are being processed in a timely
manner. If the queues grow over time, it indicates the
management server cannot keep up with the load created by the
agents.

If any of these counters consistently exceed the threshold indicated, or if the IOC counters grow
continuously, it is an indication that the management server is either handling too many agents or that
it is undersized for the load.

9.2 Changing the Polling Interval for Agent

Computers
Periodically, each management server in a site checks the status of its agent computers.

There are registry keys that control how the management server determines the status of the agent
computers it communicates with. These HKEY_LOCAL_MACHINE\Software registry keys are under
\NetIQ\AppManager\4.0\NetIQms\Config. Because communication is handled differently for
Windows agent computers and UNIX agent computers, there are separate keys for checking the
status of Windows agent computers and UNIX agent computers.

112 Advanced Configuration for Management Servers

9.2.1 Changing the Interval for Windows Computers
By default, the machine polling thread for Windows runs on the management server every 15
minutes. At each interval, the management server receives an updated list of its current agent
computers and checks the availability of the designated primary management server for those agent
computers.

Before changing this interval, you should evaluate the potential impact on your environment. If you
lengthen the interval, it will take longer for job property or job status changes to be passed to your
agent computers if the primary or backup management server fails. If you shorten the interval and
have a large number of agent computers, it will increase the processing load on the management
server and may degrade throughput performance. In general, if you have a large number of agent
computers, you should not change the machine polling interval.

To change the machine polling interval for Windows agent computers:

1 In the Windows Registry Editor, expand \HKEY_LOCAL_MACHINE, to

\SOFTWARE\netiq\appmanager\4.0\netiqms\config.
2 Double-click Machine Poll Interval to specify the number of seconds between updates. The
default is 900 seconds. If desired, you can click the Decimal option to display the current value
in decimal format.
3 Click OK.

9.2.2 Changing the Interval for UNIX and Linux Computers

For UNIX and Linux computers, the management server uses the agent heartbeat to determine the
status of its agent computers. The registry keys that control how the management server determines
the status of the NetIQ Corporation UNIX agents are the Unix Machine Check Interval and the
Unix Machine Timeout keys.

At each Unix Machine Check Interval, the management server checks the timestamp of the last
heartbeat signal from each of its UNIX agents. If the timestamp indicates that the UNIX agent has not
sent a heartbeat signal within the period of time specified for the Unix Machine Timeout, the
management server considers the UNIX agent unavailable and passes this information back to the
repository and the computer is grayed out in the Operator Console.

Before changing the interval or the timeout period, you should consider the potential impact on your
environment. If you lengthen the interval or the timeout setting, it may take longer to be notified when
UNIX agents stop communicating with the management server. If you shorten the interval or timeout
setting and have a large number of agent computers, it will increase the processing load on the
management server and may degrade throughput performance. You should also keep in mind that
these registry keys work in conjunction with each other so any changes should take in account both
values.

To change the Unix Machine Check Interval or the Unix Machine Timeout period:

1 In the Windows Registry Editor on the management server, expand \HKEY_LOCAL_MACHINE, to

\SOFTWARE\netiq\appmanager\4.0\netiqms\config.
2 Double-click Unix Machine Check Interval to specify the number of seconds between status
checks.
This interval controls how often the management server checks the timestamp of the last
heartbeat signal from each of its UNIX agents. The default is 300 seconds. If desired, you can
click the Decimal option to display the current value in decimal format.

Advanced Configuration for Management Servers 113

 3 Double-click Unix Machine Timeout to specify the maximum number of seconds between
heartbeat signals.
If the UNIX agent does not send a heartbeat signal within this period of time, it is deemed
unavailable. The default is 1200 seconds. If desired, you can click the Decimal option to display
the current value in decimal format.

NOTE: If you change the UNIX heartbeat interval, you may need to adjust the Check and
Timeout intervals. For example, if you set a longer heartbeat interval to conserve network
bandwidth, you should lengthen the Unix Machine Check and Unix Machine Timeout intervals to
prevent the UNIX agent from appearing to be unavailable between heartbeat signals.

4 Click OK.

After you modify the registry entries, you must restart the NetIQ Corporation AppManager
Management Service (NetIQms) for the changes to take effect. To restart the NetIQ Corporation
AppManager Management Service (NetIQms), use the Services Control Panel.

9.3 Changing the Listening Ports

By default, the computer you designate as a management server listens on port number 9001 for
communication from UNIX agents and on port 9999 for communication from Windows agents. You
can modify these default ports during installation or by modifying the registry on the management
server after installation.

To change the port numbers where the management server listens:

1 On the management server computer, from the Windows start menu, click Run, then type
regedt32.exe to start the Registry Editor.
2 Expand the HKey_Local_Machine\Software\NetIQ\AppManager\4.0\NetIQms registry key.
3 Doubleclick Port to change the port for Windows agents or Unix Port to change the port for
UNIX agents.
4 Select the Decimal option to display the current value in decimal format.
5 Type the port number you want to use.
6 Click OK.

For this change to take effect, you need to restart the computer.

After you change the registry entry for the Windows computer where the management server is
installed, you also need to update the agent computers with the appropriate information.

 For Windows agents, modify the registry key HKey_Local_Machine\Software\NetIQ\

AppManager\4.0\NetIQmc\NetIQms Port.
 For UNIX agents, you can change the port using UNIX Agent Manager, you can edit the default
configuration file, nqmcfg.xml, or you can create a new configuration file. For more information,
see the AppManager for UNIX Servers Management Guide, available on the AppManager
Modules Documentation page (http://www.netiq.com/documentation/appmanager-modules).

114 Advanced Configuration for Management Servers

9.4 Changing the Level of Detail in Trace Logging
By default, the management server records information about its operations in a log file. You can find
this log file, ms.log, in the NetIQ\Temp\NetIQ_debug\computer directory where NetIQ is the
AppManager installation path and computer is either the name of the computer where the
management server is installed or the directory specified for the
Software\NetIQ\AppManager\4.0\Generic\Tracing\ TraceLogPath registry key.

Typically, the information in the log contains little detail. You can, however, change the amount of
information recorded in the log file by modifying registry keys.

Enabling logging for some types of information, such as data point tracing, can affect the performance
of the management server. In most cases, you should use the default logging options unless you are
troubleshooting problems with the management server and have been instructed by NetIQ Technical
Support to trace additional information.

Changes to trace logging do not require you to restart the computer or the NetIQ Corporation
AppManager Management Service (NetIQms).

To change the level of logging detail for the management server:

1 On the management server computer, from the Windows start menu, click Run, then type
regedt32.exe to start the Registry Editor.
2 Expand the HKey_Local_Machine\Software\NetIQ\AppManager\4.0\NetIQms\Tracing
registry key. Within this key, there are several entries for tracing management server activity. By
default, all trace logging is disabled.
3 To enable tracing, select the type of tracing you are interested in, then doubleclick to open the
DWORD Editor. For example, select TraceSockets to trace socket communication between the
management server and UNIX agents or TraceRpc to trace the trace RPC communication
between the management server and Windows agents.
4 In the DWORD Editor, select the Decimal option to display the current value in decimal format.
5 Set the logging level to one (1) to enable logging or to zero (0) to disable logging for the type of
information you are interested in recording.
6 Click OK.

Your changes take effect immediately.

9.5 Moving the Management Server to a New

Computer
Moving the management server to a new computer requires ensuring that it will be able to
communicate with the QDB and agents after the move, installing a new management server on the
new computer, and uninstalling the management server from the old computer. For detailed
instructions about moving the management server to a new computer, see the Upgrade and Migration
Guide for AppManager, available on the AppManager Documentation page (http://www.netiq.com/
documentation/appmanager).

Advanced Configuration for Management Servers 115

116 Advanced Configuration for Management Servers
10 Advanced Configuration Options for
10

Windows Agents

This chapter describes several ways you can control the flow of information from agent computers
and customize the behavior of AppManager agents. Tuning the communication flow for agent
computers is optional, but it allows you to tailor when and how agent computers communicate with
the management server to suit your network requirements, bandwidth, latency, and operational
policies.

NOTE: Some of the configuration options available for Windows-based agents and UNIX-based
agents are similar but are controlled in different ways or through different scripts. If you are managing
both Window-based agents and UNIX-based agents, be sure to review both this chapter and the
AppManager for UNIX Servers Management Guide, available on the AppManager Modules
Documentation page (http://www.netiq.com/documentation/appmanager-modules).

10.1 Understanding the AppManager Agent

When you install the AppManager agent on a Windows computer, the following key components are
installed:

 NetIQ Corporation AppManager Client Resource Monitor agent service (netiqmc)

 NetIQ Corporation AppManager Client Communication Manager agent service (netiqccm)
 Local repository
 One or more objects for application monitoring (COM/OLE objects)

When you start a job, the Client Resource Monitor receives the job information from the management
server and replies to the management server with job status (whether the job started, failed, or
encountered an error).

In addition to notifying the management server of the job status, the Client Resource Monitor copies
the jobs it receives from the management server into the local repository. When the agent computer is
rebooted or services are stopped and restarted, the Client Resource Monitor reads the information
from the local repository and restarts all of the jobs that were running before the shutdown.

If the jobs assigned to the agent computer start successfully, the Client Resource Monitor runs the
local jobs, collects any data points and event information the jobs generate, and sends this
information to the Client Communication Manager.

When the Client Communication Manager receives data points and event information from the Client
Resource Monitor, it forwards the information to the management server as long as the management
server is available to receive the information. To ensure the availability of the management server, the
Client Communication Manager periodically runs a health check that polls the management server to
determine its availability. If the management server is unavailable, the Client Communication
Manager stores the information in the local repository until the management server becomes
available.

Advanced Configuration Options for Windows Agents 117

 The majority of advanced tuning options control communication between the agent services on the
agent computer and the management server. By customizing this flow of information, you can
optimize network communication to best suit your environment and network topology.

10.2 Understanding Agent Autonomy

As discussed in Section 10.1, “Understanding the AppManager Agent,” on page 117, the Client
Resource Monitor and the Client Communication Manager work together to start jobs automatically if
a computer is shut down and to retain information about jobs, events, and data in the agent
computer’s local repository if communication with the management server is interrupted. This default
behavior is called Autonomous operation.

Autonomous operation requires the following:

 The Client Communication Manager service must be running to log events and data points
locally on the agent computer when the agent cannot communicate with the management
server.
 The Client Communication Manager service must be configured to periodically poll the
management server and the Client Resource Monitor to determine the availability of the
management server and whether events and data points should be stored locally or uploaded to
the management server.

Although it ensures that data and events are not lost when communication with the management
server is interrupted, autonomous operation requires the Client Resource Monitor and Client
Communication Manager to be started together and to run continuously while a monitored computer
is powered up.

NOTE: If the Client Communication Manager service is stopped, the Client Resource Monitor can
send events and data directly to the management server. If the Client Communication Manager
service is running, events and data are always passed by that service unless you explicitly disable
Autonomy.

In some rare cases, you may need to temporarily disable Autonomous operation. If you disable
Autonomous operation, be aware of the following:

 The Client Resource Monitor agent service must be running for jobs to run and events and data
to be collected.
 The Client Resource Monitor agent service will bypass the Client Communication Manager and
send events and data directly to the management server, if needed, as long as the management
server is available. The Client Resource Monitor does not, however, write to the local repository.
If the Client Communication Manager is stopped and the Client Resource Monitor cannot
communicate with the management server, any event or data point generated while connectivity
is down is lost.

Because of this potential loss of data, you should always run both agent services in Autonomous
mode unless there is a specific need to temporarily stop the Client Communication Manager service
and you can ensure connectivity between the Client Resource Monitor and the management server.

118 Advanced Configuration Options for Windows Agents

10.2.1 Disabling Autonomous Operation
To turn off autonomy so that updates occur without being routed through the Client
Communication Manager service:

1 On the agent computer, in the Services Control Panel or from the command-line prompt, stop the
NetIQ AppManager Client Communication Manager and NetIQ AppManager Client Resource
Monitor services.
2 Start the Registry Editor and change the value of the following registry key from 1 (Autonomous
operation) to 0 (non-autonomous operation):
HKEY_LOCAL_MACHINE\Software\NetIQ\AppManager\4.0\Netiqmc\Config\Autonomy
3 In the Services Control Panel or from a command prompt, restart the AppManager services.

10.2.2 Controlling the Interval for Checking Connectivity

Periodically, the Client Communication Manager service checks the connectivity between the agent
computer and the management server. Two registry keys control the interval for this checking under
HKEY_LOCAL_MACHINE\Software\ NetIQ\AppManager\4.0\NetIQccm\Config:

Registry Key Interval Controlled

PingMSInterval Checking connectivity to each management server.

The default interval is 30 seconds.

PollMCInterval Polling the Client Resource Monitor service (NetIQmc) to find if there’s been
any data generated that needs to be sent to the management server.

The default interval is 5 seconds.

At each PollMCInterval, the Client Communication Manager (NetIQccm) service checks the Client
Resource Monitor for new event messages and collected data. If there have been any events or data
collected, the service processes the information and prepares to send it to the management server or
the local repository.

At each PingMSInterval, the Client Communication Manager checks whether it can communicate
with the management server. As it checks connectivity, the service sets a flag for each management
server to indicate whether communication was successful. If the flag indicates the agent computer
can successfully connect to a management server, all events and data points received are uploaded.
If the flag indicates the communication with the management server was not successful, the Client
Communication Manager sends events and data points to the local repository until the next
PingMSInterval.

Although you can adjust both of these intervals for checking connectivity, you should be careful about
doing so. For example, if you have a slow network connection between the agent computer and the
management server, you may want to lengthen the time for the PingMSInterval key, but this may put
a strain on the agent computer and its local repository or may prevent you from seeing problems
promptly.

Before changing these intervals for any agent computer, consider the following:

 The characteristics of the network connection between the managed computer and the
management server computer. For example, if you have a high-speed, LAN connection, you
should be able to maintain a shorter interval for checking the connection than if you have a WAN
connection.

Advanced Configuration Options for Windows Agents 119

  The characteristics of the managed computer in terms of available disk, memory, and CPU for
checking connectivity and storing data locally between connections to the management server.
 The type of monitoring you are doing and the intervals at which jobs run on the computer. For
example, if jobs are scheduled to run at 15 minute or one hour intervals, you are less likely to
generate a backlog of events and data points than when jobs run at two- or five-minute intervals.
 The frequency at which you are seeing events on the agent computer. For example, if events are
rare for a particular computer, you may feel more confident in increasing the PollMCInterval,
PingMSInterval, or both intervals.

10.3 Using a Windows User Account for Agent

Services
On each agent computer, the Client Communication Manager (NetIQccm) service and the Client
Resource Monitor (NetIQmc) service can run using either the LocalSystem account or a specific
Windows user account. Both services must use the same account on any single agent computer.
Although the LocalSystem account is used by default in most cases, there are many reasons to use
a specific Windows account instead.

You should use a Windows account for the Client Communication Manager (NetIQccm) and Client
Resource Monitor (NetIQmc) services if you are:

 Sending MAPI email from the agent computer as an action

 Enabling the reporting capability option on the agent computer to run reports
 Monitoring any Exchange Servers
 Monitoring SQL Server in Windows only authentication mode
 Running any jobs that require specific privileges or require a user account to perform specific
monitoring tasks

Normally, you specify whether you want to use the LocalSystem account or a Windows user account
when you install the AppManager agent. You can, however, change this information after installation,
using the Services Control Panel program. If you change the account information after installation, be
sure to use the same account for both agent services.

For information about Knowledge Scripts that have special requirements and changing the account
you use for the agent services, see the AppManager online help.

10.4 Account Permissions Used to Run AppManager

Agent services
If AD account “Without Admin Rights” on the domain fails to work, then you must 'Log on' as service
for Client Communication Manager (NetIQccm). The reason for the failure is AD account on a domain
works 'Log on' as service only if it is having admin rights.

Follow the steps to activate ‘Log on’ service:

 A domain account works as 'Log on' if it is having the admin rights defined in group policy (AD).
 A domain account with 'no admin rights' in group policy (AD) fails to start the service Client
Communication Manager (NetIQccm) as 'Log on.'
 If you want to make the non-admin domain account to work as 'Log on' for the agent services,
then that user should be part of the Local 'Administrators' group on the computer.

120 Advanced Configuration Options for Windows Agents

  The 'Local System Account' works fine as 'Log on' for both NetIQmc and NetIQccm.
 The 'System Admin account' works fine as 'Log on' for both NetIQmc and NetIQccm.

10.5 Restarting Agent Services

By default, the AppManager agent services are started automatically whenever you restart an agent
computer. Under normal conditions, the agent services are restarted using a warm startup that
preserves information about the jobs that were running when the computer was shut down.

When the agent services are restarted using a warm startup, the Client Resource Monitor
automatically restarts all of the jobs that were in progress when the computer is rebooted without
requiring you to take any additional action. Because all of the job information is preserved between
starts, an agent computer that uses a warm startup for the agent services is identified as being in
Persistent mode.

If an managed computer is set to use the Persistent mode, any time jobs are interrupted because of
power failures, system shutdowns, or network outages, the AppManager agent services are restarted
using a warm startup.

It is also possible to perform a cold startup of the agent services. With a cold startup, the Client
Resource Monitor does not remember the jobs that were running before the restart. Any monitoring
jobs that were running are lost.

10.5.1 Performing a Cold Startup of the AppManager Agent

By default, the Client Resource Monitor performs a “warm” startup anytime the service is interrupted.
This type of restart preserves information from ongoing jobs in the local repository. However, from
time to time you may find it useful to perform a “cold” startup, which doesn’t preserve information
about jobs or data. For example, if you have accumulated a large number of jobs on a particular
computer, you may want to remove those jobs and data.

To perform a cold startup, start the Client Resource Monitor service (NetIQmc.exe) using the -oa
option from the command-line. For example, open a Command window, then type the path to the
Client Resource Monitor service with these options:

C:\Program Files\NetIQ\AppManager\bin>netiqmc -oa

Once you perform a cold startup on an agent computer, you must run the discovery script, and then
recreate the jobs you want to restart. For example, if you have customized the properties for a
specific job but have not changed the default properties for the Knowledge Script, when you restart
the job you must restore the customized property settings, such as the changes to threshold settings
or data collection options. A cold start of the agent also deletes any delta discovery cache files for all
delta discoveries performed by the agent.

NOTE: Before performing a cold startup, consider running an AppManager job report to collect details
about the jobs you are running.

Advanced Configuration Options for Windows Agents 121

10.5.2 Setting the Agent Startup Mode
Normally, you only perform a cold startup of the AppManager agent if an agent service hangs on a
computer or if you want to remove unwanted information. But if you find that you want to use this
option regularly, you can manually instruct the Client Resource Monitor service to use the -o option at
startup.

To manually set the startup parameters for the agent:

1 Click Administrative Tools in the Windows Control Panel, then click Services.
2 Select NetIQ AppManager Client Resource Monitor in the list of services.
3 Click Stop to stop the service.
4 Type -o in the Start Parameters field.
5 Click Start, then click OK.

To change the default Client Resource Monitor startup mode, you must edit a registry key.

To change the default agent startup mode:

1 Use regedit to find the following registry key:

HKEY_LOCAL_MACHINE/SOFTWARE/NETIQ/AppManager/4.0/NETIQMC/CONFIG
2 Double-click Persistent.
3 Set the key value to 0 for a cold startup of the agent or to 1 for warm startup of the agent by
default.

10.6 Agent Self Monitoring

In addition to monitoring the operating system, server hardware, and application resources, most
organizations find it useful to monitor the operation of the AppManager components themselves. You
can choose from three basic methods for monitoring the operation of AppManager agents on your
Windows agent computers:

 Run the NT_RemoteServiceDown on one or more agent computers to remotely monitor the
NetIQ Corporation AppManager Client Resource Monitor and NetIQ Corporation AppManager
Client Communication Manager on other agent computers by listing the agent computer names
for the Machine list parameter and netiqmc.exe,netiqccm for the Services parameter.
 Run the AMAdmin_AgentSelfMon Knowledge Script to monitor the status of the scripting engine
and other low-level components that the Client Resource Monitor uses to ensure the agent is
running jobs properly.
When you run the AgentSelfMon Knowledge Script, the Client Resource Monitor sets a
timestamp in the Windows registry at each interval. At subsequent intervals, the Client
Communication Manager compares the timestamp value with a threshold that specifies the
maximum amount of time, in seconds, that can elapse between timestamps. If the age of the
timestamp value exceeds the threshold you specify, the Client Communication Manager
(netiqccm.exe) automatically restarts the Client Resource Monitor (netiqmc.exe). If the
timestamp is within an acceptable range, the job simply updates the timestamp value and waits
for the next iteration.
 Run the AMAdmin_AgentHealth Knowledge Script to monitor the Windows Application log for
events generated by the Client Resource Monitor and the Client Communication Manager that
indicate general, communication, job, security, or upgrade problems. Both services log specific

122 Advanced Configuration Options for Windows Agents

 “self-monitoring” information, which the AgentHealth Knowledge Script can check for. You can
further filter log entries by specifying a combination of include and exclude strings for the
Description field.
 Run the AMHealth_HeartbeatWin Knowledge Script to monitor the heartbeat of the AppManager
agent computer. A heartbeat is a periodic signal generated by an Appmanager agent computer
to indicate that it is still running. For more information, see the module management guide on the
AppManager Modules Documentation page.

10.7 Configuring Agents to Use a Hostname or IP

Address
In some environments, the NetIQ Corporation AppManager Client Communication Manager
(NetIQccm) may use an IP address instead of a hostname to locate and communicate with the
management server. However, using an IP address can be problematic. For example:

 If your management server and agent computers are connected through a remote dialup and
use DHCP, IP addresses are often assigned dynamically and change from one connection time
to the next.
 If your management server is installed on a cluster, you must use a virtual server name
associated with the cluster rather than a specific IP address.

NOTE: AppManager currently supports only Microsoft clusters.

 If you plan to periodically replace the computer you use as the management server, you may find
using a hostname for communication is more convenient to change and less error-prone than
maintaining an IP address.

For each management site, you should decide whether you want the NetIQ Corporation AppManager
Client Communication Manager to use an IP address or hostname to locate the management server.

Once you select the best approach for your environment, you can use the
AMAdmin_ConfigSiteCommType Knowledge Script to set or change the communication type. For
more information about using this Knowledge Script, consult the online Help.

10.8 Configuring the Size of a Local Repository

In some environments, it is useful to be able to control the maximum size of the local repository to
prevent a data or event “storm” from impacting performance. For example, if an agent computer is
unable to connect to its management server for an extended period, it may generate a large number
of redundant events that must be stored locally that you are not interested in transferring to the
management server and repository when communication is restored. By limiting the size of the local
repository, you can control both the strain put on the agent computer and the potential bottleneck
involved in transferring a large number of unwanted events to the management server.

You can use the AMAdmin_SetLocalRPSize Knowledge Script to control the maximum number of
events or data points that can be stored in an agent computer’s local repository. If the agent computer
is not able to communicate with the management server, the local repository for the agent computer
will store the most recent events and data points up to this limit until communication with the
management server is restored.

Advanced Configuration Options for Windows Agents 123

 NOTE: If the number of events or data points exceeds the limit you have set (for example, because of
an extended network interruption), the oldest event or data records are lost as new events or data
points are recorded.

In deciding how to configure the number of rows for events and data in the local repository, assume
that 1000 rows is roughly equivalent to 1 MB. You should also consider the types of jobs you run on
the agent computer and the frequency with which you collect data. In a typical environment, you are
more likely to generate a large number of data points for reporting purposes than a large number of
events. For this reason, you may want to reduce the number of rows you reserve for events and
increase the number of rows you reserve for data points on some of your agent computers.

You can use the SetLocalRPSize Knowledge Script in conjunction with the
AMAdmin_SiteSchedUpload Knowledge Script to establish a schedule for the communication
between each agent computer and its management server. You can also use the SetLocalRPSize
Knowledge Script in conjunction with AMAdmin_SchedMaint Knowledge Script to set storage
restrictions on data and events when a computer requires maintenance or in conjunction with the
AMAdmin_DisableSiteComm and AMAdmin_EnableSiteComm Knowledge Scripts when you need to
temporarily disable network communication with the management server.

For more information about using any of these Knowledge Scripts, double-click the Knowledge Script
in the View pane of the Control Center console, select the Values tab, and click Help.

10.9 Adjusting the Flow of Network Traffic

The AMAdmin_ConfigSiteNetFlowCtrl Knowledge Script helps you manage network bandwidth and
control the transfer of data from agent computers to the management server to suit your network
capacity and make data transfers more efficient. With this Knowledge Script, you can restrict the
amount of data the NetIQ Corporation AppManager Client Communication Manager sends at any
one time and the frequency with which data is transferred by defining upper and lower bandwidth
limits for the size of message batches transferred.

For example, assume you define a high watermark of 100 KB, a low watermark of 2 KB, and a
communication interval of one hour (3600 seconds). With this configuration, the Client
Communication Manager sends up to 100 KB of data per hour to the management server until the
data waiting to be transferred falls below 2 KB. The Client Communication Manager then stores the
data in the local repository. At the next interval, if the data to be transferred is greater than 2 KB,
NetIQccm resumes sending the data to the management server. If the data package is still below 2
KB, Client Communication Manager continues to store the data in the local repository until the next
interval.

The AMAdmin_ConfigSiteNetFlowCtrl Knowledge Script also provides dynamic tuning to allow the
Client Communication Manager to respond to load changes on the management server. With
dynamic tuning, each time the Client Communication Manager connects to transfer data, it checks
the management server’s current load. If the management server is busy and load has increased, the
Client Communication Manager reduces the data sent and increases the communication interval. The
Client Communication Manager continues to reduce the data sent until the amount of data falls below
the low watermark or until the load on the management server decreases.

For more information about using this Knowledge Script, double-click the Knowledge Script in the
View pane of the Control Center console, select the Values tab, and click Help.

124 Advanced Configuration Options for Windows Agents

10.10 Scheduling the Transfer of Events and Data
The AMAdmin_SiteSchedUpload Knowledge Script is used to specify a schedule for uploading data
and events from an agent computer’s local repository to the current management server.

This Knowledge Script allows you to store data points and events in the local repository until you’re
ready to upload it to the management server. By giving you the flexibility to transfer events and data
during off-peak hours or when network traffic is light, the AppManager management server and
repository can handle data from more servers and you can better manage network bandwidth.

For example, if you are collecting a significant amount of data on a few key agent computers, you
may want to store the data locally on those agent computers while the network is busy, then transfer
it to the management server at a time you know network traffic is light. In addition, you can schedule
data from different agent computers to be uploaded at staggered times, further reducing the load on
the management server and repository.

You can set up specific schedules for data, events, or both, as needed. The Client Communication
Manager stores the events or data points in the local repository until the scheduled upload time. At
upload time, Client Communication Manager reads the events or data points from the local repository
and sends them to the management server.

The SiteSchedUpload Knowledge Script is often used in conjunction with other Knowledge Scripts to
provide maximum control over data transfers:

 You can configure the size of message batches delivered in the upload with the
AMAdmin_ConfigSiteNetFlowCtrl Knowledge Script. For more information, see Section 10.9,
“Adjusting the Flow of Network Traffic,” on page 124.
 You can configure the maximum number of data points or events to store in the local repository
with the AMAdmin_SetLocalRPSize Knowledge Script. For more information, see Section 10.8,
“Configuring the Size of a Local Repository,” on page 123.

Best Practices. Configuring your agent computers to immediately forward events while storing
performance data locally provides you with maximum flexibility in determining your transfer strategy
without affecting event notification. If you are monitoring a WAN environment, however, you should
use the SiteSchedUpload and ConfigSiteNetFlowCtrl Knowledge Scripts to control the data transfers
from your remote agent computers to the management server.

For more information about using any of these Knowledge Scripts, double-click the Knowledge Script
in the View pane of the Control Center console, select the Values tab, and click Help.

10.11 Configuring Designated Management Servers

As discussed in “Setting up Primary and Backup Management Servers” on page 41, the agent on
each managed computer should be configured to use one primary management server and one
backup management server to provide predictable failover support and static load distribution. For
Windows agents, you designate the primary and backup management server during installation or by
running the AMAdmin_SetPrimaryMS Knowledge Script. You can also use the
AMAdmin_SetPrimaryMS Knowledge Script to change the primary management server, the
secondary management server, or both.

Once you explicitly designate a primary management server, the agent services communicate
exclusively with that management server.

Advanced Configuration Options for Windows Agents 125

10.11.1 Changing Agent Failover Configuration
By default, the Client Resource Monitor attempts to communicate with the primary management
server once every minute to determine its availability. If the attempt to connect to the primary
management server fails in three consecutive tries, the Client Resource Monitor determines the
primary management server is not available and notifies the Client Communication Manager to begin
sending events and data to the backup management server until it is able to re-establish
communication with the primary management server.

You can change both the default interval and the number of connection attempts the Client Resource
Monitor uses to determine the availability of the primary management server by modifying the
Windows registry.

To change the failover configuration for an agent computer, expand the

\HKEY_LOCAL_MACHINE\SOFTWARE
\NetIQ\AppManager\4.0\NetIQmc\config folder:

Registry Key to Edit Description

PrimaryMSFailOverCtrlTimes The number of times the Client Resource Monitor should attempt
to connect to the primary management server before failing over
to a backup management server. The default is 3 attempts.

You may want to increase this value if there are frequent, brief
interruptions in communication or you decrease the interval. In
general, you should not set this value to less than the default.

PrimaryMSFailOverInterval The number of seconds between attempts to communicate with

the primary management server. The default is 60 seconds.

You may want to increase this value if there are frequent, brief
interruptions in communication or if you use a schedule for
transferring data from the agent computer. In general, you should
not set this value to less than the default.

Before changing the failover configuration, you should consider the network connection between the
specific agent computer and the management server. If they are connected through a wide area
network or have a slow connection, you may need to increase the failover interval to prevent frequent
or unnecessary failover. In practice, having an agent computer fail over from a primary management
server to a backup management server should be a rare event and any changes to the failover
interval or number of connection attempts should reflect this.

10.11.2 Removing a Designated Management Server

Normally, once you have explicitly designated a primary management server and a backup
management server, there’s no need to remove the designation using the
AMAdmin_RemovePrimaryMS Knowledge Script. Instead, you can change the primary management
server, the secondary management server, or both with the AMAdmin_SetPrimaryMS Knowledge
Script. In some rare cases, however, you may want to remove a designation entirely for a computer.

Running AMAdmin_RemovePrimaryMS removes the primary and backup designations stored in the
registry, potentially allowing any management server available to communicate with the agent
computer, depending on the version of the AppManager agent installed and how you have configured
management server restrictions with the AMAdmin_AgentConfigMSRestrictions Knowledge Script.

126 Advanced Configuration Options for Windows Agents

 Keep in mind that you should only allow an undesignated management server to communicate with
an agent computer if you are:

 Using a single management server and you are unsure of the management server name or
suspect an incorrect name has been recorded (for example, because it has been edited
manually after installation).
 Changing your site configuration from a multiple management server environment to a single
management server environment and you are unsure of the management server name.
 Temporarily decommissioning both the primary management server and the backup
management server and want to use any available management server until the primary and
backup management servers are available or until you identify new management server names
or IP addresses to explicitly designate as the new primary management server and the new
backup management server.

For more information about using any of these Knowledge Scripts, double-click the Knowledge Script
in the View pane of the Control Center console, select the Values tab, and click Help.

10.12 Manually Controlling Network Communication

You can use the AMAdmin_DisableSiteComm Knowledge Script to temporarily disable network
communication from a Windows agent computer to the management server and repository. When
communication is manually disabled with this Knowledge Script, information about events, data, and
job status is stored in the local repository. The information in the local repository is then transferred to
the management server when communication is re-enabled with the EnableSiteComm Knowledge
Script. As discussed in Section 10.9, “Adjusting the Flow of Network Traffic,” on page 124, you can
use the AMAdmin_ConfigSiteNetFlowCtrl Knowledge Script to configure the size and frequency of
the batches to be transferred when communication is re-enabled.

These Knowledge Scripts allow you to intentionally stop the communication between agent
computers and management servers, and by extension, their respective site repositories, at any time.
For example, if you are experiencing network problems, you may want to temporarily disable
communication while you troubleshoot the problem or if you are experiencing high network activity,
you may want to disable communication to store data locally on an agent computer until the demand
for server bandwidth is reduced.

For more information about using any of these Knowledge Scripts, double-click the Knowledge Script
in the View pane of the Control Center console, select the Values tab, and click Help.

10.13 Controlling Access to an Agent’s Local

Repository
You can use standard Windows file system security to control who can access the local repository on
an agent computer.

To set specific permissions for individual users or for groups:

1 Select the local repository file. By default, the local repository is located in the AppManager
installation folder under NetIQ\AppManager\db\Local-Repository.sqlite. For example, if
you installed the AppManager agent in the folder C:\Program Files\NetIQ\AppManager, the
default location for the local repository is C:\Program Files\NetIQ\AppManager\db\Local-
Repository.sqlite.
2 Right-click the file, then click Properties.

Advanced Configuration Options for Windows Agents 127

 3 Click the Security tab.
4 Click Add to add users and groups to the access control list, if needed.
5 Select the permissions you want to Allow or Deny for each user and group. For example, to
prevent a user or group from accessing the local repository, in the Deny column click Full
Control. Similarly, to give a user or group permission to view but not to modify the local
repository, in the Allow column click Read.

NOTE: In setting permissions for users and groups, be sure you do not change the permissions
for the account the agent services use. If the agent services on an agent computer run under a
Windows user account, that account must be allowed Full Control for the local repository file.

If users are denied access to the local repository and attempt to open the file, they will see a
message similar to the following:
6 Click OK when you have finished setting user permissions to access the local repository.

128 Advanced Configuration Options for Windows Agents

11 Developing Scripts to Perform
1

AppManager Tasks

AppManager allows you to automate many common tasks using command-line scripts and calls to
the NetIQOLE automation object. This chapter discusses several sample scripts included with
AppManager and explains how they are used to perform common AppManager tasks. For
information about the NetIQOLE object, see the NetIQ OLE Object Reference Guide for
AppManager, available on the AppManager Documentation page (http://www.netiq.com/
documentation/appmanager).

11.1 Understanding Command-line Scripting

AppManager allows you to automate many common tasks using command-line scripts and calls to
the NetIQOLE automation object. The NetIQOLE automation object uses the ODBC SQL Server
driver to connect to the SQL Server where a QDB has been installed and can be used in conjunction
with a scripting host to enable you to perform many AppManager activities without using the Operator
Console interactively. Command-line scripts can be especially powerful because they give you the
flexibility to create batch files that can:

 Encapsulate multiple activities

 Automate frequent tasks
 Run unattended to perform tasks at off-peak hours
 Carry out site-specific policies

For example, you may want to create batch files that start jobs or automatically acknowledge certain
types of events.

To illustrate how you can use NetIQOLE in scripts, AppManager includes several sample scripts
located in the c:\Program Files\NetIQ\AppManager\scripts folder on the computer where the
Operator Console is installed.

NOTE: For more detailed information about using NetIQOLE object calls and the methods and
properties available, see the NetIQ OLE Object Reference Guide for AppManager, available on the
AppManager Documentation page (http://www.netiq.com/documentation/appmanager).

Developing Scripts to Perform AppManager Tasks 129

 11.2 About the Sample Command-line Scripts
AppManager includes several sample command-line scripts and a sample scripting host, netiqcmd,
for running the scripts. These sample scripts only illustrate a few common activities. Depending on
your level of programming skill and knowledge of AppManager, far more complex scripting is possible
through NetIQOLE.

The following sample command-line scripts are available:

Script Name Description

ackevent.vbs Acknowledges an existing AppManager event.

AddChildJob.vbs Adds a child job to an existing parent job.

AddToMonPolicy.vbs Adds a Knowledge Script group to a monitoring policy.

CloseEvent.vbs Closes an existing AppManager event.

CloseJob.vbs Closes an existing AppManager job.

CreateJob.vbs Creates a new AppManager job on a specified target computer.

CreateKSGroup Creates a new Knowledge Script Group.

DeleteEvent.vbs Deletes an existing AppManager event.

DeleteJob.vbs Deletes an existing AppManager job.

DumpGraph.vbs Dumps graph data from a data stream in comma-delimited form to the computer
screen or a file.

KSCheckin Checks a Knowledge Script into the QDB.

KSCheckout Checks a Knowledge Script out of the QDB.

RemoveFromMonPolicy Removes a Knowledge Script Group from a monitoring policy.

RemoveKSGroup Deletes a Knowledge Script Group.

StartJob.vbs Starts an existing AppManager job.

StartKSGroup Creates new jobs based on the members of the Knowledge Script Group.

StopJob.vbs Stops an existing AppManager job.

Refer to the command-line reference Help for each sample script to determine the information each
script requires to run. For example, the AckEvent.vbs script requires the event ID.

At a command prompt, type netiqcmd.exe and the script name. For example, to display usage
information for the AckEvent.vbs script, type:

c:\Program Files\NetIQ\AppManager\scripts\netiqcmd.exe ackevent.vbs

The Help includes a brief description of the sample script, a usage example, and a list of script
parameters.

130 Developing Scripts to Perform AppManager Tasks

11.3 Running AppManager Command-line Scripts
To run AppManager command-line scripts, you must log on to the AppManager repository with a SQL
Server login account that has permission to access AppManager.

Open a command prompt, and type the path to netiqcmd.exe, followed by the command-line script
filename and one or more required and optional parameters. For example:

c:\Program Files\NetIQ\AppManager\bin\netiqcmd.exe startjob.vbs /jobid=19

Include the path to netiqcmd.exe if you plan to run the script (or a batch file with a script command-
line statement) from a scheduling program, such as the Task Scheduler. It is not necessary to include
the path to the command-line script file.

NOTE: The required and optional parameters required vary depending on the purpose of the script.
All scripts require information for logging on to the QDB. You can specify the logon information at the
command-line or by creating a default logon profile in a text file.

If you have Windows Scripting Host (WSH) installed in your environment, you can also run scripts
using WSH instead of using netiqcmd.exe. The syntax for running scripts with Windows Scripting
Host is similar. For example:

cscript deleteevents.vbs /eventid=5

11.4 Creating a Default Logon Profile

All AppManager command-line scripts require you to log on to an AppManager repository. By default,
AppManager scripts use the following login information:

Logon Parameter Default

/USER Windows user account name with which you logged on.

/PASSWORD Password for the current Windows user account.

/SERVER Windows name of the local computer.

/DATABASE Repository name of QDB.

To create your own default logon profile for AppManager scripts, add a section called [Default
Logon] to the netiq.ini file (located in the %SYSTEMROOT% directory) and enter the logon
parameters. For example:

[Default Logon]
USER=FRED
PASSWORD=SCOOTER
SERVER=SHASTA
DATABASE=MY_QDB
DEBUGGING=TRUE

NOTE: In creating a default logon profile, consider your security requirements. For example, you may
want to include only the /SERVER and /DATABASE parameters, requiring the /USER and /
PASSWORD parameters to be entered at the command-line.

Developing Scripts to Perform AppManager Tasks 131

 If you do not want to include the password in a default logon profile, change the SQL Server security
mode to minimize the arguments entered at the command-line.

With Windows Authentication or Mixed security modes, SQL Server uses Windows security to
authenticate a Windows user at the computer where the script is being run. The Windows user is
allowed to log on if authenticated by SQL Server. In this case, only two parameters (/DATABASE and /
SERVER) are required to log on. These can be included in the netiq.ini file or entered at the
command-line.

11.5 Creating Jobs

The CREATEJOB.VBS script creates a new job on a specific computer. This script does not allow you to
set properties from the command-line. Therefore, you should use this script only when creating jobs
that use default Knowledge Script properties or when you have created custom Knowledge Scripts
with the appropriate properties, including the scheduling interval, parameter values, actions, action
parameters, and advanced options.

The following example illustrates the command-line statement for this script:

c:\Program Files\NetIQ\AppManager\bin\netiqcmd.exe createjob.vbs

/user=miles /password=pwd /server=shasta /database=qdb1 /ksname=NT_CpuLoaded /
target=mango

This script uses the following command-line arguments:

Parameter Description

/USER username of the SQL Server login account used to access the AppManager repository.

Not required if using Windows authentication.

/PASSWORD Password for the SQL Server login account.

Not required if using Windows authentication.

/SERVER Windows name of the server where the AppManager repository you want to work with
is installed.

The default is the name of the local computer. Not required if using the default.

/DATABASE Name of the AppManager repository you want to work with.

The default AppManager repository name is QDB. Not required if using the default.

/DEBUGGING Flag to turn on debugging. If set to TRUE, the script displays descriptive information
about any SQL errors that occur in a message box.

The default is FALSE. Not required if using the default.

/KSNAME Name of the Knowledge Script you want to run on the selected computer. Include the
category prefix for the Knowledge Script. For example, Winbasic_CpuLoaded.

Be sure the Knowledge Script properties have been set properly and saved, either
under the existing Knowledge Script name or with a new Knowledge Script name.

This parameter is required.

132 Developing Scripts to Perform AppManager Tasks

 Parameter Description

/TARGET Name of the computer where you want the Knowledge Script to run. You can only
specify one computer name. Server groups and multiple computer names are not
supported.

This parameter is required.

11.6 Starting, Stopping, Closing, and Deleting Jobs

Use these AppManager command-line scripts to work with existing jobs:

 STARTJOB.VBS changes the state of the job to running.

 STOPJOB.VBS changes the state of the job to stopped.
 CLOSEJOB.VBS changes the status of the job to closed.
 DELETEJOB.VBS deletes the job.

The following example illustrates the syntax for these scripts:

c:\Program Files\NetIQ\AppManager\bin\netiqcmd.exe closejob.vbs

/server=srv1 /user=miles /database=qdb /jobid=5

All of these scripts use the following command-line arguments:

Parameter Description

/USER Username of the SQL Server login account used to access the AppManager repository.

If using Windows authentication, this parameter is not required.

/PASSWORD Password for the SQL Server login account.

If using Windows authentication, this parameter is not required.

/SERVER Windows name of the server where the AppManager repository you want to work with
is installed.

The default is the name of the local computer.

Not required if using the default.

/DATABASE Name of the AppManager repository you want to work with.

The default AppManager repository name is QDB.

Not required if using the default.

/DEBUGGING Flag to turn on debugging. If set to TRUE, the script displays descriptive information
about any SQL errors that occur in a message box.

The default is FALSE.

Not required if using the default.

/JOBID Identifier for the existing job you want to start, stop, close, or delete. This parameter is
required. For example:

/jobid=5

Developing Scripts to Perform AppManager Tasks 133

 11.7 Acknowledging, Closing, and Deleting Events
Use these AppManager command-line scripts to work with existing events:

 ACKEVENT.VBS acknowledge the event.

 CLOSEEVENT.VBS closes the event.
 DELETEEVENT.VBS deletes the event.

The following example illustrates the syntax for these scripts:

C:\Program Files\NetIQ\AppManager\bin\netiqcmd.exe ackevent.vbs

/server=srv1 /user=miles /password=pwd /database=qdb1 /eventid=5

All of these scripts use the following command-line arguments:

Parameter Description

/USER username of the SQL Server login account used to access the AppManager repository.

If using Windows authentication, this parameter is not required.

/PASSWORD Password for the SQL Server login account.

If using Windows authentication, this parameter is not required.

/SERVER Windows name of the server where the AppManager repository you want to work with
is installed.

The default is the name of the local computer. If using the default, this parameter is not
required.

/DATABASE Name of the AppManager repository you want to work with.

The default AppManager repository name is QDB. If using the default, this parameter is
not required.

/DEBUGGING Flag to turn on debugging. If set to TRUE, the script displays descriptive information
about any SQL errors that occur in a message box.

The default is FALSE. If using the default, this parameter is not required.

/EVENTID Identifier for the event you want to acknowledge, close, or delete. This parameter is
required. For example:

/eventid=5

11.8 Exporting Data Streams

The DUMPGRAPH.VBS script exports data streams in comma-delimited format to a computer screen or
text file.

The following is an example of the syntax for exporting data to the screen:

c:\Program Files\NetIQ\AppManager\bin\netiqcmd.exe dumpgraph.vbs

/server=srv1 /database=qdb1 /graphid=5

The following is an example of the syntax for exporting data to a file:

c:\Program Files\NetIQ\AppManager\bin\netiqcmd.exe dumpgraph.vbs

/user=miles /password=pwd /server=srv1 /database=qdb /graphid=5 > output.txt

134 Developing Scripts to Perform AppManager Tasks

 This script uses the following command-line arguments:

Parameter Description

/USER Username of the SQL Server login account used to access the AppManager repository.
Not required if using Windows authentication.

/PASSWORD Password for the SQL Server login account. Not required if using Windows
authentication.

/SERVER Windows name of the server where the AppManager repository you want to work with
is installed.

The default is the name of the local computer.

Not required if using the default.

/DATABASE Name of the AppManager repository you want to work with.

The default AppManager repository name is QDB.

Not required if using the default.

/DEBUGGING Flag to turn on debugging. If set to TRUE, the script displays descriptive information
about any SQL errors that occur in a message box.

The default is FALSE. Not required if using the default.

/GRAPHID Identifier for the existing graph data stream you want to output. This parameter is
required. For example:

/graphiid=20

/SHOWUTC Flag to control date formatting. If set to TRUE, date/time fields are displayed in
Coordinated Universal Time (UTC) format. If set to FALSE, date/time fields are
converted to a mm/dd/yy hh:mm:ss format. This parameter is not required.

11.9 Scheduling Scripts to Run

You can use the Microsoft Task Scheduler or another scheduling tool to create automated tasks to
execute one or more AppManager command-line scripts on the computers you choose. To do this,
you should create a batch file that starts the scripting host and runs the script(s) that perform the
AppManager task you want to automate. For example, if you are using one of the sample command-
line scripts provided with AppManager, the batch file might look similar to this:

REM
call c:\program files\netiq\appmanager\bin\Netiqcmd.exe startjob.vbs /
SERVER=alien1 /DATABASE=NYQDB /JOBID=22

NOTE

 The scheduling program you use must interact with the Desktop and allow you to log on as a
specific Windows user. Service-based scheduling programs such as SQL Server Management
Studio (with its Scheduled Task feature) and the Windows AT command do not meet these
requirements. They only allow you to log on under the system account, which doesn’t have the
full set of permissions needed to run AppManager command-line scripts, and they do not allow
the command-line script to interact with the Desktop.
 Be sure to modify the command-line statement in the batch file to reflect the proper path to the
scripting host and valid logon information for the repository.

Developing Scripts to Perform AppManager Tasks 135

11.10 Getting Help for Sample Scripts
Information is available to help you run AppManager command-line scripts. At a command prompt,
type netiqcmd.exe and the script name. For example, to display usage information, type:

c:\Program Files\NetIQ\AppManager\scripts\netiqcmd.exe startjob.vbs

The Help includes a brief description of the sample script, a usage example, and a list of script
parameters.

136 Developing Scripts to Perform AppManager Tasks

12 Troubleshooting and Diagnostic Tools
12

This chapter describes how to use AppManager diagnostic tools and utilities to retrieve information
about the NetIQ Corporation AppManager Management Service and AppManager agents and to
identify problems within your environment. These tools and utilities allow you to view current activity
and configuration settings for specified computers and are used primarily for diagnostic analysis and
troubleshooting.

12.1 Understanding What AppManager Provides

AppManager provides several ways for you to uncover information about the activity of AppManager
components and your AppManager deployment and locate and resolve any problems that may
prevent you from monitoring your environment. With these troubleshooting and diagnostics tools, you
can check AppManager activity, network communication, and configuration information for your agent
computers, management servers, and the management site.

The following tools are available to perform these tasks:

 Troubleshooter is available through the Control Center console and the Operator Console and
enables you to report information about management server and agent communication, server
maintenance, job status, and configuration details such as a computer’s time zone setting and
upload schedule.
 NetIQCtrl provides a command line interface for accessing the information available using the
Troubleshooter and options for a small number of additional reports that are not available
through the Troubleshooter.
 NetIQ Diagnostics gathers log files and registry information for AppManager components. You
can run the NetIQ Diagnostics utility on any computer that has at least one AppManager
component installed.
 Tracing registry keys and component log files allow you to configure the level of log file
tracing for AppManager components. Component log files can provide detailed information
about the activity of AppManager components, depending on the level of tracing enabled.
Changing the level of tracing may require editing the registry, however, and therefore should only
be done if you have exhausted other sources of information or are instructed to do so by NetIQ
Technical Support.
 Log Analysis Tool parses UNIX agent log files to consolidate job information, making the file
contents easier to interpret.
 The AM Self Monitoring module, also known as AM Health, provides monitoring of the health
and availability of SQL Server resources for the QDB, the Management Server, and the Control
Center components, as well as monitoring of the AppManager agent heartbeat. For more
information, see the module management guide on the AppManager Modules Documentation
page.

Troubleshooting and Diagnostic Tools 137

 12.2 Using the Troubleshooter
The Troubleshooter utility provides access to many different types of diagnostic reports about
AppManager management servers and agent services through an easy-to-use console interface.
Through the Troubleshooter, you can retrieve information about management server and agent
communication, detailed and summary job status, detailed operational statistics, and configuration
details such as a computer’s time zone setting and upload schedule.

The Troubleshooter is not applicable when diagnosing issues on UNIX or Linux computers.

12.2.1 Starting Troubleshooter

To use the Troubleshooter:

1 Open the Control Center console.

2 Select a Server view in the Enterprise Layout pane.
3 Right-click a server in the View pane, click Utilities > Job Troubleshooter, and then select a
specific Troubleshooter report to view. For example, click Utilities > Job Troubleshooter > Event
Collapsing Summary.
For information about the information types and specific reports, see Section 12.2.3, “Selecting
Specific Troubleshooter Reports,” on page 140.
4 Once you select a report, the Troubleshooter window is displayed with the information you have
selected displayed in the right pane.

NOTE: You can choose to hide or display the toolbar and status bar can by selecting Toolbar or
Status Bar from the View menu. When displayed, a check mark appears by the menu item.

5 Once you open the Troubleshooter window, it remains displayed, allowing you to select
additional computers and reports, until you close the window by clicking File > Exit.

138 Troubleshooting and Diagnostic Tools

12.2.2 Generating Reports from within Troubleshooter
Once you have opened Troubleshooter from the Operator Console, you can generate additional
reports for one or more computers or domains in your environment.

To generate reports with TroubleShooter:

1 Select the computers or domains you want to generate reports for by checking the box next to
the computer or domain name.
 If you check a domain, Troubleshooter generates diagnostic reports for each computer
within that domain.
 If you check Entire Network, Troubleshooter generates diagnostic reports for all of the
computers in all of the domains.
 If you select one or more computers within a domain, Troubleshooter generates
diagnostic reports only for the computers you have checked.

2 After selecting the appropriate computers and domains, click

Files > Troubleshooter > information type > report to display the report in the Information pane.
For information about the information types and specific reports, see Section 12.2.3, “Selecting
Specific Troubleshooter Reports,” on page 140. Depending on the report select, you may need
to use the scroll bar to see an entire report.

NOTE: The information for any new report you run is appended to any existing information in the
Information pane. The pane is not cleared of previous information until you explicitly decide to do
so. Appending the information in this way allows you to scroll through or export all of the
information for a computer or group of computers without having to rerun reports. For more
information, see Section 12.2.4, “Clearing the Diagnostic Report’s Information Pane,” on
page 142.

3 To close Troubleshooter, click File > Exit from the menu.

Accessing Diagnostic Reports

Once the Troubleshooter window is displayed, you can access specific diagnostic reports by doing
either of the following:

 From the File menu, click Troubleshooter > information type.

 In the Computer List pane, right-click and click Troubleshooter > information type.

Troubleshooting and Diagnostic Tools 139

12.2.3 Selecting Specific Troubleshooter Reports
Troubleshooter reports are organized by the type of information they provide. For each information
type, you can select from several different reports to investigate specific areas of interest. In some
cases, reports may overlap and provide similar information or give you the option to view information
in summary or in detail form.

Before you select a specific report, you need to identify the general type of information you are
interested in reviewing from the following information types:

 “Job Info Reports” on page 140

 “Client Resource Monitor Info Reports” on page 141
 “Client Communication Manager Info Reports” on page 141
 “Management Service Info Reports” on page 142

When you click an information type, you will see a list of the specific reports associated with that type.
All of the reports are based on the output from NetIQCtrl commands. If you are not sure which
report to run, you may want to review the sample output for each report by looking up the
corresponding NetIQCtrl command in Section 12.3, “Using the Command-line Program NetIQctrl,”
on page 143.

Job Info Reports

Job Info reports provide detailed and summary information about the jobs that are running, stopped,
or pending on the selected agent computer or group.

Report Description

Job Summary Summary of all running and stopped or completed jobs for an agent
computer. This report displays the output from the job command.

Event Collapsing Summary Summary of event collapsing information including the collapse
interval and the number of collapsed events for all jobs on an agent
computer. This report displays the output from the jobevt command.

Maintenance Summary Status information for jobs that are inactive on an agent computer
during scheduled maintenance periods. This report displays the output
from the jobrsc command.

Event Collapsing Detail Detailed event collapsing information for all jobs on an agent
computer. This report displays the output from the profevt
command.

Job Detail Detailed information about all jobs running on an agent computer. This
report displays the output from the profile command.

Maintenance Detail Detailed status information for jobs that are inactive on an agent
computer during scheduled maintenance periods. This report displays
the output from the profrsc command.

140 Troubleshooting and Diagnostic Tools

Client Resource Monitor Info Reports
Client Resource Monitor Info reports provide information about the operation, connectivity, and
configuration for the NetIQ AppManager Client Resource Monitor service running on the selected
agent computer or group.

Report Description

Active Management Servers A list of management servers that are communicating with an agent
computer and the network communication status. Displays output from
the listms command.

Application Monitoring Status A list, by application, of jobs running on an agent computer and the
applications affected by scheduled maintenance periods. Displays
output from the listrsc command.

Time Zone Setting The time zone setting of an agent computer. Displays output from the
localtime command.

Connectivity Verification that the Client Resource Monitor service is running on the
server and configuration information for the service. Displays output
from the ping command.

Statistics Statistical information collected by the Client Resource Monitor service

on an agent computer. Displays output from the stat command.

Upload Schedule The upload schedule that has been defined on an agent computer for
all management sites. Displays output from the uploadsched
command.

Client Communication Manager Info Reports

Client Communication Manager Info reports provide information about the operation, connectivity,
and configuration for the NetIQ AppManager Client Communication Manager service running on a
selected agent computer or group.

Report Description

Connectivity Verification that the Client Communication Manager service is running

on the server and configuration information for the service. Displays
output from the ping command.

Active Management Sites A list of all management sites that are monitoring an agent computer
and configuration information for the Client Communication Manager.
Displays output from the listsite command.

Statistics Statistical information collected by the Client Communication Manager

service on an agent computer. Displays output from the stat
command.

Troubleshooting and Diagnostic Tools 141

 Management Service Info Reports
Management Service Info reports provide information about the operation, connectivity, and
configuration of the NetIQ AppManager Management Server service and the agent computers for
which the management server is responsible.

Report Description

Configuration Information Configuration information for a management server. Displays output

from the infoconfig command.

Managed Client Information Information collected by a management server for all agent
computers. Displays output from the machine command.

Time Zone Setting The time zone configuration of a management server. Displays output
from the localtime command.

Connectivity Verification that the NetIQ Corporation AppManager Management

Service is running on the server and configuration information for the
service. Displays output from the ping command.

Management Site Information Information about the management site that a management server is
configured to monitor. Displays output from the site command.

Statistics Statistical information collected by the Management Server service on

a management server. Displays output from the stat command.

Threads Control thread statistics maintained by a management server.

Displays output from the thread command.

12.2.4 Clearing the Diagnostic Report’s Information Pane

Unless you clear the Information pane, the information for any new report you run is appended to any
existing information in the Information pane. Having new information appended to existing information
allows you to scroll through or export all of the information for a computer or group of computers
without having to rerun reports.

When attempting to diagnose activity on multiple computers or running multiple reports, however, you
may want to clear the Information pane periodically to make the reports more readable.

To clear all information from the Information pane, click Information > Clear from the menu or
click the Clear Information button on the toolbar.

12.2.5 Exporting a Diagnostic Report

The information returned by Troubleshooter can be exported to a text (.TXT) file.

To export a diagnostic report to a text file:

1 In the TreeView pane, right-click and select Export or click the Export button on the toolbar.
2 In the Save As dialog box, select a location to save the file and name the report.

NOTE: If the file already exists, the information is appended to the end of the file.

3 Click Save As.

142 Troubleshooting and Diagnostic Tools

 12.3 Using the Command-line Program NetIQctrl
The NetIQctrl command-line program is an interactive program that allows you to view current
activity and configuration settings for specified computers. It is used primarily for diagnostic analysis
and troubleshooting.

Most of the information available through NetIQctrl commands is also available by clicking
TreeView > Troubleshooter in the Operator Console. The command output is identical to what’s
displayed in the Troubleshooter Information pane. However, some report options are only available
from the command line using NetIQctrl.

12.3.1 Starting NetIQctrl

You can start the NetIQctrl program from the AppManager Operator Console by clicking
Extensions > NetIQCtrl, or from a Command Prompt window by running the executable
NetIQctrl.exe (located in the AppManager bin directory).

Once you start the NetIQctrl program, you enter commands on the command line. The general
format for NetIQCtrl commands is:

command hostname component [options …]

Parameter Description

command One of the available NetIQCtrl commands.

hostname The name or IP address of the computer where the AppManager management server
or agent is running.

In the syntax descriptions:

 ms_hostname indicates you should use the name of the computer where the
management server is running.
 mc_hostname.indicates you should use the name of an agent computer.
component The appropriate AppManager component.

 NetIQms
 NetIQmc
 NetIQccm
Some commands can apply for more than one component, but you can only retrieve
information for one component at a time.

In addition, some commands require you to use a keyword in the command line to
control the information retrieved.

[options …] One or more optional parameters, such as a job ID number, that limit or refine the type
of information that the command displays.

Troubleshooting and Diagnostic Tools 143

12.3.2 Available NetIQctrl Commands
The following table lists the NetIQctrl commands and describes how to use them. Most commands
include an example of the output they produce. These examples are only intended to illustrate the
type of information returned. You may see different or additional information when you run these
commands.

Command Description

debug Sets a debug category and level to start tracing activity on a management server or an
agent computer. The debug command is for diagnostic purposes only and is therefore of
primary interest to programmers who are developing custom Knowledge Scripts.

The categories and levels you specify depend on the component, NetIQmc or NetIQms,
you want to trace. The higher you set the debugging level, the more verbose the debugging
output. The basic syntax is:

debug mc_hostname NetIQmc debug_category debug_level

debug ms_hostname NetIQms debug_category debug_level

For example, to set moderate tracing for the AppManager agent on the agent computer
shasta, use:

debug shasta NetIQmc MC_ALL 256

To control where tracing output is sent, use the output command.

For a list of tracing categories and levels, use the info command.

144 Troubleshooting and Diagnostic Tools

Command Description

dictget Displays Server-Side Job Configuration (SSJC) parameters from an agent's local
repository. The basic syntax is:

dictget mc_hostname NetIQmc [ms_host] param_name|get_all

You can retrieve:

 All of the Server-Side Job Configuration parameters in the dictionary using the
get_all keyword.
 Parameters with a specific name or with names that start with a specific string using a
wild card (for example, _NQ_L*). Note that only trailing wild cards are supported. You
can't specify a pattern such as *logical*.

To retrieve Server-Side Job Configuration parameters associated with a specific

AppManager repository, specify the name of a management server that communicates with
that repository.

For example, if the agent computer starlet is managed by two management servers,
sunset and venice, with data and events stored in separate repositories, you may want to
specify which repository you are interested in by including the management server name in
the command line:

dictget starlet NetIQmc venice get_all

Output example

Results for site VENICE1029277802_1029277802:

_NQ_LogicalDisk_DriveList = c:,d:
_NQ_LogicalDisk_TH_FREE = 10
_NQ_LogicalDisk_TH_READS = 50
_NQ_LogicalDisk_TH_UTIL = 90
_NQ_LogicalDisk_TH_WRITES = 50
_NQ_LogicalDisk_TH_XFERS = 80
_NQ_Service_ExcludeList =
_NQ_Service_ServiceList = EventLog

exit Exits NetIQctrl. The basic syntax is:

exit

Troubleshooting and Diagnostic Tools 145

 Command Description

healthcheck Verifies that the job information stored in the AppManager repository is in sync with the
agent’s job information. Under normal conditions, the agent sends its job list to the
management server periodically and the management server compares this list to the job
list stored in the repository to ensure they are the same. This command allows you to
check this activity.

This command provides the following information:

 The job list retrieved from the repository, the job list retrieved from the agent and the
time the management server last performed the comparison.
 The time of the last job check that the management server sent to the agent for
verification of the job list if the management serve didn't receive the job list from the
agent.
 The number of jobs and the job IDs of jobs waiting in the cache. Pending jobs are
stored temporarily in the management server cache only if they are detected when
the management server retrieves agent information from the repository.

This command can be useful if you are trying to determine whether changes to job status
or the job list are being handled properly for an agent computer. For example, if a job
appears to remain in a Pending state or has been stopped but still appears to be running in
the Operator Console, you can use this command to see the time of the last status check
by the management server and the list of active jobs from the repository and the agent.

The basic syntax is:

healthcheck ms_hostname NetIQms mc_hostname

Output example

---------------------------
Health Check Info
---------------------------
Last Health Check Time: 1029354749
Job List from Repository: 12 18 20 22
Job List from Agent: 22 18 20 12
Last Job Check Time: 1029269190
Job List to Agent: 22
Number of Jobs in Cache: 0
Job List in Cache: None

help Displays the list of commands and usage information for NetIQctrl. The basic syntax is:

help

You can also use a question mark (?) to display help.

146 Troubleshooting and Diagnostic Tools

Command Description

info Displays a list of symbol-to-number mappings that can be used with the debug command
to set the category and level of tracing information returned from a Knowledge Script while
it is running. The basic syntax is:

info

Output example

(Tracing Categories)
MC_CORE, 65
MC_RPC, 66
MC_VBA, 67
MC_CALLBACK, 68
MC_REPOSITORY, 69
MS_MS, 85
MS_MC, 86
MS_RP, 87
-------
(Tracing Levels)
LEVEL_VERBOSE, 65535
LEVEL_TRACE, 256
LEVEL_CRITICAL, 64

When specifying the debug category or level, you can use either the symbol (such as
MC_CORE or LEVEL_VERBOSE) or the number mapping (such as 65 or 65535).

For example, to start tracing for the agent computer named shasta, you can use either:

debug shasta netiqmc MC_VBA LEVEL_TRACE

or

debug shasta netiqmc 67 256

To control where tracing output is sent, use the output command.

Troubleshooting and Diagnostic Tools 147

 Command Description

infoconfig Displays configuration information for a management server. Some configuration

parameters, such as polling intervals, control the behavior of a management server and
can be used to fine-tune its performance.

The basic syntax is:

infoconfig ms_hostname NetIQms

For example, to list the configuration for the management server olympus, use:

infoconfig olympus netiqms

Output example

----------------------------------------------------
MS Configuration Info
----------------------------------------------------
** connectivity
MS Port : 9999
MC Port : 9998
rpc comm wait : 5000
ccm flow ctrl : enabled
** execution
mode : service
start time : Tue Aug 13 10:04:53 2002
** repository
server : OLYMPUS
site name : OLYMPUS1028146695
repository name : QDB
ms UUID : c6ebacea-50d9-4e73-8e0f-f7654c713
dsn : QDBms
user name : netiq
machine id : 34
machine name : OLYMPUS
wait on rp failure : 300
rp retry : 0
** ioc threads
data worker : 2
event worker : 1
** thread sleep intervals
job poll : 5
job stat : 300
job stat ip refresh : 1000
unix machine check : 300
unix machine timeout: 600
machine poll : 900
machine ping : 5
all machines ping : 0
** event config
record type : create open events (default)
cache list max : 10
collapsed ioc retry : 1
** data config
data batching : on
data retry : 1

148 Troubleshooting and Diagnostic Tools

Command Description

job Displays a summary of the jobs on an agent computer. For more detailed job information,
use the profile command.

The job command is useful for verifying the state of a job. For example, if a job appears in
Pending state in the Operator Console, you can use the job command to determine
whether the job has started on the agent computer. If the job has started on the agent
computer but the Operator Console shows it as pending, you would want to investigate the
connections between the agent computer, the management server, and the repository. The
basic syntax is:

job mc_hostname NetIQmc [option]

Use the optional parameter to specify the type of job you want to display:

 run for jobs that are currently running, including jobs that are in an active, inactive,
and scheduled state.
 done for jobs that stopped recently.
 active for jobs that are currently running and active.
 inactive for jobs that are running but are inactive, for example because of a
scheduled maintenance period.
 sched for jobs that are waiting for the start of their next scheduled running period.
You can check the status of a specific job by specifying the management server name that
started the job and the job ID.

To see a list of all jobs on the agent computer named paris, use:

job paris NetIQmc

Output example

----------------------
Running Jobs
----------------------
22_AJAX1028146695_1028146695 : thread=2012 15 <worker running> <sleeping>
18_AJAX1028146695_1028146695 : thread=2144 15 <worker running> <sleeping>
20_AJAX1028146695_1028146695 : thread=768 3 <worker running> <sleeping>
12_AJAX1028146695_1028146695 : thread=1652 14 <worker running> <sleeping>
-------------------------------
Stopped/Completed Jobs
-------------------------------
40_AJAX1028146695_1028146695 : Wed Aug 14 11:52:23 2002
42_AJAX1028146695_1028146695 : Wed Aug 14 11:56:30 2002
+++++++ total 2 completed jobs
+++++++ total 4 running jobs

Troubleshooting and Diagnostic Tools 149

 Command Description

jobevt Displays event summary information for all jobs or for a specific job on an agent computer.
The jobevt command is useful for verifying the number of events generated by a specific
job. For example, you might compare the number of events reported by the jobevt
command with the number of events displayed in the Operator Console for that job. If the
numbers don’t match, you might want to investigate the connections between the agent
computer, the management server, and the repository.

For detailed event collapsing information, use the profevt command.

The basic syntax is:

jobevt mc_hostname NetIQmc [ms_hostname job_id]

The optional parameters let you specify a job ID. To identify a specific job, you must also
provide the name of the management server that started the job.

For example, to see the event collapsing information for job number 20, which is running
on the agent computer named shasta and was scheduled by the management server
ajax, use:

jobevt shasta netiqmc ajax 20

Output example

----------------------
Running Jobs
----------------------
Job [20] =>
KS Name : 1702:NT_LogicalDiskBusy
QDB Site : AJAX1028146695_1028146695
QDB Site UpdTime : 1028146695
MS machine : AJAX <10.5.10.92>
Collapse Intv : 1200 sec
Occur Interval : 1
[1029258286_2] inst 5 non_collapse 5 collapse 0 (cur=0)
Job [12] =>
KS Name : 1702:General_ServiceDown
QDB Site : AJAX1028146695_1028146695
QDB Site UpdTime : 1028146695
MS machine : AJAX <10.5.10.92>
Collapse Intv : 1200 sec
Occur Interval : 1
[1029258286_5] inst 1 non_collapse 1 collapse 24 (cur=24)
+++++++ total 2 running jobs

jobmod Indicates the time of the last modification to a job’s properties. The modification time is
displayed in UTC format. The basic syntax is:

jobmod ms_hostname NetIQms job_id

Output example

---------------------------
Job Modification Info
---------------------------
job id: 4
last mod time (utc): 1029432427
last status: 513

150 Troubleshooting and Diagnostic Tools

Command Description

jobrsc Displays status information for jobs that are inactive on an agent computer during a
maintenance period. Maintenance periods are set by Knowledge Script category. The
jobrsc command includes standard job information, a resource ID for each Knowledge
Script category running on the agent computer, the number of job iterations skipped
because of maintenance, and the last time an iteration was skipped.

The jobrsc command is useful for determining how many times a job has not run because
of a maintenance period. For example, you may be trying to discover why a job has not
generated the expected number of data points. You can use the jobrsc command to
determine how many times the job did not run, which could explain why fewer data points
were collected.

The basic syntax is:

jobrsc mc_hostname NetIQmc [ms_hostname job_id]

Optional parameters let you specify a job ID. To identify a specific job, provide the name of
the management server that scheduled it.

For example, to display information about skipped iterations for all jobs on the agent
computer named shasta:

jobrsc shasta NetIQmc

Output example

----------------------
Running Jobs
----------------------
Job [62] =>
KS Name : NT_CpuResource
QDB Site : OLYMPUS904955486_904955487
QDB Site UpdTime : 904955487
MS machine : OLYMPUS <10.1.10.65>
Job Status : worker running
RSC ID : 0
# Skipped Iter : 0
Iter Skip Time :
Job [66] =>
KS Name : SQL_DataSpace

QDB Site : OLYMPUS904955486_904955487

QDB Site UpdTime : 904955487
MS machine : OLYMPUS <10.1.10.65>
Job Status : Inactive
RSC ID : 1

# Skipped Iter : 18
Iter Skip Time : Tue Sep 10 14:46:40 2002
+++++++ total 2 running jobs

Troubleshooting and Diagnostic Tools 151

 Command Description

jobsched Displays scheduling information for a specific job. Basic syntax:

jobsched mc_hostname NetIQmc ms_hostname job_id

For example, to see scheduling information for job ID 68, which is running on the agent
computer named shasta and was scheduled by the management server named olympus,
use:

jobsched shasta netiqmc olympus 68

Output example

--------------------------
Job Scheduling Info
--------------------------
Job [68__OLYMPUS904955486_904955487] ==>
Type: on demand
Recur Type: INTERVAL ITERATION
Interval: 5 min

jobstat Displays statistics for a specific job running on an agent computer. For example, jobstat
displays the number of events, data headers, data points, and agent computer actions
generated by the job. The basic syntax is:

jobstat mc_hostname NetIQmc ms_hostname job_id

For example, to display information for job number 62, running on the agent computer
shasta and was scheduled by the management server olympus, use:

jobstat shasta netiqmc olympus 62

Output example

Job [62_OLYMPUS904955486_904955487] =>

#-Generated #-Failed
---------- ----------- ----------
Event 4 0
CtrlEvt 1344 0
DataHead 1 0
DataLog 22 0
MCAction 0 0

ks Displays the Knowledge Script of a specified job that is currently running on an agent
computer. The basic syntax is:

ks mc_hostname NetIQmc ms_hostname job_id

NOTE: This command is not supported for version 4.0 and later Knowledge Scripts.

152 Troubleshooting and Diagnostic Tools

Command Description

listfc Displays the current network configuration and flow control information between an agent
computer and the management server that it is communicating with. The basic syntax is:

listfc mc_hostname NetIQccm site|ms ms_hostname

 Use the site keyword to extract information from the Client Communication Manager
using the repository name.
 Use the ms keyword to extract information using the management server hostname.
The information returned should be the same, whether you use the site or ms keyword.

For example, to see network configuration and flow control information between the agent
computer named shasta and the management server named olympus, use:

listfc shasta netiqccm site olympus

Output example

----------------------------------------------
List CCM Current Site Network Info
----------------------------------------------
netsrv thread id 2460
MS hostname OLYMPUS <10.5.111.139>
MS network status up
Communication mode uploadInProcess
Current high watermark 100 kb
Current low watmermark 0 kb
Current batching interval 1000 sec
Last net transaction Time Thu Aug 15 12:23:20 2002

Troubleshooting and Diagnostic Tools 153

 Command Description

listms Displays a list of all management servers that are communicating with a specified agent
computer. The list indicates the number of running jobs that were started from each
management server and the state of the connection between the agent computer and each
management server. The basic syntax is:

listms mc_hostname NetIQmc

For example, to see information about the management servers that communicate with the
agent computer named paris, use:

listms paris netiqmc

Output example

----------------------------------------------
List MS
----------------------------------------------
OLYMPUS1029277802_1029277802
Current MS => 10.5.11.39 OLYMPUS
Job Refcnt => 3
Use MS IP => 1
MS status => Up
Send via => ccm
AJAX1029363296_1029363296
Current MS => 10.5.10.92 AJAX
Job Refcnt => 2
Use MS IP => 1
MS status => Down
Send via => ccm

This example indicates that the agent computer paris communicates with two
management servers, olympus and ajax. Three jobs were submitted from the
management server olympus and two jobs were submitted by the management server
ajax.

Because communication between the agent computer and the management server ajax is
down, data and events for the two jobs submitted by ajax are being stored locally on the
agent computer. Data and events from the three jobs submitted by olympus are being
uploaded via the Client Communication Manager because communication between that
management server and agent computer is working correctly.

The Use MS IP parameter indicates whether the communication between the agent
computer and management server is established using the management server’s IP
address or hostname. A value of 1 indicates the communication uses the management
server’s IP address. A value of 0 indicates communication is established using the
hostname.

154 Troubleshooting and Diagnostic Tools

Command Description

listrsc Displays a list of all categories of jobs running on a agent computer and indicates which
categories are affected by scheduled maintenance periods. Each job category is identified
by a resource ID. The resource ID is specific to each agent computer. For example, if two
SQL Knowledge Scripts are running on an agent computer, both jobs will have the same
resource ID. However, that resource ID for SQL Server jobs on that agent computer will not
necessarily match the resource ID for SQL Server jobs on other agent computers.

For each category of Knowledge Script affected by a scheduled maintenance, the jobrsc
command provides additional detail about the maintenance period.

The basic syntax is:

listrsc mc_hostname NetIQmc

For example, to display a list of all categories of Knowledge Scripts running on the agent
computer named shasta:

listrsc shasta netiqmc

Output example

---------------------
RSC Info
-----------------------
<RSC #0> :
Name => NT
JobCnt => 2
Status => NotScheduled

ResDepend =>
SvcDepend =>
<RSC #1> :
Name => SQL
JobCnt => 1
Status => Inactive

ResDepend =>
SvcDepend =>
#-KPC-#
Type: scheduled
Recur Type: DAILY
Recur Freq: every <1> day(s)

Start Time: 14:00:00

End Time: 17:59:00
Interval: 5 min

Troubleshooting and Diagnostic Tools 155

 Command Description

listsite Displays a list of all QDBs monitoring an agent computer. The basic syntax is:

listsite mc_hostname NetIQccm

For example, to list all the QDBs that are monitoring the agent computer named paris,
use:

listsite paris netiqccm

Output example

----------------------------------------------
List CCM Site Info
----------------------------------------------
[SITE #1]
QDB Name VENICE1029277802_1029277802
QDB Key 32c368bf-36a0-401f-b64c-5ee5547cc689
QDB Updtime 1029277802
MS hostname VENICE <10.5.11.52>
CCM comm id 3
Server thread id 1060
Startup Time Wed Aug 14 14:19:07 2002
Reference Count 1
[SITE #2]
QDB Name LONDON1028151606_1028151607
QDB Key ae215a98-dbdb-4d9f-a13e-22b8a33a083d
QDB Updtime 1028151607
MS hostname LONDON <10.5.18.42>
CCM comm id 2
Server thread id 1560
Startup Time Fri Aug 02 11:30:52 2002
Reference Count 1
[SITE #3]
QDB Name MILAN1027112432_1027112433
QDB Key dfdb0224-fef3-4e51-b05d-5454ae4034f6
QDB Updtime 1027112433
MS hostname MILAN <10.5.11.61>
CCM comm id 1
Server thread id 1012
Startup Time Thu Jul 25 17:09:28 2002
Reference Count 1

156 Troubleshooting and Diagnostic Tools

Command Description

listupload Lists the scheduled upload status that a QDB has registered with the Client
Communication Manager service on an agent computer. This command lists the upload
status of both events and data. The basic syntax is:

listupload mc_hostname NetIQccm site|ms ms_hostname

 Use the site keyword to extract information using the repository name.
 Use the ms keyword to extract information using the management server hostname.
The information returned should be the same, whether you use the site or ms keyword.

For example, to list upload information for the agent computer named paris and the
management server on the computer named olympus, use:

listupload paris netiqccm site olympus

Output example

----------------------------------------------
List CCM Site Upload Configuration
----------------------------------------------
QDB Site Name OLYMPUS1029277802_1029277802
QDB Site Updtime 1029277802
MS hostname OLYMPUS <10.5.11.39>
Event Upload active
Data Upload active

Troubleshooting and Diagnostic Tools 157

 Command Description

machine Displays computer- or monitoring-related information that a management server has

collected for all agent computers or a specified agent computer. The information displayed
includes:

 Remote Procedure Call communication version and the time the agent computer was
last pinged.
 The time of the last job status check between the management server and the agent
computer, the number of start and stop job requests submitted, the current
outstanding job (if any), the time the current job was submitted, and the number of
jobs that may have been skipped because of this job.
 Time zone information for the agent computer.
The basic syntax is:

machine ms_hostname NetIQms [mc_hostname]

If you do not specify a specific agent computer, the machine command displays cached
information for all agent computers that the management server is currently aware of.
Because this operation is more expensive in terms of system resources, it is usually better
to specify a specific agent computer.

For example, to display the information that the management server named olympus has
cached at the agent computer named paris, use:

machine olympus netiqms paris

Output example:

----------------------------------------------------
MS Cached Machine Info
----------------------------------------------------
PARIS:
** connectivity
rpc comm version : 2.4.0
last ping success : Thu Aug 15 11:47:39 2002
last ping fail : Tue Aug 13 15:47:31 2002
** jobs
last job status success : Tue Aug 13 16:02:31 2002
last job status fail : none
start requests submitted : 9
stop requests submitted : 1
current job request : 0
time job submitted : Wed Aug 14 15:41:03 2002
jobs skipped : 0
** time zone
name : Pacific Standard Time
daylight savings name : Pacific Daylight Time
bias : 28800
active bias : 25200
daylight savings : applicable

158 Troubleshooting and Diagnostic Tools

Command Description

netconf Lists the user-specified network configuration that a specific QDB or management server
has registered with the Client Communication Manager (NetIQccm) service on an agent
computer. The information includes the flow control configuration and the communication
type.

The basic syntax is:

netconf mc_hostname NetIQccm site|ms ms_hostname

 Use the site keyword to extract information by specifying the repository name.
 Use the ms keyword to extract information by specifying the management server
hostname.

For example, to display the network configuration information that the management server
named olympus has registered with the agent computer named paris, use:

netconf paris netiqccm site olympus

Output example:

-----------------------------------------------
List CCM Site Network Configuration
-----------------------------------------------
MS hostname OLYMPUS <10.5.11.39>
RPC connection caching disabled
Communication type ipaddr
Communication encryption Off
Communication mode uploadScheduled
Net high watermark 100 kb
Net low watermark 0 kb
Net batching interval 1000 sec
Dynamic Flow Control disabled

Troubleshooting and Diagnostic Tools 159

 Command Description

output Specifies where to send the debug tracing output collected from a agent computer or
management server. The basic syntax is:

output mc_hostname NetIQmc [option]

output ms_hostname NetIQmc [option]

Optional parameters turn tracing off or direct output:

 off turns off tracing output.

 here displays the output in the NetIQctrl window.
 console displays the output in the console window.
 log displays the output in the Windows event log.
 file file_name stores the output in a file.
For example, to direct tracing for the AppManager agent on the agent computer named
shasta to the file trace.txt, use:

output shasta NetIQmc file trace.txt

To view tracing for the AppManager agent on the agent computer named shasta in the
NetIQctrl window, use:

output shasta NetIQmc here

Output example:

NetIQctrl> 10.1.1.163: [484] MCRunJob: finished processing job

<45_SHASTA880588204>, ms=<10.1.1.163>

NOTE: The debugging output will be intermixed with your commands.

160 Troubleshooting and Diagnostic Tools

Command Description

ping Checks connectivity and displays version and configuration information for an agent
computer or a management server. If a connection is made, the ping command displays
the version number and startup information for the AppManager service running on the
specified computer.

The basic syntax is:

ping mc_hostname NetIQmc [ext]

ping ms_hostname NetIQms

The optional ext keyword displays extended configuration for the agent computer. The
additional information indicates whether the agent is running in autonomous mode,
whether data persistence is enabled, the communication protocol for the local repository
and for the management server, and how tracing is configured.

For example, to check whether the AppManager agent is running on the agent computer
named shasta, use:

ping shasta NetIQmc

Output example:

version 4.6.31.0
start_mode Service
start_time Wed Aug 14 15:25:16 2002
trace_level 1
rpc version 4.0
rpc port # 9998

If the AppManager agent isn’t running on shasta, you see:

Failed to connect to mc

NOTE: Generally, the AppManager agent uses port 9998, and the management server
uses port 9999.

probe Sends a probe request to the computer where the management server service (NetIQms)
or agent service (NetIQmc) is located. If the service is running, the issue, arrival, and return
times are displayed. The basic syntax is:

probe mc_hostname NetIQmc

probe ms_hostname NetIQms

For example, to test the communication between the computer paris and the computer
where the AppManager agent is running, use:

probe paris NetIQmc

Output example:

1029437586 - ctrl
1029437586 - paris <NetIQmc>
1029437586 - ctrl

NOTE: Inconsistent arrival times are generally caused by different internal clock settings
on the two computers.

Troubleshooting and Diagnostic Tools 161

 Command Description

profevt Displays detailed event collapsing information for all jobs or a specific job on an agent
computer. For a summary of event collapsing information, use the jobevt command. The
basic syntax is:

profevt mc_hostname NetIQmc [ms_hostname job_id]

For example, to see detailed event collapsing information for job 6 on the agent computer
paris and scheduled by the management server named olympus, use:

profevt paris netiqmc olympus 6

Output example:

Job [6] =>

KS Name : NT_CpuResource
QDB Site : OLYMPUS1029363296_1029363296
QDB Site UpdTime : 1029363296
MS machine : OLYMPUS <10.5.10.92>
Collapse Intv : 1200 sec
Occur Interval : 1
---------------------------
Event Id : 1029363916_9
Severity : 5
Object list :
Event Message : Number of Processes High
Occurrence Count : 1
CurOccur Count : 0
Collapse Intv : 1200 sec
Total Collapse : 3
Total NonCollap : 1
Current Collapse : 3
First Occurrence : Thu Aug 15 14:49:34 2002
Last Occurrence : Thu Aug 15 14:52:33 2002
---------------------------
Event Id : 1029363916_10
Severity : 5
Object list :
Event Message : Number of Threads High
Occurrence Count : 1
CurOccur Count : 0
Collapse Intv : 1200 sec
Total Collapse : 3
Total NonCollap : 1
Current Collapse : 3
First Occurrence : Thu Aug 15 14:49:34 2002
Last Occurrence : Thu Aug 15 14:52:34 2002

162 Troubleshooting and Diagnostic Tools

Command Description

profile Displays detailed information about all jobs or a specific job running on an agent computer.
For a summary of job information, use the job command. The basic syntax is:

profile mc_hostname NetIQmc [option]

The optional parameters specify the type of job for which you want to display information:

 run for jobs that are currently running, including jobs that are in an active, inactive,
and scheduled state.
 done for jobs that are recently stopped.
 active for jobs that are currently running and active.
 inactive for jobs that are currently running but are inactive.
 sched for jobs that are running and are waiting for the start of their next scheduled
running period.

For example, to display profile information for all jobs on the agent computer paris, use:

profile paris netiqmc

Output example:

----------------------
Running-Active Jobs
----------------------
Job [4] =>
KS Name : NT_CpuLoaded
QDB Site : OLYMPUS1029363296_1029363296
QDB Site UpdTime : 1029363296

MS machine : OLYMPUS <10.5.10.92>

Thread ID : 2736 (0xab0)
Local Action : <>
Job Status : worker running
Detailed State : <end one iteration>
Submit Time : Thu Aug 15 10:27:06 2002
Start Time : Thu Aug 15 10:27:06 2002

StopPending Time :
Iteration Intv : 300 sec
Iteration Count : 18
Iter Start Time : Thu Aug 15 11:52:07 2002
Iter Stop Time : Thu Aug 15 11:52:08 2002
Iter Run Time : 491 msec

Avg Iter Time : 539 msec

+++++++ total 1 job

Troubleshooting and Diagnostic Tools 163

 Command Description

profrsc Displays detailed status information about jobs that are currently inactive on an agent
computer because of a maintenance period.

For a summary of status information for inactive jobs, use the jobrsc command.

Each job is associated with a resource ID that identifies the Knowledge Script category for
that job. The resource ID is specific to each agent computer. For example, if two SQL
Knowledge Scripts are running on an agent computer, both jobs will have the same
resource ID. However, that resource ID for SQL Server jobs on that agent computer will not
necessarily match the resource ID for SQL Server jobs on other agent computers.

The basic syntax is:

profrsc mc_hostname netiqmc [ms_hostname job_id]

For example, to get detailed information about job number 66, which is running on the
agent computer named polar and was scheduled by the management server named
olympus, use:

profrsc polar netiqmc olympus 66

Output example:

Job [66] =>

KS Name : SQL_DataSpace
QDB Site : OLYMPUS904955486_904955487
QDB Site UpdTime : 904955487
MS machine : OLYMPUS <10.1.10.65>
Job Status : Inactive
RSC ID : 2
# Skipped Iter : 22
Iter Skip Time : Tue Sep 10 14:48:40 2002

164 Troubleshooting and Diagnostic Tools

Command Description

rpstat Displays the statistics stored in the local repository of an agent computer. The list includes
the number of events, data logs, and messages stored in the local repository. The
messages may be waiting for a scheduled upload or they may be stored locally because
the agent computer cannot communicate with the management server.

Basic syntax:

rpstat mc_hostname NetIQccm site|ms ms_hostname

 Use the site keyword to extract information by specifying the repository name.
 Use the ms keyword to extract information by specifying the management server
hostname.

For example, to list statistics for the agent computer named paris, which is managed by
the management server named olympus, use:

rpstat paris netiqccm ms olympus

Output example:

----------------------------------------------
List CCM Site Local RP Stat
----------------------------------------------
QDB Site Name OLYMPUST011029277802_1029277802
QDB Site Updtime 1029277802
MS hostname OLYMPUS <10.5.11.39>
Type #-RP #-Cache LastDur AvgDur
------------- -------- -------- -------- --------
Event 0 0 0 0.00
CtrlEvent 0 4 0 0.00
DataHeader 0 0 0 0.00
DataLog 0 0 0 0.00
Exception 0 0 0 0.00
JobComplete 0 1 0 0.00

 The RP column indicates the number of transactions held in the local repository.
 The Cache column indicates the number of transactions held in memory.
 The LastDur column indicates the duration of the last transaction with the local
repository in seconds.

Troubleshooting and Diagnostic Tools 165

 Command Description

script Saves NetIQctrl input and output in a text file. The basic syntax is:

script <filename>

To stop capturing input and output, use:

script done

For example:

NetIQctrl> script c:\temp\netiqctrl.log

Script <c:\temp\netiqctrl.log> started
NetIQctrl> ping mojo netiqmc

version 2.0.261.5
start_mode Service
start_time Wed Nov 26 15:52:04 1997
trace_level 1
rpc version 2.0
rpc port # 9998
NetIQctrl> script done
Script <c:\temp\netiqctrl.log> done

site Displays information about the repository that a specified management server is
communicating with. The basic syntax is:

site ms_hostname NetIQms

For example, to see the repository information for the management server on the computer
named paris, use:

site paris NetIQms

Output example:

site name PARIS880588204

site time 880588206

166 Troubleshooting and Diagnostic Tools

Command Description

stat Displays statistical information collected by a specific agent computer or management

server. The output for this command varies depending on the service and options you
specify in the command line. For example, if you run this command to display statistics for
the Client Resource Monitor, NetIQmc, the output lists the number of events, data streams,
actions, and jobs completed by the agent computer. By default, the statistics reflect the
total for the agent computer regardless of which QDB or management server scheduled its
jobs. The basic syntax is:

stat mc_hostname NetIQmc [option]

stat mc_hostname NetIQccm [option]
stat ms_hostname NetIQms

For NetIQmc, use the following keywords:

 site displays both the total numbers for an agent computer, and a breakdown by site
for the number of events, data streams, data points, and actions. You can also use the
keyword site and a specific management server hostname to retrieve information
associated with a specific AppManager repository.
 rpc provides detailed information about RPC activity on the agent computer.
 sec provides information about any agent computer activity that caused RPC
requests to be rejected.
 jobpoll indicates the last management server to which the agent computer sent a
job status report.

For NetIQccm, use the keyword site or ms and a management server hostname to
retrieve information associated with a specific AppManager repository or management
server.

For NetIQms, this command provides detailed statistics covering thread activity and
successful and failed communication.

For example, to see summary information for the management client named paris, use:

stat paris NetIQmc

Output example:

----------------------------------------------
List Summary Stat
----------------------------------------------
[Total] :
Type #-Done #-Fail #-Skip
------------ -------- -------- --------
Event 7 0 0
CtrlEvt 8 0 0
DataHeader 2 0 0
DataLog 19 0 0
Exception 0 0 0
JobComplete 7 0 0

Troubleshooting and Diagnostic Tools 167

 Command Description

thread Displays the status of all threads maintained by a management server. Basic syntax:

thread ms_hostname NetIQms [option]

Use the optional parameter to select what types of thread information you want to see:

 jobpoll displays information for the job polling thread.

 jobstat displays information for the job status check thread.
 machpoll displays information for the machine polling thread.
 machping displays information for the machine status check thread.
If you don’t specify an option, the command returns information for all management server
threads.

For example, to get detailed information about the job polling thread maintained by the
management server named olympus, use:

thread olympus netiqms jobpoll

----------------------------------------------------
Job Poll Thread Info
----------------------------------------------------
** thread
state : sleeping
last completed : Thu Aug 15 11:56:35 2002
last start time : Thu Aug 15 11:56:35 2002
current machine : none
sleep interval : 5
** job polling
last mod time : Thu Aug 15 11:49:32 2002
run pending jobs : 0
stop pending jobs: 0
** run pending job submission
jobs cached : 0
jobs skipped : 0
jobs submitted : 0
** stop pending job submission
jobs cached : 0
jobs skipped : 0
jobs submitted : 0

168 Troubleshooting and Diagnostic Tools

Command Description

trip Sends a path request to the agent computer (NetIQmc) and a management server
(NetIQms) to test the round-trip connectivity between them. The basic syntax is:

trip mc_hostname NetIQmc ms_hostname

For example, to test the round-trip connectivity between the agent computer named
shasta and the management server named paris, use:

trip shasta NetIQmc paris

Output example:

1066766782 - ctrl
1066766831 - mc <shasta>
1066766782 - ms <paris>
1066766831 - mc <shasta>
1066766782 - ctrl

NOTE: The response time for each computer is based on its internal clock settings. If the
two computers have different clock settings, the UTC timestamps may appear to be
incorrect. As long as the round trip is successful, however, you can verify the connectivity
between the computers.

uploadsched Lists the user-specified upload schedule that has been registered on an agent computer for
a specific QDB. The output includes the site identifier for the repository and the separate
schedules for uploading events and uploading data. The basic syntax is:

uploadsched mc_hostname NetIQmc [ms_hostname]

For example, to list the upload schedule that is registered on the agent computer named
shasta, use:

uploadsched shasta netiqmc

Output example:

[PARIS1029363296_1029363296]
#-EventUpload-#
#-DataUpload-#
Type: scheduled
Recur Type: DAILY
Recur Freq: every <1> day(s)
Start Time: 13:00:00
End Time: 02:00:00
Interval: 1 hour

unixjob Displays a summary of the jobs on UNIX and Linux agent computers. The output includes
a list of the job IDs for the selected computer, the management site ID, and the status of
each job.

The basic syntax is:

UnixJob ms_hostname NetIQms [UNIX_agent_IP]

Use the optional UNIX_agent_IP parameter to indicate a specific UNIX or Linux computer
for which you want to list jobs. To display the job summary for a specific UNIX or Linux
computer, include the computer’s IP address in the command line (you must use the IP
address and not the hostname). For example:

UnixJob rainier netiqms 64.220.132.10

Unix Agent: 64.220.132.10
Job: 26 Unknown
Job: 28 Unknown

Troubleshooting and Diagnostic Tools 169

 Command Description

unixmachine Displays configuration and monitoring information for UNIX and Linux agent computers.
The output for this command includes:

 Agent version, platform, start time, and time zone

 Queue configuration for the agent’s data, event, job, and exception queues
 Jobs that are running, pending, and pending a restart for the agent
The basic syntax is:

UnixMachine ms_hostname NetIQms [UNIX_agent_IP]

Use the optional UNIX_agent_IP parameter to indicate a specific UNIX or Linux computer
for which you want to list information. To display information for a specific UNIX or LInux
computer, include the computer’s IP address in the command line (you must use the IP
address and not the hostname).

For example:

unixmachine rainier netiqms 64.220.132.10

Unix Agent: 64.220.132.10 (obj id: 149)
Version: 2.0.137.0
Platform OS: SunOS/sparc/5.8
Startup Time: 1028323718
Time Zone Bias: -480+1
Socket Port: 9001
# of Running Jobs: 2
# of Pending Jobs: 0
# of Pending Restart Jobs: 0
Communication Queue Configuration:
CurBrk/MaxBrk/MinBrk/Adj%/MaxSize/IncVal/MaxBlks>
Data 1000/1000/10000/20/65536/10000/20
Event 1000/1000/10000/20/65536/5000/20
JobStat 1000/1000/10000/20/65536/0/20
Exception 1000/1000/10000/20/65536/0/20

unixmms Displays the primary and secondary management servers for a UNIX or Linux agent
computer. The output for this command displays the primary and secondary management
server hostname for a specified UNIX agent or all UNIX agents.

The basic syntax is:

UnixMMS ms_hostname NetIQms [UNIX_agent_IP]

Use the optional UNIX_agent_IP parameter to indicate a specific UNIX computer for which
you want to list information. To display communication details for a specific UNIX computer,
include its IP address in the command line (not the UNIX hostname). For example:

unixmms rainier netiqms 64.220.132.10

Unix Agent: 64.220.132.10 (obj id: 149)
Primary MS: RAINIER
Secondary MS: SANDMAN

170 Troubleshooting and Diagnostic Tools

 Command Description

unixtime Displays information about the communication between the management server and UNIX
and Linux agent computers. The output for this command includes:

 The time the last heartbeat was received by the management server
 The time the agent last requested data, events, jobs, and exception information
 The time the management server last received the agent requests for data, events,
jobs, or exceptions
 The time of the last request rejected by the agent and the management server.
The basic syntax is:

UnixTime ms_hostname NetIQms [UNIX_agent_IP]

Use the optional UNIX_agent_IP parameter to indicate a specific UNIX computer for which
you want to list information. To display communication details for a specific UNIX or Linux
computer, include the computer’s IP address in the command line (you must use the IP
address and not the hostname). For example:

unixtime rainier netiqms 64.220.132.10

Unix Agent: 64.220.132.10 (obj id: 149)
Last MSU Heartbeat Received Time: 1028324108
Last Agent Request Reject Time: 0
Last MSU Request Reject Time: 0
Last Agent Data Request Time: 0
Last MSU Data Request Received Time: 0
Last Agent Event Request Time: 1028323797
Last MSU Event Request Received Time: 1028323815
Last Agent Job Status Request Time: 1028323878
Last MSU Job Status Request Received Time: 1028323896
Last Agent Exception Request Time: 1028323722
Last MSU Exception Request Received Time: 0

The UnixTime command is useful for troubleshooting communication or network problems

between the management server and UNIX agent. With this command, you can trace the
heartbeat and task requests from the UNIX agent and compare them to the requests
received by the management server to determine whether there are connection or
communication problems.

12.4 Using the NetIQ Diagnostics Utility

NetIQ Diagnostics is a utility found in the bin folder for your AppManager installation (for example, in
a default location such as C:\Program Files\NetIQ\AppManager\bin). NetIQ Diagnostics is used
to collect information from the agent computer log files and from the registry. Although the information
may help you to troubleshoot your environment on your own, typically this information is sent directly
to NetIQ Corporation Solutions Support to help them analyze and diagnose problems in your
deployment of AppManager components.

Troubleshooting and Diagnostic Tools 171

12.4.1 Starting the NetIQ Diagnostics Utility
The NetIQ Diagnostics utility must be run locally on the computer you are attempting to diagnose.

To run the NetIQ Diagnostics utility:

1 Double-click the NetIQDiag.exe program in the NetIQ\AppManager\bin folder.

2 In the first page of the Diagnostics wizard:
 Verify that Set maximum trace level is selected.
 Check both AppManager Agent and AppManager Management Server unless instructed
otherwise by NetIQ Technical Support.
 Click Set to set the tracing levels for the agent and management server to the maximum
level, then click Next.
3 Check the specific components you want to diagnose from the AppManager Component Options
list.
4 Click Diagnose. The NetIQ Corporation Diagnostics utility begins collecting information about
your environment. When the diagnosis is complete, click Next.
5 If diagnosing an Analysis Center report repository, type a SQL Server login account and
password for a SQL Server account with permissions associated with the System Administrators
role, and, if appropriate, check Use NT Authentication.
6 If diagnosing an AppManager repository, type a user name and password that has permission to
access the AppManager database, if appropriate, check Use NT Authentication, then click
Next.
7 Check any external sources of information you want included with the diagnostic package, then
click Next. For example, if you are seeing unusual Windows events or Dr. Watson errors, you
may want to include those log files.
8 Click Next to bypass the AppAnalyzer and XMP diagnostic pages.
9 Click compress to collect all of the log files and other information into a CAB file in the
NetIQ\diagnostics directory, for example, C:\Program Files\NetIQ\diagnostics.
The name of the diagnostic file is:

computer name_MM.DD.YY_HH.MM.SS_diag.cab

For example: Detroit_08.16.02_15.09.20_diag.cab

12.4.2 Viewing NetIQ Diagnostics Output

All log files that NetIQ Diagnostics generates are collected in a compressed CAB file each time you
run the Diagnostics utility. To view any of the log files, you first need to extract them from the
compressed file. You can then view the information from the text-based logs in any text editor.

12.5 Enabling Tracing and Viewing Log Files

Most AppManager components include registry keys for fine-tuning trace logging. By default, most
components are set to do little or no logging for performance reasons. If you are troubleshooting your
AppManager environment, however, it may be useful to change the tracing level to provide more
detailed information in log files.

172 Troubleshooting and Diagnostic Tools

NOTE: NetIQ Corporation recommends you use the Diagnostics utility to set the tracing level rather
than edit registry keys directly because using the Registry Editor incorrectly can cause serious
problems that may require you to reinstall your operating system. In general, you should only edit the
registry directly if instructed to do so by NetIQ Technical Support or if you have a thorough
understanding of the key values and the implications of making changes. NetIQ cannot guarantee
that problems resulting from the incorrect use of the Registry Editor can be resolved.

All AppManager log files for the components installed on a computer are stored in the location
defined in the HKEY_LOCAL_MACHINE registry under \Software\NetIQ\Generic\Tracing. For
example, the default path is typically:

TraceLogPath: c:\program files\netiq\Temp\NetIQ_Debug

For information about the specific registry keys that enable or configure logging for each component,
see “Registry Keys” on page 187. The following table provides a summary of the information
recorded in the log files and how you can use this information to troubleshoot your AppManager
environment.

Log Information Recorded

ccmtrace.log If you enable TraceCCM, the AppManager Client Communication Manager

(NetIQccm) records information about its activity in the ccmtrace.log file.

The information recorded in this file includes the connection status for
communication with the management server, and the processing status for events
and data stored in the local repository.

mctrace.log If you enable TraceMC, the AppManager Client Resource Monitor (NetIQmc)
records information about its activity in the mctrace.log file. The information
recorded in this file includes the status of polling threads, job requests, and job
execution.

If you also enable Knowledge Script tracing with TraceKS, this log also includes
line-by-line trace entries for each job running on the agent. This allows you to step
through the Knowledge Script as it is executed to locate the point of failure.

NOTE: Knowledge Script tracing creates an ASCII copy of the compiled Knowledge
Script with debugging line numbers in the TraceLogPath\mc subdirectory. A
separate file is created for each job and action executed on the agent and the name
of each file includes the JobID and the SiteID.

mo.log If you enable tracing for any managed object, the mo.log records information about
monitoring activity for that managed object. The information recorded includes all
function calls made from the managed object during job execution.

By default all managed object tracing flags are set to 0x10, which provides a
minimal level of tracing. You can log additional detail by increasing the value for the
relevant TraceMOcomponent registry key. To enable full tracing for a desired MO,
set the appropriate registry value to 0xFF.

Ckcomponent.log Pre-installation information for each managed object selected during a pre-
installation check is recorded in a separate log file. For example, if you run the pre-
installation check for Exchange 2000, the setup program records information about
the checks performed in the CkExch2.log.

These log files can help you determine why a particular managed object cannot be
installed or discovered on a computer.

loc.log The loc.log traces internal pipe communication between the Client Resource
Monitor and Client Communication Manager services.

Troubleshooting and Diagnostic Tools 173

 Log Information Recorded

Nqioc_err.log The Nqioc_err.log records information about errors generated by the IO

Completion port on the agent. The IO Completion port is used to verify the delivery
of information to the management server. If errors are generated on this port, it may
suggest delivery failures.

ms.log The AppManager Management Service (NetIQms) records information about all of
its activity in the ms.log. For example, the service writes information in the ms.log
when it delivers jobs to agents, receives events and data, or detects changes to job
or machine status.

msaction.log If you enable Action Log tracing, the AppManager Management Service
(NetIQms) records detailed information about management server or proxy action
processing errors.

msqdb.log If you enable QDB Log tracing, the AppManager Management Service (NetIQms)
records detailed information about errors encountered when the management
server connects to the repository.

msrplib.log The msrplib.log records information about activity between the AppManager
Management Service (NetIQms) and the QDB.

rplib.log The rplib.log records information about the connection and activity between the
Operator Console and the QDB.

This file logs any ODBC errors encountered in the connection between the Operator
Console and the QDB. The file also includes information about all requests to fetch,
update, refresh, or delete information in the QDB.

KSCheckin.log The kscheckin.log records information about all attempts to check Knowledge
Scripts into the repository, including attempts to check in scripts from a local
Operator Console, using the Kscheckin.exe utility, or through an installation or
upgrade of the repository.

QDBInstall.log The QDBInstall.log stores a complete record of the repository installation

process.

QDBUpgradenn.log The QDBUpgradenn.log stores a complete record of the repository upgrade

process. The log filename indicates the version of AppManager to which you
upgraded. For example, if you are upgrading to AppManager 6.7, the log filename is
QDBUpgrade67.log.

KSCustomnn.log The KSCustomnn.log stores information about Knowledge Scripts that have had
properties customized and records whether the customized version of the
Knowledge Script has been successfully checked into the QDB. The log filename
indicates the version of AppManager to which you upgraded. For example, if you
are upgrading to AppManager 6.7, the log filename is KSCustom67.log.

appmgr.log The appmgr.log records debugging information for an AppManager agent

installation. Unlike other log files, this file is located in the Windows system folder.
For example:

%SYSTEMROOT%\appmgr.log

maint.log The maint.log records information about any patches or hot-fixes installed for any
AppManager component on a local computer.

msadapt.log The msadapt.log records information about all activity processed by an

AppManager Connector.

174 Troubleshooting and Diagnostic Tools

12.6 Using the Log Analysis Tool
The Log Analysis Tool lets you parse the UNIX agent log files to consolidate information about default
threads executed by the agent, and information about threads executed in conjunction with jobs.

During normal operation, the UNIX agent records information about its activity in log files. Because
the UNIX agent makes entries in the log file at each execution of a thread, the various thread entries
become interspersed with each other. The Log Analysis Tool helps you analyze the information
recorded in the log file by consolidating entries by thread and extracting the consolidated information
in a more readable format. The output from the Log Analysis Tool makes it easier to troubleshoot
agent operation and identify any agent problems.

NOTE: For information about configuring logging for the UNIX agent, see the AppManager for UNIX
Servers Management Guide, available on the AppManager Modules Documentation page (http://
www.netiq.com/documentation/appmanager-modules).

The Log Analysis Tool is located in $NQMAGT_HOME/bin/logparser/fileParse.sh.

You can use the following arguments and options with the Log Analysis Tool:

Option Description

-v level Set the verbosity level. Valid levels are:

1 Displays only the start and end steps of each task thread
(default).
2 Displays start and end steps, as well as all intermediate steps of
each task thread.

-a Display the average time for each iteration.

-i interval Set the iteration interval to any whole number you specify for the interval. For
example, if you specify 3, the Log Analysis Tool returns every 3rd iteration of a
thread.

If you do not specify an interval, the Log Analysis Tool returns information for all
intervals.

-x type Specify the type of information you want to exclude from the output. The valid types
of output you can exclude are:

 threads to exclude the default agent threads and display only job threads.
 jobs to exclude job threads and display only the default agent threads.
NOTE: The default agent threads are the Heartbeat, Event Queue, Job Status
Queue, Exception Queue, Job Sync, and Thread Monitoring threads.

If you do not specify a type of output to exclude, the Log Analysis Tool returns
information for all threads.

Troubleshooting and Diagnostic Tools 175

 Option Description

-d date Specify a date range for the information returned. You can identify a specific date or
a range of dates using the format:

mm/dd/yy

For example, if you want information for a specific date, you can enter that date:

-d 03/01/04

To specify a date range, enter the start and end dates. For example:

-d 03/01/04-03/05/04

If you do not specify a date or date range, the Log Analysis Tool returns information
for all dates in the log file.

-j jobID Identify a specific job for which you want to return information. You can separate
multiple job IDs by using commas. For example, to specify you want information for
Job IDs 1, 12, and 23:

-j 1,12,23

If you do not specify a job ID, the Log Analysis Tool returns information for all jobs.

-q siteID Identify a specific QDB for which you want to return information.

NOTE: This option is not supported in this version of the Log Analysis Tool.

-h or ? Display usage Help for the Log Analysis Tool.

-f logfile Specify the filename for the log file to parse.

You should use this option if you are running the Log Analysis Tool in the log file
directory.

Use nqmlog to parse the most recent log file. The nqmlog is a hard link to the most
recent log file. To parse an earlier file, enter the exact filename.

You can parse multiple files by entering the filenames, separated by commas. For
example:

-f log20030412180531,log20030412180531

If you do not specify a filename, the Log Analysis Tool parses all UNIX agent log
files.

-l path Specify the path to the log file directory. You should use this option if you are running
the Log Analysis Tool from a directory other than the log file directory. For example:

$NQMAGT_HOME/log

If you use this option without specifying the -f option, the Log Analysis Tool parses
all log files in the directory.

If you use this option with the -f option, the Log Analysis Tool parses only the files
specified by the -f option.

-e messageoption Indicate whether you want to write error messages to file or standard output. The
valid messageoptions are:

 yes to write error messages in the log file to an Errors.txt file in the current
directory.
 no to write error messages to standard output.

176 Troubleshooting and Diagnostic Tools

A Additional Site Administration
A

Utilities

This appendix provides reference information for using AppManager utilities that perform specialized
tasks. All of these utilities are command-line programs. The following utilities are discussed:

 Key file utility for Windows agents

 Key file utility for UNIX agents
 MAPI mail utility
 Synchronization utilities
 Time conversion utility

A.1 Key File Utility for Windows Agents

The NetIQ Corporation key file generation program, NQKeyGenWindows.exe, is a command-line
program used to set the security level for an AppManager management site and to generate and
manage public/private encryption keys for secure communication between the management server
and Windows managed computers. This utility is installed in the NetIQ\AppManager\bin folder.

The basic syntax for the NQKeyGenWindows.exe program is:

NQKeyGenWindows -option value

NOTE: Type NQKeyGenWindows without specifying any options to see usage information.

The program supports the following command-line options:

Option Description

-db Specifies the login information for connecting to the repository using the following
format:

NQKeyGenWindows -db database_name:user_name:sql_server

For example:

NQKeyGenWindows -db qdb:smithj:nyc2003

If you are using Windows authentication to connect to the repository, leave the
username blank. If you are using SQL Server authentication, type a SQL Server
username for connecting to the repository. The program prompts for the password to
use for the SQL Server account.

NOTE: Most of the other options require you to specify the connection information. If
you use this option without specifying any additional options, the command displays the
current security level setting.

Additional Site Administration Utilities 177

 Option Description

-new Creates a new record in the repository for the key information used to encrypt
communication and authenticate the management server to the agents. For example:

NQKeyGenWindows -db db:user:sqlsvr -new

To create a new key file to share across multiple repositories on a computer other than
the repository, use the command:

NQKeyGenWindows -new filelocation

This option creates a new key with password protection in the specified file location
without checking it into the repository.

NOTE: When you use the -new option, you’ll be prompted to provide a password for
the key stored in the repository. You must specify a password to create the key.

-change Changes the key information stored in the repository to use the new key file you specify.
You must specify the key file password you used to create the key and the location of
the key file to use.

For example:

NQKeyGenWindows -db db:user:sqlsvr -change filelocation

This option enables you to check an existing key from a key file into a new repository
when you want to share a key file across multiple repositories and management
servers.

NOTE: When you use this option, you’ll be prompted to provide the password you
specified when you created the key.

-ckey Extracts only the agent portion of the key stored in the repository. You must specify a
location for the agent key file.

For example:

NQKeyGenWindows -db db:user:sqlsvr -ckey filelocation

To extract the agent portion of the key, you must run NQKeyGenWindows on a
management server.

NOTE: When you use this option, you’ll be prompted to provide the password you
specified when you created the key in the repository.

Once you extract the agent portion of the key, you can copy the file and distribute it to
the agents for encryption or authentication and encryption.

-info Displays the current security level setting stored in repository. You are then prompted
for the repository key password to display the checksum for verifying the encryption key
and authentication key for an agent. For example:

NQKeyGenWindows -db db:user:sqlsvr -info

You can compare the checksum from the repository with the checksum returned by the
-agentinfo option to verify whether an agent is using the correct key file for a specific
repository.

You can only use this option if you run NQKeyGenWindows on a management server
computer.

178 Additional Site Administration Utilities

Option Description

-skey Extracts the key information stored in the repository. You must specify a location for the
key file.

For example:

NQKeyGenWindows -db db:user:sqlsvr -skey filelocation

NOTE: When you use this option, you’ll be prompted to provide the password you
specified when you created the key in the repository.

This option checks out the current key into a password-protected file format. This file
then can be checked into a different repository using the -change option.

You can only use this option if you run NQKeyGenWindows on a management server
computer.

-seclev Sets the security level in the repository for communication between the management
server and agents. Valid security levels are:

 0 for no security
 1 for encryption only security
 2 for authentication of the management server and encryption
NOTE: If you change the security level, the change takes effect when the management
server is restarted.

For example, to set the security level to use authentication of the management server:

NQKeyGenWindows -db db:user:sqlsvr -seclev 2

-agentchange Changes the agent key file for a managed computer to a key file you specify. The file
location must be a local path.

For example:

NQKeyGenWindows -agentchange filelocation

This option enables you to update the agent key file for a managed computer.

-agentinfo Displays the checksum for verifying the encryption key and authentication key for an
agent. For example:

NQKeyGenWindows -agentinfo

This option is useful for comparing the key information stored in the repository with the
agent key information recorded for a managed computer to verify whether the correct
key is being used.

-agentseclev Sets the security level in the managed computer registry for communication between
the management server and the agent. The valid security levels are:

 0 for no security
 1 for encryption only security
 2 for authentication of the management server and encryption
For example, to set the security level to use authentication of the management server:

NQKeyGenWindows -agentseclev 2

Additional Site Administration Utilities 179

 Option Description

-remoteseclev Sets the security level for a remote managed computer registry. You must specify the
hostname of the remote computer for which you want to set a security level. For
example to set the security to authentication and encryption for the remote computer
AJAX:

NQKeyGenWindows -remoteseclev ajax 2

The valid security levels are:

 0 for no security
 1 for encryption only security
 2 for authentication of the management server and encryption
Requires a user account with permission to access the remote computer’s registry.

-convert Converts an old key file from a previous release to the new key file format. For
example:

NQKeyGenWindows -convert oldkeylocation -newkeylocation

Enables you to check an older key file generated using the NetIQ Encryption Utility
(rpckey.exe) in AppManager 5.0.1 and earlier into the repository and continue using it
for all of your agents.

After converting an old key file, use the -change option to check the key information
into the repository, set the security level to 1 with the -seclev option, and restart your
management servers.

For more information about updating an older key file after upgrading to AppManager,
see the Upgrade and Migration Guide for AppManager, available on the AppManager
Documentation page (http://www.netiq.com/documentation/appmanager).

-verify Verifies the password and encrypted key file location are correct and can be imported
into the repository. To use this option, you must specify the password used to create the
public/private key and the location of the key file extracted from the repository.

For example:

NQKeyGenWindows -verify filelocation

NOTE: You are prompted to provide the password you specified when you created the
key.

A.2 Key File Utility for UNIX Agents

The NetIQ Corporation key file generation program, NQKeyGenUNIX.exe, is a command-line program
used to set the security level for a site and to generate and manage public/private keys for secure
communication between the management server and UNIX managed computers. This utility is
installed in the NetIQ\AppManager\bin folder when you run the AppManager setup program.

The basic syntax for the NQKeyGenUnix.exe program is:

NQKeyGenUnix -option value

NOTE: If you type NQKeyGenUnix without specifying any options, the program displays usage
information.

180 Additional Site Administration Utilities

The program supports the following command-line options.

Option Description

-db Specifies the login information for connecting to the repository using the following format:

NQKeyGenUnix -db database_name:user_name:sql_server

For example:

NQKeyGenUnix -db qdb:smithj:nyc2003

If you are using Windows authentication to connect to the repository, leave the username
blank. If you are using SQL Server authentication, type a SQL Server username for
connecting to the repository. The program prompts for the password to use for the SQL
Server account.

NOTE: Most other options require you to specify connection information.

-new Creates a record in the repository for the public/private key pair used to authenticate the
management server to your UNIX agents. You must specify a password to create the key.
For example:

NQKeyGenUnix -db db:user:sqlsvr -new

To create a new key file to share across multiple repositories on a computer other than the
repository, you can use the command:

NQKeyGenUnix -new filelocation

This option creates a new private/public key pair with password protection in the specified
file location without checking the new key into the repository.

NOTE: When you use the -new option, the NQKeyGenUnix utility prompts you to provide a
key pair password.

-change Changes the public/private key stored in the repository to use the new key file you specify.
You must specify the key file password you used to create the key pair and the location of
the key file to use.

For example:

NQKeyGenUnix -db db:user:sqlsvr -change filelocation

This option enables you to check an existing key from a key file into a new repository when
you want to share a key file across multiple repositories and management servers.

NOTE: When you use this option, you are prompted for the password you specified when
you created the key pair.

-ckey Extracts just the public key portion of the key file stored in the repository. You must specify
a location for the public key file.

For example:

NQKeyGenUnix -db db:user:sqlsvr -ckey filelocation

Once you extract the public portion of the key, you can copy the file and distribute it to your
UNIX agents for authentication purposes.

Additional Site Administration Utilities 181

 Option Description

-skey Extracts the public and private key stored in the repository. You must specify a location for
the key file.

For example:

NQKeyGenUnix -db db:user:sqlsvr -skey filelocation

This option is used to check out the current key pair into a password-protected file. This file
then can be checked into a different repository using the -change option.

-seclev Sets the security level in the repository for communication between the management
server and UNIX agents. The valid security levels are:

 0 for no security
 1 for encryption only security
 2 for authentication of the management server
 9 to remove all historical key-pairs while maintaining the current security level
Removing historical key pairs enables you to manually expire older keys, as needed.

NOTE: If you change the security level, the change takes effect when the management
server is restarted.

For example, to set the security level to use authentication of the management server:

NQKeyGenUnix -db db:user:sqlsvr -seclev 2

-verify Verifies the password and encrypted key file location are correct and can be imported into
the repository. To use this option, you must specify the password used to create the public/
private key and the location of the key file extracted from the repository.

For example:

NQKeyGenUnix -verify filelocation

NOTE: When you use this option, you are prompted for the password you specified when
you created the key pair.

-ckeyinfo Display the public portion of the key as it is stored in the repository. For example:

NQKeyGenUnix -db db:user:sqlsvr -ckeyinfo

This option is useful for comparing the public key information stored in the repository with
the public key information recorded in the UNIX agent log file to verify whether the correct
key is being used.

A.3 MAPI Mail Utility

The NetIQ Corporation MAPI mailer program, NetIQMapiMail.exe, is a command-line program used
to send MAPI mail messages.

The basic syntax for the NetIQMapiMail.exe program is:

NetIQMapiMail -tRecipients [-sSubject] [-mMessage]

[-pProfile] [-wPassword] [-fAttachmentPath]

182 Additional Site Administration Utilities

 Use quotation marks around the entire parameter string if any information you specify contains blank
spaces. For example, if you are specifying the subject line and using spaces between words, you
would enclose the entire string in quotation marks similar to this:

NetIQMapiMail [email protected] -s"This is a test mail message"

The program supports the following options:

Option Description

-tRecipients Specifies the e-mail address of each individual you want to receive the report,
using the format in the address book. To specify more than one address,
separate each name with a semicolon (;). For example:

-t"Chris Lin;[email protected]"

-sSubject Specifies the text to use in the Subject line of the mail message.

-mMessage Specifies the body of the mail message.

-pProfile Specifies the MAPI client profile name to use for sending the message.

-wPassword Specifies the password for the client profile you are using.

-fAttachmentPath Specifies the full path to the file you want attached to the mail message.

A.4 SMTP Mail Utility

The NetIQ Corporation SMTP mailer program, NetIQSMTPMail.exe, is a command-line program
used to send SMTP mail messages.

The basic syntax for the NetIQSMTPMail.exe program is:

NetIQSMTPMail -tRecipients [-sSubject] [-fFrom] [-mMessage]

[-hHost:Port] [-rFilename]

Use quotation marks around the entire parameter string if any information you specify contains blank
spaces. For example, if you are specifying the subject line and using spaces between words, you
would enclose the entire string in quotation marks similar to this:

NetIQSMTPMail [email protected] -s"This is a test mail message" [email protected] -

hmailcenter:800 -rC:\Temp\NewsReport.txt

The program supports the following options:

Option Description

-tRecipients Specifies the e-mail address of each individual you want to receive the report, using
the format:

recipient@domain

For example:

[email protected]

Separate names of multiple recipients by commas.

-sSubject Specifies the text to use in the Subject line of the message.

-fFrom Specifies the sender identified in the From line of the message.

Additional Site Administration Utilities 183

 Option Description

-mMessage Specifies the body of the mail message.

-hHost:Port Specifies the SMTP mail server hostname and, optionally, the port number on the
server to use.

-rFilename Specifies the full path to a file to attach to the message.

A.5 SNMP Trap Utility

The NetIQ Corporation SNMP trap program, NetIQSNMPTrap.exe, is a command-line program used
to generate and send enterprise-specific SNMP traps. This program provides backend support for
AppManager actions that send SNMP traps in response to events.

The basic syntax for the NetIQSNMPTrap.exe program is:

NetIQSNMPTrap [-a agent] [-c community_name]

[-d destination] [-f filename] [-i] [-m message]
[-o trap_oid] [-p trap_port] [-s specific_number]
[-v agent_varbind_oid]

The program supports the following options:

Option Description

-a agent Specifies the name of the computer originating the trap.

-c community_name Specifies the community name to use.

-d destination Specifies the SNMP destination or trap sink manager computer.

-f filename Specifies the full path to the file containing a custom trap message.

-i Installs or reset the registry entries under

HKEY_LOCAL_MACHINE\Software\NetIQ\AppManager
\4.0\NetIQmc\SNMPTRAP\Config to their default values.

-m message Specifies the message associated with the trap.

-o trap_oid Specifies the enterprise-specific Object Identifier.

-p trap_port Specifies the port that receives SNMP traps.

-s specific_number Specifies the enterprise-specific trap number.

-v agent_varbind_oid Specifies one varbind object identifier for all SNMP traps containing the
default AppManager event information or your custom message.

184 Additional Site Administration Utilities

A.6 Synchronization Utilities
Two synchronization utilities are available to help you troubleshoot inconsistencies between
AppManager agents and the repository.

The mssync.exe program checks for differences between the management server designation on the
AppManager agent and the management server designation stored in the repository. Optionally, this
program can also be used to correct the management server designation information in the repository
so that it matches the designation information on the agent. For help on using this program, open a
Command Prompt window and type mssync -h.

The netiqsync.exe program checks for differences in job status between AppManager agents and
the repository, and optionally stops orphaned jobs. You must run this program on the management
server computer. For help on using this program, open a Command Prompt window and type
netiqsync -h. Contact NetIQ Technical Support for more information about using this program.

A.7 Time Conversion Utility

The time conversion program, prttime.exe, is used to convert a UTC time value to a comparable
data and time string in plain text. You can find the prttime.exe program in the Extras folder in the
AppManager installation kit.

The syntax for the prttime.exe program is:

prttime

You are then prompted to provide the UTC time you want to convert. For example, if you type the
UTC time 1055439148, the return value is:

Thu Jun 12 10:32:28 2003

Type Ctrl-C to exit the program.

NOTE: This program always returns the UTC time in its corresponding Pacific Standard Time,
regardless of the time zone the local computer uses. By definition, UTC format is the number of
seconds since January 1, 1970, 12:00am GMT. Therefore, if you type 0, the prttime.exe program
returns Wed Dec 31 16:00:00 1969.

Additional Site Administration Utilities 185

186 Additional Site Administration Utilities
B Registry Keys
B

Each AppManager component uses registry keys to control a range of operations. For most
organizations, it is rare to need to modify any of these key values or edit the registry directly. In some
cases, however, it is useful to understand how these keys are used. This appendix provides an
overview of the common AppManager registry keys and the registry keys associated with each
AppManager component.

For each key value, the following information is provided:

 Value name
 Description of what the value represents and the default value for the key or sample values to
illustrate the entry format

All of the keys described in this appendix are under the HKEY_LOCAL_MACHINE on Local
Machine registry entry. Depending on the configuration of your installation and the version of
AppManager you are using, you may see registry keys not included in this appendix, different values,
or keys displayed in a different format.

B.1 Modifying the Registry

In most cases, you set or modify registry key values from within AppManager components by making
selections in the user interface or during installation. You can also use the NTAdmin_RegistrySet
Knowledge Script or the Registry Editor to modify the registry keys.

Before running NTAdmin_RegistrySet, check that the AppManager agent services (NetIQmc and
NetIQccm) are running on the target computer as LocalSystem or as an account with local
Administrator privileges.

NOTE: You should always back up the registry before you modify any key values. You should also
update your Emergency Repair Disk (ERD) before making any changes to the registry.

B.2 Basic NetIQ Registry Folder

On 32-bit computers, all AppManager registry keys and folders are located in HKEY_LOCAL_MACHINE
under SOFTWARE\NetIQ.

On 64-bit computers, all AppManager registry keys and folders are located in HKEY_LOCAL_MACHINE
under SOFTWARE\SysWow6432\NetIQ.

The top-level folder is created when you install any NetIQ Corporation product on a computer.

Registry Keys 187

 Depending on the products and components you have installed on the local computer, the NetIQ
folder may include some combination of the following folders for AppManager-related registry keys:

Folder Content

AppManager Key values for all of the AppManager components installed on the computer
you are viewing.

Common The path to the NetIQ Corporation\Common directory where files that can
be used by multiple NetIQ Corporation products have been installed.

Generic Keys used to customize the maximum log size of the trace log and the path
where the log file is saved.

Report Sharing Components The path to the directory where shared report components have been
installed.

Response Time Key values for the location of the schema file and tracing log used by
AppManager Response Time modules.

B.3 Main AppManager Keys and Folders

The AppManager registry keys and folders located in SOFTWARE\NetIQ\AppManager\4.0 (for 32-bit
computers) and SOFTWARE\SysWow6432\NetIQ\AppManager\4.0 (for 64-bit computers) contain the
most important registry key information for AppManager Version 4.0 and later.

 The key values provide version and build information for the AppManager executables (.exe)
and libraries (.dll) installed on a computer. All of the values are recorded during installation and
provide useful information to verify the compatibility of components installed on a computer. You
should not manually change any of these values. The format for the version and build number is
n.n.nnnnn.n (for example, 6.0.56615.0) and is the same for all components.
 The registry folders contain keys and subfolder keys that control the behavior of AppManager
components installed on the computer and the communication between local AppManager
components and AppManager components installed on other computers.

For example, you may see some or all of the following folders:

Folder Associated Component Contents

AgtShared AppManager agent Key values that define the characteristics of the
managed computer’s local repository.

AMDevCon AppManager Developer’s Key values used to configure and store information
Console about the Developer Console.

IconEdit AppManager Developer’s Key values that indicate the path to any custom icon
Console files you have added using the Icon Editor.

Install AppManager Response Time Key values that indicate the path to the uninstaller for
module or agent modules.

NetIQccm AppManager agent Key values that configure communication with the
management server. For more information about this
key, see Section B.6, “NetIQccm Folder,” on page 190.

NetIQmc AppManager agent Key values that configure the AppManager agent’s
operation. For more information about this key, see
Section B.7, “NetIQmc Folder,” on page 193.

188 Registry Keys

 Folder Associated Component Contents

NetIQms AppManager management server Key values that configure communication with the
repository and managed computers. For more
information about this key, see Section B.8, “NetIQms
Folder,” on page 199.

QDB AppManager repository Key values that configure the data device, name, path,
size and the log name, path, size. It also contains keys
that shows the encrypted password and the path of the
database installation. For more information about this
key, see Section B.9, “QDB Folder,” on page 205.

Repository AppManager Operator Console Key values that define the saved queries available in
Browser the Repository Browser.

Security AppManager Security Manager Key values that define the default security role and
Manager default SQL Server group for new users.

WebRecorder Web Transaction Recorder Key values used to configure and store information
about the Web Transaction Recorder.

B.4 AgtShared Folder

The SOFTWARE\NetIQ\AppManager\4.0\AgtShared (for 32-bit computers) and
SOFTWARE\SysWow6432\NetIQ\AppManager\4.0\AgtShared (for 64-bit computers) folders store
keys that define the characteristics of the managed computer’s local repository.

Key Description

DataCacheQueSize Defines the maximum queue size for the agent services. The default is
5MB.

RpAccessMode Defines the connection method for accessing the local repository. Currently,
only ODBC is supported.

RPC Authentication Indicates whether the agent service should authenticate the management
server before sending encrypted data.

 A value of 0 indicates no authentication is required.

 A value of 1indicates authentication is required.
RPC Encryption Indicates whether the RPC communication between the agent services and
the management server should be encrypted.

 A value of 0 indicates no encryption.

 A value of 1indicates all communication is encrypted.
RpMaxCacheSize Defines the maximum cache size for the local repository. A value of 0
indicates unlimited cache size.

RpPath Identifies the path to the local repository. For example:

C:\Program Files\NetIQ\AppManager\db

Registry Keys 189

 B.5 AMDevCon Folder
The SOFTWARE\NetIQ\AppManager\4.0\AMDevCon (for 32-bit computers) and
SOFTWARE\Syswow6432\NetIQ\AppManager\4.0\AMDevCon (for 64-bit computers) folders store keys
that define characteristics for the Developer Console.

Key Description

EbsDebugger Specifies the full path to the debugger for scripts written in Summit BasicScript
(.ebs). The Developer Console checks this key, and if the path is specified, it starts
that debugger when you click Project > Debug.

KsCheckin Identifies the path to the Knowledge Script checkin program (kscheckin.exe). For
example:

C:\Program Files\NetIQ\AppManager\bin

KsTemp Identifies the path to the folder where log files generated by kscheckin.exe are
saved. For example:

C:\NetIQ\Temp\NetIQ_Debug\server

NewKsPath Identifies the default path for checking in new Knowledge Scripts. For example:

C:\Program Files\NetIQ\AppManager\qdb

QBDName Identifies the name of the repository database.

SQLServer Identifies the name of the repository server.

SQLUser Identifies the name of a SQL Server user for logging in to the repository.

VbsDebugger Specifies the full path to the debugger for scripts written in VBScript (.vbs). The
Developer Console checks this key, and if the path is specified, it starts that
debugger when you click Project > Debug.

VbsProgArgs Specifies the program arguments to use with the VBScript debugger.

B.6 NetIQccm Folder

The SOFTWARE\NetIQ\AppManager\4.0\NetIQccm (for 32-bit computers) and
SOFTWARE\SysWow6432\NetIQ\AppManager\4.0\NetIQccm (for 64-bit computers) folders store keys
that define characteristics of the NetIQ Corporation AppManager Client Communication Manager
service and how that service communicates with the management server. The keys are organized in
the following subfolders:

 Section B.6.1, “Admin,” on page 191

 Section B.6.2, “Config,” on page 191
 Section B.6.3, “Tracing,” on page 193

190 Registry Keys

B.6.1 Admin
The NetIQccm\Admin folder contains keys that are used in agent self-monitoring.

Key Description

AdminEvtSev Defines the default AppManager event severity level for agent self-monitoring
events. The default event severity level is 40.

DisableAdminEvt Sets the flag that indicates whether an event should be raised if an agent needs
to be restarted.

IOCEventLogCommInt Specifies the communication interval in seconds for the agent to use in checking
the Windows event log for new self-monitoring events. The default value is 60
seconds.

MCFreezeThreshold Specifies the maximum amount of time, in seconds, that can elapse between
timestamps to determine whether an agent should be restarted. Set by the
AMAdmin_AgentSelfMon Knowledge Script.

B.6.2 Config
The NetIQccm\Config contains keys that control agent autonomy and communication with the
management server.

Key Description

BatchLoad Specifies the maximum number of records (events and data) for the NetIQ
Corporation AppManager Client Communication Manager to read from the
local repository and send to the management server in a single batch.

If communication with the management server fails, records are saved in

the local repository. When communication with the management server is
restored, this batch load value provides guidance for how much data the
Client Communication Manager should attempt to send at one time.

If the local repository has few records, the Client Communication Manager
may upload all of the records at once for efficiency. If the communication
between the Client Communication Manager and the management server is
slow, the Client Communication Manager may need to transfer the data in a
series of batches. The Client Communication Manager can adjust the
number of records uploaded dynamically, decreasing the load when the
management server is busy or communication is slow and increasing the
load when the management server is free or communication improves.

CacheRpcConn Sets the flag to control RPC connections. Zero disables caching, whereas a
non-zero value enables caching. The default is zero.

DataTableSize Defines the maximum size (number of records) for the local repository’s
Data table. This value is configured using the AMAdmin_SetLocalRPSize
Knowledge Script. The default value is zero (0), which indicates no limit.

Registry Keys 191

 Key Description

EventLogLvl Defines the level of the event log messages in the Windows Event Log. The
valid values for this key include:

0x0 - Don't log any events

0x1 - Log Info events

0x2 - Log Warning events

0x4 - Log Error events

Values are added to combine the events logged. For example, 0x5 logs Info
and Error events. The default is 0xF (Log everything).

EventTableSize Defines the maximum size (number of records) for the local repository’s
Event table. This value is configured using the AMAdmin_SetLocalRPSize
Knowledge Script. The key value is zero (0), which indicates no limit.

MonitorInterval Defines the monitoring interval (in seconds) to check whether the NetIQmc
service is running. If you set an interval, the NetIQ Corporation
AppManager Client Communication Manager automatically restarts the
NetIQ Corporation AppManager Client Resource Monitor service if it is
detected down. To turn off self-monitoring, set this value to 0. The default
value is 1800 seconds (30 min).

PingMSInterval Defines the interval (in seconds) to check the status of the NetIQ
Corporation AppManager Management Service. The default is 30 seconds,
for example, 0x1e.

NOTE: The NetIQ Corporation AppManager Client Communication

Manager service checks availability of the NetIQ Corporation AppManager
Management Service to determine whether to send data and events to the
management server or log them in the local repository.

This key is used when managed computers run in Autonomous mode.

PollMCInterval Defines the interval (in seconds) that the NetIQ Corporation AppManager
Client Communication Manager uses to poll the NetIQ Corporation
AppManager Client Resource Monitor for new data and events to be sent to
the management server. The default is 5 seconds.

This key is used when managed computers run in Autonomous mode.

RpcBatchHighWm Defines the high watermark for tuning the flow of network communication
from the NetIQ Corporation AppManager Client Communication Manager
service to the management server. Set when you configure network flow
with the AMAdmin_ConfigSiteNetFlowCtrl Knowledge Script.

RpcBatchIntv Defines the communication interval for dynamically adjusting the batch size
when the NetIQ Corporation AppManager Client Communication Manager
service transfers data to the management server. Set when you configure
network flow with the AMAdmin_ConfigSiteNetFlowCtrl Knowledge Script.

RpcBatchLowWm Defines the low watermark for tuning the flow of network communication
from the NetIQ Corporation AppManager Client Communication Manager
service to the management server. Set when you configure network flow
with the AMAdmin_ConfigSiteNetFlowCtrl Knowledge Script.

RpcBatchDynamicFlow Sets the flag that enables or disables dynamic flow control tuning. Zero
enables dynamic flow control. A non-zero value disables dynamic flow
control. The default is zero.

192 Registry Keys

B.6.3 Tracing
The NetIQccm\Tracing folder stores the key for tracing the activity of the NetIQ Corporation
AppManager Client Communication Manager service.

Key Description

TraceCCM Sets the flag that enables or disables tracing for the AppManager Client Communication
Manager service. A value of zero (0) turns tracing off and a non-zero value turns tracing
on. Setting a higher value for this key generates more verbose tracing output.

If set to 1 or higher, the Client Communication Manager logs information about its activity
to the ccmtrace.log file.

B.7 NetIQmc Folder

The SOFTWARE\NetIQ\AppManager\4.0\NetIQmc (for 32-bit computers) and
SOFTWARE\SysWow6432\NetIQ\AppManager\4.0\NetIQmc (for 64-bit computers) folders store keys
that define characteristics of the NetIQ Corporation AppManager Client Resource Monitor service
and control many aspects of the managed computer’s behavior and communication with other
services. There are several keys directly under the NetIQmc folder. Additional keys are organized in
the following subfolders:

 Section B.7.2, “Admin,” on page 194

 Section B.7.3, “Config,” on page 195
 Section B.7.4, “Security,” on page 198
 Section B.7.5, “Tracing,” on page 199

B.7.1 Registry Keys in the NetIQmc Folder

The NetIQmc folder contains general-purpose keys for the NetIQ Corporation AppManager Client
Resource Monitor.

Key Description

Exchange Mailbox Specifies the Exchange mailbox alias name to use if the managed computer
can send MAPI mail as an action or if the agent is set to monitor Exchange
Server on this computer. Set during installation when you enable MAPI mail
as an action or install the Exchange managed object.

Exchange Profile Specifies the Exchange profile name to use if the managed computer can
send MAPI mail as an action or if the agent is set to monitor Exchange Server
on this computer. Set during installation when you enable MAPI mail as an
action or install the Exchange managed object.

Exchange Server Specifies the Exchange Server name to use if the managed computer can
send MAPI mail as an action or if the agent is set to monitor Exchange Server
on this computer. Set during installation when you enable MAPI mail as an
action or install the Exchange managed object.

Local repository Specifies the path to the local repository. Set during installation. For example:

C:\Program Files\NetIQ\AppManager\db

Registry Keys 193

 Key Description

MS Backup Specifies the management server you have identified as the backup
management server for this managed computer. You designate the primary
and backup management server by running the SetPrimaryMS Knowledge
Script.

MS Primary Specifies the management server you have identified as the primary
management server for this managed computer. You designate the primary
and backup management server by running the SetPrimaryMS Knowledge
Script.

NetIQms Port Specifies the RPC port number where the management server listens for
communication from the NetIQ Corporation AppManager Client Resource
Monitor service. The default is 9999 (0x270f).

Port Specifies the RPC port where the AppManager Client Resource Monitor
service listens for communications from the management server. The default
is 9998 (0x270e).

ServiceDependency A comma-separated list of services on which the managed computer is

dependent. The Client Resource Monitor service checks for the dependent
services before starting up. The value is dependent on the managed objects
installed. For example, if the managed object for monitoring SQL Server is
installed, this key may contain a list similar to this:

MSSQLSever,SQLExecutive,msftpsvc

User Domain Specifies the domain for a Windows user account if a Windows user account
is being used for the agent services to run under. Set during installation if you:

 enable MAPI mail as an action

 install the Exchange managed object
 install a report-enabled agent
 choose to run the agent with a Windows account
 use the agent to perform remote agent installation
User Name Specifies the username for the Windows user account for the agent services.
Set during installation under the same circumstances as the User Domain key.

User Password Specifies the password for the Windows user account for the agent services.
Set during installation under the same circumstances as the User Domain key.

B.7.2 Admin
The NetIQmc\Admin folder contains keys that are used in agent self-monitoring.

Key Description

AdminEvtSev Defines the default AppManager event severity level for agent
self-monitoring events. Default event severity is 40.

DisableAdminEvtSev Sets the flag to enable or disable the event severity level for agent
self-monitoring events. Default event severity is 0.

DisableJobAbort Sets the flag that enables or disables the ability of a script to abort a job. If
this key is set to 0, the agent will allow a script to abort a job. If this key is set
to 1, the agent will not allow a script to abort a job. Default is 0.

194 Registry Keys

 Key Description

Knowledge Script Failure Contains internal Knowledge Script abort and exception codes. This is not
Events the same as the event severity value you can set on the Values tab of a
Knowledge Script Properties dialog box.

LastMCCheck Stores the timestamp of the last self-monitoring check in UTC format
(seconds since January 1, 1970, 12:00 am GMT). If the timestamp is older
than the MCFreezeThreshold, the NetIQ Corporation AppManager Client
Communication Manager attempts to restart the NetIQ Corporation
AppManager Client Resource Monitor service.

B.7.3 Config
The NetIQmc\Config folder contains keys that control agent autonomy, data persistence, event
handling, service availability, and failover support.

Key Description

AppDetectionPollInterval The interval at which the agent scans local resources for new software for
which there are modules available. This information is provided to the
deployment services to install modules according to deployment services
rules.

Autonomy Sets the flag that enables or disables agent autonomy. If set to 1, the
agent runs in Autonomous mode. If set to 0, autonomy is disabled. The
default is 1.

AutoUpdateMS Sets the flag that allows the managed computer to update its
management server information automatically. If set to 1, automatic
updates are allowed. If set to 0, the agent is prevented from automatically
updating its management server information.

If set to 1 and the management server is moved to another computer or

the name of the management server computer changes, the managed
computer updates its internal information about the management server
to reflect the new information.

The default is 1 to enable automatic updates.

ConcurrentRptJob Specifies the maximum number of concurrent reports that can run on the
agent. The default is 3.

Disable64BitPerProvider Determines whether AppManager uses both the 32-bit and 64-bit
performance providers or uses only the 32-bit performance provider.

EventLogLvl Defines the level of the event log messages in the Windows log files.
Valid values for this key include:

0x0 - Don't log any event

0x1 - Log Info events

0x2 - Log Warning events

0x4 - Log Error events

Values are added together to combine the events logged. For example,
0x5 logs Info and Error events. The default value is 0xF (Log everything).

Registry Keys 195

 Key Description

FullInventoryInterval Defines how often (in seconds) the agent sends full software inventory
information to Control Center. The default value is 86400 (every 24
hours).

JobSpacingInterval Controls how long an agent should pause for each subsequent job to run.
This registry key allows you to set a time delay between the jobs to
prevent overloading the system. The default delay is 3 seconds.

JobStatusPollInt Sets the interval for performing a health check of the communication
between the agent and the management server.

At each job polling interval, the agent collects data about the list of jobs
that are running, the version ID for each job, and the version number of
the agent. The version number of the agent is useful information during
upgrades. The default interval is 300 seconds.

MonitorInterval Defines the monitoring interval (in seconds) to check whether the
NetIQccm service is running. If you set an interval, the Client Resource
Monitor service automatically attempts to restart the Client
Communication Manager service if the service is detected down.

To turn off self-monitoring, set this value to 0. The default value is 1800
seconds (30 min).

NoEventSev Defines a severity level that does not raise an event. For example, you
can set a value for this key to trigger an action when a condition is met
but not raise an event in the Operator Console. The default value, 0,
disables the key.

NoMSEvent Specifies a comma-separated list of management server names that

should not receive event information. The managed computer does not
send event information to the computers you specify.

For example, to restrict the management servers MARS and AJAX from
receiving events from the AppManager agent on the local computer:

NoMSEvent:REG_SZ:MARS,AJAX

By default, no value is set for this key, indicating that no management

servers are prevented from receiving event information.

PDH threshold Threshold at which legacy performance providers are abandoned for
PDH information.

Persistent Sets the flag that enables or disables data persistence. If this key is set to
1, persistence is enabled and events and data are written to the local
repository when communication with the management server fails.

If this key is set to 0, events and data are only transferred to the
management server. If communication with the management server is
interrupted, any event or data collected during the interruption is lost.

The default is 1.

196 Registry Keys

Key Description

PrimaryMSFailOverCtrlTimes Specifies the threshold for the number of times the agent should send
ping requests to the primary management server before failing over to
the secondary management server. If the ping request fails the number of
times specified, the agent identifies the primary management server as
unavailable and transfers all events and data to the backup management
server, if you have designated one.

If you have not designated a secondary management server, events and

data are written to the local repository until communication with the
primary management server is restored.

The default value for this key is 3 ping attempts.

PrimaryMSFailOverInterval Specifies the interval in seconds to ping the primary management server.
The default is 60 seconds.

StartUpDelay Controls how long the agent should pause after the Client
Communication manager service starts before starting an iteration of any
job on the agent.

The default is 15 seconds.

SvcWaitInterval Specifies the time, in seconds, for the Client Resource Monitor service to
wait before attempting to restart dependent services. The default is 5
seconds.

vbStringSpaceSize Specifies the string size, in bytes, allocated for the Summit scripting
engine to use. The default value is 1048576 characters (0x100000).

VMRPCNoOfRetry Sets the number of retry attempts for making RPC calls from the agent to
the management server to send software inventory and application
detection data.

The default is 3.

VMRPCTimeout The time (in seconds) the agent will wait to receive an RPC response
from the management server before producing an error.

The default is 60.

Registry Keys 197

B.7.4 Security
The NetIQmc\Security folder contains keys that control the management servers authorized to
communicate with the managed computer and the operations that the local managed computer is
authorized to perform.

Key Description

AllowDosCmd Specifies the management servers that are allowed to run DOS commands on the
local computer.

The default value, *, allows all management servers to initiate DOS commands.

To create a restricted list of management servers that can run DOS commands,
set this key to a comma-separated list of computer names.

For example, if only SHASTA and DYNAMO are allowed to run DOS commands:

AllowDosCmd:REG_SZ:shasta,dynamo

This registry key value controls whether the General_RunDOS and

Action_DosCommand Knowledge Scripts can run commands on this managed
computer.

NOTE: Checking is based on the management server that initiates the job, not
the user account that starts it. For example, if the management server TANGO
starts a RunDOS job on SHASTA, but was not included in the key, the job on
SHASTA will abort with an error.

AllowMS Specifies the list of management servers that can communicate with the Client
Resource Monitor.

An asterisk (*) authorizes all management servers to communicate with the local
computer.

NOTE: You should not use this registry key to enforce security or control
communication between the management server and the managed computer
within a single management site. If you have more than one management server
in a site, use the SetPrimaryMS Knowledge Script to identify the primary and
secondary management server for each managed computer. Use the Windows
and UNIX key file utilities to manage security for the site.

AllowReboot Specifies the management servers that can request the local managed computer
to reboot.

The default value, 0, prevents all management servers from rebooting managed
computers.

To restrict reboot operations to specific computers, enter a comma-separated list

of computer names. For example:

AllowReboot:REG_SZ:NYC001,190.12.1.28

You can use the asterisk (*) wild card to permit all management servers to reboot
the local managed computer.

NOTE: You must specify at least one computer if you want to use the
Action_RebootSystem Knowledge Script.

RemoveAllowMSStar Indicates whether to remove the anonymous authorization that allows all
management servers to communicate with the agent (AllowMS set to *). When set
to 1, this key updates the AllowMS key with current information when you change
the agent's designated primary or secondary management server.

198 Registry Keys

B.7.5 Tracing
The NetIQmc\Tracing folder stores keys for tracing the activity of the NetIQ Corporation
AppManager Client Resource Monitor service and managed objects.

Key Description

TraceKS Specifies the tracing level for Knowledge Scripts. The higher the value, the
more verbose the tracing output. Specifying 0 turns tracing off. The default
is 1 (0x1).

Enabling Knowledge Script tracing creates an ASCII copy of the compiled

Knowledge Script with debugging line numbers in the TraceLogPath\mc
subdirectory and logs entries for each job running on the agent in the
mctrace.log file. A separate file is created for each job and action
executed on the agent. The name of each file includes the related JobID
and the SiteID.

TraceMC Specifies the tracing level for the NetIQ Corporation AppManager Client
Resource Monitor service. The higher the value, the more verbose the
tracing output. Specifying 0 turns tracing off. The default is 1 (0x1).

If you enable TraceMC, the NetIQ Corporation AppManager Client

Resource Monitor (NetIQmc) records information about its activity in the
mctrace.log file. The information recorded in this file includes the status
of polling threads, job requests, and job execution.

If you also enable TraceKS, the mctrace.log also includes line-by-line

trace entries for each job running on the agent to help you step through the
Knowledge Script as it is executed to locate a point of failure.

TraceMOcomponent Specifies the tracing level for specific application managed objects (for
example, use TraceMOactiveds to enable tracing for Active Directory
managed objects). The higher the value, the more verbose the tracing
output. Specifying a value of zero (0) turns tracing off. The default is 16
(0x10).

If you enable tracing for any managed object, the mo.log records
information about monitoring activity for that managed object. The
information recorded includes all function calls made from the managed
object during job execution.

B.8 NetIQms Folder

The SOFTWARE\NetIQ\AppManager\4.0\NetIQms (for 32-bit computers) and
SOFTWARE\SysWow6432\NetIQ\AppManager\4.0\NetIQms (for 64-bit computers) folders store keys
that define characteristics of the NetIQ Corporation AppManager Management Service. These keys
are the registry keys that you are most likely to be interested in or need to modify. They control many
important characteristics of a management server’s behavior and communication with other
components. Several keys are directly under the NetIQms folder. Additional keys are organized in the
following subfolders:

 Section B.8.2, “Admin,” on page 200

 Section B.8.3, “Config,” on page 201
 Section B.8.4, “RP,” on page 204
 Section B.8.5, “Tracing,” on page 204

Registry Keys 199

 NOTE: The Integration folder contains keys used by AppManager connectors.

B.8.1 Registry Keys in the NetIQms Folder

The NetIQms folder contains general-purpose keys for the NetIQ Corporation AppManager
Management Service.

Key Description

NetIQmc Port Specifies the RPC port that the AppManager Client Resource Monitor service
listens on for communication from the management server. The default is 9998
(0x270e).

Port Specifies the RPC port number that the management server listens on for
communication from the Client Resource Monitor service. The default is 9999
(0x270f).

RP database Specifies the name of the repository database. Set during installation. For
example:

QDB

RP DSN Specifies Data Source Name for the ODBC connection to the repository. Set
during installation. For example:

QDBms

RP Logon Timeout Specifies the maximum period of time, in seconds, that the management server
should wait for a successful connection to SQL Server.

The management server uses this value to determine whether SQL Server is
down when the management server attempts the connection.

The default is 600 seconds.

RP password Stores the encrypted password for the management server to use in logging on
to the repository.

RP server Stores the name of the computer where the repository is located.

RP username Stores the username the management server uses to connect to the QDB. The
default is netiq.

Unix Port Specifies the port number that the UNIX agent uses to communicate with the
management server.

UUID Stores a unique identifier for the management server.

B.8.2 Admin
The NetIQms\Admin folder contains keys that are used in management server self-monitoring.

Key Description

AdminEvtSev Defines the default AppManager event severity level for

management server self-monitoring events. The default event
severity level is 40.

200 Registry Keys

 Key Description

DisableAdminEvt Sets the flag indicating whether an event should be raised if an

agent needs to be restarted.

EnableMachineGrayOut Controls the display of computers in the TreeView pane of the

Operator Console.

If set to 1, computers that are unavailable to the management

server are displayed as grayed-out in the TreeView pane of the
Operator Console. You cannot start or stop AppManager jobs
inactive computers.

If set to 0, computers that are unavailable to the management

server are not grayed out in the TreeView pane of the Operator
Console.

The default value is 1.

General failure Events Used internally by management servers for specific error
conditions.

General Success Events Used internally by management servers for specific success
conditions.

GenKeyMismatchEvents Specifies whether a key mismatch between the agent and the
management server should generate an Application Log event. The
default value is 1 to generate an event is there is a mismatch in the
key information.

LogOptionalEvt Set the flag to enable or disable logging of optional events. The
default is 0.

MinKeyMismatchEventPeriod Specifies the number of seconds to wait before logging another

Application Log event if a key mismatch is detected.

B.8.3 Config
The NetIQms\Config folder contains keys that control event and data handling and communication
with managed computers.

Key Description

Allow Agent Install Identifies the management server to use for performing remote agent
installation. Set to 1 to all the local management server to be used for
remote installation jobs. Set to 0 to prevent a management server from
attempting to start installation jobs. The default value is 1.

NOTE: If you have more than one management server in your environment,
you should select a single management server for performing installation-
related tasks and manually set this registry key to 0 on all other
management servers.

Comm Timeout Specifies the time in milliseconds for the management server to wait before
sending a message to a managed computer if there is an outstanding call.
The default is 5000 milliseconds.

Data Thread Specifies the number of data worker threads. Increasing this value
increases the number of connections to the database, thereby increasing
overhead. The default is 2 threads.

Registry Keys 201

 Key Description

Enable Flow Control Sets the flag that grants control over network traffic to the Client
Communication Manager service on the management server. Enabling flow
control allows the agent on the management server to use a high
watermark, low watermark, and a transfer interval to dynamically adjust the
flow of data.

Set this key to 0 to disable flow control. Set this key to 1 to enable flow
control. The default is 1.

Event Thread Specifies the number of event worker threads. Increasing this value
increases the number of connections to the database, thereby increasing
overhead. The default is 2 threads.

Job Dispatch Thread Specifies the number of threads the management server creates for
dispatching jobs. The default is 5 threads.

Job Poll Interval Sets the interval, in seconds, for the job polling thread to check for
outstanding (pending) job requests. The default is 5 seconds.

Job Resend Frequency Specifies the maximum number of synchronization updates to ignore before
checking for orphan or error jobs. The default is 1 update.

Job Status Change Batch Determines whether the management server updates the QDB in batches
or sequentially. If set to 1, the management server updates the QDB in a
single batch when it receives updates from the agent. If set to 0, the
management server updates the QDB separately for each job.

The default is 0.

Job Status Change Thread Specifies the number of job status change worker threads. Increasing this
value increases the number of connections to the database, thereby
increasing overhead. The default is 1.

Job Status Check Interval Set the interval, in seconds, for the job status check thread. The job status
check thread performs a “job handshake” with each managed computer.
The default is 300 seconds.

Job Status IP Refresh Sets the minimum interval, in seconds, before an IP name resolution refresh
Interval is performed by the job status check thread. The default is 1000 seconds.

Machine Poll Interval Sets the interval, in seconds, for the machine polling thread.The default is
500 seconds.

MaxQueueItem Sets the maximum size of this request queue for UNIX and Linux
communications. When a request comes from a UNIX agent, it is placed in
a request queue for processing. Whenever a thread from the thread pool
becomes available (idle), it picks up an item in this request queue to
process. The default maximum size is 1000 items.

MaxSocketThread Sets the maximum number of threads in the thread pool for processing
requests.

MC Job Abort Event Sev Sets the severity level for an event caused by job aborting. The default
severity level is 10.

Number of Update Retry Specifies the number of times a management server should attempt an
update. The default is 1.

OptimisticSend Instructs the management server to clear out the list of pending requests
after responding to the heartbeat from a UNIX agent.

Orphan Job Event Sev Sets the severity level for an event caused orphaned jobs. The default is 5.

202 Registry Keys

Key Description

Persistent IOC Sets the flag to enable or disable the persistent IOC data and event
mapping file. The default is 1.

Ping Machine Poll Interval Sets the interval for the ping machine thread.

The default is 5 seconds.

PIOC Data Map File Size MB Defines the size of the persistent IOC file for data. The default is 25 MB.

PIOC Event Map File Size Defines the size of the persistent IOC file for event information. The default
MB is 25 MB.

PIOC JobStat Map File Size Defines the size of the persistent IOC file for job information. The default is
MB 25 MB.

PIOC Map File Path Specifies the path to where the persistent IOC file is stored. For example:

C:\Program Files\NetIQ\AppManager\dat\pioc

RecordEvents Sets the flag that controls how the management server handles events. The
valid values for this key are:

 0 - Don't record events in the QDB

 1 - Record events in the QDB (normal operation)
 2 - Record and automatically acknowledge events in the QDB
The default is 1.

RPC Encryption Specifies whether the management server uses encrypted communication.
If set to 1, RPC encryption is enabled. If set to 0, encryption is not enabled.
Set during installation.

SocketRetryInterval Defines the retry interval (in milliseconds) for sending or receiving data
between a UNIX agent and the management server. If the management
server fails to send data to the agent, it will wait for the retry interval and
then try again.

The default is 500.

The number of retry attempts is defined by the MaxSocketRetryCount

value, which has a default value of 10.

StateChangeClassic Defines the content of short and detailed event messages for state change
events when the Generate a new event when original event condition
no longer exists option is selected on the Advanced tab of a Knowledge
Script Properties dialog box. When set to 0, the short event message
contains “State Change” and the detailed message contains the original
message for the event that was closed. When set to 1, the short event
message contains the original event ID and the string “State Change” and
the detailed message contains the original event ID for the event that was
closed.

The default is 0.

Registry Keys 203

 Key Description

Unix Machine Check Sets the interval, in seconds, to control how often the management server
Interval checks the time of the last heartbeat signal from each of its UNIX agents.
Used in conjunction with the Unix Machine Timeout value to determine
whether a UNIX or Linux computer is available.

If the management server hasn’t received a heartbeat signal within the

period specified as the Unix Machine Timeout value, the UNIX agent is
considered unavailable. The default is 300 seconds.

Unix Machine Timeout Sets the interval, in seconds, that identifies a UNIX agent as unavailable. If
the UNIX agent does not send a heartbeat signal within this period of time, it
is considered unavailable. The default is 300 seconds.

B.8.4 RP
The NetIQms\RP folder contains keys that control connections to the repository.

Key Description

RP Connection Refresh Wait Sets the interval between the management server’s attempts to reconnect
to the repository when SQL Server goes down.The default is 300 seconds.

RP RPC Shutdown Threshold Specifies the number of times the management server tries to connect to
SQL Server before shutting down the RPC Server thread when SQL Server
goes down. The default is 0.

Stop Rpc On SQL Failure Sets a flag to stop the RPC service when the management server detects
that the SQL Server is down. Setting this key to 1 stops the RPC service
and 0 turns this feature off. The default is 1.

B.8.5 Tracing
The NetIQms\Tracing folder stores keys for tracing the activity of the NetIQ Corporation
AppManager Management Service and connections to the repository.

Key Description

Action Log Sets the flag to enable or disable tracing for management server actions
and proxy actions. Set to 1 to enable action debugging for management
server actions. Information about action processing errors are written to the
msaction.log file.

The default is 0 (off).

NT Event Log Tracing Sets the flag to enable or disable tracing for the Windows event logs. Set to
Threshold 1 to enable tracing for the Windows logs. The default is 1 (on).

Qdb Log Sets the flag to enable or disable tracing for repository communication
errors. Set to 1 to enable repository connection tracing. Errors are written to
msqdb.log file.

The default is 0 (off).

204 Registry Keys

 Key Description

Rpc Log Sets the flag to enable or disable tracing for RPC. Set to 1 enable tracing for
RPC communication between the management server and the agents.

The default is 0 (off).

TraceCache Sets the flag to enable or disable tracing for the cache. Set to 1 to enable
tracing for the IOC cache processing on the management server.

The default is 0 (off).

TraceData Sets the flag to enable or disable tracing for data processing. Set to 1 to
enable data point tracing on the management server.

The default is 0 (off).

TraceEvent Sets the flag to enable or disable tracing for event processing. Set to 1 to
enable event tracing on the management server. The default is 0 (off).

TraceJob Sets the flag to enable or disable tracing for job processing. Set to 1 to
enable job tracing on the management server. The default is 0 (off).

TraceOther Sets the flag to enable or disable tracing for other processing. Set to 1 to
enable other process tracing. The default is 1 (on).

TraceQueueSize Sets the size of the temporary message queue. The management server
writes log messages to a queue, which is cached in memory temporarily.
When the queue reaches the size set by this registry key, a background
thread is activated to flush the messages from the temporary queue to the
log file.The default is 100.

TraceRepository Sets the flag to enable or disable tracing for communication with the
repository. Set to 1 to enable tracing. The default is 1 (on).

TraceRPC Sets the flag to enable or disable tracing for RPC communication. Set to 1
to enable RPC tracing between the management server and the repository.
The default is 1 (on).

TraceSockets Sets the flag to enable or disable tracing for socket communication. Set to 1
to turn on socket tracing. The default is 0 (off).

TraceTimeOut Sets the interval for activating the background thread that flushes the
messages from the temporary queue to the log file. In addition to the
TraceQueueSize, this key controls when the background thread should
flush messages to the log file.The default is 60 seconds.

TraceXml Sets the flag to enable or disable tracing for XML communication. Set to 1 to
turn on XML tracing. The default is 0 (off).

B.9 QDB Folder

The SOFTWARE\NetIQ\AppManager\4.0\QDB\servername\QDB (for 32-bit computers) and
SOFTWARE\Syswow6432\NetIQ\AppManager\4.0\QDB\servername\QDB (for 64-bit computers)
folders contain keys that store information about the configuration of the repository database.

NOTE: This folder is only available in upgraded environments. New AppManager 8.0 installations do
not have this folder.

Registry Keys 205

 Key Description

Data Device Name Specifies the name of the repository data device specified during
installation. Set during installation.

Data Device Path Specifies the path for the repository data device specified during installation.
Set during installation.

Data Device Size Specifies the size of the repository data device specified during installation.
Set during installation.

Database Name Specifies the name for the repository database specified during installation.
Set during installation.

Log Device Name Specifies the name for the repository log device specified during installation.
Set during installation.

LogDevice Path Specifies the path for the repository log device specified during installation.
Set during installation.

LogDevice Size Specifies the size of the repository log device specified during installation.
Set during installation.

sa Password Specifies the encrypted password for the system administrator. Set during
installation.

SQL Path Specifies the base path for SQL Server. For example:

C:\Program Files\Microsoft SQL Server\MSSQL

SQL Server Name Name and path of the SQL Server computer.

B.10 Repository Browser

The SOFTWARE\NetIQ\AppManager\4.0\Repository Browser (for 32-bit computers) and
SOFTWARE\SysWow6432\NetIQ\AppManager\4.0\Repository Browser (for 64-bit computers)
folders contain keys that define the default and custom queries that are available in the Repository
Browser.

B.11 Security Manager

The SOFTWARE\NetIQ\AppManager\4.0\Security Manager (for 32-bit computers) and
SOFTWARE\SysWow6432\NetIQ\AppManager\4.0\Security Manager (for 64-bit computers) folders
contain keys that record the objects you have expanded in the Security pane, the identifier and name
of the role you are using as the default role, and the default SQL Server group for new SQL users.

NOTE: This folder is only available in upgraded environments. New AppManager 8.0 installations do
not have this folder.

206 Registry Keys

B.12 Other Folders
The SOFTWARE\NetIQ\Common\AMReports (for 32-bit computers) and
SOFTWARE\SysWow6432\NetIQ\Common\AMReports (for 64-bit computers) folders contain keys used
in configuring and viewing AppManager reports. The SOFTWARE\NetIQ\Generic (for 32-bit
computers) and SOFTWARE\SysWow6432\NetIQ\Generic (for 64-bit computers) folders contain keys
that define the maximum size for tracing files and the directory to use for tracing output.

Registry Keys 207

208 Registry Keys