Guest

CiscoWorks LAN Management Solution 3.2 and earlier

LMS 2.5 Data Migration Guidelines

  • Viewing Options

  • PDF (786.9 KB)
  • Feedback
LMS 2.5 Data Migration Guidelines

Table Of Contents

LMS 2.5 Data Migration Guidelines

Contents

Introduction

Migrating Data From LMS 2.1 to LMS 2.5

Overview

Backing up LMS 2.1 Data

Manual Backup of LMS 2.1 (CS / RME / Campus Manager / DFM)

Manual Backup of LMS 2.1 From Command Line

Using the CD One, 5th Edition Administration GUI to Backup

Manually Backing Up IPM Data Separately

Automatic Backup From CS Installation

Automatic Backup on Solaris

Automatic Backup on Windows

Upgrading to LMS 2.5

Data Migration and Restore From Backup

Data Migration vs. Restore From Backup

Restore From Backup

Data Migration

Data Migration (From LMS 2.1 to LMS 2.5)

Data Migration Scope

Local Migration Path

Local Migration Path for CS 3.0

Local Migration Path for Campus Manager 4.0

Local Migration Path for RME 4.0

Local Migration Path for DFM 2.0

Local Migration Path for IPM 2.6

Remote Migration Path

Remote Migration Path for CS 3.0 / Campus Manager 4.0 / RME 4.0

Remote Migration Path for DFM 2.0

Remote Migration Path for IPM 2.6 on Solaris

Remote Migration Path for IPM 2.6 on Windows

Migrating Data From LMS 2.2 to LMS 2.5

Overview

Backing up LMS 2.2 Data

Manual Backup of LMS 2.2 (CS / RME / Campus Manager / DFM)

Manual Backup of LMS 2.2 From Command Line

Using the Common Services Administration GUI to Backup

Manually Backing Up IPM Data Separately

Automatic Backup From CS Installation

Automatic Backup on Solaris

Automatic Backup on Windows

Upgrading to LMS 2.5

Data Migration and Restore From Backup

Data Migration vs. Restore From Backup

Restore From Backup

Data Migration

Data Migration (From LMS 2.2 to LMS 2.5)

Data Migration Scope

Local Migration Path

Local Migration Path for CS 3.0

Local Migration Path for Campus Manager 4.0

Local Migration Path for RME 4.0

Local Migration Path for DFM 2.0

Local Migration Path for IPM 2.6

Remote Migration Path

Remote Migration Path for CS 3.0 / Campus Manager 4.0 / RME 4.0

Remote Migration Path for DFM 2.0

Remote Migration Path for IPM 2.6 on Solaris

Remote Migration Path for IPM 2.6 on Windows

Troubleshooting Errors From Data Migration

Errors From CS Data Migration

Errors From RME Data Migration

Errors From DFM Data Migration

Guidelines for Post-Upgrade Activities

Guidelines for DFM 2.0 Post-Upgrade Activities

Guidelines for CS 3.0 Post-Upgrade Activities

Pre-CS 3.0 AAA Methods

CS 3.0 AAA Methods

Appendices

Syntax and Usage for restorebackup.pl

Syntax and Usage for backup.pl

Checking and Fixing Solaris Package Errors

Related Documentation

Obtaining Documentation

Cisco.com

Documentation DVD

Ordering Documentation

Documentation Feedback

Cisco Product Security Overview

Reporting Security Problems in Cisco Products

Obtaining Technical Assistance

Cisco Technical Support Website

Submitting a Service Request

Definitions of Service Request Severity

Obtaining Additional Publications and Information


LMS 2.5 Data Migration Guidelines


13 May 2005

Contents

Introduction

Migrating Data From LMS 2.1 to LMS 2.5

Overview

Backing up LMS 2.1 Data

Manual Backup of LMS 2.1 (CS / RME / Campus Manager / DFM)

Manually Backing Up IPM Data Separately

Automatic Backup From CS Installation

Upgrading to LMS 2.5

Data Migration and Restore From Backup

Data Migration vs. Restore From Backup

Restore From Backup

Data Migration

Local Migration Path

Local Migration Path for CS 3.0

Local Migration Path for Campus Manager 4.0

Local Migration Path for RME 4.0

Local Migration Path for DFM 2.0

Local Migration Path for IPM 2.6

Remote Migration Path

Remote Migration Path for CS 3.0 / Campus Manager 4.0 / RME 4.0

Remote Migration Path for DFM 2.0

Remote Migration Path for IPM 2.6 on Solaris

Remote Migration Path for IPM 2.6 on Windows

Migrating Data From LMS 2.2 to LMS 2.5

Overview

Backing up LMS 2.2 Data

Manual Backup of LMS 2.2 (CS / RME / Campus Manager / DFM)

Manually Backing Up IPM Data Separately

Automatic Backup From CS Installation

Upgrading to LMS 2.5

Data Migration and Restore From Backup

Data Migration vs. Restore From Backup

Restore From Backup

Data Migration

Local Migration Path

Local Migration Path for CS 3.0

Local Migration Path for Campus Manager 4.0

Local Migration Path for RME 4.0

Local Migration Path for DFM 2.0

Local Migration Path for IPM 2.6

Remote Migration Path

Remote Migration Path for CS 3.0 / Campus Manager 4.0 / RME 4.0

Remote Migration Path for DFM 2.0

Remote Migration Path for IPM 2.6 on Solaris

Remote Migration Path for IPM 2.6 on Windows

Troubleshooting Errors From Data Migration

Errors From CS Data Migration

Errors From RME Data Migration

Errors From DFM Data Migration

Guidelines for Post-Upgrade Activities

Guidelines for DFM 2.0 Post-Upgrade Activities

Guidelines for CS 3.0 Post-Upgrade Activities

Appendices

Syntax and Usage for restorebackup.pl

Syntax and Usage for backup.pl

Checking and Fixing Solaris Package Errors

Related Documentation

Obtaining Documentation

Documentation Feedback

Cisco Product Security Overview

Obtaining Technical Assistance

Obtaining Additional Publications and Information

Introduction

This document describes the steps involved in backing up, upgrading, and migrating data for CiscoWorks LAN Management Solutions (LMS) 2.5. The following upgrade paths are described in this document:

LMS 2.1 to LMS 2.5

LMS 2.2 to LMS 2.5

If you are currently on version 2.1 of LMS, see "Migrating Data From LMS 2.1 to LMS 2.5" section.

If you currently are on version 2.2 of LMS, see "Migrating Data From LMS 2.2 to LMS 2.5" section.

Migrating Data From LMS 2.1 to LMS 2.5

This section describes the data migration from LMS 2.1 to LMS 2.5.

An updated version of this document and the Release Notes are available online at the following URL:

LMS 2.5 Data Migration Guidelines

http://www.cisco.com/en/US/products/sw/cscowork/ps2425/prod_installation_guides_list.html

Release Notes for Common Services 3.0

http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/
cw2000_d/comser30/relnotes/cwcs_rnw.htm#wp1086373

You must use this document in conjunction with the Release Notes for important information that may affect the upgrade and data migration process.

Overview

This section explains how to backup data, upgrade, and migrate data from LMS 2.1 to LMS 2.5.

This involves upgrading the LMS components Common Services (CD One 5th Edition to CS 3.0), Campus Manager (3.2 to 4.0), Resource Manager Essentials or RME (3.4 to 4.0) and Device Fault Manager or DFM (1.2 to 2.0).

If you have installed CiscoWorks Routed WAN Management Solution (RWAN) 1.2 and LMS 2.1 on the same server, you may also have the RWAN 1.2 components ACL Manager (ACLM) 1.4 and Internetworking Performance Monitor (IPM) 2.4 on your system.

This section also explains how to upgrade IPM 2.4 to 2.6.

This section explains how to perform a particular upgrade process for a specific LMS component successfully without reading the entire document in sequence or referring to other documents.

For instance, if you want to migrate RME data in-place (local upgrade), read the sections "Overview" and "Upgrade to LMS 2.5". You can then read the section "Local Migration Path for RME 4.0" to get enough information to migrate RME data in-place.

This section includes the steps for both Solaris and Windows platforms.

To upgrade LMS 2.1 (which runs on Solaris 2.7, Solaris 2.8 or Windows 2000 Server) to LMS 2.5 (which runs on Solaris 2.8, Solaris 2.9, Windows 2000 Server or Windows 2003 Server):


Step 1 Take a backup of LMS 2.1 data.

For more information, see the "Backing up LMS 2.1 Data" section.

Step 2 Check the operating system supported for LMS 2.5.

Table 1 Operating Systems Supported for LMS 2.5

Operating System
Type 1
Type 2

Solaris

2.8

2.9

Windows 2000

Professional with SP3 and SP4

Server / Enterprise Edition (Advanced Server) with SP 3 and SP 4

Windows 2003

Standard Edition

Enterprise Edition



Warning For DFM users, if you plan to upgrade your operating system from Solaris 2.8 to Solaris 2.9, you need to run the DFMrestore.pl script (in the DFM 2.0 upgrade kit) on Solaris 2.8 (before migrating your operating system) for the remote upgrade. For details on how to obtain the DFM 2.0 upgrade kit, see the "Remote Migration Path for DFM 2.0" section.


Step 3 Check and fix package errors.

Solaris

For Solaris users, you need to check and fix Solaris package errors before upgrading to CS 3.0 by doing the following:

1. Download the script check_pkg_errors.sh from Cisco.com.

2. Run the script check_pkg_errors.sh to check and fix any possible Solaris package errors.

For more information, see the "Checking and Fixing Solaris Package Errors" section.

Windows

Windows users can skip this step.

Step 4 Upgrade to LMS 2.5 using either of these methods:

Method 1:

Upgrading your LMS installation from LMS 2.1 to LMS 2.5 on the same host machine or server is called a local upgrade.

Method 2:

Upgrading your LMS installation by setting up a freshly installed LMS 2.5 server on the same host or another host machine and migrating the existing LMS 2.1 data to the server on which LMS 2.5 is installed is called a remote upgrade.


Note In general, we recommended that you upgrade your LMS system using the remote upgrade method (Method 2 above), using two machines.


In order to upgrade from LMS 2.1 to LMS 2.5, you must first install Common Services (CS 3.0), then optionally install one or more of the applications, RME 4.0, Campus Manager 4.0, DFM 2.0 or IPM 2.6.


Warning To upgrade from LMS 2.1 to LMS 2.5, you must follow the steps in the same order as described in "Upgrading to LMS 2.5" section.


Step 5 Migrate Data from LMS 2.1 to LMS 2.5 using either of these methods:

Method 1: Local Migration Path

For the detailed local data migration guidelines for upgrading from LMS 2.1 to LMS 2.5, see the section "Local Migration Path" for the applications CS 3.0, Campus Manager 4.0, RME 4.0, DFM 2.0 and IPM 2.6, respectively, that is:

Local Migration Path for CS 3.0

Local Migration Path for Campus Manager 4.0

Local Migration Path for RME 4.0

Local Migration Path for DFM 2.0

Local Migration Path for IPM 2.6

Method 2: Remote Migration Path

For the detailed remote data migration guidelines for upgrading from LMS 2.1 to LMS 2.5, see the section "Remote Migration Path" for the applications CS 3.0/Campus Manager 4.0/RME 4.0, DFM 2.0, and IPM2.6, respectively, that is:

Remote Migration Path for CS 3.0 / Campus Manager 4.0 / RME 4.0

Remote Migration Path for DFM 2.0

Remote Migration Path for IPM 2.6 on Solaris

Remote Migration Path for IPM 2.6 on Windows


Backing up LMS 2.1 Data

This section contains:

Manual Backup of LMS 2.1 (CS / RME / Campus Manager / DFM)

Manually Backing Up IPM Data Separately

Automatic Backup From CS Installation

On Windows, when you attempt to restore your data during remote or local migration, you may see the following error message:

"ERROR: Unable to copy from backup archive folder to temporary folder

POSSIBLE REASON:

Some files in the backup archive might not have enough permissions to read and copy.

SUGGESTION TO RESOLVE:

1. Open 'Windows Explorer'.

2. Right click on the generation folder (DB_BKP\0) and select 'Properties'

3. Click the 'Security tab'

4. Select/De-Select the allow/deny boxes so that you have permission to read

5. Click the 'Advanced button'

6. Enable the 'Reset permissions on all child objects.......' check boxes.

7. Click 'Apply', and 'OK' Button

Try doing the restore again, you should succeed."

You can resolve the error by following the steps suggested in the error message.

To avoid encountering this error, set the permissions of the backup folder on Windows correctly by following the steps suggested here before you start the remote migration or local migration from LMS 2.1 to LMS 2.5.

Manual Backup of LMS 2.1 (CS / RME / Campus Manager / DFM)

This section contains:

Manual Backup of LMS 2.1 From Command Line

Using the CD One, 5th Edition Administration GUI to Backup

Manual Backup of LMS 2.1 From Command Line

You can use backup.pl to backup data for LMS 2.1 (CD One 5th Edition, RME 3.4.x, Campus Manager 3.2.x, and DFM 1.2) at the same time.

If BKP is the directory in which you chose to backup your data, the data will be stored in the directories BKP/0, BKP/1, BKP/2, and so on, where BKP/n stores the data of the (n+1)th generation.

IPM data must be backed up with a separate script, RBackup.sh for Solaris or rbackup.exe for Windows.

For more information, see the "Manually Backing Up IPM Data Separately" section.

The syntax for backup.pl is:

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/backup.pl BackupDirectory [LogFile] [Num_Generations]

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\backup.pl BackupDirectory [LogFile] [Num_Generations]

Where:

BackupDirectory—is the directory that you want to be your backup directory. Make sure that the backup directory has enough space. Also, the backup directory can be created automatically by running backup.pl, if it does not exist.

[LogFile]—is the log file name.

[Num_Generations]—is the maximum number of backup generations to be kept in the backup directory.

Example (Solaris):

$NMSROOT/bin/perl $NMSROOT/bin/backup.pl /var/my_backup /var/tmp/backup.log 2

Using the CD One, 5th Edition Administration GUI to Backup

You can also backup LMS 2.1 data using the LMS 2.1 Server Administration GUI. To backup the data:


Step 1 Log in to LMS 2.1.

Step 2 From the LMS 2.1 desktop, select Server Configuration > Administration > Database Management > Back Up Data Now.

Step 3 From the Backup Data Now dialog box, enter the path and name for the backup directory.

Step 4 Click Finish to start the backup.

We recommend that you backup your data in a different directory than the directory where the LMS 2.1 is located, for example, C:\backups.


Manually Backing Up IPM Data Separately

IPM data is not backed up while using the backup.pl script or automatically backed up during the CS 3.0 in-place upgrade. IPM data must be backed up with a separate script RBackup.sh for Solaris or rbackup.exe for Windows.

