Table Of Contents

Upgrading and Migrating to RME 4.0.5

Defining Upgrade and Migration for RME 4.0.5

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 to RME 4.0.5

Data That is Not Migrated to RME 4.0.5

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

Upgrade From RME 4.0.x to RME 4.0.5

Local Upgrade From RME 4.0.3, or 4.0.4 to RME 4.0.5

Remote Upgrade From RME 4.0.3 or 4.0.4 to RME 4.0.5

Backing Up and Restoring RME Data to RME 4.0.5

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

Backing Up RME 3.4.x or RME 3.5.x Data Using CLI

Backing Up RME 3.4.x or 3.5.x Data Using GUI

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

Backing Up Your RME 4.0.x Data

Backing Up RME 4.0.x Data Using CLI

Backing Up RME 4.0.x Data Using GUI

Restoring the RME 4.0.x Backup Data

Validating Your Upgrade License

Upgrading and Migrating to RME 4.0.5

---

This chapter describes upgrading and migrating older versions of RME to RME 4.0.5 on a Solaris system. It consists of:

•Defining Upgrade and Migration for RME 4.0.5

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

•Upgrade From RME 4.0.x to RME 4.0.5

•Backing Up and Restoring RME Data to RME 4.0.5

Defining Upgrade and Migration for RME 4.0.5

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. For versions prior to RME 4.0.3, you need to install RME 4.0.3 before upgrading to RME 4.0.5.

The Table 3-1 describes the scenario when the data is migrated to RME 4.0.5:

Table 3-1 Support for RME Data Migration 

RME Version	Support for Data Migration	See
RME 4.0.3	RME 4.0.3 / 4.0.4 data migrated to RME 4.0.5.	All of the RME 4.0.3 and RME 4.0.4 data is migrated to RME 4.0.5
RME 3.5.x	RME 3.5.x data not migrated to RME 4.0.5.	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.5.	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.5 on top of RME (4.0.3 or 4.0.4) on the same machine.

Or

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

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 methods:

•Local migration—Installing RME 4.0.5 on top of RME 4.0.3 or RME 4.0.4 on the same machine.

Or

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

Supported RME Versions for Upgrade and Migration

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

Resource Manager Essentials Version1	...Which Came with LAN Management Solution Version...	Upgrade and Migration action
RME 3.4	LMS 2.1	1. Upgrade to LMS 2.5.1 2. Perform data migration (inline or remote) 3. Install LMS 2.6 mega patch (this installs RME 4.0.5)
RME 3.5	LMS 2.2	1. Upgrade to LMS 2.5.1. 2. Perform data migration (inline or remote) 3. Install LMS 2.6 mega patch
RME 4.0	LMS 2.5	1. Upgrade to LMS 2.5.1 (from CD) 2. Install LMS 2.6 mega patch 3. Perform data migration (inline or remote)

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

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. It also gives details on data that is not migrated to RME 4.0.5:

•Data That is Migrated to RME 4.0.5

•Data That is Not Migrated to RME 4.0.5

Data That is Migrated to RME 4.0.5

The data migrated from RME 3.4.x or 3.5.x to RME 4.0.5 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.5. If the username does not exist in RME 4.0.5, the group is assigned to NetAdmin.

Inventory

The inventory data migrated from RME 3.4.x or 3.5.x to RME 4.0.5 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.5. 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.5.

The Alias, Pending, Conflicting, Suspended, Not Responding device states are not migrated to RME 4.0.5. However, they are migrated to Common Services Device and Credentials Repository (DCR). You have to manually, add these devices to RME 4.0.5 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.5 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.5 is:

•User Defined Templates (UDT)

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

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

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.5.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.5are Image Libraries/Repositories. The exceptions are:

•Images of device types that do not have device support, are not migrated. The corresponding device packages 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.5.

Syslog

