Application Notes for Consistacom Configuration Archive with Avaya Directory Enabled Management and Avaya Communication Manager Issue 1.

Transcription

1 . Avaya Solution & Interoperability Test Lab Application Notes for Consistacom Configuration Archive with Avaya Directory Enabled Management and Avaya Communication Manager Issue 1.0 Abstract These Application Notes describe the configuration procedures required for Consistacom Configuration Archive to successfully interoperate with Avaya Directory Enabled Management 3.0 and Avaya Communication Manager 3.0. Consistacom Configuration Archive (CAR) is a software application for logging configuration changes on Avaya Communication Manager for any data objects supported by Avaya Directory Enabled Management. Information relating to the changes is stored in a relational database, creating a historical log of all changes made. The database can then be searched, sorted and viewed at a later time. The general test approach included making configuration changes on Avaya Communication Manager and verifying that these changes were recorded in the archival database. Examples of the objects that were modified include agents, attendants, coverage paths, dial plan, and route patterns. Information in these Notes has been obtained through compliance testing and additional technical discussions. Testing was conducted via the DeveloperConnection Program at the Avaya Solution and Interoperability Test Lab. 1 of 26

2 1. Introduction These Application Notes describe a compliance-tested configuration archiving solution comprised of Consistacom Configuration Archive, Avaya Directory Enabled Management, and Avaya Communication Manager. Consistacom Configuration Archive (CAR) is a software application for logging configuration changes on Avaya Communication Manager for any data objects supported by Avaya Directory Enabled Management. Information relating to the changes is stored in a relational database, creating a historical log of all changes made. The database can then be searched, sorted and viewed at a later time. The information that is stored with each change includes: The date and time of the change The system name where the change occurred A descriptive name and unique id of the object being changed The type of change such as add, delete or modify Who made the change Object attribute values resulting from the change Figure 1 shows the logical flow of a typical Configuration Archive transaction to update configuration data. The steps are as follows: 1. A configuration change occurs on Avaya Communication Manager by an administrator or other application. 2. Avaya Communication Manager notifies Avaya Directory Enabled Management of the change via a proprietary interface. 3. Avaya Directory Enabled Management uses the Lightweight Directory Access Protocol (LDAP) to update the LDAP database with the change made on Avaya Communication Manager. 4. Avaya Directory Enabled Management notifies Configuration Archive of the change. 5. Configuration Archive creates an entry in the archival database, recording the information about this most recent change. 2 of 26

3 Figure 1: Typical Consistacom Configuration Archive Transaction to Record Configuration Changes The general test approach included making configuration changes on Avaya Communication Manager and verifying that these changes were recorded in the archival database. Changes were made from the Avaya Communication Manager System Access Terminal (SAT) and from another Consistacom application called Policy and Performance Agent Management. For the compliance test, Avaya Communication Manager was configured as an Automatic Call Distribution (ACD) environment. ACD environments typically have frequent configuration changes that need to be tracked. Examples of the objects that were modified include agents, attendants, coverage paths, dial plan, and route patterns. In a typical Configuration Archive installation, Configuration Archive runs on the Consistacom Synchronization Controller hardware bundled with Avaya Directory Enabled Management and Novell edirectory as the LDAP database. Thus, Consistacom performs the configuration procedures for these components prior to shipping the Synchronization Controller to the end customer. For the purposes of the compliance test, Configuration Archive, Avaya Directory Enabled Management and Novell edirectory were run on a Windows 2000 Server PC. Figure 2 illustrates the network configuration that was used for the compliance test. The configuration shows two systems each representing an Automatic Call Distribution (ACD) environment. Each ACD is implemented with an Avaya S8500 Media Server running Avaya Communication Manager and an Avaya G650 Media Gateway. The configuration also contains a Windows 2000 Server running Avaya Directory Enabled Management, Consistacom Configuration Archive, and Novell edirectory as the LDAP database. A second PC running Windows 2000 Professional serves as the System Access Terminal for Avaya Communication Manager. All of the network components are on the same Ethernet subnet and connect to an Avaya C363T-PWR Converged Stackable Switch. 3 of 26

