Installation and Setup Guide for Resource Manager Essentials 4.0.3 on Windows (With LMS 2.5.1) - Chapter 3: Upgrading and Migrating RME [CiscoWorks Resource Manager Essentials]

Table Of Contents

Upgrading and Migrating RME

Defining RME Upgrade and Migration

Defining RME Upgrade

Defining RME Migration

Supported RME Versions for Upgrade and Migration

Data Migrated From RME 3.4.x and RME 3.5.x

Data That is Migrated

Data That is Not Migrated

Performing Data Migration From RME 3.4.x and 3.5.x

Local Migration From RME 3.4.x and RME 3.5.x

Remote Migration From RME 3.4.x and RME 3.5.x

Backing Up Your RME 3.4.x or RME 3.5.x Data

Restoring the RME 3.4.x or RME 3.5.x Backup Data

Validating Your Upgrade License

Upgrade From RME 4.0.x to RME 4.0.3

Local Upgrade From RME 4.0, 4.0.1 or 4.0.2

Remote Upgrade From RME 4.0, 4.0.1 or 4.0.2

Backing Up Your RME 4.0.x Data

Restoring the RME 4.0.x Backup Data

Upgrading and Migrating RME

This chapter describes upgrading and migrating older version of RME to RME 4.0.3 on a Windows system. It consists of:

•Defining RME Upgrade and Migration

•Performing Data Migration From RME 3.4.x and 3.5.x

•Upgrade From RME 4.0.x to RME 4.0.3

Defining RME Upgrade and Migration

This section provides overview information on upgrade and migration process topics:

•Defining RME Upgrade

•Defining RME Migration

•Supported RME Versions for Upgrade and Migration

•Data Migrated From RME 3.4.x and RME 3.5.x

Defining RME Upgrade

Upgrade involves overwriting the existing RME version with the new RME version.

The following table describes the scenario when the data is migrated to RME 4.0.3:

Table 3-1 Support for RME Data Migration

RME Version

Support for Data Migration

See

RME 4.0.x

RME 4.0.x data migrated to RME 4.0.3.

All of the RME 4.0, 4.0.1, and RME 4.0.2 data is migrated to RME 4.0.3

RME 3.5.x

RME 3.5.x data not migrated to RME 4.0.3.

Data Migrated From RME 3.4.x and RME 3.5.x

RME 3.4.x

RME 3.4.x data not migrated to RME 4.0.3.

Data Migrated From RME 3.4.x and RME 3.5.x

You can upgrade using either of these two methods:

•Local upgrade—Installing RME 4.0.3 on top of RME (4.0.2, 4.0.1, 3.5.x, or 3.4.x) on the same machine.

Or

•Remote upgrade—Installing RME 4.0.3 on a different machine and then restoring the data on the machine that has RME 4.0.3.

Defining RME Migration

Migration involves migrating data from an older version of RME to a newer version of RME. The steps for migration include:

1. Backing up the older version of RME data.

2. Installing the newer version of RME.

3. Restoring the backed up data.

You can migrate using either of these two methods:

•Local migration—Installing RME 4.0.3 on top of RME 3.4.x or 3.5.x on the same machine.

Or

•Remote migration—Installing RME 4.0.3 on a different machine.

For information on the data that is migrated to RME 4.0.3, see.

Supported RME Versions for Upgrade and Migration

You can migrate or upgrade the following versions of RME to RME 4.0.3.

Resource Manager Essentials Version¹

...Which Came with LAN

Management Solution Version...

Reference

RME 3.4.x

LMS 2.1

Performing Data Migration From RME 3.4.x and 3.5.x

RME 3.5.x

LMS 2.2

Performing Data Migration From RME 3.4.x and 3.5.x

RME 4.0.x²

LMS 2.5

Upgrade From RME 4.0.x to RME 4.0.3

¹Migration/upgrade is also supported when any patch/IDUs or Service Packs are installed on these versions of RME.

²In this scenario, all RME 4.0.x data is preserved.

Data Migrated From RME 3.4.x and RME 3.5.x

The section provides information on RME 3.4.x and 3.5.x data that is migrated to RME 4.0.3 and data that is not migrated to RME 4.0.3:

