RMS Upgrade Procedure

Transcription

1 To upgrade from RMS4.1 FCS to RMS5.1 FCS, follow Upgrade from RMS 4.1 to RMS 5.1 FCS, on page 1. This procedure involves executing the upgrade_rms.sh script on the Central, Serving, and Upload nodes (post-rhel upgrade) to upgrade to RMS 5.1 features. To upgrade from RMS 5.1 EFT to RMS 5.1 FCS, follow Upgrade from RMS 5.1 EFT to RMS 5.1 FCS, on page 12. The procedure involves executing the upgrade_rms.sh script to upgrade to RMS 5.1 features. Upgrade from RMS 4.1 to RMS 5.1 FCS, page 1 Upgrade from RMS 5.1 EFT to RMS 5.1 FCS, page 12 Additional Information, page 21 Merging of Files Manually, page 21 Recording the BAC Configuration Template File Details, page 24 Associating Manually Edited BAC Configuration Template, page 24 Rollback to Version RMS 4.1, page 25 Rollback to Version, RMS 5.1 EFT, page 25 Removing Obsolete Data, page 25 Basic Sanity Check Post RMS Upgrade, page 26 Upgrade from RMS 4.1 to RMS 5.1 FCS Pre-Upgrade Tasks Note The following tasks should be carried out during the pre-upgrade maintenance window. Ensure that the manually added routes are made permanent on all the nodes. Else, follow Enabling Communication for VMs on Different Subnets. July 6,

2 Upgrade Prerequisites Ensure that a backup of ovfenv.xml is taken from /opt/vmware/etc/vami/ directory on all the nodes. Ensure that the CAR license on all the Serving nodes is valid. Verify if both the /rms/app/cscoar/license/cscoar.lic and /home/cscoar.lic files of the Serving node have the same valid license. In case of discrepancy, see Deployment Troubleshooting to update the valid license. Clone the system, see Back Up System Using vapp Cloning. Ensure that the existing hardware supports RMS 5.1. Before proceeding with the upgrade, Cisco RMS Hardware and Software Requirements. Ensure that the Central node VM CPU and memory is as suggested in the Optimum CPU and Memory Configurations. For more information, see Upgrading the VM CPU and Memory Settings. Ensure that the total disk space utilization is not exceeding 50 GB. Else, follow Removing Obsolete Data, on page 25 Ensure that the data storage or disk size for each Cisco RMS VMs is as recommended in Data Storage for Cisco RMS VMs. Else, follow the Upgrading the Data Storage on Root Partition for Cisco RMS VMs to increase the data storage or disk size. Perform sanity check after increasing the data storage size on root partition, see Basic Sanity Check Post RMS Upgrade, on page 26. Delete the clone taken as part of above step and take a fresh clone of the system with the increased data storage, see Back Up System Using vapp Cloning. Note This clone is used for rollback purpose; any updates made after the clone is taken is lost. Download the RHEL6.6-tar.gz file to your local Windows machine and untar the file. Verify that RHEL 6.6 upgrade MOP and the rhel-server-6.6-x86_64-dvd.iso file is present when untarred. Follow "Staging RHEL 6.6 ISO" section in the RHEL 6.6 upgrade MOP. RMS upgrade package is already copied on all the three nodes and are present in the admin directory. Free space of 20 GB is available on each RMS node (Central, Serving, and Upload). (Optional) Collect small cell statistics through GDDT before upgrade. Upgrade Prerequisites Stop the RMS Northbound and Southbound traffic. Cron jobs should not be running while upgrading the system. Upgrading Red Hat Enterprise Linux From v6.1 to v6.6 Upgrade from Red Hat Enterprise Linux (RHEL) Edition v6.1 to v July 6, 2015

3 RMS Upgrade Prerequisites for RMS 4.1 to RMS 5.1 FCS Upgrade Procedure Follow the RHEL 6.6 upgrade MOP to upgrade RHEL on all the three nodes. Cloning the RMS VMs during the RHEL upgrade is optional as the clone is already taken in the pre-upgrade maintenance window, which is used for rollback purpose. What to Do Next After RHEL upgrade on all three nodes, proceed with the RMS upgrade on each of the nodes. RMS Upgrade Prerequisites for RMS 4.1 to RMS 5.1 FCS Upgrade 1 Ensure that the RHEL is upgraded from v6.1 to v6.6. Verify the output of the below command on all the nodes as a root user: cat /etc/redhat-release Sample output: # cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.6 (Santiago) 2 Ensure that you maintain a manual backup of any additional files created by you during deployment specifically in the /tmp/rms directory as the upgrade removes the already existing directory /tmp/rms. Upgrade script does not back up any additional files. 3 Verify that there are no older upgrade files present in the /tmp directory on all nodes; if present, older upgrade files have to be manually backed up (if necessary) and removed from the /tmp directory. 4 Verify that the "password" property value in the /rms/app/bacctools/conf/apiscripter.arguments file of the Central node contains the same password as the BACadmin user password of RMS 4.1 (defaultuser used to log in to the BAC UI). If these are not in sync, change the password in the file to match the BACadmin user password. 5 If applicable, take a backup (that is, save to the local machine) of the configuration templates that have been manually changed/associated with CoS of the device. 6 Record the manually customized configuration template as described in Recording the BAC Configuration Template File Details, on page Manually back up the RF profile group instances using the Export option in the DCC UI, see "Exporting Information about a Group or ID Pool Instance" section in the Cisco RAN Management System Administration Guide for steps to export and revert RF profiles post upgrade to RMS 5.1. This would be required because the property values may be reset as per the v3.1 policy. 8 If applicable (when the default DN prefix is changed) take a backup and note the DN Prefix format configured in DCC UI > Configurations > DN Prefix tab to apply the same configurations post-upgrade. 9 Manually append the Central server "hostname" and "eth0 IP" to the existing /etc/hosts file of the Serving and Upload nodes. <Central node eth0 IP> <Central node host name> Example: blr-rms19-central 10 As a root user take a backup of CSCOrms-ops-tools-ga file present in the /etc/cron.d directory 11 Ensure that the Central, Serving, and Upload nodes are up before performing the upgrade. July 6,