Solaris:

Run RBackup.sh from the IPM 2.6 CD-ROM root directory.

This stops all IPM servers that are running and takes a backup of the database, the seed files, the environment variables and the version information. This data is compressed and a file called ipmBackup.tar is created in the IPM 2.4 root directory.

Windows:

Run rbackup.exe, from the IPM 2.6 CD-ROM root directory on the machine on which IPM 2.4 is installed.

This stops all IPM servers that are running and takes a backup of the database, the seed files, and the environment variables.

While running rbackup.exe, the default backup directory is the backup dir under the IPM Installed directory.

However the user can specify any directory. In such a case, the files will be backed up in the specified directory.

Automatic Backup From CS Installation

The CS 3.0 installer will prompt the user for a backup directory during local upgrade and automatically do a backup. However, the automatic backup facility will only back up data for CS, RME, Campus Manager and DFM. It will not back up the data for IPM.


Note You can use restorebackup.pl to restore the data for CS, RME, and Campus Manager from the automatic backup later. But you can not use restorebackup.pl to restore the DFM data from the automatic backup. DFM has its own way to restore data and has no integration with restorebackup.pl.


Automatic Backup on Solaris

For Solaris, the CS 3.0 installer will prompt the user for a backup directory during local upgrade. If DB_BKP is the directory given during the CS installation process, the location of the backup directory and structures are as follows:

DB_BKP/automaticbackup/cmfbackup

DB_BKP/automaticbackup/mcbackup

The DB_BKP/automaticbackup/cmfbackup directory and the DB_BKP/automaticbackup/mcbackup directory are used to store LMS 2.2 backup data and VMS backup data respectively.

VMS (VPN and Security Management Solutions) is another solutions bundle available from Cisco. VMS applications are sometimes known as MC or Monitoring Center applications, hence the mc in the directory name.

If the DB_BKP/automaticbackup/mcbackup directory is empty, there are no VMS based applications installed in the machine.

To restore LMS 2.1 data on LMS 2.5 Server, you should specify DB_BKP/automaticbackup/cmfbackup as the backup directory while restoring the data.

Example 1

To restore the most recent version of LMS 2.1 backup data:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl -d 
DB_BKP/automaticbackup/cmfbackup 

Example 2

To restore the (n+1)th generation of LMS 2.1 backup data:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl -d 
DB_BKP/automaticbackup/cmfbackup -gen n

Example 3

To restore the 1st generation of LMS 2.1 backup data:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl -d 
DB_BKP/automaticbackup/cmfbackup -gen now

Example 4

To restore the 3rd generation of LMS 2.1 backup data:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl -d 
DB_BKP/automaticbackup/cmfbackup -gen 2

Automatic Backup on Windows

For Windows, the CS 3.0 in-place upgrade will prompt the user for a backup directory during local upgrade. If DB_BKP is the directory given during the CS installation process, the backup data will be available under DB_BKP.

Example 1

To restore the most recent of LMS 2.1 backup data:

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl -d DB_BKP

Example 2

To restore the (n+1)th generation of LMS 2.1 backup data:

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl -d DB_BKP -gen n

Example 3

To restore the 1st generation of LMS 2.1 backup data:

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl -d DB_BKP -gen now

Example 4

To restore the 3rd generation of LMS 2.1 backup data:

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl -d DB_BKP -gen 2

Upgrading to LMS 2.5

In order to upgrade from LMS 2.1 to LMS 2.5, you must first install Common Services (CS 3.0), then optionally upgrade one or more of the applications, RME 4.0, Campus Manager 4.0, DFM 2.0, or IPM2.6.


Warning During the RME upgrade and data migration process, the script restorebackup.pl should be executed manually. This script converts RME 3.4.x data to the RME 4.0 format. It also completely restores CS, RME and Campus Manager data and overwrites the DFM device credentials data. This data could have been backed up either automatically (during the CS 3.0 installation) or manually (prior to the CS 3.0 installation). Therefore, the execution of restorebackup.pl during the RME upgrade process will overwrite all CS and Campus Manager data and DFM device credentials data.


To upgrade LMS from 2.1 to 2.5, you must:


Step 1 Upgrade the operating system (OS).


Warning For DFM users, if you plan to upgrade your operating system from Solaris 2.8 to Solaris 2.9, you need to run the DFM upgrade kit on Solaris 2.8 before migrating your operating system for the remote upgrade case. For details on how to obtain the DFM 2.0 upgrade kit, see the "Remote Migration Path for DFM 2.0" section.


Solaris:

Make sure that you upgrade to an OS supported by LMS 2.5 that is Solaris 2.8 or Solaris 2.9.

Windows:

Make sure that you upgrade to an OS supported by LMS 2.5 that is Windows 2000 Server, Windows 2000 Advanced Server, Windows 2000 professional, Windows 2003 Server Standard Edition, or Windows 2003 Server Enterprise Edition.

For details on OS platforms supported by LMS 2.5, see the "Overview" section.

Step 2 Upgrade to CS 3.0.

Solaris:

Insert CD; run setup.sh from the CD-ROM root directory, for example, /cdrom/cdrom0.

Windows:

Insert CD; run setup.exe from the CD-ROM root directory, for example, Z:\.

For more information, see the "Remote Migration Path for CS 3.0 / Campus Manager 4.0 / RME 4.0" section, "Local Migration Path for CS 3.0" section, and "Local Migration Path for Campus Manager 4.0" section.

Step 3 Upgrade to RME 4.0.


Warning At the end of RME installation, you will see the following warning messages. You may ignore it.


=======- Possible Warnings/Errors Encountered -=======

WARNING: Please install/upgrade all the required apps

WARNING: in the bundle and then run the migration scripts

[...]

==========================================================

If you have installed/upgraded RME 4.0 without having installed Campus Manager, or DFM, you will see the following warning message from running the migration script (restorebackup.pl). You may ignore it.

WARNING: There are mismatch between the applications installed in the machine and applications in the backup archive as listed above. This mismatch may lead to data inconsistency. Do you want to continue the Restore? (y-continue or n-quit, y/n)?y

Applications to be restored are............ : [Common Services] [Campus Manager] [Resource Manager Essentials] [Device Fault Manager]

Solaris:

Insert CD; run setup.sh from the CD-ROM root directory, for example, /cdrom/cdrom0.

Windows:

Insert CD; run setup.exe from the CD-ROM root directory, for example, Z:\.

For more information, see the "Remote Migration Path for CS 3.0 / Campus Manager 4.0 / RME 4.0" section and "Local Migration Path for RME 4.0" section.

Step 4 Upgrade to Campus Manager 4.0.

Solaris:

Insert CD; run setup.sh from the CD-ROM root directory, for example, /cdrom/cdrom0.

Windows:

Insert CD; run setup.exe from the CD-ROM root directory, for example, Z:\.

For more information, see the "Remote Migration Path for CS 3.0 / Campus Manager 4.0 / RME 4.0" section, "Local Migration Path for CS 3.0" section, and "Local Migration Path for Campus Manager 4.0" section.

Step 5 Upgrade to DFM 2.0.


Warning You can only do the DFM upgrade process after you have completed the RME upgrade process. Since running restorebackup.pl during the RME upgrade process overwrites the already existing LMS 2.5 data (for CS 3.0, Campus Manager 4.0, and DFM 2.0), you will lose the DCR (Device and Credential Repository) data which is created during the DFM upgrade process for the DFM devices.


Solaris:

Insert CD; run setup.sh from the CD-ROM root directory, for example, /cdrom/cdrom0.

Windows:

Insert CD; run setup.exe from the CD-ROM root directory, for example, Z:\.

For more information, see the "Remote Migration Path for DFM 2.0" section and "Local Migration Path for DFM 2.0" section.

Step 6 Upgrade to IPM 2.6.

Solaris:

Insert CD; run setup.sh from the CD-ROM root directory, for example, /cdrom/cdrom0.

Windows:

Insert CD; run setup.exe from the CD-ROM root directory, for example, Z:\.

For more information, see the "Remote Migration Path for IPM 2.6 on Solaris" section, "Remote Migration Path for IPM 2.6 on Windows" section, and "Local Migration Path for IPM 2.6" section.


Data Migration and Restore From Backup

The section contains:

Data Migration vs. Restore From Backup

Restore From Backup

Data Migration

Data Migration vs. Restore From Backup

The difference between Restore from Backup and Data Migration is:

Restore from Backup refers to data restore from one LMS system to another LMS system having the same version of LMS.

Data Migration refers to data restore from a previous version of LMS (such as LMS 2.1 with CD One 5th Edition, RME 3.4.x, CM 3.2.x, DFM 1.2 and IPM 2.4) to the latest version of LMS (such as LMS 2.5 with CS 3.0, RME 4.0, Campus Manager 4.0, DFM 2.0, and IPM 2.6).

Restore From Backup

This refers to data being restored into an LMS 2.5 server by providing LMS 2.5 backup data.


Note Cross platform backup/restore is NOT supported. That is, you cannot backup or restore from a Solaris installation of LMS to a Windows installation and vice-versa.


You can use restorebackup.pl to restore the LMS 2.5 data for CS/RME/DFM/Campus Manager at one go.


Warning For DFM, restorebackup.pl can only be used to backup data from DFM 2.0 or higher versions and not from a DFM 1.2.x installation.


The Syntax for restorebackup.pl is as follows:

Solaris

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl [-t temporary_directory] [-gen generationNumber] -d BackupDirectory [-h]

Windows

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl [-t temporary_directory] [-gen generationNumber] -d BackupDirectory [-h]

For more information, see the "Syntax and Usage for restorebackup.pl" section.

Data Migration

Data Migration (From LMS 2.1 to LMS 2.5)

Data Migration from LMS 2.1 to 2.5 refers to migrating the preserved LMS 2.1 data (CD One 5th Edition / RME 3.4.x / Campus Manager 3.2.x) to the format used by LMS 2.5 (CS 3.0 / RME 4.0 / Campus Manager 4.0).

Data migration is applicable for local upgrade (on the same machine), or remote upgrade (on a freshly installed LMS 2.5 system which can be either on the same machine or the other machine).


Note In general we suggest upgrading LMS system using the remote upgrade method with two machines.


For more information, see the "Local Migration Path" section and "Remote Migration Path" section.

For RME, you must use restorebackup.pl explicitly to migrate the LMS 2.1 (RME 3.5.x) data to LMS 2.5 (RME 4.0) for both local upgrade and remote upgrade after the RME 4.0 installation completes.

For more information, see the "Local Migration Path for RME 4.0" section and "Remote Migration Path for CS 3.0 / Campus Manager 4.0 / RME 4.0" section.


Warning At the end of RME installation, you will see the following warning messages. You may ignore it.


===========- Possible Warnings/Errors Encountered - ========

WARNING: Please install/upgrade all the required apps

WARNING: in the bundle and then run the migration scripts

[...]

==========================================================


Warning You need to run the migration script (restorebackup.pl) to complete the RME upgrade process. You will see the following warning message, if you have installed/upgraded CS 3.0 without having installed Campus Manager, DFM, or IPM. You may ignore it.


WARNING: There is a mismatch between the applications installed in the machine and applications in the backup archive as listed above. This mismatch may lead to data inconsistency. Do you want to continue the Restore? (y-continue or n-quit, y/n)?y

Applications to be restored are............ : [Common Services] [Campus Manager] [Resource Manager Essentials] [Device Fault Manager]

For Campus Manager, you need to run no explicit scripts if you are doing Campus Manager data migration for local upgrade (on the same machine). If you are doing Campus Manager data migration for the remote upgrade, you must use restorebackup.pl explicitly after the Campus Manager 4.0 installation completes.

For more information, see the "Local Migration Path for CS 3.0" section, "Local Migration Path for Campus Manager 4.0" section, and "Remote Migration Path for CS 3.0 / Campus Manager 4.0 / RME 4.0" section.

For DFM, you must run the DFM12x-DFM20-upgrade.pl command explicitly after the DFM 2.0 installation for both the local upgrade and the remote upgrade.

The restorebackup.pl command is not required, if you are doing DFM data migration for the local upgrade. For the DFM remote data migration, download the DFM-2.0 Upgrade Kit from Cisco.com, and use it after the DFM 2.0 installation.

For more information, see the "Local Migration Path for DFM 2.0" section and "Remote Migration Path for DFM 2.0" section.

IPM data must be migrated by running the command ipm upgrade if you are doing remote upgrade.

For more information, see the "Local Migration Path for IPM 2.6" section, "Remote Migration Path for IPM 2.6 on Solaris" section and "Remote Migration Path for IPM 2.6 on Windows" section.

Data Migration Scope

This section describes the scope of data migration for RME.

RME Data Migration Scope

Migrating RME data will transfer data into the RME 4.0 server by providing RME 3.5.x data backups (with their related IDUs) as inputs to the migration script.

Here are some points to note when you migrate RME data:

You can choose to migrate syslogs.

You can trigger inventory collection for devices being migrated.

On both platforms, migration is supported across different NMSROOT directories.

Cross platform data migration is NOT supported.

The following data is NOT migrated during the RME data migration process:

Inventory: Custom Inventory reports are NOT migrated.

Config Archive: the following data will NOT be migrated:

Processed data like .dfc/.dfr files.

Custom queries.

Config labels.

Out of sync data.

Config Editor: the following data will NOT be migrated:

Config files that are checked out.

Syslog: the following data will NOT be migrated:

User scripts associated with automated actions.

Jobs or job-related data.

SWIM: the following data will NOT be migrated:

Jobs or job-related data.

Local Migration Path

When you perform local data migration, LMS 2.5 (CS 3.0/ RME 4.0 / Campus Manager 4.0/DFM2.0/IPM2.6) is installed on the same machine where the LMS 2.1 (CD One 5th Edition/RME 3.4.x/CM3.2.x/DFM1.2/IPM2.4) is installed.

The data from LMS 2.1 (CD One 5th Edition/RME 3.4.x/CM3.2.x/DFM1.2 /IPM2.4) are preserved. This data is backed up automatically as part of the installation process, and then converted to the format used by LMS 2.5 (CS3.0 / RME4.0 / Campus Manager 4.0 / DFM2.0 / IPM2.6).


Warning At the end of RME installation, you will see the following warning messages. You may ignore it.


=======- Possible Warnings/Errors Encountered - =======

WARNING: Please install/upgrade all the required apps

WARNING: in the bundle and then run the migration scripts

[...]

==========================================================


Warning If you have installed/upgraded CS 3.0 without having installed Campus Manager, or DFM, you will see the following warning message from running the migration script (restorebackup.pl). You may ignore it.


