Cisco.IP.Telephony.Planning.Design.Implementation.Operation.and.Optimization [Electronic resources] نسخه متنی

CallManager Operation and Monitoring Tools

This section discusses the various tools available in CallManager that assist you in performing day-to-day operations and monitoring tasks.

Multilevel Administration

Chapter 8, "Implementation," discussed the use of the Multilevel Administration (MLA) tool during the IPT deployment. In day-to-day operations, you can use MLA to create different support groups and assign different access privileges. For example, you can give the tier 1 support group privileges to access the IP Phone configuration pages, and User management pages to troubleshoot basic end-user problems. You can give the tier 2 support group full privileges to add new gateways, new devices, and so forth. Finally, you can give the tier 3 support group, which is responsible for the complete system administration, full access to all the elements of the CallManager Administration and Serviceability pages.

Quality Reporting Tool

The Quality Reporting Tool (QRT), as the name indicates, helps users to report voice-quality problems and many other common problems with IP phones as soon as they experience them. This tool enables users to flag the following events:

Poor voice-quality calls

Phone reset events

Problems making outside calls

QRT depends on the Cisco Extended Functions (CEF) service, which you must activate to use the QRT feature. You can activate CallManager service(s) by selecting Tools > Service Activation menu option from the CallManager Serviceability page. Users access the QRT feature by using a softkey on the IP Phone, as shown in Figure 9-3.

By default, this softkey is not available in the Standard softkey template. You must configure a new softkey template that includes a QRT softkey and assign this template at the device pool or at the individual phone level. To define a new softkey template from the CallManager Administration page, select Device > Device Settings > Softkey Template.

The user can select the QRT softkey in four different call states: Connected, Connected Conference, On Hook, and Connected Transfer. In the On-Hook state, pressing the QRT softkey presents three problem categories:

Problems with last call

Phone recently rebooted

Can't make calls

As shown in Figure 9-3, each of these problem categories has reason codes associated with it, to simplify the problem-reporting task for users. When you select the QRT softkey on the Cisco IP Phone in any other state other than On-Hook, you will be asked to report the problem against one of the displayed reason codes, and you are not provided with the problem category choices.

You have the choice to deploy the QRT feature in either of two different modes:

Silent mode (default)

Interview mode

To set the QRT feature to interview mode, change the Display Extended QRT Menu Choices service parameter service parameter for the Cisco Extended Functions service to true. To access this service parameter from the CallManager Administration page, select Service > Service Parameters to bring up Service Parameters Configuration page. From this page, choose Cisco Extended Functions service for the Service option.

In interview mode, while you are on the call (Connected State), pressing the QRT softkey on the Cisco IP Phone presents various reason codes for the call. Users can select the right reason code (for example, I heard echo or Long delays) when reporting the problem for the current call. In silent mode, in the Connected State, QRT does not present the reason codes to users.

QRT Viewer

QRT Viewer enables administrators to view the problems that are reported by the IP phone users through the QRT feature. Administrators should run these reports at least twice a week and take proactive measures to reduce the problems before they get out of control.

To access the report in CallManager 4.0, from the CallManager Serviceability page, select Tools > QRT Viewer. (In CallManager 3.3.3, select Tools > Phone Problem Reports Viewer.)

QRT Viewer provides many filters to pick the records for report generation and provides a variety of fields to include in the generated report. Figure 9-4 shows a sample report generated with QRT Viewer.

Real-Time Monitoring Tool

Real-Time Monitoring Tool (RTMT) assists you in monitoring real-time information of IPT components in a Cisco CallManager cluster. RTMT, a plug-in that is accessible from the CallManager Plug-Ins page, runs on the client workstation as a standalone Java application. Do not install the RTMT client application on CallManager servers. The RTMT client application uses HTTP to communicate with the CallManager server.

RTMT provides monitoring and reporting functionality. RTMT monitoring features provide information about the health of IPT components. RTMT reporting features provide trending analysis. RTMT polls the real-time information database that receives alerts from CallManager; it also polls the performance counters.

