Table Of Contents

CLI Utilities

CWCLI

Overview: CLI Framework (cwcli)

cwcli Global Arguments

Remote Access

Overview: cwcli config Command

Using the cwcli config Command for Batch Processing

Getting Started With cwcli config

Uses of cwcli config

Remote Access

Running cwcli config

cwcli config Command Parameters

Parameters For All cwcli config Commands

cwcli config Syntax Examples

cwcli config Core Arguments

Examples of cwcli config

cwcli config Command Man Page

Arguments

cwcli config Subcommand Man Pages

Overview: cwcli netconfig Command

cwcli netconfig Remote Access

Overview: cwcli export Command

Using the cwcli export Command

Running cwcli export changeaudit

Running cwcli export config

Running cwcli export inventory Command

XML Schema for cwcli export inventory Data

Overview: cwcli inventory Command

Using the cwcli inventory Command

Running the cwcli inventory cda Command

Running the cwcli inventory crmexport Command

Running the cwcli inventory deletedevice Command

Running the cwcli inventory getdevicestate Command

Overview: cwcli invreport Command

Overview: cwcli netshow Command

Running cwcli netshow Command

Executing Netshow CLI Remotely

Performance Tuning Tool

PTT Features

Profiles and PTT

Default Profile

Perftune - Windows and Perftune - Solaris

PTT Commands

.syslogConf.pl Utility

Software Management CLI Utility

Running cwcli swim Command

Running SWIM CLI Remotely

CLI Utilities

---

Resource Manager Essentials provides Command Line Interface (CLI) support. The CLI utilities that are supported by RME are:

•CWCLI

•Performance Tuning Tool

•.syslogConf.pl Utility

•Software Management CLI Utility

CWCLI

CiscoWorks Command Line Framework (CWCLI) is the interface or framework through which application functionality is provided.

The following are the cwcli applications:

•cwcli config is the configuration command-line tool of Resource Manager Essentials. cwcli netconfig command lets you use NetConfig from the command line.

•cwcli export is a command line tool that also provides servlet access to inventory, configuration and change audit data.

This can be used for generating inventory, configuration archive, and change audit data for devices in Resource Manager Essentials (RME).

•cwcli inventory is a RME Device Management application command line tool. This tool can be used for checking the device credentials, exporting the device credentials. You can also view the RME devices and delete the RME devices.

•cwcli invreport is a CiscoWorks command line tool which allows you to run previously created Inventory Custom Reports and also system reports. The output is displayed in the (CSV) Comma Separated Value format.

•cwcli netshow is a comand line tool that lets you use NetShow features from the command line. You can use the cwcli netshow commands to view, browse, create, delete, and cancel NetShow jobs and Command Sets.

This chapter contains the following sections:

•Overview: CLI Framework (cwcli)

•Overview: cwcli config Command

•Overview: cwcli netconfig Command

•Overview: cwcli export Command

•Overview: cwcli inventory Command

•Overview: cwcli invreport Command

•Overview: cwcli netshow Command

You can set the debug mode for CLIFramework and ConfigCLI in the Log Level Settings dialog box (Resource Manager Essentials > Admin > System Preferences > Loglevel Settings).

See Application Log Level Settings for further details.

Overview: CLI Framework (cwcli)

CLI Framework (cwcli) is a Command-Line Interface (CLI). This interface provides application-related functionality.

The CLI Framework supports the following tasks for the RME applications:

•Parsing the command line for the applications.

•Easy logging and messaging capabilities

•Authentication and authorization for individual applications

•Remote access support.

SYNOPSIS

The command line syntax is as follows:

cwcli application command GlobalArgs AppSpecificArguments

•application specifies one or more RME applications that use the framework. For example, config, export, inventory, invreport, and netconfig.

•command specifies which core operations are to be performed for a particular service.

•GlobalArgs specifies arguments common for all CLI. For example, username, password, log, debug, etc.

•AppSpecificArguments are the additional parameters required for each core command.

You should enter the application name immediately after cwcli and the command name, after the application name. All other GlobalArgs arguments can be specified in any order.

Apart from the applications, Global args (-u user, -p password, -l logfile, -m email, -d debuglevel) framework also supports two generic commands. They are:

•-v—Version of the CLI interface.

•-help—All the applications that can be invoked using the framework.

SYNTAX

cwcli  -v

cwcli  -help 

cwcli Global Arguments

The following table shows the cwcli config command arguments you can specify with all commands.

cwcli arguments	Description
-u userid	User ID. Field is required.
-p password	It is the password for the specified User ID. If you enter the password at the command line, a message appears: * Warning * The -p option is highly insecure and *not* recommended. See -u option for more details. If the password is not specified in the command line, framework searches for the password in the file pointed to by the CWCLIFILE environment variable. If the variable is not set, you are prompted to enter the password. * Warning * CWCLIFILE Environment variable not set. Enter your password See Setting CWCLIFILE Environment Variable for more details.
-device devicename or device_list	Display name of the device added into DCR. You can use comma separated displaynames and wild card character %. For example, if there are two devices with names Rtr12 and Rtr13, Rtr% will display both the devices. To use all the devices, use -device %.
-view view_list	If the data needs to be generated for all the devices in a specific group, you can use the -view argument. You can use this argument to generate data for devices in all RME device views including system-defined groups and user-defined groups. You can enter multiple group name separated using a comma. For view name, you have to enter the fully qualified path as in the Group Administration window. To separate the path you must use forward slash only. For example, -view "/RME@ciscoworks_servername/All Devices"
-ipaddress address	Device IP4 address as entered in the Device and Credential Repository. You can enter multiple IP address with comma separated. You cannot use this option with -device, -view , or -input. Also, you cannot specify wildcard characters.
-l logfile	Must be a relative name. By default ConfigCLI.log and cli.log files under NMSROOT/log directories are used. If the relative name is specified then the log messages are logged into the file specified. The file is created under the NMSROOT/log directory. For example, cwcli config export -u alpha -p beta -device % -l export.log. In this case, export.log is created under the NMSROOT/log directory.
-m email	Email address to mail the command output to. You can enter single or comma separated email IDs.
-d debuglevel	Enables debugging to command-line tool. Specifies debugging verbosity. Default is least verbose.
-help	Displays usage information.
-input	Text file containing arguments for each device.

---

Note -d and -l arguments are supported for backward compatibility. In the CiscoWorks LMS Portal home page, select RME > Admin > System Preferences > Loglevel Settings > CLI Framework to set debug levels.

---

When using wildcards, you must use the percent sign (%), not an asterisk (*), as shown in the following examples:

%device (lists all devices that end with the suffix `device')

dev% (lists all devices that start with the prefix `dev')

% (lists all devices RME manages)

Remote Access

CLI framework (cwcli) offers remote access facilities to allow you to invoke cwcli commands from the client in the same way as they run on the RME server.

The name of the servlet is /rme/cwcli.

The following is the servlet to be invoked to execute any command:

For post request,

http://rme-server:rme-port/rme/cwcli payload XML file

For get request,

http://rme-server:rme-port/rme/cwcli?command=cwcli config commandname -u user -p BAse64 encoded pwd -args1 arg1value...

---

Note Use <arg> and <argval> tags when the argument is a file.

---

The contents of the payload xml file is as follows.

<payload>

<command>

cwcli config export -u admin -p <Base64Enoced pwd> -device 1.1.1.1 -xml

</command>

<arg>

</arg>

<arg-val>

</arg-val>

</payload>

For example to execute the cwcli config import comand payload.xml is as follows:

<payload>

<command>

cwcli config import -u admin -p <Base64Enoced pwd> -device 10.77.240.106

<arg>

-f

</arg>

<arg-val>

tempfile

</arg-val>

</command>

</payload>

The Remote Access servlet creates a temporary file with the contents specified between the arg-val tags for the import command. On the server the command is executed as
cwcli config import -u admin -p Base64Enoced pwd -device 10.77.240.106 -f tempfile

Here, the tempfile contains the configuration of the device that you want to import.

For example,

perl samplescript.pl http(s)://rme-server:rme-port/rme/cwcli payloadXML

To invoke the servlet using a script, see the Sample Script to Invoke the Servlet.

The script and the payload file should be residing in the client machine.

---

Note For the secure mode (HTTPS) the port number is 443. The default port for CiscoWorks server in HTTP mode is 1741.

---

Sample Script to Invoke the Servlet

#!/opt/CSCOpx/bin/perl

use LWP::UserAgent;

$temp = $ARGV[0] ;

$fname = $ARGV[1] ;

open (FILE,"$fname") || die "File open Failed $!";

while ( <FILE> )

{ $str .= $_ ;

}

print $str ;

url_call($temp);

#-- Activate a CGI:

sub url_call

{

my ($url) = @_;

my $ua = new LWP::UserAgent;

$ua->timeout(1000);

# you can set timeout value depending on number of devices

my $hdr = new HTTP::Headers 'Content-Type' => 'text/html';

my $req = new HTTP::Request ('POST', $url, $hdr);

$req->content($str);

my $res = $ua->request ($req);

my $result;

if ($res->is_error)

{

print "ERROR : ", $res->code, " : ", $res->message, "\n"; $result = '';

}

else {

$result = $res->content;

if($result =~ /Authorization error/)

{ print "Authorization error\n";

}

else {

print $result ;

}

}

}

Setting CWCLIFILE Environment Variable

You can store your username and password in a file and set a variable CWCLIFILE which points to the file, if you want to avoid the -p argument which will reveal the password in clear text in CLI.

You should maintain this file and control access permissions to prevent unauthorized access.

If CWCLIFILE is set only to filename instead of full path, cwcli framework looks for the current working directory.

If you use the -p argument, even after setting the CWCLIFILE variable, the password is taken from the command line instead of CWCLIFILE. This is not secure and usage of this argument is not recommended.

The password must be provided in the file in the following format:

username password

Where username and password are the CiscoWorks login credentials. The delimiter between the username and password is a single space.

You must enter a comma as the delimiter if the password is blank. Otherwise, cwcli framework will fail to validate the password.

Example to run the cwcli command with the CWCLIFILE file:

On Windows, at the command prompt enter:

C:\Program Files\CSCOpx\bin>set CWCLIFILE=D:\ciscoworks\password.txt

C:\Program Files\CSCOpx\bin>cwcli export changeaudit -u admin -view "/RME@ciscoworksservername/Normal Devices"

Where the file, password.txt contains the username and password for CiscoWorks server.

Overview: cwcli config Command

The cwcli config command-line tool performs the following core functions on one or more devices and the configuration archive:

•Moves configuration files from the configuration archive to one or more devices.

•Transfers the configuration files from devices to the archive if the configuration running on a device is different from the latest archived version

•Imports configuration files from the file system and pushes them to one or more devices, which updates the configuration archive

•Merges the startup configuration files with the running configuration files

•Copies the running configuration files to the startup configuration files

•Copies a configuration file to the startup configuration files

•Copies the difference between a configuration file and the running configuration to the running configuration files. This makes the configuration in the file available on the running configuration.

•Reboots running devices to load a running configuration with its startup configuration

In addition, cwcli config performs the following core functions on the configuration archive:

•Exports configurations from the archive to the filesystem

•Compares any two configuration files in the archive based on version or date

•Deletes configurations older than a specified date from the configuration archive

Using the cwcli config Command for Batch Processing

In addition to using the graphical-based device configuration functions, you can use the cwcli config command-line utility to perform batch processing tasks on the configuration archive, devices, or on both.

For more details see these sections:

•Running cwcli config

•cwcli config Core Arguments

•Examples of cwcli config

On platforms other than Windows 2000, all files created by cwcli config are owned by casuser. They belong to the same group as the user (casuser) who created the files, and have read-write access for both casuser and the group.

---

Note Your login determines whether you can use this argument.

---

Getting Started With cwcli config

cwcli config is a command-line tool. This tool is like an interface between the user and the device and the configuration archive.

Generally, the configuration archive automatically registers modifications to the device's configuration in archived, version-based files. Over time, multiple configurations of a device accumulate in the archive. Typically, the latest version is the configuration running on the device.

Uses of cwcli config

With cwcli config, you can:

•Device and Archive Updates

Modify a device's running configuration. You can allow personnel of your organization to modify the device's configuration without explicitly providing them with Telnet access to the device.

•Deleting Configurations

Delete unwanted versions of the configuration file from the archive. This is a command-line variant of the UI purge feature.

•Comparing Configurations

Generate 'diffs' of different configuration versions of the same device to find out what modifications were made. This is a command-line counterpart for GUI-based reports.

Device and Archive Updates

Whenever you use cwcli config to update the running configuration of the device, the tool also archives the newly written configuration to the archive, bypassing the auto-detection mechanism.

Getting a Version of the Device Configuration

To obtain a version of the device's configuration from the device, modify it, and then write it back to the device. You use two features of cwcli config to do this.

1. Use the export command to obtain a copy of the desired configuration version file.

2. Edit and deploy it on the device using the import function. If the update succeeds, import also archives the configuration in the archive as the latest version.

Example:

cwcli config export -u user -p pass -device zebra.domain.com -version 3 -f zebraconf

version 3 of device zebra's configuration has been obtained from the device. It is available in the file zebraconf. You must edit the file and make the necessary modifications.

cwcli config import -u user -p pass -device zebra.domain.com -f zebraconf

The edited file is written back to the device and archive. If there were five configurations originally, a sixth one is now added.

If you want to update the running config on the device, and are certain that the latest archived version is the same as the running config, then you can obtain the latest version as follows:

cwcli config export -u user -p pass -device zebra.domain.com -f zebraconf

the latest version is copied to file zebraconf.

After writing the edited configuration to the device, you might want to reboot the device. You can do this automatically from cwcli config by using the -reboot argument to the import command:

cwcli config export -u user -p pass -device zebra.domain.com -f zebraconf -reboot

In addition, you might want to write file zebraconf to both the running as well as the startup configuration. To do this, enter the following command:

cwcli config export -u user -p pass -device zebra.domain.com -f zebraconf -save

Reverting to Earlier Configuration Version

For running configuration, use either compare or export to decide, which version to revert to.

For VLAN configuration, look into the Configuration Version Report for the device to find the versions for which VLAN configuration is also archived. Then use put to deploy the desired version.

The put function gets the requested version from the archive, writes it to the device. For Running configuration, it archives it as the latest version of that device.

Example:

cwcli config put -u user -p pass -device zebra.domain.com -version 3

version 3 of device zebra's configuration is extracted from the archive and written to the device. It is also stored in the archive as the latest version.

Example:

cwcli config put -u user -p pass -device zebra.domain.com -version 3 -filetype vlan

version 3 of device zebra's vlan configuration is extracted from the archive and written to the device.

Like import, the put function allows you to reboot the device using the -reboot argument, and to update the startup configuration using the -save argument.

Writing Startup Configuration to Running Configuration

To write the startup configuration of the device to its running configuration. Use the start2run function of cwcli config to retrieve the startup configuration from the device, and then write it back to the device's running configuration. The new running configuration is archived as the latest version.

Example:

cwcli config start2run -u user -p pass -device zebra.domain.com

To ensure that the running configuration on the device is stored in the archive, that is, synchronize the archive with the device. Use the get function to do so.

Example:

cwcli config get -u admin -p admin -device zebra.domain.com

The running configuration of device zebra is retrieved from the device and archived as the latest version, only if there is a need to do so. However, if the running configuration does not differ from the latest archived version, then the archival does not take place.

Configuration updates can be performed on multiple devices at once. For more details see "Running cwcli config on Multiple Devices" section.

Deleting Configurations

Use the delete function of cwcli config to delete unwanted versions from the archive, to conserve disk space, and to reduce visual clutter on reports.

Example:

cwcli config delete -u user -p pass -device zebra.domain.com -version 2 5

All versions between and including 2 and 5 are removed from the archive. There is also a time-stamp based variant.

Comparing Configurations

Use the compare function to compare any two versions of the archived configuration files of one or more devices. The compare function also lists down the entire configuration changes based on the timestamp.

Example:

cwcli config compare -u user -p pass -device zebra.domain.com -version 2 5

cwcli config can only compare the archived configuration files. The compliance report is stored in the job directories.

Remote Access

cwcli config uses remote access facilities offered by the CLI framework to allow you to invoke the cwcli config commands from the client in the same manner they would execute them on the RME server.

The name of the servlet is /rme/cwcli.

All the command can be executed remotely.

---

Note For the secure mode (HTTPS) the port number is 443. The default port for CiscoWorks server in HTTP mode is 1741.

---

Running cwcli config

The cwcli config command is located in the following directories, where install_dir is the directory in which RME is installed:

•On UNIX systems, /opt/CSCOpx/bin

•On Windows systems, install_dir\CSCOpx\bin

The default install directory is C:\Program Files.

If you install RME on Windows on an NTFS partition, only users in the administrator or casuser group can access cwcli config.

Users with read-execute access to the CSCOpx\files\archive directory and the directories under that can also use cwcli config.

Running cwcli config on Multiple Devices

You can run cwcli config simultaneously on multiple devices. Details vary from command to command. This section describes how to apply import on multiple devices. Details of multiple-device syntax for other commands are described under the DESCRIPTION in the man page.

The commands, such as put, import, write2run and write2start accept only one device on the command line. If you want to apply the command to multiple devices, enter the names of those devices and any arguments in a text file.

For example, assume that you want to deliver the configuration file serviceconf to devices, antelope and rhino. Also assume that you want to reboot rhino. The command line of cwcli config is as follows:

cwcli config import -u admin -p admin -input device-list -m root@netcontrol.domain.com

You do not want the output of the command to go to stdout. Instead, you want it to be mailed to the superuser at host netcontrol.

Device-list is a text with the following contents:

# comments start with a leading hash symbol. Write serviceconf to rhino and # antelope. reboot antelope.

-device rhino.domain.com -f serviceconf

-device antelope.domain.com -f serviceconf -reboot

# end of input file device-list

Additional Information

The examples in this man page are not comprehensive. There are many other scenarios in which cwcli config can be used.

For example, if you want to modify the running configuration on the device, without using the latest archived version, considering the latest may not be the same as the running configuration. You can apply the get command and then export and import. Various combinations of the features can be used.

You can also use cwcli config in UNIX cron jobs to schedule config updates in advance.

Also, the output generated by cwcli config can be logged to a file and sent to any recipient through email. A host of additional arguments can be applied on other commands.

cwcli config Command Parameters

Using the cwcli config commands you can manipulate, deploy and archive your device configuration files.

•Using the Compare Command

•Using the Delete Command

•Parameters For All cwcli config Commands

•cwcli config Syntax Examples

Using the Compare Command

When you specify the compare command, both -version and -date are optional.

•If you do not specify -version or -date, the latest configuration is compared with the previous version.

•If you do specify -version or -date, and the value you enter is the latest version or date, that configuration is compared with the previous version.

Using the Delete Command

When you specify the -date command, you must specify -version or -date.

If you specify only one date, all versions archived up and including that date are deleted.

To delete a version archived on a particular date, specify two dates that are the same date as the archived version date. The latest two versions of configuration can never be deleted from the archive. Be careful while using the delete command.

Parameters For All cwcli config Commands

The -d and -l arguments are supported for backward compatibility.

In the CiscoWorks LMS Portal home page, select Resource Manager Essentials > Admin > SystemPreferences > Loglevel Settings > ConfigCLI to set debug levels.

When using wildcards, you must use the percent sign (%), not an asterisk (*), as shown in the following examples:

%device

dev%

%device%

The following table lists the cwcli config command-specific arguments and which commands you can use the arguments with:

cwcli config arguments	Applicable Commands	Description
-baseline	createdeployparamfile, directbaselinedeploy	Specifies the name of the Baseline template for which the parameter file has to be created.
-date	compare, delete	•Compare –If you specify one date, the latest configuration version is compared with the most recently archived version on that particular date. –If you specify two dates, the most recently archived version of the first date is compared with the most recently archived version of the second date. •Delete –If you specify one date, all versions archived up to this date are deleted. –If you specify two dates, all versions archived between and on those dates are deleted.
-enable_pass	import, put, write2run, write2start, run2start, start2run, deploycomplianceresults, compareanddeploy, reload	Specifies execution mode Base64 encoded Password for connecting to device.
-f filename	export, import	Specifies fully qualified pathname of configuration file to import to or export from. •If you do not specify this argument, the current working directory is assumed. •If you do not specify this argument when importing or exporting a single device configuration, default filename, devicename.cfg, in the current working directory is assumed. The -f argument applies only to single devices. To perform the operation on multiple devices, you must specify the -input argument.
-input inputlist	Applicable to all commands except compareanddeploy, createdeployparamfile, deploycomplianceresults, and directbaselinedeploy,	You must enter -input inputlist to run commands, such as put and import, on multiple devices. The parameter, inputlist is a text file containing arguments for each device. A line starting with # is treated as a comment. For example, an input list file might look like this: #comment line -version version [-save] [-reboot] device_name -version version [-save] [-reboot] device_name
-jobid	createdeployparamfile	Used to specify the job identifier of the previously executed comparewithbaseline job.
-l	createdeployparamfile, directbaselinedeploy	Specifies the file to log the results of the command.
-listonly	write2run	Displays difference between the latest running configuration for device in configuration archive and new configuration that is generated, without downloading changes.
-m	createdeployparamfile, directbaselinedeploy	Specifies an email address to send the results of the command.
primary_pass	import, put, write2run, write2start, run2start, start2run, deploycomplianceresults, compareanddeploy, reload	Specifies primary user name for connecting to device.
-primary_user	import, put, write2run, write2start, run2start, start2run, deploycomplianceresults, compareanddeploy, reload	Specifies primary user name for connecting to device.
-reboot	import, put	After successfully pushing a configuration to a device, device reboots. By default the device does not reboot. For IOS devices, you must also specify -save to avoid losing configuration changes when rebooting.
-save	import, put	Applies to Cisco IOS devices only. Performs a write memory after pushing the configuration. The default is no write memory.
-timeout	import, put, write2run, write2start, run2start, start2run, comparewithbaseline, deploycomplianceresults, compareanddeploy, get, reload	Specifies the duration of the interval in seconds between two successive polling cycles. Archive management is polled according to the interval specified to retrieve and display the job results.
-version version	compare, delete, export, put	•For put and export, you can specify one version of the configuration in the archive. •For compare, you can specify two versions, which are compared with each other. If you specify only one version, that is compared with latest archived version. •For delete, if you specify one version, that version is deleted. If you specify two versions, all versions in between and including those version are deleted.

cwcli config Syntax Examples

The following examples demonstrate the cwcli config command syntax. Square brackets ([ ]) indicate arguments. A pipe (|) acts as a delimiter. This means that only one of the listed entries can be specified.

---

Note Make sure you first use the cwcli config command in a test environment before running the command in production. This is to avoid any loss of data when a device is rebooted or a configuration is overwritten.

---

The following command extracts the running configurations from all devices:

cwcli config get -u user -p password -device %

The following command exports the configuration of all the devices from the archive and puts the configuration into the file, devicename.cfg. This is the default file name because -f is not specified:

cwcli config export -u user -p password -device %

If there is more than one device in the default view All, you see an error message because the export command does not accept multiple device names on the command line. You must specify the -input argument to run the export command on more than one device.

The following table shows more syntax examples:

Argument	Syntax	Notes
no arguments	cwcli config -u user -p password [-v -help]	If you do not specify arguments, cwcli config shows command usage (-help)
compare	cwcli config compare -u userid -p password [-d debuglevel] [-m email] [-l logfile] { -device list | -view name | -device list -view name |-ipaddress list } { -version version1 [version2] | -date date1 [date2] }	Specify versions to compare using -version or -date argument. When specifying a date, use format mm/dd/yyyy. If you do not specify a date or a version, the latest two archived configurations are compared.
compareanddeploy	cwcli config compareanddeploy -u userid -p password [-d debuglevel] [-m email][-l logfile] {-device list | -view name | -device list -view name |-ipaddress list }{ -baseline baselinefile }[ -timeout seconds] [-input argumentFile] [-primary_user primary user name] [-primary_pass Base64 encoded primary password] [-enable_pass Base64 encoded enable password]	Creates a job that compares the given Baseline template with the latest version of the configuration for a device and downloads the configuration to the device if there is non-compliance.
comparewithbaseline	cwcli config comparewithbaseline -u userid -p password [-d debuglevel] [-m email][-l logfile] { -device list | -view name | -device list -view name |-ipaddress list }{ -baseline baselinefile }[ -timeout seconds] [-input argumentFile]	Creates a job that compares the given Baseline template with the latest version of the configuration for a device. In case of non-compliance, the non-compliant commands are displayed.
delete	cwcli config delete -u userid -p password [-d debuglevel] [-m email] [-l logfile] { -device list | -view name | -device list -view name |-ipaddress list } { -version version1 [version2] | -date date1 [date2] }	Deletes the specified device configuration from the archive. Use -date or -version argument to specify configurations to delete. If you specify two dates, all configurations archived between those dates are deleted. If you specify two versions, all configurations between and including the versions are deleted.
deploycomplianceresults	cwcli config deploycomplianceresults -u userid -p password [-d debuglevel] [-m email][-l logfile] { -substitute datafile } {-jobid jobID}[ -timeout seconds][-primary_user primary user name] [-primary_pass Base64 encoded primary password] [-enable_pass Base64 encoded enable password]	Creates a job that uses the previously executed comparewithbaseline job to get the non-compliance commands and create a job. It replaces the parameters in the non-compliant commands with the values from the data file. The commands are then downloaded to ensure compliance with the baseline configuration.
export	cwcli config export -u userid -p password [-d debuglevel] [-m email] [-l logfile] { -device list | -view name | -device displayName -view name | -ipaddress list } [-f filename] [-version number] [-xml] [-input argumentFile]	Retrieves a configuration version for a device from the archive and writes it to a file. Exported configurations are named devicename.cfg if -f argument is not used.
get	cwcli config get -u userid -p password [-d debuglevel] [-m email] [-l logfile][-timeout seconds] [-filetype running|startup|runningstartup] { -device list | -view name | -device list -view name |-ipaddress list }	Creates a job that fetches the configuration from the device and stores it in the archive.
import	cwcli config import -u userid -p password [-d debuglevel] [-m email] [-l logfile][-timeout seconds] { -device displayName |-ipaddress address } [-f filename] [-save [-reboot]][-input argumentFile]	Creates a job that retrieves the configuration from a file and transfers it to the device. The job is added to the device running configuration. It then polls Archive Management at periodic intervals to get the job results and display it. Specify -input to operate on more than one device. You cannot specify wildcards or more than one device.
listversions	cwcli config listversions -u userid -p password [-d debuglevel] [-m email] [-l logfile] { -device list | -view name | -device displayName -viewname | -ipaddress list} -baseline	Lists the versions of the configuration archived for a device on the main branch or the Baseline templates applicable to a device.
put	cwcli config put -u userid -p password [-d debuglevel] [-m email] [-l logfile] { -device displayName |-ipaddress address -version number}[-config 1|2][-save [-reboot]] [-input argumentFile][-timeout seconds] [-filetype vlan|running][-primary_user primary user name] [-primary_pass Base64 encoded primary password] [-enable_pass Base64 encoded enable password]]	Creates a job that retrieves the configuration from the configuration archive and pushes it to the device. Specify -input to operate against more than one device. You cannot specify wildcards or more than one device. You must specify a version.
reload	cwcli config reload -u userid -p password [-d debuglevel] [-m email][-l logfile] { -device list | -view name | -device list -view name |-ipaddress list }[-input argumentFile][-timeout seconds][-primary_user primary user name] [-primary_pass Base64 encoded primary password] [-enable_pass Base64 encoded enable password]	Creates a job that reboots devices. The configuration loaded runs with the startup configuration.
run2start	cwcli config run2start -u userid -p password [-d debuglevel] [-m email][-l logfile]{ -device list | -view name | -device list -view name | -ipaddress list}[-config 1|2] [-input argumentFile][-timeout seconds][-primary_user primary user name] [-primary_pass Base64 encoded primary password] [-enable_pass Base64 encoded enable password]	Creates a job that overwrites the startup configuration of device with running configuration. Specify multiple devices with -device argument by separating each device name with comma or with -input argument, which takes filename containing the multiple devices as an argument.
start2run	cwcli config start2run -u userid -p password [-d debuglevel] [-m email][-l logfile] { -device list | -view name | -device list -view name | -ipaddress list } [-config 1|2] [-input argumentFile][-timeout seconds] [-primary_user primary user name] [-primary_pass Base64 encoded primary password] [-enable_pass Base64 encoded enable password]	Creates a job that merges the startup configuration with running configuration. Specify multiple devices with -device argument by separating each device name with comma or with -input argument, which takes filename containing the multiple devices as an argument.
write2run	cwcli config write2run -u userid -p password [-d debuglevel][-m email][-l logfile] { -device displayName | -ipaddress address } -f filename [-config 1|2][-listonly][-input argumentFile][-timeout seconds][-primary_user primary user name][-primary_pass Base64 encoded primary password][-enable_pass Base64 encoded enable password]	Creates a job that downloads the differences between the specified file and the latest version in the archive for the specified device. If you specify -listonly, difference is displayed but no changes are downloaded. To run command on multiple devices, use -input argument, which takes a filename as an argument.
write2start	cwcli config write2start -u userid -p password [-d debuglevel] [-m email][-l logfile] { -device displayName |-ipaddress address -f filename} [-config 1|2][-input argumentFile][-timeout seconds][-primary_user primary user name][-primary_pass Base64 encoded primary password] [-enable_pass Base64 encoded enable password]	Creates a job that erases contents of device startup configuration and writes contents of given file as new startup configuration. You must specify a filename. To run a command against multiple devices, use -input argument.

