Вы находитесь на странице: 1из 120

AvaAvaya Application rver 5300 R3.

0Ava
tion Srv Avaya Application Server 5300 R3.0Ava
Avaya Application Server 5300 R3.0Ava
102.2.3 AS 5300 3.0 - 2.0 to 3.0 SIP CORE Upgrade
Method of Procedure

Product Release:

AS 5300 R3.0

Document Version:

2.6

Document Status:

Released

Document Release Date:

March 14, 2012

Security Classification:

Avaya Confidential

Copyright 2012 Avaya


All rights reserved.
Avaya CONFIDENTIAL: The information contained in this document is the property of Avaya. Except as
specifically authorized in writing by Avaya, the holder of this document shall keep the information contained
herein confidential and shall protect same in whole or in part from disclosure and dissemination to third parties
and use same for evaluation, operation, and maintenance purposes only.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

Revision History
Version Date

Description

0.0

November 3, 2010

Initial Draft

0.1

December 13, 2010

Removed Online Help installation

0.2

March 1, 2011

Removed Oracle Database installation

0.3

March 15, 2011

Added IPCM Decommissioning steps

0.4

April 1, 2011

Added new required steps for SM console launch

0.5

April 12, 2011

Modified step 12b inTable 4

0.6

April 28, 2011

Modified Step 7 in Table 1

0.7

May 4, 2011

Updated Software load Protal link

0.8

May 5, 2011

Added new required steps for Half Rollback

0.9

June 30, 2011

Added new required steps for Full Rollback

1.0