WARNING: There is a mismatch between the applications installed in the machine and applications in the backup archive as listed above. This mismatch may lead to data inconsistency. Do you want to continue the Restore? (y-continue or n-quit, y/n)?y

Applications to be restored are............ : [Common Services] [Campus Manager] [Resource Manager Essentials] [Device Fault Manager]

This section contains:

Local Migration Path for CS 3.0

Local Migration Path for Campus Manager 4.0

Local Migration Path for RME 4.0

Local Migration Path for DFM 2.0

Local Migration Path for IPM 2.6

Local Migration Path for CS 3.0

The following describes how to upgrade the running LMS 2.1 (with CD One 5th Edition) to LMS 2.5 (with CS 3.0) on the same machine and to migrate data from LMS 2.2 to LMS 2.5 for CS 3.0. The procedures are applicable to both Solaris and Windows.


Step 1 Log in to the local LMS 2.1 machine.

Solaris

Log in as root.

Windows

Log in as a local administrator.

Step 2 Run the following command to backup data for LMS 2.1, where NMSROOT is the default installation directory (normally /opt/CSCOpx for Solaris, and C:\Program Files\CSCOpx for Windows):

Solaris

$NMSROOT/bin/perl $NMSROOT/bin/backup.pl BKP

Windows

%NMSROOT%\bin\perl %NMSROOT%\bin\backup.pl BKP

If BKP is backup directory, the data will be stored in the directories BKP/0, BKP/1, and BKP/2 etc., where BKP/n stores the data of the (n+1)th generation

Step 3 Upgrade LMS 2.1 (CD One 5th Edition) to LMS 2.5 (CS 3.0).

To perform the upgrade, you will need to install CS 3.0 from the CD.


Note Upgrading to CS 3.0 forces you to backup data for all the LMS 2.1 installed applications except IPM.



Local Migration Path for Campus Manager 4.0

When you install LMS 2.5 (which includes Campus Manager 4.0) on the same machine where LMS 2.1 (which includes Campus Manager 3.2.x) is installed, the Campus Manager 3.2.x database is preserved.

When you install Campus Manager 4.0, certain data from the preserved Campus Manager 3.2.x database is converted to Campus Manager 4.0 format.

The Campus Manager 4.0 installer automatically updates Campus Manager 3.2.x program files. It also migrates the data from the Campus Manager 3.2.x format to the Campus Manager 4.0 format.

The following procedure describes how to upgrade the running LMS 2.1 (which includes Campus Manager 3.2.x) to LMS 2.5 (which includes Campus Manager 4.0) on the same machine and to migrate data from LMS 2.1 to LMS 2.5 for Campus Manager 4.0.

The procedures are applicable to both Solaris and Windows.


Step 1 Log in to the local LMS 2.1 machine.

Solaris:

Log in as root.

Windows:

Log in as a local administrator.

Step 2 Run the following command to backup data for LMS 2.1, where NMSROOT is the default installation directory (normally /opt/CSCOpx for Solaris, and C:\Program Files\CSCOpx for Windows):

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/backup.pl BKP

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\backup.pl BKP

If BKP is backup directory, the data will be stored in the directories BKP/0, BKP/1, and BKP/2 etc., where BKP/n stores the data of the (n+1)th generation.

Step 3 Upgrade LMS 2.1 (CD One 5th Edition) to LMS 2.5 (CS 3.0) if you have not done it yet.

To perform the upgrade, you need to install CS 3.0 from the CD.

Note that upgrading to CS 3.0 forces you to backup data for all the LMS 2.1 installed applications except IPM.

Step 4 Upgrade from Campus Manager 3.2.x to Campus Manager 4.0.

To perform the upgrade, install the application (Campus Manager 4.0) from the CD.


Local Migration Path for RME 4.0

The following procedure describes how to upgrade the running LMS 2.1 (CD One 5th Edition /RME 3.4.x) to LMS 2.5 (CS 3.0/RME 4.0), and perform data migration from the format of LMS 2.1 to LMS 2.5 on the same machine for CS/RME/Campus Manager, and it is applicable to both Solaris and Windows.


Step 1 Log in to the local LMS 2.1 machine where the application (RME 3.4.x) is installed.

Solaris:

Log in as root.

Windows:

Log in as a local administrator.

Step 2 Run the following command to backup data for LMS 2.1, where NMSROOT is the default installation directory (normally /opt/CSCOpx for Solaris, and C:\Program Files\CSCOpx for Windows):

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/backup.pl BKP

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\backup.pl BKP

If BKP is backup directory, the data will be stored in the directories BKP/0, BKP/1, and BKP/2 etc., where BKP/n stores the data of the (n+1)th generation.

Step 3 Upgrade LMS 2.1 (CD One 5th Edition /RME 3.4.x) to LMS 2.5 (CS 3.0) if you have not done it yet.

To perform the upgrade, you need to install CS 3.0 from the CD.


Note Upgrading to CS 3.0 forces you to backup data for all the LMS 2.1 installed applications except IPM.


Step 4 Upgrade from RME 3.4.x to RME 4.0.

To perform the upgrade, you will need to install the application RME 4.0 from the CD.


Note The upgrade process collects inputs required for installation, uninstalls RME 3.4.x or RME 3.5.x, and installs RME 4.0. Uninstalling RME 3.5.x will cause uninstall of dependent applications like ACLM,
VPN Monitor, etc.


Step 5 Stop the LMS system by entering:

Solaris:

/etc/init.d/dmgtd stop

Windows:

net stop crmdmgtd

Step 6 Restore data from backup of LMS 2.1 (RME 3.4.x) by entering:

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl [-t temporary_directory] [-gen generationNumber] -d BackupDirectory [-h]

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl [-t temporary_directory] [-gen generationNumber] -d BackupDirectory [-h]

For more information, see the "Syntax and Usage for restorebackup.pl" section.

Step 7 To restore the most recent version, enter:

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl -d BackupDirectory

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl -d BackupDirectory

Example (Windows):

%NMSROOT%\bin\restorebackup.pl -d D:\var\backup

Step 8 Restore data from the forced auto backup during the CS upgrade process, by entering the following command:

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl -d DB_BKP/automaticbackup/cmfbackup -gen now

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl -d DB_BKP -gen now

Where, DB_BKP is the specified backup directory name provided during the CS installation.

Step 9 Examine the log file in the following location to verify that the database was restored.

Solaris:

The location is /var/adm/CSCOpx/log/restorebackup.log.

Windows:

The location is %NMSROOT%\log\restorebackup.log.

Step 10 Start the LMS system by entering:

Solaris:

/etc/init.d/dmgtd start

Windows:

net start crmdmgtd


Local Migration Path for DFM 2.0

The following procedure describes how to upgrade the running LMS 2.1 to LMS 2.5, and perform data migration from the format of LMS 2.1 to LMS 2.5 on the same machine for DFM, and it is applicable to both Solaris and Windows.


Note Pathnames provided in the steps below are based on Solaris. For Windows the pathnames will be the same, but will use %NMSROOT%, and backslashes ('\') for path delimiters.



Step 1 Upgrade LMS 2.1 (CD One 5th Edition) to LMS 2.5 (CS 3.0) if you have not done it yet.

To perform the upgrade, you will need to install CS 3.0 from the CD.


Note Upgrading to CS 3.0 forces you to backup data for all the LMS 2.1 installed applications except IPM.


Step 2 Upgrade from DFM 1.2 to DFM 2.0.

To perform the upgrade, install DFM 2.0 from the CD.

The upgrade proceeds without displaying any more questions.

The following upgrade operation is performed transparently during the installation of DFM2.0):

The DFM1.2.x inventory is backed up in the file $NMSROOT/objects/smarts/conf/ICseed.txt

The DFM1.x polling and threshold setting is backed up in $NMSROOT/objects/smarts/conf/ICptm.xml

Managed/unmanaged state of DFM1.x components is backed up in $NMSROOT/objects/smarts/conf/ICinventory.txt

Step 3 Migrate DFM 1.2 data to DFM 2.0 data format.

After the installation of DFM2.0, when the DFM2.0 system comes up, you need to explicitly run the following script to complete the upgrade of DFM 1.2 data into DFM 2.0:

$NMSROOT/bin/perl $NMSROOT/bin/DFM12x-DFM20-upgrade.pl

where $NMSROOT is the default installation directory, normally /opt/CSCOpx for Solaris, and C:\Program Files\CSCOpx for Windows.

The script DFM12x-DFM20-upgrade.pl automatically does all of the following:

Imports the seedfile generated from DFM 1.2.x into DCR.

Imports devices from DCR into DFM 2.0 and monitors device import status.

Device import can take a maximum of three hours, depending on the number of devices in your inventory.

Applies the managed/unmanaged state of the devices/device components obtained from DFM 1.2.x during the upgrade.

Applies new polling and threshold settings to the devices.

Step 4 Verify that the DfmServer process is running.

To verify this, log on to the CiscoWorks Homepage as the administrator and select Common Services > Server > Admin > Processes.

Look for the DfmServer process entry.


Local Migration Path for IPM 2.6

During local migration of IPM 2.6, the IPM database, the HTML reports and seed files from IPM 2.4 are preserved. This data is backed up automatically as part of the installation process and then converted to the format used by IPM 2.6.

The following procedure describes how to upgrade the running IPM 2.4 to IPM 2.6 (LMS 2.5), and perform data migration to LMS 2.5 on the same machine for IPM. It is applicable to both Solaris and Windows platforms.


Step 1 Make sure that you have upgraded the CD One 5th Edition system to CS 3.0 system on the running machine.

Step 2 Upgrade from IPM 2.4 to IPM 2.6.

To perform the upgrade, install IPM 2.6 from the CD.

IPM local upgrade (IPM 2.4 to IPM 2.6) takes care of the IPM data migration like CS/Campus Manager.



Note On Windows, to complete the IPM 2.4 to IPM 2.6 migration, you must stop and restart the IPM processes using the commands ipm stop and ipm start.


Remote Migration Path

Remote Migration of LMS 2.5 refers to the process of migrating data from a machine on which LMS 2.1 is installed to another machine on which LMS 2.5 is installed. Data from LMS 2.1 are preserved.

This data is backed up automatically as part of the installation process, and then converted to the format used by LMS 2.5. The remote migration path is the suggested method to upgrade your LMS system.

The remote upgrade (LMS 2.1 to LMS 2.5) can be done for CS/Campus Manager/RME at one go.

The guidelines described in the section are applicable to both Solaris and Windows.

This section contains:

Remote Migration Path for CS 3.0 / Campus Manager 4.0 / RME 4.0

Remote Migration Path for DFM 2.0

Remote Migration Path for IPM 2.6 on Solaris

Remote Migration Path for IPM 2.6 on Windows

Remote Migration Path for CS 3.0 / Campus Manager 4.0 / RME 4.0

If you want to perform remote upgrade (LMS 2.1 to LMS 2.5) against all of the applications (CS/Campus Manager/RME), you just need to run the following remote upgrade procedures once instead of upgrading CS, Campus Manager, and RME applications separately.

To do a remote migration:


Step 1 Log in to the local LMS 2.1 machine where the application (for example, CD One 5th Edition, CM 3.2.x, or RME 3.4.x) is installed.

Solaris:

Log in as root.

Windows:

Log in as a local administrator.

Step 2 Run the following command to backup data for LMS 2.1, where NMSROOT is the default installation directory (normally /opt/CSCOpx for Solaris, and C:\Program Files\CSCOpx for Windows):

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/backup.pl BKP

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\backup.pl BKP

If BKP is backup directory, the data will be stored in the directories BKP/0, BKP/1, and BKP/2 etc., where BKP/n stores the data of the (n+1)th generation

Step 3 Copy the backup data that you created in Step 2 to a temporary location on the LMS 2.5 machine where the application (for example, CS 3.0, Campus Manager 4.0, or RME 4.0) is installed.

Step 4 Log in to the remote LMS 2.5 machine.


Note If t he applications in the backup data and the applications on the remote machine is not having one-to-one correspondence, restorebackup will display a warning message. You may ignore it.


Solaris:

Log in as root.

Windows:

Log in as a local administrator.

Step 5 Stop the LMS system by entering:

Solaris:

/etc/init.d/dmgtd stop

Windows:

net stop crmdmgtd

Step 6 Migrate the LMS 2.1 data to LMS 2.5 by entering:

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl [-t temporary directory] [-gen generationNumber] -d BackupDirectory [-h]

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl [-t temporary directory] [-gen generationNumber] -d BackupDirectory [-h]

where NMSROOT is the CiscoWorks installation directory.

Step 7 To restore the most recent version, enter the following command:

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl -d BackupDirectory

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl -d BackupDirectory

Example (Windows):

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl -d D:\var\backup

Step 8 Examine the log file in the following location to verify that the database has been restored.

Solaris:

The location is /var/adm/CSCOpx/log/restorebackup.log.

Windows:

The location is %NMSROOT%\log\restorebackup.log.

Step 9 Start the LMS system by entering:

Solaris:

/etc/init.d/dmgtd start

Windows:

net start crmdmgtd


Remote Migration Path for DFM 2.0

The following describes how to backup LMS 2.1 (DFM 1.2) data on one machine and migrate this data to a freshly installed LMS 2.5 (DFM2.0) machine. The LMS 2.5 installation can either be on the same machine or the other machine. The guidelines are applicable to both Solaris and Windows platforms.


Warning For DFM users, if you plan to upgrade your operating system from Solaris 2.8 to Solaris 2.9, you need to run the DFMrestore.pl script (in the DFM 2.0 upgrade kit) on Solaris 2.8 (before migrating your operating system) for the remote upgrade.



Step 1 Log in to the local LMS 2.1 machine where DFM 1.2 is installed.

Solaris:

Log in as root.

Windows:

Log in as a local administrator.

Step 2 Run the following command to backup data for LMS 2.1, where NMSROOT is the default installation directory (normally /opt/CSCOpx for Solaris, and C:\Program Files\CSCOpx for Windows):

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/backup.pl BKP

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\backup.pl BKP

If BKP is backup directory, the data will be stored in the directories BKP/0, BKP/1, and BKP/2 etc., where BKP/n stores the data of the (n+1)th generation.

Step 3 Locate the DFM.rps file.

Solaris:

Untar the file filebackup.tar which is located in DB_BKP/0/dfm. The DFM.rps file is located at /opt/CSCOpx/objects/smarts/repos/icf

Windows:

Untar the file filebackup.tar which is located in DB_BKP\0\dfm.

This DFM.rps file is located at:

DB_BKP\0\dfm\%NMSROOT%\objects\smarts\repos\icf

where,

DB_BKP is the backup directory specified when running the backup.pl command.

Example (Windows):