cwcli config Core Arguments

cwcli config Argument	Description
compare	Compares last two configurations in archive, specific configuration versions, or configuration changes based on a specified date. To run this command on multiple devices, specify -device argument or -input argument.
delete	Deletes configurations older than specified date or version from archive. To run this command on multiple devices, specify -device argument or -input argument.
export	Retrieves latest configuration from archive and writes it to specified file. To run this command on multiple devices, specify -input argument.
get	Pulls configuration from device to configuration archive if configuration is different from latest archived configuration. To run this command on multiple devices, specify -device argument or -input argument.
import	Imports configuration from specified file and pushes it to devices. To run this command on multiple devices, specify -input argument.
put	Pushes configuration files from RME configuration archive to device based on version. To run this command on multiple devices, specify -input argument.
reload	Reboots devices to reload running configuration with startup configuration. To run this command on multiple devices, specify -device argument or -input argument.
run2start	Overwrites startup configuration with running configuration. To run this command on multiple devices, specify -device argument or -input argument.
start2run	Merges startup configuration with running configuration. To run this command on multiple devices, specify -device argument or -input argument.
write2run	Downloads difference between latest running configuration for the device in configuration archive with configuration in file specified by -f argument. To run this command on multiple devices, specify -input argument.
write2start	Erases the contents of the device's startup configuration and writes the contents of the given file as the device's new startup configuration. To run this command on multiple devices, specify -input argument.

Examples of cwcli config

The following cwcli config command retrieves configurations for all devices in the CiscoWorks home_routers domain and stores the configurations in Sybase:

cwcli config get -u adam -p max -view home_routers

where home_routers is an RME device view.

The following cwcli config command reads inputfile and, for each device listed, pushes the appropriate configuration to that device:

cwcli config import -U adam -P max -input /tmp/inputfile

cwcli config Command Man Page

This man page is also accessible from the command line of a CiscoWorks server installed on a UNIX system.

To view the man page, add the path install_dir/CSCOpx/man to the MANPATH variable. Then you can enter the command man cwcli config from any directory.

You can also access man pages for each cwcli config command by entering the command man cwc-command, where command is the command name (for example, export).

The man pages for each subcommand are also available in this help system.

NAME

cwcli config CiscoWorks command line interface for the device configuration archive

SYNOPSIS

cwcli config command {-arg1 [arg1Value] -arg2 [arg2Value] -argN [argNValue]}

cwcli config -help

DESCRIPTION

cwcli config is a CiscoWorks command line tool that allows you to access the configuration archive or configurations on devices. You can use cwcli config to update, export, and import configurations on devices and in the archive. You can also compare configurations and delete old configurations.

To get a list of supported commands, run the command

cwcli config -help

or

cwcli config?

Help on each command can be obtained in the following manner:

cwcli config command -help

For example:

cwcli config export -help

Additionally, man pages are available on UNIX installations for individual commands. To view the man page for any command, enter:

man cwc-command

For example:

man cwc-export

Arguments

Many of the arguments are common across all commands. These arguments can be broadly classified as those that are expected by every command (function independent) and those that are specific to the context of a command.

•Mandatory Arguments

•Function-independent Arguments

•Function-dependant Arguments

•Function-specific Arguments

•Common Arguments

•Command Arguments

Mandatory Arguments

You must use the following arguments with all commands.

-u userid

Specifies the CiscoWorks username. You must define an environment variable cwcli CWCLIFILE with value set to a filename, which will contain the corresponding password.

The file has to be maintained by you. You can control the access permissions of this file to prevent un-authorized access. cwcli config looks for current working directory if cwcli CWCLIFILE is set to only file name instead of full path.

If -u argument is used along with -p argument, the password is taken from the command line instead of cwcli CWCLIFILE. This is not secure and usage of this argument is not recommended.

The password must be provided in the file in the following format:

username password

Where username is the CiscoWorks user name given in command line. The delimiter between username and password is single blank space. You must provide the delimiter if the password is blank

Otherwise, cwcli config will not validate the password. The password file can contain multiple entries with different user names. The password of the first match is considered in case of duplicate entries.

See Setting CWCLIFILE Environment Variable for more details.

Function-independent Arguments

You can use the following arguments without any commands:

-help

When run with the -help argument, cwcli config displays a list of all supported commands and a one-line description of the command.

-v

When run with the -v argument, cwcli config displays cwcli config version information.

Function-dependant Arguments

You can use the following arguments only with commands:

-p password

Specifies the password for the CiscoWorks username.

---

Warning SECURITY WARNING: If -p password is used, the password is read from the command line instead of cwcli CWCLIFILE. This is highly insecure and *not* recommended. See -u argument for more details. See Setting CWCLIFILE Environment Variable for more details.

---

-d debuglevel

Sets the debug level based on which debug information is printed. debuglevel is a numeric value between 1 and 5.

-f filename

Specifies the name of the file to which the retrieved configuration is written. If not specified, devicename.cfg is assumed.

-l logfile

Logs the results of the cwcli config command to the specified log filename.

-m mailbox

Mails the results of the cwcli config command to the specified email address.

Function-specific Arguments

You can use the following arguments only with specific commands:

-baseline

Used with the compareanddeploy, deploycomplianceresults, listversions, createdeployparamfile, directbaselinedeploy, or comparewithbaseline function, specifies the name of the Baseline template that is compared with the latest configuration version of the device.

If there are commands in the baseline configuration file that are not compliant with the latest configuration of the device in the archive, they are downloaded to the device.

---

Note The Baseline template must not contain any parameters for the command to succeed.

---

-date date1 date2

Used with the compare or delete command, specifies the configuration date(s) to compare or delete. Use the format mm/dd/yyyy.

-device name

Used with the export, import, or put function, specifies the name of the device. You can specify a wildcard, %, in the device name to match any device(s) that have the same textual pattern.

-device list

Used with the get, start2run, compare, compareanddeploy, comparewithbaseline, deploycomplianceresults, listversions, put, run2start, start2run, write2run or delete commands

Specifies the list of device names separated by commas. You can specify a wildcard, %, in the device list to match device(s) that have the same textual pattern.

- ipaddress list

Used with the get, start2run, compare, compareanddeploy, comparewithbaseline, deploycomplianceresults, listversions, put, run2start, start2run, write2run or delete commands.

Specifies IP4 address as entered in the Device and Credential Repository. You can enter multiple IP address with comma separated.

You cannot use this option with -device, -view, or -input. Also, you cannot specify wildcard characters.

-filetype type

Used with the put function, specifies the type of the configuration (running/vlan) that should be written to the device.

-f filename

Used with the directbaselinedeploy, export, import, write2run or write2start function, specifies the name of the file to which the configuration from archive should be exported to. Used with the import function, specifies the name of the file that contains the configuration to import.

---

Note -f argument must not be specified when -view or -device % is used. If used, the given file will be overwritten with the configuration retrieved for other devices.

---

-input listfile

Used with the export, import, compareanddeploy, comparewithbaseline, deploycomplianceresults or put function, specifies the name of the file containing the arguments for multiple devices.

The contents of the file must be similar to those described in the Input List File Format section later in this man page.

-listonly

Used with the write2run function, lists the differences between the running configuration and the specified configuration file.

-reboot

Used with the import or put function, reboots the device after the configuration has been written to the device.

-save

Used with the import or put function, saves the configuration written to the device to the device's memory.

-timeout

Used with the compareanddeploy, deploycomplianceresults, import, put, run2start, start2run, write2run or comparewithbaseline function, specifies the duration of the interval in seconds between two successive polling cycles.

-version number

Used with the export function, specifies the configuration version to retrieve from the archive. Used with the put function, specifies the configuration version to load from the archive and push to the device.

-version version1 version2

Used with the compare, or delete function, specifies the configuration version(s) to compare or delete.

-view name

Specifies the device view where the device name specified with -device argument is located. If -device argument is not specified, performs the operation on all devices in the view. More details are described in the -view Argument Usage section later in this man page.

-xml

Creates an XML file with the name of the device containing the configuration retrieved.

Input List File Format

For commands that do not accept multiple device names on the command line, such as put, import, and export, you can create an input list file that contains a list of devices to perform the operation on.

The contents of the input list file are a sequence of lines. Each line specifies a device name and the arguments to apply to that device. The arguments must be specific to the function. You cannot include view names in the input list file. You must specify view names on the command line. You can include comments in the input list file by starting the each commented line with #.

Input List File Example:

For the command

cwcli config put -u userid -p password -view myView -input ~/todo_list

An example of the input list file ~/todo_list is # Comment line.

-version 3 -reboot -device enm-2501.cisco.com

-version 2 -save -device enm-4500.cisco.com

-view Argument Usage

If both -device and -view are specified, the devices in that view and the devices specified against -device are considered.

For example, assume that -view has two devices D1 and D2 and D3 is specified against -device, then all the three devices D1, D2 and D3 are considered.

-view Argument Usage Examples:

Search for a device in a specified view:

cwcli config export -u admin -p admin -view myView -device myDevice

cwcli config Subcommand Man Pages

Each cwcli config command has a man page. You can access these man pages from the command line of a CiscoWorks server installed on a UNIX system.

To view the man pages, add the path:

install_dir/CSCOpx/man to the MANPATH variable.

Then you can enter the command
man cwc- command

where command is the command name. For example, export.

This topic contains the man pages for the following cwcli config subcommands:

•compare

•comparewithbaseline

•compareanddeploy

•delete

•deploycomplianceresults

•export

•get

•import

•put

•reload

•run2start

•start2run

•write2run

•write2start

•listversions

•createdeployparamfile

•directbaselinedeploy

compare

Name	cwcli config compare - CiscoWorks cwcli config compare function
Syntax	cwcli config compare -u userid -p password [-d debuglevel] [-m email] [-l logfile] { -device list | -view name | -device list -view name | -ipaddress list } { -version version1 [version2] | -date date1 [date2] } cwcli config compare -help
Description	compare lists the differences between versions of a device configuration. You can specify the versions to be compared by using the -version argument or the -date argument. •If you specify the -version argument with only one version number, that version is compared with the latest archived configuration of the device. •If you specify the -date argument with only one date, the configuration version with that date is compared with the latest archived configuration. When specifying a date, use the format mm/dd/yyyy. •If you do not specify either a date or a version, the latest two archived configurations are compared. You can specify multiple devices by separating each device name with a comma. The output of the Compare function can be interpreted as follows: –Lines preceded by '+' sign signify those occurring only in the first version but not in the latter. –Lines preceded by '-' sign signify those occurring only in the latter version but not in the first. –Lines preceded by '<' and '>' connote those which are present in both files but differ from each other.

compareanddeploy

Name	cwcli config compareanddeploy - CiscoWorks compare and download configuration with Baseline template function.
Syntax	cwcli config compareanddeploy -u userid -p password [-d debuglevel] [-m email][-l logfile] { -device list | -view name | -device list -view name |-ipaddress list }{ -baseline baselinefile }[ -timeout seconds] [-input argumentFile] [-primary_user primary user name] [-primary_pass Base64 encoded primary password] [-enable_pass Base64 encoded enable password] cwcli config compareanddeploy -help
Description	compareanddeploy creates a job that compares the given Baseline template with the latest version of the configuration for a device and downloads the configuration to the device if there is non-compliance. If you specify -baseline argument, the name of the Baseline template is compared with the latest configuration version of the device and later downloaded to the device if there are any commands in the baseline config file which are not compliant with the latest configuration of the device in the archive. The Baseline template must not have any parameters for the command to succeed.

comparewithbaseline

Name	cwcli config comparewithbaseline - CiscoWorks compare configuration with Baseline template function.
Syntax	cwcli config comparewithbaseline -u userid -p password [-d debuglevel] [-m email][-l logfile] { -device list | -view name | -device list -view name |-ipaddress list }{ -baseline baselinefile }[ -timeout seconds] [-input argumentFile] cwcli config comparewithbaseline -help
Description	comparewithbaseline creates a job that compares the given Baseline template with the latest version of the configuration for a device. If you use the -baseline argument, the name of the Baseline template is compared with the latest configuration version of the device.

delete

Name	cwcli config delete - CiscoWorks cwcli config delete function
Syntax	cwcli config delete -u userid -p password [-d debuglevel] [-m email] [-l logfile] { -device list | -view name | -device list -view name | -ipaddress list } { -version version1 [version2] | -date date1 [date2] } cwcli config delete -help
Description	delete deletes the specified device configuration from the archive. You can use the -date argument or the -version argument to specify which configurations to delete. •If you specify two dates, all configurations archived between those two dates are deleted. •If you specify only one date, all configurations up to and including the configuration archived on that date are deleted. •If you specify two versions, all configurations between and including the two versions are deleted. •If you specify only one version, the configuration corresponding to that version is deleted.

deploycomplianceresults

Name	cwcli config deploycomplianceresults - CiscoWorks deploy command with baseline function.
Syntax	cwcli config deploycomplianceresults -u userid -p password [-d debuglevel] [-m email][-l logfile] { -substitute datafile } {-jobid jobID}[ -timeout seconds][-primary_user primary user name] [-primary_pass Base64 encoded primary password] [-enable_pass Base64 encoded enable password] cwcli config deploycomplianceresults -help
Description	deploycomplianceresults uses the previously executed comparewithbaseline job to get the non-compliance commands and creates a job after replacing the parameters if any in the non-compliance commands with the values from the data file and then downloads those commands to ensure the compliance with the baseline config. If you specify the -baseline argument, the name of the Baseline template which will be compared with the latest configuration version of the device.

export

Name	cwcli config export - CiscoWorks cwcli config's export function.
Syntax	cwcli config export -u userid -p password [-d debuglevel] [-m email] [-l logfile] { -device name | -view name | -device name -view name |-ipaddress list } [-f filename] [-version number] [-xml] [-input argumentFile] cwcli config export -help
Description	export retrieves the configuration specified by the -version argument, for the device specified by -device and/or -view argument, from the archive and writes it to the file specified by the -f argument. •If you do not specify a version number, the latest configuration of the device from the archive is retrieved. •If you do not specify a file name, a file named devicename.cfg is created. To run this command against multiple devices, you must specify the -input argument, which takes a file name as an argument. The contents of the file must be similar to those described in the Input List File Format section of the cwcli config man page.

get

Name	cwcli config get - CiscoWorks cwcli config get function
Syntax	cwcli config get -u userid -p password [-d debuglevel] [-m email] [-l logfile] -filetype running|startup|runningstartup -device list | -view name | -device list -view name | -ipaddress list } cwcli config get -help
Description	get retrieves the running configuration from the device(s), specified by the -device and/or -view argument, and pushes it to the configuration archive if the running configuration is different than the latest version in the archive. For devices that support vlan configuration like CatIOS devices, the vlan configuration is also fetched and archived along with running-configuration. However, if a new version of the running configuration is not archived, the vlan configuration fetched, overwrites the previously archived vlan configuration for the latest version of running configuration in the archive. You can run the get function against multiple devices by separating each device name with a comma.

import

Name	cwcli config import - CiscoWorks cwcli config import function
Syntax	cwcli config import -u userid -p password [-d debuglevel] [-m email] [-l logfile][-timeout time] { -device name |-ipaddress address} [-f filename] [-save [-reboot]][-input argumentFile ] cwcli config import -help
Description	import retrieves the configuration from a file specified by the -f argument, and pushes it to the device specified by the -device and/or the -view argument, adding to the device's running configuration. •If you do not specify a file name, a file named device name.cfg is used. You can specify the -save and -reboot arguments, which operate the same as for the put argument. To run the import argument against more than one device, you must specify the -input argument, which takes a file name as an argument. The contents of the file must be similar to those described in the Input List File Format section of cwcli config(1). The configuration archive might be updated after you specify the import argument if the loaded configuration is different from the latest configuration in the archive.

put

Name	cwcli config put - CiscoWorks cwcli config put function
Syntax	cwcli config put -u userid -p password [-d debuglevel] [-m email] [-l logfile] { -device name |-ipaddress address -version number}[-config 1|2][-save [-reboot]] [-input argumentFile][-timeout seconds] [-filetype vlan|running][-primary_user primary user name] [-primary_pass Base64 encoded primary password] [-enable_pass Base64 encoded enable password]] cwcli config put -help
Description	put retrieves the configuration specified by -version from the configuration archive and pushes it to the device specified by the -device and/or -view argument The -filetype can be used to specify the type of configuration viz running/vlan configuration. By default, the running configuration is considered •In case of running configuration, the archived running configuration is merged with the running configuration on the device unless you specify -save, in which case, the archived configuration is also written to the device's memory. •In case of vlan configuration, the archived vlan configuration overwrites that on the device. The vlan configuration will not come into effect until the device is rebooted. You can specify -reboot to reboot the device after the configuration (running/vlan) is pushed to the device. To run the put command on more than one device at a time, you must use the -input argument, which takes a file name as an argument. The contents of the file must be similar to those described in the Input List File Format section of cwcli config(1).

reload

Name	cwcli config reload - CiscoWorks cwcli config reload function
Syntax	cwcli config reload -u userid -p password [-d debuglevel] [-m email][-l logfile] { -device list | -view name | -device list -view name|-ipaddress list }[-input argumentFile][-timeout seconds][-primary_user primary user name] [-primary_pass Base64 encoded primary password] [-enable_pass Base64 encoded enable password] cwcli config reload -help
Description	reload reboots the device(s), specified by the -device and/or -view argument, resulting in the running configuration being loaded with its startup configuration. You can specify multiple devices with the -device argument by separating each device name with a comma.

run2start

Name	cwcli config run2start - CiscoWorks cwcli config run2start function
Syntax	cwcli config run2start -u userid -p password [-d debuglevel] [-m email][-l logfile]{ -device list | -view name | -device list -view name | -ipaddress list}[-config 1|2] [-input argumentFile][-timeout seconds][-primary_user primary user name] [-primary_pass Base64 encoded primary password] [-enable_pass Base64 encoded enable password] cwcli config run2start -help
Description	run2start overwrites the startup configuration of any device(s), specified by the -device and/or -view argument, with its running configuration. You can specify multiple devices with the -device argument by separating each device name with a comma or with the -input argument, which takes a file name as an argument. The contents of the file must be similar to those described in the Input List File Format section of cwcli config(1).