RTMT has predefined monitoring parameters. Thresholds can be set on these parameters to alert the administrator via e-mail or page. You can change the polling interval from the default value of 30 seconds. To do so, from the CallManager Administration page, select Service > Service Parameters, and then choose the Cisco RIS Data Collector (RISDC) service. Modify the Data Collection Polling Rate service parameter value to the desired polling interval. The predefined monitoring parameters and alerts are sufficient to monitor the health of the IPT system. RTMT provides flexibility to add more performance counters if needed.

RTMT provides the following seven different views. To access any view, click the desired view button on the left side in the RTMT application. Each view displays information about a similar group of objects. For example, Device view displays information about all the devices in the CallManager. The following sections describe the important objects that you need to monitor in each view.

Summary

Server

CallProcess

Service

Device

CTI

Perfmon

This section also discusses two other important features of RTMT. They are

RTMT alerts

RTMT reports

Summary View

Summary view displays information about CPU usage, memory usage, the number of registered phones, the number of calls in progress, and the number of active gateway ports/channels. This is useful information to monitor on a daily basis. A sudden decrease in the number of registered phones, for example, could indicate a problem with the server or with the switch/module on a particular segment. You should note the statistics on this page before performing an upgrade and run RTMT to ensure that the same numbers of IP phones and gateway ports are available after the upgrade.

During a busy period, monitor the CPU and memory usage. A value above 80 percent is not a good indication. Possible reasons for higher usage are that the server is overloaded with too many devices or a service is malfunctioning because of a memory leak. You should examine the reason for this high usage and act appropriately to reduce the usage values. High CPU usage could introduce call-processing delays.

Server View

Server view displays information about CPU, memory, and disk usage and the status of critical services.

The CPU and Memory page displays in graphical format the various processes that are currently running on the system and their corresponding memory and CPU usage. Whenever you notice higher CPU or memory usage, you can see which service is taking up maximum resources. This information will help you to troubleshoot issues such as a slow dial tone, CallManager not responding, and so on. You also can view the memory and CPU usage of another server in the cluster.

Enabling detailed tracing levels for the signal distribution layer (SDL) and system diagnostic interface (SDI) traces is often required during troubleshooting. Detailed tracing occupies a lot of disk space. If the level of trace remains at Detailed, you might run out of disk space. The information gathered from disk usage will help to prevent such scenarios.

The Critical Services page lists all the CallManager-related services, including the status and uptime of the service.

CallProcess View

CallProcess view displays information about call activity, gateway activity, trunk activity, and SDL queues. The information displayed under Gateway Activity assists you in evaluating the capacity of the PRI usage and assists you in troubleshooting issues with PRI when the channel is activated but not operating.

Selecting SDL Queue from the CallProcess view displays the number of signals and requests in various SDL queues and the number of processed requests. To understand the importance of the SDL queue parameters, you need to know about the call-throttling feature in CallManager. Call-throttling protects CallManager from high CPU usage caused either by a burst of call attempts that exceeds the threshold that the CallManager can support or by a call routing loop. In addition, a faulty hardware or faulty firmware could send too many events to CallManager, forcing CallManager to process all the faulty requests, thereby reducing the CPU cycles available for other devices.

To protect from such events, CallManager places the incoming messages and signals into four different SDL priority queues:

High priority

Normal priority

Low priority

Lowest priority

CallManager processes messages in the high-priority queue before messages in the normal-priority queue, processes messages in the normal-priority queue before messages in the low-priority queue, and so forth. The types of messages that go into the normal-priority queue are the initial call setup messages. Whenever CallManager receives a new message request, it calculates the expected delay to complete the request. The expected delay depends on the number of messages in the queue and the number of messages processed.

The higher the number of signals waiting in the queue, the higher the delay is. If the delay is more than the configured threshold values (configured via the Cisco CallManager (CCM) Call Throttling service parameters), the call-throttling feature denies the incoming requests.