If you have installed LMS 2.1 in the C:\Program Files\CSCOpx directory on the LMS 2.1 server, and you have backed up LMS 2.1 data in the directory C:\backup, the DFM.rps file will be stored in the following location:

C:\backup\0\dfm\progra~1\CSCOpx\objects\smarts\repos\icf

Step 4 Copy the DFM.rps file to a temporary location on a machine with DFM 2.0 installation.

You can obtain the DFM.rps file for DFM 1.2 from the location you referenced above in step 3 if you have run the script backup.pl.

You also can obtain the DFM.rps file from the DFM1.2.x installation directory as below:

Solaris:

$NMSROOT/objects/smarts/repos/icf

Windows:

%NMSROOT%\objects\smarts\repos\icf

where NMSROOT is the default installation directory (normally /opt/CSCOpx for Solaris, and C:\Program Files\CSCOpx for Windows).

Step 5 Log in to the LMS 2.5 machine (with DFM 2.0 installed) as root for Solaris, and as local administrator for Windows.

Step 6 Download the Upgrade Kit patch from Cisco.com.

Make sure you have adequate free space, then, from the DFM download page at

http://www.cisco.com/cgi-bin/tablebuild.pl/cw2000-dfm, click the:

cw-dfm-20UpgradeKit-sol.tar.Z link for Solaris,

or

cw-dfm-20UpgradeKit-win.zip for Windows,

and follow the instructions to download the file to a temporary working area of your server (such as /tmp).

Step 7 Extract or unzip the patch from the directory in which the download file resides.

Solaris:

Uncompress the patch and extract the script DFMRestore.pl file into the local directory:

a. Make sure you have adequate free space to store the uncompressed patch, then run the following command to uncompress the patch in the temporary working area.

b. Uncompress cw-dfm-20UpgradeKit-sol.tar.Z.

c. Extract the files from the uncompressed patch into the local directory using the tar command tar xvf cw-dfm-20UpgradeKit-sol.tar.

Windows:

Unzip the patch into a local directory (such as C:\), and get the script DFMRestore.pl file into the local directory.

Step 8 Upgrade the DFM.rps file information from DFM 1.2 into DFM 2.0.


Note Make sure that you change your working directory to the smarts subdirectory under the directory in which you extracted the patch before running the DFMRestore.pl command.


From the directory EXTRACT_DIR/smarts run the following command:

$NMSROOT/bin/perl DFMRestore.pl -n $NMSROOT -o DFM_RPS_DIR

where,

NMSROOT—Environment variable containing full pathname of DFM 2.0 installation directory (normally /opt/CSCOpx).

EXTRACT_DIR—Directory into which you extracted the patch (using tar)

DFM_RPS_DIR—Location of your copy of the DFM.rps file for DFM 1.2.x (full pathname).

For DFM 1.2.x, this file is located in $NMSROOT/objects/smarts/repos/icf/DFM.rps.

If you plan to use a copy of this file that was created during a backup, the file will be located in the backup directory you specified when using CiscoWorks Common Services 2.2.

This creates the necessary DFM 1.2.x export text files (ICseed.txt, ICinventory.txt, and ICptm.xml) and moves them to the existing DFM 2.0 installation directory under $NMSROOT/objects/smarts/conf for Solaris and %NMSROOT%\objects\smarts\conf for Windows.

Example (Solaris):

(If the patch is extracted in the /tmp directory.)

cd /tmp/smarts
/opt/CSCOpx/bin/perl DFMRestore.pl -n /opt/CSCOpx -o  
/opt/CSCOpx/objects/smarts/repos/icf

Example (Windows):

(If the patch is extracted in C:\ directory)

cd C:\smarts
C:\Progra~1\CSCOpx\bin\perl  DFMRestore.pl -n C:\Progra~1\CSCOpx -o 
C:\backup\0\dfm\Progra~1\CSCOpx\objects\smarts\repos\icf

The system is now configured to use the standard upgrade script (as documented in the installation guides).

Step 9 From the new DFM 2.0 installation, verify that the DfmServer process is running by selecting Common Services > Server > Reports > Process Status.

Step 10 Migrate DFM 1.2 data to DFM 2.0 data format.

After the installation of DFM 2.0, when the DFM 2.0 system comes up, you need to explicitly run the following script to complete the upgrade of DFM 1.2.x data into DFM2.0:

$NMSROOT/bin/perl $NMSROOT/bin/DFM12x-DFM20-upgrade.pl

where $NMSROOT is the default installation directory, normally /opt/CSCOpx for Solaris, and C:\Program Files\CSCOpx for Windows.

The script DFM12x-DFM20-upgrade.pl automatically does all of the following:

Imports the seedfile generated from DFM 1.2.x into DCR.

Imports devices from DCR into DFM 2.0 and monitors device import status.

Device import can take a maximum of three hours, depending on the number of devices in your inventory.

Applies the managed/unmanaged state of the devices/device components obtained from DFM 1.2.x during the upgrade.

Applies new polling and threshold settings to the devices.

Step 11 Refer to the document "Installing and Setting Up Device Fault Manager on Windows" on cisco.com for information on post-upgrade tasks. Go to the URL:

http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/
cw2000/dfm/index.htm


Remote Migration Path for IPM 2.6 on Solaris

When you want to migrate IPM 2.4 data from one machine to IPM 2.6 on the other machine on the same network, you need to do a remote upgrade.


Note When you do an upgrade, existing IPM 2.6 data is overwritten.


To do a remote upgrade of IPM 2.6:


Step 1 Mount the IPM 2.6 CD-ROM on the machine on which IPM 2.4 is installed.

Step 2 Run RBackup.sh from the CD-ROM root directory.

This stops all IPM servers that are running and takes a backup of the database, the seed files, the environment variables, and the version information.

While executing RBackup.sh, the default backup directory is /opt. The user can specify any directory.

The data is compressed and ipmBackup.tar file is created in the specified directory.

Step 3 Install IPM 2.6 on the remote machine.

Step 4 Copy ipmBackup.tar to the IPM 2.6 root directory.

Before copying the file, make sure that IPM 2.6 has been installed on that machine.

Step 5 Change your working directory to the bin directory of the IPM server.

Step 6 Make sure that the License Server process (called LicenseServer) is up and running.

Step 7 Run ipm upgrade at the command prompt.


Remote Migration Path for IPM 2.6 on Windows

When you migrate IPM 2.4 data from one machine to IPM 2.6 on the other machine on the same network, you need to do a remote upgrade. Note that when you do an upgrade, existing IPM 2.6 data is overwritten.

To do a remote upgrade:


Step 1 Run rbackup.exe, from the IPM 2.6 CD-ROM root directory, on the machine on which IPM 2.4 is installed.

This stops all IPM servers that are running and takes a backup of the database, the seed files, and the environment variables.

While executing rbackup.exe, the default backup directory is the backup directory under the IPM installation root directory. However, you can specify any directory when running this command. In that case, the files will be backed up in the specified directory.


Note When using a custom directory some of the files does not have proper permissions so later when moving these files to remote machine, the permissions of the files need to be manually modified.


Step 2 Change your working directory to the directory where you have installed IPM 2.4 and change to the backup directory.

Step 3 Install IPM 2.6 on the remote machine.

Step 4 Copy the entire contents in this directory to the backup directory under the directory where you have installed IPM 2.6.

Step 5 Change your working directory to the bin directory of the IPM server.

Step 6 Make sure that the License Server process (called LicenseServer) is up and running.

Step 7 Run ipm upgrade at the command prompt.

The upgrade from IPM 2.4 to IPM 2.6 is complete.


Migrating Data From LMS 2.2 to LMS 2.5

This section describes the data migration from LMS 2.2 to LMS 2.5.

An updated version of this document and the Release Notes are available online at the following URL:

LMS 2.5 Data Migration Guidelines

http://www.cisco.com/en/US/products/sw/cscowork/ps2425/prod_installation_guides_list.html

Release Notes for Common Services 3.0

http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/
cw2000_d/comser30/relnotes/cwcs_rnw.htm#wp1086373

You must use this document in conjunction with the Release Notes for important information that may affect the upgrade and data migration process.

Overview

This section explains how to backup data, upgrade, and migrate data from LMS 2.2 to LMS 2.5. This involves upgrading the LMS components Common Services (2.2 to 3.0), Campus Manager (3.3 to 4.0), Resource Manager Essentials or RME (3.5 to 4.0) and Device Fault Manager or DFM (1.2.3 to 2.0).

If you have installed CiscoWorks Routed WAN Management Solution (RWAN) version 1.3 and LMS 2.2 on the same server, you may also have the RWAN 1.3 components ACL Manager (ACLM) 1.4 and Internetworking Performance Monitor (IPM) 2.5 on your system. This document also explains how to upgrade IPM 2.5 to 2.6.


Note If the server on which you are planning the upgrade is running Windows, you must first install Common Services 2.2 Service Pack 3.0 on your LMS 2.2 server before you begin the upgrade, otherwise the upgrade will fail. For more information on this issue, see the Critical Upgrade section in the Release Notes for Common Services 3.0.


This section explains how to perform a particular upgrade process for a specific LMS component successfully without reading the entire document in sequence or referring to other documents.

For instance, if you want to migrate RME data in-place (local upgrade), read the sections "Overview" and "Upgrade to LMS 2.5", then read the section "Local Migration Path for RME 4.0" to get enough information to migrate RME data in-place.

This section explains the procedure for both Solaris and Windows platforms. To upgrade LMS 2.2 (which runs on Solaris 2.7, Solaris 2.8 or Windows 2000 Server) to LMS 2.5 (which runs on Solaris 2.8, Solaris 2.9, Windows 2000 Server or Windows 2003 Server):


Step 1 Take a backup of LMS 2.2 data.

For more information, see the "Backing up LMS 2.2 Data" section.

Step 2 Check the operating system supported for LMS 2.5.

Table 2 Operating Systems Supported for LMS 2.5

Operating System
Type 1
Type 2

Solaris

2.8

2.9

Windows 2000

Professional with SP3 and SP4

Server / Enterprise Edition (Advanced Server) with SP 3 and SP 4

Windows 2003

Standard Edition

Enterprise Edition



Warning For DFM users, if you plan to upgrade your operating system from Solaris 2.8 to Solaris 2.9, you need to run the DFMrestore.pl script (in the DFM 2.0 upgrade kit) on Solaris 2.8 (before migrating your operating system) for the remote upgrade. For details on how to obtain the DFM 2.0 upgrade kit, see the "Remote Migration Path for DFM 2.0" section.


Step 3 Check and fix package errors.

Solaris

For Solaris users, you need to check and fix Solaris package errors before upgrading to CS 3.0 by doing the following:

1. Download the script check_pkg_errors.sh from Cisco.com.

2. Run the script check_pkg_errors.sh to check and fix any possible Solaris package errors.

For more information, see "Checking and Fixing Solaris Package Errors" section.

Windows

Windows users can skip this step.

Step 4 Upgrade to LMS 2.5 using either of these methods:

Method 1:

Upgrading your LMS installation from LMS 2.2 to LMS 2.5 on the same host machine or server is called a local upgrade.

Method 2:

Upgrading your LMS installation by setting up a freshly installed LMS 2.5 server on the same host or another host machine, and migrating LMS 2.2 data to the server on which LMS 2.5 is installed is called a remote upgrade.

In general, we recommended that you upgrade your LMS system using the remote upgrade method (Method 2 above), using two machines.

In order to upgrade from LMS 2.2 to LMS 2.5, you must first install Common Services (CS 3.0), then optionally install one or more of the applications RME 4.0, Campus Manager 4.0, DFM 2.0 or IPM 2.6 applications.


Warning To upgrade from LMS 2.2 to LMS 2.5, you must follow the steps in the same order as described in "Upgrading to LMS 2.5" section.


Step 5 Migrate Data from LMS 2.2 to LMS 2.5 using either of these methods:

Method 1: Local Migration Path

For the detailed local data migration guidelines for upgrading from LMS 2.2 to LMS 2.5, see the section "Local Migration Path" for the applications CS 3.0, Campus Manager 4.0, RME 4.0, DFM 2.0 and IPM2.6, respectively, that is:

Local Migration Path for CS 3.0

Local Migration Path for Campus Manager 4.0

Local Migration Path for RME 4.0

Local Migration Path for DFM 2.0

Local Migration Path for IPM 2.6

Method 2: Remote Migration Path

For the detailed remote data migration guidelines for upgrading from LMS 2.2 to LMS 2.5, see the section "Remote Migration Path" for the applications CS 3.0 / Campus Manager 4.0 / RME 4.0, DFM 2.0, and IPM 2.6, respectively, that is:

Remote Migration Path for CS 3.0 / Campus Manager 4.0 / RME 4.0

Remote Migration Path for DFM 2.0

Remote Migration Path for IPM 2.6 on Solaris

Remote Migration Path for IPM 2.6 on Windows


Backing up LMS 2.2 Data

On Windows, you must first install Common Services 2.2 Service Pack 3.0 on your LMS 2.2 server before you begin the upgrade, otherwise the upgrade will fail. For more information on this issue, see the Critical Upgrade section in the Release Notes for Common Services 3.0. The Release Notes are at:

http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/cw2000_d/comser30/relnotes/cwcs_rnw.htm#wp1086373

This section contains:

Manual Backup of LMS 2.2 (CS / RME / Campus Manager / DFM)

Manually Backing Up IPM Data Separately

Automatic Backup From CS Installation

Manual Backup of LMS 2.2 (CS / RME / Campus Manager / DFM)

This section contains:

Manual Backup of LMS 2.2 From Command Line

Using the Common Services Administration GUI to Backup

Manual Backup of LMS 2.2 From Command Line

You can use backup.pl to backup data for LMS 2.2 (CS 2.2, RME 3.5.x , Campus Manager 3.3.x, and DFM 1.2.x) at the same time. If BKP is the directory in which you chose to backup your data, the data will be stored in the directories BKP/0, BKP/1, BKP/2, and so on, where BKP/n stores the data of the (n+1)th generation.

IPM data must be backed up with a separate script, RBackup.sh for Solaris or rbackup.exe for Windows.

For more information, see the "Manually Backing Up IPM Data Separately" section.

The syntax for backup.pl is:

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/backup.pl BackupDirectory [LogFile] [Num_Generations]

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\backup.pl BackupDirectory [LogFile] [Num_Generations]

Where:

BackupDirectory—is the directory that you want to be your backup directory. Make sure that the backup directory has enough space. Also, the backup directory can be created automatically by running backup.pl, if it does not exist.

[LogFile]—is the log file name.

[Num_Generations]—is the maximum number of backup generations to be kept in the backup directory.

Example (Solaris):

$NMSROOT/bin/perl $NMSROOT/bin/backup.pl /var/my_backup 
/var/tmp/backup.log 2