start2run

Name	cwcli config start2run - CiscoWorks cwcli config start2run function
Syntax	cwcli config start2run -u userid -p password [-d debuglevel] [-m email][-l logfile] { -device list | -view name | -device list -view name |-ipaddress list } [-config 1|2] [-input argumentFile][-timeout seconds] [-primary_user primary user name] [-primary_pass Base64 encoded primary password] [-enable_pass Base64 encoded enable password] cwcli config start2run -help
Description	start2run merges the running configuration of any device(s), specified by the -device and/or -view arguments, with its startup configuration to give a new running configuration. You can specify multiple devices with the start2run argument by separating each device name with a comma or with the -input argument, which takes a file name as an argument. The contents of the file must be similar to those described in the Input List File Format section of cwcli config(1).

write2run

Name	cwcli config write2run - CiscoWorks cwcli config write2run function
Syntax	cwcli config write2run -u userid -p password [-d debuglevel][-m email][-l logfile] { -device name | -ipaddress address} -f filename [-config 1|2][-listonly][-input argumentFile][-timeout seconds][-primary_user primary user name][-primary_pass Base64 encoded primary password][-enable_pass Base64 encoded enable password] cwcli config write2run -help
Description	write2run compares the latest running configuration for the device in the configuration archive with the configuration in the file specified by the -f argument to generate a new configuration that is downloaded to the device, so that the end result is that the configuration specified in the file is available on the running configuration of the device. If -listonly is specified, the difference between the latest running configuration for the device in the configuration archive and the new configuration that is generated is listed on the display, but no configuration is downloaded to the device. To run this command against multiple devices, specify the -input argument, which takes a file name as an argument. The contents of the file must be similar to those described in the Input List File Format section of cwcli config(1). CAVEAT This command is not 100% reliable in that it may not successfully overwrite the running configuration. This is due to the dependency on the underlying Diff API, which generates the configuration difference to be downloaded to the device to make the running configuration on the device same as the one specified in the file (by the -f argument).

write2start

Name	cwcli config write2start - CiscoWorks cwcli config write2start function
Syntax	cwcli config write2start -u userid -p password [-d debuglevel] [-m email][-l logfile] { -device name -f filename |-ipaddress address} [-config 1|2][-input argumentFile][-timeout seconds][-primary_user primary user name][-primary_pass Base64 encoded primary password] [-enable_pass Base64 encoded enable password] cwcli config write2start -help
Description	write2start erases the contents of the device's startup configuration and then writes the contents of the given file as the device's new startup configuration. If you do not specify a file name, it prints an error message and exits. To run this command against multiple devices, you must specify the -input argument, which takes a file name as its argument. The contents of the file must be similar to those described in the Input List File Format section of cwcli config(1).

listversions

Name	cwcli config listversions - CiscoWorks cwcli config listversions function
Syntax	cwcli config listversions -u userid -p password [-d debuglevel] [-m email][-l logfile]{ -device name | -view name | -device name -view name | -ipaddress list} [-baseline][-input argumentFile] cwcli config listversions -help
Description	Listversions (specified by "listversions") lists the different versions of configuration files archived in the archival system. If you use the -baseline argument, only the names of the Baseline templates are displayed. You can choose a template and use it inline with the comparewithbaseline and compareanddeploy commands.

createdeployparamfile

Name	cwcli config createdeployparamfile - CiscoWorks cwcli config createdeployparamfile function.
Syntax	cwcli config createdeployparamfile -u userid -p password [-d debuglevel] [-m email][-l logfile][-jobid comparewithbaseline jobid] [ -baseline baselinefile ] [-f parameterfile] cwcli config createdeployparamfile -help
Description	createdeployparamfile creates a parameter file if the Baseline template containing the parameters is specified. You can use the -jobid argument to specify the job identifier of the previously executed comparewithbaseline job. You can choose a template with the -baseline argument and specify the name of the Baseline template for which the parameter file has to be created.

directbaselinedeploy

Name	cwcli config directbaselinedeploy - CiscoWorks cwcli config directbaselinedeploy function
Syntax	cwcli config directbaselinedeploy -u userid -p password [-d debuglevel] [-m email][-l logfile] { -baseline baselinefile } {-substitute parameterfile}[ -timeout seconds] [-primary_user primary user name] [-primary_pass Base64 encoded primary password] [-enable_pass Base64 encoded enable password] cwcli config directbaselinedeploy -help
Description	directbaselinedeploy creates a job that downloads the given Baseline template after retrieving the values of the parameters in the template from the given parameter file. You can use the -timeout argument to specify the duration of the interval in seconds between the two successive polling cycles. You can use the -baseline to specify the name of the Baseline template which will be compared with the latest configuration version of the device and later downloaded to the device if there are any commands in the baseline config file which are not compliant with the latest configuration of the device in the archive. You can use the -substitute to substitute the values from the XML parameter file for the parameters specified in the template.

Overview: cwcli netconfig Command

The cwcli netconfig command lets you use NetConfig from the command line.

---

Caution The cwcli netconfig command does not validate the command arguments you use or the configuration commands that you run using it. If you enter incorrect commands you can misconfigure or disable the devices on which the job runs.

---

Running the cwcli netconfig Command

To use the cwcli netconfig command, you must be able to run the cwcli command, and you must have permissions to use the Adhoc system-defined task. For more details see topic in the section.

The command syntax is:

cwcli netconfig Sub_command Common_arguments Command_arguments

The subcommands and arguments are described in the following sections:

•Subcommands (see Subcommands)

•Common Arguments (see Common Arguments)

•Command Arguments (see Command Arguments)

Subcommands

Subcommands specify the action the command performs. Valid values for the subcommands are:

Subcommand	Description
createjob	Creates job.
deletejob	Deletes jobs.
canceljob	Cancels jobs.
jobdetails	Lists job details.
jobresults	Lists job results.
listjobs	Lists jobs.
import	Imports user-defined tasks in XML format.
export	Exports user-defined tasks in XML format.
listtasks	Lists the NetConfig user-defined tasks.

Common Arguments

Common arguments specify parameters that apply to all subcommands. Valid values for common_arguments are:

Common Argument	Description	Usage Notes
-u user	Enter valid CiscoWorks username.	None
-p password	Enter password for username. You can also specify the password in a file. See Setting CWCLIFILE Environment Variable for more details.	None

Command Arguments

Command arguments specify parameters that apply only to specific subcommands.

The conventions followed are:

•Arguments in [ ] are optional. For optional arguments, if you do not specify a value the default value that has been set by the administrator using the NetConfig UI, will become applicable.

•Arguments in { } denote that you must provide one argument from each group of arguments in curly braces ({}) that is separated by vertical bars (|).

•Arguments suffixed with + denote that you can enter multiple values separated with spaces.

•Values that contain spaces need to be entered within " ". For example, the job description that you provide when you use a the createjob command should be entered within " ".

Valid values for command_arguments are described in the following table:

Sub Command	Command Argument	Description	Usage Notes
createjob Allows you to create a NetConfig job.	{-device comma_separated_device_names | -devicefile devicelist_filename | -view device_view_name}	Defines devices to be configured. comma_separated_device_names is list of device display names. devicelist_filename is path to device list file. Can be full pathname or filename in the local directory. The devicelist file should be of this format: -device 1.1.1.1,2.2.2.2,3.3.3.3 or -device 1.1.1.1 -device 2.2.2.2 -device 3.3.3.3 device_view_name is name of the device view.	Jobs can run only one device category (IOS, Catalyst, Content Engine (CE), or Content Service Switch (CSS)). Do not enter devices of multiple categories.
	{[{-commandfile commandlist_filename -mode {config | enable}} [-rollbackfile rollback_cmdlist_filename]] [-taskname : "User defined task name"]}	Defines configuration commands to be used. You can specify the command file path, the command mode, the rollback file and the name of the user-defined task. Specify the user-defined task name within quotes.	commandlist_filename is path to command file. Can be a full pathname or filename in local directory. -mode specifies the command mode.{config | enable} are the command mode arguments. By default, -mode value is set to config. This is not valid for jobs that configure Catalyst devices. For jobs on IOS, CE, or CSS devices, config is default.
			rollback_cmdlist_filename defines the rollback configuration commands for the job. It can be a full pathname to the file or a filename in the local directory. User defined task name is the name that you specify for the user-defined task.
	{-description : "job_description "}	Enter the description for the job you are creating.	"job_description" is the description you specify, for the job that you are creating. Enter this value within quotes.
	[{-schedule : MM/dd/yyyy:HH:mm:ss -schedule_type: once| weekly| monthly| lastDayOfMonth}]	-schedule defines time and date job will run. If you have enabled Job Approval, and later if you create the job without using the -schedule argument, the job will automatically be scheduled to run after 5 minutes of the job creation time. You should approve this job within 5 minutes of creating the job. If you want to schedule the job to run at any other time, use the -schedule argument. If not specified, job will run immediately. -schedule_type defines the type of job schedule.	MM is month (01 to 12). DD is day of month (01 to 31). YYYY is year (Example: 2004). HH is hours, mm is minutes, and ss is seconds in 24-hour time. If you do not specify the schedule type, the job will be an immediate job.
	[ -policyfile policy_filename ]	Defines job policies using a job policy file. You can specify job policies using combination of -policyfile argument and other optional arguments, However, you can specify each argument only once in command.	policy_filename is path to job policy file. Can be a full pathname or filename in local directory.
	[-makercomments : "maker comments" ]	Comments from the job creator, to the job approvers, if job approval is enabled for the job.	Enter your comments within quotes.
	[-mkemail : maker email id ]	E-mail ID of the job creator, for approval notifications, if approval is enabled for the job.	None
	[-execution: Sequential|Parallel ]	Configures the job execution property, whether the jobs should be run sequentially or in parallel.	None.
	[-startup ]: Copy running config to startup policy	Select to cause the configuration job to write the running configuration to the startup configuration on each device after configuration changes are made successfully.	None.
	[-version] : Fail on mismatch of Config Versions.	Select to cause the job to be considered a failure when the most recent configuration version in the Configuration Archive is not the same as the configuration that was running when you created the job.	-sync argument should be provided if this policy is selected. This argument causes the job to archive the running configuration before making configuration changes.
	[-email : Job Notification email ids ]	Specify the email addresses to which the configuration job will send status notices.	Separate multiple addresses with commas.
	[-sync ] : Synch configuration archive before deploy	Select to cause the job to archive the running configuration before making configuration changes.	None.
	[-failure: "Stop on failure" | "Ignore failure and continue" | "Rollback device and stop" | "Rollback device and continue" | "Rollback job on failure"]	Select what the job should do if it fails to run on a device.	Ensure that you place your selected value within quotes.
	[{-primary_user : Primary User name -primary_pass : "Primary password" }]	Primary username for connecting to the device. Primary password for connecting to the device.	Enter the primary password within quotes.
	[ -enable_pass : "Execution mode Password"}]	Password for running commands in the execution mode, on the device.	Enter the execution mode password within quotes.
deletejob This subcommand allows you to delete one or more NetConfig jobs.	-id job_id+		job_id+ specifies the ID of the job on which to act. You can specify multiple job IDs separated by spaces or commas.
canceljob This subcommand allows you to cancel a NetConfig job from the command line.	-id job_id		job_id specifies ID of job on which to act.
jobdetails Allows you to view details of one or more NetConfig jobs from the command line.	[ -id job_id+ ]	Specifies ID of job on which to act.	You can specify multiple job ID separated by spaces or commas.
jobresults Allows you to view results of one or more NetConfig jobs from the command line.	[ -id job_id+ ]	Specifies ID of job on which to act.	You can specify multiple job ID separated by spaces or commas.
	[ -details ]	Specifies full details of job results to be displayed.	Not specifying details will display only the summary of job execution result.
listjobs Allows you to list all NetConfig jobs from the command line.	[ -status {A(ll) | R(unning) | C(ompleted) | P(ending)} ]	Specifies status of jobs to list.	If status is not specified, all registered jobs are listed.
import Allows you to import user defined task in xml format to to netconfig from the command line.	{-taskfile User-defined task file }	User-defined task filename in XML format.
export Allows you to export one or more user defined tasks created in netconfig to xml files from the command line.	{ -task+ User-defined task name }	Name of the user-defined task to be exported.	You can specify multiple tasks separated by spaces or commas.
	{-dest file export location }	Path of the destination location to which the exported user-defined task file is to be copied.
listtask		Lists the NetConfig user-defined tasks.

Command Examples

Example 1

The command

cwcli netconfig -u username -p password createjob -devicefile devicefile -commandfile command.file -failure Ignore failure and Continue -startup

creates a NetConfig job with the following characteristics:

•Devices mentioned in devicefile will be configured.

•Commands in file command.file will run.

•Job will continue if it fails to successfully configure a device.

•Each device's running configuration will be copied to startup as soon as the device is successfully configured.

•Job will run immediately because the -schedule argument is not specified.

Example 2

The command

cwcli netconfig -u username -p password createjob -devicefile devicefile -commandfile command.file -policyfile policyfile

creates a NetConfig job with the following characteristics:

•Devices listed in the file devicefile will be configured.

•Commands in the file command.file will run.

•The file policyfile contains job policy arguments that determine the job policy.

Understanding cwcli netconfig Input Files

Several types of text files are available for you to use as input for the cwcli netconfig command and the -createjob subcommand. You can also use the command list type as input for user-defined tasks.

File Type	Description	Usage Notes
Device list	Lists devices on which job will run. It lists one device on each line.	Use with -devicefile argument. Job can run only one device category (IOS, or Catalyst). Do not list devices of multiple categories.
Command list	Lists configuration commands that job will run; one command per line.	Use with -commandfile argument, or to add commands to a user-defined task.
Job policy	Lists of job policy arguments; one argument per line.	Use with -policyfile argument.

Examples

Device List File

-device device_display_name1
-device device_display_name2
-device device_display_name3
-device device_display_name4

Command List File

command1
command2
command3
command4

Job Policy File

This file configures the job to stop running if the job fails on a device, to write the running configuration to startup after configuration changes are made.

-failure Stop on Failure
-sync

cwcli netconfig Man Page Examples

On UNIX, you can view the complete man pages by setting the MANPATH to /opt/CSCOpx/man

The following are some examples from the NetConfig man page:

Examples

Device List File Example

For the command

cwcli netconfig createjob -u userid -p password -devicefile c7000.dev -commandfile command.file

-description "cwcli netconfig job" -mode config

An example of the device list file c7000.dev is

enm-7000-1.cisco.com

enm-7000-2.cisco.com

enm-7000-3.cisco.com

enm-7000-4.cisco.com

Command List File Example

For the command

cwcli netconfig createjob -u userid -p password -devicelist c7000-1,c7000-2 -commandfile command.file

-description "cwcli netconfig job" -mode config

An example of the command file command.file is

snmp-server community public ro

snmp-server community private rw

Policy File Example

For the command

cwcli netconfig createjob -u userid -p password -devicefile c7000.dev -commandfile command.file -policyfile policy.in

-description "cwcli netconfig job" -mode config

An example of the policy file policy.in is

-failure "Stop on failure"

-sync

-execution Parallel

User-defined Task XML file Example

<?xml version="1.0" encoding="UTF-8"?>

<Task name="SampleTASK">

<Template mode="1" name="iproute" parameterized="false">

<Commands>

<cli>ip route 0.0.0.1 0.0.0.0 Ethernet0/0</cli>

<cli>ip route 0.0.0.2 0.0.0.0 Ethernet0/0</cli>

<cli>ip route 0.0.0.3 0.0.0.0 Ethernet0/0</cli>

<cli>ip route 0.0.0.4 0.0.0.0 Ethernet0/0</cli>

<cli>ip route 0.0.0.5 0.0.0.0 Ethernet0/0</cli>

<cli>ip route 0.0.0.6 0.0.0.0 Ethernet0/0</cli>

</Commands>

<RollbackCommands>

<cli>no ip route 0.0.0.4 0.0.0.0 Ethernet0/0</cli>

<cli>no ip route 0.0.0.5 0.0.0.0 Ethernet0/0</cli>

</RollbackCommands>

<MDFIds>268438030,273153536,272819655</MDFIds>

</Template>

</Task>

cwcli netconfig Remote Access

You can also perform the cwcli netconfig tasks using the servlet. You will have to upload a payload XML file, which contains the cwcli netconfig command arguments and CiscoWorks user credentials.

You have to write your own script to invoke the servlet with a payload of this XML file and the servlet returns the output either on the console or in the specified output file, if the credentials are correct and arguments are valid.

The name of the servlet is /rme/cwcli.

The following is the servlet to be invoked to execute any command:

For post request,

perl samplepost.pl http://rme-server:rme-port/rme/cwcli payload_XML_file

The default port for CiscoWorks server in HTTP mode is 1741.

If you have enabled SSL on CiscoWorks server, you can also use https protocol for secured connection.

perl samplepost.pl https://rme-server:rme-port/rme/cwcli payload_XML_file

The default port for CiscoWorks server in HTTPS mode is 443.

The schema for creating the payload file in XML format is:

<payload>

<command>

cwcli inventory commandname -u user -p BAse64 encoded pwd -args1 arg1value...

</command>

</payload>

To invoke the servlet using a script, see the Sample Script to Invoke the Servlet.

The script and the payload file should be residing in the client machine.

For get request,

http://<rme-server>:<rme-port>/rme/cwcli?command=cwcli netconfig commandname -u user -p BAse64 encoded pwd -args1 arg1value...

The default port for CiscoWorks server in HTTP mode is 1741.

If you have enabled SSL on CiscoWorks server, you can also use https protocol for secured connection.

https://rme-server:rme-port/rme/cwcli?command=cwcli netconfig commandname -u user -p BAse64 encoded pwd -args1 arg1value...

The default port for CiscoWorks server in HTTPS mode is 443.

The BAse64 encoded for "admin" is YWRtaW4=.

The URL encode for,

