Data Migration Guide for LAN Management Solution 3.1
Chapter 1: Overview
Download this chapter
Chapter 1: OverviewChapter 1: Overview
Download the complete book
Data Migration Guide for LAN Management Solution 3.1 - PDF of Entire BookData Migration Guide for LAN Management Solution 3.1 - PDF of Entire Book (PDF - 1 MB)
give_us_feedback

Table Of Contents

Overview

Overview of Migration to LMS 3.1

System Requirements

Terms Used in the Data Migration Guide

Scope of Data Migration

CS Data Migration Scope

CM Data Migration Scope

RME Data Migration Scope

DFM Data Migration Scope

IPM Data Migration Scope

CV Data Migration Scope

HUM Data Migration Scope

Portal Data Migration Scope

CiscoWorks Assistant Data Migration Scope


Overview

This document describes the steps involved in migrating data for CiscoWorks LAN Management Solutions (LMS) 3.1.

The following migration paths are described in this document:

•LMS 2.6 or LMS 2.6 Service Pack (SP1) to LMS 3.1

•LMS 3.0 or LMS 3.0 December 2007 Update to LMS 3.1

For more information on the applications and the version numbers, see the Overview of LAN Management Solution 3.1 section in Installing and Getting Started With CiscoWorks LAN Management Solution.

This chapter contains:

•Overview of Migration to LMS 3.1

•System Requirements

•Terms Used in the Data Migration Guide

•Scope of Data Migration

Overview of Migration to LMS 3.1

Migration is the process of carrying over data from an older version of LMS to a newer version of LMS.

Migration involves:

1. Backing up the older version of LMS data.

2. Installing the newer version of LMS.

3. Restoring the backed up data.

You can migrate to LMS 3.1 using either of these methods:

•Local Migration. This is installing LMS 3.1 on top of the existing LMS version, on the same machine and migrating the data into it.

Or

•Remote Migration. This is installing LMS 3.1 on a different machine and migrating the backed up data into it.

In Solaris machines, the backed up folder must be tarred and transferred. If not, the restore may fail due to the changes in the file name, as the file name changes from the upper case to the lowercase.

Notes for Remote Migration

The application list in the backed up data should exactly match the application list in the machine where it is restored. If there is a difference, the behavior of the applications after upgrade will be unpredictable.

Table 1-1 is an example of a scenario when the behavior of the application is unpredictable.

Table 1-1

Example No
Applications in the Backup Archive
Applications in the Restore Machine
Explanation

Example 1

CS 3.1

RME 4.1

CM 5.0

DFM 3.0

CS 3.2

RME 4.2

CM 5.1

DFM 3.1

This is a supported combination for remote migration.

Example 2

CS 3.1

CM 5.0

IPM 4.0

HUM 1.0

CS 3.2

RME 4.2

CM 5.1

DFM 3.1

IPM 4.1

HUM 1.1

This is not a supported combination for remote migration.

When you try to migrate this backup data on a remote machine, the behavior of the applications may be unpredictable and few features in the CiscoWorks applications may not work properly

Example 3

CS 3.1

CM 5.0

RME 4.1

IPM 4.0

HUM 1.0

DFM 3.0

CS 3.2

CM 5.1

IPM 4.1

HUM 1.1


Remote Migration Scenario

For details on migrating data for all applications to LMS 3.1, see:

•Migrating Data to LAN Management Solution 3.1 on Solaris

•Migrating Data to LAN Management Solution 3.1 on Windows

System Requirements

The following table provides details of the system requirements for LMS 3.1:

Table 1-2 Operating Systems Supported for LMS 3.1

Operating System
Version

Solaris

9, 10

Windows

Windows 2003 Standard and Enterprise Editions with SP1 and SP2

Windows 2003 R2 Standard and Enterprise Editions with SP1 and SP2

Note Both 32 bit and 64 bit operating systems are supported on these versions.


LMS 3.1 support virtual machines, such as VMware ESX server 3.0.1 and VMware ESX server 3.5.0.