Figure 9-5 shows the CCM Call Throttling service parameters for the CallManager service.

Do not change the default values of the parameters shown in Figure 9-5 unless directed to do by Cisco support personnel.

In Figure 9-5, entering 0 for System Throttle Sample Size disables the call-throttling feature. The call-throttling mechanism applies to incoming calls from phones, Cisco IOS gateways, MGCP gateways, and MGCP back-haul PRI gateways. Whenever the call-throttling feature is called for, the IP phone devices making calls display the message "Too Much Traffic Try Again Later."

Service View

Service view displays information about the Cisco TFTP service, directory server, and Heartbeat for critical services.

The information gathered for the TFTP service includes total TFTP requests, total TFTP requests not found, and total TFTP requests aborted. This information helps you to troubleshoot TFTP-related issues during the initial phone registrations with CallManager. A higher number for TFTP requests not found indicates that many devices are attempting to download the configuration file or firmware from the TFTP server but are unable to find the specified file. This clearly indicates that you must have specified a device load in the Device Defaults page that does not exist in the TFTP server.

The Directory Server window displays information about the status of the replication; this helps you to troubleshoot issues related to directory replication.

The HeartBeat window shows the HeartBeat count for CallManager service, Cisco TFTP service, and Cisco Telephony Call Dispatcher (TCD) services. The HeartBeat is an incremental count that indicates which service is alive and running. If the count for a service does not increment, you can consider the service dead, and you should take immediate action to analyze the reason for the failure of the service.

Device View

Device view displays information about the number of registered phones, registered gateways, and registered media resource groups. The information gathered in the Device Summary view assists you during a CallManager upgrade, where the number of devices registered before the upgrade must be equal to the number of devices registered after the upgrade. It also gives you the data required to calculate the device weights or dial plan weights for the CallManager cluster.

The Device Search view lets you search for devices, such as IP Phones and gateways, in the cluster. An important feature of the Device Search view is that it enables you to search for devices based on their status, such as registered, unregistered, or registration rejected, as shown in Figure 9-6. RTMT and the IP Phone Information Facility option in the IP Telephony Monitor (part of ITEM) are the only Cisco tools that allow you to query the devices based on the real-time status. You can use this search filter to determine the number of phones that are in the unregistered status before or after an upgrade or during the deployment of IP Phones in the network.

The filter in the Device Search that is of most interest in day-to-day operations is the search based on the IP address or IP subnet, as shown in Figure 9-7. You might want to search using these filter options if multiple users report problems with their IP phones. If you can narrow down the problems to a group of users based on an IP subnet, you can focus on troubleshooting only within that network segment or device pool.

CTI View

The Computer Telephony Integration (CTI) view provides the status of the registered CTI applications and their connection status.

Perfmon View

Perfmon view displays all the counters available in Windows Perfmon. To meet your requirements, you can select a particular counter that is not available in default monitoring and add it. You can also set alerts for the new counter, as discussed in the next section.

RTMT Alerts

There are two kinds of RTMT alerts. The first set is preconfigured, and the second set is user defined. You can customize both of them. The main difference is that you cannot delete preconfigured alerts, whereas you can add and delete user-defined alerts. However, you can disable both preconfigured and user-defined alerts. To view the preconfigured alerts, from the RTMT client application, select the Alert > Alert Central menu option.

The preconfigured alerts are enabled by default. In most cases, you do not have to change the default threshold settings configured for the preconfigured alerts. However, you have an option to change the threshold settings to meet your requirements. The notification can be an e-mail or a pager. To set up e-mail notification, you should specify the SMTP server name and port number. You can do this in the RTMT client application by selecting the Alert > Configure E-Mail Server menu option.

To set a new alert, select the Perfmon Monitoring in PerfMon view, select any performance counter that you want to monitor, and right-click the graph to configure the alert settings, as shown in Figure 9-8.

Example 9-2 shows a few sample alert messages sent by RTMT via e-mail.