•Double quotes (") is %22

•Percentage sign (%) is %25

Overview: cwcli export Command

cwcli export is a command line tool that also provides servlet access to inventory, configuration and change audit data.

This can be used for generating inventory, configuration archive, and change audit data for devices in Resource Manager Essentials (RME).

---

Note You cannot run this command for the RME devices that are in Conflicting or Suspended state.

---

This tool supports the following features:

•Generating change audit data in XML format

The tool uses the existing Change Audit log data and generates the Change Audit log data in XML format.

See Running cwcli export changeaudit for the usage and XML schema details

•Generating configuration data in XML format

The tool uses existing configuration archive APIs and generates latest configuration data from the configuration archive in XML format.

Elements in the XML file are created at the configlet level in the current configuration archive. Predefined rules that currently exist in the configuration archive are used to get the configlets data.

See Running cwcli export config for the usage and XML schema details

•Generating inventory data in XML format

The tool has servlet access and command line utilities that can generate inventory data for devices managed by the RME server.

See Running cwcli export inventory Command for the usage and XML schema details

The cwcli export command is located in the following directories, where install_dir is the directory in which CiscoWorks is installed:

•On UNIX systems, /opt/CSCOpx/bin

•On Windows systems, install_dir\CSCOpx\bin

The default install directory is C:\Program Files.

If you install RME on an NTFS partition on Windows, only users in the administrator or casuser group can access cwcli export. Users with read-execute access to the CSCOpx\files\archive directory and the directories under that can also use cwcli export.

You can also perform the cwcli export tasks using the servlet. You will have to upload a payload XML file, which contains the cwcli export command arguments and CiscoWorks user credentials.

You have to write your own script to invoke the servlet with a payload of this XML file and the servlet returns the output either on the console or in the specified output file, if the credentials are correct and arguments are valid.

The name of the servlet is /rme/cwcli.

The following is the servlet to be invoked to execute any command:

For post request,

perl samplepost.pl http://rme-server:rme-port/rme/cwcli payload_XML_file

The default port for CiscoWorks server in HTTP mode is 1741.

If you have enabled SSL on CiscoWorks server, you can also use https protocol for secured connection.

perl samplepost.pl https://rme-server:rme-port/rme/cwcli payload_XML_file

The default port for CiscoWorks server in HTTPS mode is 443.

The schema for creating the payload file in XML format is:

<payload>

<command>

cwcli inventory commandname -u user -p BAse64 encoded pwd -args1 arg1value...

</command>

</payload>

To invoke the servlet using a script, see the Sample Script to Invoke the Servlet.

The script and the payload file should be residing in the client machine.

For get request,

http://rme-server:rme-port/rme/cwcli?command=cwcli export commandname -u user -p BAse64 encoded pwd -args1 arg1value...

The default port for CiscoWorks server in HTTP mode is 1741.

If you have enabled SSL on CiscoWorks server, you can also use https protocol for secured connection.

https://rme-server:rme-port/rme/cwcli?command=cwcli export commandname -u user -p BAse64 encoded pwd -args1 arg1value...

The default port for CiscoWorks server in HTTPS mode is 443.

The BAse64 encoded for "admin" is YWRtaW4=.

The URL encode for,

•Double quotes (") is %22

•Percentage sign (%) is %25

Using the cwcli export Command

The command line syntax of the application is in the following format:

cwcli export command GlobalArguments AppSpecificArguments

•cwcli export is the CiscoWorks command line interface for exporting inventory/config/changeaudit details into XML format.

•Command specifies which core operation is to be performed.

•GlobalArguments are the additional parameters required for each core command.

•AppSpecificArguments are the optional parameters, which modify the behavior of the specific cwcli export core command.

The order of the arguments and arguments are not important. However, you must enter the core command immediately after cwcli export.

The following sections describe:

•The cwcli export commands (See cwcli export Commands)

•The mandatory and optional arguments (See cwcli export Global Arguments)

•The default archiving location (See Archiving cwcli export Data in XML File)

On UNIX, you can view the cwcli export man pages by setting the MANPATH to /opt/CSCOpx/man.

The commands to launch the cwcli export man pages are:

•man cwcli-export—To launch the cwcli export command man page.

•man export-changeaudit—To launch the cwcli export changeaudit command man page.

•man export-config—To launch the cwcli export config command man page.

•man export-inventory—To launch the cwcli export inventory command man page.

cwcli export Commands

The following table lists the command part of the cwcli export syntax.

Command	Description
cwcli export changeaudit	Generates Change Audit log data in XML format.
cwcli export config	Generates configlets in XML format
cwcli export inventory	Generates Inventory data in XML format.

You must invoke the cwcli export command with one of the core commands specified in the above table. If no core command is specified, cwcli export can execute the -v or -h. arguments only. Argument -v specifies the version of the cwcli export utility and argument -h (or null argument) displays the usage information of this tool.

cwcli export Global Arguments

The following describes the mandatory and optional global arguments for cwcli export:

Global Arguments	Description
-u userid	Mandatory Specifies the CiscoWorks username.
-p password	Mandatory Specifies the password for the CiscoWorks username. If you want to avoid the -p argument which will reveal the password in clear text in cli, you will have to store your username and password in a file and set a variable cwcli CWCLIFILE which points to the file. You will have to maintain this file and control access permissions to prevent unauthorized access. cwcli export looks for current working directory if cwcli CWCLIFILEis set only to file name instead of full path. If you use the -p argument, even after setting the cwcli CWCLIFILE variable the password is taken from the command line instead of cwcli CWCLIFILE. This is not secure and usage of this argument is not recommended. The password must be provided in the file in the following format: username password where username is the CiscoWorks user name given in the command line.The delimiter between the username and password is single blank space. You must enter the delimiter if the password is blank. Otherwise, cwcli export will fail to validate the password.The password file can contain multiple entries with different user names. The password that matches first is considered in case of duplicate entries. Note If -p password is used, the password is read from the command line instead of cwcli CWCLIFILE. This is highly insecure and therefore not recommended. See Setting CWCLIFILE Environment Variable for more details.
{ -device devicename | -view viewname| -input inputfilename | -ipaddress mgmt-ip-address }	Mandatory -device devicename Specifies the display name of the device that you have added in the Device and Credentials database (Common Services > Device and Credentials > Device Management). You can enter multiple display name separated by a comma. You can use either wildcard or specific device(s) but not at the same time. The argument syntax used for -device argument may be a single device or a device list. Devices in a list are separated by a ','. The wild card symbol '%' may be used to specify a group of devices having a pattern. For example if a pattern x% is specified as a device in the list, then all the CiscoWorks devices that have names that start with x will be selected for this operation.
{ -device devicename | -view viewname | -input inputfilename | -ipaddress mgmt-ip-address}	Mandatory -view viewname If the data needs to be generated for all the devices in a specific group, you can use the -view argument. You can use this argument to generate data for devices in all RME device views including system-defined groups and user-defined groups. You can enter multiple group name separated using a comma. For view name, you have to enter the fully qualified path as in the Group Administration window. To separate the path you must use forward slash only. For example, -view "/RME@ciscoworks_servername/All Devices"
{ -device devicename | -view viewname -input inputfilename | -ipaddress mgmt-ip-address}	Mandatory -input inputfilename You can create an input list file that contains a list of devices to perform the operation on. The contents of the input list file are a sequence of lines. Each line specifies a display name as entered in the Device and Credential Repository. The arguments must be specific to the function. You cannot include group names in the input list file. You can include comments in the input list file by starting each commented line with #. The input file should be of this format: -device 1.1.1.1,2.2.2.2,3.3.3.3 or -device 1.1.1.1 -device 2.2.2.2 -device 3.3.3.3
{ -device devicename | -view viewname -input inputfilename | -ipaddress mgmt-ip-address}	Mandatory -ipaddress mgmt-ip-address Specify the device IP4 address as entered in the Device and Credential Repository. You can enter multiple IP address with comma separated. You cannot use this option with -device, -view, or -input. Also, you cannot specify wildcard characters.
-d debuglevel	Optional debug_level is a number between 1 (the least information is sent to the debug output) and 5 (the most information is sent to the debug output). If you do not specify this argument, 4(INFO) is the default debug level.
-l logfile	Optional Logs the results of the cwcli export command to the specified log file name. By default the command output will be displayed on the standard out.
-m mailid	Optional Mails the results of the cwcli export command to the specified email address. This argument notifies you whether the task is completed. Only one mail id can be given at a time.
-f filename	This is applicable only for changeaudit and inventory applications. Optional Specifies the name of the file to which the changeaudit and inventory information is to be exported on CiscoWorks server. If you are using cwcli remotely (get or post request), by default the output file is available at this location on CiscoWorks server: On Windows: NMSROOT\MDC\tomcat Where, NMSROOT is the CiscoWorks installed directory. On Solaris: /opt/CSCOpx/objects/dmgt

Archiving cwcli export Data in XML File

By default, the data generated through cwcli export command is archived at the location:

cwcli export Command	Location on CiscoWorks Server
changeaudit	On Solaris: /var/adm/CSCOpx/files/rme/archive/YYYY-MM-DD-HH-MM-SS -changeaudit.xml
	On Windows: NMSROOT\files\rme\archive\YYYY-MM-DD-HH-MM-SS -changeaudit.xml
config	On Solaris: /var/adm/CSCOpx/files/rme/cwconfig/YYYY-MM-DD-HH-MM-SS-MSMSMS-Device_Display_Name.xml
	On Windows: NMSROOT\files\rme\cwconfig\YYYY-MM-DD-HH-MM-SS-MSMSMS -Device_Display_Name.xml
inventory	On Solaris: /var/adm/CSCOpx/files/rme/archive/YYYY-MM-DD-HH-MM-SS-inventory.xml
	On Windows: NMSROOT\files\rme\archive\YYYY-MM-DD-HH-MM-SS- inventory.xml

Where NMSROOT is the RME installed directory.

You can also specify a directory to store the output. This application does not have a feature to delete the files created in the archive. You should delete the files when necessary.

While generating data through the servlet, the output will be displayed in the client terminal.

Running cwcli export changeaudit

Using this command you can export the Change Audit log data in the XML format.

The command syntax for cwcli export changeaudit is:

cwcli export changeaudit {-u username -p password -device devicenames}
[- ipaddress mgmt-ip-address]

[-f filename]

[-from mm/dd/yyyy] ---> eg: 05/01/2004

[-to mm/dd/yyyy] ---> eg: 05/06/2004

[-app comma separated list of applications]

[-cat comma separated list of categories]

Arguments in square brackets ([]) are optional; arguments in curly braces ({}) are required. You must provide one argument from each group of arguments in curly braces ({}) that is separated by vertical bars (|).

If you enter an argument which has space then use double quotes for that argument. For example for Software Management, you enter this as "Software Management".

The following table describes the arguments that are specific to cwcli export changeaudit command. The other common arguments used by cwcli export are explained in Using the cwcli export Command.

Arguments	Description
[-from mm/dd/yyyy]	Optional. Enter the from date. If you enter only -from date then the report will be generated from the date that you have specified, to the current date.
[-to mm/dd/yyyy]	Optional. Enter the from date. If you enter only -to date then the report will be generated from the date RME has logged Change Audit record to the -to date that you have specified.
[-app comma separated list of applications]	Specify the application name. The supported applications are: •Archive Mgmt •ConfigEditor •CwConfig •ICServer •NetConfig •Software Management If you do not specify the -app argument, then changes made by all applications is reported.
[-cat comma separated list of categories]	Specify the category name. The supported categories are: •CONFIG_CHANGE—Configuration changes on the device. •INVENTORY_CHANGE—Hardware changes on the device. •SOFTWARE_CHANGE—Software changes on the device. If you do not specify the -cat argument, then changes made by all categories is reported.

---

Note If you do not enter -from and -to arguments, all the Change Audit records logged till the current date will be displayed.

---

The following sections describes:

•XML Schema for cwcli export changeaudit

•XML Schema for Configuration Management Application

•XML Schema for Software Management

•Usage Examples for cwcli export changeaudit Command

XML Schema for cwcli export changeaudit

The following is the schema used for exporting the change audit data in XML format.

<?xml version = "1.0" encoding = "UTF-8"?>

<!--Generated by XML Authority. Conforms to w3c http://www.w3.org/2000/10/XMLSchema-->

<xsd:schema xmlns:xsd = "http://www.w3.org/2000/10/XMLSchema">

 <xsd:element name = "changeRecord">

  <xsd:complexType>

   <xsd:sequence>

    <xsd:element ref = "groupId"/>

    <xsd:element ref = "category"/>

    <xsd:element ref = "host"/>

    <xsd:element ref = "user"/>

    <xsd:element ref = "device"/>

    <xsd:element ref = "connectionMode"/>

    <xsd:element ref = "timestamp"/>

    <xsd:element ref = "description"/>

   </xsd:sequence>

   <xsd:attribute name = "id" use = "required" type = "xsd:integer"/>

  </xsd:complexType>

 </xsd:element>

 <xsd:element name = "groupId" type = "xsd:string"/>

 <xsd:element name = "category" type = "xsd:string"/>

 <xsd:element name = "application" type = "xsd:string"/>

 <xsd:element name = "host" type = "xsd:string"/>

 <xsd:element name = "user" type = "xsd:string"/>

 <xsd:element name = "device" type = "xsd:string"/>

 <xsd:element name = "connectionMode" type = "xsd:string"/> 

 <xsd:element name = "timestamp" type = "xsd:string"/> 

 <xsd:element name = "description"> 

  <xsd:complexType> 

   <xsd:sequence> 

    <xsd:element ref = "summary"/> 

    <xsd:element ref = "details"/> 

   </xsd:sequence> 

  </xsd:complexType> 

 </xsd:element> 

 <xsd:element name = "summary" type = "xsd:string"/> 

 <xsd:element name = "details"> 

  <xsd:complexType/> 

 </xsd:element> 

 <xsd:element name = "changeRecordSet"> 

  <xsd:complexType> 

   <xsd:sequence> 

    <xsd:element ref = "changeRecord" maxOccurs = "unbounded"/> 

   </xsd:sequence> 

  </xsd:complexType> 

 </xsd:element> 

</xsd:schema> 

Detailed Description of changeaudit Schema

The table below describes elements in the changeaudit schema:

Field	Description
Category	Type of the change. For example, configuration, inventory, or software.
Application	Name of the RME application involved in the network change (Device Configuration, Inventory, or Software Management).
Host	Host device from which the user accessed the device or the host name of the RME server.
User	Name of the person who performed the change. This is the name entered when the person logged in. It can be the name under which the RME application is running, or the name under which the Telnet connection is established.
Device	Network device on which the change occurred. The display name as entered in the Device and Credential Repository.
ConnectionMode	Connection mode through which the change was made, for example, Telnet, snmp, console, or RME application.
Timestamp	Date and time at which the application communicated the network change or when Change Audit saw the change record.
Description	Contains the detailed information of the changes that had occurred on the device. The description changes based on the application you have selected: •Archive Mgmt (See XML Schema for Configuration Management Application for more information.) •ConfigEditor (See XML Schema for Configuration Management Application for more information.) •CwConfig (See XML Schema for Configuration Management Application for more information.) •ICServer—Inventory Collection Service (See XML Schema for Inventory Collection Service for more information.) •NetConfig (See XML Schema for Configuration Management Application for more information.) •Software Management (See XML Schema for Software Management for more information.)

The following section describes the schema used by these application when you run the command cwcli export changeaudit with -app argument:

•Archive Mgmt, ConfigEditor, CwConfig, NetConfig

•Inventory Collection Service

•Software Management

XML Schema for Configuration Management Application

The following XML schema is used by all Configuration Management application when you run the cwcli export changeaudit command with -app argument and the -app argument values as either Archive Mgmt, ConfigEditor, CwConfig, or NetConfig.

The schema file is:

<?xml version="1.0" encoding="UTF-8" ?> 

- <!--  edited with XMLSPY v2004 rel. 2 U (http://www.xmlspy.com) by Cisco (t) --> 

- <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" 
attributeFormDefault="unqualified">

- <xs:element name="ConfigDiff">

- <xs:annotation>

  	<xs:documentation>Comment describing your root element</xs:documentation> 

  </xs:annotation>

- <xs:complexType>

	- <xs:sequence>

		- <xs:element name="OldConfig">

			- <xs:complexType>

				- <xs:sequence>

					<xs:element name="Command" maxOccurs="unbounded" /> 

				</xs:sequence>

				<xs:attribute name="Version" type="xs:integer" /> 

			</xs:complexType>

		</xs:element>

- <xs:element name="NewConfig">

- <xs:complexType>

	- <xs:sequence>

  		<xs:element name="Command" maxOccurs="unbounded" /> 

	</xs:sequence>

				<xs:attribute name="Vesrion" type="xs:integer" /> 

			</xs:complexType>

		</xs:element>

	</xs:sequence>

	<xs:attribute name="CASLogID" type="xs:integer" /> 

	<xs:attribute name="DeviceName" type="xs:string" /> 

</xs:complexType>

</xs:element>

</xs:schema>

Detailed Description of Configuration Management Schema

The table below describes elements in the Configuration Management schema.

Field	Description
Category	Type of the change. For example, configuration, inventory, or software.
Host	Host device from which the user accessed the device or the host name of the RME server.
Application	Name of the application. For example, Archive Mgmt, NetConfig, etc.
User	Name of the person who performed the change. This is the name entered when the person logged in. It can be the name under which the RME application is running, or the name under which the Telnet connection is established.
Device	Network device on which the change occurred. The display name as entered in the Device and Credential Repository.
ConnectionMode	Connection mode through which the change was made, for example, Telnet, snmp, console, or RME application.
Timestamp	Date and time at which the application communicated the network change or when Change Audit saw the change record.
Summary	Description describing what caused the change. For example: •Configuration Download due to job •Syslog triggered Config Collection
ConfigDiff	•FirstConfig, SecondConfig •DeviceName—Network device on which the change occurred. The display name as entered in the Device and Credential Repository. •Version—Configuration file version number. •CommandDiff Polarity—Changes in the configuration file. –POSNEG—No change –POSITIVE —Added new commands –IGNORED—Ignored the commands –NEGATIVE—Deleted the commands

XML Schema for Inventory Collection Service

The following XML schema is used by Inventory Collection Service application when you run the cwcli export changeaudit command with -app argument and the -app argument values as ICServer.

The schema file is:

<?xml version = "1.0" encoding = "UTF-8"?>

<xsd:schema xmlns:xsd = "http://www.w3.org/2000/10/XMLSchema">

<xsd:element name = "InventoryChangeDetailRecord">

<xsd:complexType>

	<xsd:sequence maxOccurs = "unbounded">

	<xsd:element ref = "Section"/>

	</xsd:sequence>

</xsd:complexType>

</xsd:element>

<xsd:element name = "Section">

<xsd:complexType>

	<xsd:sequence maxOccurs = "unbounded">

	<xsd:element ref = "Attributes"/>

	</xsd:sequence>

	<xsd:attribute name = "Name" type = "xsd:string"/>

	<xsd:attribute name = "Identity" type = "xsd:string"/>

</xsd:complexType>

</xsd:element>

<xsd:element name = "Attributes">

<xsd:complexType>

	<xsd:all maxOccurs = "unbounded">

	<xsd:element ref = "Previous_value"/>

	<xsd:element ref = "Current_value"/>

	<xsd:element ref = "Action"/>

	</xsd:all>

</xsd:complexType>

</xsd:element>

<xsd:element name = "Previous_value" type = "xsd:string"/>

<xsd:element name = "Current_value" type = "xsd:string"/>

<xsd:element name = "Action" type = "xsd:string"/>

</xsd:schema>

Detailed Description of Inventory Collection Service Schema

The table below describes elements in the Inventory Collection Service schema.

Field	Description
Name	Name of the physical and logical entities. The main physical entities are Chassis, Backplane, Card, CommunicationConnector, FlashDevice, FlashPartition, FlashFile, SoftwareIdentity, PhysicalMemory The main logical entities are ManagedNetworkElement, LogicalModule, Port, MemoryPool, OSElement, IPProtocolEndpoint, IfEntry, AdditionalInformation See Detailed Description of the Inventory Schema for further information.
Identity	Identifies the entity that has changed on the device. For example: If the Flash File name has changed then Identity will be Flash Device 2, Flash Partition 3.
AttributeName	Name of the different physical and logical entities For example: In MemoryPool, the different entities are User, Free, PoolType. See Detailed Description of the Inventory Schema for further information.
Previous_value	Value of the entity before the change occurred.
Current_value	Value of the entity after the change occurred.
Action	Type of change that has occurred on the device: •Inserted— Added a new entity. •Changed—Changed in the entity. •Deleted—Deleted an entity.

XML Schema for Software Management

The following XML schema is used by Software Management application when you run the cwcli export changeaudit command with -app argument and the -app argument values as Software Management.

The schema file is:

<?xml version="1.0" encoding="UTF-8" ?> 

- <!--  edited with XMLSPY v2004 rel. 2 U (http://www.xmlspy.com) by Cisco --> 

- <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" 
attributeFormDefault="unqualified">

- <xs:element name="SwimHistoryRecord">

	- <xs:annotation>

  		<xs:documentation>Models a set of image changes on the device.</xs:documentation> 

	</xs:annotation>

- <xs:complexType>

- <xs:sequence>

	- <xs:element name="JobID" type="xs:positiveInteger" minOccurs="0">

- <xs:annotation>

<xs:documentation>ID of the Job in which the change happened</xs:documentation>

</xs:annotation>

</xs:element>

- <xs:element name="ImageChange" maxOccurs="unbounded">

- <xs:complexType>

- <xs:sequence>

  <xs:element name="OldImage" type="Image" /> 

  <xs:element name="NewImage" type="Image" /> 

  </xs:sequence>

  <xs:attribute name="ID" type="xs:positiveInteger" use="required" /> 

  </xs:complexType>

  </xs:element>

  </xs:sequence>

  </xs:complexType>

</xs:element>

- <xs:complexType name="Image">

- <xs:annotation>

 	 <xs:documentation>Models an Image.</xs:documentation> 

  </xs:annotation>

- <xs:sequence>

- <xs:element name="Type">

- <xs:annotation>

  <xs:documentation>Label of corresponding image type from enumeration 
com.cisco.nm.xms.xdi.ags.imageparser.ImageType</xs:documentation> 

  </xs:annotation>

- <xs:simpleType>

	- <xs:restriction base="xs:string">

  	<xs:whiteSpace value="preserve" /> 

  </xs:restriction>

</xs:simpleType>

</xs:element>

  <xs:element name="Name" type="xs:string" /> 

  <xs:element name="Version" type="xs:string" /> 

- <xs:element name="Attribute" minOccurs="0" maxOccurs="unbounded">

- <xs:complexType>

- <xs:sequence>

- <xs:element name="AttributeName">

- <xs:simpleType>

	- <xs:restriction base="xs:string">

  	<xs:whiteSpace value="preserve" /> 

  </xs:restriction>

  </xs:simpleType>

  </xs:element>

- <xs:element name="AttributeValue">

- <xs:simpleType>

	- <xs:restriction base="xs:string">

	 <xs:whiteSpace value="preserve" /> 

  </xs:restriction>

  </xs:simpleType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:schema>

Detailed Description of Software Management Schema

The table below describes elements in the Software Management schema.

Field	Description
Category	Type of the change. For example, configuration, inventory, or software.
Host	Host device from which the user accessed the device or the host name of the RME server.
Application	Name of the application. For example, Archive Mgmt, NetConfig, etc.
User	Name of the person who performed the change. This is the name entered when the person logged in. It can be the name under which the RME application is running, or the name under which the Telnet connection is established.
Device	Network device on which the change occurred. The display name as entered in the Device and Credential Repository.
ConnectionMode	Connection mode through which the change was made, for example, Telnet, snmp, console, or RME application.
Timestamp	Date and time at which the application communicated the network change or when Change Audit saw the change record.
Summary	Description describing what caused the change. For example, Software upgrade.
Job ID	Job ID for the Software Upgrade.
OldImage	Displays the details on device type, name of the software image, and version of the image.
NewImage	Displays the details on device type, name of the software image, and version of the image.

Usage Examples for cwcli export changeaudit Command

This section provides some examples of usage for the cwcli export changeaudit command.

Example 1: To generate the Change Audit report for all applications and categories for a particular RME device group.

cwcli export changeaudit -u admin -p admin -view "/RME@ciscoworksservername/Normal Devices"

SUMMARY

========

Successful: export: D:/PROGRA~1/CSCOpx/files/rme/archive/2004-10-15-04-09-42-changeaudit.xml

Example 2: To generate the Change Audit report for a specific application and category for a device in a given time frame

cwcli export changeaudit -u admin -p admin -device 10.6.8.6 -from 09/30/2004 -to 10/15/2004 -app "Archive Mgmt" -cat CONFIG_CHANGE

SUMMARY

========

Successful: export: D:/PROGRA~1/CSCOpx/files/rme/archive/2004-10-15-04-44-50-changeaudit.xml

Example 3: To generate the Change Audit report in the given output file

cwcli export changeaudit -u admin -p admin -device % -f changeaudit.xml

SUMMARY

========

Successful: export: changeaudit.xml

The output for this is written to the changeaudit.xml file in the Install_dir/CSCOpx/bin directory. Where Install_dir is the CiscoWorks installed directory.

Example 4: To generate the Change Audit using the cwcli get request

The password that you enter here must be in base64 encoded.

In this example,

•YWRtaW4= is the base64 encoded password for admin.

•%25 is the URL encode for "%"

•%2f is the URL encode for "_"

Enter this in your browser:

http://ciscowork_servername:1741/rme/cwcli?command=cwcli export changeaudit -u admin -p YWRtaW4= -device 10.7.3.8 -app %22Archive Mgmt%22 -cat %22CONFIG%2fCHANGE%22 -f changeaudit.xml

The output for this is written to the changeaudit.xml file.The changeaudit.xml file is located:

On Windows:

NMSROOT\MDC\tomcat

Where, NMSROOT is the CiscoWorks installed directory.

On Solaris:

/opt/CSCOpx/objects/dmgt

Example 5: To generate the Change Audit report using cwcli post request method

The password that you enter here must be in base64 encoded. In this example, YWRtaW4= is the base64 encoded password for admin.

The payload file, changeaudit.xml contains:

<payload>

<command>

cwcli export changeaudit -u admin -p YWRtaW4= -device 1.6.8.6 -from 09/30/2004 -app "Archive Mgmt" -cat CONFIG_CHANGE -view "/RME@CiscoWorks_servername/Pre-deployed" -f changeauditreport.xml

</command>

</payload>

At the command prompt enter:

perl samplepost.pl https://CiscoWorks_Servername:443/rme/cwcli changeaudit.xml

To invoke the servlet using a script, see the Sample Script to Invoke the Servlet.

SUMMARY

========

Successful: export: changeauditreport.xml

<!-- Processing complete -->

The output for this is written to the changeauditreport.xml file.The changeauditreport.xml file is located:

On Windows:

NMSROOT\MDC\tomcat

Where, NMSROOT is the CiscoWorks installed directory.

On Solaris:

/opt/CSCOpx/objects/dmgt

Running cwcli export config

Using this command you can retrieve the configuration data in the XML format specified by the schema. The Configlet Generator provides a wrapper over the existing Config Archive to retrieve configlets data for the selected device. The exported data contains the entire running configuration data.

The command syntax for cwcli export config is:

cwcli export config{-u username -p password} [-d debuglevel] [-m mailid] [-l logfile] {-device devicename | -input inputfilename | -view viewname | - ipaddress mgmt-ip-address}

Arguments in square brackets ([]) are optional; arguments in curly braces ({}) are required. You must provide one argument from each group of arguments in curly braces ({}) that is separated by vertical bars (|).

If you enter an argument which has space then use double quotes for that argument.

The following table describes the argument that is specific to
cwcli export config command. The other common arguments used by
cwcli export are explained in Using the cwcli export Command.

Arguments

Description

-s 1

Optional. Displays the exported configuration file on the console. If you use this command, you can specify only one device. You cannot export the configuration files of multiple devices. To export the configuration files of multiple devices, either make multiple requests to the servlet, or get these files from the CiscoWorks server. Usage of this option: cwcli export config -u admin -p admin -device 10.22.33.44 -s 1

The output files depends on the number of devices specified. There are as many configuration XML output files as the number of devices. The output files are created under this location on CiscoWorks server:

On Solaris: /var/adm/CSCOpx/files/rme/cwconfig/YYYY-MM-DD-HH-MM-SS-XXX-Device_Display_Name.xml

On Windows: NMSROOT\files\rme\cwconfig\YYYY-MM-DD-HH-MM-SS-XXX-Device_Display_Name.xml

Where NMSROOT is the CiscoWorks installed directory.

XML Schema for cwcli export config

The following is the schema used for exporting the configuration data in XML format.

<?xml version="1.0" encoding="UTF-8"?> 

<!-- edited with XMLSPY v5 rel. 4 U (http://www.xmlspy.com) by Cisco --> 

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" 
attributeFormDefault="unqualified"> 

<xs:element name="DeviceConfiguration"> 

<xs:annotation> 

<xs:documentation>This has list of Configlets</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element ref="Confilglet" maxOccurs="unbounded"/> 

<xs:element name="DeviceName" type="xs:string"> 

<xs:annotation> 

<xs:documentation>Device Name as managed by RME</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="DeviceFamily" type="xs:string"> 

<xs:annotation> 

<xs:documentation>MDF devcie family</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="CreationTime" type="xs:date"> 

<xs:annotation> 

<xs:documentation>Date and Time this was created</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="Version" type="xs:string"> 

<xs:annotation> 

<xs:documentation>Config File Version</xs:documentation> 

</xs:annotation> 

</xs:element> 

<xs:element name="Data" minOccurs="0"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name="Confilglet"> 

<xs:annotation> 

<xs:documentation>Configlet can have subconfiglets</xs:documentation> 

</xs:annotation> 

<xs:complexType> 

<xs:sequence> 

<xs:element ref="Confilglet" minOccurs="0" maxOccurs="unbounded"/> 

<xs:element name="command" minOccurs="0" maxOccurs="unbounded"> 

<xs:complexType> 

<xs:simpleContent> 

<xs:extension base="xs:string"> 

<xs:attribute name="LineNo"/> 

</xs:extension> 

</xs:simpleContent> 

</xs:complexType> 

</xs:element> 

<xs:element name="SubModeCommand" type="xs:string" minOccurs="0"> 

<xs:annotation> 

<xs:documentation>Command to change the mode</xs:documentation> 

</xs:annotation> 

</xs:element> 

</xs:sequence> 

<xs:attribute name="Name" type="xs:string" use="required"> 

<xs:annotation> 

<xs:documentation>Configlet Name</xs:documentation> 

</xs:annotation> 

</xs:attribute> 

<xs:attribute name="Checkedout" type="xs:boolean" use="optional" default="false"> 

<xs:annotation> 

<xs:documentation>Future Use </xs:documentation> 

</xs:annotation> 

</xs:attribute> 

<xs:attribute name="Rebuild" type="xs:boolean" use="optional" default="false"> 

<xs:annotation> 

<xs:documentation>Specifies if the entire list of commands in particular configlet needs a rebuild if any of 
the coammnds is modified</xs:documentation> 

</xs:annotation> 

</xs:attribute> 

<xs:attribute name="Submode" type="xs:boolean" use="optional" default="false"> 

<xs:annotation> 

<xs:documentation>Specfies if the commands under the configlet falls under a submode</xs:documentation> 

</xs:annotation> 

</xs:attribute> 

<xs:attribute name="OrderSensitive" type="xs:boolean" use="optional" default="false"> 

<xs:annotation> 

<xs:documentation>Specifies if the commands in the configlet are oreder sensitive or not</xs:documentation> 

</xs:annotation> 

</xs:attribute> 

</xs:complexType> 

</xs:element> 

</xs:schema> 

Detailed Description of config Schema

The table below describes elements in the config schema:

Field	Description
Device	Device display name as entered in the Device and Credential Repository.
Date	Date and time at which the configuration changes have occurred.
Version	Configuration file version.
Configlet name	Name of the configlet. The available configlets vary from device to device; the following are examples: •SNMP displays SNMP configuration commands, for example, snmp-server community public RO. •IP Routing displays IP routing configuration commands, for example, router abcd 100. •Interface folder displays the different interface configuration commands, for example, Interface Ethernet0 and Interface TokenRing. •Global displays global configuration commands, for example no ip address. •Line con 0 displays configuration commands for line console 0. •IP displays IP configuration commands, for example, ip http server.

Usage Examples for cwcli export config Command

This section provides some examples of usage for the cwcli export config command.

Example 1: To generate the config report for a particular RME device group

cwcli export config -u admin -p admin -view "/RME@ciscoworksservername/Normal Devices"

SUMMARY

========

Successful: ConfigExport:D:/PROGRA~1/CSCOpx/files/rme/cwconfig

The output folder will contain separate config file for every devices in the Normal Devices group.

Example 2: To generate the config report for the devices that are specified in the device input file

The input configdevices.txt contains these devices:

-device 10.22.33.44,10.22.33.55,1.1.1.1

cwcli export config -u admin -p admin -input configdevices.txt

Example 3: To generate the config using the cwcli get request

The password that you enter here must be in base64 encoded.

In this example,

•YWRtaW4= is the base64 encoded password for admin.

•%25 is the URL encode for "%"

Enter this in your browser:

http://ciscowork_servername:1741/rme/cwcli?command=cwcli export config -u admin -p YWRtaW4= -device %25

<!-- Processing Starts -->

SUMMARY

========

Successful: ConfigExport: D:/PROGRA~1/CSCOpx/files/rme/cwconfig

<!-- Processing complete -->

Example 4: To generate the Change Audit report using cwcli post request method

The password that you enter here must be in base64 encoded. In this example, YWRtaW4= is the base64 encoded password for admin.

The payload file, config.xml contains:

<payload>

<command>

cwcli export config -u admin -p YWRtaW4= -device 1.6.8.6

</command>

</payload>

At the command prompt enter:

perl samplepost.pl https://CiscoWorks_Servername:443/rme/cwcli config.xml

<!-- Processing Starts -->

SUMMARY

========

Successful: ConfigExport: D:/PROGRA~1/CSCOpx/files/rme/cwconfig

<!-- Processing complete -->

To invoke the servlet using a script, see the Sample Script to Invoke the Servlet.

Running cwcli export inventory Command

Using this command you can export inventory data in the XML format.

The command syntax for cwcli export inventory is:

cwcli export inventory {-u username -p password}[-d debuglevel] [-m mailid] [-l logfile] [-f filename] {-device devicename | -input inputfilename | -view viewname | - ipaddress mgmt-ip-address} [-hop hopdevice]

The above command retrieves the inventory data in XML format specified by the schema. The -f parameter stores the output in the file specified by filename. If you have not specified the filename, the output is stored at the following location:

PX_DATADIR/rme/archive/timestampinventory.xml

Where PX_DATADIR is the NMSROOT/files directory and NMSROOT is the RME installed directory.

The device name can also have a wild card symbol "%" to choose all devices with that particular name.

If the number of devices is large, the list of devices can be stored in an input file and the name of the input file can be given in the command line.The input argument cannot occur with the device or view arguments.

If the data needs to be generated for all the devices in a specific group, you can use the -view argument. You can use this argument to generate data for devices in all RME device groups including system-defined groups and user-defined groups.

The following table describes the arguments that are specific to cwcli export inventory command. The other common arguments used by cwcli export are explained in Using the cwcli export Command.

Arguments	Description
-hop hopdevice	Optional Used to increase performance by using more memory. This indicates the number of devices to be worked upon at a time. By default, this value is 1.

Given below is the list of combinations, which could occur for the inventory command.

cwcli export inventory -u admin -p admin -f myinv.xml

cwcli export inventory -u admin -p admin -f myinv.xml -device device1

cwcli export inventory -u admin -p admin -device device%

cwcli export inventory -u admin -p admin -input inv.txt

cwcli export inventory -u admin -p admin -view "/RME@ciscoworksservername/Normal Devices"

cwcli export inventory -u admin -p admin -f myinv.xml -input inv.txt

To apply the cwcli export command on more than one CiscoWorks device you must use the format in the example given below. The parameter, inputlist, is a text file which will have the list of device names separated by a new line. A line starting with # will be treated as a comment.

Example:

#comment

-device device1,device2,device3

#comment

where device1, device2, and device3 are device displaynames.

XML Schema for cwcli export inventory Data

The following is the schema used for exporting the inventory data in XML format.

<?xml version = "1.0" encoding = "UTF-8"?> 

<xs:schema xmlns:xs = "http://www.w3.org/2001/XMLSchema" elementFormDefault = "qualified" 
attributeFormDefault = "unqualified"> 

        <!--This schema is based on the classes defined in Cisco Information Model V2.0 (CIMCXV2.0) 

Each Device has Chassis and NetworkElement. 

Chassis: 

        Chassis contains a blackplane and multiple Cards. Each Card contains CommunicationConnectors and 
multiple daughter cards. Flash Devices reside on the Cards. 

NetworkElement: 

System Information, Interface Information and LogicalModules. LogicalModules contain OSElements and Logical 
Ports. 

The element AdditionalInformation is meant to capture device specific details that are not part of the common 
schema. 

--> 

<xs:element name = "InvDetails"> 

<xs:complexType> 

<xs:sequence> 

<xs:element ref = "SchemaInfo" minOccurs = "0" maxOccurs = "1"/> 

<xs:element ref = "RMEPlatform" minOccurs = "0" maxOccurs = "unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "SchemaInfo"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name = "RMEServer" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "CreatedAt" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "SchemaVersion" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "RMEPlatform"> 

<xs:complexType> 

<xs:sequence> 

<xs:element ref = "Cisco_Chassis" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "Cisco_NetworkElement" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "Cisco_ComputerSystemPackage" minOccurs = "0" maxOccurs = "unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "Cisco_Chassis"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name = "InstanceID" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "Model" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "HardwareVersion" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "SerialNumber" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "ChassisSystemType" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "NumberOfSlots" type = "xs:integer" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "NoOfCommunicationConnectors" type = "xs:integer" minOccurs = "0" maxOccurs = "1"/> 

<xs:element ref = "Cisco_Backplane" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "Cisco_Card" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "AdditionalInformation" minOccurs = "0" maxOccurs = "unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "Cisco_Backplane"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name = "BackplaneType" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "Model" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "SerialNumber" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element ref = "AdditionalInformation" minOccurs = "0" maxOccurs = "unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "Cisco_Card"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name = "InstanceID" type = "xs:integer" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "RequiresDaughterBoard" type = "xs:boolean" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "Model" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "SerialNumber" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "LocationWithinContainer" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "PartNumber" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "CardType" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "HardwareVersion" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "Description" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "OperationalStatus" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "FWManufacturer" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "Manufacturer" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "NumberOfSlots" type = "xs:integer" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "NoOfCommunicationConnectors" type = "xs:integer" minOccurs = "0" maxOccurs = "1"/> 

<xs:element ref = "SoftwareIdentity" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "Cisco_CommunicationConnector" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "Cisco_FlashDevice" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "Cisco_PhysicalMemory" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "Cisco_Card" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "AdditionalInformation" minOccurs = "0" maxOccurs = "unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "Cisco_CommunicationConnector"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name = "InstanceID" type = "xs:integer" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "ConnectorType" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "Description" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "POEAdminStatus" type = "xs:string" minOccurs = "0" maxOccurs = "1"/>

<xs:element name = "MaximumPower" type = "xs:string" minOccurs = "0" maxOccurs = "1"/>

<xs:element name = "PowerAllocated" type = "xs:string" minOccurs = "0" maxOccurs = "1"/>

<xs:element ref = "AdditionalInformation" minOccurs = "0" maxOccurs = "unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "Cisco_FlashDevice"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name = "InstanceID" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "InstanceName" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "FlashDeviceType" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "Size" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "NumberOfPartitions" type = "xs:integer" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "ChipCount" type = "xs:integer" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "Description" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "Removable" type = "xs:boolean" minOccurs = "0" maxOccurs = "1"/> 

<xs:element ref = "Cisco_FlashPartition" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "AdditionalInformation" minOccurs = "0" maxOccurs = "unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "Cisco_FlashPartition"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name = "InstanceID" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "InstanceName" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "Upgrade" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "NeedsErasure" type = "xs:boolean" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "PartitionStatus" minOccurs = "0" maxOccurs = "1"> 

<xs:simpleType> 

<xs:restriction base = "xs:string"> 

<xs:enumeration value = "unknown"/> 

<xs:enumeration value = "readOnly"/> 

<xs:enumeration value = "runFromFlash"/> 

<xs:enumeration value = "readWrite"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name = "FileSystemSize" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "AvailableSpace" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "FileCount" type = "xs:integer" minOccurs = "0" maxOccurs = "1"/> 

<xs:element ref = "Cisco_FlashFile" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "AdditionalInformation" minOccurs = "0" maxOccurs = "unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "Cisco_FlashFile"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name = "InstanceID" type = "xs:integer" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "FileSize" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "FileStatus" minOccurs = "0" maxOccurs = "1"> 

<xs:simpleType> 

<xs:restriction base = "xs:string"> 

<xs:enumeration value = "unknown"/> 

<xs:enumeration value = "deleted"/> 

<xs:enumeration value = "invalidChecksum"/>

<xs:enumeration value = "valid"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name = "Checksum" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "InstanceName" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element ref = "AdditionalInformation" minOccurs = "0" maxOccurs = "unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "Cisco_PhysicalMemory"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name = "MemoryType" minOccurs = "0" maxOccurs = "1"> 

<xs:simpleType> 

<xs:restriction base = "xs:string"> 

<xs:enumeration value = "nvRam"/> 

<xs:enumeration value = "NVRAM"/> 

<xs:enumeration value = "processorRam"/> 

<xs:enumeration value = "RAM"/> 

<xs:enumeration value = "ROM"/> 

<xs:enumeration value = "FEPROM"/> 

<xs:enumeration value = "BRAM"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name = "Capacity" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element ref = "AdditionalInformation" minOccurs = "0" maxOccurs = "unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "Cisco_NetworkElement"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name = "InstanceID" type = "xs:integer" maxOccurs = "1"/> 

<xs:element name = "Description" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "PrimaryOwnerName" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "InstanceName" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "PhysicalPosition" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "SysObjectId" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "SysUpTime" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "OfficialHostName" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "NumberOfPorts" type = "xs:integer" minOccurs = "0" maxOccurs = "1"/> 

<xs:element ref = "Cisco_LogicalModule" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "Cisco_Port" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "Cisco_MemoryPool" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "Cisco_IfEntry" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "Cisco_IPProtocolEndpoint" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "Cisco_PEHasIfEntry" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "AdditionalInformation" minOccurs = "0" maxOccurs = "unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "Cisco_LogicalModule"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name = "InstanceID" type = "xs:integer" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "ModuleNumber" type = "xs:integer" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "ModuleType" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "InstanceName" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "EnabledStatus" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "NumberOfPorts" type = "xs:integer" minOccurs = "0" maxOccurs = "1"/> 

<xs:element ref = "Cisco_Port" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "Cisco_LogicalModule" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "Cisco_OSElement" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "AdditionalInformation" minOccurs = "0" maxOccurs = "unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "Cisco_Port"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name = "PortNumber" type = "xs:integer" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "PortType" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "InstanceName" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "IfInstanceID" type = "xs:integer" minOccurs = "0" maxOccurs = "unbounded"/> 

<xs:element ref = "AdditionalInformation" minOccurs = "0" maxOccurs = "unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "Cisco_MemoryPool"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name = "InstanceName" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "PoolType" type = "xs:integer" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "DynamicPoolType" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "AlternatePoolType" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "IsValid" type = "xs:boolean" minOcurs = "0" maxOccurs = "1"/> 

<xs:element name = "Allocated" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "Free" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "LargestFree" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element ref = "AdditionalInformation" minOccurs = "0" maxOccurs = "unbounded"/> 

<!--PoolType ValueMap  {"0", "1", "2", "3", "4", "5", "65536"}, 

Values {"Unknown", "Processor", "I/O", "PCI", "Fast", "Multibus", "Dynamic"}, 

--> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "Cisco_OSElement"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name = "InstanceName" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "OSFamily" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "Version" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "Description" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element ref = "AdditionalInformation" minOccurs = "0" maxOccurs = "unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "Cisco_IfEntry"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name = "InstanceID" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "InstanceName" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "ProtocolType" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "Speed" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "RequestedStatus" minOccurs = "0" maxOccurs = "1"> 

<xs:simpleType> 

<xs:restriction base = "xs:string"> 

<xs:enumeration value = "up"/> 

<xs:enumeration value = "down"/> 

<xs:enumeration value = "testing"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name = "OperationalStatus" minOccurs = "0" maxOccurs = "1"> 

<xs:simpleType> 

<xs:restriction base = "xs:string"> 

<xs:enumeration value = "Up"/> 

<xs:enumeration value = "Down"/> 

<xs:enumeration value = "Testing"/> 

<xs:enumeration value = "Unknown"/> 

<xs:enumeration value = "Dormant"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name = "Description" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "PhysicalAddress" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "NetworkAddress" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element ref = "AdditionalInformation" minOccurs = "0" maxOccurs = "unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "Cisco_IPProtocolEndpoint"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name = "Address" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "SubnetMask" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "DefaultGateway" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element ref = "AdditionalInformation" minOccurs = "0" maxOccurs = "unbounded"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "Cisco_PEHasIfEntry"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name = "Cisco_IPProtocolEndpoint" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "Cisco_IfEntry" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "Cisco_ComputerSystemPackage"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name = "Antecedent" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<xs:element name = "Dependent" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

<!-- 

Antecedent is the InstanceID from Cisco_Chassis Element 

Dependent is the InstanceID from Cisco_NetworkElement 

--> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "SoftwareIdentity"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name = "Classification" minOccurs = "0" maxOccurs = "1"> 

<xs:simpleType> 

<xs:restriction base = "xs:string"> 

<xs:enumeration value = "Firmware"/> 

<xs:enumeration value = "Software"/> 

</xs:restriction> 

</xs:simpleType> 

</xs:element> 

<xs:element name = "VersionString" type = "xs:string" minOccurs = "0" maxOccurs = "1"/> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

<xs:element name = "AdditionalInformation"> 

<xs:complexType> 

<xs:sequence> 

<xs:element name = "AD" minOccurs = "0" maxOccurs = "unbounded"> 

<xs:complexType> 

<xs:attribute name = "name" type = "xs:string"/> 

<xs:attribute name = "value" type = "xs:string"/> 

</xs:complexType> 

</xs:element> 

</xs:sequence> 

</xs:complexType> 

</xs:element> 

</xs:schema> 

Detailed Description of the Inventory Schema

The inventory schema provides the structure for the inventory information exported from Resource Manager Essentials (RME). The schema divides inventory information into two groups:

•Physical Inventory

•Logical Inventory

The Physical Inventory contains the chassis information and related details for the device. The main elements in the schema for the physical inventory part are:

•Chassis (Cisco_Chassis

•Backplane (Cisco_ Backplane

•Card (Cisco_Card)

•CommunicationConnector (Cisco_CommunicationConnector)

•FlashDevice (Cisco_FlashDevice)

•FlashPartition (Cisco_FlashPartition)

•FlashFile (Cisco_FlashFile)

•.SoftwareIdentity (Cisco_SoftwareIdentity)

•PhysicalMemory (Cisco_PhysicalMemory)

The Logical Inventory part of the schema contains the details of the managed network element. The main elements in the schema for the logical inventory part are:

•.ManagedNetworkElement (Cisco_NetworkElement)

•LogicalModule (Cisco_LogicalModule)

•Port (Cisco_Port)

•MemoryPool (Cisco_MemoryPool)

•OSElement (Cisco_OSElement)

•IPProtocolEndpoint (Cisco_IPProtocolEndpoint)

•IfEntry (Cisco_IfEntry)

•Additional Information

Chassis (Cisco_Chassis

The Chassis class represents the physical elements that enclose other elements in the device and provide specific functions, such as a desktop, networking node, UPS, disk or tape storage, or a combination of these functions.

The following table describes the elements in Chassis:

Element	Description
InstanceID	Unique identifier.
Model	Chassis model / Chassis ID.
Version	Hardware version of the chassis
SerialNumber	Serial number associated with the chassis.
Type	Chassis type.
NumberOfSlots	Number of slots in a chassis.
NoOfCommunicationConnectors	Number of physical connectors in a chassis.

Chassis also contains the elements Card and Backplane.

Backplane (Cisco_ Backplane

Backplane is an instance of a backplane in a chassis. The following table describes the elements in Backplane:

Element	Description
BackplaneType	Type of backplane
Model	Model of the backplane
SerialNumber	Serial number of the backplane.

Card (Cisco_Card)

Card represents:

•A type of physical container that can be plugged into another card, motherboard, or hosting board

•A motherboard or hosting board in a chassis

This element includes any package capable of carrying signals and providing a mounting point for physical components such as chips, or other physical packages such as other cards. The following table describes the elements in Card:

Element	Description
InstanceID	Card number. This is used to correlate with the logical part of the card.
Model	Model of the card.
SerialNumber	Serial number of the card.
LocationWithinContainer	Number that indicates the physical slot number. This can be used as an index into a system slot table, irrespective of whether that slot is physically occupied or not.
PartNumber	Part number of the Hardware Component.
CardType	Type of the card (Card Type)
Description	Descriptive string used to describe the card.
OperationalStatus	Status of the card describing whether it is up or down
FWManufacturer	Manufacturer of the firmware
Manufacturer	Manufacturer of the hardware
NumberOfSlots	Number of slots in the card.
NoOfCommunicationConnectors	Number of ports in the card.

Apart from the elements described in the table above, the card element also contains reference to itself, which can represents a sub card. It also contains other elements such as CommunicationConnector and FlashDevice.

CommunicationConnector (Cisco_CommunicationConnector)

CommunicationConnector represents a physical port. The table below describes the elements in CommunicationConnector:

Element	Description
InstanceID	Indicates the connector number for the chassis or system.
ConnectorType	Type of the physical port.
Description	Descriptive string used to describe the card.

FlashDevice (Cisco_FlashDevice)

FlashDevice represents physical flash memory. Flash memory may reside on a PCMCIA card, line card, or any other type of card. FlashDevice may consist of one or more actual flash memory chips.

It also consists of reference to one or more flash partitions described in FlashPartition. The table below describes the elements in FlashDevice.

Element	Description
InstanceID	FlashDevice sequence number to index the flash devices within the table of initialized FlashDevices.
InstanceName	Name of FlashDevice. This name is used to refer to the device within the system. Flash operations get directed to a device based on this name.
Size	Total size of FlashDevice. For a removable device, the size will be zero if the device has been removed.
NumberOfPartitions	Number of Flash partitions present in f FlashDevice
ChipCount	Total number of chips within FlashDevice. This element provides information to a network management station on how much chip information to expect. It also helps the management station to check the chip index against an upper limit when randomly retrieving chip information for a partition.
Description	Description of a FlashDevice. The description is meant to explain what FlashDevice is and its purpose.
Removable	Specifies whether FlashDeviceis removable. Typically, only PCMCIA Flash cards are treated as removable. Socketed Flash chips and Flash SIMM modules are not treated as removable.

FlashPartition (Cisco_FlashPartition)

FlashPartition corresponds to the Cisco-flash-mib. The elements in FlashPartiion are derived from the table of properties of ciscoFlashPartitionTable for each initialized flash partition.

When there is no explicit partitioning for a device, it is assumed that there is a single partition spanning the entire device exists. Therefore, a device always has at least one partition.

FlashPartition contains one or more FlashFileSystems as described in FlashFile. The table below describes the elements in FlashPartition.

Element	Description
InstanceID	FlashPartition sequence number used to index FlashPartitions within the table for initialized FlashPartitions.
InstanceName	FlashPartition name used to refer to a partition by the system.
PartitionStatus	Status of the partition.
Upgrade	Upgrade information for the partition. This helps to download new files into the partition, and is needed when the PartitionStatus is run from flash.
NeedsErasure	Boolean parameter indicating whether the partition requires to be erased before any write operations can occur.
Size	FlashPartition size. It should be an integral multiple of ciscoFlashDeviceMinPartitionSize. If there is a single partition, this size will be equal to ciscoFlashDeviceSize.
FreeSpace	Free space within aFlashPartition.
FileCount	Number of files stored in the file system.

FlashFile (Cisco_FlashFile)

FlashFile manages the storage and organization of files on a Flash memory device. The table below describes the elements in FlashFile

Element	Description
InstanceID	FlashFile sequence number used to index within a FlashPartition directory table.
FileSize	Size of the file in bytes.This size does not include the size of the filesystem file header.
FileStatus	Status of a file. A file could be explicitly deleted if the file system supports such a user command. Alternatively, an existing good file would be automatically deleted if another good file with the same name were copied in. Deleted files continue to occupy prime space in flash memory. A file is marked as having an invalid checksum if any checksum mismatch was detected while writing or reading the file. Incomplete files (files truncated either because of lack of free space, or because of a network download failure) are also written with a bad checksum and marked as invalid.
Checksum	File checksum stored in the file header. This checksum is computed and stored when the file is written into Flash memory, and serves to validate the data written into Flash. Where the system generates and stores the checksum internally in hexadecimal form, checksum provides the checksum in a string form. Checksum is available for all valid and invalid-checksum files.
FileName	FlashFile name as specified by the user while copying the file to Flash memory. The name should not include the colon (:) character as it is a special separator character used to separate the device name, partition name, and the file name.

.SoftwareIdentity (Cisco_SoftwareIdentity)

SoftwareIdentity provides the hardware and firmware version of the card. The table below describes elements in SoftwareIdentity.

Element	Description
Classification	Specifies whether the information is for hardware or firmware.
VersionString	Version information for software or firmware.

PhysicalMemory (Cisco_PhysicalMemory)

PhysicalMemory specifies the memory type and capacity of the device. The table below describes elements in PhysicalMemory.

Element	Description
MemoryType	Specifies the type of memory, that is whether RAM, ROM, or NVRAM.
Capacity	Capacity in bytes.

.ManagedNetworkElement (Cisco_NetworkElement)

ManagedNetworkElement is the entity that contains all logical parts of the device, which the users can configure (such as Logical Module, Port, Interfaces, Software Image details, and Memory Pool). The table below describes elements in ManagedNetworkElement.

Element	Description
InstanceID	Index number assigned to the network element.
Description	Description of the network element. This description includes the full name and version identification of the system's hardware type, operating system, and networking software. The description can have only printable ASCII characters.
PrimaryOwnerName	Identification of the contact person for this managed node, and information on how to contact this person.
InstanceName	Administratively defined name for the network element.
PhysicalPosition	Physical location of the network element.
SysObjectId	Vendor's authoritative identification of the management subsystem contained in the element.
SysUpTime	Time in hundredths of a second since the network management portion of the element was last initialized.
OfficialHostName	Name of the device.
NumberOfPorts	Number of ports in the network element.

LogicalModule (Cisco_LogicalModule)

LogicalModule is the logical device corresponding to a line card in the network device.

For example, a line card in a switch is an instance of LogicalModule, associated with the ManagedNetworkElement, in this case the switch. LogicalModule is not necessarily independently managed.

To represent a sub module, LogicalModule contains a reference to itself. It also contains Port and the OSElement. The table below describes the other elements in LogicalModule.

Element	Description
InstanceID	Index that correlates the physical card and the logical module. This helps to correlate the physical card to logical card details.
ModuleNumber	Number assigned to the module by its parent ManagedNetworkElement.
ModuleType	Type or model of the module.
InstanceName	Name of the logical module.
EnabledStatus	Status of the module, that is whether it is up or down.
NumberOfPorts	Number of ports in the logical module.

Port (Cisco_Port)

Port is the logical representation of network communications hardware - a physical connector and the setup or operation of the network chips, at the lowest layers of a network stack

For example, an Ethernet port on an Ethernet line card uses an instance of Port to represent its operational and logical properties. A port should be associated with either a LogicalModule or directly with a ManagedNetworkElement.

It also contains the element IPProtocolEndpoint. The table below describes the other elements in Port.

Element	Description
PortNumber	Number assigned to the port. Ports are often numbered relative to either a logical module or a network element.
PortType	Type of the port.
InstanceName	Name assigned to the port.
IfInstanceID	Index of the interface related to this port.

MemoryPool (Cisco_MemoryPool)

MemoryPool corresponds to entries to monitor entries. Each pool is a range of memory segregated by type or function. The table below describes the other elements in MemoryPool.

Element	Description
InstanceName	Name assigned to the MemoryPool.
PoolType	Dynamic type value assigned to a dynamic MemoryPool. This is valid only when the PoolType attribute has the value Dynamic. MemoryPools can be divided into two groups Predefined Pools and Dynamic Pools. For dynamic pools, the PoolType is set to the dynamic value (65536) and the DynamicPoolType is set to an integer value used to distinguish the various dynamic pool types.
DynamicPoolType	This attribute holds the dynamic type value assigned to a dynamic memory pool. It is only valid when the PoolType attribute has the value Dynamic (65536).
AlternatePoolType	Indicates whether this MemoryPool has an alternate pool configured. Alternate pools are used for fallback when the current pool runs out of memory. If the value is set to zero, then this pool does not have an alternate. Otherwise the value is the same as the value of PoolType of the alternate pool.
IsValid	Indicates whether the other attributes in this MemoryPool contain accurate data. If an instance of this object has the value, False, (indicating an internal error condition), the values of the remaining objects in the instance may contain inaccurate information. That is, the reported values may be less than the actual values.
Used	Indicates the number of bytes from the MemoryPool that are currently in use by applications on the managed device.
Allocated	Indicates the number of bytes from the MemoryPool that are currently unused on the managed device.
Free	Indicates the largest number of contiguous bytes from the MemoryPool that are currently unused on the managed device.

OSElement (Cisco_OSElement)

OSElement represents the software element that is deployed to a network system and describes the software behind the operating system.The table below describes the other elements in OSElement.

Element	Description
InstanceName	Name of the OS image.
Family	Family of the OS component.
Version	Version of the OS.
Description	Description of the OS image.

IPProtocolEndpoint (Cisco_IPProtocolEndpoint)

IPProtocolEndpoint contains the subnet mask and default gateway information corresponding to the management IP Address.

Element	Description
Address	IP address of this endpoint, formatted according to the convention as defined in the AddressType property of this class.
SubnetMask	Mask for the IP address of this element, formatted according to the convention as defined in the AddressType property of this class (e.g., 255.255.252.0).
DefaultGateway	Default gateway address.

IfEntry (Cisco_IfEntry)

IfEntry represents the contents of an entry in the ifTable as defined in RFC 1213.

Element	Description
InstanceID	Index in the interface table defined in RFC 1213 for the entry containing the interface attributes of this object.
InstanceName	ifName attribute in the interface table defined in RFC 1213.
IfType	Interface type enumeration taken from the IANA definition of ifType.
IfSpeed	Estimate of the current bandwidth of the interface in bits per second. In cases, where the current bandwidth cannot be given, the nominal bandwidth should be specified.
IfAdminStatus	Desired state of the interface.
IfOperStatus	Current operational status of the interface.
Description	Description of the interface.
PhysicalAddress	Hardware address of the interface.
NetworkAddress	Network address of the interface.

Additional Information

AdditionalInformation is used to describe device specific information. It contains name and value attributes for elements specific to the device.

Class	Element	AdditionalInformation Tag
Cisco Call Manager	Cisco_NetworkElement	ActivePhones, InActivePhones, ActiveGateways, InActiveGateways, CallManagerIndex, CallManagerName, CallManagerDescription, CallManagerVersion, CallManagerStatus
	Cisco_Chassis	ApplicationPackageIndex, PackageManufacturer, Productname, Packageversion, Package SerialNumber
Cisco FastSwitch With_Module	Cisco_NetworkElement	FwdEngRev, BoardRev, SwitchPortNumber , SharedPortNumber, FirmwareSource
	Cisco_FlashDevice	FlashBankStatus
	Cisco_Card	InstanceID, ID
Cisco Firewall	None	None
Cisco IPX-IGX-BPX	Cisco_Chassis	InstanceName , Number
	Cisco_Card	SecondarySwRev, slotIndex, RAMId, ROMId, BRAMId, BOOTId, LocationWithinContainer, SecondaryStatus
	Cisco_Port	switchIfSlot,switchIfPort, SubPortNo, Status, Speed, PortType
Cisco LS1010 Switch	Cisco_Chassis	Slot0 (Type), Slot1(Type), AvailableSlots
	Cisco_NetworkElement	ConfigReg
	Cisco_PhysicalMemory	NVRAMUsed, RomVersion
Cisco MGX	Cisco_Chassis	Name, switchIfSlot, switchIfPort, SubPortNo, Status, Speed, PortType
Cisco Catalyst 3900 Switch	Cisco_Chassis	ModuleCount, Configuration, SwitchCount
	Cisco_Card	CiscoTsNumber, PermanentMAC, LocalMAC, CiscoTsModNumber , StackNo
Cisco Router 700 Series	Cisco_Chassis	MACAddress, PortCount, Type
Cisco Router	Cisco_PhysicalMemory	NVRAMUsed, ROMVersion
	Cisco_NetworkElement	Config
Cisco Catalyst IOS Switch	Cisco_Chassis	MACAddress, PortCount, Type
	Cisco_Card	FlashSize,FlashFree,FlashCard
	Cisco_Chassis	Config
	Cisco_PhysicalMemory	NVRAMUsed, ROMVersion
Cisco Catalyst L2L3 Switch	Cisco_Chassis	Slot0, Slot1 , MACAddress, PortCount, Type
	Cisco_NetworkElement	Config
	Cisco_PhysicalMemory	NVRAMUsed, ROMVersion
Cisco VPN 3000 Concentrators	Cisco_Chassis	PowerSupply1Type, PowerSuppy2Type, RAMSize
	Cisco_Card	LocationWithinContainer, CryptoHardwareType, SepState, DSPCodeVersion
Cisco Catalyst Switch	Cisco_Chassis	PowerSupply1, PowerSupply2 , MgmtType, BroadcastAddress, AvailableSlots
	Cisco_Card	ModuleIndex, RedundantModule, ModuleSubType
	Cisco_LogicalModule	moduleIndex,ModuleIPAddress
Cisco Optical Switches	Cisco_NetworkElement	RFUnitDetected, RFUnitID, RFUnitState, RFPeerUnitID, RFPeerUnitState, ActivateRF, ManualSwitchPermitted , StartupSyncStatus, RunningSyncStatus
	Cisco_PhysicalMemory	NVRAMUsed
Cisco FastSwitch	Cisco_NetworkElement	FwdEngRev, BoardRev, SwitchPortNumber , SharedPortNumber, FirmwareSource
	Cisco_FlashDevice	FlashBankStatus
	Cisco_Chassis	EPROMRev
	Cisco_CommunicationConnector	swPortIndex , PortTableSize, RevName, Type
Cisco Content Service Switch	None	None
Cisco Aironet	Cisco_PhysicalMemory	NVRAMUsed, ROMVersion
	Cisco_NetworkElement	Config
Cisco NAM	None	None
Cisco Management Engines	None	None

Overview: cwcli inventory Command

The cwcli inventory is a RME Device Management application command line tool. This tool supports the following features:

•You can check the specified device credentials for the RME devices.

•You can export device credentials of one or more RME devices in clear text.

•You can delete the specified RME devices.

•You can view the RME devices state.

The cwcli inventory command is located in the following directories, where install_dir is the directory in which CiscoWorks is installed:

•On UNIX systems, /opt/CSCOpx/bin

•On Windows systems, install_dir\CSCOpx\bin

The default install directory is C:\Program Files.

If you install RME on an NTFS partition on Windows, only users in the administrator or casuser group can access cwcli inventory.

You can also perform the cwcli inventory tasks using the servlet. You will have to upload a payload XML file, which contains the cwcli inventory command arguments and CiscoWorks user credentials.

You have to write your own script to invoke the servlet with a payload of this XML file and the servlet returns the output either on the console or in the specified output file, if the credentials are correct and arguments are valid.

The name of the servlet is /rme/cwcli.

The following is the servlet to be invoked to execute any command:

For post request,

perl samplepost.pl http://rme-server:rme-port/rme/cwcli payload_XML_file

The default port for CiscoWorks server in HTTP mode is 1741.

If you have enabled SSL on CiscoWorks server, you can also use https protocol for secured connection.

perl samplepost.pl https://rme-server:rme-port/rme/cwcli payload_XML_file

The default port for CiscoWorks server in HTTPS mode is 443.

The schema for creating the payload file in XML format is:

<payload>

<command>

cwcli inventory commandname -u user -p BAse64 encoded pwd -args1 arg1value...

</command>

</payload>

To invoke the servlet using a script, see the Sample Script to Invoke the Servlet.

The script and the payload file should be residing in the client machine.

For get request,

http://rme-server:rme-port/rme/cwcli?command=cwcli inventory commandname -u user -p BAse64 encoded pwd -args1 arg1value...

The default port for CiscoWorks server in HTTP mode is 1741.

If you have enabled SSL on CiscoWorks server, you can also use https protocol for secured connection.

https://rme-server:rme-port/rme/cwcli?command=cwcli inventory commandname -u user -p BAse64 encoded pwd -args1 arg1value...

The default port for CiscoWorks server in HTTPS mode is 443.

The BAse64 encoded for "admin" is YWRtaW4=.

The URL encode for,

•Double quotes (") is %22

•Percentage sign (%) is %25

Using the cwcli inventory Command

The command line syntax of the application is in the following format:

cwcli inventory command GlobalArguments AppSpecificArguments

The command line syntax of the application is in the following format:

cwcli export command GlobalArguments AppSpecificArguments

•cwcli inventory is the CiscoWorks command line interface for:

–Checking the specified device credentials for the RME devices.

–Exporting device credentials of one or more RME devices in clear text.

–Deleting the specified RME devices.

–Viewing the RME devices state.

•Command specifies which core operation is to be performed.

•GlobalArguments are the additional parameters required for each core command.

•AppSpecificArguments are the optional parameters, which modify the behavior of the specific cwcli inventory core command.

The order of the arguments and arguments are not important. However, you must enter the core command immediately after cwcli inventory.

The following sections describe:

•The cwcli inventory commands (See cwcli inventory Commands)

•The mandatory and optional arguments (See cwcli inventory Global Arguments)

On UNIX, you can view the cwcli inventory man pages by setting the MANPATH to /opt/CSCOpx/man. The man pages to launch the cwcli inventory are:

•man cwinventory-cda to launch the cwcli inventory cda command.

•man cwinventory-delete to launch the cwcli inventory delete command.

•man cwinventory-export to launch the cwcli inventory export command.

•man cwinventory-state to launch the cwcli inventory getdevicestate command

cwcli inventory Commands

The following table lists the command part of the cwcli inventory syntax:

Command	Description
cwcli inventory cda	You can check the specified device credentials for the RME devices. See Running the cwcli inventory cda Command
cwcli inventory crmexport	You can export device credentials of one or more RME devices in clear text. See Running the cwcli inventory crmexport Command
cwcli inventory deletedevice	You can delete the specified RME devices. See Running the cwcli inventory deletedevice Command
cwcli inventory getdevicestate	You can view the RME devices state. See Running the cwcli inventory getdevicestate Command

cwcli inventory Global Arguments

The following describes the mandatory and optional global arguments for
cwcli inventory:

Argument	Description	Usage Notes
-u user	Enter a valid CiscoWorks username.	Mandatory.
-p password	Enter the password for the username.	Mandatory. You can provide this as part of argument or you can enter the password when you get the password prompt. You can also specify the password in a file. See Setting CWCLIFILE Environment Variable for more details.
{-device name | -view name | -device list -view name| -ipaddress list}	device name—Enter the Display name of the device that you have added in the Device and Credentials database (Common Services > Device and Credentials > Device Management)	Mandatory •You can enter multiple device list separated using a comma. For example, if there are two devices with Display Names Rtr12 and Rtr13, using Rtr% will display both the devices. •To include all the devices in the RME, use the wild card character "%". For example, To use all the devices, use -device %.
	view name—Enter the Device Group name.	Mandatory You can enter multiple group name separated using a comma. For view name, you have to enter the fully qualified path as in the Group Administration GUI. For example, -view "/RME@ciscoworks_servername/ All Devices"
	device list view name—Enter the Display name and the Device Group name.	Mandatory.
	ipaddress list—Enter the device IP4 address as entered in the Device and Credential Repository. You can enter multiple IP address with comma separated.	Mandatory. You cannot use this option with -device, -view, or -input. Also, you cannot specify wildcard characters.
[-d debug_level]	Enter the debug level.	Optional. debug_level is a number between 1 (the least information is sent to the debug output) and 5 (the most information is sent to the debug output). If you do not specify this argument, 4(INFO) is the default debug level.
[-m email]	Specify an e-mail address to send the results.	Optional. email is one or more e-mail addresses for notification. They can be separated by a space or comma.
[-l logfile]	Specify a file to which this command has to write log messages. The default log filename is cli.log. The default log directory is: On Windows: NMSROOT\log Where NMSROOT is the CiscoWorks installed directory. On Solaris: /var/adm/CSCOpx/log	Optional. Use the relative pathname to specify the log_filename.
-help	Displays command usage information	None.

Running the cwcli inventory cda Command

You can use this command to check the following device credentials:

•SNMP Read Community String—SNMP version 2 read community string.

•SNMP Write Community String—SNMP version 2 write community string.

•SNMP Version 3—SNMP version 3 username and password.

•Telnet—Telnet username and password.

•Telnet Enable Mode User Name and Password—Telnet username and password in Enable mode.

•SSH—SSH username and password.

•SSH Enable Mode User Name and Password—SSH username and password in Enable mode.

You can update these credentials using Common Services > Device and Credentials > Device Management.

The command syntax for cwcli inventory cda is:

cwcli inventory cda -u userid -p password {-invoke | -status} [-credType credTypeList] {-device list | -view name | -device list -view name | ipaddress list} [-d debuglevel] [-m email] [-help] [-l logfile]

Arguments in square brackets ([]) are optional; arguments in curly braces ({}) are required. You must provide one argument from each group of arguments in curly braces ({}) that is separated by vertical bars (|).

If you do not specify an optional argument, the default value configured for the system is used.

The following table describes the arguments that are specific to cwcli inventory cda command.

The other common arguments used by cwcli export are explained in Using the cwcli export Command

:

Argument	Description	Usage Notes
{-invoke | -status}	Invoke—Invokes the Check Device Attribute operation. Status—Displays the check device attributes result.	Mandatory. These arguments are mutually exclusive. You cannot run -invoke and -status together. After using the -invoke argument to the check device attribute you must run the command again with -status argument to view the result. If you are checking the device credentials for same devices and for same set of credentials, then you can use -invoke argument only once. If you are checking the device credentials for different devices and different credentials then you must use -invoke argument first and then you must use -status.
{-credType credTypeList}	Enter the device credentials for which you want to view the status. You can use the following arguments to view the different credentials status: •0 —Enter 0 to view all credentials status. •1 — Enter 1 to view status for Read Community. •2 — Enter 2 to view status for Write Community. •3 — Enter 3 to view status for SNMP version 3 username and password. •4 — Enter 4 to view status for Telnet username and password. •5 — Enter 5 to view status for Telnet username and password in Enable mode. •6 — Enter 6 to view status for SSH username and password. •7 — Enter 7 to view status for SSH username and password in Enable mode. You can specify multiple arguments separated by comma to check multiple credentials	Mandatory. If you do not specify the credentials type, all credentials status are displayed.
Command Argument for Inventory CDA createjob
{-device comma_separated_devicelist}|{-view device_view_name}	-device comma_separated_devicelist - Specify devices to be used for the job. The comma_separated_devicelist is list of devices. -view device_view_name Specify the device view to be used for the job. The device_view_name is the name of a device view.	Mandatory. These arguments are mutually exclusive. You cannot run -device and -view together. cwcli inventory cda createjob -u Username -p Password -device Device 1, Device 2 |-view device_view_name, -schedule Schedule -scheduletype Schedule Type
[{-schedule MM/dd/yyyy:HH:mm:ss -scheduletype Once | Daily | Weekly | Monthly | LastDayOfMonth | 6hourly | 12hourly}]	You can specify the date and time as well as the frequency of the CDA job. •To specify the date and time when you want to run the CDA job, use the schedule option. •To specify the frequency of the job use the scheduletype option. You have to set both the schedule and scheduletype options for a scheduled job. You do not have to set the schedule and scheduletype for an Immediate job.	Optional. scheduletype can have any of the following values: •Once •6hourly •12hourly •Daily •Weekly •Monthly If the schedule option is not specified, the job will be created as an immediate job.
[-input argFile]	Input file containing the details of the subcommands to be used for a job creation.	Optional If you are specifying the argument file, you need not specify the arguments in the command line. cwcli inventory cda -u admin -p admin [-input argFile]
[-description JobDescription]	Gives details of the job.	JobDescription is a user-defined entry describing the job details.
[-notificationmail comma_separated_email_list]	Specify the e-mail addresses to which the configuration job will sends status notices.	Optional Separate multiple addresses with commas.
{-credType credentialList}	Enter the device credentials for which you want to create a job. You can use the following arguments to view the different credentials status: •0 —Enter 0 to view all credentials status. (ALL). •1 — Enter 1 to view status for Read Community. •2 — Enter 2 to view status for Write Community. •3 — Enter 3 to view status for SNMP version 3 username and password. •4 — Enter 4 to view status for Telnet username and password. •5 — Enter 5 to view status for Telnet username and password in Enable mode. •6 — Enter 6 to view status for SSH username and password. •7 — Enter 7 to view status for SSH username and password in Enable mode. You can specify multiple arguments separated by comma to check multiple credentials.	Mandatory If you do not specify the credentials type, all credentials status are displayed.
Command Argument for Inventory CDA stopjob
{-id Job ID}	You can stop only one job at a time. You can stop a CDA job that is in scheduled as well as running state.	Mandatory Use this command to stop an Inventory CDA job that is scheduled. cwcli inventory cda stopjob -u userid -p password {-id jobID}
Command Argument for Inventory CDA deletejob and jobdetails
{-id Job IDs}	You can delete more than one job at a time. Enter the Job IDs that you want to delete, separated by commas. You can list the details of more than one job at a time. Enter the Job IDs separated by commas.	Mandatory Inventory CDA deletejob command: cwcli inventory cda deletejob -u userid -p password {-id jobID1, jobID2..} Inventory CDA jobdetails command: cwcli inventory cda jobdetails -u userid -p password {-id jobID1, jobID2..}
Command Argument for Inventory CDA listjobs
[-jobstatus status]	You can specify the status of the job. This can be: •All jobs •Running jobs •Completed jobs •Pending jobs.	Optional. cwcli inventory cda listjobs -u Username -p Password [-jobstatus A, R, C, P]
Command Arguments for Inventory CDA jobresults
{-id Job ID, Job ID}	You can list the results of more than one job at a time. Enter the job IDs separated by commas.	cwcli inventory cda jobresults -u Username -p Password -id "Job ID 1" , "Job ID 2" , "Job ID 3"
[-csvoutput filepath]	You can specify the fully qualified pathname for saving the job results.	If you do not specify this argument, the job results appear in the console itself. If the specified path does not exist, the job results are stored in the default location. cwcli inventory cda jobresult -u admin -p admin {-jobid jobID} [-csvoutput filepath]

The Table 20-1 maps the device credentials that you have entered in the Device and Credentials (Common Services > Device and Credentials > Device Management) database and the credentials that appear in the
cwcli inventory cda command:

Table 20-1 Credentials Mapping 

Credentials in Device and Credentials Database	Credentials displayed in cwcli inventory cda
Device Name	deviceName
SNMP V2C RO Community String	ro
SNMP V2C RW Community String	rw
SNMP V3 Username and Password	snmpv3
Primary Credentials Username	telnet
Primary Credentials Username and Primary Enable Password	telnetEnable
Primary Credentials Username	ssh
Primary Credentials Username and Primary Enable Password	sshEnable

Table 20-2 describes the Credential Verification Report Status messages:

Table 20-2 Understanding Credential Verification Report 

Status Message	Description
OK	Check for device credentials completed. The device credentials data in the Device and Credential Repository matches the physical device credentials.
No authentication configured	Device was not configured with authentication mechanism (Telnet/LocalUsername/TACACS). RME was able to use Telnet and log into the device successfully with out using the values entered in the Device and Credential Repository.
Incorrect	Check for device credentials completed. The device credentials data in the Device and Credential Repository does not match with the physical device credentials for one of the following reasons: •The device credentials data in Device and Credential Repository is not correct. •The device is unreachable or offline. •One of the interfaces on the device is down.
No Data Yet	Check for device credentials is in progress.
Did Not Try	Check for device credentials is not performed for one of the following reasons: •A Telnet password does not exist, so could not login to the device. •Device Telnet login mode failed, so enable mode login is not attempted.
No Value To Test	Check for device credentials is not performed because you have not entered the device credentials data.
Not Supported	Check for Telnet passwords is not performed because Telnet credential checking is not supported on this device.
Failed	Check failed because a Telnet session could not be established due to a not responding device.
Not Selected For Verification	Protocol was not selected for verification.

Usage Examples for cwcli inventory cda Command

This section provides some examples of usage for the cwcli inventory cda command.

Example 1: Invoking the Check Device Attributes

cwcli inventory cda -u admin -p admin -invoke -device 3750-stack

The command output is:

CDA invoked for given device and credType list

SUMMARY

========

Successful: CDA: Success

Example 2: Checking the read and write device credentials for multiple devices

cwcli inventory cda -u admin -p admin -device 3750-stack, rtr% -credtype 1,2 -status

CDA Status :

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

deviceId | deviceName | ro | rw | snmpv3 | telnet | telnetEnable | ssh | sshEnable

25 | rtr10005 | OK | OK | | | | |

27 | 3750-stack | OK | OK | | | | |

32 | rtr10K | No Data Yet | No Data Yet | | | | |

SUMMARY

========

Successful: CDA: Success

Example 3: Checking all device credentials for a group

cwcli inventory cda -u admin -p admin -view "/RME@ciscoworksservername/Pre-deployed" -status

CDA Status:

==========

deviceId | deviceName | ro | rw | snmpv3 | telnet | telnetEnable | ssh | sshEnable

29 | v2 | No Data Yet | No Data Yet | No Data Yet | No Data Yet | No Data Yet | No Data Yet | No Data Yet

SUMMARY

========

Successful: CDA: Success

Example 4: Checking device credentials for a device using the cwcli get request

The password that you enter here must be in base64 encoded. In this example, YWRtaW4= is the base64 encoded password for admin.

Enter this in your browser:

http://ciscowork_servername:1741/rme/cwcli?command=cwcli inventory cda -u admin -p YWRtaW4= -device 10.10.10.12 -status

The output for this appears on your console:

<!-- Processing Starts -->

CDA Status :

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

deviceId | deviceName | ro | rw | snmpv3 | telnet | telnetEnable | ssh | sshEnable

12 | 10.10.10.12 | OK | OK | No Value To Test | Incorrect | Did Not Try | Failed | Did Not Try

SUMMARY

========

Successful: CDA: Success

<!-- Processing complete -->

Example 5: Checking device credentials for a device using the cwcli post request

The password that you enter here must be in base64 encoded. In this example, YWRtaW4= is the base64 encoded password for admin.

The payload file, cda.xml contains:

<payload>

<command>

cwcli inventory cda -u admin -p YWRtaW4= -device 10.10.16.20 -status

</command>

</payload>

At the command prompt enter:

perl samplepost.pl http://ciscowork_servername:1741/rme/cwcli cda.xml

To invoke the servlet using a script, see the Sample Script to Invoke the Servlet.

<!-- Processing Starts -->

CDA Status :

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

deviceId | deviceName | ro | rw | snmpv3 | telnet | telnetEnable | ssh | sshEnab

le

71 | 10.10.16.20 | No Data Yet | No Data Yet | No Data Yet | No Data Yet | No

Data Yet | No Data Yet | No Data Yet

SUMMARY

========

Successful: CDA: Success

<!-- Processing complete -->

Example 6: Creating a job using cwcli inventory cda createjob command

cwcli inventory cda createjob -u admin -p admin - Cat6230, Cat4500 | -view myview -schedule 03/23/2007:12:15:01 -scheduletype Once

This command creates a cda job for the devices Cat6230 and Cat4500 in the view myview and scheduled for 23rd march 2007 at 12:15 pm with schedule type specified as Once.

Example 7: Stopping a cwcli inventory cda job using stopjob command

There is a job 1098, which is currently running. You can use this command to stop the job 1098.

cwcli inventory cda stopjob -u admin -p admin -id 1098

Example 8: Deleting cwcli inventory cda jobs using deletejob command

There are two jobs 1057 and 1058 scheduled. You can use this command to stop the two jobs.

cwcli inventory cda deletejob -u admin -p admin -id 1057,1058

Example 9: Getting details of jobs using cwcli inventory cda jobdetails command

There are two jobs 1001 and 1002 that are scheduled. You can use this command to list the details of both the jobs:

cwcli inventory cda jobdetails -u admin -p admin -id 1001, 1002

Example 10: Listing the cda jobs based on the status using the listjobs command

cwcli inventory cda listjobs -u admin -p admin -jobstatus R, C

Use this command to list those jobs whose status is Running or Completed.

Example 11: Obtaining results of jobs using jobresults comand

There are two jobs 1023 and 1024 that are completed. You can use this command to save the results of these jobs to the specified location.

cwcli inventory cda jobresult -u admin -p admin -jobid 1023, 1024 -csvoutput C:/jobs/results

Running the cwcli inventory crmexport Command

You can use this command to export RME device credentials in CSV or XML format.

The command syntax for cwcli inventory crmexport is:

cwcli inventory crmexport -u userid -p password [-d debuglevel] [-m email] [-l logfile] {-device list | -view name | -device list -view name} [ipaddress list] {-filetype format | -filename outputfile}

Arguments in square brackets ([]) are optional; arguments in curly braces ({}) are required. You must provide one argument from each group of arguments in curly braces ({}) that is separated by vertical bars (|).

If you do not specify an optional argument, the default value configured for the system is used.

The following table describes the arguments that are specific to cwcli inventory crmexport command. The other common arguments used by cwcli export are explained in Using the cwcli inventory Command.

Argument	Description	Usage Notes
{-filetype format }	-filetype format —Enter the file format to export, either XML or CSV.	Mandatory. The default CSV file format version is 3.0.
{ -filename outputfile }	-filename outputfile—Enter the filename.	Mandatory. Specifies the name of the file to which the device credentials information is to be exported on CiscoWorks server. If you are using cwcli remotely (get or post request), by default the output file is available at this location on CiscoWorks server: On Windows: NMSROOT\MDC\tomcat Where, NMSROOT is the CiscoWorks installed directory. On Solaris: /opt/CSCOpx/objects/dmgt

Usage Examples for cwcli inventory crmexport Command

This section provides some examples of usage for the cwcli inventory crmexport command.

Example 1: Exporting device credentials of all RME devices in XML format

cwcli inventory crmexport -device % -filetype xml -filename crmexport-xml -u admin -p admin

SUMMARY

======== Successful: Export: Success

The RME device credentials are exported into a file, crmexport-xml in XML format. The credentials that are exported depends on the data that you have provided when you added the devices to Device Credentials Repository.

Example 2: Exporting device credentials of all RME devices in Normal State in CSV format

cwcli inventory crmexport -view "/RME@ciscoworksservername/Normal Devices" -filetype csv -filename crmexport-csv -u admin -p admin

SUMMARY

========

Successful: Export: Success

The RME device credentials for devices that are in Normal state are exported into a file, crmexport-csv in CSV version 3.0 format. The credentials that are exported depends on the data that you have provided when you added the devices to Device Credentials Repository.

Example 3: Exporting device credentials of all RME devices using cwcli get request method

The password that you enter here must be in base64 encoded.

In this example,

•YWRtaW4= is the base64 encoded password for admin.

•%25 is the URL encode for "%"

Enter this in your browser:

http://ciscowork_servername:1741/rme/cwcli?command=cwcli inventory crmexport -u admin -p YWRtaW4= -device %25 -filetype xml
-filename getxml

The output is written in the getxml file. The getxml file is located:

On Windows:

NMSROOT\MDC\tomcat

Where, NMSROOT is the CiscoWorks installed directory.

On Solaris:

/opt/CSCOpx/objects/dmgt

Example 4: Exporting device credentials of all RME devices using cwcli post request method

The password that you enter here must be in base64 encoded. In this example, YWRtaW4= is the base64 encoded password for admin.

The payload file, crmexport.xml contains:

<payload>

<command>

cwcli inventory crmexport -u admin -p YWRtaW4= -device 10.66.162.208 -filetype xml -filename /opt/CSCOpx/crmexport-xml

</command>

</payload>

At the command prompt enter:

perl samplepost.pl http://ciscowork_servername:1741/rme/cwcli crmexport.xml

To invoke the servlet using a script, see the Sample Script to Invoke the Servlet.

SUMMARY

========

Successful: Export: Success

The RME device credentials are exported into a file, crmexport-xml in XML format. This file is created in the /opt/CSCOpx directory. By default, the specified file is created in this location:

On Windows:

NMSROOT\MDC\tomcat

Where, NMSROOT is the CiscoWorks installed directory.

On Solaris:

/opt/CSCOpx/objects/dmgt

The credentials that are exported depends on the data that you have provided when you added the devices to Device Credentials Repository.

Running the cwcli inventory deletedevice Command

You can use this command to delete devices from RME.

The device information will be retained in the Device Credentials Repository. This information will not be removed till you delete the device from Device Credentials Repository.

The command syntax for cwcli inventory deletedevice is:

cwcli inventory deletedevice -u userid -p password [-d debuglevel]
[-m email] [-l logfile] [-view name] {-device list | -input inputfile | ipaddress list}

Arguments in square brackets ([]) are optional; arguments in curly braces ({}) are required. You must provide one argument from each group of arguments in curly braces ({}) that is separated by vertical bars (|).

If you do not specify an optional argument, the default value configured for the system is used.

The following table describes the arguments that are specific to cwcli inventory deletedevice command. The other common arguments used by cwcli export are explained in Using the cwcli export Command.

Argument	Description	Usage Notes
-input inputfile	-input inputfile—Enter the full path of the file containing comma-separated list of device display name as entered in Device Credentials Repository. The input file should be of this format: -device 1.1.1.1,2.2.2.2,3.3.3.3 or -device 1.1.1.1 -device 2.2.2.2 -device 3.3.3.3	Mandatory You must also enter the file format either CSV or txt.

Usage Examples for cwcli inventory deletedevice Command

This section provides some examples of usage for the
cwcli inventory deletedevice command.

Example 1: To delete a device

cwcli inventory deletedevice -u admin -p admin -device 10.76.10.10

<cwcli> INFO - Total number of devices deleted successfully: 1

SUMMARY

========

Successful: Delete Device: Success

Example 2: To delete devices listed in a file

The input file, deletedevice contains list of device Display Name separated by a comma:

-device 3750-stack,rtr1000,rtr10005

cwcli inventory deletedevice -u admin -p admin -input deletedevice.csv

Example 3: To delete devices using cwcli get request

The password that you enter here must be in base64 encoded. In this example, YWRtaW4= is the base64 encoded password for admin.

Enter the following in your browser:

http://ciscowork_servername:1741/rme/cwcli?command=cwcli inventory deletedevice -u admin -p YWRtaW4= -device 10.10.10.41,10.10.10.51

The output for this appears on your console:

<!-- Processing Starts -->

<cwcli> INFO - Total number of devices deleted successfully: 2

SUMMARY

========

Successful: Delete Device: Success

<!-- Processing complete -->

Example 4: To delete devices using cwcli post request

The password that you enter here must be in base64 encoded. In this example, YWRtaW4= is the base64 encoded password for admin.

The payload file, deletedevicestate.xml contains:

<payload>

<command>

cwcli inventory deletedevice -u admin -p YWRtaW4= -device 10.77.9.10,10.77.9.18,10.76.8.6

</command>

</payload>

At the command prompt enter:

perl samplepost.pl http://doclab2:1741/rme/cwcli deletedevice.xml

To invoke the servlet using a script, see the Sample Script to Invoke the Servlet.

<!-- Processing Starts -->

<cwcli> INFO - Total number of devices deleted successfully: 3

SUMMARY

========

Successful: Delete Device: Success

<!-- Processing complete -->

Running the cwcli inventory getdevicestate Command

You can use this command to view the RME device state.

The command syntax for cwcli inventory getdevicestate is:

cwcli inventory getdevicestate -u userid -p password [-d debuglevel]
[-m email] [-l logfile] [-view name] {-device list | -input inputfile | ipaddress list}

Arguments in square brackets ([]) are optional; arguments in curly braces ({}) are required. You must provide one argument from each group of arguments in curly braces ({}) that is separated by vertical bars (|).

If you do not specify an optional argument, the default value configured for the system is used.

The following table describes the arguments that are specific to cwcli inventory getdevicestate command. The other common arguments used by cwcli export are explained in Using the cwcli inventory Command.

Argument	Description	Usage Notes
-input inputfile	-input inputfile—Enter the full path of the file containing comma-separated list of devices display name as entered in Device Credentials Repository. The input file should be of this format: -device 1.1.1.1,2.2.2.2,3.3.3.3 or -device 1.1.1.1 -device 2.2.2.2 -device 3.3.3.3	Mandatory You must also enter the file format either CSV or txt.

Usage Examples for cwcli inventory getdevicestate Command

This section provides some examples of usage for the
cwcli inventory getdevicestate command.

Example 1: To view the device state of the RME devices

cwcli inventory getdevicestate -u admin -p admin -device 10.10.19.10,10.10.19.12

<cwcli> INFO - Device State Information

DisplayName:Device State

10.10.19.10:PREDEPLOYED

10.10.19.12:NORMAL

SUMMARY

========

Successful: getdevicestate: Success

Example 2: To view the devices state specified in a file

The input file, deletedevice contains list of device Display Name separated by a comma:

-device VG200,rtr1750,cat4000

cwcli inventory deletedevice -u admin -p admin -input devicestate.csv

Example 3: To view the devices state using get request

The password that you enter here must be in base64 encoded. In this example, YWRtaW4= is the base64 encoded password for admin.

Enter the following in your browser:

http://ciscowork_servername:1741/rme/cwcli?command=cwcli inventory getdevicestate -u admin -p YWRtaW4= -device 10.16.10.15,10.16.10.35

The output for this appears on your console:

<!-- Processing Starts -->

<cwcli> INFO - Device State Information

DisplayName:Device State

10.16.10.15:NORMAL

10.16.10.35:PREDEPLOYED

SUMMARY

========

Successful: getdevicestate: Success

<!-- Processing complete -->.

Example 4: To view the RME device state using post request

The password that you enter here must be in base64 encoded. In this example, YWRtaW4= is the base64 encoded password for admin.

The payload file, getdevicestate.xml contains:

<payload>

<command>

cwcli inventory getdevicestate -u admin -p YWRtaW4= -device 12.20.12.26,10.6.12.21,12.18.10.129,10.7.9.13

</command>

</payload>

At the command prompt enter:

perl samplepost.pl http://ciscowork_servername:1741/rme/cwcli getdevicestate.xml

To invoke the servlet using a script, see the Sample Script to Invoke the Servlet.

<!-- Processing Starts -->

<cwcli> INFO - Device State Information

DisplayName:Device State

12.18.13.129:ALIAS

10.7.9.13:PREDEPLOYED

10.6.12.21:NORMAL

12.20.12.26:NORMAL

SUMMARY

========

Successful: getdevicestate: Success

<!-- Processing complete -->

Sample Script to Invoke the Servlet

#!/opt/CSCOpx/bin/perl

use LWP::UserAgent;

$temp = $ARGV[0] ;

$fname = $ARGV[1] ;

open (FILE,"$fname") || die "File open Failed $!";

while ( <FILE> ) 

{        $str .= $_ ;

}

print $str ;

url_call($temp); 

#-- Activate a CGI:

sub url_call 

{    

my ($url) = @_;

my $ua = new LWP::UserAgent; 

$ua->timeout(1000);

# you can set timeout value depending on number of devices   

my $hdr = new HTTP::Headers 'Content-Type' => 'text/html'; 

my $req = new HTTP::Request ('POST', $url, $hdr);    

$req->content($str);  

my $res = $ua->request ($req); 

my $result; 

if ($res->is_error) 

{  

print "ERROR : ", $res->code, " : ", $res->message, "\n";        $result = '';

}

else {    

    $result = $res->content; 

       if($result =~ /Authorization error/)

{           print "Authorization error\n";   

          }

else {     

print $result ;     

         }    

     }

Overview: cwcli invreport Command

The cwcli invreport is a CiscoWorks command line tool which allows you to run previously created Inventory Custom Reports and also system reports. The supported output file format is Comma Separated Value (CSV).

The above command retrieves the inventory report in CSV format. The -file parameter stores the output in the file specified by filename. If you have not specified the filename, the output is stored at the following location:

NMSROOT\files\rme\jobs\inventory\reports\archives\reportname_timestamp.csv

You can:

•Use the -reportname argument to generate the report.

This can be the name of:

–An already defined custom template

or

–A system report name such as Detailed Device Report.

•Use the -input argument to specify a file containing the parameters for the report generation.

---

Note The -view argument is not allowed in the input file.

---

•Enable debug mode and set the debug level using the -d argument.

•E-mail the output to an e-mail recipient using the -m argument.

•Log the error messages to a file using the -l argument. The log and the output files are created in the current directory.

•List the existing reports with the -listreports argument.

Running the cwcli invreport Command

To use the cwcli invreport command, you must be able to run the cwcli command

You should be authorized to generate inventory reports.

The command syntax is:

cwcli invreport -u userid -p password [-d debuglevel] [-m email] [-l logfile] {-listreports | -reportname name {-view viewname | -device list | -ipaddress list} [-file filename] | -input inputfile}

Arguments in square brackets ([]) are optional; arguments in curly braces ({}) are required. You must provide one argument from each group of arguments in curly braces ({}) that is separated by vertical bars (|).

If you do not specify an optional argument, the default value configured for the system is used. Valid values for arguments are described in the following table:

Argument	Description	Usage Notes
-u user	Provide valid CiscoWorks username.	None.
-p password	Provide password for username. You can also specify the password in a file. See Setting CWCLIFILE Environment Variable for more details.	None.
[ -d debug_level ]	Set debug level.	Optional. debug_level is a number between 1 (the least information is sent to the debug output) and 5 (the most information is sent to the debug output). If you do not specify this argument, 4(INFO) is the default debug level.
[-m email]	Specify an e-mail address to send the results.	Optional. email is one or more e-mail addresses for notification. They can be separated by a space or comma.
[ -l log_filename ]	Logs the error messages and debug of messages of the invreport command, to the specified logfile name. If not specified, it will be written to default logs (invreports.log and cli.log).	Optional. log_filename can be full pathname or filename in local directory.
[ -l log_filename ]	Logs the error messages and debug of messages of the invreport command, to the specified logfile name. If not specified, it will be written to default logs (invreports.log and cli.log).	Optional. log_filename can be full pathname or filename in local directory.
{-listreports | -reportname name {-view viewname | -device list | -ipaddress list} [-file filename] | -input inputfile}	Specify any one of the required arguments: •-listreports •-reportname •-input	-listreports argument lists out all Inventory system reports and custom reports templates. You can run this command if you have the required permissions to generate reports. -reportname name specifies the name of an already defined custom template or the name of a system report (such as Detailed Device Report) for which the CSV formatted report is to be generated. -input inputfile specifies the input file containing report parameters. The parameters in this file will be used to generate the CSV formatted report(s). This file should be located in the current directory or you can specify the complete path of the input file. Note The -view argument is not allowed in the input file.
	If you selected -reportname name, then specify any one of these arguments: –-view viewname. This confines the device search to the specified view. –-device list. This specifies one or more device names as a comma-separated list. Optionally, you can also specify -file filename. Name of the file where CSV formatted report will be stored. If you do not specify the location, the default location is $NMSROOT\files\rme\jobs\inventory\reports\archives\reportname_timestamp.csv –ipaddress list—This specifies IP4 address as entered in the Device and Credential Repository. You can enter multiple IP address with comma separated. You cannot use this option with -device, -view , or -input. Also, you cannot specify wildcard characters.

Usage Examples

This section provides some examples of usage for the cwcli invreport command:

•Example 1

•Example 2

•Example 3

•Example 4

•Example 5

•Example 6

Example 1

cwcli invreport -u admin -p admin -reportname "Detailed Device Report" -device %

This generates Detailed Device Report for all devices and CSV file will be located at $NMSROOT\files\rme\jobs\inventory\reports\archives\Detailed Device Report_timestamp.csv

Example 2

cwcli invreport -u admin -p admin -reportname "Detailed Device Report" -device % -file D:\cisco\CSCOpx\a.csv

This generates Detailed Device Report, a system report, for all devices, and the result will be written to D:\cisco\CSCOpx\a.csv

Example 3

cwcli invreport -u admin -p admin -reportname "Detailed Device Report" -device % -file a.csv

This generates the Detailed Device Report, a system report, for all devices, and the result will be written to the file a.csv in the current directory (from where you are running this command).

Example 4

cwcli invreport -u admin -p admin -input cliinputs.txt

Generate the reports using the parameters provided in the file cliinputs.txt. Using -input argument you can run multiple reports at a time by providing parameters in the file.

Example 5

cwcli invreport -u admin -p admin -listreports

Displays a list of all Inventory system report and custom templates.

You can run this command if you have the required permissions to generate reports.

Example 6

cwcli invcreport -u admin -p admin -d 3 -m xxx@yyy.com -reportname acmeinventory -view acme -file acmeinventory.txt

Generates the report named acmeinventory, using the acme device view and the CSV formatted output will be written to acmeinventory.txt

You can place this file in the current directory (from where you are running the command).

Example 7

cwcli invreport -u admin -p admin -reportname HardwareStatisticsReport -device devname -file hwstreport.txt

Generates the Hardware Statistics Report for the device devname and the CSV formatted output will be written to hwstreport.txt

Example 8

cwcli invreport -u admin -p admin -reportname DeviceStatisticsReport -device devname -file devstreport.txt

Generates the Device Statistics Report for the device devname and the CSV formatted output will be written to devstreport.txt

Example 9

cwcli invreport -u admin -p admin -reportname POEReport -device devname -file report.txt

Generates the POE Report for the device devname and the CSV formatted output will be written to report.txt

cwcli invreport Remote Access

You can also perform the cwcli invreport tasks using the servlet. You will have to upload a payload XML file, which contains the cwcli invreport command arguments and CiscoWorks user credentials.

You have to write your own script to invoke the servlet with a payload of this XML file and the servlet returns the output either on the console or in the specified output file, if the credentials are correct and arguments are valid.

The name of the servlet is /rme/cwcli.

The following is the servlet to be invoked to execute any command:

For post request,

perl samplepost.pl http://rme-server:rme-port/rme/cwcli payload_XML_file

The default port for CiscoWorks server in HTTP mode is 1741.

If you have enabled SSL on CiscoWorks server, you can also use https protocol for secured connection.

perl samplepost.pl https://rme-server:rme-port/rme/cwcli payload_XML_file

The default port for CiscoWorks server in HTTPS mode is 443.

The schema for creating the payload file in XML format is:

<payload>

<command>

cwcli inventory commandname -u user -p BAse64 encoded pwd -args1 arg1value...

</command>

</payload>

To invoke the servlet using a script, see the Sample Script to Invoke the Servlet.

The script and the payload file should be residing in the client machine.

For get request,

http://rme-server:rme-port/rme/cwcli?command=cwcli invreport commandname -u user -p BAse64 encoded pwd -args1 arg1value...

The default port for CiscoWorks server in HTTP mode is 1741.

If you have enabled SSL on CiscoWorks server, you can also use https protocol for secured connection.

https://rme-server:rme-port/rme/cwcli?command=cwcli invreport commandname -u user -p BAse64 encoded pwd -args1 arg1value...

The default port for CiscoWorks server in HTTPS mode is 443.

The BAse64 encoded for "admin" is YWRtaW4=.

The URL encode for,

•Double quotes (") is %22

•Percentage sign (%) is %25

Overview: cwcli netshow Command

You can invoke NetShow features from Command Line Interface (CLI).

The cwcli netshow commands let you use NetShow features from the command line. You can use the cwcli netshow commands to view, browse, create, delete, and cancel NetShow jobs.

You can also view the Command Sets assigned to each user by entering the command listcmdsets from CLI.

You can set the following job attributes using the command line option:

•E-mail Notification

•Job Based Password

•Execution Policy

•Approver List

However, the Administrator must define and assign the command sets to you, in the browser interface.

If you do not have permission to run custom commands, you can run a command or command set from the CLI only if:

•The command set is assigned to you by the Administrator.

•The command set has at least one command that can be run on the specified device.

If you have permission to run custom commands, you can run any of the following adhoc commands:

•show

•version

•where

•ping

•traceroute

•?

Administrator level users have all command sets assigned to them. However, only system-defined command sets are assigned to all users, by default. Other commands have to be assigned to the user by the Administrator. If any users create a command, it is automatically assigned to them.

Running cwcli netshow Command

The command syntax for running cwcli netshow commands is:

cwcli netshow common_arguments subcommands command_arguments

In the CLI version, you can provide the arguments in the (operating system shell) command line or in an input file. The input file provides you with flexibility and control over commands and command sets. You can specify the devices on which you want to run the command sets.

In the input file, you can include subcommands and command arguments.

For example, you can create a new netshow job with command sets, set1 and set2, and the custom commands, custom command 1 and custom command 2, by entering:

cwcli netshow createjob -u Username -p Password -commandset "Command Set 1"," Command Set 2" -device Device 1, Device 2 -customcmd "Custom command 1"," Custom command 2" -schedule Schedule -scheduletype Schedule Type

Items in square brackets ([]) are optional; items in curly brackets ({}) are required.

The arguments are described in the following sections.

Subcommands

Subcommands specify the actions that you perform. Valid values for subcommands are described in the following table.

Sub command	Description	Usage Notes	Example
createjob	Creates a new job that can be scheduled to run immediately or to be run sometime in the future. You can also specify the job attributes you want to enable.	Either use an input file containing the details of the subcommands or enter the full command syntax.	cwcli netshow createjob -u Username -p Password -commandset "Command Set 1"," Command Set 2" -device "Device Name 1", "Device Name 2" -customcmd "Custom Command 1", "Custom Command 2" -schedule Schedule -scheduletype Schedule Type Or cwcli netshow createjob -u Username -p Password -input Input File
canceljob	Cancels an existing job.	Enter the job ID.	cwcli netshow canceljob -u Username -p Password -id "Job ID"
deletejob	Deletes existing jobs.	Enter the job IDs separated by commas.	cwcli netshow deletejob -u Username -p Password -id "Job ID 1"," Job ID 2"
jobdetails	Displays details of specified job.	Enter the job IDs separated by commas.	cwcli netshow jobdetails -u Username -p Password -id "Job ID 1","Job ID 2", "Job ID 3"
listjobs	Displays a list of jobs created by the user and the job status.	Specify the type of jobs to be listed. The command type is case sensitive. The commands that you can use are: A —All jobs R —Running jobs C —Completed jobs P —Pending jobs You can use combinations of status options. Separate the options by commas.	cwcli netshow listjobs -u Username -p Password -status R,C
listcmdsets	Displays a list of command sets assigned to the user.	None.	cwcli netshow listcmdsets -u Username -p Password
jobresults	Displays results of specified jobs	Specify the job IDs. Separate the job IDs by commas.	cwcli netshow jobresults -u Username -p Password -id "Job ID 1" , "Job ID 2" , "Job ID 3"
help	Displays command usage information.	None.	cwcli netshow -help

Common Arguments

Common arguments specify parameters that apply to all subcommands. Valid values for common_arguments are described in the following table.

Common Arguments	Description/Action	Usage Notes
-u user	Enter a valid CiscoWorks username.	None
-p password	Enter the password for the username. You can also specify the password in a file. See Setting CWCLIFILE Environment Variable for more details.	None
[-d debug_level]	Set the debug level.	Optional debug_level should be a number between 1-5. 1 —The least information is sent to the debug output 5 —The most information is sent to the debug output.
[-l log_filename]	Identifies a file to which Network Show Commands will write log messages. If you do not specify this, the log output will appear on screen.	Optional log_filename can be a full path to the file or a filename in the local directory.
[-m Email ID]	Enter your Email ID	You will get the output of the CLI operation in an Email.

Command Arguments

Command arguments specify parameters that apply only to specific subcommands. Valid values for command arguments are described in the following table.

Arguments in square brackets ([]) are optional. Arguments in curly brackets ({}) are required. You must provide one argument from each group of arguments in curly brackets ({}) that is separated by vertical bars (|).

Command Arguments	Description	Usage Notes
Command Arguments for createjob
{-device devicelist | -view view_name}	Defines devices on which you want the command set to run.	device_list —List of device names. Separate these names by commas. view_name — Name of a device view.
{-commandset commandset}	Defines available command sets that you want to run on the selected devices.	commandset is the name of the command set that was assigned to you. You can specify more than one command set separated by commas. The command set name is case sensitive. You must specify command set or custom command or both to create a job.
{-customcmd customcommand}	Defines the user-defined commands that you want to run on the selected devices.	customcommand is a user-defined show command. You must specify command set or custom command or both to create a job. The custom commands which can be run on NetShow are: •show •version •where •ping •traceroute •? You can use the short forms of these commands. For example, sh for show.
[-description description]	Gives details of the job.	description is a user-defined entry describing the job details.
[{-schedule MM/dd/yyyy:HH:mm:ss -scheduletype Once | Daily | Weekly | Monthly | LastDayOfMonth | 6hourly | 12hourly}]	You can specify the date and time as well as the frequency of the NetShow job. •To specify the date and time when you want to run the NetShow job, use the schedule option. •To specify the frequency of the job use the scheduletype option. You have to set both the schedule and schedule type options for a scheduled job. You do not have to set the schedule and schedule type for an Immediate job.	scheduletype can have any of the following values: •Once •6hourly •12hourly •Daily •Weekly •Monthly •LastDayOfMonth If the schedule option is not specified, the job will be created as an immediate job.
[-makercomments comments]	Job creator's comments to Job approver.
[-mkemail email]	Maker e-mail ID for sending approval notifications
[-notificationmail email]	Defines the e-mail addresses of persons who need to get mails when the job has started and completed.	email can contain a comma separated email list. If you do not specify this option in the CLI, the e-mail address specified in the UI are used.
[-execution Sequential|Parallel]	Execution policy. Specifies the order in which you want to run the job on the devices. Parallel—Allows the job to run on multiple devices at the same time. By default, the job runs on five devices at a time. Sequential—Allows the job to run on only one device at a time.	If you do not specify these options in the CLI, the corresponding settings from the UI are used.
{-primary_user username -primary_pass password}	Primary username and password to connect to devices.
{-enable_pass password}	Execution mode password to connect to device.
[-input input file]	Input file containing the details of the subcommands	If you are specifying the input file, you do not need to specify the subcommands.
Command Argument for listjob
{-status status}	You can specify the status of the job. This can be: •All jobs •Running jobs •Completed jobs •Pending jobs.
Command Argument for canceljob
{-id Job ID}	You can cancel only one job at a time.
Command Argument for deletejob and jobdetails
{-id Job ID, Job ID}	You can delete more than one job at a time. Enter the Job IDs that you want to delete, separated by commas. You can list the details of more than one job at a time. Enter the Job IDs separated by commas.
Command Arguments for jobresults
{-id Job ID, Job ID}	You can list the results of more than one job at a time. Enter the job IDs separated by commas.
[-output file path]	You can specify the fully qualified pathname for saving the job results.	If you do not specify this argument, the job results appear in the console itself. If the specified path does not exist, the job results are stored in the default location.

Executing Netshow CLI Remotely

You can execute NetShow CLI from a remote console.

NetShow uses the Remote Access feature in the CLI framework to help you to invoke the NetShow commands from the client in the same way as you run them on the RME server.

The name of the servlet, to be invoked, is /rme/cwcli.

You must invoke the following URLs to run any command.

•For POST request:

http://rme-server:rme-port/rme/cwcli payload XML file

•For GET request:

http://rme-server:rme-port/rme/cwcli?command=cwcli netshow command -u Username -p Password command_specific_args

The contents of the payload.xml is:

<payload>

<command>

cwcli netshow command -u Username -p Password command_specific_args

</command>

</payload>

For example to execute the listcmdsets command payload.xml will be as follows:

<payload>

<command>

cwcli netshow listcmdsets -u Username -p Password

</command>

</payload>

To invoke the servlet using a script, see the Sample Script to Invoke the Servlet.

The script and the payload file should be residing in the client machine.

Performance Tuning Tool

Performance Tuning Tool (PTT) is a Command Line Interface (CLI) utility that enables you to apply and list various profiles available in CiscoWorks server. Profiles consists of configuration files, which are in the form of XML files whose values are based on the recommendations for various RME applications. For more information on PTT features, refer to PTT Features.

There are two profiles shipped with CiscoWorks. You can use any of the profile that matches the system. For more information on PTT Profiles, see Profiles and PTT.

There maybe multiple configuration files that are involved while applying a profile. The parameters such as, snmp.threads.min, snmp.threads.max, ICSThreadCount, ICS DBConnectionCount, ThreadPoolCount, CDLNumOfThreads, max_db_connections, max_threads_for_config_fetch, EssentialsDMServicesHeapsize,ConfigJobManager.heapsize, and CDA_MIN_THREADS are tuned and available in each profile. You can apply the required profile to the system and improve performance. This is a major advantage of using PTT.

To know more about the command usage, see PTT Commands.

---

Note Currently, profiles are applicable to RME application only.

---

PTT Features

The PTT CLI utility allows you to:

•List the profile that is currently applied to the target machine.

•List the profiles that match the system configuration.

•List the profiles that match the operating system.

•Apply a selected profile onto the target machine.

•Reverse the changes done to a target machine by applying the default profile to restore the default settings.

•View details of a profile.

Profiles and PTT

Profiles are XML files whose values are based on the recommendations of the various RME applications. Each profile (XML file) consists of tuned parameters which when applied, improves performance.

There are two profiles that are shipped with LMS 3.0. They are:

•Default Profile

•Perftune - Windows and Perftune - Solaris

---

Note All the configuration files are backed up before applying a profile.

---

PTT identifies the matching profile for a CiscoWorks server based on the following criteria:

•The operating system for which the profile is created.

•The System Configurations such as Dual CPU and 4 GB RAM.

A profile is considered matching only if it meets these criteria.

When you apply a profile, the tuned parameters, see Table 20-3 corresponding to that profile is applied to the system.

These parameters belong to Sync Archive, Netconfig, Syslog, Device Management, Check Device Attributes (CDA) and Inventory Collection sub systems of the RME application. The profile, with tuned parameters when applied, improves the performance. Before running PTT, ensure that the Daemon manager is stopped.

Default Profile

A default profile is a profile with default values. It is used to rollback the changes done by PTT. You can roll back the changes made to a profile, by applying the default profile. This action rolls back the parameters to their original values. The parameters and the original values are:

Table 20-3 Default Profile Original Values

RME Sub system	Parameters	Original Values	Platform Supported
CDA	CDA_MIN_THREADS	7	Windows and Solaris
EssentialsDM	ConfigJobManager.heapsize	192m	Windows and Solaris
EssentialsDM	EssentialsDMServiceHeapsize	256	Windows and Solaris
Inventory Collection	snmp.threads.min	10	Windows and Solaris
Inventory Collection	snmp.threads.max	15	Windows and Solaris
Inventory Collection	ICS ThreadCount	10	Windows and Solaris
Inventory Collection	ICS DBConnectionCount	5	Windows and Solaris
NetConfig and SyncArchive	max_threads_for_config_fetch	5	Windows and Solaris
NetConfig and SyncArchive	ThreadPoolCount	10	Windows and Solaris
NetConfig and SyncArchive	CDLNumOfThreads	5	Windows and Solaris
NetConfig and SyncArchive	max_db_connections	20	Windows and Solaris
Config Management (Config Management Server Daemons - dmgtd.conf Arguments for max heap size.)	Xmx	192	Solaris
Config Management (Config Management Server Daemons - dmgtd.conf Arguments for minimum heap size.)	Xms	64	Solaris

Perftune - Windows and Perftune - Solaris

This profile consists of parameters that are tuned to improve performance.

•Perftune - Windows profile is applied to a system that has a Windows operating system, provided the profile matches the required criteria.

•Perftune - Solaris profile is applied to a system that has a Solaris operating system, provided the profile matches the required criteria.

See Profiles and PTT for more informationon criteria for a profile to match a system.

The parameters that can be tuned are:

Table 20-4 Perftune - Windows and Perftune - Solaris Parameters

RME Sub system	Parameters	Original Values	New Value	Platform Supported
CDA	CDA_MIN_THREADS	7	14	Windows and Solaris
EssentialsDM	ConfigJobManager.heapsize	192m	256	Windows and Solaris
EssentialsDM	EssentialsDMServiceHeapsize	256	512	Windows and Solaris
Inventory Collection	snmp.threads.min	10	20	Windows and Solaris
Inventory Collection	snmp.threads.max	15	25	Windows and Solaris
Inventory Collection	ICS ThreadCount	10	20	Windows and Solaris
Inventory Collection	ICS DBConnectionCount	5	10	Windows and Solaris
NetConfig and SyncArchive	max_threads_for_config_fetch	5	10	Windows and Solaris
NetConfig and SyncArchive	ThreadPoolCount	10	20	Windows and Solaris
NetConfig and SyncArchive	CDLNumOfThreads	5	10	Windows and Solaris
NetConfig and SyncArchive	max_db_connections	20	40	Windows and Solaris
Config Management (Config Management Server Daemons - dmgtd.conf Arguments for max heap size.)	Xmx	192	256	Solaris
Config Management (Config Management Server Daemons - dmgtd.conf Arguments for minimum heap size.)	Xms	64	128	Solaris

Example 1

If the Perftune - Windows profile is applied to a system which already has a default profile applied, the parameters are changed from the original values to new values. See Table 20-4 for Original and New values.

Example 2

If the default profile is applied to a system which already has a Perftune - Windows profile applied to it, the parameters are rolled back to original values. See Table 20-3 for Original values..

PTT Commands

Table 20-5 lists the various PTT command options that you can use. These command options are common for Windows and Solaris.

Table 20-5 PTT Command Options

PTT command options	Description
-apply <profileName>	Applies a particular profile. To reset, specify the default profile name as parameter and apply that profile.
-apply	Finds the matching profile and applies it automatically in a single step.
-apply Default	Finds the default profile and applies it automatically in a single step.
-show	Displays the currently applied profile.
-list	Lists all the profiles that match the target operating system.
-list Match	Lists the profile that matches the system configuration.
-view <profileName>	Displays the profile details. The details of the profile, which is specified in the command is displayed.
rmeptt -help	Displays help for all commands.

Command Usage

In Windows enter:

rmeptt.bat <option> <argument>

For example, to list all the profiles that matches the target operating system, the command is:

rmeptt.bat -list

In Solaris, enter:

rmeptt.sh <option> <argument>

For example to display the profile details, the command is:

rmeptt.sh -view x

Where x is the name of the profile

.syslogConf.pl Utility

The syslogConf.pl is a perl script CLI utility. You can use this utility to:

•Change Syslog Analyzer Port.

•Change Syslog Collector Port.

•Configure Remote Syslog Collector(RSAC) Address and Port in RME server.

•Change Syslog File Location.

You can run this script in the RME server as well as the RSAC server. All the activities mentioned above can be performed in a RME server by running the syslogConf.pl script from the command prompt.

In RSAC server, you can only change the Syslog Collector Port and Syslog File location. The Syslog Collector and Syslog Analyzer ports can be any number between 1025 and 5000.

This utility is available under:

NMSROOT/bin/

A log file for the syslogconf.pl script is available at:

In Solaris

/var/adm/CSCOpx/log/SyslogConf.log

In Windows

NMSROOT\log\SyslogConf.log

---

Note Before you run the syslogConf.pl script, ensure that the Daemon Manager is stopped.

---

Running the syslogConf.pl Script

To run the script:

---

Step 1 Go to the command prompt and enter:

NMSROOT/bin/perl NMSROOT/syslogConf.pl

When you run this syslogConf.pl script, a message appears with five options.

[1] Change Syslog Analyzer Port

[2] Change Syslog Collector Port

[3] Configure Remote Syslog Collector(RSAC) Address and Port

[4] Change Syslog File Location

[Q] Quit

Enter Your Choice:

Step 2 Enter your choice.

•If you enter 1 the following message is displayed with the old Syslog Analyser Port number. You are also prompted to enter the new port number for the Syslog Analyser.

INFO: You have opted to change Local Syslog Analyser port.

Old Syslog Analyser Port :xxxx

Enter new Syslog Analyser port:

For example, you can change the Syslog Analyser Port from 4444 to 2222.

After providing the new port information, the following message is displayed.

INFO:Local Syslog Analyser port has been changed from 4444 to 2222 successfully

•If you enter 2 the following message is displayed with the old Syslog Collector Port number. You are also prompted to enter the new port number for the Syslog Collector.

INFO: You have opted to change Local Syslog Collector port.

Old Syslog Collector Port :xxxx

Enter new Syslog Collector port:

For example you can change the Syslog Collector Port from 1111 to 3333.

After providing the new port information, the following message is displayed.

INFO:Local Syslog Collector port has been changed from 1111 to 3333 successfully

•If you enter 3, the following message is displayed, with the old Syslog Collector Port number. You are also prompted to provide the new RSAC Address and the new port number for the Syslog Collector.

INFO: You have opted to change RSAC port.

Enter the RSAC Address:

Old Syslog Collector Port :0

Enter new Syslog Collector port:

Ensure that the RSAC port that you configure in the RME server corresponds with the Collector port configured in the RSAC server.

You can specify srme-w2k as the RSAC Address, and change the Syslog Collector port from 0 to 3456.

After providing the RSAC Address and port information, the following message is displayed.

INFO: Remote Syslog Collector(RSAC) port has been changed from 0 to 3456.

•If you enter 4, the following message is displayed with the old Syslog Directory Path. You are also prompted to enter the new Syslog Directory path.

INFO: You have opted to change Syslog File Location

Old Syslog Directory : /var/log/

Enter Full Path of New Syslog Directory:

Ensure that you enter the full directory path, if you are running the syslogConf.pl script on Solaris. You can provide the relative directory path if you are running the syslogConf.pl script on Windows.

For example you can change the Syslog Directory location from /var/log/ to /var/log/newSyslogLoc.

After providing the required information, the following message is displayed.

Syslog file location changed from: /var/log/ to: /var/log/newSyslogLoc

•If you enter Q, you are allowed to quit from the script.

Software Management CLI Utility

You can invoke Software Management (SWIM) features from Command Line Interface (CLI).

The cwcli swim commands let you use SWIM features from the command line. You can use the cwcli swim commands to:

•List Images from Software Management (SWIM) Repository

•Export Images from Software Management (SWIM) Repository

These functions are only accessible to the Network Administrator, Network Operator and super users who have all of the roles.

If you do not have permission to run custom commands, you can run a command or command set from the CLI only if:

•The command set is assigned to you by the Administrator.

•The command set has at least one command that can be run on the specified device.

Running cwcli swim Command

The command syntax for running cwcli swim commands is:

cwcli swim subcommands common_arguments command_arguments

In the CLI version, you can provide the arguments in the (operating system shell) command line or in aninput file.

The input file gives you flexibility and control over commands and command sets. You can specify the images on which you want to run the command sets.

In the input file, you can include subcommands and command arguments.

Items in square brackets ([]) are optional; items in curly brackets ({}) are required.

The arguments are described in the following sections.

Subcommands

Subcommands specify the actions that you perform. Valid values for subcommands are described in the following table.

Sub command	Description	Example
listimages	Displays a list of images available in the Software Repository.	cwcli swim listimages -u Userid -p Password
exportimages	Exports specified images in a non-compressed format from the Software Repository to any directory. The default target directory is the current directory. For exportimages command either one of these arguments is mandatory: -imagenames|-all|-input	cwcli swim exportimages -u Username -p Password [-imagenames imagename1, imagename2...] [-all] [-dirname directoryname] [-input argumentFile] [-m email][-l logfile]
help	Displays command usage information.	cwcli swim -help

Common Arguments

Common arguments specify parameters that apply to all subcommands. Valid values forcommon_arguments are described in the following table.

Common Arguments	Description/Action	Usage Notes
-u user	Enter a valid CiscoWorks username.	None
-p password	Enter the password for the username. You can also specify the password in a file. See Setting CWCLIFILE Environment Variable for more details.	None
[-l log_filename]	Identifies a file to which Software Management Commands will write log messages. If you do not specify this, the log output will appear on screen.	This argument is optional. log_filename can be a full path to the file or a filename in the local directory.
[-m Email ID]	Enter your Email ID	This argument is optional. You will get the output of the CLI operation in an e-mail.

Command Arguments

Command arguments specify parameters that apply only to specific subcommands. Valid values for command arguments are described in the following table.

Arguments in square brackets ([]) are optional. Arguments in curly brackets ({}) are required. You must provide one argument from each group of arguments in curly brackets ({}) that is separated by vertical bars (|).

Command Arguments	Description	Usage Notes
Command Arguments for exportimages
{-imagenames ImageName1, ImageName2}	Specify the image names that you want to export using this command.	cwcli swim exportimages -u Username -p Password [-imagenames imagename1, imagename2...] [-all] [-dirname directoryname] [-input argumentFile] [-m email][-l logfile] ImageName1, ImageName2 —List of images. Separate these names by commas.
{-all}	Specify this option if you want to export all images from Software Repository to the current directory or any specified directory.	--
{-input argumentFile}	Input file containing the details of the subcommands	If you are specifying the input file, you need not specify the subcommands. For instance, if you are using sample.txt as the argumentFile for -input command, you have to provide the following command: cwcli swim exportimages -input sample.txt Example of sample.txt: -imagenames {imagename1}, [imagename2...] -imagenames {imagename4}, [imagename5...] Items in square brackets ([]) are optional; items in curly brackets ({}) are required.
[-dirname directoryname]	Specify a directory name if you want to export images to a specified directory using this command.	If you do not specify this the images are exported to the NMSROOT/temp directory, where CLI is launched.

Running SWIM CLI Remotely

You can run Software Management (SWIM) CLI from a remote console.

SWIM uses the Remote Access feature in the CLI framework to help you to invoke the SWIM commands from the client in the same way as you run them on the RME server.

The name of the servlet to be invoked is /rme/cwcli.

You must invoke the following URLs to run any command.

•For POST request:

http://rme-server:rme-port/rme/cwcli payload XML file

•For GET request:

http://rme-server:rme-port/rme/cwcli?command=cwcli swim command -u Username -p Password command_specific_args

The contents of the payload.xml is:

<payload>

<command>

cwcli swim command -u Username -p Password command_specific_args

</command>

</payload>

For example to execute the listimages command payload.xml will be as follows:

<payload>

<command>

cwcli swim listimages -u Username -p Password

</command>

</payload>

---

Note The Base64 encoded password is used for accessing Software Management (SWIM) CLI remotely.

---

To invoke the servlet using a script, see the Sample Script to Invoke the Servlet.

The script and the payload file should be residing in the client machine.