Avaya Aura System Manager 5.2 Beta Release Notes

Transcription

1 Avaya Aura System Manager 5.2 Beta Release Notes 1

2 Contents Contents...2 Introduction...3 Troubleshooting...3 Known issues...3 Avaya Aura TM System Manager Cold Standby Procedure...8 Introduction...8 Prerequisites...8 Cold Standby Procedure...8 Avaya Aura TM System Manager IP/ FQDN change procedure...9 Introduction...9 Prerequisites...9 Steps to execute the IP/ FQDN change...9 Changes to be done on Managed Elements...11 Contacting support...12 Contact support checklist...12 Contact support tasks...12 Appendix A...12 Scheduling a Data backup...12 Appendix B...13 Restoring a Backup

3 Introduction This document provides late-breaking information to supplement Avaya Aura System Manager Software and documentation for the beta product. The Appendix section describes about setting up the cold standby server and IP/FQDN change script for System Manager. For updated documentation, product support notices, and service pack information, go to the Avaya Support Center Web site: The System Manager delivers a set of shared management services. The shared services can be accessed from the System Manager common console from which all management (both shared and element based) is exposed. The common shared services help in the reduction of total cost of ownership through the following key capabilities:! Remove duplicate data entry via shared management services! Simplify access through a browser-based Avaya Management Console with single sign on! Optimize IT skill sets with consistency of management functions across Avaya solutions Avaya Aura System Manager will be delivered as Avaya s System Platform template. Template contains RHEL 5.3 OS and Avaya Aura System Manager pre-installed consisting:! JDK _11! Open Source JBOSS 4.2.3! Postgres 8.3.7! Secure Access Link Agent! Secure Access Link Enterprise Troubleshooting Refer to the troubleshooting documentation available at under Resource Library, Find Documentation and Technical Information by Product Name, System Manager. Known issues Problem Incorrect behavior seen while traversing from breadcrumb links with Change Password page where if you select Change Password shortcut and click on User Edit breadcrumb link, an empty user editor opens and cancel button will have no effect. Internal Service Error getting generated when scheduling a job with start time falling in DST skip window. On demand Backup timestamp is 6 hours off Viewing a job in the System Manager scheduler does not show its execution time in the local time zone. Network Routing Policy import fails with if you use exported file. Scheduling of Communication Manager sync job with recurrence pattern every 3 month fails Workaround/ Resolution Workaround: Perform User management Edit User functionality by selected user and click on Edit on the user list page Workaround: Extract the exported zip file containing the xml files, do the required changes and then use these files as a source for importing. No Workaround. This issue will be addressed in SMGR 5.2 Service Pack 3

4 Permanently deleted users are visible as a resource in edited role Export all log records takes more time. Import of Access Control List shows successful even if its failed in case of duplicate user information in Presentity and watcher Logging UI Color Code can not set for Logs If user Interrupts the running scheduler job, user should be notified about the same and job status needs to be changed to Interrupted Also if database goes down in between of job execution, job is getting stuck in the Database as running state. "Some internal error occurred" error message is displayed when filtered alarm has only one record and its severity is changed. Import Application fails to add more than 500 records containing Application data. Last login information does not get displayed with navigating from Service Profile Management sub-links. Version number and Product name need to be updated for consistency in the help pages. User with Avaya Services Maintenance and Support role privileges cannot change the Alarm Status Unencrypted password in log files and SMGR configuration files for System Manager element manager User is able to perform operation for which he is not having permissions with Group Management View group page is not showing correct information after performing duplicate/move group operation on parent group Cannot give permissions on both ALL users and ALL attributes with Role Creation, Permission on all attributes gets lost. Content section extensions may appear closed (not visible) even though its checkbox is checked with User Management GUI Extension In Communication System Manager/ Telephony user Management, while creating a station profile if you give invalid characters in the Security Code field, UI will get hanged. End user can't view his own role System Manager is not accessible due to out of memory errors in JBOSS server Usability and Naming issue with Service Profile Management The Element Cut Through launched with Communication System management/ Telephony uses login password No Workaround. This issue will be addressed in SMGR 5.2 Service Pack No Workaround. This issue will be addressed in SMGR 5.2 Service Pack No workaround No workaround No workaround No workaround Import with batches containing 250 records. No Workaround SMGR next releases. Restart the JBOSS server It will be handled with next Major release. 4

