1.9 Discovering Avaya Communication Manager Resources

Use the Discovery_AvayaCM Knowledge Script to discover Avaya Communication Manager configuration information and resources, including Switch Processing Elements (SPE), Enterprise Survivable Servers (ESS), Local Survivable Processors (LSP), H.248 media gateways, IP stations, attendant consoles, and remote office stations. You can also choose to discover NetIQ SNMP Trap Receiver. For more information, see Working with NetIQ SNMP Trap Receiver.

Only one Windows server can act as proxy for any given Communication Manager cluster. Therefore, run this script on only one computer at a time.

AppManager uses SNMP queries to access remote Communication Manager servers and to enable functionality of NetIQ SNMP Trap Receiver. Configure the SNMP community string information in AppManager Security Manager for each Communication Manager you want to monitor. The community string information allows AppManager to access the remote Communication Manager servers. For more information, see Configuring SNMP Community Strings.

NOTE:If you discover a call manager when you are bypassing SNMP (by selecting the Discover using manual configuration? parameter), the created treeview is restricted to the object types that the configuration supports. If the Knowledge Scripts that correspond to a particular object type are not supported for the configuration, they will not appear in the treeview. Review the Knowledge Script descriptions for specific restrictions.

Set the parameters on the Values tab as needed:

Parameter	How to Set It
General Settings
Job Failure Notification
Event severity when job fails	Set the severity level, from 1 to 40, to indicate the importance of the failure of the Discovery_AvayaCM job. The default is 5.
Set up supplemental database?	Select Yes to create the Avaya CM supplemental database, including the tables and stored procedures needed to store call detail records and phone deregistration information. The default is Yes. For more information, see Understanding the Avaya CM Supplemental Database.
Event severity when database setup fails	Set the event severity level, from 1 to 40, to indicate the importance of an event in which the Avaya CM supplemental database is not created. The default is 15. It is possible that the supplemental database was not created because the Discovery job ran on a computer on which SQL Server is not installed.
Number of days to keep call detail records	Specify the number of days’ worth of CDRs to keep in the Avaya CM supplemental database. Data older than what you specify is discarded. The default is 7 days. NOTE:Run DeleteCDRRecords Knowledge Script to remove old records from the supplemental database.
Local SQL Server Instance name	Specify the name of the local SQL Server instance (on the proxy computer) in which you want to create the new Avaya CM supplemental database. Leave this parameter blank to accept the default name.
Raise event if database setup succeeds?	Select Yes to raise an event if creation of the Avaya CM supplemental database is successful. The default is unselected.
Event severity when database setup succeeds	Set the event severity level, from 1 to 40, to indicate the importance of an event in which the Avaya CM supplemental database is created successfully. The default is 25.
SNMP
Global SNMP Message timeout	Specify the number of seconds discovery should attempt an SNMP message request to an individual Communication Manager server before retrying the connection. The default is 120 seconds. The value you set here is the timeout value for all SNMP message requests for all AvayaCM Knowledge Script jobs.
Global SNMP Task timeout	Specify the number of seconds discovery should attempt an SNMP retrieve request to an individual Communication Manager server before retrying the connection. The default is 3600 seconds. The value you set here is the timeout value for all SNMP retrieve requests for all AvayaCM Knowledge Script jobs.
Global SNMP retries	Specify the number of times discovery should attempt an SNMP connection to an individual Communication Manager before attempting an SNMP connection to the next Communication Manager in the list. The default is 4 retries. The value you set here will be the number of retries for all SNMP connections for all AvayaCM Knowledge Script jobs. Hint If you experience timeouts that appear to be caused by lost messages rather than CPU usage, increase the number of retries, which affects SNMP GETNext and GETBulk requests. For example, if CPU is stable and you have already increased the timeout value, but packet loss in the network is high and timeouts are still being experienced, you can increase the number of retries.
Enable use of SNMP GETBulk requests during discovery?	By default, this parameter is enabled, allowing the Discovery_AvayaCM Knowledge Script job to use SNMP GETNext and GETBulk requests to access Communication Manager MIBs. Disable this parameter to allow the script to use only GETNEXT requests. Not all MIB tables are extensive enough to need a GETBulk request. A GETBulk request is faster, but more CPU-intensive than a GETNext request.
Number of rows to request for each GETBulk operation	Specify the number of rows from the MIB table to return in a GETBulk request. The default is 10 rows. The number of rows determines how quickly MIB data is returned. If CPU usage is too high, you can reduce the number of rows per GETBulk request or disable the Enable use of SNMP GETBulk requests during discovery? parameter.
Interval to pause between GETBulk requests	Specify the number of milliseconds to wait between GETBulk requests. The default is 100 milliseconds. The delay can help manage CPU usage and speed of SNMP requests. For example, a one-row GETBulk with a 100-millisecond delay between requests executes slower and uses less CPU than a GETNext request.
Raise event if discovery succeeds?	Select Yes to raise an event if discovery succeeds in finding Communication Manager devices. The default is unselected.
Event severity when discovery succeeds	Set the severity level, from 1 to 40, to indicate the importance of an event in which discovery succeeds in finding Communication Manager devices. The default if 25.
Raise event if discovery fails?	Select Yes to raise an event if discovery fails to find some or all of your Communication Manager devices. The default is Yes.
Event severity when discovery fails	Set the severity level, from 1 to 40, to indicate the importance of an event in which discovery fails to find some or all of your Communication Manager devices. The default is 10.
Discover Avaya Communication Manager Servers
Discovery timeout for all servers	Specify the number of minutes the script should attempt to discover all specified Communication Manager servers before stopping as unsuccessful. The maximum is 60 minutes. The default is 30 minutes.
Maximum number of concurrent discoveries	Specify the maximum number of Communication Manager servers that can be queried for discovery at one time. No matter what value you enter, discovery is still performed for the entire list of devices that you specify in the following parameters. Setting this parameter to a low value throttles the number of SNMP requests performed at one time, but may increase the overall time it takes to discover a list of devices. The default is 10 concurrent discoveries.
Comma-separated list of active Communication Manager servers	Use this parameter if you know which Communication Manager servers you want to discover. Each duplex pair of AvayaCM call managers has an active server IP address that is shared between the duplex servers. This address is known as an IP-alias (or virtual address). The active server is the only server that responds on the IP-alias. Each server in the pair also responds to the physical address of that server. When a duplex call manager pair is discovered, the virtual address must be used rather than the physical address. If Domain Name Service (DNS) entries are mapped to the addresses and a DNS name is used for discovery, the DNS name used on a duplex pair should be the one mapped to the virtual address. HINT:You should discover the Communication Manager server by the virtual address, as a server discovered by physical address loses connectivity when the duplex processor changes the active status between the physical servers. Specify at least one IP address or hostname, using a comma to separate multiple items. For example: 10.0.1.1,10.0.1.7 You can enter IP addresses or hostnames, but you must enter the same IP address or hostname for which you configured SNMP community string information. If you configured a community string for a hostname, enter the same hostname; if you configured an IP address, enter the same IP address. For more information, see Configuring SNMP Community Strings.
Comma-separated list of Communication Manager IP address pairs in a single NAT cluster	MSPs (Managed Service Providers) frequently maintain distributed customer networks in which NAT (Network Address Translation) is used to translate the IP address ranges that are monitored from a single NOC (Network Operations Center). The use of NAT prevents AppManager from recognizing the actual IP addresses of the servers in the remote cluster. If your AppManager agent is located on a server in the NOC, but the monitored devices are located in a cluster in the remote customer network, you need to provide AppManager with a list of the IP addresses of the remote monitored devices. Use this parameter to enable AppManager to recognize the IP addresses of the servers for a single remote Communication Manager cluster. Type a list of IP address pairs for the Communication Manager servers in a remote cluster. Use commas to separate the addresses. A pair consists of a server’s NAT (external) IP address and its IP address inside the cluster. A Communication Manager cluster can contain three IP addresses: an active SPE virtual address, a primary physical address, and a secondary physical address. Each of these addresses must be represented by a pair in this parameter. A maximum of six IP addresses is allowed in this parameter. Use the following format: externalactiveSPEvirtualaddress,internalactiveSPEvirtualaddress,externalprimaryphysicaladdress,internalprimaryphysicaladdress,externalsecondaryphysicaladdress,internalsecondaryphysicaladdress In the following example, the 10.41* addresses are externally visible and the 172.16* addresses are visible only to the Communication Managers: 10.41.1.10,172.16.1.10,10.41.1.11,172.16.1.11,...
Full path to file with list of active Communication Manager servers	Instead of listing each server separately, you can specify the full path to a file on the proxy computer that contains a list of IP addresses or hostnames of Communication Manager servers. In the file, specify the servers on multiple lines and ensure that each line contains only one entry. For example: AvayaCM01 AvayaCM02 AvayaCM10 You can enter IP addresses or hostnames, but you must enter the same IP address or hostname for which you configured SNMP community string information. If you configured a community string for a hostname, enter the same hostname in the list; if you configured an IP address, enter the same IP address in your list. For more information, see Configuring SNMP Community Strings.
Add Avaya Index to discovered names?	Select Yes to discover all Avaya objects for which indices will be collected.The collected indices will be placed in the treeview with the treeview name formed by suffixing the index of the object to the Avaya name of for the object. For example: “Fax test 1” at index 14 becomes Fax test 1[14] and “Fax test 2” at index 15 becomes Fax test 2[15]. The Avaya objects that use indices for identification include the following: Trunk Groups Gateways Hunt Groups If a trunk group has been named with a num suffix, do not use that suffix as a trunk group index. If there are two objects with the same name that have indices present, the names will be decomposed to identify the specific index so that the correct object is monitored. When this parameter is deselected, Avaya will suffix index numbers only to names that are not unique.
Resolve server names locally on agent?	Select Yes to override the Avaya call server MIB entries for server names with names found by the agent’s local name resolution lookup. The default is unselected. If set to Yes, the server name resolutions that are run on the agent will override the name values read through the Avaya call server MIB. The names displayed in the treeview will be the ones found by the agent when doing a reverse DNS for the discovered IP addresses. For example, s8000-001-EndCustomer1@MSP-com will display as s8000-001-EndCustomer1. The domain portion of the FQDN returned will not display. If set to Yes, and if the Network Address Translation (NAT) is in use (a list of address pairs entered for the NAT discovery parameter), the reverse DNS lookup will be for the addresses visible to the agent instead of the addresses for the call server side of the NAT. NOTE:If the set to Yes, an error case may occur if one or more of the server IP addresses (active SPE, server a or server b) cannot be resolved with a reverse DNS lookup because no lookup entry exists on either the DNS server or in the host file. If this occurs, the IP address that is used for the lookup is substituted for the missing name.
Discover using manual configuration	Select Yes to bypass SNMP and discover the data based on the IP address entered. Using a DNS lookup, the cluster name will be resolved, or if the lookup does not return a name, Avaya uses the IP address as the cluster name. Call data collection is supported for Call Managers discovered when bypassing SNMP, but Knowledge Scripts requiring SNMP are not supported. The treeview objects corresponding to SNMP-based Knowledge Scripts do not appear in the treeview. When this parameter is deselected, Avaya will use SNMP.
Discover Trap Receiver?	Select Yes to discover NetIQ SNMP Trap Receiver. When this parameter is selected, a treeview object is created for each call manager server (including ESS and LSP servers) in the cluster as well as for each H.248 gateway known to the cluster. You should configure the gateways to send traps directly to the Appmanager agent. For additional information about configuring gateway trap destinations, see https://downloads.avaya.com/css/P8/documents/100134724.The default is unselected.
Trap Receiver IP address	Specify the IP address of the computer on which Trap Receiver is installed. The default is localhost.
Trap Receiver TCP port	Specify the TCP port number through which Trap Receiver will communicate with AppManager. The default is port 2735.
Configure Trap Receiver for associated servers?	Select Yes to allow Trap Receiver to listen for traps coming from other servers such as SIP Enablement Services (SES) servers or Application Enablement Services (AES) servers. The default is unselected.
Comma-separated list of associated server IP addresses	Provide a comma-separated list of the IP addresses of other servers. If you enabled the Configure Trap Receiver for associated servers? parameter, then Trap Receiver will listen for traps coming from the servers you specify.