For complete information on the System Requirements, see the "System and Browser Requirements for Server and Client" section in the Prerequisites chapter in the Installing and Getting Started with CiscoWorks LAN Management Solution 3.1 guide at this location:

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

Terms Used in the Data Migration Guide

The terms frequently used in this document are explained below:

•Copying —Copying the LMS Data in a directory.

•Upgrading—Installing a newer software version on top of an older version (For example, installing Common Services 3.2 on Common Services 3.1.1).

•Migrating—Carrying over data from an older version of LMS to a newer version.

•Restoring—Bringing the backed up data into the newer version of LMS.

Scope of Data Migration

This section lists the data that is migrated for CS, CiscoWorks Assistant, CM, RME, DFM, IPM,CV, HUM and Portal when you upgrade to LMS 3.1.

•On both platforms, migration is supported across different NMSROOT directories, where NMSROOT is the CiscoWorks installation directory. By default, it is:

–/opt/CSCOpx for Solaris

–C:\Program Files\CSCOpx for Windows, where C: is the System Drive

•Cross platform data migration is not supported.

This section contains the following topics:

•CS Data Migration Scope

•CM Data Migration Scope

•RME Data Migration Scope

•DFM Data Migration Scope

•IPM Data Migration Scope

•Portal Data Migration Scope

•CiscoWorks Assistant Data Migration Scope

•CV Data Migration Scope

•HUM Data Migration Scope

CS Data Migration Scope

The following data gets migrated when you upgrade to Common Services 3.2:

•CiscoWorks User information

•Single Sign-on configuration

•Device and Credential Repository (DCR) configuration

•Peer Certificates

•Peer Server Account information

•System Identity Account configuration

•Cisco.com User Account

•Proxy server settings or proxy server configuration

•System Preferences

•Home Page settings

•Applications Registered

•Links Registered

•Login Module settings

•Software Center map files

•ACS Credentials

•Jobs and Resources data, DCR data, Groups data, and other data stored in the database

•Local User Policy Setup

•CS Discovery configuration data and Discovery jobs

–Seed devices settings

–module settings

Note CS Discovery configuration data and Discovery jobs will be migrated only from LMS 3.0 December 2007 Update.

CM Data Migration Scope

The following data gets migrated when you upgrade to Campus Manager 5.1:

•Data Collection settings

–IP Address Filter

–SNMP Timeouts and retries

–Data Collection Schedule

–Debugging Options

•Syslog settings

•Campus Manager groups

•Topology Groups-User Defined Groups

•Discrepancy setting

•Configure Discrepancy

•Configure Syslog server

•User Tracking

–Custom Layout

–Custom Query

–Username and Notes in UT Report

–UT Purge Interval

–UT Acquisition Schedule

–Subnet Discovery Ranges

–Ping sweep options

–Domain name Display

–UT End host and IP Phone entries

–Delete Interval

–Acquisition settings

•Jobs and Archives

•UT Jobs and Archives

•Discovery Settings:

–Seed Devices

–IP address Filter

–Discovery Schedule

–SNMP Settings

•Path Analysis

–Archive Trace

–Path Analysis Options

•Path Analysis Jobs

However, when you migrate or upgrade from LMS 3.0 December 2007 Update, the following data will not be migrated.

•Discovery Settings:

–Seed Devices

–IP address Filter

–Discovery Schedule

•Path Analysis

–Archive Trace

–Path Analysis Options

•Path Analysis Jobs

RME Data Migration Scope

The following data gets migrated when you upgrade to RME 4.2:

•Config Archive

–Shadow directory

–ChangeAudit records. This includes Configuration change details

–Archived configuration versions

•NetConfig

–User-defined Templates (UDT)

–Default Template Usage

By default, all templates are assigned to Admin on migration. The device-to-task mapping is not migrated.

•Config Editor — Editing Mode in which the files are opened. It is either Raw or Processed