•Data That is Migrated

•Data That is Not Migrated

Data That is Migrated

The data migrated from RME 3.4.x or 3.5.x to RME 4.0.3 is:

•Devices and its credentials are updated in the Device Credential Repository (DCR).

•Device configurations collected from devices using Config Archive.

•Change Audit history of all devices. This includes detailed changes that each application maintains.

•Images in Software Management repository.

•NetConfig user-defined templates

•Syslog user-defined filters.

•NetShow User Defined Command Sets and the Commands associated with those command sets. The migrated Command Sets will not have any device type associated with them. You must edit them before using them in jobs.

See the following sections for application specific details on data migrated:

•Device Selector

•Inventory

•Config Archive

•NetConfig

•Config Editor

•NetShow

•Software Management

•Syslog

•Change Audit

Device Selector

The Public and Private Static Device Views are migrated.

For Private views, device groups are created with the RME 3.4 or RME 3.5 username. You may use groups if the same username exists in RME 4.0.3. If the username does not exist in RME 4.0.3, the group is assigned to NetAdmin.

Inventory

The inventory data migrated from RME 3.4.x or 3.5.x to RME 4.0.3 is:

•Change History

•User-defined fields and their display names

•Device attributes and credentials

•RME Device Management Application updates

RME Device Management Application updates DCR with the list of devices and appropriate credentials.

Migration Strategy

All devices in the managed state in RME 3.4.x or RME 3.5.x are migrated to RME 4.0.3. For the list of devices maintained in RME 3.4.x or RME 3.5.x, the migration strategy is:

1. Device Management Application is supplied with the list of devices migrated from RME 3.4.x or RME 3.5.x.

2. Device Management Application assigns the device ID to the device. The device ID is the same ID that the device used in RME 3.4.x or RME 3.5.x. Device Management Application also marks the state of the devices as normal.

3. You are prompted to initiate inventory collection.

If you choose to collect inventory data during migration, inventory collection is triggered towards the end of migration.

We recommend that you do not perform Inventory collection during migration. This is because it takes a long time to complete inventory data collection. It depends on number of devices, network speed and device response time.

Schedule inventory collection after migration using the user interface. To do this select RME > Devices > Inventory from the CiscoWorks homepage.

Only devices in Managed state are migrated to RME 4.0.3.

The Alias, Pending, Conflicting, Suspended, Not Responding device states are not migrated to RME 4.0.3. However, they are migrated to Common Services Device and Credentials Repository (DCR). You have to manually, add these devices to RME 4.0.3 Device Management.

Credentials are associated. These devices and their associated credentials are migrated to DCR. For details, select Devices > Device Management > RME Devices, from the CiscoWorks homepage

Config Archive

The Config Archive data migrated from RME 3.4.x or 3.5.x to RME 4.0.3 is:

•Raw Configuration files. This includes all running, startup and VLAN configurations.

•Shadow directory.

•ChangeAudit records. This includes Configuration change details.

•Archived configuration versions

NetConfig

The NetConfig data migrated from RME 3.4.x or 3.5.x to RME 4.0.3 is:

•User Defined Templates (UDT)

UDT RouterUDT in RME3.5 is migrated as RouterUDTTask with the UDT template, RouterUDT in RME 4.0.3.

•Default Template Usage

All templates are assigned to Admin on migration by default. The device to task mapping is not migrated.

Config Editor

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

NetShow

All the RME 3.4.x or RME 3.5.x User Defined Command Sets and the Commands associated with those command sets are migrated to RME 4.0.3. The migrated Command Sets will not have any device type associated with them. You must edit them before using them in jobs.

Software Management

The Software Management data migrated from RME 3.4.x or 3.5.x to RME 4.0.3 are Image Libraries/Repositories.

Exceptions

•Images of device types that do not have device support are not migrated. The corresponding device package may not be installed.

•Images are migrated with default attributes. If you made any changes to the image attributes in RME 3.4 or RME 3.5, you must redo the changes after migrating the image to RME 4.0.3.

Syslog

The Syslog data migrated from RME 3.4.x or 3.5.x to RME 4.0.3 is:

•Automated Actions and Filters