Using the Common Services Administration GUI to Backup

You can also backup LMS 2.2 data using the LMS 2.2 Server Administration GUI. To backup the data:


Step 1 Log in to LMS 2.2.

Step 2 From the LMS 2.2 home page, select Server Configuration > Administration > Database Management > Back Up Data Now.

Step 3 From the Backup Data Now dialog box, enter the path and name for the backup directory.

Step 4 Click Finish to start the backup.

We recommend that you backup your data in a different directory than the directory where the LMS 2.2 is located, for example, C:\backups.


Manually Backing Up IPM Data Separately

IPM data is not backed up while using the backup.pl script or automatically backed up during the CS3.0 in-place upgrade. IPM data must be backed up with a separate script RBackup.sh for Solaris or rbackup.exe for Windows.

Solaris:

Run RBackup.sh from the IPM 2.6 CD-ROM root directory.

This stops all IPM servers that are running and takes a backup of the database, the seed files, the environment variables and the version information. This data is compressed and a file called ipmBackup.tar is created in the IPM 2.5 root directory.

Windows:

Run rbackup.exe, from the IPM 2.6 CD-ROM root directory on the machine on which IPM 2.5 is installed.

This stops all IPM servers that are running and takes a backup of the database, the seed files, and the environment variables.

While running rbackup.exe, the default backup directory is the backup dir under the IPM Installed directory.

However the user can specify any directory. In such a case, the files will be backed up in the specified directory.

Automatic Backup From CS Installation

The CS 3.0 installer will prompt the user for a backup directory during local upgrade and automatically do a backup. However, the automatic backup facility will only back up data for CS, RME, Campus Manager and DFM. It will not back up the data for IPM.


Note You can use restorebackup.pl to restore the data for CS, RME, Campus Manager from the automatic backup later, but you can not use restorebackup.pl to restore the DFM data from the automatic backup.
DFM has its own way to restore data and has no integration with restorebackup.pl.


Automatic Backup on Solaris

For Solaris, the CS 3.0 installer will prompt the user for a backup directory during local upgrade. If DB_BKP is the directory given during the CS installation process, the location of the backup directory and structures are as follows:

DB_BKP/automaticbackup/cmfbackup

DB_BKP/automaticbackup/mcbackup

The DB_BKP/automaticbackup/cmfbackup directory and the DB_BKP/automaticbackup/mcbackup directory are used to store LMS 2.2 backup data and VMS backup data respectively.

VMS stands for VPN and Security Management Solutions, another solutions bundle available from Cisco. VMS applications are sometimes known as MC or Monitoring Center applications, hence the mc in the directory name.

If the DB_BKP/automaticbackup/mcbackup directory is empty, there are no VMS based applications installed in the machine.

To restore the LMS 2.2 data on LMS 2.5 Server, you should specify DB_BKP/automaticbackup/cmfbackup as the backup directory while restoring data.

Example 1

To restore the most recent version of LMS 2.2 backup data:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl -d 
DB_BKP/automaticbackup/cmfbackup 

Example 2

To restore the (n+1)th generation of LMS 2.2 backup data:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl -d 
DB_BKP/automaticbackup/cmfbackup -gen n

Example 3

To restore the 1st generation of LMS 2.2 backup data:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl -d 
DB_BKP/automaticbackup/cmfbackup -gen now

Example 4

To restore the 3rd generation of LMS 2.2 backup data:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl -d 
DB_BKP/automaticbackup/cmfbackup -gen 2

Automatic Backup on Windows

For Windows, the CS 3.0 in-place upgrade will prompt the user for a backup directory during local upgrade. If DB_BKP is the directory given during the CS installation process, the backup data will be available under DB_BKP.

Example 1

To restore the most recent of LMS 2.2 backup data:

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl -d DB_BKP

Example 2

To restore the (n+1)th generation of LMS 2.2 backup data:

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl -d DB_BKP -gen n

Example 3

To restore the 1st generation of LMS 2.2 backup data:

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl -d DB_BKP -gen now

Example 4

To restore the 3rd generation of LMS 2.2 backup data:

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl -d DB_BKP -gen 2

Upgrading to LMS 2.5

In order to upgrade from LMS 2.2 to LMS 2.5, you must first install Common Services (CS 3.0), then optionally upgrade one or more of the applications RME 4.0, Campus Manager 4.0, DFM 2.0 or IPM2.6.


Warning During the RME upgrade and data migration process, the script restorebackup.pl should be executed manually. This script converts RME 3.5.x data to the RME 4.0 format. It also completely restores CS, RME and Campus Manager data and restores device credentials data used by DFM. This data could have been backed up either automatically (during the CS 3.0 installation) or manually (prior to the CS 3.0 installation). Therefore, the execution of restorebackup.pl during the RME upgrade process will overwrite all CS and Campus Manager data and DFM device credentials data.


To upgrade LMS from 2.2 to 2.5:


Step 1 Upgrade the operating system (OS).


Warning For DFM users, if you plan to upgrade your operating system from Solaris 2.8 to Solaris 2.9, you need to run the DFM upgrade kit on Solaris 2.8 before migrating your operating system for the remote upgrade case. For details on how to obtain the DFM 2.0 upgrade kit, see the "Remote Migration Path for DFM 2.0" section.


Solaris:

Make sure that you upgrade to an OS supported by LMS 2.5, that is Solaris 2.8 or Solaris 2.9.

Windows:

Make sure that you upgrade to an OS supported by LMS 2.5, that is Windows 2000 Server, Windows 2000 Advanced Server, Windows 2000 professional, Windows 2003 Server Standard Edition, or Windows 2003 Server Enterprise Edition.

For details on OS platforms supported by LMS 2.5, see the "Overview" section.

Step 2 Upgrade to CS 3.0.

Solaris:

Insert CD; run setup.sh from the CD-ROM root directory, for example, /cdrom/cdrom0.

Windows:

Insert CD; run setup.exe from the CD-ROM root directory, for example, Z:\.

For more information, see the "Remote Migration Path for CS 3.0 / Campus Manager 4.0 / RME 4.0" section, "Local Migration Path for CS 3.0" section, and "Local Migration Path for Campus Manager 4.0" section.

Step 3 Upgrade to RME 4.0.


Warning At the end of RME installation, you will see the following warning messages. You may ignore it.


=======- Possible Warnings/Errors Encountered -=======

WARNING: Please install/upgrade all the required apps

WARNING: in the bundle and then run the migration scripts

[...]

==========================================================

If you have installed/upgraded RME 4.0 without having installed Campus Manager, or DFM, you will see the following warning message from running the migration script (restorebackup.pl). You may ignore it.

WARNING: There are mismatch between the applications installed in the machine and applications in the backup archive as listed above. This mismatch may lead to data inconsistency. Do you want to continue the Restore? (y-continue or n-quit, y/n)?y

Applications to be restored are............ : [Common Services] [Campus Manager] [Resource Manager Essentials] [Device Fault Manager]

Solaris:

Insert CD; run setup.sh from the CD-ROM root directory, for example, /cdrom/cdrom0.

Windows:

Insert CD; run setup.exe from the CD-ROM root directory, for example, Z:\.

For more information, see the "Remote Migration Path for CS 3.0 / Campus Manager 4.0 / RME 4.0" section and "Local Migration Path for RME 4.0" section.

Step 4 Upgrade to Campus Manager 4.0.

Solaris:

Insert CD; run setup.sh from the CD-ROM root directory, for example, /cdrom/cdrom0.

Windows:

Insert CD; run setup.exe from the CD-ROM root directory, for example, Z:\.

For more information, see the "Remote Migration Path for CS 3.0 / Campus Manager 4.0 / RME 4.0" section, "Local Migration Path for CS 3.0" section, and "Local Migration Path for Campus Manager 4.0" section.

Step 5 Upgrade to DFM 2.0.


Warning You can only do the DFM upgrade process after you have completed the RME upgrade process. Since running restorebackup.pl during the RME upgrade process overwrites the already existing LMS 2.5 data (for CS 3.0, Campus Manager 4.0, and DFM 2.0), you will lose the DCR (Device and Credential Repository) data which is created during the DFM upgrade process for the DFM devices.


Solaris:

Insert CD; run setup.sh from the CD-ROM root directory, for example, /cdrom/cdrom0.

Windows:

Insert CD; run setup.exe from the CD-ROM root directory, for example, Z:\.

For more information, see the "Remote Migration Path for DFM 2.0" section and "Local Migration Path for DFM 2.0" section.

Step 6 Upgrade to IPM 2.6.

Solaris:

Insert CD; run setup.sh from the CD-ROM root directory, for example, /cdrom/cdrom0.

Windows:

Insert CD; run setup.exe from the CD-ROM root directory, for example, Z:\.

For more information, see the "Remote Migration Path for IPM 2.6 on Solaris" section, "Remote Migration Path for IPM 2.6 on Windows" section, and "Local Migration Path for IPM 2.6" section.


Data Migration and Restore From Backup

The section contains:

Data Migration vs. Restore From Backup

Restore From Backup

Data Migration

Data Migration vs. Restore From Backup

The difference between Restore from Backup and Data Migration is:

Restore from Backup refers to data restore from one LMS system to another LMS system having the same version of LMS.

Data Migration refers to data restore from a previous version of LMS (such as LMS 2.2 with CS 2.2, RME 3.5.x, Campus Manager 3.3.x, DFM 1.2.x, and IPM 2.5) to the latest version of LMS (such as LMS 2.5 with CS 3.0, RME 4.0, Campus Manager 4.0, DFM 2.0, and IPM 2.6).

Restore From Backup

This refers to data being restored into an LMS 2.5 server by providing LMS 2.5 backup data.


Note Cross platform backup/restore is NOT supported. That is, you cannot backup or restore from a Solaris installation of LMS to a Windows installation and vice-versa.


You can use restorebackup.pl to restore the LMS 2.5 data for CS/RME/DFM/Campus Manager at one go.


Warning For DFM, restorebackup.pl can only be used to backup data from DFM 2.0 or higher versions and not from a DFM 1.2.x installation.


The Syntax for restorebackup.pl is as follows:

Solaris

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl [-t temporary_directory] [-gen generationNumber] -d BackupDirectory [-h]

Windows

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl [-t temporary_directory] [-gen generationNumber] -d BackupDirectory [-h]

For more information, see the "Syntax and Usage for restorebackup.pl" section.

Data Migration

Data Migration (From LMS 2.2 to LMS 2.5)

Data Migration from LMS 2.2 to 2.5 refers to migrating the preserved LMS 2.2 data (CS 2.2 / RME 3.5.x / Campus Manager 3.3.x) to the format used by LMS 2.5 (CS 3.0 / RME 4.0 / Campus Manager 4.0) for local upgrade (on the same machine), or remote upgrade (on a freshly installed LMS 2.5 system which can be either on the same machine or the other machine).

Note that in general we suggest upgrading LMS system using the remote upgrade method with two machines.

For more information, see the "Local Migration Path" section and "Remote Migration Path" section.

For RME, you must use restorebackup.pl explicitly to migrate the LMS 2.2 (RME 3.5.x) data to LMS 2.5 (RME 4.0) for both local upgrade and remote upgrade after the RME 4.0 installation completes.

For more information, see the "Local Migration Path for RME 4.0" section and "Remote Migration Path for CS 3.0 / Campus Manager 4.0 / RME 4.0" section.


Warning At the end of RME installation, you will see the following warning messages. You may ignore the message.


===========- Possible Warnings/Errors Encountered - ========

WARNING: Please install/upgrade all the required apps

WARNING: in the bundle and then run the migration scripts

[...]

==========================================================


Warning You need to run the migration script (restorebackup.pl) to complete the RME upgrade process. You will see the following warning message, if you have installed/upgraded CS 3.0 without having installed Campus Manager, DFM, or IPM. You may ignore it.


WARNING: There is a mismatch between the applications installed in the machine and applications in the backup archive as listed above. This mismatch may lead to data inconsistency. Do you want to continue the Restore? (y-continue or n-quit, y/n)?y

Applications to be restored are............ : [Common Services] [Campus Manager] [Resource Manager Essentials] [Device Fault Manager]

For Campus Manager, you need to run no explicit scripts if you are doing Campus Manager data migration for local upgrade (on the same machine). If you are doing Campus Manager data migration for the remote upgrade, you must use restorebackup.pl explicitly after the Campus Manager 4.0 installation completes.

For more information, see the "Local Migration Path for CS 3.0" section, "Local Migration Path for Campus Manager 4.0" section, and "Remote Migration Path for CS 3.0 / Campus Manager 4.0 / RME 4.0" section.

For DFM, you must run the DFM12x-DFM20-upgrade.pl command explicitly after the DFM 2.0 installation for both the local upgrade and the remote upgrade.

The restorebackup.pl command is not required, if you are doing DFM data migration for the local upgrade. For the DFM remote data migration, download the upgrade kit from Cisco.com, and use it after the DFM 2.0 installation.

For more information, see the "Local Migration Path for DFM 2.0" section and "Remote Migration Path for DFM 2.0" section.

IPM data must be migrated by running the command ipm upgrade if you are doing remote upgrade.

For more information, see the "Local Migration Path for IPM 2.6" section, "Remote Migration Path for IPM 2.6 on Solaris" section and "Remote Migration Path for IPM 2.6 on Windows" section.

Data Migration Scope

This section describes the scope of data migration for RME.

RME Data Migration Scope

Migrating RME data will transfer data into the RME 4.0 server by providing RME 3.5.x data backups (with their related IDUs) as inputs to the migration script.

Here are some points to note when you migrate RME data:

You can choose to migrate syslogs.

You can trigger inventory collection for devices being migrated.

On both platforms, migration is supported across different NMSROOT directories.

Cross platform data migration is NOT supported.

The following data is NOT migrated during the RME data migration process:

Inventory: Custom Inventory reports are NOT migrated.

Config Archive: the following data will NOT be migrated:

Processed data like .dfc/.dfr files.

Custom queries.

Config labels.

Out-of-sync data.

Config Editor: the following data will NOT be migrated:

Config files that are checked out.

Syslog: the following data will NOT be migrated:

User scripts associated with automated actions.

Jobs or job-related data.

SWIM: the following data will NOT be migrated:

Jobs or job-related data.

Local Migration Path

When you perform local data migration, LMS 2.5 (CS 3.0/RME 4.0/ Campus Manager 4.0/DFM2.0/IPM2.6) is installed on the same machine where the LMS 2.2 (CS 2.2/RME 3.5.x/Campus Manager3.3.x/DFM1.2.x/IPM2.5) is installed.