The Syslog data migrated from RME 3.4.x or 3.5.x to RME 4.0.5 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.5. Ensure that the scripts work on the RME 4.0.5 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.5 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.5, 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 to RME 4.0.5

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

•Scheduled jobs that need to be executed.

These jobs must be recreated and you need to get the required approvals again.

•Application execution logs.

The structure and components of RME 4.0.5 are different from those in the earlier RME versions. 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.5 default configuration overrides the configurations of the earlier RME versions. For the admin settings of your RME 3.x system, see AdminSettings.txt file. This file is usually available in NMSROOT. You may use this file as a baseline to configure your RME 4.0.5 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.5.

Inventory

The inventory data not migrated from RME 3.4.x or 3.5.x to RME 4.0.5 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.5.

•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.5.

•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.5 is:

•Protocol order and archive location

The RME 4.0.5 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.5 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.5 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.5 is:

•Negation rules

In RME 3.4 or RME 3.5, negation rules are maintained in flat files. In RME 4.0.5, RME device packages maintain the negation rules.

•Insertion rules

In RME 4.0.5, 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.5 is:

•Admin Settings

Admin settings are stored in a flat file. You may access the file after migration. To configure RME 4.0.5 you need to refer to your old administration settings from the text file.

•Jobs and details

Jobs and their details are not migrated.

Syslog

The Syslog data not migrated from RME 3.4.x or 3.5.x to RME 4.0.5 is Admin settings. If 3.4.x or 3.5.x automated action, message filters and custom reports contain device names with wildcard characters, they are not migrated.

Change Audit

The Change Audit data not migrated from RME 3.4.x or 3.5.x to RME 4.0.5 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.5, 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.5, 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.

Note the following points about migration:

•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.5, 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-2 provides an overview of the local migration procedure when migrating from RME 3.4.x or 3.5.x to RME 4.0.5:

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

	Task	Reference
Step 1	Log in as root on the machine where RME 3.4.x or RME 3.5.x is installed.	—
Step 2	Back up your RME 3.4.x or RME 3.5.x data.	Upgrade From RME 4.0.x to RME 4.0.5
Step 3	Verify that your operating system is supported by RME 4.0.3.	Chapter 1, "Server Requirements and Recommendations"
Step 4	Install CS 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, page -xvi
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.	You need to perform a series of procedures to install RME 4.0.5. Proceed with the installations, in the order listed below:, page 2-2
Step 6	Install CS 3.0.5 and RME 4.0.5 from the LMS 2.6 CD ROM	Chapter 2, "You need to perform a series of procedures to install RME 4.0.5. Proceed with the installations, in the order listed below:"
Step 7	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 8	Perform post-installation tasks	Chapter 2, "Post Installation Checklist" and Chapter 4, "Preparing to Use RME Applications"

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

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

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

	Task	Reference
Step 1	Log in as root on the machine where RME 3.4.x or RME 3.5.x is installed.	—
Step 2	Back up your RME 3.4.x or RME 3.5.x data.
Step 3	Log in 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.	Chapter 1, "Server Requirements and Recommendations"
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, page -xvi
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.	--
Step 7	Install CS 3.0.5 and RME 4.0.5 from the LMS 2.6 CD ROM	Chapter 2, "You need to perform a series of procedures to install RME 4.0.5. Proceed with the installations, in the order listed below:"
Step 8	Transfer the RME 3.4.x or RME 3.5.x backup data to the RME 4.0.5 machine.	—
Step 9	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 10	Validate your upgrade license.	Validating Your Upgrade License
Step 11	Perform post-installation tasks.	Chapter 2, "Post Installation Checklist" and Chapter 4, "Preparing to Use RME Applications"

Upgrade From RME 4.0.x to RME 4.0.5

You can upgrade from any of the previous versions of RME to RME 4.0.5. This section consists of:

•Local Upgrade From RME 4.0.3, or 4.0.4 to RME 4.0.5

•Remote Upgrade From RME 4.0.3 or 4.0.4 to RME 4.0.5