July 29, 2011`

Added SM Renaming steps

1.1

August 8,2011

Updated SM Renaming steps

1.2

August 10,2011

Updated screen captures, table of contents etc..

1.3

August 12, 2011

Updated Rollback section

1.4

August 17, 2011

Updated R3.0 naming. Replace MCP Management Console


with AS 5300 Element Manager Console. Replaced AMS
with Avaya MS, replaced SESM with AS 5300 SESM

1.5

August 25, 2011

Updated Table 10 for System Rollback

1.6

Sept ember 10, 2011

Updated Rollback Section

1.7

September 15, 2011

Updated after MOP review

1.8

September 20, 2011

Updated Audiocodes Firmware Upgrade

1.9

October 1, 2011

Updated SM Renaming steps

2.0

Oct 14, 2011

Updated document number, rollback section, and AudioCode


section

2.1

Oct 28, 2011

Changed MCP 15.0 to MCP 15.1, and more updates as per


review comments

2.2

Nov 7, 2011

Added IPv6 manual upgrade instructions

2.3

Nov 18, 2011

Updated as per review comments from AvayaGov Training.


2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

2.6
Method of Procedure
Version Date

Description
Added instructions to access EM console in FIPS compliant
mode after upgrade.
Updated Data Changes section.

2.4

January 25, 2012

Changed title bar to Avaya Application Server 5300


Changed instances of AS5300 to AS 5300
Changed product reference of MCP 13.0 to AS 5300 2.0
Changed product reference of MCP 15.1 to AS 5300 3.0
Inserted step 17 in table 4
Changed diagrams to relect the Element Manager Console

2.5

Feb 8, 2012

Updated patching related information

2.6

March 14, 2012

Updated Prep Steps

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

ii

Table of Contents
1 Upgrade AS 5300 2.0 Release to 3.0 .......................................................................... 1
1.1

Notes for upgrading from the AS 5300 2.0 Release ........................................................ 1

1.2

Conceptual view of the Upgrade Process............................................................................... 3

1.3

Options to upgrade over multiple Maintenance Windows ................................................ 4

2 Preparatory Steps ..................................................................................................... 6


3 Process to Upgrade AS 5300 2.0 to 3.0 ............................................................19
3.1

Upgrading a Redundant System .........................................................................................19

3.2

Steps to Update the License Key ........................................................................................46

3.3

Steps to find/stop/undeploy Primary/Stand-by NEs ...........................................................49


3.3.1

Steps to Stop a given NE Instance .......................................................................52

3.3.2

Steps to Undeploy a given NE Instance ...............................................................54

Config Data changes that may be required ..........................................................................56

3.4

3.4.1

Directory Change for Records on OSS Server ............................................................56

3.4.2

Config Data Changes ...............................................................................................56

Provisioning Data changes that may be required after the Database Upgrade..........................58

3.5

4 Definitions & Abbreviations ...................................................................................59


External Documents Referenced.........................................................................................60

4.1

5 Appendix A: MAS Upgrade Notes ..........................................................................61


5.1

MAS Platform Upgrade (13.0 to 15.1) ................................................................................61

5.2

MAS Platform Rollback (15.1 to 13.0)................................................................................61

6 Appendix C: Example installprops file ...................................................................62


7 Appendix D: MCP SM/EM CONSOLE Notes .......................................................64
7.1

Install/launch the MCP SM/EMCONSOLE .........................................................................64

7.2

Deploy/start a Network Element (NE) ............................................................................67

7.3

User Forced Out msg or Unable to launch MCP Mgmt Console .................................71

8 Appendix E: Installing OnlineHelp files .................................................................73


8.1

Install the AS 5300 2.0 OnlineHelp files .........................................................................73

9 Appendix F: Installing ASU files.............................................................................75


9.1

Installing Client ASU files ...............................................................................................75

9.1.1

Installing 8.1 Hardened Client ASU files on the AS 5300 3.0 Server ...........................75
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

iii

2.6
Method of Procedure
9.1.2

Installing 7.2 Hardened Client ASU files on the MCP Server ......................................76

10 Appendix G: Upgrade AudioCodes to its latest MR ...............................................78


11 Appendix H: Rollback Steps ...................................................................................79
11.1 Rollback one half of an upgraded system ......................................................................79
11.2 Rollback an entire system ..............................................................................................86

12 Appendix I: Applying a MCP Patch .....................................................................103


12.1 Patch the Database Schemas and System Manager .............................................................103
12.2 Patch Network Elements ..................................................................................................104
12.2.1

Service Issues ....................................................................................................104

12.2.2

Perform the Patch ..................................................................................................105

13 Appendix J: 13.0 Patch current determination .....................................................110


14 Appendix L: Retrieving the MCP License Key .....................................................111

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

iv

List of Figures
Figure 1: Small (2 server) SIP Core configuration..........................................................................20
Figure 2: Medium (4 server) SIP Core configuration .....................................................................20
Figure 3: Large (8 server) SIP Core configuration .........................................................................21
Figure 4: Management Console License Key Invalid Alarm ..........................................................46
Figure 5: Management Console Update License Key Right-Click Option......................................47
Figure 6: Management Console Update License Key Window ......................................................48
Figure 7: Management Console License Key Information Dialog ..................................................48
Figure 8: Management Console Servers Panel ..........................................................................49
Figure 9: Management Console IP Addresses Panel .................................................................50
Figure 10: Management Console Physical View ICON ...............................................................50
Figure 11: Management Console Physical View panel ...............................................................51
Figure 12: Management Console Physical View with Servers/NE instances...............................52
Figure 13: Management Console Config Tree ............................................................................53
Figure 14: Management Console NE Maintenance Panel ..........................................................54
Figure 15: Management Console Undeploy a given NE .............................................................55
Figure 16: Launch 13.0 System Management Console Window ..................................................64
Figure 17: Launch 15.1 AS 5300 Element Manager Console Window ..........................................65
Figure 18: MCP System Management Console Connection Frame for 13.0 ..........................................65
Figure 19: AS 5300 Element Manager Console Connection Frame for 15.1 .................................65
Figure 20:: Login to the System Management Console for 13.0 ...................................................66
Figure 21: Login to AS 5300 Element Manager Console for 15.1 .................................................66
Figure 22 Initial Management Console display window .................................................................67
Figure 23: Configure a NE to the 15.1 load from the NE instance window .................................68
Figure 24: Apply the 15.1 load from the pop up window .............................................................68
Figure 25: Deploy a NE Instance Maintenance panel .................................................................69
Figure 26: Start a NE Instance Maintenance panel.....................................................................70
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

2.6
Method of Procedure
Figure 27: Access to the Load Manager application ....................................................................105
Figure 28: Selecting the patch load in the Load Manager .........................................................106
Figure 29: Patch Session Managers ............................................................................................107
Figure 30: Session Manager Patch ..............................................................................................108

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

vi

List of Tables
Table 1: High-Level steps to perform an Upgrade ........................................................................... 3
Table 2: Preparatory Steps ............................................................................................................... 6
Table 3: Pre-upgrade steps for a MCP Redundant configuration system ......................................21
Table 4: Upgrade a MCP (Redundant configuration) system ........................................................24
Table 5: Post-upgrade steps ..........................................................................................................41
Table 6: Section to Filename mapping for Config Data Changes ..................................................57
Table 7: Definitions & Abbreviations...............................................................................................59
Table 8: Documents referenced by this MOP ................................................................................60
Table 9: Downgrade one half of a Redundant system ...................................................................79
Table 10: Downgrade an Entire Redundant system.......................................................................86

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

vii

1 Upgrade AS 5300 2.0 Release to 3.0


This document contains the process (steps) to upgrade the components in an AS
5300 system executing a 2.0 release to a 3.0 release.
For the 3rd party components which can be utilized by the MCP system, please
reference the vendors documentation regarding the appropriate upgrade process
for each of these components.
o Audiocodes EMS
o Audiocodes Gateways
o Audiocodes IADs

1.1Notes for upgrading from the AS 5300 Release

To upgrade from the 2.0 release, the latest Released status MR must be installed
on the given system.
Information regarding the Latest General Available MR and/or Patch load can be
checked from the Application Server 5300 web page via the following link. Be
sure to select 2.0 in the pulldown window (in the upper/middle of the page)
http://support.avaya.com/css/appmanager/public/support/Downloads/P0626
All load line up information (MCP Core Load, Operating System Patch level,
Client versions, MAS Firmware versionsetc) are available from the Release
Notes located in Portal page in the above link.

All the 1120/1140 (Unistim) phones must be migrated to SIP 4.2 firmware
phones, and all the IPCMs must be decommissioned from the system prior to
the upgrade window.

During this upgrade process, there must be a Data Freeze for all
Provisioning/Configuration Data. Note that the Data Freeze for Provisioning
Data does not stay intact for the entire upgrade process of a Redundant system.
Provisioning data can be modified once one half of a Redundant system has been
upgraded (as noted within the MOP itself below).

The primary role of a user can be determined by executing the roles command
as shown below:
[ntappadm@zngdy18a install]$ roles
roles for ntappadm are: AA
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

Document Version 2.6

Method of Procedure

primary Role is: AA

If required, the primary role of a user can be changed by executing the chrole
<newrole> command

When the user is directed to perform some function (e.g. logging in, running a
script) as a selected role, that role must be the users primary role.

As an attempt to assist with the usernames for a pre-configured (e.g. not


individual) system, the default username created for the role will be shown in
parenthesis in each step that requests the user to login, as shown below.
o Login as the DBA role (ntdbadm) to the Primary database server

Note, that even for the pre-configured system, there are no guarantees that the
default username will exist (a customer can delete these usernames and add
back their own usernames for each role).

The user might or might not be prompted for a password when they login as the
SSA role (ntsysadm) and execute the "sudo" command (or any command that is
aliased to an underlying sudo command). If the system does prompt for the
password, then please enter the SSA roles (ntsysadm's) password.

When the user gets the below prompt, while SFTPing to a server for the first time,
always accept the connection by answering yes.
The authenticity of host '47.104.19.19 (47.104.19.19)' can't be established.
RSA key fingerprint is ec:27:47:7f:ff:47:c2:c5:7f:63:0d:6d:08:e6:21:e5.
Are you sure you want to continue connecting (yes/no)? yes

In the 15.1 release, the log file location for all the
- install/upgrade scripts in the /var/mcp/install directory is
/var/mcp/run/install/logs
- DB scripts in the /var/mcp/run/<MCP release>/<dbName> directory is
/var/mcp/run/<MCP release>/<dbName>/work or
/var/mcp/run/<MCP release>/<dbName>/installLogs

When following the steps in this MOP you will notice that instead of
cut&pasting information within the MOP, the MOP references the given Step or
Section (this keeps the data in the document from growing stale/inconsistent.)
Thus, as a suggestion to keep the references from confusing the flow of the
document, if you are using a softcopy of the MOP, bring up the MOP in two
different windows. One window will be used for working on each step in the
given Upgrade Table, and the other window will be used to look up references to
other steps/sections. If you are using a Hardcopy of the MOP, then when a
reference to another step/section comes up, then create two stacks from the
MOP such that the current page/step stays at the top of one stack, and thus is
not lost when looking up the referenced step/section.
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

Terminology used within this document


o Releases MCP 13.0 and AS 5300 2.0 are synonymous
o Releases MCP 15.1 and AS 5300 3.0 are synonymous
o System Manager in R2.0/MCP 13.0 has been renamed to Element
Manager in R3.0/MCP 15.1
o System Management Console (SM Console) in R2.0/MCP 13.0 has been
renamed to AS 5300 Element Manager Console (EM Console) in
R3.0/MCP 15.1
o MAS (Media Application Server) in R2.0/MCP 13.0 has been renamed to
Avaya MS (Avaya Media Server) in R3.0/ MCP 15.1

This document will generally use the terms AS 5300 2.0 and AS
5300 3.0 when referring to the two releases involved in this
upgrade process.

1.2 Conceptual view of the Upgrade Process


To assist the user in understanding the upgrade process, the following Table shows the
high level steps that will be performed during an upgrade.

Table 1: High-Level steps to perform an Upgrade

Step #

Description

Perform Prep Steps described in the Table 2

Perform Pre-Upgrade Steps described in the Table 3

Perform Upgrade of the Primary Core components


described in the Table 4

3a

To perform an upgrade with minimal service downtime across


the Core elements, the Servers and Network Elements (NE) are
divided into two logical groups and upgrade one-half of
the MCP system/network at a time letting the other half
continue to provide services. With this, the servers (and
the NEs resident on those servers) are divided into two
groups, Primary and Secondary.

3b

Upgrade the Primary Core Servers and NEs

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

Document Version 2.6

Method of Procedure

Stop the NEs running on the Primary Servers


Upgrade the OS/Platform on the Primary servers
Upgrade the DB and EM to the AS 5300 3.0 load
Bring up the AS 5300 3.0 Element Manager Console and
insert the new license key
Deploy and Start the NEs on the Primary Servers with
the new AS 5300 3.0 load
Stop the 2.0 core NEs running on the Secondary
servers.
o This will force traffic to the 3.0 system
Install client ASU files on the PA/PROV residing on
the Primary Servers
3c

Primary Core Components Upgrade is complete.

3d

A AS 5300 3.0Primary system is now running.


Perform Sanity testing to ensure the system is
operating normally.

Perform Upgrade of the Secondary Core components


described in the Table 4
Upgrade the Secondary Core Servers and NEs

4a

Upgrade the OS/Platform on the Secondary servers


Deploy and Start the NEs on the Secondary Servers
with the new AS 5300 3.0load
Resync the Databases.
Install the ASU files on the PA/PROV residing on the
Secondary Servers

4b

Secondary Core Components Upgrade is complete.

Perform Post-Upgrade Steps described in the Table 5

1.3 Options to upgrade over multiple Maintenance


Windows
The Media Application Server (MAS) and AudioCodes components are upgraded
after all of the Core MCP components. Given the upgrade of the MAS and
AudioCodes are independent of the Core components, the upgrade to AS 5300 3.0
can be split over multiple Maintenance windows (if required). The core
components can be upgraded in one Maintenance window, and then the MAS
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

and/or AudioCodes components can be upgraded within another Maintenance


window.
For additional details regarding the upgrade of a MAS, please refer to Appendix
A: MAS Upgrade Notes.
For additional details regarding the upgrade of an AudioCodes component to its
latest MR (if the given AS 5300 2.0 system being upgraded has an AudioCodes
component configured), please refer to Appendix G: Upgrade AudioCodes to its
latest MR.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

Document Version 2.6

Method of Procedure

2 Preparatory Steps
The table below contains a list of steps that must be performed/verified prior to the day
when the actual Upgrade to AS 5300 3.0 procedure is performed. Given the low
impact to service of the Prep Steps, they can be performed during normal operational
hours if needed. However with any operation at a customer site, a Maintenance Window
during off-hours prior to the day of actual upgrade is the preferred timeframe.

Table 2: Preparatory Steps


Step # Description
1

The following documents are referenced by this upgrade. Please ensure


they are available before the upgrade process begins:

Link to 3.0 documents:


103.1.2_AS 5300_Software_Update
103.2.3 AS 5300 Backup And Restore
102.2.7 AS 5300 2.0 to 3.0 AVAYA MS Upgrade
102.1.9 AS 5300 IPv6 Configuration (if using IPv6 on the 2.0
system)

Link to 2.0 documents:

102.1.1_AS5300_Server_Installation
102.1.2_AS5300_Initial_System_Installation
103.1.2_AS5300_Software_Update
103.2.3_AS5300_Backup_And_Restore
101.2.6_AS5300 IPv6 Configuration (if using IPv6 on the 13.0
system)
103.1.3_AS5300 11x0 SIP Client Configuration

Ensure the person performing the upgrade knows how to launch the
System Management Console, and how to use it.
For details regarding how to launch a System Management Console,
please refer to section 7.1 of Appendix D: MCP SM/EM CONSOLE Notes.

Ensure the AS 5300 system is on the latest 2.0 MR and Patch.

Refer to the instructions in Appendix J: 13.0 Patch current


determination to determine if the MCP system is Patch current
and apply the latest Patch if needed.
Refer to the 103.1.2_AS5300_Software_Update MOP for AS 5300 2.0
for the steps to apply the patch.
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

Perform 2.0 Backups for the Core Servers.

4a

Ensure the 2.0 onlineHelp file and ASU (Automatic Software Update)
files exist on the Primary Element Management Server

Login as the AA role (ntappadm) to the Primary Element Management


Server
cd /var/mcp/media
ls l

You should see the following:


MCP-OnlineHelp_13.0.X.0_XXX.zip
HardenedClient_7.2.XXX
If the onlineHelp file and the ASU files do not exist, please execute
the following steps:
1) Obtain the latest AS 5300 2.0 Core Apps CD for the MCP load
currently installed.
2) Extract the 2.0 online Help file

insert DVD in the DVD tray of the Primary Element Management


Server

login as the AA Role (ntappadm) to the server

mcpExtractContent o -aat

Note:
The AS 5300 2.0 load zip file will be copied to the
/var/mcp/loads directory.

The OnlineHelp zip file will be copied to the /var/mcp/media


directory.

The ASU related files will be copied to the


/var/mcp/media/HardenedClient_7.2.XXX.

The Database installer will be copied to the /var/mcp/media


directory.

Note: Remove the extracted ASU 7.2 files by following the steps below.

4b

cd /var/mcp/media

rm rf HardenedClient_7.2.XXX

Save the 2.0 ASU files to the Primary Element Management Server to be
used during upgrade/rollback.
Note:
- Even though the system may have more than one PROV, only one copy of
the Online Help file is required.
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

Document Version 2.6

Method of Procedure

- This step may not be applicable for non-hardened system.

- Login as the AA role (eg:ntappadm) to the Primary Element


Management Server

cd /var/mcp/media

mkdir HardenedClient_ASU_preupg

chmod 770 HardenedClient_ASU_preupg

If the Provisioning Manager is on the Primary Element Management


Server, execute the following steps:
o cd /var/mcp/media/prov_pa_installs/ASU
o cp smcclient.jnlp
/var/mcp/media/HardenedClient_ASU_preupg/HardenedClient.jnlp
o zip r pcclientcode/signedJar/HardenedClient_Release.zip *
o mv pcclientcode/signedJar/HardenedClient_Release.zip
/var/mcp/media/HardenedClient_ASU_preupg
o zip -r pcclientcode/HardenedClient_unsigned.zip * -x
signedJar/*
o mv pcclientcode/HardenedClient_unsigned.zip
/var/mcp/media/HardenedClient_ASU_preupg

If the Provisioning Manager is NOT on the Primary Element


Management Server, execute the following steps:
o Login as the AA role (eg:ntappadm) to a server hosting a PROV
cd /var/mcp/media/prov_pa_installs/ASU
o cp smcclient.jnlp HardenedClient.jnlp
o zip r pcclientcode/signedJar/HardenedClient_Release.zip *
o zip -r pcclientcode/HardenedClient_unsigned.zip * -x
signedJar/*
o sftp 47.10.10.20
(where 47.10.10.20 is the IP address of the Primary Element
Management Server. Please replace it with the IP address used
in your system.)
o Enter the ntappadm password
o cd /var/mcp/media/HardenedClient_ASU_preupg
o put HardenedClient.jnlp
o put pcclientcode/signedJar/HardenedClient_Release.zip
o put pcclientcode/HardenedClient_unsigned.zip

o exit
Login as the AA role (ntappadm) to the Primary Element
Management Server
cd /var/mcp/media
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions


4c

chmod 660 HardenedClient_ASU_preupg/*

Remove unneeded old loads on the Element Management Servers if needed


Normally the number of loads in the /var/mcp/loads directory should
be 3 or less.
For example, when an MR with multiple Patch loads exist, keep the
latest base/MR load (MCP_13.0.0.0_2010-05-05-2108) and the latest
associated patch load (MCP_13.0.0.3_2010-07-13-1208).
In two different windows, login as the AA role (ntappadm) to the
Primary and Secondary Element Management Servers
cd /var/mcp/loads (on both servers)
Get the rm command ready on both servers (e.g. rm rf <loadname>)
Hit the Enter key on both servers at roughly the same time. (Note:
The reason for doing this is that Primary EM and Secondary EM
monitor the loads and if the load is on one server but not the
other, it will repopulate the loads in the /var/mcp/loads on the
other Element Management Server.)

4d

Backup Preparation
AS 5300 2.0 backups taken for the upgrade to the 2.0 release will be
stored on the Secondary Element Management Server in the
/var/mcp/backup/remote/13.0 directory.
Create a 2.0 backup directory on the Secondary Element Management
Server
- login as the SSA role (ntsysadm) to the Secondary Element Management
Server
- su root
-

cd /var/mcp/backup/remote/
mkdir 13.0
chown root:ntsysgrp 13.0
chmod 770 13.0
ls lrt

Note: Ensure the /var/mcp/backup/remote/13.0 directory exits and is


owned by root:ntsysgrp.
In addition, as an additional safe guard, it is recommended that the
backups stored in the /var/mcp/backup/remote/13.0 directory are copied
to one of the following machines if available:
Site dropbox (eg: /var/mcp/dropbox)
PC
Non-core server
4e

Take a backup for each of the Core Servers:


2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

Document Version 2.6

Method of Procedure

Notes:
The server restore logic will only look for server backup
filenames formatted like mcpPlatform*.tar.

Core server backups are required to rollback to 13.0 if the


upgrade to 15.1 runs into some unforeseen issue.

Core Servers
If you are familiar with the execution of the MCP backup script,
execute the following steps to back up the server configuration and
Application data. However if additional details are required
regarding how to create a backup, please refer to the sections
listed below,
3.12.2 Example invocation (Change passphrase and/or SSH Keys)
3.12.5 Config script help
4.3.2 Backup to remote server
in the 103.2.3_AS5300_Backup_And_Restore MOP
Follow the steps below for all Core Servers except the Secondary
Element Management Server.
Login as the SSA role (e.g., ntsysadm)
Ensure job-specific backup parameters for the "server" and
"platform" backup jobs are disabled.
[ntsysadm@ ]$ configSvrBkup
o

If the menu option "[6] Set remote configuration parameters


to default values" is available, then select menu option 6,
answering "y" to confirm.
Otherwise, select menu option 4 to exit the tool.

[ntsysadm@ ]$ configPlatformBkup
o

If the menu option "[6] Set remote configuration parameters


to default values" is available, then select menu option 6,
answering "y" to confirm.
Otherwise, select menu option 4 to exit the tool.

Enable remote backup configuration parameters for all backup jobs


(Select Option 2).
[ntsysadm@ ]$ configBkup
You are required to set:
o IP address of remote backup server (Primary or Secondary
Element Management Server or any other server that you want)
o Directory on remote backup server where backup tar files are
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

10

o
o
o

to be stored (/var/mcp/backup/remote/13.0)
SSA role (ntsysadm) username to use for remote SSH commands
Previously generated SSH keys
Select exit when finished.

On the Primary Element Management Server, backup the Configuration and


Application data to the Secondary Element Management Server.
[ntsysadm@ ]$ bkupSvr remote
The duration of this backup can vary based on the number and
size of files to be backed up. Larger backups typically will be
completed in less than 30 minutes.

On the Secondary Element Management Server, backup the Configuration


and Application data to the Secondary Element Management Server.
[ntsysadm@ ]$ bkupSvr local
[ntsysadm@ ]$ cd /var/mcp/backup/local
[ntsysadm@ ]$ mv mcp* ../remote/13.0/
For all other core servers, backup the Configuration data to the
Secondary Element Management Server.
[ntsysadm@ ]$ bkupPlatform remote
If IPv6 is configured for any 2.0 AS 5300 SESM, reference section "8.2
Manual Backup and Restore" of 101.2.6 AS 5300 IPv6 Configuration for
details on manually saving any IPv6 AS 5300 SESM configuration.
Perform this step for each of the 2.0 SIP Core servers which have an
AS 5300 SESM deployed to them.

4g

Server information required when rolling back the server to the 2.0
release
Note that this information is required to rollback to 2.0 if the
upgrade to 3.0 runs into some unforeseen issue.

The information required to restore a server (using a backup of the


given server stored on a remote server) is listed below. As part
of the preparation for the actual server upgrade, please compile a
table with this information for each Core server.
The VLAN ID, the IP address, the gateway and the netmask of the
server that you are restoring.
The IP address of the remote server (that the server backup is
stored on), the directory where the backup was placed, and the
userid/password for accessing the data on the remote server.
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

11

Document Version 2.6

Method of Procedure

o The user will be the SSA role (ntsysadm) for the server
backups

To obtain this information for a given server, login to the server


as the SSA role (ntsysadm) user.
Execute the command below:
o

mcpShowNwkConfig

or
o

su -

cat /admin/nwk/ mcpNwkCfg.xml

Identify the three required items from the output of the command.
There will be other items listed in mcpNwkCfg.xml An example of
the information to be captured from the above output, is shown
here:
gateway=47.10.X.X
machineIP=47.10.X.X
vlanID=1729 (optional)
5

Passwords required
Before the upgrade is started, ensure that the following passwords are
known:
On all Core servers
o AA role (ntappadm) user password
o root password
o SSA role (ntsysadm) user password
Only on the Core server(s) hosting the Database
o DBA role (ntdbadm) user password
Only on the MAS Server(s)
o Note down the username/password of the MAS Server(s) and EM.
Only on the AudioCodes EMS
o Note down the username/password for AudioCodes EMS

The new (AS 5300 3.0) License Key is required to deploy the AS 5300
3.0 load. And a new AVAYA MS 7.5 license key is also required for the
applicable services on the AVAYA MS 7.5 platform (i.e., Adhoc,
Announcements, Chat, Music on Hold, and Meet Me Conferencing). Thus,
ensure the AS 5300 3.0 License Key and the AVAYA MS 7.5License Key
have been obtained.
For information about generating/retrieving a license key, please
refer to Appendix L: Retrieving the MCP License Key.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

12

IPCM Decommissioning (following the steps below to make sure IPCM


instances are deleted from the system) IMPORTANT!!
(Note: This is an important step. Upgrade will fail if this step is
not completed.)
After all the hard phones are migrated successfully to the SIP
software from UNIStim firmware, the IPCM NE (which was managing the
UNIStim phones) can be decommissioned.
Note: Please refer to Migration from UNIStim to SIP section of
103.1.3 AS 5300 11x0 SIP Client Configuration MOP for AS 5300 2.0

The following steps describe the procedure to decommission the IPCM


using the AS 5300 2.0 System Manager console.
1. Ensure that all the UNIStim phones are migrated to SIP phones
2. Launch the AS 5300 2.0 System Manager console
3. Click on IP Client Manager NE under Network Elements
4. Click on IPCM NE Maintenance
5. Select the instance in the IPCM Maintenance Panel and stop the
instance by clicking on the Stop button, as shown below.

6. Click on the Yes button in the Confirmation panel

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

13

Document Version 2.6

Method of Procedure

7. Click on the Undeploy button to undeploy all the IPCM NEs as


shown below.

8. Select the Instance and Click on the - (Delete) button to


remove the all the IPCM instances, as shown below.

9. Click on the Yes button in the Confirmation panel.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

14

10.

11.
12.

Select IP Client Managers, and click on the - (Delete)


button to remove the IPCMx as shown below.

Click on the Yes button in the Confirmation panel.


Select IP Client Managers, all the IPCM instances should be
deleted as shown below.

(For a Redundant MCP system only)


Ensure there are a limited number of deferred DB transactions for the
Database
Use the System Management Console to check for deferred transactions
PRIOR to beginning the AS 5300 2.0 to 3.0 upgrade process. Deferred
transactions are changes that have been made to the Database and are
awaiting transfer to the other Database. A few deferred
transactions are fine (as updates are being made to the system), but
the number of deferred transactions should be very low (less than 50)
unless some type of Bulk Provisioning is taking place. In addition,
it is essential to clear (resolve) any/all alarms regarding Database
replication before starting the upgrade process.
From the Management Console, open the Database-><DBname> folders, and
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

15

Document Version 2.6

Method of Procedure

then select Monitor. From the <DBname> Monitor panel, select instance
0 of the Database, and then select the Monitor button at the bottom of
the Panel. Once the Database Instance Monitor panel initializes,
select the Replication Tab to see the number of Deferred Transactions
(as is shown in the screenshot

Suggestion Prior to starting the upgrade process of a Redundant


system, a list should be generated showing the Servers, IP Addresses,
the NEs that are deployed on each server, and whether the server is
designated a Primary or Secondary Server.
Primary/
Secondary

Server
Name

Server IP
address

Associated
NEs

In addition, a list of the Non-Core Servers should be generated. NonCore Servers are servers in which one of the following components are
deployed/running:
MAS
AudioCodes
If the MASs are configured in a redundant configuration, then
reference Appendix A: MAS Upgrade Notes for details in generating an
upgrade order/strategy for these components which limits any service
impact.
The information in these lists can then be referenced (checked-off)
during the upgrade steps out-lined below.
10

Make sure 2.0 Server installation CDs, Server Patch CDs, Core App CDs,
Oracle 10.2.0.4 Installation CDs, Oracle 10.2.0.4 Patch CDs, MAS CDs
exist.
These are needed if a system rollback from 3.0 to 2.0 is required for
some unforeseen reason.

11

Ensure all applicable 3.0 software is on Site prior to starting the


upgrade.
The 3.0 software (CoreApp bundle) in the DVD are extracted to the
servers in Preparatory Steps for two reasons:
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

16

- to reduce the amount of time required during the actual upgrade


- to eliminate the chance of finding a bad CD or DVD during the
upgrade
11a

Extract the latest 3.0 Linux OS Platform Patch to all servers in the
system.
Execute the following steps on the Primary Element Management Server
If a latest Platform Patch CD is available:
- place the Linux OS Platform Patch CD in the DVD tray
- log into the server as an SSA role user
- mcpExtractContent o aat (take note of the extracted
"mcp_core_linux_ple2-<patch>.iso" file)
- type "su " to become the root user
- cd /var/mcp/os/install/images
- Transfer the platform patch (ISO) file to all other core and
MAS servers in the system using SFTP as the AA role user (e.g.,
ntappadm). In the steps that follow, "target server" refers to
the IP address of either a core or MAS server.
- sftp <aa_role_user>@<target_server>
- cd /var/mcp/media
- put mcp_core_linux_ple2_<patch>.iso
Execute the following steps on each remaining server on the Primary
and Secondary half of the system after transferring to these servers:
- Log into the server as an SSA role user
- Type "su " to become the root user
- cd /var/mcp/os/install/images
- mv /var/mcp/media/mcp_core_linux_ple2-<patch>.iso .
- chown root:root mcp_core_linux_ple2-<patch>.iso
- chmod 400 mcp_core_linux_ple2-<patch>.iso

If the latest platform patch is available at Avaya Portal page


https://support.avaya.com/css/appmanager/public/support/Downloads/P0626,
then please manually transfer the platform patch ISO Image file to the
directory /var/mcp/os/install/images (owned by root) for all the
servers.
11b

Extract the AS 5300 3.0 Core Applications to the Primary Element


Management Server by executing the following steps.
- place the MCP Core Applications DVD in the CD-ROM drive
- login as the SSA role (ntsysadm) to the server
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

17

Document Version 2.6

Method of Procedure

- mcpExtractContent o aat

Note:

12

The AS 5300 3.0 load zip file will be copied to the


/var/mcp/loads directory.

The ASU related files will be copied to the


/var/mcp/media/HardenedClient_8.1.XXXX.

After extracting the MCP apps to the Primary EM Server, alarms


will be raised in the System Management Console that a new load
is available

Please determine if there are patches available for the 3.0 MR that is
being upgraded.

If patches are available, then please manually transfer the patches to


the /var/mcp directory on the Primary Element Management Server (owned
by the AA (ntappadm) user).
Note: after the Element Manager has been upgraded to the 15.1 release,
the application patch will be moved to the normal directory
(/var/mcp/dropbox) and database software patch will be moved to the
normal directory (/var/mcp/media).
For detailed information regarding how to download a patch, please
refer to Download Update Files within the 103.1.2_AS
5300_3.0_Software_Update document.

13

Make sure there is no NE with short name "EM".

14

During upgrade procedure System Manager called "SM" will be renamed to


"EM". Use System Management Console to check short names of all NE and
rename them if required.
Manually backup the IPv6 Configuration Data
During the upgrade procedure, all IPv6 data will be removed from the
system and will need to be manually added after the upgrade to 3.0 is
complete. To save the current IPv6 configuration, run the command
- configIPv6
and manually write down (or copy and paste) the current IPv6
onfiguration data for each server and the Avaya SESMs. This command
will need to be run on all servers that have IPv6 enabled. This data
will have to be manually re-entered once the 3.0 upgrade is complete.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

18

3 Process to Upgrade AS 5300 2.0 to


3.0
3.1Upgrading a Redundant System
The diagrams on the following page show redundant 4 server and 2 server
configurations. The Servers and Network Elements (NE) are divided into two
logical networks so that the user can upgrade them with minimal service
downtime. The strategy is to upgrade half of the MCP system/network at a time;
while letting the other half providing service. Thus, the servers are divided into two
groups, Primary and Secondary.
Prov does not have an active/standby configuration; however they are named
Primary and Secondary to match the server they reside on. Please use the following
diagrams to help envision how the Primary Servers/components are upgraded first,
and then the Secondary Servers/components are upgraded next.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

19

Document Version 2.6

Method of Procedure

The following diagrams show the MCP systems are divided into two groups
Primary Servers and Secondary Servers.
Figure 1: Small (2 server) SIP Core configuration

Figure 2: Medium (4 server) SIP Core configuration

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

20

Figure 3: Large (8 server) SIP Core configuration

Note: A data freeze for all provisioning and configuration data must take place after Step
2c. Therefore, it is recommended to execute Step 2a to Step 2c of Table 3: Pre-upgrade
steps for a MCP Redundant configuration system no more than two hours prior to the
maintenance window scheduled for the upgrade.
Table 3: Pre-upgrade steps for a MCP Redundant configuration system
Step # Est. Time

Description

N/A

Ensure the Preparatory Steps (in Table ) have


already been performed.

25 mins

Prepare for the upgrade (drop Database Replication


and backup the database)

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

21

Document Version 2.6


2a

5 mins

Method of Procedure
Ensure there are very few deferred DB transactions for the
Database
Login to the System Management Console to check for
deferred transactions. Deferred transactions are changes
that have been made to the Primary Database and are
awaiting transfer to the Secondary Database. Given there
is a data freeze on for the upgrade process, there should
be very few deferred transactions ( less than 50 since
only registrations and NE admin state changes (by the EM)
are being written to the DB). Note, if less than 50
deferred transactions are present, the upgrade can proceed.
However, there is a potential that some of those
transactions will not be propagated to the Secondary
Database (before Database replication is dropped in the
next step).
From the Management Console, open the Database-><DBname>
folders, and then select Monitor. From the Monitor panel,
select instance 0 of the Database, and then select the
Monitor button at the bottom of the Panel. Once the
Database Instance Monitor panel initializes, select the
Replication Tab to see the number of Deferred Transactions
(as is shown in the screenshot below).

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

22

A snapshot of the Database Monitor with 0 Deferred Transactions:

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

23

Document Version 2.6


2b

Time
will
vary
based on
the size
of the
DB

Method of Procedure
Take a backup (e.g. export) of the data in the database for
safe keeping.
login as the DBA role (ntdbadm) to the server hosting the
primary Database
cd /var/mcp/run/MCP_13.0/<dbName>/bin/util/
./dbBackup.pl repdbupgrade
Note: The generated DB backup file is stored in the
/var/mcp/db/backup directory. for safe keeping.
Also, save off a copy of the dbBackup to the local PC.

2c

15 mins
Idle: 10
mins

Drop Database Replication


login as the DBA role (ntdbadm) to the server hosting the
Primary Database
cd /var/mcp/run/MCP_13.0/<dbName>/bin/util
./cleanupReplication.pl

The following table contains the detailed steps for performing the upgrade.
Table 4: Upgrade a MCP (Redundant configuration) system
Step #

Est. Time

Description

5 mins

Stop the NEs running on the Primary Servers


CallP Impact:
1 min/active SessMgr to failover

1a

Using the MCP System Management console, stop and undeploy


the components running on the Primary Servers.
If additional details are needed regarding how to stop and
undeploy a running component from the SM Console, then
please reference the steps defined in Sections 3.3.1 and
3.3.2.
Stop and undeploy the NEs listed below, except the System
Manager itself, from the System Management Console. Order in
which to stop/undeploy the NEs running on the Primary
Servers:
- Session Managers
- Personal Agent Managers (if any)
- Provisioning Managers
- Accounting Managers
Note that as the components on the Servers are stopped,
Peer presumed failed alarms will be displayed on the
Management console. These alarms are expected.
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

24

1b

5 mins

Stop the System Manager (SM) running on the Primary Element


Management Server.
Login to the MCP System Management Console (using the SM
Service Address) and
Stop the SM running on the Primary Element Management server
(instance 0), by traversing to the SystemManager Folder:

From the NE Maintenance panel, select instance 0, and then


select the Stop ICON (Red Stop Sign) at the bottom of the
panel.
If instance 0 was in a
Hot Standby state, it will go to Offline.
Active state, Then a Warning message will be displayed
stating Connection with the server lost answer OK.
If User Force Out message is received, answer OK.
2

2a

15 mins
(per
server)

Upgrade platform for each of the Primary servers,


including the server hosting the Primary Database.
The Server Patch file(s) should already reside on the
Servers (this was performed in step 11a of Table 2:
Preparatory Steps). Upgrade platform for each of primary
servers.
To reduce the overall time to patch the platform, the
Primary Servers can be patched in parallel by opening a
window to each server, and then executing the
patchPlatform.pl command (described in the step below)
within each window.

2b
Install the latest OS patch (if any)
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

25

Document Version 2.6

Method of Procedure

login as the SSA role (ntsysadm) to the server


su
patchPlatform.pl
A list of available patch ISO files is presented,
followed by the prompt:
Please make selection =>

Enter the number of the menu choice corresponding to the


patch ISO file to be used.

If the locally resident "patchPlatform.pl" command is out


of date, it is automatically updated at this point and
the tool exits after displaying the following message:
The system-resident patching tool (patchPlatform.pl)
has been updated from version x.x.x to version y.y.y.
Please re-execute the (updated) "patchPlatform.pl"
command.

If this happens, then re-execute the patchPlatform


command as described above and continue with the next
step below.

If there are patches that need to be applied, the list to be


applied (the patch chain) is presented, and the following
prompt is given:
Apply patch chain?

20 -40
mins

Enter "y" to apply the patches. The server will


automatically reboot after all patches have been applied.

On the Primary servers hosting the DB and EM,


upgrade the DB (and the data) and the EM to the AS
5300 3.0 load
Note that once the Primary
alarms should be displayed
the given component cannot
Disregard these alarms and

3a

0 mins

DB has been Upgraded, several


on the Management console stating
connect to the Primary DB.
continue with this process.

The MCP_15.1 load (zip file) should already be on the


Primary Element Management Server (this was performed in
step 11b of Table 2: Preparatory Steps)
FYI - before the components can be upgraded to the AS
5300 3.0 load, the AS 5300 3.0 load must be installed
onto the Primary Element Management Server (and the
old/existing 2.0 load must be there as well).
o NOTE: the 2.0 load will not be installed/deployed, but
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

26

it must be resident on the Primary Element Management


Server (in the /var/mcp/loads directory) during the
upgrade to 3.0 to determine Eng/Config Parms that have
been deleted/added/modified between the new and old
loads.
3b

10 - 30
mins

Upgrade the DB and EM to the 3.0 load in the Primary Element


Management Server

Login as the AA role (ntappadm) to the Primary Element


Management Server

cd /var/mcp/install
./mcpUpgradeNextRel.pl
o

select the MCP_15.1 load

Note:
The upgrade script will stop/undeploy SM_1 instance and
deploy/start EM_0 instance
At this point, Primary Element Management Server has been
upgraded from 2.0 to 3.0. System Manager(SM) is renamed to
Element Manager(EM).

Apply patches if applicable.

If there is a MCP 15.1 database software patch to


apply (downloaded in Table 2: Preparatory Steps):
o

Login as the SSA role (ntsysadm) to the Primary


Element Management Server
o su root
o cd /var/mcp
o chmod 660 <postgresql-x.y.z-patch_name>
(e.g.installer-mcp-postgresql-9.0.5-8.LINUX64.zip)
o chown ntappsw:ntappgrp <postgresql-x.y.zpatch_name>
o mv <postgresql-x.y.z-patch_name> /var/mcp/media
o Login as the AA role (ntappadm) to the Primary
Element Management Server

o
o

cd /var/mcp/install
./mcpDbSwPatch.pl primary

If there is a MCP 15.1 core application load patch to


apply (downloaded in Table 2: Preparatory Steps)
o

Login as the SSA role (ntsysadm) to the Primary


Element Management Server

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

27

Document Version 2.6

Method of Procedure

o
o
o
o
o
o
o
o

o
o

su root
cd /var/mcp
chmod 660 <15.1.x.y_patch_name>
chown ntappsw:ntappgrp <15.1.x.y_patch_name>
mv <15.1.x.y_patch_name> /var/mcp/dropbox
Login as the AA role (ntappadm) to the Primary
Element Management Server
cd /var/mcp/loads
ls (wait for the patch load to be generated, note
that you might need to wait up to 10 minutes)

cd /var/mcp/install
./mcpPatch.pl

Pick the <MCP 15.1.x.y patch> load

Note that as the Primary servers, Primary EM and DB are


upgraded, the following alarms may be displayed on the
Management Console
Load audit failed
NEComm
Rogue NE instance
SNMP Agent Communication Failure
Database Communication Error
These alarms are expected and will be cleared once the other
Primary NEs, Secondary Servers and Secondary DB are upgraded
to the 15.1 release.
Also the following is expected:
The db.shared property failed validation, setting it to N
INSTALL, for Database Software on 172.27.153.150 ...
Installing Database Software...please be patient
4

4a

5 mins

Bring up the AS 5300 3.0 Element Manager Console,


insert 3.0 license key and stop DB monitor for the
Secondary DB.
Launch the 3.0 Element Manager Console
At this point, the 3.0 Element Manager Console will be used
to communicate with the 3.0 EM.
Given the upgrade process will cause the SM/EM to failover
between the Primary and Secondary EMs, ensure you are using
the Service Address of the SM/EM (not the IP address of the
server where an SM/EM instance runs) to log into the SM/EM
console during this process.
For details of how to launch the 3.0 Element Manager
Console, please reference Section 7.1 Install/launch the
MCP SM/EM.
2012 Avaya Inc.
28
Avaya proprietary use pursuant to company instructions

Note 1:
To access AS 5300 Element Manager Console in FIPS compliant
mode,a new fips-mgmtconsole.zip file must be downloaded and
unzipped EVERY time the MCP system is upgraded.
The following are quick reference steps:
1.

Download the FIPS Management Console ZIP file by issuing


the following command in the web browser:
https://<AS 5300 Element Manager Console
IP>:12121/fips-mgmtconsole.zip

2.

Save the fips-mgmtconsole.zip file to the workstation

3.

Unzip the file to the C:\ hard drive.

For detailed MCP Hardening steps, please refer to MCP FIPS


configuration section of 105.1.3 AS 5300 3.0 Security
Hardening MOP.
Note 2:
If Custom Certificats are used, please perform the following
steps to apply certificates:
1. Launch the 3.0 Element Manager Console
2. Click on Advance button from Element Manager Console

3. Click Trust Store Certificates tab and click +


button to add Trust Store Certificates

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

29

Document Version 2.6

Method of Procedure

4. Click Key Store Certificates tab and Click + button


to add Key Store Certificates.

5. Click on Connect button to launch Element Manager


Console

4b

With the database and Element Manager updated to the 3.0


release, the associated 3.0 license key must be entered into
the system. To update the License Key select the
NetworkData and Mtc => Licensekey menu option from the
System tree of the Element Manager Console.
For additional details, please reference section 3.2 titled
Steps to Update the License Key
Note: Without a new 3.0 License Key, you will not be able to
deploy any components in the 3.0 system.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

30

4c

Stop the DB monitor for Secondary DB


From the EM

Console:

Open the Database Folder, then the <dbName> folder:


Select Monitor (under the database name) and the Monitor
panel will display.
o Select the instance 1
o Select the Monitor menu button and the Monitor panel
will be displayed
o Select the Stop Monitor menu button at the bottom of
the Monitor panel
o A Confirmation message will be displayed stating
Stopping this monitor will also stop corresponding OM
data collection for this Database Instance!
Do you wish to continue? Answer Yes.
o Close these panels
5

15 mins

Deploy/Start the NEs on the Primary Servers with


the new MCP 15.1load
Reference section 7.2 Deploy/start a Network Element (NE)
if additional details are needed for this process.

5a

Note:
If an NE is in a deactivated, disconnected, or rogue
state, then stop or kill the NE to get it to the offlined
state. Once in the offlined state, the load can be
changed and it will go to the configured state.
Due to the DB migration, an NE that was stopped before is
likely in an Online state although its Operation State is
Unavailable. Stop or kill the NE before deploying it.
Reference section 7.2 Deploy/start a Network Element (NE)
if additional details are needed for this process.

5b

Deploy and Start the remaining NEs on the Primary Servers


1. Select the MCP 15 load that you use for upgrade in
Instance Windows first prior to deploy.
o
o
o
o
o

Open the Instance window for the NE


Select the instance to be deployed
Click the -/+ button
Use the Load or Patch dropdown box to select
the MCP 15 load
Click the Apply button

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

31

Document Version 2.6

Method of Procedure

2. Deploy and Start the NEs listed below, from the


Element Manager Console
Order in which to deploy and start the 3.0 NEs:
Fault Performance Managers (if any)
Accounting Managers
Provisioning Managers
Personal Agent Managers (if any)
Session Managers
NEs can be upgraded/deployed in parallel.
Note:
While the PROV is being deployed, the "Media Application
Server Unreachable" alarm will be displayed on the Element
Manager Console. This alarm is expected and will clear once
the PROV is deployed and started successfully.
If IPv6 was configured on the 2.0 AS 5300 SESM, the IPv6
configuration that was manually saved during the backup
procedure must be manually re-applied to the 15.1 AS 5300
SESM once it is deployed. Refer to section "4.8 Configuring
AS 5300 SESM IPv6 Service Address" of 101.2.6 AS 5300 IPv6
Configuration for details on configuring an AS 5300 SESM
IPv6 address. Once the 3.0 AS 5300 SESM IPv6 address has
been manually configured, the AS 5300 SESM must be restarted
to pick up the IPv6 address.
5c

With the upgraded 3.0 (non-redundant) system, please


reference sections 3.4 & 3.5 for instructions regarding
changes that may be required to the existing data.
The provisioning changes (if any are required), can be
performed in parallel with the remaining steps - which
upgrade the Secondary servers/components of the system to
15.1.
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

32

10 mins

Stop the remaining 2.0 core NEs running on the


Secondary servers. This will force the Primary
NEs (on the 3.0 system) to take over activity.

6a

10 mins

Using the Element Manager Console stop and undeploy the


Running Secondary NEs (this forces traffic to the upgraded
15.1 Primary components).
Order in which to stop the remaining 2.0components:
Session Managers
Personal Agent Managers (if any)
Provisioning Managers
Accounting Managers
Fault-Performance Managers (if any)
If additional details are needed regarding how to stop and
undeploy a running component from the Management console,
then please reference the steps defined in Sections 3.3.1
and 3.3.2.

20 mins

7a

Install the ASU files on the PA/PROV residing on


the Primary Servers.
Install the 2.0 ASU files on the Primary Servers.
Please reference the following section to install the 7.2
Hardened Clients for the Provisioning Managers and Personal
Agent Managers running on the Primary Servers. Note that the
8.1 ASU will be installed later once the 3.0 system (nonredundant) is verified to be functioning properly.

Varies

9.1.2 Installing 7.2 Hardened Client ASU files on the


MCP Server for instructions regarding the ASU.

You now have one half of the Core upgraded to the


AS 5300 3.0 release and the active NEs are
executing on the 3.0 system (non-redundant)

8a
At this point in time, the Active side of the Core is
Running on the 3.0 release (non-redundant) with the
Redundant Core components (on the Secondary Servers) stopped
and still on the 2.0 release.
Please perform some sanity tests using 7.2 Hardened clients
to verify the 3.0 non-redundant system is functioning
properly.
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

33

Document Version 2.6

Method of Procedure

Thus, this is the point in the process to ensure


the 3.0 system (running on the Primary Servers) is
operating correctly prior to Upgrading the
remaining 2.0 servers/components.
If for some unforeseen reason the 3.0 system is not
operating correctly, you can rollback to a 2.0 system by
following the steps defined in section 11.1 Rollback one
half of an upgraded system.
9

Data Freeze for Provisioning User Data ends here

9a

With the 3.0 simplex system up and running, the customer can
begin making user data provisioning changes via the 3.0
NEs/components running on the Primary Servers (e.g. the data
freeze for provisioning user data is now off). However,
note that in the unlikely event that the 3.0 system is
rolled back to the old/previous 2.0 system, any/all
provisioning changes made to the 3.0 system will be lost.

10

10 mins/
server

10a

Upgrade the platform for the remaining Secondary


servers
Upgrade the remaining secondary servers, which consist of:
2.0 components that were just stopped.

Secondary
Secondary
Secondary
Secondary

System Manager (SM)


Session Manager
Database
PROV

The Server Patch file(s) should already reside on the


Servers (this was performed in step 11a of Table 2:
Preparatory Steps).
For each of the Secondary Servers:
Upgrade the Linux servers using step 2b (the Upgrade
process can be done in parallel across the servers):
11
11a

10 mins

Uninstall Oracle and Install Postgres on the Secondary


Database
Execute the script that performs all of the necessary
functions to change the database.
Note: Make sure execute the following scripts from PRIMARY
Element Management server hosting the DB and SM
login as the AA role (ntappadm) to the Primary System
Management server
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

34

cd /var/mcp/install
./oracleUninstall.pl -secondary
./mcpDbSwInstall.pl -secondary

./mcpDbSwPatch.pl -secondary (if there is database


software patch available)

Deploy and Start the Secondary EM server

12

Reference section 7.2 Deploy/start a Network Element (NE)


if additional details are needed for this process.
12a

From the Element Manager Console, deploy Secondary EM with


15.1 load

12b

From the Element Manager Console, start Secondary EM with


Reference section 7.2 Deploy/start a Network Element (NE)
if additional details are needed for this process.

13

25 mins

Deploy and Start the remaining Core NEs on the


Secondary Servers
Reference section 7.2 Deploy/start a Network Element (NE)
if additional details are needed for this process.

13a

From the Element Manager Console, deploy and start the


remaining NEs.
If an NE is in a deactivated, rogue, or disconnected
state, then stop or kill the NE to get it to the offlined
state. Once in the offlined state, the load can be
changed and it will go to the configured state.
Given the DB was backed up when the NEs were up and running,
an NE may show an Online Admin state, with an Operation
State of Unavailable. For this case, Stop or kill the NE
to get it to the offlined Admin state.
The ordered list of NEs to deploy and start on the Secondary
Servers is:
-

Fault Performance Managers (if any)


Accounting Managers
Provisioning Managers
Personal Agent Managers (if any exist)
Session Managers

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

35

Document Version 2.6

Method of Procedure

In addition, ensure you are using the Service Address of the


EM (not the IP address of the server where an EM instance
runs) to log into the Element Manager Console, since there
is no guarantee which instance will be active.
If IPv6 was configured on the 13.0 AS 5300 SESM, the IPv6
configuration that was manually saved during the backup
procedure must be manually re-applied to the 15.1 AS 5300
SESM once it is deployed. Refer to section "4.8 Configuring
AS 5300 SESM IPv6 Service Address" of 101.2.6 AS 5300 IPv6
Configuration for details on configuring an AS 5300 SESM
IPv6 address. Once the 15.1 AS 5300 SESM IPv6 address has
been manually configured, the AS 5300 SESM must be restarted
to pick up the IPv6 address.

All AS 5300 Core components have now been upgraded


to 3.0, and are using the upgraded 3.0 Primary
database.

14

15

25 mins

Set up Database replication

15a

25 mins

Execute the script that performs all of the necessary


functions to setup Database Replication.
login as the AA role (ntappadm) to the Primary Element
Management server
cd /var/mcp/install
./setupDBReplication.pl
Note: During the process of DB replication setup, an alarm
regarding the IMDB is not able to get information from the
DB may be generated by the NEs. These alarms are not
service effecting and should be acknowledged.

16
16a

5 mins

Ensure the Database Monitors are started


Start the Database Monitors to monitor the state of the
DBs.
Note: The Database monitor for DB instance 1 was stopped
before. It will definitely need to be started.
From the Mgmt Console:
Open the Database Folder, then the <dbName> folder:
Select Monitor (under the database name) and the Monitor
panel will display. For each DB instance:
o Select the instance
o Select the Monitor menu button and the Monitor panel
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

36

will be displayed
If the Monitor is not running, select the Start
Monitor menu button at the bottom of the Monitor
panel
Close these panels

Note:
You might need to re-start DB monitor for DB instance 0, if
Replication tab is not displayed after DB resync
completes.
A screenshot of the Database Monitor

16b

Start the Server Monitors so that the system will generate


alarms when the server has high CPU, Memory, Disk, or I/O
usage.
Open the Servers Folder, and then for each Server configured
execute the following steps:
Open the given server folder
Select Monitor (under server) and the Monitor panel will
be displayed
If the Monitor is not running, select the Start Monitor
menu button at the bottom of the Monitor panel
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

37

Document Version 2.6

Method of Procedure

A screenshot of a Server Monitor

17

For upgrades of hardened 2.0 systems to 3.0, perform the


following to configure the HTTPS cipher suites:

18

Access the AS 5300 Element Manager Console


o (if MCP FIPS is enabled: run fips-mgmtconsole.bat,
o if MCP FIPS is not enabled: https://<AS 5300 Element
Manager Console IP>:12121)
Login as the "admin" user
Click "+" next to Network Data and Mtc
Click "+" next to Cipher Suites
Click HTTPS Cipher Suites
Modify the HTTPS Cipher Suites to ensure that only the following
are enabled, disable all others:
SSL_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
Click Apply
Restart all Provs and EM (both inactive and active)

varies

Steps to complete the core components upgrade

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

38

18a
Please refer to sections 3.4 and 3.5 for instructions
regarding changes that may be required to the existing data.
Please verify those changes (if any was required) are
completed.
18b

Install the 2.1 ASU on the Secondary Servers.


Please reference the following section to install the 2.1ASU
for the Provisioning Managers and Personal Agent Managers
running on the Secondary Servers. Note that the 8.1 ASU will
be installed later once the 3.0 system is verified to be
functioning properly

18c

Varies

18d

9.1.2 Installing 7.2 Hardened Client ASU files on the


MCP Server for instructions regarding the ASU files.

The 3.0 Core Components upgrade is now complete. Please


perform some sanity tests using the 7.2 Clients to verify
the 3.0 system is functioning properly.
Once it is verified that the 15.1 load is functioning
properly, then simultaneously delete the oldest MCP load
from the Primary and Secondary Element Management Servers.
Normally, the current and previous MCP loads should be
retained on the Element Management Servers. All other old
loads should be removed.

18e

19

19a

If for some unforeseen reason the 3.0 system becomes nonoperational, please reference Section 11.2 Rollback an
entire system, for instructions regarding the rollback of
an entire redundant system to the 2.0 release.
25 mins

Step to perform once it is verified that the 3.0


system is functioning properly

5 mins
Now that all NEs have been upgraded to use the MCP_15.1
load, remove the <13.0.x_loadname>.zip file from both
Primary and Secondary Element Management Servers
o login as the AA role (ntappadm) to the Primary and
Secondary Element Management Server
o cd /var/mcp/loads
o rm <13.0.x_loadname>.zip
or
o rm R f v MCP_13* (optional: if you want to remove all
MCP_13 directory stored under /var/mcp/loads)
Note:
User should perform the commands in parallel [e.g. have two
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

39

Document Version 2.6

Method of Procedure
windows up, one for each EM server, and execute the commands
one after another on the two servers]

19b

Time
will
vary
based on
the size
of the
DB.
20 mins

Once the upgrade has completed, a 15.1 Database backup


should be taken (as a precautionary step).

login as the DBA role (ntdbadm) to the server hosting the


Primary Database.
cd /var/mcp/run/MCP_15.1/<DBname>/bin/util
./dbBackup.pl post_15.1_upgrade

Note: The generated DB backup file is stored in the


/var/mcp/db/backup directory.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

40

Table 5: Post-upgrade steps


Step # Est. Time

Description

This step contains the detailed process for taking server


backups of the upgraded Core system.

10 mins

Backup configuration data (/admin) for every Core Server.


Backup the Primary and Secondary Element Management Servers
loads, media and install directories.
If you are familiar with the execution of the MCP backup
script, the commands to perform backups are shown below.
additional details are required, then please refer to
Section 4.3 Backup of an MCS server in 103.2.3 AS 5300
Backup And Restore MOP.
/usr/local/bin/configBkup.pl

If

For the configuration data and application data (if


available) backup of Core Server, execute the following
command,
/usr/local/bin/bkupSvr.pl
For the configuration data backup of a Core Server, execute
the following command,
/usr/local/bin/bkupPlatform.pl
Recommendation of where to backup is as follows:
1. Set the backup of all servers (except Secondary
Element Management Server) to Secondary Element
Management Server directory /var/mcp/backup/remote/15.1
2. The backup of Secondary Element Management Server will
be taken using the local option in the Secondary
Element Management Server directory
/var/mcp/backup/local/
Note, prior to taking remote backups, please ensure that
/var/mcp/backup/remote/15.1 directory exists on the
Secondary Element Management Servers by executing the
following steps.
o Login as the SSA role (ntsysadm) to the
Secondary Element Management Servers
o su - root
o cd /var/mcp/backup/remote
o ls -l
o Check if 15.1 directory exists. If not, create 15.1
directory as follows:
o mkdir 15.1
o chown root:ntsysgrp 15.1
o chmod 770 15.1
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

41

Document Version 2.6

Method of Procedure

Once it is ensured that the /var/mcp/backup/remote/15.1


directory exists, follow the steps below to take backups of
the server.
o Login as the SSA role (ntsysadm) to the servers which
you want to take a backup
o For all servers except the Secondary Element Management
Server, execute configBkup to enable remote backup
configuration parameters for all backup jobs (Select
Option 2).
[ntsysadm@ ]$ configBkup
You are required to set:
o IP address of remote backup server (Primary or
Secondary Element Management Server or any other
server that you want)
o Directory on remote backup server where backup tar
files are located (/var/mcp/backup/remote/15.1)
o SSA role (ntsysadm) username to use for remote SSH
commands
o Previously generated SSH keys
o Select exit when finished.
o On the Primary Element Management Server, backup the
Configuration and Application data to the Secondary
Element Management Server
[ntsysadm@ ]$ bkupSvr remote
o On the Secondary Element Management Server, backup the
Configuration and Application data to the Secondary
Element Management Server
[ntsysadm@ ]$ bkupSvr local
[ntsysadm@ ]$ cd /var/mcp/backup/local
[ntsysadm@ ]$ mv mcp* /var/mcp/backup/remote/15.1/
o For all other core servers, backup the Configuration
data to the Secondary Element Management Server
[ntsysadm@ ]$ bkupPlatform remote
2

Varies

Steps that can be performed now, or in a later


Maintenance Window

2a

Varies

Upgrade the MAS components to 3.0


Please reference section 5 Appendix A: MAS Upgrade Notes for
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

42

o Instructions regarding upgrading Multiple MASs.


o Instructions to upgrade the base software on the server.
Note: After upgrade, 2.0 MAS becomes 3.0 AVAYA MS.
2b

Varies

Upgrade the AudioCodes components to its latest MR (if they


exist in this system)
The upgrade steps are as follows:
1) Upgrade the EMS using 101.2.1 AS 5300 Install & Config
Method for Audiocodes EMS
2) Upgrade the M3K using 101.2.2 AS 5300 Install & Config
Method for Audiocodes M3K GW
3) Upgrade the MP-112/124 IADs, if they exist, using
101.2.3 AS 5300 Install & Config Method for
AudiocodesMP112/124
4) Upgrade the M500s, if they exist, using 101.2.4 AS
5300 Install & Config Method for Audiocodes M800 IAD

Please reference Upgrade/Downgrade the GW/MP Firmware Using EMS


section of the each MOP mentioned in Appendix G: Upgrade
AudioCodes to its latest MR for Instructions to upgrade
the base software on the server.
2c

If for some unforeseen reason, the Audiocodes or 15.1 AVAYA


MS need to rollback, follow the procedures below:
AudioCodes Gateways or MPs: (if it has been upgraded to
15.1)
For procedure to rollback/downgrade Audiocodes, please refer
to Upgrade/Downgrade the GW/MP Firmware Using EMS section in each
of the MOPs mentioned in Appendix G: Upgrade the AudioCodes
Firmware for Instructions to downgrade/rollback the base
software on the server.

AVAYA MS: (if it has been upgraded to 15.1)


The steps to restore the 13.0 MAS are defined in Section 0

5 mins

Clean up the /var/mcp/backup/remote directory


Once the MCP 15.1 System has been operating satisfactory for
a period of time (a few days), the 13.0 directory can be
removed. Please note that once the
/var/mcp/backup/remote/13.0 directory is removed, the server
rollback to the previous release will not be possible.

Login as the SSA role (ntsysadm) to the Primary Element


Management Server
su - root

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

43

Document Version 2.6

Method of Procedure

cd /var/mcp/backup/remote
rm rf 13.0

Note: This step is applicable only for Federal Civilian and


Enterprise. For DoD, the ASU patch will be delivered via
DVD.

Execute this step to download the ASU patch only if a 15.1.x


patch was downloaded in step 12 of Table 2: Preparatory
Steps.
Download the Hardened Client related software for this 15.1
MR patch.
For example:
Title:
o HardenedClient 8.1.<version_number>
o ASU HardenedClient 8.1.<version_number>

Transfer the Hardened Client to the proper location.


o Login as the AA role (ntappadm) to the server
hosting the Primary EM.
o cd /var/mcp/media
o ls HardenedClient_8.1.<version_number>
where <version_number> is the Hardened Client
version number for the patch found above
o If this directory exists, skip the rest of the
Patching ASU procedure since there is no need to
download the Hardened Client.
o mkdir HardenedClient_8.1.<version_number>
o chmod 770 HardenedClient_8.1.<version_number>
o cd HardenedClient_8.1.<version_number>
Download the
ASU_HardenedClient_8.1.<version_number>.zip
o unzip ASU_HardenedClient_8.1.<version_number>.zip
o rm ASU_HardenedClient_8.1.<version_number>.zip
o chmod 660 *
o cd ..
o ls
o Remove the older Hardened Client ASU files that were
extracted from the 15.1.x Core App Bundle.
rm -rf HardenedClient_8.1.<old_version_number>

Install the ASU files for the 8.1 Hardened Client on the
Primary and Secondary PROV/PA server(s).

Please reference the below section to install the 8.1 ASU


for the Provisioning Managers and Personal Agent
Managers.

9.1.1 Installing 8.1 Hardened Client ASU files on the AS


2012 Avaya Inc.
44
Avaya proprietary use pursuant to company instructions

5300 3.0 Server


6

5 mins

To capture the timestamps for the upgrade scripts that were


executed on the server hosting the Primary EM.

Login as the AA role (ntappadm) to the Primary Element


Management Server
cd /var/mcp/run/install/logs
find . -mtime -3 | xargs fgrep " at => " | tee
timestamps_file
Note: The command above is capturing timestamps from the
log files which are less than 3 days old. Output from the
command is displayed to screen, and written to the
timestamps_file. In addition, you can change the number
of days (-3) if needed.

Perform Network separation (optional), once it is verified


that Media Server and Audiocodes are working fine with SIP
Core.
In AS 5300 3.0 the system can be configured to use separate
networks for Internal OAM, External OAM, Signaling and Media
traffic. To configure the system in this way, please
reference the 105.1.1 AS 5300 Network Separation document
for configuring the VLAN.

Manually Configure IPv6 (optional)


If the servers had IPv6 enabled prior to the upgrade, then
using the IPv6 data written down in the pre-upgrade steps,
refer to the IPv6 Configuration MOP and perform all the
steps in that doc to manually re-configure IPv6 on each IPv6
capable server.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

45

Document Version 2.6

Method of Procedure

3.2 Steps to Update the License Key


An alarm will be raised by the Element Manager when the EM and DB are
upgraded to the 15.1 release, and the 13.0 License Key is still being used.
Figure 4: Management Console License Key Invalid Alarm

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

46

To update the License Key from the Management Console, the user selects the
Network Data and Mtc=>Licensekey menu option from the System tree as shown
in the following figure.
Figure 5: Management Console Update License Key Right-Click Option

The Edit option is available from the bottom of the License Key panel as shown
in the above figure.
Once the Edit button is selected, a dialog box is displayed to the Administrator to
Update the License Key. The Update window is shown in Figure 6: Management
Console Update License Key Window.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

47

Document Version 2.6

Method of Procedure

Figure 6: Management Console Update License Key Window

Once the new license key is selected, click on open and license key information is
displayed as shown in the following figure. To enter the new license key, click on
apply.
Figure 7: Management Console License Key Information Dialog

In addition, the alarm shown in Figure 4: Management Console License Key


Invalid Alarm, will be cleared once a valid license key is entered.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

48

3.3Steps to find/stop/undeploy Primary/Stand-by


NEs
To find/stop/undeploy NEs executing on the Primary/Secondary Servers, you first
must know the Server Names for the Primary/Stand-by Servers that the NEs are
deployed to.
If you do not know the Server names, but do know the IP addresses of the servers
in question, then first display the Servers Panel to find the Interface 1 value for
the given servers.
Figure 8: Management Console Servers Panel

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

49

Document Version 2.6

Method of Procedure

Then display the Addresses panel to display the mapping of IP address to Logical
Interface name. Matching the Logical Name to the above Interface 1 value will
give you the Server Name to IP address mapping required.
Figure 9: Management Console IP Addresses Panel

To
find/determine the NEs that are deployed to a server or set of servers, bring up
the Physical view from the Management Console (which is the 5th ICON from the
left, below the Main Menu Bar).
Figure 10: Management Console Physical View ICON

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

50

The physical view panel is displayed once the ICON has been selected. From the
Physical View panel, open up the Physical Sites folder, the Site1 folder, and then
the Servers Folder, as shown in Figure 11: Management Console Physical View
panel.
Figure 11: Management Console Physical View panel

Then under the Servers folder, open the folder for each physical server that you
are searching to find the deployed NEs for. In the screenshot below the
EMServer1, and the SESMServer1 have been opened, and then the Instances
folder opened to display the NE instances that are deployed onto each of these
servers.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

51

Document Version 2.6

Method of Procedure

Figure 12: Management Console Physical View with Servers/NE instances

Once the NE Instances are found/determined for the given physical servers, then
for each NE Instance perform the steps in section 3.3.1 Steps to Stop a given
NE to stop the NE Instance.

3.3.1 Steps to Stop a given NE Instance


Given a NE Instance Name, and the type of NE it is (e.g. a Session Manager, a
Prov Manager etc.), open the Network Elements folder from the Config Tree (left
hand panel of the main Management Console display).

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

52

Figure 13: Management Console Config Tree

Then open the appropriate component type folder for the NE instance (e.g.
Session Managers), and then open the folder with the given NEname, and select
the NE Maintenance service under that NEs folder. The screenshot below
shows the NE Maintenance panel for the SESM1 NE.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

53

Document Version 2.6

Method of Procedure

Figure 14: Management Console NE Maintenance Panel

To stop the NE instance from the NE Maintenance panel, select the given Instance
from the panel, and then select the Stop ICON (Red Stop Light 4th ICON from
the left) at the bottom of the Maintenance panel.

3.3.2 Steps to Undeploy a given NE Instance


Follow the same steps shown in section 3.3.1- Steps to Stop a given NE
Instance to open the Maintenance Panel for the given NE instance.
The given NE instance must be in an Offline State (shown in the NE
Maintenance window), before it can be undeployed (in the NE Instance
window). Thus, if the given NE instance is not in the OffLine State, then follow
the steps in section 3.3.1- Steps to Stop a given NE Instance to stop it. If for
some reason the NE does not go to the OffLine State, then select the Kill ICON
(ICON farthest to the right) to kill the instance.
To undeploy the given NE Instance, select the given Instance from panel, and
then select the Undeploy ICON (Red Arrow going up 2nd ICON from the left)
at the bottom of the Maintenance panel. The screenshot below shows how to
undeploy the SESM1 NE Instance 0.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

54

Figure 15: Management Console Undeploy a given NE

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

55

Document Version 2.6

Method of Procedure

3.4Config Data changes that may be required


The modifications discussed within this section (if they apply to the given system)
should be implemented once the system has been upgraded to the new 15.1
release.

3.4.1 Directory Change for Records on OSS Server


If FTP push was configured to transfer the records from the MCP system to an
OSS server, please be aware that the directory of the records on the OSS server
will change after the upgrade to AS 5300 3.0. .The directory structure in which
records are transferred to the OSS server, have the following new structure:
<Root Directory>/oss/<stream>/<EM>/<filter>/<format>/<ne_id>
where
- Root Directory -- is the value defined for the Root Directory parameter
- stream -- is log, om, or acct
- EM -- identifies the element manager that gathered the data such as SM, FPM,
or AM.
- filter is the name of the filter (e.g all, etc.)
- format is the Predefined record format name. (e.g.: MCP, CSV)
- ne_id is the <Short name of network element>_<Instance number>. (e.g.:
SESM1_0.)
For comparison purposes, below is the format of this same structure in the AS
5300 2.0 release:
<Root Directory>/oss/<stream>/MCP_13.0/<EM>_instance/<ne_id>/<format>

3.4.2 Config Data Changes


The modifications discussed within this section (if they apply to the given system)
should be implemented on the Primary Database as soon as possible to eliminate
any service impact. Note that in a redundant configuration no changes are
required to the Secondary database, because the changes made to the Primary
Database will be replicated to the Secondary Database when the two Databases
are resyncd.
As a reference, the table below maps a Section to the filename (report) that is
generated for a given issue. Thus, if the user finds any file(filename) in the
/var/mcp/run/MCP_15.1/<dbName>/dataChanges directory after the upgrade has
been executed, the user should follow the instructions within those file(s), this
table will inform the user which section describes the issue that is documented in
the given file.
Note: Log into the server hosting the Primary Database as the DBA role user
(ntdbadm) to view these files.
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

56

Table 6: Section to Filename mapping for Config Data Changes

Section

Filename

Currently, there are no Config Data changes defined/required for this upgrade.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

57

Document Version 2.6

Method of Procedure

3.5 Provisioning Data changes that may be required


after the Database Upgrade
Currently, there are no Provisioning Data changes defined/required for this
upgrade.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

58

4 Definitions & Abbreviations


Table 8: Definitions & Abbreviations

ASU

Automatic Software Update

CD-ROM

Compact Disc Read Only Memory

DVD

Digital Video Disc

DB

Database

EM

Element Manager (server)

Gig

Gigabyte

GUI

Graphical User Interface

IP

Internet Protocol

IPCM

IP Client Manager

MAS

Media Application Server

MCP

Multimedia Communications Platform

MOP

Method of Procedure

OS

Operating System

PC

Personal Computer

SIP

Session Initiation Protocol

SM

System Manager (server)

SSA

System Security Administrator

SSH

Secure Shell

URL

Universal Resource Locator (internet address)

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

59

Document Version 2.6

Method of Procedure

4.1External Documents Referenced


Table 9: Documents referenced by this MOP
Document Name
101.2.2_AS 5300 Install and Config Method for Audiocodes_M3K PRI GW
101.2.1 AS 5300 Install and Config Method for Audiocodes EMS
101.2.3 AS 5300 Install and Config Method for Audiocodes MP1xx
101.2.4 AS 5300 Install and Config Method for Audiocodes M800
101.2.5 AS 5300 Install and Config Method for Audiocodes M1K PRI GW
102.1.9 AS 5300 IPv6 Configuration
102.2.7 AS 5300 2.0 to 3.0 AVAYA MS Upgrade
103.1.2_AS 5300_Software_Update
103.1.2_AS 5300_Software_Update
103.2.3 AS 5300 Backup And Restore
105.1.1 AS 5300 Network Separation
105.1.3 AS 5300 Security Hardening Guide
105.4.1 AS 5300 Security Administration

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

60

5 Appendix A: MAS Upgrade Notes


5.1MAS Platform Upgrade (13.0 to 15.1)
For procedures to install and upgrade a 13.0 MAS to 15.1 AVAYA MS , please reference
the Major Release Upgrade section within the latest version of the 102.2.7 AS 5300
2.0 to 3.0 AVAYA MS Upgrade document.

5.2MAS Platform Rollback (15.1 to 13.0)


To rollback the AVAYA MS/MAS Platform from7.5 to 6.6, please reference the Major
Release Rollback section in the latest version of the 102.2.7 AS 5300 2.0 to 3.0
AVAYA MS Upgrade document.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

61

Document Version 2.6

Method of Procedure

6 Appendix C: Example installprops file


An example installation properties file for a deployment of a system with a
Replicated database is shown below. Lines starting with !--" are comment lines
and not processed by system. Comment lines are used to describe how to fill in
the file according to the deployments needs. For a typical deployment, do not
change the parameters shown below in gray. Parameter values that should be
set according to the given MCP system environment are in bold face.
!-- Sample props file for use with both DB and EM install
!-- Load to use/deploy
!-- Example: ne.load=MCP_13.0.0.0_2010-03-12-0500
ne.load=MCP_13.0.0.0_2010-05-05-2200
!-- The machine logical address of the server that the EM is being
installed on.
ne.mgmt.ip=47.105.83.86
!-- The base port of the EM. Except for well known ports, all
communication
!-- ports used by an element will be in the range basePort-basePort+99
!-- Default is 12100
ne.mgmt.basePort=12100
!-- Element ManagerElement Manager network element name. Must be 6
characters or less.
!-- Default is EM.
ne.name=EM
!-- EM Instance identifier (0/1).
ne.instance.id=0

Default is 0.

!-- Instance engineering configuration


!-- AS5300_Small_X3550M2M3-8GB4Core, AS5300_Small_X3550M2M3-8GB8Core,
!-- AS5300_Small_X3550-8GB8Core,
!-- AS5300_Small_Other-8GB4Core, AS5300_Small_Other-8GB8Core,
!-- AS5300_Medium_X3550M2M3-8GB4Core, AS5300_Medium_X3550M2M3-8GB8Core,
!-- AS5300_Medium_X3550-8GB8Core,
!-- AS5300_Medium_Other-8GB4Core, AS5300_Medium_Other-8GB8Core,
!-- AS5300_Large_X3550M2M3-8GB4Core, AS5300_Large_X3550M2M3-8GB8Core,
!-- AS5300_Large_X3550-8GB8Core,
!-- AS5300_Large_Other-8GB4Core, AS5300_Large_Other-8GB8Core,
!-- Demo_Small_Other-4GB2Core
ne.config=AS5300_Medium_X3550-8GB8Core
!-- Machine logical IP address of the database server
db.host=47.105.83.86
!-- Database server platform (solaris/linux)
platform=linux
!-- DB NE name, used as both the logical name of the database,
!-- as well as the directory name into which the database bundle

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

62

!-- will be deployed on the database server. Must be 6 characters or


less.
!-- Default is mcpdb.
db.neName=mcpdb
!-- DB type (Single or Replicated)
!-- Default is Replicated
db.type=Replicated
!-- If type set to Replicated (above), then provide
!-- valid machine logical IP address for the Secondary database (ignored
if
!-- instance is set to Single)
db.secHost=47.105.83.87
!-- Should database be backed up on upgrades, default is Y
db.backup=Y

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

63

Document Version 2.6

Method of Procedure

7 Appendix D: MCP SM/EM CONSOLE


Notes
The following notes cover how to install/launch the AS 5300 Element Manager
(EM) Console /System Management (SM) Console , and how to use the
CONSOLE to deploy/start the MCP components. Please reference the Mgmt
Console documentation for all other details regarding use of the Management
Console.

7.1Install/launch the MCP SM/EMCONSOLE


To install/launch the SM/EM CONSOLE, bring up Internet Explorer (IE) and
enter the following URL
http://<Service Address of the SM/EM>:12120
or https://<Service Address of the SM/EM>:12121
- where <IP address> is the Service IP address of the SM/EM
- if a Service IP address does not exist for the SM/EM, then use the Server
IP address of the server that the SM/EM executes on.
Then select Launch MCP System Management Console for 13.0, Launch AS
5300 Element Manager Console for 15.1, as shown in the following figures:
Figure 16: Launch AS 5300 2.0 Element Manager Console Window

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

64

Figure 17: Launch AS 5300 3.0 Element Manager Console Window

The SM/EM console will automatically load/install using files resident on the
SM/EM.
For redundant System/Element Manager installations select the correct one from the drop
down menu and press connect.
Figure 18:

Element Manager Console Connection Frame fpr AS 5300 2.0

Figure 19:

Element Manager Console Connection Frame fpr AS 5300 3.0

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

65

Document Version 2.6

Method of Procedure

For redundant System/Element Manager Installations, the IP address in the


Service Address drop down box of the MCP Management Console login
window will be different than the IP address that is found in the install
property file.

Enter the appropriate UserID and Password.

Figure 20:: Login to the Element Manager Console for 2.0

Figure 21: Login to AS 5300 Element Manager Console for 3.0

Select Ok.

Note: If the Pre and Post Login Security Banners are enabled in the system, the
Pre-Login banner is displayed and need to be acknowledged before attempting to
login and the Post-Login banner is displayed and need to be acknowledged after
logging in to proceed with the main Management Console screen.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

66

If you are not able to launch the Management Console, please refer to section 7.3
User Forced Out msg or Unable to launch MCP Mgmt Console.

7.2Deploy/start a Network Element (NE)


Once you have logged into the Management Console, a given Network Element
(NE) can be deployed and started by performing the following steps.
From the initial display window, select the Network Elements folder as shown in
the next figure.
Figure 22 Initial Management Console display window

Open the Network Elements folder, and then open the folder for the type of
component and the folder for the currently configured NE that you are going to
deploy/start. Under the given NE folder, select Instance (to display the NE
Instance window), and then select NE Maintenance (to display the NE
Maintenance window).
The given NE instance must be in an Offline or Configured State (shown
in the NE Maintenance window), before the load can be updated (in the NE
Maintenance window). Thus, if the NE instance being updated is not in the
OffLine or Configured State, then select the instance from the NE Maintenance
window and select the Stop ICON (4th from the left). If for some reason the NE
does not go to the OffLine or Configured state, then select the Kill ICON (ICON
farthest to the right) to kill the instance.
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

67

Document Version 2.6

Method of Procedure

To deploy and start an NE using the new load, the instance must be modified to
use (e.g. configure) the 3.0 load.
To modify the load, select the instance from the NE Instance window and select
the Edit ICON (2nd from the left). In the new pop up window, click on the drop
down menu next to Load or Patch, select the latest load and click Apply.
Figure 23: Configure a NE to the 15.1 load from the NE instance window

Figure 24: Apply the 15.1 load from the pop up window

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

68

Once the load has been updated to the new 3.0 load, then from the NE
Maintenance panel, select the instance, and then select the first ICON (from the
left) to deploy the instance. FYI - if you place your cursor over the first ICON, it
will show that the ICON is the Deploy Icon, as shown below.
Figure 25: Deploy a NE Instance Maintenance panel

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

69

Document Version 2.6

Method of Procedure

Once the NE has been deployed, from the same NE Maintenance panel select the
third ICON (from the left) to start the instance. FYI - if you place your cursor
over the third ICON, it will show that the ICON is the Start Icon, as shown
below.
Figure 26: Start a NE Instance Maintenance panel

Once the NE has started successfully, it will go to the Active or Hot Standby
state.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

70

7.3User Forced Out msg or Unable to launch MCP


Mgmt Console
If you receive the message User Forced Out when attempting to
login with the Management Console, and no one has forced you
out:

OR
If any of the following error messages is received (most likely
after a 3.0 Mgmt console has been used, and then you are
attempting to use the old 2.0 Mgmt Console):

Then on your PC bring up a Java Cache Viewer window (Start->Run


and then enter javaws viewer into the Open field) as shown
below

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

71

Document Version 2.6

Method of Procedure

This will cause a new window to be displayed. From the Java


Application Cache Viewer, select the MCP Mgmt Console Application
and then select the Remove Selected Items button at the top of
the panel.

Once the MCP Mgmt Console Application(s) have been removed, then
exit from the above window (click on the Close button), and then
try opening the Management Console from an Internet Explorer
window again.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

72

8 Appendix E: Installing OnlineHelp files


In AS 5300 2.0/3.0 the online Help files for the Provisioning Manager/Personal Agent
were separated out from the MCP software load file (installed/unzipped on the
Element Manager Server), and Help Files were contained in a separate zip file (on the
same CD as the MCP software load).
In AS 5300 3.0 online Help have been included into the MCP software load file and
now the Help Files are installed automatically.

8.1 Install the AS 5300 2.0 OnlineHelp files


Note, in the example below the Provisioning Manager has been named PROV1.
Thus, replace PROV1 with the name that has been given the Provisioning Manager or
Personal Agent Manager within the given system.
The MCP-OnlineHelp_13.0.X.X_<date-time>.zip should already be on the Primary
Element Management Server (this was performed in the step 4a of Table 2:
Preparatory Steps).
To download the zip file to a server hosting Provisioning Manager/Personal
Agent:
1. login as the AA role (ntappadm) to the server hosting Provisioning
Manager/Personal Agent
2. cd /var/mcp/media/prov_pa_installs
If the Provisioning Manager/Personal Agent is not on the Primary System
Management Server, execute step 3 to sftp the zip file from the Primary System
Management Server and proceed to step 6, otherwise proceed to step 4.
3. sftp the MCP-OnlineHelp_13.0.X.X_<date-time>.zip file from the Primary
System Management Server.
o sftp 47.10.10.20
(where 47.10.10.20 is the IP address of the Primary System Management
Server. Please replace it with the IP address used in your system)
o Enter the AA role (ntappadm) password.
o cd /var/mcp/media
o get MCP-OnlineHelp_13.0.X.X_<date-time>.zip
o exit
If the Provisioning Manager/Personal Agent is on the Primary System
Management Server, execute step 4-5 to copy the zip file from the /var/mcp/loads
directory.
4. ls /var/mcp/media
5. cp /var/mcp/media/MCP-OnlineHelp_13.0.X.X_<date-time>.zip .
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

73

Document Version 2.6

Method of Procedure

Once the zip file has been installed onto the server hosting the Provisioning
Manager/Personal Agent, then execute the utility script to extract all of the help
files from the MCP-OnlineHelp zip file.
6. cd /var/mcp/run/MCP_15.1/PROV1_0/bin
7. ./installHelp.pl z MCP-OnlineHelp_15.1.X_<date-time>.zip
With the Help files successfully extracted from the MCPOnlineHelp_13.0.X.X_<date-time>.zip file, the updated Online Help Files will now
be accessible from the Provisioning Manager/Personal Agent client and the 7.2
PCClient.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

74

9 Appendix F: Installing ASU files


Below is a list of notes (Information) regarding Automatic Software Update (ASU)
files and the installation of them onto the Provisioning Server.

9.1 Installing Client ASU files


9.1.1 Installing 8.1 Hardened Client ASU files on the AS 5300 3.0 Server
Note, in the example below the Provisioning Manager has been named PROV1.
Thus, replace PROV1 with the name that has been given the Provisioning Manager or
Personal Agent Manager within your system.
The HardenedClient_8.1.<release info>_Release.jnlp, HardenedClient_8.1.<release
info>_Release.zip and HardenedClient_8.1.<release info>_UnsignedRelease.zip files
should already be on the server (this was performed in Step 11b of Preparatory
Steps.
To download the jnlp and zip files to a server hosting Provisioning
Manager/Personal Agent:
1. login as the AA role (ntappadm) to the server hosting Provisioning
Manager/Personal Agent
2. cd /var/mcp/media/prov_pa_installs/
If the Provisioning Manager/Personal Agent is not on the Primary Element
Management Server, execute step 3 to sftp the jnlp and zip files from the Primary
Element Management Server and proceed to step 8, otherwise proceed to step 4.
3. sftp the HardenedClient*8.1*.jnlp and HardenedClient*8.1*.zip files from the
Primary Element Management Server.
o sftp 47.10.10.20
(where 47.10.10.20 is the IP address of the Primary Element Management
Server. Please replace it with the IP address used in your system.
o Enter the AA role (ntappadm) password
o cd /var/mcp/media
o cd HardenedClient_8.1.XXXX
o mget HardenedClient*8.1*.jnlp
o mget HardenedClient*8.1*.zip
o exit
If the Provisioning Manager/Personal Agent is on the Primary Element
Management Server, execute step 4-6 to copy the jnlp and zip files from the
/var/mcp/media directory.
4. ls /var/mcp/media
5. cp /var/mcp/media/HardenedClient_8.1.XXXX/HardenedClient*8.1*.jnlp .
6. cp /var/mcp/media/HardenedClient_8.1.XXXX/HardenedClient*8.1*.zip .
7. ls /var/mcp/media/prov_pa_installs
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

75

Document Version 2.6

Method of Procedure

Once the files have been installed onto the server hosting the Provisioning
Manager/Personal Agent, then execute the utility script to extract the ASU files.
8. cd /var/mcp/run/MCP_15.1/PROV1_0/bin
9. ./installASU.pl -j HardenedClient_8.1.<release info>_Release.jnlp -s
HardenedClient_8.1.<release info>_Release.zip u
HardenedClient_8.1.<release info>_UnsignedRelease.zip
- where <release info> is the release number and date of the client

9.1.2 Installing 7.2 Hardened Client ASU files on the MCP Server
Note, in the example below the Provisioning Manager has been named PROV1.
Thus, replace PROV1 with the name that has been given the Provisioning Manager or
Personal Agent Manager within your system.
The HardenedClient.jnlp and HardenedClient.zip files should already be on the server
(this was performed in the Step 4b of Table 2: Preparatory Steps).
To download the jnlp and zip files to a server hosting Provisioning
Manager/Personal Agent:
1. login as the AA role (ntappadm) to the server hosting Provisioning
Manager/Personal Agent
2. cd /var/mcp/media/prov_pa_installs/
If the Provisioning Manager/Personal Agent is not on the Primary Element
Management Server, execute step 3 to sftp the jnlp and zip files from the Primary
Element Management Server and proceed to step 8, otherwise proceed to step 4.
3. sftp the HardenedClient.jnlp, HardenedClient_Release.zip and
HardenedClient_unsigned.zip files from the Primary Element Management
Server.
o sftp 47.10.10.20
(where 47.10.10.20 is the IP address of the Primary Element Management
Server. Please replace it with the IP address used in your system.
o Enter the AA role (ntappadm) password
o cd /var/mcp/media
o cd HardenedClient_ASU_preupg
o get HardenedClient.jnlp
o get HardenedClient*.zip
o exit
If the Provisioning Manager/Personal Agent is on the Primary Element
Management Server, execute step 4-6 to copy the jnlp and zip files from the
/var/mcp/media directory.
4. ls /var/mcp/media
5. cp /var/mcp/media/HardenedClient_ASU_preupg/HardenedClient.jnlp .
6. cp /var/mcp/media/HardenedClient_ASU_preupg/HardenedClient*.zip .
7. ls /var/mcp/media/prov_pa_installs
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

76

Once the jnlp and zip files have been installed onto the server hosting the
Provisioning Manager/Personal Agent, execute the following steps to install the ASU
files.
8. cd /var/mcp/run/MCP_15.1/PROV1_0/bin
9. ./installASU.pl -j HardenedClient.jnlp -s HardenedClient_Release.zip u
HardenedClient_unsigned.zip
-

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

77

Document Version 2.6

Method of Procedure

10 Appendix G: Upgrade AudioCodes to its


latest MR
For procedure to upgrade an existing AS 5300 2.0 AudioCodes GW or MP from
5.8 firmware load to AS 5300 3.0 AudioCodes GW or MP 6.2 firmware load and
rollback procedure for downgrading the GW or MP from 6.2 firmware load to 5.8
firmware load, please reference the MOPs below.
For GW, see section on Upgrade/Downgrade the GW Firmware Using EMS of
101.2.2 AS 5300 Install and Config Method for Audiocodes M3K PRI GW or
101.2.5 AS 5300 Install and Config Method for Audiocodes M1K PRI GW
For MP, see section on Upgrade/Downgrade MP Firmware Using EMS of
101.2.3 AS 5300 Install and Config Method for Audiocodes MP1xx or
101.2.4 AS 5300 Install and Config Method for Audiocodes M800
User needs to upgrade the EMS first then the gateways and IADs.
The upgrade steps are as follows:
1) Upgrade the EMS using 101.2.1 AS 5300 Install & Config Method for
Audiocodes EMS
2) Upgrade the M3K using 101.2.2 AS 5300 Install & Config Method for
Audiocodes M3K GW
3) Upgrade the MP-112/124 IADs, if they exist, using 101.2.3 AS 5300
Install & Config Method for AudiocodesMP112/124
4) Upgrade the M500s, if they exist, using 101.2.4 AS 5300 Install & Config
Method for Audiocodes M800 IAD
If the Audiocodes needs to be rolled back, please refer to Upgrade/Downgrade
GW/MP Firmware Using EMS section in each of the MOPs mentioned above.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

78

11 Appendix H: Rollback Steps


There are two logical points in a Major Release upgrade, in which a Rollback can
be performed:

A redundant system is being upgraded, and after half of the system has been
upgraded, it was determined that the new system (AS 5300 3.0) was not
functioning correctly. Thus, a decision was made to take that half of the
system back to the previous release (AS 5300 2.0) that had been running
(from Step 11 of section 0 ). For this scenario, follow the steps defined in
section 11.1 Rollback one half of an upgraded system.

An entire redundant system has been upgraded to AS 5300 3.0 and it was
determined that the AS 5300 3.0 system was not functioning correctly. Thus,
a decision was made to go back to the AS 5300 2.0 release that had been
running prior to the upgrade. For this scenario, follow the steps defined in
section 11.2 Rollback an entire system.

Note:
If during the steps to rollback a AS 5300 system, you receive the message User
Forced Out when attempting to login to a 2.0 System Management Console, then
please reference section 7.3 User Forced Out msg or Unable to launch MCP
Mgmt Console, for details of a workaround for this known Java Web Start issue
(that can occur when switching back and forth between login to Management
Consoles on different MCP releases).

11.1 Rollback one half of an upgraded system


If for some unforeseen reason the half of your system (the Primary Servers) that
has been upgraded to 3.0 is not operating correctly, you can rollback to a 2.0
system by performing the following steps:

Note: When the Primary servers are rolled back, the data on these servers will
be removed completely, but the data on the Secondary servers will be
retained.
Table 9: Downgrade one half of a Redundant system
Step # Est. Time Description
1

5mins

Prior to starting a Downgrade, ensure you


have backups (from the previous release) of
all the servers being downgraded, and a
backup of the /var/mcp/loads directory
(containing the previous 2.0 load) on the
Element Manager. The backups should already
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

79

Document Version 2.6

Method of Procedure

be stored in /var/mcp/backup/remote/13.0 on
the Secondary Element Management Server from
previous Preparatory Steps.
Note: For safe keeping, also save off a copy
of the 2.0 backup files to local PC, or USB
drive, or remote disk.
In addition, if any changes were made to the
data stored in the 3.0 Database, those
changes will be lost when the DB is restored
with the 2.0 backup.
2

15 mins

Stop the 15.1 components that are running on


the Primary Servers (except EM)
CallP Time: 1 min

2a

Using the 3.0 Element Manager Console, stop the


components running on the Primary Servers. Order
in which to stop the NEs running on the Primary
Servers:
- Session Managers
- Personal Agent Managers (if any)
- Provisioning Managers
- Accounting Managers
Stop a running Primary component by performing
the steps defined in Section
3.3.1 - Steps to Stop a given NE Instance

5 mins

Stop the DB monitor for Primary DB and Stop Primary

Element Manager
3a

From the

Management Console:

Open the Database Folder, then the <dbName> folder:


Select Monitor (under the database name) and the
Monitor panel will display.
o Select the instance 0
o Select the Monitor menu button and the Monitor
panel will be displayed
o Select the Stop Monitor menu button at the
bottom of the Monitor panel
o Click Yes to confirm
o Close these panels
3b
Login to the MCP

Management Console and

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

80

Stop the EM running on the Primary Element Management


server (instance 0)
From the NE Maintenance panel, select instance 0, and
then select the Stop ICON (Red Stop Sign) at the
bottom of the panel.
Answer Yes for the exit confirmation message.
Answer OK for the warning message.
3c

4
4a

You now have a Single 2.0 system up and providing


litmited service.
varies

Rollback the Primary Servers to 2.0.


Re-install 2.0 platform on each server and Restore
backup sets on Primary Servers.
On each Primary Servers, execute the steps in section
10.1 General Server Restore of document 103.2.3 AS
5300 2.0 System Backup & Restore.
Note 1:
If re-install platform using the data stored on
Secondary Element management Server and IPSec is
enabled, then IPSec need to be disabled before
executing step 5 of above mentioned section 10.1 and
IPSec need to be re-enabled after step 15 of section
10.1 is completed for all the Secondary Servers.

Login as the SSA role (ntsysadm) to the


Secondary Element Management Server to disable/enable
IPSec
. ipsecstatus (check IPSec status)
. stopipsec (prior to Step 5 of section 10.1)
. startipsec (after step 15 of section 10.1)

Note 2: If you are familiar with the restore process,


you can use the following as a quick reference.
Only on the Primary Element Management Server:
Restore the backups on the Primary Element Management
Server.
Login as the SSA role (ntsysadm) to the Primary
Element Management Server to restore the backup.
Execute configBkup to enable remote backup
configuration parameters (Select Option 2).
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

81

Document Version 2.6

Method of Procedure

[ntsysadm@ ]$ configBkup
You are required to set:
o IP address of remote backup server
(Secondary Element Management Server or any
other server that you want)
o Directory on remote backup server where
backup tar files are located
(/var/mcp/backup/remote/13.0)
o SSA role (ntsysadm) username to use for
remote SSH commands
o Previously generated SSH keys
o Select exit when finished.
o Execute the restoreSvr script to restore the
Application data on the Primary Element
Management Server
[ntsysadm@ ]$ restoreSvr remote

For more details on restore process, refer section


4.4 of 103.2.3_AS 5300_Backup_And_Restore MOP.

4b

Re-install and patch Oracle on Primary DB, Restore


Primary DB.
If the server hosts the primary DB, log onto the
server hosting the primary System Manager as an AA
role (ntappadm) and install and patch Oracle, to its
latest release level, for the primary database only
login as the AA role (ntappadm) to the Primary
Element Management server
cd /var/mcp/install
./oracleInstall.pl -primary
./oraclePatch.pl -primary
Refer to Step 1 of section 10.2 Primary DB, Primary
SM Restore of document 103.2.3 AS 5300 2.0 System
Backup & Restore.
For more details on Oracle Application installation
process, refer sections 8.1 install and 8.2 Patch
Current of "102.1.2 AS 5300 Initial System
Installation",

1 hour

Resync the two Databases (Resync from


Secondary to Primary)
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

82

CallP Time: 2 mins


5a

Perform a dbInstall (files only) to put the 2.0


scripts/files back on the server hosting the
Database.
login as AA role (ntappadm) to the Primary Element
Management Server
cd /var/mcp/install
./dbInstall.pl fo
Answer Y to the following prompts after verifying
the settings:
Continue with these settings? (Y/N)[N]:
Perform "Deploy Files Only" operation to Secondary
DB also (Y/N)?[Y]:

5b

60 mins

On the Secondary DB, resync the DBs


(Ensure that this step is performed on the Secondary
DB - NOT on the Primary DB.)
Using the Secondary Database, utilize the resync
script to copy the data in the Secondary DB to the
Primary DB, and then setup/start Database
replication.
login as DBA role (ntdbadm) to the server hosting
the Secondary Database
TMOUT=0
cd /var/mcp/run/MCP_13.0/<dbName>_1/bin/util
./resync.pl
Answer Y to the prompts

6a

15 mins

Redeploy and start all of the 13.0


Components on the Primary servers
Redeploy and start Primary SM
Only on the Primary Element Management Server:
login as AA role (ntappadm) to the Primary Element
Management Server
cd /var/mcp/install
./smDeploy.pl
./smStart.pl
Answer Y to the prompts

6b

From the

Management Console:

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

83

Document Version 2.6

Method of Procedure
For each NE on the Primary Servers, deploy and start
the NE instance from the NE Maintenance window on the
System Management Console.
Recommended order of deploying and starting NEs
according to their types is as follows:
o Provisioning Managers
o Personal Agent Managers
o Accounting Managers (deploy only)
o Session Managers

FYI the order to downgrade the Primary components


is not really important since the 13.0 components on
the Secondary servers are currently providing
service.
If an NE is in a deactivated, disconnected or
rogue state, then stop or kill the NE to get it to
the offlined state. Once in the offlined state,
the load can be changed and it will go to the
configured state.
If an NE is in a Online state although its
Operation State is Unavailable. Stop or kill the NE
before deploying it.
Reference section 7.2 Deploy/start a Network Element
(NE) if additional details are needed for this
process.
If IPv6 was configured on the AS 5300 2.0 SESM, the
IPv6 configuration will be removed if an undeploy
command is performed. If an undeploy and deploy are
performed for an AS 5300 SESM that had an IPv6
configuration, the IPv6 configuration must be
manually re-applied to the AS 5300 SESM after the
deploy. A redeploy (without an undeploy) will not
remove the IPv6 configuration data. Refer to section
"4.8 Configuring AS 5300 SESM IPv6 Service Address"
of 101.2.6 AS 5300 IPv6 Configuration for details on
configuring a AS 5300 SESM IPv6 address. Once the AS
5300 SESM IPv6 address has been manually configured,
the AS 5300 SESM must be restarted to pick up the
IPv6 address.
7

5 mins

Restart
running
traffic
Primary

the redundant 2.0 components


on the Secondary Servers to force
back to the instance running on the
Servers

CallP Time: 1 min


2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

84

7a

5 mins

From the System Management Console, configure the 2.0


load in the Instance window, deploy the AS 5300 2.0
load to the System Manager on the Secondary server
(if not already done), and then start that System
Manager.
Reference section 7.2 Deploy/start a Network Element
(NE) if additional details are needed for this
process.

7b

After Resyncing the DBs, the standby components


running on the Primary Servers should be restarted.
Using the 2.0 System Management console, restart the
redundant components that are standby on the
Primary Servers.
From the NE Maintenance panel, select the NE Instance
0, and then select the
Restart ICON (Red & Green Arrows 5th ICON from the
left)

7c

Now, force traffic back to the instance(s) running on


the Primary Servers, by restarting the instance on
the Secondary Servers.
Using the 2.0 System Management console, restart the
redundant components that are active/running on the
Secondary Servers.
From the NE Maintenance panel, select the NE Instance
1, and then select the
Restart ICON (Red & Green Arrows 5th ICON from the
left).

varies

Downgrade associated Hardened clients that are used


in conjunction with the MCP components on the Primary
Servers.

8a

5 mins

Install 2.0 OnlineHelp files


Please reference the following sections to install
the 13.0 OnlineHelp for the Provisioning Managers and
Personal Agent Managers running on the Primary
Servers.
1 Install the AS 5300 2.0 OnlineHelp files

8b

varies

Install ASU files


Please reference the following section to install the
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

85

Document Version 2.6

Method of Procedure
7.2 ASU for the Provisioning Managers and Personal
Agent Managers running on the Primary Servers.
9.1.2 Installing 7.2 Hardened Client ASU files
on the MCP Server

10 mins

9a

Ensure the Database and Server monitors are started.


If not, execute step 15 of Table 4: Upgrade a MCP
(Redundant configuration) system to start the
Database and Server monitors.
Note: The Database monitor for DB instance 0 was
stopped before. It might need to be restarted.

10

The system is now back on the 2.0 Release.

11.2 Rollback an entire system


If for some unforeseen reason the AS 5300 3.0 system is not operating correctly,
you can rollback an entire 3.0 system to the previous AS 5300 2.0 system by
performing the steps shown in the following table Table 10: Downgrade an
Entire Redundant system.

Table 10: Downgrade an Entire Redundant system


Step # Est. Time Description
0

5 mins

Prior to starting a Downgrade, ensure you


have backups (from the previous release) of
all the servers being downgraded and a
backup of the /var/mcp/loads directory
(containing the previous 13.0 load) on the
Element Manager. The backups should already
be stored in /var/mcp/backup/remote/13.0 on
the Secondary Element Management Server from
previous Preparatory Steps. The backup files
need to be transferred to Primary Element
Management Server prior to the downgrade.
Note 1: If re-install option is chosen to
use data stored on USB drive or remote
server other than Secondary Element Server,
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

86

then the following steps can be skipped.


Transfer backup files from Secondary Element
Management Server to Primary Secondary Server by
performing the following steps:
- login as the SSA role (ntsysadm) to the Primary
Element Management Server
- cd /var/mcp/backup/remote/
- mkdir 13.0
- cd 13.0
- sftp ip_address (Secondary Element Management
Server IP address
(eg: sftp 47.11.148.23)
- cd /var/mcp/backup/remote/13.0

- get *.tar

Note 2:
For safe keeping, also save off a copy of
the 2.0 backup files to local PC, or USB
drive, or remote disk.
Note 3:
In addition, if any changes were made to the
data stored in the 3.0 Database, those
changes will be lost when the DB is restored
with the 2.0 backup.
0a

N/A

Before starting the downgrade of a redundant system,


the user should compose a list of all the
applications names & IP addresses (including the
redundant applications). Then, as applications are
downgraded, mark them off of the list. This will
help as applications are switched from active to
standby, and back again.
The status of the instance (Active, Standby.) is
shown in the Maintenance window of the NE instance
on the System Management console.
Any data written to the Secondary DB (registrations)
during the downgrade process will be lost.
The database access layer (used by all of the
Network Elements (NE) which connects to the
database) is designed such that the NE instance will
only setup communications with a database which has
the same (or higher) version as the NE. This allows
the downgrade process the ability to downgrade the
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

87

Document Version 2.6

Method of Procedure
DB and the NE instances in a single (one-by-one)
fashion, and the NEs will connect to the correct DB
based on the current load/version installed.

0b

1 hour/
NE

If needed, restore the 3.0 AVAYA MS to 2.0


MAS
AVAYA MS: (if it has been upgraded to 3.0)
The steps to restore the 2.0 MAS are defined in
Section 0

5 mins

1a

Stop all 3.0 Provisioning Managers and


Personal Agent Managers
Using the 3.0 Element Manager Console, stop the
Provisioning Managers and Personal Agent Managers
running on the Primary and Secondary Servers. FYI,
this is done to prevent any additional provisioning
changes from being made to the 3.0 DB/data. In the
Full rollback scenario, the Primary DB is left on
15.1 until the end of the rollback process, and then
the Secondary DB is used to populate (resync) the
Primary DB to the 2.0 release/schema. Thus, we
should not allow any provisioning changes to the 3.0
Primary DB, and this is accomplished by stopping the
Provisioning Managers/Personal Agent Managers
components.
Provisioning Managers
Personal Agent Managers
For more details, please refer to section 3.3.1 Steps
to Stop a given NE Instance

10 mins

Drop Database Replication

2a

10 mins

login as the DBA role (ntdbadm) to the server hosting


the Primary Database
cd /var/mcp/run/MCP_15.1/<dbName>/bin/util
./cleanupReplication.pl
Enter Y at the following prompt
You are about to drop replication between the 2
Databases. This will put both Databases into a
"single mode", and changes will not be replicated
between them.
Please Confirm(Y/N): [N]

10 mins

Stop the 3.0 components that are running on


2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

88

the Secondary Servers


CallP Time: 10 mins
3a

Using the 3.0 Element Manager Console, stop the


components running on the Secondary Servers. Order
in which to stop the 15.1 components:
Session Managers
Accounting Managers
Stop a running components by performing the steps
defined in Section 3.3.1 Steps to Stop a given NE
Instance

3b

Using the 3.0 Element Manager Console, stop the


Element Manager on the Secondary Element Management
Server.
Reference 3.3.1 Steps to Stop a given NE Instance
for more details.

4
4a

120
mins

Rollback the Secondary Servers:


Re-install the Secondary Servers with the 13.0
platform using the platform restore backup set
On each of the Secondary Servers, execute steps 1 to
15 from section 10.1 of document "103.2.3 AS 5300 2.0
System Backup & Restore" to re-install platform and
apply platform patch.

Note 1:
If re-install platform using the data stored on
Primary Element management Server and IPSec is
enabled, then IPSec need to be disabled before
executing step 5 of above mentioned section 10.1 and
IPSec need to be re-enabled after step 15 of section
10.1 is completed for all the primary servers.

Login as the SSA role (ntsysadm) to the Primary


Element Management Server to disable/enable IPSec
. ipsecstatus (check IPSec status)
. stopipsec (prior to Step 5 of section 10.1)
. startipsec (after step 15 of section 10.1)
4b

Re-install and patch Oracle on Secondary DB Server


In order to install and patch Oracle on the Secondary
DB server, log into the server hosting the primary
Element Manager as an AA role (ntappadm) and perform
the following steps.
2012 Avaya Inc.
89
Avaya proprietary use pursuant to company instructions

Document Version 2.6

Method of Procedure

login as the AA role (ntappadm) on the Primary


Element Management server (EMS)
Ensure the Oracle installer and patch are
available on the primary EMS in /var/mcp/media
directory.
If the files are not present, refer to section 7
of "102.1.2 AS 5300 2.0 Initial System
Installation" on how to extract Oracle from the
13.0 media.

Copy the install scripts from the directory of


the MCP_13.0 load (you are rolling back to) to
/var/mcp/install directory.

cd /var/mcp/loads/<MCP_13.0load>/install_scripts/bin
cp * /var/mcp/install
cp .* /var/mcp/install

cd /var/mcp/install
On the primary EMS (currently running 15.1),
change the ne.load within the installprops.txt
file to point to the MCP_13.0 load you are
rolling back to (if ne.load is not set
correctly)
o To do this run the command :
./populateInstallprops.pl

./oracleInstall.pl -secondary
./oraclePatch.pl -secondary

For more details on Oracle Application installation


process, refer sections 8.1 and 8.2 of "102.1.2 AS
5300 2.0 Initial System Installation",
4c

Only on the Secondary Element Management Server:


Restore the Application backup on the Secondary
Element Management Server.
Login as the SSA role (ntsysadm) to the Secondary
Element Management Server to restore the backup.

o cd /var/mcp/backup/local
o Transfer backup file mcpApp.<Primary EM
Server's hostname>.<date.time>.tar from remote
backup server:
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

90

- sftp ip_address (Primary Element Management


Server IP address
(eg: sftp 47.11.148.22)
- cd /var/mcp/backup/remote/13.0
- get mcpApp.<Primary EM Server's
hostname>.<date.time>.tar

- get mcpLoad.<Secondary EM Server's


hostname>.<date.time>.tar
loads are not available)

(if AS 5300 2.0

o mv mcpApp.<Primary EM Server's
hostname>.<date.time>.tar mcpApp.<Secondary EM
Server's hostname>.<date.time>.tar
o Execute the restoreSvr script to restore the
Application data on the Secondary Element
Management Server
[ntsysadm@ ]$ restoreSvr local

For more details on restore process, refer section


4.4.2 Restore from Local drive of
103.2.3_AS5300_Backup_And_Restore MOP.
Note: Ensure the AS 5300 2.0 loads you are
rolling back are available on the secondary EMS
in /var/mcp/loads

If the files are not present, refer to


section 7 of "102.1.2 AS 5300 2.0 Initial
System Installation" on how to extract from the
13.0 media.
4d

Restore the 2.0 install scripts/files on the server


hosting the Secondary Database.
Login as AA role (ntappadm) to the Secondary
Element Management Server
cd /var/mcp/install
Edit the installprops.txt file to update:
o ne.mgmt.ip to be the IP address of the
Secondary Element Management Server.
o ne.instance.id to 1
o ne.name = SM (if ne.name is not SM)
cp installprops.txt installprops.txt.sav
Edit the installprops.txt file to update:
o db.host to be the IP address of the server
hosting the Secondary Database.
o db.type to Single.
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

91

Document Version 2.6

Method of Procedure

Perform a dbInstall (files only) to put the 13.0


scripts/files on the server hosting the Database.
./dbInstall.pl fo
Answer Y to the following prompts after verifying
the settings:
Continue with these settings? (Y/N)[N]:
Perform "Deploy Files Only" operation to Secondary DB
also (Y/N)?[Y]:
4e

Move the temporary DB directory on the server hosting


the Secondary DB

5a

Varies
(30
mins)

Login as the SSA role (ntsysadm) to the server


hosting the Secondary DB
su - root
cd /var/mcp/run/MCP_13.0/
/bin/rm -rf <dbName>_1
mv <dbName>_0 <dbName>_1

Restore the 2.0 Database backup into the


Secondary DB
Restore the 2.0 Database backup into the Secondary DB
login as the DBA role (ntdbadm) to the server
hosting the Secondary Database
TMOUT=0
cd /var/mcp/db/backup
sftp the repdbupgrade.tar.gz file from the server
hosting the Primary Database.
o sftp 47.10.10.20
(where 47.10.10.20 is the IP address of the
server hosting the Primary Database. Please
replace it with the IP address used in your
system)
o Enter the DBA role (ntdbadm) password
o cd /var/mcp/db/backup/oracle
o get repdbupgrade.tar.gz
o exit
ls lrt
(make sure the size of repdbupgrade.tar.gz is the
same as what is on the server hosting the Primary
Database.)
Restoring the contents of the database is
accomplished by importing the 13.0 backup into the
database.
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

92

cd /var/mcp/run/MCP_13.0/<DBname>_1/bin/util
./dbRestore.pl repdbupgrade.tar.gz
o repdbupgrade.tar.gz is the name of the
13.0 backup taken prior to the upgrade
starting
Verify the import worked successfully - from the
messages displayed to the screen.
Note that once the Secondary DB has been rolled back,
several alarms should be displayed on the Management
console stating the given component cannot connect to
the Secondary DB nor have database Communication
Error. Disregard these alarms and continue with this
process.
5b

Stop the DB monitor for Secondary DB.


From the

Management Console:

Open the Database Folder, then the <dbName> folder:


Select Monitor (under the database name) and the
Monitor panel will display.
o Select the DB instance 1
o Select the Monitor menu button and the Monitor
panel will be displayed
o Select the Stop Monitor menu button at the
bottom of the Monitor panel
o Close these panels
5c

Downgrade the load to 2.0 for each NE on the


Secondary Servers (including the System Manager NE):
(IMPORTANT: DO NOT deploy and start Secondary SM from
NE Maintenance window on SM CONSOLE)
System Manager
Provisioning Managers
Personal Agent Managers
Accounting Managers
Session Managers
In the NE Maintenance window:
If an NE that was stopped before, it is likely in
Online state although its Operation State is
Unavailable, stop or kill the NE before deploying
it.
In the NE instance window:
select the instance
click edit button(+/-) and an edit window will be
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

93

Document Version 2.6

Method of Procedure
displayed
Select the previously deployed 13.0 loadname
from the pulldown list (the previous 13.0 load
may already be selected - from the data that was
restored in the Database.)
Click the apply button
Deploy and start the NE instance from the NE
Maintenance window for all the NEs on Secondary
Server except Secondary System Manager. (DO NOT
deploy and start Secondary SM from NE Maintenance
window on SM CONSOLE)

Login as the AA role (ntappadm) to the server


hosting Secondary System Manager, deploy and
start SM:
-

cd /var/mcp/install
./smDeploy.pl
./smStart.pl

If IPv6 was configured on the 2.0 AS 5300 SESM, the


IPv6 configuration will be removed if an undeploy
command is performed. If an undeploy and deploy are
performed for an AS 5300 SESM that had an IPv6
configuration, the IPv6 configuration must be
manually re-applied to the AS 5300 SESM after the
deploy. A redeploy (without an undeploy) will not
remove the IPv6 configuration data. Refer to section
"4.8 Configuring AS 5300 SESM IPv6 Service Address"
of 101.2.6 AS 5300 IPv6 Configuration for details on
configuring an AS 5300 SESM IPv6 address. Once the AS
5300 SESM IPv6 address has been manually configured,
the AS 5300 SESM must be restarted to pick up the
IPv6 address.
6
6a

10 mins

Force the traffic over to Secondary Servers


Using the 3.0 Element Manager Console, stop the
components running on the Primary Servers (except
for the Element Manager NE), thus forcing traffic
over to the components (on the Secondary Servers)
running the 2.0 release.
Order in which to stop the 3.0 components:
Session Managers
Accounting Managers
Stop a running Primary component by performing the
steps defined in Section
3.3.1 - Steps to Stop a given NE Instance
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

94

6b

Failover the Element Manager to the Secondary Server


Login to the MCP Element Manager Console and Stop the
EM running on the Primary Element Management server
(instance 0), by traversing to the SystemManager
Folder:
From the NE Maintenance panel, select instance 0, and
then select the Stop ICON (Red Stop Sign) at the
bottom of the panel. A Confirmation message will be
displayed stating Stopping the active Element
Manager will cause the Management Console to exit
answer Yes.
Note that after the active EM switch to the Secondary
server, Load audit failed, NEComm and Rogue NE
instance alarms might display on the Management
console. These alarms are expected and will be
cleared once the other Primary NEs are downgraded to
the 13.0 release.

6c

Stop the DB monitor for the Primary DB


From the

Management Console:

Open the Database Folder, then the <dbName> folder:


Select Monitor (under the database name) and the
Monitor panel will display.
o Select the instance 0
o Select the Monitor menu button and the Monitor
panel will be displayed
o Select the Stop Monitor menu button at the
bottom of the Monitor panel
o Click Yes to confirm
o Close these panels
7

8
8a

0 mins

120
mins

A Single 2.0 system is now up and providing


limited service
(no provisioning changes can be made yet due to the
active 2.0 database being the Secondary DB with
limited write access).

Rollback the Primary Servers


Prior to starting a rollback Primary
Servers, ensure you have backups (from the
previous release) of all the servers being
downgraded and a backup of the
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

95

Document Version 2.6

Method of Procedure

/var/mcp/loads directory (containing the


previous 13.0 load) on the Element Manager.
The backups should already be stored in
/var/mcp/backup/remote/13.0 on the Primary
Element Management Server from previous
Steps. The backup files need to be
transferred to Secondary Element Management
Server prior to the downgrade.
Note 1: If re-install option is chosen to
use data stored on USB drive or remote
server other than Secondary Element Server,
then the following steps can be skipped.
Transfer backup files from Secondary Element
Management Server to Primary Secondary Server by
performing the following steps:
- login as the SSA role (ntsysadm) to the
Secondary Element Management Server
- su root
-

cd /var/mcp/backup/remote/
mkdir 13.0
chown root:ntsysgrp 13.0
chmod 770 13.0

- exit out of root and login as the SSA role


(ntsysadm)
- cd /var/mcp/backup/remote/13.0
- sftp ip_address (Primary Element Management
Server IP address
(eg: sftp 47.11.148.22)
- cd /var/mcp/backup/remote/13.0

- get *.tar
8b

Re-install platform and Restore backup sets on


Primary Servers
On each Primary Servers, execute the steps in section
10.1 General Server Restore of document 103.2.3 AS
5300 2.0 System Backup & Restore.
Note 1:
If re-install platform using the data stored on
Secondary Element management Server and IPSec is
enabled, then IPSec need to be disabled before
executing step 5 of above mentioned section 10.1 and
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

96

IPSec need to be re-enabled after step 15 of section


10.1 is completed.

Login as the SSA role (ntsysadm) to the


Secondary Element Management Server to disable/enable
IPSec
. ipsecstatus (check IPSec status)
. stopipsec (prior to Step 5 of section 10.1)
. startipsec (after step 15 of section 10.1)
Note 2:
If you are familiar with the restore process, you can
use the following as a quick reference.
Only on the Primary Element Management Server:
Restore the Application backup on the Primary Element
Management Server.
Login as the SSA role (ntsysadm) to the Primary
Element Management Server to restore the backup.
Execute configBkup to enable remote backup
configuration parameters (Select Option 2).
[ntsysadm@ ]$ configBkup
You are required to set:
o IP address of remote backup server
(Secondary Element Management Server or any
other server that you want)
o Directory on remote backup server where
backup tar files are located
(/var/mcp/backup/remote/13.0)
o SSA role (ntsysadm) username to use for
remote SSH commands
o Previously generated SSH keys
o Select exit when finished.
o

Execute configSvrBkup to regenerate SSH keys


o

[ntsysadm@ ]$ configSvrBkup

o Execute the restoreSvr script to restore the


Application data on the Primary Element
Management Server
[ntsysadm@ ]$ restoreSvr remote
For more details on restore process, refer section
4.4 of 103.2.3_AS5300_Backup_And_Restore MOP.
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

97

Document Version 2.6

8c

Method of Procedure

Re-install and patch Oracle on Primary DB


If the server hosts the primary DB, log onto the
server hosting the primary System Manager as an AA
role (ntappadm) and install and patch Oracle, to its
latest release level, for the primary database only
login as the AA role (ntappadm) to the Primary
Element Management server (EMS)
Ensure the Oracle installer and patch are
available on the primary EMS in /var/mcp/media
If the files are not present, refer to section 7
of "102.1.2 AS 5300 2.0 Initial System
Installation" on how to extract Oracle from the
13.0 media

cd /var/mcp/install
./oracleInstall.pl -primary
./oraclePatch.pl -primary

Refer to Step 1 of section 10.2 Primary DB, Primary


SM Restore of document 103.2.3 AS 5300 2.0 System
Backup & Restore.
For more details on Oracle Application installation
process, refer sections 8.1 install and 8.2 Patch
Current of "102.1.2 AS 5300 Initial System
Installation",
9

9a

60 mins

Resync the two Databases (Resync from


Secondary to Primary)
CallP Time: 5 mins
Deploy the 13.0 scripts/files to the servers hosting
the Primary Database (Deploy files only option)
Login as AA role (ntappadm) to the Primary Element
Management Server
cd /var/mcp/install/
./dbInstall.pl fo
Answer Y to the following prompts after verifying
the settings:
Continue with these settings? (Y/N)[N]:
Perform "Deploy Files Only" operation to
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

98

Secondary DB also (Y/N)?[Y]:


9b

Update the db.type in the installprops.txt on the


Secondary Element Management Server
Login as the AA Role (ntappadm) to the Secondary
Element Management Server
cd /var/mcp/install
mv installprops.txt.sav installprops.txt

9c

60 mins

On the Secondary DB, resync the DBs


(Ensure that this step is performed on the Secondary
DB - NOT on the Primary DB.)
Using the Secondary Database (which has already been
downgraded to the MCP_13.0 load/schema), utilize the
resync script to copy the data in the Secondary DB
to the Primary DB, and then setup/start Database
replication.
login as DBA role (ntdbadm) to the server hosting
the Secondary Database
TMOUT=0
cd /var/mcp/run/MCP_13.0/<dbName>_1/bin/util
./resync.pl
Answer Y to the prompts

10

10a

15 mins

Redeploy (the 13.0 load) and start all of


the Components on the Primary Servers.
For each NE on the Primary Servers:
Deploy and start the NE instance in the NE
Maintenance window. Note that the NEs can be deployed
/started in parallel.
If an NE is in a Online state although its
Operation State is Unavailable. Stop or kill the NE
before deploying it.
The complete list of NEs that may be on the Primary
Servers is:
System Managers
Accounting Managers
Provisioning Managers
Personal Agent Managers
Session Managers
IP Client Managers (IPCM)
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

99

Document Version 2.6

Method of Procedure

Reference section 7.2 Deploy/start a Network Element


(NE) if additional details are needed for this
process.
If IPv6 was configured on the AS 2.0 5300 SESM, the
IPv6 configuration will be removed if an undeploy
command is performed. If an undeploy and deploy are
performed for an AS 5300 SESM that had an IPv6
configuration, the IPv6 configuration must be
manually re-applied to the AS 5300 SESM after the
deploy. A redeploy (without an undeploy) will not
remove the IPv6 configuration data. Refer to section
"4.8 Configuring AS 5300 SESM IPv6 Service Address"
of 101.2.6 AS 5300 IPv6 Configuration for details on
configuring an AS 5300 SESM IPv6 address. Once the AS
5300 SESM IPv6 address has been manually configured,
the AS 5300 SESM must be restarted to pick up the
IPv6 address.
11
11a

10 mins

Correct the Rogue NEs if needed


Correct Rogue status for any NEs
Due to the 15.0 Database restore, the System Manager
may have alarms raised stating an NE is Rogue
(which means an NE is connecting to the EM when the
EM expects it to be in an offline (or down) state).

To clear these alarms, for each NE that is shown as


Rogue perform the following steps
- Bring up the NE Maintenance panel for the NE
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

100

12

10 mins

kill the NE
redeploy the NE
start the NE

Restart
running
traffic
Primary

the redundant 2.0 components


on the Secondary Servers to force
back to the instance running on the
Servers

CallP Time: 1 min


After Resyncing the DBs, the standby components
running on the Primary Servers should be restarted.

12a

Using the 2.0 System Management console, restart the


redundant components that are standby on the
Primary Servers.
From the NE Maintenance panel for the Session
Manager, select the instance 0, and then select the
Restart ICON (Red & Green Arrows 5th ICON from the
left)
12b

Now, force traffic back to the instance(s) running on


the Primary Servers, by restarting the instance on
the Secondary Servers.
Using the 2.0 System Management console, restart the
redundant components that are active/running on the
Secondary Servers.
From the NE Maintenance panel for the System Manager,
select the instance 1, and then select the
Stop ICON (Red Light 4th ICON from the left)
If you receive the message User Forced Out when
attempting to login with the System Management
Console, then please reference Section 7.3 User
Forced Out msg or Unable to launch MCP Mgmt Console,
for the workaround.
Login to the Mgmt Console again.
From the NE Maintenance panel for the System Manager,
select the instance 1, and then select the
Start ICON (Green Light 3th ICON from the left)

13

varies

Downgrade associated Hardened clients that are used


in conjunction with the MCP components on the Primary
and Secondary Servers.

13a

5 mins

Install 2.0 OnlineHelp files


Please reference the following sections to install
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

101

Document Version 2.6

Method of Procedure
the 13.0 OnlineHelp for the Provisioning Managers and
Personal Agent Managers running on the Primary and
Secondary Servers.
8.1 Install the AS 5300 2.0 OnlineHelp files

13b

varies

Install ASU files


Please reference the following section to
7.2 ASU for the Provisioning Managers and
Agent Managers running on the Primary and
Servers.
9.1.2 Installing 7.2 Hardened Client
on the MCP Server

14
14a

10 mins

install the
Personal
Secondary
ASU files

Ensure the Database and Server monitors are started.


If not, execute step 15 of Table 4: Upgrade a MCP
(Redundant configuration) system to start the
Database and Server monitors.
Note: The Database monitor for DB instance 0 was
stopped before. It will definitely need to be
started.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

102

12 Appendix I: Applying a MCP Patch


This section provides the basic set of steps/commands for applying a Patch for the
Core NEs. If the user is NOT familiar with this process and additional details are
required regarding how to apply a MCP Patch, or the patch is for Online Help or
the
Audio
Codes
element,
then
please
refer
to
the
103.1.2_AS5300_Software_Update.pdf
Assume the patch has already been downloaded to the Primary Element
Management Server.
When applying the patch, the first step is to patch the data in the database and the
SM/EM instances. This is the only step in the patch application process that
involves interaction with the server file system. Subsequent steps will be
performed using the SM/EM Console.
In the process of patching a load, all Network Elements will be taken out of
service when the patch is being applied, except for the Session Managers which
have Hot Standby instances. The order in which Network Elements should be
patched is as follows (if the particular network element is not configured, the step
can be skipped):
1.
2.
3.
4.
5.

Database Data/Schema and Element Manager


Accounting Managers (AM)
Provisioning Managers.
Personal Agent Managers
Session Managers

12.1 Patch the Database Schemas and System Manager


The first step of the patch is to update the database schemas and System Manager
instances.

For 2.0 release:

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

103

Document Version 2.6

Method of Procedure

1. Login as the AA Role (ntappadm) to the server hosting the Primary


System/ Manager
Note: Do not login to the server using the SM Service Address because
the mcpPatch.pl script may stop prematurely when the active SM is
stopped (which removes/unconfigures the SM Service Address from that
server).
2. Execute the mcpPatch.pl script
cd /var/mcp/install
./mcpPatch.pl

This script will produce output detailing the progress of the patch process. At the
completion of the database schema and System Manager patch, the output should
indicate that the database and both System Manager instances have been patched
and the patched System Manager instances have been started. The system is ready
for the next step in the patch process.
Note: If the mcpPatch.pl script fails (i.e. the network goes down and
communications fail when upgrading the DB or the SM), once the problem is
corrected, the mcpPatch.pl script should be re-executed. This should be done at
least once prior to contacting the support teams as this will be successful in most
cases.
o Re-login to the MCP System Management Console.
Result:
The EM has been started and is in Active state running on the desired load. A
new MCP System Management Console has been started.

12.2 Patch Network Elements


Once the Database and System Manager are patched successfully, the other
network elements need to be patched from the Management Console as specified
in order below.
1. Accounting Managers (AM)
2. Provisioning Managers.
3. Personal Agent Managers
4. Session Managers

12.2.1 Service Issues


If a network element is supported in a fault tolerant mode such as a Session
Manager, one instance will be in ACTIVE state, and one will be in HOT
STANDBY state. When the active instance is shut down so that it can be patched,
the standby instance becomes active to prevent loss of service.
In case of non-fault tolerant network elements such as Provisioning Manager, the
service provided by the network element will be impacted during the patch.
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

104

12.2.2 Perform the Patch


1. Patches should be performed from the Load Manager application. The Load
Manager application can be accessed from the Administration menu item in
the Management Console.
Figure 27: Access to the Load Manager application

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

105

Document Version 2.6

Method of Procedure

2. The Load Manager application shows what NEs need to be patched based upon
the patch selected. Select the patch load that the system is being patched to in the
in the Load or Patch dropdown box.
Figure 28: Selecting the patch load in the Load Manager

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

106

3. Once the patch load is selected, expand the Network Element branch in the Load
Manager tree and select the Network Element to be patched. In the Figure below,
applying a patch to Session Manager is shown as an example.
Figure 29: Patch Session Managers

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

107

Document Version 2.6

Method of Procedure

4. Once the Network Element is selected, the patch button on the bottom of the Load
Manager application can be used to patch the Network Element instances. Once
the patch process has begun, the NE Maintenance Panel will be launched to
monitor the patch of the Network Element. As an example, the application of
patch to the Session Manager is shown in the Figure below.
Figure 30: Session Manager Patch

5. If the Network Element is fault tolerant, both instances of the Network Element
will be patched. The details of the patch can be monitored by clicking the
Details button on the NE Maintenance panel.
Note: These steps must be repeated for each Network Element if multiple Network
Elements are present in the tree in the Load Manager application in the MCP System
Management Console.
Result:
The Instance window for the Network Element shows one or more instances. If
there is one instance, it is in the ACTIVE state. Additional instances, if present,
are in the HOT STANDBY state in case of Network Element that is supported
2012 Avaya Inc.
Avaya proprietary use pursuant to company instructions

108

in hot standby mode such as Session Manager. The load name listed for each
instance is the patched load.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

109

Document Version 2.6

Method of Procedure

13 Appendix J: 13.0 Patch current


determination
1. Perform the following steps to determine the current patch levels for the MCP
system.

Login to the EM console, the title bar of the console shows the AS 5300
2.0.x.y load deployed in the system.
Where:
The letter y represents the current patch level

Please reference section 5 System Inventory of the


103.1.2_AS5300_Software_Update.pdf to determine the current version
of all components.

2. Get the latest 13.0 patch release notes.


Obtain the latest Updates from AVAYA.
3. Compare patch versions of the current deployed versions (found in step 1)
against the release notes, and apply the latest Patch if needed.
4. If the current MCP systems versions do not match with what are stated in the
latest Patch Release Notes, the system is not patch current. Then follow the
steps in section 6 Download Update Files of the
103.1.2_AS5300_Software_Update.pdf to download the latest General
Available Patch loads (MCP Core Load, Operating System Patch level, Client
versions, MAS Firmware versions, etc). Then apply the latest application patch
by following the instructions in Appendix I: Applying a MCP Patch.
For instructions to apply the latest patch, follow the steps in the
103.1.2_AS5300_Software_Update.pdf MOP.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

110

14 Appendix L: Retrieving the MCP


License Key
Customers can retrieve MCP license keys online via the Keycode Retrieval
System (KRS).

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

111

Document Version 2.6

Method of Procedure

102.2.3 AS 5300 3.0 - 2.0 to 3.0 SIP CORE Upgrade


Method of Procedure

Copyright 2011 Avaya


All rights reserved.
Avaya CONFIDENTIAL: The information contained in this document is the property of Avaya. Except as
specifically authorized in writing by Avaya, the holder of this document shall keep the information contained
herein confidential and shall protect same in whole or in part from disclosure and dissemination to third parties
and use same for evaluation, operation, and maintenance purposes only.

2012 Avaya Inc.


Avaya proprietary use pursuant to company instructions

112

Вам также может понравиться