4 Upgrading Central Node from RMS 4.1 to RMS 5.1 FCS 12 Ensure that the user has root privileges to the RMS nodes. 13 Ensure that the PAR on the Serving node is upgraded to version. Execute the rpm -qa grep command on all the Serving nodes to confirm the version. 14 Verify whether postgresql port number has been changed from 5432 to 5435 using the following command: netstat -an grep 5435 The postgresql port should be listening to port 5435 before upgrade. If it is not listening, revert the postgres port setting as follows: Log in to the Central node. Change to root user using this command: su Run the following command: sed -i 's/pgport=5432/pgport=5435/' /etc/rc.d/init.d/postgresql Output: /home/admin1 # Reboot the VM. Upgrading Central Node from RMS 4.1 to RMS 5.1 FCS Procedure Step 1 Step 2 Copy the RMS-UPGRADE x.tar.gz file to the /rms directory of the Central node. Note The "x" in the upgrade image represents the target upgrade load number. Execute the following commands as root user to perform the upgrade: a) cd / b) rm -rf /rms/upgrade c) tar -zxvf /rms/rms-upgrade x.tar.gz -C /rms d) /rms/upgrade/upgrade_rms.sh In the output, when you are prompted to proceed with the upgrade, enter a response and wait for the upgrade to complete with a completed message on the console. Sample Output: [BLR17-Central-41N] / # /rms/upgrade/upgrade_rms.sh Detecting the RMS Node.. Central-Node Detected RMS4.1 setup Upgrading the current RMS installation to FCS. Do you want to proceed? (y/n) : y Stopping applications on Central Node Stopping bpragent.. BAC stopped successfully Stopping PMG and AlarmHandler.. Taking RMS Central Node file backup as per the configuration in the file:/rms/upgrade/backupfilelist/centralbackupfilelist Filebackup tar is present at path : /rmsbackupfiles/rdubackup/rms-central.tar 4 July 6, 2015

5 Upgrading Central Node from RMS 4.1 to RMS 5.1 FCS Starting RPM Upgrade..... Upgrading DCC-UI... DCC-UI upgraded to /rms/upgrade/rpms/cscorms-dcc-ui-ga noarch.rpm Upgrading FM SERVER... FM SERVER upgraded to /rms/upgrade/rpms/cscorms-fm_server-ga noarch.rpm Updating audit sensitive config file Disabling ETH0 gateway in central node ifcfg-eth0 Changing Postgres port from 5435 to 5439 and AlarmHandler port from 4678 to 4698 Restoring the DCC-UI DB.. Executing /rmsbackupfiles/dccuidbbackup/dbbackup.sql in dcc Restarting applications on Central Node Restarting bpragent... BAC is running Restarting PMG and Alarmhandler.. Disabling the unnecessary TCP/IP Services Finished upgrading RMS Central Node. [BLR17-Central-41N] / # Step 3 Step 4 Step 5 Step 6 Repeat Steps 2a to 2d on the cold standby Central node in case of high availability setup. Clear the browser cache and cookies before accessing the DCC UI. Restore the value of property "sdm.logupload.ondemand.nbpassword" in the /rms/app/cscobac/rdu/tomcat/webapps/dcc_ui/sdm/plugin-config.properties file from the /rmsbackupfiles/plugin-config.properties file. Verify if the AlarmHandler process is running post upgrade, else restart the process using the following command: ps ef grep Ala god restart AlarmHandler Example: [CENTRAL] /home/smallcell # ps -ef grep Ala root :40 pts/4 00:00:00 grep Ala [CENTRAL] /home/smallcell # god restart AlarmHandler Sending 'restart' command The following watches were affected: AlarmHandler [CENTRAL] /home/smallcell # ps -ef grep Ala ciscorms :42? 00:00:03 /usr/java/default/bin/java -cp /rms/app/ops-tools/lib/*:/rms/app/cscobac/lib/adventnetsnmp.jar: /rms/app/cscobac/lib/bacbase.jar:/rms/app/cscobac/lib/baccwmpsoap.jar: /rms/app/cscobac/lib/bpr.jar -Djava.security.egd=file:///dev/urandom com.cisco.ca.rms.dcc.opstools.common.pub.alarmhandler.alarmhandler root :43 pts/4 00:00:00 grep Ala [CENTRAL] /home/smallcell # July 6,

6 Upgrading Serving Node from RMS 4.1 to RMS 5.1 FCS Upgrading Serving Node from RMS 4.1 to RMS 5.1 FCS Procedure Step 1 Step 2 Copy the RMS-UPGRADE x.tar.gz file to the /rms directory of the Serving node. Note The "x" in the upgrade image represents the target upgrade load number. Execute the following commands as root user to perform the upgrade: a) cd / b) rm -rf /rms/upgrade c) tar -zxvf /rms/rms-upgrade x.tar.gz -C /rms d) /rms/upgrade/upgrade_rms.sh Note In the output, when you are prompted to proceed with the upgrade, enter the response. Sample Output: Provide the PNR/PAR password (RMS_App_Password of RMS, Release 4.1) when prompted and wait for the upgrade to complete with a completed message on the console. [root@blr17-serving-41n /]# /rms/upgrade/upgrade_rms.sh Detecting the RMS Node.. Serving-Node Detected RMS4.1 setup Upgrading the current RMS installation to FCS. Do you want to proceed? (y/n) : y Stopping applications on Serving Node Stopping bpragent.. BAC stopped successfully Disabling the PNR extension points Enter cnradmin Password: Stopping PNR.. Stopping CAR.. Taking RMS Serving Node file backup as per the configuration in the file:/rms/upgrade/backupfilelist/servingbackupfilelist Copying the DHCP files.. Files are being moved to backup directory Copying the DHCP files done Filebackup tar is present at path : /rms-serving.tar Starting RPM Upgrade.. Upgrading the BAC on RMS Serving Node... Enabling the PNR extensions Starting bpragent.. Starting PNR.. Starting CAR.. 6 July 6, 2015

7 Upgrading Serving Node from RMS 4.1 to RMS 5.1 FCS Enter caradmin Password: Executing configarextension.sh.. Executing runcopycarfile.sh.. Restarting bpragent.. /usr/java /rms /rms Upgrading PNR-local... PNR upgraded to CNR i686 Rollforward recovery using "/rms/app/cscoar/data/db/vista.tjf" started Thu Jun 18 05:46: Rollforward recovery using "/rms/app/cscoar/data/db/vista.tjf" finished Thu Jun 18 05:46: Upgrading PAR... Upgrading jre to CAR upgraded to CPAR noarch Restoring the Serving certs : Disabling the unnecessary TCP/IP Services Finished upgrading RMS Serving Node. [root@blr17-serving-41n /]# Step 3 Step 4 Repeat steps 2a to 2d on the redundant Serving node in case of a redundant setup. If the Serving nodes have redundancy configured on the system, follow these steps: a) On the primary Serving node, run the following commands: Remove the existing firewall for the port 647 on udp protocol. iptables -D INPUT -s serving-node-2-eth0-address/netmask -d serving-node-1-eth0-address/netmask -i eth0 -p udp -m udp --dport 647 -m state --state NEW -j ACCEPT iptables -D OUTPUT -s serving-node-1-eth0-address/netmask -d serving-node-2-eth0-address/netmask -o eth0 -p udp -m udp --dport 647 -m state --state NEW -j ACCEPT Add the IPtable for the port 647 on tcp protocol. iptables -A INPUT -s serving-node-2-eth0-address/netmask -d serving-node-1-eth0-address/netmask -i eth0 -p tcp -m tcp --dport 647 -m state --state NEW -j ACCEPT iptables -A OUTPUT -s serving-node-1-eth0-address/netmask -d serving-node-2-eth0-address/netmask -o eth0 -p tcp -m tcp --dport 647 -m state --state NEW -j ACCEPT service iptables save service iptables restart July 6,