Automated Actions and Filters are migrated. However, the scripts associated with the automated actions are not migrated.

Hence, you must manually copy the scripts from RME 3.4 or RME 3.5 installation to the required location in RME 4.0.3. Ensure that the scripts work on the RME 4.0.3 system for the automated tasks to function properly.

•Syslog messages

Syslog messages are critical. However, the data volume is huge. Hence, you may choose to migrate the Syslog messages during migration.

•RME 4.0.3 retains data up to 7 days by default. During migration, if you attempt to restore RME 3.4 or RME 3.5 data older than the configured number of days on RME 4.0.3, messages are purged when the next Syslog purge job is triggered.

•Custom reports

Custom reports are migrated.

Change Audit

All change records with the details are migrated.

Data That is Not Migrated

This section lists the data that is not migrated RME 3.4.x or 3.5.x to RME 4.0.3. It also states the tasks that you need to recreate.

•Scheduled jobs that need to be executed.

These jobs must be recreated with required approvals sought anew.

•Application execution logs.

The structure and components of earlier versions of RME in comparison to RME 4.0.3 are different. Hence, earlier versions of logs are irrelevant.

•Completed jobs.

Completed jobs cannot be edited or used to create new jobs. However, the details of job execution are available. View the Change Audit reports for details about how devices were affected.

•Admin Settings

RME 4.0.3 default configuration overrides configurations of earlier versions of RME. For the admin settings of your RME 3.x system, see AdminSettings.txt file. The file is usually available in NMSROOT. You may use this file as a baseline to configure your RME 4.0.3 system, if required.

See the following sections for application specific details on data not migrated:

•Device Selector

•Inventory

•Config Archive

•NetConfig

•Config Editor

•Software Management

•Syslog

•Change Audit

•Jobs

Device Selector

The Dynamic Views are not migrated.

RME 3.4 or RME 3.5 dynamic views are not migrated because of the device classification changes to Meta Data Format (MDF) in RME 4.0.3.

Inventory

The inventory data not migrated from RME 3.4.x or 3.5.x to RME 4.0.3 is:

•Detailed Device Data

Importing a device in RME 4.0.3 fetches device data from the managed device.

•Scan History

This feature is not supported in RME 4.0.3.

•Collection and Polling Interval

Default system inventory collection and polling job is created.

•Inventory Change Filter

Inventory change filter details are not backed up in RME 3.4 and RME 3.5. This data must be recreated in RME 4.0.3.

•Check device attributes

Check device attribute data is overwritten when invoked.

Config Archive

The Config Archive data not migrated from RME 3.4.x or 3.5.x to RME 4.0.3 is:

•Protocol order and archive location

The RME 4.0.3 settings take precedence.

•Admin settings

Default update schedule, purge policy and syslog policy.

•Label information.

•Custom queries

•Last Configuration change time for devices.

•Running-Startup configuration out-of-synchronized data.

NetConfig

The NetConfig data not migrated from RME 3.4.x or 3.5.x to RME 4.0.3 is:

•Template to Device Type Assignment

In RME 3.4 or RME 3.5, User Defined Templates are associated with a device category, while in RME 4.0.3 the categorization is based on MDF type. Hence, the translation from RME 3.4 or RME 3.5 categorization to RME 4.0.3 is not feasible.

•Jobs and details

•User Preferences and Admin Settings

Config Editor

The Config Editor data not migrated from RME 3.4.x or 3.5.x to RME 4.0.3 is:

•Negation rules

In RME 3.4 or RME 3.5, negation rules are maintained in flat files. In RME 4.0.3, RME device packages handle this task.

•Insertion rules

In RME 4.0.3, insertion rules are maintained by Config archive.

•User Preferences and Admin Settings

Software Management

The Software Management data not migrated from RME 3.4.x or 3.5.x to RME 4.0.3 is:

•Admin Settings

Admin settings are stored in a flat file. You may access the file after migration. See your old admin settings from the text file and configure RME 4.0.3.

•Jobs and details

Jobs and its details are not migrated.

Syslog

The Syslog data not migrated from RME 3.4.x or 3.5.x to RME 4.0.3 is:

•Admin settings

The devices that are not managed in RME 4.0.3 and are represented using wildcards, are ignored during migration of automated action, message filters and custom reports.