Example 9-2. Sample RTMT Alert Messages Sent via E-Mail

From: RTMT_Admin@xyz.com
Sent: Friday, February 27, 2004 1:47 AM
To: ccmadmins@xyz.com
Subject: [RTMT-ALERT] CallProcessingNodeCpuPegging
At 01:46:03 on 02/27/2004 on cluster StandAloneCluster.
Number of registered phones in the cluster drops 10 Percent.
Current monitored precanned object has decreased by 100 percent.
This is alert from CallManager 4.0 server At 01:46:33 on
02/27/2004 on node 10.1.3.1. Processor load over 90 Percent.
Ccm (91 percent) uses most of the CPU.
At 21:01:03 on 02/27/2004 on node 10.1.3.1.
Directory connection failed .
Monitored precanned object has value of 0.
At 18:12:27 on 02/26/2004 on cluster StandAloneCluster.
Number of registered gateways increased.
Current monitored precanned object has increased by 1.

RTMT Reports

RTMT reporting functionality provides predefined reports that include the information collected during the monitoring process. To access the RTMT reports, from the CallManager Serviceability page, select Tools > Serviceability Report Archive. There are five predefined reports:

Alert report

Call Activities report

Device Statistics report

Server Statistics report

Service Statistics report

The service parameter RTMT Report Deletion Age for the Cisco Serviceability Reporter service defines the age of the report. This parameter specifies the number of days that must elapse before reports are deleted. For example, if this parameter is set to 7 (default value), reports that were generated 7 days ago are deleted on the eighth day. A value of 0 disables report generation, and any existing reports are deleted.

These reports aid you in analyzing the capacity of the system and troubleshooting problems. More importantly, careful interpretation of the reports will help you to identify the problems in advance and take appropriate measures to prevent them from happening again.

The service that is responsible for generating the reports is Cisco Serviceability Reporter service. Set the service parameter RTMT Report Deletion Age for this service to 30 and keep the reports for 30 days. At the end of 30 days, copy the reports onto the network share server so that the trending analysis covers a longer period, resulting in meaningful data.

CallManager Traces

CallManager traces aid you in troubleshooting various issues with CallManager. CallManager logs every incoming and outgoing message in the trace files. Table 9-2 lists the location of the trace files for various applications. This information helps you when you are working on troubleshooting issues. All the trace directories are located under the C:\Program Files\Cisco\Trace directory.

Trace Configuration

To configure the level of tracing for the available services, select Trace > Configuration on the CallManager Serviceability page. The default tracing level for all the services is Error. Enabling the Detailed tracing level for any of the services logs huge amounts of data in the log files.

The Troubleshooting Trace Settings Page and Cisco CallManager Trace Collection Tool

The Troubleshooting Trace Settings page provides a one-stop shop for enabling the traces required to troubleshoot a problem. This page offers you the option of selecting the service on a particular CallManager or on the entire cluster. This page has predefined trace levels to capture sufficient information needed by Cisco TAC and engineering teams to investigate deep into the problems. To access the Troubleshooting Trace Settings page from the CallManager Serviceability page, go to Trace > Troubleshooting Trace Settings.

The client portion of this tool, CallManager Trace Collection Tool, sits on a desktop running Windows XP or Windows 2000. With this tool, you can connect to any CallManager from your desktop or laptop and collect all the required traces. The client version of this tool is available as a plug-in on the CallManager Administration page. To access the tool after the installation from your workstation, select the Trace Collection Tool menu option from Start > Programs > Cisco CallManager Serviceability > Trace Collection Tool.

This tool gathers log files that are associated with various CallManager services, CallManager applications, system traces. System traces include Event Viewer logs, Dr. Watson logs, Microsoft IIS logs, SQL logs, Directory logs, System Performance logs, and Prog logs.

Refer to the following URL for more information on the Trace Collection Tool and Troubleshooting Trace Settings page:

http://www.cisco.com/en/US/partner/products/sw/voicesw/ps556/products_configuration_example09186a00801f3b4d.shtml

Bulk Trace Analysis Tool

The Bulk Trace Analysis Tool assists you in troubleshooting a problem that requires you to analyze logs collected over a period of time. Enabling the Detailed level traces on CallManager uses a lot of CPU and memory resources. Furthermore, analyzing such a large amount of data on CallManager requires more resources. By using the Bulk Trace Analysis Tool, you can analyze the trace files from a standalone workstation. This tool reads the SDI and SDL trace files stored in XML format. By default, all CallManager traces are stored in plain text files. To generate SDI and SDL trace files in XML format, you should enable XML tracing from the Trace Configuration page for the services. The limitation of logging traces in XML format is that it reduces the number of lines stored per log file and increases the amount of processing power required to analyze and display the contents. Hence, avoid using XML logging whenever possible.

You can install the Bulk Trace Analysis Tool on your workstation by downloading the Bulk Trace Analysis Tool plug-in from the CallManager Plug-ins page. Do not install the tool on the CallManager Publisher or Subscriber servers because analyzing a large number of trace files consumes CPU and memory resources. You can copy the XML trace files that you need to analyze from the CallManager server to your workstation and open them in the Bulk Trace Analysis Tool.

Figure 9-9 shows the sample output of an analysis of XML trace files by using the Bulk Trace Analysis Tool.

CDR Analysis and Reporting

CDR Analysis and Reporting (CAR) reads the records stored in the CallManager Call Detail Record (CDR) and Call Management Record (CMR) databases and provides basic billing reports and an interface to search the CDRs. CAR stores all the extracted information from the CDR and CMR databases in a separate database file called ART in SQL (also referred to as the CAR database). By default, this process runs at midnight every day. The amount of time required to complete this process depends on the number of records in the CDR database, which again depends on the call volume in the cluster.

You have to set to True the following three CallManager service parameters to enable logging of CDR and CMR data:

CDR Enabled Flag

CDR Log Calls with Zero Duration Flag

Call Diagnostics Enabled

Note that CAR is not full-fledged billing software, because it contains only raw data. There is no link between the minutes, time of day, destination/called number, and related costs.

You can install CAR on the CallManager Publisher. The installation file is available on the CallManager Plug-Ins page. After CAR is installed, you can access the application from the CallManager Serviceability page by selecting CDR Analysis and Reporting from the Tools menu.

You can generate three types of reports using CAR:

User reports

System reports

Device reports

User Reports

User reports can provide billing information about an individual user or a whole department. You can determine who the top users are based on several categories, including usage duration, number of calls, and amount of charges. This information helps you to identify users in the cluster who have a heavy call volume.

The CDRs do not contain cost information, by default. However, in the CAR application, you can select Rating Engine from the Report Config menu to configure the costs associated with calls and define the cost factors based on time of day. After you configure these values, the reports you generate through CAR will have cost information.

When you log in to the CAR application, if your user ID is assigned as a manager for some users in the CallManager user pages, you can generate a report for all the users who are reporting to you.

System Reports

The system reports provide information about QoS, traffic, and malicious calls, and provide a system overview. The QoS reports help you to troubleshoot voice-quality issues; they contain information about jitter and packet loss. The Call Management Record database stores the information about QoS parameters.

The traffic report identifies traffic patterns, provides information about the call activities during the day, and identifies the peak time and lean time. This report helps in capacity planning of the gateways and circuits.

Device Reports

The device reports help in capacity planning of gateways, Conference Bridge resources, and voice mail. The route plan report provides information about the use of the route pattern, route list, and route group. The route plan report helps you to optimize the dial plan.

The CDR search tool helps you to pull a CDR for a particular call that experiences problems; the details in the record help you to troubleshoot issues with one-way audio, duplex mismatch, and so on.

Q.931 Translator