4 Avaya Directory Enabled Management was configured to log in and exchange information with both ACDs. Thus, changes on either system would be recorded by Configuration Archive. Figure 2: Compliance Test Configuration for Consistacom Configuration Archive 2. Equipment and Software Validated The following equipment and software/firmware were used for the test configuration provided. Equipment Avaya S8500 Media Server Software/Firmware Avaya Communication Manager (R013x ) Avaya G650 Media Gateway - TN2312BP IP Server Interface (IPSI) HW 03 FW 21 TN799DP C-LAN Interface (C-LAN) HW 01 FW 15 TN2302AP IP Media Processor (MEDPRO) HW 20 FW 104 Windows PC with following applications Avaya Directory Enabled Management 3.0 ( ) Consistacom Configuration Archive 1.3 Novell edirectory Windows 2000 Server SP4 4 of 26

5 3. Configure Avaya Communication Manager This section describes the configuration procedure for Avaya Communication Manager to allow Avaya Directory Enabled Management to connect to it and allow Configuration Archive to record configuration changes. These steps are performed through the System Access Terminal (SAT). The following steps must be repeated for each Avaya Communication Manager to which Avaya Directory Enabled Management will need to communicate. Step Description 1. For the compliance test, Configuration Archive was tested in an Automatic Call Distribution (ACD) environment. In the form below, the display system-parameters customer-options command shows the following ACD-related features are enabled: ACD, Business Advocate, Expert Agent Selection and EAS-Phd. The y next to the feature name indicates the feature is enabled. However, enabling these features is not required for using Configuration Archive. To enable any of the features shown below, contact an Avaya representative. display system-parameters customer-options Page 6 of 10 CALL CENTER OPTIONAL FEATURES Call Center Release: 3.0 ACD? y Reason Codes? n BCMS (Basic)? n Service Level Maximizer? n BCMS/VuStats Service Level? n Service Observing (Basic)? y BSR Local Treatment for IP & ISDN? n Service Observing (Remote/By FAC)? n Business Advocate? y Service Observing (VDNs)? n Call Work Codes? n Timed ACW? n DTMF Feedback Signals For VRU? n Vectoring (Basic)? y Dynamic Advocate? n Vectoring (Prompting)? n Expert Agent Selection (EAS)? y Vectoring (G3V4 Enhanced)? n EAS-PHD? y Vectoring (3.0 Enhanced)? n Forced ACD Calls? n Vectoring (ANI/II-Digits Routing)? n Vectoring (G3V4 Advanced Routing)? n Lookahead Interflow (LAI)? n Vectoring (CINFO)? n Multiple Call Handling (On Request)? n Vectoring (Best Service Routing)? n Multiple Call Handling (Forced)? n Vectoring (Holidays)? n PASTE (Display PBX Data on Phone)? n Vectoring (Variables)? n (NOTE: You must logoff & login to effect the permission changes.) 5 of 26

6 2. Before Avaya Directory Enabled Management can connect to Avaya Communication Manager, a login must be created for this purpose. Use the add login <login-name> command to create the login. The Login s Name will be filled in by the <login-name> used on the command line. The Login Type must be customer and the Service Level must be super-user. Lastly, choose any valid formatted password for the Login s Password. add login dem Page 1 of 1 LOGIN ADMINISTRATION LOGIN BEING ADMINISTERED Login's Name: dem Login Type: customer Service Level: super-user Days To Disable After Inactivity: Shell Access? n LOGIN'S PASSWORD INFORMATION Login's Password: Change Password at First Login? n Password Aging Cycle Length (Days): LOGOFF NOTIFICATION Facility Test Call Notification? y Remote Access Notification? y Reenter Password: Acknowledgement Required? y Acknowledgement Required? y 6 of 26

7 3. Avaya Directory Enabled Management will log in to Avaya Communication Manager remotely through the C-LAN circuit pack for all Avaya Media Servers other than the Avaya S8300 Media Server. For the Avaya S8300 Media Server, Avaya Directory Enabled Management will log in remotely through the Media Server itself. In either case, a SAT IP service must be created for this purpose. However, before this can be done, the node name of the C-LAN circuit pack or Media Server must be known. In the case of the compliance test, the node name of the C-LAN circuit pack is needed since Avaya S8500 Media Servers were used in the test. To locate the node name of the C-LAN, use the list ip-interface clan command. If multiple C-LANs are displayed, locate the C-LAN in the list that will be used for the SAT remote access. Note the name in the Node Name / IP-Address field. The example below shows the node name of the C-LAN circuit pack is simply C-LAN. If the node-name of the Media Server is required, use the list ip-interface all command instead. Output from ACD 1 in Figure 2. list ip-interface clan IP INTERFACES Num Skts Net ON Slot Code Sfx Node Name/ Subnet Mask Gateway Address Warn Rgn VLAN IP-Address y 01A13 TN799 D C-LAN n Use the change ip-services command to create the IP service for the SAT connection. Set each field to the values shown in the example below. change ip-services Page 1 of 2 IP SERVICES Service Enabled Local Local Remote Remote Type Node Port Node Port SAT y C-LAN 5023 any 0 5. Repeat Steps 1-4 for the second Avaya Communication Manager in Figure Configure Novell edirectory Novell edirectory must be installed prior to installing Avaya Directory Enabled Management. Novell edirectory is pre-installed on the Synchronization Controller by Consistacom prior to shipping to the customer. These installation procedures are out of the scope of these Application 7 of 26

