AppManager Administrator Guide
AppManager Administrator Guide
AppManager Administrator Guide
NetIQ® AppManager®
June 2011
Legal Notice
NetIQ AppManager is covered by United States Patent No(s): 05829001, 05986653, 05999178, 06078324, 06397359,
06408335.
THIS DOCUMENT AND THE SOFTWARE DESCRIBED IN THIS DOCUMENT ARE FURNISHED UNDER AND ARE SUBJECT TO THE
TERMS OF A LICENSE AGREEMENT OR A NON-DISCLOSURE AGREEMENT. EXCEPT AS EXPRESSLY SET FORTH IN SUCH LICENSE
AGREEMENT OR NON-DISCLOSURE AGREEMENT, NETIQ CORPORATION PROVIDES THIS DOCUMENT AND THE SOFTWARE
DESCRIBED IN THIS DOCUMENT "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. SOME STATES DO NOT
ALLOW DISCLAIMERS OF EXPRESS OR IMPLIED WARRANTIES IN CERTAIN TRANSACTIONS; THEREFORE, THIS STATEMENT MAY NOT
APPLY TO YOU.
This document and the software described in this document may not be lent, sold, or given away without the prior written
permission of NetIQ Corporation, except as otherwise permitted by law. Except as expressly set forth in such license
agreement or non-disclosure agreement, no part of this document or the software described in this document may be
reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, or otherwise,
without the prior written consent of NetIQ Corporation. Some companies, names, and data in this document are used for
illustration purposes and may not represent real companies, individuals, or data.
This document could include technical inaccuracies or typographical errors. Changes are periodically made to the
information herein. These changes may be incorporated in new editions of this document. NetIQ Corporation may make
improvements in or changes to the software described in this document at any time.
© 2011 NetIQ Corporation. All rights reserved.
U.S. Government Restricted Rights: If the software and documentation are being acquired by or on behalf of the U.S.
Government or by a U.S. Government prime contractor or subcontractor (at any tier), in accordance with 48 C.F.R.
227.7202-4 (for Department of Defense (DOD) acquisitions) and 48 C.F.R. 2.101 and 12.212 (for non-DOD acquisitions),
the government’s rights in the software and documentation, including its rights to use, modify, reproduce, release, perform,
display or disclose the software or documentation, will be subject in all respects to the commercial license rights and
restrictions provided in the license agreement.
Check Point, FireWall-1, VPN-1, Provider-1, and SiteManager-1 are trademarks or registered trademarks of Check Point
Software Technologies Ltd.
ActiveAudit, ActiveView, Aegis, AppManager, Change Administrator, Change Guardian, Compliance Suite, the cube logo
design, Directory and Resource Administrator, Directory Security Administrator, Domain Migration Administrator,
Exchange Administrator, File Security Administrator, Group Policy Administrator, Group Policy Guardian, Group Policy
Suite, IntelliPolicy, Knowledge Scripts, NetConnect, NetIQ, the NetIQ logo, PSAudit, PSDetect, PSPasswordManager,
PSSecure, Secure Configuration Manager, Security Administration Suite, Security Manager, Server Consolidator, VigilEnt,
and Vivinet are trademarks or registered trademarks of NetIQ Corporation or its subsidiaries in the USA. All other company
and product names mentioned are used only for identification purposes and may be trademarks or registered trademarks of
their respective companies.
For purposes of clarity, any module, adapter or other similar material ("Module") is licensed under the terms and conditions
of the End User License Agreement for the applicable version of the NetIQ product or software to which it relates or
interoperates with, and by accessing, copying or using a Module you agree to be bound by such terms. If you do not agree to
the terms of the End User License Agreement you are not authorized to use, access or copy a Module and you must destroy all
copies of the Module and contact NetIQ for further instructions.
This product claims FIPS compliance by use of one or more of the Microsoft cryptographic components listed below. These
components were certified by Microsoft and obtained FIPS certificates via the CMVP.
893 Windows Vista Enhanced Cryptographic Provider (RSAENH)
894 Windows Vista Enhanced DSS and Diffie-Hellman Cryptographic Provider (DSSENH)
989 Windows XP Enhanced Cryptographic Provider (RSAENH)
990 Windows XP Enhanced DSS and Diffie-Hellman Cryptographic Provider (DSSENH)
997 Microsoft Windows XP Kernel Mode Cryptographic Module (FIPS.SYS)
1000 Microsoft Windows Vista Kernel Mode Security Support Provider Interface (ksecdd.sys)
1001 Microsoft Windows Vista Cryptographic Primitives Library (bcrypt.dll)
1002 Windows Vista Enhanced Cryptographic Provider (RSAENH)
1003 Windows Vista Enhanced DSS and Diffie-Hellman Cryptographic Provider (DSSENH)
1006 Windows Server 2008 Code Integrity (ci.dll)
1007 Microsoft Windows Server 2008 Kernel Mode Security Support Provider Interface (ksecdd.sys)
1008 Microsoft Windows Server 2008
1009 Windows Server 2008 Enhanced DSS and Diffie-Hellman Cryptographic Provider (DSSENH)
1010 Windows Server 2008 Enhanced Cryptographic Provider
1012 Windows Server 2003 Enhanced Cryptographic Provider (RSAENH)
This product may also claim FIPS compliance by use of one or more of the Open SSL cryptographic components listed below.
These components were certified by the Open Source Software Institute and obtained the FIPS certificates as indicated.
918 - OpenSSL FIPS Object Module v1.1.2 - 02/29/2008 140-2 L1
1051 - OpenSSL FIPS Object Module v 1.2 - 11/17/2008 140-2 L1
1111 - OpenSSL FIPS Runtime Module v 1.2 - 4/03/2009 140-2 L1
Note: Windows FIPS algorithms used in this product may have only been tested when the FIPS mode bit was set. While the
modules have valid certificates at the time of this product release, it is the user's responsibility to validate the current module
status.
EXCEPT AS MAY BE EXPLICITLY SET FORTH IN THE APPLICABLE END USER LICENSE AGREEMENT,
NOTHING HEREIN SHALL CONSTITUTE A WARRANTY AND ALL EXPRESS OR IMPLIED CONDITIONS,
REPRESENTATIONS, AND WARRANTIES INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTY
OR CONDITION OF FITNESS FOR A PARTICULAR PURPOSE ARE HEREBY EXCLUDED TO THE EXTENT
ALLOWED BY APPLICABLE LAW AND ARE EXPRESSLY DISCLAIMED BY NETIQ, ITS SUPPLIERS AND
LICENSORS.
Contents
Chapter 1
Introduction to AppManager Site Administration 1
The AppManager Management Site...........................................................................................................................1
Understanding Site Communication.........................................................................................................................2
Understanding the Site Administrator’s Role............................................................................................................3
Developing a Management Site and Site Policies.......................................................................................................4
Managing a Small, Internal Network ............................................................................................................4
Managing a Mid-size Network With Local and Remote Facilities................................................................5
Monitoring Large Environments with Multiple Management Servers ........................................................7
Monitoring a Widely Distributed Enterprise ...............................................................................................9
Defining a Management Site.......................................................................................................................10
Planning and Staging a Deployment...........................................................................................................10
Defining Site-Level Policies .........................................................................................................................10
Managing Multiple Sites ...........................................................................................................................................10
Chapter 2
Site Communication and Security 11
AppManager Communication Protocols ................................................................................................................. 11
Understanding Communication Security Levels ..................................................................................................... 11
Understanding FIPS Compliance ............................................................................................................................13
Using Secure Communication for Windows Agents...............................................................................................13
Changing the Security Level for Management Servers ............................................................................... 14
Changing the Security Level for Windows Agents ..................................................................................... 14
Generating a Repository Key for Windows ................................................................................................15
Extracting and Sharing Key Information from the Repository .................................................................. 16
Extracting the Key File for Windows Agents .............................................................................................. 17
Updating the Key File for Windows Agents ............................................................................................... 17
Using Secure Communication for UNIX Agents .................................................................................................... 18
Changing the Security Level for Management Servers ...............................................................................19
Changing the Security Level for UNIX Agents ..........................................................................................19
Generating a Public/Private Key Pair for UNIX Agents ............................................................................19
Extracting and Sharing Key Information from the Repository .................................................................. 21
Extracting the Public Key for UNIX Agents ............................................................................................... 21
Updating the Public/Private Key Pair for UNIX Agents............................................................................22
Contents v
Setting up Primary and Backup Management Servers.............................................................................................22
Designating the Local Management Server as the Primary Management Server.......................................23
Configuring a Primary and Secondary Management Server for Windows Agent Computers..................24
Configuring a Primary and Secondary Management Server for UNIX Agent Computers .......................24
How Failover Works ....................................................................................................................................25
Distributing Processing Load ......................................................................................................................26
Verifying the Management Server Assigned to an Agent Computer .........................................................26
Changing a Management Server Assigned to an Agent Computer ...........................................................26
Adding a New Management Server ............................................................................................................27
Chapter 3
Managing Security for AppManager and Control Center 29
Understanding User Security ...................................................................................................................................29
Using Windows Authentication Security ...................................................................................................30
Using Mixed Mode Security........................................................................................................................30
Managing Users with Windows Groups.....................................................................................................30
Managing Operator Console Security ...................................................................................................................... 31
Starting Security Manager ........................................................................................................................... 31
Adding Operator Console Users ................................................................................................................33
Managing Operator Console User Accounts..............................................................................................35
Operator Console Roles..............................................................................................................................35
Understanding Predefined Operator Console Roles .................................................................................36
Modifying a Predefined Role ......................................................................................................................36
Regenerating Predefined Roles ................................................................................................................... 37
Understanding Custom Roles..................................................................................................................... 37
Renaming a Role .........................................................................................................................................38
Deleting a Role ............................................................................................................................................38
Selecting the Default Role...........................................................................................................................39
Changing User Roles ..................................................................................................................................39
Modifying the Security Profile for a Role ...................................................................................................39
Understanding Access Restrictions.............................................................................................................40
Functional Rights for the Operator Console.............................................................................................. 41
Rights in Other Consoles............................................................................................................................ 41
Defining Functional Rights for a Role........................................................................................................42
Restricting Access to AppManager Views ...................................................................................................42
Setting Computer-Based Exceptions for a Role ..........................................................................................43
Restricting Access to Knowledge Scripts by Category.................................................................................43
Viewing a Security Profile ...........................................................................................................................44
Disabling an Operator Console User Account...........................................................................................44
Removing a User Account from Security Manager ....................................................................................45
vi Administrator Guide
Managing Control Center Security ..........................................................................................................................45
Configuring Control Center Permissions...................................................................................................45
Adding a Control Center User ...................................................................................................................46
Understanding the Administrator Group ..................................................................................................48
Creating a User Group................................................................................................................................49
Modifying a User Group .............................................................................................................................50
Removing a User Group .............................................................................................................................50
Copying a User Group ................................................................................................................................ 51
Default User Groups ................................................................................................................................... 51
Understanding Permission Sets ..................................................................................................................52
Creating a Permission Set............................................................................................................................53
Modifying a Permission Set.........................................................................................................................54
Removing a Permission Set .........................................................................................................................54
Copying a Permission Set............................................................................................................................55
Setting Global Permissions..........................................................................................................................55
Permissions for Control Center ..................................................................................................................56
Granting and Removing Access to Management Groups ..........................................................................58
Default User Groups and Permission Sets..................................................................................................59
Understanding the Interaction Between Control Center Console and Operator Console Security ........66
Chapter 4
Managing Jobs 69
Deploying to a Pilot Group ......................................................................................................................................69
Implementing Core Monitoring Support ................................................................................................................70
Collecting Data ........................................................................................................................................... 71
Expanding the Scope of Your Deployment .............................................................................................................. 74
Running Additional Knowledge Scripts ..................................................................................................... 74
Strategies for Managing Systems and Applications ..................................................................................................75
Managing Existing Jobs.............................................................................................................................................79
Suspending AppManager Monitoring......................................................................................................................80
Reviewing and Refining the Deployment.................................................................................................................82
Chapter 5
Managing Events 83
Deciding When to Raise Events ...............................................................................................................................83
Understanding Events and Event Messages .............................................................................................................84
Setting Preferences for Event Information ...............................................................................................................85
Understanding Event Archiving...............................................................................................................................88
Using Advanced Event-handling Properties.............................................................................................................89
Notifying Individuals of Events ................................................................................................................................ 91
Sending an Email Event Notification .........................................................................................................92
Sending a Page as an Event Notification.....................................................................................................92
Sending Event Information to Another Console .......................................................................................94
Triggering Corrective Actions for Events .................................................................................................................95
Contents vii
Chapter 6
Managing Data 97
Deciding When to Collect Data...............................................................................................................................97
Understanding Data Collection for Charts, Graphs, and Reports .........................................................................99
Setting Preferences for Real-time Charts and Graphs..............................................................................................99
Understanding Data Archiving and Reporting......................................................................................................100
Using Advanced Data-handling Properties for Jobs...............................................................................................102
Chapter 7
Managing a QDB 105
Understanding the AppManager Repository .........................................................................................................105
Understanding the Tables .........................................................................................................................106
Stored Procedures......................................................................................................................................108
SQL Server Jobs.........................................................................................................................................108
Managing Data Streams.......................................................................................................................................... 110
Managing Event Information ................................................................................................................................. 111
Managing Audit Trails ............................................................................................................................................ 112
Checking SQL Server Configuration ..................................................................................................................... 112
Expanding the Size of a Repository ........................................................................................................................ 115
Checking the Integrity of the Repository ............................................................................................................... 116
Backing Up the QDB.............................................................................................................................................. 117
Restoring the Repository with SQL Server Management Studio.............................................................120
Removing Archived Data and Events..................................................................................................................... 121
Using DeleteOldArchiveData to Remove Data ........................................................................................ 121
Using Standard SQL Statements to Remove Data ................................................................................... 121
Moving the QDB ....................................................................................................................................................123
Using the Repository Browser ................................................................................................................................123
Chapter 8
Managing Control Center 125
Understanding the Control Center Repository .....................................................................................................125
Backing Up the Control Center Repository ..........................................................................................................126
Disconnecting Connections to the Control Center Repository ..............................................................126
Backing up the Control Center Repository with SQL Server Management Studio................................ 127
Restoring the Control Center Repository ................................................................................................128
Moving the Control Center Repository .................................................................................................................129
Moving the Deployment Service to a New Computer ...........................................................................................129
Moving the Deployment Web Service to a New Computer...................................................................................130
Moving the Command Queue Service to a New Computer.................................................................................. 131
Changing the Log Path for the Command Queue Service .................................................................................... 131
Changing the Log Path for the Deployment Service..............................................................................................132
Changing Configuration Parameters......................................................................................................................132
Chapter 10
Advanced Configuration Options for Windows Agents 143
Understanding the AppManager Agent................................................................................................................. 143
Understanding Agent Autonomy ........................................................................................................................... 144
Disabling Autonomous Operation ........................................................................................................... 145
Controlling the Interval for Checking Connectivity ................................................................................ 145
Using a Windows User Account for Agent Services.............................................................................................. 146
Restarting Agent Services ....................................................................................................................................... 147
Performing a Cold Startup of the AppManager Agent ............................................................................ 147
Setting the Agent Startup Mode ............................................................................................................... 147
Agent Self Monitoring ............................................................................................................................................ 148
Configuring Agents to Use a Hostname or IP Address ......................................................................................... 149
Configuring the Size of a Local Repository............................................................................................................ 149
Adjusting the Flow of Network Traffic...................................................................................................................150
Scheduling the Transfer of Events and Data..........................................................................................................150
Configuring Designated Management Servers....................................................................................................... 151
Changing Agent Failover Configuration .................................................................................................. 151
Removing a Designated Management Server ...........................................................................................152
Manually Controlling Network Communication ..................................................................................................153
Controlling Access to an Agent’s Local Repository ...............................................................................................153
Chapter 11
Optimizing Performance 155
Using Command-line Parameters...........................................................................................................................155
Specifying Logon Information................................................................................................................................155
Customizing the Operator Console Layout ...........................................................................................................156
Disabling Proxy Events in the TreeView pane ..........................................................................................158
Getting Help for Command-line Parameters .........................................................................................................159
Chapter 12
Developing Scripts to Perform AppManager Tasks 161
Understanding Command-line Scripting............................................................................................................... 161
About the Sample Command-line Scripts..............................................................................................................162
Running AppManager Command-line Scripts.......................................................................................................163
Creating a Default Logon Profile ...........................................................................................................................163
Contents ix
Creating Jobs...........................................................................................................................................................164
Starting, Stopping, Closing, and Deleting Jobs......................................................................................................165
Acknowledging, Closing, and Deleting Events ......................................................................................................166
Exporting Data Streams..........................................................................................................................................166
Scheduling Scripts to Run ...................................................................................................................................... 167
Getting Help For Sample Scripts............................................................................................................................168
Chapter 13
Troubleshooting and Diagnostic Tools 169
Understanding What AppManager Provides .........................................................................................................169
Using the Troubleshooter....................................................................................................................................... 170
Generating Reports from within Troubleshooter..................................................................................... 171
Selecting Specific Troubleshooter Reports ............................................................................................... 172
Clearing the Diagnostic Report’s Information Pane ................................................................................ 174
Exporting a Diagnostic Report ................................................................................................................. 174
Using the Command-line Program NetIQctrl........................................................................................................ 175
Starting NetIQctrl ..................................................................................................................................... 175
Available NetIQctrl Commands ............................................................................................................... 176
Using the NetIQ Diagnostics Utility ......................................................................................................................201
Viewing NetIQ Diagnostics Output..........................................................................................................201
Enabling Tracing and Viewing Log Files................................................................................................................202
Using the Log Analysis Tool ...................................................................................................................................204
Appendix A
Additional Site Administration Utilities 207
Key File Utility for Windows Agents......................................................................................................................207
Key File Utility for UNIX Agents ........................................................................................................................... 210
Persistent Data Utility............................................................................................................................................. 212
MAPI Mail Utility................................................................................................................................................... 213
SMTP Mail Utility .................................................................................................................................................. 213
SNMP Trap Utility.................................................................................................................................................. 214
Synchronization Utilities ........................................................................................................................................ 215
Time Conversion Utility......................................................................................................................................... 215
x Administrator Guide
Appendix B
Registry Keys 217
Modifying the Registry............................................................................................................................................ 217
Basic NetIQ Registry Folder ................................................................................................................................... 217
Main AppManager Keys and Folders ..................................................................................................................... 218
AgtShared folder ..................................................................................................................................................... 219
AMDevCon folder ..................................................................................................................................................220
NetIQccm Folder ....................................................................................................................................................220
NetIQmc Folder......................................................................................................................................................223
NetIQms Folder ......................................................................................................................................................228
QDB Folder ............................................................................................................................................................234
Repository Browser .................................................................................................................................................234
Security Manager ....................................................................................................................................................234
Web Folder..............................................................................................................................................................235
Other Folders..........................................................................................................................................................235
Chapter C
AM Health Knowledge Scripts 237
Monitoring the Health of a Management Server in an Untrusted Domain .........................................................238
CCComponentsHealth ..........................................................................................................................................239
HeartbeatUNIX ......................................................................................................................................................244
HeartbeatWin .........................................................................................................................................................246
QDBComponentsHealth .......................................................................................................................................249
Recommended Knowledge Script Groups .............................................................................................................254
Contents xi
xii Administrator Guide
About This Guide
The NetIQ AppManager product (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 administrators with a central, easy-to-use console to view critical server and
application resources across the enterprise. With AppManager, administrative staffs can monitor
computer and application resources, check for potential problems, initiate 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.
Convention Use
Using Help
AppManager provides task-based, reference, and context-sensitive Help.
To access task-based Help or search for Help topics, click Help Contents on the Main menu. To view
context-sensitive Help within dialog boxes, click Context Help or press F1.
You can get help on individual Knowledge Scripts in one of the following ways:
• On the Values tab of the Knowledge Script Properties dialog box, click Help or press F1.
• In the Knowledge Script pane of the Operator Console, highlight a Knowledge Script and press F1.
Note
You can access NetIQ Corporation Support without a password or registration. To access the Extended
Support site, you must be a registered AppManager customer.
In addition to the AppManager documentation, consult the documentation for your Windows or UNIX
operating system, or other application- or system-specific documentation for reference and conceptual
information. This background information can help you get the most out of your AppManager
installation.
Worldwide: www.netiq.com/about_netiq/officelocations.asp
United States and Canada: 888-323-6768
Email: info@netiq.com
Web Site: www.netiq.com
Worldwide: www.netiq.com/Support/contactinfo.asp
North, Central, and South America: 1-713-418-5555
Europe, Middle East, and Africa: +353 (0) 91-782 677
Email: support@netiq.com
Web Site: www.netiq.com/support
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.
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 “Implementation Guidelines” in the Installation Guide for AppManager and “Developing a
Management Site and Site Policies” on page 4 in this guide.
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 Corporation 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.
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 Corporation 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.
2 Administrator Guide
• 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 AppManager repository.
• Once the repository is updated, any new events or data points are sent to the Operator Console or
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).
4 Administrator Guide
• 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:
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 repository’s storage and
communication requirements.
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 may 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 of a firewall and some number of computers being monitored are outside of 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.
6 Administrator Guide
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 backup 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 complexity of the site becomes too difficult
to manage.
The following diagram represents a simple two-management server site configuration:
The site administrator could also designate ONYX as a secondary management server for the computers
managed by the computer ENCORE, so that both computers have a backup management server, or could
designate a separate management server computer that does not have any agent computers to be a
secondary management server. In this second scenario, the backup 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 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.
8 Administrator Guide
Monitoring a Widely Distributed Enterprise
A single management site with one repository 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 may not be possible, manageable, or desirable. For an enterprise with computer resources widely
distributed across a national or international network, multiple management sites may 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 repositories synchronized can be very 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.
In a decentralized environment with multiple administrative teams that operate independently,
consistency across multiple repositories may 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 may best
suit your needs.
The following diagram illustrates this type of site configuration:
10 Administrator Guide
Chapter 2
Site Communication and Security
This chapter describes ways you can customize the communication between your agent computers and the
AppManager 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.
Note
For simplicity and ease of maintenance, NetIQ Corporation recommends that you select one security
level to use for all agent computers in a site (Windows and UNIX agents).
12 Administrator Guide
Understanding FIPS Compliance
There are two components to AppManager FIPS compliance:
• The FIPS-compliant algorithms that AppManager uses for security levels 1 and 2
• 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.
Note
AppManager FIPS compliance is independent of operating system FIPS compliance.
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. For more
information about implementing FIPS-compliant algorithms, see the Control Center User Guide.
2. Run NQKeyGenWindows.exe to set the security level for the management server using the following
format:
NQKeyGenWindows -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
Notes
• All management servers that connect to the same repository must use the same security level for
all Windows agents.
• For encryption or management server authentication and encryption, use the same key file.
3. Change the security level for all of your Windows agents to match the new security level setting.
4. Stop and restart the NetIQ AppManager Management Service (NetIQms). This allows the
management server to receive the new security level information.
14 Administrator Guide
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 “Generating a Repository Key for Windows” on page 15.
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 207.
2. Run the NQKeyGenWindows.exe program to generate a new key and store the key information in the
repository:
NQKeyGenWindows -db database_name:user_name:sql_server -new
Variable Description
database_name The name of the AppManager repository.
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 “Extracting and Sharing Key Information from the Repository” on page 16.
4. Run NQKeyGenWindows.exe to extract the portion of the key for the agents to use with the following
command-line format:
NQKeyGenWindows -db database_name:user_name:sql_server\instance -ckey
filelocation
Note
If you are using Windows authentication to connect to the repository, leave the username blank. For
SQL Server authentication, type a SQL Server username for connecting to the repository. The
NQKeyGenWindows.exe 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.
Note
If you are using Windows authentication to connect to the repository, leave the username blank. To use
SQL Server authentication, type a SQL Server username for connecting to the repository. The
NQKeyGenWindows.exe program prompts for the password to use for the SQL Server account.
16 Administrator Guide
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 NQKeyGenWindows.exe 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 -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.
Note
If you are using Windows authentication to connect to the repository, leave the username blank. For
SQL Server authentication, type a SQL Server username for connecting to the repository. The
NQKeyGenWindows.exe 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. You can then use the
AMAdmin_AgentConfigSecurityKey Knowledge Script to distribute the agent key file to all of your
Windows agents. For more information, see “Updating the Key File for Windows Agents” on
page 17.
18 Administrator Guide
Changing the Security Level for Management Servers
After installation, you can use the NQKeyGenUNIX.exe program to change the security level for
communication between the management server and UNIX agents.
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 NQKeyGenUnix.exe to set the security level for the management server using the following
command:
NQKeyGenUnix -db database_name:user_name:sql_server -seclev level
For example, to log into the QDB on the computer named NYC2003 using your current Windows
account name and password and set the security level to use encryption only (1), type a command
similar to this:
NQKeyGenUnix -db qdb::nyc2003 -seclev 1
Note
All management servers that connect to the same repository must use the same security level, and, if
using management server authentication, the same key pair.
3. Stop and restart the NetIQ AppManager Management Service (NetIQms) to have the management
server receive the new security level information.
2. Run the NQKeyGenUnix.exe program to generate a new public/private key pair and store the key
information in the repository using the following command:
NQKeyGenUnix -db database_name:user_name:sql_server -new
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 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.
sql_server The name of the SQL Server computer where the AppManager repository is
installed.
For example, to use Windows authentication with a QDB installed on the server NYC2003, you would
type a command similar to this:
NQKeyGenUnix -db qdb::nyc2003 -new
Note
If you attempt to generate a new key pair when a key pair already exists in the repository, the
NQKeyGenUnix.exe program issues a warning. If you continue, the existing key pair becomes
inactive and is added to a historical listing of keys, and the new key pair is activated. You can remove
these older keys, as needed. For more information, see “Key File Utility for UNIX Agents” on
page 210.
3. Type a password for the public/private key pair.
4. Run NQKeyGenUnix.exe to extract the public portion of the key for the UNIX agents to use with the
following command:
NQKeyGenUnix -db database_name:user_name:sql_server -ckey filelocation
In specifying a path for the file, use a directory that you can access from the UNIX computers to be
managed.
5. Copy the public key file to a network location accessible from the UNIX computers to be managed.
6. Stop and restart the NetIQ AppManager Management Service (NetIQms) to register the new key pair
with the management server.
20 Administrator Guide
Extracting and Sharing Key Information from the Repository
The NQKeyGenUnix.exe program can extract the public/private key information and save it in a
password-protected file. Saving the information in a file allows you to share a single key pair across
multiple repositories.
If you want to create this password-protected file, run the NQKeyGenWindows.exe program using the
following command:
NQKeyGenWindows -db database_name:user_name:sql_server -skey filelocation
Note
If you are using Windows authentication to connect to the repository, leave the username blank. To use
SQL Server authentication, type a SQL Server username for connecting to the repository. The
NQKeyGenWindows.exe 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 NQKeyGenUnix.exe 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:
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 NetIQ AppManager Management Service (NetIQms) to
register the new key pair with the management server.
Notes
• 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 the agent can
communicate with the management server before you start re-key operations. And never stop the
UNIX agent management server during re-key operations.
22 Administrator Guide
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-based 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
“Designating the Local Management Server as the Primary Management Server” on page 23.
• 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 “Configuring a Primary and Secondary Management Server for Windows Agent
Computers” on page 24 and “Configuring a Primary and Secondary Management Server for UNIX
Agent Computers” on page 24.
24 Administrator Guide
7. Select either Set primary management server or Set secondary management server to designate a
new primary or secondary management server for this agent computer.
Note
You can only perform one management server operation at a time with this Knowledge Script.
Therefore, to change both the primary management server and the secondary management server,
you need to run this Knowledge Script twice. By default, if you use this Knowledge Script to specify a
new primary management server, the management server you specified when you installed the UNIX
agent becomes the secondary management server. You can use the Unset specified management
server option to remove a specific management server you no longer want to use as either a primary
or secondary management server.
8. If you want to change the port number the UNIX agents use to communicate with the management
server, you can type a new port number for the Port number for the management server parameter.
For information about setting a new port on the management server, see “Changing the Listening
Ports” on page 138.
Note
If you change the port number of the management server, you can use this Knowledge Script to
update this setting for your UNIX agents. After running the job, restart the management server to
restore communication using the new port number.
9. Click OK to run the job.
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.
When the management server designation is complete, you can run jobs on the agent computers. Job
requests will be sent from the designated primary management server.
26 Administrator Guide
Adding a New Management Server
You may 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, you should 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 management
server and 50% of the agent computers to use the new management server as the primary and to use the
first management server as the secondary management server.
To add a management server to your management site:
1. If you have not already explicitly designated the management server for every agent computer, run
the AMAdmin_SetPrimaryMS Knowledge Script on all 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 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
“Designating the Local Management Server as the Primary Management Server” on page 23.
4. Configure each agent computer to recognize the new management server as follows:
• To configure a Windows agent computer, run the AMAdmin_SetPrimaryMS Knowledge Script.
• To configure a UNIX agent computer, run the AMAdminUNIX_SetPrimaryMS Knowledge Script.
It can take up to 15 minutes for the management server to identify any changes to its list of agent
computers. Therefore, the agent computer can begin sending information to a newly designated
management server immediately, but there may be a delay of approximately 15 minutes before a newly
designated management server can begin sending new job information to the agent computer.
Configuring who has access to the AppManager Operator Console and 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 for the Operator Console using Security Manager.
For the Control Center console, 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. This chapter also describes:
• How to use Security Manager to define role-based security for AppManager Operator Console users,
add AppManager user accounts based on SQL Server login accounts, assign AppManager users to the
roles you create, and manage user rights.
• 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.
Note
You must be an SQL Server administrator to create SQL Server logins using Security Manager or the
Control Center console.
With mixed mode security, users can log on to an AppManager or Control Center repository using
Windows authentication or SQL Server authentication. If you are using mixed mode security, you need
to 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 have configured the account.
30 Administrator Guide
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 “Managing Control Center Security” on page 45 and “Adding a Control
Center User” on page 46.
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.
Field Description
Server The name of the Windows server where the AppManager repository is installed.
After you enter the name, the repositories available on that server are displayed in the
Repository list.
Notes
• If you are running SQL Server in Windows Authentication mode, you will not see this
option.
• When using a SQL user account, make sure the password for the user account is less
than 32 characters. If your password exceeds 32 characters, Security Manager
displays an error message.
• If FIPS is enabled on the operating system, you cannot log on to SQL Server using
SQL Server authentication. You must use Windows authentication.
3. Click Logon to open Security Manager.
32 Administrator Guide
Adding Operator Console Users
Operator Console users are SQL Server logins with permissions to access a QDB. You must configure
each QDB to recognize the users and allow them to log into the Operator Console.
How you add Operator Console users and configure QDBs depends on the SQL Server security mode
you are using:
• If you are using Windows Authentication security, use the SQL Server Management Studio to add
Windows groups or users as valid SQL Server logins on a QDB. Then use the Security Manager to
identify the new SQL Server logins as Operator Console users.
• If you are using Mixed mode security, you can create the SQL Server logins with Security Manager at
the same time you are creating the Operator Console user account. You can also add SQL Server
logins using SQL Server Management Studio and then identify these logins as Operator Console
users with the Security Manager.
Node Properties
General • Type the name of the Windows user or group or click Search to locate the
user or group in the domain.
Server Roles • Select the public option.
User Mapping • Select the QDB to grant access to the repository database.
• Select the public and AM_public database roles for the repository.
Status • Select the Grant option under Status to grant the user permission to
access the database engine.
• Select the Enabled option under Login to enable the user account.
For more information about using the SQL Server Management Studio to create SQL Server login
accounts and using Windows Authentication, see your SQL Server documentation.
5. Click OK to add the login account.
Note
Server Roles defined in SQL Server Management Studio take precedence over Operator Console
roles. Therefore, if you add SQL Server users who have System Administrator or Server
Administrator server roles, those users’ rights are not restricted by their Operator Console role and
those users will be able to perform virtually any Operator Console task. If you are assigning SQL
Server users to a Standard User, Read-Only User, or custom role, verify that the user account has not
been assigned a server role with broad permissions. For more information about server roles, see the
Microsoft SQL Server documentation.
5. Click Close when you are finished adding users and groups and setting roles.
Notes
• You cannot create a SQL Server login that uses Windows Authentication through Security Manager.
If you are using Mixed mode security and want to create SQL Server logins that use Windows
Authentication, you must create the accounts with SQL Server Management Studio.
• If you have enabled FIPs compliant security in the Control Center Console, you cannot create SQL
Server logins in Security Manager. You can create new logins using SQL Server Management Studio
or the Control Center Console.
34 Administrator Guide
To add new SQL Server logins with Security Manager:
1. Start Security Manager and log on with an AppManager administrator account.
2. From the Security menu, select User Setup.
3. Click New SQL User.
4. Specify a SQL Server username, SQL Server group, and login password for the user you want to
create, then click OK.
Field Description
SQL user name A username for the account. The maximum length you can specify for a user
name is 29 characters. If the user name is too long, it is truncated and you
cannot log into the Operator Console.
Note:
• You cannot specify login names with certain special characters. These
characters include: \ / * ? : < > | “
• You can specify a case-sensitive user name in a case-sensitive SQL
Server environment.
SQL group A valid SQL group for the user. The default SQL Server group is public,
but your organization may have additional groups.
SQL login password The SQL login password for the new SQL Server login.
The maximum length you can specify for a password is 32 characters.
If the password is too long, it is truncated and you cannot log into the
Operator Console.
Note
An Operator Console user or group can belong to only one Operator Console role.
The rights you can set for Operator Console roles include:
• Access to basic AppManager functions, such as whether users can run jobs, acknowledge and close
events, or modify the TreeView
• Permission to start AppManager console programs such as the Chart Console and the Repository
Browser
If you plan to use the predefined roles with the default functional rights and views, you can begin adding
Operator Console users and assigning those users to these predefined roles. For information about
adding new Operator Console users, see “Adding Operator Console Users” on page 33.
Most organizations, however, find it useful to modify the predefined roles or create custom roles before
adding any Operator Console users.
36 Administrator Guide
You can also copy any of the predefined roles to create a new custom role and modify that role to suit your
needs. For more information about defining roles and setting functional rights, see “Understanding
Custom Roles” on page 37 and “Modifying the Security Profile for a Role” on page 39.
Note
Server Roles defined in SQL Server Management Studio take precedence over Operator Console roles.
Therefore, if you add SQL Server users who have System Administrator or Server Administrator server
roles, those users’ rights are not restricted by their Operator Console role.
Tip
If you need to create a role that is similar to an existing role, copy the existing role, and then change its
properties. See “Copying an Existing Role to Create a New Role” on page 38 for more information.
Renaming a Role
Operator Console roles, both predefined and custom, can be renamed. However, the Administrator role
cannot be renamed.
To rename a predefined or custom Operator Console role:
1. Start Security Manager. For more information, see “Starting Security Manager” on page 31.
2. Expand the list of AppManager Roles.
3. Select the role you want to rename.
4. On the Security menu, click Rename Role.
5. Type a New name for the role, then click OK. The renamed role is added to the list of AppManager
Roles in the Security pane.
38 Administrator Guide
Deleting a Role
Operator Console roles, both predefined and custom, can be deleted. However, the Administrator role
cannot be deleted.
To delete any predefined or custom AppManager role:
1. Start Security Manager. For more information, see “Starting Security Manager” on page 31.
2. Expand the list of AppManager Roles.
3. Click the role you want to delete.
4. On the Security menu, click Delete Role, then click Yes.
Tab Tasks
Functional Rights Select the specific components that users assigned this role can access, and the
specific activities the user can perform using each component. For more
information, see “Defining Functional Rights for a Role” on page 42.
Views Select the specific AppManager views and custom views that users assigned this
role can access. For more information, see “Restricting Access to AppManager
Views” on page 42.
Exceptions Select the rights that users assigned this role are not allowed to exercise on
specific computers. For more information, see “Setting Computer-Based
Exceptions for a Role” on page 43.
Users See a list of the AppManager users currently assigned this role. You cannot modify
the list of users and logins from this tab. You must assign users to a role when you
add them as AppManager users.
For information about changing a user’s role, see “Changing User Roles” on
page 39.
Knowledge Scripts Select the specific Knowledge Script categories that users assigned this role can
access. For more information, see “Restricting Access to Knowledge Scripts by
Category” on page 43.
When you configure the security profile, users who do not have the functional right to perform an
operation cannot access the related menu commands or toolbar buttons. For example, if a user is not
permitted to modify Operator Console preferences, the File > Preferences command and Preferences
toolbar button are both inactive and a X icon appears next to the command.
40 Administrator Guide
Functional Rights for the Operator Console
You can set the following rights to control what different users can do in the Operator Console and the
Operator Web Console.
Tip
NetIQ Corporation recommends that you assign most users to a role with minimal functional
rights and that you strictly control which users can:
• Start and stop jobs
• Acknowledge, close, and delete events
• Modify job properties
• Create and delete custom views
• Perform other important activities
8. Click Apply when you finish modifying rights for the role.
42 Administrator Guide
4. Click Role has access to only selected views to activate the list of the currently discovered views and
custom views.
5. Select the views that users in this role can access. Clear any view you do not want users to access. If
you want to restrict the access to some computers based on a view, be sure to clear the Master view
check box.
6. If you want to use the inherited functional rights for all views for this role, click Apply. You do not
need to perform any additional steps.
7. If you want to set view-specific functional rights, select the view for which you want to set view-based
functional rights, then click the Functional Rights browse [...] button to define the specific activities
a user can perform in the selected view.
8. Click Override functional rights for this view to activate the list of functional rights available.
9. Expand any item to see the list of rights you can set.
10. Select the functional rights you want users in this role to have when using the selected view. For
information about functional rights for Operator Console views, see “Functional Rights for the
Operator Console” on page 41.
11. Click OK when you are finished modifying the functional rights for the view.
12. When you have finished modifying the views for the role, click Apply.
Note
Once you have added a computer to the list of exceptions for a role, you cannot delete the computer
from the list. However, you can clear the exceptions you have set to remove any restrictions for that
computer.
6. Click Apply when you are finished modifying exceptions for computers.
44 Administrator Guide
3. Expand the AppManager Users list.
4. Select the username to disable.
5. Check Account disabled to disable the user account.
To re-enable a user account you have previously disabled, select the username and clear Account
disabled.
Note
Members of the Control Center console Administrator group are granted the sysadmin server role on the
SQL server where you installed the Control Center repository database. If the primary QDB is also
installed on the same SQL server, members of the Administrator group will also have the sysadmin server
role on the QDB.
46 Administrator Guide
7. Click Find Now.
8. Select the users you want to add to Control Center. You can select multiple users.
9. Click OK.
10. Select the QDBs where you want to register the user. This permits the user to manage the registered
repositories.
11. Click OK.
The Manage Security dialog box displays the user 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 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.
Field Action
User Name Specify the login name of the SQL user account you want to add. This can be
a new SQL login name or the name of an existing SQL login.
Note:
• You cannot specify login names with certain special characters. These
characters include: \ / * ? : < > | “
• You can specify a case-sensitive user name in a case-sensitive SQL
Server environment.
Note
If you have enabled FIPs compliant security in the Control Center Console you cannot create SQL
Server logins using Security Manager.
48 Administrator Guide
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 who 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.
Notes
• You need to log in as the Administrator user of the trusted domain to import user groups from the
trusted domain.
• You can import user groups from trusted domains within the same forest. However, ensure that the
user groups are either Global groups or Universal groups.
Ensure that all the members of the Windows user group you import into Control Center have access to
SQL Server.
To import Windows user groups:
1. On the Global Tasks tab of the Ribbon, click Manage Security.
2. In the Manage Security dialog box, click User Groups.
3. Click Import.
4. In the Import User Groups dialog box, click Import.
5. In the Select Groups dialog box, click Locations.
To change Do this
The name of the user group Specify a new name.
The description of the user group Specify a new description.
The users who belong to the user group Click Add to add a user.
To remove a user, select the user and click Remove.
5. Click OK.
50 Administrator Guide
To remove a user group:
1. On the Global Tasks tab of the Ribbon, click Manage Security.
2. In the Manage Security dialog box, click User Groups.
3. Select the user group you want to remove, and then Click Delete.
To change Do this
The name of the user group Specify a new name.
The description of the user group Specify a new description.
The users who belong to the user group Click Add to add a user.
To remove a user, select the user and click Remove.
5. Click OK.
52 Administrator Guide
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. The
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:
For more information, see “Setting Global Permissions” on page 55 and “Default User Groups and
Permission Sets” on page 59.
Field Action
Name Specify a name for the permission set.
Note: You can specify permission set names with blank spaces and special
characters.
Description Specify a short description for the permission set.
Operational and • Click the check boxes to grant permissions.
Knowledge Script • Double-click the check boxes to deny permissions.
permissions
• Do not click the check box if you do not want to grant or deny a permissions.
5. Click OK.
54 Administrator Guide
Copying a Permission Set
You can create new permission sets based on a copy of an existing permission set. You need to first copy
the permission set and then modify the permissions.
To copy an existing permission set:
1. On the Global Tasks tab of the Ribbon, click Manage Security.
2. In the Manage Security dialog box, click Permission Sets.
3. Select the permission set you want to copy, and then click Make Copy.
4. Specify the name and an optional description of the new permission set.
5. Modify the operational and Knowledge Script permissions as needed to define the new permission
set.
6. Click OK.
56 Administrator Guide
Permissions Functional Group Available Rights
Event • Access event views
• Acknowledge and close events
• Create and modify event views
• Delete events views
• Delete events
• Modify event comments
Job • Access job views
• Add child jobs
• Close jobs
• Create and modify job views
• Create jobs
• Delete job views
• Delete jobs
• Modify job properties
• Start jobs
• Stop jobs
Knowledge Script • Access Knowledge Script views
• Check Knowledge Scripts and Knowledge Script
Groups into repositories
• Check Knowledge Scripts and Knowledge Script
Groups out of repositories
• Copy Knowledge Scripts and Knowledge Script
Groups
• Create and modify Knowledge Script views
• Create Knowledge Script groups
• Delete Knowledge Scripts views
• Delete Knowledge Scripts and Knowledge Script
groups
• Modify Knowledge Script and Knowledge Script
group properties
• Propagate Knowledge Script properties to jobs and
Knowledge Script Group members
Management Group and • Access management groups
Folder • Change management group and folder general
properties
• Change management group members
• Change management group policies
• Change management group security permissions
• Create and modify management groups and
folders
• Move management groups and folders
Monitoring Policy • Close monitoring policy jobs
• Create monitoring policies
• Delete monitoring policies
• start monitoring policy jobs
• Stop monitoring policy jobs
• Update monitoring policy jobs
58 Administrator Guide
You can only assign one permission set 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.
If you have multiple levels of management groups, one inside the other, this hierarchy does not affect the
permissions of the management groups. Parent security permissions are not inherited by any child
management groups. Management group security is defined by the user group/permission set pairs
assigned to each individual management group.
To grant or remove access to a management group:
1. Select a management group in the Enterprise Layout pane.
2. In the Tasks pane, click Management Group Properties > Security.
3. If you want to grant access:
a. Click Add.
b. In the Assign Permissions dialog box, select a user group from the User Group list.
c. 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.
d. Click OK.
4. 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.
60 Administrator Guide
Permissions Functional Group Available Rights
Job • Add child jobs
• Close jobs
• Create jobs
• Delete jobs
• Modify job properties
• Start jobs
• Stop jobs
Knowledge Script • Check Knowledge Scripts and Knowledge Script
Groups into repositories
• Check Knowledge Scripts and Knowledge Script
Groups out of repositories
• Copy Knowledge Scripts and Knowledge Script
Groups
• Create Knowledge Script groups
• Delete Knowledge Scripts and Knowledge Script
groups
• Modify Knowledge Script and Knowledge Script
group properties
• Propagate Knowledge Script properties to jobs and
Knowledge Script Group members
Management Group and • Access management groups.
Folder • Change management group and folder general
properties
• Change management group members
• Change management group policies
• Change management group security permissions
• Create and modify management groups and
folders
• Move management groups and folders
Monitoring Policy • Close monitoring policy jobs
• Create monitoring policies
• Delete monitoring policies
• start monitoring policy jobs
• Stop monitoring policy jobs
• Update monitoring policy jobs
Server • Delete servers
• Put servers into and remove servers from
maintenance mode
62 Administrator Guide
Permissions Functional Group Available Rights
Knowledge Script • Check Knowledge Scripts and Knowledge Script
Groups into repositories
• Check Knowledge Scripts and Knowledge Script
Groups out of repositories
• Copy Knowledge Scripts and Knowledge Script
Groups
• Create Knowledge Script groups
• Delete Knowledge Scripts and Knowledge Script
groups
• Modify Knowledge Script and Knowledge Script
group properties
• Propagate Knowledge Script properties to jobs and
Knowledge Script Group members
Management Group and • Access management groups
Folder • Change management group and folder general
properties
• Change management group members
• Change management group policies
• Change management group security permissions
• Create and modify management groups and
folders
• Move management groups and folders
Monitoring Policy • Close monitoring policy jobs
• Create monitoring policies
• Delete monitoring policies
• start monitoring policy jobs
• Stop monitoring policy jobs
• Update monitoring policy jobs
Server • Delete servers
• Put servers into and remove servers from
maintenance mode
64 Administrator Guide
Permissions Functional Group Available Rights
Monitoring Policy • Close monitoring policy jobs
• Create monitoring policies
• Delete monitoring policies
• start monitoring policy jobs
• Stop monitoring policy jobs
• Update monitoring policy jobs
Server • Put servers into and remove servers from
maintenance mode
66 Administrator Guide
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.
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.
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.
70 Administrator Guide
Knowledge Script Description
NT_LogicalDiskBusy Monitors logical disk activity and raises an event if a monitored value exceeds
the threshold
NT_PhysicalDiskBusy Monitors physical disk activity and raises an event if a monitored value exceeds
the threshold
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
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. For information about removing data from the QDB, see “Removing Archived Data and Events”
on page 121.
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.
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.
• 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.
72 Administrator Guide
Establishing a Manageable Level of Event Activity
If you are receiving too many events, you may 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
may 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 90.
• 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.
74 Administrator Guide
Knowledge Script Description
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 Administrator Guide for AppManager.
76 Administrator Guide
Managing Systems in a Dynamic View
A dynamic view allows you to discover and monitor servers that are organized into a logical view. Unlike
snapshot views and the Master view, a dynamic view uses rules to automatically display and organize
systems and applications.
Note
If your business needs require a rule-based approach to managing your systems and applications, NetIQ
recommends that instead of a dynamic view, you implement a rule-based management group in the
Control Center console. In the Control Center console, you can easily configure rules that have more
power and flexibility to select the resources you want. See the Control Center console online help for
more information.
A dynamic view provides the flexibility to select conforming systems and applications as well as logically
group systems using custom properties. Dynamic views work well when you have less information about
the system that is being managed and you need to rely on the view rules to select the correct system, or
you do not want to give access to the Master view.
Dynamic views are particularly useful when you want to:
• Organize a subset of servers into a view that can be managed by your operations staff. For example, if
you configure a dynamic view 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
dynamic view to automatically select similarly configured and loaded systems, and automatically
monitor those systems by policy.
• Implement view-based reporting. For example, you can use a dynamic view to select similarly
configured systems and run a report on the servers in that dynamic view.
If you are planning to implement a dynamic view, keep the following in mind:
• You must use the Control Center console to configure custom property information on a managed
computer. From the Operator Console, you can only view custom property information.
• You cannot delete a server from a dynamic view. When configuring a dynamic view, it is a good idea
to select a custom property value so that, if necessary, you can change the custom property value to
remove the server from the dynamic view.
• You cannot create nested groups in a dynamic view. This means that if you want to monitor by policy,
you will need to organize servers into separate groups rather than use the “layered” approach that is
available in snapshot views and the Master view.
78 Administrator Guide
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.
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.
80 Administrator Guide
There are two ways to suspend AppManager monitoring:
• Machine maintenance: From the Operator Console and Control Center console, you can suspend
all jobs running on a managed Windows, UNIX, or Linux client computer. The maintenance mode
status is reflected in the TreeView pane of the Operator Console and in the View pane of the
Control Center console immediately, but it can take 10 minutes for the AppManager agent to block
jobs and send its status to the repository.
When reporting on service availability, machine maintenance periods are reported as down time.
• Scheduled maintenance: The AMAdmin_SchedMaint Knowledge Script suspends monitoring for a
particular Knowledge Script category or all monitoring on a Windows computer for a specified
period. On a UNIX computer, use the AMAdminUNIX_SchedMaint Knowledge Script. Scheduled
maintenance is initiated on the AppManager agent at the scheduled time, but it can take up to 10
minutes for the TreeView pane of the Operator Console or the View pane of the Control Center
console to display the scheduled maintenance status.
When reporting on service availability, scheduled maintenance periods are not reported as down
time.
You cannot use ad hoc maintenance to turn off scheduled maintenance. Therefore, it is good practice to
avoid using both at the same time.
82 Administrator Guide
Chapter 5
Managing Events
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.
84 Administrator Guide
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.
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.
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.
86 Administrator Guide
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 Archived Data and Events” on page 121.
4. Click OK in the Preference - Event Options dialog box, then click OK in the Preferences dialog box.
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.
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.
88 Administrator Guide
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.
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.
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.
90 Administrator Guide
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.
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.
92 Administrator Guide
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
• Using SMTP Mail Messages
• Using MAPI or Lotus Notes Mail Messages
• Using Log Files or Other Sources to Send Messages
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.
94 Administrator Guide
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.
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.
96 Administrator Guide
Chapter 6
Managing Data
Before you deploy AppManager across your entire enterprise, you need to develop and refine your data
handling policies. In determining how you want to manage AppManager data in your organization, you
need to consider your group’s internal procedures, department structure, and management goals. For
example, if your manager has asked 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 following topics address the impact of data collection and the options you should consider when
planning to run Knowledge Scripts that collect data:
• “Deciding When to Collect Data” on page 97
• “Understanding Data Collection for Charts, Graphs, and Reports” on page 99
• “Setting Preferences for Real-time Charts and Graphs” on page 99
• “Understanding Data Archiving and Reporting” on page 100
• “Using Advanced Data-handling Properties for Jobs” on page 102
98 Administrator Guide
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 the information is
stored 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 are visually updated as new data
points are received.
• 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.
Because you cannot keep information available indefinitely, AppManager provides repository preferences
to help you manage how long to keep data for real-time charts and graphs and options for archiving and
summarizing data for reports.
Note
This option is not available in the Control Center console, though how you set this option in the
Operator Console also determines the amount of data available to the Control Center console for real-
time analysis and diagnosis.
Note
This preference only affects new jobs. You must update existing jobs individually to change the
number of days that they keep data points in the data stream.
4. Specify the time, in hours, to remove old or “expired” data points from the repository in Time
interval to purge old points in repository.
AppManager runs the NetIQ PurgeData QDB scheduled task at the interval you specify and deletes
any data points older than the value you specified in Default period to keep points in data table. For
more information about the impact of these settings on repository maintenance, see “Managing a
QDB” on page 105.
5. Click OK in the Preference - Data Options dialog box.
6. Click OK in the Preferences dialog box.
Note
Move points after N months requires you to keep data points in the data archive tables for at least
one month. A minimum of one month’s worth of data must be stored for every Knowledge Script
collecting data.
Notes
• Although summarizing and moving archive data helps decrease the database requirements while
preserving historical information, you should periodically back up and purge the data from the QDB.
For more information about backing up and removing data, see the chapter ““Managing a QDB” on
page 105.”
• These data aggregation options are not available in the Control Center console, though how you set
them in the Operator Console also affects the data available for reporting in the Control Center
console.
Note
Changing the default behavior for data collection in the Operator Console does not affect default settings
for the Control Center console.
Select To
Collect data details with data point This option only applies to data collection for AppManager graphs and
charts.
Deselect this option to only collect the value of the monitored resource;
detailed information, such as server name and collection time, is not
collected. This option is selected by default.
Do not archive data detail This option only applies to data collection for AppManager reports that
display detail data, such as ReportAM_DetailData.
Select this option to only collect the value of the monitored resource;
detailed information, such as server name and collection time, is not
collected. This option is selected by default.
Note
Changing the default behavior for data collection in the Operator Console does not affect default settings
for the Control Center 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 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. Click Start collecting data when an event is generated in the Data options group.
4. Click Stop collecting data when event condition no longer exists if you want jobs to stop collecting
data when the event condition no longer exists.
5. Click OK in the Preference - Knowledge Script Advanced Options dialog box.
6. Click OK in the Preferences dialog box.
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. The following topics are covered:
• “Understanding the AppManager Repository” on page 105
• “Managing Data Streams” on page 110
• “Managing Event Information” on page 111
• “Managing Audit Trails” on page 112
• “Checking SQL Server Configuration” on page 112
• “Expanding the Size of a Repository” on page 115
• “Checking the Integrity of the Repository” on page 116
• “Backing Up the QDB” on page 117
• “Removing Archived Data and Events” on page 121
• “Moving the QDB” on page 123
• “Using the Repository Browser” on page 123
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.
Note
Because these SQL Server jobs handle internal data management, you should not change the default
schedule or attempt to modify the SQL Server job steps unless instructed to do so by a NetIQ Technical
Support representative or implementation consultant, or unless you fully understand the impact of
making a change.
Job Description
NetIQ AMDC daily QDB Removes data points from jobs that collect diagnostic data when that data is
more than 1 day old. The job runs every day at 1:30 AM.
NetIQ Archive Event QDB Moves events from the Event tables to the ArchiveEvent tables if you have
set the repository preference to archive events. The job runs every 2 hours.
NetIQ CC Daily Task Removes items marked for deletion from the Event, Job, and Computer
tables. The job runs daily at midnight.
NetIQ CC Half-Hourly Maintains the Queue table, which is used by the Command Queue Service for
Task tasks submitted by the Control Center console. The job runs every 30 minutes.
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 and DataHeader tables when jobs are deleted from the
Operator Console, no matter how long the information has remained in the tables. For more
information about deleting data, see the chapter “Managing Data” on page 97.
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.
Note
You should check your Microsoft SQL Server documentation and your current server configuration to
determine which options, if any, should be changed.
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.
Note
The AMAdmin_DBHealth Knowledge Script also checks the percentage of data space and log space used
by the Update Definition in User Variables. repository, the time it takes an Update Definition in User
Variables. query to execute, and the status of Update Definition in User Variables. scheduled SQL Server
jobs. For more information about using this Knowledge Script, select 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.
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 “AM Health Knowledge Scripts” on page 237.
Notes
• The master database holds all of the device configuration information, SQL Server login
information, and extended stored procedures. Therefore, you should periodically back up the master
database even if you are not backing up the AppManager repository—especially if you add data
devices, databases, or users, or change any configuration options.
• If you want to move the 32-bit QDB to a 64-bit SQL Server, you need to update you 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 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 the 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.
Note
You must install the SQL module to take a back up with the SQL_RunSQL Knowledge Script.
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, you should perform a complete or incremental backup at least once a week.
Notes
• If you set the service to automatically restart when it stops, you must disable the service.
• If you want to move the QDB to a different computer, you should start all services only after you
complete all the steps for moving the QDB.
2. Close any AppManager console applications, such as the Operator Console or Control Center
console, that are connected to the QDB.
3. If the QDB is a data source for Analysis Center, stop Analysis Center ETL jobs.
4. Verify that there are no open connections to the QDB by running the following SQL query:
USE master
GO
Exec sp_who2
GO
5. If no programs are listed in the query results, you are now ready to back up the QDB.
Field Description
Database Select the QDB that you want to back up from the list.
Recovery Model Displays the type of recovery model that the database
follows. This field is disabled by default. For more
information about recovery models, see the SQL Server
documentation.
Backup Type Select Full as the backup type to create a full backup
copy of the repository.
Backup Component Select Database as the backup component.
Backup set will expire Select After and retain the default setting of zero such
that your backup does not expire.
If you select the On option, you need to specify a date on
which the backup expires.
Destination Select Disk to copy the backup to a particular folder.
Select a backup destination, if the destination you want to
use is listed.
To select a destination or backup device that is not listed,
click Add.
Note
If you restore the QDB to a different computer, and it is managed by Control Center, you need to
update the QDB connection information in the Control Center repository. For more information,
see the AppManager Upgrade and Migration Guide.
Note
This stored procedure can impose a heavy load on your SQL Server. Run it only during off-peak hours
and when the NetIQ PurgeData QDB job is not running. If you have accumulated a large amount of data
(for example, two million rows or more) before running this stored procedure for the first time, gradually
decrease the number of days so that you incrementally delete the oldest data first. For example, if you
have 120 days’ worth of data, run DeleteOldArchiveData 115, then DeleteOldArchiveData 110, then
DeleteOldArchiveData 105, until the desired amount of data has been deleted.
Note
Removing data and events can impose a heavy load on your SQL Server. Only perform these operations
during off-peak hours when the NetIQ PurgeData QDB job is not running.
Notes
• 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, refer to the Upgrade and Migration Guide.
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. The following topics
are covered:
• “Understanding the Control Center Repository” on page 125
• “Backing Up the Control Center Repository” on page 126
• “Moving the Control Center Repository” on page 129
• “Moving the Deployment Service to a New Computer” on page 129
• “Moving the Deployment Web Service to a New Computer” on page 130
• “Moving the Command Queue Service to a New Computer” on page 131
• “Changing the Log Path for the Command Queue Service” on page 131
• “Changing the Log Path for the Deployment Service” on page 132
Note
If you want to move the Control Center repository to a different computer, you should start all
services only after you complete all the steps for moving the Control Center repository.
Field Description
Database Select the Control Center repository from the list.
Recovery Model Displays the type of recovery model that the database
follows. This field is disabled by default. For more
information about recovery models, see the SQL Server
documentation.
Backup Type Select Full as the backup type to create a full backup
copy of the repository.
Backup Component Select Database as the backup component.
Backup Set Specify a name and description for your database backup
set.
Backup set will expire Select After option and retain the default setting of zero
such that your backup does not expire.
If you select the On option, you need to specify a date on
which the backup expires.
Destination Select Disk to copy the backup to a particular folder.
Select a backup destination, if the destination you want to
use is listed.
To select a destination or backup device that is not listed,
click Add.
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 the
new remote Deployment Web Service is installed.
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 the new Deployment Web Service is
installed.
4. Close and save your changes to the DeploymentService.exe.config file.
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 3 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.
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\"/>
5. Close and save your changes to the NQCQS.exe.config file.
This chapter describes several ways you can customize and configure the operation of the AppManager
management server.
• “Rules for Management Servers” on page 135
• “Changing the Polling Interval for Agent Computers” on page 137
• “Changing the Listening Ports” on page 138
• “Changing the Level of Detail in Trace Logging” on page 139
• “Moving the Management Server to a New Computer” on page 140
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.
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.
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.
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.
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.
• 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.
Each line in the log file includes a timestamp in UTC format, a message type indicator, and the message
body. For example:
987220342: info 1: computer name = MERCURY
987220342: info 1: host name = MERCURY
987220342: info 1: ip = 10.5.102.152
987220342: info 2: SocketServerThread, 2920
987220342: info 2: UnixAgentsThread, 3052
987220342: info 2: QUnixaConfigureThread, 2620
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.
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. The following
topics are covered:
• “Understanding the AppManager Agent” on page 143
• “Understanding Agent Autonomy” on page 144
• “Using a Windows User Account for Agent Services” on page 146
• “Restarting Agent Services” on page 147
• “Agent Self Monitoring” on page 148
• “Configuring Agents to Use a Hostname or IP Address” on page 149
• “Configuring the Size of a Local Repository” on page 149
• “Adjusting the Flow of Network Traffic” on page 150
• “Scheduling the Transfer of Events and Data” on page 150
• “Configuring Designated Management Servers” on page 151
• “Manually Controlling Network Communication” on page 153
• “Controlling Access to an Agent’s Local Repository” on page 153
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.
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.
3. In the Services Control Panel or from a command prompt, restart the AppManager services.
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.
Note
Before performing a cold startup, consider running an AppManager job report to collect details about the
jobs you are running.
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.
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.
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.
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.
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.
AppManager console command-line parameters enable you to specify logon information or customize the
layout of the Operator Console when you start console programs.
This chapter discusses how to use these command-line parameters and Operator Console filtering to
optimize performance. The following topics are covered:
• “Using Command-line Parameters” on page 155
• “Specifying Logon Information” on page 155
• “Customizing the Operator Console Layout” on page 156
• “Getting Help for Command-line Parameters” on page 159
Note
There are no command-line parameters for login information available for the Control Center console.
Parameter Description
/S Server The name of the SQL Server that manages the AppManager repository. When
specifying a computer name, you can enter the Windows computer name or the
IP address. For example, to specify a named instance on SQL Server 2000, you can
enter 10.1.10.443\INST1.
/R Repository The name of the AppManager repository you want to work with. For example, the
default database name for AppManager is QDB.
/TRUST Validate the user based on the Windows user information. The AppManager console
computer needs to be part of a Windows domain or workgroup. The user needs to be
validated as a Windows user before access is granted.
Optional parameter. If you do not specify this parameter, SQL Server uses the
standard SQL Server security validation to validate a specified login name and
password.
/N Name The username of the SQL Server login account used to access the AppManager
repository. This parameter is ignored when the /TRUST parameter is specified.
Note The SQL Server login account must have permission to access AppManager.
For more information about granting access to AppManager to SQL Server login
accounts, see the Installation Guide for AppManager.
/P Password The password for the SQL Server login account. This parameter is ignored when the /
TRUST parameter is specified.
Note
There are no command-line parameters for customizing the layout of the console available for the Control
Center console.
Parameter Description
/SHOWMASTERVIEW Shows the Master view and splits the TreeView pane. Any other available views are
hidden on startup.
To show other available views, in the Operator Console, click View > View Manager,
and select the available views.
You can hide the right panel of the split TreeView pane by right-clicking the right panel
and deselecting Show Details Panel (the TreeView pane remains split).
/SHOWEVENTSONLY Shows event information in the List pane (and dims all other tabs and panes, including
the TreeView pane).
This parameter:
• Optimizes the Operator Console startup by viewing events only. If you minimize
the Operator Console, the taskbar button will not flash when events are open.
• Dims the layout options in the Console tab of the Operator Console Preferences
dialog box. To change the console layout preferences, restart the Operator
Console without using this parameter.
/SHOWALL Shows all tabs in the List pane—previously dimmed panes can be shown.
This parameter overrides any other parameters and selects all of the console layout
options in the Console tab of the Operator Console’s Preferences dialog box.
Note To show a hidden pane, in the Operator Console, click View > TreeView Pane,
List Pane, Knowledge Script Pane, and Graph Pane.
/HIDEEVENTS Dims the Events tab in the List pane and event-related menu commands (for example,
List > Acknowledge Event).
This parameter:
• Always shows the TreeView pane
• Deselects the Work with events check box in the Console tab of the Operator
Console’s Preferences dialog box
To work with events:
• Start the Operator Console using the /SHOWALL parameter or another /HIDEname
parameter
• Select the Work with events check box in the Console tab of the Operator
Console’s Preferences dialog box
/HIDEJOBS Dims the Jobs tab in the List pane, job-related menu commands (for example, List >
Close Job), and the Knowledge Script pane.
This parameter:
• Always shows the TreeView pane
• Deselects the Work with jobs check box in the Console tab of the Operator
Console’s Preferences dialog box
To work with jobs:
• Start the Operator Console using the /SHOWALL parameter or another /HIDEname
parameter
• Select the Work with jobs check box in the Console tab of the Operator
Console’s Preferences dialog box
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. The following topics are
covered:
• “Understanding Command-line Scripting” on page 161
• “About the Sample Command-line Scripts” on page 162
• “Running AppManager Command-line Scripts” on page 163
• “Creating a Default Logon Profile” on page 163
• “Creating Jobs” on page 164
• “Starting, Stopping, Closing, and Deleting Jobs” on page 165
• “Acknowledging, Closing, and Deleting Events” on page 166
• “Exporting Data Streams” on page 166
• “Scheduling Scripts to Run” on page 167
• “Getting Help For Sample Scripts” on page 168
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.
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
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
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.
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.
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.
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
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
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.
Notes
• 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.
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.
The following topics are covered:
• “Understanding What AppManager Provides” on page 169
• “Using the Troubleshooter” on page 170
• “Using the Command-line Program NetIQctrl” on page 175
• “Using the NetIQ Diagnostics Utility” on page 201
• “Enabling Tracing and Viewing Log Files” on page 202
• “Using the Log Analysis Tool” on page 204
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.
4. 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.
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 “Clearing the Diagnostic Report’s Information Pane” on page 174.
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.
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.
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.
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.
Note
If the file already exists, the information is appended to the end of the file.
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.
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.
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
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.
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.
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
#-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.
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
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
[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
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.
• 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
----------------------------------------------
• 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.
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
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
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.
#-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
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
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 217. 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.
Note
For information about configuring logging for the UNIX agent, see the AppManager for UNIX Servers
Management Guide.
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.
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 in this
appendix:
• “Key File Utility for Windows Agents” on page 207
• “Key File Utility for UNIX Agents” on page 210
• “MAPI Mail Utility” on page 213
• “Synchronization Utilities” on page 215
• “Time Conversion Utility” on page 215
Note
Type NQKeyGenWindows without specifying any options to see usage information.
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.
-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.
-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
-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.
Note
If you type NQKeyGenUnix without specifying any options, the program displays usage information.
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.
-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.
-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.
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;pat_conner@bigcorp.com”
-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.
Option Description
-tRecipients Specifies the e-mail address of each individual you want to receive the report, using
the format:
recipient@domain
For example:
-tIT_Admin@ajuba.com
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.
-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.
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.
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.
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.
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.
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.
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.
Diagnostic Console Key values for the Diagnostic Console components installed on the computer
you are viewing.
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.
AgtShared folder
The SOFTWARE\NetIQ\AppManager\4.0\AgtShared folder stores 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
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
NetIQccm Folder
The SOFTWARE\NetIQ\AppManager\4.0\NetIQccm folder stores 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:
• Admin
• Config
• Tracing
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.
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.
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).
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.
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
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
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.
Knowledge Script Failure Contains internal Knowledge Script abort and exception codes. This is not the
Events 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.
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.
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.
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.
NetIQms Folder
The SOFTWARE\NetIQ\AppManager\4.0\NetIQms folder stores 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:
• Admin
• Config
• RP
• Tracing
Note
The Integration folder contains keys used by AppManager connectors.
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.
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.
DisableAdminEvt Sets the flag indicating whether an event should be raised if an agent
needs to be restarted.
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.
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 1 thread.
RP
The NetIQms\RP folder contains keys that control connections to the repository.
Key Description
RP Connection Refresh Sets the interval between the management server’s attempts to reconnect to
Wait 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.
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 1
Threshold 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).
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).
Note
This folder is only available in upgraded environments. New AppManager 8.0 installations do not have
this folder.
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.
Repository Browser
The SOFTWARE\NetIQ\AppManager\4.0\Repository Browser folder contains keys that define the
default and custom queries that are available in the Repository Browser.
Security Manager
The SOFTWARE\NetIQ\AppManager\4.0\Security Manager folder contains 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.
Note
This folder is only available in upgraded environments. New AppManager 8.0 installations do not have
this folder.
Other Folders
The SOFTWARE\NetIQ\Common\AMReports folder contains keys used in configuring and viewing
AppManager reports. The SOFTWARE\NetIQ\Generic folder contains keys that define the maximum size
for tracing files and the directory to use for tracing output.
The AppManager Self Monitoring module, also known as AM Health, provides Knowledge Scripts for
monitoring the health and availability of AppManager components. From the Knowledge Script view of
Control Center, you can access more information about any NetIQ-supported Knowledge Script by
selecting it and clicking Help. In the Operator Console, click any Knowledge Script in the Knowledge
Script pane and press F1.
Note
If you want to use the AMHealth_CCComponentsHealth Knowledge Script to monitor a Command
Queue Service (CQS) that is not in the same domain as the Control Center repository (NQCCDB),
set up the user account using the above process for the CQS instead of a Management Server.
Note
If the NQCCDB does not have an AppManager agent installed on it, Discovery_AMHealth discovers the
NQCCDB components on the server running the Command Queue Service. As a result, the service and
database monitoring parameters for this script run remotely. In this situation, you must have sufficient
privileges on the service account for the NetIQMC service on the server running the Command Queue
Service so that the service account can remotely access the SQL Server service on the NQCCDB to
obtain its status. If the account does not have proper privileges, the script will be unable to access the
service status and will report that the SQL Server service is down even when it is not. If you do not have
sufficient access for the service account for the NetIQMC service, deselect the Raise an event if SQL Server
services are down and Restart SQL Server services that stop unexpectedly parameters in this script to avoid
raising unnecessary events.
If you want to use CCComponentsHealth to monitor a CQS that is not in the same domain or trusted
domain as the NQCCDB, see “Monitoring the Health of a Management Server in an Untrusted
Domain” on page 238.
This script raises events for the following situations:
• SQL Server services are down or have been restarted
• SQL Server agent jobs are disabled, missing, or have failed
• The CQS is down or is not connected to the Control Center repository
• Control Center Cache Manager errors occur
• SQL Server queries against the NQCCDB take too long to process
• Deployment services are down
• Database or log space is low, and there is insufficient disk space for further growth
If you do not have an agent installed on the NQCCDB server, the repository component gets discovered
on the CQS. If you try to remotely monitor the NQCCDB from the CQS using the
CCComponentsHealth script, the script will not be able to obtain the disk information remotely.
As a result, if the repository component is monitored remotely from the CQS by the
CCComponentsHealth script, the following NQCCDB component monitoring parameters under the
SQL Server File Size and Growth Settings Monitoring Event Notification Knowledge Script section will not be
available:
• Raise an event if SQL Server maximum file size exceeds available disk space?
• Raise an event if insufficient space available for further file growth?
Default Schedule
The default interval for this script is every 30 minutes.
HeartbeatUNIX
Use this Knowledge Script to test the heartbeat of the AppManager agent computer running UNIX. A
heartbeat is a periodic signal generated by an AppManager agent computer to indicate that it is still
running.
You can set this script to raise an event for the following conditions:
• Heartbeat fails
• An agent is healthy, such as when the heartbeat returns after failing
• The agent heartbeat fails a user-specified number of times
Note
If you use this Knowledge Script with the AppManager Operator Console, you can access the Actions and
Advanced tab, but the options on those two tabs will not function.
Resource Objects
UNIX servers
Default Schedule
The default interval for this script is every five minutes.
Note
If you use this Knowledge Script with the AppManager Operator Console, you can access the Actions and
Advanced tab, but the options on those two tabs will not function.
Resource Objects
Windows servers
Default Schedule
The default interval for this script is every five minutes.
Note
If the QDB does not have an AppManager agent installed on it, Discovery_AMHealth discovers the QDB
components on the Management Server. As a result, the service and database monitoring parameters for
this script run remotely. In this situation, you must have sufficient privileges on the service account for
the NetIQMC service on the Management Server so that the service account can remotely access the SQL
Server service on the QDB to obtain its status. If the account does not have proper privileges, the script
will be unable to access the service status and will report that the SQL Server service is down even when it
is not. If you do not have sufficient access for the service account for the NetIQMC service, deselect the
Raise an event if SQL Server services are down and Restart SQL Server services that stop unexpectedly parameters
in this script to avoid raising unnecessary events.
If you want to use QDBComponentsHealth to monitor a Management Server that is not in the same
domain or trusted domain as the QDB, see “Monitoring the Health of a Management Server in an
Untrusted Domain” on page 238.
You can set this script to raise an event for the following conditions:
• SQL Server services are down or have been restarted
• SQL Server agent jobs are disabled, missing, or have failed
• Database or log space is low
• The Management Server isn't connected to the QDB database
• The Management Server service is down
• SQL Server queries against the QDB are taking too long to process
• Database or log space is low, and there is insufficient disk space for further growth
When monitoring Management Server performance, QDBComponentsHealth does not use the standard
method of creating events through the Management Server, because the problem being detected might
prevent events from being generated through the Management Server. As a result, this script generates
events for these conditions directly in the QDB, and Action scripts will not operate with certain
QDBComponentsHealth parameters to generate actions when the conditions occur. Because these events
are generated directly in the QDB, event collapsing is always enabled for these events, and it cannot be
turned off.
The following QDBComponentsHealth parameters related to Management Server monitoring will not
generate actions:
• Raise an event if the Management Server service is down?
• Raise an event if the Management Server service fails to restart?
• Raise an event if the Management Server service restarts successfully?
• Raise an event if the Management Server service is not connected to the QDB?
• Raise an event if data map file usage exceeds threshold?
Resource Objects
• AppManager repository (QDB) server
• Management Server
Default Schedule
The default interval for this script is every thirty minutes.