5 configured in Run Time Service. This will be updated to show a login page based on the role given to a specific user. For incremental syncs logging level should be set appropriately. Change Log Data Values to be set to both using change logging-levels command on Communication Manager. Edit template reset does not work properly on change of set type. Internet Explorer 7 has some caching issue for available extension list. If we delete browser cache files, it shows all correct values in available extension list. In Communication System Manager, the new field "Expire Password" added to the Add/Edit subscriber form currently behaves as below - 1. If we choose "yes" for "Expire Password", then the date for the field "umlastlogon" as " Z" -> This date is specified in the documentation. 2. Any existing subscriber having the date for the field "umlastlogon"as " Z" will have his "Expire Password" set to "yes". However, when we add/edit subscriber from MM and set the "Expire Password" field to "yes", it is again reset back to "no". User Management doesn t support distributed transactions. For example: If you try to add messaging and station profiles within single transaction and if one of activity fails, the other gets added on the device. Also shown in station or Messaging list as associated with the User. But this user will not be created as it failed due to wrong data entered while creating user. In some cases Available extension list for stations is not showing proper extensions & not getting updated. There are improper message in Scheduler logs for Bulk Add station failure When editing existing entries for the adaptations (DigitConversionAdapter, VerizonAdapter, CiscoAdapter, etc.), duplicate entries of all module parameters will be generated upon submitting the form. This will result in the module parameters being ignored during call processing and they will not be applied. In addition sometimes one can not remove the module parameters from an adaptation module. Workaround: Delete the browser cache No Workaround No Workaround Workaround: - do the following: 1) All adaptation modules please delete and then re-add the adaptation if you are trying to remove all module parameters 2) DigitConversionAdapter - editing current parameters is fine, you will not see duplicates upon submitting the form 3) AttAdapter, VerizonAdapter, CiscoAdapter, 5

6 NortelAdapter - you can edit the form, but you must completely re-enter the module parameters before submitting the form - this is for any type of edit operation. You do not need to re-enter the adaptation module even though it is blank. The other option is to explicitly use the parameter odstd when specifying the domain as a module parameter (this is what it defaults to if you do not specify a parameter keyword). So for example use AttAdapter odstd= instead of just AttAdapter SIP firewall rules are not preserved on a backup/restore operation - When you create a backup and you have firewall rules defined for your session managers, this data will not be preserved upon a single backup operation. Management of contact lists by the Administrator: 1. When adding a contact to a users list of private contacts, each entry must include a type sip handle. This entry can be a real or a dummy sip handle of the form sip: @xyz.com. A second entry for the same contact of type phone should also be added for the normal phone number. Note that the sip handle must be unique. 2. When adding an entry to user A s default contact list, it is possible to select another user in the enterprise, e.g. user B. If user B is administered on a different SM than user A, this operation will fail (with no notification of the failure to the user). In this case the recommended workaround is to add user B as a private contact for user A. 3. Assigning a contact to a user s speedial list is not supported. NOTE: It appears that you do not see duplicate entries upon submission if you limit the module parameters to use the following keywords: iosrcd, iodstd, osrcd, odstd; however if you use any free form text such as the domain name, for example, this will cause the duplicate issue noted. Workaround: - please do the following: 1) if you have not yet performed the backup/restore operation execute the backup operation twice and use the second copy for the restore 2) if you have already restored a backup that did not retain the sip fw configuration do the following -> copy both /var/avaya/sipfw/default/current.xml and /var/avaya/sipfw/default/current.sum from a good system to the freshly restored system. (use mkdir -p /var/avaya/sipfw/default if the directory is missing). Contact Support for a default copy of these files. No workaround available Administrator setting of Session Manager Administration -> PPM Connection Timeout Leave the timeout value set at 5 minutes. 6

7 This field is non-functional. The system default timeout is 5 minutes and un-changeable. Can t change the IP address of a system manager box Refer Avaya Aura TM System Manager IP/ FQDN change procedure in this document 7

8 Avaya Aura TM System Manager Cold Standby Procedure Introduction A cold standby System Manager server acts as a failover when the main server running System Manager fails. This document covers the Cold Standby failover process for System Manager Application deployed on a System Platform. The document explains the process with an example of having 2 nodes, one being active and the other being the cold standby node. The document refers to node A as the primary machine that s active. Node B is the cold standby server. The cold standby procedure is to be executed in the scenario of Node A going down and the application is to be failed over to Node B. Prerequisites 1. Node A (Active Node) and Node B (Cold Standby Server) must have same IP address and Hostname. It s assumed that when the Active Node is running, the Cold Standby Server will be powered off. 2. The System Manager 5.2 template has been deployed on Node A and Node B using the install procedure mentioned in the Avaya Aura TM System Manager Installation Guide. 3. System date should be identical on both of the Nodes. 4. Using the Remote backup facility of System Manager Element Manager one should be taking regular backup of System Manager DB of Node A. This needs to be done regularly so that a latest snapshot of the System Manager DB is available incase a cold standby procedure is to be executed. Retain the backup of the DB on a remote node or an external storage device (e.g. Tape drive, DVD, etc.) so as to use that backup to restore it on Node B when Node A goes down. Appendix A in this document mentions the steps for scheduling a backup on the System Manager Node. Cold Standby Procedure 1. Confirm that Node A is shutdown. 2. Power up Node B. 3. Restore the last DB backup that was taken from Node A on Node B using the backup & restore utility of System Manager Element Manager provided with SMGR. Appendix B in this document mentions the steps for performing a restore of the backup on the System Manager Node. 4. After restoration, System Manager on Node B will be available for operations. 8