The data from LMS 2.2 (CS2.2/RME3.5.x/Campus Manager3.3.x/ DFM1.2.x/IPM2.5) are preserved. This data is backed up automatically as part of the installation process, and then converted to the format used by LMS 2.5 (CS3.0 / RME4.0 / Campus Manager 4.0 / DFM2.0 / IPM2.6).


Warning At the end of RME installation, you will see the following warning messages. You may ignore it.


=======- Possible Warnings/Errors Encountered - =======

WARNING: Please install/upgrade all the required apps

WARNING: in the bundle and then run the migration scripts

[...]

==========================================================


Warning If you have installed/upgraded CS 3.0 without having installed Campus Manager, or DFM, you will see the following warning message from running the migration script (restorebackup.pl). You may ignore it.


WARNING: There is a mismatch between the applications installed in the machine and applications in the backup archive as listed above. This mismatch may lead to data inconsistency. Do you want to continue the Restore? (y-continue or n-quit, y/n)?y

Applications to be restored are............ : [Common Services] [Campus Manager] [Resource Manager Essentials] [Device Fault Manager]

This section contains:

Local Migration Path for CS 3.0

Local Migration Path for Campus Manager 4.0

Local Migration Path for RME 4.0

Local Migration Path for DFM 2.0

Local Migration Path for IPM 2.6

Local Migration Path for CS 3.0

The following describes how to upgrade the running LMS 2.2 (with CS 2.2) to LMS 2.5 (with CS 3.0) on the same machine and to migrate data from LMS 2.2 to LMS 2.5 for CS 3.0. The procedures are applicable to both Solaris and Windows.


Step 1 Log in to the local LMS 2.2 machine.

Solaris

Log in as root.

Windows

Log in as a local administrator.

Step 2 Run the following command to backup data for LMS 2.2, where NMSROOT is the default installation directory (normally /opt/CSCOpx for Solaris, and C:\Program Files\CSCOpx for Windows):

Solaris

$NMSROOT/bin/perl $NMSROOT/bin/backup.pl BKP

Windows

%NMSROOT%\bin\perl %NMSROOT%\bin\backup.pl BKP

If BKP is backup directory, the data will be stored in the directories BKP/0, BKP/1, and BKP/2 etc., where BKP/n stores the data of the (n+1)th generation

Step 3 Upgrade LMS 2.2 (CS 2.2) to LMS 2.5 (CS 3.0).

To perform the upgrade, you will need to install CS 3.0 from the CD.


Note Upgrading to CS 3.0 forces you to backup data for all the LMS 2.2 installed applications except IPM.



Local Migration Path for Campus Manager 4.0

When you install LMS 2.5 (which includes Campus Manager 4.0) on the same machine where LMS 2.2 (which includes Campus Manager 3.3.x) is installed, the Campus Manager 3.3.x database is preserved.

When you install Campus Manager 4.0, certain data from the preserved Campus Manager 3.3.x database is converted to Campus Manager 4.0 format.

The Campus Manager 4.0 installer automatically updates Campus Manager 3.3.x program files. It also migrates the data from the Campus Manager 3.3.x format to the Campus Manager 4.0 format.

The following procedure describes how to upgrade the running LMS 2.2 (which includes Campus Manager 3.3.x) to LMS 2.5 (which includes Campus Manager 4.0) on the same machine and to migrate data from LMS 2.2 to LMS 2.5 for Campus Manager 4.0.

The procedures are applicable to both Solaris and Windows.


Step 1 Log in to the local LMS 2.2 machine.

Solaris:

Log in as root.

Windows:

Log in as a local administrator.

Step 2 Run the following command to backup data for LMS 2.2, where NMSROOT is the default installation directory (normally /opt/CSCOpx for Solaris, and C:\Program Files\CSCOpx for Windows):

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/backup.pl BKP

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\backup.pl BKP

If BKP is backup directory, the data will be stored in the directories BKP/0, BKP/1, and BKP/2 etc., where BKP/n stores the data of the (n+1)th generation.

Step 3 Upgrade LMS 2.2 (CS 2.2) to LMS 2.5 (CS 3.0) if you have not done it yet.

To perform the upgrade, you will need to install CS 3.0 from the CD.

Note that upgrading to CS 3.0 forces you to backup data for all the LMS 2.2 installed applications except IPM.

Step 4 Upgrade from Campus Manager 3.3.x to Campus Manager 4.0.

To perform the upgrade, install the application (Campus Manager 4.0) from the CD.


Local Migration Path for RME 4.0

The following procedure describes how to upgrade the running LMS 2.2 (CS 2.2/RME 3.5.x) to LMS 2.5 (CS 3.0/RME 4.0), and perform data migration from the format of LMS 2.2 to LMS2.5 on the same machine for CS/RME/Campus Manager, and it is applied to both Solaris and Windows.


Step 1 Log in to the local LMS 2.2 machine where the application (RME 3.5.x) is installed.

Solaris:

Log in as root.

Windows:

Log in as a local administrator.

Step 2 Run the following command to backup data for LMS 2.2, where NMSROOT is the default installation directory (normally /opt/CSCOpx for Solaris, and C:\Program Files\CSCOpx for Windows):

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/backup.pl BKP

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\backup.pl BKP

If BKP is backup directory, the data will be stored in the directories BKP/0, BKP/1, and BKP/2 etc., where BKP/n stores the data of the (n+1)th generation.

Step 3 Upgrade LMS 2.2 (CS 2.2) to LMS 2.5 (CS 3.0) if you have not done it yet.

To perform the upgrade, you need to install CS 3.0 from the CD.


Note Upgrading to CS 3.0 forces you to backup data for all the LMS 2.2 installed applications except IPM.


Step 4 Upgrade from RME 3.5.x to RME 4.0.

To perform the upgrade, you will need to install the application RME 4.0 from the CD.


Note The upgrade process collects inputs required for installation, uninstalls RME 3.4.x or RME 3.5.x, and installs RME 4.0. Uninstalling RME 3.5.x will cause uninstall of dependent applications like ACLM,
VPN Monitor, etc.


Step 5 Stop the LMS system by entering:

Solaris:

/etc/init.d/dmgtd stop

Windows:

net stop crmdmgtd

Step 6 Restore data from backup of LMS 2.2 (RME 3.5.x) by entering:

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl [-t temporary_directory] [-gen generationNumber] -d BackupDirectory [-h]

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl [-t temporary_directory] [-gen generationNumber] -d BackupDirectory [-h]

For more information, see the "Syntax and Usage for restorebackup.pl" section.

Step 7 To restore the most recent version, enter:

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl -d BackupDirectory

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl -d BackupDirectory

Example (Windows):

%NMSROOT%\bin\restorebackup.pl -d D:\var\backup

Step 8 Restore data from the forced auto backup during the CS upgrade process, by entering the following command:

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl -d DB_BKP/automaticbackup/cmfbackup -gen now

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl -d DB_BKP -gen now

Where, DB_BKP is the specified backup directory name provided during the CS installation.

Step 9 Examine the log file in the following location to verify that the database was restored.

Solaris:

The location is /var/adm/CSCOpx/log/restorebackup.log.

Windows:

The location is %NMSROOT%\log\restorebackup.log.

Step 10 Start the LMS system by entering:

Solaris:

/etc/init.d/dmgtd start

Windows:

net start crmdmgtd


Local Migration Path for DFM 2.0

The following procedure describes how to upgrade the running LMS 2.2 to LMS 2.5, and perform data migration from the format of LMS 2.2 to LMS 2.5 on the same machine for DFM, and it is applicable to both Solaris and Windows.


Note Pathnames provided in the steps below are based on Solaris. For Windows the pathnames will be the same, but will use %NMSROOT%, and backslashes ('\') for path delimiters.



Step 1 Upgrade LMS 2.2 (CS 2.2) to LMS 2.5 (CS 3.0) if you have not done it yet.

To perform the upgrade, you will need to install CS 3.0 from the CD.


Note Upgrading to CS 3.0 forces you to backup data for all the LMS 2.2 installed applications except IPM.


Step 2 Upgrade from DFM 1.2.x to DFM 2.0.

To perform the upgrade, install DFM 2.0 from the CD.

The upgrade proceeds without displaying any more questions.

The following upgrade operation is performed transparently during the installation of DFM2.0):

The DFM1.2.x inventory is backed up in the file $NMSROOT/objects/smarts/conf/ICseed.txt

The DFM1.x polling and threshold setting is backed up in $NMSROOT/objects/smarts/conf/ICptm.xml

Managed/unmanaged state of DFM1.x components is backed up in $NMSROOT/objects/smarts/conf/ICinventory.txt

Step 3 Migrate DFM 1.2.x data to DFM 2.0 data format.

After the installation of DFM2.0, when the DFM2.0 system comes up, you need to explicitly run the following script to complete the upgrade of DFM 1.2.x data into DFM2.0:

$NMSROOT/bin/perl $NMSROOT/bin/DFM12x-DFM20-upgrade.pl

where $NMSROOT is the default installation directory, normally /opt/CSCOpx for Solaris, and C:\Program Files\CSCOpx for Windows.

The script DFM12x-DFM20-upgrade.pl automatically does all of the following:

Imports the seedfile generated from DFM 1.2.x into DCR.

Imports devices from DCR into DFM 2.0 and monitors device import status.

Device import can take a maximum of three hours, depending on the number of devices in your inventory.

Applies the managed/unmanaged state of the devices/device components obtained from DFM 1.2.x during the upgrade.

Applies new polling and threshold settings to the devices.

Step 4 Verify that the DfmServer process is running.

To verify this, log on to the CiscoWorks Homepage as the administrator and select Common Services > Server > Admin > Processes.

Look for the DfmServer process entry.


Local Migration Path for IPM 2.6

During local migration of IPM 2.6, the IPM database, the HTML reports and seed files from IPM 2.5 are preserved. This data is backed up automatically as part of the installation process and then converted to the format used by IPM 2.6.

The following procedure describes how to upgrade the running IPM 2.5 to IPM 2.6, and perform data migration to LMS 2.5 on the same machine for IPM. It is applicable to both Solaris and Windows platforms.


Step 1 Make sure that you have upgraded the CS 2.2 system to CS 3.0 system on the running machine.

Step 2 Upgrade from IPM 2.5 to IPM 2.6.

To perform the upgrade, install IPM 2.6 from the CD.

IPM local upgrade (IPM 2.5 to IPM 2.6) takes care of the IPM data migration like CS/Campus Manager.


Remote Migration Path

Remote Migration of LMS 2.5 refers to the process of migrating data from a machine on which LMS 2.2 is installed to another machine on which LMS 2.5 is installed. Data from LMS 2.2 are preserved.

This data is backed up automatically as part of the installation process, and then converted to the format used by LMS 2.5. The remote migration path is the suggested method to upgrade your LMS system.

The remote upgrade (LMS2.2 to LMS2.5) can be done for CS/Campus Manager/RME at one go.

The guidelines described in the section are applicable to both Solaris and Windows.

This section contains:

Remote Migration Path for CS 3.0 / Campus Manager 4.0 / RME 4.0

Remote Migration Path for DFM 2.0

Remote Migration Path for IPM 2.6 on Solaris

Remote Migration Path for IPM 2.6 on Windows

Remote Migration Path for CS 3.0 / Campus Manager 4.0 / RME 4.0

If you want to perform remote upgrade (LMS 2.2 to LMS 2.5) against all of the applications (CS/Campus Manager/RME), you just need to run the following remote upgrade procedures ONCE instead of multiple times for CS, Campus Manager, and RME applications, separately.

To do a remote migration:


Step 1 Log in to the local LMS 2.2 machine where the application (for example, CS2.2, Campus Manager 3.3.x, or RME 3.5.x) is installed.

Solaris:

Log in as root.

Windows:

Log in as a local administrator.

Step 2 Run the following command to backup data for LMS 2.2, where NMSROOT is the default installation directory (normally /opt/CSCOpx for Solaris, and C:\Program Files\CSCOpx for Windows):

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/backup.pl BKP

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\backup.pl BKP

If BKP is backup directory, the data will be stored in the directories BKP/0, BKP/1, and BKP/2 etc., where BKP/n stores the data of the (n+1)th generation

Step 3 Copy the backup data that you created in Step 2 to a temporary location on the LMS 2.5 machine where the application (for example, CS 3.0, Campus Manager 4.0, or RME 4.0) is installed.

Step 4 Log in to the remote LMS 2.5 machine.


Note The application backup data and the applications on the remote machine is not having one-to-one correspondence, restorebackup will display a warning message. You may ignore it.


Solaris:

Log in as root.

Windows:

Log in as a local administrator.

Step 5 Stop the LMS system by entering:

Solaris:

/etc/init.d/dmgtd stop

Windows:

net stop crmdmgtd

Step 6 Migrate the LMS 2.2 data to LMS 2.5 by entering:

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl [-t temporary directory] [-gen generationNumber] -d BackupDirectory [-h]

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl [-t temporary directory] [-gen generationNumber] -d BackupDirectory [-h]

where NMSROOT is the CiscoWorks installation directory.

Step 7 To restore the most recent version, enter the following command:

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl -d BackupDirectory

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl -d BackupDirectory

Example (Windows):

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl -d D:\var\backup

Step 8 Examine the log file in the following location to verify that the database has been restored.

Solaris:

The location is /var/adm/CSCOpx/log/restorebackup.log.

Windows:

The location is %NMSROOT%\log\restorebackup.log.

Step 9 Start the LMS system by entering:

Solaris:

/etc/init.d/dmgtd start

Windows:

net start crmdmgtd


Remote Migration Path for DFM 2.0

The following describes how to backup LMS 2.2 (DFM 1.2.x) data on one machine and migrate this data to a freshly installed LMS 2.5 (DFM2.0) machine. The LMS 2.5 installation can either be on the same machine or the other machine. The guidelines are applicable to both Solaris and Windows platforms.


Warning For DFM users, if you plan to upgrade your operating system from Solaris 2.8 to Solaris 2.9, you need to run the DFMrestore.pl script (in the DFM 2.0 upgrade kit) on Solaris 2.8 (before migrating your operating system) for the remote upgrade.



Step 1 Log in to the local LMS 2.2 machine where DFM 1.2.x is installed.

Solaris:

Log in as root.

Windows:

Log in as a local administrator.

Step 2 Run the following command to backup data for LMS 2.2, where NMSROOT is the default installation directory (normally /opt/CSCOpx for Solaris, and C:\Program Files\CSCOpx for Windows):

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/backup.pl BKP

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\backup.pl BKP

If BKP is backup directory, the data will be stored in the directories BKP/0, BKP/1, and BKP/2 etc., where BKP/n stores the data of the (n+1)th generation.

Step 3 Locate the DFM.rps file.

Solaris:

Untar the file filebackup.tar which is located in DB_BKP/0/dfm. The DFM.rps file is located at /opt/CSCOpx/objects/smarts/repos/icf