Change Audit

The Change Audit data not migrated from RME 3.4.x or 3.5.x to RME 4.0.3 is:

•Admin settings

•Exception periods

Jobs

In RME 3.x, jobs are serialized objects. You could copy the RME job objects from one 3.x version to another. In RME 4.0.3, the job data structures are not serialized objects. Hence, you cannot migrate jobs.

Performing Data Migration From RME 3.4.x and 3.5.x

This section describes how to migrate to RME 4.0.3, if you have RME 3.4.x or RME 3.5.x installed on the server.

•To migrate RME on the same server see, "Local Migration From RME 3.4.x and RME 3.5.x" section.

•To migrate RME on a different server see, "Remote Migration From RME 3.4.x and RME 3.5.x" section.

Important Migration Note

•Data migration across operating systems is not supported.

•Before starting migration, all currently scheduled jobs must be suspended.

•Before upgrading RME 3.5 to RME 4.0.3, you must download and install the patch with the ID CSCec01327. Install the patch on the RME 3.5 system. You can download the patch from:

http://www.cisco.com/pcgi-bin/tablebuild.pl/cw2000-cd-one

Else, restoration of the data backed up during Common Services installation will fail.

Local Migration From RME 3.4.x and RME 3.5.x

Table 3-1 provides an overview of the local migration procedure when migrating from RME 3.4.x or 3.5.x to RME 4.0.3:

Table 3-2 Procedure for Local Migration from RME 3.4.x and RME 3.5.x

Task

Reference

Step 1

Login as root on the machine where RME 3.4.x or RME 3.5.x is installed.

—

Step 2

Backup your RME 3.4.x or RME 3.5.x data.

Backing Up Your RME 3.4.x or RME 3.5.x Data

Step 3

Verify that your operating system is supported by RME 4.0.3.

"Prerequisites"

Step 4

Install Common Services 3.0.3.

CS 3.0.3 installer prompts you for a backup directory during local migration, and automatically does a backup.

Installation and Setup Guide for Common Services 3.0.3 (Includes Ciscoview) on Windows.

Related Documentation

Step 5

Install RME 4.0.3

The RME 4.0.3 install script uninstalls older versions of RME (3.4.x or 3.5.x) along with dependent applications installed in the system.

For example, consider Access Control List Manager (ACLM) and VPN/Security Management as RME dependant applications. During RME 4.0.3 installation, ACLM, VPN and the older version of RME (3.x) is uninstalled.

"Installing RME"

Step 6

Restore RME 3.4.x or RME 3.5.x data

Restoring the RME 3.4.x or RME 3.5.x Backup Data

Step 7

Perform post-installation tasks

"Installing RME"

and

"Preparing to Use RME Applications"

and

"Changes From RME 3.x to RME 4.x"

Remote Migration From RME 3.4.x and RME 3.5.x

Table 3-1 provides an overview of the remote migration procedure when migrating from RME 3.4.x or 3.5.x to RME 4.0.3:

Table 3-3 Procedure for Remote Migration from RME 3.4.x and RME 3.5.x

Task

Reference

Step 1

Login as root on the machine where RME 3.4.x or RME 3.5.x is installed.

—

Step 2

Backup your RME 3.4.x or RME 3.5.x data.

Step 3

Login as root on the machine where you want to install RME 4.0.3

—

Step 4

Verify that your operating system is supported by RME 4.0.3.

"Prerequisites"

Step 5

Install Common Services 3.0.3.

CS 3.0.3 installer prompts you for a backup directory during local migration, and automatically does a backup.

Installation and Setup Guide for Common Services 3.0.3 (Includes Ciscoview) on Windows.

Related Documentation

Step 6

Install RME 4.0.3

The RME 4.0.3 install script uninstalls older versions of RME (3.4.x or 3.5.x) along with dependent applications installed in the system.

For example, consider Access Control List Manager (ACLM) and VPN/Security Management as RME dependant applications. During RME 4.0.3 installation, ACLM, VPN and the older version of RME (3.x) is uninstalled.

"Installing RME"

Step 7

Transfer the RME 3.4.x or RME 3.5.x backup data to the RME 4.0.3 machine.