9 Avaya Aura TM System Manager IP/ FQDN change procedure Introduction This document covers the procedure for updating the IP/ FQDN of the System Manager virtual appliance present on the System Platform in the Avaya Aura TM System Manager 5.2 solution. The document also covers procedure to reflect the IP/ FQDN change on the managed elements nodes (eg. Session Manager Node) in the Avaya Aura TM solution Prerequisites The following pre-requisite should be carried out before executing the IP/ FQDN change procedure on the System Manager virtual appliance: 1. Updates made to the profiles, after the System Manager installation, by navigating to the Settings > Service Profile Management link on the Avaya Aura TM System Manager administration console need to be noted down. This is to be done as the IP/FQDN change restores the default profiles once the procedure is executed. The profiles that are noted down need to be re-entered once the IP/FQDN procedure is completed. Steps to execute the IP/ FQDN change The IP/ FQDN change for the System Manager Appliance can be achieved by executing a script viz. Ip-fqdn-r5.2.sh that s made available as part of the System Manager 5.2 release. The Ip-fqdn-r5.2.sh script performs the following steps: " Stops JBOSS, SAL agent and postgres services " Changes the network information of System Manager box. " Make IP and FQDN changes in the required files and DB " Starts JBOSS, SAL agent and postgres services " Uninstall the Service Profile Management profiles " Re-install the Service Profile Management profiles reflecting the new IP/ FQDN. This is what needs to be done for using the script: 1. Copy the Ip-fqdn-r5.2.sh script from the Avaya support site on to the System Manager virtual appliance. The script can be copied any where on the box. 2. Run the command: dos2unix Ip-fqdn-r5.2.sh 3. Assign execute permission to the script by executing the command: chmod +x Ip-fqdn-r5.2.sh 4. The script usage is as shown below: # sh Ip-fqdn-r5.2.sh -OLDIP <> -NEWIP <> -OLDFQDN <> -NEWFQDN <> -INSTALLPATH <> -ENCRYPTKEY <> - DBPASSWORD <> -GATEWAY <> -NETMASK <> -OLDDNS <> -NEWDNS <> 9

10 The script can be utilized for updating the IP or FQDN or both on the System Manager virtual appliance. The significance of the different options is as follows: OLDIP & NEWIP For changing the IP address, both of these options are mandatory OLDFQDN & NEWFQDN For changing the FQDN, both of these options are mandatory INSTALLPATH This is an optional field. Default value used is /opt/avaya. ENCRYPTKEY A default value is used if this argument is not passed. DBPASSWORD A default value is used if this argument is not passed. GATEWAY This is an optional field. This option to be used if one has to update the gateway configuration on the System Manager virtual appliance. NETMASK This is an optional field. This option to be used if one has to update the netmask on the System Manager virtual appliance. OLDDNS & NEWDNS For updating the DNS configuration on the System Manager virtual appliance, both of these options are mandatory Example: #sh Ip-fqdn-r5.2.sh -OLDIP w.x -NEWIP y.z -OLDFQDN a.platform.avaya.com -NEWFQDN b.platform.avaya.com -INSTALLPATH /opt/avaya -ENCRYPTKEY avaya -DBPASSWORD asd123 -GATEWAY NETMASK OLDDNS NEWDNS NOTE: # The script must be run by the root user since the script is capable of changing the IP/FQDN/GATEWAY/NETMASK/DNS of the system. # As the script also re-starts the network service it is re-commended that the script be run from the console of the System Manager virtual appliance. To gain access to the System Manager virtual appliance console, log on to the dom-0 of the System Platform and then login to the System Manager virtual appliance using the command "xm console <name> # The script updates one particular DNS entry in resolv.conf. If there are other DNS entries in resolv.conf that need to be updated, those updates would need to be done manually. # During the script execution you might see the following errors which can be safely ignored: " log4j:warn No such property [conversionpattern] in com.avaya.common.logging.client.commonlogginglayout during un-installation / installation of SPM profiles. " cp: cannot stat `Binary': No such file or directory and sed: can't read Binary: No such file or directory during IP / FQDN change in files. 10