8 Upgrading Serving Node from RMS 4.1 to RMS 5.1 FCS Example: iptables -D INPUT -s /32 -d /32 -i eth0 -p udp -m udp --dport 647 -m state --state NEW -j ACCEPT iptables -D OUTPUT -s /32 -d /32 -o eth0 -p udp -m udp --dport 647 -m state --state NEW -j ACCEPT iptables -A INPUT -s /32 -d /32 -i eth0 -p tcp -m tcp --dport 647 -m state --state NEW -j ACCEPT iptables -A OUTPUT -s /32 -d /32 -o eth0 -p tcp -m tcp --dport 647 -m state --state NEW -j ACCEPT service iptables save service iptables restart b) On the secondary Serving node, run the following commands: Remove the existing firewall for the port "647" on udp protocol. iptables -D INPUT -s serving-node-1-eth0-address/netmask -d serving-node-2-eth0-address/netmask -i eth0 -p udp -m udp --dport 647 -m state --state NEW -j ACCEPT iptables -D OUTPUT -s serving-node-2-eth0-address/netmask -d serving-node-1-eth0-address/netmask -o eth0 -p udp -m udp --dport 647 -m state --state NEW -j ACCEPT Add the IPtable for the port 647 on tcp protocol. iptables -A INPUT -s serving-node-1-eth0-address/netmask -d serving-node-2-eth0-address/netmask -i eth0 -p tcp -m tcp --dport 647 -m state --state NEW -j ACCEPT iptables -A OUTPUT -s serving-node-2-eth0-address/netmask -d serving-node-1-eth0-address/netmask -o eth0 -p tcp -m tcp --dport 647 -m state --state NEW -j ACCEPT service iptables save service iptables restart Example: iptables -D INPUT -s /32 -d /32 -i eth0 -p udp -m udp --dport 647 -m state --state NEW -j ACCEPT iptables -D OUTPUT -s /32 -d /32 -o eth0 -p udp -m udp --dport 647 -m state --state NEW -j ACCEPT iptables -A INPUT -s /32 -d /32 -i eth0 -p tcp -m tcp --dport 647 -m state --state NEW -j ACCEPT iptables -A OUTPUT -s /32 -d /32 -o eth0 -p tcp -m tcp --dport 647 -m state --state NEW -j ACCEPT service iptables save service iptables restart c) Change the PNR product version on the cluster configuration of the primary Serving node by following these steps as a root user: 8 July 6, 2015

9 Upgrading Upload Node from RMS 4.1 to RMS 5.1 FCS /rms/app/nwreg2/local/usrbin/nrcmd -N cnradmin Note Enter the RMS_App_Password password as set in RMS, Release 4.1. cluster Backup-cluster set product-version=8.3 save dhcp reload Example: admin1]# /rms/app/nwreg2/local/usrbin/nrcmd -N cnradmin password: 100 Ok session: cluster = localhost current-view = Default current-vpn = global default-format = user dhcp-edit-mode = synchronous dns-edit-mode = synchronous groups = superuser roles = superuser user-name = cnradmin visibility = 5 nrcmd> cluster Backup-cluster set product-version= Ok nrcmd> save 100 Ok nrcmd> dhcp reload 100 Ok nrcmd> Upgrading Upload Node from RMS 4.1 to RMS 5.1 FCS Procedure Step 1 Step 2 Copy the RMS-UPGRADE x.tar.gz file to the /rms directory of the Upload node. Note The "x" in the upgrade image represents the target upgrade load number. Execute the following commands as root user to perform the upgrade: a) cd / b) rm -rf /rms/upgrade c) tar -zxvf /rms/rms-upgrade x.tar.gz -C /rms d) /rms/upgrade/upgrade_rms.sh July 6,

10 Post RMS 5.1 Upgrade Note In the output, when you are prompted to proceed with the upgrade, enter a response. Provide the valid keystore password (RMS_App_Password for RMS, Release 4.1)) when prompted and wait for the upgrade to complete with a completed message on the console. Step 3 Sample Output: [root@blr17-upload-41n /]# /rms/upgrade/upgrade_rms.sh Detecting the RMS Node.. Upload-Node Detected RMS4.1 setup Upgrading the current RMS installation to FCS. Do you want to proceed? (y/n) : y Stopping applications on Upload Node Stopping Upload Server.. Taking RMS Upload Node file backup as per the configuration in the file:/rms/upgrade/backupfilelist/uploadbackupfilelist tar: Removing leading `/' from member names Filebackup tar is present at path : /rms-upload.tar Starting RPM Upgrade.. UPLOAD SERVER upgraded to /rms/upgrade/rpms/cscorms-upload-server noarch.rpm Restoring the Upload certs : Restarting the audit service Enter Keystore Password: Restarting Upload Server Disabling the unnecessary TCP/IP Services Finished upgrading RMS Upload Node. [root@blr17-upload-41n /]# Repeat Steps 2a to 2d on the redundant Upload node in case of a redundant setup. Post RMS 5.1 Upgrade 1 Update the group/pool types associations from the DCC UI manually if there are any changes made to the default associations (example, Area group type modified to get associated with Alarms Profile group type or any new group type). 2 Merge the pmg-profile.xml in /rms/app/rms/conf, see Merging of Files Manually, on page Follow these steps to configure the RMS 5.1 version features: a b Log in to the Central node as a root user and follow this procedure to disable the Instruction Generation Service. i. Create a file /home/admin1/stopigs.kiwi using vi editor. ii. Add the following content in a single line to the file and save. Proprietary.changeSystemDefaultsInternally -vcs CommandStatusCodes.CMD_OK -m { { -s "/pace/crs/start" -s "false" } } -l "NULL" iii. Run the following command as root user to stop Instruction Generation Service and proceed to the next step to configure groups and pools. /rms/app/baseconfig/bin/runkiwi.sh /home/admin1/stopigs.kiwi Migrate the existing groups to the new group architecture. 10 July 6, 2015