•RME groups

–Archive Management :

–All jobs

–Label Configs

–Custom queries

–Baseline templates

–Shadow directory

–ChangeAudit records. This includes Configuration change details.

–Archived configuration versions

•Admin— Purge policiesConfig Editor:

–Private Configs

–Public Configs

–Config Editor jobs

–Editing mode in which the files are opened. It is either Raw or Processed.

•NetConfig:

–Netconfig jobs

–User-defined tasks

•NetShow:

–NetShow jobs

–Output archives

–Commandsets

•Software Management

–Software Management repository images

–All jobs in a Job Browser

•Inventory

–Inventory jobs

–Device details

–Inventory Collection status

–DCA jobs

–Device Management state

–User -defined groups

When you migrate RME data, the following syslog details get migrated:

•Automated actions

•Message filters

•Custom reports

•Syslog messages for the past 14 days

•Report jobs and archives

Note While restoring data from RME 4.1 to RME 4.2, all jobs, data and admin settings will be migrated.

DFM Data Migration Scope

The following data gets migrated when you upgrade to DFM 3.1:

•Device list—The migration procedure adds devices to Common Services Device and Credentials Repository (DCR). To manage them in DFM, either enable Auto Manage feature or manually add the devices to DFM.

•The following notification information:

–Mail notification information

–Mail recipient information

–Mail sender ID

–Syslog notification

–SMTP addresses

–Trap forwarding addresses

–Trap notification addresses and ports

•DFM groups

•AAD page

•Data Purge settings—Data Purge settings are migrated only when you restore data from LMS 3.0 December 2007 Update.

•Log settings—Log settings are migrated only when you restore data during a Local Migration.

•Some polling and threshold settings—For details, see sections Upgrading Polling Settings and Upgrading Threshold Settings in the Installation and Setup Guide for Device Fault Manager.

This is available at http://www.cisco.com/en/US/products/sw/cscowork/ps2421/prod_installation_guides_list.html.

IPM Data Migration Scope

The following data gets migrated when you upgrade to IPM 4.1:

•IPM Collectors

•IPM database—Contains information about source devices, target devices, operations, collectors, and the statistics of data collected.

•The settings in ipm.env file

Note HTML reports available in IPM 2.6 is backed-up but not restored by running restorebackup.pl.

You can generate consolidated System Reports for data migrated from IPM 2.6 to IPM 4.1. However, the time taken to generate the reports depends on the length of the period for which you are querying.

For example, generating reports for a period of 6 months may take a longer time, than generating reports for a period of 10 days.

During the same version backup/restore, do not run /NMSROOT/bin/restorebackup.pl script from the following directories:

•Solaris

NMSROOT/MDC/tomcat/webapps/ipm/system_reports and

/var/adm/CSCOpx/files/ipm/

•Windows

NMSROOT/MDC/tomcat/webapps/ipm/system_reports and

NMSROOT/CSCOpx/files/ipm/

When you install IPM 4.1, and migrate from LMS 3.0 or LMS3.0 December 2007 Update to LMS 3.1, the following data gets migrated:

•IPM database—contains information about source devices, target devices, operations, collectors, and the statistics of data collected.

•Settings in IPM properties.

•Log Settings.

•System Reports

•Report Jobs and archives.

•Exported data (Statistics and Collectors).

CV Data Migration Scope

When you upgrade to CiscoView 6.1.8, the user's device preferences are migrated.

HUM Data Migration Scope

The following data gets migrated when you upgrade to HUM 1.1:

•Poller configuration

•Custom templates details

•Threshold configuration

•In System preferences other than the log-level settings, all other data will be migrated.

•Jobs and data stored in the database.

Portal Data Migration Scope

The following data gets migrated when you upgrade to Portal 1.1:

•Public Portal configuration or settings

•Private Portal configuration or settings.

CiscoWorks Assistant Data Migration Scope

No data gets migrated when you upgrade to CiscoWorks Assistant 1.1.