Local Upgrade From RME 4.0.3, or 4.0.4 to RME 4.0.5

Table 3-4 provides an overview of the local upgrade procedure when upgrading from RME 4.0.3, or 4.0.4 to RME 4.0.5.

During local upgrade from RME 4.0.3 or RME 4.0.4 to RME 4.0.5,

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

•If you have a evaluation copy of RME 4.0.3 after upgrading to RME 4.0.5, if you want to update your evaluation license to valid LMS 2.6 license, follow the steps described in Chapter 5, "Registering Your License".

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

Table 3-4 Procedure for Local Upgrade from RME 4.0.3 or 4.0.4 to RME 4.0.5

	Task	Reference
Step 1	Log in as root to the machine where RME 4.0.3 or 4.0.4 is installed	—
Step 2	Back up your RME 4.0.3 or RME 4.0.4 data.	Backing Up Your RME 4.0.x Data
Step 3	Install RME 4.0.5 from the LMS 2.6 CD ROM.	You need to perform a series of procedures to install RME 4.0.5. Proceed with the installations, in the order listed below:, page 2-2
Step 4	Restore RME 4.0.3 or RME 4.0.4 data.	You need not run any scripts to migrate data. All necessary data is migrated to RME 4.0.5 during the upgrade.

Remote Upgrade From RME 4.0.3 or 4.0.4 to RME 4.0.5

Table 3-5 provides an overview of the remote upgrade procedure when upgrading from RME 4.0.3, or 4.0.4 to RME 4.0.5.

Table 3-5 Procedure for Remote Upgrade from RME 4.0.3 or 4.0.4 

	Task	Reference
Step 1	Log in as root to the machine where RME 4.0.3 or 4.0.4 is installed	—
Step 2	Back up your RME 4.0.3 or RME 4.0.4 data.	Backing Up Your RME 4.0.x Data
Step 3	Log in as root on the machine where you want to install RME 4.0.5.	—
Step 4	Verify that your operating system is supported by RME 4.0.5.	Chapter 1, "Server Requirements and Recommendations"
Step 5	Install RME 4.0.5 from the LMS 2.6 CD ROM. You need not run any scripts to migrate data. All necessary data is migrated to RME 4.0.5 during the upgrade.	You need to perform a series of procedures to install RME 4.0.5. Proceed with the installations, in the order listed below:, page 2-2
Step 6	Transfer the RME 4.0.3 or 4.0.4 backup data to the RME 4.0.5 machine.	—
Step 7	Restore RME 4.0.3 or RME 4.0.4 data.	Restoring the RME 4.0.x Backup Data

Backing Up and Restoring RME Data to RME 4.0.5

Data from the previous versions of RME, can be backed up and restored to a system, that has RME 4.0.5 installed. This section consists of:

•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

•Backing Up Your RME 4.0.x Data

•Restoring the RME 4.0.x Backup Data

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 RME 3.4.x or RME 3.5.x 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 RME 3.4.x or 3.5.x Data Using GUI

To back up RME 3.4.x or 3.5.x data using GUI 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. To restore the data:

---

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

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.5. 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.

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

Step 5 Start daemon manager after the migration is completed. To do this, enter:

net start crmdmgtd

You have migrated to RME 4.0.5.

---

Backing Up Your RME 4.0.x Data

You can back up data either using CLI or GUI.

Backing Up RME 4.0.x Data Using CLI

To back up using CLI, enter:

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.5 online help.

Backing Up RME 4.0.x Data Using GUI

To back up on RME 4.0.5 (Common Services 3.0.5), 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. To restore the data:

---

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

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 4.0.x backup data is available. This is mandatory.

•-gen version is the version to be migrated to RME 4.0.5. 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.

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

Step 5 Start daemon manager after the migration is completed. To do this, enter:

net start crmdmgtd

You have migrated to RME 4.0.5.

---

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.

---