11 Post RMS 5.1 Upgrade Note New group types have been added in RMS 5.1, that is, UMTSSecGateway, Region, LTESecGateway, and HeNBGateway. To migrate the groups, follow this procedure: i. Log in to DCC UI and go to Groups and IDs screen. Update the mandatory properties in following groups with appropriate values: GlobalRegion and GlobalUMTSSecGateway. ii. Enable the required location verification methods on the GlobalRegion group level to adhere to the new group architecture. iii. Log in to the Central Node as admin user and export all existing Areas by using the following opstool command: bulkimportexport.sh -ops export -type Area -outdir /home/admin1 This command exports all Areas to a file, for example, BulkImportExport /GroupsAndIds_export_Area_AllGroups _09_59_30.csv. Note Edit the csv file and remove the "DefaultArea" entry before proceeding to the next step. iv. Import all the areas exported above, associating the GlobalRegion and DefaultHeNBGW to each area by using the following command: bulkimportexport.sh -ops import -type Area csvfile /home/admin1/bulkimportexport /groupsandids_export_area_allgroups _09_59_30.csv -defaultlinkedgroups "{name:globalregion,type:region},{name:defaulthenbgw,type:henbgw} This command associates all the existing areas to GlobalRegion and DefaultHeNBGW. v. Export all existing FemtoGateways by using the following command: bulkimportexport.sh -ops export -type FemtoGateway -outdir /home/admin1 This command exports all FemtoGateways to a file, for example, BulkImportExport /GroupsAndIds_export_FemtoGateway_AllGroups _09_59_30.csv. Note Edit the csv file and remove the "DefaultFGW" entry before proceeding to the next step. vi. Import all the FemtoGateways exported in sub-step iv, associating the GlobalUMTSSecGateway to each FemtoGateway using the following command: bulkimportexport.sh -ops import -type FemtoGateway csvfile /home/admin1/bulkimportexport /groupsandids_export_femtogateway_allgroups _09_59_30.csv -defaultlinkedgroups "{name:globalumtssecgateway,type:umtssecgateway} This command associates all the existing FemtoGateways to GlobalUMTSSecGateway. c d e f The Configuration templates in BAC are automatically replaced with respective RMS 5.1 versions during upgrade. Manually customize the replaced configuration template as described in Associating Manually Edited BAC Configuration Template, on page 24. Manually update the RF profile property value (if required) as per the previously exported csv file (in RMS 4.1). The DN prefix format configured in DCC UI > Configurations > DN Prefix are automatically replaced with the respective RMS 5.1 versions. If required, manually reconfigure the format as in RMS, Release 4.1. Update the newly added mandatory properties in DCC-UI groups and pools using the DCC UI. For more information, see Configuring New Groups and Pools. July 6,

12 Post RMS 5.1 Upgrade Tasks Note The LTE-related mandatory properties are without values on the existing Area/Site that are created in RMS 4.1. Enter default values for mandatory properties via DCC UI; default values can be referenced from tooltip present for each property. g h Log in as root user and replace the backed up CSCOrms-ops-tools-ga file in /etc/cron.d directory post-upgrade, if required. Enable the Instruction Generation Service by following the below procedure: i. Create a /home/admin1/startigs.kiwi file using vi editor. ii. Add the following line to the file and save. Proprietary.changeSystemDefaultsInternally -vcs CommandStatusCodes.CMD_OK -m { { -s "/pace/crs/start" -s "true" } } -l "NULL" iii. Log in as root user and run the following command to start Instruction Generation Service. /rms/app/baseconfig/bin/runkiwi.sh /home/admin1/startigs.kiwi iv. Start the RMS Northbound traffic and Southbound traffic. v. Start the cron jobs. What to Do Next To know more about customizing the RMS system, post-upgrade, see Additional Information, on page 21. Post RMS 5.1 Upgrade Tasks Run the reassign Opstool on the Central node as ciscorms user to associate the existing EIDs with the new groups: Note The following reassignment should be performed for a set of 50,000 FAPs in each maintenance window. # reassigndevices.sh -idfile eidlist.txt -type devices -donotassignids Upgrade from RMS 5.1 EFT to RMS 5.1 FCS Assumptions Backup of the ovfenv.xml is taken from the /opt/vmware/etc/vami/ directory on all nodes. CAR license on all the Serving nodes is valid. Verify if both the /rms/app/cscoar/license/cscoar.lic and /home/cscoar.lic files of the Serving node have the same valid license. In case of discrepancy, see Deployment Troubleshooting to update the valid license. Total disk space utilization is not exceeding 50 GB. Else, follow Removing Obsolete Data, on page 25. Upgrade package is already copied on all the three nodes and are present in the admin directory. 12 July 6, 2015

13 RMS Upgrade Prerequisites for RMS 5.1 EFT to RMS 5.1 FCS Upgrade Free space of 20 GB is available on each RMS node (Central, Serving, and Upload). (Optional) Small cell statistics is collected through GDDT before upgrade. RMS Upgrade Prerequisites for RMS 5.1 EFT to RMS 5.1 FCS Upgrade Stop the RMS Northbound traffic and Southbound traffic. Cron jobs should not be running while upgrading the system. Ensure that you maintain a manual backup of any additional files created by you during deployment specifically in the /tmp/rms directory as the upgrade removes the already existing directory /tmp/rms. Upgrade script does not back up any additional files. Verify that there are no older upgrade files present in the /tmp directory on all nodes; if present, older upgrade files have to be manually backed up (if necessary) and removed from the /tmp directory. Verify that the "password" property value in the Central node, that is, if the /rms/app/bacctools/conf/apiscripter.arguments file contains the same password as the BACadmin user password of RMS 4.1 (used to log in to the BAC UI). If these are not in sync, change the password in the file to match the BACadmin user password. If applicable, take a backup (that is, save to the local machine) of the configuration templates that have been manually changed/associated with class of service (CoS) of the device. Record the manually customized configuration template as described in Recording the BAC Configuration Template File Details, on page 24. Manually back up the RF profile group instances using the Export option in the DCC UI, see "Exporting Information about a Group or ID Pool Instance" section in the Cisco RAN Management System Administration Guide for steps to export and revert RF profiles post upgrade to RMS 5.1. This would be required because the property values may be reset as per the v3.1 policy. If applicable (when the default DN prefix is changed) take a backup and note the DN Prefix format configured in DCC UI > Configurations > DN Prefix tab to apply the same configurations post-upgrade. Manually append the Central server "hostname" and "eth0 IP" to the existing /etc/hosts file of the Serving and Upload nodes. <Central node eth0 IP> <Central node host name> Example: blr-rms19-central As a root user take a backup of CSCOrms-ops-tools-ga file present in the /etc/cron.d directory Ensure that the Central, Serving, and Upload nodes are up before performing the upgrade. Ensure that the user has root privileges to the RMS nodes. July 6,