Windows:

Untar the file filebackup.tar which is located in DB_BKP\0\dfm.

This DFM.rps file is located at:

DB_BKP\0\dfm\%NMSROOT%\objects\smarts\repos\icf

where,

DB_BKP is the backup directory specified when running the backup.pl command.

Example (Windows):

If you backup LMS 2.2 data in the directory C:\backup, the DFM.rps file will be stored in the following location:

C:\backup\0\dfm\progra~1\CSCOpx\objects\smarts\repos\icf

Step 4 Copy the DFM.rps file to a temporary location on a machine with DFM 2.0 installation.

You can obtain the DFM.rps file for DFM 1.2.x from the location you referenced above in step 3 if you executed backup.pl.

You also can obtain the DFM.rps file from the DFM1.2.x installation directory as below:

Solaris:

$NMSROOT/objects/smarts/repos/icf

Windows:

%NMSROOT%\objects\smarts\repos\icf

where NMSROOT is the default installation directory (normally /opt/CSCOpx for Solaris, and C:\Program Files\CSCOpx for Windows).

Step 5 Log in to the LMS 2.5 machine (with DFM 2.0 installed) as root for Solaris, and as a local administrator for Windows.

Step 6 Download the Upgrade Kit patch from Cisco.com.

Make sure you have adequate free space, then, from the DFM download page at

http://www.cisco.com/cgi-bin/tablebuild.pl/cw2000-dfm, click the:

cw-dfm-20UpgradeKit-sol.tar.Z link for Solaris,

or

cw-dfm-20UpgradeKit-win.zip for Windows,

and follow the instructions to download the file to a temporary working area of your server (such as /tmp).

Step 7 Extract or unzip the patch from the directory in which the download file resides.

Solaris:

Uncompress the patch and extract the script DFMRestore.pl file into the local directory:

a. Make sure you have adequate free space to store the uncompressed patch, then run the following command to uncompress the patch in the temporary working area.

b. Uncompress cw-dfm-20UpgradeKit-sol.tar.Z.

c. Extract the files from the uncompressed patch into the local directory using the tar command tar xvf cw-dfm-20UpgradeKit-sol.tar.

Windows:

Unzip the patch into a local directory (such as C:\), and get the script DFMRestore.pl file into the local directory.

Step 8 Upgrade the DFM.rps file information from DFM 1.2.x into DFM 2.0.


Note Make sure that you change your working directory to the smarts subdirectory under the directory in which you extracted the patch before running the DFMRestore.pl command.


From the directory EXTRACT_DIR/smarts run the following command:

$NMSROOT/bin/perl DFMRestore.pl -n $NMSROOT -o DFM_RPS_DIR

where,

NMSROOT—Environment variable containing full pathname of DFM 2.0 installation directory (normally /opt/CSCOpx).

EXTRACT_DIR—Directory into which you extracted the patch (using tar)

DFM_RPS_DIR—Location of your copy of the DFM.rps file for DFM 1.2.x (full pathname).

For DFM 1.2.x, this file is located in $NMSROOT/objects/smarts/repos/icf/DFM.rps.

If you plan to use a copy of this file that was created during a backup, the file will be located in the backup directory you specified when using CiscoWorks Common Services 2.2.

This creates the necessary DFM 1.2.x export text files (ICseed.txt, ICinventory.txt, and ICptm.xml) and moves them to the existing DFM 2.0 installation directory under $NMSROOT/objects/smarts/conf for Solaris and %NMSROOT%\objects\smarts\conf for Windows.

Example (Solaris):

(If the patch is extracted in the /tmp directory.)

cd  /tmp/smarts
/opt/CSCOpx/bin/perl DFMRestore.pl -n /opt/CSCOpx -o  
/opt/CSCOpx/objects/smarts/repos/icf

Example (Windows):

(If the patch is extracted in C:\ directory)

cd  C:\smarts
C:\Progra~1\CSCOpx\bin\perl  DFMRestore.pl -n C:\Progra~1\CSCOpx -o 
C:\backup\0\dfm\Progra~1\CSCOpx\objects\smarts\repos\icf

The system is now configured to use the standard upgrade script (as documented in the installation guides).

Step 9 From the new DFM 2.0 installation, verify that the DfmServer process is running by selecting Common Services > Server > Reports > Process Status.

Step 10 Migrate DFM 1.2.x data to DFM 2.0 data format.

After the installation of DFM2.0, when the DFM2.0 system comes up, you need to explicitly run the following script to complete the upgrade of DFM 1.2.x data into DFM2.0:

$NMSROOT/bin/perl $NMSROOT/bin/DFM12x-DFM20-upgrade.pl

where $NMSROOT is the default installation directory, normally /opt/CSCOpx for Solaris, and C:\Program Files\CSCOpx for Windows.

The script DFM12x-DFM20-upgrade.pl automatically does all of the following:

Imports the seedfile generated from DFM 1.2.x into DCR.

Imports devices from DCR into DFM 2.0 and monitors device import status.

Device import can take a maximum of three hours, depending on the number of devices in your inventory.

Applies the managed/unmanaged state of the devices/device components obtained from DFM 1.2.x during the upgrade.

Applies new polling and threshold settings to the devices.

Step 11 Refer to the document "Installing and Setting Up Device Fault Manager on Windows" on cisco.com for information on post-upgrade tasks. Go to the URL:

http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/
cw2000/dfm/index.htm


Remote Migration Path for IPM 2.6 on Solaris

When you want to migrate IPM 2.5 data from one machine to IPM 2.6 on the other machine on the same network, you need to do a remote upgrade.


Note When you do an upgrade, existing IPM 2.6 data is overwritten.


To do a remote upgrade of IPM 2.6:


Step 1 Mount the IPM 2.6 CD-ROM on the machine on which IPM 2.5 is installed.

Step 2 Run RBackup.sh from the CD-ROM root directory.

This stops all IPM servers that are running and takes a backup of the database, the seed files, the environment variables, and the version information.

While executing RBackup.sh, the default backup directory is /opt. The user can specify any directory.

The data is compressed and ipmBackup.tar file is created in the specified directory.

Step 3 Install IPM 2.6 on the remote machine.

Step 4 Copy ipmBackup.tar to the IPM 2.6 root directory.

Before copying the file, make sure that IPM 2.6 has been installed on that machine.

Step 5 Change your working directory to the bin directory of the IPM server.

Step 6 Make sure that the License Server process (called LicenseServer) is up and running.

Step 7 Run ipm upgrade at the command prompt.


Remote Migration Path for IPM 2.6 on Windows

When you migrate IPM 2.5 data from one machine to IPM 2.6 on the other machine on the same network, you need to do a remote upgrade. Note that when you do an upgrade, existing IPM 2.6 data is overwritten.

To do a remote upgrade:


Step 1 Run rbackup.exe, from the IPM 2.6 CD-ROM root directory, on the machine on which IPM 2.5 is installed.

This stops all IPM servers that are running and takes a backup of the database, the seed files, and the environment variables.

While executing rbackup.exe, the default backup directory is the backup directory under the IPM installation root directory. However, you can specify any directory when running this command. In that case, the files will be backed up in the specified directory.


Note When using a custom directory some of the files does not have proper permissions so later when moving these files to remote machine, the permissions of the files need to be manually modified.


Step 2 Change your working directory to the directory where you have installed IPM 2.5 and change to the backup directory.

Step 3 Install IPM 2.6 on the remote machine.

Step 4 Copy the entire contents in this directory to the backup directory under the directory where you have installed IPM 2.6.

Step 5 Change your working directory to the bin directory of the IPM server.

Step 6 Make sure that the License Server process (called LicenseServer) is up and running.

Step 7 Run ipm upgrade at the command prompt.

The upgrade from IPM 2.5 to IPM 2.6 is complete.


Troubleshooting Errors From Data Migration

Make sure that the server configuration and OS versions are compatible with LMS 2.5. Also, make sure the server has enough space to do the DB backup and restore.

Check migration logs. The logs (migration.log, restorebackup.log, rme_base.log) are available under:

Solaris

/var/adm/CSCOpx/log

Windows

%NMSROOT%\log

Note that time taken to collect inventory is directly proportional to the number of devices and the network response time

There is another way of migrating data, where inventory collection can be skipped during migration (especially if there are many devices in the backup) Inventory can be triggered from the UI after the data migration of other apps have completed.

If you run into problems during the data migration process, you can do the following to clean up the temporary files and go back to the initial state:

a) Stop the LMS system by entering:

/etc/init.d/dmgtd stop

b) Run the following two commands:

/opt/CSCOpx/bin/perl
/opt/CSCOpx/objects/db/conf/configureDb.pl action=unreg dsn=rme dmprefix=Essentials

/opt/CSCOpx/bin/perl
/opt/CSCOpx/objects/db/conf/configureDb.pl action=uninstall dsn=rme

c) rm -fr /opt/CSCOpx/tempBackupData

This section contains:

Errors From CS Data Migration

Errors From RME Data Migration

Errors From DFM Data Migration

Errors From CS Data Migration

Enabling CAM (Core Admin Module) debugging:

CAM debugging can be enabled by running:

/opt/CSCOpx/MDC/bin/ccraccess -updateLog Core cam DEBUG

Disabling CAM debugging:

CAM debugging can be disabled by running:

/opt/CSCOpx/MDC/bin/ccraccess -updateLog Core cam WARN

Daemon Manager restart is necessary.

CAM debug details are logged at:

/opt/CSCOpx/MDC/log/core-MM-DD-YYYY.log

Sybase version supported:

Solaris: 9.0.0.1364

You can get the Sybase version by running $NMSROOT/objects/db/bin/dbversion

Windows: 9.0.0.1383

You can get the Sybase version by running %NMSROOT%\objects\db\win32\dbeng9 -v

Collecting server information:

Select Common Services > Server > Admin > Collect Server Information from the LMS Home Page to collect the server information.

This allows you to quickly collect all-in-one information about the state of the system so that such a report can be sent to TAC for troubleshooting. The report provides information about System configuration, environment settings, application configuration details, process status, and product log files.

SelfTest tool:

You can select Common Services > Server > Admin > SelfTest from the LMS Home Page to invoke the SelfTest tool.

The SelfTest tool checks the integrity and health of the system for some of the Common Services components.

This tool is useful to debug issues of corrupted files and issues related to failure of some basic components. It runs perl scripts that provide outputs that indicate whether the test has passed or failed.

Errors From RME Data Migration

Make sure that the server configuration and OS version are compatible with LMS 2.5. Also, make sure the server has enough space to do the DB backup and restore.

Check migration logs. The logs (migration.log, restorebackup.log, rme_base.log) are available under

Solaris

/var/adm/CSCOpx/log

Windows

%NMSROOT%\log

If you get the OutOfMemoryError message, you can try to increase the available JVM (Java Virtual Machine) heap size to work around the problem.

The JVM heap size can be configured in:

Solaris:

$NMSROOT/MDC/tomcat/webapps/rme/WEB-INF/classes/com/Cisco/nm/
rmeng/cli/framework/heap.properties

Windows:

%NMSROOT%\MDC\tomcat\webapps\rme\WEB-INF\classes\com\cisco\
nm\rmeng\cli\framework\heap.properties

The default min and max settings are 128 MB and 512 MB respectively. You can increase the JVM heap size as much as possible (up to available RAM) However, do not exceed real system memory or your application will page and crawl to a halt.

Time taken to collect inventory is directly proportional to the number of devices and the network response time.

There is another way of migrating data, where inventory collection can be skipped during migration (especially if there are many devices in the backup) You can trigger the Inventory from the UI after you complete the data migration for other applications.

Rarely, RME Migration may fail with a message in the logfile migration.log that DCRServer could not be started. You can work around this problem by running the following command before executing migration:

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/dbRestoreOrig.pl dsn=cmf dmprefix=Cmf opt=Y

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\dbRestoreOrig.pl dsn=cmf dmprefix=Cmf opt=Y

On Windows, you must first install Common Services 2.2 Service Pack 3.0 on your LMS 2.2 server before you begin the upgrade, otherwise the upgrade will fail. For more information on this issue, see the Critical Upgrade section in the Release Notes for Common Services 3.0. The Release Notes are at:

http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/
cw2000_d/comser30/relnotes/cwcs_rnw.htm#wp1086373

Errors From DFM Data Migration

Check logs. The relevant log files are:

Solaris

/var/tmp/ciscoinstall.log

/var/tmp/ciscouninstall.log

/var/adm/CSCopx/log/dbbackup.log

Windows

C:\Ciscoworks_setupno.log

%NMSROOT%\log\dbbackup.log

Check the contents of the backup data file filebackup.tar. Note that the following is the list of DFM related files/databases that are backed up during the backup into the user-defined backup directory:

Contents of the following folders are backed up as filebackup.tar under specified backup directory.

Solaris:

$NMSROOT/objects/smarts/conf

$NMSROOT/objects/smarts/local/repos

$NMSROOT/objects/smarts/local/logs

$NMSROOT/objects/smarts/local/conf

$NMSROOT/setup/dfm.info

Windows:

%NMSROOT%\objects\smarts\conf

%NMSROOT%\objects\smarts\local\repos

%NMSROOT%\objects\smarts\local\logs

%NMSROOT%\objects\smarts\local\conf

%NMSROOT%\setup\dfm.info

The following database files along with corresponding database transaction log files are backed up:

dfmEpm.db

dfmInv.db

dfmFh.db

Solaris

/opt/CSCOpx/databases/dfmEpm/dfmEpm.db

/opt/CSCOpx/databases/dfmInv/dfmInv.db

/opt/CSCOpx/databases/dfmFh/dfmFh.db

Windows

%NMSROOT%\databases\dfmEpm\dfmEpm.db

%NMSROOT%\databases\dfmInv\dfmInv.db

%NMSROOT%\databases\dfmFh\dfmFh.db


Note dfmEpm.db—contains the data of the DFM Event Promulgation Module
dfmInv.db—contains the data of the DFM Inventory
dfmFh.db—contains the data of the DFM Fault History


Guidelines for Post-Upgrade Activities

This section contains:

Guidelines for DFM 2.0 Post-Upgrade Activities

Guidelines for CS 3.0 Post-Upgrade Activities

Guidelines for DFM 2.0 Post-Upgrade Activities

After the upgrade script completes, DFM discovers devices and updates its managed inventory. DFM might take some time to complete this task. Afterward, you should do the following:

Familiarize yourself with new device management procedures; see Installation and Setup guides for DFM, "Performing Device Management" section in Chapter 4, "Getting Started".

Verify discovery status; see Installation and Setup guides for DFM, "Verifying Devices Added to DFM" section in Chapter 4, "Getting Started".

