Operations Center integrates directly with NetIQ AppManager. However, the JDBC driver does not support connections using Windows authentication.
If you are using the AppManager Operations Portal, see the NetIQ AppManager Operations Portal Getting Started Guide.
Refer to the following topics to configure the integration with NetIQ AppManager:
To integrate the NetIQ AppManager:
Create an adapter for each instance of a NetIQ object server on the network.
From the Type drop-down list, select NetIQ AppManager.
For instructions, see Section 2.1, Creating an Adapter.
Define the adapter properties.
For property descriptions, see Section A.22, NetIQ AppManager.
To configure the NetIQ AppManager adapter to use Windows authentication:
Update the DbName adapter property to databaseName;domain=domainName.
For example, where the DbName value was previously QDB, with this change it is now: QDB;domain=MOS.
Do one of the following to configure the server:
On Unix: No native libraries required, but you must provide user, password.
On Windows: Native libraries are optional. If you don't use the native library, you must provide user, password.
On Windows for MSSQL Configuration: The following requirements must be met:
Must be configured to use Windows Authentication.
The machine must be on the domain.
Users must be a member of the OS's administrator group.
For example, if you are logging in as MOS\jsmith, the user jsmith must be in the adminitrators group on the MSSQL machine on the MOS domain.
If MSSQL is setup to use an instance name, you must turn on the SQLServer Browser Service. Then add the user to the instance's security group.
To configure for Windows Single Sign-On (SSO), do the following:
If running Operations Center as a service, the service must use the same domain user account as the database.
If you are receiving an NT AUTHORITY\ANONYMOUS LOGON exception, verify that the account used by the service and the database are the same.
Leave the User and Password adapter properties blank (empty).
Copy the /OperationsCenter_install_path/classes/win32/ntlmauth32.jar or /OperationsCenter_install_path/classes/win64/ntlmauth64.jar file into the /OperationsCenter_install_path/classes/ext directory.
Restart the Operations Center server.
For instructions, see Manually Starting the Operations Center Server
and Starting the Operations Center Server in UNIX
in the Operations Center Server Installation Guide.
Alarms are handled similar to other event-based adapters in Operations Center. Unacknowledged alarms propagate the adapter’s hierarchy at all times.
Element condition in the machine’s hierarchy is affected by unacknowledged job alarms, turning the job to CRITICAL and then propagating to the machine element. Acknowledged and closed alarms do not aversely impact the condition of parent elements. If there are no alarms on a job but the job’s condition changes for another reason, state is propagated to the Monitors element but not to the machine.
When custom properties have been created for objects in NetIQ AppManager, the same properties are surfaced in the Object Custom Properties page in Operations Center properties.
To view object properties:
Right-click the NetIQ element in the Operations Center Explorer pane, then select Properties. The Properties dialog opens.
Click Object Attributes, Object Details, or Object Custom Properties to view object attributes, details or custom properties.
The pages available for a NetIQ element depend on object type and if any custom properties exist for the object in NetIQ AppManager.
While Operations Center includes the NetIQ comment feature, there is also an Operations Center-based commenting option:
To add a NetIQ comment:
Right-click a NetIQ alarm in the Operations Center Alarms view, then click Add AppManager comment to open the AppManager Comments dialog box.
Enter comments, then click Apply.
You can view previous comments in the Comments History section.
To add an Operations Center comment:
Right-click a NetIQ alarm in the Operations Center Alarms view, then click Add Comment to open the Comments dialog box.
Enter comments, then click Apply.
You can view previous comments in the Comments History section.
You can add custom fields to Operations Center alarms that are derived from AppManager events by configuring the AppManager adapter to call a custom script during adapter startup that registers an event listener with the adapter. Each time the adapter receives an event from AppManager, it invokes the event listener to read information about the event and add custom fields to the event.
You can find example implementations in NOC/database/scripts on the Operations Center server:
enrichAlarmsStart.fs assigns a service level to the event based on information from the element that is associated with the event.
enrichAlarmsSample.fs adds logic to obtain the service level from a local Data Integrator adapter and cache service level information during startup in order to improve performance when events are initially loading.
To use a sample script:
In the AppManager adapter properties, for Script.enrichAlarms, specify the name of the script, preceded by @ (for example, @enrichAlarmsStart.fs).
(Optional) For AlarmColumns, list the names for the new columns.
Restart the AppManager adapter.
When developing your own custom scripts, consider the following:
The method that adds an event listener is available on the adapter object and should be similar to the following in the script:
adapter.addAMEventListener(myListener,[Packages.Adapter.appManager.eventEnrichment.AMEventListener.Options.SUPPRESS_UPDATES]);
The event listener must implement an interface that can be registered with the AppManager adapter to intercept events as the adapter processes them. The implementation should be similar to the following in the script:
var listener = new Packages.Adapter.appManager.eventEnrichment.AMEventListener()
{
eventCreated: function(element, event)
{
},
eventUpdated: function(element, event)
{
},
discoveryStart: function()
{
},
discoveryComplete: function()
{
}
}
eventCreated() is required. If the custom fields are likely to change (for example, Status), use eventUpdated(). If you do not require eventUpdated(), use the SUPPRESS_UPDATES option when you register the interface to improve performance.
discoveryStart() and discoveryComplete() are not required, but you can use them to improve performance by caching discovery information.
Because the AppManager adapter defines the following attrName values, do not use them in custom scripts:
EventID
ParentEventID
JobID
DepJobID
RepositoryName
SeverityCode
SeverityNum
Status
FirstOccurTime
LastOccurTime
ObjID
KPName
TypeObjName
Severity
EventMsg
Occurrence
ModificationTime
UserAcknowledged
MachineName
KSGName
KSName
Category
TimeActiveBias
LastOccurConsoleTime
FirstOccurConsoleTime
HasComment
WasNullAttrs
FirstOccurTimeString
LastOccurTimeString
FCOName
Actions
If you want to use the Operations Center Script Debugger as you are developing custom scripts, ensure that you set //@debug to on in your script and then create a server side operation with the following parameters:
Menu text: Enrich Alarm
Context: Alarm
Match by: Distinguished name expression (for the expression, specify .*/netiq=.*/root=Elements
Permission: Manage
Type: Server script
Operation: @Script_Name.fs
With this operation, you can right-click an alarm for the adapter and run your script with the debugger.
For information about creating a server side operation, see the Operations Center Server Configuration Guide.
For general information about developing scripts, see the Operations Center Scripting Guide.