14 Upgrading Central Node from RMS 5.1 EFT to RMS 5.1 FCS Upgrading Central Node from RMS 5.1 EFT to RMS 5.1 FCS Procedure Step 1 Step 2 Copy the RMS-UPGRADE x.tar.gz file to the /rms directory of the Central node. Note The "x" in the upgrade image represents the target upgrade load number. Execute the following commands as root user to perform the upgrade: a) cd /; rm -rf /rms/upgrade ; b) tar -zxvf /rms/rms-upgrade x.tar.gz -C /rms; c) /rms/upgrade/upgrade_rms.sh Note In the output, when you are prompted to proceed with the upgrade, enter a response and wait for the upgrade to complete with a completed message on the console. Sample Output: [CENTRAL] / # /rms/upgrade/upgrade_rms.sh Detecting the RMS Node.. Central-Node Detected RMS E setup. Upgrading the current RMS installation to FCS. Do you want to proceed? (y/n) : y Stopping applications on Central Node Stopping bpragent.. BAC stopped successfully Stopping PMG and AlarmHandler.. Taking RMS Central Node file backup as per the configuration in the file:/rms/upgrade/backupfilelist/centralbackupfilelist Filebackup tar is present at path : /rmsbackupfiles/rdubackup/rms-central.tar Starting RPM Upgrade.. Upgrading the BAC on RMS Central Node... Restarting the bpragent.. Upgrading BACCTOOLS... BACCTOOLS upgraded to /rms/upgrade/rpms/cscorms-bacctools noarch.rpm Upgrading BASELINE CONFIG... BAC-CONFIG upgraded to /rms/upgrade/rpms/cscorms-baseline-config-ga noarch.rpm Upgrading PNR-Regional... Upgrading the PNR-Regional on Central node : PNR upgraded to CNR i686 Upgrading OPS-TOOLS... OPS-TOOLS upgraded to /rms/upgrade/rpms/cscorms-ops-tools-ga noarch.rpm Upgrading PMG... PMG upgraded to /rms/upgrade/rpms/cscorms-pmg-ga noarch.rpm Upgrading DCC-UI July 6, 2015

15 Upgrading Central Node from RMS 5.1 EFT to RMS 5.1 FCS DCC-UI upgraded to /rms/upgrade/rpms/cscorms-dcc-ui-ga noarch.rpm Upgrading FM SERVER... FM SERVER upgraded to /rms/upgrade/rpms/cscorms-fm_server-ga noarch.rpm Changing Postgres port from 5435 to 5439 and AlarmHandler port from 4678 to 4698 Restarting applications on Central Node Restarting bpragent... BAC is running Restarting PMG and Alarmhandler.. Disabling the unnecessary TCP/IP Services Finished upgrading RMS Central Node. [CENTRAL] / # Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9 Repeat Steps 2a to 2c on the cold standby Central Node in case of a High Availability setup. Clear the browser cache and cookies before accessing the DCC UI. Replace the backed up CSCOrms-ops-tools-ga file in /etc/cron.d directory as a root user, post-upgrade. Restore the value of property "sdm.logupload.ondemand.nbpassword" in the /rms/app/cscobac/rdu/tomcat/webapps/dcc_ui/sdm/plugin-config.properties file from the /rmsbackupfiles/plugin-config.properties file. The DN prefix format configured in DCC UI > Configurations > DN Prefix is automatically replaced with the respective RMS51 versions. If required, manually reconfigure the format as in RMS, Release 4.1. Verify the SNMP manager version in /rms/app/fm_server/conf/fmserver.properties file by using the following commands. cat /rms/app/fm_server/conf/fmserver.properties grep version If the version is not as configured in RMS, Release 4.1, edit the file vi editor, modify, and save the file. Perform the below steps to set unlimited password lifetime for system users. Log in to the Central node as a root user and execute the command. psql -U dcc_app -p 5439 dcc Provide the RMS_App_Password as an input when the system prompts for the password. Example: [CENTRAL] ~ # psql -U dcc_app -p 5439 dcc Password for user dcc_app: psql (8.4.20) Type "help" for help. dcc=# Run the following command to update the value. dcc=# UPDATE role_names SET password_lifetime=0, password_warning_period=0, password_grace_period=0 WHERE rolename='superuser' OR rolename='pmgadmin' OR rolename='pmgreadonly'; Example: [CENTRAL] ~ # psql -U dcc_app -p 5439 dcc Password for user dcc_app: psql (8.4.20) Type "help" for help. dcc=# UPDATE role_names SET password_lifetime=0, password_warning_period=0, password_grace_period=0 WHERE rolename='superuser' OR rolename='pmgadmin' OR rolename='pmgreadonly'; UPDATE 3 July 6,

16 Upgrading Serving Node from RMS 5.1 EFT to RMS 5.1 FCS Exit from SQL using /q. Example: dcc-# \q Verify if the AlarmHandler process is running post upgrade else restart the process using the following command: ps ef grep Ala god restart AlarmHandler Example: [CENTRAL] /home/smallcell # ps -ef grep Ala root :40 pts/4 00:00:00 grep Ala [CENTRAL] /home/smallcell # god restart AlarmHandler Sending 'restart' command The following watches were affected: AlarmHandler [CENTRAL] /home/smallcell # ps -ef grep Ala ciscorms :42? 00:00:03 /usr/java/default/bin/java -cp /rms/app/ops-tools/lib/*:/rms/app/cscobac/lib/adventnetsnmp.jar: /rms/app/cscobac/lib/bacbase.jar:/rms/app/cscobac/lib/baccwmpsoap.jar: /rms/app/cscobac/lib/bpr.jar -Djava.security.egd=file:///dev/urandom com.cisco.ca.rms. dcc.opstools.common.pub.alarmhandler.alarmhandler root :43 pts/4 00:00:00 grep Ala [CENTRAL] /home/smallcell # Upgrading Serving Node from RMS 5.1 EFT to RMS 5.1 FCS Procedure Step 1 Step 2 Copy the RMS-UPGRADE x.tar.gz file to the /rms directory of the Serving node. Note The "x" in the upgrade image represents the target upgrade load number. Execute the following commands as root user to perform the upgrade: a) cd /; rm -rf /rms/upgrade ; b) tar -zxvf /rms/rms-upgrade x.tar.gz -C /rms; c) /rms/upgrade/upgrade_rms.sh Note In the output, when you are prompted to proceed with the upgrade, enter the response. Sample Output: Provide the PNR/PAR password (RMS_App_Password) when prompted and wait for the upgrade to complete with a completed message on the console. [root@primary-serving /]# /rms/upgrade/upgrade_rms.sh Detecting the RMS Node.. Serving-Node 16 July 6, 2015