The Q.931 Translator tool decodes the ISDN messages by reading the CallManager trace files. You should enable Detailed tracing and Q.931 tracing on the CallManager service to log the messages in the trace files. To access the Q.931 Translator, go to the CallManager Serviceability page and select Trace > Q.931 Translator. Figure 9-10 shows the Q931 Translator application.

Alternatively, you can copy to your laptop or PC, along with the trace files, the q931Translator.exe program stored in the C:\Program Files\Cisco\bin directory on the CallManager server. After you have the executable file and the trace files on your PC or laptop, you can run Q.931 Translator locally to analyze the traces. This also avoids the extra CPU time required on the CallManager to run the tool and analyze a large number of traces.

Alarm Configurations and Definitions

CallManager logs alarms in the Windows Event log, SDI/SDL traces, or syslog. You can also specifically choose the destinations in which to log the alarms. For example, you can configure the alarm settings, so that CallManager logs all emergency alarms in the event log and all alarms with error level in the SDI/SDL logs. You can log the alarms to an external syslog server by specifying the IP Address of the syslog server in the Alarm configuration page.

To get the meaning of these alarms and recommended actions, you can search in the alarm definitions. To access the alarm definitions, from the CallManager Serviceability page, select Alarm > Definitions.

Backup and Restore System

The availability of the IPT network relies mainly on the availability of the CallManager cluster, which controls the call processing and call routing. A strong backup and restore policy enables the organization to restore the database and bring up the CallManager cluster quickly in case of a disaster, such as failure of hard disks, a fire, or a natural disaster (for example, a flood). A good backup also helps in recovering the data in case of an unsuccessful CallManager upgrade.

High-end CallManager servers have mirrored hard drives. Hence, failure on one hard drive does not affect the functioning of CallManager.

During the installation of the BARS application, you configure the backup server and backup target, the backup server performs all the backup operations, and the backup target contains information to back up. Usually, the backup server resides on CallManager Publisher.

In a CallManager cluster, the Publisher contains a read-write database and the Subscribers contain a read-only database. The Publisher database, which is also called the master database, holds all the changes made to a cluster; thus, you do not have to back up the data on Subscribers.

The CallManager application bundles the Cisco IP Telephony Applications Backup Utility software for backing up and restoring the data. Cisco does not support the installation of any third-party backup application to take the backup of the CallManager data. The BARS application allows you to store the backup data on a tape, a network drive, or a local drive. The best practice is to back up the data to a tape or network drive; avoid using the local drive as the backup destination.

If you are using a network drive as the backup destination, ensure that the network drive share is configured and that the CallManager hosts and LMHOSTS files contain the name and IP address of the network share server.

The backup utility archives the configuration data into a single file. The filename format is backupmm-dd-yy.tar. The backup utility truncates the transaction logs for the CallManager database and the ART database.

A good backup strategy requires CallManager administrators to perform the following tasks:

Schedule the time and day for running the backup. Because the backup process is CPU intensive, schedule the backups during off-peak hours.

Check for errors after every backup. The log file is available under C:\Program Files\Common Files\Cisco\Logs on the backup server.

Validate and check the data integrity of the backup data once a month by restoring the data onto a lab server.

Perform the backup operation when you make major changes to the production cluster, such as numerous configuration changes or a CallManager version upgrade.

Sometimes Cisco releases upgrades to the backup software application alone. Check for the latest upgrades and perform them. After performing an upgrade, make a backup with the new version of the software and ensure that you can restore the data successfully.

To access BARS in CallManager 3.3(3) and above, select Start > Programs > Cisco BARS > BARS Admin. This is a web-based utility that allows you to configure the backup and restore the data.

In addition to running the backup utility to back up the data, you can pull one drive from the server spare drives to mirror the data on each server. This requires you to have an additional hard disk for each server. With this method, you can rebuild a cluster in less time. There are three imperative steps in mirroring:

Note

This section discussed the backup and restore operations for CallManager cluster only. You should also include other servers such as Unity, Personal Assistant, Cisco Emergency Responder, voice gateways, and other network devices in your backup schedule.