8 Notes. Any specific configuration required for use with Avaya Directory Enabled Management will be covered in Section Configure Avaya Directory Enabled Management Much of the configuration of Avaya Directory Enabled Management is done as part of the initial installation. This installation procedure can be found in reference [4]. This section will not repeat these procedures but will highlight the steps taken, the input required and the values used for the compliance test. In addition, this section will continue the configuration where the installation procedures end including the procedures described in reference [6]. All procedures in this section are performed by Consistacom prior to shipping the Synchronization Controller to the customer. Step Description 1. Install Avaya Directory Enabled Management as per the installation procedures described in reference [4]. As part of the installation, the administrator is prompted to add a Definity Server for each Avaya Media Server to which Avaya Directory Enabled Management will communicate. The following list shows the fields that need to be populated and the values used for the compliance test. DSM Name acd1 Name of the DataStore Manager internal to Avaya Directory Enabled Management that will communicate to a specific Avaya Media Server. Release Version R11 The value R11 is used for Definity Releases 11 or greater and all releases of Avaya Communication Manager. Host IP IP address on Avaya Communication Manager to be used for the SAT connection for Avaya Directory Enabled Management. This is the value displayed in Step 3 of Section 3. Port 5023 Port to use for the SAT connection. This value is shown in Step 4 of Section 3. Login dem Login configured in Step 2 of Section 3 for use by Avaya Directory Enabled Management. Password demtest123 Password configured in Step 2 of Section 3 for login dem. A second Definity Server was added with the following values. DSM Name acd2 Port 5023 Release Version R11 Login dem Host IP Password demtest123 8 of 26

9 2. Follow the procedures in reference [4] to configure the default parameters for each of the internal components of Avaya Directory Enabled Management. The procedures will cover the following: Configuring the LDAP Schema. Configuring the default triggers in the GWAgent. Activating the Synchronization Engine using the default settings. No additional mappings or routing rules will be created. Activating and attaching the DataStore Manager that connects to the LDAP Server. This creates a DataStore Manager with the default name of GWDSM. This step requires the following information about the LDAP database. o LDAP base o LDAP IP address o LDAP server port o LDAP user id with administrative privileges o LDAP password Activating and attaching the DataStore Managers that connects to the Avaya Media Servers. 3. Follow the procedures in reference [6] to activate, attach and configure the Adapter DataStore Manager that connects to Configuration Archive. The DataStore Manager that is created is given the name AdapterDSM. 9 of 26

10 4. Once the installation procedures are complete, all the Avaya Directory Enabled Management DataStore Managers (DSMs) are in the Ready state. Next, the Avaya Directory Enabled Management Administrator will be used to move all the DSMs to the Running state. If it is not already open, launch the Avaya Directory Enabled Management Administrator by navigating from the Windows Start Menu to Start Programs Avaya Directory Enabled Management DEM Admin. Select the DataStore Manager tab. Highlight one of the DSMs in the list that is in the Ready state. Select the Run button. Repeat for each DSM in the list that is in the Ready state. Please note that the DSM named ess1a was not used as part of the compliance test and so was left in the Offline state. 10 of 26

11 5. Once the DSMs are in the Running state, the indicators on the left turn green. 11 of 26

12 6. Configuration Archive requires that the terminal type used by the Definity DSMs be changed. To modify any Avaya Directory Enabled Management setting, select Actions Configurations from the menu. 12 of 26

13 7. To modify the settings of a DSM, set Device Class to DataStore Manager and highlight the specific DSM in the list. To accomodate Configuration Archive, modify the TerminalType to ossiz in the textbox called Configuration Details. Select Save and Done. 13 of 26