17 Upgrading Serving Node from RMS 5.1 EFT to RMS 5.1 FCS Detected RMS E setup. Upgrading the current RMS installation to FCS. Do you want to proceed? (y/n) : y Stopping applications on Serving Node Stopping bpragent.. BAC stopped successfully Disabling the PNR extension points Enter cnradmin Password: Stopping PNR.. Stopping CAR.. Taking RMS Serving Node file backup as per the configuration in the file:/rms/upgrade/backupfilelist/servingbackupfilelist Copying the DHCP files.. Files are being moved to backup directory Copying the DHCP files done Filebackup tar is present at path : /rms-serving.tar Starting RPM Upgrade.. Upgrading the BAC on RMS Serving Node... Enabling the PNR extensions Starting bpragent.. Starting PNR.. Starting CAR.. Enter caradmin Password: Executing configarextension.sh.. Executing runcopycarfile.sh.. Restarting bpragent.. /usr/java /rms /rms Upgrading PNR-local... PNR upgraded to CNR i686 Rollforward recovery using "/rms/app/cscoar/data/db/vista.tjf" started Sat Jun 20 13:59: Rollforward recovery using "/rms/app/cscoar/data/db/vista.tjf" finished Sat Jun 20 13:59: Upgrading PAR... Upgrading jre to CAR upgraded to CPAR noarch Restoring the Serving certs : Disabling the unnecessary TCP/IP Services July 6,

18 Upgrading Serving Node from RMS 5.1 EFT to RMS 5.1 FCS Step 3 Step 4 Finished upgrading RMS Serving Node. [root@primary-serving /]# Repeat steps 2a to 2c on the redundant Serving node in case of a redundant setup. If the Serving nodes have redundancy configured on the system, follow these steps: a) On the primary Serving node, run the following commands: 1 Remove the existing firewall for the port 647 on udp protocol. iptables -D INPUT -s serving-node-2-eth0-address/netmask -d serving-node-1-eth0-address/netmask -i eth0 -p udp -m udp --dport 647 -m state --state NEW -j ACCEPT iptables -D OUTPUT -s serving-node-1-eth0-address/netmask -d serving-node-2-eth0-address/netmask -o eth0 -p udp -m udp --dport 647 -m state --state NEW -j ACCEPT 2 Add the IPtable for the port 647 on tcp protocol. iptables -A INPUT -s serving-node-2-eth0-address/netmask -d serving-node-1-eth0-address/netmask -i eth0 -p tcp -m tcp --dport 647 -m state --state NEW -j ACCEPT iptables -A OUTPUT -s serving-node-1-eth0-address/netmask -d serving-node-2-eth0-address/netmask -o eth0 -p tcp -m tcp --dport 647 -m state --state NEW -j ACCEPT service iptables save service iptables restart Example: iptables -D INPUT -s /32 -d /32 -i eth0 -p udp -m udp --dport 647 -m state --state NEW -j ACCEPT iptables -D OUTPUT -s /32 -d /32 -o eth0 -p udp -m udp --dport 647 -m state --state NEW -j ACCEPT iptables -A INPUT -s /32 -d /32 -i eth0 -p tcp -m tcp --dport 647 -m state --state NEW -j ACCEPT iptables -A OUTPUT -s /32 -d /32 -o eth0 -p tcp -m tcp --dport 647 -m state --state NEW -j ACCEPT service iptables save service iptables restart b) On the secondary Serving node, run the following commands: 1 Remove the existing firewall for the port "647" on udp protocol. iptables -D INPUT -s serving-node-1-eth0-address/netmask -d serving-node-2-eth0-address/netmask -i eth0 -p udp -m udp --dport 647 -m state --state NEW -j ACCEPT iptables -D OUTPUT -s serving-node-2-eth0-address/netmask -d serving-node-1-eth0-address/netmask -o eth0 -p udp -m udp --dport 647 -m state --state NEW -j ACCEPT 2 Add the IPtable for the port 647 on tcp protocol. iptables -A INPUT -s serving-node-1-eth0-address/netmask -d serving-node-2-eth0-address/netmask -i eth0 -p tcp -m tcp --dport 647 -m state --state NEW -j ACCEPT 18 July 6, 2015

19 Upgrading Serving Node from RMS 5.1 EFT to RMS 5.1 FCS iptables -A OUTPUT -s serving-node-2-eth0-address/netmask -d serving-node-1-eth0-address/netmask -o eth0 -p tcp -m tcp --dport 647 -m state --state NEW -j ACCEPT service iptables save service iptables restart Example: iptables -D INPUT -s /32 -d /32 -i eth0 -p udp -m udp --dport 647 -m state --state NEW -j ACCEPT iptables -D OUTPUT -s /32 -d /32 -o eth0 -p udp -m udp --dport 647 -m state --state NEW -j ACCEPT iptables -A INPUT -s /32 -d /32 -i eth0 -p tcp -m tcp --dport 647 -m state --state NEW -j ACCEPT iptables -A OUTPUT -s /32 -d /32 -o eth0 -p tcp -m tcp --dport 647 -m state --state NEW -j ACCEPT service iptables save service iptables restart c) Change the PNR product version on the cluster configuration of the primary Serving node by following these steps as a root user: 1 /rms/app/nwreg2/local/usrbin/nrcmd -N cnradmin 2 cluster Backup-cluster set product-version=8.3 3 save 4 dhcp reload Example: [root@serving-1-41 admin1]# /rms/app/nwreg2/local/usrbin/nrcmd -N cnradmin password: 100 Ok session: cluster = localhost current-view = Default current-vpn = global default-format = user dhcp-edit-mode = synchronous dns-edit-mode = synchronous groups = superuser roles = superuser user-name = cnradmin visibility = 5 nrcmd> cluster Backup-cluster set product-version= Ok nrcmd> save 100 Ok nrcmd> dhcp reload 100 Ok nrcmd> July 6,