—

Step 8

Restore RME 3.4.x or RME 3.5.x data.

Restoring the RME 3.4.x or RME 3.5.x Backup Data

Step 9

Validate your upgrade license.

Validating Your Upgrade License

Step 10

Perform post-installation tasks.

"Installing RME"

and

"Preparing to Use RME Applications"

and

"Changes From RME 3.x to RME 4.x"

Backing Up Your RME 3.4.x or RME 3.5.x Data

You can back up data either using CLI or GUI.

Backing Up Data Using CLI

To back up using CLI, follow this syntax:

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

For example:
D:\Program Files\CSCOpx\bin\perl D:\Program Files\CSCOpx\bin\backup.pl 
D:\ciscoworks\rmebackupdata 2
where,

•NMSROOT is the CiscoWorks installed directory.

•BKP—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.

•num_generations—Maximum backup generations to be kept in the backup directory

For more information, see CD One, Fifth Edition and Common Services 2.2 online help.

Backing Up Data Using GUI

To back up on,

•RME 3.4.x (CD One, Fifth Edition):

Select Server Configuration > Administration > Database Management > Back Up Data Now.

•RME 3.5.x (Common Services 2.2):

Select Server Configuration > Administration > Database Management > Back Up Data Now.

Click Help for more information.

Restoring the RME 3.4.x or RME 3.5.x Backup Data

We recommend that you do not cancel migration while it is running. This is to avoid errors.

Step 1 Log in as the local administrator on the system on which you installed RME 4.0.3.

Step 2 Shut down the daemon manager. To do this, enter:
net stop crmdmgtd
Step 3 Run the command:

NMSROOT\bin\perl NMSROOT\bin\restorebackup.pl -d backup location -gen version -t tempbackup dir

For example:
D:\Program Files\CSCOpx\bin\perl  
D:\Program Files\CSCOpx\bin\restorebackup.pl  
-d D:\ciscoworks\rmebackupdata -gen 2 -t D:\temp
where

•NMSROOT is the CiscoWorks installation directory

•-d backup location is the location where RME 3.4 or RME 3.5. backup data is available. This is mandatory.

•-gen version is the version to be migrated to RME 4.0.3. By default, it will restore the latest backup data. If generations 1 through 5 exist, then 5 will be the latest. This is optional.

•-t tempbackup dir is used to extract files from the backup into a temporary location. These files are used by the restore backup script. This will be deleted after the data restoration is complete. This is optional. By default, the Restore Backup script uses NMSROOT/tempbackupdata directory.

The migration script checks the details of the applications installed in the system and applications in the backup archive.

You are prompted to migrate syslog information. The following message appears:
Do you want to migrate syslogs [y / n]? Enter y to continue.
If you wish to migrate syslog information, choose Y, otherwise choose N.

You are prompted to collect inventory data. The following message appears:
Do you want to collect Inventory [y/n]?
If you wish to collect inventory information during migration, choose Y, otherwise choose N.

We recommend that you do not perform Inventory collection during migration. This is because it takes a long time to complete inventory data collection.It depends on number of devices, network speed and device response time.

Schedule inventory collection after migration using the user interface. From the CiscoWorks homepage, select RME > Devices > Inventory.

Step 4 Start daemon manager after the migration is completed. To do this, enter:
net start crmdmgtd
You have migrated to RME 4.0.3.

Validating Your Upgrade License

If you purchased an upgrade license of RME 4.0.3, you must validate the upgrade on the system where RME 4.0.3 is installed.

Proof of Purchase (POP) is required to validate an upgrade license of RME 4.0.3 You are prompted to run a CLI script to validate this upgrade license. This script is available at this location, NMSROOT/bin/validateupgrade.exe.

Where NMSROOT is the CiscoWorks installed directory.

•If you plan to use the same machine (that has RME 3.4.x or RME 3.5.x) for RME 4.0.3 installation with valid RME 4.0.3 license, you will not be prompted to run this CLI script.

In this case, Proof of Purchase validation is done automatically.

•If you plan to use the same machine (that has RME 3.4.x or RME 3.5.x) for RME 4.0.3 installation with RME 4.0.3 Evaluation license, you will not be prompted to run this CLI script.