Password-Changing Tools

Because the interoperability relationships of Cisco CallManager are so complex, Cisco recommends that administrators and installers not change CallManager passwords or services manually. The following two tools are available to change the passwords used by Cisco CallManager:

Cisco CallManager Admin Utility (adminutility.exe)

Cisco CallManager Password Changer (ccmpwdchanger.exe)

Admin Utility

Starting with CallManager 3.3(2), Cisco has modified the way passwords are used for various services in the CallManager cluster to increase the security for the Windows Services that comprise the system. Many of the services that were running as Local System in prior releases have been changed to run as Local Windows user accounts and services. The services that use these accounts are listed in Table 9-3.

During installation, by default, the accounts shown in Table 9-3 are created (without Log on Locally access) and the local Windows password is generated by an algorithm based on the NetBIOS name of the CallManager Publisher server as the seed for each account within the Cisco CallManager cluster. After entering the private password phrase during the Publisher installation, the passwords for the service accounts are regenerated and modified. When you are installing the Subscriber servers, you should enter the same password phrase that you used when building the Publisher.

Because all the servers in the cluster must be able to communicate with Publisher to keep the database up to date, it is critical that the passwords for the service accounts shown in Table 9-3 are identical among all the servers in the cluster. If you decide to change passwords for any of these service accounts, you should use the Cisco-provided Admin Utility. The Admin Utility program is in the C:\Program Files\Cisco\Bin directory on the CallManager servers. You should run this utility on the CallManager publisher server only. Refer to the AdminUtility-Readmel file located in the C:\Program Files\Cisco\Bin directory on the CallManager servers before running this utility.

As with any installation or upgrade, Cisco recommends that you execute this utility during off-peak hours. This utility will change the affected local Windows account, services, and virtual directories.

If you choose to change all accounts on all systems within the cluster, all call processing will be terminated until the entire cluster is updated. Depending on the number of servers within the cluster and the call volume at the time this utility is executed, the upgrade process could take several minutes per server.

The steps to run the Admin Utility to set a new password are as follows:

Cisco CallManager Password Changer

You can use CCM Password Changer to change the password of special CCM users, such as the following:

Directory Manager (user account for DC Directory)

CCMSysUser (account used for CTI applications, such as QRT, CRA, and Callback)

CCMAdministrator (account used by MLA)

IPMASysUser (account used by IPMA)

CCM Password Changer works with all supported directory servers, which include DC Directory, Active Directory, and Netscape directory. This utility updates the passwords on all the CallManager servers in the cluster and in the registry. You have to reboot the CallManager servers any time you change the passwords.

To launch CCM Password Changer, using Windows Explorer, browse to C:\Program Files\Cisco\Bin and launch ccmpwdchanger.exe. Figure 9-12 shows the CCM Password Changer interface. Use the local Administrator password to log in to the CCM Password Changer.

Event Viewer

Windows Event Viewer is a useful monitoring tool for implementation and troubleshooting. You need to check Event Viewer periodically for errors; specifically, look for several events that occur at the same time. For instance, it is unusual to see a bunch of IP phones reporting transient connections or resetting at the same time; this can happen by pure coincidence, or it could indicate a problem with the switch module or a power failure for that physical location.

CallManager logs all events in the Windows Event Viewer application. Event Viewer records the errors in three kinds of logs. They are System log, Security log, and Application log. CallManager logs all errors under the Application log. If a service (including TFTP) cannot read the database (where it gets the trace configuration), it logs errors to Event Viewer. Event Viewer is the only place where these types of errors appear unless you have configured a syslog server. Figure 9-13 shows an error generated by the Cisco CallManager service in Event Viewer.

To open Event Viewer on CallManager or any other application servers, including Cisco Unity, select Start > Programs > Administrative Tools > Event Viewer.

Bulk Administration Tool