20 Upgrading Upload Node from RMS 5.1 EFT to RMS 5.1 FCS Upgrading Upload Node from RMS 5.1 EFT to RMS 5.1 FCS Procedure Step 1 Step 2 Copy the RMS-UPGRADE x.tar.gz file to the /rms directory of the Upload node. Note The "x" in the upgrade image represents the target upgrade load number. Execute the following commands as root user to perform the upgrade: a) cd /; rm -rf /rms/upgrade ; b) tar -zxvf /rms/rms-upgrade x.tar.gz -C /rms; c) /rms/upgrade/upgrade_rms.sh Note In the output, when you are prompted to proceed with the upgrade, enter a response. Provide the valid keystore password (RMS_App_Password) when prompted and wait for the upgrade to complete with a completed message on the console. Step 3 Sample Output: [root@primary-upload /]# /rms/upgrade/upgrade_rms.sh Detecting the RMS Node.. Upload-Node Detected RMS E setup. Upgrading the current RMS installation to FCS. Do you want to proceed? (y/n) : y Stopping applications on Upload Node Stopping Upload Server.. Taking RMS Upload Node file backup as per the configuration in the file:/rms/upgrade/backupfilelist/uploadbackupfilelist tar: Removing leading `/' from member names Filebackup tar is present at path : /rms-upload.tar Starting RPM Upgrade.. UPLOAD SERVER upgraded to /rms/upgrade/rpms/cscorms-upload-server noarch.rpm Restoring the Upload certs : Enter Keystore Password: Restarting Upload Server Disabling the unnecessary TCP/IP Services Finished upgrading RMS Upload Node. [root@primary-upload /]# Repeat Steps 2a to 2c on the redundant Upload node in case of a redundant setup. What to Do Next Start the RMS Northbound traffic and Southbound traffic. Start the cron jobs and proceed to Additional Information, on page July 6, 2015

21 Additional Information Additional Information Post-upgrade, the default NBI user "pmguser" password and role is changed as per RMS5.1 versions, hence NBI operations cannot be performed as pmguser. Manually create a new NBI user via DCC UI > Admin tab with access to PMG API to do all the NBI operations. Optionally, use pmgadmin user with the default RMS5.1 version password to peroform NBI operations. After upgrade, the default password provided as the "Current Password" is "Rmsuser@1" for any newly created DCC UI login user. All the other user passwords, CLI passwords, BAC password, keystore passwords, and so on remain unchanged as in RMS, Release 4.1. The existing truststore/keystore is retained. If there are new certificates signed by certificate authority required for provisioning LTE AP, manually add the certificates signed by certificate authority that is not included in the file by default, see the Importing Certificates Into Cacerts File and Importing Certificates Into Upload Server Truststore file. The DCC UI dynamic screens, such as SDM Dashboard, Registration, Update, and Groups and IDs XMLs, are auto-replaced with the respective RMS 5.1 versions. Manually merge the customization from the backup directory /rmsbackupfiles with the RMS 5.1 xmls present in /rms/app/rms/conf by following Merging of Files Manually, on page 21. Perform basic sanity on the system, see Basic Sanity Check Post RMS Upgrade, on page 26. Merging of Files Manually Post upgrade, only the new RMS configuration can be used. To use a property that was manually configured in an earlier release of the RMS to be used in the new installation, specifically the DCC-UI dynamic screens, manually merge the files by copying the respective properties to the new XML of your release. Following are the files that require manual change: sdm-register-residential-screen-setup.xml sdm-register-enterprise-screen-setup.xml sdm-update-residential-screen-setup.xml sdm-update-enterprise-screen-setup.xml sdm-static-neighbors-filter-screen-setup.xml sdm-inter-rat-static-neighbors.xml sdm-inter-freq-static-neighbors.xml umt-config.xml umt-setup.xml deviceparamsdisplayconfig.xml bgmt-add-group-screen-setup-area.xml bgmt-add-group-screen-setup-femtogateway.xml bgmt-add-group-screen-setup-rfprofile.xml July 6,

22 Merging of Files Manually bgmt-add-group-screen-setup-alarmsprofile.xml bgmt-add-group-screen-setup-site.xml bgmt-add-group-screen-setup-enterprise.xml bgmt-add-pool-screen-setup-cell-pool.xml bgmt-add-pool-screen-setup-sai-pool.xml pmg-profile.xml All the above files are backed up in /rmsbackupfiles directory of the Central node by the upgrade script. Copy and paste the specific propertytag from XMLs in /rmsbackupfiles manually to the respective files under /rms/app/rms/conf directory. sdm-register-residential-screen-setup.xml in RMS 4.1 corresponds to sdm-register-umts-residential-screen-setup.xml in RMS 5.1. sdm-register-enterprise-screen-setup.xml in RMS 4.1 corresponds to sdm-register-umts-enterprise-screen-setup.xml in RMS 5.1. sdm-update-residential-screen-setup.xml in RMS 4.1 corresponds to sdm-update-umts-residential-screen-setup.xml in RMS 5.1. sdm-update-enterprise-screen-setup.xml in RMS 4.1 corresponds to sdm-update-umts-enterprise-screen-setup.xml in RMS 5.1. sdm-static-neighbors-filter-screen-setup.xml in RMS 4.1 corresponds to sdm-static-neighbors-filter-screen-setup.xml in RMS 5.1. sdm-inter-rat-static-neighbors.xml in RMS 4.1 corresponds to sdm-inter-rat-static-neighbors.xml in RMS 5.1. sdm-inter-freq-static-neighbors.xml in RMS 4.1 corresponds to sdm-inter-freq-static-neighbors.xml in RMS 5.1. umt-setup.xml in RMS 4.1 corresponds to umt-setup.xml in RMS 5.1. umt-config.xml in RMS 4.1 corresponds to umt-config.xml in RMS 5.1. deviceparamsdisplayconfig.xml in RMS 4.1 corresponds to deviceparamsdisplayconfig.xml in RMS 5.1. bgmt-add-group-screen-setup-area.xml in RMS 4.1 corresponds to bgmt-add-group-screen-setup-area-mixed.xml in RMS 5.1. bgmt-add-group-screen-setup-femtogateway.xml in RMS 4.1 corresponds to bgmt-add-group-screen-setup-femtogateway.xml in RMS 5.1. bgmt-add-group-screen-setup-rfprofile.xml in RMS 4.1 corresponds to bgmt-add-group-screen-setup-rfprofile.xml in RMS 5.1. bgmt-add-group-screen-setup-alarmsprofile.xml in RMS 4.1 corresponds to bgmt-add-group-screen-setup-alarmsprofile.xml in RMS 5.1. bgmt-add-group-screen-setup-site.xml in RMS 4.1 corresponds to bgmt-add-group-screen-setup-site.xml in RMS 5.1. bgmt-add-group-screen-setup-enterprise.xml in RMS 4.1 corresponds to bgmt-add-group-screen-setup-enterprise.xml in RMS July 6, 2015