In this case, Proof of Purchase validation has to be done manually after purchasing a valid RME 4.0.3 license

•If you plan to use a new/different server for RME 4.0.3 (that has RME 3.4.x or RME 3.5.x installed on a different server), a message appears at the end of the RME 4.0.3 installation to validate the upgrade license.

The product will be in the nag mode until POP is validated. This message appears till you complete the upgrade validation:
This software installation requires reusing a license provided in 
a previous version. If a previous license is not available or 
proof of purchase validation was not performed, you may continue 
to install in NAG mode, while arranging with your Cisco 
representative to return this product and purchase a full licensed 
version.
To validate the upgrade license:

Step 1 Go to the directory NMSROOT/bin using the command.

Where NMSROOT is the CiscoWorks installed directory.

Step 2 Run the CLI script:

validateupgrade.exe

The following prompt appears:
This utility will validate your proof of purchase of the product and 
allow you to obtain an upgrade license.
Please enter the CiscoWorks product for the proof of purchase 
validation (such as LMS, ITEM, VMS):
Step 3 Enter the bundle name and press Enter.

The following prompt appears:
Please select the source for upgrade validation from the following
1. Validate from a CD (older version of RME).
2. Validate from a remote server (where older version of RME is 
installed).
Please enter 1 to upgrade from a CD; enter 2 to upgrade from a remote 
server  [1 / 2] :
•If you select 1, a prompt appears:

Please insert the previous versions of RME CD into the CDROM drive and provide the absolute path to the CD drive:

Enter the CDROM drive path. For example, Z:

•If you select 2, a prompt appears:
Please enter the remote CiscoWorks server host name or the IP 
address : 
Please enter the remote CiscoWorks server http or https port 
number   :
Please enter the remote CiscoWorks server login name :
Please enter the remote CiscoWorks server login password :
Please be patient. Upgrade validation is in progress from a remote 
server.
Enter the following details of the remote CiscoWorks server:

–Host name or the IP address. For example, ciscoworks-rme

–http or https port number. For example, 1741

–Login name. For example, admin

–Login password.

This message appears after you enter the above details:
Please be patient. Upgrade validation is in progress from a remote 
server.
After the RME upgrade validation completes, this message appears:
Validation succeeded.
Upgrade From RME 4.0.x to RME 4.0.3

You can perform this upgrade using the RME 4.0.3 CD-ROM or LMS 2.5 December 2005 Update.

•For CD-ROM, use the instructions in this section.

•For LMS 2.5 December 2005 Update, use the instructions in the Readme for LMS 2.5 December 2005 Update.

This is available at this location:

http://www.cisco.com/public/sw-center/cw2000/lan-planner.shtml

Important Local Upgrade Notes

During local upgrade from RME 4.0.x to RME 4.0.3,

•If you have a licensed copy of RME 4.0.x, after upgrading to RME 4.0.3 you do not have to upgrade your license.

•If you have a evaluation copy of RME 4.0.x after upgrading to RME 4.0.3, if you want to update your evaluation license to valid LMS 2.5.1 license, follow the steps described in "Licensing".

•If you have configured for ACS login module, all of the ACS settings are retained after Local and Remote upgrade.

The following section captures procedure for:

•Local Upgrade From RME 4.0, 4.0.1 or 4.0.2

•Remote Upgrade From RME 4.0, 4.0.1 or 4.0.2

Local Upgrade From RME 4.0, 4.0.1 or 4.0.2

Table 3-1 provides an overview of the local upgrade procedure when upgrading from RME 4.0, 4.0.1, or 4.0.2 to RME 4.0.3.

Table 3-4 Procedure for Local Upgrade from RME 4.0, 4.0.1 or 4.0.2

Task

Reference

Step 1

Login as root to the machine where RME 4.0, 4.0.1 or 4.0.2 is installed

—

Step 2

Backup your RME 4.0.x data.

Backing Up Your RME 4.0.x Data

Step 3

Install Common Services 3.0.3.

Installation and Setup Guide for Common Services 3.0.3 (Includes Ciscoview) on Windows.

Related Documentation

Step 4

Install RME 4.0.3