Complete basic configuration steps; see Installation and Setup guides for DFM, "Configuring SNMP Trap Receiving and Forwarding" section in Chapter 4, "Getting Started".

Start using DFM to monitor the network; see Installation and Setup guides for DFM, "Viewing Alerts" section, and "What Next?" section in Chapter 4, "Getting Started".

If you plan to use HPOV or NetView adapters on a remote system with Device Fault Manager 2.0 on a local system, perform these steps:


Step 1 Make sure the system running DFM is registered with DNS.

Step 2 Upgrade all remote adapters as described in Installation and Setup guide for DFM, Section "Installing and Upgrading HPOV-NetView Adapters".


Guidelines for CS 3.0 Post-Upgrade Activities

This section contains:

Pre-CS 3.0 AAA Methods

CS 3.0 AAA Methods

Pre-CS 3.0 AAA Methods

Before CS 3.0, the CiscoWorks server supported two types of authentication methods: one method used an external PAM (Pluggable Authentication Module) and the other was the CiscoWorks local method.

Before CS 3.0, both CiscoSecure ACS (Access Control Server) and third party AAA (Authentication, Authorization, Accounting) servers were treated as external PAMs.

Before CS 3.0, if you selected an external authentication method using a PAM, the CiscoWorks server would only do authentication but not authorization against either the CiscoSecure ACS or the third party AAA server that you selected.

Note that regardless of the authentication method, authorization would still be done by the CiscoWorks server before CS 3.0.

If you select the CiscoWorks local authentication method, both authentication and authorization were done by the CiscoWorks server before CS 3.0.

CS 3.0 AAA Methods

CS 3.0 supports two AAA modes, ACS mode and non-ACS mode.

ACS Mode

If you select ACS mode, the CS 3.0 server uses both authentication and authorization from the CiscoSecure ACS server. Since authorization is based on the roles of the user in the CS 3.0 server, note the following:

CS 3.0 only supports ACS 3.2, 3.2.3, and 3.3.2

CS 3.0 no longer supports Kerberos PAM

We recommend that you install the Admin HTTPS PSIRT patch (on ACS 3.2.3). The patch is available at: http://www.cisco.com/kobayashi/sw-center/ciscosecure/cs-acs.shtml

AAA is done by sending a query to ACS using TACACS+ protocol

To configure the CiscoWorks server to use CiscoSecure ACS:

You need ACS Administrator username and password

You need to add the CiscoWorks server as a AAA client (in ACS)

You need to configure secret key to be used (at AAA Mode setup in CS and in ACS)

You must ensure that the login user in CiscoWorks must be a valid user in ACS

Non-ACS Mode

CS 3.0 supports two types of non-ACS modes: CiscoWorks local and non-CiscoWorks local.

By default, CS 3.0 uses CiscoWorks server authentication (CiscoWorks local) to authenticate users and authorize them to access CiscoWorks applications. If you select CiscoWorks local mode, CS 3.0 will do the authentication and authorization.

However, you can choose to use a third party AAA server (non-CiscoWorks local) to do authentication (not authorization). If you choose to use a third party AAA server, you can only use it for authentication, not authorization.

Modifying User Information in CiscoWorks Local Mode

The information for parsing and verifying the password / role of a user are present in the cwpass file. This file is located at:

Solaris:

$NMSROOT/lib/classpath/com/cisco/nm/cmf/servlet

Windows:

%NMSROOT%\lib\classpath\com\cisco\nm\cmf\servlet

Resetting the Login Module

You can run the following commands to reset the Login Module:


Step 1 Stop the LMS system by entering:

Solaris:

/etc/init.d/dmgtd stop

Windows:

net stop crmdmgtd

Step 2 Run the following script:

Solaris:

$NMSROOT/bin/perl ResetLoginModule.pl

Windows:

%NMSROOT%\bin\perl ResetLoginModule.pl

Step 3 Start the LMS system by entering:

Solaris:

/etc/init.d/dmgtd start

Windows:

net start crmdmgtd


Appendices

This section contains:

Syntax and Usage for restorebackup.pl

Syntax and Usage for backup.pl

Checking and Fixing Solaris Package Errors

Syntax and Usage for restorebackup.pl

All of the services or processes should be stopped before running restorebackup.pl.

The Syntax for restorebackup.pl is as follows:

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl [-t temporary_directory] [-gen generationNumber] -d BackupDirectory [-h]

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl [-t temporary_directory] [-gen generationNumber] -d BackupDirectory [-h]

Where,

NMSROOT—Environment variable containing full pathname of Common Services installation directory (normally /opt/CSCOpx).

[-t temporary_directory]—(Optional) This is the directory/folder used by the restore program to store its temporary files. By default this directory is $NMSROOT/tempBackupData. You can customize this by specifying your own temporary directory to avoid overloading NMSROOT.

[-gen generationNumber]—(Optional) By default, this is the latest generation. If generations 1 through 5 exist, then 5 will be the latest.

-d BackupDirectory—(Required) Which backup directory to use.

[-h]—(Optional) Provides help. When used with -d BackupDirectory, shows correct syntax along with available suites and generations.

Example 1 (Solaris)

Restoring the latest version of data:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl -d DB_BKP -gen now

Example 2 (Solaris)

Restoring the 12th generation of data:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl -d DB_BKP -gen 11

where DB_BKP is the backup directory, into which you have used backup.pl to back up data for Campus, RME, and DFM at one go.

The data will be stored in the directories DB_BKP/0, DB_BKP/1, and DB_BKP/2 etc., where DB_BKP/n stores the data of the (n+1)th generation.

Example 3

Restoring data from the forced auto backup during the CS upgrade process:

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl -d 
DB_BKP/automaticbackup/cmfbackup -gen now

where DB_BKP is the backup directory provided during the CS installation.

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\restorebackup.pl -d DB_BKP -gen now

where DB_BKP is the backup directory provided during the CS installation.

Syntax and Usage for backup.pl

The syntax for backup.pl is as follows:

Solaris:

$NMSROOT/bin/perl $NMSROOT/bin/backup.pl BackupDirectory

Windows:

%NMSROOT%\bin\perl %NMSROOT%\bin\backup.pl BackupDirectory

Where:

NMSROOT is the environment variable containing full pathname of Common Services installation directory (normally /opt/CSCOpx).

BackupDirectory is the backup directory to use.

DB_BKP is the backup directory, into which you have used backup.pl to back up data for Campus, RME, and DFM at the same time.

The data will be stored in the directories DB_BKP/0, DB_BKP/1, and DB_BKP/2 etc., where DB_BKP/n stores the data of the (n+1)th generation. If generations 0 through 5 exist, then 5 will be the latest.


Note On LMS 2.1, the backup directory must exist before running backup.pl, otherwise you will see an error.


Example (Solaris):

Backing up data to the directory /backup

$NMSROOT/bin/perl $NMSROOT/bin/backup.pl /backup

Checking and Fixing Solaris Package Errors

Before CS 3.0 upgrade, make sure that you run the script check_pkg_errors.sh to check and fix any possible Solaris package errors.

This script:

Removes servlets.properties_backup to fix an internal error during installation.

Runs pkgchk on Solaris packages whose names have a prefix CSCO and whose installation base is $NMSROOT.

Reports any package verification errors, if found.

Logs all its output in to /var/tmp/ciscoinstall.log for debugging purposes.

Provides an option -c to correct any package verification errors if found.

This means that if you ran the script without -c option, check_pkg_errors.sh will list only the errors if there are any. In such a case, you have to run the script again with -c to fix the package check errors.

Related Documentation

Installation and Setup Guide for CiscoWorks Common Services 3.0 (Includes CiscoView) on Solaris.

Installation and Setup Guide for CiscoWorks Common Services 3.0 (Includes CiscoView) on Windows.

Installation and Setup Guide for Campus Manager 4.0 on Solaris.

Installation and Setup Guide for Campus Manager 4.0 on Windows.

Installation and Setup Guide for Resource Manager Essentials 4.0 on Solaris.

Installation and Setup Guide for Resource Manager Essentials 4.0 on Windows.

Installing and Setting Up Device Fault Manager on Solaris.

Installing and Setting Up Device Fault Manager on Windows.

CiscoWorks Internetwork Performance Monitor 2.6

Obtaining Documentation

Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several ways to obtain technical assistance and other technical resources. These sections explain how to obtain technical information from Cisco Systems.

Cisco.com

You can access the most current Cisco documentation at this URL:

http://www.cisco.com/univercd/home/home.htm

You can access the Cisco website at this URL:

http://www.cisco.com

You can access international Cisco websites at this URL:

http://www.cisco.com/public/countries_languages.shtml

Documentation DVD

Cisco documentation and additional literature are available in a Documentation DVD package, which may have shipped with your product. The Documentation DVD is updated regularly and may be more current than printed documentation. The Documentation DVD package is available as a single unit.

Registered Cisco.com users (Cisco direct customers) can order a Cisco Documentation DVD (product number DOC-DOCDVD=) from the Ordering tool or Cisco Marketplace.

Cisco Ordering tool:

http://www.cisco.com/en/US/partner/ordering/

Cisco Marketplace:

http://www.cisco.com/go/marketplace/

Ordering Documentation

You can find instructions for ordering documentation at this URL:

http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm

You can order Cisco documentation in these ways:

Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from the Ordering tool:

http://www.cisco.com/en/US/partner/ordering/

Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 1 800 553-NETS (6387).

Documentation Feedback

You can send comments about technical documentation to bug-doc@cisco.com.

You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address:

Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883

We appreciate your comments.

Cisco Product Security Overview

Cisco provides a free online Security Vulnerability Policy portal at this URL:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

From this site, you can perform these tasks:

Report security vulnerabilities in Cisco products.

Obtain assistance with security incidents that involve Cisco products.

Register to receive security information from Cisco.

A current list of security advisories and notices for Cisco products is available at this URL:

http://www.cisco.com/go/psirt

If you prefer to see advisories and notices as they are updated in real time, you can access a Product Security Incident Response Team Really Simple Syndication (PSIRT RSS) feed from this URL:

http://www.cisco.com/en/US/products/products_psirt_rss_feed.html

Reporting Security Problems in Cisco Products

Cisco is committed to delivering secure products. We test our products internally before we release them, and we strive to correct all vulnerabilities quickly. If you think that you might have identified a vulnerability in a Cisco product, contact PSIRT:

Emergencies — security-alert@cisco.com

Nonemergencies — psirt@cisco.com


Tip We encourage you to use Pretty Good Privacy (PGP) or a compatible product to encrypt any sensitive information that you send to Cisco. PSIRT can work from encrypted information that is compatible with PGP versions 2.x through 8.x.

Never use a revoked or an expired encryption key. The correct public key to use in your correspondence with PSIRT is the one that has the most recent creation date in this public key server list:

http://pgp.mit.edu:11371/pks/lookup?search=psirt%40cisco.com&op=index&exact=on


In an emergency, you can also reach PSIRT by telephone:

1 877 228-7302

1 408 525-6532

Obtaining Technical Assistance

For all customers, partners, resellers, and distributors who hold valid Cisco service contracts, Cisco Technical Support provides 24-hour-a-day, award-winning technical assistance. The Cisco Technical Support Website on Cisco.com features extensive online support resources. In addition, Cisco Technical Assistance Center (TAC) engineers provide telephone support. If you do not hold a valid Cisco service contract, contact your reseller.

Cisco Technical Support Website

The Cisco Technical Support Website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The website is available 24 hours a day, 365 days a year, at this URL:

http://www.cisco.com/techsupport

Access to all tools on the Cisco Technical Support Website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a user ID or password, you can register at this URL:

http://tools.cisco.com/RPF/register/register.do


Note Use the Cisco Product Identification (CPI) tool to locate your product serial number before submitting a web or phone request for service. You can access the CPI tool from the Cisco Technical Support Website by clicking the Tools & Resources link under Documentation & Tools. Choose Cisco Product Identification Tool from the Alphabetical Index drop-down list, or click the Cisco Product Identification Tool link under Alerts & RMAs. The CPI tool offers three search options: by product ID or model name; by tree view; or for certain products, by copying and pasting show command output. Search results show an illustration of your product with the serial number label location highlighted. Locate the serial number label on your product and record the information before placing a service call.


Submitting a Service Request

Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3 and S4 service requests are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Service Request Tool provides recommended solutions. If your issue is not resolved using the recommended resources, your service request is assigned to a Cisco TAC engineer. The TAC Service Request Tool is located at this URL:

http://www.cisco.com/techsupport/servicerequest

For S1 or S2 service requests or if you do not have Internet access, contact the Cisco TAC by telephone. (S1 or S2 service requests are those in which your production network is down or severely degraded.) Cisco TAC engineers are assigned immediately to S1 and S2 service requests to help keep your business operations running smoothly.

To open a service request by telephone, use one of the following numbers:

Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)
EMEA: +32 2 704 55 55
USA: 1 800 553-2447

For a complete list of Cisco TAC contacts, go to this URL:

http://www.cisco.com/techsupport/contacts

Definitions of Service Request Severity

To ensure that all service requests are reported in a standard format, Cisco has established severity definitions.

Severity 1 (S1)—Your network is "down," or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.

Severity 2 (S2)—Operation of an existing network is severely degraded, or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation.

Severity 3 (S3)—Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels.

Severity 4 (S4)—You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations.

Obtaining Additional Publications and Information

Information about Cisco products, technologies, and network solutions is available from various online and printed sources.

Cisco Marketplace provides a variety of Cisco books, reference guides, and logo merchandise. Visit Cisco Marketplace, the company store, at this URL:

http://www.cisco.com/go/marketplace/

Cisco Press publishes a wide range of general networking, training and certification titles. Both new and experienced users will benefit from these publications. For current Cisco Press titles and other information, go to Cisco Press at this URL:

http://www.ciscopress.com

Packet magazine is the Cisco Systems technical user magazine for maximizing Internet and networking investments. Each quarter, Packet delivers coverage of the latest industry trends, technology breakthroughs, and Cisco products and solutions, as well as network deployment and troubleshooting tips, configuration examples, customer case studies, certification and training information, and links to scores of in-depth online resources. You can access Packet magazine at this URL:

http://www.cisco.com/packet

iQ Magazine is the quarterly publication from Cisco Systems designed to help growing companies learn how they can use technology to increase revenue, streamline their business, and expand services. The publication identifies the challenges facing these companies and the technologies to help solve them, using real-world case studies and business strategies to help readers make sound technology investment decisions. You can access iQ Magazine at this URL:

http://www.cisco.com/go/iqmagazine

Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL:

http://www.cisco.com/ipj

World-class networking training is available from Cisco. You can view current offerings at this URL:

http://www.cisco.com/en/US/learning/index.html