23 Merging of Files Manually bgmt-add-pool-screen-setup-cell-pool.xml in RMS 4.1 corresponds to bgmt-add-pool-screen-setup-cell-pool.xml in RMS 5.1. bgmt-add-pool-screen-setup-sai-pool.xml in RMS 4.1 corresponds to bgmt-add-pool-screen-setup-sai-pool.xml in RMS 5.1. pmg-profile.xml in RMS4.1 corresponds to pmg-profile.xml in RMS5.1. Procedure Step 1 Step 2 Step 3 Step 4 Step 5 If you want the following property, which was manually configured in RMS4.1 (to block the device through update operation) to be in 5.1 as well, copy the below configuration to /rms/app/rms/conf/sdm-update-residential-screen-setup.xml from /rmsbackupfiles/sdm-update-screen-setup.xml: <ScreenElement> <Id>blocked</Id> <Required>false</Required> <Label>Block</Label> <LabelWidth>100px</LabelWidth> <CheckBox> </CheckBox> <ToolTip>Controls if the device is blocked or not.</tooltip> <StoredKey>Blocked</StoredKey> <StoredSection>element</StoredSection> <StoredType>boolean</StoredType> </ScreenElement> Navigate to /rms/app/rms/conf. Edit sdm-update-residential-screen-setup.xml using VI Editor as follows: a) vi sdm-update-residential-screen-setup.xml b) At the end of the file, before </ScreenElements> tag, paste the sdm-update-residential-screen-setup.xml c) Save the changes :wq! d) Verify the changes in the Update screen of DCC UI. If you want all the customization to be reconfigured use the linux diff command between the backup file in /rmsbackupfiles and the actual file in /rms/app/rms/conf, copy the customization from backupfile and paste it in the actual file. If pmg-profile.xml is modified, restart the PMG process using the below command: service god restart Example: [rms-distr-central] /rms/app/rms/conf # service god restart Sending 'stop' command. The following watches were affected: PMGServer Sending 'stop' command The following watches were affected: AlarmHandler.. Stopped all watches Stopped god Sending 'load' command The following tasks were affected: July 6,

24 Recording the BAC Configuration Template File Details PMGServer Sending 'load' command The following tasks were affected: AlarmHandler [rms-distr-central] /rms/app/rms/conf # Recording the BAC Configuration Template File Details Follow this procedure to record the Class of Service for the manually edited BAC configuration template file pre-upgrade. Procedure Step 1 Step 2 Step 3 Log in to the BAC UI. Go to Configuration > Class of Service. Click each Class of Services and record all the manual customization implemented in the configuration template. Skip this step if the customized information is available. Associating Manually Edited BAC Configuration Template Follow this procedure to associate the manually edited BAC configuration template, post upgrade. Procedure Step 1 Step 2 Step 3 Step 4 Step 5 Step 6 Step 7 Step 8 Step 9 Step 10 Log in to the BAC UI. Go to Configuration > Files. Export each configuration template to be customized. Save the file to the local machine and customize the changes in the template. Go to Configuration > Files. Click Add to open the Add File dialog box. In the File Type drop-down list, select Configuration Template. Click Browse and select the file from your system. Click Submit. Repeat Steps 2 to 8 for all the applicable templates. 24 July 6, 2015

25 Rollback to Version RMS 4.1 Rollback to Version RMS 4.1 Procedure Step 1 Step 2 Step 3 Step 4 Power-Off the current VM. Right-click on the VM, and choose the option Delete from Disk. Follow the steps described in Restore from vapp Clone. Follow the, on page 1 to perform the upgrade again. Rollback to Version, RMS 5.1 EFT Procedure Step 1 Step 2 Step 3 Step 4 Step 5 Power off the current VM. Right-click on the VM and choose and click the Delete from Disk option. Follow the steps described in Restore from vapp Clone. Follow the steps described in Network Unreachable on Cloning RMS VM to access the clone via ssh. Follow the, on page 1 to perform the upgrade again. Removing Obsolete Data Procedure Step 1 Log in to the Central node as a root user and execute the following commands: a) Delete files older than five days in the PMG console, debug, audit, events, inbound and outbound message log files using the following command: find /rms/log/pmg/pmgserver.console.log.[0-9]*.gz -mtime +5 -exec rm {} \; find /rms/log/pmg/pmg-debug*.[0-9].log.gz -mtime +5 -exec rm {} \; find /rms/log/pmg/pmg-audit*.[0-9].log.gz -mtime +5 -exec rm {} \; find /rms/log/pmg/pmg-events*.[0-9].log.gz -mtime +5 -exec rm {} \; find /rms/log/pmg/pmg-outbound-msg*.[0-9].log.gz -mtime +5 -exec rm {} \; find /rms/log/pmg/pmg-inbound-msg*.[0-9].log.gz -mtime +5 -exec rm {} \; find /rms/log/pmg/pmg-alarms-*.[0-9].log.gz -mtime +5 -exec rm {} \; find /rms/log/pmg/*.tmp -mtime +5 -exec rm {} \; July 6,

26 Basic Sanity Check Post RMS Upgrade b) Delete files older than five days in the DCC debug, audit, useredits, and csrf log files using the following command: find /rms/log/dcc_ui/ui-debug*.[0-9]*.gz -mtime +5 -exec rm {} \; find /rms/log/dcc_ui/ui-audit*.[0-9]*.gz -mtime +5 -exec rm {} \; find /rms/log/dcc_ui/ui-csrf*.[0-9]*.gz -mtime +5 -exec rm {} \; c) Delete all RMS4.1 hotfix related files present in /rms and /home directory (scripts and tars). d) Delete files older than five days in the ops tool output directory using the following command: find /rms/ops/* -daystart -mtime +5 delete; e) Delete the files older than 5 days in the troubleshooting logs, agent logs and cron backups using the following commands: find /rms/data/cscobac/rdu/logs/troubleshooting.log.* -mtime +5 -exec rm {} \; find /rms/data/cscobac/agent/logs/*.log-[0-9]* -mtime +5 -exec rm {} \; find /rms/backups/* -mtime +5 -exec rm {} \; Step 2 Step 3 Log in to the Serving node as a root user and execute the following commands: a) Delete all RMS4.1 hotfix related files present in /rms and /home directory (scripts and tars). b) Delete files older than five days in the DPE log and agent logs files using the following command: find /rms/data/cscobac/dpe/logs/dpe.*.log -daystart -mtime +5 -delete; find /rms/data/cscobac/agent/logs/*.log-[0-9]* -daystart -mtime +5 -delete; Log in to the Upload Node as a super user and execute the following commands: a) Delete all RMS4.1 hotfix related files present in /rms and /home directory (scripts and tars). b) Delete files older than five days in the Upload server log files using the following command: find /opt/cscouls/logs/uls-*.gz -daystart -mtime +5 delete; find /opt/cscouls/logs/uploadserver.console.*.gz -daystart -mtime +5 delete; Basic Sanity Check Post RMS Upgrade RMS installation sanity check should be performed to ensure that all processes are up and running. For more information, see RMS Installation Sanity Check. On DCC UI: Browse through all tabs on UI and check the group contents. Check version of components on the UI using the "About..." link. Create a new user. Create a new role. On Existing AP: Trigger connection request. Reboot. Trigger on-demand log upload. Perform Factory Recovery/Reset. Set/Get live data. 26 July 6, 2015