14 8. After the configuration of a DSM is changed, the DSM needs to be restarted. Cycle the DSM through the states of Shutdown, Activate, (Re)Attach, and Run using the buttons on the form. Once complete, the DSM will be returned to the Running state. 9. Repeat Steps 6-8 for each Definity DSM. After all the DSMs have been restarted, select Quit on the form in the previous step to exit the Avaya Directory Enabled Management Administrator. 14 of 26

15 6. Configure Consistacom Configuration Archive No additional configuration is required of Configuration Archive other than installing the application. All installation procedures are performed by Consistacom prior to shipping the Synchronization Controller to the customer. 7. Using Consistacom Configuration Archive This section will describe how to perform basic operations using Configuration Archive. Step Description 1. Use the Electronic Event Monitor to access data from the archival database. From the Windows Start Menu, navigate to Start Programs TCI EEMon Event Monitor. In the Enterprise Event Monitor window that appears, navigate to File Configure. 15 of 26

16 2. In the window below, select the Archive Login tab. Enter a valid Login ID and Password. In the Server field, enter the name or IP address of the host machine where the archival database resides. Use the default value for the Path field. Select the Login button to continue. 3. Upon successful login, the Login button becomes the Logout button and the Archive Login Status indicates that the Enterprise Event Monitor is connected to the archival database. Select Close to continue. 16 of 26

17 4. Returning to the Enterprise Event Monitor window, navigate to File Load From Archive. 5. Enter the date and time range for the configuration changes to be viewed. In the From Date field, enter the starting date and time. In the To Date field, enter the end date and time. Select OK to continue. 17 of 26

18 6. The lower part of the Enterprise Event Monitor window shows a summary of each change recorded in the specified date and time range. The scroll bar to the right of the window can be used to scroll through all the entries. The information displayed in the summary includes: The date and time of the change The system name where the change occurred A descriptive name and unique id of the object being changed The type of change such as add, delete or modify Who made the change either the login ID or application name 18 of 26

19 7. Highlighting an entry in the table in the lower grid of the window displays in the upper grid each attribute that was modified for that object. In the example shown below, an object with Name McClure,B and ID was added on 12/15 at 18:05:34 by APM. The time shown is Greenwich Mean Time (GMT). There is a GMT clock in the bottom of the window. The description of this object that appears directly below the menu bar indicates that this object is a definityacdagent. The list of attributes indicates the ID used in the summary table corresponds to the agent ID on Avaya Communication Manager. The Who field is typically the Avaya Communication Manager login ID of the person who made the change. In the special case, where the change was made by another Consistacom application, this will be indicated in the Who field. In the example below, the value of APM in the Who field indicates the change was made by the Consistacom application: Policy and Performance Agent Management. Testing also included making changes from the System Access Terminal of Avaya Communication Manager. 19 of 26

20 8. Historical information on the changes of an individual object can also be displayed. Highlight an entry in the table in the lower grid of the window, right-mouse click, and select Show History. 20 of 26

21 9. The following window appears showing all the changes for agent ID The example below shows that the agent was added, modified (including the Name), and deleted multiple times in the time frame displayed in the summary grid on the left side of the window. 10. Multiple entries in the table can be compared by highlighting the entries to be compared, followed by a right-mouse click, and select Compare Selected Events. 21 of 26

22 11. The following table shows the value of each attribute at the time the changes were performed. The example below shows that at the time of the first entry the attribute deftyagentskilllevel2 was set to 3 and at the time of the next entry it was changed to 1. Similarly, attribute deftyagentskilllevel3 was set to 2 and later changed to 5. All attributes with value <unavailable> were not set. More attributes can be viewed by scrolling through the list with the scroll bar at the right-side of the window. 22 of 26

23 12. The output can be simplified by viewing only those values which changed between the two entries. To do this, select the not equal icon in the tool bar at the top of the window. 8. Interoperability Compliance Testing This section describes the general test approach and results of the compliance test General Test Approach The general test approach included making configuration changes on Avaya Communication Manager and verifying that these changes were recorded in the archival database. For the compliance test, Avaya Communication Manager was configured as an Automatic Call Distribution (ACD) environment. ACD environments typically have frequent configuration changes that need to be tracked. 23 of 26