11 # Once script execution is completed, please verify the log. The script displays the log name and the location on the console at the end of the execution. At the end of the script execution you would see a message: Backup of modified files, old logs and Db change logs can be found at <location of logs>. If the log reports a failure with the, restart JBOSS and execute the following command from the location $MGMT_HOME/trs./trust_initializer_install.sh -RMIPORT HTTPSPORT 443 -TMCONFIGLOC $JBOSS_HOME/server/avmgmt/conf/tm/ # You would find the backup of all the modified files at the mentioned location. The backup and log directory is created under the $AVAYA_LOG directory. # A unique directory, whose name starts with IPChangedFilesBackup_ is created under the $AVAYA_LOG folder every time you run the script. # If the services do not stop after the stipulated wait time, the services are killed. As a result errors could be reported on the console. Those can be ignored. Once the script execution is complete, the system is available for use. Changes to be done on Managed Elements a. Updates to be done on User Service client i. The jndi properties need to be updated with the new hostname/ip so that it can connect to the System Manager box ii. Update the truststore/keystore certificates present in the UPM client classpath with the new certificates from the System Manager box and ensure the new certificates are being picked by the client. b. Changes in Sal Agent on remote box i. Update the following values in $SPIRIT_HOME/config/agent/SPIRITAgent_1_0_DataTransportConfig_orig.xml file, if the hostname of the System Manager virtual appliance has been updated :- Connection.AvayaBase.PlatformQualifier, "Connection.AvayaBase.URL.0". ii. Update the following values in $SPIRIT_HOME/config/agent/SPIRITAgent_1_0_SpiritComponentConfig_orig.xml, if the hostname of the System Manager virtual appliance has been updated :- "Address.AgentHeartbeat", "Address.Inventory", "Address.ConfirmConfiguration", "Address.SNMP" and "Address.ProcessLog". iii. Update the following value in $SPIRIT_HOME/config/agent/ SPIRITAgent_1_0_BaseAgentConfig_orig.xml, if the hostname of the System Manager virtual appliance has been updated :- "SPIRIT.LoggingServiceURL" iv. Run the EnableHostAgentSecurity_postinstall.bsh script and re-start the SAL Agent Note: If the Manager Element is a Session Manager please refer to the Maintaining and Troubleshooting Avaya Aura Session Manager document for the instructions on how to do this. 11

12 Contacting support Contact support checklist If you are having trouble with System Manager, you should: 1. Retry the action. Carefully follow the instructions in written or online documentation. 2. Check the documentation that came with your hardware for maintenance or hardware-related problems. 3. Note the sequence of events that led to the problem and the exact messages displayed. Have the Avaya documentation available. If you continue to have a problem, contact Avaya Technical Support by: 1. Logging in to the Avaya Technical Support Web site 2. Calling or faxing Avaya Technical Support at one of the telephone numbers in the Support Directory listings on the Avaya support Web site. If you have difficulty reaching Avaya Technical Support through the above URL or address, please go to for further information. Avaya Global Services Escalation Management provides the means to escalate urgent service issues. For more information, see the Escalation Contacts listings on the Avaya Web site. Have the following information available when contacting Avaya Technical Support: Problem description. Detailed steps to reproduce the problem if any. The release version in which the issue is occurring Whether the System Manager software is an upgrade, and if yes then from which previous release. Installation log files. System Manager JBOSS server log file available at $JBOSS_HOME/server/avmgmt/log/server.log. The domain log available under $AVAYA_LOG. Contact support tasks You may be asked to one or more files to Technical Support for analysis of your application and its environment. Appendix A Scheduling a Data backup 1. Log in to the Avaya Aura System Manager web interface as an administrator. 2. Click Settings > Backup and Restore. 3. Click Backup. 4. On the Backup page, perform one of the following steps: o To schedule a local backup, perform the following steps: a. Click Local option. b. In the File name field, enter the name of the backup file field that you want to create. 12

13 o To schedule a remote backup, perform the following steps: a. Click Remote option. b. Specify the SCP server IP, SCP server port, user name, password, and file name in the respective fields 5. Click Schedule. 6. On the Schedule Backup page, specify the following: Job Name, Task Time, Recurrence and Range in the respective fields. 7. Click Commit. Appendix B Restoring a Backup 1. Log in to the Avaya Aura System Manager web interface as an administrator. 2. Click Settings > Backup and Restore. 3. Click Restore. 4. On the Restore page, perform one of the following steps: o o To restore data from a local backup a. Click Local option. b. Enter the back up file name in the File name field. To restore data from a remote backup a. Click Remote option. b. Specify the SCP server IP, SCP server port, user name, password, and file name in the respective fields. c. Click Restore. 13