Bulk Administration Tool (BAT) is bundled with CallManager software and is available on the Cisco CallManager Plug-Ins page. BAT is a useful tool during implementation and in performing day-to-day operations. You have to install BAT on CallManager Publisher. To access the BAT application from Internet Explorer, type the URL http://IPADDROFPUBLISHER/bat.

Some of the day-to-day operations involved in IPT networks are the following:

Adding new IP Phones

Changing settings on IP Phones, such as changing calling privileges (changing partitions, CSS), or changing the number of lines configured on the phones

Subscribing IP Phones to new services

Migrating users from one cluster to another cluster

Consolidating two CallManager clusters into a single cluster

BAT allows you to do all of the above and many other tasks. When you are moving users between clusters, you can use the BAT export feature to export the user or phone information into a file and use this file to import the same users or phones into the new cluster. When configuring the users in the CallManager directory, populate all the fields, including Manager Name and Department Name. This helps later when you have to manage the users in bulk, because you can base search criteria on the Manager Name field or Department Name field.

BAT writes the configuration changes directly into the SQL database. To avoid having end users experience call-processing delays because of high CPU usage, perform bulk changes using BAT after hours.

DHCP Management

IP Phones receive the IP addressing information and TFTP server information via custom Option 150 or Option 66 from the DHCP server. The best practice is to set the lease period to a longer duration (for example, 8 days). For devices such as CallManager servers, Unity, application servers, conferencing, transcoding, and voice gateways, assign the static IP addresses.

Before you choose Option 66 to pass the TFTP server information to the phones, make sure that you are not using that option in your network. Many other vendors already use the TFTP Boot Host 66 record for other purposes (netbooting X Windows workstations). If you are already using Option 66 for such purposes, you should use DHCP custom Option 150. If you use Option 66, you have to use a fully qualified name to specify the DHCP server, which requires relying on the DNS server to resolve the DHCP server name to an IP address before IP Phones can send out the DHCP request. By comparison, DHCP custom Option 150 allows you to configure the IP address for the DHCP server and to specify an array of IP addresses instead of just one. IPT endpoints such as Cisco IP Phones can receive the multiple TFTP server to provide the TFTP server redundancy and no need to relay on the DNS server.

The behavior of the IP phones as far as DHCP is concerned is the same as the behavior of any other DHCP client. When an IP phone boots, it sends a DHCPREQUEST, if it previously had a valid lease. The DHCP server responds with a DHCPACK message, if the phone can continue to use the same address. If the phone moves to another subnet, it gets a DHCPNACK, which forces the phone to do a DHCPDISCOVER and get a new lease. The lease should not expire, because the IP phone will make renewal attempts over the course of the lease time at certain intervals according to the DHCP specification (RFC 2131 and RFC 2132). Having a longer DHCP lease period helps the functioning of the IPT network, even if the DHCP server is down for more than one or two days.

You can use CallManager Publisher as a DHCP server for smaller IPT deployments of up to 250 phones. In a large network, the best practice is to deploy DHCP and TFTP servers on the same server. The following URL explains configuring Windows 2000 Server as a DHCP server:

http://www.cisco.com/en/US/partner/products/sw/voicesw/ps556/products_tech_note09186a00800942f4.shtml

The DHCP Export Import Tool from Microsoft comes in handy when you are upgrading server hardware or moving the DHCP server to a different machine. You can download the tool from the Microsoft website:

http://www.microsoft.com/downloads/details.aspx?familyid=3603ae26-81f0-478a-836cb31ed463af5e&displaylang=en

You can always use any other DHCP server, or even a router, as long as you can configure Option 150 to give out the TFTP server address as part of the DHCP request to the IP Phones.

Typically, companies use a centralized DHCP server that resides on the data network subnet that leases out the addresses for IP Phones and for user workstations. In this case, you should configure the ip helper-address IP address of the DHCP server on the routing interface (the routing interface acts as a relay agent) or set up a separate DHCP relay agent to convert the DHCP broadcast requests into unicast and forward them to the DHCP server and vice versa.