Avaya Interaction Center and Operational Analyst Release 7.2 Software Upgrade and Data Migration

Transcription

1 Avaya Interaction Center and Operational Analyst Release 7.2 Software Upgrade and Data Migration May 2009

2 2005 to 2009 Avaya Inc. All Rights Reserved. Notice While reasonable efforts were made to ensure that the information in this document was complete and accurate at the time of printing, Avaya Inc. can assume no liability for any errors. Changes and corrections to the information in this document might be incorporated in future releases. Documentation disclaimer Avaya Inc. is not responsible for any modifications, additions, or deletions to the original published version of this documentation unless such modifications, additions, or deletions were performed by Avaya. Customer and/or End User agree to indemnify and hold harmless Avaya, Avaya's agents, servants and employees against all claims, lawsuits, demands and judgments arising out of, or in connection with, subsequent modifications, additions or deletions to this documentation to the extent made by the Customer or End User. Link disclaimer Avaya Inc. is not responsible for the contents or reliability of any linked Web sites referenced elsewhere within this documentation, and Avaya does not necessarily endorse the products, services, or information described or offered within them. We cannot guarantee that these links will work all the time and we have no control over the availability of the linked pages. Warranty Avaya Inc. provides a limited warranty on this product. Refer to your sales agreement to establish the terms of the limited warranty. In addition, Avaya s standard warranty language, as well as information regarding support for this product, while under warranty, is available through the Avaya Support Web site: License USE OR INSTALLATION OF THE PRODUCT INDICATES THE END USER'S ACCEPTANCE OF THE TERMS SET FORTH HEREIN AND THE GENERAL LICENSE TERMS AVAILABLE ON THE AVAYA WEB SITE ("GENERAL LICENSE TERMS"). IF YOU DO NOT WISH TO BE BOUND BY THESE TERMS, YOU MUST RETURN THE PRODUCT(S) TO THE POINT OF PURCHASE WITHIN TEN (10) DAYS OF DELIVERY FOR A REFUND OR CREDIT. Avaya grants End User a license within the scope of the license types described below. The applicable number of licenses and units of capacity for which the license is granted will be one (1), unless a different number of licenses or units of capacity is specified in the Documentation or other materials available to End User. "Designated Processor" means a single stand-alone computing device. "Server" means a Designated Processor that hosts a software application to be accessed by multiple users. "Software" means the computer programs in object code, originally licensed by Avaya and ultimately utilized by End User, whether as stand-alone Products or pre-installed on Hardware. "Hardware" means the standard hardware Products, originally sold by Avaya and ultimately utilized by End User. License type(s) Concurrent User License (CU). End User may install and use the Software on multiple Designated Processors or one or more Servers, so long as only the licensed number of Units are accessing and using the Software at any given time. A "Unit" means the unit on which Avaya, at its sole discretion, bases the pricing of its licenses and can be, without limitation, an agent, port or user, an or voice mail account in the name of a person or corporate function (e.g., webmaster or helpdesk), or a directory entry in the administrative database utilized by the Product that permits one user to interface with the Software. Units may be linked to a specific, identified Server. Copyright Except where expressly stated otherwise, the Product is protected by copyright and other laws respecting proprietary rights. Unauthorized reproduction, transfer, and or use can be a criminal, as well as a civil, offense under the applicable law. Third-party components Certain software programs or portions thereof included in the Product may contain software distributed under third party agreements ("Third Party Components"), which may contain terms that expand or limit rights to use certain portions of the Product ("Third Party Terms"). Information identifying Third Party Components and the Third Party Terms that apply to them is available on the Avaya Support Web site: Preventing toll fraud "Toll fraud" is the unauthorized use of your telecommunications system by an unauthorized party (for example, a person who is not a corporate employee, agent, subcontractor, or is not working on your company's behalf). Be aware that there can be a risk of toll fraud associated with your system and that, if toll fraud occurs, it can result in substantial additional charges for your telecommunications services. Avaya fraud intervention If you suspect that you are being victimized by toll fraud and you need technical assistance or support, call Technical Service Center Toll Fraud Intervention Hotline at for the United States and Canada. For additional support telephone numbers, see the Avaya Support Web site: Trademarks Avaya and the Avaya logo are either registered trademarks or trademarks of Avaya Inc. in the United States of America and/or other jurisdictions. All other trademarks are the property of their respective owners. Downloading documents For the most current versions of documentation, see the Avaya Support Web site: Avaya support Avaya provides a telephone number for you to use to report problems or to ask questions about your product. The support telephone number is in the United States. For additional support telephone numbers, see the Avaya Support Web site:

3 Contents Preface Purpose Audience Related documents Chapter 1: Differences that affect migration Differences between Avaya IC 7.1 and Differences between Avaya IC 7.0 and Differences between Avaya IC and Differences between Avaya IC 6.1.x and Differences between Avaya IC and Avaya OA and Differences between Avaya IC 6.0 and Differences between Avaya IC 5.6 and Chapter 2: Upgrading Avaya Interaction Center from 7.1 to Considerations Prerequisites Prerequisites for migrating Content Analyzer Shut down Install Avaya IC Install the 7.2 Avaya Agent applications Prepare the new administration machine for migration Upgrade customized IC Scripts and workflows Copy customized website, Avaya Agent layouts, and EDU Viewer stylesheets.. 33 Migrate your ADL files Actions performed by Database Migration tool Prerequisites Migrate ccq.adl Migrate repository.adl Move the migrated files to Migrate your Avaya IC 7.1 servers Start the 7.2 core servers Troubleshooting Reconfigure your 7.2 databases Reconfigure the IC Repository database Reconfigure the CallCenterQ database Generate your applications Upgrade the 7.1 data to Software Upgrade and Data Migration May

4 Contents Import the 7.2 seed data Load the new workflows Migrate your server settings into Import your server settings Update server and agent properties Update existing server properties Set new properties for existing servers Update the web configuration Removing the ICM server context in IC Manager BA configuration Remove links to 7.1 Resource Manager servers Import new agent properties Update existing agent properties Migrate your Content Analyzer data Verifying the new Knowledge Base file locations Migrate data from server Migrate WAS to Tomcat Migrate SDK Install and Configure WebLM Start Avaya IC Deploy the Web Agent clients Uninstall 7.1 Avaya Agent applications Detailed changes to the IC Scripts and workflows IC Script changes Workflow changes Migrating Operational Analyst 7.1 to Migrating from Avaya OA to Avaya OA 7.2 on Windows Migrating from Avaya OA to Avaya OA 7.2 on Solaris Migrating from Avaya OA to Avaya OA 7.2 on AIX Chapter 3: Upgrading Avaya Interaction Center from 7.0 to Considerations Prerequisites Prerequisites for migrating Content Analyzer Remove unused servers Install Avaya IC Install the 7.1 Avaya Agent applications Prepare the new administration machine for migration Upgrade customized IC Scripts and workflows Software Upgrade and Data Migration May 2009

5 Contents Copy customized website, Avaya Agent layouts, and EDU Viewer stylesheets.. 87 Upgrade website Java methods Migrate your ADL files Actions performed by Database Migration tool Prerequisites Verify the size of varchar fields for Oracle databases Migrate ccq.adl Migrate repository.adl Move the migrated files to Migrate your Avaya IC 7.0 servers Start the 7.1 core servers Troubleshooting Shut down Reconfigure your 7.1 databases Reconfigure the IC Repository database Reconfigure the CallCenterQ database Generate your applications Upgrade the 7.0 data to Import the 7.1 seed data Import creationrules and fieldexpressions data Add the new default logout code Load the new workflows Migrate your server settings into Import your server settings Update the web configuration Update server and agent properties Update existing server properties Set new properties for existing servers Remove links to 7.0 Resource Manager servers Update the Chat transcript directory Import new agent properties Update existing agent properties Migrate long text property fields Migrate your Content Analyzer data Verifying the new Knowledge Base file locations Start Avaya IC Deploy the Web Agent clients Uninstall 7.0 Avaya Agent applications Detailed changes to the IC Scripts and workflows Software Upgrade and Data Migration May

6 Contents IC Script changes Workflow changes Chapter 4: Upgrading Avaya Interaction Center from to Considerations Upgrade Business Advocate Prerequisites Prerequisites for migrating Content Analyzer Install 7.0 administration and migration tools Migrate your ADL files Actions performed by Database Migration tool Prerequisites Verify the size of varchar fields for Oracle databases Migrate ccq.adl Migrate repository.adl Migrate dialer.adl Move the migrated files to Upgrade customized IC Scripts, workflows, and website files Avaya Agent EDU Viewer stylesheets Shut down Install the 7.0 servers Update the telephony configuration Set up the VMM Service Reboot your server machines Migrate your Avaya IC servers Troubleshooting Remove unused data sources Update the web configuration Update the Chat transcript directory Import the 7.0 seed data Import the localization seed data Reconfigure your 7.0 databases Reconfigure the IC Repository database Reconfigure the CallCenterQ database Reconfigure the Outbound Contact database Generate your applications and load the new workflows Disable Business Advocate mapping rules Migrate your server settings into Import your server settings Software Upgrade and Data Migration May 2009

7 Contents Import new agent properties Migrate your Content Analyzer data Verifying the new Knowledge Base file locations Upgrade your Avaya Agent applications Uninstall Uninstall Avaya Agent applications Detailed changes to the IC Scripts, workflows, and website files IC Script changes Workflow changes Website file changes Chapter 5: Upgrading Avaya Interaction Center from 6.1.x to Considerations Upgrading Avaya Operational Analyst Upgrading Siebel Prerequisites Upgrading customized IC Scripts, workflows, and website files Shut down 6.1.x Upgrading to Upgrade your server installations Upgrade your Design/Admin installations Upgrade Business Advocate Upgrade your Avaya Agent applications Restart the primary ORB server Import your server settings into Import the IC Scripts and workflows Import the seed data Upgrade the Full Text Search Engine Reconfigure the servers on Solaris and AIX Stop and restart all Avaya IC servers Changes to the IC Scripts, workflows, and website files IC Script changes Workflow changes Website file changes Chapter 6: Upgrading and migrating from to Overview of the migration process Verify valid Avaya OA upgrade file Considerations and prerequisites Considerations Software Upgrade and Data Migration May

8 Contents Prerequisites for migrating Content Analyzer Prerequisites for migrating all configurations of Avaya IC Prerequisites for Avaya OA upgrades Set up a test system for migration Prepare for Avaya IC installation Install the Avaya IC software Migrate the application ADL files Requirements for FixDesignFiles Run FixDesignFiles Migrate IC Scripts, workflows, and Avaya Agent files Avaya Agent Layout (CDL) file changes Avaya Agent EDU Viewer stylesheet changes Create the Avaya Agent application installer Install the Avaya Agent applications Increase the database Timeout parameter Testing your Timeout parameters Prepare to shut down Avaya IC Shut down Avaya IC Disable JRun servers and remove JRun connector filters Back up your databases Migrate your Avaya IC servers Upgrade your Avaya IC databases to Change the reportowner and packowner fields Reconfigure your databases Insert Avaya IC specific properties into the database Rerunning update_properties Import creationrules and fieldexpressions data Migrate your existing Prompter ActiveX controls Generate Windows applications and update server information Generate the Windows applications Back up your databases Update server information Install your secondary ORB servers Configure the License server Upgrade Avaya OA on the CMS servers Expand the Avaya OA forwarder buffer sizes Verify that Avaya OA interval processing and aggregation are complete Upgrade the Avaya OA subsystem on CMS servers Software Upgrade and Data Migration May 2009

9 Contents Shut down the Avaya OA servers before starting the upgrade Verify that Avaya OA interval processing and aggregation are complete Stop Avaya OA processes Filesystem backup for Avaya OA Upgrade Avaya OA components from to Path definitions License key considerations Update Cognos and server properties Upgrade Avaya OA software Bring up the Avaya OA servers and components Start up all Avaya OA servers Disable aggregation recovery Update and verify Avaya OA components Verify that forwarders on CMS servers are sending data Migrate the Avaya OA historical database Prerequisites Transfer the Avaya OA historical data Migrate the Avaya OA historical RowDate data Complete related data migration procedures Migrate Chat & data Update Chat & data with the new schema Import new seed data Reconfigure the Chat & database Install and configure Web Management Reapply your customizations to Chat & Migrate your Content Analyzer data Verifying the new Knowledge Base file locations Migrate Avaya Agent applications Migrating Agent resources Migrate the Report Wizard application Contact form Migrate WebQ Complete the migration process Migrating mcscon.ini Verify Content Analyzer migration Migrate QKnowledge Migrate contact data Back up your databases and server files Put into production Moving to Business Advocate Software Upgrade and Data Migration May

10 Contents Restoring Chapter 7: Upgrading Avaya Interaction Center from 6.0 to Chapter 8: Migrating from Avaya IC 5.6 SP1 to Overview of the migration process Migration prerequisites Prerequisites for migrating Business Applications Prerequisites for all configurations of Avaya IC 5.6 SP Prerequisites for chat and migration Prerequisites for installing the web and servers on a new machine 307 Migrate application ADL files Move the migrated ADLs to the design subdirectories Create the application databases Creating the CI Repository database Creating the CCQ database Creating the HRQ database Creating the CustomerQ database Copy 5.6 SP1 data into Copying SQL Server data Copying Oracle data Update database constraints Reconfigure your application databases using the migrated ADL files Import seed data for new CI Repository database tables Create the Migration database Run DBMigrate Verify the data migration Migrate and chat data Update chat and data with the new schema Import new seed data Reconfigure the chat and databases Reapply 5.6 SP1 configuration and customizations Routing changes Chat client changes Chat and workflow changes IC Script changes Historical data changes Migrate Web Agent applications drafts Migrating agent resources and preferences Software Upgrade and Data Migration May 2009

11 Contents Setting the home directory for agents Migrate Message Care Migrate your Avaya Agent CDL files Migrate your Avaya Agent EDU Viewer stylesheets Migrate your existing workflows Customized workflow block changes Letter Generation workflow changes Migrate your existing Prompter ActiveX controls Migrate your existing IC Scripts Generate the Windows applications Migrate WebQ Remove old QRepository data source Migrate telephony Migrate QKnowledge Customizing the DBMigrate tool Data schema changes in Working with the Migration ADL file Process flow Format of the XML file Modifying the XML file XML elements for DBMigrate tool DBMIGRATE PROPERTIES PROPSECTION PROPERTY TABLES TABLE OLDTABLE NEWTABLES NEWTABLE UPDATE ORCRITERIA ANDCRITERIA COLUMNS COLUMN NEWCOLUMNVALUE FROMOLDCOLUMN COMPUTED APPEND Software Upgrade and Data Migration May

12 Contents Chapter 9: Migrating telephony from Avaya IC 5.6 SP1 to Prerequisites Avaya Definity and MultiVantage Nortel Meridian Call tracking Container formats Container implementation Event reporting Multi-Site Heterogeneous Switch Switch configuration Telephony server configuration IC Database tables Avaya Definity Device assignment TS.Assign parameter Voice contact containers Events Workflow assignment Aspect CallCenter Device assignments Events Data posting to/from EDUs Workflow Data exchange with client applications External requirements Reserved subtypes Nortel Meridian and Symposium Transfer event change Party list for transfers and conferences Appendix A: Detailed changes for Avaya IC and Avaya OA from to Data model changes from to Data model changes for Avaya IC Data model changes for Avaya OA Avaya Agent IC Script changes Avaya Agent IC Scripts in IC Scripts that have been removed in Chat & IC Script changes Avaya IC workflow changes Software Upgrade and Data Migration May 2009

13 Contents Blender workflows Chat & workflow changes Analysis workflows (IC server workflows) Letter Generation workflows System workflows Routing workflow changes Voice channel flow changes channel flow changes Chat channel workflow changes RowDate data changes in Avaya OA Appendix B: Troubleshooting FixDesignFiles Index Software Upgrade and Data Migration May

14 Contents 14 Software Upgrade and Data Migration May 2009

15 Preface This section contains the following topics: Purpose on page 15 Audience on page 15 Related documents on page 16 Purpose The purpose of this guide is to provide detailed information about how to upgrade an existing Avaya IC system to the current Release 7.2 system. Audience This guide is intended primarily for those who use Avaya Interaction Center (Avaya IC). You should use this guide as an information source for: Installing all Avaya IC components. Configuring an out-of-the-box Avaya IC system for a development environment, without customizations. Software Upgrade and Data Migration May

16 Preface Related documents The following documents in the Avaya IC Release 7.2 documentation set are related to the installation and configuration of an Avaya IC system: IC Installation Planning and Prerequisites: This document provides information about the supported third-party platforms and other prerequisites required for Avaya Interaction Center, including installation information for those platforms. IC Installation Planning and Prerequisites also includes planning and deployment information for Avaya Interaction Center. OA Installation Planning and Prerequisites: This document provides information about the supported third-party platforms and other prerequisites required for Avaya Operational Analyst, including installation information for those platforms. OA Installation Planning and Prerequisites also includes planning and deployment information for Avaya Operational Analyst. IC Installation and Configuration: This document provides installation and configuration information for all Avaya Interaction Center components. OA Installation and Configuration: This document provides installation and configuration information for all Avaya Operational Analyst components. 16 Software Upgrade and Data Migration May 2009

17 Chapter 1: Differences that affect migration This section describes the differences that affect migration for the following releases: Differences between Avaya IC 7.1 and 7.2 on page 17 Differences between Avaya IC 7.0 and 7.1 on page 17 Differences between Avaya IC and 7.0 on page 18 Differences between Avaya IC 6.1.x and on page 19 Differences between Avaya IC and Avaya OA and on page 19 Differences between Avaya IC 6.0 and on page 21 Differences between Avaya IC 5.6 and 6.0 on page 21 Differences between Avaya IC 7.1 and 7.2 For the specific upgrade and migration steps, see Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 on page 23. The channel in Avaya IC 7.2 has changed at the server side because of introduction of new IC and Poller servers. The database and VESP configuration needs to be upgraded to support these new servers. For this purpose Avaya IC 7.2 introduces MigrateConfig utility to migrate VESP configuration and Migrate utility to migrate data. For migrating VESP configuration, see Migrate your Avaya IC 7.1 servers on page 40 For migrating data, see Migrate data from server on page 60 Some IC Scripts and workflow files have changed. You can find a list of changed files in Detailed changes to the IC Scripts and workflows on page 63 For details about the new requirements, see IC Installation Planning and Prerequisites. Differences between Avaya IC 7.0 and 7.1 For the specific upgrade and migration steps, see Chapter 3: Upgrading Avaya Interaction Center from 7.0 to 7.1 on page 77. Software Upgrade and Data Migration May

18 Chapter 1: Differences that affect migration The data model and functional differences between Avaya IC 7.0 and 7.1 are relatively minor. However, changes to the CRuntime and JDK versions make in-place migrations extremely time consuming because the systems must be taken down and reconfigured before the migration can begin. Therefore, Avaya recommends that you migrate to new server machines that have been properly configured for 7.1. For details about the new requirements, see IC Installation Planning and Prerequisites. Outbound Contact Management In Avaya IC 7.1, Avaya discontinued support for Outbound Contact Management. If your installation uses this feature, contact your Avaya IC support representative. Differences between Avaya IC and 7.0 For the specific upgrade and migration steps, see Chapter 4: Upgrading Avaya Interaction Center from to 7.0 on page 119. Avaya IC 7.0 includes a new agent interface called the Avaya Agent Web Client that runs from a server instead of being installed on an agent s machine. The client allows agents to handle work items for all channels from one work list, and its interface is customizable using Cascading Style Sheets (CSS), JavaScript, and XML tags. (For details, see Avaya Agent Web Client Customization.) Both the Avaya Agent Web Client and the Avaya Agent application can be used on the same agent machine in Avaya IC 7.0. For a comparison of the two interfaces, see whatsnew.pdf located on the Avaya IC CD-ROM. In order to accommodate this interface, some IC agent properties have changed with Avaya IC 7.0. For more information about the new properties, see IC Administration Volume 2: Agents, Customers, & Queues. In addition, some of the IC Script, workflow, and website files have changed. For a list of these changes, see Detailed changes to the IC Scripts, workflows, and website files on page 155. The following is a list of some of the enhancements that have been added in 7.0: A new Customer HTML chat client provides an end-user chat client that does not require a Java applet. It supports all of the functions of the current applet except for collaboration/ form filling and VOIP. The localization release of Avaya IC 7.0 will support the Russian language in all areas except spell checking, Content Analyzer, and QKnowledge. You can now transfer or conference a chat with a virtual queue as well as another agent. 18 Software Upgrade and Data Migration May 2009

19 Differences between Avaya IC 6.1.x and Avaya Business Applications In Avaya IC 7.0, Avaya discontinued support for the Business Applications. If your installation uses CallCenterQ, HRQ, or CustomerQ, you can continue to run those applications in a stand-alone environment while you set up a separate 7.0 environment for Avaya Agent and the new Avaya Agent Web Client. For details, see Considerations on page 120. Differences between Avaya IC 6.1.x and For the specific upgrade and migration steps, see Chapter 5: Upgrading Avaya Interaction Center from 6.1.x to on page 159. There are no functional or data model changes between Avaya IC releases 6.1, and 6.1.2, because added internationalization support to the 6.1 code base, and added migration tools to the 6.1 code base. Therefore, the upgrade steps are the same whether you are moving from 6.1, 6.1.1, or to Some IC Scripts, workflows, and website files have changed due to bug fixes included in You can find a list of changed files in Changes to the IC Scripts, workflows, and website files on page 168. Differences between Avaya IC and Avaya OA and For the specific upgrade and migration steps, see Chapter 6: Upgrading and migrating from to on page 175. The major changes for Avaya IC in this release are: You can use the new Business Advocate feature to make intelligent routing decisions about the contacts coming into your call center. Business Advocate can either work with or replace the Blender server. For details, see IC Business Advocate Configuration and Administration. You can now add messages to the ALM string table using Database Designer. For details, see the IC Database Designer User Guide. The channel associations for the Workflow server are now case-sensitive. When you recreate your Workflow servers, you will need to follow the new guidelines for each channel as described in IC Installation and Configuration. Software Upgrade and Data Migration May

20 Chapter 1: Differences that affect migration When you push the IC Scripts to the database, the Database Designer loads all of the QSC files from the specified directories instead of just taking the individual script files that you specify. If you want to modify an out-of-the-box IC Script file and keep both versions in the same directory, make sure you change the out-of-the-box file extension to be ".old", ".original", or anything other than ".qsc". For details, see the IC Database Designer User Guide. Some tables, keys, and fields have been added to the CallCenterQ and IC Repository databases. For a complete list of these changes, see Data model changes for Avaya IC on page 385. The major changes for Avaya OA in this release are: Enhanced reports for Business Advocate and Integrated Softdialer. New workforce management API. Support for outbound dialing performance data added several new stores (for example, for jobs and completion codes). Allowing drill down to individual logical resource managers per Advocate service class required addition of ResourceMgrID as a primary key component in existing service class performance tables. Changes in subsystem administration to ensure historical uniqueness of source subsystem identifiers affected some administration tables. Normalization of Avaya OA and Avaya IC data received from multiple real time subsystems required consolidation of data from different Avaya IC source subsystems into a single database record identified by a SourceID of zero. This also affects the rules stored in some internal tables used by aggregation. Avaya OA and Avaya CMS data is unaffected and non-zero SourceIDs continue to distinguish different ACDs. Time stamping of historical data by a single date-time column, for ease of use by third party tools such as Cognos, resulted in addition of the IntervalStart column in Avaya OA and Avaya IC data. (Avaya OA and Avaya CMS stores are not affected.) Avoiding the Oracle NVARCHAR2 data type in historical data for compatibility with Cognos reporting tools required conversion to VARCHAR2 for Oracle databases (SQL Server databases continue to use both VARCHAR and NVARCHAR and are unaffected). Full national character support is retained since the Oracle VARCHAR2 may contain UTF-8 characters. Daily, weekly and monthly archives now use an administrable Archive Time Zone rather than UTC. Depending upon the existing 6.0 configuration, some customers will require a RowDate migration to accomplish this conversion. Defining historical container membership by workgroups rather than by agents, and removing Avaya IC source subsystem as an administrable container dimension required changes to existing administration tables and an additional table to access 6.0 containers as well as the new 6.1 containers. The following changes to containers: 20 Software Upgrade and Data Migration May 2009

21 Differences between Avaya IC 6.0 and The containers are permanently inactive following migration to To continue aggregating data, new containers must be defined using the Avaya OA Administration client interface. - All enabled Avaya IC containers will be retired (disabled) after the upgrade. You will be able to view the containers, but you will not be able to add any new data or change the tables. - The disabled containers will appear in the historical Basic report input page 1. For each disabled container, an ampersand character (&) appears next to the container name. This is how user can distinguish the active containers from disabled containers. - If there were any administratively disabled containers in the system prior to the migration, those containers will also appear with the ampersand character (&). Updates to the Avaya OA data model. For a detailed description of the data model differences, see Data model changes for Avaya OA on page 389. Differences between Avaya IC 6.0 and For the specific migration steps, see Upgrading Avaya Interaction Center from 6.0 to on page 293. The major changes in this release are: Changes to the IC Scripts and workflows as a result of bug fixes. Changes to the Web Management website files. Changes to Avaya Agent as a result of the IC Script and workflow changes. Content Analyzer now supports Dutch, Italian, Portuguese, Korean, and Simplified Chinese. Differences between Avaya IC 5.6 and 6.0 For the specific migration steps, see Migrating from Avaya IC 5.6 SP1 to on page 299. The major changes in this release are: Introduction of Avaya Outbound Contact Management, a tool for creating and managing outbound calling lists. Introduction of Avaya Content Analyzer, a tool for automatically parsing and responding to customer s in 5 languages (English, French, German Spanish, Japanese). RDBMS update to MS SQL Server Software Upgrade and Data Migration May

22 Chapter 1: Differences that affect migration For Oracle databases, the Character Set and National Character Set parameters must now be set to UTF8. Data type changes to support internationalization requirements. Schema changes in the qrepository database. Schema changes in the ccq database to support and Chat changes. 22 Software Upgrade and Data Migration May 2009

23 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 This chapter contains information that helps you upgrade from Avaya Interaction Center (Avaya IC) 7.1 to release 7.2. If you are starting from an earlier release, you must first upgrade to 7.1. For details, see the appropriate chapter in this manual. This section includes the following topics: Considerations on page 24 Prerequisites on page 25 Shut down 7.1 on page 29 Install Avaya IC 7.2 on page 30 Prepare the new administration machine for migration on page 31 Upgrade customized IC Scripts and workflows on page 33 Copy customized website, Avaya Agent layouts, and EDU Viewer stylesheets on page 33 Migrate your ADL files on page 34 Migrate your Avaya IC 7.1 servers on page 40 Start the 7.2 core servers on page 46 Reconfigure your 7.2 databases on page 47 Generate your applications on page 50 Upgrade the 7.1 data to 7.2 on page 51 Load the new workflows on page 52 Migrate your server settings into 7.2 on page 52 Update server and agent properties on page 54 Migrate your Content Analyzer data on page 58 Migrate data from server on page 60 Migrate WAS to Tomcat on page 61 Migrate SDK on page 61 Install and Configure WebLM on page 62 Start Avaya IC 7.2 on page 62 Uninstall 7.1 Avaya Agent applications on page 63 Detailed changes to the IC Scripts and workflows on page 63 Software Upgrade and Data Migration May

24 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 Migrating Operational Analyst 7.1 to 7.2 on page 73 Considerations Qui Applications not supported: In this release of Avaya IC, Qui Applications are no longer supported, hence customized forms and focusses will not work and has to be created again. IC See Migrate data from server on page 60, before starting migration for Avaya IC 7.2. Migration from WAS to Tomcat: See Migrate WAS to Tomcat on page 61, before starting migration for Avaya IC 7.2. Platform changes: In this release of Avaya IC, changes to the CRuntime and JDK versions make in-place migrations extremely time consuming because the systems must be taken down and reconfigured before the migration can begin. Therefore, Avaya recommends that you migrate to new server machines that have been properly configured for 7.2. For details, see IC Installation Planning and Prerequisites. Avaya Operational Analyst: For details about upgrading Avaya OA 7.2, see Avaya Operational Analyst Installation and Configuration. Localization: If you are using a localized version of Avaya IC 7.1, you need to migrate to the localized version of Avaya IC 7.2. You cannot migrate a localized 7.1 system to a non-localized 7.2 system. To determine whether you have the localized version of 7.2, see the Readme.pdf file on the core Avaya IC CD-ROM. Siebel: For details about upgrading Siebel, see Avaya IC for Siebel Integration. 24 Software Upgrade and Data Migration May 2009

25 Prerequisites Prerequisites Before you begin the migration process: Avaya recommends that you make a backup copy of: - The entire IC71_INSTALL_DIR\IC71\design directory and its subdirectories from the IC71 Design Admin machine - The IC71_INSTALL_DIR\IC71\etc directory from the IC server machine containing vesp.imp & ds.ffd files - Your 7.1 databases, including those for Business Advocate if your site uses that product Verify that servers you are migrating to meet all the requirements for Avaya IC 7.2. For more information about prerequisites for Avaya IC 7.2, see IC Installation Planning and Prerequisites. Prerequisites for migrating Content Analyzer Before you migrate your 7.1 system, you should make detailed notes about your Content Analyzer system, as described in the sections below. With this information, you can: Verify that all of your Content Analyzer data migrated properly Restore all of the settings for your Content Analyzer CAServer and CAAdmin servers For details about Content Analyzer and the Content Analyzer servers, see IC Administration Volume 1: Servers & Domains. If at all possible, you should configure your 7.2 Content Analyzer servers so that they have the same relative path to the Content Analyzer Knowledge Bases as the 7.1 servers did. For example, if the fully-qualified path from your current 7.1 servers to your Knowledge Bases is X:\Avaya\KBs\, then you should make sure that your 7.2 servers use the same path. If your 7.2 servers can use the same relative path to the Knowledge Bases, then all of your Content Analyzer database data will be migrated automatically when you perform the standard migration steps described in this chapter. The only Content Analyzer-specific migration step you need to take is to recreate your 7.1 Content Analyzer servers in your 7.2 environment. If you have to change the relative location of your Knowledge Bases to your Content Analyzer servers, you will also need to perform the migration steps in Migrate your Content Analyzer data on page 58. In order to verify Content Analyzer data migration, you need to record information about your 7.1 Content Analyzer environment, as described in the following sections: Determining the current Content Analyzer data Software Upgrade and Data Migration May

26 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 Determining the current Content Analyzer server settings Determining the training and validation information for your Knowledge Bases Determining the current Content Analyzer data To find out what Content Analyzer data is currently stored in your Avaya IC system: 1. In IC Manager, select Tools > Content Analysis. 2. To get a list of all the Knowledge Bases in your system, select KB Management in the left-hand pane and make a note of the information in the File Path column for each Knowledge Base that appears in the right-hand pane. Tip: The File Path column shows the relative path to the Knowledge Base, not the exact machine on which that Knowledge Base is located. Make sure you contact your Content Analyzer Administrator for the specific machines and directories where the Knowledge Base files are located. 3. To get a list of all the topic trees in your system, select Topic Tree Management in the left-hand pane. Make a note of all the topic trees and their topics. Tip: An easy way to do this is to expand all of the topic trees and then take one or more screenshots of the resulting data. If you have a large number of topic trees, you may want to expand each one individually and take one screenshot per tree. 4. To get a list of all the sample sets in your system: a. Select Sample Management in the left-hand pane. b. Select the Remove Samples tab in the right-hand pane. c. Open the Sample Set drop down list and make a note of the sample sets. Determining the current Content Analyzer server settings To determine your Content Analyzer server settings: 1. In IC Manager, select the Server tab and then select All Domains in the left-hand pane. 2. For each Avaya IC server of type CAAdmin: a. Right click on that server and select Edit from the pop-up menu. IC Manager displays the Server Editor dialog box for that server. b. Take a screenshot of each tab in the Server Editor dialog box, making sure that you take special note of the Name on the General tab, the system on which this server was configured, and the setting for Path to NLP Data on the CAAdmin tab. c. Select OK or Cancel to close the Server Editor dialog box. 26 Software Upgrade and Data Migration May 2009

27 Prerequisites d. Repeat steps a through c for the next CAAdmin server. 3. For each Avaya IC server of type CAServer: a. Right click on that server and select Edit from the pop-up menu. IC Manager displays the Server Editor dialog box for that server. b. Take a screenshot of each tab in the Server Editor dialog box, making sure that you take special note of the Name on the General tab, the system on which this server was configured, and the setting for Path to NLP Data on the CAServer tab. c. On the CAServer tab, select the Knowledge Base button and, for each associated Knowledge Base: 1. Record the Name, KB File Location, and Threshold values. 2. Click on under the Languages column and note all of the languages that are associated with this Knowledge Base. 3. Select OK or Cancel to close the Knowledge Base dialog box. d. Select OK or Cancel to close the Server Editor dialog box. e. Repeat steps a through d for the next CAServer server. 4. When you have finished recording the details for all of your CAAdmin and CAServer servers, you can close IC Manager. Determining the training and validation information for your Knowledge Bases To view the training and validation information about your existing Knowledge Bases (such as the topic tree associated with the Knowledge Base, the sample set used in training or validation, and the date/time of any training or validation sessions), you can run a SQL query on your 7.1 SQL Server database, or a SQL Plus query on your 7.1 Oracle database. Both queries are shown below. Tip: Tip: If you saved the results of previous training and validation sessions, make sure that you know where those files are located so that you can compare them to your migrated 7.2 system. Software Upgrade and Data Migration May

28 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 For a SQL Server database, run the following SQL query: USE ccq SELECT kb.name "KBName", kb.kbfilepath "KBFilePath", ss.name "SampleSet", ct.name "Topic Tree", sskb.intent "Train:0; Validate:1", sskb.dateperformed "Date Performed" FROM knowledgebase kb, sampleset ss, samplesetknowledge sskb, contenttree ct WHERE kb.pkey = sskb.knowledgebase_key AND sskb.sampleset_key = ss.pkey AND ss.contenttree_key = ct.pkey ORDER BY sskb.intent ASC, sskb.dateperformed DESC A screenshot showing an example of this query is shown below. In this example, each of the three Knowledge Bases went through one training session and one validation session. The sample set used for each training and validation session is shown in the SampleSet column. 28 Software Upgrade and Data Migration May 2009

29 Shut down 7.1 For an Oracle database, run the following SQL script: SET LINESIZE 180; COLUMN "KB Name" FORMAT A15; COLUMN "File Path" FORMAT A30; COLUMN "Topic Tree" FORMAT A15; COLUMN "Sample Set" FORMAT A20; COLUMN "Date Performed" FORMAT A30; SELECT kb.name AS "KB Name", kb.kbfilepath AS "File Path", ct.name AS "Topic Tree", ss.name AS "Sample Set", sskb.intent AS "Intent 0 or 1", sskb.dateperformed AS "Date Performed" FROM ccq.knowledgebase kb, ccq.sampleset ss, ccq.samplesetknowledge sskb, ccq.contenttree ct WHERE kb.pkey = sskb.knowledgebase_key AND sskb.sampleset_key = ss.pkey AND ss.contenttree_key = ct.pkey ORDER BY sskb.intent ASC, sskb.dateperformed DESC; For a DB2 database, run the following SQL script: SELECT kb.name, kb.kbfilepath, ct.name, ss.name, sskb.intent, sskb.dateperformed FROM ccq.knowledgebase kb, ccq.sampleset ss, ccq.samplesetknowledge sskb, ccq.contenttree ct WHERE kb.pkey = sskb.knowledgebase_key AND sskb.sampleset_key = ss.pkey AND ss.contenttree_key = ct.pkey ORDER BY sskb.intent ASC, sskb.dateperformed DESC Shut down 7.1 After you have verified that your customized IC Scripts, workflows, website files, and EDU Viewer stylesheets work in your 7.2 test system, as described in Upgrade customized IC Scripts and workflows on page 33, you can begin migrating your 7.1 servers and Avaya Agent applications. In order to do so, Avaya IC 7.1 must be shut down and the system will not be available to agents until the migration process is complete. Software Upgrade and Data Migration May

30 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 To shut down 7.1: 1. Stop all Avaya Agent applications. 2. Stop all Avaya IC servers: a. Go to the server machine running the Primary ORB server. b. For Windows, open a command prompt, navigate to IC71_INSTALL_DIR\IC71\ bin, and run icadmin tva <Username> <PW>. c. For Solaris or AIX, navigate to IC71_INSTALL_DIR/IC71/bin and run./icadmin tva <Username> <PW>. d. Make sure that you wait until all Avaya IC servers have been shut down. 3. Stop and disable all the Avaya IC Website servers and services, including the Avaya IC CIRS Service, Avaya IC ICM Service, Avaya IC ORB Service, Avaya IC Web Management Service, Avaya IC WebLM Service, and Avaya Voice Media Manager. For details, see IC Installation and Configuration. 4. If your site uses Business Advocate, stop all Business Advocate services. Install Avaya IC 7.2 Before you begin the migration process, you need to install the Avaya IC 7.2 servers, the administration and design tools, and the license file on a set of new machines that meet the platform requirements for 7.2. For details about these platform requirements, see IC Installation Planning and Prerequisites. To install 7.2, follow the steps in IC Installation and Configuration and: Important: Install the 7.2 core servers on dedicated server machines. During the migration process, you will be migrating all your 7.1 server settings, so you do not need to duplicate that information now. Just install 7.2 with the minimum information needed for each of the core servers.! Important: When IC Installation and Configuration instructs you to run the Configuration Tool and fill out the Initial Configuration tab, ensure that you use the same ORB server port number that you used in 7.1. Otherwise, your 7.2 agent clients will not connect correctly. You will need to delete data from some tables if you have changed the host name of the machine that was running the Business Advocate in IC 7.1. For more information see BA configuration on page 56 Install the 7.2 administration and design tools on a dedicated administration machine. Install the new license file. 30 Software Upgrade and Data Migration May 2009

31 Prepare the new administration machine for migration Shutdown Avaya IC 7.2 servers & services after completing initial configuration on all server machines. Do not start 7.2 servers until after you have migrated your 7.1 server settings. After you have installed the software, look at the Patches directory on the 7.2 installation CD-ROM. If there are any patches in that directory, apply them as described in the associated patch Readme file. Install the 7.2 Avaya Agent applications You should never run 7.2 Avaya Agent applications with Avaya IC 7.1 servers. However, you can install the 7.2 agent applications on the same machines as your 7.1 agent applications without affecting the operation of 7.1. As long as you specify the same ORB server port number in 7.2 that you used in 7.1, the 7.2 agent applications will work with your migrated system without further alteration. Therefore, you can install the 7.2 agent applications in parallel with the rest of the migration procedure so that your agent machines will be ready once the migration is complete. Tip: Tip: When you have finished installing the 7.2 Avaya Agent, make sure the agents know that they should continue to use their old shortcut to log into the 7.1 system until further notice. After the migration is complete, they can being using their 7.2 shortcut immediately. For details about installing the 7.2 Avaya Agent application, see IC Installation and Configuration. Prepare the new administration machine for migration On the new 7.2 administration machine: 1. Avaya recommends that you make a backup copy of the entire: IC72_INSTALL_DIR\IC72\design directory and its subdirectories IC72_INSTALL_DIR\IC72\etc directory 2. Create a migration directory that you can use to store the original 7.1 design files and their migrated counterparts. The examples in this section use the directory IC72_INSTALL_DIR\IC71-migration. 3. Under this migration directory, create the following subdirectories: design\custom-71-files Software Upgrade and Data Migration May

32 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 design\oob-71-files design\new-72-files etc 4. Copy the following files from the old 7.1 administration machine: Source Directory on 7.1 Administration machine Files to copy Destination Directory on 7.2 Administration machine IC71_INSTALL_DIR\IC71\ design\callcenterq IC71_INSTALL_DIR\IC71\ design\repository IC71_INSTALL_DIR\IC71\etc from the IC server machine running the Directory Server ccq.adc ccq.adf ccq.adl ccq.alm repository.adc repository.adf repository.adl repository.alm ds.ffd vesp.imp IC72_INSTALL_DIR\ IC71-migration\design\ custom-71-files IC72_INSTALL_DIR\ IC71-migration\design\ custom-71-files IC72_INSTALL_DIR\ IC71-migration\etc 5. For your convenience, the 7.1 out-of-the-box ADL files are installed with 7.2. To migrate your customized ADL files, you need to copy the out-of-the-box ADL files into the migration folder and rename them as shown: Source File IC72_INSTALL_DIR\IC72\design\ CallCenterQ\ccq_71.adl IC72_INSTALL_DIR\IC72\design\ CallCenterQ\ccq.adc IC72_INSTALL_DIR\IC72\design\ repository\repository_71.adl IC72_INSTALL_DIR\IC72\design\ repository\repository.adc Copy and Rename As IC72_INSTALL_DIR\IC71-migration\ design\oob-71-files\ccq.adl IC72_INSTALL_DIR\IC71-migration\ design\oob-71-files\ccq.adc IC72_INSTALL_DIR\IC71-migration\ design\oob-71-files\repository.adl IC72_INSTALL_DIR\IC71-migration\ design\oob-71-files\repository.adc Important:! Important: You must rename the out-of-the-box files as ccq.adl and repository.adl or the ADL migration procedure will not work. 32 Software Upgrade and Data Migration May 2009

33 Upgrade customized IC Scripts and workflows Upgrade customized IC Scripts and workflows Your customized 7.1 IC Scripts and workflows will continue to work in 7.2. However, Avaya recommends that you reapply your customizations to the out-of-the-box files in order to take advantage of the bug fixes included in 7.2. You can find a list of changed files in IC Script changes on page 64 and Workflow changes on page 72. In order to minimize the amount of time that your production system will be shut down, Avaya recommends that you install an out-of-the-box version of 7.2 and use that to test your customized IC Scripts and workflows. To upgrade your IC Script and workflow files: 1. Set up an out-of-the-box 7.2 test system. 2. Merge your customizations with the out-of-the-box IC Script and workflow files that have changed since 7.1. For the names of the changed files, see Detailed changes to the IC Scripts and workflows on page Copy all customized IC Script and workflow files into your 7.2 test system. 4. Verify that all your customized files work the way you expect. 5. When you are sure that everything is working, copy your verified IC Script and workflow files to the appropriate 7.2 directories. The directory structure between 7.1 and 7.2 has not changed, so you can copy these files from where they exist in 7.1 to the equivalent directory in 7.2 Copy customized website, Avaya Agent layouts, and EDU Viewer stylesheets Avaya IC 7.2 introduces WACD redunduncy. The following file is enhanced for WACD Redundancy: IC72\comp\icws\acd\admin\servmgmt.html If you have customized this file, you need to manually re-customize this file from the IC7.2 setup. For Customized Website files: 1. Backup and move your existing IC71_Install_Dir\comp\website folder to some other location. 2. Create Diff files for the customized 7.1 files and the files shipped with Avaya IC 7.2. Software Upgrade and Data Migration May

34 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to Then based on the diff, re-apply the customized changes to the files shipped with IC7.2 in the IC72_Install_Dir\comp\website folder. 4. Repeat steps 2 and 3 for all the customized files. For *.CDL files: 1. Edit the.cdl file that you copied from IC71_INSTALL_DIR\IC71\design\ QConsole\ to IC72_INSTALL_DIR\IC72\design\QConsole. Find all instances of 7.1 and replace with 7.2 Find all instances of.71 and replace with.72 Find all instances of Ctrl71 with Ctrl72 2. Save the file. Do not delete existing files in IC72_INSTALL_DIR\IC72\ before you copy files from IC71_INSTALL_DIR\IC71\to the IC72_INSTALL_DIR\IC72\ folder. Migrate your ADL files Database Designer includes a Database Migration tool that you can use to merge the customizations in your existing CallCenterQ and Repository ADL and ADF files with the updated ADL and ADF files in release 7.2 of Avaya IC. This section includes the following topics: Actions performed by Database Migration tool on page 35 Prerequisites on page 36 Migrate ccq.adl on page 36 Migrate repository.adl on page 38 Move the migrated files to 7.2 on page Software Upgrade and Data Migration May 2009

35 Migrate your ADL files Actions performed by Database Migration tool The following table describes the action performed by the Database Migration tool during the comparison of the ADL files. Source out-of-the-box 7.1 ADL file Source Customized ADL file New out-of-the-box 7.2 ADL file Action performed Component does not exist Component does not exist Component does not exist Component exists Component exists Component does not exist Component exists Component exists Component does not exist Adds component to the new customized ADL file. Adds component to the new customized ADL file. Component exists Component exists Asks you to select one of the existing components to add to the new customized ADL file. Component does not exist Component does not exist Component does not exist Component exists Component exists Component exists Component does not exist Does not copy the component to the new customized ADL file. Adds the component to the new customized ADL file and advises you that you need to manually remove this component if desired. Advises you that the customized component was added to the new customized ADL file. Component exists Component exists Component exists Asks you to select one of the components to add to the new customized ADL file. Form exists Form does not exist Form does not exist Does not copy the form to the new customized ADL file. Form exists Form does not exist Form exists Does not copy the form to the new customized ADL file. Form exists/form does not exist Form exists Form does not exist Adds the form from customized ADL file to the new customized ADL file. Also adds a message to the log file. Software Upgrade and Data Migration May

36 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 Source out-of-the-box 7.1 ADL file Source Customized ADL file New out-of-the-box 7.2 ADL file Action performed Form exists/form does not exist Form exists Form Exists Adds the form from customized ADL file to the new customized ADL file. Form does not exist Form does not exist Form exists Adds the form to the new customized ADL file. Also adds a message to the log file. For all versions of Avaya IC, you need to migrate ccq.adl and repository.adl. Prerequisites The ADL migration tool can only save the new ADL file using the same fully-qualified filename as the original ADL file. Therefore, you have to save the migrated ADL file to the output directory you created in Prepare the new administration machine for migration on page 31. These examples use the directory: IC72_INSTALL_DIR\IC71-migration\design\new-72-files After the ADL migration tool is finished, you can then copy the files from the design\ new-72-files directory to the appropriate IC72_INSTALL_DIR\IC72\design directory, overwriting the out-of-the-box files. Migrate ccq.adl To migrate your ccq.adl file, on the new 7.2 administration machine: 1. Open the 7.2 Database Designer, but do not open an ADL file in Database Designer. Important:! Important: The Database Migration tool will not start if you have an ADL file open in Database Designer. You must close all ADL files before you attempt to migrate customized ADL files. 36 Software Upgrade and Data Migration May 2009

37 Migrate your ADL files 2. Click Tools > Database Migration. Database Designer displays the Choose ADL Files dialog box: 3. In the Choose ADL Files dialog box: a. Click the Ellipsis ( ) button next to the Source out-of-the-box ADL file field and navigate to the directory containing the out-of-the-box 7.1 ccq.adl file. (Default location: IC72_INSTALL_DIR\IC71-migration\design\oob-71-files.) Select the ccq.adl file and click Open. Tip: Important: Tip: You can also cut and paste the fully-qualified directory name into all the fields in this dialog box. b. Click the Ellipsis ( ) button next to the Source customized ADL file field and navigate to the directory containing the customized 7.1 ccq.adl file. (Default location: IC72_INSTALL_DIR\IC71-migration\design\custom-71-files.) Select the ccq.adl file and click Open. c. Click the Ellipsis ( ) button next to the New out-of-the-box ADL file field and navigate to the directory containing the out-of-the-box 7.2 ADL file. (Default location: IC72_INSTALL_DIR\IC72\design\CallCenterQ.) Select the ccq.adl file and click Open. d. Click the Ellipsis ( ) button next to the New customized ADL file field and navigate to the directory where you want the Database Migration tool to save the migrated ADL file. (Default location: IC72_INSTALL_DIR\IC71-migration\design\ new-72-files.) Click OK and then add the filename ccq.adl to the end of that path.! Important: You must use ccq.adl as the name of the ADL file. e. Click OK. Software Upgrade and Data Migration May

38 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to As the Database Migration tool compares the ADL files, review and respond to all information messages. (For more information about why the Database Migration tool prompts you for a decision, see Migrate your ADL files on page 34.) When the Database Migration tool finishes, it writes the migrated ADL and ADF files, and the out-of-the-box 7.2 ADC file, to the specified output directory. 5. After the Database Migration tool has merged the ADL files: a. Review the ccq.txt log file in the output directory for details about the ADL file migration. b. Open the new customized ADL file in Database Designer and verify that your customizations were properly migrated. Migrate repository.adl To migrate your repository.adl file: 1. Open Database Designer, but do not open an ADL file in Database Designer. Important: Tip:! Important: The Database Migration tool will not start if you have an ADL file open in Database Designer. You must close all ADL files before you attempt to migrate customized ADL files. 2. Click Tools > Database Migration. 3. In the Choose ADL Files dialog box: a. Click the Ellipsis ( ) button next to the Source out-of-the-box ADL file field and navigate to the directory containing the out-of-the-box 7.1 repository.adl file. (Default location: IC72_INSTALL_DIR\IC71-migration\design\ oob-71-files.) Select the repository.adl file and click Open. Tip: You can also cut and paste the fully-qualified directory name into all the fields in this dialog box. b. Click the Ellipsis ( ) button next to the Source customized ADL file field and navigate to the directory containing the customized 7.1 repository.adl file. (Default location: IC72_INSTALL_DIR\IC71-migration\design\ custom-71-files.) Select the repository.adl file and click Open. c. Click the Ellipsis ( ) button next to the New out-of-the-box ADL file field and navigate to the directory containing the out-of-the-box 7.2 ADL file. (Default location: IC72_INSTALL_DIR\IC72\design\repository.) Select the repository.adl file and click Open. 38 Software Upgrade and Data Migration May 2009

39 Migrate your ADL files d. Click the Ellipsis ( ) button next to the New customized ADL file field and navigate to the directory where you want the Database Migration tool to save the migrated ADL file. (Default location: IC72_INSTALL_DIR\IC71-migration\design\ new-72-files.) Click OK and then add the filename repository.adl to the end of that path. Important:! Important: You must use repository.adl as the name of the ADL file. e. Click OK. 4. As the Database Migration tool compares the ADL files, review and respond to all information messages. (For more information about why the Database Migration tool prompts you for a decision, see Migrate your ADL files on page 34.) When the Database Migration tool finishes, it writes the migrated ADL and ADF files, and the out-of-the-box 7.2 ADC file, to the specified output directory. 5. After the Database Migration tool has merged the ADL files: a. Review the repository.txt log file in the output directory for details about the ADL file migration. b. Open the new customized ADL file in Database Designer and verify that your customizations were properly migrated. Move the migrated files to 7.2 Once you have successfully migrated your ADL files, you need to move them, along with the ADF and ADC files, to the 7.2 design directories, as shown below: Move... IC72_INSTALL_DIR\IC71-migration\ design\new-72-files\ccq.* IC72_INSTALL_DIR\IC71-migration\ design\custom-71-files\ccq.adc and ccq.alm IC72_INSTALL_DIR\IC71-migration\ design\new-72-files\repository.* IC72_INSTALL_DIR\IC71-migration\ design\custom-71-files\ repository.adc and repository.alm To... IC72_INSTALL_DIR\IC72\design\ CallCenterQ IC72_INSTALL_DIR\IC72\design\ CallCenterQ IC72_INSTALL_DIR\IC72\design\ repository IC72_INSTALL_DIR\IC72\design\ repository Software Upgrade and Data Migration May

40 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 Migrate your Avaya IC 7.1 servers The channel in Avaya IC 7.2 has changed at the server side because of introduction of new IC and Poller servers. The database and VESP configuration needs to be upgraded to support these new servers. For this purpose Avaya IC 7.2 introduces MigrateConfig utility to migrate VESP configuration and Migrate utility to migrate data. For migrating data, see Migrate data from server on page 60 Prerequisites for Migration: Install.NET framework 2.0 on Windows computer Install Avaya IC 7.2 design and Admin Ensure no IC server is running To migrate your servers to 7.2: 1. Copy the ds.ffd and vesp.imp files from IC71_INSTALL_DIR\IC71\etc on the primary 7.1 server machine to IC72_INSTALL_DIR\IC72\etc on the new 7.2 administration machine, overwriting the existing 7.2 files. If you are copying the files via FTP, make sure that you transfer them in ASCII mode. Keep a copy of the ds.ffd and vesp.imp files in IC71_INSTALL_DIR\ IC71\etc folder. 2. Launch the migrateconfig.exe. The following window appears. 40 Software Upgrade and Data Migration May 2009

41 Migrate your Avaya IC 7.1 servers The migrateconfig utility is delivered with the Design and Admin installer. The migrateconfig utility uses.net 2.0. As AIX and Solaris do not support.net applications this utility can be used only on Windows. 3. Click Next. 4. Choose a location of VESP.IMP and DS.FFD files. 5. Select the Create backup files and Add dynamic logging info check boxes. Software Upgrade and Data Migration May

42 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to Select Trace from the Log Level drop-down list. 7. Click Next. The MigrateConfig utility loads vesp.imp and ds.ffd files in memory. 8. Click Save Log to save the text output. The log is created in the same directory where the migrateconfig.exe file is located. 42 Software Upgrade and Data Migration May 2009

43 Migrate your Avaya IC 7.1 servers 9. Click Next. The IP address information appears. The IP address information displays the existing IP addresses that are available in the vesp.imp and ds.ffd files. Green color indicates that you have not changed the IP addresses yet. 10. If you change the computers IP address while upgrading to Avaya IC 7.2, click the IP address that you have changed. 11. Enter the new IP address in New IP address field. If you want to change all IP addresses displayed in the window, select the Change All IP s to this value check box. Software Upgrade and Data Migration May

44 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to Click Apply. Red color indicates the IP address you have changed. 13. Click Next. The Path Information appears. 14. You can change the installation path in the vesp.imp and ds.ffd files in bulk if you have installed Avaya IC 7.2 on the same computer as IC 7.1, but the path is changed from d:/ Avaya/IC71 to d:/avaya/ic Software Upgrade and Data Migration May 2009

45 Migrate your Avaya IC 7.1 servers 15. Enter the new path in New Path field. If you want to change all paths displayed in the window, select the Change all paths to this value check box. 16. Click Apply. Pink color indicates the path that is not common and is outside the IC home. You can change the working directory and the server path. 17. Enter the new server path in Server New field and enter the new home path in the Home New field. Software Upgrade and Data Migration May

46 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to Click Finish to apply the changes. The Operation progress window appears. 19. Click Save Log to save the text output. The log is created in the same directory where the migrateconfig.exe file is located. Start the 7.2 core servers To complete the server migration process: 1. Copy the new vesp.imp and ds.ffd files in IC72_INSTALL_DIR\IC72\etc to all server machines that are running a Directory server, overwriting any existing files. If you are copying the files via FTP, make sure that you transfer them in ASCII mode. 2. Copy the new vesp.imp file in IC72_INSTALL_DIR\IC72\etc to all other server machines, overwriting any existing files. If you are copying the file via FTP, make sure that you transfer it in ASCII mode. 3. Start the Avaya IC 7.2 core servers using the icadmin so command on the primary server machine. You can either run icadmin so from the command line of the server s host machine, or you can run icadmin so <hostname> if your host has multiple network interface cards. For details, see IC Administration Volume 1: Servers & Domains. 4. If the servers start, continue with Shut down 7.1 on page 29. If the icadmin command encounters errors, see Troubleshooting on page Software Upgrade and Data Migration May 2009

47 Reconfigure your 7.2 databases Troubleshooting If the 7.2 servers do not start after migration, verify that: The 7.2 paths you specified are correct relative to the server machine on which the ds.ffd file resides. If you find a path problem, rerun MigrateConfig, specifying the new path. All servers have a valid path to their executable file defined in the 7.1 IC Manager. If you find a problem, either fix the path or delete that server from IC Manager and click Manager > Refresh. Then copy the updated ds.ffd file to the administration machine and rerun MigrateConfig. Reconfigure your 7.2 databases In order to migrate your 7.1 databases to 7.2, you need to reconfigure them. In order to do so, you will need an IC Manager login and password for an account with Administrator authority. All configurations of Avaya IC require you to upgrade your IC Repository and CallCenterQ database. For details, see Reconfigure the IC Repository database on page 47 and Reconfigure the CallCenterQ database on page 49. Reconfigure the IC Repository database If you need to determine how many rows of data are in your IC Repository database, you can use the following SQL statements to get a record count: : select count(*) from agentsegment select count(*) from routingevent select count(*) from mediainteraction select count(*) from contact select count(*) from mediasegment To reconfigure your 7.1 IC Repository database for 7.2: 1. Start the 7.2 Database Designer and open IC72_INSTALL_DIR\IC72\design\ repository\repository.adl. Tip: Tip: If you are using a localized Avaya IC environment, you will need to enable your 7.2 Database Designer to handle the localized files. For details, see the IC Database Designer User Guide. Software Upgrade and Data Migration May

48 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to On the Properties tab in the right-hand pane, make sure that the IC72_INSTALL_DIR\ design and IC72_INSTALL_DIR\IC72\design\QConsole directories are displayed in the Upload scripts from these directories box. If not, add them so that all the required IC Scripts will be pushed to the database. 3. Expand Components > Physical DB Connections and click repositorydbconnection in the tree pane. 4. Verify that the connection information is correct. For details, see IC Installation and Configuration. The Database Name and Database Server should point to your 7.2 database. 5. If your database has less than 3 million rows and you are going to reconfigure it in Database Designer: a. Make a note of the current Timeout parameter so that you can reset it after the reconfigure. b. Set the Timeout parameter to at least 7200 seconds. 6. Save the ADL file using File > Save. 7. Click File > Database Administration. 8. Click the Reconfigure option button. 9. Enable the Recreate Stored Procedures check box to update the database with the 7.2 database schema. 10. If necessary, enter your IC Manager Administrator username and password in the appropriate fields. (Do not enter your DBA username and password.) 11. If your database has over 3 million rows or you want to test this procedure, click Test. Instead of reconfiguring the database, Database Designer lists all the SQL statements needed to reconfigure the database in the Status Messages section. You can cut and paste the statements into an ASCII text editor, modify the SQL statements as needed, and run the modified statements against the IC Repository database using your database administration tools. (For details, see the IC Database Designer User Guide.) Otherwise, click OK. Database Designer reconfigures the database. CAUTION:! CAUTION: If the reconfigure reports any errors, such as a mttbinary: :timeout execute error, it is possible that the data has not been properly migrated and you will need to restore the database from a backup. Tip: Tip: Avaya recommends that you save the reconfigure SQL. 12. When Database Designer is finished, click Close. 48 Software Upgrade and Data Migration May 2009

49 Reconfigure your 7.2 databases 13. If you increased the Timeout parameter in step 5, reset it to its previous value. 14. Save and close the ADL file. 15. If you clicked Test in step 11, modify the generated SQL statements and apply them to the IC Repository database using your database administration tools. Reconfigure the CallCenterQ database If you need to determine how many rows of data are in your CallCenterQ database, you can use the following SQL statements to get a record count: Select count (*) from qem_message Select count (*) from qem_messagestatlog Select count (*) from w_chat_transcript In addition, if your CallCenterQ database is on Oracle, you should include the following command: Select count (*) from qw_text To reconfigure your 7.1 CallCenterQ database for 7.2: 1. Open IC72_INSTALL_DIR\IC72\design\CallCenterQ\ccq.adl in Database Designer. 2. On the Properties tab in the right-hand pane, make sure that the IC72_INSTALL_DIR\ IC72\design\common and IC72_INSTALL_DIR\IC72\design\QConsole directories are displayed in the Upload scripts from these directories box. If not, add them so that all the required IC Scripts will be pushed to the database. 3. Expand Components > Physical DB Connections and click ccqconnection in the tree pane. 4. Verify that the connection information is correct. For details, see IC Installation and Configuration. The Database Name and Database Server should point to your 7.1 database. 5. If your database has less than 3 million rows and you are going to reconfigure it in Database Designer: a. Make a note of the current Timeout parameter so that you can reset it after the reconfigure. b. Set the Timeout parameter to at least 7200 seconds. 6. Save the ADL file using File > Save. 7. Click File > Database Administration. 8. Click the Reconfigure option button. Software Upgrade and Data Migration May

50 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to Enable the Recreate Stored Procedures check box to update the database with the 7.2 database schema. 10. If necessary, enter your IC Manager Administrator username and password in the appropriate fields. (Do not enter your DBA username and password.) 11. If your database has over 3 million rows or you want to test this procedure, click Test. Instead of reconfiguring the database, Database Designer lists all the SQL statements needed to reconfigure the database in the Status Messages section. You can cut and paste the statements into an ASCII text editor, modify the SQL statements as needed, and run the modified statements against the CallCenterQ database using your database administration tools. (For details, see the IC Database Designer User Guide.) Otherwise, click OK. Database Designer reconfigures the database. CAUTION:! CAUTION: If the reconfigure reports any errors, such as a mttbinary: :timeout execute error, it is possible that the data has not been properly migrated and you will need to restore the database from a backup. Tip: Tip: Avaya recommends that you save the reconfigure SQL. 12. When Database Designer is finished, click Close. 13. If you increased the Timeout parameter in step 5, reset it to its previous value. 14. Save and close the ADL file. 15. If you clicked Test in step 11, modify the generated SQL statements and apply them to the CallCenterQ database using your database administration tools. Generate your applications! CAUTION: CAUTION: If you have customized any of the 7.2 IC Scripts, make sure that you have tested your customizations as described in Upgrade customized IC Scripts and workflows on page 33 before you push them to your production database. For all versions of Avaya IC, you need to generate the interaction_center application in the ccq.adl file and the repository application in the repository.adl file. To regenerate your applications: 1. In Database Designer, click File > Generate Windows Application. 50 Software Upgrade and Data Migration May 2009

51 Upgrade the 7.1 data to Regenerate the interaction_center application, making sure that you push all IC Scripts and Avaya Agent layout (CDL) files to the database. 3. Regenerate the repository application, making sure that you push all IC Scripts to the database. Upgrade the 7.1 data to 7.2 In order to upgrade your data to 7.2, you need to: Import the 7.2 seed data on page 51 Import the 7.2 seed data To import the new seed data for 7.2: 1. Open a command prompt and navigate to IC72_INSTALL_DIR\IC72\design\ CallCenterQ\delta. 2. Open migrate_seed.cfg in an ASCII editor such as Notepad and verify that the administration login ID and password are correct. 3. Save and close the migrate_seed.cfg file. 4. Run migrate_seed.bat. Import the localization seed data If you are migrating a localized version of Avaya IC: 1. Make sure that you have the localized version of Avaya IC Open a command prompt and navigate to IC72_INSTALL_DIR\IC72\design\ CallCenterQ\delta. 3. Open migrate_l10n_seed.cfg in an ASCII editor such as Notepad and verify that the administration login ID and password are correct. 4. Save and close the migrate_l10n_seed.cfg file. 5. Run migrate_l10n_seed.bat. Software Upgrade and Data Migration May

52 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 Load the new workflows! CAUTION: CAUTION: If you have customized any of the 7.2 workflows, make sure that you have tested your customizations as described in Upgrade customized IC Scripts and workflows on page 33 before you push them to your production database. To load the new workflows: 1. Open the 7.2 Workflow Designer. 2. Recompile all customized 7.2 workflows. 3. Upload them to the database. For details, see Avaya Workflow Designer User Guide. Migrate your server settings into 7.2 In order to migrate your server settings, you first need to restart the Directory server and create a new agent administrator account. To do so: 1. Open the 7.2 IC Manager. 2. Stop and then restart the Directory server. 3. Click Manager > Refresh. 4. Add a new Administrator account that can be used as a secondary login for IC Manager in case the regular Administrator account encounters any login-related issues during the migration process. To do so: a. Click the Agent tab. b. In the left pane, click the Default workgroup. c. Click Agent > New. IC Manager displays the Agent Editor dialog box. d. Enter required basic information for the agent record. The login ID you select should be the install user for the Avaya IC software. e. Click the Security tab and set a password for this account. In the Agent Roles section, select the Administrator check box. 52 Software Upgrade and Data Migration May 2009

53 Migrate your server settings into 7.2 Important:! Important: Avaya recommends that you have a backup Administrator account in case of any unforeseen login issues. If you cannot log into IC Manager using any of your administrator accounts, you need to review the icmanager_admin.log for database errors or disabled login. Import your server settings To import your server settings into 7.2: 1. In the 7.2 IC Manager, click Manager > Options. IC Manager displays the Options dialog box. 2. Click the Environment tab. 3. Hold the Ctrl+Alt keys and double-click the left mouse button anywhere on this dialog. 4. IC Manager displays a new button called XML Maintenance under the Export Configuration button. 5. Click XML Maintenance. 6. In the XML Record Maintenance dialog box, select sc.xsd and click Import. 7. In the File Chooser, select the sc.xsd file from IC72_INSTALL_DIR\IC72\etc. 8. Click OK to return to the Options dialog box. 9. Click Import Configuration. 10. In the File Chooser, select the sc.xml file from IC72_INSTALL_DIR\IC72\etc. IC Manager should display a message stating that the sc.xml file has been successfully validated. 11. Click OK to import the server settings. 12. Click OK to close the Options dialog box. 13. Exit from IC Manager and then restart it so that it reads the updated configuration information. Tip: Tip: If the administrator account is locked out of IC Manager, use the back up account you created in Migrate your server settings into 7.2 on page 52 to log in and unlock the primary account. For information about unlocking an account, see IC Administration Volume 2: Agents, Customers, & Queues. Software Upgrade and Data Migration May

54 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 Update server and agent properties For details about upgrading your server and agent properties to match 7.2, see: Update existing server properties on page 54 Set new properties for existing servers on page 54 Update the web configuration on page 55 Removing the ICM server context in IC Manager on page 55 BA configuration on page 56 Remove links to 7.1 Resource Manager servers on page 56 Import new agent properties on page 57 Update existing agent properties on page 57 Update existing server properties Some server properties need to be migrated by hand. To do so: 1. In the 7.2 IC Manager, click the Servers tab. 2. Select All Domains in the left-hand pane. 3. Double click each server to open the Server Editor and reconfigure the server properties as mentioned in the IC Installation and Configuration guide. Set new properties for existing servers Some of the properties for following servers have been added or changed in 7.2: IC server WACD server Telephony (TS) servers SIPTS server TSA server Telephony Queue Statistics (TSQS) servers Workflow server License server Notification Server 54 Software Upgrade and Data Migration May 2009

55 Update server and agent properties Logging properties for all servers have changed in Avaya IC 7.2. For details about the new properties, see IC Administration Volume 1: Servers & Domains. Once you have read about the changes, you can use the Server Editor in IC Manager to set the properties as desired. Update the web configuration To update the web configuration, you need to run the Configuration tool on all Avaya IC server machines. To do so: 1. On an Avaya IC server machine, start the Configuration Tool by Clicking Start > Programs > Avaya Interaction Center 7.1 > Configuration Tool. 2. Click the Web tab. 3. Change the Web Server Host field to point to the 7.2 web server machine. 4. Click Apply Settings. 5. Click Exit. 6. Repeat this procedure for another Avaya IC server machine as needed. For details about running the Configuration Tool, see IC Installation and Configuration. Removing the ICM server context in IC Manager 1. Start IC Manager. 2. Delete the existing ICM server context in IC Manager. 3. Click the configuration tab. 4. Expand chat in the left hand pane. 5. Click ICM. 6. Select the entries in the right hand pane and click the delete icon on the toolbar. 7. Now create a new ICM context by clicking New in the Configuration Tab. Configure this new ICM context with the same values as were given for the previous ICM context. For more information on how to create a new context see IC Installation and Configuration 8. Restart the ICM service. Software Upgrade and Data Migration May

56 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 BA configuration If your site uses Business Advocate, make sure you specify your 7.1 Business Advocate database when you run the Business Advocate Configuration Tool. If you have changed the host name of the machine that was running the Business Advocate in IC 7.1 or if you are using new machine for Business Advocate with a new host name. Delete all the data from the following tables in the given order: 1. MX_CM_CONFIG 2. MX_CM_COMPONENT 3. MX_CM_SERVER For Example, You can use the following query to delete the data from the above mentioned tables: Delete FROM MX_CM_CONFIG Delete FROM MX_CM_COMPONENT Delete FROM MX_CM_SERVER Run the Business Advocate Configuration Tool on all Advocate Machines. Remove links to 7.1 Resource Manager servers If your site uses Business Advocate and the name of any server machine hosting one or more Resource Manager servers has changed, remove the reference to those servers from the Business Advocate Component Manager. To do so: 1. Open the 7.2 Business Advocate Administration Tool. 2. In the left-hand pane, expand the Advocate Component Manager placeholder. 3. Right click on the first link to a 7.1 Resource Manager server and click Delete. 4. Confirm the deletion at the prompt. 5. Repeat steps 3 and 4 for each link to a 7.1 Resource Manager server. 6. If necessary, add the migrated 7.2 Resource Manager servers. 7. For each 7.2 server, make sure that its role is correct. 8. Close the Business Advocate Administration Tool. 56 Software Upgrade and Data Migration May 2009

57 Update server and agent properties Import new agent properties To import the new agent properties into your migrated system: 1. Open a command prompt and navigate to IC72_INSTALL_DIR\IC72\design\ repository\data. 2. Open import_properties.bat in an ASCII editor such as Notepad and verify that the administration login ID and password are correct. 3. Save and close the file. 4. Run import_properties.bat. 5. To see the new properties, open IC Manager. If IC Manager is already running, select Manager > Refresh. For details about all Avaya IC agent properties, see IC Administration Volume 2: Agents, Customers, & Queues. Update existing agent properties Some existing agent properties need to be updated before the agent clients will work properly in 7.2. The properties are: Property Section Property Name Change AgentDesktop/WebClient WorkingDirectory If the relative path to the agent working directory has changed, update this property. System/Configuration ChatLoginServer Update the path to the new 7.2 chat server. LoginServer Server Update the path to the new 7.2 server that handles logins. Update the path to the new 7.2 server. For details about changing these properties, see IC Administration Volume 2: Agents, Customers, & Queues. Software Upgrade and Data Migration May

58 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 Migrate your Content Analyzer data If your Content Analyzer Knowledge Bases can be accessed through the same fully-qualified file path by the new 7.2 servers as was used by your old 7.1 servers, then all you need to do is: Bring up the Avaya IC 7.2 system Ensure that Content Analyzer works as expected If you need to move the Content Analyzer Knowledge Bases relative to the servers: 1. Make sure that all of the Knowledge Bases you identified in Prerequisites for migrating Content Analyzer on page 25 are stored in a directory on a machine that is accessible to any server machine that will be running a CAAdmin or CAServer server. Make a note of all the Knowledge Base names and file locations. If appropriate, consult your Content Analyzer Administrator for the approved location of the Knowledge Base files. 2. If you want to change any of your Knowledge Base file names, you should do so at this point. Make sure that you make a note of the old and new filenames so that you can change the File Location information when you configure the associated 7.2 CAServer.! Important: Important: Do not change the Knowledge Base name during the migration process. Any such changes should be done through IC Manager once the 7.2 system is up and running. 3. In the CallCenterQ database, change the file names and locations in the knowledgebase database table to reflect the new names and locations for your Knowledge Bases. To do so, run the following database-specific SQL script for each of the migrated Knowledge Bases. For SQL Server: 1. Open the SQL Server Query Analyzer. 2. Connect to the appropriate 7.2 CCQ database. 58 Software Upgrade and Data Migration May 2009

59 Migrate your Content Analyzer data 3. Run the following SQL script for each of the renamed or moved Knowledge Bases: USE ccq UPDATE knowledgebase SET knowledgebase.kbfilepath = 'Full_Destination_KB_Path' WHERE knowledgebase.name = 'KB_Name' AND knowledgebase.kbfilepath = 'Full_Source_KB_File_Path' For Oracle: Where Full_Destination_KB_Path is the fully-qualified location of the 7.2 Knowledge Base (including the file name), KB_Name is the Knowledge Base name, and Full_Source_KB_File_Path is the fully-qualified name of the corresponding 7.1 Knowledge Base. (Do not change the quotation marks.) 1. Use SQL Query to connect to the appropriate Oracle 7.2 Avaya IC database. 2. Run the following SQL script for each of the renamed or moved Knowledge Bases: For DB2: UPDATE ccq.knowledgebase SET knowledgebase.kbfilepath = 'Full_Destination_KB_Path' WHERE knowledgebase.name = 'KB_Name' AND knowledgebase.kbfilepath = 'Full_Source_KB_File_Path'; COMMIT; Where Full_Destination_KB_Path is the fully-qualified location of the 7.2 Knowledge Base (including the file name), KB_Name is the Knowledge Base name, and Full_Source_KB_File_Path is the fully-qualified name of the corresponding 7.1 Knowledge Base. (Do not change the quotation marks.) 1. Use DB2 SQL Query to connect to the appropriate DB2 7.2 Avaya IC database. 2. Run the following SQL script for each of the renamed or moved Knowledge Bases: UPDATE knowledgebase SET knowledgebase.kbfilepath = 'Full_Destination_KB_Path' WHERE knowledgebase.name = 'KB_Name' AND knowledgebase.kbfilepath = 'Full_Source_KB_File_Path' Where Full_Destination_KB_Path is the fully-qualified location of the 7.2 Knowledge Base (including the file name), KB_Name is the Knowledge Base name, and Full_Source_KB_File_Path is the fully-qualified name of the corresponding 7.1 Knowledge Base. (Do not change the quotation marks.) Software Upgrade and Data Migration May

60 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 Verifying the new Knowledge Base file locations To make sure that your changes are accurate, run the SQL statements shown in Determining the training and validation information for your Knowledge Bases on page 27. The entries in the KB File column should match the new locations and names for your Knowledge Bases. Migrate data from server Avaya IC 7.2 allows the IC server to store large s exceeding 1 MB in size into the database. However IC 7.1 Server was not designed to store large s into the database and as such all large s exceeding 1 MB were stored as a local file on the disk. These files reside in to the <ICHOME>/MessgeCenter/messages folder. While migrating to Avaya IC 7.2 we need to migrate this data as well. For this purpose Avaya IC 7.2 introduces Migrate utility to migrate data. Prerequisites for migrating data: All contacts in the IC system must be in the completed state (Wrapped, dismissed, bounced,.. states) Old IC server must not be removed from VESP configuration Databases must be tuned for better performance as large amount of data is going to be uploaded inside the database. To migrate data: 1. Backup your existing IC CCQ and REPOSITORY databases. 2. Backup the messages directory from IC 7.1 installation. This directory is located at <ICHOME>/MessageCenter/Messages folder. This folder contains the.msg files that are created by IC server. You will find this folder on the computer where the IC server is configured. 3. Install Avaya IC 7.2. See Install Avaya IC 7.2 on page 30. For more information, see Avaya IC 7.2 Installation and Configuration guide. 4. Copy the messages directory from IC 7.1 installation to <IC-72-HOME>/ MessageCenter/Messages folder. 5. Start core servers. 6. Reconfigure CCQ and REPOSITORY databases. See Reconfigure your 7.2 databases on page Re-Generate windows applications. See Generate your applications on page Software Upgrade and Data Migration May 2009

61 Migrate WAS to Tomcat 8. Stop IC system. 9. Start core servers. 10. Launch Migrate utility from the Command line. This utility is located in the <ICHOME>/bin folder. The Migrate utility provides the following command line options: -u : Name of the user who performs this operation. For example, administrator. -p : Password of the user. -d : Directory where.msg files are stored. -t : Upload thread count. Default is 10. Maximum is 50. -m : Number of messages to be processed in batch. Default is 100. Maximum is l : Log level. Default is trace. -v : Verbose mode. 11. Configure the number messages to load and number of upload threads as per you server configuration. 12. Log file is created in the <ICHOME>/logs folder. Migrate WAS to Tomcat As of IC7.2, Avaya Agent WebClient will no longer require IBM WAS. Customers who have deployed Avaya Agent WebClient on IBM WAS need to perform the following steps: 1. Install Avaya IC 7.2 Avaya Agent Web Client. For more information, see IC Installation and Configuration guide, section Installing Avaya Agent Web Client. 2. Before generating the war file, manually merge all your customization scripts, JSP scripts and properties files that were modified for AAWC in IC7.1, with files in Avaya IC Once all files are merged, proceed with creating the application WAR file. For more information, see IC Installation and Configuration guide, section Creating the application WAR file. Migrate SDK In IC7.1, Workitem id was represented by eduid so that its unique within the agent worklist. In IC7.2, workitem id will no longer be represented by eduid for unique identification, instead SDK Server will decide what id should be used for a workitem. Software Upgrade and Data Migration May

62 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 Do not use workitem id as eduid. If you have used workitem id as eduid then your custom client needs to be modified to fetch edu id from MediaInteraction interface as shown below: Java Code: ArrayList list = (ArrayList)workitem.getMediaInteractionList().getMediaInteractions(); for(int i=0; i< list.size(); i++) { MediaInteraction mediainteraction = (MediaInteraction)list.get(i); String streduid = mediainteraction.getid(); //perform your business logic here } C# Code: ICollection mediainteractions = wi.mediainteractionlist.getmediainteractions(); foreach (IMediaInteraction mi in mediainteractions) { String strid = mediainteraction.id; //perform your business logic here } Install and Configure WebLM For information about installing and configuring WebLM, refer the Avaya IC 7.2 Installation and Configuration guide. Start Avaya IC 7.2 At this point, all the Avaya IC data has been migrated and you can start all the 7.2 servers and begin running the 7.2 agent clients. 62 Software Upgrade and Data Migration May 2009

63 Uninstall 7.1 Avaya Agent applications Deploy the Web Agent clients If desired, deploy the 7.2 Web Agent clients as described in IC Installation and Configuration. Uninstall 7.1 Avaya Agent applications If you want to uninstall the 7.1 Avaya Agent applications from your agent machines, you will need to re-register the 7.2 Avaya Agent. To do so: 1. Uninstall the 7.1 Avaya Agent. 2. Open a Command Prompt and navigate to IC72_INSTALL_DIR\IC72\bin. 3. Run the following commands: RegRichClient.bat vtel -register Detailed changes to the IC Scripts and workflows Bug fixes were made to some IC Scripts and workflows in 7.2. If you have customized these files, you need to either reapply your customizations to the 7.2 out-of-the-box files, or continue to use your 7.1 files and not take advantage of those bug fixes. For a list of changes, see IC Script changes, below, and Workflow changes on page 72. For WACD and IC flows, if you have customized these files, you need to either reapply your customizations to the 7.2 out-of-the-box files, or add the out-of-box enhancements to your customized flows. Software Upgrade and Data Migration May

64 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 IC Script changes Bug fixes and support for chat transfers and conferences were made to some IC Scripts in 7.2. While you can copy other customized IC Scripts from the IC71_INSTALL_DIR\IC71\ design\<appname> subdirectory into the appropriate IC72_INSTALL_DIR\IC72\design directory, you should reapply your customizations to these out-of-the-box IC Scripts in order to take full advantage of the bug fixes in 7.2. Location IC Scripts changed in 7.2 Description design\ CallCenterQ design\ common design\ common design\ qconsole design\ qconsole design\ qconsole design\ qconsole ccq.qsc FindAndRunScript.qsc QPrompter_Exit.qsc QPrompter_Initialize.qsc QPrompterClient_FlowComplete.qsc QPrompterClient_FlowDelete.qsc Initialize.qsc BlenderClient_AgentStateEvent PhoneEngine_OnCoreStateChanged.qsc StatusDialog_Update.qsc WebEngine_LookupAgentForTransfer.qsc Changes made to handle Nothing (VB upgrade).getactivexcontrol is used instead of GApp.GetActivexControl. Changes made to handle Nothing (VB upgrade).getactivexcontrol is used instead of GApp.GetActivexControl. GetActivexControl function is added. To support that Same agent can't login from Multiple Locations. Changes made to handle Nothing (VB upgrade).getactivexcontrol is used instead of GApp.GetActivexControl. Changed to show Wrapup dialog for voice contacts when TS goes down. Changes made to handle Nothing (VB upgrade). GetActivexControl is used instead of GApp.GetActivexControl. Changes made for display messages for transfer/ conference. Changes made for recognize the transfer/conference action. 64 Software Upgrade and Data Migration May 2009

65 Detailed changes to the IC Scripts and workflows Location IC Scripts changed in 7.2 Description design\ qconsole ACViewer_Initialize.qsc ACViewer_LoadSpecsFromDB.qsc ACViewer_RefreshContact.qsc btnoperation_click.qsc CHBrowser_AddContact.qsc CHBrowser_GetActiveContactCriteria.qsc CHBrowser_Initialize.qsc CHBrowser_RefreshContact.qsc CHBrowser_RemoveContact.qsc CHBrowser_Reset.qsc CHBrowser_SetActiveContactCriteria.qsc CHBrowser_ShowContact.qsc CHBrowserTabStrip_Click.qsc CHFilter_Initialize.qsc CHFilter_OnFilterReset.qsc CHFilter_OnFilterSet.qsc CoreServices_BeforeChannelLogout.qsc CoreServices_Logout.qsc CoreServices_MakeChannelBusy.qsc CoreServices_RestartServer.qsc CoreServices_SetCollabAttemptTime.qsc CoreServices_SetEDUValue.qsc CoreServices_SetOrIncrementEDUValue.qsc CoreServices_StoreComment.qsc Changes made to handle Nothing (VB upgrade).getactivexcontrol is used instead of GApp.GetActivexControl. Software Upgrade and Data Migration May

66 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 Location IC Scripts changed in 7.2 Description design\ qconsole EDUViewer_AddContact.qsc EDUViewer_Initialize.qsc EDUViewer_LoadSpecsFromDB.qsc EDUViewer_RefreshContact.qsc EDUViewer_RemoveContact.qsc EDUViewer_Reset.qsc EDUViewer_ShowContact.qsc _CompleteContact.qsc _Exit.qsc _HasActiveContacts.qsc _Initialize.qsc _Login.qsc _Logout.qsc _ShowHistory.qsc _SuspendActiveContacts.qsc _Transfer.qsc ErrorDialog_ButtonClicked.qsc ErrorDialog_Create.qsc ErrorDialog_Update.qsc LM_InitializeWebBrowser.qsc LM_RunScript.qsc MailEngine_LookupAgentForTransfer.qsc MailEngine_RequestAlertInfo.qsc Changes made to handle Nothing (VB upgrade).getactivexcontrol is used instead of GApp.GetActivexControl. 66 Software Upgrade and Data Migration May 2009

67 Detailed changes to the IC Scripts and workflows Location IC Scripts changed in 7.2 Description design\ qconsole OutboundAgent_AddDataWakeID.qsc OutboundAgent_CompleteContact.qsc OutboundAgent_Exit.qsc OutboundAgent_WrapScript.qsc PhoneEngine_OnTelephonyStateChanged.qsc QConsole_AddContact.qsc QConsole_AsyncExecuteQScript.qsc QConsole_CheckVoiceRefCountForChat.qsc QConsole_ClearFocus.qsc QConsole_CompleteContact.qsc QConsole_ExitChannelsNotInUse.qsc QConsole_ExitComponents.qsc QConsole_GetContactLabelFromEDU.qsc QConsole_GetCoreServices.qsc QConsole_HangUpCall.qsc QConsole_InitializeComponents.qsc QConsole_KeyDown.qsc QConsole_LoginComponents.qsc QConsole_MouseDown.qsc QConsole_PerformScreenPopFromEDU.qsc QConsole_PlaceCall.qsc QConsole_RemoveContact.qsc QConsole_SelectContact.qsc QConsole_ShowContact.qsc QConsole_StartPrompterFlow.qsc QConsole_TransferRelatedChat.qsc Changes made to handle Nothing (VB upgrade).getactivexcontrol is used instead of GApp.GetActivexControl. Software Upgrade and Data Migration May

68 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 Location IC Scripts changed in 7.2 Description design\ qconsole QConsole_UpdateActivePanes.qsc QConsole_UpdateVoiceRefCount.qsc QConsole_WrapContact.qsc Softphone_ClickButton.qsc Softphone_CompleteConference.qsc Softphone_CompleteConsTransfer.qsc Softphone_CompleteContact.qsc Softphone_Exit.qsc Softphone_GetCurrentAgentFromEDU.qsc Softphone_GetTelephony.qsc Softphone_HandleTelephonyResponse.qsc Softphone_HangUpCall.qsc Softphone_HasActiveContacts.qsc Softphone_InitBlindTransfer.qsc Softphone_InitConference.qsc Softphone_InitConsTransfer.qsc Softphone_Initialize.qsc Softphone_Login.qsc Softphone_Logout.qsc Softphone_PlaceCall.qsc Softphone_Reset.qsc StatusDialog_Create.qsc Changes made to handle Nothing (VB upgrade).getactivexcontrol is used instead of GApp.GetActivexControl. 68 Software Upgrade and Data Migration May 2009

69 Detailed changes to the IC Scripts and workflows Location IC Scripts changed in 7.2 Description design\ qconsole TaskList_Initialize.qsc TaskList_Reset.qsc UAD_CancelContact.qsc UAD_HandleUADCancel.qsc UAD_HandleUADError.qsc UAD_HandleUADOK.qsc UAD_Initialize.qsc UAD_RemoveContact.qsc UAD_SetContact.qsc UAD_Show.qsc UAD_Show LookupResponse.qsc WAC_LoggedIn.qsc WAC_Login.qsc WAC_SendAddressLookup.qsc WACEngine_Initialize.qsc WACEngine_LookupAddress.qsc Web_Exit.qsc Web_HandleIVChatInitialize.qsc Web_HasActiveContacts.qsc Web_Initialize.qsc Web_Login.qsc Web_Logout.qsc Web_Reset.qsc Web_ShowHistoricTranscript.qsc Web_SuspendActiveContacts.qsc Web_Transfer.qsc Changes made to handle Nothing (VB upgrade).getactivexcontrol is used instead of GApp.GetActivexControl. Software Upgrade and Data Migration May

70 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 Location IC Scripts changed in 7.2 Description design\ qconsole Web_WrapContact.qsc WebEngine_ActivateCallback.qsc WebEngine_LookupAgentForTransfer.qsc WebEngine_TransferResponse.qsc WebEngine_WebStateChanged.qsc WrapUpDialog_Initialize.qsc WrapUpDialog_Login.qsc WrapUpDialog_StartWrapUp.qsc WrapUpEngine_Exit.qsc StatusDialog_ButtonClicked.qsc StatusDialog_Update.qsc CoreServices_Initialize.qsc CoreServices_BeforeLogout.qsc _BeforeLogout.qsc QConsole_SuspendOtherContacts.qsc Softphone_BeforeLogout.qsc Web_BeforeLogout.qsc Custom_Exit.qsc Custom_IHH_CHB_Initialize.qsc Custom_IHH_UAD_Initialize.qsc Custom_IHH_UAD_Login.qsc Custom_IHH_UAD_Show.qsc Custom_Initialize.qsc Custom_Login.qsc Custom_Logout.qsc Changes made to handle Nothing (VB upgrade).getactivexcontrol is used instead of GApp.GetActivexControl. 70 Software Upgrade and Data Migration May 2009

71 Detailed changes to the IC Scripts and workflows Location IC Scripts changed in 7.2 Description design\ qconsole design\ qconsole Custom_ManualLogin.qsc Custom_Routine_Bar.qsc Custom_Routine_Foo.qsc Siebel_AICD_AcceptPreviewCall.qsc Siebel_AICD_Activate.qsc Siebel_AICD_AgentAutomaticMode.qsc Siebel_AICD_AgentAvailable.qsc Siebel_AICD_AgentUnavailable.qsc Siebel_AICD_Cancel .qsc Siebel_AICD_ChangeAuxReasonCode.qsc Siebel_AICD_ChannelAvailable.qsc Siebel_AICD_ChannelUnavailable.qsc Siebel_AICD_CompleteConsultTransfer.qsc Siebel_AICD_Defer .qsc Siebel_AICD_Disconnect.qsc Siebel_AICD_Dismiss .qsc Siebel_AICD_InitConference.qsc Siebel_AICD_InitConsultTransfer.qsc Siebel_AICD_InitMuteTransfer.qsc Siebel_AICD_MakeCall.qsc Siebel_AICD_RejectPreviewCall.qsc Siebel_Exit.qsc Siebel_HandleAICDAssigned.qsc Siebel_IHH_AddContact.qsc Siebel_IHH_RemoveContact.qsc Siebel_IHH_UAD_CancelContact.qsc Siebel_Initialize.qsc Siebel_Launch.qsc Siebel_PerformRecoveryPop.qsc Siebel_PopInteraction.qsc Siebel_Run SendFlow.qsc Siebel_SelectInteraction.qsc Siebel_SendAgentState.qsc Siebel_SendChannelState.qsc Siebel_SetInteractionState.qsc SiebelErrorDialog_ButtonClicked.qsc SiebelErrorDialog_Create.qsc Changes made to handle Nothing (VB upgrade).getactivexcontrol is used instead of GApp.GetActivexControl. Changes made to handle Nothing (VB upgrade).getactivexcontrol is used instead of GApp.GetActivexControl. Software Upgrade and Data Migration May

72 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 Workflow changes The following workflows under IC72_INSTALL_DIR\IC72\design\IC\Flows\Avaya\ have changed in 7.2: Location Workflow name Description IC WACD analyzeca.qfd analyzenoca.qfd outboundca.qfd outboundnoca.qf d ic .prj qualifychat.qfd qualify .qfd wacd.prg In IC7.2, IC server sends its UUID as name "ic _uuid" and IC server alias name as "ic _name" for analyzing contact. This UUID / Name is used by enhanced flows to call IC .Analyzed and IC .OutboundResponse on IC server. Following are the changes in analyzeca, analyzenoca, outboundca and outboundnoca flows: Introduced new Symbols "ic _uuid" and "ic _name" of type "string". Enhanced "Get Input Parameters" block to populate IC server's UUID and Name into symbol "ic _uuid" and "ic _name". Enhanced "IC Analyzed" and "IC Outbound Response" blocks to use "ic _uuid" and "ic _name" symbols while making Toolkit request "IC .Analyzed" and "IC .OutboundResponse" onto IC server. Please refer out-of-box flows for detailed enhancements. In IC7.2, WACD server sends its UUID as name "wacduuid" for qualifying contact. This UUID is used by enhanced flows to call WACD.Route on WACD server that requested for qualify contact. Following are the changes in qualifychat and qualify flows: Introduced new Symbol "wacduuid" of type "string". Enhanced "Get Input Parameters" block to populate WACD server's UUID into symbol "wacduuid". Enhanced "Complete Qualification" block to use "wacduuid" symbol while making Toolkit request "WACD.Route" onto WACD server. Please refer out-of-box flows for detailed enhancements. 72 Software Upgrade and Data Migration May 2009

73 Migrating Operational Analyst 7.1 to 7.2 Migrating Operational Analyst 7.1 to 7.2 Operational Analyst 7.2 is a fresh install and you cannot upgrade to Avaya OA 7.2 from an earlier release. Changes in C++ runtime and JDK version make it difficult to perform software upgrade and migrate real time data between releases. However it is possible to migrate historical data from to 7.2. This section describes the procedure to migrate historical data from to 7.2. Avaya OA 7.2 reports display outbound data after migrating data from Avaya OA 7.1 to Avaya OA 7.2. For information on supported and de-supported platforms in Avaya OA 7.2, see Avaya Operational Analyst 7.2 Installation Planning and Prerequisites guide. Prerequisites If you are migrating from an earlier release, you must first upgrade to release. Same deployment setup of Avaya OA is used for Avaya OA 7.2. To access the OA database, check if the database user exists in the database, if not then create a user and give proper grants to access the OA database. Migrating from Avaya OA to Avaya OA 7.2 on Windows While migrating Avaya OA to Avaya OA 7.2 on WIDNOWS 2003 with MS SQL 2005 as back end database, you can use the existing database server of Avaya OA for Avaya OA 7.2, as Avaya OA 7.2 also supports MS SQL This eliminates the need to import Avaya OA database to new database server, as importing a database requires you to import table data, users with their grants, indexes, keys and so on. Before you migrate Avaya OA to Avaya OA 7.2 Disable all interface services using the Admin client. If you have customized the properties of any OA server components in (e.g. Auth server or forwarders) make a backup copy of those properties files from <OA Install Location>/data/admin. Uninstall Avaya OA Install Avaya OA 7.2 components 1. Verify that the servers including the database server meet the requirements of Avaya OA 7.2. See Avaya Operational Analyst 7.2 Installation Planning and Prerequisites guide. Software Upgrade and Data Migration May

74 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 You can install Avaya OA 7.2 on the same set of servers that you used for Avaya OA Set the environment variable BI_DONT_RUN_DBSETUP to true on the server, where you will install the Avaya OA 7.2 historical subsystem. Setting this variable to true prevents the OA installer from creating schemas and populating the historical database with default entries. 3. Install the OA components. For information on installing OA components, see Avaya Operational Analyst 7.2 Installation and Configuration guide. 4. If you have made backup copies of any properties files, copy the backup files to <OA Install Location>/data/admin. Configure Avaya OA 7.2 subsystems Skip steps 5 to 13 if you install Avaya OA 7.2 on the same set of servers that you used for Avaya OA Log in to the Admin client installed on the Avaya OA 7.2 server 2. Go to Interface Services. Select all services and click disable. 3. Click Save. 4. Go to Subsystems. 5. Select the appropriate subsystem (For Example, Historical) and click modify. 6. In the Modify Subsystem screen, change the location to the IP Address or domain name of the new Avaya OA 7.2 server. 7. Click OK. 8. The message "Is this subsystem being physically moved from one server to another?" appears. Click Yes. 9. The message "Do you want to continue this subsystem modification?" appears. Click Yes. 10. The administration client displays a list of services that must be disabled before proceeding. 11. Click the Continue request without disabling services option. 12. Click OK. 13. Click Save to save the changes. 14. Repeat steps 5 to 15 for all subsystems in the following order: a. Historical b. Reports c. Realtime 74 Software Upgrade and Data Migration May 2009

75 Migrating Operational Analyst 7.1 to 7.2 d. EC Source e. CMS f. CMS Source 15. Configure the EC server. For information on configuring the EC server, see Avaya Operational Analyst 7.2 Installation and Configuration guide. 16. Go to Interface Services. Select all services and click enable. 17. Click Save. 18. Check if the status of all the services show normal operation. If all services do not start, type the following commands at the command prompt: pa stop all pa start all If you face any problems while starting the OA processes, see Avaya Operational Analyst Release 7.2 Maintenance and Troubleshooting guide. Migrating from Avaya OA to Avaya OA 7.2 on Solaris For migrating from Avaya OA that is using Oracle 10g on Solaris 10 to Avaya OA 7.2 that is using Oracle 10g on Solaris 10, follow the same procedure described in Migrating from Avaya OA to Avaya OA 7.2 on Windows on page 73. For migrating from Avaya OA that is using Oracle 9i/10g on Solaris 9 to Avaya OA 7.2 that is using Oracle 10g/11g on Solaris 10: The combination of Oracle 9i with Solaris 9 is de-supported in Avaya OA 7.2, you can migrate the existing configuration in Avaya OA to Avaya OA 7.2. If you are migrating from Avaya OA that is using Oracle 10g on Solaris 9, you can use the Avaya OA database server for Avaya OA 7.2. Before you migrate Avaya OA to Avaya OA 7.2 on Solaris Disable all interface services using the Admin client. If you have customized the properties of any OA server components in (e.g. Auth server or forwarders) make a backup copy of those properties files from <OA Install Location>/data/admin. Take full backup of Avaya OA historical database. Refer to respective database vendor documentation for information on database backup. Export entire Avaya OA historical database with schemas, table contents, user grants, indexes and so on and import the same in Avaya OA 7.2. For any prerequisites, See Avaya Operational Analyst 7.2 Installation Planning and Prerequisites guide. Uninstall Avaya OA Software Upgrade and Data Migration May

76 Chapter 2: Upgrading Avaya Interaction Center from 7.1 to 7.2 Follow the procedures described in the sections Install Avaya OA 7.2 components on page 73 and Configure Avaya OA 7.2 subsystems on page 74. Migrating from Avaya OA to Avaya OA 7.2 on AIX Before you migrate from Avaya OA that is using DB2 8.x on AIX 5.x to Avaya OA 7.2 that is using DB2 9.5 on AIX 6.1: Disable all interface services using the Admin client. If you have customized the properties of any OA server components in (e.g. Auth server or forwarders) make a backup copy of those properties files from <OA Install Location>/data/admin. Take full backup of Avaya OA historical database. Refer to respective database vendor documentation for information on database backup. Export entire Avaya OA historical database with schemas, table contents, user grants, indexes and so on and import the same in Avaya OA 7.2. For any prerequisites, See Avaya Operational Analyst 7.2 Installation Planning and Prerequisites guide. Uninstall Avaya OA Follow the procedures described in the sections Install Avaya OA 7.2 components on page 73 and Configure Avaya OA 7.2 subsystems on page Software Upgrade and Data Migration May 2009

77 Chapter 3:Upgrading Avaya Interaction Center from 7.0 to 7.1 This chapter contains information that helps you upgrade from Avaya Interaction Center (Avaya IC) from 7.0 to release 7.1. If you are starting from an earlier release, you must first migrate to 7.0. For details, see the appropriate chapter in this manual. This section includes the following topics: Considerations on page 78 Prerequisites on page 78 Remove unused servers on page 83 Install Avaya IC 7.1 on page 84 Prepare the new administration machine for migration on page 85 Upgrade customized IC Scripts and workflows on page 86 Copy customized website, Avaya Agent layouts, and EDU Viewer stylesheets on page 87 Migrate your ADL files on page 88 Migrate your Avaya IC 7.0 servers on page 94 Start the 7.1 core servers on page 96 Shut down 7.0 on page 97 Reconfigure your 7.1 databases on page 98 Generate your applications on page 101 Upgrade the 7.0 data to 7.1 on page 102 Load the new workflows on page 104 Migrate your server settings into 7.1 on page 105 Update the web configuration on page 106 Update server and agent properties on page 107 Migrate your Content Analyzer data on page 112 Start Avaya IC 7.1 on page 114 Uninstall 7.0 Avaya Agent applications on page 114 Detailed changes to the IC Scripts and workflows on page 115 Software Upgrade and Data Migration May

78 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to 7.1 Considerations Platform changes: In this release of Avaya IC, changes to the CRuntime and JDK versions make in-place migrations extremely time consuming because the systems must be taken down and reconfigured before the migration can begin. Therefore, Avaya recommends that you migrate to new server machines that have been properly configured for 7.1. For details, see IC Installation Planning and Prerequisites. Avaya Operational Analyst: For details about upgrading Avaya OA 7.1, see Avaya Operational Analyst Installation and Configuration. Localization: If you are using a localized version of Avaya IC 7.0, you need to migrate to the localized version of Avaya IC 7.1. You cannot migrate a localized 7.0 system to a non-localized 7.1 system. To determine whether you have the localized version of 7.1, see the Readme.pdf file on the core Avaya IC CD-ROM. Outbound Contact Management: In Avaya IC 7.1, Avaya discontinued support for Outbound Contact Management. If your installation uses this feature, contact your Avaya IC support representative. Siebel: For details about upgrading Siebel, see Avaya IC for Siebel Integration. Voice Quick Start (VQS): If your installation uses VQS, you can continue to use your current VQS set up with the 7.1 Avaya IC servers and Avaya Agent desktop application. However, VQS does not support the new Avaya Agent Web Client. The new Avaya Agent Web Client is supported by Avaya IC only. For more information or additional VQS seats, contact your Avaya sales representative. Prerequisites Before you begin the migration process: Avaya recommends that you make a backup copy of: - The entire IC71_INSTALL_DIR\IC71\design directory and its subdirectories - The IC71_INSTALL_DIR\IC71\etc directory - Your 7.0 databases, including those for Business Advocate if your site uses that product Verify that the Sun JDK version 1.4.2_08 is installed on your Avaya IC web server machines. 78 Software Upgrade and Data Migration May 2009

79 Prerequisites Verify that servers you are migrating to meet all the requirements for Avaya IC 7.1. For more information about prerequisites for Avaya IC 7.1, see IC Installation Planning and Prerequisites. Prerequisites for migrating Content Analyzer Before you migrate your 7.0 system, you should make detailed notes about your Content Analyzer system, as described in the sections below. With this information, you can: Verify that all of your Content Analyzer data migrated properly Restore all of the settings for your Content Analyzer CAServer and CAAdmin servers For details about Content Analyzer and the Content Analyzer servers, see IC Administration Volume 1: Servers & Domains. If at all possible, you should configure your 7.1 Content Analyzer servers so that they have the same relative path to the Content Analyzer Knowledge Bases as the 7.0 servers did. For example, if the fully-qualified path from your current 7.0 servers to your Knowledge Bases is X:\Avaya\KBs\, then you should make sure that your 7.1 servers use the same path. If your 7.1 servers can use the same relative path to the Knowledge Bases, then all of your Content Analyzer database data will be migrated automatically when you perform the standard migration steps described in this chapter. The only Content Analyzer-specific migration step you need to take is to recreate your 7.0 Content Analyzer servers in your 7.1 environment. If you have to change the relative location of your Knowledge Bases to your Content Analyzer servers, you will also need to perform the migration steps in Migrate your Content Analyzer data on page 112. In order to verify Content Analyzer data migration, you need to record information about your 7.0 Content Analyzer environment, as described in the following sections: Determining the current Content Analyzer data Determining the current Content Analyzer server settings Determining the training and validation information for your Knowledge Bases Determining the current Content Analyzer data To find out what Content Analyzer data is currently stored in your Avaya IC system: 1. In IC Manager, select Tools > Content Analysis. 2. To get a list of all the Knowledge Bases in your system, select KB Management in the left-hand pane and make a note of the information in the File Path column for each Knowledge Base that appears in the right-hand pane. Software Upgrade and Data Migration May

80 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to 7.1 Tip: The File Path column shows the relative path to the Knowledge Base, not the exact machine on which that Knowledge Base is located. Make sure you contact your Content Analyzer Administrator for the specific machines and directories where the Knowledge Base files are located. 3. To get a list of all the topic trees in your system, select Topic Tree Management in the left-hand pane. Make a note of all the topic trees and their topics. Tip: An easy way to do this is to expand all of the topic trees and then take one or more screenshots of the resulting data. If you have a large number of topic trees, you may want to expand each one individually and take one screenshot per tree. 4. To get a list of all the sample sets in your system: a. Select Sample Management in the left-hand pane. b. Select the Remove Samples tab in the right-hand pane. c. Open the Sample Set drop down list and make a note of the sample sets. Determining the current Content Analyzer server settings To determine your Content Analyzer server settings: 1. In IC Manager, select the Server tab and then select All Domains in the left-hand pane. 2. For each Avaya IC server of type CAAdmin: a. Right click on that server and select Edit from the pop-up menu. IC Manager displays the Server Editor dialog box for that server. b. Take a screenshot of each tab in the Server Editor dialog box, making sure that you take special note of the Name on the General tab, the system on which this server was configured, and the setting for Path to NLP Data on the CAAdmin tab. c. Select OK or Cancel to close the Server Editor dialog box. d. Repeat steps a through c for the next CAAdmin server. 3. For each Avaya IC server of type CAServer: a. Right click on that server and select Edit from the pop-up menu. IC Manager displays the Server Editor dialog box for that server. b. Take a screenshot of each tab in the Server Editor dialog box, making sure that you take special note of the Name on the General tab, the system on which this server was configured, and the setting for Path to NLP Data on the CAServer tab. c. On the CAServer tab, select the Knowledge Base button and, for each associated Knowledge Base: 1. Record the Name, KB File Location, and Threshold values. 80 Software Upgrade and Data Migration May 2009

81 Prerequisites 2. Click on under the Languages column and note all of the languages that are associated with this Knowledge Base. 3. Select OK or Cancel to close the Knowledge Base dialog box. d. Select OK or Cancel to close the Server Editor dialog box. e. Repeat steps a through d for the next CAServer server. 4. When you have finished recording the details for all of your CAAdmin and CAServer servers, you can close IC Manager. Determining the training and validation information for your Knowledge Bases To view the training and validation information about your existing Knowledge Bases (such as the topic tree associated with the Knowledge Base, the sample set used in training or validation, and the date/time of any training or validation sessions), you can run a SQL query on your 7.0 SQL Server database, or a SQL Plus query on your 7.0 Oracle database. Both queries are shown below. Tip: Tip: If you saved the results of previous training and validation sessions, make sure that you know where those files are located so that you can compare them to your migrated 7.1 system. For a SQL Server database, run the following SQL query: USE ccq SELECT kb.name "KBName", kb.kbfilepath "KBFilePath", ss.name "SampleSet", ct.name "Topic Tree", sskb.intent "Train:0; Validate:1", sskb.dateperformed "Date Performed" FROM knowledgebase kb, sampleset ss, samplesetknowledge sskb, contenttree ct WHERE kb.pkey = sskb.knowledgebase_key AND sskb.sampleset_key = ss.pkey AND ss.contenttree_key = ct.pkey ORDER BY sskb.intent ASC, sskb.dateperformed DESC Software Upgrade and Data Migration May

82 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to 7.1 A screenshot showing an example of this query is shown below. In this example, each of the three Knowledge Bases went through one training session and one validation session. The sample set used for each training and validation session is shown in the SampleSet column. 82 Software Upgrade and Data Migration May 2009

83 Remove unused servers For an Oracle database, run the following SQL script: SET LINESIZE 180; COLUMN "KB Name" FORMAT A15; COLUMN "File Path" FORMAT A30; COLUMN "Topic Tree" FORMAT A15; COLUMN "Sample Set" FORMAT A20; COLUMN "Date Performed" FORMAT A30; SELECT kb.name AS "KB Name", kb.kbfilepath AS "File Path", ct.name AS "Topic Tree", ss.name AS "Sample Set", sskb.intent AS "Intent 0 or 1", sskb.dateperformed AS "Date Performed" FROM ccq.knowledgebase kb, ccq.sampleset ss, ccq.samplesetknowledge sskb, ccq.contenttree ct WHERE kb.pkey = sskb.knowledgebase_key AND sskb.sampleset_key = ss.pkey AND ss.contenttree_key = ct.pkey ORDER BY sskb.intent ASC, sskb.dateperformed DESC; For a DB2 database, run the following SQL script: SELECT kb.name, kb.kbfilepath, ct.name, ss.name, sskb.intent, sskb.dateperformed FROM ccq.knowledgebase kb, ccq.sampleset ss, ccq.samplesetknowledge sskb, ccq.contenttree ct WHERE kb.pkey = sskb.knowledgebase_key AND sskb.sampleset_key = ss.pkey AND ss.contenttree_key = ct.pkey ORDER BY sskb.intent ASC, sskb.dateperformed DESC Remove unused servers Before migrating your 7.0 system, you should remove the servers that are no longer used in Avaya IC 7.1. To do so: 1. On the primary 7.0 administration machine, open the 7.0 IC Manager. 2. Go to the Servers tab and select All Domains in the left-hand pane. Software Upgrade and Data Migration May

84 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to Delete all instances of the following servers: DataServerLegacy DialingKernel Dialer SoftDialer 4. Select Manager > Refresh. 5. Close IC Manager. Install Avaya IC 7.1 Before you begin the migration process, you need to install the Avaya IC 7.1 servers, the administration and design tools, and the license file on a set of new machines that meet the platform requirements for 7.1. For details about these platform requirements, see IC Installation Planning and Prerequisites. To install 7.1, follow the steps in IC Installation and Configuration and: Important: Install the 7.1 core servers on dedicated server machines. During the migration process, you will be migrating all of your 7.0 server settings, so you do not need to duplicate that information now. Just install 7.1 with the minimum information needed for each of the core servers.! Important: When IC Installation and Configuration instructs you to run the Configuration Tool and fill out the Initial Configuration tab: - Make sure you use the same ORB server port number that you used in 7.0. Otherwise, your 7.1 agent clients will not connect correctly. - Do NOT select the Start ORBServer option. The 7.1 servers should not be started until after you have migrated your 7.0 server settings. In addition, if your site uses Business Advocate, make sure you specify your 7.0 Business Advocate database when you run the Business Advocate Configuration Tool. Install the 7.1 administration and design tools on a dedicated administration machine. Install the new license file. After you have installed the software, look at the Patches directory on the 7.1 installation CD-ROM. If there are any patches in that directory, apply them as described in the associated patch Readme file. 84 Software Upgrade and Data Migration May 2009

85 Prepare the new administration machine for migration Install the 7.1 Avaya Agent applications You should never run 7.1 Avaya Agent applications with Avaya IC 7.0 servers. However, you can install the 7.1 agent applications on the same machines as your 7.0 agent applications without affecting the operation of 7.0. As long as you specify the same ORB server port number in 7.1 that you used in 7.0, the 7.1 agent applications will work with your migrated system without further alteration. Therefore, you can install the 7.1 agent applications in parallel with the rest of the migration procedure so that your agent machines will be ready once the migration is complete. Tip: Tip: When you have finished installing the 7.1 Avaya Agent, make sure the agents know that they should continue to use their old shortcut to log into the 7.0 system until further notice. After the migration is complete, they can being using their 7.1 shortcut immediately. For details about installing the 7.1 Avaya Agent application, see IC Installation and Configuration. Prepare the new administration machine for migration On the new 7.1 administration machine: 1. Avaya recommends that you make a backup copy of the entire: IC72_INSTALL_DIR\IC72\design directory and its subdirectories IC72_INSTALL_DIR\IC72\etc directory 2. Create a migration directory that you can use to store the original 7.0 design files and their migrated counterparts. The examples in this section use the directory IC72_INSTALL_DIR\IC71-migration. 3. Under this migration directory, create the following subdirectories: design\custom-71-files design\oob-71-files design\new-72-files etc Software Upgrade and Data Migration May

86 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to Copy the following files from the old 7.0 administration machine: Source Directory on 7.0 Administration machine Files to copy Destination Directory on 7.1 Administration machine IC71_INSTALL_DIR\IC71\ design\callcenterq IC71_INSTALL_DIR\IC71\ design\repository IC71_INSTALL_DIR\IC71\ etc ccq.adc ccq.adf ccq.adl ccq.alm repository.adc repository.adf repository.adl repository.alm ds.ffd vesp.imp IC72_INSTALL_DIR\ IC71-migration\design\ custom-71-files IC72_INSTALL_DIR\ IC71-migration\design\ custom-71-files IC72_INSTALL_DIR\ IC71-migration\etc 5. For your convenience, the 7.0 out-of-the-box ADL files are installed with 7.1. To migrate your customized ADL files, you need to copy the out-of-the-box ADL files into the migration folder and rename them as shown: Source File IC72_INSTALL_DIR\IC72\design\ CallCenterQ\ccq_70.adl IC72_INSTALL_DIR\IC72\design\ repository\repository_70.adl Copy and Rename As IC72_INSTALL_DIR\IC71-migration\ design\oob-71-files\ccq.adl IC72_INSTALL_DIR\IC71-migration\ design\oob-71-files\repository.adl Important:! Important: You must rename the out-of-the-box files as ccq.adl and repository.adl or the ADL migration procedure will not work. Upgrade customized IC Scripts and workflows Your customized 7.0 IC Scripts and workflows will continue to work in 7.1. However, Avaya recommends that you reapply your customizations to the out-of-the-box files in order to take advantage of the bug fixes included in 7.1. You can find a list of changed files in IC Script changes on page 115 and Workflow changes on page Software Upgrade and Data Migration May 2009

87 Copy customized website, Avaya Agent layouts, and EDU Viewer stylesheets In order to minimize the amount of time that your production system will be shut down, Avaya recommends that you install an out-of-the-box version of 7.1 and use that to test your customized IC Scripts and workflows. To upgrade your IC Script and workflow files: 1. Set up an out-of-the-box 7.1 test system. 2. Merge your customizations with the out-of-the-box IC Script and workflow files that have changed since 7.0. For the names of the changed files, see Detailed changes to the IC Scripts and workflows on page Copy all customized IC Script and workflow files into your 7.1 test system. 4. Verify that all of your customized files work the way you expect. 5. When you are sure that everything is working, copy your verified IC Script and workflow files to the appropriate 7.1 directories. The directory structure between 7.0 and 7.1 has not changed, so you can copy these files from where they exist in 7.0 to the equivalent directory in 7.1 Copy customized website, Avaya Agent layouts, and EDU Viewer stylesheets No changes have been made to the website files, Avaya Agent layout (CDL) files, or EDU View stylesheets between 7.0 and 7.1. Therefore you can copy your customized files from 7.0 directly into 7.1 as shown below: Copy... IC71_INSTALL_DIR\IC71\ comp\website\*.* IC71_INSTALL_DIR\IC71\ design\qconsole\*.cdl and *.XSL To... IC72_INSTALL_DIR\IC72\comp\website IC72_INSTALL_DIR\IC72\design\QConsole Upgrade website Java methods If your customized website pages use any Java 1.3 methods that are no longer supported in 1.4.2, you need to upgrade those pages to use supported methods. For a list of supported Java methods, see Software Upgrade and Data Migration May

88 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to 7.1 Migrate your ADL files Database Designer includes a Database Migration tool that you can use to merge the customizations in your existing CallCenterQ and Repository ADL and ADF files with the updated ADL and ADF files in release 7.1 of Avaya IC. dialer.adl was used for Outbound Contact Management and cannot be migrated to 7.1. This section includes the following topics: Actions performed by Database Migration tool on page 88 Prerequisites on page 89 Verify the size of varchar fields for Oracle databases on page 90 Migrate ccq.adl on page 90 Migrate repository.adl on page 92 Move the migrated files to 7.1 on page 93 Actions performed by Database Migration tool The following table describes the action performed by the Database Migration tool during the comparison of the ADL files. Source out-of-the-box 7.0 ADL file Source Customized ADL file New out-of-the-box 7.1 ADL file Action performed Component does not exist Component does not exist Component does not exist Component exists Component does not exist Component exists Component exists Component does not exist Adds component to the new customized ADL file. Adds component to the new customized ADL file. Component exists Component exists Asks you to select one of the existing components to add to the new customized ADL file. Component does not exist Component does not exist Does not copy the component to the new customized ADL file. 88 Software Upgrade and Data Migration May 2009

89 Migrate your ADL files Source out-of-the-box 7.0 ADL file Source Customized ADL file New out-of-the-box 7.1 ADL file Action performed Component exists Component does not exist Component exists Component exists Component exists Component does not exist Adds the component to the new customized ADL file and advises you that you need to manually remove this component if desired. Advises you that the customized component was added to the new customized ADL file. Component exists Component exists Component exists Asks you to select one of the components to add to the new customized ADL file. Form exists Form does not exist Form does not exist Does not copy the form to the new customized ADL file. Form exists Form does not exist Form exists Does not copy the form to the new customized ADL file. Form exists/form does not exist Form exists/form does not exist Form exists Form does not exist Adds the form from customized ADL file to the new customized ADL file. Also adds a message to the log file. Form exists Form Exists Adds the form from customized ADL file to the new customized ADL file. Form does not exist Form does not exist Form exists Adds the form to the new customized ADL file. Also adds a message to the log file. For all versions of Avaya IC, you need to migrate ccq.adl and repository.adl. Prerequisites The ADL migration tool can only save the new ADL file using the same fully-qualified filename as the original ADL file. Therefore, you have to save the migrated ADL file to the output directory you created in Prepare the new administration machine for migration on page 85. These examples use the directory: IC72_INSTALL_DIR\IC71-migration\design\new-72-files Software Upgrade and Data Migration May

90 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to 7.1 After the ADL migration tool is finished, you can then copy the files from the design\ new-72-files directory to the appropriate IC72_INSTALL_DIR\IC72\design directory, overwriting the out-of-the-box files. Verify the size of varchar fields for Oracle databases For Oracle databases, the column size for varchar fields cannot be larger than To support UTF-8 on Oracle 9i, Database Designer increases the size of every char and varchar field by three times during a configure or reconfigure operation. If you define a field of varchar size x in an ADL file, the equivalent SQL generated by Database Designer will create a varchar field in the Oracle database table as 3x. The maximum size for a varchar field in Oracle 9i is Therefore, the maximum size that Database Designer can put for a custom varchar field in the ADL file is: 3999 divided by 3 = 1333 A custom varchar field that is larger than 1333 will cause Oracle errors when Database Designer attempts to configure or reconfigure a database. For example, if you define a custom varchar field of size 1980, during reconfigure Database Designer will attempt to add a varchar field of size 1980 x 3 = This attempt will fail and cause Oracle errors. Migrate ccq.adl To migrate your ccq.adl file, on the new 7.1 administration machine: 1. Open the 7.1 Database Designer, but do not open an ADL file in Database Designer. Important:! Important: The Database Migration tool will not start if you have an ADL file open in Database Designer. You must close all ADL files before you attempt to migrate customized ADL files. 90 Software Upgrade and Data Migration May 2009

91 Migrate your ADL files 2. Select Tools > Database Migration. Database Designer displays the Choose ADL Files dialog box: 3. In the Choose ADL Files dialog box: a. Select the Ellipsis ( ) button next to the Source out-of-the-box ADL file field and navigate to the directory containing the out-of-the-box 7.0 ccq.adl file. (Default location: IC72_INSTALL_DIR\IC71-migration\design\oob-71-files.) Select the ccq.adl file and select Open. Tip: Important: Tip: You can also cut and paste the fully-qualified directory name into all of the fields in this dialog box. b. Select the Ellipsis ( ) button next to the Source customized ADL file field and navigate to the directory containing the customized 7.0 ccq.adl file. (Default location: IC71_INSTALL_DIR\IC71\design\custom-71-files.) Select the appropriate ADL file and select Open. c. Select the Ellipsis ( ) button next to the New out-of-the-box ADL file field and navigate to the directory containing the out-of-the-box 7.1 ADL file. (Default location: IC72_INSTALL_DIR\IC72\design\CallCenterQ.) Select the ccq.adl file and select Open. d. Select the Ellipsis ( ) button next to the New customized ADL file field and navigate to the directory where you want the Database Migration tool to save the migrated ADL file. (Default location: IC72_INSTALL_DIR\IC71-migration\ design\new-72-files.) Select OK and then add the filename ccq.adl to the end of that path.! Important: You must use ccq.adl as the name of the ADL file. e. Select OK. Software Upgrade and Data Migration May

92 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to As the Database Migration tool compares the ADL files, review and respond to all information messages. (For more information about why the Database Migration tool prompts you for a decision, see Migrate your ADL files on page 88.) When the Database Migration tool finishes, it writes the migrated ADL and ADF files, and the out-of-the-box 7.1 ADC file, to the specified output directory. 5. After the Database Migration tool has merged the ADL files: a. Review the ccq.txt log file in the output directory for details about the ADL file migration. b. Open the new customized ADL file in Database Designer and verify that your customizations were properly migrated. Migrate repository.adl To migrate your repository.adl file: 1. Open Database Designer, but do not open an ADL file in Database Designer. Important: Tip:! Important: The Database Migration tool will not start if you have an ADL file open in Database Designer. You must close all ADL files before you attempt to migrate customized ADL files. 2. Select Tools > Database Migration. 3. In the Choose ADL Files dialog box: a. Select the Ellipsis ( ) button next to the Source out-of-the-box ADL file field and navigate to the directory containing the out-of-the-box 7.0 repository.adl file. (Default location: IC72_INSTALL_DIR\IC71-migration\design\ oob-71-files.) Select the repository.adl file and select Open. Tip: You can also cut and paste the fully-qualified directory name into all of the fields in this dialog box. b. Select the Ellipsis ( ) button next to the Source customized ADL file field and navigate to the directory containing the customized 7.0 repository.adl file. (Default location: IC72_INSTALL_DIR\IC71-migration\design\ custom-71-files.) Select the appropriate ADL file and select Open. c. Select the Ellipsis ( ) button next to the New out-of-the-box ADL file field and navigate to the directory containing the out-of-the-box 7.1 ADL file. (Default location: IC72_INSTALL_DIR\IC72\design\repository.) Select the repository.adl file and select Open. 92 Software Upgrade and Data Migration May 2009

93 Migrate your ADL files d. Select the Ellipsis ( ) button next to the New customized ADL file field and navigate to the directory where you want the Database Migration tool to save the migrated ADL file. (Default location: IC72_INSTALL_DIR\IC71-migration\ design\new-72-files.) Select OK and then add the filename repository.adl to the end of that path. Important:! Important: You must use repository.adl as the name of the ADL file. e. Select OK. 4. As the Database Migration tool compares the ADL files, review and respond to all information messages. (For more information about why the Database Migration tool prompts you for a decision, see Migrate your ADL files on page 88.) When the Database Migration tool finishes, it writes the migrated ADL and ADF files, and the out-of-the-box 7.1 ADC file, to the specified output directory. 5. After the Database Migration tool has merged the ADL files: a. Review the repository.txt log file in the output directory for details about the ADL file migration. b. Open the new customized ADL file in Database Designer and verify that your customizations were properly migrated. Move the migrated files to 7.1 Once you have successfully migrated your ADL files, you need to move them, along with the ADF and ADC files, to the 7.1 design directories, as shown below: Move... IC72_INSTALL_DIR\IC71-migration\ design\new-72-files\ccq.* IC72_INSTALL_DIR\IC71-migration\ design\custom-71-files\ccq.adc and ccq.alm IC72_INSTALL_DIR\IC71-migration\ design\new-72-files\repository.* IC72_INSTALL_DIR\IC71-migration\ design\custom-71-files\ repository.adc and repository.alm To... IC72_INSTALL_DIR\IC72\design\ CallCenterQ IC72_INSTALL_DIR\IC72\design\ CallCenterQ IC72_INSTALL_DIR\IC72\design\ repository IC72_INSTALL_DIR\IC72\design\ repository Software Upgrade and Data Migration May

94 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to 7.1 Migrate your Avaya IC 7.0 servers To migrate your servers to 7.1: 1. Copy the ds.ffd and vesp.imp files from IC71_INSTALL_DIR\IC71\etc on the primary 7.0 server machine to IC72_INSTALL_DIR\IC72\etc on the new 7.1 administration machine, overwriting the existing 7.1 files. If you are copying the files via FTP, make sure that you transfer them in ASCII mode. 2. On the new 7.1 administration machine, open a command prompt, navigate to IC72_INSTALL_DIR\IC72\bin, and run FixConfigFiles.exe. 3. Read the warning about pre-requisite patches. If all pre-requisite patches have been applied as described in Install Avaya IC 7.1 on page 84, click OK. 4. In the Files location dialog box, enter the path to the ds.ffd file you just copied to IC72_INSTALL_DIR\IC72\etc and click OK. The default path is C:\Program Files\Avaya\IC71\etc. 94 Software Upgrade and Data Migration May 2009

95 Migrate your Avaya IC 7.0 servers 5. The following screenshot shows the FixConfigFiles tool: 1 2 Figure notes: 1. The left-hand pane allows you to update the paths in the current ds.ffd and vesp.imp files 2. The right-hand pane allows you to update the IP addresses in the current ds.ffd and vesp.imp files 6. In the left-hand pane: a. Click on the first entry in the list. The tool automatically copies the path to the Path in OLD server configuration files field. b. Enter the new path in the Path in NEW server configuration files field. Important:! Important: Verify that this path is correct relative to the machine on which the servers are installed, not relative to the administration machine. Do not mix backslashes "\" and forward slashes "/" in the path name. If your servers are running on a Windows platform, you need to use all backslashes. If your servers are running on UNIX, you need to use all forward slashes. Software Upgrade and Data Migration May

96 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to 7.1 c. If you want to change all servers to use this path, select the Change all paths to the same value checkbox. Tip: Tip: If you want to change most of your 7.0 paths to the same value, enter the value you want to use for the majority of the paths in the Path in 7.1 server configuration files field and select this checkbox. You can then change the other fields individually before the final conversion. d. Click Update. FixConfigFiles displays the updated path in the New paths column. e. If you are updating the paths individually, click on the next entry in the list and repeat this procedure until all paths have been updated. f. When all paths have the correct 7.1 information in the New paths column, click GO! in the left-hand pane. FixConfigFiles generates new vesp.imp and ds.ffd files in the etc directory under IC72_INSTALL_DIR\IC72\. 7. In the right-hand pane: a. Click on the first entry in the list. The tool automatically copies the path to the IP in OLD server configuration files field. b. Enter the new IP address in the IP in NEW server configuration files field. c. Click Update. FixConfigFiles displays the updated IP address in the New IP addresses column. d. Click on the next entry in the list and repeat this procedure until all IP addresses have been updated. e. When all IP addresses have the correct 7.1 information in the New IP addresses column, click GO! in the right-hand pane. FixConfigFiles generates new vesp.imp and ds.ffd files in IC72_INSTALL_DIR\IC72\etc. Start the 7.1 core servers To complete the server migration process: 1. Copy the new vesp.imp and ds.ffd files in IC72_INSTALL_DIR\IC72\etc to all server machines that are running a Directory server, overwriting any existing files. If you are copying the files via FTP, make sure that you transfer them in ASCII mode. 2. Copy the new vesp.imp file in IC72_INSTALL_DIR\IC72\etc to all other server machines, overwriting any existing files. If you are copying the file via FTP, make sure that you transfer it in ASCII mode. 96 Software Upgrade and Data Migration May 2009

97 Shut down Start the Avaya IC 7.1 core servers using the icadmin so command on the primary server machine. You can either run icadmin so from the command line of the server s host machine, or you can run icadmin so <hostname> if your host has multiple network interface cards. For details, see IC Administration Volume 1: Servers & Domains. 4. If the servers start, continue with Shut down 7.0 on page 97. If the icadmin command encounters errors, see Troubleshooting on page 97. Troubleshooting If the 7.1 servers do not start after migration, verify that: The 7.1 paths you specified are correct relative to the server machine on which the ds.ffd file resides. If you find a path problem, rerun FixConfigFiles, specifying the new path. All servers have a valid path to their executable file defined in the 7.0 IC Manager. If you find a problem, either fix the path or delete that server from IC Manager and select Manager > Refresh. Then copy the updated ds.ffd file to the administration machine and rerun FixConfigFiles. Shut down 7.0 After you have verified that your customized IC Scripts, workflows, website files, and EDU Viewer stylesheets work in your 7.1 test system, as described in Upgrade customized IC Scripts and workflows on page 86, you can begin migrating your 7.0 servers and Avaya Agent applications. In order to do so, Avaya IC 7.0 must be shut down and the system will not be available to agents until the migration process is complete. To shut down 7.0: 1. Stop all Avaya Agent applications. 2. Stop all Avaya IC servers: a. Go to the server machine running the Primary ORB server. b. For Windows, open a command prompt, navigate to IC71_INSTALL_DIR\IC71\ bin, and run icadmin tva <Username> <PW>. c. For Solaris or AIX, navigate to IC71_INSTALL_DIR/IC71/bin and run./icadmin tva <Username> <PW>. d. Make sure that you wait until all Avaya IC servers have been shut down. Software Upgrade and Data Migration May

98 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to Stop and disable all of the Avaya IC Website servers and services, including the Avaya IC CIRS Service, Avaya IC ICM Service, Avaya IC ORB Service, Avaya IC Web Management Service, Avaya IC WebLM Service, and Avaya Voice Media Manager. For details, see IC Installation and Configuration. 4. If your site uses Business Advocate, stop all Business Advocate services. Reconfigure your 7.1 databases In order to migrate your 7.0 databases to 7.1, you need to reconfigure them. In order to do so, you will need an IC Manager login and password for an account with Administrator authority. All configurations of Avaya IC require you to upgrade your IC Repository and CallCenterQ database. For details, see Reconfigure the IC Repository database on page 98 and Reconfigure the CallCenterQ database on page 100. Reconfigure the IC Repository database If you need to determine how many rows of data are in your IC Repository database, you can use the following SQL statements to get a record count: : select count(*) from agentsegment select count(*) from routingevent select count(*) from mediainteraction select count(*) from contact select count(*) from mediasegment To reconfigure your 7.0 IC Repository database for 7.1: 1. Start the 7.1 Database Designer and open IC72_INSTALL_DIR\IC72\design\ repository\repository.adl. Tip: Tip: If you are using a localized Avaya IC environment, you will need to enable your 7.1 Database Designer to handle the localized files. For details, see the IC Database Designer User Guide. 2. On the Properties tab in the right-hand pane, make sure that the IC72_INSTALL_DIR\ IC72\design\common and IC72_INSTALL_DIR\IC72\design\QConsole directories are displayed in the Upload scripts from these directories box. If not, add them so that all of the required IC Scripts will be pushed to the database. 3. Expand Components > Physical DB Connections and select repositorydbconnection in the tree pane. 98 Software Upgrade and Data Migration May 2009

99 Reconfigure your 7.1 databases 4. Verify that the connection information is correct. For details, see IC Installation and Configuration. The Database Name and Database Server should point to your 7.0 database. 5. If your database has less than 3 million rows and you are going to reconfigure it in Database Designer: a. Make a note of the current Timeout parameter so that you can reset it after the reconfigure. b. Set the Timeout parameter to at least 7200 seconds. 6. Save the ADL file using File > Save. 7. Select File > Database Administration. 8. Select the Reconfigure option button. 9. Enable the Recreate Stored Procedures check box to update the database with the 7.1 database schema. 10. If necessary, enter your IC Manager Administrator username and password in the appropriate fields. (Do not enter your DBA username and password.) 11. If your database has over 3 million rows or you want to test this procedure, select Test. Instead of reconfiguring the database, Database Designer lists all of the SQL statements needed to reconfigure the database in the Status Messages section. You can cut and paste the statements into an ASCII text editor, modify the SQL statements as needed, and run the modified statements against the IC Repository database using your database administration tools. (For details, see the IC Database Designer User Guide.) Otherwise, select OK. Database Designer reconfigures the database. CAUTION:! CAUTION: If the reconfigure reports any errors, such as a mttbinary: :timeout execute error, it is possible that the data has not been properly migrated and you will need to restore the database from a backup. Tip: Tip: Avaya recommends that you save the reconfigure SQL. 12. When Database Designer is finished, select Close. 13. If you increased the Timeout parameter in step 5, reset it to its previous value. 14. Save and close the ADL file. 15. If you selected Test in step 11, modify the generated SQL statements and apply them to the IC Repository database using your database administration tools. Software Upgrade and Data Migration May

100 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to 7.1 Reconfigure the CallCenterQ database If you need to determine how many rows of data are in your CallCenterQ database, you can use the following SQL statements to get a record count: Select count (*) from qem_message Select count (*) from qem_messagestatlog Select count (*) from w_chat_transcript In addition, if your CallCenterQ database is on Oracle, you should include the following command: Select count (*) from qw_text To reconfigure your 7.0 CallCenterQ database for 7.1: 1. Open IC72_INSTALL_DIR\IC72\design\CallCenterQ\ccq.adl in Database Designer. 2. On the Properties tab in the right-hand pane, make sure that the IC72_INSTALL_DIR\ IC72\design\common and IC72_INSTALL_DIR\IC72\design\QConsole directories are displayed in the Upload scripts from these directories box. If not, add them so that all of the required IC Scripts will be pushed to the database. 3. Expand Components > Physical DB Connections and select ccqconnection in the tree pane. 4. Verify that the connection information is correct. For details, see IC Installation and Configuration. The Database Name and Database Server should point to your 7.0 database. 5. If your database has less than 3 million rows and you are going to reconfigure it in Database Designer: a. Make a note of the current Timeout parameter so that you can reset it after the reconfigure. b. Set the Timeout parameter to at least 7200 seconds. 6. Save the ADL file using File > Save. 7. Select File > Database Administration. 8. Select the Reconfigure option button. 9. Enable the Recreate Stored Procedures check box to update the database with the 7.1 database schema. 10. If necessary, enter your IC Manager Administrator username and password in the appropriate fields. (Do not enter your DBA username and password.) 100 Software Upgrade and Data Migration May 2009

101 Generate your applications 11. If your database has over 3 million rows or you want to test this procedure, select Test. Instead of reconfiguring the database, Database Designer lists all of the SQL statements needed to reconfigure the database in the Status Messages section. You can cut and paste the statements into an ASCII text editor, modify the SQL statements as needed, and run the modified statements against the CallCenterQ database using your database administration tools. (For details, see the IC Database Designer User Guide.) Otherwise, select OK. Database Designer reconfigures the database. CAUTION:! CAUTION: If the reconfigure reports any errors, such as a mttbinary: :timeout execute error, it is possible that the data has not been properly migrated and you will need to restore the database from a backup. Tip: Tip: Avaya recommends that you save the reconfigure SQL. 12. When Database Designer is finished, select Close. 13. If you increased the Timeout parameter in step 5, reset it to its previous value. 14. Save and close the ADL file. 15. If you selected Test in step 11, modify the generated SQL statements and apply them to the CallCenterQ database using your database administration tools. Generate your applications! CAUTION: CAUTION: If you have customized any of the 7.1 IC Scripts, make sure that you have tested your customizations as described in Upgrade customized IC Scripts and workflows on page 86 before you push them to your production database. For all versions of Avaya IC, you need to generate the interaction_center application in the ccq.adl file and the repository application in the repository.adl file. Avaya recommends that you also generate the reportwizard application in the repository.adl file. (For details about generating applications, see the IC Database Designer User Guide.) Optionally, if you are using Business Advocate or List Management, you can generate the listq application in the ccq.adl file. To regenerate your applications: 1. In Database Designer, select File > Generate Windows Application. 2. Regenerate the interaction_center application, making sure that you push all IC Scripts and Avaya Agent layout (CDL) files to the database. Software Upgrade and Data Migration May

102 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to Regenerate the repository application, making sure that you push all IC Scripts to the database. 4. Optionally regenerate the reportwizard and listq applications, making sure that you push all IC Scripts to the database. Tip: Tip: The reportwizard application also has a help file that you should push to the database as well. (Default location: IC72_INSTALL_DIR\IC72\help\ ReportWizard\Reports.chm.) Upgrade the 7.0 data to 7.1 In order to upgrade your data to 7.1, you need to: Import the 7.1 seed data on page 102 Import creationrules and fieldexpressions data on page 103 Add the new default logout code on page 104 Import the 7.1 seed data To import the new seed data for 7.1: 1. Open a command prompt and navigate to IC72_INSTALL_DIR\IC72\design\ CallCenterQ\delta. 2. Open migrate_seed.cfg in an ASCII editor such as Notepad and verify that the administration login ID and password are correct. 3. Save and close the migrate_seed.cfg file. 4. Run migrate_seed.bat. Import the localization seed data If you are migrating a localized version of Avaya IC: 1. Make sure that you have the localized version of Avaya IC Open a command prompt and navigate to IC72_INSTALL_DIR\IC72\design\ CallCenterQ\delta. 3. Open migrate_l10n_seed.cfg in an ASCII editor such as Notepad and verify that the administration login ID and password are correct. 102 Software Upgrade and Data Migration May 2009

103 Upgrade the 7.0 data to Save and close the migrate_l10n_seed.cfg file. 5. Run migrate_l10n_seed.bat. Import creationrules and fieldexpressions data You need to remove the 7.0 mapping rules stored in the current creationrules and fieldexpressions tables, import the new 7.1 mapping rules, and then recreate any customized mapping rules. To do so: 1. Identify any customizations you have made to the creationrules and fieldexpressions tables in the Repository database. 2. Use your database administration tools to make a backup of these two tables so that you can use this information to help you recreate your customizations later. 3. Delete all records from the creationrules and fieldexpressions tables using your database administration tools. 4. Close your database administration tools. 5. In an ASCII editor such as Notepad, open IC71_INSTALL_DIR\IC71\design\ repository\data\seed.cfg and: a. Make sure that the DestinationLogin and DestinationPasswd properties match a 7.1 IC Manager login with administrator privileges. b. In the Tables section, comment out all Table=<tablename> lines except for: Table=fieldexpressions Table=creationrules To do so, add a number sign and a space (# ) in the first column of each Table=<tablename> row. c. Save and close the file. 6. Run IC72_INSTALL_DIR\IC72\design\repository\data\import_seed.bat. 7. Return to your database administration tool and recreate any customizations you made in 7.0, using the backup you made in Step 2 as a guide. Software Upgrade and Data Migration May

104 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to 7.1 Add the new default logout code The 7.1 seed data includes a new logout reason code with Name = 1. By default, this code is associated with the agent property Agent/Desktop/LogoutNotAvailableReasonCode. If your site uses logout codes and you have not already customized the logout code associated with this agent property, you can add the new default logout code to your database. To do so: 1. Open IC Manager. 2. Select Tools > Codes. 3. In the left-hand pane, navigate to Default Tenant > SystemAuxGroup > Logout Codes. 4. Select Codes > New and enter the following information: Field Name Definition Name 1 Display Name Description Reason Not Available There is no reason available. 5. Select OK. Load the new workflows! CAUTION: CAUTION: If you have customized any of the 7.1 workflows, make sure that you have tested your customizations as described in Upgrade customized IC Scripts and workflows on page 86 before you push them to your production database. To load the new workflows: 1. Open the 7.1 Workflow Designer. 2. Recompile all customized 7.1 workflows. 3. Upload them to the database. For details, see Avaya Workflow Designer User Guide. 104 Software Upgrade and Data Migration May 2009

105 Migrate your server settings into 7.1 Migrate your server settings into 7.1 In order to migrate your server settings, you first need to restart the Directory server and create a new agent administrator account. To do so: 1. Open the 7.1 IC Manager. 2. Stop and then restart the Directory server. 3. Select Manager > Refresh. 4. Add a new Administrator account that can be used as a secondary login for IC Manager in case the regular Administrator account encounters any login-related issues during the migration process. To do so: a. Select the Agent tab. b. In the left pane, select the Default workgroup. c. Select Agent > New. IC Manager displays the Agent Editor dialog box. d. Enter required basic information for the agent record. The login ID you select should be the install user for the Avaya IC software. e. Select the Security tab and set a password for this account. In the Agent Roles section, select the Administrator check box. Important:! Important: Avaya recommends that you have a backup Administrator account in case of any unforeseen login issues. If you cannot log into IC Manager using any of your administrator accounts, you need to review the icmanager_admin.log for database errors or disabled login. Import your server settings To import your server settings into 7.1: 1. In the 7.1 IC Manager, select Manager > Options. IC Manager displays the Options dialog box. 2. Select the Environment tab. 3. Hold the Ctrl+Alt keys and double-click the left mouse button anywhere on this dialog. 4. IC Manager displays a new button called XML Maintenance under the Export Configuration button. 5. Select XML Maintenance. 6. In the XML Record Maintenance dialog box, select server.xsd and select Import. Software Upgrade and Data Migration May

106 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to In the File Chooser, select the server.xsd file from IC72_INSTALL_DIR\IC72\etc. 8. Select OK to return to the Options dialog box. 9. Select Import Configuration. 10. In the File Chooser, select the sc.xml file from IC72_INSTALL_DIR\IC72\etc. IC Manager should display a message stating that the sc.xml file has been successfully validated. 11. Select OK to import the server settings. 12. Select OK to close the Options dialog box. 13. Exit from IC Manager and then restart it so that it reads the updated configuration information. Tip: Tip: If the administrator account is locked out of IC Manager, use the back up account you created in Migrate your server settings into 7.1 on page 105 to log in and unlock the primary account. For information about unlocking an account, see IC Administration Volume 2: Agents, Customers, & Queues. Update the web configuration To update the web configuration, you need to run the Configuration tool on all Avaya IC server machines. To do so: 1. On an Avaya IC server machine, start the Configuration Tool by selecting Start > Programs > Avaya Interaction Center 7.1 > Configuration Tool. 2. Select the Web tab. 3. Change the path in the JDK Home field to point to the new JDK version 1.4.2_08. For Windows, the default path is C:\j2sdk1.4.2_08. For Unix, the default path is /usr/java Change the Web Server Host field to point to the 7.1 web server machine. 5. Click Apply Settings. 6. Click Exit. 7. Repeat this procedure for another Avaya IC server machine as needed. For details about running the Configuration Tool, see IC Installation and Configuration. 106 Software Upgrade and Data Migration May 2009

107 Update server and agent properties Update server and agent properties For details about upgrading your server and agent properties to match 7.1, see: Update existing server properties on page 107 Set new properties for existing servers on page 109 Remove links to 7.0 Resource Manager servers on page 110 Update the Chat transcript directory on page 110 Import new agent properties on page 110 Update existing agent properties on page 111 Migrate long text property fields on page 111 Update existing server properties Some server properties need to be migrated by hand. To do so: 1. In the 7.1 IC Manager, select the Servers tab. 2. Select All Domains in the left-hand pane. 3. Double click each Attribute server to open the Server Editor and: a. Go to the Attribute tab. b. Click the Ellisis (...) button in the ICM Servers field. c. Update the name and domain of the ICM server to as required for 7.1. d. Click OK to close the Server Editor. e. Repeat this procedure for all Attribute servers defined in your Avaya IC system. 4. If you use Content Analyzer, double click each CAAdmin server to open the Server Editor and: a. Go to the CAAdmin tab. b. If required, update the path in the Path to NLP Data field. c. Click OK to close the Server Editor. d. Repeat this procedure for all CAAdmin servers defined in your Avaya IC system. 5. If you use Content Analyzer, double click each CAServer server to open the Server Editor and: a. Go to the CAServer tab. b. If required, update the path in the Path to NLP Data field. Software Upgrade and Data Migration May

108 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to 7.1 c. Click Knowledge Base and update the name or path of the associated Knowledge Base as needed. d. Click OK to close the Knowledge Base dialog box. e. Click OK to close the Server Editor. f. Repeat this procedure for all CAServer servers defined in your Avaya IC system. 6. Double click each ComHub server to open the Server Editor and: a. Go to the ComHub tab. b. Update the host name in the the Host Name field to point to the 7.1 ComHub server machine. c. Click OK to close the Server Editor. d. Repeat this procedure for all ComHub servers defined in your Avaya IC system. 7. Double click each Java Application Bridge server to open the Server Editor and: a. Go to the JavaAppBridge tab. b. Enter the name of the agent account for this server in the the IC User field. c. Enter the password for the agent account in the the IC Password field. d. Click OK to close the Server Editor. e. Repeat this procedure for all Java Application Bridge servers defined in your Avaya IC system. 8. Edit the License server to point to the new hostname. 9. Double click each License server to open the Server Editor and: a. Go to the License Server tab. b. Click the Ellisis (...) button in the WebLM Server URLs field. c. For each WebLM server, update the URL. You need to: Change the host name to point to the appropriate 7.1 WebLM server Change the directory name weblm to WebLM Click OK to save your changes to that URL Repeat this procedure for each WebLM server defined in the Avaya IC system. d. Click OK to close the Server Editor. e. Repeat this procedure for all License servers defined in your Avaya IC system. 10. Double click each Paging server to open the Server Editor and: a. Go to the Paging tab. b. Update the host name in the the Host Name field to point to the 7.1 Paging server machine. 108 Software Upgrade and Data Migration May 2009

109 Update server and agent properties c. Update the ComHub host name in the the ComHub Host Name field to point to the 7.1 ComHub server machine. d. Click OK to close the Server Editor. e. Repeat this procedure for all Paging servers defined in your Avaya IC system. 11. If you use Business Advocate, double click on each Resource Manager server and: a. Go to the Resource Manager tab. b. Make sure that the LRM field is set to a valid 7.1 Logical Resource Manager. c. Click OK to close the Server Editor. 12. Double click each WebACD server to open the Server Editor and: a. Go to the WACD tab. b. Update the host name in the the Host Name field to point to the 7.1 WebACD server machine. c. Update the Web Administration server name in the the WACD Webserver field to point to the 7.1 server machine that hosts the Web Administration pages. d. Update the ComHub host name in the the ComHub Host Name field to point to the 7.1 ComHub server machine. e. Click Apply. f. Go to the Configuration tab. g. If necessary, update the name of the server in the servername property. h. Click Apply. i. Click OK to close the Server Editor. j. Repeat this procedure for all WebACD servers defined in your Avaya IC system. Set new properties for existing servers Some of the properties for following servers have been added or changed in 7.1: ADU server Alarm server Advocate server Report server Telephony (TS) servers Telephony Queue Statistics (TSQS) servers Software Upgrade and Data Migration May

110 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to 7.1 For details about the new properties, see IC Administration Volume 1: Servers & Domains. Once you have read about the changes, you can use the Server Editor in IC Manager to set the properties as desired. Remove links to 7.0 Resource Manager servers If your site uses Business Advocate and the name of any server machine hosting one or more Resource Manager servers has changed, remove the reference to those servers from the Business Advocate Component Manager. To do so: 1. Open the 7.1 Business Advocate Administration Tool. 2. In the left-hand pane, expand the Advocate Component Manager placeholder. 3. Right click on the first link to a 7.0 Resource Manager server and select Delete. 4. Confirm the deletion at the prompt. 5. Repeat steps 3 and 4 for each link to a 7.0 Resource Manager server. 6. If necessary, add the migrated 7.1 Resource Manager servers. 7. For each 7.1 server, make sure that its role is correct. 8. Close the Business Advocate Administration Tool. Update the Chat transcript directory If your installation uses the Chat feature, you need to update the path to the Chat transcript directory. To do so: 1. Open the 7.1 IC Manager and select the Configuration tab. 2. From the Tables list in the left-hand pane, select Chat > ICM. 3. In the right-hand pane, change the path for the Chat Transcript Directory to point to your 7.1 installation. Import new agent properties To import the new agent properties into your migrated system: 1. Open a command prompt and navigate to IC72_INSTALL_DIR\IC72\design\ repository\data. 2. Open import_properties.bat in an ASCII editor such as Notepad and verify that the administration login ID and password are correct. 110 Software Upgrade and Data Migration May 2009

111 Update server and agent properties 3. Save and close the file. 4. Run import_properties.bat. 5. To see the new properties, open IC Manager. If IC Manager is already running, select Manager > Refresh. For details about all Avaya IC agent properties, see IC Administration Volume 2: Agents, Customers, & Queues. Update existing agent properties Some existing agent properties need to be updated before the agent clients will work properly in 7.1. The properties are: Property Section Property Name Change AgentDesktop/WebClient WorkingDirectory If the relative path to the agent working directory has changed, update this property. System/Configuration ChatLoginServer Update the path to the new 7.1 chat server. LoginServer Server Update the path to the new 7.1 server that handles logins. Update the path to the new 7.1 server. For details about changing these properties, see IC Administration Volume 2: Agents, Customers, & Queues. Migrate long text property fields In 7.0, if a property was specified as a long text field but contained fewer than 255 characters, Avaya IC would ignore the data type and save the property as a string. In 7.1, long text properties are always saved as long text no matter how many characters there are. To change all 7.0 long text properties to match their data type: 1. Make sure that all instances of IC Manager, Workflow Designer, and Database Designer are closed. 2. Open a command prompt and navigate to IC72_INSTALL_DIR\IC72\bin. 3. Open migratelt.bat in an ASCII editor such as Notepad and verify that the administration login ID and password are correct. Software Upgrade and Data Migration May

112 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to Save and close the file. 5. Run migratelt.bat. 6. To verify that the long text migration worked, examine the messages in IC72_INSTALL_DIR\IC72\logs\Admin.log. This log file contains an entry for each migrated record as well as the total number of records migrated. Migrate your Content Analyzer data If your Content Analyzer Knowledge Bases can be accessed through the same fully-qualified file path by the new 7.1 servers as was used by your old 7.0 servers, then all you need to do is: Bring up the Avaya IC 7.1 system Ensure that Content Analyzer works as expected If you need to move the Content Analyzer Knowledge Bases relative to the servers: 1. Make sure that all of the Knowledge Bases you identified in Prerequisites for migrating Content Analyzer on page 79 are stored in a directory on a machine that is accessible to any server machine that will be running a CAAdmin or CAServer server. Make a note of all the Knowledge Base names and file locations. If appropriate, consult your Content Analyzer Administrator for the approved location of the Knowledge Base files. 2. If you want to change any of your Knowledge Base file names, you should do so at this point. Make sure that you make a note of the old and new filenames so that you can change the File Location information when you configure the associated 7.1 CAServer.! Important: Important: Do not change the Knowledge Base name during the migration process. Any such changes should be done through IC Manager once the 7.1 system is up and running. 3. In the CallCenterQ database, change the file names and locations in the knowledgebase database table to reflect the new names and locations for your Knowledge Bases. To do so, run the following database-specific SQL script for each of the migrated Knowledge Bases. For SQL Server: 1. Open the SQL Server Query Analyzer. 2. Connect to the appropriate 7.1 CCQ database. 112 Software Upgrade and Data Migration May 2009

113 Migrate your Content Analyzer data 3. Run the following SQL script for each of the renamed or moved Knowledge Bases: USE ccq UPDATE knowledgebase SET knowledgebase.kbfilepath = 'Full_Destination_KB_Path' WHERE knowledgebase.name = 'KB_Name' AND knowledgebase.kbfilepath = 'Full_Source_KB_File_Path' For Oracle: Where Full_Destination_KB_Path is the fully-qualified location of the 7.1 Knowledge Base (including the file name), KB_Name is the Knowledge Base name, and Full_Source_KB_File_Path is the fully-qualified name of the corresponding 7.0 Knowledge Base. (Do not change the quotation marks.) 1. Use SQL Query to connect to the appropriate Oracle 7.1 Avaya IC database. 2. Run the following SQL script for each of the renamed or moved Knowledge Bases: For DB2: UPDATE ccq.knowledgebase SET knowledgebase.kbfilepath = 'Full_Destination_KB_Path' WHERE knowledgebase.name = 'KB_Name' AND knowledgebase.kbfilepath = 'Full_Source_KB_File_Path'; COMMIT; Where Full_Destination_KB_Path is the fully-qualified location of the 7.1 Knowledge Base (including the file name), KB_Name is the Knowledge Base name, and Full_Source_KB_File_Path is the fully-qualified name of the corresponding 7.0 Knowledge Base. (Do not change the quotation marks.) 1. Use DB2 SQL Query to connect to the appropriate DB2 7.1 Avaya IC database. 2. Run the following SQL script for each of the renamed or moved Knowledge Bases: UPDATE knowledgebase SET knowledgebase.kbfilepath = 'Full_Destination_KB_Path' WHERE knowledgebase.name = 'KB_Name' AND knowledgebase.kbfilepath = 'Full_Source_KB_File_Path' Where Full_Destination_KB_Path is the fully-qualified location of the 7.1 Knowledge Base (including the file name), KB_Name is the Knowledge Base name, and Full_Source_KB_File_Path is the fully-qualified name of the corresponding 7.0 Knowledge Base. (Do not change the quotation marks.) Software Upgrade and Data Migration May

114 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to 7.1 Verifying the new Knowledge Base file locations To make sure that your changes are accurate, run the SQL statements shown in Determining the training and validation information for your Knowledge Bases on page 81. The entries in the KB File column should match the new locations and names for your Knowledge Bases. Start Avaya IC 7.1 At this point, all of the Avaya IC data has been migrated and you can start all of the 7.1 servers and begin running the 7.1 agent clients. Deploy the Web Agent clients If desired, deploy the 7.1 Web Agent clients as described in IC Installation and Configuration. Uninstall 7.0 Avaya Agent applications If you want to uninstall the 7.0 Avaya Agent applications from your agent machines, you will need to re-register the 7.1 Avaya Agent. To do so: 1. Uninstall the 7.0 Avaya Agent. 2. Open a Command Prompt and navigate to IC72_INSTALL_DIR\IC72\bin. 3. Run the following commands: RegRichClient.bat vtel -register 114 Software Upgrade and Data Migration May 2009

115 Detailed changes to the IC Scripts and workflows Detailed changes to the IC Scripts and workflows Bug fixes were made to some IC Scripts and workflows in 7.1. If you have customized these files, you need to either reapply your customizations to the 7.1 out-of-the-box files, or continue to use your 7.0 files and not take advantage of those bug fixes. For a list of changes, see IC Script changes, below, and Workflow changes on page 116. No website files have changed in 7.1. All you need to do is copy your customized 7.0 website files over the 7.1 out-of-the-box versions. IC Script changes Bug fixes and support for chat transfers and conferences were made to some IC Scripts in 7.1. While you can copy other customized IC Scripts from the IC71_INSTALL_DIR\IC71\ design\<appname> subdirectory into the appropriate IC72_INSTALL_DIR\IC72\design directory, you should reapply your customizations to these out-of-the-box IC Scripts in order to take full advantage of the bug fixes in 7.1. Location IC Scripts changed in 7.1 Description design\qconsole QConsole_MouseDown.qsc Added support for customizations, including custom parameters. QConsole_ShowContactChooser Dialog.qsc Fixed problem with truncated buttons. design\qconsole\custom Custom_IHH_MouseDown.qsc Added support for the new parameters passed by the QConsole_MouseDown.qsc. design\qconsole\siebel Siebel_IHH_PE_OnTelephonyStat echanged.qsc Fixed problem ending a call when "Call failed because destination was busy" message is received. design\repository employeeupdate.qsc Removed agent name handling code as that is now done by IC Manager. Software Upgrade and Data Migration May

116 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to 7.1 Workflow changes Only one Business Advocate-related system workflow, named sys_transfer.update_vq_cache, has changed in 7.1 to enable virtual queue transfers. You can copy your customized workflows from IC71_INSTALL_DIR\IC71\design\IC\ Flows\Avaya\ to IC72_INSTALL_DIR\IC72\design\IC\Flows\Avaya\, but if your installation uses Business Advocate, you must use the 7.1 out-of-the-box sys_transfer.update_vq_cache workflow. The following workflows under IC72_INSTALL_DIR\IC72\design\IC\Flows\Avaya\ have changed in 7.1: Location Workflow name Description WebCenter schedulecallback.qfd Completely rewritten due to the removal of Outbound Contact. If you have customized this flow, you need to reapply your customizations to the out-of-the-box 7.1 version. Sys_Transfer transfertovq.qfd You must use the out-of-the-box 7.1 version of this workflow. Advocate update_vq_cache.qfd handle_exception.qfd qualifychat_adv.qfd qualify _adv.qfd qualifyvoice_adv.qfd transfertoagent_adv.qfd update_qualifiersetids.qfd You must use the out-of-the-box 7.1 version of this workflow. Numerous bug fixes. If you have customized any of these flows, you need to reapply your customizations to the out-of-the-box 7.1 versions. blender clientlogin.qfd Minor bug fixes to block GetChannelLoadAndCeiling. Added new block to reset cache data after logout. 116 Software Upgrade and Data Migration May 2009

117 Detailed changes to the IC Scripts and workflows Location Workflow name Description Siebel/Advocate Siebel/IC qualify _adv_sbl.qfd qualifyvoice_adv_sbl.qfd outbound _sbl.qfd postanalyze_sbl.qfd postanalyzeerror_sbl.qfd preanalyzeca_sbl.qfd preanalyzenoca_sbl.qfd triggerxfercleanup_sbl.qfd triggerxferoutbound toic_sbl.qfd xferoutbound toic_sbl.qfd Error handling improvements in PrettyPrint block. Error handling improvements in PrettyPrint block. Software Upgrade and Data Migration May

118 Chapter 3: Upgrading Avaya Interaction Center from 7.0 to Software Upgrade and Data Migration May 2009

119 Chapter 4: Upgrading Avaya Interaction Center from to 7.0 This chapter contains information that helps you upgrade from Avaya Interaction Center (Avaya IC) from to release 7.0. If you are starting from an earlier release, you must first migrate to For details, see the appropriate chapter in this manual. This section includes the following topics: Considerations on page 120 Prerequisites on page 121 Install 7.0 administration and migration tools on page 126 Migrate your ADL files on page 128 Upgrade customized IC Scripts, workflows, and website files on page 135 Shut down on page 136 Install the 7.0 servers on page 137 Migrate your Avaya IC servers on page 139 Update the web configuration on page 141 Update the Chat transcript directory on page 142 Import the 7.0 seed data on page 142 Reconfigure your 7.0 databases on page 143 Generate your applications and load the new workflows on page 148 Disable Business Advocate mapping rules on page 148 Migrate your server settings into 7.0 on page 149 Import new agent properties on page 150 Migrate your Content Analyzer data on page 151 Upgrade your Avaya Agent applications on page 153 Uninstall on page 154 Detailed changes to the IC Scripts, workflows, and website files on page 155 Software Upgrade and Data Migration May

120 Chapter 4: Upgrading Avaya Interaction Center from to 7.0 Considerations Avaya Business Applications: In Avaya IC 7.0, Avaya discontinued support for the Business Applications. If your installation uses CallCenterQ, HRQ, or CustomerQ, you can continue to run those applications in a stand-alone environment while you set up a separate 7.0 environment for Avaya Agent and the new Avaya Agent Web Client. Because you cannot run and 7.0 servers on the same machine, you need to keep both systems completely separate. You also need to copy your database and upgrade the copy to 7.0, while keeping the original database for the Avaya Business Applications. This means that you will have to maintain two separate databases for your customer information, so you need to develop a strategy to make sure that customer records stay synchronized between both systems. For more information about using the Business Applications in 7.0, contact your Avaya Technical Support Representative. Avaya Operational Analyst: For details about upgrading Avaya OA 7.0, see Avaya Operational Analyst Installation and Configuration. Business Advocate: Now that the CallCenterQ Business Application is no longer supported, the Customer Profile Setup form has been moved into the List Management application. For details, see IC Business Advocate Configuration and Administration. Localization: If you are using a localized version of Avaya IC 6.1.3, you need to migrate to the localized version of Avaya IC 7.0. You cannot migrate a localized system to a non-localized 7.0 system. To determine whether you have the localized version of 7.0, see the Readme.pdf file on the core Avaya IC CD-ROM. Siebel: For details about upgrading Siebel, see Avaya IC for Siebel Integration. Voice Quick Start (VQS): If your installation uses VQS, you can continue to use your current VQS set up with the 7.0 Avaya IC servers and Avaya Agent desktop application. However, VQS does not support the new Avaya Agent Web Client. The new Avaya Agent Web Client is supported by Avaya IC only. For more information or additional VQS seats, contact your Avaya sales representative. Upgrade Business Advocate To upgrade Business Advocate, load the 7.0 Business Advocate installation CD-ROM on each of your Business Advocate machines and follow the installation prompts. The installation procedure will automatically detect the previously-installed version and make the necessary upgrade changes. 120 Software Upgrade and Data Migration May 2009

121 Prerequisites After you have installed the 7.0 version, reboot your Business Advocate machine. For details, see IC Business Advocate Configuration and Administration. Prerequisites Before you begin the migration process: Avaya recommends that you make a backup copy of: - The entire IC613_INSTALL_DIR\IC61\design directory and its subdirectories - The IC613_INSTALL_DIR\IC61\etc directory - Your databases. Verify that the Sun JDK version 1.3.1_06 is installed on your Avaya IC web server machines. For more information about prerequisites for Avaya IC 7.0, see IC Installation Planning and Prerequisites. Prerequisites for migrating Content Analyzer Before you migrate your system, you should make detailed notes about your Content Analyzer system, as described in the sections below. With this information, you can: Verify that all of your Content Analyzer data migrated properly Restore all of the settings for your Content Analyzer CAServer and CAAdmin servers For details about Content Analyzer and the Content Analyzer servers, see IC Administration Volume 1: Servers & Domains. If at all possible, you should configure your 7.0 Content Analyzer servers so that they have the same relative path to the Content Analyzer Knowledge Bases as the servers did. For example, if the fully-qualified path from your current servers to your Knowledge Bases is X:\Avaya\KBs\, then you should make sure that your 7.0 servers use the same path. The recommended installation directory for your Knowledge Bases is: C:\Program Files\Avaya\kbs (Windows)../opt/Avaya/kbs (Unix) Software Upgrade and Data Migration May

122 Chapter 4: Upgrading Avaya Interaction Center from to 7.0 If your 7.0 servers can use the same relative path to the Knowledge Bases, then all of your Content Analyzer database data will be migrated automatically when you perform the standard migration steps described in this chapter. The only Content Analyzer-specific migration step you need to take is to recreate your Content Analyzer servers in your 7.0 environment. If you have to change the relative location of your Knowledge Bases to your Content Analyzer servers, you will also need to perform the migration steps in Migrate your Content Analyzer data on page 151. In order to verify Content Analyzer data migration, you need to record information about your Content Analyzer environment, as described in the following sections: Determining the current Content Analyzer data Determining the current Content Analyzer server settings Determining the training and validation information for your Knowledge Bases Determining the current Content Analyzer data To find out what Content Analyzer data is currently stored in your Avaya IC system: 1. In IC Manager, select Tools > Content Analysis. 2. To get a list of all the Knowledge Bases in your system, select KB Management in the left-hand pane and make a note of the information in the File Path column for each Knowledge Base that appears in the right-hand pane. Tip: The File Path column shows the relative path to the Knowledge Base, not the exact machine on which that Knowledge Base is located. Make sure you contact your Content Analyzer Administrator for the specific machines and directories where the Knowledge Base files are located. 3. To get a list of all the topic trees in your system, select Topic Tree Management in the left-hand pane. Make a note of all the topic trees and their topics. Tip: An easy way to do this is to expand all of the topic trees and then take one or more screenshots of the resulting data. If you have a large number of topic trees, you may want to expand each one individually and take one screenshot per tree. 4. To get a list of all the sample sets in your system: a. Select Sample Management in the left-hand pane. b. Select the Remove Samples tab in the right-hand pane. c. Open the Sample Set drop down list and make a note of the sample sets. 122 Software Upgrade and Data Migration May 2009

123 Prerequisites Determining the current Content Analyzer server settings To determine your Content Analyzer server settings: 1. In IC Manager, select the Server tab and then select All Domains in the left-hand pane. 2. For each Avaya IC server of type CAAdmin: a. Right click on that server and select Edit from the pop-up menu. IC Manager displays the Server Editor dialog box for that server. b. Take a screenshot of each tab in the Server Editor dialog box, making sure that you take special note of the Name on the General tab, the system on which this server was configured, and the setting for Path to NLP Data on the CAAdmin tab. c. Select OK or Cancel to close the Server Editor dialog box. d. Repeat steps a through c for the next CAAdmin server. 3. For each Avaya IC server of type CAServer: a. Right click on that server and select Edit from the pop-up menu. IC Manager displays the Server Editor dialog box for that server. b. Take a screenshot of each tab in the Server Editor dialog box, making sure that you take special note of the Name on the General tab, the system on which this server was configured, and the setting for Path to NLP Data on the CAServer tab. c. On the CAServer tab, select the Knowledge Base button and, for each associated Knowledge Base: 1. Record the Name, KB File Location, and Threshold values. 2. Click on under the Languages column and note all of the languages that are associated with this Knowledge Base. 3. Select OK or Cancel to close the Knowledge Base dialog box. d. Select OK or Cancel to close the Server Editor dialog box. e. Repeat steps a through d for the next CAServer server. 4. When you have finished recording the details for all of your CAAdmin and CAServer servers, you can close IC Manager. Determining the training and validation information for your Knowledge Bases To view the training and validation information about your existing Knowledge Bases (such as the topic tree associated with the Knowledge Base, the sample set used in training or validation, and the date/time of any training or validation sessions), you can run a SQL query on your SQL Server database, or a SQL Plus query on your SQL Oracle database. Both queries are shown below. Software Upgrade and Data Migration May

124 Chapter 4: Upgrading Avaya Interaction Center from to 7.0 Tip: Tip: If you saved the results of previous training and validation sessions, make sure that you know where those files are located so that you can compare them to your migrated 7.0 system. For a SQL Server database, run the following SQL query: USE ccq SELECT kb.name "KBName", kb.kbfilepath "KBFilePath", ss.name "SampleSet", ct.name "Topic Tree", sskb.intent "Train:0; Validate:1", sskb.dateperformed "Date Performed" FROM knowledgebase kb, sampleset ss, samplesetknowledge sskb, contenttree ct WHERE kb.pkey = sskb.knowledgebase_key AND sskb.sampleset_key = ss.pkey AND ss.contenttree_key = ct.pkey ORDER BY sskb.intent ASC, sskb.dateperformed DESC 124 Software Upgrade and Data Migration May 2009

125 Prerequisites A screenshot showing an example of this query is shown below. In this example, each of the three Knowledge Bases went through one training session and one validation session. The sample set used for each training and validation session is shown in the SampleSet column. For an Oracle database, run the following SQL Plus script: SET LINESIZE 180; COLUMN "KB Name" FORMAT A15; COLUMN "File Path" FORMAT A30; COLUMN "Topic Tree" FORMAT A15; COLUMN "Sample Set" FORMAT A20; COLUMN "Date Performed" FORMAT A30; SELECT kb.name AS "KB Name", kb.kbfilepath AS "File Path", ct.name AS "Topic Tree", ss.name AS "Sample Set", sskb.intent AS "Intent 0 or 1", sskb.dateperformed AS "Date Performed" FROM ccq.knowledgebase kb, ccq.sampleset ss, ccq.samplesetknowledge sskb, ccq.contenttree ct WHERE kb.pkey = sskb.knowledgebase_key AND sskb.sampleset_key = ss.pkey AND ss.contenttree_key = ct.pkey ORDER BY sskb.intent ASC, sskb.dateperformed DESC; Software Upgrade and Data Migration May

126 Chapter 4: Upgrading Avaya Interaction Center from to 7.0 A screenshot showing an example of this query is shown below. In this example, the KO-Financial Knowledge Base was trained twice but validated once, and the other Knowledge Bases went through one training session and one validation session each. The sample set used for each training and validation session is shown in the Sample Set column. Install 7.0 administration and migration tools To begin the migration process, you need to install the 7.0 administration and design tools, followed by the migration tools. As described in IC Installation Planning and Prerequisites, you cannot install the Avaya IC administration and design tools on the same machine as your Avaya IC servers. Make sure that you install these tools on a dedicated administration machine. 126 Software Upgrade and Data Migration May 2009

127 Install 7.0 administration and migration tools To install the tools: 1. Shut down all administration and design tools, such as IC Manager, Database Designer, and Workflow Designer. 2. On the same administration machine, install the 7.0 administration and design tools as described in IC Installation and Configuration. Do not install the servers at this point. Tip: Tip: To make sure that the installation was successful, check the IC_INSTALL_DIR\ IC70\install.log file. 3. Reboot the 7.0 administration machine. 4. Avaya recommends that you make a backup copy of the entire: IC_INSTALL_DIR\IC70\design directory and its subdirectories IC_INSTALL_DIR\IC70\etc directory 5. Copy: IC613_INSTALL_DIR\IC61\design\CallCenterQ\ccq.adc to IC_INSTALL_DIR\IC70\design\CallCenterQ\ccq.adc IC613_INSTALL_DIR\IC61\design\repository\repository.adc to IC_INSTALL_DIR\IC70\design\repository\repository.adc Overwriting the 7.0 out-of-the-box ADC files. 6. On the 7.0 administration machine, install the migration files: a. Navigate to the Migration directory on the Avaya IC 7.0 CD-ROM and open the Migration.zip file in that directory. b. Extract the files in Migration.zip to IC_INSTALL_DIR\IC70\, making sure that you preserve the directory structure in that zip file. (Default location: C:\Program Files\Avaya\IC70\.) When you unzip Migration.zip, make sure that you maintain the folder names stored in the zip file and that you let the extraction program overwrite any existing files. Software Upgrade and Data Migration May

128 Chapter 4: Upgrading Avaya Interaction Center from to 7.0 Migrate your ADL files Database Designer includes a Database Migration tool that you can use to merge the customizations in your existing application ADL and ADF files with the updated application ADL and ADF files in release 7.0 of Avaya IC. This section includes the following topics: Actions performed by Database Migration tool on page 128 Prerequisites on page 129 Verify the size of varchar fields for Oracle databases on page 130 Migrate ccq.adl on page 130 Migrate repository.adl on page 132 Migrate dialer.adl on page 134 Move the migrated files to 7.0 on page 135 Actions performed by Database Migration tool The following table describes the action performed by the Database Migration tool during the comparison of the ADL files. Source out-of-the-box ADL file Source Customized ADL file New out-of-the-box 7.0 ADL file Action performed Component does not exist Component does not exist Component does not exist Component exists Component exists Component does not exist Component exists Component exists Component does not exist Adds component to the new customized ADL file. Adds component to the new customized ADL file. Component exists Component exists Asks you to select one of the existing components to add to the new customized ADL file. Component does not exist Component does not exist Component does not exist Component exists Does not copy the component to the new customized ADL file. Adds the component to the new customized ADL file and advises you that you need to manually remove this component if desired. 128 Software Upgrade and Data Migration May 2009

129 Migrate your ADL files Source out-of-the-box ADL file Source Customized ADL file New out-of-the-box 7.0 ADL file Action performed Component exists Component exists Component does not exist Advises you that the customized component was added to the new customized ADL file. Component exists Component exists Component exists Asks you to select one of the components to add to the new customized ADL file. Form exists Form does not exist Form does not exist Does not copy the form to the new customized ADL file. Form exists Form does not exist Form exists Does not copy the form to the new customized ADL file. Form exists/form does not exist Form exists/form does not exist Form exists Form does not exist Adds the form from customized ADL file to the new customized ADL file. Also adds a message to the log file. Form exists Form Exists Adds the form from customized ADL file to the new customized ADL file. Form does not exist Form does not exist Form exists Adds the form to the new customized ADL file. Also adds a message to the log file. For all versions of Avaya IC, you need to migrate ccq.adl and repository.adl. If your site use Outbound Contact Management, you also need to migrate dialer.adl. Prerequisites The ADL migration tool cannot save the new ADL file using the same fully-qualified filename as the original ADL file. Therefore, you either have to save the migrated ADL file to a new directory or under a different name in the design directory. Avaya recommends that you save the new ADL and ADF file to a temporary directory called: IC_INSTALL_DIR\IC70\migration\output\[CallCenterQ repository softdialer] For example, you could save the ccq.adl file to C:\Program Files\Avaya\IC70\ migration\output\callcenterq. Software Upgrade and Data Migration May

130 Chapter 4: Upgrading Avaya Interaction Center from to 7.0 After the ADL migration tool is finished, you can then copy the files from the output directory to the corresponding IC_INSTALL_DIR\IC70\design directory, overwriting the out-of-the-box files. To create these directories: 1. Open File Explorer and navigate to IC_INSTALL_DIR\IC70\migration. 2. Add a directory called output. 3. Under the output directory, create: a. A directory called CallCenterQ. b. A directory called repository. c. If your installation uses Outbound Contact, a directory called SoftDialer. The rest of these instructions assume that you are using the directory and file names listed above. If you elect to use different files, please substitute your output files as appropriate. Verify the size of varchar fields for Oracle databases For Oracle databases, the column size for varchar fields cannot be larger than To support UTF-8 on Oracle 9i, Database Designer increases the size of every char and varchar field by three times during a configure or reconfigure operation. If you define a field of varchar size x in an ADL file, the equivalent SQL generated by Database Designer will create a varchar field in the Oracle database table as 3x. The maximum size for a varchar field in Oracle 9i is Therefore, the maximum size that Database Designer can put for a custom varchar field in the ADL file is: 3999 divided by 3 = 1333 A custom varchar field that is larger than 1333 will cause Oracle errors when Database Designer attempts to configure or reconfigure a database. For example, if you define a custom varchar field of size 1980, during reconfigure Database Designer will attempt to add a varchar field of size 1980 x 3 = This attempt will fail and cause Oracle errors. Migrate ccq.adl To migrate your ccq.adl file: 1. Open the 7.0 Database Designer, but do not open an ADL file in Database Designer. 130 Software Upgrade and Data Migration May 2009

131 Migrate your ADL files Important:! Important: The Database Migration tool will not start if you have an ADL file open in Database Designer. You must close all ADL files before you attempt to migrate customized ADL files. 2. Select Tools > Database Migration. Database Designer displays the Choose ADL Files dialog box: 3. In the Choose ADL Files dialog box: a. Select the Ellipsis ( ) button next to the Source out-of-the-box ADL file field and navigate to the directory containing the out-of-the-box ccq.adl file. (Default location: IC_INSTALL_DIR\IC70\oob613adl\ccq.) Select the ccq.adl file and select Open. Tip: Tip: You can also cut and paste the fully-qualified directory name into all of the fields in this dialog box. b. Select the Ellipsis ( ) button next to the Source customized ADL file field and navigate to the directory containing the customized ccq.adl file. (Default location: IC613_INSTALL_DIR\IC61\design\CallCenterQ.) Select the appropriate ADL file and select Open. c. Select the Ellipsis ( ) button next to the New out-of-the-box ADL file field and navigate to the directory containing the out-of-the-box 7.0 ADL file. (Default location: IC_INSTALL_DIR\IC70\design\CallCenterQ.) Select the ccq.adl file and select Open. Software Upgrade and Data Migration May

132 Chapter 4: Upgrading Avaya Interaction Center from to 7.0 d. Select the Ellipsis ( ) button next to the New customized ADL file field and navigate to the directory where you want the Database Migration tool to save the migrated ADL file. (Default location: IC_INSTALL_DIR\IC70\migration\ output\callcenterq.) Select OK and then add the filename ccq.adl to the end of that path. e. Select OK. 4. As the Database Migration tool compares the ADL files, review and respond to all information messages. (For more information about why the Database Migration tool prompts you for a decision, see Migrate your ADL files on page 128.) When the Database Migration tool finishes, it writes the migrated ADL and ADF files, and the out-of-the-box 7.0 ADC file, to the specified output directory. 5. After the Database Migration tool has merged the ADL files: a. Open the new customized ADL file in Database Designer and carefully review the changes. b. Set the database connection information in the ADL. c. If necessary, delete components that were deleted in the old customized ADL file. d. Review the ccq.txt log file in the output directory for details about the ADL file migration. e. If the new customized ADL file is: Satisfactory, regenerate all applications and data sources for the ADL file. Not satisfactory, repeat this procedure. Migrate repository.adl To migrate your repository.adl file: 1. Open Database Designer, but do not open an ADL file in Database Designer. Important:! Important: The Database Migration tool will not start if you have an ADL file open in Database Designer. You must close all ADL files before you attempt to migrate customized ADL files. 2. Select Tools > Database Migration. 3. In the Choose ADL Files dialog box: a. Select the Ellipsis ( ) button next to the Source out-of-the-box ADL file field and navigate to the directory containing the out-of-the-box repository.adl file. (Default location: IC_INSTALL_DIR\IC70\oob613adl\repository.) Select the repository.adl file and select Open. 132 Software Upgrade and Data Migration May 2009

133 Migrate your ADL files Tip: Tip: You can also cut and paste the fully-qualified directory name into all of the fields in this dialog box. b. Select the Ellipsis ( ) button next to the Source customized ADL file field and navigate to the directory containing the customized repository.adl file. (Default location: IC613_INSTALL_DIR\IC61\design\repository.) Select the appropriate ADL file and select Open. c. Select the Ellipsis ( ) button next to the New out-of-the-box ADL file field and navigate to the directory containing the out-of-the-box 7.0 ADL file. (Default location: IC_INSTALL_DIR\IC70\design\repository.) Select the repository.adl file and select Open. d. Select the Ellipsis ( ) button next to the New customized ADL file field and navigate to the directory where you want the Database Migration tool to save the migrated ADL file. (Default location: IC_INSTALL_DIR\IC70\migration\ output\repository.) Select OK and then add the filename repository.adl to the end of that path. e. Select OK. 4. As the Database Migration tool compares the ADL files, review and respond to all information messages. (For more information about why the Database Migration tool prompts you for a decision, see Migrate your ADL files on page 128.) When the Database Migration tool finishes, it writes the migrated ADL and ADF files, and the out-of-the-box 7.0 ADC file, to the specified output directory. 5. After the Database Migration tool has merged the ADL files: a. Open the new customized ADL file in Database Designer and carefully review the changes. b. Set the database connection information in the ADL. c. If necessary, delete components that were deleted in the old customized ADL file. d. Review the repository.txt log file in the output directory for details about the ADL file migration. e. If the new customized ADL file is: Satisfactory, regenerate all applications and data sources for the ADL file. Not satisfactory, repeat this procedure. Software Upgrade and Data Migration May

134 Chapter 4: Upgrading Avaya Interaction Center from to 7.0 Migrate dialer.adl If your site uses Outbound Contact Management and you have customized your dialer.adl file, migrate your customized file: 1. Open Database Designer, but do not open an ADL file in Database Designer. Important: Tip:! Important: The Database Migration tool will not start if you have an ADL file open in Database Designer. You must close all ADL files before you attempt to migrate customized ADL files. 2. Select Tools > Database Migration. 3. In the Choose ADL Files dialog box: a. Select the Ellipsis ( ) button next to the Source out-of-the-box ADL file field and navigate to the directory containing the out-of-the-box dialer.adl file. (Default location: IC_INSTALL_DIR\IC70\oob613adl\softdialer.) Select the dialer.adl file and select Open. Tip: You can also cut and paste the fully-qualified directory name into all of the fields in this dialog box. b. Select the Ellipsis ( ) button next to the Source customized ADL file field and navigate to the directory containing the customized dialer.adl file. (Default location: IC613_INSTALL_DIR\IC61\design\SoftDialer.) Select the appropriate ADL file and select Open. c. Select the Ellipsis ( ) button next to the New out-of-the-box ADL file field and navigate to the directory containing the out-of-the-box 7.0 ADL file. (Default location: IC_INSTALL_DIR\IC70\design\SoftDialer.) Select the dialer.adl file and select Open. d. Select the Ellipsis ( ) button next to the New customized ADL file field and navigate to the directory where you want the Database Migration tool to save the migrated ADL file. (Default location: IC_INSTALL_DIR\IC70\migration\ output\softdialer.) Select OK and then add the filename dialer.adl to the end of that path. e. Select OK. 4. As the Database Migration tool compares the ADL files, review and respond to all information messages. (For more information about why the Database Migration tool prompts you for a decision, see Migrate your ADL files on page 128.) When the Database Migration tool finishes, it writes the migrated ADL and ADF files, and the out-of-the-box 7.0 ADC file, to the specified output directory. 134 Software Upgrade and Data Migration May 2009

135 Upgrade customized IC Scripts, workflows, and website files 5. After the Database Migration tool has merged the ADL files: a. Open the new customized ADL file in Database Designer and carefully review the changes. b. Set the database connection information in the ADL. c. If necessary, delete components that were deleted in the old customized ADL file. d. Review the dialer.txt log file in the output directory for details about the ADL file migration. If the log file is empty, then no component changes were made during the migration and you can use the 7.0 out-of-the-box files without needing to reconfigure your Outbound Contact database. e. If the new customized ADL file is: Satisfactory, regenerate all applications and data sources for the ADL file. Not satisfactory, repeat this procedure. Move the migrated files to 7.0 Once you have successfully migrated your ADL files, you need to move them, along with the ADF and ADC files, to the 7.0 design directories, as shown below: Move the ADL, ADF, and ADC files from... IC_INSTALL_DIR\IC70\migration\ output\callcenterq IC_INSTALL_DIR\IC70\migration\ output\repository IC_INSTALL_DIR\IC70\migration\ output\softdialer To... IC_INSTALL_DIR\IC70\design\ CallCenterQ IC_INSTALL_DIR\IC70\design\ repository IC_INSTALL_DIR\IC70\design\ SoftDialer Upgrade customized IC Scripts, workflows, and website files Your customized IC Scripts and workflows will continue to work in 7.0. However, Avaya recommends that you reapply your customizations to the out-of-the-box files in order to take advantage of the bug fixes included in 7.0. You can find a list of changed files in IC Script changes on page 156 and Workflow changes on page 157. Software Upgrade and Data Migration May

136 Chapter 4: Upgrading Avaya Interaction Center from to 7.0! Important: Important: You must use the 7.0 version of the CoreService_Initialize IC Script or agents will be unable to log into the Avaya Agent application. If you have customized any of the Avaya IC website files that have changed in 7.0, you will need to reapply your customizations to the new out-of-the-box versions or your website will not work. You can find a list of changed files in Website file changes on page 157. In order to minimize the amount of time that your production system will be shut down, Avaya recommends that you install an out-of-the-box version of 7.0 and use that to test your customized IC Scripts, workflows, and website files. To upgrade your IC Script, workflow, and website files: 1. Set up an out-of-the-box 7.0 test system. 2. Merge your customizations with the out-of-the-box IC Script, workflow, and website files that have changed since (for the names of the changed files, see Detailed changes to the IC Scripts, workflows, and website files on page 155). 3. Copy all customized IC Script, workflow, and website files into your 7.0 test system. 4. Verify that all of your customized files work the way you expect. 5. When you are sure that everything is working, copy your verified IC Script, workflow, and website files to the appropriate 7.0 directories. The directory structure between and 7.0 has not changed, so you can copy these files from where they exist in to the equivalent directory in 7.0 Avaya Agent EDU Viewer stylesheets There have been no changes to the EDU Viewer XSL stylesheets in 7.0. You can copy your EDU Viewer stylesheets directly into 7.0 (default location: IC_INSTALL_DIR\IC70\ design\qconsole.) Shut down After you have verified that your customized IC Scripts, workflows, website files, and EDU Viewer stylesheets work in your 7.0 test system, as described in Upgrade customized IC Scripts, workflows, and website files on page 135, you can begin migrating your servers and Avaya Agent applications. In order to do so, Avaya IC must be shut down and the system will not be available to agents until the migration process is complete. 136 Software Upgrade and Data Migration May 2009

137 Install the 7.0 servers To shut down 6.1.3: 1. Stop all Avaya Agent applications. 2. Stop all Avaya IC servers: a. Go to the server machine running the Primary ORB server. b. For Windows, open a command prompt, navigate to IC613_INSTALL_DIR\IC61\ bin, and run icadmin tva <Username> <PW>. c. For Solaris or AIX, navigate to IC61_INSTALL_DIR/IC61/bin and run./icadmin tva <Username> <PW>. d. Make sure that you wait until all Avaya IC servers have been shut down. 3. Stop and disable all of the Avaya IC Website servers and services, including the Avaya IC CIRS Service, Avaya IC ICM Service, Avaya IC ORB Service, Avaya IC Web Management Service, Avaya IC WebLM Service, and Avaya Voice Media Manager. For details, see IC Installation and Configuration. Install the 7.0 servers Install the 7.0 core servers as described in IC Installation and Configuration. During the migration process, you will be migrating all of your server settings, so you don t need to duplicate that information now. Just install 7.0 with the minimum information needed for each of the core servers. As described in IC Installation Planning and Prerequisites, you cannot install the Avaya IC servers on the same machine as your administration and design tools. Make sure that you install your servers on dedicated server machines. Update the telephony configuration To update the telephony configuration, you need to run the Configuration tool on all servers running a Telephony server or TSQS server. To do so, on each machine running a Telephony server or TSQS server: 1. Start the Configuration Tool by selecting Start > Programs > Avaya Interaction Center 7.0 > Configuration Tool. 2. Select the Initial Configuration tab. 3. Select Telephony Server. 4. Select your switch from the Telephony Switch drop-down list. Software Upgrade and Data Migration May

138 Chapter 4: Upgrading Avaya Interaction Center from to Select Apply Settings. For details about running the Configuration Tool, see IC Installation and Configuration. Set up the VMM Service If your installation uses IV Chat, you need to change the Avaya Voice Media Manager service to point to the 7.0 installation directory. To do so: 1. Stop the Avaya Voice Media Manager service that points to your installation. 2. Unregister the VMM service with the Windows Service Control Manager: a. Open a Command Prompt and navigate to the Avaya IC 6.1 bin directory. (Default C:\Program Files\Avaya\IC61\bin.) b. Execute the command: vmm_service -u 3. To register the 7.0 VMM service with the Windows Service Control Manager: a. Navigate to the Avaya IC 7.0 bin directory. (Default C:\Program Files\Avaya\IC70\bin.) b. Execute the command: vmm_service -i There is only one version of the VMM on any machine at a time, even if you have both and 7.0 installed. That means that If you remove the previous version of Avaya IC, it automatically unregisters the VMM service for 7.0 as well. Therefore, you will need to repeat this process if you uninstall Reboot your server machines After you have finished the server installation and set up VMM (if desired), reboot your server machines. Tip: You Tip: can use the Windows Services manager to make sure that all Avaya IC 7.0 services have started automatically after the reboot. 138 Software Upgrade and Data Migration May 2009

139 Migrate your Avaya IC servers Migrate your Avaya IC servers To migrate your servers to 7.0: 1. Verify that the 7.0 administration and design tools are installed on the same machine with the tools. 2. Copy the ds.ffd and vesp.imp files from IC613_INSTALL_DIR\IC61\etc on the primary server machine to IC613_INSTALL_DIR\IC61\etc on the administration machine, overwriting the existing files. If you are copying the files via FTP, make sure that you transfer them in ASCII mode. 3. On the administration machine, open a command prompt, navigate to IC_INSTALL_DIR\ IC70\migration, and run FixConfigFiles.exe. The following screenshot shows the FixConfigFiles tool: The path in the server configuration files. The tool fills in this information when you click on an IP address in the box below. 4. The path to your Avaya IC 7.0 installation. 5. The list of IP addresses found in the server configuration files 4. Select the IP address of the server machine whose configurations you want to migrate from the list of IP addresses found in the configuration file. FixConfigFiles fills the associated path into the Path in 6.1 server configuration files field. Software Upgrade and Data Migration May

140 Chapter 4: Upgrading Avaya Interaction Center from to Specify the appropriate 7.0 path information from the drive letter to the Avaya IC 7.0 directory in the Path in 7.0 server configuration files field. (For example, C:\Program Files\Avaya\IC70\.) Important:! Important: Verify that this path is correct relative to the machine on which the servers are installed, not relative to the administration machine. Do not mix backslashes "\" and forward slashes "/" in the path name. If your servers are running on a Windows platform, you need to use all backslashes. If your servers are running on UNIX, you need to use all forward slashes. 6. If you want to use the same path for all of the IP addresses listed, select the Change all paths to the same value checkbox. Tip: Tip: If you want to change most of your paths to the same value, enter the value you want to use for the majority of the paths in the Path in 7.0 server configuration files field and select this checkbox. You can then change the other fields individually before the final conversion. 7. Select Update. FixConfigFiles displays the updated path in the New 7.0 path column. 8. If you need to set another path or change one of the existing paths, repeat steps 4 through When the New 7.0 Paths column has been filled in for every IP address listed in FixConfigFiles, select Go. FixConfigFiles generates new vesp.imp and ds.ffd files in the etc directory under IC_INSTALL_DIR\IC70\. 10. Copy the new vesp.imp and ds.ffd files in IC_INSTALL_DIR\IC70\etc to all server machines that are running a Directory server, overwriting any existing files. If you are copying the files via FTP, make sure that you transfer them in ASCII mode. 11. Copy the new vesp.imp file in IC_INSTALL_DIR\IC70\etc to all other server machines, overwriting any existing files. If you are copying the files via FTP, make sure that you transfer them in ASCII mode. 12. Start the Avaya IC 7.0 core servers using the icadmin so command on the primary server machine. You can either run icadmin so from the command line of the server s host machine, or you can run icadmin so <hostname> if your host has multiple network interface cards. (For details, see IC Installation and Configuration.) 140 Software Upgrade and Data Migration May 2009

141 Update the web configuration Troubleshooting If the 7.0 servers do not work after migration, verify that: The 7.0 paths you specified are correct relative to the server machine on which the ds.ffd file resides. If you find a path problem, rerun FixConfigFiles, specifying the new path. All servers have a valid path to their executable file defined in the IC Manager. If you find a problem, either fix the path or delete that server from IC Manager and select Manager > Refresh. Then copy the updated ds.ffd file to the administration machine and rerun FixConfigFiles. Remove unused data sources With the removal of the Business Applications, there are several data sources related to CallCenterQ Contact and CallCenterQ Request that are no longer used in 7.0. If you want to delete them: 1. In IC Manager, select Tools > IC Data Source. IC Manager displays the IC Data Source dialog box. 2. Select any data sources related to CallCenterQ Contact and CallCenterQ Request and delete them..for details about working with data sources, see IC Administration Volume 2: Agents, Customers, & Queues. Update the web configuration To update the web configuration, you need to run the Configuration tool on all servers running the WebLM License server and the website servers. To do so: 1. On the machine running the WebLM license server: a. Start the Configuration Tool by selecting Start > Programs > Avaya Interaction Center 7.0 > Configuration Tool. b. Select the Web tab. c. Make sure that Configure Web License Manger is selected. d. Select Apply Settings. Software Upgrade and Data Migration May

142 Chapter 4: Upgrading Avaya Interaction Center from to On all server machines hosting the Avaya IC web servers: a. Start the Configuration Tool by selecting Start > Programs > Avaya Interaction Center 7.0 > Configuration Tool. b. Select the Web tab. c. Make sure that Configure Web Management is selected. d. If desired, select Template Administration. e. Select Apply Settings. f. If the servers are running on a Windows machine, reboot the machine or use the Windows Services manager to restart the web services. You can also use the Windows Services manager to make sure that all Avaya IC 7.0 web services have installed correctly. For details about running the Configuration Tool, see IC Installation and Configuration. Update the Chat transcript directory If your installation uses the Chat feature, you need to update the path to the Chat transcript directory. To do so: 1. Open IC Manager and select the Configuration tab. 2. From the Tables list in the left-hand pane, select Chat > ICM. 3. In the right-hand pane, change the path for the Chat Transcript Directory to point to your 7.0 installation. Import the 7.0 seed data To import the new seed data for 7.0: 1. Open a command prompt and navigate to IC_INSTALL_DIR\IC70\design\ CallCenterQ\data. 2. Open migrate_613_70_seed.cfg in an ASCII editor such as Notepad and verify that the administration login ID and password are correct. 3. Save and close the migrate_613_70_seed.cfg file. 4. Run migrate_613_70_import_seed.bat. 142 Software Upgrade and Data Migration May 2009

143 Reconfigure your 7.0 databases Import the localization seed data If you are migrating a localized version of Avaya IC: 1. Make sure that you have the localized version of Avaya IC Open a command prompt and navigate to IC_INSTALL_DIR\IC70\design\ CallCenterQ\data\L10N. 3. Open migrate_613_70_seed_l10n.cfg in an ASCII editor such as Notepad and verify that the administration login ID and password are correct. 4. Save and close the migrate_613_70_seed_l10n.cfg file. 5. Run migrate_613_70_import_seed_l10n.bat. Reconfigure your 7.0 databases In order to migrate your databases to 7.0, you need to reconfigure them. In order to do so, you will need an IC Manager login and password for an account with Administrator authority. All configurations of Avaya IC require you to upgrade your IC Repository and CallCenterQ database. For details, see Reconfigure the IC Repository database on page 143 and Reconfigure the CallCenterQ database on page 145. In addition, if your site uses the Outbound Contact Management feature, you need to reconfigure the associated Outbound Contact database. For details, see Reconfigure the Outbound Contact database on page 147. Reconfigure the IC Repository database If you need to determine how many rows of data are in your IC Repository database, you can use the following SQL statements to get a record count: : select count(*) from agentsegment select count(*) from routingevent select count(*) from mediainteraction select count(*) from contact select count(*) from mediasegment To reconfigure your IC Repository database for 7.0: 1. Start the 7.0 Database Designer and open IC_INSTALL_DIR\IC70\design\ repository\repository.adl. Software Upgrade and Data Migration May

144 Chapter 4: Upgrading Avaya Interaction Center from to 7.0 Tip: Tip: If you are using a localized Avaya IC environment, you will need to enable your 7.0 Database Designer to handle the localized files. For details, see the IC Database Designer User Guide. 2. On the Properties tab in the right-hand pane, make sure that the IC_INSTALL_DIR\ IC70\design\common and IC_INSTALL_DIR\IC70\design\QConsole directories are displayed in the Upload scripts from these directories box. If not, add them so that all of the required IC Scripts will be pushed to the database. 3. Expand Components > Physical DB Connections and select repositorydbconnection in the tree pane. 4. Verify that the connection information is correct. For details, see IC Installation and Configuration. The Database Name and Database Server should point to your database. 5. If your database has less than 3 million rows and you are going to reconfigure it in Database Designer: a. Make a note of the current Timeout parameter so that you can reset it after the reconfigure. b. Set the Timeout parameter to at least 7200 seconds. 6. Save the ADL file using File > Save. 7. Select File > Database Administration. 8. Select the Reconfigure option button. 9. Enable the Recreate Stored Procedures check box to update the database with the 7.0 database schema. 10. If necessary, enter your IC Manager Administrator username and password in the appropriate fields. (Do not enter your DBA username and password.) 11. If your database has over 3 million rows or you want to test this procedure, select Test. Instead of reconfiguring the database, Database Designer lists all of the SQL statements needed to reconfigure the database in the Status Messages section. You can cut and paste the statements into an ASCII text editor, modify the SQL statements as needed, and run the modified statements against the IC Repository database using your database administration tools. (For details, see the IC Database Designer User Guide.) Otherwise, select OK. Database Designer reconfigures the database. 144 Software Upgrade and Data Migration May 2009

145 Reconfigure your 7.0 databases CAUTION:! CAUTION: If the reconfigure reports any errors, such as a mttbinary: :timeout execute error, it is possible that the data has not been properly migrated and you will need to restore the database from a backup. Tip: Tip: Avaya recommends that you save the reconfigure SQL. 12. When Database Designer is finished, select Close. 13. If you increased the Timeout parameter in step 5, reset it to its previous value. 14. Save and close the ADL file. 15. If you selected Test in step 11, modify the generated SQL statements and apply them to the IC Repository database using your database administration tools. Reconfigure the CallCenterQ database If you need to determine how many rows of data are in your CallCenterQ database, you can use the following SQL statements to get a record count: Select count (*) from qem_message Select count (*) from qem_messagestatlog Select count (*) from w_chat_transcript In addition, if your CallCenterQ database is on Oracle, you should include the following command: Select count (*) from qw_text To reconfigure your CallCenterQ database for 7.0: 1. Open IC_INSTALL_DIR\IC70\design\CallCenterQ\ccq.adl in Database Designer. 2. On the Properties tab in the right-hand pane, make sure that the IC_INSTALL_DIR\ IC70\design\common and IC_INSTALL_DIR\IC70\design\QConsole directories are displayed in the Upload scripts from these directories box. If not, add them so that all of the required IC Scripts will be pushed to the database. 3. Expand Components > Physical DB Connections and select ccqconnection in the tree pane. 4. Verify that the connection information is correct. For details, see IC Installation and Configuration. The Database Name and Database Server should point to your database. Software Upgrade and Data Migration May

146 Chapter 4: Upgrading Avaya Interaction Center from to If your database has less than 3 million rows and you are going to reconfigure it in Database Designer: a. Make a note of the current Timeout parameter so that you can reset it after the reconfigure. b. Set the Timeout parameter to at least 7200 seconds. 6. Save the ADL file using File > Save. 7. Select File > Database Administration. 8. Select the Reconfigure option button. 9. Enable the Recreate Stored Procedures check box to update the database with the 7.0 database schema. 10. If necessary, enter your IC Manager Administrator username and password in the appropriate fields. (Do not enter your DBA username and password.) 11. If your database has over 3 million rows or you want to test this procedure, select Test. Instead of reconfiguring the database, Database Designer lists all of the SQL statements needed to reconfigure the database in the Status Messages section. You can cut and paste the statements into an ASCII text editor, modify the SQL statements as needed, and run the modified statements against the CallCenterQ database using your database administration tools. (For details, see the IC Database Designer User Guide.) Otherwise, select OK. Database Designer reconfigures the database. CAUTION:! CAUTION: If the reconfigure reports any errors, such as a mttbinary: :timeout execute error, it is possible that the data has not been properly migrated and you will need to restore the database from a backup. Tip: Tip: Avaya recommends that you save the reconfigure SQL. 12. When Database Designer is finished, select Close. 13. If you increased the Timeout parameter in step 5, reset it to its previous value. 14. Save and close the ADL file. 15. If you selected Test in step 11, modify the generated SQL statements and apply them to the CallCenterQ database using your database administration tools. 146 Software Upgrade and Data Migration May 2009

147 Reconfigure your 7.0 databases Reconfigure the Outbound Contact database To reconfigure your Outbound Contact Management database for 7.0, you need to start with the out-of-the-box 7.0 dialer.adl file: 1. Start Database Designer and open IC_INSTALL_DIR\IC70\design\SoftDialer\ dialer.adl. 2. Expand Components > Physical DB Connections and select dialerdbconnectionset in the tree pane, and: a. Verify that the connection information is correct. For details, see IC Installation and Configuration. The Database Name and Database Server should point to your database. b. Verify that the Display Time is set to DBMSTIME. If the Display Time is set to HOSTTIME, then the timestamp information will be changed and the Outbound Contact configuration will not be usable. 3. Save the 7.0 ADL file using File > Save. 4. Select File > Database Administration. 5. Select the Reconfigure option button. 6. Enable the Recreate Stored Procedures check box to update the database with the 7.0 database schema. 7. If necessary, enter your IC Manager Administrator username and password in the appropriate fields. (Do not enter your DBA username and password.) 8. Select OK. Tip: Tip: Avaya recommends that you save the reconfigure SQL. 9. When Database Designer is finished, select Close. 10. Close the ADL file. Software Upgrade and Data Migration May

148 Chapter 4: Upgrading Avaya Interaction Center from to 7.0 Generate your applications and load the new workflows! CAUTION: CAUTION: If you have customized any of the 7.0 IC Scripts or workflows, make sure that you have tested your customizations as described in Upgrade customized IC Scripts, workflows, and website files on page 135 before you push them to your production database. For all versions of Avaya IC, you need to generate the interaction_center application in the ccq.adl file and the repository application in the repository.adl file. Avaya recommends that you also generate the reportwizard application in the repository.adl file. (For details about generating applications, see the IC Database Designer User Guide.) Optionally, if you are using Business Advocate or List Management, you can generate the listq application in the ccq.adl file. To regenerate your applications and workflows: 1. In Database Designer, regenerate the interaction_center and repository applications, making sure that you push all IC Scripts to the database. 2. Optionally regenerate the reportwizard and listq applications, making sure that you push all IC Scripts to the database. Tip: Tip: The reportwizard application also has a help file that you should push to the database as well. (Default location: IC_INSTALL_DIR\IC70\help\ ReportWizard\Reports.chm.) 3. In Workflow Designer, recompile all customized 7.0 workflows and upload them to the database. Disable Business Advocate mapping rules If your site uses Business Advocate to route contacts, Avaya IC may encounter errors when it adds contacts into the routingattempt table IC Repository database. This information is not used in any out-of-the-box Avaya IC reports, so it is safe to disable these mapping rules. To do so: 1. Generate and install the Report Wizard application as described in IC Installation and Configuration. 2. Open the Report Wizard and go to the Mapping Administration focus. 148 Software Upgrade and Data Migration May 2009

149 Migrate your server settings into In the Creation Rules group, enter routingattempt in the Table Name field and select Search. 4. The Report Wizard should find two mapping rules for that table. Select the first one and: a. Select Change and set the rule to be inactive, then select Update to save the change. b. Select Search in the Field Expressions group. c. For all associated field expressions, select Change and set the expression to be inactive, then select Update to save the change. Select the second mapping rule and repeat this process. For details about using the Report Wizard, see IC Administration Volume 1: Servers & Domains. Migrate your server settings into 7.0 In order to migrate your server settings, you first need to restart the Directory server and create a new agent administrator account. To do so: 1. Open the 7.0 IC Manager. 2. Stop and then restart the Directory server. 3. Select Manager > Refresh. 4. Add a new Administrator account that can be used as a secondary login for IC Manager in case the regular Administrator account encounters any login-related issues during the migration process. To do so: a. Select the Agent tab. b. In the left pane, select the Default workgroup. c. Select Agent > New. IC Manager displays the Agent Editor dialog box. d. Enter required basic information for the agent record. The login ID you select should be the install user for the Avaya IC software. e. Select the Security tab and set a password for this account. In the Agent Roles section, select the Administrator check box. Important:! Important: Avaya recommends that you have a backup Administrator account in case of any unforeseen login issues. If you cannot log into IC Manager using any of your administrator accounts, you need to review the icmanager_admin.log for database errors or disabled login. Software Upgrade and Data Migration May

150 Chapter 4: Upgrading Avaya Interaction Center from to 7.0 Import your server settings To import your server settings into 7.0: 1. Select Manager > Options. IC Manager displays the Options dialog box. 2. Select the Environment tab. 3. Hold the Ctrl+Alt keys and double-click the left mouse button anywhere on this dialog. 4. IC Manager displays a new button called XML Maintenance under the Export Configuration button. 5. Select XML Maintenance. 6. In the XML Record Maintenance dialog box, select server.xsd and select Import. 7. In the File Chooser, select the server.xsd file from IC_INSTALL_DIR\IC70\etc. 8. Select OK to return to the Options dialog box. 9. Select Import Configuration. 10. In the File Chooser, select the sc.xml file from IC_INSTALL_DIR\IC70\etc. IC Manager should display a message stating that the sc.xml file has been successfully validated. 11. Select OK to import the server settings. 12. Select OK to close the Options dialog box. 13. Exit from IC Manager and then restart it so that it reads the updated configuration information. Import new agent properties To import the new agent properties into your migrated system: 1. Open a command prompt and navigate to IC_INSTALL_DIR\IC70\design\ repository\data. 2. Open import_properties.bat in an ASCII editor such as Notepad and verify that the administration login ID and password are correct. 3. Save and close the file. 4. Run import_properties.bat. 5. To see the new properties, open IC Manager. If IC Manager is already running, select Manager > Refresh. For details about all Avaya IC agent properties, see IC Administration Volume 2: Agents, Customers, & Queues. 150 Software Upgrade and Data Migration May 2009

151 Migrate your Content Analyzer data Migrate your Content Analyzer data If your Content Analyzer Knowledge Bases can be accessed through the same fully-qualified file path by the new 7.0 servers as was used by your old servers, then all you need to do is: Bring up the Avaya IC 7.0 system Recreate your Content Analyzer servers in the 7.0 environment Ensure that Content Analyzer works as expected The recommended installation directory for your Knowledge Bases is: C:\Program Files\Avaya\kbs (Windows)../opt/Avaya/kbs (Unix) If you need to move the Content Analyzer Knowledge Bases relative to the servers: 1. Make sure that all of the Knowledge Bases you identified in Prerequisites for migrating Content Analyzer on page 121 are stored in a directory on a machine that is accessible to any server machine that will be running a CAAdmin or CAServer server. Make a note of all the Knowledge Base names and file locations. If appropriate, consult your Content Analyzer Administrator for the approved location of the Knowledge Base files. 2. If you want to change any of your Knowledge Base file names, you should do so at this point. Make sure that you make a note of the old and new filenames so that you can change the File Location information when you configure the associated 7.0 CAServer.! Important: Important: Do not change the Knowledge Base name during the migration process. Any such changes should be done through IC Manager once the 7.0 system is up and running. 3. In the CallCenterQ database, change the file names and locations in the knowledgebase database table to reflect the new names and locations for your Knowledge Bases. To do so, run the following database-specific SQL script for each of the migrated Knowledge Bases. For SQL Server: 1. Open the SQL Server Query Analyzer. 2. Connect to the appropriate 7.0 CCQ database. Software Upgrade and Data Migration May

152 Chapter 4: Upgrading Avaya Interaction Center from to Run the following SQL script for each of the renamed or moved Knowledge Bases: For Oracle: USE ccq UPDATE knowledgebase SET knowledgebase.kbfilepath = 'Full_Destination_KB_Path' WHERE knowledgebase.name = 'KB_Name' AND knowledgebase.kbfilepath = 'Full_Source_KB_File_Path' Where Full_Destination_KB_Path is the fully-qualified location of the 7.0 Knowledge Base (including the file name), KB_Name is the Knowledge Base name, and Full_Source_KB_File_Path is the fully-qualified name of the corresponding Knowledge Base. (Do not change the quotation marks.) 1. Open an SQL Plus Worksheet. 2. Connect to the appropriate Oracle 7.0 Avaya IC database. 3. Run the following SQL Plus script for each of the renamed or moved Knowledge Bases: UPDATE ccq.knowledgebase SET knowledgebase.kbfilepath = 'Full_Destination_KB_Path' WHERE knowledgebase.name = 'KB_Name' AND knowledgebase.kbfilepath = 'Full_Source_KB_File_Path'; COMMIT; Where Full_Destination_KB_Path is the fully-qualified location of the 7.0 Knowledge Base (including the file name), KB_Name is the Knowledge Base name, and Full_Source_KB_File_Path is the fully-qualified name of the corresponding Knowledge Base. (Do not change the quotation marks.) Verifying the new Knowledge Base file locations To make sure that your changes are accurate, run the SQL statements shown in Determining the training and validation information for your Knowledge Bases on page 123. The entries in the KB File column should match the new locations and names for your Knowledge Bases. 152 Software Upgrade and Data Migration May 2009

153 Upgrade your Avaya Agent applications Upgrade your Avaya Agent applications! CAUTION: CAUTION: You should upgrade all servers and Avaya Agent applications before you run any of them. (In other words, you should never run a mixture of 6.x and 7.0 servers and/or Avaya Agent applications.) To upgrade your Avaya Agent application installations: 1. Create a new Agent Installer, as described in IC Installation and Configuration. 2. Copy the saved vesp.imp file into the AgentInstaller\config directory. 3. Run the Site Preparation Wizard. By default, the Agent Site Preparation Wizard places the: Agent installer in C:\Program Files\Avaya\IC70\AgentInstaller. Agent desktop applications in a directory path that includes IC 7.0, to ensure that the agent applications are correctly updated. 4. On every Avaya Agent application machine: a. Run the Agent Installer for every Avaya Agent application machine. (You do not need to uninstall the old Avaya Agent first.) The Agent Installer saves the agent s IC_INSTALL_DIR\IC70\bin\vtel.ini and IC_INSTALL_DIR\IC70\etc\vtel.ini files as vtel.ini.backup in their respective directories. b. If necessary, restore the agent s customized vtel.ini file in the agent s bin and etc directories. c. If you are running a localized version of Avaya Agent, install the language packs as described in IC Installation and Configuration. d. If you want to run the new Avaya Agent Web Client on this machine, update the Java Plug-in to version 1.4.2_06. For details, see IC Installation Planning and Prerequisites. Software Upgrade and Data Migration May

154 Chapter 4: Upgrading Avaya Interaction Center from to 7.0 Uninstall After 7.0 is up and running, you can remove 6.1.3: 1. Stop IC Manager. 2. Stop all Avaya IC servers: a. Go to the server machine running the Primary ORB server. b. For Windows, open a command prompt, navigate to IC_INSTALL_DIR\IC70\bin, and run icadmin tva <Username> <PW>. c. For Solaris or AIX, navigate to IC_INSTALL_DIR/IC70/bin and run./icadmin tva <Username> <PW>. d. Make sure that you wait until all Avaya IC servers have been shut down. 3. Stop all of the Avaya IC Website servers and services, including Tomcat, ICM, and CIRS. For details, see IC Installation and Configuration. 4. Uninstall On all machines on which Database Designer is being used, you need to re-register Database Designer. To do so: a. Open a Command Prompt and navigate to IC_INSTALL_DIR\IC70\bin\ Migration. b. Run regdesigner.bat. 6. On all machines running a Notification server, you need to re-register the server. To do so: a. Open a Command Prompt and navigate to IC_INSTALL_DIR\IC70\bin. b. Run regserver.bat. 7. On all machines on which Outbound Contact is being used, you need to re-register the reporting feature. To do so: if the reporting feature is running on an Avaya IC administration machine, open a Command Prompt and navigate to IC_INSTALL_DIR\IC70\bin\Migration, then run regcrystal.bat. if the reporting feature is running on a server machine, from one of the Avaya IC administration machines copy IC_INSTALL_DIR\IC70\bin\Migration\ regcrystal.bat to IC_INSTALL_DIR\IC70\bin on the server machine, then run regcrystal.bat. 8. If you use IV Chat, you need to re-register the VMM service. For details, see Set up the VMM Service on page Software Upgrade and Data Migration May 2009

155 Detailed changes to the IC Scripts, workflows, and website files Uninstall Avaya Agent applications If you want to uninstall the Avaya Agent applications from your agent machines, you will need to re-register the 7.0 Avaya Agent. To do so: 1. Uninstall the Avaya Agent. 2. Open a Command Prompt and navigate to IC_INSTALL_DIR\IC70\bin. 3. Run the following commands: RegAgentClient.bat RegCsClient.bat vtel -register Detailed changes to the IC Scripts, workflows, and website files Bug fixes were made to some IC Scripts and workflows in 7.0. If you have customized these files, you need to either reapply your customizations to the 7.0 out-of-the-box files, or continue to use your files and not take advantage of those bug fixes. For a list of changes, see IC Script changes, below, and Workflow changes on page 157. If you have customized any of the website files that have changed in 7.0, you will need to reapply your customizations to the new 7.0 out-of-the-box website files. For a list of changes, see Website file changes on page 157. Software Upgrade and Data Migration May

156 Chapter 4: Upgrading Avaya Interaction Center from to 7.0 IC Script changes Bug fixes and support for chat transfers and conferences were made to some IC Scripts in 7.0. While you can copy other customized IC Scripts from the IC613_INSTALL_DIR\IC61\ design\<appname> subdirectory into the appropriate IC_INSTALL_DIR\IC70\design directory, you should reapply your customizations to these out-of-the-box IC Scripts in order to take full advantage of the bug fixes in 7.0. Location IC Scripts changed in 7.0 design\qconsole design\qconsole\custom design\qconsole\siebel avaya_agent_en.cdl BlenderClient_AgentStateEvent.qsc _Transfer.qsc MailEngine_TransferResponse.qsc Softphone_InitBlindTransfer.qsc Softphone_InitConference.qsc Softphone_InitConsTransfer.qsc StatusDialog ButtonClicked.qsc StatusDialog_Update.qsc UAD_SetContact.qsc Web_Transfer.qsc WebEngine_TransferResponse.qsc Custom_IHH_ME_TransferResponse.qsc Custom_IHH_WE_TransferResponse.qsc Siebel_IHH_ME_TransferResponse.qsc Siebel_IHH_WE_TransferResponse.qsc 156 Software Upgrade and Data Migration May 2009

157 Detailed changes to the IC Scripts, workflows, and website files Workflow changes Only one Business Advocate-related system workflow, named sys_transfer.update_vq_cache, has changed in 7.0 to enable virtual queue transfers. You can copy your customized workflows from IC613_INSTALL_DIR\IC61\design\IC\ Flows\Avaya\ to IC_INSTALL_DIR\IC70\design\IC\Flows\Avaya\, but if your installation uses Business Advocate, you must use the 7.0 out-of-the-box sys_transfer.update_vq_cache workflow. Website file changes The following website files have changed in 7.0. If you have customized any of these files, you will need to reapply your customizations to the new 7.0 out-of-the-box versions. Otherwise, you can copy your customized website files into the 7.0 website directory. IC_INSTALL_DIR\IC70\website\public\escalate.jsp IC_INSTALL_DIR\IC70\website\public\joinus.jsp IC_INSTALL_DIR\IC70\website\public\include\checkjvm.jsp In addition, the following directories have been added in 7.0: IC_INSTALL_DIR\IC70\website\public\nojvm IC_INSTALL_DIR\IC70\website\public\htmlcliente Software Upgrade and Data Migration May

158 Chapter 4: Upgrading Avaya Interaction Center from to Software Upgrade and Data Migration May 2009

159 Chapter 5: Upgrading Avaya Interaction Center from 6.1.x to This chapter contains information that helps you upgrade from Avaya Interaction Center (Avaya IC) from 6.1.x to release If you are starting from an earlier release, you must first migrate to For details, see the appropriate chapter in this manual. There were no functional changes between Avaya IC releases 6.1, and 6.1.2, because added internationalization support to the 6.1 code base, and added migration tools to the 6.1 code base. Therefore, the upgrade steps are the same whether you are moving from 6.1, 6.1.1, or Considerations When you upgrade to 6.1.3, you should keep the following things in mind: Operating system or database version changes: These instructions assume that you are not changing your operating system, database, or database version. If you want to upgrade or change operating systems or databases, Avaya recommends that you install as a new installation or contact Avaya Professional Services for assistance. Java Virtual Machine changes: The version of Internet Explorer that is provided with Microsoft Windows operating systems shipped after December 2003 does not include a Java Virtual Machine (JVM). These operating systems include Windows XP Professional and Windows Server The following Avaya IC components require a JVM to function correctly: Template Administration Avaya Agent Business Applications IC Manager If you host these components on a machine with Windows XP Professional or Windows Server 2003, you must download and install either the Microsoft JVM or the Sun JVM 1.3.1_06 on those machines. Additionally, customers using the Chat feature may be asked to download a new version of the Microsoft or Sun JVM. Software Upgrade and Data Migration May

160 Chapter 5: Upgrading Avaya Interaction Center from 6.1.x to For more information about JVM requirements for Avaya IC and certain website customer limitations with the Sun JVM, see IC Installation Planning and Prerequisites. Upgrading Avaya Operational Analyst For details about upgrading Avaya OA, see the Avaya Operational Analyst Release Installation and Configuration manual. Upgrading Siebel For details about upgrading Siebel, see Avaya IC for Siebel Integration. Prerequisites The following steps need to be preformed before you begin the upgrade to 6.1.3: 1. The installer will back up files from your system32 directory (default name: C:\ WINDOWS\system32) into a directory called c:\documents and Settings\ <Username>\local settings\temp\sys32backup. If this directory already exists from a previous installation, you will receive an error and the installer will not be able to back up your original files. To prevent this problem, before you install on your administration and server machines, verify that the c:\documents and Settings\<Username>\local settings\temp\sys32backup directory does not already exist. If it does, rename it so that the installer will correctly back up your original files. You need to set your Explorer folder options to show hidden files in order to check this directory. 2. If desired, back up your IC_INSTALL_DIR\IC61\etc directory so that you do not accidentally overwrite your vesp.imp and ds.ffd files. 3. If you are using a localized version of Database Designer, you need to back up your WINDOWS_INSTALL_DIR\qdesigner.ini file so that you can restore it after the upgrade. 160 Software Upgrade and Data Migration May 2009

161 Shut down 6.1.x Upgrading customized IC Scripts, workflows, and website files Your customized 6.1.x IC Scripts and workflows will continue to work in However, Avaya recommends that you reapply your customizations to the out-of-the-box files in order to take advantage of the bug fixes included in You can find a list of changed files in IC Script changes on page 169 and Workflow changes on page 170.! Important: Important: You must use the version of the CoreService_Initialize IC Script or agents will be unable to log into the Avaya Agent application. If you have customized any of the Avaya IC website files that have changed in 6.1.3, you will need to reapply your customizations to the new out-of-the-box versions or your website will not work. You can find a list of changed files in Website file changes on page 173. In order to minimize the amount of time that your production system will be shut down, Avaya recommends that you install an out-of-the-box version of and use that to test your customized IC Scripts, workflows, and website files. To upgrade your IC Script, workflow, and website files: 1. Set up an out-of-the-box test system. 2. Merge your customizations with the out-of-the-box IC Script, workflow, and website files that have changed since (for the names of the changed files, see Changes to the IC Scripts, workflows, and website files on page 168). 3. Copy all customized IC Script, workflow, and website files into your test system. 4. Verify that all of your customized files work the way you expect. Shut down 6.1.x Before you can upgrade to 6.1.3, you need to: 1. Stop all Avaya Agent applications. 2. Stop IC Manager. 3. Stop all Avaya IC servers: a. Go to the server machine running the Primary ORB server. b. For Windows, open a command prompt, navigate to IC_INSTALL_DIR\IC61\bin, and run icadmin tva <Username> <PW>. c. For Solaris or AIX, navigate to IC_INSTALL_DIR/IC61/bin and run./icadmin tva <Username> <PW>. Software Upgrade and Data Migration May

162 Chapter 5: Upgrading Avaya Interaction Center from 6.1.x to d. Make sure that you wait until all Avaya IC servers have been shut down. 4. Stop all of the Avaya IC Website servers and services, including Tomcat, ICM, and CIRS. For details, see IC Installation and Configuration. Upgrading to In order to upgrade to 6.1.3, you need to follow these steps in the order given: 1. Upgrade your server installations 2. Upgrade your Design/Admin installations 3. Upgrade Business Advocate 4. Upgrade your Avaya Agent applications 5. Restart the primary ORB server 6. Import your server settings into Import the IC Scripts and workflows 8. Import the seed data 9. Upgrade the Full Text Search Engine 10. Reconfigure the servers on Solaris and AIX 11. Stop and restart all Avaya IC servers These steps are described in the following sections. Upgrade your server installations! Important: Important: If you are installing your servers on a Solaris machine, make sure that you log in with the same user ID that was used for the original 6.1.x installation. Otherwise, Avaya IC will not be able to detect the fact that a previous version of Avaya IC exists. To upgrade your server machines to 6.1.3: 1. Install the servers over your current server installation(s). 2. When prompted, select the telephony switch that you specified when you ran the Configuration Tool during the original 6.x install. 3. Reboot the server machines when prompted. 162 Software Upgrade and Data Migration May 2009

163 Upgrading to Upgrade your Design/Admin installations To upgrade from 6.1.x to 6.1.3: 1. Install over your current Design/Admin installation(s). All of the design directories installed during the product installation (CallCenterQ, common, CustQ, hrq, and so on), and the files in them, are backed up as subdirectories beneath IC_INSTALL_DIR\ IC61\backup\design. The upgrade then installs new versions of the files in the design directories. In addition, the installation program backs up the entire website directory to IC_INSTALL_DIR\IC61\backup\website. Important:! Important: When the installation prompts you to run the Configuration Tool, select Cancel. You should not run the Configuration Tool at this point. 2. Reboot the administration machine when prompted. 3. Restore your customized design files and database connection information by copying the backup ADC, ADF, ADL, and ALM files created by the installation program in Step 1. Copy: If your site uses... Copy the following files... From... To... Any Avaya IC component repository.adc repository.adf repository.adl repository.alm IC_INSTALL_DIR\IC61\ backup\design\repository IC_INSTALL_DIR\IC61\ design\repository ccq.adc ccq.adf ccq.adl ccq.alm IC_INSTALL_DIR\IC61\ backup\design\callcenterq IC_INSTALL_DIR\IC61\ design\callcenterq The HRQ Business Application hrq.adc hrq.adf hrq.adl hrq.alm IC_INSTALL_DIR\IC61\ backup\design\hrq IC_INSTALL_DIR\IC61\ design\hrq The CustomerQ Business Application custq.adc custq.adf custq.adl custq.alm IC_INSTALL_DIR\IC61\ backup\design\custq IC_INSTALL_DIR\IC61\ design\custq Outbound Contact dialer.adc dialer.adl dialer.alm IC_INSTALL_DIR\IC61\ backup\design\softdialer IC_INSTALL_DIR\IC61\ design\softdialer Software Upgrade and Data Migration May

164 Chapter 5: Upgrading Avaya Interaction Center from 6.1.x to CAUTION: 4. Restore your customized IC Script, workflow, and website files that you verified in Upgrading customized IC Scripts, workflows, and website files on page 161 by coping those files over the out-of-the-box versions.! CAUTION: Make sure that you have verified that your customizations work as expected in out-of-the-box IC Script, workflow, and website files before you overwrite the out-of-the-box files. 5. If you are using a localized version of Database Designer, restore the 6.1.x WINDOWS_INSTALL_DIR\qdesigner.ini file that you backed up in Prerequisites on page 160. Upgrade Business Advocate To upgrade Business Advocate, load the Business Advocate installation CD-ROM on each of your Business Advocate machines and follow the installation prompts. The installation procedure will automatically detect the previously-installed version and make the necessary upgrade changes. After you have installed the version, reboot your Business Advocate machine. Upgrade your Avaya Agent applications! CAUTION: CAUTION: You should upgrade all servers and all Avaya Agent applications before you run any of them. (In other words, you should never run a mixture of 6.1.x and servers and/or Avaya Agent applications.) To upgrade your Avaya Agent installations: 1. Create a new Agent Installer, as described in IC Installation and Configuration. 2. Copy the saved vesp.imp file into the AgentInstaller\config directory. 3. Run the Site Preparation Wizard. By default, the Agent Site Preparation Wizard places the: Agent installer in a directory path that includes IC613 to ensure that you do not overwrite an IC 6.1 version of the agent installer. The default directory path is C:\Program Files\Avaya\IC613\AgentInstaller. Agent desktop applications in a directory path that includes IC 6.1, to ensure that the agent applications are correctly updated. 164 Software Upgrade and Data Migration May 2009

165 Upgrading to On every Avaya Agent application machine: a. Run the Agent Installer for every Avaya Agent application machine. (You do not need to uninstall the old Avaya Agent first.) The Agent Installer saves the agent s IC_INSTALL_DIR\IC61\bin\vtel.ini and IC_INSTALL_DIR\IC61\etc\vtel.ini files as vtel.ini.backup in their respective directories. b. If necessary, restore the agent s customized vtel.ini file in the agent s bin and etc directories. Restart the primary ORB server At this point, you can restart the Avaya IC servers. To do so: 1. Go to the server machine running the Primary ORB server. 2. For Windows, open a command prompt, navigate to IC_INSTALL_DIR\IC61\bin, and run icadmin so. 3. For Solaris or AIX, navigate to IC_INSTALL_DIR/IC61/bin and run./icadmin so. Import your server settings into To restart Avaya IC: 1. Import your server configuration file into 6.1.3: a. Start IC Manager. b. Select Manager > Options. c. Select the Environment tab. d. Select Import Configuration. e. Select the sc.xml file from the IC_INSTALL_DIR\IC61\etc directory. f. Select OK to import the configurations. IC Manager should display a message stating that the sc.xml file has been successfully imported. g. Exit from IC Manager and then restart it so that it reads the updated configuration information. 2. If any of your Workflow servers reference the web_routing.update_agent_primarygroup workflow as one of their start up workflows, this reference needs to be deleted. To do so: a. In IC Manager, double-click on the Workflow server you want to update. b. In the Server Editor dialog box, select the WorkFlow tab. Software Upgrade and Data Migration May

166 Chapter 5: Upgrading Avaya Interaction Center from 6.1.x to c. Select the ellipses (...) next to Startup Flows. IC Manager displays the Startup Flows dialog box. d. Select the web_routing.update_agent_primarygroup workflow from the list, and then select Delete. e. Select OK to close the Startup Flows dialog box, then select OK to close the Server Editor and save your changes. Import the IC Scripts and workflows! CAUTION: CAUTION: If you have customized any of the IC Scripts or workflows, make sure that you have tested your customizations as described in Upgrading customized IC Scripts, workflows, and website files on page 161 before you push them to your production database. To import the IC Scripts and workflows: 1. In Database Designer, regenerate your applications, making sure that you push all IC Scripts to the database. (You do not need to regenerate the forms unless you have made other changes while upgrading to ) 2. In Workflow Designer, recompile all customized workflows and upload them to the database. Import the seed data To import the new seed data for 6.1.3: 1. Open a command prompt and navigate to IC_INSTALL_DIR\IC61\design\ CallCenterQ\data. 2. Open update_612_613_seed.cfg in an ASCII editor such as Notepad and verify that the administration login ID and password are correct. 3. Save and close the update_612_613_seed.cfg file. 4. Run update_612_613_import_seed.bat. 166 Software Upgrade and Data Migration May 2009

167 Upgrading to Upgrade the Full Text Search Engine To upgrade the Full Text Search Engine (FTSE): 1. On any machines hosting the Avaya IC website (either administrative or public), install FTSE, as described in Chapter 3 of IC Installation and Configuration. 2. Start the Configuration Tool by selecting Start > Programs > Avaya Interaction Center > Configuration Tool. 3. Select the Web tab. 4. Do not change any of the values on the Web tab, just select OK. 5. Configure the Web Self-Service feature as described in Chapter 14 of IC Installation and Configuration. Use the configuration section appropriate to your operating system. Reconfigure the servers on Solaris and AIX If you are running Avaya IC servers on Solaris or AIX, you need to run the Configuration Tool in order to update the icenv file. On all Solaris and AIX machines: 1. Start the Configuration Tool by selecting Start > Programs > Avaya Interaction Center > Configuration Tool. 2. Select the Initial Configuration tab. CAUTION:! CAUTION: Do not change any of the values on the Web tab. 3. Make sure that the Locale field is correctly set. 4. Select OK. This process adds the following entries to the icenv file: LC_MESSAGES=%LC_TYPE% export LC_MESSAGES def_desc_limit=1024 if [ "`ulimit -n`" -lt "$def_desc_limit" ]; then ulimit -n $def_desc_limit fi 5. If you are running Avaya IC as a non-root user on AIX, you need to navigate to IC_INSTALL_DIR/IC61/bin and issue the following command: chmod 555 cvlansvr Software Upgrade and Data Migration May

168 Chapter 5: Upgrading Avaya Interaction Center from 6.1.x to Stop and restart all Avaya IC servers You need to stop and restart all core servers, web servers, Tomcat services, and the ICM services. 1. To stop all Avaya IC servers: a. Go to the server machine running the Primary ORB server. b. For Windows, open a command prompt, navigate to IC_INSTALL_DIR\IC61\bin, and run icadmin tva <Username> <PW>. c. For Solaris or AIX, navigate to IC_INSTALL_DIR/IC61/bin and run./icadmin tva <Username> <PW>. d. Make sure that you wait until all Avaya IC servers have been shut down. 2. Make sure that the Avaya IC Website servers and services, including Tomcat, ICM, and CIRS, are not running. For details, see IC Installation and Configuration. 3. To restart all servers: a. Go to the server machine running the Primary ORB server. b. For Windows, open a command prompt, navigate to IC_INSTALL_DIR\IC61\bin, and run icadmin so. c. For Solaris or AIX, navigate to IC_INSTALL_DIR/IC61/bin and run./ icadmin so. d. Repeat this procedure for each machine hosting an ORB server. 4. Start the web services. For details, see IC Installation and Configuration. 5. Start IC Manager and restart your Avaya IC servers. Changes to the IC Scripts, workflows, and website files Bug fixes were made to some IC Scripts and workflows in If you have customized these files, you need to either reapply your customizations to the out-of-the-box files, or continue to use your 6.1.x files and not take advantage of those bug fixes. For a list of changes, see IC Script changes, below, and Workflow changes on page 170. If you have customized any of the website files that have changed in 6.1.3, you will need to reapply your customizations to the new out-of-the-box website files. For a list of changes, see Website file changes on page Software Upgrade and Data Migration May 2009

169 Changes to the IC Scripts, workflows, and website files IC Script changes Bug fixes were made to some IC Scripts in While you can copy other customized IC Scripts from the IC_INSTALL_DIR\IC61\backup\design\<appname> subdirectory into the appropriate design directory, you should reapply your customizations to these out-of-the-box IC Scripts in order to take full advantage of the bug fixes in IC Scripts changed in Issue resolved avaya_agent_en.cdl CoreServices_Initialize EDUViewer_Initialize PhoneEngine_ OnTelephonyStateChanged.qsc The default size of the font for the Softphone buttons should be 10 instead of otherwise, this gets displayed incorrectly on some language OS's. Need to externalized I18N lookup table for Avaya Agent and the Business Applications. EDU Viewer shows GMT time by default when all other agent UI times default to local time. If Avaya IC receives a TS.Disconnect BEFORE a TS.Ring, TS.Busy, or TS.IncomingCall, then the EDU needs to be terminated. QConsole_CompleteContact.qsc After Installing SP1 agent receives "QConsole_WrapContact Error 91: Object variable or With Block Not Set". QConsole_CompleteContact.qsc QConsole_PlaceCall.qsc QConsole_RemoveContact.qsc QConsole_TransferRelatedChat.qsc A few of the Integration Hooks have wrong parameters. qconsole_placecall function has undefined seduid variable in qconsole.qsc. If Avaya IC receives a TS.Disconnect BEFORE a TS.Ring, TS.Busy, or TS.IncomingCall, then the EDU needs to be terminated. Need to introduce a Agent/ Desktop.MultimediaAllowed for Thick Client to work with ICTC. QConsole_TransferRelatedChat.qsc QConsole_UpdateActivePanes.qsc Shared_OnActivate.qsc Shared_OnSelect.qsc Need to introduce a Agent/ Desktop.MultimediaAllowed for Thick Client to work with ICTC. SD Agent - Outbound agent transitioning to inbound must manually select proceed to continue. A few of the Integration Hooks have wrong parameters. A few of the Integration Hooks have wrong parameters. Software Upgrade and Data Migration May

170 Chapter 5: Upgrading Avaya Interaction Center from 6.1.x to IC Scripts changed in Softphone_Login.qsc Web_HandleIVChatInitialize.qsc Web_HandleIVChatInitialize.qsc WebEngine_ActivateCallback.qsc WebEngine_ActivateCallback.qsc WebEngine_WebStateChanged.qsc Issue resolved Need to introduce an Integration Hook into the Softphone_Login IC Script. Need to introduce a Agent/ Desktop.MultimediaAllowed for Thick Client to work with ICTC. Need to introduce a Agent/ Desktop.MultimediaAllowed for Thick Client to work with ICTC. Need to introduce a Agent/ Desktop.MultimediaAllowed for Thick Client to work with ICTC. Need to introduce an Agent/ Desktop.MultimediaAllowed for Thick Client to work with ICTC. If a chat is incoming with a task state other than Open, then the proper events must take place. Workflow changes The following workflows have changed in If you have customized any of these files, you will need to reapply your customizations to the new out-of-the-box versions and then upload the new flows to the database. Otherwise, you can copy your other customized workflows back into the appropriate workflow directory under IC_INSTALL_DIR\IC61\ design\ic\flows\avaya\. Workflow files changed in advocate.handle_exception advocate.qualify _adv advocate.qualifychat_adv advocate.qualifyvoice_adv advocate.transfertoagent_adv advocate_sbl.qualifychat_adv_sbl advocate_sbl.qualif _adv_sbl advocate_sbl.qualifyvoice_adv_sbl advocate.qualifychat_adv advocate.qualify _adv advocate.qualifyvoice_adv Issue resolved The Set Qualifier block in the Advocate flows creates INFO alarms for unknown customers. This should not happen. Map to Qualifier block may select incorrect Qualifier_N property if Source property is NULL 170 Software Upgrade and Data Migration May 2009

171 Changes to the IC Scripts, workflows, and website files Workflow files changed in advocate.qualify _adv advocate.qualify _adv, ic .outboundca, ic .outboundnoca advocate_sbl.qualify _adv_sbl Advocate: qualify _adv, qualifychat_adv advocate_sbl: qualify _adv_sbl, qualifychat_adv_sbl ic _sbl.xferoutbound toic_sbl icm_sbl.transcriptadded_sbl siebel: preanalyze_sbl preanalyzenoca_sbl Issue resolved Modify the qualify _adv flow to keep the original customer qualifiers when going to the supervisor approval branch. The Business Advocate qualifiers found in the Customer record were not being considered when the was sent through the QA loop. Logic has been changed in the workflow to use the data in the customerinfo container of the EDU to populate customer qualifiers (language, customertype and preferedagent). All routing hints and Business Advocate qualifiers are administered and handled in lowercase. However, the routing hint for outbound QA=suspectcontent or approvalrequired has the category (QA) in uppercase. The advocate.qualify _adv flow was looking for QA instead of qa. Both the ic .outboundca and ic .outboundnoca flows were changed to set the routing hint to qa (lowercase) and the advocate.qualify _adv flow was modified to look for qa instead of QA. The Siebel Advocate qualification workflow does not write the activityid into the EDU The Fetch Routing Hints block attempted to query the qw_qualifier table 'msgid' field with a null string "". This eventually caused the Workflow server to crash when the workflow finally completed. The Fetch Routing Hints block attempted to query the qw_qualifier table 'msgid' field with a null string "". This eventually caused the Workflow server to crash when the workflow finally completed. The Siebel Outbound workflow incorrectly sets flag values for outbound retry when not EAI.Get error occurs. IC_Siebel: WF_Webcenter Alarms on "Fetched a very high number(..) of records- suspect icm_sbl.transcriptadded_sbl flow The Put block could not take additional couples to indata input argument. Software Upgrade and Data Migration May

172 Chapter 5: Upgrading Avaya Interaction Center from 6.1.x to Workflow files changed in sys_transfer.update_vq_cache ts.incoming_call wacd: qualify , qualifychat wacd_sbl: qualify _sbl, qualifychat_sbl webcenter.schedulecallback Issue resolved Because Business Advocate service class administration changes are not synchronized with Avaya IC, if you use service classes in a virtual queue which are later deleted, running the flow will cause an exception. This prevents the Workflow server from starting. The sys_transfer.update_vq_cache flow now generates an Alarm when it finds a virtual queue whose Advocate service class members do not exist. The missing virtual queue is named in the alarm, and the workflow ignores that virtual queue. Updated workflow to support VQS by adding 'digits' Input arg to EDU The Fetch Routing Hints block attempted to query the qw_qualifier table 'msgid' field with a null string "". This eventually caused the Workflow server to crash when the workflow finally completed. The Fetch Routing Hints block attempted to query the qw_qualifier table 'msgid' field with a null string "". This eventually caused the Workflow server to crash when the workflow finally completed. Webcallback question is not seen in the EDUViewer Block changes Set Route Parameters: The block no longer ignores the specified Wait property in the steps that it creates. 172 Software Upgrade and Data Migration May 2009

173 Changes to the IC Scripts, workflows, and website files Website file changes The following website files have changed in If you have customized any of these files, you will need to reapply your customizations to the new out-of-the-box versions. Otherwise, you can copy the other customized website files back into the website directory. Website Files Changed in website/admin files login.jsp agent/navbar.jsp tenancy/editlanguages.jsp wtc/transcript.jsp website/admin/wru files wru.jsp wruedit.jsp wruproposed.jsp wrusearch.jsp website/admin/wru/xsl files approvelist display displayparts edit search website/public files escalate.jsp wru.jsp wrusearch.jsp website/public/include files header.jsp footer.jsp validateescalate.jsp website/public/include/xsl files display displayparts search Software Upgrade and Data Migration May

174 Chapter 5: Upgrading Avaya Interaction Center from 6.1.x to Software Upgrade and Data Migration May 2009

175 Chapter 6: Upgrading and migrating from to This chapter contains procedures and information that help you upgrade and migrate from Avaya Interaction Center (Avaya IC) and Avaya Operational Analyst (Avaya OA) to If you are migrating a DB2 system from 5.6 SP1 to 6.1.2, see Migrating DB2 Systems from 5.6 SP1 to on the Avaya support website. For details about accessing this document, see Migration\Readme.pdf on the installation CD-ROM.! Important: Important: If you have a pre release of Avaya IC or Avaya OA, you must first migrate from that release to 6.0.2, and then immediately migrate from that to Except for 5.6 SP1 DB2 systems, details about the migration path from Avaya IC 5.6 SP1 and 6.0 to can be found in later chapters in this document. For procedures about how to upgrade to Avaya OA 6.0.2, see Avaya Operational Analyst Release Installation and Maintenance. If your Avaya OA system is or 6.1.1, do not use the procedures in this document to upgrade your software. For procedures about how to upgrade Avaya OA from or to 6.1.2, see Avaya Operational Analyst Release 6.1 Installation and Configuration. The purpose of the upgrade and migration process is to: install the Avaya IC software and migrate your servers and domains in your new environment upgrade the Avaya OA software to upgrade the Avaya IC databases to use the out-of-the-box data schema with your customizations added upgrade the Avaya OA historical database to the out-of-the-box database schema migrate all of your current application and historical data into your upgraded database merge your customized client application (ADL) files with the new features provided in so that you can take advantage of the new features while retaining your customizations Software Upgrade and Data Migration May

176 Chapter 6: Upgrading and migrating from to Overview of the migration process The migration process assumes that: Your database has archive logging/transaction logging turned on Online backups are done on a regular basis The following table gives you an overview of the migration process and shows you which procedures can be done in parallel. You must complete the items in each row before you move on to the next row. Sections that span multiple columns contain procedures that apply to two or more product components. Skip procedures for products that are not in your configuration. For example, if your configuration only has Avaya IC as a data source, skip the procedures shown for Avaya OA on CMS. Avaya IC/OA database Avaya IC Avaya OA Avaya OA on CMS Verify valid Avaya OA upgrade file on page 179 Considerations and prerequisites on page 183 Set up a test system for migration on page 194 Prepare for Avaya IC installation on page 194 Upgrade Avaya OA on the CMS servers on page 229 Install the Avaya IC software on page 195. Migrate the application ADL files on page 196 Migrate IC Scripts, workflows, and Avaya Agent files on page 199 Create the Avaya Agent application installer on page Software Upgrade and Data Migration May 2009

177 Overview of the migration process Avaya IC/OA database Avaya IC Avaya OA Avaya OA on CMS Increase the database Timeout parameter on page 203 Prepare to shut down Avaya IC on page 204 Shut down Avaya IC on page 205. At this point, no new data can be collected for Avaya IC until is up and running in your production environment. Full backup (see Back up your databases on page 207) Migrate your Avaya IC servers on page 207 Upgrade your Avaya IC databases to on page 209 Insert Avaya IC specific properties into the database on page 218 Import creationrules and fieldexpressions data on page 219 Migrate your existing Prompter ActiveX controls on page 220 Software Upgrade and Data Migration May

178 Chapter 6: Upgrading and migrating from to Avaya IC/OA database Avaya IC Avaya OA Avaya OA on CMS Generate Windows applications and update server information on page 221. Full backup. See Back up your databases on page 225. Install your secondary ORB servers on page 228 Configure the License server on page 228 Migrate Chat & data on page 276 Migrate your Content Analyzer data on page 282 Migrate Avaya Agent applications on page 284 Migrate the Report Wizard application Contact form on page 285 Migrate WebQ on page 285 Complete the migration process on page 286 Shut down the Avaya OA servers before starting the upgrade on page 236 Upgrade Avaya OA components from to on page 240. (To back out, see Recovery from a failed upgrade on page 252.) Bring up the Avaya OA servers and components on page 255 Migrate the Avaya OA historical database on page 267 Complete related data migration procedures on page 275 Verify that forwarders on CMS servers are sending data on page Software Upgrade and Data Migration May 2009

179 Verify valid Avaya OA upgrade file Avaya IC/OA database Avaya IC Avaya OA Avaya OA on CMS Full backup (see Back up your databases and server files on page 290) Put into production on page 290 Verify valid Avaya OA upgrade file Before you shut down any servers and begin any upgrade and migration procedures, you must first check whether your servers that have the Avaya OA Real-time subsystem have a valid and uncorrupted upgrade file.! CAUTION: CAUTION: If you do not do this check and begin the upgrade, you will have longer down time and the system will not be able to receive or process data. Make sure you do this check before you shut down any servers and begin any upgrade and migration procedures. The procedure for checking the upgrade file differs between Windows and Solaris. Checking the upgrade file on Windows: To check for a valid upgrade file: 1. Open a command prompt window. 2. Log in as an administrative user. 3. Enter: oalist A message similar to the following is displayed listing what components are installed on the server: Subsystems installed Historical Real Time Reports... OA Software information Version Installed: XXX Software Upgrade and Data Migration May

180 Chapter 6: Upgrading and migrating from to Do one of the following: If the Real-time subsystem is not installed on this server, go to your next server that has Avaya OA components and start over at Step 1. If the Real-time subsystem is installed on this server, continue with Step Place the Avaya OA CD-ROM in the drive. 6. In the command prompt window, enter: X: where X is the letter for your CD-ROM drive. 7. Enter: java CheckOAUpgrade "%PABASE%" (include the quote marks) The system responds with one of the following possible conditions: If the following message is displayed, a valid upgrade file is on the server and you can continue with the upgrade: Operating System: OS Value entered for PABASE: Install_Directory... System is ready for upgrade If the following message is displayed, the upgrade file on the server is corrupted and you must escalate the problem to Avaya Technical Support: Operating System: OS Value entered for PABASE: Install_Directory... Install_Directory\..\_uninst\uninstall.dat is internally corrupted. However, it still may be viewable using WinZip. Please contact Avaya Technical Support. If the following message is displayed, the upgrade file on the server is not valid and you must escalate the problem to Avaya Technical Support: Operating System: OS Value entered for PABASE: Install_Directory... System will fail upgrade: Install_Directory\..\_uninst\uninstall.dat is missing information. Please contact Avaya Technical Support. 180 Software Upgrade and Data Migration May 2009

181 Verify valid Avaya OA upgrade file If the following message is displayed, the upgrade file does not exist on the server and you must escalate the problem to Avaya Technical Support: Operating System: OS Value entered for PABASE: Install_Directory... File doesn't exist: C:\Program Files\Avaya\BI\..\_uninst\uninstall.dat 8. Continue by checking your next server that has Avaya OA components. After checking all servers with Avaya OA components, either continue with the upgrade if the upgrade file is valid, or escalate to Avaya Technical Support if the upgrade file is corrupt, missing data, or does not exist. Checking the upgrade file on Solaris: To check for a valid upgrade file: 1. Open a command prompt window. 2. Log in as root. 3. Enter:. /opt/bi/.profile oalist A message similar to the following is displayed listing what components are installed on the server: Subsystems installed Historical Real Time Reports... OA Software information Version Installed: XXX 4. Do one of the following: If the Real-time subsystem is not installed on this server, go to your next server that has Avaya OA components and start over at Step 1. If the Real-time subsystem is installed on this server, continue with Step Place the Avaya OA CD-ROM in the drive and wait about 15 seconds. A file manager window is displayed showing the contents of the CD-ROM. Minimize that window. Software Upgrade and Data Migration May

182 Chapter 6: Upgrading and migrating from to If the File Manager window does not open, enter the following commands to start the volume manager: /etc/init.d/volmgt stop /etc/init.d/volmgt start 6. Enter the following commands: cd /cdrom/cdrom0 java CheckOAUpgrade $PABASE The system responds with one of the following possible conditions: If the following message is displayed, a valid upgrade file is on the server and you can continue with the upgrade: Operating System: OS Value entered for PABASE: Install_Directory... System is ready for upgrade If the following message is displayed, the upgrade file on the server is corrupted and you must escalate the problem to Avaya Technical Support: Operating System: OS Value entered for PABASE: Install_Directory... Install_Directory/../_uninst/uninstall.dat is internally corrupted. However, it still may be viewable using WinZip. Please contact Avaya Technical Support. If the following message is displayed, the upgrade file on the server is not valid and you must escalate the problem to Avaya Technical Support: Operating System: OS Value entered for PABASE: Install_Directory... System will fail upgrade: Install_Directory/../_uninst/uninstall.dat is missing information. Please contact Avaya Technical Support. 182 Software Upgrade and Data Migration May 2009

183 Considerations and prerequisites If the following message is displayed, the upgrade file does not exist on the server and you must escalate the problem to Avaya Technical Support: Operating System: OS Value entered for PABASE: Install_Directory... File doesn't exist: C:\Program Files\Avaya\BI\..\_uninst\uninstall.dat 7. Continue by checking your next server that has Avaya OA components. After checking all servers with Avaya OA components, either continue with the upgrade if the upgrade file is valid, or escalate to Avaya Technical Support if the upgrade file is corrupt, missing data, or does not exist. Considerations and prerequisites The installation supplies tools to migrate your components. Before you use these tools, however, you need to do several things manually.! CAUTION: CAUTION: The procedures in this manual require that you manipulate your company s databases using your database administration tools. Before you attempt any of the procedures in this manual, you should be familiar with using those tools. While this manual does try to help you determine which commands you want to run, these steps should be viewed as examples only, and you should rely on your database documentation to make sure you are running the correct tool to perform the required task. In addition, you should plan your migration strategy very carefully, and be fully aware of the structure of your database and any customizations that were made to your system. Some of the tasks depend on whether you have Avaya Business Applications installed. Do those tasks first, then do the tasks that apply to the entire Avaya IC suite. For details, see: Considerations on page 184 Prerequisites for migrating Content Analyzer on page 185 Prerequisites for migrating all configurations of Avaya IC on page 190 Prerequisites for Avaya OA upgrades on page 191 Software Upgrade and Data Migration May

184 Chapter 6: Upgrading and migrating from to Considerations Before you upgrade to 6.1.2, keep the following details in mind: Before you begin the migration on your production environment, you should be familiar with the documentation for Avaya IC and Avaya OA, especially the new deployment scenarios in Chapters 4 and 5 in IC Installation Planning and Prerequisites. In addition, you should make sure that you are familiar with this chapter so that you know what steps you will be required to complete and in what order. This migration process assumes that you are installing your components (Administration and design tools, Servers, and Avaya Agent applications) on the same machines as their counterparts. If you are going to be installing them on different machines, you will need to contact Avaya technical support for assistance. Use the sizing tools to help determine the amount of space you will need for the upgrade. To migrate the databases, the available free disk space should equal or exceed the size of the largest table in each of your databases. To see the space requirements for the Avaya IC software, see Chapter 6 in IC Installation Planning and Prerequisites. The migration process assumes that you are starting with (for Avaya OA, either load 157 patch 3, or load 166; use the oalist command from the command prompt to determine your current load number). If you have not upgraded to a supported load, you need to do so before you migrate your system to For an overview of the migration path from older versions of Avaya IC, see the appropriate chapter in this document. For procedures to upgrade to Avaya OA 6.0.2, see Avaya Operational Analyst Release Installation and Maintenance. Important:! Important: If your Avaya OA system is or 6.1.1, do not use the procedures in this document to upgrade your software. For procedures about how to upgrade Avaya OA from or to 6.1.2, see Avaya Operational Analyst Release 6.1 Installation and Configuration. The migration process assumes that you are migrating to the same databases and operating system that you started with. For example, you cannot use these instructions to go from a implementation of Oracle on Unix to a implementation of Microsoft SQL on Windows. If you want to change databases or operating systems, Avaya recommends that you contact Technical Support. If you need to back out the data migration, you will have to restore your data from your backups. Any new data collected since your latest backup will be lost. To prepare for recovery in case you need to back out the Avaya OA software upgrade, you must create a filesystem backup of the Avaya OA software and the OS. You would use this backup to restore the filesystem where Avaya OA was installed and the filesystem where the OS was installed. In addition, you have to restore your Avaya IC and Avaya OA databases from your final backup prior to your upgrade. See Filesystem backup for Avaya OA on page 240 for more information. 184 Software Upgrade and Data Migration May 2009

185 Considerations and prerequisites When you push the IC Scripts to the database, the Database Designer loads all of the QSC files from the specified directories instead of just taking the individual script files that you specify. If you want to modify an out-of-the-box IC Script file and keep both versions in the same directory, make sure you change the out-of-the-box file extension to be ".old", ".original", or anything other than ".qsc". The virtualqueue field in the routinghint table is no longer supported in If you have used this field, you will need to reassign that data to a different routing hint. The following name changes in are relevant to migration. They affect the Database Designer, the pdm.xml metadata file, and the Avaya IC environment variables: Old Name New Name Comments CI Repository database IC Repository database The default database name is repository in both releases. AVAYA_IC_HOME AVAYA_IC61_HOME The main Avaya IC environment variable. design\qrepository design\repository The subdirectory containing the design files for the IC Repository database. qrepository.adl qrepository.adf qrepository.adc qrepository.alm repository.adl repository.adf repository.adc repository.alm The design files for the IC Repository database. Prerequisites for migrating Content Analyzer Before you migrate your system, you should make detailed notes about your Content Analyzer system, as described in the sections below. With this information, you can: Verify that all of your Content Analyzer data migrated properly Restore all of the settings for your Content Analyzer CAServer and CAAdmin servers For details about Content Analyzer and the Content Analyzer servers, see Chapter 6 in IC Administration Volume 1: Servers & Domains. If at all possible, you should configure your Content Analyzer servers so that they have the same relative path to the Content Analyzer Knowledge Bases as the servers did. For example, if the fully-qualified path from your current servers to your Knowledge Bases is X:\Avaya\KBs\, then you should make sure that your servers use the same path. Software Upgrade and Data Migration May

186 Chapter 6: Upgrading and migrating from to The recommended installation directory for your Knowledge Bases is: C:\Program Files\Avaya\kbs (Windows)../opt/Avaya/kbs (Unix) If your servers can use the same relative path to the Knowledge Bases, then all of your Content Analyzer database data will be migrated automatically when you perform the standard migration steps described in this chapter. The only Content Analyzer-specific migration step you need to take is to recreate your Content Analyzer servers in your environment. If you have to change the relative location of your Knowledge Bases to your Content Analyzer servers, you will also need to perform the migration steps in Migrate your Content Analyzer data on page 282. In order to verify Content Analyzer data migration, you need to record information about your Content Analyzer environment, as described in the following sections: Determining the current Content Analyzer data Determining the current Content Analyzer server settings Determining the training and validation information for your Knowledge Bases Determining the current Content Analyzer data To find out what Content Analyzer data is currently stored in your Avaya IC system: 1. In IC Manager, select Tools > Content Analysis. 2. To get a list of all the Knowledge Bases in your system, select KB Management in the left-hand pane and make a note of the information in the File Path column for each Knowledge Base that appears in the right-hand pane. Tip: The File Path column shows the relative path to the Knowledge Base, not the exact machine on which that Knowledge Base is located. Make sure you contact your Content Analyzer Administrator for the specific machines and directories where the Knowledge Base files are located. 3. To get a list of all the topic trees in your system, select Topic Tree Management in the left-hand pane. Make a note of all the topic trees and their topics. Tip: An easy way to do this is to expand all of the topic trees and then take one or more screenshots of the resulting data. If you have a large number of topic trees, you may want to expand each one individually and take one screenshot per tree. 4. To get a list of all the sample sets in your system: a. Select Sample Management in the left-hand pane. b. Select the Remove Samples tab in the right-hand pane. 186 Software Upgrade and Data Migration May 2009

187 Considerations and prerequisites c. Open the Sample Set drop down list and make a note of the sample sets. Determining the current Content Analyzer server settings To determine your Content Analyzer server settings: 1. In IC Manager, select the Server tab and then select All Domains in the left-hand pane. 2. For each Avaya IC server of type CAAdmin: a. Right click on that server and select Edit from the pop-up menu. IC Manager displays the Server Editor dialog box for that server. b. Take a screenshot of each tab in the Server Editor dialog box, making sure that you take special note of the Name on the General tab, the system on which this server was configured, and the setting for Path to NLP Data on the CAAdmin tab. c. Select OK or Cancel to close the Server Editor dialog box. d. Repeat steps a through c for the next CAAdmin server. 3. For each Avaya IC server of type CAServer: a. Right click on that server and select Edit from the pop-up menu. IC Manager displays the Server Editor dialog box for that server. b. Take a screenshot of each tab in the Server Editor dialog box, making sure that you take special note of the Name on the General tab, the system on which this server was configured, and the setting for Path to NLP Data on the CAServer tab. c. On the CAServer tab, select the Knowledge Base button and, for each associated Knowledge Base: 1. Record the Name, KB File Location, and Threshold values. 2. Click on under the Languages column and note all of the languages that are associated with this Knowledge Base. 3. Select OK or Cancel to close the Knowledge Base dialog box. d. Select OK or Cancel to close the Server Editor dialog box. e. Repeat steps a through d for the next CAServer server. 4. When you have finished recording the details for all of your CAAdmin and CAServer servers, you can close IC Manager. Software Upgrade and Data Migration May

188 Chapter 6: Upgrading and migrating from to Determining the training and validation information for your Knowledge Bases To view the training and validation information about your existing Knowledge Bases (such as the topic tree associated with the Knowledge Base, the sample set used in training or validation, and the date/time of any training or validation sessions), you can run a SQL query on your SQL Server database, or a SQL Plus query on your SQL Oracle database. Both queries are shown below. Tip: Tip: If you saved the results of previous training and validation sessions, make sure that you know where those files are located so that you can compare them to your migrated system. For a SQL Server database, run the following SQL query: USE ccq SELECT kb.name "KBName", kb.kbfilepath "KBFilePath", ss.name "SampleSet", ct.name "Topic Tree", sskb.intent "Train:0; Validate:1", sskb.dateperformed "Date Performed" FROM knowledgebase kb, sampleset ss, samplesetknowledge sskb, contenttree ct WHERE kb.pkey = sskb.knowledgebase_key AND sskb.sampleset_key = ss.pkey AND ss.contenttree_key = ct.pkey ORDER BY sskb.intent ASC, sskb.dateperformed DESC 188 Software Upgrade and Data Migration May 2009

189 Considerations and prerequisites A screenshot showing an example of this query is shown below. In this example, each of the three Knowledge Bases went through one training session and one validation session. The sample set used for each training and validation session is shown in the SampleSet column. For an Oracle database, run the following SQL Plus script: SET LINESIZE 180; COLUMN "KB Name" FORMAT A15; COLUMN "File Path" FORMAT A30; COLUMN "Topic Tree" FORMAT A15; COLUMN "Sample Set" FORMAT A20; COLUMN "Date Performed" FORMAT A30; SELECT kb.name AS "KB Name", kb.kbfilepath AS "File Path", ct.name AS "Topic Tree", ss.name AS "Sample Set", sskb.intent AS "Intent 0 or 1", sskb.dateperformed AS "Date Performed" FROM ccq.knowledgebase kb, ccq.sampleset ss, ccq.samplesetknowledge sskb, ccq.contenttree ct WHERE kb.pkey = sskb.knowledgebase_key AND sskb.sampleset_key = ss.pkey AND ss.contenttree_key = ct.pkey ORDER BY sskb.intent ASC, sskb.dateperformed DESC; Software Upgrade and Data Migration May

190 Chapter 6: Upgrading and migrating from to A screenshot showing an example of this query is shown below. In this example, the KO-Financial Knowledge Base was trained twice but validated once, and the other Knowledge Bases went through one training session and one validation session each. The sample set used for each training and validation session is shown in the Sample Set column. Prerequisites for migrating all configurations of Avaya IC Because of the name change from qrepository.adl to repository.adl in 6.1.2, you need to rename your ADL file using your Database Designer. To do so: 1. Start your Database Designer and open the qrepository.adl file (default: C:\ Program Files\Avaya\IC60\design\qrespository\qrepository.adl). 190 Software Upgrade and Data Migration May 2009

191 Considerations and prerequisites 2. Select File > Save As and save the file as repository.adl in the same directory as your qrepository.adl file. Database Designer creates repository.adl, repository.adf, repository.adc, repository.alf, and repository.alm in that directory. You will need to use these files later on in the migration process. If you are using a localized system, Database Designer also creates repository_nn.alf and repository_nn.alm, where nn is the language code specified in Database Designer. 3. Close Database Designer. Prerequisites for Avaya OA upgrades Before you begin an upgrade on any Avaya OA servers, you must verify that the items in the following checklist and procedure have been done: Prerequisite checklist on page 191 Provide space for Avaya OA historical data migration on page 193 Prerequisite checklist Follow these important steps and recommendations: Procedure Have the installation media and documentation for Avaya OA available for use during the process in case you have to recover from a failed upgrade. See Recovery from a failed upgrade on page 252 for more information. Use the sizing tools to help determine the amount of disk space you will need for the upgrade, both for the software and for the database. Verify that you have allocated space for the filegroups or tablespaces. See Provide space for Avaya OA historical data migration on page 193 for more information. Verify that there is a minimum of 512 MB of free temporary disk space on the C: drive for Windows and in /var/tmp for Solaris. If this disk space is not available, the installer may not run successfully. For Solaris, use the df -k /var/tmp command to determine the amount of available disk space. The figures shown are in KB. Verify that the ORACLE_BASE and ORACLE_HOME entries in /opt/bi/.profile are populated with the correct entries. For example, if Oracle is installed at / oracle8i/product/8.1.7, this location would be the ORACLE_HOME and ORACLE_BASE would be /oracle8i. Software Upgrade and Data Migration May

192 Chapter 6: Upgrading and migrating from to You must install or upgrade the Source-EC subsystem on every server machine where the Real-time subsystem is installed. Verify that there is at least 100 MB of free disk space for the installation files, and that the Avaya IC secondary ORB server has already been installed on the same server machine. Verify that there are no open TTIsql sessions with the TimesTen application. You must know the following information for upgrading the Avaya OA server: For Windows, the local administrator password. The local administrator must have permission to read, write and execute (for example: biadmin). For Solaris, the root password. The password for the user ID that was used during the last Installation. You must know the following database information for upgrading Avaya IC and Avaya OA: For SQL Server, the sa password. For Oracle, the sys password. The Avaya OA database owner password. The Avaya IC Repository database password. For upgrading Avaya OA on CMS: the CMS Informix database password. For Oracle, you must know the Oracle TNS Service Name. Verify that a secondary ORB server has been installed on every Avaya IC server machine that also has the Avaya OA Real-time subsystem. Verify that JRE version 1.3.1_01 is installed on server machines where only Avaya OA components are installed. Verify that JRE version 1.3.1_06 is installed on server machines where Avaya OA components are installed with Avaya IC components. CAUTION:! Procedure CAUTION: If the correct version of JRE is not installed, or if JRE is not installed at all, contact Avaya Technical Support. Do not continue with the upgrade. Verify that no Avaya OA files are open. For example, no Avaya OA log is open, no property file is open, no add_on data file is open, and so on. Verify that all Avaya OA Administration client users have logged off and closed their browser windows before you upgrade the Avaya OA software. Turn off all virus scan software. In addition, configure the software to exclude the %PABASE%\reports\cognos directory from virus scanning. After you complete the installation, remember to turn on the virus scan software. 192 Software Upgrade and Data Migration May 2009

193 Considerations and prerequisites Provide space for Avaya OA historical data migration The upgrade of the Avaya OA Historical subsystem requires a minimum amount of free space in the filegroups (SQL) or tablespaces (Oracle) listed in this section. You must make sure that the required minimum free space is available in these filegroups or tablespaces before you upgrade the Historical subsystem to However, because the historical data will be transferred from the backup tables to the new tables in the same filegroups or tablespaces, you must allocate enough free space in each filegroup or tablespace to store two sets of historical data. For example, if the HISTSTATUS filegroup or tablespace is currently using 250 MB of space, you must allocate at least 500 MB of free space in the filegroup or tablespace, which is more than the minimum of 300 MB. Providing twice the amount of space will help ensure that the migration scripts do not fail. To check and allocate enough free space in the filegroups and tablespaces, refer to SQL Server Administrator's Guide for SQL or Oracle Administrator's Guide for Oracle. The following filegroups or tablespaces apply to all configurations: Common filegroups or tablespaces Minimum required free space (MB) HISTADMIN 200 HISTSTATUS 300 HISTIDMAP 10 The following filegroups or tablespaces apply to Avaya IC/Avaya OA and Avaya IC/Avaya OA/ CMS configurations: Avaya IC and Avaya OA filegroups or tablespaces Minimum required free space (MB) HISTICAGENT 100 HISTICAGNETSTATE 50 HISTICSVCCLASS 100 HISTICSVCSTATE 100 HISTICDISPLAY 25 Software Upgrade and Data Migration May

194 Chapter 6: Upgrading and migrating from to The following soft dialer filegroups or tablespaces apply to Avaya IC/Avaya OA or Avaya IC/ Avaya OA/CMS configurations. If the database is on a back-end database server, you must create them prior to the software upgrade. Avaya IC and Avaya OA filegroups or tablespaces on a back-end database server Minimum required free space (MB) HISTICAGENTCOMP 50 HISTICAGENTJOB 50 HISTICJOB 25 HISTICSYSCOMP 25 The Avaya CMS filegroups or tablespaces will not be migrated, so no change in the space allocation is required. Set up a test system for migration Avaya recommends that you create a test environment with a functional system that contains both Avaya IC and Avaya OA. You should run through the entire migration procedure on this test system so that you can become familiar with all of the steps and the requirements. That way, you will be able to minimize the amount of down time required when you migrate your production system. You can also use this test system to verify that your IC Scripts, workflows, and Avaya Agent layout files will work with 6.1.2, as described in Migrate IC Scripts, workflows, and Avaya Agent files on page 199. Prepare for Avaya IC installation Before you can migrate your data, you need to check your database administration tools and add a new Administrator account that can be used as a secondary login for IC Manager in case the regular Administrator account encounters any login-related issues during the migration process. To do so: 1. Make sure that your database administration tools are accessible and properly installed. For details, see your database documentation. 194 Software Upgrade and Data Migration May 2009

195 Install the Avaya IC software 2. Open your IC Manager. 3. Select the Agent tab. 4. In the left pane, select the Default workgroup. 5. Select Agent > New. IC Manager displays the Agent Editor dialog box. 6. Enter required basic information for the agent record. The login ID you select should be the install user for the Avaya IC software. 7. Select the Security tab and set a password for this account. In the Agent Roles section, select the Administrator check box. Important:! Important: Avaya recommends that you have a backup Administrator account in case of any unforeseen login issues. If you cannot log into IC Manager using any of your administrator accounts, you need to review the icmanager_admin.log for database errors or disabled login. Install the Avaya IC software Begin installing Avaya IC using the information in IC Installation and Configuration, making sure that you install your administration tools on the same machine as your administration tools, your servers on the same machine as your servers, and your Avaya Agent applications on the same machines as your Avaya Agent applications. To install 6.1.2: 1. Install your primary servers on the primary server machine. During the install, you: will see the message "Hummingbird Connector already exists". Select OK to dismiss the message. will see the message "Sys32Update will update your System32 dll/ocx files as necessary. The original files will be placed in the backup directory. Okay to continue?". Select Yes. If you rerun this installer, you will need to rename the backup directory C:\ Documents and Settings\Administrator\Local Settings\Temp so that the installer does not overwrite the original files that it backed up the first time through. 2. Run the Configuration Tool specifying this install as the Primary ORB and with the Start ORB option unchecked. Select all other options as appropriate. Software Upgrade and Data Migration May

196 Chapter 6: Upgrading and migrating from to Important:! Important: When the installation program asks you whether you want to reboot the machine, select No. 3. Install the Administration and design tools on the administration machine. You should reboot this machine when prompted to do so by the installer. 4. Make a backup copy of the entire: IC61_INSTALL_DIR\IC61\design directory and its subdirectories IC61_INSTALL_DIR\IC61\etc directory Other manuals in the 6.1 documentation set refer to the Avaya IC installation directory as..\ or...\. In all cases, we are referring to the complete path into which Avaya IC is installed (default: C:\Program Files\Avaya\IC61\). 5. On the administration machine, install the migration files by: a. Navigating to the Migration directory on the CD-ROM and opening the Migration.zip file in that directory. b. Extracting the files in the Migration.zip file to IC61_INSTALL_DIR\IC61\, making sure that you preserve the directory structure in that zip file. When you unzip Migration.zip, you should let the extraction program overwrite any existing files. c. Apply the patches located in the Patches directory the installation CD-ROM. For details, see the Migration\Readme.pdf file on the CD-ROM. 6. Although they are not required for migration, Avaya strongly recommends that you apply all of the 6.1 patches located on the Avaya support website. That way when you test your migrated system, you will not encounter any of the problems that have already been fixed by these patches. For details on accessing the Avaya support website, see the Migration\Readme.pdf file on the CD-ROM. Migrate the application ADL files In order to merge your customizations with the new application design, includes the migration tool IC61_INSTALL_DIR\IC61\migration\ FixDesignFiles.exe. When you migrate an ADL with FixDesignFiles, all customizations in your ADL and ADF files will be migrated as is to The tool: 1. Renames the corresponding out-of-the-box ADL, ADF, and ADC files as <appname>.adl.original, <appname>.adf.original, and <appname>.adc.original. 196 Software Upgrade and Data Migration May 2009

197 Migrate the application ADL files 2. Opens the appropriate ADL files and integrates the new features with the current design. 3. Saves the new ADL, ADF, and ADC files to the corresponding IC61_INSTALL_DIR\ IC61\design\<appname> directory. Tip: You must use the out-of-the-box ALF and ALM files. If you customized these files in 6.0.2, you will need to reapply your customizations to the new files. Tip: In 6.1.2, you can now create custom string tables using Database Designer. For details, see "Understanding IC Script string table messages" on page 216 of the 6.1 IC Database Designer User Guide. If your site uses... Any Avaya IC component The HRQ Business Application The CustomerQ Business Application You need to migrate... repository.adl ccq.adl hrq.adl custq.adl Requirements for FixDesignFiles! Important: Important: Before you can merge your ADL files with the new features, make sure that you have renamed the qrepository.adl file to repository.adl as described in Prerequisites for migrating all configurations of Avaya IC on page 190. In order for FixDesignFiles to work correctly, your ADL files must reside in the default directories and have the default names. The defaults are: IC602_INSTALL_DIR\IC60\design\qrepository\repository.adl IC602_INSTALL_DIR\IC60\design\CallCenterQ\ccq.adl IC602_INSTALL_DIR\IC60\design\hrq\hrq.adl IC602_INSTALL_DIR\IC60\design\CustomerQ\custq.adl If any of your ADLs are located in a different directory or have a different name, you need to open those ADL files in your Database Designer and save them to the default directory under the default name. Software Upgrade and Data Migration May

198 Chapter 6: Upgrading and migrating from to Tip: Tip: After the migration process is finished, you can recreate your custom directory names under and then use the Database Designer to save the migrated ADL files to your custom directories under your custom names. Run FixDesignFiles To migrate your application ADL files: 1. Run IC61_INSTALL_DIR\IC61\migration\FixDesignFiles.exe Application selector 7. Go: Start ADL, ADF conversion 8. Quit: Close application 9. Status pane showing the tool s progress 10. Overall Progress Bar 11. Current Task Progress Bar 2. For Application, select Repository. 3. Select GO. FixDesignFiles reports its progress in the indicated progress bars in the interface. It also stores one or two log files stored in IC61_INSTALL_DIR\IC61\logs: mig.log shows the details about all the objects that were added by the tool. 198 Software Upgrade and Data Migration May 2009

199 Migrate IC Scripts, workflows, and Avaya Agent files If it finds any errors, it writes them to err.log. If errors occur, see Appendix B: Troubleshooting FixDesignFiles on page 419. Repeat this procedure for each application that you use at your site. Migrate IC Scripts, workflows, and Avaya Agent files After you have migrated your ADL files, you can begin working on your IC Scripts, workflows, and Avaya Agent files. Because of the large number of changes to the IC Scripts and workflows in 6.1.2, Avaya recommends that you start with the out-of-the-box scripts and workflows and reapply any customizations that you made in If, however, you want to use your existing IC Scripts and workflows, you can find a detailed list of changes that have been made in in Appendix A: Detailed changes for Avaya IC and Avaya OA from to on page 385. In order to minimize the time that your production system will be unavailable during the migration process, Avaya recommends that you create a test system using an out-of-the-box environment in which you can: Update your Avaya Agent CDL layout files to conform to For details, see Avaya Agent Layout (CDL) file changes on page 200. Update your EDU Viewer stylesheets to conform to For details, see Avaya Agent EDU Viewer stylesheet changes on page 201. Either reapply your customizations to the Avaya Agent IC Scripts or verify that your Avaya Agent IC Scripts work with (For details about the changes to IC Scripts in 6.1.2, see Avaya Agent IC Script changes on page 390.) Reapply your customizations to all other IC Scripts (including Chat & and application scripts). These IC Scripts have been extensively changed in 6.1.2, and Avaya recommends that you do not try to use your versions of these scripts. Either reapply your customizations to the workflows or verify that your workflows work with (For details about the changes to workflows in 6.1.2, see Avaya IC workflow changes on page 405.) Once you have the test system functioning properly, you can import your verified IC Scripts, workflows, and CDL files into your production environment quickly and easily. Software Upgrade and Data Migration May

200 Chapter 6: Upgrading and migrating from to Avaya Agent Layout (CDL) file changes In order to migrate your Avaya Agent CDL files, you can either use the new out-of-the-box CDL files and reapply your customizations, or you can change your current CDL files to work with the new CDL format. This section details the changes that were made to the CDL files between and (For details about working with CDL files, see Chapter 3 in Avaya Agent Integration.) The following changes have been made to the Avaya Agent CDL file in 6.1.2: A new property was added to the CoreServices QSection called MakeChannelBusyWaitTime. This is used in conjunction with the CoreServices_MakeChannelBusy IC Script to determine how long to wait when requesting a channel to go busy. A new QSection, CHFilter, was added that lets you configure which table.field is used for the Contact History Filter when filtering for media type and creation time. (This was previously hardcoded in the IC Scripts.) Several new properties were added to the EDUFields QSection to access various new EDU fields from the IC Scripts. A new QSection, , was added, which contains a new property called DeferOnLogoutWaitTime. This determines how long Avaya Agent will wait to log out of Management if it finds there are s to defer. A new QSection, General, was added, which contains two new properties: - ScreenPopScript Name of the IC Script to use if ScreenPop is enabled. (This was previously hardcoded in IC Scripts.) - IntegrationHooksEnabled Turns on the new Integration Hooks mechanism within Avaya Agent. For more information about Integration Hooks, see Chapter 4 in Avaya Agent Integration. A new QSection, PaneActivation, was added that lets you configure how Panes are activated based on events occurring within Avaya Agent. (This was previously hardcoded in IC Scripts.) For more information, see the comments in the out-of-the-box CDL file. A new QSection, Softphone, was added that contains the properties related to the Softphone component. For 6.1.2, properties were added to control the Font name and size for the Softphone buttons. The QScriptFileDictionary was removed because Database Designer now reads all IC Scripts in the directories listed in the ADL Included Path list. A new set of buttons was added below the Call List to mirror the change in the UAD for where the UAD is only used for selecting destinations. Because the UAD only has OK and Cancel buttons, the choice of what you want to do with the contact must be made before the UAD is shown. Therefore, the Directory button was removed, and in its place Initiate, Conference, Consult, and Transfer were added. 200 Software Upgrade and Data Migration May 2009

201 Migrate IC Scripts, workflows, and Avaya Agent files Several of the controls now have additional Events listed in their IC Script dictionaries due to enhancements to those features. A new WrapUpEngine was added to the list of non-gui controls residing in the Media Pane. New naming strategy for Avaya Agent layout files In 6.0.2, Avaya IC used only the value of the Agent/Desktop/Layout property to determine the name of the Avaya Agent layout file to open for each agent. In 6.1.2, Avaya IC now appends the value of the Agent/UILanguage property to the Layout property to determine the full file name. For example, if Agent/Desktop/Layout is avaya_agent_mycompany, and Agent/ UILanguage is en, Avaya IC looks for the layout file avaya_agent_mycompany_en. This means that you can specify the same root CDL name for all agents, and let the language setting for each agent determine which CDL file Avaya IC will load when that agent logs in. When you are migrating your Avaya Agent layout files, make sure that the settings for Agent/ Desktop/Layout and Agent/UILanguage properties are correct. Avaya Agent EDU Viewer stylesheet changes There is no automated migration process for EDU Viewer XSL stylesheets. Avaya recommends that you start with the out-of-the-box XSL files and reapply any customizations you made in For details, see "EDU Viewer" starting on page 79 in Avaya Agent Integration. If you want to keep your stylesheets, the following EDU field changes have been made in 6.1.2: Deleted field: hasattachments Added fields: EDU Field Name comment fullname outboundcallnumber primary_ani primary_dnis preferredname Description Comment Full name Outbound Call Number Primary ANI Primary DNIS Preferred Name Software Upgrade and Data Migration May

202 Chapter 6: Upgrading and migrating from to Create the Avaya Agent application installer Before you can install the Avaya Agent application, you need to make sure your CDL files and EDU Viewer stylesheets have been updated as described in Avaya Agent Layout (CDL) file changes on page 200 and Avaya Agent EDU Viewer stylesheet changes on page 201. Then you can use the Agent Site Preparation wizard to create an agent installation file. (For details, see Creating installation files for agent applications on page 299 in IC Installation and Configuration.) The Agent Site Preparation wizard creates an agent.ini file that goes with the installation executable. If your agents desktop operating system has been updated to use the latest service pack, you need to edit the IC61_INSTALL_DIR\IC61\Agentinstaller\config\ agent.ini file as follows: [OPERATINGSYSTEM] 1=Windows NT 4.0, Service Pack 6a 4.00 SP6a 2=Windows 2000 Professional, Service Pack SP2 3=Windows 2000 Professional, Service Pack SP3 4=Windows 2000 Professional, Service Pack SP4 5=Windows XP Professional 5.10 SP0 6=Windows XP Professional 5.10 SP1 [INTERNETEXPLORER] 1= SP2 2= SP0 3= SP1 Make sure you put the agent installer and agent.ini file in their own network share so that, when you go to install the Avaya Agent applications, you do not use the Avaya Agent installer by mistake. Install the Avaya Agent applications Once you have created your agent installer, you can install on your agent machines. If you want to wait until data migration is complete and you are ready to go live with 6.1.2, then you can skip the following steps and continue with Prepare to shut down Avaya IC on page 204. You can then run the agent installer when you migrate agent resources, as described in Migrate Avaya Agent applications on page 284. If you want to install but continue to run the Avaya Agent applications until the data migration is complete, you need to create the Avaya Agent installer and agent.ini file as described above. Then, on each Avaya Agent machine, you need to: 1. Log on to that machine using a Logon ID with Administrator privileges. 202 Software Upgrade and Data Migration May 2009

203 Increase the database Timeout parameter 2. Run the Avaya Agent installer, as described in "Preparing for installation by agents" on page 314 in IC Installation and Configuration, making sure that you install in a different directory than (default installation directory: C:\Program Files\Avaya\IC61). 3. Create a new environment variable named AVAYA_IC61_HOME, and set it equal to the installation directory you specified above. The variable should not include the trailing backslash (for example: C:\Program Files\Avaya\IC61). 4. After you install the Avaya Agent application, you need to reset VTel so that it uses the configuration files and ignores To do so, run IC61_INSTALL_DIR\IC61\ migration\vtelreg602.bat file. Increase the database Timeout parameter If your database has between 1 and 3 million records, you need to increase the Data server Timeout parameter in IC Manager. If your database has more than 3 million records, you need to increase the Timeout parameter associated with your database using your database administration tools.! CAUTION: CAUTION: If the migration takes longer than the allotted database timeout parameters, the data may be corrupted and you may have to restore the database from your backup. You need to be sure the Timeout parameters are correct before you reconfigure your databases. To increase the Data server Timeout parameter for databases with 1 to 3 million records: 1. Open your IC Manager. 2. Double-click the Data server associated with the IC Repository database (as specified in the Data Server Type/Alias parameter in the database s Physical DB Connection). IC Manager displays the Server Editor dialog box. 3. Select the DataServer tab. 4. Right-click and select Show Advanced Properties from the pop-up menu. 5. Increase the Database Connection Timeout parameter to at least 120 minutes. 6. Save your changes and close the Server Editor. If necessary, repeat this procedure for the Data server associated with the CallCenterQ database, the HRQ database, and/or the CustomerQ database. For databases with over three million records, use your database administration tools to increase the query timeout parameter for your database server as necessary. For example, if your database has 8 million records, you will need to set the timeout parameter to at least 7200 seconds. Software Upgrade and Data Migration May

204 Chapter 6: Upgrading and migrating from to Testing your Timeout parameters To test whether your Timeout parameters are set correctly, you can test the reconfigure procedure in Database Designer before you actually migrate your database. For details, see Reconfigure the IC Repository database on page 211, Reconfigure the CallCenterQ database on page 213, Reconfigure the HRQ database on page 215, or Reconfigure the CustomerQ database on page 216. Prepare to shut down Avaya IC Before you can migrate your Avaya IC data, you need to: 1. Stop all of your Avaya Agent applications so that no new data is collected by Avaya IC. 2. Make sure that all calls, chat tasks, and tasks (including s deferred by agents) have been resolved and cleared from the system. To do so, use your database administration tools to run the following SQL queries on the CallCenterQ and IC Repository databases: select count(*) "w_offline_contact" from ccq.w_offline_contact; select count(*) "w_offline_task" from ccq.w_offline_task; select count(*) "qw_dustore" from repository.qw_dustore; If any of these queries return more than one record, then there are still active tasks in the system that need to be closed before migration can continue. (For details about cancelling tasks, see "Working with WebACD tasks" starting on page 59 of IC Administration Volume 1: Servers & Domains.) 3. Make sure that all EDUs and ADUs have been terminated prior to migration. To check this: a. Open a command prompt on each machine running an EDU server, navigate to the IC602_INSTALL_DIR\IC60\bin directory, and enter: listvdu Admin admin b. Open a command prompt on each machine running an ADU server, navigate to the IC602_INSTALL_DIR\IC60\bin directory, and enter: listadu Admin admin For details, see the Agent Data Unit Server Programmer Guide and the Electronic Data Unit Server Programmer Guide. 204 Software Upgrade and Data Migration May 2009

205 Shut down Avaya IC Shut down Avaya IC At this point, you need to shut down your Avaya Agent applications, servers, and services. Avaya IC will remain unavailable until you bring up your new system. To shut down 6.0.2: 1. Shut down your servers, as described in "IC Shutdown Dependencies" on pages of IC Administration Volume 1: Servers & Domains. 2. Shut down your IC Manager. 3. If applicable, shut down the Avaya IC services on Windows: a. Select Start > Programs > Administrative Tools > Services. b. Select the Avaya IC ORB Service 6.0. c. Select Action > Properties. d. Select Stop. e. Select Disabled from the Startup Type drop-down list. f. Select OK. Repeat this procedure for the Chat services ICM and CIRS (default names: Avaya IC ICM Service 6.0 and Avaya IC CIRS Service 6.0). 4. If applicable, shut down the Avaya IC services on Solaris: a. If you ran the IC60/bin/setup_orb script during installation, then the ORB server was added to the Solaris system startup script /etc/init.d/orbserver, and it is referenced by /etc/rc2.d/s98orbserver and /etc/rc0.d/ K32orbserver. Either run IC61/bin/setup_orb or manually update /etc/ init.d/orbserver with the IC 6.1 path. b. If you manually added the IC60/bin/icm.sh or IC60/bin/cirs.sh scripts to the Solaris system startup script, you need to update the paths. 5. If you are running on a Windows system, switch the Hummingbird connector services to point to instead of 6.0.2: a. From the administration machine, copy IC61_INSTALL_DIR\IC61\bin\ HBUnInstall.bat and HBInstall.bat to the primary server machine. b. On the primary server machine, run HBUnInstall.bat to uninstall the Hummingbird services. c. On the primary server machine, run HBInstall.bat to install the Hummingbird services. d. Repeat this procedure for each server machine that is running a Hummingbird connector. Software Upgrade and Data Migration May

206 Chapter 6: Upgrading and migrating from to Disable JRun servers and remove JRun connector filters Any JRun components used to host the Avaya IC web applications (such as Web Management and Template Administration) should be disabled. Disabling JRun on Windows You need to stop all of the JRun instances hosting Avaya IC web applications by stopping and disabling the appropriate JRun services, and then removing the JRun connector filters from IIS. To disable JRun NT services (such as the JRun Default Server): 1. Select Start > Programs > Administrative Tools > Services. 2. Select the appropriate JRun Service. 3. Select Action > Properties. 4. Select Stop. 5. Select Disabled from the Startup Type drop-down list. 6. Select OK. Repeat this procedure for each JRun server hosting an Avaya IC web application. To remove the JRun connector filter. 1. Select Start > Programs > Administrative Tools > Internet Services Manager. 2. If the connector filter is Global: a. Select the server icon in the left hand navigation bar of the Internet Services Manager. b. Select Action > Properties. 1. Select the Internet Information Services tab. 2. Select WWW Service from the drop down menu and select Edit. 3. Select the ISAPI tab. 4. Select the JRun ISAPI filter (if present) and select Remove. 5. Select OK. 3. If the connector filter is Local: a. Select the appropriate Web Site hosting the connector filter (for example: Default Web Site). b. Select Action > Properties 1. Select the ISAPI tab. 2. Select the JRun ISAPI filter (if present) and select Remove. 3. Select OK. 206 Software Upgrade and Data Migration May 2009

207 Back up your databases 4. Restart the WWW Publishing Service. Disabling JRun on Unix The recommended approach for disabling JRun instances hosting Avaya IC web applications is to stop the JRun servers and, if necessary, remove any references to the JRun servers in the Unix startup scripts. You do not have to remove the JRun connector filter from the iplanet configuration because the Avaya IC configuration tool will overwrite the JRun filter configuration.! Important: Important: Make sure that the iplanet server is stopped before running the Web portion of the Configuration Tool. To stop the appropriate JRun Server(s), execute: IC602_INSTALL_DIR/IC60/bin/JrunServer stop Back up your databases During the migration process, you will reconfigure your Avaya IC databases. Avaya strongly recommends that you: Create full backups of all your Avaya IC databases using your database administration tools. Back up the Avaya OA historical database. Do a full backup before you start the migration process, and do an incremental backup just before you migrate the data from the Avaya OA historical database. For details about backing up your database, see your database documentation. Migrate your Avaya IC servers To migrate your servers: 1. Copy the ds.ffd and vesp.imp files from IC602_INSTALL_DIR\IC60\etc on the primary server machine to IC602_INSTALL_DIR\IC60\etc on the administration machine, overwriting the existing files. If you are copying the files via FTP, make sure that you transfer them in ASCII mode. Software Upgrade and Data Migration May

208 Chapter 6: Upgrading and migrating from to On the administration machine, open a command prompt, navigate to IC61_INSTALL_DIR\IC61\migration, and run FixConfigFiles.exe. The following screenshot shows the FixConfigFiles tool: The path in the server configuration files. The tool fills in this information when you click on an IP address in the box below. 13. The path to your Avaya IC installation. 14. The list of IP addresses found in the server configuration files 3. Click on the IP address of the server machine whose configurations you want to migrate. FixConfigFiles fills the associated path into the Path in server configuration files field. 4. Specify the appropriate 6.1 path information from the drive letter to the IC61 directory in the Path in server configuration files field. (For example, C:\Program Files\ Avaya\IC61\.) Important:! Important: Do not mix backslashes "\" and forward slashes "/" in the path name. If your servers are running on a Windows platform, you need to use all backslashes. If your servers are running on Solaris, you need to use all forward slashes. 5. If you want to use the same path for all of the IP addresses listed, select the Change all paths to the same value checkbox and then select Update. 6. When you are ready to migrate your server configurations, click Go. FixConfigFiles generates new vesp.imp and ds.ffd files in the etc directory under IC61_INSTALL_DIR\IC61\. 208 Software Upgrade and Data Migration May 2009

209 Upgrade your Avaya IC databases to If you need to update another IP address, repeat steps 3 through Copy the new vesp.imp and ds.ffd files in IC61_INSTALL_DIR\IC61\etc to the same directory on the primary server machine, overwriting any existing files. If you are copying the files via FTP, make sure that you transfer them in ASCII mode. 9. Start the Avaya IC core servers using the icadmin so command on the primary server machine. You can either run icadmin so from the command line of the server s host machine, or you can run icadmin so <hostname> if your host has multiple network interface cards. (For details, see "Starting and stopping servers with the Avaya IC Admin utility" on page 122 of IC Installation and Configuration.) CAUTION:! CAUTION: Do not start the IC Manager yet. You need to import the new database schemas and generate the repository Windows application, as described later in this chapter. 10. Migrate your servers to 6.1.2: a. On the administration machine, open a command prompt and navigate to IC61_INSTALL_DIR\IC61\bin. b. Open ffdmigrate.bat in an ASCII editor such as Notepad. The file contains the following line of code: CommandScripter -s ffdmigrate.txt -m main -u Admin -p admin > ffdmigrate.log c. In the file, change Admin admin to a IC Manager login name and password that has administrator privileges. Save and close the file. d. Run ffdmigrate.bat to migrate the server information in the ds.ffd file to e. After the script finishes, make sure that there are no errors reported in the output file IC61_INSTALL_DIR\IC61\bin\ffdmigate.log. If there are, stop and then restart the Directory server, and run ffdmigrate.bat again. If the Directory server is running but the errors persist, contact Avaya Technical Support. Upgrade your Avaya IC databases to To upgrade your current Avaya IC databases to 6.1.2, you need to: Change the reportowner and packowner fields Reconfigure your databases Software Upgrade and Data Migration May

210 Chapter 6: Upgrading and migrating from to Change the reportowner and packowner fields In 6.1.2, the size of the packowner field in the qw_reports table and the templateowner field in the qw_templatepack table have been decreased. Therefore, you must resize those fields in all of your databases before you reconfigure them. In order to do this, the Migration.zip file contains two script files that you can run using your database administration tools. To do so: 1. Open the repository database in your database administration tool. 2. If you are using SQL Server on Windows, run the SQL commands in the file IC61_INSTALL_DIR\IC61\migration\sql_migration_scripts.txt. If you are using Oracle, run the commands in IC61_INSTALL_DIR\IC61\migration\ oracle_migration_scripts.txt. CAUTION:! CAUTION: In order to correctly change the field size in the two database tables, you must EXECUTE these statements individually, in the order they appear in the txt file. Do not try to execute them as one single command, or you will encounter errors. If you execute these SQL statements with SQL Server, you will see the following warning: "Caution: Changing any part of an object name could break scripts and stored procedures. The object was renamed to '<tablename>'". You can safely ignore this warning. These SQL statements: Make a temporary copy of the qw_reports and qw_templatepack tables Resize the reportowner and packowner fields in those temporary tables Rename the original tables with the prefix "tmp" Rename the temporary tables to qw_reports and qw_templatepack When you reconfigure your databases, the temporary tables will be removed and your database constraints will be restored. 3. Commit the changes and close the database. Repeat this procedure for the ccq database, and, if you use the HRQ or CustomerQ Business Application, the hrq or custq databases. 210 Software Upgrade and Data Migration May 2009

211 Upgrade your Avaya IC databases to Reconfigure your databases In order to migrate your databases to 6.1.2, you need to reconfigure them. In order to do so, you will need an IC Manager login and password for an account with Administrator authority. All configurations of Avaya IC require you to upgrade your IC Repository and CallCenterQ database. For details, see Reconfigure the IC Repository database on page 211 and Reconfigure the CallCenterQ database on page 213. In addition, if your site uses: The Outbound Contact Management feature, you need to reconfigure the associated Outbound Contact database. For details, see Reconfigure the Outbound Contact database on page 214. The HRQ Business Application, you need to reconfigure the HRQ database. For details, see Reconfigure the HRQ database on page 215. The CustomerQ Business Application, will need to reconfigure the HRQ database. For details, see Reconfigure the CustomerQ database on page 216. You can use Database Designer to reconfigure the actual databases, or you can have the tool generate the necessary SQL statements which you can then run using your database administration tools. Avaya recommends that you use your database administration tools for any database with over 3 million records. Reconfigure the IC Repository database If you need to determine how many rows of data are in your IC Repository database, you can use the following SQL statements to get a record count: : select count(*) from agentsegment select count(*) from routingevent select count(*) from mediainteraction select count(*) from contact select count(*) from mediasegment To reconfigure your IC Repository database for 6.1.2: 1. Start the Database Designer and open IC61_INSTALL_DIR\IC61\design\ repository\repository.adl. You can safely ignore any warning messages regarding the ALF files. Tip: Tip: If you are using a localized Avaya IC environment, you will need to enable your Database Designer to handle the localized files. For details, see "Enabling Database Designer for localization" starting on page 454 of IC Installation and Configuration. Software Upgrade and Data Migration May

212 Chapter 6: Upgrading and migrating from to On the Properties tab in the right-hand pane, make sure that the IC61_INSTALL_DIR\ IC61\design\common and IC61_INSTALL_DIR\IC61\design\QConsole directories are displayed in the Upload scripts from these directories box. If not, add them so that all of the required IC Scripts will be pushed to the database. 3. Expand Components > Physical DB Connections and select repositorydbconnection in the tree pane. 4. Verify that the Database Type/Alias, Database Server (for SQL Server) or TNS Name (for Oracle), and Database Name parameters are correct. The Database Name and Database Server should point to your database. 5. If your database has less than 3 million rows and you are going to reconfigure it in Database Designer: a. Make a note of the current Timeout parameter so that you can reset it after the reconfigure. b. Set the Timeout parameter to at least 7200 seconds. 6. Save the ADL file using File > Save. 7. Select File > Database Administration. 8. Select the Reconfigure option button. 9. Enable the Recreate Stored Procedures check box to update the database with the database schema. 10. If necessary, enter your IC Manager Administrator username and password in the appropriate fields. (Do not enter your DBA username and password.) 11. If your database has over 3 million rows or you want to test this procedure, select Test. Instead of reconfiguring the database, Database Designer creates an SQL configuration text file that contains all of the SQL statements needed to reconfigure the database. You can then modify the SQL statements as needed, and run the modified statements against the IC Repository database using your database administration tools. (For details, see "Configure with Test" starting on page 239 in the IC Database Designer User Guide.) Otherwise, select OK. Database Designer reconfigures the database. CAUTION:! CAUTION: If the reconfigure reports any errors, such as a mttbinary: :timeout execute error, it is possible that the data has not been properly migrated and you will need to restore the database from a backup. Tip: Tip: Avaya recommends that you save the reconfigure SQL. 12. When Database Designer is finished, select Close. 13. If you increased the Timeout parameter in step 5, reset it to its previous value. 212 Software Upgrade and Data Migration May 2009

213 Upgrade your Avaya IC databases to Save and close the ADL file. 15. If you selected Test in step 11, modify the generated SQL statements and apply them to the IC Repository database using your database administration tools. Reconfigure the CallCenterQ database If you need to determine how many rows of data are in your CallCenterQ database, you can use the following SQL statements to get a record count: In addition, if your CallCenterQ database is on Oracle, you should include the following command: Select count (*) from qw_text To reconfigure your CallCenterQ database for 6.1.2: 1. Open IC61_INSTALL_DIR\IC61\design\CallCenterQ\ccq.adl in Database Designer. You can safely ignore any warning messages regarding the ALF files. 2. On the Properties tab in the right-hand pane, make sure that the IC61_INSTALL_DIR\ IC61\design\common and IC61_INSTALL_DIR\IC61\design\QConsole directories are displayed in the Upload scripts from these directories box. If not, add them so that all of the required IC Scripts will be pushed to the database. 3. Expand Components > Physical DB Connections and select ccqconnection in the tree pane. 4. Verify that the Database Type/Alias, Database Server (for SQL Server) or TNS Name (for Oracle), and Database Name parameters are correct. Select count (*) from qem_message Select count (*) from qem_messagestatlog Select count (*) from w_chat_transcript The Database Name and Database Server should point to your database. 5. If your database has less than 3 million rows and you are going to reconfigure it in Database Designer: a. Make a note of the current Timeout parameter so that you can reset it after the reconfigure. b. Set the Timeout parameter to at least 7200 seconds. 6. Save the ADL file using File > Save. 7. Select File > Database Administration. 8. Select the Reconfigure option button. 9. Enable the Recreate Stored Procedures check box to update the database with the database schema. 10. If necessary, enter your IC Manager Administrator username and password in the appropriate fields. (Do not enter your DBA username and password.) Software Upgrade and Data Migration May

214 Chapter 6: Upgrading and migrating from to If your database has over 3 million rows or you want to test this procedure, select Test. Instead of reconfiguring the database, Database Designer creates an SQL configuration text file that contains all of the SQL statements needed to reconfigure the database. You can then modify the SQL statements as needed, and run the modified statements against the CallCenterQ database using your database administration tools. (For details, see "Configure with Test" starting on page 239 in the IC Database Designer User Guide.) Otherwise, select OK. Database Designer reconfigures the database. CAUTION:! CAUTION: If the reconfigure reports any errors, such as a mttbinary: :timeout execute error, it is possible that the data has not been properly migrated and you will need to restore the database from a backup. Tip: Tip: Avaya recommends that you save the reconfigure SQL. 12. When Database Designer is finished, select Close. 13. If you increased the Timeout parameter in step 5, reset it to its previous value. 14. Save and close the ADL file. 15. If you selected Test in step 11, modify the generated SQL statements and apply them to the CallCenterQ database using your database administration tools. Reconfigure the Outbound Contact database To reconfigure your Outbound Contact Management database for 6.1.2, you need to start with the out-of-the-box dialer.adl file: 1. Start Database Designer and open IC61_INSTALL_DIR\IC61\design\SoftDialer\ dialer.adl. You can safely ignore any warning messages regarding the ALF files. 2. Expand Components > Physical DB Connections and select dialerdbconnectionset in the tree pane, and: a. Verify that the Database Type/Alias, Database Server (for SQL Server) or TNS Name (for Oracle), and Database Name parameters are correct. The Database Name and Database Server should point to your database. b. Verify that the Display Time is set to DBMSTIME. If the Display Time is set to HOSTTIME, then the timestamp information will be changed and the Outbound Contact configuration will not be usable. 3. Save the ADL file using File > Save. 4. Select File > Database Administration. 5. Select the Reconfigure option button. 214 Software Upgrade and Data Migration May 2009

215 Upgrade your Avaya IC databases to Tip: 6. Enable the Recreate Stored Procedures check box to update the database with the database schema. 7. If necessary, enter your IC Manager Administrator username and password in the appropriate fields. (Do not enter your DBA username and password.) 8. Select OK. Tip: Avaya recommends that you save the reconfigure SQL. 9. When Database Designer is finished, select Close. 10. Close the ADL file. Import new seed data into the Outbound Contact database Avaya IC includes new seed data for the dialer database. To import the seed data: 1. In Notepad or another text editor, open: IC61_INSTALL_DIR\IC61\design\ SoftDialer\data\delta_seed.cfg. 2. Find the DestinationPasswd field and verify that the value is the correct password for the Admin account. 3. Save the delta_seed.cfg file. 4. Run the seed migration import BAT file IC61_INSTALL_DIR\IC61\design\ SoftDialer\data\import_delta_seed.bat. Reconfigure the HRQ database To reconfigure your HRQ database for 6.1.2: 1. Start Database Designer and open IC61_INSTALL_DIR\IC61\design\ hrq\hrq.adl. You can safely ignore any warning messages regarding the ALF files. 2. On the Properties tab in the right-hand pane, make sure that the IC61_INSTALL_DIR\ IC61\design\common and IC61_INSTALL_DIR\IC61\design\QConsole directories are displayed in the Upload scripts from these directories box. If not, add them so that all of the required IC Scripts will be pushed to the database. 3. Expand Components > Physical DB Connections and select hrqconnection in the tree pane. 4. Verify that the Database Type/Alias, Database Server (for SQL Server) or TNS Name (for Oracle), and Database Name parameters are correct. The Database Name and Database Server should point to your database. 5. If your database has less than 3 million rows and you are going to reconfigure it in Database Designer: Software Upgrade and Data Migration May

216 Chapter 6: Upgrading and migrating from to a. Make a note of the current Timeout parameter so that you can reset it after the reconfigure. b. Set the Timeout parameter to at least 7200 seconds. 6. Save the ADL file using File > Save. 7. Select File > Database Administration. 8. Select the Reconfigure option button. 9. Enable the Recreate Stored Procedures check box to update the database with the database schema. 10. If necessary, enter an IC Manager Administrator username and password in the appropriate fields. (Do not enter your DBA username and password.) 11. If your database has over 3 million rows or you want to test this procedure, select Test. Instead of reconfiguring the database, Database Designer creates an SQL configuration text file that contains all of the SQL statements needed to reconfigure the database. You can then modify the SQL statements as needed, and run the modified statements against the CallCenterQ database using your database administration tools. (For details, see "Configure with Test" starting on page 239 in the IC Database Designer User Guide.) Otherwise, select OK. Database Designer reconfigures the database. CAUTION:! CAUTION: If the reconfigure reports any errors, such as a mttbinary: :timeout execute error, it is possible that the data has not been properly migrated and you will need to restore the database from a backup. Tip: Tip: Avaya recommends that you save the reconfigure SQL. 12. When Database Designer is finished, select Close. 13. If you increased the Timeout parameter in step 5, reset it to its previous value. 14. Save and close the ADL file. 15. If you selected Test in step 11, modify the generated SQL statements and apply them to the CallCenterQ database using your database administration tools. Reconfigure the CustomerQ database To reconfigure your CustomerQ database for 6.1.2: 1. Start Database Designer and open IC61_INSTALL_DIR\IC61\design\custq\ custq.adl. You can safely ignore any warning messages regarding the ALF files. 216 Software Upgrade and Data Migration May 2009

217 Upgrade your Avaya IC databases to On the Properties tab in the right-hand pane, make sure that the IC61_INSTALL_DIR\ IC61\design\common and IC61_INSTALL_DIR\IC61\design\QConsole directories are displayed in the Upload scripts from these directories box. If not, add them so that all of the required IC Scripts will be pushed to the database. 3. Expand Components > Physical DB Connections and select custqconnection in the tree pane. 4. Verify that the Database Type/Alias, Database Server (for SQL Server) or TNS Name (for Oracle), and Database Name parameters are correct. The Database Name and Database Server should point to your database. 5. If your database has less than 3 million rows and you are going to reconfigure it in Database Designer: a. Make a note of the current Timeout parameter so that you can reset it after the reconfigure. b. Set the Timeout parameter to at least 7200 seconds. 6. Save the ADL file using File > Save. 7. Select File > Database Administration. 8. Select the Reconfigure option button. 9. Enable the Recreate Stored Procedures check box to update the database with the database schema. 10. If necessary, enter an IC Manager Administrator username and password in the appropriate fields. (Do not enter your DBA username and password.) 11. If your database has over 3 million rows or you want to test this procedure, select Test. Instead of reconfiguring the database, Database Designer creates an SQL configuration text file that contains all of the SQL statements needed to reconfigure the database. You can then modify the SQL statements as needed, and run the modified statements against the CallCenterQ database using your database administration tools. (For details, see "Configure with Test" starting on page 239 in the IC Database Designer User Guide.) Otherwise, select OK. Database Designer reconfigures the database. CAUTION:! CAUTION: If the reconfigure reports any errors, such as a mttbinary: :timeout execute error, it is possible that the data has not been properly migrated and you will need to restore the database from a backup. Tip: Tip: Avaya recommends that you save the reconfigure SQL. 12. When Database Designer is finished, select Close. 13. If you increased the Timeout parameter in step 5, reset it to its previous value. Software Upgrade and Data Migration May

218 Chapter 6: Upgrading and migrating from to Save and close the ADL file. 15. If you selected Test in step 11, modify the generated SQL statements and apply them to the CallCenterQ database using your database administration tools. Insert Avaya IC specific properties into the database Once you have reconfigured the IC Repository database, you can insert specific properties into that database. To do so: 1. Open Database Designer. 2. Select File > Open and open IC61_INSTALL_DIR\IC61\migration\ repository60_61.adl. 3. Expand Components > Physical DB Connections and select repositoryconnection in the tree pane. 4. Verify that the Database Type/Alias, Database Server (for SQL Server) or TNS Name (for Oracle), and Database Name parameters point to the IC Repository database you reconfigured in Reconfigure the IC Repository database on page 211. CAUTION:! CAUTION: Do not reconfigure your IC Repository database using this ADL or several tables will be dropped and the data in those tables will be lost. If this happens, you will have to restore the IC Repository database from your backup and start the ADL migration process over again. 5. Save the ADL file. 6. Open IC61_INSTALL_DIR\IC61\migration\update_properties.bat in an ASCII editor such as Notepad. The file contains the following lines of code: "%AVAYA_IC61_HOME%\bin\dbmigrate.exe" "%AVAYA_IC61_HOME%\migration\repository60_61.adc" migration_qrep defaultdbconnectionset Admin admin "%AVAYA_IC61_HOME%\migration\properties_61.data" 7. In the file, change Admin admin to a IC Manager login name and password that has administrator privileges. Save and close the file. 218 Software Upgrade and Data Migration May 2009

219 Import creationrules and fieldexpressions data 8. Open a command prompt window and run IC61_INSTALL_DIR\IC61\migration\ update_properties.bat. You should see messages similar to those shown in the following screenshot: 9. Examine IC61_INSTALL_DIR\IC61\logs\dbmigrate.log to make sure that the migration procedure did not result in any errors. (You can safely ignore the message "Connection <migrationdatasource> not found" if that appears in the log file.) Rerunning update_properties If the property migration is not completed for some reason, you should re-run IC61_INSTALL_DIR\IC61\migration\update_properties.bat. Any already-migrated properties will not be migrated again. The dbmigrate log indicates any existing property as!propmigration : Property (instancelevel;property_key;value_str) already exists. Import creationrules and fieldexpressions data You need to remove the mapping rules stored in the current creationrules and fieldexpressions tables, import the new mapping rules, and then recreate any customized mapping rules. To do so: 1. Identify any customizations you have made to the creationrules and fieldexpressions tables in the IC Repository database. 2. Use your database administration tools to make a backup of these two tables so that you can use this information to help you recreate your customizations later. 3. Delete all records from the creationrules and fieldexpressions tables using your database administration tools. Software Upgrade and Data Migration May

220 Chapter 6: Upgrading and migrating from to If you are planning to use Outbound Contact in but did not use it in 6.0.2, you need to make sure that the skill table is empty so that you can import the skills that Outbound Contact requires. If the skill table is not empty, delete all records from that table using your database administration tools. 5. Close your database administration tools. 6. In an ASCII editor such as Notepad, open IC61_INSTALL_DIR\IC61\design\ repository\data\delta_seed.cfg and: a. Make sure that the DestinationLogin and DestinationPasswd properties match a IC Manager login with administrator privileges. b. If you are planning to use Outbound Contact in but did not use it in 6.0.2, uncomment the statement "# Table=skill" in the # tables section by removing the "# " from the line so that the Skills table will be properly populated. c. Save and close the file. 7. Run IC61_INSTALL_DIR\IC61\design\repository\data\ import_delta_seed.bat. 8. Return to your database administration tool and recreate any customizations you made in 6.0.2, using the backup you made in Step 2 as a guide. Migrate your existing Prompter ActiveX controls If you use the Prompter client in any of the Avaya Business Applications, you need to replace all versions of the Prompter ActiveX control with the control and remove any references to the QPrompertFormActivate IC Script (which has been removed in 6.1.2). To do so: 1. Start Database Designer and open your CCQ ADL file (IC61_INSTALL_DIR\IC61\ design\callcenterq\ccq.adl). 2. Expand the Forms section under Components in the left-hand pane. 3. Select the form that contains the Prompter control (default: qprompter). 4. In the right-hand pane, go to the IC Script drop-down and replace QPrompertFormActivate with the null (empty) menu item. 5. In the left-hand pane, expand the selected form. 6. Under that form, expand the group that contains the Prompter control. 7. Under that group, select the actual Prompter control. 8. In the right-hand pane, rename the Prompter control object to QPrompterClient Under that form, right-click the group that contains the control (default: qprompter) and select New Objects from the pop-up menu. 220 Software Upgrade and Data Migration May 2009

221 Generate Windows applications and update server information 10. Select Generic ActiveX Control in the New Object dialog box and select Next. 11. Select QPrompter Control from the Insert Object dialog box and select the OK button. 12. In the New Object dialog box, make sure that the ActiveX ProgID is AvayaPrompterClient.PrompterClientCtrl.61. If it is, the control has been properly installed and you can enter the name QPrompterClient in the ActiveX control name field. When you are done, select Finish. 13. Optionally, link your IC Scripts to the Prompter events. 14. Delete the old QPrompterClient60 control that you renamed in step Select the tree-node for the newly-added dialog box object, and then select Edit > Form Layout. Database Designer opens the new dialog box in the Layout Editor. 16. If necessary, adjust the dimensions of the new dialog box so that both panes display properly. 17. Save the design and close the Layout Editor. Repeat this procedure for each form and group that contains a Prompter control. In 6.1.2, the ActiveX control no longer uses the Server and Port properties designated on the old Prompter form because the Prompter control now detects the server automatically. Therefore, the appprofileprompterlabel, appprofileqprompter_server, and appprofileqprompter_port parameters are ignored in Generate Windows applications and update server information At this point, generate the Windows applications, update server information, and install the secondary ORB servers.! Important: Important: If any failures occur when bringing up the servers, you may have to revert back to For details on how to revert to Avaya IC 6.0.2, see Restoring on page 291. This section includes the following topics: Generate the Windows applications on page 222 Update server information on page 225 Install your secondary ORB servers on page 228 Software Upgrade and Data Migration May

222 Chapter 6: Upgrading and migrating from to Generate the Windows applications The applications that you need to generate depend on your Avaya IC configuration: If you use... Avaya IC CallCenterQ Business Application Outbound Contact HRQ Business Application CustomerQ Business Application You need to generate... repository, reportwizard, interaction_center One of the ccq applications SoftDialer HRQ Custq Start the IC Manager Before you generate the Windows applications, open the IC Manager so that your administrator account does not become disabled during the generation process. Generate the repository application To generate the repository application: 1. In Database Designer, open IC61_INSTALL_DIR\IC61\design\ repository\repository.adl. 2. Select File > Generate Windows Application. 3. Select repository from the Application Name drop-down list. 4. Enable the Messages, IC Scripts, and Forms checkboxes so that these items will be saved to the database. 5. If necessary, enter an IC Manager Administrator username and password in the appropriate fields. (Do not enter your DBA username and password.) 6. Select Run. 7. Leave the ADL file open in Database Designer while you update the Directory server, as described below. Update the Directory server To update the Directory server: 1. In the instance of IC Manager that you opened in Start the IC Manager on page 222, select the Server tab. 222 Software Upgrade and Data Migration May 2009

223 Generate Windows applications and update server information 2. Stop and then restart the Directory server. 3. Select Manager > Update All. 4. Select Manager > Refresh. Generate the reportwizard application To generate the reportwizard application: 1. With the repository.adl file open in Database Designer, select File > Generate Windows Application. 2. Select reportwizard from the Application Name drop-down list. 3. Enable the Messages, IC Scripts, Forms, and Help Files checkboxes so that these items will be saved to the database. Tip: Tip: Select the help file IC61_INSTALL_DIR\IC61\help\ReportWizard\ Reports.chm. 4. If necessary, enter an IC Manager Administrator username and password in the appropriate fields. (Do not enter your DBA username and password.) 5. Select Run. 6. After you have generated the application, save and close the IC Repository ADL file. Generate the interaction_center application To generate the interaction_center application: 1. In Database Designer, open IC61_INSTALL_DIR\IC61\design\ callcenterq\ccq.adl. 2. Select File > Generate Windows Application. 3. Select interaction_center from the Application Name drop-down list. 4. Enable the Messages, IC Scripts, and Forms checkboxes so that these items will be saved to the database. 5. If your system includes Avaya Agent, enable the Avaya Agent and EDU Layout options. 6. If necessary, enter an IC Manager Administrator username and password in the appropriate fields. (Do not enter your DBA username and password.) 7. Select Run. 8. If you are going to use one of the CallCenterQ Business Applications, leave the ccq ADL file open in Database Designer and proceed to Generate a CallCenterQ Business Application (optional), below. Software Upgrade and Data Migration May

224 Chapter 6: Upgrading and migrating from to Generate a CallCenterQ Business Application (optional) If you want to use one of the CallCenterQ Business Applications, generate the appropriate application: 1. With the IC61_INSTALL_DIR\IC61\design\callcenterq\ccq.adl file open in Database Designer, select File > Generate Windows Application. 2. Select the CallCenterQ application you want to generate from the Application Name drop-down list. 3. Enable the Messages, IC Scripts, Forms, and Help Files checkboxes so that these items will be saved to the database. Tip: Tip: The default help file is IC61_INSTALL_DIR\IC61\Help\CallCenterQ\ ccq.chm. 4. If your system includes Avaya Agent, enable the Avaya Agent and EDU Layout options. 5. If necessary, enter an IC Manager Administrator username and password in the appropriate fields. (Do not enter your DBA username and password.) 6. Select Run. Generating the SoftDialer database (optional) If you want to use Outbound Contact, generate the SoftDialer application: 1. Open IC61_INSTALL_DIR\IC61\design\SoftDialer\dialer.adl. 2. Select File > Generate Windows Application. 3. Select SoftDialer from the Application Name drop-down list. 4. Enable the Messages checkbox so that the new messages will be saved to the database. 5. If necessary, enter an IC Manager Administrator username and password in the appropriate fields. (Do not enter your DBA username and password.) 6. Select Run. Generating the HRQ application (optional) If you want to use the HRQ Business Application, generate the HRQ application: 1. Open IC61_INSTALL_DIR\IC61\design\hrq\hrq.adl. 2. Select File > Generate Windows Application. 3. Select HRQ from the Application Name drop-down list. 4. Enable the Messages, IC Scripts, Forms, and Help Files checkboxes so that these items will be saved to the database. 224 Software Upgrade and Data Migration May 2009

225 Generate Windows applications and update server information Tip: Tip: The default help file is IC61_INSTALL_DIR\IC61\Help\HRQ\hrq.chm. 5. If your system includes Avaya Agent, enable the Avaya Agent and EDU Layout options. 6. If necessary, enter an IC Manager Administrator username and password in the appropriate fields. (Do not enter your DBA username and password.) 7. Select Run. Generating the CustomerQ application (optional) To generate the CustomerQ application: 1. Open IC61_INSTALL_DIR\IC61\design\custq\custq.adl. 2. Select File > Generate Windows Application. 3. Select CustomerQ from the Application Name drop-down list. 4. Enable the Messages, IC Scripts, Forms, and Help Files checkboxes so that these items will be saved to the database. Tip: Tip: The default help file is IC61_INSTALL_DIR\IC61\Help\CustomerQ\ custq.chm. 5. If your system includes Avaya Agent, enable the Avaya Agent and EDU Layout options. 6. If necessary, enter an IC Manager Administrator username and password in the appropriate fields. (Do not enter your DBA username and password.) 7. Select Run. Back up your databases After you have generated your Windows applications, Avaya strongly recommends that you create full backups of all your Avaya IC databases. Update server information To import the migrated server information and reset the password security options for the administrator account, go to the instance of IC Manager that you opened in Start the IC Manager on page 222 and: 1. Select the Server tab. Software Upgrade and Data Migration May

226 Chapter 6: Upgrading and migrating from to Import the sc.xml file by selecting Manager > Options > Environment > Import Configuration and selecting the IC61_INSTALL_DIR\IC61\etc\sc.xml file. Now make the changes listed in the following sections for any servers that your Avaya IC installation uses. When you are finished, update all server information as described in Update all server information on page 228. Workflow server changes Change the channel criteria for the workflow and web workflow servers to accommodate the case change in 6.1.2: 1. Double-click the Workflow server, and select the Channels tab. 2. Change the Event Name wacd.qualify to WACD.Qualify . 3. Select OK to save the change. 4. Double-click the Web Workflow server, and select the Channels tab. 5. Change the Event Name wacd.qualifychat to WACD.QualifyChat. 6. Select OK to save the change. server changes Update the directory for the server s temporary files: 1. Double-click the IC server. 2. Select the IC tab. 3. Right-click and select Show Advanced Properties from the pop-up menu. 4. Change the temporary file path to the new path. 5. Select OK to save the change. WebQ changes If you use WebQ, update the WebQ servers to use the paths: 1. Double-click the WebQ server. 2. Select the WebQ tab. 3. Make sure that the Login Page parameter points to the login page. 4. Select the Paths tab. 5. Change the paths to the new paths. 6. Select OK to save the changes and close the Server Editor. 7. Double-click the WebQRouter server. 226 Software Upgrade and Data Migration May 2009

227 Generate Windows applications and update server information 8. Select the WebQRouter tab. 9. Change the paths to the new paths. 10. Select OK to save the changes. Dialing Kernel server changes If you use Outbound Contact, change the agent password for the Dialing Kernel server to match the new password requirements: 1. Select the Agent tab. 2. Double-click the predictive dialing kernel agent (default: pdkdevctrl). 3. Change the password to dialer1. 4. Select OK to save the change. Tenant website changes If you have configured tenant Web sites: 1. Select the Configuration tab. 2. Open the Website table folder. 3. Right-click and select Show Advanced Properties from the pop-up menu. 4. Change the Path to PDM metadata file parameter to point to the new path. 5. Select OK to save the change. Content Analyzer server changes If you use Content Analyzer: 1. Double-click the first CAAdmin server. 2. Select the CAAdmin tab. 3. Change the Path to NLP Data parameter to point to the new path. 4. Select OK to save the change. 5. Repeat this procedure for each one of your CAAdmin servers. 6. Double-click the first CAServer server. 7. Select the CAServer tab. 8. Change the Path to NLP Data parameter to point to the new path. 9. Select OK to save the change. 10. Repeat this procedure for each one of your CAAdmin servers. Software Upgrade and Data Migration May

228 Chapter 6: Upgrading and migrating from to Update all server information To update all servers with your new settings: 1. Select Manger > Update All. 2. Select Manger > Refresh. Install your secondary ORB servers Once you have generated the Windows applications, you can begin installing your secondary ORB servers. To do so: 1. Reboot your primary server machine. 2. Make sure that your primary ORB server is up and running. 3. On the secondary machine, install Avaya IC in different directory from You should reboot this machine when prompted to do so by the installer. 4. Run the Configuration Tool specifying this install as the Secondary ORB and with the Start ORB option unchecked. Select all other options as appropriate. 5. Copy the ds.ffd and vesp.imp files from the IC61_INSTALL_DIR\IC61\etc directory on the primary ORB server machine to the same directory on the secondary ORB server machine, overwriting the out-of-the-box files. If you are copying the files via FTP, make sure that you transfer them in ASCII mode. 6. Make sure that you apply any appropriate 6.1 server patches to your secondary server machine, both from the Patches folder on the installation CD-ROM and from the Avaya Technical Support website. Repeat this procedure for each one of your secondary ORB servers. Configure the License server To configure the License server, you need to: 1. Run the Configuration Tool and specify your License server settings using the Web tab. (For details, see pages in IC Installation and Configuration.) 2. Make sure that you are running the correct version of the Java SDK, as described on pages of IC Installation Planning and Prerequisites. 3. Update your existing License server to use Tomcat instead of JRun. To do so: 228 Software Upgrade and Data Migration May 2009

229 Upgrade Avaya OA on the CMS servers a. In your IC Manager, select the Server tab. b. Double click on the License server. IC Manager displays the Server Editor dialog box. c. Select the Ellipsis (...) button next to the WebLM Server URLs field. d. In the listed URL(s), update the port to the new port number (which must be in the 9600 range). e. Select OK. f. Select OK to close the Server Editor dialog box. 4. Install the License file as described on pages of IC Installation and Configuration. Upgrade Avaya OA on the CMS servers For configurations that include CMS servers, do the procedures in this section to upgrade the CMS servers. This section includes the following topics: Expand the Avaya OA forwarder buffer sizes on page 229 Verify that Avaya OA interval processing and aggregation are complete on page 230 Upgrade the Avaya OA subsystem on CMS servers on page 230 Expand the Avaya OA forwarder buffer sizes Before upgrading Avaya OA from to on a CMS server, the size of the fwdcmscallhistory buffer on CMS servers need to be increased to avoid losing External Call History (ECH) data. The Avaya OA Administration Client on-line help under the subject Modifying interface services describes how to increase the buffer size.! Important: Important: Any data collected after the forwarder buffer becomes full will be lost. There is no way to recover this data. The formula for determining the minimum amount of space for this buffer is: Number of calls per day x 200 bytes per call record For example, if you have 100,000 calls per day at 200 bytes per call record, you will need 20 MB of free space. The default buffer size is 500 KB, with a maximum size of 2 GB. Software Upgrade and Data Migration May

230 Chapter 6: Upgrading and migrating from to Important:! Important: Make sure that the CMS filesystem has enough free disk space for the buffer data. The non-call history Avaya OA forwarders do not require buffer size adjustments since the data is stored in the CMS database. You can schedule an on-demand data collection job to recover the missing interval data after the upgrade and migration completes using the procedure found in Collect data from CMS servers on page 275. Verify that Avaya OA interval processing and aggregation are complete The Avaya OA historical server must be in operation to receive the last CMS interval data before Avaya OA on CMS is stopped. After the Avaya OA upgrade on the CMS server is finished, you can run on-demand collection to gather any missing interval data (see Collect data from CMS servers on page 275). Upgrade the Avaya OA subsystem on CMS servers This section contains the procedure to upgrade Avaya OA to Do this upgrade on all CMS servers that have Avaya OA This section includes the following topics: Preparation checklist on page 231 Upgrade Avaya OA Source-CMS subsystem from to on page 231 Recovery from a failed upgrade on page Software Upgrade and Data Migration May 2009

231 Upgrade Avaya OA on the CMS servers Preparation checklist Before you upgrade your installation, follow these important steps and recommendations. Procedure Have the installation media and documentation for Avaya OA available for use during the process in case you have to recover from a failed upgrade. See Recovery from a failed upgrade on page 235 for more information. Verify that there is a minimum of 512 MB of free temporary space in /var/tmp. If this space is not available, the installer may not run successfully. Use the df -k /var/tmp command to determine the amount of available disk space. The figures shown are in KB. Verity that you have user ID and password information for the CMS database user ID (for example, informix). Upgrade Avaya OA Source-CMS subsystem from to To start the upgrade process: 1. At the CMS server, log in as the Avaya OA installation user ID (for example, biadmin). 2. Enter: pa stop all 3. Log out of the Solaris desktop. 4. Log back in as root. CAUTION:! CAUTION: Install from a CD-ROM drive that is local to the server where you are installing the software. Installing from a networked CD drive is not supported. 5. Place the Avaya OA CD-ROM in the drive and wait about 15 seconds. A file manager window is displayed showing the contents of the CD-ROM. Minimize that window. If the File Manager window does not open, enter the following commands to start the volume manager: /etc/init.d/volmgt stop /etc/init.d/volmgt start Software Upgrade and Data Migration May

232 Chapter 6: Upgrading and migrating from to Important: 6. From the terminal window, enter the following commands:. /opt/bi/.profile cd /cdrom/cdrom0./solsetup After several seconds, the Initializing wizard window is displayed, followed by the Welcome dialog box.! Important: You can stop the installation at any time by clicking Cancel before you start the actual installation of files (see Step 19). If you click Cancel, you will be asked to confirm your intention to cancel. If you cancel, the installation is terminated and the system is restored to its previous state. 7. Click Next. The License Key dialog box is displayed. 8. Enter the provided license key for the components purchased. Confirm that you are upgrading from and to the correct loads. 9. Click Next. The License Agreement dialog box is displayed. 10. Select I accept the terms in the license agreement. 11. Click Next. The User Information dialog box is displayed. 12. Enter and confirm the password for the installed user ID. 232 Software Upgrade and Data Migration May 2009

233 Upgrade Avaya OA on the CMS servers 13. Click Next. The Historical Server Configuration dialog box is displayed. 14. The name of the Historical subsystem server cannot be changed. Complete the Alarm Services options, if required. The server name must be the server where the Source-EC subsystem is installed. 15. Click Next. The CMS Database Configuration dialog box is displayed. 16. Enter and confirm the password for the Informix user ID. Software Upgrade and Data Migration May

234 Chapter 6: Upgrading and migrating from to CAUTION: 17. Click Next. The Installation Preview dialog box is displayed listing the components you have selected. 18. Scroll through the preview dialog box to verify the selected components and configuration data.! CAUTION: Do not close the Progress dialog box after you have clicked Next in the following step. If you close the Progress dialog box after the installation has started, the installation will be disrupted and you must contact Avaya Technical Support to do a manual cleanup of the installation. 19. Click Next to start the installation. The Progress dialog box is displayed showing the progress of the installation, which will take several minutes. Near the end of the installation, the dialog box will go blank for some time. When the upgrade is finished, the Install Complete dialog box is displayed. 20. Click Next. The Install Complete dialog closes and the upgrade is finished. 21. Close all but one terminal window and enter: cd / eject cdrom 22. Remove the CD-ROM, and store it in a safe location. 23. Log out of the desktop environment. 24. Log back in as the Avaya OA installation user ID (for example, biadmin). 25. Enter:. /opt/bi/.profile 26. Enter the following command to show what processes are running: pa list A listing similar to the following is displayed.. system boot Dec 20 07:54. run-level 4 Dec 31 10:23 4 java. Dec 20 07: id=admb java. Dec 20 07: id=adm0 java. Jan 02 16: id=ams There should be three Java entries, and these lines should not have an exit code at the end of the line. 234 Software Upgrade and Data Migration May 2009

235 Upgrade Avaya OA on the CMS servers If there are any exit codes displayed on the Java entries, that process is not running. Escalate the problem to Avaya Technical Support. 27. If you get the message mom is not active, enter: pa start all 28. Repeat Step 26 to verify that Avaya OA has started. 29. If you are not successful starting Avaya OA, see Avaya Operational Analyst Release 6.1 Maintenance and Troubleshooting for more troubleshooting information. Recovery from a failed upgrade! Important: Important: If you manually stop an upgrade during file installation by closing the Progress dialog box, you cannot recover the upgrade using this procedure. You must contact Avaya Technical Support for assistance. You can return to the software and configuration if the upgrade to fails. This recovery feature applies to the Avaya OA software only and does not include data migration. The recovery to will be temporary until the upgrade to can be completed successfully. You can only recover to Avaya OA Recovery to a different version than had been previously operational is not possible. If a failure occurs during installation of files and a message is displayed indicating that recovery is required: 1. Continue with the failed upgrade until it completes. The software on the machine at this point is a mixture of the new software that was installed before the failure occurred as well as the old software that had not yet been replaced. 2. Uninstall the Avaya OA software. See Avaya Operational Analyst Release 6.1 Installation and Configuration. Do not manually remove any files under the $PABASE folders or directories. Note the following while doing the uninstall: The name of the remove script is AOARemove.bin instead of OARemove.bin as documented in Avaya Operational Analyst Release 6.1 Installation and Configuration. The script works in the same manner. With 6.1.2, the Features dialog box has changed from what is documented in Avaya Operational Analyst Release 6.1 Installation and Configuration. An example of the new dialog box is shown below. It is important that you do not clear (uncheck) the Install Software Upgrade and Data Migration May

236 Chapter 6: Upgrading and migrating from to Supporting Applications option. Leave this option and the Source-CMS Subsystem option checked when removing the software. 3. Install Avaya OA A window will indicate that a recovery is being done. The installation dialog boxes will then be displayed with the information that was entered when the software was originally installed. This information cannot be changed, except that you will have to enter your license key. Also, the Features and Destination dialog boxes will not be displayed, which prohibits you from changing that information. 4. Contact Avaya Technical Support to determine what must be fixed before trying the upgrade again. Shut down the Avaya OA servers before starting the upgrade Before you upgrade the Avaya OA servers, you must first verify that interval processing and aggregation are complete and then you can shut down the Avaya OA servers. This section includes the following topics: Verify that Avaya OA interval processing and aggregation are complete on page 237 Stop Avaya OA processes on page 237 Filesystem backup for Avaya OA on page Software Upgrade and Data Migration May 2009

237 Shut down the Avaya OA servers before starting the upgrade Verify that Avaya OA interval processing and aggregation are complete! CAUTION: CAUTION: If you stop Avaya OA and start the upgrade before the interval rollover has occurred, aggregated historical data will be lost. To minimize data loss in Avaya OA forwarders while the Real-time subsystem is being upgraded, make sure that interval processing and aggregation are complete for the last interval before you begin the upgrade. Use the Administration client to verify that interval processing and aggregation are complete. Stop Avaya OA processes Before you upgrade software on an Avaya OA server, you must stop certain processes on the server. This is required when you currently have the Historical subsystem, Real-time subsystem, Report subsystem (basic), or Source-EC (Event Collector) data collection software on the server. This section includes the following topics: Determine which components are installed on your server on page 237 Determine when to stop processes on page 238 Stop processes and services on a Windows server on page 239 Stop processes and services on a Solaris server on page 239 Determine which components are installed on your server Before you stop processes or traffic for data collection, use the oalist command to display the components currently installed on your server. To use the oalist command: 1. Log in as the Avaya OA installation user ID (for example, biadmin). Software Upgrade and Data Migration May

238 Chapter 6: Upgrading and migrating from to From a command prompt window, enter the following commands:. /opt/bi/.profile (Solaris only) oalist A message similar to the following is displayed: Subsystems installed Historical Reports Administration Client Server Names Historical: pez Historical Database: pez Database information Type: ORACLE UserID: biadmin Instance Name: dssdb Port number: 1521 IC User ID: icuser CMS Historical Tables created IC Historical Tables created User information OA User ID: biadmin Domain: oalab Group ID: oaadmin Reports information Reports Group ID: oarpt AOA Software information Version Installed: XXX Determine when to stop processes When upgrading Avaya OA subsystems, you should stop processes on servers just before you plan on upgrading the software. In other words, do not stop the processes for a server upgrade until the last possible moment. In general, you should save the upgrade of the Historical subsystem until last, doing subsystems on other servers first. See Order of server upgrades on page 245 for more information. 238 Software Upgrade and Data Migration May 2009

239 Shut down the Avaya OA servers before starting the upgrade Stop processes and services on a Windows server Based on the subsystems that are installed, use the following table to determine which procedures should be done to stop processes and services: Subsystems Historical Real-time Report Source-EC Procedure 1. Log in as a local administrative user. 2. In a command prompt window, enter pa stop all. 3. Select Start > Programs > Administrative Tools > Services. 4. Stop the Avaya Business Intelligence and ORBacus Naming services. 1. Log in as a local administrative user. 2. In a command prompt window, enter pa stop all. 3. Select Start > Programs > Administrative Tools > Services. 4. Stop the Avaya Business Intelligence, ORBacus Naming, and Stumbras-Tomcat services. 1. Log in as a local administrative user. 2. Select Start > Programs > Administrative Tools > Services. 3. Stop the ORBacus Naming service. Stop processes and services on a Solaris server Based on the subsystems that are installed, use the following table to determine which procedures should be done to stop processes and services: Subsystems Historical Real-time Report Source-EC Procedure 1. Log in with the Avaya OA installation user ID (for example, biadmin). 2. Enter the following commands:. /opt/bi/.profile pa stop all 1. Log in with the Avaya OA installation user ID (for example, biadmin). 2. Enter the following commands:. /opt/bi/.profile pa stop all cd $SUN_ONE_HOME/https-stumbras./stop From IC Manager, stop the Source-EC subsystems. Software Upgrade and Data Migration May

240 Chapter 6: Upgrading and migrating from to Filesystem backup for Avaya OA To prepare for recovery in case you need to back out the Avaya OA software upgrade, you should create a filesystem backup of the Avaya OA software and the OS. You can later use this backup to restore the filesystem where Avaya OA was installed and the filesystem where the OS was installed. See your server documentation for information about doing a filesystem backup. If you have to do a restore from this backup, see Restoring on page 291 for more information. Upgrade Avaya OA components from to This section contains the procedure to upgrade your Avaya OA software components to This upgrade must be done on all servers that have components. You may not add new subsystems while you are doing the upgrade. You must upgrade to the new version of software and then add the subsystems later using the instructions found in Avaya Operational Analyst Release 6.1 Installation and Configuration. Do not use this procedure to upgrade the CMS servers. The CMS servers, if part of the configuration, should have been upgraded previously using the instructions in Upgrade Avaya OA on the CMS servers on page 229. This section includes the following topics: Path definitions on page 240 License key considerations on page 242 Update Cognos and server properties on page 243 Upgrade Avaya OA software on page 245 Path definitions It is important to understand the path definitions for the different operating systems: Windows path definitions on page 241 Solaris path definitions on page Software Upgrade and Data Migration May 2009

241 Upgrade Avaya OA components from to Windows path definitions The following variable is used in this document to represent the installation path for most Avaya OA software on Windows: %PABASE% For example, the location for a file in that path is shown as follows: %PABASE%\stumbras\tomcat\work\localhost_8080 The following is the default installation path Avaya OA uses on a Windows server: C:\Program Files\Avaya\BI When installing Avaya OA, the BI portion of the path is not displayed when the default path is shown in the Destination dialog box. This is added as part of the installation. The following variable is used in this document to represent the installation path for EC Server and EC Bridge software on Windows: %AVAYA_IC61_HOME%\bin Solaris path definitions The following variable is used in this document to represent the installation path for most Avaya OA software on Solaris: $PABASE For example, the location for a directory in that path is shown as follows: $PABASE/data/log Depending on how the OS was installed and how the filesystems were created, the following is the default installation path Avaya OA uses on a Solaris server: /export/home/biadmin/bi When installing Avaya OA, the BI portion of the path is not displayed when the default path is shown in the Destination dialog box. This is added as part of the installation. The following variables are used in this document to represent the installation path for the Sun ONE Web Server software on Solaris: $SUN_ONE_HOME Software Upgrade and Data Migration May

242 Chapter 6: Upgrading and migrating from to The following variables are used in this document to represent the installation path for EC Server software and libraries on Solaris: $AVAYA_IC61_HOME/bin $AVAYA_IC61_HOME/lib License key considerations Beginning with 6.1, Avaya OA supports two licensing levels instead of the three used in 6.0 (CMS standalone, Operational, and Analytical): Avaya CMS Analytical: This license is used for configurations that allow only Avaya CMS as a data source to Avaya OA (no Avaya IC data source). With this license, you get both basic reports and advanced reports. Avaya IC and Avaya CMS Analytical: This license is used for configurations that allow Avaya IC and Avaya CMS as data sources to Avaya OA. With this license, you get both basic reports and advanced reports. When upgrading from Avaya OA to 6.1.2, you will have to apply new license keys to upgrade the components. When applying new license keys, you must follow the process described in the following table: Old license key Analytical CMS standalone New license key Avaya IC and Avaya CMS Analytical Avaya CMS Analytical Process Upgrade the software with the new license key using the procedures in this section. Do the following: 1. See Avaya Operational Analyst Release 6.1 Installation Planning and Prerequisites for information about installing the database and setting up tables. 2. Upgrade the software with the new license key using the procedures in this section. 3. Install both the Real-time subsystem and the Advanced Reporting subsystem. See Avaya Operational Analyst Release 6.1 Installation and Configuration. 242 Software Upgrade and Data Migration May 2009

243 Upgrade Avaya OA components from to Old license key CMS standalone Operational New license key Avaya IC and Avaya CMS Analytical Avaya IC and Avaya CMS Analytical Process Do the following: 1. See Avaya Operational Analyst Release 6.1 Installation Planning and Prerequisites for information about installing the database and setting up tables. 2. Upgrade the software with the new license key using the procedures in this section. 3. Reinstall (repair) the Historical subsystem (see Avaya Operational Analyst Release 6.1 Installation and Configuration), making sure to select Avaya IC as a data source. 4. Install both the Real-time subsystem and the Advanced Reporting subsystem. See Avaya Operational Analyst Release 6.1 Installation and Configuration. Do the following: 1. Upgrade the software with the new license key using the procedures in this section. 2. Install the Advanced Reporting subsystem. See Avaya Operational Analyst Release 6.1 Installation and Configuration. Update Cognos and server properties Before you begin an upgrade, you must update Cognos, if used currently, and check the status of the server properties. This section includes the following topics: Install Cognos software for Advanced reports (optional) on page 243 Update server properties on the Historical subsystem on page 244 Install Cognos software for Advanced reports (optional) If your system did not use the Advanced reports feature, or you are not going to use the Advanced reports feature in 6.1.2, you can skip this section. With the Advanced reports feature of Avaya OA 6.0.2, Cognos Version 6.1 was installed on the same machine as the Advanced reports subsystem. For Avaya OA 6.1.2, if you are continuing to use the Advanced reports feature, or if you are going to start using the Advanced reports feature, you must install the Cognos Version 7.0 MR1 software on the machine where you will upgrade or install the Advanced reports subsystem. After you install the new version of Cognos, you must then open any customized reports and save them to the new Cognos version. Software Upgrade and Data Migration May

244 Chapter 6: Upgrading and migrating from to For detailed information about what version of Cognos to use for language support, see Avaya Operational Analyst Release 6.1 Installation Planning and Prerequisites. To install the Cognos software for the Advanced reports feature and update the report versions: 1. Install the Cognos 7.0 MR1 software as described in Cognos documentation. 2. For any customized reports, open each report and save it as the new Cognos version as described in Cognos documentation. 3. For any predefined reports you have modified, open each report and save it as the new Cognos version under a new report name. Important:! Important: If you have modified the predefined reports under the default name in 6.0.2, the default out-of-the-box version of the predefined reports will overwrite the reports. If you want to preserve the reports, you must first save the modified reports under a different name before you upgrade the Avaya OA software. Update server properties on the Historical subsystem On the Avaya OA server where the Historical subsystem is installed, you must verify whether the server.properties file must be updated before you upgrade the subsystem to To check and update the server.properties file: 1. Make a copy of the server.properties file before you make any changes. 2. Open the %PABASE%\data\admin\server.properties (Windows) or $PABASE/ data/admin/server.properties (Solaris) file. 3. For systems that are using either SQL or Oracle, search for a line that has dbicuserid. Do one of the following: If the entry is already populated with the name of the Avaya IC User ID, skip to Step 4. If the entry is blank, after the equal sign (=), add the name of the Avaya IC User ID that was previously used in See the following example for this change:.. dbuserid=dbuser dbicuserid=icuser sqldbicname= icrepositorydbname= Software Upgrade and Data Migration May 2009

245 Upgrade Avaya OA components from to For systems that are using SQL (not Oracle), search for a line that has sqldbicname. Do one of the following: If the entry is already populated with the name of the Avaya IC User ID, skip to Step 5. If the entry is blank, after the equal sign (=), add the name of the Avaya IC database that was previously used in (often called repository). See the following example for this change:.. dbuserid=dbuser dbicuserid=icuser sqldbicname=repository icrepositorydbname=.. 5. Save and close the file. Upgrade Avaya OA software This section includes the following topics: Order of server upgrades on page 245 Upgrade Avaya OA from to 6.1 on page 246 Recovery from a failed upgrade on page 252 Order of server upgrades The order in which you upgrade the Avaya OA subsystems on your servers is very important. For example, if you have the following configuration: Main site - server with the Historical subsystem, Report subsystem, Administration client, and Real-time subsystem Remote site #1 - server with the Real-time subsystem and Report subsystem Remote site #2 - server with the Real-time subsystem, Report subsystem, and Administration client After the upgrade is done, you must install the Source-EC subsystem on every server where you have the Real-time subsystem. With this configuration, you should upgrade sites #1 and #2 first, saving the main site for last where the Historical subsystem resides. As a general rule, always upgrade the server that has the Historical subsystem last. Software Upgrade and Data Migration May

246 Chapter 6: Upgrading and migrating from to Upgrade Avaya OA from to 6.1 The procedures for upgrading Avaya OA software are almost identical for all operating systems. For this procedure, the Windows dialog boxes are shown and any differences for the other operating systems are described. To start the upgrade process: 1. Do one of the following to access and start the installation executable: CAUTION:! CAUTION: Install from a CD-ROM drive that is local to the server where you are installing Avaya OA. Installing from a networked CD drive is not supported. Operating System Windows Solaris Procedure 1. Log in as a local administrative user. 2. Place the Avaya OA CD-ROM in the drive. 3. Double-click the WinSetup.exe file in the root directory. 1. Log in as root. 2. Place the Avaya OA CD-ROM in the drive and wait about 15 seconds. A file manager window is displayed showing the contents of the CD-ROM. Minimize that window. If the File Manager window does not open, enter the following commands to start the volume manager: /etc/init.d/volmgt stop /etc/init.d/volmgt start 3. From a terminal window, enter the following commands:. /opt/bi/.profile cd /cdrom/cdrom0./solsetup After several seconds, the Initializing wizard window is displayed, followed by the Welcome dialog box. Important:! Important: You can stop the installation at any time by clicking Cancel before you start the actual installation of files (see Step 26). If you click Cancel, you will be asked to confirm your intention to cancel. If you cancel, the installation is terminated and the system is restored to its previous state. 246 Software Upgrade and Data Migration May 2009

247 Upgrade Avaya OA components from to Click Next. The License Key dialog box is displayed. 3. Enter the provided license key for the components purchased. 4. Click Next. The License Agreement dialog box is displayed. 5. Select I accept the terms in the license agreement. 6. Click Next. The User Information dialog box is displayed. The Domain field is only displayed for Windows systems. 7. Enter and confirm the password for the installed user ID. 8. Click Next. 9. One of the following occurs: If the system being upgraded has the Historical subsystem or the Report subsystem on a Windows or Solaris system, the Reports Configuration dialog box is displayed, but no options can be changed. Continue with Step 10. If the system being upgraded does not have the Historical subsystem or the Report subsystem, continue with Step Click Next. Software Upgrade and Data Migration May

248 Chapter 6: Upgrading and migrating from to The Historical Server Configuration dialog box is displayed. The fields that appear on the Historical Server Configuration dialog box may vary depending on your component selections. 12. Complete the Alarm Services options, if required. The server name must be the server where the Source-EC subsystem is installed. No other options should be changed. 13. Click Next. The Database Configuration dialog box is displayed. 14. Enter and confirm the administrator and database passwords. 248 Software Upgrade and Data Migration May 2009

249 Upgrade Avaya OA components from to Click Next. Do one of the following: For Oracle, continue with Step 16. For SQL, continue with Step A warning dialog concerning the Oracle archive log may be displayed. 17. Click OK to acknowledge the warning, if displayed. 18. For Oracle, the TNSnames.ora file is scanned to see if the TNS server name is contained within that file. If it is, the install continues with Step 19. If it is not, the following warning message is displayed asking if you want the installation program to modify the TNSnames.ora file to include the TNS server name. If you select No, you are returned to the Database Configuration dialog box. You can go no further until you resolve the TNS server name issue. If you select Yes, the installation program attempts to edit the file. One of the following occurs: - If the permissions on the TNSnames.ora file allow writing, the file is modified to include the administered TNS server name and the install continues. - If the permissions on the TNSnames.ora file are read-only, the file cannot be modified and a message is displayed stating that the permissions on the file must be changed manually. Select OK to return to the Database Configuration dialog box. You must change permissions on the file if you want to continue with the install. There may be a long delay before the next dialog box is displayed. 19. For an Avaya IC and Avaya OA configuration, the filegroup or tablespace dialog box for the new Avaya IC tables is displayed. Otherwise, continue with Step 21. Software Upgrade and Data Migration May

250 Chapter 6: Upgrading and migrating from to If the database is on a dedicated back-end database server (a server other than where the Historical subsystem is being upgraded), none of the table space dialog boxes are displayed. Continue with Step Click Next (do not change any options). 21. One of the following occurs: If you are upgrading a system that has a Real-time subsystem, the Real-time Configuration dialog box is displayed, but no options can be changed. Continue with Step 22. If the system does not have a Real-time subsystem, continue with Step Click Next. 23. A warning message concerning TimesTen files may be displayed. Click OK to continue. 24. The Installation Preview dialog box is displayed listing the components you have selected. 25. Scroll through the preview dialog box to verify the selected components and configuration data. 250 Software Upgrade and Data Migration May 2009

251 Upgrade Avaya OA components from to CAUTION: CAUTION:! CAUTION: Do not close the Progress dialog box after you have clicked Next in the following step. If you close the Progress dialog box after the installation has started, the installation will be disrupted and you must contact Avaya Technical Support to do a manual cleanup of the installation. 26. Click Next to start the installation. The Progress dialog box is displayed showing the progress of the installation, which will take several minutes. Near the end of the installation, the dialog box will go blank for some time. When the upgrade is finished, the Install Complete dialog box is displayed. 27. Click Next. On Solaris, the Install Complete dialog closes and the upgrade is finished. On Windows, the Restart System dialog box is displayed. Before you reboot the server, make sure that a copy of the server.properties file is saved in case it is deleted during the reboot. Do the following: 1. Open Windows Explorer. 2. Navigate to %PABASE%\BI\data\admin. 3. Copy the server.properties file onto the Windows clipboard. 4. Go to your Windows desktop (or some other location other than the Avaya OA installation directory) and paste the server.properties file there.! CAUTION: You must always restart a Windows server at this time for Avaya OA to operate properly. If you are not requested to restart the server, you must manually restart the server. 5. Go back to the Restart System dialog box, select the option to restart your system now, and click Next. 6. After the system reboots, navigate to %PABASE%\BI\data\admin. 7. Verify that the server.properties file is in the folder. 8. If the file is not in the folder, go to the location where you saved a copy of server.properties and copy the file onto the Windows clipboard. 9. Navigate to %PABASE%\BI\data\admin. 10. Paste the server.properties file into the folder. 28. Do one of the following: On Windows, press the eject button on the CD-ROM drive, remove the CD-ROM, and store it in a safe location. Software Upgrade and Data Migration May

252 Chapter 6: Upgrading and migrating from to On Solaris, close all but one terminal window and enter: cd / eject cdrom 29. Repeat this procedure for every machine where Avaya OA components are installed. Recovery from a failed upgrade If a failure occurs during installation and a message is displayed indicating that recovery is required, you can return to the software and configuration if the upgrade to fails. This recovery feature applies to the Avaya OA software only and does not include data migration. The recovery to will be temporary until the upgrade to can be completed successfully. Important:! Important: If you manually stop an upgrade during file installation by closing the Progress dialog box, you cannot recover the upgrade using this procedure. You must contact Avaya Technical Support. You can only recover to Avaya OA Recovering to a different version than had been previously operational is not possible. Even if you have to uninstall failed upgrade software from the Avaya OA servers, do not uninstall the Avaya OA Source-CMS subsystem from the CMS servers that were upgraded earlier. The Avaya OA Source-CMS subsystem on a CMS server will be able to communicate with an Avaya OA server. To continue the upgrade and then uninstall the software: 1. Continue with the failed upgrade and reboot. The software on the machine at this point is a mixture of the new software that was installed before the failure occurred as well as the old software that had not yet been replaced. 2. Uninstall the Avaya OA software. See Avaya Operational Analyst Release 6.1 Installation and Configuration. Do not manually remove any files under the %PABASE% or $PABASE folders or directories. Important:! Important: On Solaris, the name of the remove script is AOARemove.bin instead of OARemove.bin as documented in Avaya Operational Analyst Release 6.1 Installation and Configuration. The script works in the same manner. 252 Software Upgrade and Data Migration May 2009

253 Upgrade Avaya OA components from to Important:! Important: With 6.1.2, the Features dialog box has changed from what is documented in Avaya Operational Analyst Release 6.1 Installation and Configuration. An example of the new dialog box is shown below. It is important that you do not clear (uncheck) the Install Supporting Applications option. Leave this option checked when removing the software. To uninstall all JRE software (Windows only): 1. Select Start > Settings > Control Panel. 2. Double-click Add/Remove Programs. 3. Scroll through the list of currently-installed programs and find all occurrences of Java 2 Runtime Environment (JRE) software. 4. Remove all occurrences of the JRE software. To reinstall the software: 1. Stop all processes on the server (see Stop Avaya OA processes on page 237). 2. Reinstall Avaya OA A window will indicate that a recovery is being done. The installation dialog boxes will then be displayed with the information that was entered when the software was originally installed. This information cannot be changed, except that you will have to enter your license key. Also, the Features and Destination dialog boxes will not be displayed, which prohibits you from changing that information. Software Upgrade and Data Migration May

254 Chapter 6: Upgrading and migrating from to CAUTION:! CAUTION: Do not make any changes to the server.properties file that are not described in Step 3. Do not add any blank lines or spaces to any existing lines. If the server.properties file is damaged, the server will not operate properly. 3. On a Windows or Solaris server where the upgrade failed while upgrading the Historical subsystem: a. Make a copy of the server.properties file before you make any changes. b. Open the %PABASE%\data\admin\server.properties (Windows) or $PABASE/ data/admin/server.properties (Solaris) file. c. For systems that are using either the SQL or Oracle database software, search for a line that has dbicuserid. This entry should be blank. d. After the equal sign (=), add the name of the Avaya IC User ID that was previously used in e. For systems that are using the SQL database software (not Oracle), search for a line that has sqldbicname. This entry should be blank. f. After the equal sign (=), add the name of the Avaya IC database that was previously used in (often called repository). See the following example for these changes:.. dbuserid=dbuser dbicuserid=icuser sqldbicname=repository icrepositorydbname=.. g. Save and close the file. 4. Contact Avaya Technical Support to determine what must be fixed before trying the upgrade again. 254 Software Upgrade and Data Migration May 2009

255 Bring up the Avaya OA servers and components Bring up the Avaya OA servers and components The Avaya OA servers and components must now be started and brought into operation.! Important: Important: If any failures occur when bringing up the servers, you may have to revert back to For details on how to revert to Avaya OA 6.0.2, see Recovery from a failed upgrade on page 252. This section includes the following topics: Start up all Avaya OA servers on page 255 Disable aggregation recovery on page 263 Update and verify Avaya OA components on page 263 Start up all Avaya OA servers Depending on the platform you are using, use the procedures in the following sections to complete your upgrade and bring up the Avaya OA servers: To start Avaya OA on a Windows system on page 255 To start Avaya OA on a Solaris system on page 258 To start Avaya OA on a Windows system 1. Log in using an Avaya OA user ID and password. 2. Open a command prompt window. Software Upgrade and Data Migration May

256 Chapter 6: Upgrading and migrating from to In the command prompt window, enter the following command to show what processes are running: pa list A listing similar to the following is displayed.. system boot Dec 20 07:54. run-level 4 Dec 31 10:23 4 java. Dec 20 07: id=admb java. Dec 20 07: id=adm0 java. Jan 02 16: id=ams java. Dec 20 07: id=aut java. Dec 20 07: id=schd recorder. Dec 20 08: id=reccmsagent recorder. Dec 20 08: id=reccmscwc... There should be several Java entries, and these lines should not have an exit code at the end of the line. The recorder entries are displayed only if you are collecting data from CMS or Avaya IC. Forwarder entries will be displayed on a server that has the Real-time subsystem installed. If there are any exit codes displayed on the Java entries, that process is not running. Escalate the problem to Avaya Technical Support. 4. If you get the message mom is not active, enter: pa start all 5. Repeat Step 3 to verify that Avaya OA has started. 256 Software Upgrade and Data Migration May 2009

257 Bring up the Avaya OA servers and components 6. Enter: oalist A message similar to the following is displayed listing what components are installed on this server: Subsystems installed Historical Advanced Reports Administration Client Server Names Historical: pez Reports: pez Database information Type: ORACLE User ID: oracle Instance Name: dssdb Port Number: 1521 IC User ID: icuser CMS Historical Tables created IC Historical Tables created User information OA User ID: biadmin Domain: oalab Group ID: oaadmin Reports information Reports Group ID: oarpt Admin Client Locale Admin Client Locale: en_us OA Software information Version Installed: XXX 7. Select Start > Programs > Administrative Tools > Services. Software Upgrade and Data Migration May

258 Chapter 6: Upgrading and migrating from to Based on the subsystems that are installed, validate that the following services are started and are set to start automatically. If they are not administered to start automatically, administer them as such. Subsystems Services Historical Avaya Business Intelligence Service ORBacus Naming Service Real-time Avaya Business Intelligence Service ORBacus Naming Service TimesTen Data Manager 4.5 Report Avaya Business Intelligence Service ORBacus Naming Service Stumbras-Tomcat Source-EC ORBacus Naming Service 9. If you are not successful starting Avaya OA, see Avaya Operational Analyst Release 6.1 Maintenance and Troubleshooting for more troubleshooting information. To start Avaya OA on a Solaris system 1. Log out of the desktop environment. 2. Log in using an Avaya OA user ID and password. 3. Enter:. /opt/bi/.profile 258 Software Upgrade and Data Migration May 2009

259 Bring up the Avaya OA servers and components 4. Enter the following command to show what processes are running: pa list A listing similar to the following is displayed.. system boot Dec 20 07:54. run-level 4 Dec 31 10:23 4 java. Dec 20 07: id=admb java. Dec 20 07: id=adm0 java. Jan 02 16: id=ams java. Dec 20 07: id=aut java. Dec 20 07: id=schd recorder. Dec 20 08: id=reccmsagent recorder. Dec 20 08: id=reccmscwc... There should be several Java entries, and these lines should not have an exit code at the end of the line. The recorder entries are displayed only if you are collecting data from CMS or Avaya IC. Forwarder entries will be displayed on a server that has the Real-time subsystem installed. If there are any exit codes displayed on the Java entries, that process is not running. Escalate the problem to Avaya Technical Support. 5. If you get the message mom is not active, enter: pa start all 6. Repeat Step 4 to verify that Avaya OA has started. 7. If you are not successful starting Avaya OA, see Avaya Operational Analyst Release 6.1 Maintenance and Troubleshooting for more troubleshooting information. Software Upgrade and Data Migration May

260 Chapter 6: Upgrading and migrating from to Enter: oalist A message similar to the following is displayed: Subsystems installed Historical Real Time Reports Data Export Utility Server Names Historical: screamer Historical Database: screamer Reports: screamer.dr.avaya.com Database information Type: ORACLE UserID: oracle Instance Name: dssdb Port Number: 1521 IC UserID: icuser CMS Historical Tables created IC Historical Tables created User information OA User ID: biadmin Group ID: oaadmin Reports information Reports Group ID: oarpt iplanet Root: /usr/iplanet/servers Stumbras Port Number: Admin Client Locale OA Software information Version Installed: XXX 9. If the Historical subsystem is installed, use the following commands to verify that the required services are running. If the services are not running, escalate the problem using the normal channels. a. Enter the following command to see if the Avaya Business Intelligence Service is running: ps -ef grep initsrv A message similar to the following should be displayed. root Dec 27? 0:06 /opt/bi/bin/initsrv -n oaadmin -v 30 biadmin :28:00 pts/11 0:00 grep initsrv 260 Software Upgrade and Data Migration May 2009

261 Bring up the Avaya OA servers and components b. Enter the following command to see if the ORBacus Naming Service is running: ps -ef grep nameserv A message similar to the following should be displayed. root Dec 27? 38:41 /opt/bi/bin/nameserv -OAport OAnumeric biadmin :32:21 pts/11 0:00 grep nameserv 10. If the Real-time subsystem is installed, use the following commands to verify that the required services are running. If the services are not running, escalate the problem using the normal channels. a. Enter the following command to see if the Avaya Business Intelligence Service is running: ps -ef grep initsrv A message similar to the following should be displayed. root Dec 27? 0:06 /opt/bi/bin/initsrv -n oaadmin -v 30 biadmin :28:00 pts/11 0:00 grep initsrv b. Enter the following command to see if the ORBacus Naming Service is running: ps -ef grep nameserv A message similar to the following should be displayed. root Dec 27? 38:41 /opt/bi/bin/nameserv -OAport OAnumeric biadmin :32:21 pts/11 0:00 grep nameserv c. Enter the following command to see if the TimesTen Data Manager 4.5 is running: ps -ef grep timesten A message similar to the following should be displayed. root Dec 23? 0:01 /export/home/biadmin/timesten4.5/ 32/bin/timestend root Dec 23? 0:00 /export/home/biadmin/timesten4.5/ 32/bin/timestensubd -id 0 root Dec 23? 0:00 /export/home/biadmin/timesten4.5/ 32/bin/timestensubd -id 1 root Dec 23? 0:00 /export/home/biadmin/timesten4.5/ 32/bin/timestensubd -id 2 root Dec 23? 0:00 /export/home/biadmin/timesten4.5/ 32/bin/timestensubd -id 3 biadmin :34:22 pts/11 0:00 grep timesten Software Upgrade and Data Migration May

262 Chapter 6: Upgrading and migrating from to If the Source-EC subsystem is installed, use the following commands to verify that the required services are running. If the services are not running, escalate the problem using the normal channels. a. Enter the following command to see if the ORBacus Naming Service is running: ps -ef grep nameserv A message similar to the following should be displayed. root Dec 27? 38:41 /opt/bi/bin/nameserv -OAport OAnumeric biadmin :32:21 pts/11 0:00 grep nameserv 12. If the Report subsystem is installed, enter the following commands to start Stumbras: cd $SUN_ONE_HOME/https-stumbras./start The following message is displayed.... Startup: server started successfully 13. If the Report subsystem is installed, use the following commands to verify that the required services are running. If the services are not running, escalate the problem using the normal channels. a. Enter the following command to see if the Avaya Business Intelligence Service is running: ps -ef grep initsrv A message similar to the following should be displayed. root Dec 27? 0:06 /opt/bi/bin/initsrv -n oaadmin -v 30 biadmin :28:00 pts/11 0:00 grep initsrv b. Enter the following command to see if the ORBacus Naming Service is running: ps -ef grep nameserv A message similar to the following should be displayed. root Dec 27? 38:41 /opt/bi/bin/nameserv -OAport OAnumeric biadmin :32:21 pts/11 0:00 grep nameserv 262 Software Upgrade and Data Migration May 2009

263 Bring up the Avaya OA servers and components c. Enter the following command to see if Stumbras-Tomcat is running: ps -ef grep https-stumbras A message similar to the following should be displayed. biadmin Dec 31? 0:00./uxwdog -d /usr/iplanet/servers/ https-stumbras/config biadmin Dec 31? 1:01 ns-httpd -d /usr/iplanet/servers/ https-stumbras/config biadmin Dec 31? 0:03 ns-httpd -d /usr/iplanet/servers/ https-stumbras/config biadmin :38:51 pts/11 0:00 grep https-stumbras Disable aggregation recovery Since no data has been collected while the system was being upgraded, there is no data in the Avaya OA STATUS or Avaya OA/Avaya IC historical tables. Meanwhile, the containers have been disabled during the upgrade since the schema modification. Since the old data has not yet been migrated in tables, you must disable the Aggregation Recovery using the Administration client. Do not use on-demand aggregation to aggregate the old historical data. Update and verify Avaya OA components After you have upgraded the Avaya OA components, do the following to update and verify that the components are working properly: 1. Delete and reconfigure all Report subsystems. After you reconfigure the Report subsystems, you must manually stop and restart Stumbras on each server. To restart Stumbras on a Windows server: 1. Select Start > Programs > Administrative Tools > Services. The Services dialog box is displayed. 2. Find the Stumbras-Tomcat service. 3. Manually stop and restart the service, verifying that it is also set to start automatically. To restart Stumbras on a Solaris server: 1. Log in using an Avaya OA user ID and password. Software Upgrade and Data Migration May

264 Chapter 6: Upgrading and migrating from to Important: 2. Enter the following commands: cd $SUN_ONE_HOME/https-stumbras./stop./start 2. On all Avaya OA Report client PCs, uninstall the JRE and Report client support files, and install the new JRE and Report client support files. 3. Verify that all other subsystems are configured and operating properly. 4. Change the naming service port number if it had been changed from the default of on the system. 5. Verify that all Avaya OA Administration client users, in case they did not log off and closed their browser windows before you upgraded the Avaya OA software, log off now and restart their Administration client sessions. 6. Customize the Administration client as needed for locale and archive time zone. 7. Define new containers for Avaya OA based on the new schema. Once the containers are defined, a user can then do on-demand aggregation. See the Avaya OA Administration client online help for more information.! Important: The containers are permanently inactive following migration to In order to continue aggregating data, new containers must be defined using the Avaya OA Administration client. 8. Rebuild all saved basic reports. 9. If you use the Avaya IC dialer, modify the Avaya Interaction Center source type on the Add Subsystem page to select the following stores for historical data flows, and save the configuration: Agent Completion Code Agent Job Job Summary System Completion Code 10. Install the Source-EC subsystem on all servers where the Real-time subsystem is installed. If the server where the Real-time subsystem has already been upgraded with the new Source-EC subsystem, you can skip this step. The Avaya IC secondary ORB server must be installed before you install the Source-EC subsystem. When you install the new Source-EC subsystems, you must reapply your old Source-EC configurations to the new subsystems by: a. Copying the current configuration in IC Manager. 264 Software Upgrade and Data Migration May 2009

265 Bring up the Avaya OA servers and components b. Pasting the configuration into a new Server Editor session. c. Change the IP address to point to the server where the Source-EC subsystem is installed. d. Verify the sites and domains to monitor. Change these as needed. e. Save the new configuration and remove the old configuration. f. Remove the Source-EC subsystem from any servers that are no longer in the proper deployment configuration. 11. With Avaya OA 6.1.2, there is a new optional feature called the Data Export utility that allows you to export data from the database. For more information about this feature and how to install it, see: Avaya Operational Analyst Release 6.1 What s New in Operational Analyst R6.1 Avaya Operational Analyst Release 6.1 Data API Utility Avaya Operational Analyst Release 6.1 Installation and Configuration If you do add the Data Export utility (or any other feature) on a Windows server, make sure that a copy of the server.properties file is saved after you add this feature in case it is deleted during the reboot. Do the following: a. Open Windows Explorer. b. Navigate to %PABASE%\BI\data\admin. c. Copy the server.properties file onto the Windows clipboard. d. Go to your Windows desktop (or some other location other than the Avaya OA installation directory) and paste the server.properties file there. e. Go back to the Restart System dialog box, select the option to restart your system now, and click Next. f. After the system reboots, navigate to %PABASE%\BI\data\admin. g. Verify that the server.properties file is in the folder. h. If the file is not in the folder, go to the location where you saved a copy of server.properties and copy the file onto the Windows clipboard. i. Navigate to %PABASE%\BI\data\admin. j. Paste the server.properties file into the folder. See Avaya Operational Analyst Release 6.1 Installation and Configuration for details on installing subsystems and making configuration changes. Software Upgrade and Data Migration May

266 Chapter 6: Upgrading and migrating from to Verify that forwarders on CMS servers are sending data To verify that forwarders on each CMS server are sending data: 1. Log in as root to the CDE on the local CMS machine. 2. Use the following command to verify that the required services are running. If the services are not running, escalate the problem using the normal channels. ps -ef grep nameserv A message similar to the following should be displayed. root Dec 27? 38:41 /opt/bi/bin/nameserv -OAport OAnumeric biadmin :32:21 pts/11 0:00 grep nameserv 3. Enter: dcstat -n forwarder -a where forwarder includes the following CMS forwarders: fwdcmscallhistory fwdcmssynonyms fwdcmsagent fwdcmscwc fwdcmsskill fwdcmsvdn The following display shows a typical status message for the forwarders on the CMS server. servername Process: pid=16563 forwarder -n forwarder -v 30 -t all Status: 12/30/03 14:18:14 through 12/30/03 14:23:56 Trace: debug all *:Listener: XXX processdata hagent:cmscollector: OK: 12/30/03 14:18:51 XXX queries - last at 12/30/03 14:17:51 XXX collected hforwarder@server_name:sender: OK: 12/30/03 14:18:32 XXX processdata - last at 12/30/03 14:17:32 XXX delivered 266 Software Upgrade and Data Migration May 2009

267 Migrate the Avaya OA historical database 4. If the forwarders are not active, enter: dcrun on cms fwd Migrate the Avaya OA historical database After successfully upgrading the Avaya OA Historical subsystem, the Avaya OA historical server is now in the normal operational mode and you must migrate the historical data from to This section includes the following topics: Prerequisites on page 267 Transfer the Avaya OA historical data on page 267 Migrate the Avaya OA historical RowDate data on page 274 Complete related data migration procedures on page 275 Prerequisites Before you begin the migration, confirm that the following procedures have been completed: Provide enough space for migration on page 267 Disable aggregation recovery on page 267 Provide enough space for migration Verify that enough space has been provided for the migration, which should have been done in Provide space for Avaya OA historical data migration on page 193. Disable aggregation recovery You must disable the Aggregation Recovery using the Administration client as described earlier in Disable aggregation recovery on page 263. Transfer the Avaya OA historical data The procedures in this section describes how to transfer the Avaya OA historical data from the backup tables to the current historical tables. This data was collected before the Historical subsystem was upgraded. Software Upgrade and Data Migration May

268 Chapter 6: Upgrading and migrating from to 6.1.2! Important: Important: Avaya recommends that you back up the historical database now before executing the following steps. If you have a recent full backup, all you need is an incremental backup. To transfer the data from the backup tables to the new tables, several SQL migration scripts must be executed. During the upgrade process, SQL migration scripts are dynamically generated based on whether the historical table existed in the database. For each historical table that requires a schema upgrade in the data model, there is an SQL migration script named table_name.sql that is placed in the %PABASE%\data\admin\ migscripts (Windows) or $PABASE/data/admin/migscripts (Solaris) directory. If the version of the table is empty, the file size of the SQL migration script will be 0. Any scripts with a file size larger than 0 must be used to transfer the historical data for that table. There are three ways to execute the migration SQL scripts to transfer the historical data from backup tables to the new tables. Individually, any of these methods can completely transfer the historical data into the tables. Or, you may use any combination of the three methods to customize the data transfer process. For each SQL data transfer script for the specific historical table, there will be some "time slides" of the RowDate values defined in the script command that make the data transfer database transactions small. If you think the defined time slides can be smaller than the defaults, you can modify the data transfer SQL commands in the SQL script. Avaya recommends that you make a backup copy of the original script before you make any changes to the script. For example, if you have a statement like: insert into... where... and rowdate > and rowdate <= you can split that one statement into two statements: insert into... where... and rowdate > and rowdate <= insert into... where... and rowdate > and rowdate <= This allows you to process a smaller amount of data, if desired. This section includes the following topics: Examples for using the migration scripts on page 268 Method 1: One superscript on page 270 Method 2: One script per data store on page 271 Method 3: One script per table on page 272 Examples for using the migration scripts This section describes how to use the migration scripts using SQL and Oracle. 268 Software Upgrade and Data Migration May 2009

269 Migrate the Avaya OA historical database You must log in as the Avaya OA database user that owns the table that you are migrating or dropping. You cannot use the sa or sys administrator IDs. To run the migration scripts using Oracle: 1. From a command prompt window, change the current directory to one of the following: %PABASE%\data\admin\migscripts on a Windows server $PABASE/data/admin/migscripts on a Solaris server 2. Log in to SQL*PLUS as the Avaya OA database user. For example: sqlplus OA_database_userID/OA_database_userID_pwd 3. Run the scripts from the SQL*PLUS interface. For example: SQLPLUS>@datatransfer.sql To run the migration batch scripts using Microsoft SQL: 1. From a command prompt window, change the current directory to %PABASE%\data\ admin\migscripts. 2. Run the batch file (*.bat) using the following parameters: Database machine name (plus the database instance name, if needed) OA database user name OA database user password OA database name For example, DataTransfer.bat database_server_name[\instance_name] oauser oauserpwd oadb To run the cleanup scripts for dropping tables using Microsoft SQL: 1. From a command prompt window, change the current directory to %PABASE%\data\ admin\migscripts\droptablescripts. 2. Run the script using the following parameters: Database machine name (plus the database instance name, if needed) OA database user name OA database user password OA database name For example, osql -S database_server_name[\instance_name] -U oauser -P oauserpwd -d oadb -i drop_oa602_all_tables.sql Software Upgrade and Data Migration May

270 Chapter 6: Upgrading and migrating from to Some errors may be reported when running the cleanup scripts. If those errors complain that the table is not exist to drop, ignore those errors. As long as all of the x_*, X_*, *_b and *_B tables do not exist in the database, the cleanup scripts are successfully executed. For details about how to use the database vendor tools, please refer to Oracle SQL*PLUS manual for the Oracle SQL*PLUS usage information or Microsoft SQL Server reference for Command Prompt Utilities, osql. Method 1: One superscript There is one superscript that can transfer all of the historical table data. The script is named and located at: DataTransfer.bat under %PABASE%\data\admin\migscripts on a Windows server using the Microsoft SQL database DataTransfer.sql under %PABASE%\data\admin\migscripts on a Windows server using the Oracle database DataTransfer.sql under $PABASE/data/admin/migscripts on a Solaris server using the Oracle database This superscript runs each SQL migration script one after the other. Executing this superscript transfers all of the data collected before the Historical subsystem was upgraded to the historical tables. To run the superscript: For Oracle, use SQL*PLUS under the historical database user's connection. For SQL Server, execute the batch file from a command prompt window. To turn on tracing and error handling while running the script, see Tracing messages and error messages on page 273. Dropping the backup tables: After the superscript has completed successfully, run the drop_oa602_all_tables.sql script to drop all of the backup tables. This script is located at: %PABASE%\data\admin\migscripts\droptablescripts on a Windows server $PABASE/data/admin/migscripts/droptablescripts on a Solaris server You must log in as the Avaya OA database user that owns the table that you are dropping. You cannot use the sa or sys administrator IDs. 270 Software Upgrade and Data Migration May 2009

271 Migrate the Avaya OA historical database Method 2: One script per data store The following historical data stores in an Avaya OA and Avaya IC configuration require schema changes for 6.1.2: AgentState AgentSvcClass SvcClassSummary SvcClassState For each of these data stores, there is a script that calls the data transfer SQL scripts for the historical tables of each data store. Executing these scripts transfers all of the data collected in that data store before the Historical subsystem was upgraded to the historical tables of that data store. These scripts can be executed sequentially or parallel. The scripts are named and located at: data_store_name.bat under %PABASE%\data\admin\migscripts on a Windows server using the Microsoft SQL database (for example, agent.bat) data_store_name.sql under %PABASE%\data\admin\migscripts on a Windows server using the Oracle database (for example, agent.sql) data_store_name.sql under $PABASE/data/admin/migscripts on a Solaris server using the Oracle database (for example, agent.sql) In addition, there is a script called status.bat or status.sql that transfers status table information. To run each script: For Oracle, use SQL*PLUS under the historical database user's connection. For SQL Server, execute the batch file from a command prompt window. To turn on tracing and error handling while running the scripts, see Tracing messages and error messages on page 273. Dropping the backup tables: After the superscript has completed successfully, run the following scripts to drop the backup tables: drop_oa602_oacmsinfo_tables.sql (configurations with CMS) drop_oa602_oaicinfo_tables.sql (configurations with IC) drop_oa602_oaicagentstate_tables.sql (configurations with IC) drop_oa602_oaicagentsvcclass_tables.sql (configurations with IC) drop_oa602_oaicsvcclassstate_tables.sql (configurations with IC) drop_oa602_oaicsvcclasssummary_tables.sql (configurations with IC) Run the following scripts to drop the administration backup tables and status tables: drop_oa602_admin_tables.sql Software Upgrade and Data Migration May

272 Chapter 6: Upgrading and migrating from to drop_oa602_status_tables.sql These scripts are located at: %PABASE%\data\admin\migscripts\droptablescripts on a Windows server $PABASE/data/admin/migscripts/droptablescripts on a Solaris server You must log in as the Avaya OA database user that owns the table that you are dropping. You cannot use the sa or sys administrator IDs. Method 3: One script per table The following historical tables require schema changes in 6.1.2: For any kind of Avaya OA historical server: - hstatus - astatus - dstatus - wstatus - mstatus For an Avaya OA/Avaya IC historical server: - hagentstate, aagentstate, dagentstate, wagentstate, and magentstate - hagentsvcclass, aagentsvcclass, dagentsvcclass, wagentsvcclass, and magentsvcclass - hsvcclassstate, asvcclassstate, dsvcclassstate, wsvcclassstate, and msvcclassstate - hsvcclasssummary, asvcclasssummary, dsvcclasssummary, wsvcclasssummary and msvcclasssummary For each of these historical tables, there is a script that calls the data transfer SQL scripts. Executing these scripts transfers all of the data collected in that historical table, before the historical server was upgraded, from its backup table to the historical table. These scripts can be executed sequentially or parallel. The scripts are named and located at: table_name.sql under %PABASE%\data\admin\migscripts for a Windows server using the Microsoft SQL database (for example, hstatus.sql) table_name.sql under %PABASE%\data\admin\migscripts on a Windows server using the Oracle database (for example, hstatus.sql) table_name.sql under $PABASE/data/admin/migscripts on a Solaris server using the Oracle database (for example, hstatus.sql) 272 Software Upgrade and Data Migration May 2009

273 Migrate the Avaya OA historical database To run each script: For Oracle, use SQL*PLUS under the historical database user's connection. For SQL Server, use OSQL under the historical database user's connection. To turn on tracing and error handling while running the scripts, see Tracing messages and error messages on page 273. Dropping the backup tables: After you have finished running the scripts for each individual table, run the drop_oa602_all_tables.sql script to drop all of the backup tables. This script is located at: %PABASE%\data\admin\migscripts\droptablescripts on a Windows server $PABASE/data/admin/migscripts/droptablescripts on a Solaris server You must log in as the Avaya OA database user that owns the table that you are dropping. You cannot use the sa or sys administrator IDs. Tracing messages and error messages The command prompt window will display any tracing messages while the script runs. If you prefer to save the tracing messages in a file: For Oracle, use the command spool when using SQL*PLUS For SQL Server, use the "-o" option of OSQL To use the "-o" option, you must add the option inside of the batch file. The following is an example of how you would edit the batch file: -- Copyright (C) 2003 by Avaya Inc. All Rights Reserved. -- Usage: SvcClassSummary server_name(\instance_name) logid_id password db_name osql -o <filename1> -S %1 -U %2 -P %3 -d %4 -i hsvcclasssummary.sql osql -o <filename2> -S %1 -U %2 -P %3 -d %4 -i asvcclasssummary.sql osql -o <filename3> -S %1 -U %2 -P %3 -d %4 -i dsvcclasssummary.sql osql -o <filename4> -S %1 -U %2 -P %3 -d %4 -i wsvcclasssummary.sql osql -o <filename5> -S %1 -U %2 -P %3 -d %4 -i msvcclasssummary.sql There should not be any error messages about the duplicated rows reported when executing any SQL script for historical table data transfer the first time (no matter whether you are running it directly, running it from a data store level script, or running it from the superscript). If the script fails for any reason other than the duplicated rows (for example, running out of space on the filegroup or tablespace, or running out of temporary space) or if the script is terminated manually for any reason, run the script again after resolving the problem. Errors concerning duplicated rows are reported for any record already inserted by the last stopped script and should be ignored. Therefore, running the data transfer scripts more than once does not insert any duplicated rows in tables. Software Upgrade and Data Migration May

274 Chapter 6: Upgrading and migrating from to Troubleshooting For any errors that you encounter other than free space problems, escalate to Avaya Technical Support. Migrate the Avaya OA historical RowDate data After successfully transferring Avaya OA historical data, the RowDate data in the archive tables will need to be migrated from the format to the Archive Time Zone format. The oarowdatemig command determines whether there are changes required for the RowDate data, and if necessary, automatically makes those changes. Depending on the customers choice of day definition, they may see their migrated data labeled differently as a consequence of the Archive Time Zone feature. Use the following command to migrate the RowDate data: oarowdatemig.bat -a -v 30 on a Windows server or oarowdatemig.sh -a -v 30 on a Solaris server The oarowdatemig commands are located at: %PABASE%\bin on a Windows server $PABASE/bin on a Solaris server Consider the following when using the oarowdatemig command: To stop the execution of oarowdatemig, you can kill the process of the running instance. Executing oarowdatemig again later with the same option chosen before will continue the RowDate migration work on the archive tables from the terminated point. At any one time, only one oarowdatemig instance is allowed on the historical server. The RowDate migration jobs for historical archive tables are handled in parallel by the oarowdatemig script. The oarowdatemig command will migrate the RowDate data in archive tables once only. If you have already run the oarowdatemig command on an archive table, executing oarowdatemig again will not do anything except report that there is no work left for RowDate migration on this table. The RowDate migration status and the RowDate values range of each historical archive table are stored in a temporary table, OA60ROWDATE. This table is used only by upgrade migration. Do not change the contents of this table. The Day Definition value used by is saved in a temporary table named OA60DAYDEF. This is a table used by upgrade migration only. Do not change the contents of this table. 274 Software Upgrade and Data Migration May 2009

275 Migrate the Avaya OA historical database After the script has completed successfully, manually drop the temporary tables OA60DAYDEF and OA60ROWDATE. See SQL Server Administrator's Guide for SQL or Oracle Administrator's Guide for Oracle for information about dropping tables. For more details on how and why archive date labels may have changed in your system, see RowDate data changes in Avaya OA on page 415. Complete related data migration procedures After migrating the historical data, you must do the following to complete the migration process: Create Avaya IC containers and enable aggregation recovery on page 275 Regenerate custom Cognos cubes on page 275 Collect data from CMS servers on page 275 Create Avaya IC containers and enable aggregation recovery Create new Avaya IC containers for the old historical data and request on-demand aggregation for these containers if you want to view the old data using reports. See the Avaya OA Administration client help for more information about this process. The containers are permanently inactive following migration to To continue aggregating data, new containers must be defined using the Avaya OA Administration client interface. All enabled Avaya IC containers will be retired after the upgrade. You will be able to view the containers, but you will not be able to add any new data or change the tables. The retired containers will appear in the historical Basic report input page 1. For each disabled container, an ampersand (&) character appears next to the container name. This is how user can distinguish the active containers from retired containers. If there were any administratively inactive containers in the system prior to the migration, those containers will also appear with the ampersand symbol. Regenerate custom Cognos cubes All custom Cognos cubes need to be regenerated using the Cognos Transformer as described in Cognos documentation. Collect data from CMS servers This procedure is required only if your configuration has CMS servers. Software Upgrade and Data Migration May

276 Chapter 6: Upgrading and migrating from to Using on-demand collection and aggregation from the Administration client, collect all CMS data from the CMS servers for any interval data that was not collected while the server was being upgraded. This should be done as soon as possible after bringing up the database and servers. Migrate Chat & data The data migration steps in Upgrade your Avaya IC databases to on page 209 automatically transfers the following data from your Avaya IC system to 6.1.2: WebACD Chat & task data messages and message history Chat transcripts and chat history Website authentication data for registered customers Datawake Filters and customer Datawake history Avaya IC Web Management FAQs Avaya IC Web Management configuration data (MultiTenant metadata) response templates The following areas of the Avaya IC Chat & components have changed since and may require reimplementing your personalizations and customizations: Avaya IC Web Management website Java server pages Avaya IC routing hints Chat & workflows (Authentication, Analysis and Routing) Chat client Avaya IC Scripts Avaya IC Web and Management servlet engine (from JRun to Tomcat) To migrate your Chat & data, you should have already: Completed the prerequisites in Prerequisites for migrating all configurations of Avaya IC on page 190. Upgraded your databases, as described in Upgrade your Avaya IC databases to on page 209. To finish migrating your Chat & data, you need to: 1. Run SQL scripts to update the data. For details, see Update Chat & data with the new schema on page Import the migration seed data. For details, see Import new seed data on page Software Upgrade and Data Migration May 2009

277 Migrate Chat & data 3. Reconfigure the databases. For details, see Reconfigure the Chat & database on page Remove the JRun connector filter and disable the JRun servers. For details, see Disable JRun servers and remove JRun connector filters on page Reapply website and workflow customizations. For details, see Reapply your customizations to Chat & on page Copy agent properties and resources. For details, see Migrate Avaya Agent applications on page 284. The final step in the Chat & migration process is to recreate your Chat & servers in your new environment after you have migrated the rest of your Avaya IC data. For details, see Complete the migration process on page 286. Update Chat & data with the new schema You need to run a SQL script to update the migrated Chat & data to conform with the new schema, and to prepare it for the import of the new seed data.! CAUTION: CAUTION: If one of the new Web Management configuration parameters (the website metadata) has the same name as a custom piece of configuration data, errors may occur when importing the seed data. In this case, the new configuration data will not be imported properly. The way you update your Chat & data depends on whether you are using SQL Server or Oracle. SQL Server: To update the Chat & data using SQL Server, use your database utilities to run the SQL statements in IC61_INSTALL_DIR\IC61\migration\ migrate_chat_ _script_mssql.sql against your CallCenterQ database (default name: ccq). Oracle: To update the Chat & data using Oracle, use your database utilities to run the SQL statements in IC61_INSTALL_DIR\IC61\migration\ migrate_chat_ _script_ora.sql against your CallCenterQ database (default name: ccq). Software Upgrade and Data Migration May

278 Chapter 6: Upgrading and migrating from to Import new seed data Avaya IC includes new seed data required by the Avaya IC Chat & servers and by the Avaya IC Web Management application. If you are migrating a localized system, you should perform all of the standard migration tasks and then see Appendix C in IC Installation and Configuration for information about localizing your migrated system. To import seed data: 1. In Notepad or another text editor, open the following file: IC61_INSTALL_DIR\IC61\ design\callcenterq\data\migrate_602_610_seed.cfg 2. Find the DestinationPasswd field and verify that the value is the correct password for the Admin account. 3. Save the migrate_602_610_import_seed.cfg file. 4. Run the seed migration import BAT file IC61_INSTALL_DIR\IC61\design\ CallCenterQ\data\migrate_602_610_import_seed.bat. 5. If you are using a localized version of Avaya IC, you need to import the localized seed data by running the localized seed migration import BAT file IC61_INSTALL_DIR\IC61\ design\callcenterq\data\ migrate_602_610_import_seedl10n.bat. Reconfigure the Chat & database After importing the seed data, you need to reconfigure the CallCenterQ database. To do so: 1. Start Database Designer and open your CallCenterQ ADL file (IC61_INSTALL_DIR\ IC61\design\CallCenterQ\ccq.adl). 2. Select File > Database Administration. 3. Select defaultdbconnectionset from the DB Connection Set list. 4. Select the Reconfigure option button. 5. If necessary, enter your IC Manager username and password in the appropriate fields. (Do not enter your DBA username and password.) 6. Select Run. 7. When the reconfigure has finished, select Close. 8. Close Database Designer. 278 Software Upgrade and Data Migration May 2009

279 Migrate Chat & data Install and configure Web Management At this point, all of your Chat & data has been migrated, and you can install and configure the rest of the Chat & components as described in Chapter 8 of IC Installation and Configuration. After you have finished the basic set up, you need to reapply any customizations you made to your system. Before you can make any changes to the metadata, you need to run the Web Configuration Tool as described on pages of IC Installation and Configuration. Make sure that you specify the path to the JDK _06 install on your local drive so that your system makes the proper connection to the metadata and pdm files. Reapply your customizations to Chat & After you have finished setting up Web Management for 6.1.2, you need to reapply any customizations you made to your system. The following sections describes how the changes to Avaya IC may affect your customizations. For a description of the changes in the workflows, see Avaya IC workflow changes on page 405. Website Java server page changes The following Avaya IC Web Management Website Java Server Pages have been updated between and 6.1.2: /public/acknowledge.jsp /public/error.jsp /public/escalate.jsp /public/include/checkuser.jsp /public/include/diagwin.jsp /public/include/footer.jsp /public/include/header.jsp /public/include/validate.jsp /public/include/validateescalate.jsp /public/joinus.jsp /public/showsurvey.jsp /public/wru.jsp /public/wrusearch.jsp /public/xsl/grouping.xsl In addition many of the pages in the /admin directory have also been updated. Java Server Pages from Avaya IC should not be used with All customizations made to pages must be reapplied to the versions. Software Upgrade and Data Migration May

280 Chapter 6: Upgrading and migrating from to Website home, finish, and wrap (survey) page changes The Avaya IC Web Management configuration data (metadata) for the home, finish, and wrap (survey) pages has changed in If your pages use the default settings, you need to make the following changes to match the out-of-the-box pages: Metadata Default Default website.pages.home / /public website.pages.finish / /public chat.webpops.wrapurl showsurvey.jsp showsurvey.jsp?$encodedparms$ To do so: 1. Open IC Manager and select Services > MultiTenancy Administration. IC Manager opens the web-based IC Website Administration Tool and displays the Welcome to the Interaction Center Website Multi-Tenant Administration page. 2. Select Tenant Properties in the Tenant Admin menu. 3. Select the tenant you want to customize from the Select a Tenant drop-down list, and then select the Customize Tenant button. The IC Website Administration Tool displays the Customize Tenant page. 4. Select the language properties you want to set from the Select Language drop-down list at the top of the page. 5. Select All Properties. The IC Website Administration Tool displays all of the tenant s properties, sorted alphabetically. 6. Make the changes to the metadata properties listed in the chart above. 7. Make any other changes you would like to make to the metadata. 8. When you are finished, select Update Data at the bottom of the page. For information about changing the Avaya IC Web Management configuration data, see "Customizing tenant websites" starting on page 48 of IC Administration Volume 2: Agents, Customers, & Queues. ICM Web Pop changes Prior to 6.1.2, all contact data associated with a chat was appended to the end of all ICM Web Pops as query parameters. Out-of-the-box, this functionality was used in the Page Push feature of the Avaya IC Chat On Hold treatment, and when the WrapURL was pushed to a chat customer s browser at the end of a chat. For 6.1.2, these query parameters are not automatically added. If you want to restore this functionality, you need to append the $ENCODEDPARMS$ template variable to the end of any web pop URL. 280 Software Upgrade and Data Migration May 2009

281 Migrate Chat & data For example: showsurvey.jsp?$encodedparms$ If specific contact data parameters are required, then they need to be specified in the URL as well. For example, if you want to append the EDUID and the tenant, the web pop URL would be: mypage.jsp?eduid=$eduid$&tenant=$aictenant$ If you want Avaya IC to append the contact data automatically the way it did in 6.0.2: 1. Add the following configuration parameter to the ICM bootstrap configuration file IC61_INSTALL_DIR/IC61/etc/systemParms.txt: AddWebPopParms=true 2. Restart the ICM service. Chat client changes The Avaya IC Chat Client and Chat Client template files have been updated from to Modifications to the Chat Client applet template files need to be migrated to the template files. In addition, although the updated chat client applet should be downloaded automatically by end users who have previously downloaded the client, it is possible that the ActiveX control used to enable Shared Browsing will not be compatible with This section shows which template files have changed and also provides a solution for cleaning end user machines of chat client components. The following Chat Client template files have been updated: IC61_INSTALL_DIR/IC61/comp/icm/default/callercl.txt IC61_INSTALL_DIR/IC61/comp/icm/default/callerap.txt IC61_INSTALL_DIR/IC61/comp/icm/ibm/callercl.txt To remove chat client files from an end user machine (Internet Explorer only): 1. Stop all instances of Internet Explorer on the Client Machine. 2. Check the currently running processes list to ensure no instances of "iexplore.exe" are running. 3. Remove the following Interaction Center applet files: C:\WINNT\Java\lib\com\avaya\icm\applet\IEComClient.class - or - C:\Windows\Java\lib\com\avaya\icm\applet\IEComClient.class 4. Remove the Interaction Center collaboration dll files: a. Open a command prompt and navigate to: C:\WINNT\Downloaded Program Files - or - C:\Windows\Downloaded Program Files Software Upgrade and Data Migration May

282 Chapter 6: Upgrading and migrating from to b. Execute the following commands: regsvr32 -u iecom.dll del iecom.dll del setup.inf Migrate your Content Analyzer data If your Content Analyzer Knowledge Bases can be accessed through the same fully-qualified file path by the new servers as was used by your old servers, then all you need to do is bring up the Avaya IC system, recreate your Content Analyzer servers in the environment, and make sure that Content Analyzer works as expected. The recommended installation directory for your Knowledge Bases is: C:\Program Files\Avaya\kbs (Windows)../opt/Avaya/kbs (Unix) If you need to move the Content Analyzer Knowledge Bases relative to the servers: 1. Make sure that all of the Knowledge Bases you identified in Prerequisites for migrating Content Analyzer on page 185 are stored in a directory on a machine that is accessible to any server machine that will be running a CAAdmin or CAServer server. Make a note of all the Knowledge Base names and file locations. If appropriate, consult your Content Analyzer Administrator for the approved location of the Knowledge Base files. 2. If you want to change any of your Knowledge Base file names, you should do so at this point. Make sure that you make a note of the old and new filenames so that you can change the File Location information when you configure the associated CAServer.! Important: Important: Do not change the Knowledge Base name during the migration process. Any such changes should be done through IC Manager once the system is up and running. 3. In the CallCenterQ database, change the file names and locations in the knowledgebase database table to reflect the new names and locations for your Knowledge Bases. To do so, run the following database-specific SQL script for each of the migrated Knowledge Bases. For SQL Server: 1. Open the SQL Server Query Analyzer. 282 Software Upgrade and Data Migration May 2009

283 Migrate your Content Analyzer data 2. Connect to the appropriate CCQ database. 3. Run the following SQL script for each of the renamed or moved Knowledge Bases: For Oracle: USE ccq UPDATE knowledgebase SET knowledgebase.kbfilepath = 'Full_Destination_KB_Path' WHERE knowledgebase.name = 'KB_Name' AND knowledgebase.kbfilepath = 'Full_Source_KB_File_Path' Where Full_Destination_KB_Path is the fully-qualified location of the Knowledge Base (including the file name), KB_Name is the Knowledge Base name, and Full_Source_KB_File_Path is the fully-qualified name of the corresponding Knowledge Base. (Do not change the quotation marks.) 1. Open an SQL Plus Worksheet. 2. Connect to the appropriate Oracle Avaya IC database. 3. Run the following SQL Plus script for each of the renamed or moved Knowledge Bases: UPDATE ccq.knowledgebase SET knowledgebase.kbfilepath = 'Full_Destination_KB_Path' WHERE knowledgebase.name = 'KB_Name' AND knowledgebase.kbfilepath = 'Full_Source_KB_File_Path'; COMMIT; Where Full_Destination_KB_Path is the fully-qualified location of the Knowledge Base (including the file name), KB_Name is the Knowledge Base name, and Full_Source_KB_File_Path is the fully-qualified name of the corresponding Knowledge Base. (Do not change the quotation marks.) Verifying the new Knowledge Base file locations To make sure that your changes are accurate, run the SQL statements shown in Determining the training and validation information for your Knowledge Bases on page 188. The entries in the KB File column should match the new locations and names for your Knowledge Bases. Software Upgrade and Data Migration May

284 Chapter 6: Upgrading and migrating from to Migrate Avaya Agent applications The way you migrate your Avaya Agent applications depends on whether you chose to install the Avaya Agent applications with your Avaya Agent applications as described in Install the Avaya Agent applications on page 202. If you have not installed your Avaya Agent applications: 1. Log on to each agent machine using a Logon ID with Administrator privileges. 2. Run the agent installer that you created in Create the Avaya Agent application installer on page Migrate the agent resources as described in Migrating Agent resources on page If desired, after you have migrated the agent resources you can uninstall the Avaya Agent application. Repeat this procedure for each Avaya Agent application machine. If you have already installed your Avaya Agent applications on your agent machines: 1. Log on to each agent machine using a Logon ID with Administrator privileges. 2. Reset VTel so that it uses the configuration files and ignores To do so, run the IC61_INSTALL_DIR\IC61\migration\vtelreg61.bat file. 3. Migrate the agent resources as described in Migrating Agent resources on page If desired, after you have migrated the agent resources you can uninstall the Avaya Agent application. Repeat this procedure for each Avaya Agent application machine. Migrating Agent resources Local (and locally-stored Global) Web Agent Chat & resources, agent preferences, attachments, and drafts can be migrated from to by copying files from the agent's Webagent directory to the new Avaya IC Webagent directory. Before logging into the Avaya Agent for the first time: To migrate the agent preferences, drafts, and locally-stored resources, copy the entire IC602_INSTALL_DIR\IC60\Webagent\agents directory to IC61_INSTALL_DIR\ IC61\Webagent. To migrate any global resources, copy the IC602_INSTALL_DIR\IC60\Webagent\ GlobalResources.xml file to IC61_INSTALL_DIR\IC61\Webagent. 284 Software Upgrade and Data Migration May 2009

285 Migrate the Report Wizard application Contact form To migrate any attachments that are associated with the global agent resources, copy the entire IC602_INSTALL_DIR\IC60\Webagent\Attachments directory to IC61_INSTALL_DIR\IC61\Webagent. Make sure that you have renamed your CDL files and set the new Avaya Agent application properties as described in New naming strategy for Avaya Agent layout files on page 201. Migrate the Report Wizard application Contact form In 6.1.2, the Report Wizard Contact(Routing) form is now called Contact. When you migrate the application ADL, FixDesignFiles.exe adds the new Contact form to the application and migrates the Contact(Routing) form into If you have not customized the Contact(Routing) form, then you can simply delete that form from the Report Wizard application. If you have customized the Contact(Routing) form, you should use Database Designer to reapply your customizations to the new Contact form and then delete the old Contact(Routing) form. That way, your application form names will match the out-of-the-box form names and make future migrations easier. Additionally, the out-of-the-box Customer form no longer includes the econtact Web Login group. In order to keep this form aligned with the out-of-the-box version, you should delete that group using Database Designer. For details about editing applications with Database Designer, see the IC Database Designer User Guide. Migrate WebQ WebQ in is backwardly compatible with WebQ in Simply regenerate your WebQ pages after you have migrated your other applications. Avaya does not recommend making any customizations to your generated WebQ HTML pages. All customizations should be done using the ADL. If, however, you have customized your HTML pages, you will need to reapply those customizations after you regenerate. Software Upgrade and Data Migration May

286 Chapter 6: Upgrading and migrating from to Complete the migration process To finish the migration process: 1. Push all of the workflows that you updated on your test system to the database using the Workflow Designer. For more information on pushing your workflows, see Loading Workflows in the Workflow Server on page 66 in the Avaya Workflow Designer User Guide. For more information about testing your workflows, see Migrate IC Scripts, workflows, and Avaya Agent files on page If you are using the Outbound Contact feature, migrate the mcscon.ini file. For details, see Migrating mcscon.ini on page If you are using Content Analyzer, make sure that your Knowledge Bases migrated properly. For details, see Verify Content Analyzer migration on page If you are using QKnowledge, you need to copy your document collections and reindex them using IndexQ. For details, see Migrate QKnowledge on page Migrate the contact-related data as described in Migrate contact data on page If you turned off any virus scan software before you started the upgrade and migration, turn this software back on. Migrating mcscon.ini The mcscon.ini file is a configuration file for the Avaya IC Softphone that is included in the initial installation of Avaya IC if the Softphone functionality is selected. (For details, see Appendix B in IC Administration Volume 1: Servers & Domains.) To migrate this configuration file: 1. Make a backup copy of the Avaya IC mcscon.ini file, located in the IC602_INSTALL_DIR\IC60\etc directory on the machine on which the DialingKernel server is running. 2. Compare the mcscon.ini file with the mcscon.ini file, located in the IC61_INSTALL_DIR\IC61\etc directory on the machine on which the DialingKernel server is installed. 3. Modify the mcscon.ini file so that the following fields match the file: LoginName PredictiveRoutePoint PredictiveDropPoint LOCALFORMAT INTERLOCALFORMAT 286 Software Upgrade and Data Migration May 2009

287 Complete the migration process INTERNATIONALFORMAT SYSTEMAREA SYSTEMCOUNTRY 4. Set the Password parameter to dialer1 so that it matches the password you specified in Dialing Kernel server changes on page Reapply any customizations you made to the mcscon.ini file to the mcscon.ini file. 6. Save the mcscon.ini file. 7. If the DialingKernel server is already running, you will need to use IC Manager to stop and then restart it. Verify Content Analyzer migration Once you have installed your servers, you need to configure your CAAdmin and CAServers. To do so: 1. In IC Manager, select the Server tab and then select All Domains in the left-hand pane. 2. For each CAAdmin and CAServer that you identified in Determining the current Content Analyzer server settings on page 187, make sure that you have a corresponding server. Use the screenshots you created to configure the CAAdmin and CAServer servers. 3. For the CAServers, make sure that the KB Location parameter matches the location of your Knowledge Bases, as shown in the KB File column in the report you generated in Verifying the new Knowledge Base file locations on page When you have finished configuring all of your CAAdmin and CAServer servers, you can verify the integrity of your Content Analyzer Knowledge Bases, as described below. Verifying the integrity of your Content Analyzer Knowledge Bases To verify the integrity of the Content Analyzer Knowledge Bases after you complete the migration process: 1. In IC Manager, select Tools > Content Analysis. 2. Make sure that the Content Analyzer data matches what you observed in Determining the current Content Analyzer data on page 186: a. Select KB Management in the left-hand pane and make sure that the Knowledge Bases listed in the right-hand pane match the list of Knowledge Bases. b. Select Topic Tree Management in the left-hand pane and make sure that the topic trees are the same as the topic trees. Software Upgrade and Data Migration May

288 Chapter 6: Upgrading and migrating from to c. Select Sample Management in the left-hand pane, and then select the Remove Samples tab in the right-hand pane. Open the Sample Set drop-down list and compare the sample set names to the sample set names. 3. Validate each one of your Knowledge Bases using the associated sample set. The results you achieve should be similar to the results you saw in 6.0.2, but there may be small changes due to enhancements to the product that were made in (For details, see "Validating a Knowledge Base" starting on page 107 of IC Administration Volume 1: Servers & Domains.) Migrate QKnowledge To migrate QKnowledge: 1. Configure the QKnowledge Server and start IndexQ. For more information, see Chapter 6 in IC Administration Volume 2: Agents, Customers, & Queues. 2. Copy all external documents (maintaining their directory structure) from the old machine to your new machine and recreate your document collections. 3. Index the collections using IndexQ. Migrate contact data The following contact-related data model changes have been made between and 6.1.2: abandon_time and abandon_flag fields: The abandon_time field has moved from the mediainteraction table to the mediasegment table. The abandon_flag field has been renamed the abandoment_state field and moved to the mediasegment table. The enumeration values have changed for this field as well. The following table shows the differences between and 6.1.2: abandon_flag field Enumeration abandonment_state field Enumeration handled 0 Not migrated to while ringing 1 alerting 3 while in queue 2 queued 2 while on hold 3 inactive 4 other 4 Not migrated to Software Upgrade and Data Migration May 2009

289 Complete the migration process 1. If a record in has the abandon_flag field set to handled or other, the corresponding abandonment_state field will be empty in Mediainteraction type and direction to mediadirectionmask: For reporting purposes, the type and direction fields in the mediainteraction table are now being combined into the denormalized mediadirectionmask field in the contact table. This new field is a bitmap created from the combination of type and direction, as shown below: b8 b7 b6 b5 b4 b3 b2 b1 voice inbound voice outbound inbound outbound chat inbound chat outbound The final value in the mediadirectionmask field is the logical OR of the type and direction pairs from all of the mediainteraction records linked to the contact. For example, if the contact has only one associated type and direction, the value placed in the mediadirectionmask would be: Type Direction mediadirectionmask value Chat Voice outbound inbound outbound inbound outbound inbound Routingevent type and direction to activemediamask: For reporting purposes, the type and direction fields in the routingevent table are now being combined into the denormalized activemediamask field in the routingevent table. The values for the new activemediamask field are generated using the same bitmap and logical OR procedure as described above for the mediadirectionmask field. The final value in the routingevent activemediamask field is the logical OR of the type and direction pairs from all of the mediainteraction records (typically only one) linked to the routingevent. Migration script files Two migration script files, dbmigrateinfo.sql and dbmigrate.sql, provide a set of SQL scripts that migrate the data as explained above. The commands in both files are identical except that the commands in dbmigrateinfo.sql only count the number of records that will be migrated and the command in dbmigrate.sql actually update the records. Software Upgrade and Data Migration May

290 Chapter 6: Upgrading and migrating from to You should run the statements in dbmigrateinfo.sql first so that you can estimate how long the actual migration will take. To migrate your non-critical data: 1. Open the IC Repository database in your database administration tool. 2. Open IC61_INSTALL_DIR\IC61\migration\dbmigrateInfo.sql in an ASCII editor such as Notepad. 3. Run the SQL commands in dbmigrateinfo.sql script one by one. Keep track of the count returned for each SQL command, and use that information to plan when you want to migrate the actual data. 4. When you are ready to perform the migration, open IC61_INSTALL_DIR\IC61\ migration\dbmigrate.sql in an ASCII editor such as Notepad. 5. Run the SQL commands in dbmigrate.sql script one by one in the order they appear in that file. CAUTION:! CAUTION: You must execute these commands in the exact order as they appear in dbmigrate.sql. If you run them out of order, you may corrupt the data in those fields. Back up your databases and server files Once you have tested your environment, Avaya strongly recommends that you: Create full backups of all your Avaya IC databases using your database administration tools. Backup the final versions of IC61_INSTALL_DIR\IC61\etc\ds.ffd and IC61_INSTALL_DIR\IC61\etc\vesp.imp so that you can restore your server settings at a later date. Back up the Avaya OA historical database. For details about backing up your database, see your database documentation. Put into production At this point, you can start your Avaya Agent applications and put your system into production. 290 Software Upgrade and Data Migration May 2009

291 Moving to Business Advocate Moving to Business Advocate If you want to start using Business Advocate with your newly-migrated system, you can install and configure it as described in the following documents: IC Installation and Configuration IC Business Advocate Configuration and Administration Avaya Operational Analyst Release 6.1 Installation and Configuration (for installation and configuration of the EC-Bridge subsystem) There are no migration-specific steps you need to perform in order to add Business Advocate to your system. Restoring If the migration fails and you want to restore your system, you need to: 1. Stop all of your servers and services, including Tomcat. 2. Restore your databases from the backups you made in Back up your databases on page If you switched over to the Avaya Agent applications, you need to reset VTel on each Avaya Agent application machine by: a. Logging on to each agent machine using a Logon ID with Administrator privileges. b. Running the IC61_INSTALL_DIR\IC61\migration\vtelreg602.bat file. 4. Restart your servers and services, including JRun. 5. If you installed Hummingbird, you need to change the connector services so they point to your installation instead of your installation. To do so: a. Stop all Hummingbird connector services for b. From the administration machine, copy IC61_INSTALL_DIR\IC61\bin\ HBUnInstall.61.bat and HBInstall.60.bat to the primary server machine. c. On the primary server machine, run HBUnInstall.61.bat to uninstall the Hummingbird services. d. On the primary server machine, run HBInstall.60.bat to install the Hummingbird services. e. Repeat this procedure for each server machine that is running a Hummingbird connector. 6. Restart your Avaya Agent applications. Software Upgrade and Data Migration May

292 Chapter 6: Upgrading and migrating from to Use the backup created in Filesystem backup for Avaya OA on page 240 to restore the filesystem where Avaya OA was installed and the filesystem where the OS was installed. 292 Software Upgrade and Data Migration May 2009

293 Chapter 7: Upgrading Avaya Interaction Center from 6.0 to This chapter contains information that helps you upgrade from Avaya Interaction Center (Avaya IC) from 6.0 and to release If you are migrating from Avaya IC 5.6 SP1 or earlier, see Chapter 8: Migrating from Avaya IC 5.6 SP1 to on page 299. If you are upgrading from 6.0 or to 6.0.2, your customized websites, IC Scripts, and workflows will continue to work. However, Avaya recommends that you reapply your customizations to the out-of-the-box files in order to take advantage of the bug fixes included in To make this process easier, the following procedure notes which IC Script, workflow, and website files have changed in both and Tip: Tip: If you are upgrading from 6.0, you should reapply your customizations to all of the files listed. If you are upgrading from 6.0.1, you only need to reapply your customizations to the files changed in To upgrade from 6.0 or to 6.0.2: 1. Stop the entire Avaya IC system (all clients and all servers on all machines that host parts of the IC system). 2. If desired, make a backup of your IC_INSTALL_DIR/IC60/etc directory so that you do not accidentally overwrite your vesp and ds.ffd files. 3. Install over your current Server and Design/Admin installation(s). All of the design directories installed during the product installation (CallCenterQ, common, CustQ, hrq, and so on), and the files in them, are backed up as subdirectories beneath IC_INSTALL_DIR/IC60/backup/design. The upgrade then installs new versions of the files in the design directories. In addition, the installation program backs up the entire website directory to IC_INSTALL_DIR/IC60/backup/website. Tip: Tip: After the installation is finished, the program asks if you want to run the Configuration Tool. If you are installing over an old 6.0 or installation, you do not need to do this. 4. If you have customized your ADL and ADF files, copy the customized versions, along with the associated ALM and ADC files, back to the standard IC_INSTALL_DIR/IC60/ design/<appname> directory from the associated backup directory created by the installation program. Software Upgrade and Data Migration May

294 Chapter 7: Upgrading Avaya Interaction Center from 6.0 to Bug fixes were made to some IC Scripts in both and While you can copy other customized IC Scripts from the IC_INSTALL_DIR/IC60/backup/ design/<appname> subdirectory into the appropriate design directory, you should reapply your customizations to these out-of-the-box IC Scripts in order to take full advantage of the bug fixes in IC Scripts Changed in IC Scripts Changed in ccq.qsc custq.qsc hrq.qsc qrepository.qsc AddressUpdate.qsc ccq.qsc CopyPriceCatalog.qsc CrossSell.qsc FindCreditCard.qsc FulfillmentItemCellChange.qsc FullTextSearch.qsc PromotionTest.qsc RequestPostUpdate.qsc 294 Software Upgrade and Data Migration May 2009

295 6. The following workflows have changed in and If you have customized any of these files, you will need to reapply your customizations to the new out-of-the-box versions and then upload the new flows to the database. Otherwise, you can copy your other customized workflows back into the appropriate workflow directory under IC_INSTALL_DIR/IC60/design/IC/Flows/Avaya/. Workflow Files Changed in Workflow Files Changed in Files in Flows/Avaya/blender: initialization.qfd state.qfd Files in Flows/Avaya/IC outboundnoca.qfd Files in Flows/Avaya/ Sys_Agentsearch: agentsearch.qfd cleanup_global_cache.qfd fetch.qfd start.qfd stop.qfd update_agentstate_cache.qfd Files in Flows/Avaya/Sys_Transfer: transfertovq.qfd update_vq_cache.qfd Files in Flows/Avaya/blender: blender.prj clientlogin.qfd SymDictionary.txt Files in Flows/Avaya/DocGen: enctmpl.qfd Files in Flows/Avaya/IC analyzeca.qfd analyzenoca.qfd ic .prj outboundca.qfd Files in Flows/Avaya/TS: incoming_ivchat.qfd incomingcall.qfd ts.prj Files in Flows/Avaya/wacd: qualifychat.qfd qualify .qfd Software Upgrade and Data Migration May

296 Chapter 7: Upgrading Avaya Interaction Center from 6.0 to The following website files have changed in and If you have customized any of these files, you will need to reapply your customizations to the new out-of-the-box versions. Otherwise, you can copy the other customized website files back into the website directory. Website Files Changed in Website Files Changed in Language specific resources /error/publicerrormessages_de.properties /error/publicerrormessages_es.properties /error/publicerrormessages_fr.properties /error/publicerrormessages_it.properties /error/publicerrormessages_ja.properties /error/publicerrormessages_ko.properties /error/publicerrormessages_pt.properties /error/publicerrormessages_zh.properties Language specific resources /error/publicerrormessages_de.properties /error/publicerrormessages_es.properties /error/publicerrormessages_fr.properties /error/publicerrormessages_it.properties /error/publicerrormessages_ja.properties /error/publicerrormessages_ko.properties /error/publicerrormessages_pt.properties /error/publicerrormessages_zh.properties JSPs Because of changes to the Java beans, all JSP files should be re-customized. JSPs Because of changes to the Java beans, all JSP files should be re-customized. FAQ Stylesheets /public/xsl/display.xsl /public/xsl/grouping.xsl /public/xsl/href.xsl /public/xsl/search.xsl FAQ Stylesheets /public/xsl/display.xsl /public/xsl/grouping.xsl /public/xsl/href.xsl /public/xsl/search.xsl Readmes /sametime/sametimenotes.txt Readmes /sametime/sametimenotes.txt 8. Run the upgrade on all machines that host Avaya IC servers or Design/Admin software. 9. In order to set up the Notification server, register..ic60\bin\emsmtp.dll. 10. Restart all Avaya IC servers. Tip: Tip: The first time you run IC Manager, the program puts you into the Configuration Tool wizard if you did not run that tool after you installed It is safe to exit the Configuration Tool without going through the configuration process. When you restart IC Manager, everything should work as expected using your old configuration. 11. Regenerate your client applications, making sure that you push all IC Scripts to the database. 296 Software Upgrade and Data Migration May 2009

297 12. If you have customized any of the workflows, make sure that you recompile them and upload them to the database. 13. To upgrade your Avaya Agent installations: a. Upgrade the Agent Installer. b. Run the Site Preparation Wizard. c. Run the Agent Installer for every Avaya Agent application machine. (You do not need to uninstall the old Avaya Agent first.) CAUTION:! CAUTION: You should upgrade all servers and all Avaya Agent applications before you run any of them. (In other words, you should never run a mixture of 6.0 (or 6.0.1) and servers and/or Avaya Agent applications.) Software Upgrade and Data Migration May

298 Chapter 7: Upgrading Avaya Interaction Center from 6.0 to Software Upgrade and Data Migration May 2009

299 Chapter 8: Migrating from Avaya IC 5.6 SP1 to This chapter contains information that helps you migrate from Avaya Interaction Center (Avaya IC) 5.6 SP1 to Avaya IC The purpose of the migration process is to: Move your 5.6 SP1 data (including application and chat and data) into new databases that match the out-of-the-box database schema. Merge your customized client application (ADL) files with the new features provided in so that you can take advantage of the new features while retaining your customizations. If you have an earlier release of the Quintus econtact Suite, you must first migrate from that release to Avaya IC 5.6 SP1, and then migrate from that to Avaya IC For an overview of the migration path from older versions, see the appropriate chapter. There have been several name changes in that are relevant to migration: Old Name econtact Agent econtact Manager Fulcrum QDesigner QRepository database (default database name qrepository) QWorkflow Designer New Name Avaya Agent IC Manager Hummingbird Database Designer CI Repository database (default database name: repository) Workflow Designer For a complete list of name changes, see the readme.htm file on the Avaya IC product CD. The default base installation directory has changed from C:\Quintus to C:\ Program Files\Avaya. In this manual, the 5.6 SP1 installation directory will be called QeS_INSTALL_DIR and the installation directory will be called IC_INSTALL_DIR. Software Upgrade and Data Migration May

300 Chapter 8: Migrating from Avaya IC 5.6 SP1 to In addition, Real Time Monitoring has been replaced by Avaya Operational Analyst. Because of the design changes in 6.0.2, some of the 5.6 SP1 reports no longer apply and have been removed. These reports are: ActivityForAllTaskTypes.imr DailyActivityForTaskTypeX.imr DailyActivityForWebACD.imr TasksForAgentX.imr TasksForTaskTypeX.imr TaskTypeXActivityOnDayY.imr TeamPerformanceByTaskType.imr WebACDActivityOnDayX.imr The following terminology changes affect reporting: Old Name tasktype task team New Name queue chat or contact workgroup For details about using Operational Analyst or the out-of-the-box reports, see the Advanced Reporting Tools Guide. Overview of the migration process During the Avaya IC migration process, you will: Complete the Avaya IC installation and begin configuration. Modify the ADL files for your existing applications. Create a new CI Repository database from the provided CI Repository ADL. Rebuild your application databases. Transfer data among your existing application databases into the new CI Repository database. Update the migrated data in the CI Repository database to match new schema and import CI Repository migration seed data. Apply chat and migration scripts to update migrated data in CCQ and import migration seed data for CCQ. Complete Avaya IC configuration. Manually reapply necessary chat and customizations. Migrate agents desktops and agent resources. 300 Software Upgrade and Data Migration May 2009

301 To accomplish these changes, the Avaya IC migration provides: Detailed steps that will guide you through the migration process. A tool for modifying the underlying ADL and ADF files (defining the database schema and forms) for the product. For details about what has changed in the database in 6.0.2, see Data schema changes in on page 355. A customizable database migration tool that takes data from the 5.6 SP1 databases and places it in the appropriate fields in the new data schema. Scripts for updating migrated data to match the new schema and importing migration seed data. A tool for migrating agent resources. The migration process can be divided into three parts: Part A. Create compatible physical databases with your 5.6 SP1 database schema. Part B. Add your 5.6 SP1 data to your new databases. Part C. Migrate your data and the rest of your 5.6 SP1 customizations into your databases. Software Upgrade and Data Migration May

302 Chapter 8: Migrating from Avaya IC 5.6 SP1 to These three parts are summarized in the following diagram: Migration prerequisites The Avaya IC installation supplies tools to migrate your Avaya IC 5.6 SP1 components. Before you use these tools, however, you need to do several things manually. The migration process assumes that you are starting with 5.6 SP1. If you have not upgraded to 5.6 SP1, you need to do so before you migrate your system to Software Upgrade and Data Migration May 2009

303 Migration prerequisites Some of the tasks depend on whether you have Avaya Business Applications installed. Do those tasks first, then do the tasks that apply to the entire Avaya Interaction Center suite. For details, see: Prerequisites for migrating Business Applications on page 303 Prerequisites for all configurations of Avaya IC 5.6 SP1 on page 303. CAUTION:! CAUTION: The procedures in this manual require to manipulate your company s databases using your database administration tools. Before you attempt any of the procedures in this manual, you should be familiar with using those tools. While this manual does try to help you determine which commands you want to run, these steps should be viewed as examples only, and you should rely on your database documentation to make sure you are running the correct tool to perform the required task. In addition, you should plan your migration strategy very carefully, and be fully aware of the structure of your 5.6 SP1 database and any customizations that were made to your 5.6 SP1 system. Prerequisites for migrating Business Applications You can migrate your CallCenterQ (CCQ), HRQ, or CustomerQ Business Application to Avaya IC Before you use the migration tools, you need to backup the following components: Your entire design directory and all its subdirectories (default location: C:\Quintus\ QeS56\design) Underlying databases (as applicable), using your database administration tools: - Application (for CCQ, CustomerQ, and/or HRQ) - Repository (CI Repository) QKnowledge data directories containing index files from QeS_INSTALL_DIR\fulcrum\ fultext directory. QKnowledge collectionname.cfg files from QeS_INSTALL_DIR\fulcrum\ fultext directory. Prerequisites for all configurations of Avaya IC 5.6 SP1 Avaya IC and 5.6 SP1 cannot co-exist on the same machine because they use the same environment variable to determine the location of the Avaya IC installation directory. Software Upgrade and Data Migration May

304 Chapter 8: Migrating from Avaya IC 5.6 SP1 to Avaya recommends that you install the Avaya IC servers and design tools on a clean machine (instead of installing them on top of 5.6 SP1). In addition, you should uninstall the 5.6 SP1 client from an end-user s machine before you install the upgraded client. If you are using the Web Management component for Chat or and you elect to install your servers on a new machine, you need to perform the steps in Prerequisites for installing the web and servers on a new machine on page 307. Verifying Oracle UTF8 settings If you have an Oracle database, the NLS_NCHAR_CHARACTERSET and NLS_CHARACTERSET parameters must be set to UTF8. To check this, use the SQL statement: select "SYS"."NLS_DATABASE_PARAMETERS"."PARAMETER", "SYS"."NLS_DATABASE_PARAMETERS"."VALUE" from "SYS"."NLS_DATABASE_PARAMETERS" If the NLS_NCHAR_CHARACTERSET and NLS_CHARACTERSET parameters are not set to UTF8, you need to: 1. Export your Oracle data in UTF8 format. 2. Drop your Oracle database. 3. Recreate your Oracle database, specifying UTF8 for the Character Set and National Character Set parameters. 4. Import your data into the new database. For details about changing the character set after you create your database, see your Oracle documentation. Verifying disk space During this migration process, you will make a copy of your 5.6 SP1 databases. Make sure that you have enough disk space available for this task. Changing agent login IDs Avaya IC does not allow underscore character (_) in the agent login ID. (This ID is stored in the loginname field in the employee table.) If you migrate any agent name with that character and then attempt to set the agent properties in the IC Manager, IC Manager will display an error and you will have to change the agent login ID at that point. Avaya recommends that you use one of your database utilities to remove the underscore from your agent login IDs before you migrate them. 304 Software Upgrade and Data Migration May 2009

305 Migration prerequisites Verifying site migration During the migration process, all of the sites in the queue table are copied to the site table. Any site that does not exist in one of the queues will not be migrated. If a group of agents is assigned to a site that is not associated with any chat, , or voice queue, you need to create a queue for them before you migrate so that this site will be properly migrated along with all the others. Migrating DS Table information If you want to save your current DS Table information so that you can reimport it into the new database, you need to export it from the 5.6 SP1 IC Manager. You should: 1. Open the 5.6 SP1 IC Manager. 2. Select the DS Table tab. 3. Select DS Table > Export. 4. Save the file and make a note of its name and location. After you have migrated your 5.6 SP1 system, you can import this information into by selecting DS Tables (5.6) > Import from the IC Manager DS Tables (5.6) dialog box. Installing the migration files and creating migration folders The following steps install the migration files and set up the basic system folders you will need during the migration process: 1. Make sure that your database administration tools are accessible and properly installed. For details, see your database documentation. 2. Begin installing Avaya IC on a clean system using the information in the IC Installation and Configuration Guide. Once you have configured the Data Connector server as described in the "Configuring the Data Connector Server" section of that manual, stop the installation process and return to these instructions. 3. If you want to save a copy of the out-of-the-box files for future reference, create a backup by copying the entire IC_INSTALL_DIR\IC60\design directory into a backup directory such as IC_INSTALL_DIR\IC60\migration\60files. 4. Before you can merge your 5.6 SP1 ADL files with the new features, you need to create a migration "staging area" to contain the design files used during the migration process. To do so, create a migration\56files directory under your installation directory (default: c:\program Files\Avaya\IC60). 5. Copy the following files from 5.6 SP1, along with the new ALM files, to your migration\56files directory: From QeS_INSTALL_DIR\QeS56\design\qrepository, copy qrepository.adl, qrepository.adc, qrepository.adf. Software Upgrade and Data Migration May

306 Chapter 8: Migrating from Avaya IC 5.6 SP1 to From IC_INSTALL_DIR\IC60\design\qrepository, copy qrepository.alm. If your site uses the CallCenterQ Business Application, or the Avaya IC chat or component: - From QeS_INSTALL_DIR\QeS56\design\callcenterq, copy ccq.adl, ccq.adc, ccq.adf. - From IC_INSTALL_DIR\IC60\design\callcenterq, copy ccq.alm. If your site uses HRQ, from QeS_INSTALL_DIR\QeS56\design\hrq, copy hrq.adl, hrq.adc, hrq.adf. From IC_INSTALL_DIR\IC60\design\hrq, copy hrq.alm. If your site uses CustomerQ, from QeS_INSTALL_DIR\QeS56\design\custq, copy custq.adl, custq.adc, custq.adf. From IC_INSTALL_DIR\IC60\ design\custq, copy custq.alm. If you customized the messages in the 5.6 SP1 ALM file, you will need to reapply those changes to the ALM file. You cannot use the 5.6 SP1 ALM file with Avaya IC Prerequisites for chat and migration Before you can migrate your chat and data, you need to: 1. Make sure that all prerequisites described in Prerequisites for all configurations of Avaya IC 5.6 SP1 on page 303 have been completed. 2. Make sure that all chat tasks have been resolved and cleared from the 5.6 SP1 system. 3. Make sure that all tasks (including s deferred by agents) have been resolved and cleared from the active task list. 4. Make sure that all chat and servers (including the WACD, WTC, Attribute server, WIM, , ComHub, and JRun) have been shutdown to prevent additional data from being written to the database during migration. 5. If you want to migrate the local agent resources for your Web Agent application machines, you need to save the agent s local resource files (*.WAC, *.RSC) before you uninstall the 5.6 SP1 Web Agent application. For example, on the agent desktop, copy C:\Quintus\QeS56\ChatClient\agent1\ agent1.wac to C:\Temp, then copy C:\Quintus\QeS56\ChatClient\agent1\ agent1.rsc to C:\Temp. 306 Software Upgrade and Data Migration May 2009

307 Migration prerequisites Prerequisites for installing the web and servers on a new machine Part of the information that gets migrated along with your Chat and configuration data are the fully-qualified server names used for Avaya IC Web Management and Template administration. Therefore, if you install your Web Management and Management web applications on a different machine from your 5.6 SP1 installation, the machine must have the same fully qualified machine name for the migrated system to function properly. If the machine names are different, you will not be able to access the Web Management administration pages to correct the problem. For this reason, you may need to two machines on your network using the same fully qualified domain names during the migration process. To accomplish this, you can use the following procedures to change the local DNS settings of the machines during the course of the migration. After migration, these changes should be undone. In order for this procedure to work, your 5.6 SP1 databases must use a different database server from your databases. For Windows installations You need to make changes to the local hosts file to resolve the reused machine names to the new IP addresses. To do so: 1. Open the local host file on each of the Avaya IC servers by opening C:\WINNT\ system32\drivers\etc\hosts in an ASCII text editor. 2. Add entries to the hosts file for each of the servers, mapping the "reused" fully qualified domain name to the new IP addresses for the servers. Below the line: localhost add: #comment: these are temporary entries mapping the current ip addresses to the 56 fully qualified domain names aaa.bbb.ccc.ddd ic6and56machine1.domain.com ic6and56machine1 ic6and56machine2.domain.com ic6and56machine2 3. Save the hosts file. Repeat this procedure on each server. Software Upgrade and Data Migration May

308 Chapter 8: Migrating from Avaya IC 5.6 SP1 to For Solaris installations On Solaris, make changes to the etc/hosts on each Solaris server, then update the nsswitch.conf file to tell each server to read the local DNS entries first: 1. From a text editor open etc/hosts. 2. Add entries to the hosts file for each of the servers, mapping the "reused" fully qualified domain name to the new IP addresses for the servers. Below the line: localhost add: #comment: these are temporary entries mapping the current ip addresses to the 56 fully qualified domain names aaa.bbb.ccc.ddd ic6and56machine1.domain.com ic6and56machine1 ic6and56machine2.domain.com ic6and56machine2 3. Save the hosts file. 4. From a text editor open /etc/nsswitch.conf and modify it so that "files" comes before "dns" in the name resolution search order. For example, change: hosts: dns files [NOTFOUND=return] nis to hosts: files dns [NOTFOUND=return] nis Repeat this procedure on each Solaris server. After server migration has been completed Once the server migration has been completed and verified, but prior to performing the agent migration, the 5.6 SP1 system should be retired and the file modifications above should be undone. The fully qualified machine names should then be mapped to the IP addresses using a global DNS service. In addition, your external DNS may also have to be updated so that users accessing the public web pages in the Web Management application can reach the new Avaya IC system. 308 Software Upgrade and Data Migration May 2009

309 Migrate application ADL files Migrate application ADL files In order to merge your 5.6 SP1 customizations with the new application design, the migration process uses the following files from IC_INSTALL_DIR\IC60\bin: FixDesignFiles.exe. The migration tool qrepository60.def, ccq60.def, hrq60.def, custq60.def. Files defining paths of design files for each application mig.def. Generic definition file for application paths. When the tool finishes processing the ADL file, it writes the migrated ADL to a file called <filename>.adl.mig. All configurations of Avaya IC require you to migrate qrepository.adl, and all configurations that use chat, , or CallCenterQ require you to migrate ccq.adl. In addition, if your site uses HRQ, you must migrate hrq.adl. If your site uses CustomerQ, you must migrate custq.adl. To migrate your design files: 1. Configure the DEF file specific to your application (ccq60.def, hrq60.def, or custq60.def). You must define the: Paths of the 5.6 SP1 files you want modified ([oldfile] section) Paths of the files to reference ([newfile] section) For example, if you have a CCQ application and you used the directory paths specified in Prerequisites for all configurations of Avaya IC 5.6 SP1 on page 303, you would customize the oldfile and newfile sections as follows: [oldfile] file1=c:\program files\avaya\ic60\migration\56files\ccq.adl file2=c:\program files\avaya\ic60\migration\56files\ccq.adf [newfile] file1=c:\program files\avaya\ic60\design\callcenterq\ccq.adl file2=c:\program files\avaya\ic60\design\callcenterq\ccq.adf 2. Open mig.def and set the correct logfile path in the [log] section. Software Upgrade and Data Migration May

310 Chapter 8: Migrating from Avaya IC 5.6 SP1 to Run IC_INSTALL_DIR\IC60\bin\FixDesignFiles.exe Application Selector 16. Go: Start ADL, ADF conversion 17. Quit: Close application 18. Check this box if you want to use the new forms in your application 19. Status pane showing the tool s progress 20. Overall Progress Bar 21. Current Task Progress Bar You can select: Application. Select QRepository, CCQ, HRQ, or CustomerQ. Add new forms. Select this if you want to tool to check the names of all forms in the ADF against the contents of the 5.6 SP1 ADF, and, if a form exists in but not in 5.6 SP1, copy that form to the 5.6 SP1 ADF so that it will be migrated into the new system. If a form already exists in 5.6 SP1, any functionality needs to be added manually using Database Designer. Avaya recommends that you select this option. 4. Select GO. FixDesignFiles reports its progress in the indicated progress bars in the interface. It also stores one or two log files in the designated Avaya IC logs directory: mig.log shows the details about all the objects that were added by the tool. If it finds any errors, it writes them to err.log. If errors occur, see Appendix B: Troubleshooting FixDesignFiles on page Software Upgrade and Data Migration May 2009

311 Migrate application ADL files 5. Rerun this tool for each application that you use at your site. Move the migrated ADLs to the design subdirectories When the tool completes the migration successfully, it creates a file called: qrepository.adl.mig ccq.adl.mig custq.adl.mig - or - hrq.adl.mig depending on which application you selected. Additionally, if you selected the Create New Forms check box, then the migration tool also creates a corresponding <appname>.adf.mig file. Once you have migrated an ADL file, you need to copy it to the appropriate design directory.! CAUTION: CAUTION: Do not copy the corresponding ADC file to the design directory, or attempt to open the migrated files from the IC_INSTALL_DIR\IC60\migration\ 56files directory. After you have migrated the ADL files, you must open them using the corresponding ADC files or the data source names will not match and most of your database tables will be dropped. To move the migrated ADL to 6.0.2: 1. Copy the migrated <appname>.adl.mig file and, if applicable, the <appname>.adf.mig file, to the IC_INSTALL_DIR\IC60\design\<appname> subdirectory. 2. Rename the out-of-the-box <appname>.adl file and, optionally, the <appname>.adf file, from that subdirectory to <appname>.adl.backup and <appname>.adf.backup. 3. Rename <appname>.adl.mig and, optionally, <appname>.adf.mig to <appname>.adl and <appname>.adf. Repeat this procedure for each application that you migrated using FixDesignFiles. Software Upgrade and Data Migration May

312 Chapter 8: Migrating from Avaya IC 5.6 SP1 to Create the application databases You need to create the Avaya IC databases using the Avaya IC 5.6 SP1 design files that you copied to your Avaya IC system in Prerequisites for all configurations of Avaya IC 5.6 SP1 on page 303. Once these Avaya IC databases have been created, you need to copy the tables from the 5.6 SP1 system into these databases using the data transfer services provided by SQL Server or Oracle. Later in the migration process, you will reconfigure the Avaya IC databases to match the new database schema, and then you will run a series of SQL queries to make the data in the transferred tables match the new schema. Creating the CI Repository database To create the CI Repository database: 1. Start the Database Designer. 2. Select File > Open and open the 5.6 SP1 QRepository ADL file (IC_INSTALL_DIR\ IC60\migration\56files\qrepository.adl). In 6.0.2, Avaya introduced an ALF file. When you open a 5.6 SP1 ADL in Database Designer, you may see an error message stating that the ALM file could not be found. It is safe to select the OK button and continue opening the file, after which Database Designer will create the ALF file for you. 3. In order to accommodate localization requirements, four fields in the database had to be resized so that the indexes using those fields did not exceed 1024 bytes. To make the corresponding changes in your 5.6 SP1 database: a. Expand the Tables placeholder in the Database Designer tree view. b. Expand the qw_reports table entry and change the field length of reportowner from 255 to 150. Before you move your cursor out of this field, save the change by selecting File > Save. c. In the qw_reports table entry, change the field length of reportname from 255 to 150. Before you move your cursor out of this field, save the change by selecting File > Save. d. Expand the qw_templatepack table entry and change the field length of packowner from 255 to 150. Before you move your cursor out of this field, save the change by selecting File > Save. e. In the qw_templatepack table entry, change the field length of packname from 255 to 150. Before you move your cursor out of this field, save the change by selecting File > Save. 312 Software Upgrade and Data Migration May 2009

313 Create the application databases If you have added any custom fields that are part of an index that exceeds 1024 bytes, you should resize those fields as well. 4. To connect to your new database, you need to configure the CI Repository database connection: a. Expand Components > Physical DB Connections and select QrepositoryConnection in the tree pane. b. In the DB Connections Properties tab, fill in at least the following fields (you can find a description of all the fields in the IC Installation and Configuration Guide): Field Description Notes Database Type Data Server Type/Alias Select the type of database from the drop-down menu. The name of your Data Connector server from IC Manager. Database Designer uses the selected database type to generate a SQL statement which can be applied to the database. Enter the name that you gave the Data Connector server during the installation procedure. Database Server Database Name Database Home Directory (Oracle only) Host name of the machine that hosts your database server. Name or schema of the CI Repository database. For example, repository. Enter the full directory path for the Oracle client on the machine that hosts the Data Connector server. For SQL Server: For the default database instance, enter the host name. For another database instance, enter <machine name>/<database name>. For Oracle, enter the server alias from the tnsnames.ora file. For example, support_support.xyzcorp.com In 5.6 SP1, the default name for the QRepository (now CI Repository) database was qrepository. In 6.0.2, that default name has changed to repository. If you do not use the default name, you will need to change the SQL scripts that govern chat and migration to reflect the name you chose. For more information, see Update chat and data with the new schema on page 332. For Oracle only. For example, enter <OraInstlDir>/opt/oracle/8.1.7 Software Upgrade and Data Migration May

314 Chapter 8: Migrating from Avaya IC 5.6 SP1 to To configure the connection set for the CI Repository database: a. Expand DB Connection Sets and select Qconnections in the tree pane. b. Select Application from the Logical DB Connections list in the Connection Set Properties tab. c. Make sure the properties are set as follows: Physical DB Connection - Select QrepositoryConnection. Primary - Do not select this check box. Use External Database - Select this check box. Database Name - Enter the name of your application database. This name must be the exact name that you will give your application database when you create it. For example, enter ccq. d. Select qrepositorydatasource from the Logical DB Connections list. e. Make sure the properties are set as follows: Physical DB Connection - Select QrepositoryConnection. Primary - Select this check box. 6. Save the ADL file using File > Save. 7. To create your new database: a. Select File > Database Administration. b. Select the Configure option button. c. If the Import Seed Data check box is available, make sure that it is not checked. d. Enter your IC Manager username and password in the appropriate fields. (Do not enter your DBA username and password.) e. Select Run. f. When Database Designer is finished, select Close. 8. Save and close the ADL file. Creating the CCQ database To create the CCQ application database: 1. In the Database Designer, select File > Open and open the 5.6 SP1 CallCenterQ ADL file (IC_INSTALL_DIR\IC60\migration\56files\ccq.adl). 314 Software Upgrade and Data Migration May 2009

315 Create the application databases In 6.0.2, Avaya introduced an ALF file. When you open a 5.6 SP1 ADL in Database Designer, you may see an error message stating that the ALM file could not be found. It is safe to select the OK button and continue opening the file, after which Database Designer will create the ALF file for you. 2. In order to accommodate localization requirements, four fields in the database had to be resized so that the indexes using those fields did not exceed 1024 bytes. To make the corresponding changes in your 5.6 SP1 database: a. Expand the Tables placeholder in the Database Designer tree view. b. Expand the qw_reports table entry and change the field length of reportowner from 255 to 150. Before you move your cursor out of this field, save the change by selecting File > Save. c. In the qw_reports table entry, change the field length of reportname from 255 to 150. Before you move your cursor out of this field, save the change by selecting File > Save. d. Expand the qw_templatepack table entry and change the field length of packowner from 255 to 150. Before you move your cursor out of this field, save the change by selecting File > Save. e. In the qw_templatepack table entry, change the field length of packname from 255 to 150. Before you move your cursor out of this field, save the change by selecting File > Save. If you have added any custom fields that are part of an index that exceeds 1024 bytes, you should resize those fields as well. 3. To connect to your new database, you need to configure the ccqconnection database connection: a. Expand Components > Physical DB Connections and select ccqconnection in the tree pane. b. In the DB Connections Properties tab, fill in at least the following fields (you can find a description of all the fields in the IC Installation and Configuration Guide): Field Description Notes Database Type Data Server Type/Alias Select the type of database from the drop-down menu. The name of your Data Connector server from IC Manager. Database Designer uses the selected database type to generate a SQL statement which can be applied to the database. Enter the name that you gave the Data Connector server during the installation procedure. Software Upgrade and Data Migration May

316 Chapter 8: Migrating from Avaya IC 5.6 SP1 to Field Description Notes Database Server Database Name Database Home Directory (Oracle only) Host name of the machine that hosts your database server. Name or schema of the CallCenterQ database. For example, ccq. Enter the full directory path for the Oracle client on the machine that hosts the Data Connector server. For SQL Server: For the default database instance, enter the host name. For another database instance, enter <machine name>/<database name>. For Oracle, enter the server alias from the tnsnames.ora file. For example, support_support.xyzcorp.com. The Avaya IC default database name is ccq. For Oracle only. For example, enter <OraInstlDir>/opt/oracle/ To configure the connection set for the CCQ database: a. Expand DB Connection Sets and select Qconnections in the tree pane. b. Select ccqdatasource from the Logical DB Connections list in the Connection Set Properties tab and make sure the properties are set as follows: Physical DB Connection - Select ccqconnection. Primary - Select this check box. c. Select qrepositorydatasource from the Logical DB Connections list. d. Make sure the properties are set as follows: Physical DB Connection - Select ccqconnection. Primary - Do not select this check box. Use External Database - Select this check box. Database Name - Enter the name of your CI Repository database. For example, enter repository. 5. Save the ADL file using File > Save. 6. To create your new database: a. Select File > Database Administration. b. Select the Configure option button. c. If the Import Seed Data check box is available, make sure that it is not selected. d. If necessary, enter your IC Manager username and password in the appropriate fields. (Do not enter your DBA username and password.) 316 Software Upgrade and Data Migration May 2009

317 Create the application databases e. Select Run. f. When Database Designer is finished, select Close. 7. Save and close the ADL file. Creating the HRQ database If you are using the HRQ Business Application, you need to create the HRQ application database. To do so: 1. In Database Designer, select File > Open and open the open the 5.6 SP1 HRQ ADL file (IC_INSTALL_DIR\IC60\migration\56files\hrq.adl). In 6.0.2, Avaya introduced an ALF file. When you open a 5.6 SP1 ADL in Database Designer, you may see an error message stating that the ALM file could not be found. It is safe to select the OK button and continue opening the file, after which Database Designer will create the ALF file for you. 2. In order to accommodate localization requirements, four fields in the database had to be resized so that the indexes using those fields did not exceed 1024 bytes. To make the corresponding changes in your 5.6 SP1 database: a. Expand the Tables placeholder in the Database Designer tree view. b. Expand the qw_reports table entry and change the field length of reportowner from 255 to 150. Before you move your cursor out of this field, save the change by selecting File > Save. c. In the qw_reports table entry, change the field length of reportname from 255 to 150. Before you move your cursor out of this field, save the change by selecting File > Save. d. Expand the qw_templatepack table entry and change the field length of packowner from 255 to 150. Before you move your cursor out of this field, save the change by selecting File > Save. e. In the qw_templatepack table entry, change the field length of packname from 255 to 150. Before you move your cursor out of this field, save the change by selecting File > Save. If you have added any custom fields that are part of an index that exceeds 1024 bytes, you should resize those fields as well. 3. To connect to your new database, you need to configure the hrqconnection database connection: a. Expand Components > Physical DB Connections and select hrqconnection in the tree pane. Software Upgrade and Data Migration May

318 Chapter 8: Migrating from Avaya IC 5.6 SP1 to b. In the DB Connections Properties tab, fill in at least the following fields (you can find a description of all the fields in the IC Installation and Configuration Guide): Field Description Notes Database Type Data Server Type/Alias Database Server Database Name Database Home Directory (Oracle only) Select the type of database from the drop-down menu. The name of your Data Connector server from IC Manager. Host name of the machine that hosts your database server. Name or schema of the HRQ database. For example, hrq. Enter the full directory path for the Oracle client on the machine that hosts the Data Connector server. Database Designer uses the selected database type to generate a SQL statement which can be applied to the database. Enter the name that you gave the Data Connector server during the installation procedure. For SQL Server: For the default database instance, enter the host name. For another database instance, enter <machine name>/<database name>. For Oracle, enter the server alias from the tnsnames.ora file. For example, support_support.xyzcorp.com The Avaya IC default database name is hrq. For Oracle only. For example, enter <OraInstlDir>/opt/oracle/ To configure the connection set for the HRQ database: a. Expand DB Connection Sets and select Qconnections in the tree pane. b. Select hrqdatasource from the Logical DB Connections list in the Connection Set Properties tab and make sure the properties are set as follows: Physical DB Connection - Select hrqconnection. Primary - Select this check box. c. Select qrepositorydatasource from the Logical DB Connections list. d. Make sure the properties are set as follows: Physical DB Connection - Select hrqconnection. Primary - Do not select this check box. Use External Database - Select this check box. Database Name - Enter the name of your CI Repository database. For example, enter repository. 318 Software Upgrade and Data Migration May 2009

319 Create the application databases 5. Save the ADL file using File > Save. 6. To create your new database: a. Select File > Database Administration. b. Select the Configure option button. c. If the Import Seed Data check box is available, make sure that it is not selected. d. If necessary, enter your IC Manager username and password in the appropriate fields. (Do not enter your DBA username and password.) e. Select Run. f. When Database Designer is finished, select Close. 7. Save and close the ADL file. Creating the CustomerQ database If you are using the CustomerQ Business Application, you need to create the CustQ application database. To do so: 1. In Database Designer, select File > Open and open the 5.6 SP1 CustomerQ ADL file (IC_INSTALL_DIR\IC60\migration\56files\custq.adl). In 6.0.2, Avaya introduced an ALF file. When you open a 5.6 SP1 ADL in Database Designer, you may see an error message stating that the ALM file could not be found. It is safe to select the OK button and continue opening the file, after which Database Designer will create the ALF file for you. 2. In order to accommodate localization requirements, four fields in the database had to be resized so that the indexes using those fields did not exceed 1024 bytes. To make the corresponding changes in your 5.6 SP1 database: a. Expand the Tables placeholder in the Database Designer tree view. b. Expand the qw_reports table entry and change the field length of reportowner from 255 to 150. Before you move your cursor out of this field, save the change by selecting File > Save. c. In the qw_reports table entry, change the field length of reportname from 255 to 150. Before you move your cursor out of this field, save the change by selecting File > Save. d. Expand the qw_templatepack table entry and change the field length of packowner from 255 to 150. Before you move your cursor out of this field, save the change by selecting File > Save. Software Upgrade and Data Migration May

320 Chapter 8: Migrating from Avaya IC 5.6 SP1 to e. In the qw_templatepack table entry, change the field length of packname from 255 to 150. Before you move your cursor out of this field, save the change by selecting File > Save. If you have added any custom fields that are part of an index that exceeds 1024 bytes, you should resize those fields as well. 3. To connect to your new database, you need to configure the custqconnection database connection: a. Expand Components > Physical DB Connections and select custqconnection in the tree pane. b. In the DB Connections Properties tab, fill in at least the following fields (you can find a description of all the fields in the IC Installation and Configuration Guide): Field Description Notes Database Type Data Server Type/Alias Database Server Database Name Database Home Directory (Oracle only) Select the type of database from the drop-down menu. The name of your Data Connector server from IC Manager. Host name of the machine that hosts your database server. Name or schema of the CustomerQ database. For example, custq. Enter the full directory path for the Oracle client on the machine that hosts the Data Connector server. Database Designer uses the selected database type to generate a SQL statement which can be applied to the database. Enter the name that you gave the Data Connector server during the installation procedure. For SQL Server: For the default database instance, enter the host name. For another database instance, enter <machine name>/<database name>. For Oracle, enter the server alias from the tnsnames.ora file. For example, support_support.xyzcorp.com The Avaya IC default database name is custq. For Oracle only. For example, enter <OraInstlDir>/opt/oracle/ To configure the connection set for the CustomerQ database: a. Expand DB Connection Sets and select Qconnections in the tree pane. b. Select custqdatasource from the Logical DB Connections list in the Connection Set Properties tab and make sure the properties are set as follows: Physical DB Connection - Select custqconnection. 320 Software Upgrade and Data Migration May 2009

321 Copy 5.6 SP1 data into Primary - Select this check box. c. Select qrepositorydatasource from the Logical DB Connections list. d. Make sure the properties are set as follows: Physical DB Connection - Select custqconnection. Primary - Do not select this check box. Use External Database - Select this check box. Database Name - Enter the name of your CI Repository database. For example, enter repository. 5. Save the ADL file using File > Save. 6. To create your new database: a. Select File > Database Administration. b. Select the Configure option button. c. If the Import Seed Data check box is available, make sure that it is not selected. d. If necessary, enter your IC Manager username and password in the appropriate fields. (Do not enter your DBA username and password.) e. Select Run. f. When Database Designer is finished, select Close. 7. Close the ADL file. Copy 5.6 SP1 data into How you copy your data from 5.6 SP1 into your databases depends on whether you use SQL Server or Oracle. Copying SQL Server data To copy data from SQL Server, you need to prepare the databases and then transfer the data from the 5.6 SP1 databases into your new databases using your database s export/ import facility. To do so: 1. Prepare your 5.6 SP1 QRepository database by using your database utilities to run the SQL commands located in IC_INSTALL_DIR\IC60\bin\ Migration\clear_tables.sql against that database (default name: qrepository). Software Upgrade and Data Migration May

322 Chapter 8: Migrating from Avaya IC 5.6 SP1 to Run the SQL commands located in IC_INSTALL_DIR\IC60\bin\Migration\ disable_constraints_sqlserver.sql against your 5.6 SP1 QRepository database. 3. Use your database export/import utilities to export the data from your 5.6 SP1 QRepository database, making sure that you select the disable constraints option. 4. Import your data into your CI Repository database (default name: repository). If your site uses the: CallCenterQ Business Application, or the Avaya IC chat or component, repeat this procedure with the CallCenterQ database (default name in both releases: ccq). HRQ Business Application, repeat this procedure with the HRQ database (default name in both releases: hrq). CustomerQ Business Application, repeat this procedure with the CustomerQ database (default name in both releases: custq). Copying Oracle data To copy data from Oracle, you need to disable the constraints and then import the data. The steps below are provided as an example only. You should confirm these steps by referring to your official database documentation. To import data from Oracle: 1. Open a DOS prompt and navigate to IC_INSTALL_DIR\IC60\bin\Migration. 2. Open generate_disable_constraints_all.sql in an ASCII editor. 3. Edit the placeholder database names in this file to match the databases that you created, then save and close the file. If your site does not use one or more of the default databases, you should delete the corresponding placeholders. The placeholder database names are: Database CI Repository database CallCenterQ database HRQ database CustomerQ database Placeholder Name QREPMIG60 CCQMIG60 HRQMIG60 CUSTQMIG Software Upgrade and Data Migration May 2009

323 Update database constraints You need to make sure that you replace the placeholder names with the exact name of your database, and that the entire name is in uppercase. For example, if you used the default name for the CI Repository database, then you would replace QREPMIG60 with REPOSITORY. 4. From the command line in the IC_INSTALL_DIR\IC60\bin\Migration subdirectory, run the generate_disable_constraints_all.sql script using SQL Plus. For example, if your login ID is system, the password is manager, and the host string is orautf8, you would enter the following command: When this script finishes, it creates a file called disable_constraints_all.sql and puts it in the current directory. Run this script file with SQL Plus to disable all of the constraints in your databases. 5. For repository and, optionally, ccq, custq, and hrq, you need to: a. Run clear_tables.sql from the command line of the migration subdirectory using SQL Plus. b. Import data from the 5.6 SP1 dump files using imp (for more information about imp, see your Oracle documentation). Update database constraints In order to update the database constraints and verify that the data import worked correctly, you need to run two SQL scripts and reconfigure the databases using the 5.6 SP1 ADL files. To do so: 1. Open a DOS prompt and navigate to IC_INSTALL_DIR\IC60\bin\Migration. 2. Update the qw_dbinfo table by running updateversion.sql in SQL Enterprise Manager (for SQL Server), or SQL Plus (for Oracle) against the repository database, and, if applicable, against the ccq, hrq, and custq databases as well. 3. Enable all constraints by: For SQL Server, run enable_constraints_sqlserver.sql. For Oracle, run the generate_enable_constraints_all.sql script using SQL Plus. For example, if your login ID is system, the password is manager, and the host string is orautf8, you would enter the following command: sqlplus When this script finishes, it creates a file called enable_constraints_all.sql and puts it in the current directory. Run this script file with SQL Plus to enable all of the constraints in your databases. Software Upgrade and Data Migration May

324 Chapter 8: Migrating from Avaya IC 5.6 SP1 to Tip: Tip: Avaya recommends that you back up all of your databases at this point in case you need to re-run the later stages of the migration process. For more information about backing up your databases, see your database documentation. Reconfigure your application databases using the migrated ADL files In order to merge your migrated ADLs with your databases, you need to set your ADL Include Path and reconfigure your databases. To do so: 1. Start Database Designer and open your CI Repository ADL file (IC_INSTALL_DIR\ IC60\design\qrepository\qrepository.adl). 2. Set the connection information to point to the databases you created in Create the application databases on page 312. For details, see Configuring the CI Repository Database Connection in the IC Installation and Configuration Guide. 3. Set the ADL include path to the appropriate directories. To do so: a. In the left pane, select the first node to open the Application Design File Properties tab. b. In the right pane, select the (ellipsis) button next to the ADL Include Path text box. c. In the ADL Include Path dialog box, delete the current path and then select Add. d. In the Browse for Folder dialog box, navigate to the folder where the common IC Scripts are located, then select the OK button. (Default: c:\program Files\ Avaya\IC60\design\common.) e. Select Add again and navigate to the folder where the QConsole IC Scripts are located, then select the OK button. (Default: c:\program Files\Avaya\IC60\ design\qconsole.) f. In the ADL Include Path dialog box, select the OK button. 4. To make sure that the process worked successfully, reopen Database Designer and then reopen the ADL file. It should open without errors. 5. To reconfigure the database: a. Select File > Database Administration. b. Select defaultdbconnectionset from the DB Connection Set list. c. Select the Reconfigure option button. d. Enter your IC Manager username and password in the appropriate fields. (Do not enter your DBA username and password.) 324 Software Upgrade and Data Migration May 2009

325 Import seed data for new CI Repository database tables e. Select Run. f. When Database Designer has finished, select Close. 6. Close the ADL file. If your site uses the: CallCenterQ Business Application, or the Avaya IC chat or component, open IC_INSTALL_DIR\IC60\design\ccq\ccq.adl and repeat this procedure. HRQ Business Application, open IC_INSTALL_DIR\IC60\design\hrq\hrq.adl and repeat this procedure. CustomerQ Business Application, open IC_INSTALL_DIR\IC60\design\custq\ custq.adl and repeat this procedure. Tip: Tip: Avaya recommends that you back up all of your databases at this point in case you need to re-run the later stages of the migration process. For more information about backing up your databases, see your database documentation. Import seed data for new CI Repository database tables There are several new tables in the CI Repository database that require seed data. These tables are: site languagecode classificationcode classificationgrp localizedcode If you have customized the mapping rules for the Report server, you need to make a note of those customizations so that you can reapply them later. (These mapping rules are stored in the creationrules and fieldexpressions tables.) To import the seed data: 1. First delete the old Report server table data. To do so, use your database administration tool to run the following SQL statements: delete from fieldexpressions delete from creationrules Software Upgrade and Data Migration May

326 Chapter 8: Migrating from Avaya IC 5.6 SP1 to Open a DOS window and navigate to IC_INSTALL_DIR\IC60\design\ qrepository\data. 3. Run import_delta_seed.bat. 4. Reapply any customized mapping rules. 5. Generate the CI Repository application by: a. Opening IC_INSTALL_DIR\IC60\design\qrepository\qrepository.adl in Database Designer. b. Select File > Generate Windows Application and generate the application, being sure to push all IC Scripts to the database. (For details, see the IC Database Designer Application Reference.) Create the Migration database The Migration database provides temporary storage of transferred data, record keeping for the DBMigration tool, and a way for you to verify what data was migrated. To create this database: 1. Open Database Designer. 2. Open IC_INSTALL_DIR\IC60\bin\Migration\migration.adl. When you open the ADL in Database Designer, you may see an error message stating that the ALF file could not be found. It is safe to select the OK button and continue opening the file, after which Database Designer will create the ALF file for you. 3. Configure the migration database connection: a. Expand Components > Physical DB Connections and select migconnection in the tree pane. b. In the DB Connections Properties tab, fill in at least the following fields (you can find a description of all the fields in the IC Installation and Configuration Guide): Field Description Notes Database Type Data Server Type/Alias Select the type of database from the drop-down menu. The name of your Data Connector server from IC Manager. Database Designer uses the selected database type to generate a SQL statement which can be applied to the database. Enter the name that you gave the Data Connector server during the installation procedure. 326 Software Upgrade and Data Migration May 2009

327 Run DBMigrate Field Description Notes Database Server Database Name Host name of the machine that hosts your database server. Name or schema of the migration database. For example, MigrationDB. For SQL Server: For the default database instance, enter the host name. For another database instance, enter <machine name>/<database name>. For Oracle, enter the server alias from the tnsnames.ora file. For example, support_support.xyzcorp.com The Avaya IC default database name is MigrationDB. 4. Save the ADL. 5. To create the migration database: a. Select File > Database Administration. b. Select Qconnections from the DB Connection Set list. c. Select the Configure option button. d. If the Import Seed Data check box is available, make sure that it is not selected. e. Enter your IC Manager username and password in the appropriate fields. (Do not enter your DBA username and password.) f. Select Run. g. When Database Designer is finished, select Close. 6. Save and close the ADL file. Run DBMigrate The DBMigrate tool updates your 5.6 SP1 data to match the new database schema, then places it in the appropriate fields in the new data model using the rules specified in the provided migration ADL files. You should never configure your database using a migration ADL file, because you will lose data from your database. If you have heavily customized your Avaya IC installation, you may need to customize the DBMigrate tool in order to accommodate those customizations, or check the results of the migration to what database fields were migrated. For details about this tool, see Customizing the DBMigrate tool on page 354. Software Upgrade and Data Migration May

328 Chapter 8: Migrating from Avaya IC 5.6 SP1 to In order to run DBMigrate, you need to specify the connection set information for the DBMigrate-specific ADL, and then run the migrate_qrepository.bat file. To set the connection information for DBMigrate: 1. Open IC_INSTALL_DIR\IC60\bin\Migration\qrepository56_60.adl in Database Designer. When you open the ADL in Database Designer, you may see an error message stating that the ALF file could not be found. It is safe to select the OK button and continue opening the file, after which Database Designer will create the ALF file for you. 2. To connect to your new database, you need to configure the CI Repository database connection: a. Expand Components > Physical DB Connections and select qrepositoryconnection in the tree pane. b. In the DB Connections Properties tab, fill in at least the following fields (you can find a description of all the fields in the IC Installation and Configuration Guide): Field Description Notes Timeout Database Type Data Server Type/Alias The maximum number of seconds that the client application waits for a response to a database request before the application assumes the connection to the Data Connector server is lost. Select the type of database from the drop-down menu. The name of your Data Connector server from IC Manager. Set this interval based on the size of your database. Avaya recommends using at least Database Designer uses the selected database type to generate a SQL statement which can be applied to the database. Enter the name that you gave the Data Connector Server during the installation procedure. 328 Software Upgrade and Data Migration May 2009

329 Run DBMigrate Field Description Notes Database Server Database Name Host name of the machine that hosts your database server. Name of your CI Repository database. For example, repository. For SQL Server: For the default database instance, enter the host name. For another database instance, enter <machine name>/<database name>. For Oracle, enter the server alias from the tnsnames.ora file. For example, support_support.xyzcorp.com This must be the same name you used for the CI Repository database in Creating the CI Repository database on page To configure the connection set for the DBMigrate database: a. Expand DB Connection Sets and select Qconnections in the tree pane. b. Select migrationdatasource from the Logical DB Connections list in the Connection Set Properties tab. c. Make sure the properties are set as follows: Physical DB Connection - Select qrepositoryconnection. Primary - Do not select this check box. Use External Database - Select this check box. Database Name - Enter the name of your migration database. This name must be the exact name that you gave your migration database in Create the Migration database on page 326. For example, enter MigrationDB.! CAUTION: CAUTION: Do not reconfigure your database using this ADL or it will seriously damage your database. 4. Save the ADL file using File > Save. To run DBMigrate: 1. Make sure that you have customized the DBMigrate tool to account for any changes you made to the 5.6 SP1 data model, as described in Customizing the DBMigrate tool on page Open a DOS prompt and navigate to IC_INSTALL_DIR\IC60\bin\Migration. 3. Open migrate_qrepository.bat in an ASCII editor such as Notepad. This bat file calls the DBMigrate tool, which will move your 5.6 SP1 data into the proper places in the new database schema. The bat file contains the following text: Software Upgrade and Data Migration May

330 Chapter 8: Migrating from Avaya IC 5.6 SP1 to "%AVAYA_IC_HOME%\bin\dbmigrate.exe" "%AVAYA_IC_HOME%\bin\Migration\ qrepository56_60.adc" migration_qrep Qconnections Admin admin "%AVAYA_IC_HOME%\bin\ Migration\qrepository56_60.xml" where: "%AVAYA_IC_HOME%\bin\dbmigrate.exe" is the path to the DBMigrate executable. "%AVAYA_IC_HOME%\bin\Migration\qrepository56_60.adc" is the path to the migration ADC file. migration_qrep is the name of the application in the ADC file that DBMigrate will used to transfer the data. Qconnections is the name of the connectionset specified in the ADC file that DBMigrate will use to connect to the database. Admin is an IC Manager user ID with Administrator authority. admin is the password for the IC Manager user ID specified in Admin. "%AVAYA_IC_HOME%\bin\Migration\qrepository56_60.xml" is the path to the XML file that defines the migration rules. 4. Change Admin and admin to be your IC Manager administrator login and password. 5. If you want to increase the level of logging maintained by DBMigrate, you can append the optional <loglevel> parameter to the end of the command. <loglevel> can be 0, 1, 2, or 3, where 0 (the default) is the minimum amount of logging. 6. Save and close migrate_qrepository.bat. 7. Run migrate_qrepository.bat. The length of time that DBMigrate requires depends upon the size of your database. 8. When the process is finished, check the IC_INSTALL_DIR\IC60\logs\ dbmigrate.log file to make sure the process completed without errors. Verify the data migration After you have run DBMigrate, there are several new tables that you can check to make sure that the data has migrated properly: mediainteraction - This table is created from the 5.6 SP1 contact table. It should have as many rows as the contact table does. mediasegment - This table is the intersection of the routingevent and mediainteraction tables. It should mirror the 1:N link between the contact and routingevent, and there should be as many rows in this table as there are in the routingevent table. Additionally, there will be at least one row for every mediainteraction that was created. 330 Software Upgrade and Data Migration May 2009

331 Migrate and chat data agentsegment - This table is the intersection of the routingevent and employee tables. There should be the same number of rows in the agentsegment table as there are routingevent rows with the agent_key column populated. classificationcode - This table contains the data previously stored in the outcomecode, reasoncode, and categorycode tables. There should be one row in the classificationcode table for each row in the other three tables. localizedcode - This table contains the display value of the classificationcode table. It is populated with the display values coming from the 5.6 SP1 outcomecode, reasoncode and categorycode tables. There should be the same number of rows in the localizedcode table as there are in the classificationcode table. taskperformedcode - This is the intersection that represents the individual keys in the taskperformed table that were linked to the 5.6 SP1 outcomecode, reasoncode and categorycode tables. There will be a single row for each populated column (outcomecode_key, categorycode_key and reasoncode_key) in each taskperformed row. For more details about these new tables, see Data schema changes in on page 355. Tip: Tip: Avaya recommends that you back up all of your databases at this point in case you need to re-run the later stages of the migration process. For more information about backing up your databases, see your database documentation. Migrate and chat data Chat and migration is performed simultaneously and will automatically transfer the following from your 5.6 SP1 system to Avaya IC 6.0.2: WACD chat and task data messages and message history Chat transcripts and chat history Website authentication data for registered customers Datawake Filters and customer Datawake history Avaya IC Web Management FAQs Avaya IC Web Management configuration data (MultiTenant metadata) response templates Tools are provided for migrating Agent chat and resources, but some steps must be done manually. Software Upgrade and Data Migration May

332 Chapter 8: Migrating from Avaya IC 5.6 SP1 to This following areas of the Avaya IC Chat and components have changed since 5.6 SP1 and may require reimplementing your personalizations and customizations: Server configuration Avaya IC Web Management - Chat and Escalation for Avaya IC 5.6 SP1 and Internet Call Center (ICC) Self-Service FAQs - Configuration Data (Multi-tenant metadata) - Customer Authentication - Proactive Contact and Datawake Chat and routing - Analysis and Routing (WACD Scripts, Workflows, and WACD PLAID Scripts) - Chat Routing (Chat Workflows and WACD PLAID Scripts) Chat Client Workflows Agent Scripts Historical Data To migrate your data, you need to: Complete the prerequisites in Prerequisites for all configurations of Avaya IC 5.6 SP1 on page 303 and Prerequisites for chat and migration on page 306. Update your chat and data to conform to the new schema. For details, see Update chat and data with the new schema on page 332. Import the migration seed data. For details, see Import new seed data on page 334. Reapply and 5.6 SP1 customizations and configuration options. For details, see Reapply 5.6 SP1 configuration and customizations on page 335. Update agent properties and resources. For details, see Migrate Web Agent applications on page 345. Update chat and data with the new schema Before you update your chat and data, you should consider the following issues: If one of the new Web Management configuration parameters has the same name as a custom piece of 5.6 SP1 configuration data, errors may occur when copying the 5.6 SP1 seed data. In this case, the custom configuration data will not be migrated. 332 Software Upgrade and Data Migration May 2009

333 Migrate and chat data If you have modified the CallCenterQ database schema to support customizations such as adding additional survey questions for the Web Management website, you may need to modify the Chat and migration scripts to migrate the custom fields. For more information, see Survey changes on page 340. The way you update your chat and data depends on whether you are using SQL Server or Oracle. Using SQLServer To update the chat and data using SQLServer: 1. If your CI Repository database is not called repository, you need to open IC_INSTALL_DIR\IC60\bin\Migration\migrate_chat_ _script.sql and change all instances of repository in the following query to match your CI Repository database name: update w_qw_wru_entry set w_qw_wru_entry.tenant_key = repository.dbo.tenant.pkey from w_qw_wru_entry, repository.dbo.tenant where w_qw_wru_entry.tenant_id = repository.dbo.tenant.name 2. If you want to migrate any custom survey data, you need to modify the script as described in Survey changes on page Using your database utilities, run the SQL statements in IC_INSTALL_DIR\IC60\bin\ Migration\migrate_chat_ _script.sql against your CallCenterQ database (default name: ccq). Using Oracle To update the chat and data using Oracle: 1. Open a DOS window and navigate to IC_INSTALL_DIR\IC60\bin\Migration. 2. If your CI Repository database name is something other than repository, you need to edit the script to replace the hardcoded database name. To do so: a. Open migrate_chat_ _scripts_ora.sql in an ASCII editor. b. Perform a a global search for the string repository and replace it with your CI Repository database name. c. Save and close migrate_chat_ _scripts_ora.sql. 3. If you want to migrate any custom survey data, you need to modify the script as described in Survey changes on page From the DOS prompt, run migrate_chat_ _scripts_ora.sql script using SQL Plus. Software Upgrade and Data Migration May

334 Chapter 8: Migrating from Avaya IC 5.6 SP1 to Make sure you login to SQLPlus using your ccq database user account. For example, if your ccq user login ID is ccq, your password is avaya, and the host string is ccqdb, you would enter: Import new seed data Avaya IC includes new seed data required by the Avaya IC Chat and servers and by the Avaya IC Web Management application. If you are migrating localized system, you should perform all of the standard migration tasks and then see the IC Installation and Configuration Guide for information about localizing your migrated system. To import seed data: 1. In Notepad or another text editor, open the following file: IC_INSTALL_DIR\IC60\ design\callcenterq\data\migrate_56_601_import_seed.cfg 2. Find the DestinationPasswd field and verify that the value is the correct password for the Admin account. 3. Save the migrate_56_601_import_seed.cfg file. 4. Run the seed migration import BAT file migrate_56_601_import_seed.bat. Reconfigure the chat and databases In order to merge your migrated chat and data with your databases, you need to reconfigure those databases. To do so: 1. Start Database Designer and open your CI Repository ADL file (IC_INSTALL_DIR\ IC60\design\qrepository\qrepository.adl). 2. Select File > Database Administration. 3. Select defaultdbconnectionset from the DB Connection Set list. 4. Select the Reconfigure option button. 5. If necessary, enter your IC Manager username and password in the appropriate fields. (Do not enter your DBA username and password.) 6. Select Run. 7. When Database Designer has finished, select Close. 8. Close the ADL file. 334 Software Upgrade and Data Migration May 2009

335 Migrate and chat data 9. Open your CallCenterQ ADL file (IC_INSTALL_DIR\IC60\design\ callcenterq\ccq.adl) and repeat steps 2 through 8 for that database. Reapply 5.6 SP1 configuration and customizations This section summarizes the changes made to Avaya IC Chat and , and how these changes may affect the 5.6 SP1 to migration. Server changes In Avaya IC the Web Management application, the ICM server, and the CIRS server require a valid VESP Toolkit login account with at least Operator permissions to function properly. If a migrated account (such as the "db" account) is used, the account must be given Operator permissions using IC Manager. To set these permissions: 1. Start IC Manager. 2. Select the Agent tab. 3. In the left-hand pane, right-click the account used by the Web Management application, ICM, and CIRS and select Edit from the pop-up menu. 4. Select the Security tab. 5. Make sure the Operator or Administrator check box is selected. 6. Select the OK button. Due to architectural changes in Chat and , some system configuration information will be lost during the migration. This section lists some of the major changes to the system and highlights configuration settings which may need to be reapplied in Avaya IC after you have finished installing and configuring Avaya IC as described in the IC Installation and Configuration Guide. The following server changes have been made in 6.0.2: WACD - The WACD server is now configured and controlled by IC Manager. Most standard configuration options are provided in the WACD tab of the IC Manager server configuration window. These options include: Logging Level ComHub Location and Port Task Timeouts DataServer Connectivity WACD Admin Page Location The WACD no longer needs to be told the location of the IC server, this is determined automatically. Software Upgrade and Data Migration May

336 Chapter 8: Migrating from Avaya IC 5.6 SP1 to If additional WACD configuration needs to be migrated custom configuration name value pairs can be entered on the "configuration" tab of the WACD server configuration window in IC Manager. (For details, see IC Administration Volume 1: Servers & Domains.) WTC - The WTC server has been replaced by the ICM Server in Avaya IC For more information, see Configuring the ICM Server in the IC Installation and Configuration Guide. For information about changes to the Avaya IC Chat Client, see Chat client changes on page 343. Backgrounder - The functions performed by the Backgrounder server are now being performed by the ICM Server. WIM/Paging - The WIM server has been renamed the Paging server and is now configured and controlled by IC Manager. Most standard configuration options, including ComHub Location and Port, are provided in the Paging tab when you create or modify the Paging server in IC Manager. If additional Paging configuration information needs to be migrated, you can enter custom configuration name value pairs on the Paging server s Configuration tab. (For more information, see IC Administration Volume 1: Servers & Domains.) ComHub - The ComHub server is now configured and controlled by IC Manager. /IC - The server is now configured and controlled by IC Manager. Most standard configuration options are provided in the IC tab in the server s Server Configuration dialog box, including: SMTP Server SMTP Helo Domain Maximum Messages Retrieved per POP Cycle POP Cycler wait Duplicate Message Checking Loop Detection server properties previously configured using the IC Manager Property Manager must be manually migrated to the IC tab of the server configuration. These Avaya IC 5.6 SP1 properties are automatically copied to 6.0.2, but they are not moved to the IC configuration tab. If you want the server to use those parameters, you must manually reenter them on the server s IC configuration tab. QChat - The functions performed by the QChat server are now being performed by the WACD server. QWC - The functions performed by the QWC are now being performed by the WACD server. WebChannel/HTTPConnector - The WebChannel server has been renamed the HTTPConnector, and it is no longer used by the Avaya IC Web or applications to run Chat and authentication and routing workflows. Therefore, this server is no longer required by Web Management or the WACD server. 336 Software Upgrade and Data Migration May 2009

337 Migrate and chat data General changes The Web Management component has been extended to include support for localization. New user-configurable parameters have been introduced and administrative components have been added to support Web Management configuration data (metadata) in multiple languages. In addition, the parsing of HTTP request parameters and form data have been modified to accept multi-byte UTF-8 encoding. Chat escalation has been modified for the new Avaya IC Chat architecture. The Chat Connector server is no longer used and the Chat plugin is no longer used as part of the chat escalation procedure. Most HTTP request parameters in the web application now have constants defined for their names, and the method used to retrieve HTTP request parameters now accepts UTF-8 parameters. For example, an localized request for the parameter "aicauthaction" would look like: String action = JSPUtils.getParameter(request, sessionlanguage, JSPConstants.HTTP_PARAMS_AUTH_ACTION); The Avaya IC Website system configuration has been moved to IC Manager. For details, see "Configuring the Website" in the IC Installation and Configuration Guide. The public and administrative pages for the Web Management component have been modified for Avaya IC Any JSP pages and Java components developed for 5.6 SP1 cannot be migrated to Instead, you must install the new Web Management component and then reapply any customizations that you made to 5.6 SP1. One-click chat escalation links or web forms, used to access Chat or Web Management, should still function with only minor modification. In addition, forms created to access the ICC/CentreVu Chat or Chat & Callback functionality will continue to work with minor changes. The following sections provide additional details about how the following Web Management changes might effect migration: Single-click authentication and escalation on page 337 Self-service/FAQ changes on page 339 Self-service/FAQ changes on page 339 Configuration data changes on page 339 Web Management configuration data (multi-tenant metadata) Proactive contact and DataWake changes on page 340. Single-click authentication and escalation URLs or forms created in a separate web application to access Chat functionality in 5.6 SP1 or ICC/CentreVu 4.5 can be migrated to Avaya IC with minimal changes. These URLs are sometimes referred to as "single-click" or "one shot" URLs. Software Upgrade and Data Migration May

338 Chapter 8: Migrating from Avaya IC 5.6 SP1 to If you are migrating from ICC/CentreVu 4.5, Chat and Chat & Callback requests can be reused by changing the target of the link or form now used to access the ICC translation page iccescalate.jsp. The page is designed to accept many of the standard ICC chat request parameters and translate them into Avaya IC chat escalation request parameters. The page causes an automatic guest login to occur and an automatic Chat or Chat & Callback escalation to occur. For example, if the previous forms target was: then the new URL would be of the form: If you are migrating from Avaya IC 5.6 SP1, one-click links and forms essentially remain the same (as long as the server name has not changed). The only changes involve request parameters: If any of your 5.6 SP1 parameters use the namespace identifier "qew", this must be changed to "aic" for For example, a parameter like "qewescaction" would become "aicescaction". The request parameter descriptor "Endpoint" is now referred to as "RequestedMedia" in website URLs. For example, a one-click escalation URL of the following form: guest&qewauthaction=login&qewtenant=defaulttenant&qewescaction=escalate& qewescendpoint=chat&qewescquestion=thisismyquestion would become: guest&aicauthaction=login&aictenant=defaulttenant&aicescaction=escalate& aicescendpoint=chat&aicescquestion=thisismyquestion The redirection URLs passed in as query parameters for single-click authentication must be fully qualified. If relative URLs were used to send customers to a specific page in the IC Website (such as the Search page), these URLs may not function correctly in Please contact Avaya Technical support if you experience any problems. Escalation routing changes Routing of Chat and requests made from the Web Management pages has changed. In 5.6 SP1, standard routing involved associating each FAQ in Web Management Self-Service with a Queue (or Tasktype). These FAQ-Queue associations were used to determine how chat tasks were routed and which address was used for sending s from the website. In 6.0.2, FAQs are associated instead with Routing Hints for Chat escalations and Mail Accounts for escalations. Therefore, after migration each FAQ in the WRU may have to be manually updated to associate the document with a set of Routing Hints and a Mail Account. (For more information about Mail Accounts, see IC Administration Volume 1: Servers & Domains. For more information about Routing Hints, IC Administration Volume 2: Agents, Customers, & Queues.) 338 Software Upgrade and Data Migration May 2009

339 Migrate and chat data If desired, the FAQ-Queue associations from 5.6 SP1 can be reused and are migrated, however to take advantage of them you will need to customize the Web Management chat escalation pages and the Chat and WACD workflows. To add the tasktype to the chat escalation add the following line: ChatEscalate.setEduValue("tasktype", tasktype); below the other escalation parameters in IC_INSTALL_DIR/IC60/comp/website/ public/escalate.jsp For more information, please contact Avaya Technical Support. Self-service/FAQ changes In order to support localization and the use of Routing Hints and Mail Accounts (as described in Escalation Routing Changes, above) for Chat and escalations from the website, the Avaya IC Web Management Self-Service display stylesheets have changed. The following files in QeS_INSTALL_DIR\QeS56\chatserver\website\public\xsl have changed: display.xsl search.xsl grouping.xsl If you applied any customizations to these stylesheets, you need to reapply them to the corresponding Avaya IC stylesheets, located in IC_INSTALL_DIR\IC60\comp\ website\public\xsl. Administration page changes In 6.0.2, the Administration page stylesheets have changed. (In 5.6 SP1, these stylesheets are located in QeS_INSTALL_DIR\QeS56\chatserver\website\admin\wru\xsl.) If you applied any customizations to these stylesheets, you need to reapply them to the corresponding Avaya IC stylesheets, located in IC_INSTALL_DIR\IC60\comp\ website\wru\xsl. Configuration data changes To support changes made to Web Management, the localization of Chat and , and the new Chat features, a significant amount of Web Management configuration data (metadata) has been added. In addition, many pieces of the Avaya IC 5.6 SP1 configuration data are no longer used, although they will all be copied automatically to If one of the new Web Management configuration parameters has the same name as a custom piece of 5.6 SP1 configuration data, errors may occur when copying the 5.6 SP1 seed data as described in Update chat and data with the new schema on page 332. In this case, the custom configuration data will not be migrated. Software Upgrade and Data Migration May

340 Chapter 8: Migrating from Avaya IC 5.6 SP1 to Although most migrated metadata is still used in 6.0.2, some metadata sections and metadata elements are no longer used due to architectural changes. The following is a summary of how the migrated 5.6 SP1 metadata is used (listed by metadata section). Chat - Properties used in the Web Management web pages for escalation are still used. All chat metadata used for customizing the 5.6 SP1 chat client (chat.custom*) are no longer used and may be ignored. Chat client customizations are now found in chat.attributes.* and chat.phrases.*. - Properties still used. Fax - Properties still used. Flows - Properties still used. Security - Properties still used. Servers - Properties NOT used. Server data is now resolved using VESP or is maintained in the website configuration managed by IC Manager. Proactive contact and DataWake changes Proactive Contact is not supported in Avaya IC 6.0.2, however proactive contact filters and ripples will be migrated to and will still be used to define how DataWake information should be collected. In Windows, the DataWake configuration settings have moved from the registry to a configuration file called datawake.cfg that resides in IC_INSTALL_DIR\IC60\etc. Survey changes In Avaya IC 6.0.2, survey data has been moved from the w_wrap_survey table to the w_chat_wrap_survey table. (The new table is still in the CallCenterQ database.) The Chat and migration scripts, migrate_chat_ _script.sql and migrate_chat_ _script_ora.sql, copy data from the old table to the new table. If you have created custom columns in w_wrap_survey and you want to migrate the data in those columns to 6.0.2, you need to: 1. Add your custom columns to the new w_chat_wrap_survey table. To do so: a. Open the CallCenterQ ADL file (default name: ccq.adl) in Database Designer and add the custom columns. For details, see the IC Database Designer Application Reference. b. Reconfigure the CallCenterQ database. c. Save and close the CallCenterQ ADL file. 340 Software Upgrade and Data Migration May 2009

341 Migrate and chat data 2. Customize the Chat and migration scripts so that they migrate your custom data. To do so: a. Open the Chat and migration script you will be using (either migrate_chat_ _script.sql or migrate_chat_ _script_ora.sql) in an ASCII text editor and search for the following line: insert into w_chat_wrap_survey (chat_id, courtesy, speed, useful) select task_id, courtesy, speed, useful from w_wrap_survey b. Change this line to include the new columns. For example, if you to migrate the custom column mysurveyfield, you would change the above line to read: insert into w_chat_wrap_survey (chat_id, courtesy, speed, useful, mysurveyfield) select task_id, courtesy, speed, useful, mysurveyfield from w_wrap_survey c. Save your changes and close the migration script file. 3. Run the Chat and migration scripts as described in Update chat and data with the new schema on page 332. Make sure that you run this script only once. If you ran this script before you did your customizations, you must restore the back up you made after Verify the data migration on page 330 and start over. 4. Web Management accesses CallCenterQ data using the PDM database schema file (pdm.xml). Therefore, you must update the PDM file if you want to access a custom field. To do so: a. Open the PDM database schema file (default: IC_INSTALL_DIR\IC60\etc\ pdm.xml) in an ASCII text editor. b. Find the PDM entity defined by the path chat_wrap_survey, which appears in the PDM file as <PATHDEF name="/chat_wrap_survey">. Software Upgrade and Data Migration May

342 Chapter 8: Migrating from Avaya IC 5.6 SP1 to c. Add the following field definition to this entity: <FLDDEF dtype="<my_field_datatype>" name="<my_field_name>" xmltype="attr"> <DM_DCO fldname="<my_field_name>"/> <DMODBC fldname="<my_field_name>"/> </FLDDEF> For example, if you added the string field mysurveyfield, with the name aicsurveyresponse4, the field definition would look like this: <FLDDEF dtype="string" name="aicsurveyresponse4" xmltype="attr"> <DM_DCO fldname="mysurveyfield"/> <DMODBC fldname="mysurveyfield"/> </FLDDEF> d. Save and close the PDM database schema file. Routing changes Several changes have occurred with respect to Routing or Qualification of contacts, specifically to the use of Web Queues (Chat and ), Queues, Mail Accounts, WACD PLAID scripts, and WACD scripts. These changes are: Web Queues (Chat and ) are migrated to 6.0.2, however Web Queue to WACD PLAID script associations are no longer used. Queues (Incoming Queues or Pools) are no longer used in SP1 Queues are migrated to 6.0.2, and their Mail Template usage and reply address settings are applied to the Mail Accounts. Mail Accounts are migrated to and inherit the attributes of the 5.6 SP1 Queues (such as Mail Template associations and reply addressing). WACD scripts are no longer supported and are not migrated. You will need to reapply any customizations to the WACD scripts to the IC server and the WACD workflows. WACD PLAID scripts are no longer supported and are not migrated. You will need to reapply any customizations to the WACD PLAID scripts to the WACD workflows. WACD scripts are no longer supported and are not migrated. You will need to reapply any customizations to the WACD Scripts to the IC and WACD workflows. 342 Software Upgrade and Data Migration May 2009

343 Migrate and chat data Chat client changes In Avaya IC 6.0.2, the Chat architecture has changed significantly. The previous implementation included the WTC (Text Conferencing) server and an HTML application served by the IC Chat plugin. Shared browsing was implemented as a separate application which could be downloaded when needed. In 6.0.2, these components have been replaced by the ICM server and a Chat & Collaboration applet. These changes have the following effect on migration: The acuitysb virtual directory used for 5.6 SP1 shared browsing is no longer necessary and can be removed. Customizations made to the 5.6 SP1 chat client source code have to be reapplied to the Chat & Collaboration configuration parameters (found in Web Management configuration data chat.attributes.*) or in the applet template files (found in IC_INSTALL_DIR\IC60\comp\icm\default). For example, the HTML pages in QeS_INSTALL_DIR\QeS56\chatserver\icws\wtc\data\html\livehelp are no longer used in for the Chat Client. Any customizations to these pages will have to be applied to the new applet template files. Customizations made to the 5.6 SP1 chat client using Web Management configuration data (chat.custom.*) needs to be reapplied using the new Web Management configuration data (chat.attributes.*). The new Chat & Collaboration applet, by default, runs in a separate window from the user s browser. The applet template files can be modified to run the applet in the user s existing browser. Chat and workflow changes Architectural changes to Chat and required changes to the standard workflows used for Chat and authentication, escalation, and routing. The 5.6 SP1 Chat and Workflow projects and flows are not supported in Avaya IC Any customizations made to the 5.6 SP1 Chat and workflows must be reapplied to the workflows. The following projects must be opened in Workflow Designer, built and uploaded to the database from IC_INSTALL_DIR\IC60\design\IC\Flows\Avaya: IC \ic .prj WACD\wacd.prj Web_Routing\web_routing.prj WebCenter\webcenter.prj Software Upgrade and Data Migration May

344 Chapter 8: Migrating from Avaya IC 5.6 SP1 to The table below briefly describes the types of changes which have made to each of the 5.6 SP1 Chat and workflow projects. 5.6 SP1 Project(s) Project(s) Purpose Change wacd Qualify chat and tasks for routing. New for Qualification flow is called directly by WACD using VESP. Flow looks at routing hints and availability in making routing decision for chat and . Response is formatted for use by WACD. Replaces functionality previously implemented in qchat and qwc workflow projects and WACD PLAID scripting. ic Analyze incoming s. New for analysis, pre-qualification (authentication), content analysis, and outbound flows. Replaces WACD Scripting, WebCenter workflows. qchat Qualify chat tasks for routing. No longer used. Functionality moved to wacd project. qwc Qualify tasks for routing. web_routing web_routing Lookup workgroups for selected queues. webcenter webcenter Authenticate chat and customers. No longer used. Functionality moved to wacd project. No major functional change, however 5.6 SP1 flows may be incompatible. No longer used by for pre-qualification (authentication). For Web Management, the authentication workflow response is now sent using VESP rather than via the WebChannel. For more information about migrating workflows, see Migrate your existing workflows on page 349. For more information about changing workflows, see the Avaya Workflow Designer Guide. IC Script changes 5.6 SP1 Chat and IC Scripts are not migrated. Any changes made to the 5.6 SP1 IC Scripts will have to be manually reapplied to the new IC Scripts after the system has been completely configured. 344 Software Upgrade and Data Migration May 2009

345 Migrate Web Agent applications Historical data changes All 5.6 SP1 Chat and historical data is migrated to However, changes to the database schema and business rules make the 5.6 SP1 reporting tools incompatible with Therefore, while the historical data will be available, some modifications will be needed in order to report on that data. The major changes are: Migrated 5.6 SP1 Chat and tasks will be available for display in the agent s contact history browser, and they can be accessed for transcript review and history review in the same manner as entries. 5.6 SP1 survey data is migrated to will display on the web pages identically to new data. 5.6 SP1 DataWake data is migrated to and can be viewed using the Web Management administration pages can report on migrated chat and task data without modification. 5.6 SP1 reports are not supported in You will need to reapply any customizations to the reports. Migrate Web Agent applications 5.6 SP1 Web Agent configuration data contained in the Agent CDL layout file is not used in Before Agents will be able to connect to the system the location and port of the Paging server will have to be entered in the Agent:Desktop:WAC section of IC Manager properties. To edit these properties: 1. Log in to IC Manager. 2. Open the Group Manager by selecting Tools > Groups. 3. Select the Properties tab. 4. Select IC in the navigation bar, then select Agent/Desktop/WAC. 5. Double-click Server. 6. Enter the fully-qualified domain name of the Paging server in the Server field. 7. Select the OK button. 8. Select the OK button in Group Manager. Software Upgrade and Data Migration May

346 Chapter 8: Migrating from Avaya IC 5.6 SP1 to drafts drafts are not migrated from 5.6 SP1 to All tasks should be completed before the migration has started. Migrating agent resources and preferences Local and Global Web Agent Chat and resources can be migrated from 5.6 SP1 to using the Web Agent application. However, you must save the agent s resource files (*.WAC, *.RSC) before you uninstall the 5.6 SP1 Web Agent application and install the new Web Agent. For example, on the agent desktop, copy C:\Quintus\QeS56\ChatClient\ agent1\agent1.wac to C:\Temp, then copy C:\Quintus\QeS56\ChatClient\ agent1\agent1.rsc to C:\Temp. Although the 5.6 SP1 Web Agent application stores agent preference information in the agent s WAC file, these preferences will not be migrated when you open the 5.6 SP1 file in Therefore, if you want to save any of the agent preferences, you must make a note of them and then reapply them manually to the Web Agent application. If you installed your servers on a separate machine from your 5.6 SP1 servers, make sure that you have retired your 5.6 SP1 system and restored the machine name as described in After server migration has been completed on page 308 before you migrate your agent resources. To import the saved agent resource files: 1. Make sure you have saved the 5.6 SP1 resource files and made a note of any agent preferences that you want to save. 2. Uninstall the 5.6 SP1 Web Agent application. 3. Install the new Web Agent application. 4. Start Web Agent and log in. If you want to migrate an agent s global resources, the login you use must be assigned either the Supervisor or Administrator role. For details, see IC Administration Volume 2: Agents, Customers, & Queues. 5. Maximize the Web Agent by clicking the Avaya Web Agent button in the Windows toolbar. 6. To import the agent s local resource files: a. Select Resource > Import. b. Select the saved 5.6 SP1 WAC file. The Web Agent displays the 5.6 SP1 resources. 346 Software Upgrade and Data Migration May 2009

347 Migrate Message Care c. Drag and drop the root folder of the 5.6 SP1 resources to the Agent Resources folder in the Resource Pane of the Web Agent to copy all of the 5.6 SP1 resources to To import the agent s Global resource files: a. Select Resource > Import. b. Select the saved 5.6 SP1 RSC file. The Web Agent displays the 5.6 SP1 global resources. c. Drag and drop the root folder of the 5.6 SP1 resources to the Web Agent s Global Resources folder. 8. Optionally, reapply any agent preferences that you want to use in Close the Web Agent. Setting the home directory for agents In 5.6 SP1, you specified the agent s home directory using a property in the agent.properties file. This setting told Avaya IC where to find the agent s global resource file. In 6.0.2, you set the agent s home directory using the Homedir property in the Agent/ Desktop/WAC property subsection. (For details on setting this property, see IC Administration Volume 2: Agents, Customers, & Queues.) Migrate Message Care The Avaya IC DBMigrate tool migrates the content analysis-based data stored in your Message Care Messages and Outbound tables. It does not migrate customer history or customer data. To migrate your Message Care data, you need to set the connection information and then run DBMigrate using the migrate_messagecare.bat file. To set the connection information for DBMigrate: 1. Open IC_INSTALL_DIR\IC60\bin\Migration\messagecare_60.adl in Database Designer. CAUTION:! CAUTION: Do not reconfigure your database using this ADL or it will seriously damage your database. 2. Set your Connection information as appropriate. Software Upgrade and Data Migration May

348 Chapter 8: Migrating from Avaya IC 5.6 SP1 to Set the TIMEOUT interval based on the size of your database. Avaya recommends using at least Save and close the ADL file. To run DBMigrate: 1. Make sure that you have customized the DBMigrate tool to account for any changes you made to the 5.6 SP1 data model, as described in Customizing the DBMigrate tool on page 354. The XML file that DBMigrate will be using is IC_INSTALL_DIR\IC60\bin\ Migration\messagecare_60.xml. 2. Open a DOS prompt and navigate to IC_INSTALL_DIR\IC60\bin\Migration. 3. Run the migrate_messagecare.bat file. 4. When the process is finished, check the dbmigrate.log file to make sure the process completed without errors. Migrate your Avaya Agent CDL files There is no automated migration process for Avaya Agent CDL files. You should start with the out-of-the-box CDL files and reapply any customizations you made in 5.6 SP1. For details, see the Avaya Agent Integrator s Guide. Migrate your Avaya Agent EDU Viewer stylesheets There is no automated migration process for EDU Viewer XSL stylesheets. You should start with the out-of-the-box XSL files and reapply any customizations you made in 5.6 SP1. For details, see the Avaya Agent Integrator s Guide. 348 Software Upgrade and Data Migration May 2009

349 Migrate your existing workflows Migrate your existing workflows You cannot use your 5.6 SP1 workflows with an system. Therefore, you must use Workflow Designer to build the system workflows and load them into your migrated database. If you have customized any of the 5.6 SP1 workflows, you need to reapply your customizations to the workflows. (For details about using Workflow Designer, see the Avaya Workflow Designer Guide.) There have been several changes to the way flows are handled in Make sure you verify your customizations based on the information in the Avaya Workflow Designer Guide. To migrate the out-of-the-box workflows: 1. Open Workflow Designer. 2. Select File > Open Project. 3. Navigate to the directory IC_INSTALL_DIR\IC60\design\IC\Flows\Avaya. For each of the subdirectories in this directory: a. Double-click the subfolder and then open the project file that it contains. b. If you customized the corresponding 5.6 SP1 workflows in any way, reapply your customizations to the workflows in this project. (For details about the changes to Chat and workflows, see Chat and workflow changes on page 343. For details about changes to Letter Generator workflows, see Letter Generation workflow changes on page 350.) c. Build the workflows and save them to the database by selecting Build > Build Flowset. d. Select File > Open Project, navigate up one level back to IC_INSTALL_DIR\IC60\ design\ic\flows\avaya, and select the next folder in the list. Repeat this process until you have built the flows for all of the flowsets. 4. If your site uses the Siebel integration, navigate to IC_INSTALL_DIR\IC60\design\ IC\Flows\Siebel and build all of the flows for the projects under that directory. Customized workflow block changes Except for the Start block, all of your custom blocks can be copied into your workflows without modification. The Start block, however, has changed considerably in Avaya recommends that you reapply any customizations to an out-of-the-box Start block instead of trying to update your 5.6 SP1 Start block. If, however, you want to update your existing Start block, you need to: 1. Set the ToolkitTimeout input parameter on the Advanced tab to 0. Software Upgrade and Data Migration May

350 Chapter 8: Migrating from Avaya IC 5.6 SP1 to Add two variable declarations by locating the Dim statements at the top of script and appending the following statements to that section: Dim ssys_scripttimeout As String Dim ltoolkittimeout As Long 3. Change the session creation information by replacing the statement GetSession().SetSessionId "", {_DBNetwork} with set isession = GetUniqueSession({_DBNetwork}). 4. Add additional timeout logic by replacing the statement Toolkit.Timeout {_ToolkitTimeout} with the following statements: ssys_scripttimeout = Script.InputArg.data.FindValue("sys_scripttimeout") If Len(sSys_scripttimeout) > 0 Then ltoolkittimeout = CLng(sSys_scripttimeout)* 1000 Else ltoolkittimeout = CLng({_ToolkitTimeout}) End If If ltoolkittimeout > 0 Then Toolkit.Timeout ltoolkittimeout End If Letter Generation workflow changes If you have customized your Letter Generator workflows, then you can either reapply your customizations to the new workflows, or you can modify your 5.6 SP1 workflows and rebuild them using Workflow Designer. To do so: 1. Open Workflow Designer. 2. Select File > Open Project. 3. Open the system flow project called docgen.prj in the IC_INSTALL_DIR\IC60\ design\ic\flows\avaya\docgen directory. 4. Remove the line containing the following text: iqxmldoc.appendchild This line is no longer required as the root node is now appended to document object when it is created. 5. To build the workflows and save them to your database, select Build > Build Flowset. 350 Software Upgrade and Data Migration May 2009

351 Migrate your existing Prompter ActiveX controls The changed workflows are: addltmplrecord.qfd addmtonlink.qfd addrecord.qfd clonebatch.qfd clonerecord.qfd deletebatch.qfd deletedestination.qfd deleteitmpk.qfd deleteltmplrecord.qfd deletemtonlink.qfd deleteparagraph.qfd deleterecord.qfd deletetmplpk.qfd docgen.prj enctmpl.qfd findbatchrecord.qfd findltmplrecord.qfd findrecord.qfd findreports.qfd generatedocs.qfd getalldestinations.qfd getalllocations.qfd getallrecipients.qfd getbatches.qfd getdestinations.qfd getfieldsintable.qfd getitemdetails.qfd getitempkinbatch.qfd getitemsinbatch.qfd getitemtext.qfd getitemtextex.qfd getprinterinfo.qfd getrelationsetsandtbls.q fd gettemplatesinpk.qfd gettemplpacks.qfd imagelist.qfd images.qfd loadimages.qfd moveitmpkstobatch.qfd opentemplate.qfd processbatch.qfd sendalldocuments.qfd setbatchstate.qfd setitemtext.qfd startprocessbatch.qfd storeimages.qfd substpara.qfd templatetree.qfd updatebatch.qfd updateltmplrecord.qfd updaterecord.qfd For information about installing and configuring Letter Generation, see the IC Installation and Configuration Guide. Migrate your existing Prompter ActiveX controls Because of changes to the Prompter client, you need to replace all 5.6 SP1 versions of the Prompter ActiveX control with the control. To do so: 1. Start Database Designer and open your CCQ ADL file (IC_INSTALL_DIR\IC60\ design\ccq\ccq.adl). 2. Expand the Forms section under Components in the left-hand pane. 3. Expand the form that contains your Prompter control (default: qprompter). 4. Under that form, right-click the group that contains the control (default: qprompter) and select New Objects from the pop-up menu. 5. Select Generic ActiveX Control in the New Object dialog box and select Next. 6. Select QPrompter Control from the Insert Object dialog box and select the OK button. Software Upgrade and Data Migration May

352 Chapter 8: Migrating from Avaya IC 5.6 SP1 to In the New Object dialog box, make sure that the ActiveX ProgID is AvayaPrompterClient.PrompterClientCtrl.60. If it is, the control has been properly installed and you can enter the name QPrompterClient in the ActiveX control name field. When you are done, select Finish. 8. Delete the old object. 9. Optionally, link your IC Scripts to the Prompter events. 10. Select the tree-node for the newly-added dialog box object, and then select Edit > Form Layout. Database Designer opens the new dialog box in the Layout Editor. 11. If necessary, adjust the dimensions of the new dialog box so that both panes display properly. 12. Save the design and close the Layout Editor. Repeat this procedure for each form and group that contains a Prompter control. Migrate your existing IC Scripts 5.6 SP1 IC Scripts are not migrated. If you made any changes to the 5.6 SP1 IC Scripts, you need to manually apply them to the IC Scripts after the system has been completely configured., and then push your customized IC Scripts to the database. In this release, the format for writing IC Scripts has not changed. Therefore, you should be able to migrate your customizations by copying the customized code and pasting it into the new IC Script. Generate the Windows applications Once you have migrated the data, you can generate your Windows applications and perform your system tests. For details, see the IC Database Designer Application Reference or "Creating Business Applications" in the IC Installation and Configuration Guide. 352 Software Upgrade and Data Migration May 2009

353 Remove old QRepository data source Migrate WebQ WebQ is backwardly compatible with 5.6 SP1 WebQ. Simply regenerate your WebQ pages after you have migrated your other applications. Avaya does not recommend making any customizations to your generated WebQ HTML pages. All customizations should be done using the ADL. If, however, you have customized your HTML pages, you will need to reapply those customizations after you regenerate. Remove old QRepository data source If you changed the name of your CI Repository data source, you need to delete the 5.6 SP1 QRepository data source from IC Manager. To do so: 1. Open IC Manager. 2. Select Tools > IC Data Sources. 3. Under Repository > Physical DB Connections, select the old 5.6 SP1 QRepository data source name. 4. Select the Delete IC Data Source icon in the toolbar. 5. Exit from IC Manager. Migrate telephony For information about migrating telephony, see Migrating telephony from Avaya IC 5.6 SP1 to on page 371. Migrate QKnowledge To migrate QKnowledge: 1. Configure the QKnowledge Server and start IndexQ. For more information, see IC Administration Volume 3: FAQs, Document Collections, & Legacy Data. Software Upgrade and Data Migration May

354 Chapter 8: Migrating from Avaya IC 5.6 SP1 to Copy all external documents (maintaining their directory structure) from the old 5.6 SP1 machine to your new machine and recreate your document collections. 3. Index the collections using IndexQ. Customizing the DBMigrate tool If you have heavily customized your Avaya IC installation, you may need to customize the DBMigrate tool in order to accommodate those customizations, or check the results of the migration to what database fields were migrated. This section provides detailed information about how the tool works and explains how you can customize it. The DBMigrate tool takes data from the 5.6 SP1 databases and places it in the appropriate fields in the new datamodel. In performing this task, DBMigrate uses: An XML file specific to the database migration (for example, qrepository56_60.xml) ADL and ADC files specific to the migration (for example, qrepository56_60.adl and qrepository56_60.adc) A functioning database connection specified in the Transfer ADC. DBMigrate requires that the ADC specify an Avaya IC dataserver. The XML file contains instructions appropriate to the selected migration. DBMigrate uses a variety of XML elements to process each row in the database being migrated. If necessary, you can modify the XML file which specifies the processing. For details, see Modifying the XML file on page 360. For a list of available XML elements, see XML elements for DBMigrate tool on page 361. DBMigrate: Moves the data from the specified application database to the new CI Repository database Inserts seed data, if you select the "seed" parameter Creates a dbmigrate.log for information and errors depending on the logging level specified. Each invocation of DBMigrate allows for one and only one data transfer, as defined in the Transfer ADL. If you need to make multiple transfers, you need to run DBMigrate multiple times. 354 Software Upgrade and Data Migration May 2009

355 Customizing the DBMigrate tool Data schema changes in The data schema surrounding the Routing Event table in CI Repository has changed as shown below: Changes to site information There is a new site table that contains the site field from the 5.6 SP1 employee and queue tables. DBMigrate builds the site table based on the information in the employee and queue tables, and replaces the old site field with a site_key field that points to the site in the new site table. Changes to outcome, reason, and category code information There is a new classificationcode table that replaces the 5.6 SP1 outcomecodes, reasoncodes, and categorycodes tables. DBMigrate builds the classificationcode table by taking the name and value fields from the outcomecodes, reasoncodes, and categorycodes tables and appending a codetype field to each record that denotes whether the entry is an outcome code, reason code, or category code. Once DBMigrate has created the classificationcode table, it updates the taskperformedcode table based on the existing links in the taskperformed table by copying the pkeys from any records linked with an outcome, reason, or category code to the code_key field in the classificationcode table. Software Upgrade and Data Migration May

356 Chapter 8: Migrating from Avaya IC 5.6 SP1 to Finally, DBMigrate builds the localized table for international language support by setting the appropriate classificationcode_key in the localizedcode table. Changes to routing events, agent and media segments, and contacts DBMigrate moves all media-specific fields from the contact table to the mediainteraction table. It then creates an intersection table, called mediasegment, between routingevent and mediainteraction. In order to track agents who are working in several media channels simultaneously, the generic talktime and holdcount fields in the routingevent table have been replaced by media-specific fields. (The new fields are stored in the routingevent table.) To accommodate this, DBMigrate moves information from talktime and holdcount to the appropriate media-specific fields as follows: Old Field talktime holdcount New Field (based on type of media contact) writetime chattalktime voicetalktime inactcount chatholdcount voiceholdcount Finally, DBMigrate creates an intersection table, called agentsegment, between routingevent and employee. This intersection table eliminates the need for the agent_key field in the contact record. Working with the Migration ADL file The migration ADL file contains an application, which contains modules, tablesets, and tables. Application. The application node is the parent of two modules (source and target module). The application itself is not used in the XML, but it is used as a parameter in the bat file that executes the migration tool. Modules. There are two modules in the ADL, a source and a destination. A source module contains the source tableset and the destination module contains the destination tableset. They appear in the XML as: 356 Software Upgrade and Data Migration May 2009

357 Customizing the DBMigrate tool <SOURCEMODULE>q_migration_56</SOURCEMODULE> <DESTINATIONMODULE>q_migration_60</DESTINATIONMODULE> The data migration tool uses them to determine the source and destination locations within the ADL. TablesSets. There are two tablesets in the ADL, a source and a destination. A source tableset contains all the source tables and a destination tableset contains all the destination tables. (The same table might be in both tablesets if data is being moved from one field to another within the same table.) In the XML, all <OLDTABLENAME> parameters will be taken from the source tableset, and all <NEWTABLENAME> parameters will be taken from the destination tableset Tables. All tables required to perform the migration. Running DBMigrate You run DBMigrate using the migrate_qrepository.bat file or the migrate_messagecare.bat file. For details, see Run DBMigrate on page 327 and Migrate Message Care on page 347. Rerunning DBMigrate You may rerun DBMigrate once you have corrected any data issues identified in the dbmigrate.log. DBMigrate uses the Migrate database to identify where the database migration halted, and resumes the process from that point. If you want to rerun DBMigrate from the beginning, you need to delete all of the data in the Migrate database first. Software Upgrade and Data Migration May

358 Chapter 8: Migrating from Avaya IC 5.6 SP1 to Process flow The DBMigrate processing flow looks like this: For a full description of each XML tag reference in the Processing diagram, see XML elements for DBMigrate tool on page Software Upgrade and Data Migration May 2009

359 Customizing the DBMigrate tool Format of the XML file The XML files supplied for migration, such as ccq56_60.xml, are built from a series of XML tags. Each file has a nested structure; each section starts with a beginning tag and ends with a closing tag. Here is a sample XML file that adds the SME property to the Agent/Desktop/ / AlertInfo property section and then migrates one field: <PROPERTIES> <PROPSECTION Name="Agent/Desktop/ /AlertInfo/SME" Description=""> <PROPERTY Name="AlertDuration" Description="Time to wait for Alert to fire." RequiredFlag="1" PredefineFlag="0" CumulativeFlag="0" Datatype="integer" SystemFlag="1" TenantFlag="1" AgentFlag="1" WorkgroupFlag=""> <PROPINSTANCE InstanceLevel="system" OverrideFlag="1" Value_str="86400" Value_lt="" /> </PROPERTY> </PROPSECTION> </PROPERTIES> <TABLES> <TABLE> <OLDTABLE> <OLDTABLENAME>employee</OLDTABLENAME> <ORDERBY>pkey</ORDERBY> </OLDTABLE> <NEWTABLES> <NEWTABLE> <NEWTABLENAME>newemployee</NEWTABLENAME> <UPDATE> <ORCRITERIA> <ANDCRITERIA> <NEWCOLUMNNAME>workgroup_name</NEWCOLUMNNAME> <OLDCOLUMNNAME>name</OLDCOLUMNNAME> </ANDCRITERIA> </ORCRITERIA> </UPDATE> <COLUMNS> <COLUMN> <NEWCOLUMNNAME>fullname</NEWCOLUMNNAME> <NEWCOLUMNVALUE> <FROMOLDCOLUMN>empfullname</FROMOLDCOLUMN> </NEWCOLUMNVALUE> </COLUMN> </COLUMNS> </NEWTABLE> </NEWTABLES> </TABLE> </TABLES> All XML tags have the format <tagname...attributes...> [optional intermediate tags] </tagname> to show the start and end points for each tag. Software Upgrade and Data Migration May

360 Chapter 8: Migrating from Avaya IC 5.6 SP1 to Modifying the XML file You can customize any supplied migration XML file to your particular needs. A common customization for the ccq56_60.xml file would be to add <COLUMN> elements to migrate 5.6 SP1 custom fields you may have added to the CCQ employee table, so that your customized field is properly migrated to CI Repository in Avaya IC To modify the XML file for custom field migration: 1. Open the ccq56_60.xml file in an XML or ASCII editor. 2. Locate the XML elements which define the column migration to <NEWTABLENAME> employee. You will find a series of <COLUMN> elements, one for each column being migrated to the new employee table. <NEWTABLES> <NEWTABLE> <NEWTABLENAME>employee</NEWTABLENAME> <COLUMNS> <COLUMN> <NEWCOLUMNNAME>pkey</NEWCOLUMNNAME> <NEWCOLUMNVALUE> <FROMOLDCOLUMN>pkey</FROMOLDCOLUMN> </NEWCOLUMNVALUE> </COLUMN> <COLUMN> <NEWCOLUMNNAME>communicatepref</NEWCOLUMNNAME> <NEWCOLUMNVALUE> <FROMOLDCOLUMN>communicatepref</FROMOLDCOLUMN> </NEWCOLUMNVALUE> </COLUMN> <COLUMN> <NEWCOLUMNNAME>electronsignature</NEWCOLUMNNAME> <NEWCOLUMNVALUE> <FROMOLDCOLUMN>electronsignature</FROMOLDCOLUMN> </NEWCOLUMNVALUE> </COLUMN> Copy an existing <COLUMN>... </COLUMN> element. 4. Paste this element within the <COLUMNS>...</COLUMNS> element. 5. Modify the pasted section as follows: a. <NEWCOLUMNNAME>: new column name you have defined in the employee table in he new qrepository.adl b. <FROMOLDCOLUMN>: old column name from the employee_old table, from the 5.6 SP1 ccq.adl 360 Software Upgrade and Data Migration May 2009

361 Customizing the DBMigrate tool 6. Repeat Steps 4 and 5 for each field you have added to the employee table. 7. Save the file. XML elements for DBMigrate tool DBMIGRATE Description Root element of the XML document. Syntax Contains three elements: SOURCEMODULE, DESTINATIONMODULE, TABLES Element SOURCEMODULE DESTINATIONMODULE TABLES Description name of the source module as string name of the destination module as string contains one or more TABLE elements Example <DBMIGRATE> <SOURCEMODULE>m_migration</SOURCEMODULE> <DESTINATIONMODULE>m_migration</DESTINATIONMODULE> <TABLES>... PROPERTIES Description Root element of properties section. Syntax Contains PROPSECTION elements that contain one or more PROPERTY tags. Software Upgrade and Data Migration May

362 Chapter 8: Migrating from Avaya IC 5.6 SP1 to Example <PROPERTIES> <PROPSECTION Name="Agent/Desktop/ /AlertInfo/SME" Description="">... </PROPERTIES> PROPSECTION Description Example Contained by PROPERTIES tag, and contains one or more PROPERTY tags. Corresponds to a single record in propsection table. <PROPERTIES> <PROPSECTION Name="Agent/Desktop/ /AlertInfo/SME" Description=""> <PROPERTY Name="AlertDuration" Description="Time to wait for Alert to fire." RequiredFlag="1" PredefineFlag="0" CumulativeFlag="0" Datatype="integer" SystemFlag="1" TenantFlag="1" AgentFlag="1" WorkgroupFlag="">... PROPERTY Description Syntax Contained by the PROPSECTION tag and contains PROPINSTANCE and PROPVALUE tags. Corresponds to a single record in property table. Contains the optional elements PROPINSTANCE and PROPVALUE. Element Description PROPINSTANCE the inheritance level at which this property should be applied (for example, if you specify system for the PROPINSTANCE, then all objects in the Avaya IC environment will inherit that property. PROPVALUE the value of the property 362 Software Upgrade and Data Migration May 2009

363 Customizing the DBMigrate tool Example <PROPERTY Name="UADStringFormat" Description="Format to display Agent in the Directory Tree." RequiredFlag="1" PredefineFlag="1" CumulativeFlag="0" Datatype="string" SystemFlag="1" TenantFlag="1" AgentFlag="1" WorkgroupFlag=""> <PROPVALUE PredefineValue="Standard" Description="" /> </PROPERTY> TABLES Description Example Contained by DBMIGRATE. Contains one or more TABLE elements corresponding to each table mapping. <TABLES> <TABLE>... TABLE Description Example Contained by TABLES. Defines a table mapping from old table to new table(s). Contains two elements, OLDTABLE and NEWTABLES. You may have only one OLDTABLE element as tables are moved one by one. <TABLE> <OLDTABLE>... </OLDTABLE> <NEWTABLES>... Software Upgrade and Data Migration May

364 Chapter 8: Migrating from Avaya IC 5.6 SP1 to OLDTABLE Description Syntax Contained by TABLE. Defines the old table for mapping. To sort incoming data, use ORDERBY to indicate a sort column. Contains the elements QBE, OLDTABLENAME, and ORDERBY. Element QBE OLDTABLENAME ORDERBY Description constraints to be used during the table search name of the old table column used for sorting records internally Example <OLDTABLE> <QBE Field="acdsite" Value="!NULL" /> <QBE Field="exitreason" Value="foobar" /> <OLDTABLENAME>routingevent</OLDTABLENAME> <ORDERBY>uuid</ORDERBY> </OLDTABLE> NEWTABLES Description Example Contained by TABLES. Contains one or more NEWTABLE elements, as data from one old table can go into one or more new tables. <NEWTABLES> <NEWTABLE> Software Upgrade and Data Migration May 2009

365 Customizing the DBMigrate tool NEWTABLE Description Syntax Contained by NEWTABLES. Defines all data movement. One or more NEWTABLE elements may be defined; each element describes the new table receiving data from the specified old table. The old table was described via the OLDTABLE and OLDTABLENAME tags. Contains the elements NEWTABLENAME, COLUMNS, and, optionally, UPDATE. Element NEWTABLENAME COLUMNS UPDATE Description name of the new table contains one or more COLUMN elements (optional) contains one or more ORCRITERIA elements; if present, indicates data in the new table is to be updated rather than inserted; ORCRITERIA provides criteria to identify record for updating Example <NEWTABLE> <NEWTABLENAME>mig_workgroup</NEWTABLENAME> <UPDATE> <ORCRITERIA>... </ORCRITERIA> </UPDATE> <COLUMNS> <COLUMN>... </NEWTABLE> UPDATE Description Example Contained by NEWTABLE. Contains one or more ORCRITERIA elements, in turn providing ANDCRITERIA criteria to identify a record for updating in the new table. <UPDATE> <ORCRITERIA> <ANDCRITERIA> Software Upgrade and Data Migration May

366 Chapter 8: Migrating from Avaya IC 5.6 SP1 to <NEWCOLUMNNAME>workgroup_name</NEWCOLUMNNAME> <OLDCOLUMNNAME>name</OLDCOLUMNNAME> </ANDCRITERIA> </ORCRITERIA> </UPDATE> ORCRITERIA Description Example Contained by UPDATE. Contains one or more ANDCRITERIA elements, providing criteria to identify a record for updating in the new table. Multiple ORCRITERIA may be used to specify a record for updating. If no ORCRITERIA criteria are met, then the record from the old table is inserted. <ORCRITERIA> <ANDCRITERIA> <NEWCOLUMNNAME>workgroup_name</NEWCOLUMNNAME> <OLDCOLUMNNAME>name</OLDCOLUMNNAME> </ANDCRITERIA> </ORCRITERIA> ANDCRITERIA Description Syntax Contained by ORCRITERIA. Multiple ANDCRITERIA may be used to specify a record for updating. All ANDCRITERIA criteria must be met for the record to be updated. Contains pairs of elements to be matched, NEWCOLUMNNAME to OLDCOLUMNNAME or NEWCOLUMNNAME to CONSTANT. Element NEWCOLUMNNAME OLDCOLUMNNAME CONSTANT Description name of column in new table name of column in old table string constant for comparison to NEWCOLUMNNAME 366 Software Upgrade and Data Migration May 2009

367 Customizing the DBMigrate tool Example <ANDCRITERIA> <NEWCOLUMNNAME>workgroup_name</NEWCOLUMNNAME> <OLDCOLUMNNAME>name</OLDCOLUMNNAME> </ANDCRITERIA> COLUMNS Description Example Contained by NEWTABLE. Contains one or more COLUMN elements, providing information about all columns in the new table. <COLUMNS> <COLUMN> <NEWCOLUMNNAME>workgroup_name</NEWCOLUMNNAME> <NEWCOLUMNVALUE> <FROMOLDCOLUMN>name</FROMOLDCOLUMN> </NEWCOLUMNVALUE> </COLUMN> <COLUMN>... COLUMN Description Contained by COLUMNS. Each COLUMN element corresponds to a column in the new table. Contains elements NEWCOLUMNNAME, NEWCOLUMNVALUE, and optionally OVERWRITE. Element Description NEWCOLUMNNAME name of column in new table NEWCOLUMNVALUE element defining value of the new column OVERWRITE if element is present and "true" (case-insensitive), then value in column will be overwritten Example <COLUMN> <NEWCOLUMNNAME>workgroup_name</NEWCOLUMNNAME> <NEWCOLUMNVALUE> Software Upgrade and Data Migration May

368 Chapter 8: Migrating from Avaya IC 5.6 SP1 to <FROMOLDCOLUMN>name</FROMOLDCOLUMN> </NEWCOLUMNVALUE> </COLUMN> <COLUMN> <NEWCOLUMNNAME>app_key</NEWCOLUMNNAME> <NEWCOLUMNVALUE> <FROMOLDCOLUMN>pkey</FROMOLDCOLUMN> </NEWCOLUMNVALUE> </COLUMN> NEWCOLUMNVALUE Description Contained by COLUMN. Defines the value of the column in the new table. Contains elements FROMOLDCOLUMN, CONSTANT or COMPUTED. If the value for the new column comes from old column, then FROMOLDCOLUMN name should be defined. If a constant value, then CONSTANT element should be defined; if computed, then COMPUTED element is defined. Element FROMOLDCOLUMN CONSTANT COMPUTED Description name of column in old table holding value. Contains the elements LINKCRITERIA and MATCH. (For more information, see FROMOLDCOLUMN on page 369.) string constant defining new column value element defining computed value for new column Example <COLUMN> <NEWCOLUMNNAME>phonetype</NEWCOLUMNNAME> <NEWCOLUMNVALUE> <CONSTANT>pager</CONSTANT> </NEWCOLUMNVALUE> </COLUMN> <COLUMN> <NEWCOLUMNNAME>employee_key</NEWCOLUMNNAME> <NEWCOLUMNVALUE> <FROMOLDCOLUMN>pkey</FROMOLDCOLUMN> </NEWCOLUMNVALUE> </COLUMN> 368 Software Upgrade and Data Migration May 2009

369 Customizing the DBMigrate tool FROMOLDCOLUMN Description Contained by NEWCOLUMNVALUE. Defines the name of the column in the old table. Contains the element LINKCRITERIA, which contains the element MATCH. Element LINKCRITERIA MATCH Description used to extract a field value from parent table based on a foreign key. Contains the MATCH element. used for specifying search constraints Example <FROMOLDCOLUMN> holdcount <LINKCRITERIA TableName="contact" ForeignKey="contact_key"> <MATCH ColumnName="type" ColumnValue=" " /> </LINKCRITERIA> </FROMOLDCOLUMN> COMPUTED Description Contained by NEWCOLUMNVALUE. Enables computation of the column value in the new table. May contain two different sets of elements: (FROMTABLE, FROMCOLUMN and ORCRITERIA) or (APPEND and SEPARATOR). The first set indicates to DBMigrate that the value for the new column comes from a table other than the old table. ORCRITERIA allows conditional searching for a value in the old table. Only one ORCRITERIA (and, in turn, ANDCRITERIA, is allowed. The second set of elements enables the appending of data from two separate columns inserting a specified separator. Element FROMTABLE FROMCOLUMN Description name of source table holding value name of source column holding value Software Upgrade and Data Migration May

370 Chapter 8: Migrating from Avaya IC 5.6 SP1 to Element ORCRITERIA APPEND Description element defining OR criteria in searching for data in old table element defining columns to be appended Example <NEWCOLUMNVALUE> <COMPUTED> <APPEND Separator=" "> <NEWCOLUMNNAME>firstname</NEWCOLUMNNAME> <NEWCOLUMNNAME>lastname</NEWCOLUMNNAME> </APPEND> </COMPUTED> </NEWCOLUMNVALUE> APPEND Description Contained by COMPUTED. Contains either OLDCOLUMNNAME or NEWCOLUMNNAME elements. DBMigrate may use these elements as input for computing new column values. SEPARATOR defines string for separating column values in the new column. Element OLDCOLUMNNAME NEWCOLUMNNAME SEPARATOR Description name of column from old table holding value name of column from new table holding value string value serving as separator Example <NEWCOLUMNVALUE> <COMPUTED> <APPEND Separator=" "> <NEWCOLUMNNAME>firstname</NEWCOLUMNNAME> <NEWCOLUMNNAME>lastname</NEWCOLUMNNAME> </APPEND> </COMPUTED> </NEWCOLUMNVALUE> 370 Software Upgrade and Data Migration May 2009

371 Chapter 9: Migrating telephony from Avaya IC 5.6 SP1 to This chapter describes the migration impact when upgrading the Avaya Telephony server (TS) from Avaya Interaction Center 5.6 SP1 to Avaya Interaction Center It provides the basic procedures involved in the migration process and evaluates the data element differences between the 5.6 SP1 and releases. Prerequisites Avaya Interaction Center 6.0 supports specific versions of the following telephony products, but not their emulations or variants. Users migrating from 5.6 SP1 to may need to upgrade their environment to support the telephony products running on their system. Avaya Definity and MultiVantage products Aspect CallCenter switches Nortel Meridian switches Nortel Symposium switches Interactive Voice Response systems Refer to the IC Installation Prerequisites Guide for detailed information on the specific versions of the products that are supported and their prerequisites. Avaya Definity and MultiVantage Users running Avaya Definity and MultiVantage products on must upgrade to the following versions of CVLAN and the adjunct link: CVLAN Server 8.2.1, mode 6 or 8, on MAPD CVLAN Client ADJLK Adjunct Link (not ASAI Adjunct link) configured on the switch Software Upgrade and Data Migration May

372 Chapter 9: Migrating telephony from Avaya IC 5.6 SP1 to Nortel Meridian Users running Nortel Meridian or Symposium 4.0 switches on must upgrade their CT Connect software from version 4.0 to version 5.0. Call tracking When a call left the 5.6 SP1 system, for example it was routed or transferred to a device that was not monitored by the TS, it was still tracked and reported on by 5.6 SP1. In 6.0.2, a call that leaves the IC system is handled differently. The TS calculates the amount of time the contact was in before it left, writes that time to the EDU, then terminates the EDU. There are two possible scenarios: If the switch supports persistent application data in the switch and the call comes back into IC from the non-monitored device within the configured "nouserinterval" period of time, the EDU is preserved and the TS proceeds as if the call never left If the switch does not support persistent application data in the switch or if the call remained outside of for longer than the configured "nouserinterval" period of time, the original EDU is retired by the TS and a new EDU is created. Container formats Voice contact containers (call containers) have been improved in with a new, standardized format. In 5.6 SP1, the TS wrote two sets of voice contact containers, one with a prefix of "ts" and one with a prefix of "voice". In 6.0.2, the containers with a "ts" prefix are discontinued. Contact centers that use 5.6 SP1 voice contact containers with a "ts" prefix must re-configure their TS to use container formats with a "voice" prefix. Refer to the IC Installation Prerequisites Guide for details on the supported switches and versions. To use container formats: 1. Start IC Manager if it is not already running. 2. Select the Server tab. 3. Select the TS from the list of servers in the Server Manager to display the Server Editor dialog. 4. Select the TS tab to display basic configuration parameters. 372 Software Upgrade and Data Migration May 2009

373 Container implementation 5. Right-click and select Show Advanced Properties to display advanced configuration parameters. 6. Check the check box for the Use 6.0 State Fields to enable the new container formats. 7. Select the OK button to save the new setting. Container implementation The implementation of the voice contact containers (containers) on all supported switches was modified in to provide more meaningful data for reporting. In 6.0.2, containers are only created for a queue if the call is abandoned while in the queue. Containers are not created for route points in Avaya IC 6.0. Detailed information on 6.0 container implementation is available on the through the web at These containers were originally modified for Avaya IC 6.0.1, the layout of the containers is the same in and To access this information from the website: 1. Enter your login id and password at the Login screen. 2. Select Login. 3. Select the Product Documentation link. 4. Select the Avaya Interaction Center link. 5. Select IC Voice Contact Containers from the list of available documentation. If you do not have a WebQ username and password, and you are an approved Avaya Technical Support contact, please sent an to Avaya CRM Support (crmsupport@avaya.com) along with your preferred username and password. Tip: Tip: Your username and password must be at least six characters long, your password must contain at least one number, and your username and password cannot be the same. Software Upgrade and Data Migration May

374 Chapter 9: Migrating telephony from Avaya IC 5.6 SP1 to Event reporting When a call is received by an agent and either transferred or conferenced to a second agent, the switch reports a transfer or conference event to some of the devices that handled the call. The TS.Conference.event and the TS.Transfer.event are reported to the agent who initiated the transfer or conference and to only those devices that changed their call id as a result of the transfer or conference. Call id changes vary based on how the individual switch handles the transfer or conference. For example, Avaya Definity switches handle transfers and conferences differently than Aspect CallCenter switches, therefore changes to the call id occur at different devices for each of these switches. On most switches events are only sent when the call id changes. Avaya Definity switches may send events to the devices that handled even if the call id does not change, in which case they get whatever is from the switch. Multi-Site Heterogeneous Switch Avaya IC provides Multi-Site Heterogeneous Switch (MSHS) functionality to enable transfers and routing of voice contacts between switches regardless of switch type or location supports MSHS functionality on selected versions of Avaya Definity, Nortel Meridian, and Aspect CallCenter switches. Refer to the IC Installation Prerequisites Guide for details on the supported versions of these switches. Switch configuration The Reserved DN Pool configuration parameter for the switch is changed due to the introduction of MSHS. The Reserved DN Pool parameter enables you to reserve phone numbers for each of the switches between which you want to communicate. For detailed instructions on reserving phone numbers for MSHS, refer to the Telephony Connectors Programmer s Guide. Telephony server configuration provides new configuration parameters for the Telephony server to support Multi-Site Heterogeneous Switch functionality. For detailed instructions on configuring the Telephony server for MSHS, refer to the Telephony Connectors Programmer s Guide. 374 Software Upgrade and Data Migration May 2009

375 Avaya Definity IC Database tables The IC Database requires the following new tables to support MSHS. These tables need to be created in IC Manager and populated before MSHS operations can be performed. Table Name Dial Translation Multiple ANI Reserved DN Transfer Resolution Values Multiple lines of four fields containing: 1. Sequence of numbers that must match the beginning of the PSTN number for the rule to apply. An asterisk may be used to indicate any number. 2. Boolean value indicating if the matching prefix should be removed or not. 3. Number(s) that must be pre-pended to the resulting number. 4. Number(s) that must be appended to the resulting number. Multiple lines of one field containing sequences of digits blocks (for example, , 081x, 9123). Multiple lines of two fields containing: 1. Dialable numbers digits block (DID Range). 2. Routing point s digits block or digits block for the DNIS followed by an asterisk and a single route point. Multiple lines of four fields containing: 1. Alias or UUID of the destination TS. 2. Boolean value indicating if the connection to this TS supports TakeBackAndTransfer. 3. Boolean value indicating if the connection to the destination TS can be done using ISDN UUI. 4. Sequence of numbers to be pre-pended to the device number found in the ADU in order to reach the destination TS. Avaya Definity The port of the interface to the Avaya Definity switch was changed from a "C" code-based, mono-threaded TS in 5.6 SP1 to a "C++" code-based, multi-threaded TS in The migration impact of this change affects the following: Device Assignment TS.Assign Parameter Software Upgrade and Data Migration May

376 Chapter 9: Migrating telephony from Avaya IC 5.6 SP1 to Voice Contact Containers Events Workflow Assignments Device assignment In 6.0.2, the assignment for Adjunct Route requires an explicit VDN, TS.Assign("*r4771"), where "4771" is the VDN. In this scenario, a client application interested in route requests for "4771" will not see the request for "5991", which allows for multiple Workflow servers. TS.Assign parameter The input parameter *rvdn was added to the TS.Assign method for the Definity TS. This parameter enables the routing point to get the call and make it available for a routing decision. This returns all the Adjunct Route Requests that are associated with the MAPD to the TS after filtering them so the TS only sees those that came from such a VDN. Please note that the original *r parameter is not supported in Workflows that use *r will need to list the VDNs to which they are listening. Voice contact containers The Agent Data Unit (ADU) is a record created each time the agent logs into the Avaya Agent, which contains information about the agent s activities during their session. The Electronic Data Unit (EDU) is a record of the customer s activities over the course of their contact with Avaya IC. In 6.0.2, the following values are added to the voice contact container values that are always written to the ADU and the EDU by the Avaya Definity TS. primary_ani primary_dnis In 6.0.2, the following values are no longer written to the Agent Data Unit and the Electronic Data Unit by the Avaya Definity TS: L_ucid (renamed to ucid in 6.0.2) lai_dnis 376 Software Upgrade and Data Migration May 2009

377 Avaya Definity Events The Definity TS supports the following events. Some of these events are new in and some provide different data on common events between the 5.6 SP1 Definity TS and the Definity TS. Call events TS.Abandoned TS.Busy TS.Conference TS.Connect TS.Disconnect TS.Diverted TS.Drop TS.Hold TS.HoldReconnect TS.IncomingCall TS.Ring TS.Transfer Agent events TS.AuxWork TS.Login TS.Logout TS.Ready TS.Rona TS.WrapUp In 6.0.2, the following elements are added to the TS.IncomingCall.Event event for the Avaya Definity TS: primary_ani primary_dnis The element "monitor" has been added to all of the events for the Avaya Definity TS. Software Upgrade and Data Migration May

378 Chapter 9: Migrating telephony from Avaya IC 5.6 SP1 to Workflow assignment The workflow routing point assignment criteria needs to be adjusted to include the VDN in the TS.Assign method because the Telephony server requires the VDN as part of the assignment criteria in This feature applies to all the switches that are supported in For details on the supported switches and versions, refer to the IC Installation Prerequisites Guide. For Example: status = Vesp_Assign_Request( "TS.Assign", &ev, callback, user_data, event_callback, session, "*r1221" ); where 1221 is the VDN. The parameter *r is no longer supported. Workflows that use *r must list the VDNs to which they are listening. The flows themselves need adjustment only if the flows are written to scan events for VDN information and route based on this data. This feature allows you to assign multiple workflows to the same Telephony server in 6.0.2, which was not supported in 5.6 SP1. Aspect CallCenter supports the Avaya CallCenter 8 switch. To take advantage of the feature set on the Aspect TS, you must migrate from Aspect CallCenter 7 to Aspect CallCenter 8. Device assignments The 5.6 SP1 implementation of the TS in an Aspect environment requires a workflow to take incoming call events and to adjunct route calls. The TS also performs some EDUID operations (GetOneValue, and SetOneValue) that are controlled by the CCTs, via subtype field on CIM (001) messages. As a result, the TS has a set of "well known" subtypes. In 6.0.2, this TS only monitors and reports events on devices with client applications assigned to them. This applies to all switch interfaces to standardize the behavior of the TS across switches. The TS does not know which kind of client to which it is assigned to receive events and post requests. The TS.Assign method uses specific qualifiers in to determine what kind of device is being monitored, as well as, what kind of behavior is to be expected from the device. The following devices are supported on this interface: station teleset/agents 378 Software Upgrade and Data Migration May 2009

379 Aspect CallCenter route points data exchange with EDUIDs data exchange between CCTs and client applications Events The Aspect TS supports the following events. Some of these events are new in and some provide different data on common events between the two versions of the Telephony server. Call events TS.Abandoned TS.Busy TS.Conference TS.Connect TS.Disconnect TS.Diverted TS.Drop TS.Hold TS.HoldReconnect TS.IncomingCall TS.Ring TS.SendData TS.Transfer Agent events TS.AuxWork TS.Login TS.Logout TS.Ready TS.Rona TS.WrapUp Software Upgrade and Data Migration May

380 Chapter 9: Migrating telephony from Avaya IC 5.6 SP1 to Data posting to/from EDUs Data Posting is a convenient feature of the 5.6 SP1 Aspect TS, which allows data passing to and from the CCT via SendData and ReceiveData steps. If a subtype starting with elements "gv", or "sv", is detected on a CIM, the TS treats the subtype as an EDU transaction. "gv" indicates GetOneValue "sv" indicates SetOneValue The data element follows the "gv/sv" on the EDUID. The "gv" operation means that the CCT will be "waiting", on a ReceiveData step, for the associated value gathered from the EDUID. This value is returned to the CCT on "data_d". The EDUID is passed along on field "data_e". The "sv" operation sets a value on a EDUID. This architecture replicates the functionality on the 5.6 SP1 Aspect TS. Workflow Unlike the 5.6 SP1 Legacy Aspect TS, the Aspect TS requires explicit assignment for route points, and subtypes associated with EDU field values. These requirements impact workflow migration because assignments need to be adjusted and flows need to be revisited to handle events and requests in a different fashion. These modifications cause the Aspect TS to use a limited number of sessions, which do not increase. It also provides for load balancing across multiple Workflow servers. Because the Aspect CallCenter switch does not support an adjunct route step on a CCT, route points are implemented via a combination of Call Information Messages (CIM, or 001 message), subtype, and Receive Data. The workflow assigns for a given subtype, via TS.Assign("*rVALUE"), where VALUE is a subtype from a given CIM step on any CCT. This assignment causes the TS to monitor for a CIM with a subtype equal to the VALUE in the assign operation. When that subtype is detected, the TS issues a Route Request to the upper layers. This route request makes its way to Workflow server as an TS.IncomingCall event. Since the next step in the CCT is a Receive Data, the Workflow server can issue a TS.Route request. 380 Software Upgrade and Data Migration May 2009

381 Aspect CallCenter Data exchange with client applications Although the "gv/sv" transactions provide the Aspect TS with a good way to sync up to a CCT, this approach does not provide a completely generic solution. Furthermore, since the objective is to disrupt the production environment during migration as little as possible, backward support for one event: TS.SendData, and one method: TS.ReceiveData, is necessary. The TS.SendData event is generated when a SendData step is posted from a CCT to a subtype that does not start with "gv or sv", and was properly assigned by a client application. The TS.AssignRequest qualifier for this feature is "*s" such as, TS.Assign("*sLANGUAGE"). On this scenario, a CIM to subtype "LANGUAGE" triggers a TS.SendData event to the client application. The client application sends a TS.ReceiveData request to the TS, which generates a CIMR (message 601) back to the CCT to satisfy a CCT ReceiveData step. The TS.ReceiveData.Request takes a SeqCouples which is translated to variables "data_a" through "data_e", "cct", and "resp", on a CIMR message (601). By default, "resp" is NAK. If "resp" is ACK, the "cct" field is set on the CIMR message, which causes CCT execution to branch to the top of the "cct". This is a mechanism through which route points (adjunct routing) can be implemented. However, the standard method to respond to a route request (route points) is through the TS.Route method. The assign criteria for a Route Point is "*r" such as, TS.Assign("*rRP001"), which causes a TS.IncomingCall event to the client application monitoring CIM messages with subtype "RP001". The TS.Route request also generates a CIMR record. External requirements CCTs The 5.6 SP1 Aspect TS could operate solely on Application Bridge messages. The Event Bridge is a requirement for the Aspect TS. 5.6 SP1 uses a set of standard CCTs throughout the system that are responsible for: External Call Make Call Route Transfer Transfer Init Predictive Software Upgrade and Data Migration May

382 Chapter 9: Migrating telephony from Avaya IC 5.6 SP1 to For example, the IncomingCall CCT used to have a reserved subtype = "startcall" to indicate to the TS that a brand new call has arrived at the contact center. This same functionality can be achieved through route points, but without the restriction to one workflow, and the subtype can have any value. Startcall is no longer a reserved subtype. In 6.0.2, the Transfer CCT has been replaced by the Blind Transfer CCT. Reserved subtypes The Aspect event "subtype" coordinates incoming route requests and the general communication of data between the Aspect CallCenter switch and the Telephony server. When a Call Information Message (CIM) is received by the switch, it is examined to determine if it is defined as reserved, which means the subtype is not used in any CIM except one that is automatically generated by the Aspect CallCenter System as a result of a make predictive call request.refer to Telephony Services for Aspect CallCenter for more detailed information about subtypes. The following table contains the Aspect subtypes used in 6.0.2: Subtype ANS_ ANSM_ BUSY_ destbusy ERR FBUSY_ gv* INVCCT Description The call is answered by a human being. The call is answered by an answering machine. The call is busy for one of the two following reasons: a busy tone is detected. an ISDN code 17 (user busy) is detected. The call destination is busy. The call was disconnected because of a software error. Indicates problems with the telephone network. a fast busy (reorder) is detected. a number unobtainable tone is detected. the call was cleared on the ISDN trunk with a code other than 16, 17, 19, 22, 31. VDU.GetOneValue - EDUID is on data_e. The EDUID element name is encoded on the subtype. The response is posted on data_a. The call was disconnected because a CCT step that is not allowed for predictive virtual agent was encountered. 382 Software Upgrade and Data Migration May 2009

383 Aspect CallCenter Subtype NANS_ newtrans NOAD NORMAL preptrans REDIRECTED RLS_ sv* TRUNK Description The call is not answered for one of the following reasons: no tone or voice for a period of 10 seconds. country code too long. the ring no answer time-out was exceeded (simple no answer). an ISDN code 19, no answer received. The CCT has just executed a NEWTRANS step. It uses information stored via preptrans to send ChangeRefld events to the upper layer informing the TS of the new call id. The call was disconnected because the TS could not access the port for the answering machine. Two reasons a call is launched, but quickly dies. The Aspect CallCenter does not distinguish between these two for the client. The TS sent a call release message before the call could be classified. The IC system started to launch the call, but then changed and intentionally terminated the call. An incorrect CCT disconnected the call before the "wait for answer" step or the CCT ended before the "wait for answer" step. Indicates that a NEWTRANS step is about to occur. It saves the EDUID and the current active call id for processing when the NEWTRANS is completed. The call is sent to a different number than the one dialed. The call is launched, but quickly dies. This is the result of one of the following causes: a trunk answer followed by an immediate release. an ISDN code 16, a normal clearing or disconnect before call classification could occur. as ISDN code 31, a normal, unspecified disconnect before call classification could occur. VDU.SetOneValue - EDUID is on data_e. The EDUID element name is encoded on the subtype. The value is posted on data_a. The call was disconnected after a trunk was selected due to an unexpected trunk disconnection or error at one of the following times: before the "wait for answer" CCT step. during the "wait for answer" CCT step. Software Upgrade and Data Migration May

384 Chapter 9: Migrating telephony from Avaya IC 5.6 SP1 to Nortel Meridian and Symposium There are only a few changes to the Telephony servers for the Nortel Meridian and the Nortel Symposium switches because the code base is essentially the same as it was for 5.6 SP1. The EDU container implementation outlined in Container implementation on page 373 applies to these Telephony servers. There are also some event changes in that apply to these servers. Transfer event change In 5.6 SP1, when a contact was transferred from one agent to a second agent, the agent transferring the contact received a TS.Disconnect.Event once the contact was successfully transferred to the second agent. The second agent, who received the transferred contact, got a TS.Transfer.Event. In 6.0.2, the agent transferring the contact to a second agent receives a TS.Disconnect.Event and a TS.Transfer.Event once the contact is successfully transferred to the second agent. The second agent, who received the transferred contact, still gets a TS.Transfer.Event. Party list for transfers and conferences In 6.0.2, when a contact is either transferred to or conferenced with multiple agents on the system, information about these agents or parties is added to the appropriate event. This party list is added to the TS.Transfer.event or the TS.Conference.event based on whether the call was transferred or conferenced. The party list is underlined in the following example of a TS.Conference.event. The first entry provides the phone number the contact used to access The second, third, and fourth entries are the extension numbers of the agents who were conferenced into the contact.![ts.conference.event({0,"ts.conference",{0,11,{"vdu_id","3de60bd ac148a "},{"call_ref_id"," "},{"new_call_ref_id"," "},{"orig"," "},{"number_in_call","4"},{"dest"," "},{"dest","8609"},{"dest","3372"},{" dest","3371"},{"queue","5609/4371"},{"monitor","3372"}}})] 384 Software Upgrade and Data Migration May 2009

385 Appendix A: Detailed changes for Avaya IC and Avaya OA from to This appendix describes several detailed changes that have been made to Avaya IC and Avaya OA when upgrading and migrating from to This section includes the following topics: Data model changes from to on page 385 Avaya Agent IC Script changes on page 390 Chat & IC Script changes on page 405 Avaya IC workflow changes on page 405 RowDate data changes in Avaya OA on page 415 Data model changes from to This section describes the data model differences for Avaya IC and Avaya OA when going from to This section includes the following topics: Data model changes for Avaya IC on page 385 Data model changes for Avaya OA on page 389 Data model changes for Avaya IC The following changes have been made to the CallCenterQ and IC Repository databases. The HRQ and CustomerQ databases have not changed in Software Upgrade and Data Migration May

386 Appendix A: Detailed changes for Avaya IC and Avaya OA from to CallCenterQ data model changes New tables: The following tables have been added to the CallCenterQ database for 6.1.3: Table Name Excontactmap excustomermap exorganizationmap linkgroup lrmid routingattempt servicetag Data Source ccq repository New keys: The following new keys have been added to the CallCenterQ database for 6.1.3: Table Name employee mediainteraction repos_contact Key Name linkgroup_fkey lrmid_fkey customer_fkey organization_fkey customer_idx organization_fkey New fields: The following new keys have been added to the CallCenterQ database for 6.1.3: Table Name appprofile customer employee Mediainteraction queue Field Name flag_dupcustcheck secondname secondlastname linkgroup_key lrmid_key customer_key organization_key outboundcallnumber audiosource 386 Software Upgrade and Data Migration May 2009

387 Data model changes from to Table Name repos_contact wc_auth Field Name sbl_contact_key sbl_activity_key cbrequesttime cbrequestcreatetm cbrequestnumber jobid description organization_key mediadirectionmask dialerid Externalid Datasource subdatasource IC Repository data model changes New tables: The following new tables have been added to the IC Repository database for 6.1.3: Table Name addressbookhistory addressbookmark linkgroup lrmid passwordchange Routingattempt Servicetag excontactmap excustomermap exorganizationmap exorganizationmap organization w_offline_task Data Source Repository Application Software Upgrade and Data Migration May

388 Appendix A: Detailed changes for Avaya IC and Avaya OA from to New keys: The following new keys have been added to the IC Repository database for 6.1.3: Table name Agentsegment contact Employee mediainteraction mediasegment propsection routingevent Key name routingevent_idx createtime_idx mediadirectionmask_idx organization_fkey linkgroup_fkey lrmid_fkey contact_idx customer_fkey organization_fkey mediainteraction_idx name_uid queue_idx New fields: The following new fields have been added to the IC Repository database for 6.1.3: Table Name contact Contentsample creationrules Employee fieldexpressions Field Name description organization_key mediadirectionmask dialerid countrycode Rulestatus history lrmid_key linkgroup_key serverprocess_uuid Rulestatus history 388 Software Upgrade and Data Migration May 2009

389 Data model changes from to Table Name mediainteraction Mediasegment Property Propinstance Propsection Propvalue queue Routingevent wc_auth Field Name customer_key organization_key outboundcallnumber typecode abandonment_state abandon_time Minimumvalue maximumvalue history history history history Audiosource Waitannouncementid Waitringbackid announcementlength Activemediamask svcclassid Externalid Datasource subdatasource Data model changes for Avaya OA For a detailed description of the data model differences for both real-time and historical data, see the Customer Interaction Repository Data Models on the Avaya OA software CD-ROM. The historical data model differences may provide further insight to the operations of the to data migration. To view the data models: 1. Use Windows Explorer and navigate to the \docs\data_models folder on the software CD-ROM. 2. Double-click the index.html file. The data model opens in Internet Explorer (or your default browser). Software Upgrade and Data Migration May

390 Appendix A: Detailed changes for Avaya IC and Avaya OA from to Avaya Agent IC Script changes Because of the large number of changes to the IC Scripts in 6.1.3, the easiest way to migrate is to start with a working Avaya IC environment and reapply any customizations you have made, as described in Migrate IC Scripts, workflows, and Avaya Agent files on page 199. If, however, you want to use your existing Avaya Agent IC Scripts, the following sections detail the changes that have been made in One architectural change is that all the QSC files have been broken into individual QSC files, with one IC Script per file. This makes source code management easier. Multiple developers can be working on IC Scripts for same component without running into file contention issues. In addition, future migrations will be easier because you can compare individual IC Scripts to each other. This section contains two tables. The first shows all of the Avaya Agent IC Scripts and denotes the changes that have been made to those scripts. The second shows all of the IC Scripts that have been removed in Both of these tables refer to. Mass changes: Mass changes are one or more small changes that were made across a large number of IC Scripts. The two mass changes in are: 1. The Softphone_GetTelephony and QConsole_GetCoreServices IC Scripts are no longer used just to get the Objects that can be directly retrieved from the Phone Engine: Set icoreservices = iapp.getactivexcontrol( PhoneEngine ).GetCoreObject or Set itelephony = iapp.getactivexcontrol( PhoneEngine ).GetTelephonyObject 2. The Integration Hook concept that was introduced in has been added to all of the IC Scripts. For more information, see Chapter 4 in Avaya Agent Integration. Major changes: Major changes are complex changes that enhance or fix an IC Script. The major changes are: 1. Added support for a second EDU Viewer in Avaya Agent (called EDUViewer2 ) that is kept exactly in sync with EDUViewer. 2. Replaced the individual Chat and Login/Logout Options in the Avaya Agent Context Menu with a single Web Agent Login / Web Agent Logout menu item. 3. Replaced the properties that set the server and port for the WebACD and HTTPConnector with server parameters that specify those values. 4. Changed the TaskState constants. 390 Software Upgrade and Data Migration May 2009

391 Avaya Agent IC Script changes 5. Significantly changed the Unified Agent Directory (UAD) GUI, including the addition of buttons that initiating Softphone operations (Initiate, Transfer, Conference, and Consult). Many IC Scripts were changed to support the new UAD. 6. Introduced caching of the Interaction State in Avaya Agent to improve WrapUp handling. 7. In 6.1.3, IC Scripts now use the Change event from the TaskList instead of the individual events (such as Incoming, Select and Wrapup ). This change permits integrators to access all events using a single Integration Hook. 8. Introduced a WrapUp Engine to read and write WrapUp data. Parameter changes: Parameter changes are change to the parameters that must be passed to the IC Script. Other changes: Other changes are relatively simple, and isolated, changes that enhance or fix an IC Script. Avaya Agent IC Scripts in The following IC Scripts are located in: IC61_INSTALL_DIR\IC61\design\QConsole: IC Script Affected by Comments ACViewer_Initialize Mass change #1 ACViewer_LoadSpecsFromDB ACViewer_RefreshContact Mass change #1 BlenderClient_ADUChange Mass change #2 BlenderClient_AgentStateEvent Mass change #2 Other changes BlenderClient_ChannelStateEvent QConsole_ChannelEnabled btnoperation_click CHBrowser_AddContact Other changes CHBrowser_GetActiveContactCriteria CHBrowser_Initialize Mass change #2 New in Handles Channel State Changes from Blender Client. Formerly called ChannelEnabled. New in Handles Softphone button clicks. Software Upgrade and Data Migration May

392 Appendix A: Detailed changes for Avaya IC and Avaya OA from to IC Script Affected by Comments CHBrowser_OnContactSelected Mass change #2 Other changes CHBrowser_RefreshContact CHBrowser_RemoveContact CHBrowser_Reset CHBrowser_SetActiveContactCriteria CHBrowser_ShowContact CHBrowserTabStrip_Click CHFilter_Initialize CHFilter_OnFilterReset Other changes New in Refreshes a given Contact in the CHBrowser. CHFilter_OnFilterSet ContactList_Add ContactList_Count ContactList_Item ContactList_ItemExists ContactList_Remove ContactList_GetAttribute ContactList_SetAttribute CoreServices_BeforeChannelLogout CoreServices_BeforeLogout Other changes Other Changes CoreServices_Exit Mass change #1 CoreServices_GetEDUValue Mass change #1 CoreServices_GetHUBEDU Mass change #1 Other changes CoreServices_GetRelatedEDUs Mass change #1 Other changes New in Takes care of what is needed before logging out of a channel. 392 Software Upgrade and Data Migration May 2009

393 Avaya Agent IC Script changes IC Script Affected by Comments CoreServices_IncrementAgentContainer Mass change #1 CoreServices_Initialize CoreServices_IsValidEDU Other changes Other changes CoreServices_LinkEDUs Mass change #1 CoreServices_Login Mass change #1 CoreServices_Logout Mass change #1 Other changes CoreServices_MakeChannelBusy CoreServices_RestartServer Mass change #1 CoreServices_SetEDUValue Mass change #1 Other changes CoreServices_SetOrIncrementEDUValue CoreServices_StoreComment CoreServices_GetSeqCoupleValue CoreServices_SetSeqCoupleValue EDUViewer_AddContact Major change #1 EDUViewer_Initialize Major change #1 Mass change #1 EDUViewer_LoadSpecsFromDB Major change #1 EDUViewer_RefreshContact EDUViewer_Reload EDUViewer_RemoveContact Major change #1 EDUViewer_Reset Major change #1 EDUViewer_ShowContact Major change #1 New in Makes a given channel busy and waits for return. New in Performs a VDU.SetOrIncrementValue. New in Stores comments from UAD into EDU. New in Gets a value from a SeqCouple. New in Sets a value within a SeqCouple. New in Refreshes a Contact within an EDU Viewer. Software Upgrade and Data Migration May

394 Appendix A: Detailed changes for Avaya IC and Avaya OA from to IC Script Affected by Comments _BeforeLogout Major change #4 _CompleteContact _Exit Major changes #2 & 4 _HasActiveContacts Other changes _Initialize Major change #3 _Login _Logout Major change #4 Other changes _ManualLogout Major change #2 _ShowHistory _SuspendActiveContacts Major change #4 _Transfer ErrorDialog_ButtonClicked ErrorDialog_Create ErrorDialog_Update LMWebBrowser_BeforeNavigate2 LM_Cancel LM_CheckListMemberStatus LM_ClearLM_Info LM_Done LM_FormClear LM_FormIsFilled LM_GetFieldName LM_GetLM_InfoFromForm LM_InitializeWebBrowser LM_LoadLM_Info LM_Next LM_PlaceCall 394 Software Upgrade and Data Migration May 2009

395 Avaya Agent IC Script changes IC Script Affected by Comments LM_PutLM_InfoInForm LM_RunScript LM_SetListMemberStatus MailEngine_LookupAgentForTransfer Major change #5 MailEngine_RequestAlertInfo MailEngine_TaskDeclined MailEngine_TransferResponse OutboundAgent_AddDataWakeID Mass change #1 Other changes OutboundAgent_CompleteContact OutboundAgent_DisplayScript OutboundAgent_Exit OutboundAgent_GetScriptSessionId OutboundAgent_SetScriptSessionId OutboundAgent_PopScreen OutboundAgent_RemoveContact OutboundAgent_WrapScript Other changes Other changes PhoneEngine_OnCoreStateChanged Mass change #2 PhoneEngine_OnTelephonyStateChanged Major change #6 Mass change #1 & 2 Other changes QConsole_AddContact QConsole_AsyncExecuteQScript QConsole_BuildActiveContactCriteria Parameter changes Mass change #2 Many other changes New in Handles the TaskDeclined event. New in Handles the TransferResponse event. New in Runs whenever an Outbound Contact is being completed. New in Pulls logic out of QConsole_AddContact. Software Upgrade and Data Migration May

396 Appendix A: Detailed changes for Avaya IC and Avaya OA from to IC Script Affected by Comments QConsole_BuildCHBrowserInfo QConsole_ChannelEnabled QConsole_CheckVoiceRefCountForChat QConsole_ClearFocus Mass change #1 QConsole_CompleteContact Mass change #2 Several other changes QConsole_ExitChannelsNotInUse QConsole_ExitComponents Major change #2 Mass change #2 Several other changes QConsole_GetAvayaAgentDisabled QConsole_SetAvayaAgentDisabled QConsole_FindExistingRelatedEDU QConsole_GetContactLabelFromEDU Mass change #1 Other changes QConsole_GetCoreServices QConsole_GetExistingRelatedEDU QConsole_GetInteractionState QConsole_HangUpCall New in Caches the interaction state. QConsole_InitializeComponents Major change #2 Mass change #2 Several other changes QConsole_IntegrationHook QConsole_KeyDown QConsole_LoginComponents Major change #2 Mass change #2 Several other changes New in Pulls logic out of QConsole_AddContact. Formerly called ChannelEnabled. New in handles Multi-media. New in Handles multi-media contacts. New in Caches the interaction state. Formerly called QConsole_ IntegratedApplicationHook. 396 Software Upgrade and Data Migration May 2009

397 Avaya Agent IC Script changes IC Script Affected by Comments QConsole_MouseDown Mass change #2 Several other changes QConsole_PerformScreenPopFromEDU Mass change #2 Other changes QConsole_PlaceCall QConsole_RemoveContact Major change #5 Mass change #2 QConsole_ScreenPop QConsole_SelectContact QConsole_SetInteractionState QConsole_ShowContact Mass change #2 QConsole_ShowContactChooserDialog QConsole_StartPrompterFlow QConsole_SuspendOtherContacts QConsole_TransferRelatedChat Other changes Other changes New in Caches interaction state. New in Starts a Prompter session the Avaya Agent. QConsole_UpdateActivePanes Major change #5 New in Consistently and configurably activates panes in Avaya Agent. QConsole_UpdateAgentStats Major change #5 New in Keeps track of Agent statistics. QConsole_UpdateVoiceRefCount Major change #5 QConsole_WrapContact QConsole_WriteAgentStats Parameter changes Major changes #5 & 6 Mass changes #2 Many other changes Shared_OnActivate Mass changes #2 Shared_OnSelect Mass changes #2 Softphone_BeforeLogout Mass changes #1 New in Keeps track of Agent statistics. Software Upgrade and Data Migration May

398 Appendix A: Detailed changes for Avaya IC and Avaya OA from to IC Script Affected by Comments Softphone_ClickButton Softphone_CompleteConference Mass changes #1 Softphone_CompleteConsTransfer Mass changes #1 Softphone_CompleteContact Mass changes #1 Other changes Softphone_Exit Mass change #1 Other changes Softphone_GetCurrentAgentFromEDU Mass change #1 Other changes Softphone_GetTelephony Softphone_HandleTelephonyResponse Other changes Softphone_HangUpCall Mass change #1 Softphone_HasActiveContacts Mass change #1 Softphone_InitBlindTransfer Mass change #1 Softphone_InitConference Mass change #1 Softphone_InitConsTransfer Mass change #1 Softphone_Initialize Mass change #1 Softphone_Login Softphone_Logout Softphone_ManualLogin Softphone_ManualLogout Other changes Parameter changes Other changes Other changes Softphone_PlaceCall Mass changes #1 & 2 Softphone_Reset Softphone_ResetVoiceContacts Parameter changes Mass change #1 Softphone_SuspendActiveContacts Mass change #1 Other changes StatusDialog_ButtonClicked Other changes 398 Software Upgrade and Data Migration May 2009

399 Avaya Agent IC Script changes IC Script Affected by Comments StatusDialog_Create StatusDialog_Update Several other changes Many other changes TaskList_Change Major changes #4, 6, & 7 Mass change #2 TaskList_GuiActivate Mass change #2 TaskList_Initialize TaskList_Reset Major change #4 UAD_CancelContact Major change #5 New in UAD_HandleUADCancel Major change #5 Mass change #2 Other changes UAD_HandleUADError UAD_HandleUADOK Major change #5 Mass change #2 Other changes UAD_Initialize Major change #5 Mass change #2 Other changes UAD_Login UAD_RemoveContact Major change #5 New in Handles errors in the UAD. New in Provides a hook so that you can run an IC Script when the Agent logs into the UAD. UAD_SetContact Major change #5 New in Sets the contact into the UAD. UAD_Show Major change #5 New in Consistently shows the UAD. UAD_Show LookupResponse UAD_UADStateChange Major change #5 Mass change #2 WAC_ActivateClient Software Upgrade and Data Migration May

400 Appendix A: Detailed changes for Avaya IC and Avaya OA from to IC Script Affected by Comments WAC_Exit Major change #2 New in Supports Avaya Agent client Login/ Logout. WAC_GetClientView WAC_Hide New in Hides the Avaya Agent client. WAC_LoggedIn Major change #2 New in Supports Avaya Agent client Login/ Logout. WAC_Login Major change #2 New in Supports Avaya Agent client Login/ Logout. WAC_Logout Major change #2 New in Supports Avaya Agent client Login/ Logout. WAC_ManualLogout Major change #2 New in Supports Avaya Agent client Login/ Logout. WAC_SendAddressLookup WAC_SetClientView WAC_Show WACEngine_AgentStateChanged Mass change #2 WACEngine_ErrorOccurred Mass change #2 WACEngine_Initialize WACEngine_LookupAddress Major change #5 WACEngine_PerformConsoleAction Mass change #2 Several other changes Web_BeforeLogout Web_CompleteContact Web_EndIVChat Web_Exit Web_HandleIVChatInitialize Web_HasActiveContacts Other changes Several other changes 400 Software Upgrade and Data Migration May 2009

401 Avaya Agent IC Script changes IC Script Affected by Comments Web_Initialize Major change #3 Web_Login Web_Logout Web_ManualLogout Web_Reset Web_ShowHistoricTranscript Web_SuspendActiveContacts Web_Transfer Web_WrapContact Several other changes WebEngine_ActivateCallback Mass change #2 Several other changes WebEngine_LookupAgentForTransfer WebEngine_TaskDeclined WebEngine_TransferResponse Other changes WebEngine_WebStateChanged Major change #6 Mass change #2 Other changes WrapUpDialog_Initialize Major change #8 New in Handles the TaskDeclined event. New in Handles the TransferResponse event. WrapUpDialog_Login Major change #8 New in Performs login time operations on the WrapUpDialog. WrapUpDialog_StartWrapUp WrapUpDialog_WrapupEvent Parameter changes Major change #8 WrapUpEngine_Exit Major change #8 New in Shuts down the WrapUpEngine. WrapUpEngine_Initialize Major change #8 New in Initializes the WrapUpEngine. Software Upgrade and Data Migration May

402 Appendix A: Detailed changes for Avaya IC and Avaya OA from to The following IC Scripts are located in IC61_INSTALL_DIR\IC61\design\common: 6.1 IC Scripts Comments AddItemRecord AddQBEValueToList AlertAdministrator AlertInfo Cleanup ConstructFaxAddress CreateFileFromText CreateFlowCatalogFromTable DebugLevel ExMapping_CreateExCustomer ExMapping_CreateExOrganization ExMapping_LookupContact ExMapping_LookupIndividual ExMapping_LookupOrganization ExMapping_LookupReposCustomer ExMapping_LookupReposOrganization File_FindExecutable File_SendToOpenWithDialog FillTargetFromIFB FormatDate GetRegistryKeyValue GetTempPath New in Supports new external mapping tables in Avaya IC. New in Supports new external mapping tables in Avaya IC. New in Supports new external mapping tables in Avaya IC. New in Supports new external mapping tables in Avaya IC. New in Supports new external mapping tables in Avaya IC. New in Supports new external mapping tables in Avaya IC. New in Supports new external mapping tables in Avaya IC. New in Lets you send a file to the Windows "Open With " dialog. Has parameter changes. 402 Software Upgrade and Data Migration May 2009

403 Avaya Agent IC Script changes 6.1 IC Scripts Comments Initialize MakeNumeric ProcessTemplate ProcessTemplatePack QPrompter_CompleteWrapUp QPrompter_Exit QPrompter_Initialize Affected by major change #3. QPrompter_StartFlow QPrompter_StartWrapUp QPrompterClient_FlowComplete QPrompterClient_FlowDelete RecordIsLocked SendMessageHook SetRegistryKeyValue String_StripSpaces System_GetCursorPos System_GetMemoryStats ViewFileFromFilename WebBrowser_AddSelectValue WebBrowser_ClearSelectControl WebBrowser_ClickControl WebBrowser_FindControl WebBrowser_GetControl WebBrowser_GetControlValue WebBrowser_GetDocument WebBrowser_RemoveSelectValue Has parameter changes and other changes. Has parameter changes. New in Strips spaces from a string. New in Gets the position of the mouse pointer. New in Uses Win32 API to retrieve Memory statistics about Avaya Agent. Software Upgrade and Data Migration May

404 Appendix A: Detailed changes for Avaya IC and Avaya OA from to IC Scripts Comments WebBrowser_SetControlValue Window_GetInfo Window_Move Window_SetTopMost WriteLogMessage IC Scripts that have been removed in The following IC Scripts in IC602_INSTALL_DIR\IC60\design\QConsole have been removed: IC Script Comments _GetAgentId QConsole_UpdateUAD tbdirectory_click UAD_AddContact UAD_HandleUADBlindTransfer UAD_HandleUADConference UAD_HandleUADConsTransfer UAD_HandleUADInitiate UAD_HandleUADTaskSelected UAD_ShowContact SiebelApp_CheckActivityContactLink SiebelApp_Exit SiebelApp_GetApplication SiebelApp_Login SiebelApp_Logout SiebelApp_ManualLogin SiebelApp_PerformScreenPop SiebelApp_PerformScreenPopFromEDU SiebelApp_ShowActivity Removed as a result of major change #5. Removed because Siebel 2000 support is no longer part of the out-of-the-box product. Softphone_GetAgentId 404 Software Upgrade and Data Migration May 2009

405 Chat & IC Script changes IC Script Comments TaskList_Incoming TaskList_Select TaskList_Terminate TaskList_Wrapup WACEngine_Exit WACEngine_Login Removed as a result of major change #7. Removed as a result of major changes #2 & 3. Web_GetAgentId The following IC Scripts in IC602_INSTALL_DIR\IC60\design\common have been removed: batchq_add batchq_delete batchq_report batchq_update InitializeDesktop SendLetterHook Chat & IC Script changes The Avaya IC Chat & scripts have been extensively updated for You need to reapply any customizations that you made to the scripts to the updated version of these scripts. Avaya IC workflow changes Avaya IC workflows are difficult to migrate, especially because they are not text files and cannot be compared with previous versions. In addition, if you keep your current workflows, you will not be able to take advantage of any of the new functionality introduced in Therefore, Avaya recommends that you start with the out-of-the-box workflows and reapply your customizations. If you want to keep your current workflows, however, most of them will run in a environment with the following minor changes. web_routing.update_qw_cache changes: If you customized web_routing.update_qw_cache: 1. Open the web_routing.update_qw_cache in Workflow Designer. Software Upgrade and Data Migration May

406 Appendix A: Detailed changes for Avaya IC and Avaya OA from to Reapply any customizations you made in to the new workflow. 3. Change the database settings to point to the custflow application. 4. Build and upload the flowset. Blender workflows All of the Blender workflows were changed for 6.1.3, and new workflows have been added.! Important: Important: Because of the extensive changes, it is essential that you use the out-of-the-box Blender workflows as a starting point and reapply your customizations to those workflows. Otherwise, you will lose some Avaya Agent system functionality. The changes include: Additional information is now being pulled from and put into the EDU for the client login. The workflows now handle the setting of current load and load values for channels that fail. New Blender workflows have been introduced. Chat & workflow changes The Avaya IC Chat & workflows have been updated for These workflows are contained in the following projects located in IC61_INSTALL_DIR\IC61\design\IC\ Flows\Avaya: IC \ic .prj WACD\wacd.prj Web_Routing\web_routing.prj WebCenter\webcenter.prj All of these projects must be compiled and loaded into the Avaya IC system database after you have migrated your data. Customizations to the workflows must be reapplied to the Workflows. For details about the Chat & workflows, see Chapters 5, 7, and 8 in the Avaya IC Media Workflow Reference. Analysis workflows (IC server workflows) Most of the changes to the analysis workflows for are the result of bug fixes. Additionally, a new Fetch Customer Block was introduced into the Analysis and Routing workflows to look up the Customer and write the data into the EDU consistently. 406 Software Upgrade and Data Migration May 2009

407 Avaya IC workflow changes Letter Generation workflows The Letter Generation workflows were changed in If you made any customizations to the workflows, you will need to reapply your customizations to the new workflows. System workflows Avaya recommends that you do not customize the system workflows. If you have, you will need to reapply your customizations to the out-of-the-box system workflows because the Avaya IC system depends on the functionality in these workflows. Routing workflow changes The routing workflows were significantly changed in Many of the existing blocks were updated and rewritten. In addition, all of the workflows now have the same three stages: 1. The setup stage retrieves the EDU and gets things ready for the next step. 2. The Customer Lookup stage, in which you would do other Application work such as creating records. 3. The routing stage. For 6.1.3, Routing Hints were made easier to understand and consistent across channels. For details, see Chapter 2 in the Avaya IC Media Workflow Reference. This section describes the methodology required to migrate the following routing workflows to 6.1.3: ts.incomingcall voice routing workflow wacd.qualify routing workflow wacd.qualifychat chat routing workflow Each of the routing workflows perform the following functionality: Fetch input arguments and EDU Customer lookup based on a channel specific query parameter Set Data for EDU viewer Perform channel specific routing logic In all three routing flows: Enable Advocate block: The Enable Advocate block can be removed as it is not required for Software Upgrade and Data Migration May

408 Appendix A: Detailed changes for Avaya IC and Avaya OA from to Customer lookup blocks: The collection of blocks used for Customer lookup have been replaced with a single Fetch Customer Record block. You should use this new block in your workflows because it includes functionality to detect whether a database query for Customer data has already been attempted, and it has been optimized to work across all Avaya IC routing flows (both Advocate and non-advocate). The out-of-the-box Fetch Customer Record block accesses the ccq.customer table only. If you need access to another table, you need to change the block code. Set EDU View data blocks: The collection of blocks used to set the data for the EDU Viewer have been replaced with a single Create Agent Desktop block. The blocks will still work in 6.1.3, however, you need to explicitly add a Write EDU block to the flows. The Create Agent Desktop block does its own write EDU internally. Chat and workflows: In 6.1.3, all routing hints are administered in the RoutingHint DS table, and the Outbound RoutingHint table has been removed. Make sure that change your workflows to use the new table of outbound routing hints. Web routing flow set: The workflows in the web_routing flow set have been modified.: The update_agent_primaryworkgroup workflow has been removed. This flow created a set of global variables in the Workflow Server that mapped agents to the workgroups that they belonged to. This was used whenever an attempt was made to route an or chat contact to a specific agent. This functionality was moved into the Set Route Parameters block in The update_qw_cache workflow has changed. In 6.0.2, this flow created a set of global variables in the Workflow server that managed mappings of queues, workgroups and tenants for and chat. For 6.1.3, this flow adds analogous mapping information for the voice channel. Additionally, the format and layout of the global variables created has changed. Therefore, you need to be sure to use the new web_routing.update_qw_cache workflow for all contact routing, including voice. Voice channel flow changes The ts.incomingcall workflow uses the ANI and DNIS as possible routing hints to determine a route destination based on the ani and dnis input arguments. For 6.1.3, only the DNIS is used directly as a routing hint, and the ANI is ignored. Additionally, the logic for determining the route to destination has been changed in to be more consistent across all 3 channels. The block labeled Dinis & Ani -> Hints is no longer needed. In 6.0.2, this block put, if available, the ANI and DNIS values into a SeqString called HintsToTranslate. All of the blocks from the Dinis & Ani -> Hints to just before the Transfer Block have been replaced with new blocks and logic for Software Upgrade and Data Migration May 2009

409 Avaya IC workflow changes The following screenshots show the differences between the Voice routing workflows in and The following screenshot shows the Voice routing workflow structure: Software Upgrade and Data Migration May

410 Appendix A: Detailed changes for Avaya IC and Avaya OA from to The following screenshot shows the Voice routing workflow structure: Add Routing Hints block In the new ts.incomingcall workflow, the Add Routing Hints block is used to add the DNIS to the hint set to be considered by the routing logic to select the appropriate route to destination (queue). The collection of routing hints in the flow is now a SeqCouple (the output of the Add Routing Hints block) with each Couple being of the form of a name value pair such as intent= The use of categories for hints is new in and was introduced because: Advocate uses the notion of category/value and these hints are directly used as hints by Advocate to identify an Advocate qualifier. By categorizing hints, it guarantees that only one possible value is used for a particular category. For example, identifying a set of hints that contain language=en and language=sp doesn t make sense. However, there is no way to identify/enforce the category that a hint belongs to in the RoutingHint DS table, so it is only a rule of thumb that should be followed. 410 Software Upgrade and Data Migration May 2009

411 Avaya IC workflow changes Routing hint script variables: The script variables that could be used as routing hints in the flows were restricted to ANI and DNIS which were hard coded into the DNIS & ANIS -> Hints block. In the flow, up to 10 possible script variables can be added to the hint set that is considered by the Map Hints to Queue block. Map Hints to Queue block The Map Hints to Queue block in has been completely rewritten in to receive a hint set in a SeqCouple and to allow the ability to set a failover route to queue destination if no queues are found in the RoutingHint DS table. This is done be entering a valid voice queueid into the DefaultQueueID property of the Map Hints to Queue block. It is no longer necessary, nor advisable, to enter a queue name or VDN value into the Transfer Call block. The new Map Hints To Queue block requires the use of the updated web_routing.update_qw_cache workflow. channel flow changes The qualification flow, wacd.qualify , supports the ability to route new incoming as well as an outbound that has been flagged for QA by the ic .oubound(no)ca workflows. This workflow has the same Customer lookup and EDU Viewer logic as the ts.incomingcall workflow and should be retrofitted with the new Fetch Customer Record and Create Agent Desktop blocks. The hints that are considered during new incoming or flagged for QA outbound use routing logic that is different in compared to The following changes have been made: Using Content Analysis results as hints: This is no longer supported in because using the Test Category block in the ic .analyzeca workflow to set routing hints (using the Set Routing Hint block) is a more consistent and accurate way to identify hints for a contact. Hence the actual, raw Content Analysis results are not considered in the qualification flow. The routing hints identified in the prequalification workflows, ic .analyze(no)ca are stored in the ccq.qw_qualifier table. The Fetch Routing Hint block is used to retrieve them. flagged for QA contacts need information about the original incoming The qualification workflow adds the hints identified for the original incoming to the QA hint identified by the outbound flow by fetching the routing hints using the rootmsgid field in the outbound contact s EDU. This way if an outbound is flagged for QA for either agent quota or suspicious content, the original s hints are added to determine the correct queue to deliver the contact to. This is important if the original was a French and sales and the response must be sent to QA. The logic tries to deliver this outbound to an agent who is skilled in French and sales and QA, thereby providing a more accurate routing decision. Software Upgrade and Data Migration May

412 Appendix A: Detailed changes for Avaya IC and Avaya OA from to Additionally, the workflow required the input of the ApprovalQueueID and the ApprovalAgentID properties in the Approval Queue/Agent block. This restricted where this contact could be routed and has been replaced with the same routing hint to queue technology used for all incoming contacts. The Compete Qualification block has been re-worked: The Complete Qualification block found in wacd.qualify , which is the same block (with a different block label) as the wacd.qualifychat Complete Chat Qualification block, has been rewritten to remove the properties that are no longer used. Additionally, the block has been made channel aware ( or chat) within the block. Avaya recommends that you use the version of the Complete Qualification block, along with its required Set Route Parameters block, in all qualification workflows for and chat. Avaya recommends that all routing logic be replaced with the simpler and more complete logic and blocks. The following screenshots show the differences between the qualification workflows in and The following screenshot shows the qualification workflow structure: 412 Software Upgrade and Data Migration May 2009

413 Avaya IC workflow changes The following screenshot shows the qualification workflow structure: Chat channel workflow changes The chat qualification flow, wacd.qualifychat, supports the ability to route chat contacts. This workflow has the same Customer lookup and EDU Viewer logic as the ts.incomingcall workflow and should be retrofitted with the new Fetch Customer Record and Create Agent Desktop blocks. The logic of the chat qualification workflow has essentially not changed for The only changes surround the collection/retrieval of routing hints, the handling of VOIP call and PSTN callback chats, and the configuration of chat wait treatment: Routing hint collection/retrieval : Each chat contact (EDU) has a language field populated with an ISO language code. This language code is now handled in by extracting the language from the EDU s Get EDU Values block and using the flexible Add Routing Hint block to add it to the collection of routing hints to consider for the contact. Then the Fetch Routing Hint block is used to extract the web page specific routing hint (if administered) and is added to the routing hint collection. Software Upgrade and Data Migration May

414 Appendix A: Detailed changes for Avaya IC and Avaya OA from to Identifying VOIP call and PSTN callback chats : This is done by looking at the values associated with the requestedmedia, ivchatenabled and pvchatenabled variables delivered as input arguments to the flow and then assigning either ivchat or pvchat as a multimedia hint to the hint set. In 6.0.2, the chat qualification workflow only hardcoded a specific Workgroup for either IVChat or PVChat in the Set Route Step block. However, all qualifications workflows should resolve to a queue to route to and not a specific workgroup. Hence this functionality was changed to take advantage of the mapping of routing hints to queues in the RoutingHint DS table. In order to support backward compatibility to chat handling of VOIP call and PSTN callback, you can set the IVChatWorkgroup and PVChatWorkgroup directly in the Set Route Parameters block. Chat Wait Treatment configuration: The individual chat steps for wait treatment have been moved out of the Set Route Step block and into the Set Chat Wait Treatment block in Avaya recommends that you use this new technique as it is reused in the Advocate chat qualification flows. Avaya recommends that all routing logic be replaced with the simpler and more complete logic and blocks. The following screenshots show the differences between the Chat qualification workflows in and The following screenshot shows the Chat qualification workflow structure: 414 Software Upgrade and Data Migration May 2009

415 RowDate data changes in Avaya OA The following screenshot shows the Chat qualification workflow structure: RowDate data changes in Avaya OA An improvement was made in Avaya OA 6.1.x in how the date/time labels of archived data are administered, represented in the database, and presented in reports. In 6.0.x, this was done relative to the local time zone of the administrator, which sometimes led to confusion when systems spanned multiple time zones. In 6.1.x, archive data is labeled relative to an administered absolute time zone, which resolves this potential confusion. As a result, the oarowdatemig command was used, as described in Migrate the Avaya OA historical Software Upgrade and Data Migration May