24 8.2. Test Results It was verified that Configuration Archive captured a record in the database for each configuration change on Avaya Communication Manager performed as part of the test. Configuration Archive can only support data objects supported by Avaya Directory Enabled Management. Examples of the objects that were modified include agents, attendants, coverage paths, dial plan, and route patterns. Observations with this solution: 1. Changes to route patterns on Avaya Communication Manager did not show up in the archival database. Configuration Archive expected the optype field in the Avaya Directory Enabled Management Change Descriptor to be populated. Since the field was not populated, the transaction was not included in the archival database. 2. Once, while making changes to a trunk group on Avaya Communication Manager, the change did not appear in the archival database due to Avaya Directory Enabled Management receiving a timeout when publishing to the Adapter DSM. The same operation was repeated and passed. 3. The details for a Class of Service (COS) change were not stored in the archival database. Avaya Directory Enabled Management encodes data differently for different data objects. Configuration Archive used the wrong encoding for this object so the details did not get recorded. 4. The Who field is blank for delete operations when the source of the operation is a Consistacom application. If the delete operation is performed by a user at the System Access Terminal (SAT), the loginid of the user will be displayed. 9. Verification Steps The following steps may be used to verify the configuration: Verify the physical connectivity between the Avaya Directory Enabled Management host machine and each Avaya Communication Manager that will be accessed. Use the ping command on the Avaya Directory Enabled Management host machine to ping each Avaya Communication Manager. Use the IP address that Avaya Directory Enabled Management is configured to use for its SAT connection. Verify that each ping command succeeds. Verify that the login to be used by Avaya Directory Enabled Management is properly configured on Avaya Communication Manager. From the Avaya Directory Enabled Management host machine, telnet into Avaya Communication Manager using the IP address and port number configured for use as the SAT IP service. Verify that a SAT login screen appears. Login to Avaya Communication Manager using the login and password configured for use by Avaya Directory Enabled Management. Verify that the login is successful. Verify the state of the DataStore Managers in Avaya Directory Enabled Management. Launch the Avaya Directory Enabled Management Administrator by navigating from the Windows Start Menu to Start Programs Avaya Directory Enabled Management DEM Admin. Select the DataStore Manager tab. Verify that each of the DataStore Managers is in the Running state. 24 of 26

25 Verify that a record is created in the database for a configuration change on Avaya Communication Manager. Modify any supported data object such as a station. Using the Electronic Event Monitor, verify that a record is created in the database indicating the correct object and time of the modification. 10. Support Technical support for Configuration Archive can be obtained by contacting Consistacom at (866) or (906) or via at support@telecominstitute.com. Sales support for Configuration Archive can be reached at (866) or via at solutions@telecominstitute.com. General company and product information can be found at the website Conclusion These Application Notes describe the procedures for configuring Consistacom Configuration Archive with Avaya Directory Enabled Management and Avaya Communication Manager. Consistacom Configuration Archive successfully passed compliance testing. 12. Additional References The following Avaya product documentation can be found at with the exception of reference [6], which is part of the Avaya Directory Enabled Management installation. [1] Feature Description and Implementation For Avaya Communication Manager, Release 3.0, , Issue 3.0, June 2005 [2] Administrator Guide for Avaya Communication Manager, Release 3.0, , Issue 1.0, June 2005 [3] Avaya Communication Manager Release 3.0, Call Center Software, Automatic Call Distribution (ACD) Guide, , Issue 1.0, June [4] Avaya Directory Enabled Management Release 3.0 Installation and Implementation, , Issue 9, April [5] Avaya Directory Enabled Management Release 3.0 Administration, , Issue 9, April [6] Adapter DSM Technical Notes, located in AdapterNotes2_0.pdf in the /docs folder of the Avaya Directory Enabled Management install directory. The following Configuration Archive product documentation is available from Consistacom. [7] PBX/ACD Configuration Archive / EEMon User Guide, Document Version C, December 7, of 26

26 Avaya and the Avaya Logo are trademarks of Avaya Inc. All trademarks identified by and are registered trademarks or trademarks, respectively, of Avaya Inc. All other trademarks are the property of their respective owners. The information provided in these Application Notes is subject to change without notice. The configurations, technical data, and recommendations provided in these Application Notes are believed to be accurate and dependable, but are presented without express or implied warranty. Users are responsible for their application of any products specified in these Application Notes. Please any questions or comments pertaining to these Application Notes along with the full title name and filename, located in the lower right corner, directly to the Avaya DeveloperConnection Program at 26 of 26