"Installing RME"

Step 5

Restore RME 4.0.x data.

You need not run any scripts to migrate data. All necessary data is migrated to RME 4.0.3 during the upgrade.

Remote Upgrade From RME 4.0, 4.0.1 or 4.0.2

Table 3-1 provides an overview of the remote upgrade procedure when upgrading from RME 4.0, 4.0.1, or 4.0.2 to RME 4.0.3.

Table 3-5 Procedure for Remote Upgrade from RME 4.0, 4.0.1 or 4.0.2

Task

Reference

Step 1

Login as root to the machine where RME 4.0, 4.0.1 or 4.0.2 is installed

—

Step 2

Backup your RME 4.0.x data.

Backing Up Your RME 4.0.x Data

Step 3

Login as root on the machine where you want to install RME 4.0.3

—

Step 4

Verify that your operating system is supported by RME 4.0.3.

"Prerequisites"

Step 5

Install Common Services 3.0.3.

Installation and Setup Guide for Common Services 3.0.3 (Includes Ciscoview) on Windows.

Related Documentation

Step 6

Install RME 4.0.3

You need not run any scripts to migrate data. All necessary data is migrated to RME 4.0.3 during the upgrade.

"Installing RME"

Step 7

Transfer the RME 4.0, 4.0.1 or 4.0.2 backup data to the RME 4.0.3 machine.

—

Step 8

Restore RME 4.0.x data.

Restoring the RME 4.0.x Backup Data

Backing Up Your RME 4.0.x Data

You can back up data either using CLI or GUI.

Backing Up Data Using CLI

To back up using CLI, follow this syntax:

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

For example:
D:\Program Files\CSCOpx\bin\perl D:\Program Files\CSCOpx\bin\backup.pl 
D:\ciscoworks\rmebackupdata 2
where,

•NMSROOT is the CiscoWorks installed directory.

•BKP—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.

•num_generations—Maximum backup generations to be kept in the backup directory

For more information, see Common Services 3.0.x online help.

Backing Up Data Using GUI

To back up on RME 4.0.x (Common Services 3.0.x), select Common Services > Server > Admin > Backup.

Click Help for more information.

Restoring the RME 4.0.x Backup Data

We recommend that you do not cancel migration while it is running. This is to avoid errors.

Step 1 Log in as the local administrator on the system on which you installed RME 4.0.3.

Step 2 Shut down the daemon manager. To do this, enter:
net stop crmdmgtd
Step 3 Run the command:

NMSROOT\bin\perl NMSROOT\bin\restorebackup.pl -d backup location -gen version -t tempbackup dir

For example:
D:\Program Files\CSCOpx\bin\perl  
D:\Program Files\CSCOpx\bin\restorebackup.pl  
-d D:\ciscoworks\rmebackupdata -gen 2 -t D:\temp
where

•NMSROOT is the CiscoWorks installation directory

•-d backup location is the location where RME 3.4 or RME 3.5. backup data is available. This is mandatory.

•-gen version is the version to be migrated to RME 4.0.3. By default, it will restore the latest backup data. If generations 1 through 5 exist, then 5 will be the latest. This is optional.

•-t tempbackup dir is used to extract files from the backup into a temporary location. These files are used by the restore backup script. This will be deleted after the data restoration is complete. This is optional. By default, the Restore Backup script uses NMSROOT/tempbackupdata directory.

The migration script checks the details of the applications installed in the system and applications in the backup archive.

You are prompted to migrate syslog information. The following message appears:
Do you want to migrate syslogs [y / n]? Enter y to continue.
If you wish to migrate syslog information, choose Y, otherwise choose N.

You are prompted to collect inventory data. The following message appears:
Do you want to collect Inventory [y/n]?
If you wish to collect inventory information during migration, choose Y, otherwise choose N.

We recommend that you do not perform Inventory collection during migration. This is because it takes a long time to complete inventory data collection.It depends on number of devices, network speed and device response time.

Schedule inventory collection after migration using the user interface. From the CiscoWorks homepage, select RME > Devices > Inventory.

Step 4 Start daemon manager after the migration is completed. To do this, enter:
net start crmdmgtd
You have migrated to RME 4.0.3.