Huong Dan Su Dung Cisco Work

User Guide for CiscoWorks
Common Services 3.0

CiscoWorks
Corporate Headquarters
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
USA
http://www.cisco.com
Tel: 408 526-4000
800 553-NETS (6387)
Fax: 408 526-4100
Customer Order Number: DOC-7816571

Text Part Number: 78-16571-01
THE SPECIFICATIONS AND INFORMATION REGARDING THE PRODUCTS IN THIS MANUAL ARE SUBJECT TO CHANGE WITHOUT
NOTICE. ALL STATEMENTS, INFORMATION, AND RECOMMENDATIONS IN THIS MANUAL ARE BELIEVED TO BE ACCURATE BUT
ARE PRESENTED WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED. USERS MUST TAKE FULL RESPONSIBILITY FOR
THEIR APPLICATION OF ANY PRODUCTS.
THE SOFTWARE LICENSE AND LIMITED WARRANTY FOR THE ACCOMPANYING PRODUCT ARE SET FORTH IN THE INFORMATION
PACKET THAT SHIPPED WITH THE PRODUCT AND ARE INCORPORATED HEREIN BY THIS REFERENCE. IF YOU ARE UNABLE TO
LOCATE THE SOFTWARE LICENSE OR LIMITED WARRANTY, CONTACT YOUR CISCO REPRESENTATIVE FOR A COPY.
The Cisco implementation of TCP header compression is an adaptation of a program developed by the University of California, Berkeley (UCB) as
part of UCB’s public domain version of the UNIX operating system. All rights reserved. Copyright © 1981, Regents of the University of California.
NOTWITHSTANDING ANY OTHER WARRANTY HEREIN, ALL DOCUMENT FILES AND SOFTWARE OF THESE SUPPLIERS ARE
PROVIDED “AS IS” WITH ALL FAULTS. CISCO AND THE ABOVE-NAMED SUPPLIERS DISCLAIM ALL WARRANTIES, EXPRESSED
OR IMPLIED, INCLUDING, WITHOUT LIMITATION, THOSE OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT OR ARISING FROM A COURSE OF DEALING, USAGE, OR TRADE PRACTICE.
IN NO EVENT SHALL CISCO OR ITS SUPPLIERS BE LIABLE FOR ANY INDIRECT, SPECIAL, CONSEQUENTIAL, OR INCIDENTAL
DAMAGES, INCLUDING, WITHOUT LIMITATION, LOST PROFITS OR LOSS OR DAMAGE TO DATA ARISING OUT OF THE USE OR
INABILITY TO USE THIS MANUAL, EVEN IF CISCO OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH
DAMAGES.
CCSP, the Cisco Square Bridge logo, Follow Me Browsing, and StackWise are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live,
Play, and Learn, and iQuick Study are service marks of Cisco Systems, Inc.; and Access Registrar, Aironet, ASIST, BPX, Catalyst, CCDA, CCDP, CCIE,
CCIP, CCNA, CCNP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco
Systems logo, Cisco Unity, Empowering the Internet Generation, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, FormShare,
GigaDrive, GigaStack, HomeLink, Internet Quotient, IOS, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, LightStream, Linksys,
MeetingPlace, MGX, the Networkers logo, Networking Academy, Network Registrar, Packet, PIX, Post-Routing, Pre-Routing, ProConnect, RateMUX,
ScriptShare, SlideCast, SMARTnet, StrataView Plus, SwitchProbe, TeleRouter, The Fastest Way to Increase Your Internet Quotient, TransPath, and VCO
are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a
partnership relationship between Cisco and any other company. (0411R)
User Guide for CiscoWorks Common Services

Copyright © 1998-2005 Cisco Systems, Inc. All rights reserved.
C ON T E NT S
Preface xiii
Audience xiii
Conventions xiii
Product Documentation xiv
Related Documentation xvi
Additional Information Online xvi
Obtaining Documentation xvi
Cisco.com xvii
Ordering Documentation xvii
Documentation Feedback xviii
Obtaining Technical Assistance xviii
Cisco Technical Support Website xviii
Submitting a Service Request xix
Definitions of Service Request Severity xx
Obtaining Additional Publications and Information xx
CHAPTER 1 Overview 1-1

New Features 1-2
Understanding Time Zone Settings 1-3
Learning More About the Common Services 1-3

78-16571-01 iii
Contents
CHAPTER 2 Interacting With CiscoWorks Homepage 2-1

Invoking CiscoWorks Homepage 2-2
Invoking CWHP in Normal Mode (HTTP) 2-2
Invoking CWHP in SSL Enabled Mode (HTTPS) 2-3
Logging Into CiscoWorks 2-4
Using CWHP 2-5
Common Services Panel 2-5
Application Panels 2-6
Supporting Applications on Another Server 2-6
Supporting Traditional Applications With New Navigation 2-7
Device Troubleshooting Panel 2-7
Resources Panel 2-7
CiscoWorks Product Updates Panel 2-7
Tool Bar Items 2-8
Configuring CWHP 2-8
Registering Applications With CWHP 2-8
Registering a New Application 2-9
Importing from other servers 2-10
Unregistering an Application 2-11
Registering Links With CWHP 2-11
Unregistering a Link 2-12
Setting Up CiscoWorks Homepage 2-12
Using Online Help 2-13
Changing Web Server Port Numbers 2-14
CHAPTER 3 Configuring the Server 3-1

Setting up Security 3-1
Managing Security in Single Server Mode 3-1

iv 78-16571-01
Contents
Setting up Browser-Server Security 3-2

Enabling Browser-Server Security From the CiscoWorks Server 3-2
Enabling Browser-Server Security From the Command Line Interface
(CLI) 3-4
About User Accounts 3-4
Understanding Security Levels 3-5
Setting up Local Users 3-6
Modifying Your Profile 3-6
Adding a User 3-7
Editing User Profiles 3-8
Deleting a User 3-8
Creating Self Signed Certificate 3-9
Managing Security in Multi-Server Mode 3-10
Setting up Peer Server Account 3-11
Setting up System Identity Account 3-13
Setting up Peer Server Certificate 3-14
Deleting Peer Certificates 3-15
Enabling Single Sign-On 3-15
Navigating Through the SSO Domain 3-16
Registering Server Links 3-17
Launching a new Browser Instance 3-17
Changing the Single Sign-On Mode 3-18
Setting up the AAA Mode 3-20
About Common Services Authentication 3-21
Cisco Secure ACS Support for Common Services Client Applications 3-22
Setting the Login Module to Non-ACS 3-24
Changing Login Module to CiscoWorks Local 3-25
Changing Login Module to IBM SecureWay Directory 3-25
Changing Login Module to KerberosLogin 3-27

78-16571-01 v
Contents
Changing Login Module to Local Unix System 3-28

Changing Login Module to Local NT System 3-29
Changing Login Module to MS Active Directory 3-29
Changing Login Module to Netscape Directory 3-30
Changing Login Module to Radius 3-32
Changing Login Module to TACACS+ 3-33
Understanding Fallback Options for Non-ACS mode 3-35
Setting the Login Module to ACS 3-35
Assigning Privileges in ACS 3-38
Creating and Modifying Roles in ACS 3-39
Resetting Login Module 3-42
Understanding Fallback Options for ACS Mode 3-43
Managing Cisco.com Connection 3-44
Setting up Cisco.com User Account 3-44
Setting Up the Proxy Server 3-44
Generating Reports 3-45
Log File Status Report 3-45
Permissions Report 3-46
Users Logged In Report 3-47
Process Status Report 3-48
Viewing Audit Log Report 3-49
Administering Common Services 3-51
Using Daemon Manager 3-52
Restarting Daemon Manager on Solaris 3-52
Restarting Daemon Manager on Windows 3-53
Managing Processes 3-53
Viewing Process Details 3-54
Starting a Process 3-54
Stopping a Process 3-55

vi 78-16571-01
Contents
Backing Up Data 3-55

Backing up Using CLI 3-57
Data Backed up During CS 3.0 Backup 3-57
Restoring Data 3-58
Restoring Data on UNIX 3-59
Restoring Data on Windows 3-60
Data Restored from Common Services 3.0 Backup Archive 3-61
Data Restored from Common Services 2.2 Backup Archive 3-62
Data Restored from CD One 5th Edition Backup Archive 3-62
Effects of Backup-Restore on DCR 3-63
Master -Slave Configuration Prerequisites and Restore Operations 3-66
Effects of Backup-Restore on Groups 3-67
Licensing CiscoWorks Applications 3-68
Obtaining a License for CiscoWorks Applications 3-68
Licensing the Application 3-69
Viewing License Information 3-70
Updating Licenses 3-70
Collecting Server Information 3-71
Collecting Self Test Information 3-72
Messaging Online Users 3-72
Managing Jobs 3-73
Managing Resources 3-76
Maintaining Log Files 3-78
Maintaining Log Files on UNIX 3-78
Maintaining Log Files on Windows 3-80
Using Logrot 3-81
Configuring Logrot 3-81
Running Logrot 3-82
Modifying System Preferences 3-83

78-16571-01 vii
Contents
CHAPTER 4 Managing Device and Credentials 4-1

DCR Architecture 4-5
Master DCR 4-6
Slave DCR 4-6
Standalone DCR 4-6
Using the Device and Credential Admin 4-7
Managing Devices 4-7
Adding Devices 4-8
Standard Type 4-9
Auto Update Type 4-10
Cluster Managed Type 4-11
Deleting Devices 4-12
Editing Device Credentials 4-13
Importing Devices and Credentials 4-14
Import Using DCA Interface 4-15
Exporting Devices and Credentials 4-18
Export Using DCA Interface 4-19
Excluding Devices 4-21
A Sample CSV Exclude File 4-21
Viewing Devices List 4-22
Generating Reports in DCA 4-23
Managing Auto Update Servers 4-24
Adding Auto Update Server 4-24
Editing Auto Update Server 4-25
Deleting Auto Update Server 4-25

viii 78-16571-01
Contents
Administering Device and Credential Repository 4-26

Changing DCR Mode 4-26
Master-Slave Configuration Prerequisites 4-27
Changing the Mode to Standalone 4-27
Changing the Mode to Master 4-28
Changing the Mode to Slave 4-28
Adding User-defined Fields 4-29
Renaming User-defined Fields 4-30
Deleting User-defined Fields 4-31
Sample CSV File 4-31
A Sample CSV 2.0 File 4-31
A Sample CSV 3.0 File 4-32
Sample CSV 3.0 File for Auto Update Server Managed Devices 4-33
Sample CSV 3.0 File for Cluster Managed Devices 4-34
Mapping CSV 2.0 to CSV 3.0 Fields 4-35
Sample XML File 4-36
Sample XML File (Standard) 4-36
Sample XML File for Auto Update Server Managed Devices 4-37
Sample XML File for Cluster Managed Devices 4-38
Using DCR Features Through CLI 4-39
Adding Devices Using dcrcli 4-39
Deleting Devices Using dcrcli 4-39
Editing Devices Using dcrcli 4-40
Listing the Attributes 4-40
Viewing the Current DCR Mode Using dcrcli 4-41
Viewing Device Details 4-41
Changing DCR Mode Using dcrcli 4-42
Import Using CLI 4-43
Export Using CLI 4-44

78-16571-01 ix
Contents
Implications of ACS Login Module on DCR 4-45

Custom Roles and DCR 4-45
CHAPTER 5 Administering Groups 5-1

Group Concept 5-2
Group Hierarchy 5-2
Dynamic Group 5-3
Static Group 5-3
Container Groups 5-3
System-defined and User-defined Groups 5-3
Common Groups and Shared Groups 5-4
Secure Views 5-6
Groups in a Single-Server Setup 5-7
Groups in Multi-Server Setup 5-7
DCR Mode Changes and Group behavior 5-10
Unregistering a Slave 5-13
Group Administration 5-14
Creating Groups 5-14
Specifying Group Properties 5-15
Defining Group Rules 5-17
Assigning Group Membership 5-18
Removing Devices 5-19
Viewing Group Details 5-19
Modifying Group Details 5-20
Refreshing Groups 5-22
Deleting Groups 5-22
System Defined and User Defined Attributes 5-23

x 78-16571-01
Contents
CHAPTER 6 Using Device Center 6-1

Launching Device Center 6-2
Invoking Device Center 6-3
Using Device Center Functions 6-3
Device Selector 6-4
Device Summary 6-4
Management Functions 6-5
Enabling Debugging Tools 6-5
Checking Device Connectivity 6-6
Using Ping 6-8
Using Traceroute 6-9
Using SNMP Walk 6-9
Using SNMP Set 6-11
Using Packet Capture 6-12
Creating a New Packet Capture File 6-13
Editing Device Credentials 6-15
Displaying Reports 6-15
Performing Management Tasks 6-15
CHAPTER 7 Working With Software Center 7-1

Performing Software Updates 7-2
Performing Device Update 7-4
Deleting Packages 7-6
Scheduling Device Package Downloads 7-7
Viewing Activity Logs 7-9

78-16571-01 xi
Contents
CHAPTER 8 Diagnosing Problems With CiscoWorks Server 8-1

Verifying Server Status 8-1
Testing Device Connectivity 8-4
Troubleshooting the CiscoWorks Server 8-6
Frequently Asked Questions 8-6
Troubleshooting Suggestions 8-33
APPENDIX A Understanding CiscoWorks Security A-1

General Security A-2
Server Security A-2
Server–Imposed Security A-2
Files, File Ownership, and Permissions A-3
Runtime A-4
Remote Connectivity A-5
Access to Systems Other Than the CiscoWorks Server A-6
Access Control A-6
System Administrator-Imposed Security A-7
Connection Security A-7
Security Certificates A-7
Terms and Definitions A-8
INDEX

xii 78-16571-01
Preface
This document describes CiscoWorks Common Services 3.0 and gives an

overview of the features and functions provided by CiscoWorks Common
Services.
Audience
This manual is for network administrators who need to configure and maintain
CiscoWorks Common Services. Most of the tools and applications described are
available only to systems administrators.
Conventions
This document uses the following conventions:
Item Convention
Commands and keywords boldface font
Variables for which you supply values italic font
Displayed session and system information screen font
Information you enter boldface screen font
Variables you enter italic screen font

Menu items and button names boldface font

78-16571-01 xiii
Preface
Product Documentation
Item Convention
Selecting a menu item in paragraphs Option > Network Preferences
Selecting a menu item in tables Option > Network Preferences
Note Means reader take note. Notes contain helpful suggestions or references to
material not covered in the publication.
Caution Means reader be careful. In this situation, you might do something that could
result in equipment damage or loss of data.
Note We sometimes update the printed and electronic documentation after original
publication. Therefore, you should also review the documentation on Cisco.com
for any updates.
Table 1 describes the product documentation that is available.

xiv 78-16571-01
Preface
Table 1 Product Documentation
Document Title Available Formats

Release Notes for CiscoWorks • Printed document that was included with the product.
Common Services 3.0
• On Cisco.com at:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/c
w2000/cw2000_d/comser30/relnotes/index.htm
Installation Guide for CiscoWorks • PDF on the product CD-ROM.
Common Services 3.0 on Windows • On Cisco.com at:
http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/
cw2000/cw2000_d/comser30/ig_win/index.htm
• Printed document available by order (part number
DOC-7816497=).1
Installation Guide for CiscoWorks • PDF on the product CD-ROM.
Common Services 3.0 on Solaris • On Cisco.com at:
cw2000/cw2000_d/comser30/ig_sol/index.htm
DOC-7815885=).1
User Guide for CiscoWorks • PDF on the product CD-ROM.
Common Services 3.0 (this
document)
cw2000/cw2000_d/comser30/usrguide/index.htm
DOC-7816571=).1
Context-sensitive online help • Select an option from the navigation tree, then click Help.
• Click the Help button in the dialog box
1. See the “Obtaining Documentation” section on page xvi

78-16571-01 xv
Preface
Related Documentation
Related Documentation
Note We sometimes update the printed and electronic documentation after original
publication. Therefore, you should also review the documentation on Cisco.com
for any updates.
Table 2 describes the additional documentation that is available.
Table 2 Related Documentation
Document Title Available Formats

Quick Start Guide for LAN • Printed document that was included with the product.
Management Solution 3.0
• PDF on the product CD-ROM.
Additional Information Online

To determine which packages are installed on your CiscoWorks Server, select
Common Services > Software Center > Applications and Versions.
You can also obtain any published patches from the download site.
Obtaining Documentation
Cisco documentation and additional literature are available on Cisco.com. Cisco
also provides several ways to obtain technical assistance and other technical
resources. These sections explain how to obtain technical information from Cisco
Systems.

xvi 78-16571-01
Preface
Obtaining Documentation
Cisco.com
You can access the most current Cisco documentation at this URL:
http://www.cisco.com/univercd/home/home.htm
You can access the Cisco website at this URL:
http://www.cisco.com
You can access international Cisco websites at this URL:
http://www.cisco.com/public/countries_languages.shtml
Ordering Documentation
You can find instructions for ordering documentation at this URL:
http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm
You can order Cisco documentation in these ways:
• Registered Cisco.com users (Cisco direct customers) can order Cisco product
documentation from the Ordering tool:
http://www.cisco.com/en/US/partner/ordering/index.shtml
• Nonregistered Cisco.com users can order documentation through a local
account representative by calling Cisco Systems Corporate Headquarters
(California, USA) at 408 526-7208 or, elsewhere in North America, by
calling 1 800 553-NETS (6387).

78-16571-01 xvii
Preface
Documentation Feedback
Documentation Feedback
You can send comments about technical documentation to bug-doc@cisco.com.
You can submit comments by using the response card (if present) behind the front
cover of your document or by writing to the following address:
Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883
We appreciate your comments.
Obtaining Technical Assistance

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

The Cisco Technical Support Website provides online documents and tools for
troubleshooting and resolving technical issues with Cisco products and
technologies. The website is available 24 hours a day, 365 days a year, at this
URL:
http://www.cisco.com/techsupport
Access to all tools on the Cisco Technical Support Website requires a Cisco.com
user ID and password. If you have a valid service contract but do not have a user
ID or password, you can register at this URL:
http://tools.cisco.com/RPF/register/register.do

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

Using the online TAC Service Request Tool is the fastest way to open S3 and S4
service requests. (S3 and S4 service requests are those in which your network is
minimally impaired or for which you require product information.) After you
describe your situation, the TAC Service Request Tool provides recommended
solutions. If your issue is not resolved using the recommended resources, your
service request is assigned to a Cisco TAC engineer. The TAC Service Request
Tool is located at this URL:
http://www.cisco.com/techsupport/servicerequest
For S1 or S2 service requests or if you do not have Internet access, contact the
Cisco TAC by telephone. (S1 or S2 service requests are those in which your
production network is down or severely degraded.) Cisco TAC engineers are
assigned immediately to S1 and S2 service requests to help keep your business
operations running smoothly.
To open a service request by telephone, use one of the following numbers:
Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)
EMEA: +32 2 704 55 55
USA: 1 800 553-2447
For a complete list of Cisco TAC contacts, go to this URL:
http://www.cisco.com/techsupport/contacts

78-16571-01 xix
Preface
Obtaining Additional Publications and Information
Definitions of Service Request Severity

To ensure that all service requests are reported in a standard format, Cisco has
established severity definitions.
Severity 1 (S1)—Your network is “down,” or there is a critical impact to your
business operations. You and Cisco will commit all necessary resources around
the clock to resolve the situation.
Severity 2 (S2)—Operation of an existing network is severely degraded, or
significant aspects of your business operation are negatively affected by
inadequate performance of Cisco products. You and Cisco will commit full-time
resources during normal business hours to resolve the situation.
Severity 3 (S3)—Operational performance of your network is impaired, but most
business operations remain functional. You and Cisco will commit resources
during normal business hours to restore service to satisfactory levels.
Severity 4 (S4)—You require information or assistance with Cisco product
capabilities, installation, or configuration. There is little or no effect on your
business operations.

Information about Cisco products, technologies, and network solutions is
available from various online and printed sources.
• Cisco Marketplace provides a variety of Cisco books, reference guides, and
logo merchandise. Visit Cisco Marketplace, the company store, at this URL:
http://www.cisco.com/go/marketplace/
• The Cisco Product Catalog describes the networking products offered by
Cisco Systems, as well as ordering and customer support services. Access the
Cisco Product Catalog at this URL:
http://cisco.com/univercd/cc/td/doc/pcat/
• Cisco Press publishes a wide range of general networking, training and
certification titles. Both new and experienced users will benefit from these
publications. For current Cisco Press titles and other information, go to Cisco
Press at this URL:
http://www.ciscopress.com

xx 78-16571-01
Preface
• Packet magazine is the Cisco Systems technical user magazine for

maximizing Internet and networking investments. Each quarter, Packet
delivers coverage of the latest industry trends, technology breakthroughs, and
Cisco products and solutions, as well as network deployment and
troubleshooting tips, configuration examples, customer case studies,
certification and training information, and links to scores of in-depth online
resources. You can access Packet magazine at this URL:
http://www.cisco.com/packet
• iQ Magazine is the quarterly publication from Cisco Systems designed to
help growing companies learn how they can use technology to increase
revenue, streamline their business, and expand services. The publication
identifies the challenges facing these companies and the technologies to help
solve them, using real-world case studies and business strategies to help
readers make sound technology investment decisions. You can access iQ
Magazine at this URL:
http://www.cisco.com/go/iqmagazine
• Internet Protocol Journal is a quarterly journal published by Cisco Systems
for engineering professionals involved in designing, developing, and
operating public and private internets and intranets. You can access the
Internet Protocol Journal at this URL:
http://www.cisco.com/ipj
• World-class networking training is available from Cisco. You can view
current offerings at this URL:
http://www.cisco.com/en/US/learning/index.html

78-16571-01 xxi
Preface

xxii 78-16571-01
C H A P T E R 1
Overview
CiscoWorks Common Services (Common Services) represents a common set of

management services that are shared by CiscoWorks applications. CiscoWorks is
a family of products based on Internet standards for managing networks and
devices. All CiscoWorks products use and depend on Common Services.
Common Services provides a foundation for CiscoWorks applications to share a
common model for data storage, login, user role definitions, access privileges,
security protocols, as well as navigation.
It creates a standard user experience for all management functions. It also
provides the common framework for all basic system level operations such as
installation, data management including backup-restore and import-export, event
and message handling, and job and process management.
Common Services 3.0 provides a set of new features required to drive the
CiscoWorks applications towards a common look and feel. The new CiscoWorks
Homepage replaces the existing desktop.
Common Services 3.0 enables sharing of critical information among the various
products, and provides a new framework for delivering timely support of new
devices. In addition, it supports new platforms, and provides enhanced security
mechanisms.

78-16571-01 1-1
Chapter 1 Overview
New Features
New Features
The major new features in this release:
• CiscoWorks Homepage
Provides launch points for CiscoWorks family of products and other
resources. The HTML based CiscoWorks Homepage replaces the Java applet
based Desktop.
• Device and Credential Repository (DCR)
Provides a central place for management of devices and their credentials that
the different applications managing those devices can use. Sharing of devices
and credentials help in common administration.
• Device Center
Provides a one-stop place where you can see a summary for a device, and
launch troubleshooting tools, management tasks, and reports for the selected
device.
• Groups
Provides a mechanism for applications to create shared device groups.
Provides grouping facility based on various attributes in Device and
Credential Repository (DCR).
• Software Center
Allows you to download and deploy device packages and software patches.
• Enhanced security to support SNMPv3 authNoPriv
Provides packet level security, integrity protection, and replay protection.
However, it does not encrypt the packets.
• Enhanced restore framework.
Enables Common Services and its applications to restore the data backed up
from an earlier version.
• Security mechanisms for managing security in Single-Server and
Multi-Server scenarios. Granular role based access.
• New utilities for diagnosing problems with CiscoWorks Server, and
managing log files.
• New licensing framework.

1-2 78-16571-01
Chapter 1 Overview
Understanding Time Zone Settings
• Support for IPv6.

• HTML based Online help.
Understanding Time Zone Settings

Common Services and associated CiscoWorks application suites support many
time zones. However, applications that have scheduling and reporting functions,
and applications that produce or use time stamps vary based on:
• Server and client—Time stamps can differ between server and client if they
are located in different time zones.
• Platforms—Windows and UNIX servers support different time zones and are
not synchronized.
For detailed information, see the Release Notes included with your CiscoWorks
applications.
Learning More About the Common Services

You can find detailed information on the features and functions of CiscoWorks
Common Services in the following sections:
• Interacting With CiscoWorks Homepage
• Setting up Security
• Generating Reports
• Administering Common Services
• Managing Device and Credentials
• Administering Groups
• Using Device Center
• Working With Software Center
In addition, the Online help included with Common Services provides
explanations and procedures for the related tasks.
You can launch the Online help from the CiscoWorks Homepage by clicking the
Help button on top of the right hand side of the CiscoWorks Homepage.

78-16571-01 1-3
Chapter 1 Overview
Learning More About the Common Services
For tips about accessing Online help, see Using Online Help.
You can check the version details and licensing information about Common
Services by clicking the About button on top of the right hand side of the
CiscoWorks Homepage.

1-4 78-16571-01
C H A P T E R 2
Interacting With CiscoWorks
Homepage
CiscoWorks Homepage (CWHP) provides launch points for all Common Services
features. It also provides launch points for applications installed on the same
server or a remote server, and their major functions.
CWHP also provides launch points for other web-based products
(Non-CiscoWorks products and third party/home-grown tools) residing on the
same or a different server.
After you install the applications, you can see the application panels on CWHP.
CWHP supports application oriented and device oriented navigation paradigms.
When you select any of the application functions on CWHP, it launches the
application homepage, and the selected function is launched in application
homepage content area.
CWHP is completely based on HTML, and provides intuitive navigation for you
to move back-and-forth between CiscoWorks Homepage, and all other application
homepages.
CWHP has the look and feel of a portal. By default, CWHP provides launch
points for:
• Server
• HomePage
• Device and Credentials
• Groups

78-16571-01 2-1
Chapter 2 Interacting With CiscoWorks Homepage
Invoking CiscoWorks Homepage
• Software Center
• Device Center
The following sections explain the CWHP features, in detail:
• Invoking CiscoWorks Homepage
• Logging Into CiscoWorks
• Using CWHP
• Configuring CWHP
• Using Online Help
• Changing Web Server Port Numbers

You may invoke CWHP in the normal mode (HTTP), or secure mode (HTTPS).
Invoking CWHP in Normal Mode (HTTP)

To invoke CWHP in the normal mode (HTTP), enter the URL for your
CiscoWorks Server in your web browser:
http://server_name:port_number
where server name is the name of the CiscoWorks Server and port number is the
TCP port used by the CiscoWorks Server, in the normal mode.
If you enter, http://server_name:port_number/login.html in your browser, the
CiscoWorks Server will not launch. Also, do not bookmark the URL with the
login.html.
In normal mode (HTTP), the default TCP port for CiscoWorks Server is 1741.
• On Windows, the CiscoWorks Server always uses the default port numbers in
secure and normal modes.
• On Solaris, if the default TCP ports (1741 and 443) are used by other
applications, you can select different ports for secure and normal modes
during CiscoWorks Server installation.

2-2 78-16571-01
For more information, see the “Logging Into CiscoWorks” section on page 2-4.
See also, Installation and Setup Guide for CiscoWorks Common Services on
Solaris.
Invoking CWHP in SSL Enabled Mode (HTTPS)

To invoke CWHP in the SSL enabled mode (HTTPS):
Step 1 Enter the URL for your CiscoWorks Server in your browser.
http://server_name:port_number
where server name is the name of the CiscoWorks Server and port number is the
TCP port used by the CiscoWorks Server, when SSL is enabled (secure mode).
If you enter, http://server_name:port_number /login.html in your web
browser, the CiscoWorks Server will not launch. Also, do not bookmark the URL
with the login.html.
When SSL is enabled (HTTPS), the default TCP port for CiscoWorks Server is
443.
• On Windows, CiscoWorks Server always uses the default port numbers in
secure and normal modes.
• On Solaris, if the default TCP ports (1741 and 443) are used by other
applications, you can select different ports for secure and normal modes
during CiscoWorks Server installation. For more information, see Installation
and Setup Guide for CiscoWorks Common Services on Solaris.
If you use Microsoft Internet Explorer to invoke CWHP, the browser displays a
Security Alert window, indicating that you are about to view web pages over a
secure connection.
a. Click OK in the Security Alert window.
The Security Alert window displays the security certificate alert.
b. Click Yes in the Security Alert window.
If you use Netscape Navigator to invoke CWHP, the browser displays the New
Site Certificate wizard.

78-16571-01 2-3
Logging Into CiscoWorks
In the New Site Certificate wizard you can accept the certificate for the current
session or accept it till the certificate expires. To avoid going through the New Site
Certificate wizard every time you invoke CWHP, you may accept the certificate
till it expires.
If Common Services is running in a Plug-in environment, it displays Plug-in alert
dialogs. (For example, Server Certificate details, Hostname Mismatch details).
Step 2 Click Yes in the Plug-in alert dialogs to get to the Login panel.
If the server is in SSL mode and if you invoke Common Services as
http: //server_name:1741, you will be redirected to https: //server_name:443
Logging Into CiscoWorks

If you have installed CiscoWorks Server and logging in for the first time, use the
reserved admin user name and password.
To log in:
Step 1 Enter admin in the User ID field, and the password for admin in the Password
field of the Login Page.
The CiscoWorks Server administrator can set the passwords to admin and guest
users during installation. Contact the CiscoWorks Server administrator if you do
not know the password.
Step 2 Click Login or press Enter.
You are now logged into CiscoWorks Server.
Step 3 You can change the admin password at Common Services > Server >
Security > User Management
For more information, see Online Help.
Login sessions time out after two hours of inactivity. If the session is not used for
two hours, you will be prompted to login again.
Session timeout is not automatic. If you try to do any task after timeout, a message
appears informing you that your session has timed out.

2-4 78-16571-01
Using CWHP
The Login screen replaces the current page of the current browser window. After
you log in, the page you were on before re-logging in, appears.
Using CWHP
CiscoWorks Homepage is the primary user interface and the launch point for all
features. After you log in to CiscoWorks, the default CiscoWorks Homepage
appears.
The CWHP window consists of:
• Common Services Panel
• Application Panels
• Device Troubleshooting Panel
• Resources Panel
• CiscoWorks Product Updates Panel
• Tool Bar Items
Common Services 3.0 and CiscoWorks applications use popup dialog boxes at
many places.
If you have a popup-blocker enabled in your browser, none of these popups would
appear. Therefore, you have to disable the popup-blocker, if you have installed
any.
Common Services Panel

The Common Services Panel displays all Common Services functions. The
Common Services panel appears in a tree window.
First level items displayed in the Tree window are:
• Server
• HomePage
• Software Center
• Device and Credentials
• Groups

78-16571-01 2-5
Using CWHP
Application Panels
Each Application Panel in the CWHP serves as a top-level launch point for all
Common Services applications installed on the local/remote server.
Applications appear in the CWHP in three columns.
By default, only the first level items are displayed when you login. These first
level items are in collapsed mode. Lower level navigations are displayed only if
you manually expand a first level item.
The title of each application panel displays the application name and it serves as
a link to the relevant application homepage.
Application tasks are displayed in a hierarchical manner. When you select a task
from the hierarchy, it launches the application homepage in a new window.
If the corresponding application homepage already exists for some other task, the
window for this task is focussed, instead of creating a new window.
To launch the URL associated with the item in the popup window, click on the
label.
Supporting Applications on Another Server

CiscoWorks applications from other servers can be made to display in the same
way as CiscoWorks applications from the local server.
For this, you should import registration details of CiscoWorks applications
installed on other servers. This allows you to navigate various CiscoWorks
applications from same or different bundles (such as LMS, RWAN, VMS), from
a single homepage.
You should authenticate yourself before using applications from other server
(once for each server, for each session), even if you are authenticated on the local
server.
Common Services will not do the license check. Applications need to authenticate
and do the license check.
For details on transparently navigating through multiple CiscoWorks Servers, see
“Enabling Single Sign-On” section on page 3-15.

2-6 78-16571-01
Using CWHP
Supporting Traditional Applications With New Navigation

CWHP also displays the applications that are based on the traditional CiscoWorks
Common Services desktop.
CWHP provides a Product Home Page, which looks similar to the traditional
CiscoWorks Common Services desktop. Traditional applications are registered
during installation to display their links on CWHP.
Device Troubleshooting Panel

The Device Troubleshooting panel provides a launch point to the Device Center.
See Chapter 6, “Using Device Center” for details.
Resources Panel
Resources panel is on the top of the right hand side of the CWHP. It also serves
as a top-level launch point for CiscoWorks resources, Cisco.com resources, third
party application links, and web based custom tool links. This panel shows the
types of resources as first level and details in the next level.
Note CWHP provides an Admin UI to turn off this information if you are behind the
firewall or if you do not want this information to be displayed in CWHP.
CiscoWorks Product Updates Panel

CiscoWorks Product Updates panel is on the right hand side of the page. It
displays informative messages about CiscoWorks product announcements, and
help related topics.
If you click the More Updates link, a popup window appears with all the Cisco
Product Update details.

78-16571-01 2-7
Configuring CWHP
In case the CiscoWorks Server is behind a firewall, the proxy settings are used to
download messages from Cisco.com. CWHP provides an Admin UI to accept the
proxy settings. CWHP alerts you if any urgent messages are found.
By default, the polling interval is one minute. You can change this polling
interval.
Tool Bar Items

Three buttons are available on top of the right hand side of the CWHP:
• Logout—Returns the browser to the Login dialog box.
• Help—Displays the Online help in a separate browser window. See Using
Online Help for details.
• About—Displays the general information about the software. The window
displays license information, version and patch level, installation date and
copyright information.
Configuring CWHP
The Application Registration, Link Registration, and Settings links under
Homepage help you configure your CiscoWorks Homepage. They help you in:
• Registering Applications With CWHP
• Registering Links With CWHP
• Setting Up CiscoWorks Homepage
Registering Applications With CWHP

Using this feature you can register CiscoWorks applications on local or remote
servers. You need to enter application instance attributes (host, port, and
protocol).
Other information such as AppName, URLs available are already defined by the
application in a template.

2-8 78-16571-01
Configuring CWHP
During registration you are prompted to select an application template and then
register with CiscoWorks Server. The registration enables the application to be
integrated with other applications based on the template definition. It also helps
application launch points to be displayed on CWHP.
To register applications:
Step 1 Select Common Services > HomePage > Application Registrations.

The Application Registration Status page appears.
Step 2 View the list of registered applications in the Registered Applications dialog box.
Registering a New Application

To register a new application:
Step 1 Click Registration in the Registered Applications dialog box.

The Choose Location for Registration page appears. A wizard guides you through
the process.
Step 2 Choose the location for registration.
You can choose to Register from Templates or Import from Other servers.
To register from Templates:
Step 1 Select the Register from Templates radio button and click Next.
The Registration Through Template page appears. A list of templates appears in
the Select a Template to Register dialog box.
Step 2 Select the radio button corresponding to the Template you require and click Next.
The Server Attributes page appears.

78-16571-01 2-9
Configuring CWHP
Step 3 Enter the Server attributes in the Server attributes dialog box and click Next.
The Registration Summary page displays the Application Registration summary
window. It displays a summary the information you entered.
Step 4 Click Finish.
Importing from other servers

You must perform the following tasks before importing application registrations
from other servers. This is to ensure a secure environment for importing
registrations.
• Create self signed certificates for the local and remote servers (if not already
done).
• Add remote server's certificate to the local server. See Setting up Peer Server
Certificate for details.
• Restart the local server.
• Create a Peer Server user on the remote server. Configure this user a System
Identity user in the local server. See Setting up Peer Server Account and
Setting up System Identity Account for details.
To import from other servers:
Step 1 Select the Import from Servers radio button and click Next.
The Import Registrations page appears.
Step 2 Enter the Server Name, Server Display Name, and the secure Port Number in the
Import Server’s Attributes dialog box.
Step 3 Click Next.
The Import Registrations Summary window displays a summary of the
information you entered.
Step 4 Click Finish.

2-10 78-16571-01
Configuring CWHP
Unregistering an Application
To unregister an application:
Step 1 Select Common Services > HomePage > Application Registrations.

The Application Registration Status page appears. You can view the list of
registered applications in the Registered Applications dialog box.
Step 2 Select the radio button corresponding to the Application you want to unregister,
and click Unregister.
The Applications to be Unregistered window appears with the details of the
Application unregistered.
Step 3 Click Confirm.
Registering Links With CWHP

You can add additional links to CiscoWorks Homepage for Custom tools and
home grown tools, and third party applications such as HPOV. The links appear
under the Third Party or Custom Tools, as you specify.
To register links with CiscoWorks Homepage:
Step 1 Select Common Services > HomePage > Links Registration.

The Links Registration Status page appears.
Step 2 Click Registration.
The Enter Link Attributes dialog box appears.
Step 3 Enter the Link Name and the URL.
Select the radio button corresponding to Third Party or Custom Tools to set the
display location.
Step 4 Click OK.

78-16571-01 2-11
Configuring CWHP
Unregistering a Link
To unregister a link:
Step 1 Select Common Services > HomePage > Links Registration.

The Links Registration Status page appears.
Step 2 Select the check box corresponding to the link you need to unregister.
Step 3 Click Unregister.
Setting Up CiscoWorks Homepage

You can configure or change the CiscoWorks Homepage settings.
To modify CiscoWorks Homepage settings:
Step 1 Select Common Services > HomePage > Settings.

The Homepage Settings page displays the Homepage Settings dialog box.
Step 2 Enter a name for the CiscoWorks Server in the Change Homepage Server Name
field.
You can use this name in the Provider Group name in the Common Services
Groups UI. See “System-defined and User-defined Groups” section on page 5-3
for details on Provider Group.
Step 3 Select the Hide External Resources check box to hide the Resources and
CiscoWorks Product Updates panels in the Homepage.
Step 4 Enter the display name you want for Third Party tools in the Custom Name for
Third Party field.
Step 5 Enter the display name you want for Custom tools/homegrown tools in the
Custom Name for Custom Tools field.

2-12 78-16571-01
Using Online Help
Step 6 Select a value from the Urgent Messages Polling Interval drop-down list to set the
polling interval for messages.
The time you set here decides the polling interval for disk watcher messages and
messages you want to broadcast using the Notify Users features.
To disable this feature, select DISABLE from the drop-down list.
Disk watcher is a utility that monitors the file system. If the file system size goes
above 90 percent, it displays an alert to logged in CiscoWorks users. You can use
this to monitor critical file systems.
To know more about the Notify Users feature, see “Messaging Online Users”
section on page 3-72.
Step 7 Click Update.
You can update any one of the above settings by clicking update.
If you have changed the Homepage Server Name, a popup window appears
prompting you to confirm whether you want to use this name in Provider Group
name.
• Click OK if you want the name to be suffixed to the Provider Group name.
• You need to restart Daemon Manager for the Provider Group name change to
take effect. See “Using Daemon Manager” section on page 3-52 for details on
restarting Daemon Manager.
Using Online Help

Each CiscoWorks application includes online help that provides procedural and
conceptual information to assist you in using CiscoWorks.
Online help also contains:
• A search engine—Allows you to search the topics in Help, based on
keywords.
• An index—Contains typical network tasks.
• A glossary.

78-16571-01 2-13
Changing Web Server Port Numbers
To access Online help, click the Help button on the top-right corner. This opens a
window that displays help contents. From this window, you can access help for all
the CiscoWorks applications installed.

To change the web server port numbers, you must execute separate commands for
both Windows and Solaris.
On Solaris:
You can change the web server port numbers (for HTTP and HTTPS) for
CiscoWorks webservers.
To change the port numbers you must login as CiscoWorks Server administrator,
and run the following command at the prompt:
/opt/CSCOpx/MDC/Apache/bin/changeport
If you run this command without any command line parameter, CiscoWorks
displays:
*** CiscoWorks Webserver port change utility ***
Usage: changeport <port number> [-s] [-f]
where
port number—The new port number that should be used
-s—Changes the SSL port instead of the default HTTP port
-f—Forces port change even if Daemon Manager detection FAILS.
Note Do not use this option by default. Use it only when CiscoWorks
instructs you to use.
For example, you can enter:

changeport 1744—Changes the CiscoWorks web server HTTP port to use 1744.
Or
changeport port number -s—Changes the CiscoWorks web server HTTPS port
to use the specified port number.

2-14 78-16571-01
If you change the port after installation, CiscoWorks will not launch from Start
menu (Start > Programs > Ciscoworks > Ciscoworks). You have to manually
invoke the browser, and specify the URL, with the changed port number.
The restrictions that apply to the specified port number are:
• Port numbers less than 1025 are not allowed except 80 (HTTP) and
443 (HTTPS). Also port 80 is not allowed for SSL port, and port 443 is not
allowed for HTTP port.
• The specified port should not be used by any other service or daemon. The
utility checks for active listening ports, and ports listed in /etc/services. If
there is any conflict, it rejects the specified port.
• The port number must be a numeric value in the range 1026 – 65000. Values
outside this range, and non-numeric values are not allowed.
• If port 80 or 443 is specified for any of the webservers, that webserver process
is started as root. This is because ports lower than 1026 are allowed to be used
only by root in Solaris.
However, according to Apache behavior, only the main webserver process run
as root, and all the child processes run as casuser:casusers. Only the child
processes serve the external requests.
The main process which runs as root, monitors the child processes. It does not
accept any HTTP requests. Owing to this, Apache ensures that a root process
is not exposed to the external world, and thus ensures security.
• If you do not want CiscoWorks processes to run as root, do not use the ports
80 and 443.
When you execute the utility with the appropriate options, it displays
messages on the tasks it performs.
This utility lists out all the files that are being updated. Before updating, the
utility will back up all the affected files in /opt/CSCOpx/conf/backup and
creates appropriate unique sub-directories.
It also creates a new file called index.txt. This text file contains information
about the changed port, a list of all the files that are backed up, and their
actual location in the CiscoWorks directory.

78-16571-01 2-15
A sample backup may be similar to:

/opt
|
`--/CSCOpx
|
`--/conf
|
`--/backup
|
|--README.txt (Note the purpose of this directory as it
is initially empty)
|
`--/AAAtpaG03_Ciscobak (Autogenerated unique backup
directory).
|
|--index.txt (The backup file list)
|--httpd.conf (Webserver config file)
|--md.properties (CiscoWorks config elements)
|--mdc_web.xml (Common Services application
config file)
|--regdaemon.key (Common Services config
registry key file)
|--regdaemon.xml (Common Services config
registry data file)
|--rootapps.conf (CiscoWorks daemons using
privileged ports)
|--services (The system /etc/services file)
|--ssl.properties (CiscoWorks config elements
for SSL mode)
`--vms_web.xml (Common Services application
config file)
Note All the above files and the unique directories are stored with read only permission
to casuser:casusers. To ensure the security of the backup files, only the
CiscoWorks Server administrator has write permissions.
The change port utility displays messages to the console, as it runs. These
messages contain information about the directory where the backup files are being
stored. These messages are also logged to a file, changeport.log
This file is saved to the directory:
/var/adm/CSCOpx/log/changeport.log
This file contains the date and time stamps to indicate when the log entries were
created.

2-16 78-16571-01
On Windows:
You can change the web server port numbers (for HTTP and HTTPS) for the
CiscoWorks Webserver.
To change the port numbers you must have administrative privileges. Run the
following command at the prompt:
CSCOpx\MDC\Apache\changeport.exe
If you run this utility without any command line parameter, CiscoWorks displays
the following usage text:
*** Common Services Webserver port change utility ***
where:
-s—Change the SSL port instead of the default HTTP port
-f—Force port change even if Daemon Manager detection fails.
instructs you to use.

changeport 1744 —Changes the Common Services web server HTTP port to use
1744.
Or
changeport port number -s—Changes the Common Services web server HTTPS
port to use the specified port number.

78-16571-01 2-17

443 (HTTPS). Also port 80 is not allowed for HTTPS port and port 443 is not
utility checks for active listening ports, and if any conflict is found the utility
rejects the specified port.
There is no reliable way to determine whether any other service or application
is using a specified port. If the service or application is running and actively
listening on a port, it can be easily detected.
However, if the service is currently stopped, there is no way that the utility
can determine what port it uses. This is because on Windows there is no
common port registry equivalent to /etc/services as in UNIX.
outside this range, and non-numeric values are not allowed.
When you run the utility with the appropriate options, it displays messages on the
actions it is performing.
It lists out all the files that are being updated. Before updating, the utility backs
up all the affected files in CSCOpx\conf\backup, and creates, appropriate, unique,
sub-directories.
It also creates a new file called index.txt. This text file contains information
about the changed port, a list of all the files that are backed up, and their actual
location in the CiscoWorks directory.

2-18 78-16571-01

[drive:]
|
`--\Program Files
|
`--\CSCOpx
|
`--\conf
|
`--\backup
|
|--README.txt (Notes the purpose of this dir as
it is initially empty)
|
`--\skc03._Ciscobak (Autogenerated unique
backup directory).
|
|--md.properties (CiscoWorks config
elements)
|--mdc_web.xml (Common Services
application config file)
|--regdaemon.key (Common Services config
registry key file)
|--regdaemon.xml (Common Services config
registry data file)
|--ssl.properties (CiscoWorks config
elements for SSL mode)
`--vms_web.xml (Common Services
application config file)
Note All the above files and the unique directories are stored with read only
permissions. Only the administrator and casuser have write permissions, to ensure
the security of the backup files.
The change port utility displays messages on the console, as it runs. These
stored. These messages are also logged to a file, changeport.log.
NMSROOT\log\changeport.log
This log file contains the date and time stamps to indicate when the log entries
were created.

78-16571-01 2-19

2-20 78-16571-01
C H A P T E R 3
Configuring the Server
Common Services includes administrative tools to configure the server, manage

security, and data. You can set up security mechanisms, manage processes, jobs,
resources, and generate reports that provide troubleshooting information about
the status of the server.
Setting up Security
Common Services provides security mechanisms that help to prevent
unauthenticated access to the CiscoWorks Server, CiscoWorks applications, and
data. Common Services provides features for managing security when operating
in single-server and multi-server modes.
You can specify the user authentication mode using the AAA Mode Setup. You
can create user accounts on Cisco.com using the Cisco.com Connection
Management UI.
Managing Security in Single Server Mode

You can set up browser-server security, add and modify users, and create self
signed certificate using the features that come under Single-Server Management
link in the Security Settings UI.

78-16571-01 3-1
Chapter 3 Configuring the Server
Setting up Browser-Server Security
For details, see:

• Setting up Browser-Server Security
• Setting up Local Users
• Creating Self Signed Certificate

Common Services provides secure access between the client browser and
management server, and also between the management server and devices. It does
this using SSL (Secure Socket Layer).
SSL encrypts the transmission channel between the client, and server.
Common Services provides secure access between the client browser, and
management server, and also between the management server, and devices.
SSL is an application-level protocol that enables secure transactions of data
through privacy, authentication, and data integrity. It relies upon certificates,
public keys, and private keys.
You can enable or disable SSL, depending on the need to use secure access
between the client browser and the management server.
CiscoWorks Server uses certificates for authenticating secure access between the
client browser and the management server.
• Enabling Browser-Server Security From the CiscoWorks Server
• Enabling Browser-Server Security From the Command Line Interface (CLI)
Enabling Browser-Server Security From the CiscoWorks Server

To enable Browser-Server Security:
Step 1 In the CiscoWorks Homepage, select Common Services > Server > Security >
Browser-Server Security Mode Setup.
The Browser-Server Security Mode Setup dialog box appears.
Step 2 Select the Enable check box.
Step 3 Click Apply.

3-2 78-16571-01
Step 4 Log out from your CiscoWorks session, and close all browser sessions.
Step 5 Restart the Daemon Manager from the CiscoWorks Server CLI:
On Windows:
a. Enter net stop crmdmgtd
b. Enter net start crmdmgtd
On Solaris:
a. Enter /etc/init.d/dmgtd stop
b. Enter /etc/init.d/dmgtd start
Step 6 Restart the browser, and the CiscoWorks session.

When you restart the CiscoWorks session after enabling SSL, you must enter the
URL with the following changes:
• The URL should begin with https instead of http to indicate secure
connection. CiscoWorks will automatically redirect you to HTTPS mode if SSL
is enabled.
• Change the port number suffix from 1741 to 443.
If you do not make the above changes, CiscoWorks Server will automatically
redirect you to HTTPS mode with port number 443. The port numbers mentioned
above are applicable for CiscoWorks Server running on Windows.
On Solaris, if the default port (1741) is used by another application, you can select
a different port during CiscoWorks Server installation. For details, see
Installation and Setup Guide for CiscoWorks Common Services on Solaris.

78-16571-01 3-3
About User Accounts
Enabling Browser-Server Security From the

Command Line Interface (CLI)
To enable Browser-Server Security from CLI:
Step 1 Go to the command prompt.

Step 2 Navigate to the directory NMSROOT\MDC\Apache.
Step 3 Enter NMSROOT\bin\perl ConfigSSL.pl -enable
Step 4 Press Enter.
About User Accounts

Several CiscoWorks network management and application management
operations are potentially disruptive to the network or to the applications
themselves, and must be protected.
To prevent such operations from being used accidentally or maliciously,
CiscoWorks uses a multi-level security system that only allows access to certain
features to users who can authenticate themselves at the appropriate level.
Common Services provides two predefined login IDs:
• guest—Specify a password during installation. User role is Help Desk.
• admin—Specify the password during installation. The user role is a
combination of System Administrator, Network Administrator, Network
Operator, Approver, and Help Desk.
The login named admin is the equivalent of a superuser (in UNIX) or an
administrator (in Windows). This login provides access to all CiscoWorks
tasks.

3-4 78-16571-01
Understanding Security Levels
However, as an administrator, you can create additional unique login IDs for users
at your company.
Note The CiscoWorks Server administrator can set the passwords for admin and guest
users during installation. Contact the CiscoWorks Server administrator if you do
not know the password for admin.
Understanding Security Levels

System administrators determine user security levels when users are granted
access to CiscoWorks. When users are granted logins to the CiscoWorks
application, they are assigned one or more roles.
A role is a collection of privileges that dictate the type of system access you have.
A privilege is a task or operation defined within the application. The set of
privileges assigned to you, defines your role and dictates how much and what type
of system access you have.
The user role or combination of roles, dictates which tasks are presented to the
users. Table 3-1 shows the security levels.
Table 3-1 Security Levels
Level Description
0 Help Desk
1 Approver
2 Network Operator
4 Network Administrator
8 System Administrator
16 Export Data
For information on tasks that can be performed with each role, see the
“Permissions Report” section on page 3-46.
See also “About Common Services Authentication” section on page 3-21.
Other roles are displayed, depending on your applications.

78-16571-01 3-5
Setting up Local Users

Local User Setup feature helps you in:
• Modifying Your Profile
• Adding a User
• Editing User Profiles.
• Deleting a User
For information on tasks that can be performed with each role, see the
“Permissions Report” section on page 3-46.
Modifying Your Profile

To edit your profile:
Local User Setup.
The Local User Setup page appears.
Step 2 Click Modify me to modify the logged in user credentials.
Step 3 Enter the password in the Password field.
Step 4 Re-enter the password in the Verify field.
Step 5 Enter the e-mail ID in the E-mail field.
Step 6 Click OK.

3-6 78-16571-01
Adding a User
You can add further users into CiscoWorks as required. To add a user:
Local User Setup.
Step 2 Click Add.
The User Information dialog box appears.
Step 3 Enter the username in the Username field.
Step 6 Enter the e-mail ID in the E-mail field.
Step 7 In the Roles pane, select the check box corresponding to the role to specify the
roles to be assigned to the user.
The following roles are available:
• Help Desk (available by default)
• Approver
• Network Operator
• Network Administrator
• System Administrator
• Export Data
See “About Common Services Authentication” section on page 3-21 for
more details.

78-16571-01 3-7
Editing User Profiles

You can edit the user profiles to modify the roles assigned to the users.
To edit user profiles:
Local User Setup.
Step 2 Click Edit.
The User Information dialog box appears.
Step 6 Enter the E-mail ID in the E-mail field.
In the Roles pane, select or deselect the check box corresponding to the role to
change the role to be assigned to the user.
Deleting a User
To delete a user:
Local User Setup.
Step 2 Select the check box corresponding to the user.
Step 3 Click Delete.
A confirmation dialog box appears.
Step 4 Click OK to confirm.

3-8 78-16571-01
Creating Self Signed Certificate
Creating Self Signed Certificate

CiscoWorks allows you to create security certificate used to enable SSL
communication between your client browser and management server.
Self signed certificates are valid for five years from the date of creation. When the
certificate expires, the browser prompts you to install the certificate again from
the server where you have installed CiscoWorks.
Note If you re-generate the certificate, when you are in multi-server mode, any existing
peer relation might break. The peers need to re-import the certificate in this
scenario.
To create a certificate:
Certificate Setup.
The Certificate page appears.
Step 2 Enter the values required for the fields described in the following table:
Field Usage Notes

Country Name Two character country code.
State or Province Two character state or province code or the
complete name of the state or province.
Locality Two character city or town code or the
complete name of the city or town.
Organization Name Complete name of your organization or an
abbreviation.
Organization Unit Name Complete name of your department or an
abbreviation.

78-16571-01 3-9
Managing Security in Multi-Server Mode
Field Usage Notes

Host Name DNS name of the computer or the IP address
of the computer.
Enter the Host Name with a proper domain
name. This is displayed on your certificate
(whether self-signed or third party issued).
Local host or 127.0.0.1 should not be given.
Email Address E-mail address to which the mail has to be
sent.
Step 3 Click Apply to create the certificate.

The process generates the following files:
• server.key—Server's private key.
• server.crt—Server's self- signed certificate.
• server.pk8—Server's private key in PKCS#8 format.
• server.csr—Certificate Signing Request (CSR) file.
You can use CSR file to request a security certificate, if you want to use a third
party security certificate.
If the certificate is not a Self signed certificate, you cannot modify it.
Managing Security in Multi-Server Mode

Communication between peer servers part of a multi server domain has to be
secure. In multi-server mode the server is configured as DCR Master/Slave or
SSO Master/Slave. In a multi-server scenario, secure communication between
peer CiscoWorks Servers is enabled using certificates and shared secrets.
You have to copy certificates between the CiscoWorks Servers. In addition, you
have to generate a shared secret on one server, and configure it on the other servers
that need to communicate with the server. The shared secret is tied to a particular
CiscoWorks user (for authorization).

3-10 78-16571-01
Setting up Peer Server Account
See the following sections to understand more about the features that enables
secure communication between peer servers part of a multi-server domain:
• Setting up Peer Server Account
• Setting up System Identity Account
• Setting up Peer Server Certificate
• Enabling Single Sign-On

Peer server Account Setup helps you create users who can programmatically login
to CiscoWorks Servers and perform certain tasks. These users should be set up to
enable communication between multiple CiscoWorks Servers. Users created
using Peer Server Account Setup can authenticate processes running on remote
CiscoWorks Servers.
In ACS mode, the user created with Peer Server Account Setup needs to be
configured in ACS, with all the privileges that user has in CiscoWorks.
See “Master-Slave Configuration Prerequisites” section on page 4-27 to know
more about the usage of this feature.
You can add a Peer Server user, edit user information and role, and delete a user.
To add a Peer Server user:
Peer Server Account Setup.
Step 2 Click Add.
The Peer Server Account Setup page appears.
Step 6 Click OK.

78-16571-01 3-11
To edit User information:
Step 2 Click Edit.
Step 5 Click OK.
To delete a User:
Step 2 Select the check box corresponding to the user you want to delete.
The confirmation dialog box appears.
Step 4 Click OK to confirm.

3-12 78-16571-01
Setting up System Identity Account
Setting up System Identity Account

Communication between multiple CiscoWorks Servers is enabled by a trust model
addressed by certificates and shared secrets. System Identity setup helps you to
create a “trust” user on servers that are part of a multi-server setup. This user
enables communication between servers that are part of a domain.
There can only be one System Identity User for each machine.
The System Identity User you configure must be a Peer Server User.
In Non-ACS mode, the System Identity User you create must be a Local User,
with System Administrator privileges. In ACS mode, the System Identity user
should be configured in ACS, with all the privileges the user has in CiscoWorks.
CiscoWorks installation program allows you to have the admin user configured as
the default System Identity User.
For the admin user to work as a System Identity User, the same password should
be configured on all machines that are part of the domain, while Installing
CiscoWorks on the machines part of that domain. If this is done, the user admin
serves the purpose of System Identity user. See Installation Guide for Common
Services 3.0, for details.
However, you can create a System Identity User from the Common Services UI
too (Common Services > Server > Security > System Identity Setup UI).
If you create a System Identity User, the default System Identity User, admin, will
be replaced by the newly created user.
While you create the System Identity User, Common Services checks whether:
• The user is a Local User with all privileges. If the user is not present, or if the
user does not have all privileges, an error message appears.
• The System Identity User is also a Peer Server User. If not, the user will
automatically be made a Peer Server User too.
For peer to peer communication to work in a multi-server domain, you have to
configure the same System Identity User on all the machines that are part of the
domain.
For example, if S1, S2, S3, S4 are part of a domain, and you configure a new
System Identity User, say Joe, on S1, you have to configure the same user, Joe,
with the same password you specified on S1, on all the other servers, S2, S3, and
S4, to enable communication between them.

78-16571-01 3-13
Setting up Peer Server Certificate
See “Master-Slave Configuration Prerequisites” section on page 4-27 and

“Enabling Single Sign-On” section on page 3-15 to know more on the usage of
this features.
To add a System Identity user:
System Identity Setup
Step 5 Click Apply.
Setting up Peer Server Certificate

You can add the certificate of another CiscoWorks Server into it's trusted store.
This will allow one CiscoWorks Server to communicate to another. If a
CiscoWorks Server needs to communicate to another CiscoWorks Server, it must
possess the Certificate of the other server. You can add Certificates of any number
of peer CiscoWorks Servers to the trusted store.
To add peer CiscoWorks Server certificates:
Step 1 In the CiscoWorks Homepage, select Common Services > Server > Security>
Peer Server Certificate Setup.
The Peer Server Certificate page appears with a list of certificates imported from
other servers.
Step 2 Click Add.
Step 3 Enter the IP address/hostname of peer CiscoWorks Server in the corresponding
fields.

3-14 78-16571-01
Enabling Single Sign-On
Step 4 Enter the value of the Non-SSL(HTTP) Port of the peer CiscoWorks Server.
Step 5 Click OK.
The default Non-SSL(HTTP) Port of the peer CiscoWorks Server is 1741.
Deleting Peer Certificates

To delete peer certificates:
Step 1 Select the check box corresponding to the certificate you want to delete.
You can also view the details of the client certificates. For this, select the
check box corresponding to the certificate and click View.
Enabling Single Sign-On

With Single Sign-On (SSO), you can use your browser session to transparently
navigate to multiple CiscoWorks Servers without authenticating to each of them.
Communication between multiple CiscoWorks Servers is enabled by a trust model
addressed by Certificates and shared secrets.
The following tasks need to be done initially:
• One of the CiscoWorks Servers should be set up as the authentication server.
• Trust should be built between the CiscoWorks Servers, using self signed
certificates. A trusted certificate is created by adding it in the trust key store
of the server. CiscoWorks TrustStore or KeyStore is maintained by the
certificate management framework in Common Services.
• Each CiscoWorks Server should setup a shared secret with the authentication
server. The System Identity user password acts as a secret key for SSO.
The SSO authentication server is called the Master, and the SSO regular server is
called the Slave.

78-16571-01 3-15
Navigating Through the SSO Domain
The following tasks should be performed if the server is either configured as

Master or Slave.
• Configure the System Identity User and password in both Master and Slave.
The System Identity User name and password you specify in Master and
Slave should be the same.
• Configure Master’s Self Signed Certificate in Slave.
To set up System Identity User:
Step 1 Select Common Services > Server > Security > System Identity Setup.
Step 2 Enter the username and password.
Step 3 Click Apply.
SSO uses System Identity User password as the secret key to provide
confidentiality and authenticity between Master and Slave.
It is sufficient to have the same System Identity User passwords in Master and
Slave, without having the same user name.
We recommend that you have the same user name and password across Master and
Slave.
To configure Master’s Self Signed Certificate in the Slave, select

Common Services > Server > Security > Peer Server Certificate Setup > Add.
The CN present in the certificate should match with the Master server name.
Otherwise it would not be considered as a valid certificate.

The Authentication Server and all Regular Servers that are configured on this
Authentication Server forms an SSO domain. If you login to any of the servers
that are part of the same SSO domain, you can launch any other server that is part
of the domain.
You can navigate through the SSO domain in two ways. By:
• Registering Server Links
• Launching a new Browser Instance

3-16 78-16571-01
Registering Server Links

You can register the links of servers part of the SSO domain, in any of the servers,
using the Link registration feature. See “Registering Links With CWHP” section
on page 2-11.
The registered links will appear either under Third Party or Custom tools,
depending on what you specify during registration. If you click on the registered
link, it launches the page corresponding to the registered link.
You must specify the URL, with the context while registering the server link.
For example, let ABC and XYZ be part of the same SSO domain. You can register
the link for ABC on XYZ. While registering server ABC in XYZ, you have to
specify the URL as:
http://ABC:1741/cwhp/cwhp.applications.do
If ABC is running in HTTPS mode, you have to specify the URL as:
https://ABC:443/cwhp/cwhp.applications.do
In the above example, clicking on the registered link will launch the CiscoWorks
Homepage of server ABC.
Launching a new Browser Instance

After logging in to any of the servers part of the SSO domain, you can open a new
browser instance from that server, and provide the URL of any other server part
of the SSO domain, to which you need to navigate to.
Note We recommend that you do not use IP address of the servers that are part of SSO
or localhost, while specifying the URL.

78-16571-01 3-17
Changing the Single Sign-On Mode
Suppose ABC and XYZ are part of an SSO domain.
Step 1 Login to ABC.

Step 2 Launch a new browser instance (File > New > Window, in Internet Explorer)
from the same browser window.
Step 3 Enter the URL, with the context (http://XYZ:1741/cwhp/cwhp.applications.do) of
XYZ in the new browser instance.
This launches the CiscoWorks Homepage of XYZ, directly.

The Common Services server can be configured for Single Sign-On (SSO). It can
also be configured to be in Standalone mode (Normal mode, without SSO).
When the server is configured for SSO, it can either be in:
• Master mode—The SSO Authentication Server does the authentication and
sends the result to the Regular Server.
Change the SSO mode to Master, if log in is required for all SSO regular
servers. Login requests for all the SSO regular servers will be served from the
Master.
• Slave mode—SSO Regular server for which authentication is done at the
Master.
Only one server is configured to be in the Master mode. All other servers are
configured as Slaves. If the server is configured as an SSO Regular server (Slave),
you should provide the following details:
• Master server name
• Login Port of the Master (443)
If you change the name of the server configured as the Master, in the /etc/hosts
file, you must restart Daemon Manager for the name resolution to reflect in
the Slave.

3-18 78-16571-01
To change the SSO mode to Standalone:
Single Sign-On.
The Single Sign-On Configuration page shows the current Single Sign-On mode.
Step 2 Click Change Mode
Step 3 Select Standalone (Normal) radio button.
Step 4 Click Apply.
To change the SSO mode to Master:
Single Sign-On.
The Single Sign-On Configuration page shows the current Single Sign On mode.
Step 2 Click Change Mode.
Step 3 Select the Master (SSO Authentication Server) radio button.
Step 4 Click Apply.
To change the SSO mode to Slave:
Single Sign-On.
The Single Sign-On Configuration page shows the current Single Sign-On mode.
Step 2 Click Change Mode.
Step 3 Select the Slave (SSO Regular Server) radio button.
Step 4 Enter the Master server name and port number.
If you select the Slave mode, ensure that you specify the Master server name and
port. The default port is 443. The server configured as master (or Authentication
Server) should be DNS resolvable.

78-16571-01 3-19
Setting up the AAA Mode
Step 5 Click Apply.

It checks whether:
• The System Identity user password of the Slave matches that of the Master.
• The Self Signed Certificate of the Master is added as the peer certificate in
the Slave. The CN present in the certificate should match with the Master
server name.
• The Master is up and running on the specified port.
In case these checks fail, you are prompted to perform these steps, before
proceeding.
Setting up the AAA Mode

The CiscoWorks Server provides mechanisms used to authenticate users for
CiscoWorks applications.
CiscoWorks login modules allow administrators to add new users using a source
of authentication other than the native CiscoWorks Server mechanism (that is, the
CiscoWorks Local login module). You can use Cisco Secure ACS services for this
purpose (see Setting the Login Module to ACS).
However, many network managers already have a means of authenticating users.
To use your current authentication database for CiscoWorks authentication, you
can select a login module (NT, UNIX, TACACS+, Radius, and others).
After you select and configure a login module, all authentication transactions are
performed by that source.
The CiscoWorks Server determines user roles. Therefore, all users must be in the
local database of user IDs and passwords. Users who are authenticated by an
alternative service and who are not in the local database are assigned to the same
role as the guest user (by default, the Help Desk role).
To assign a user to a different role, such as the System Admin role, you must
configure the user locally. Such users must have the same user ID locally, as they
have in the alternative authentication source. Users log in with the user ID and
password associated with the current login module.

3-20 78-16571-01
About Common Services Authentication
CiscoWorks Common Services supports two AAA modes:

• Non-ACS
• ACS
To use this mode, you must have a Cisco Secure ACS (Access Control
Server), installed on your network. Common Services 3.0 supports the
following versions of Cisco Secure ACS for Windows Server:
– Cisco Secure ACS 3.2
– Cisco Secure ACS 3.2.3
– Cisco Secure ACS 3.3.2
We recommend that you install the Admin HTTPS PSIRT patch, if you are
using ACS3.2.3.
To install the patch:
• Go to http://www.cisco.com/kobayashi/sw-center/ciscosecure/cs-acs.shtml
• Click Download CiscoSecure ACS Software (Windows) link. You can find
the link to the Admin HTTPS PSIRT patch, in the table.
See “Setting the Login Module to Non-ACS” section on page 3-24 and “Setting
the Login Module to ACS” section on page 3-35 for details on usage of the login
modules.

By default, CiscoWorks Common Services uses CiscoWorks Server
authentication (CiscoWorks Local) to authenticate users, and authorize them to
access CiscoWorks Common Services applications.
After authentication, your authorization is based on the privileges that have been
assigned to you. A privilege is a task or an operation defined within the
application. The set of privileges assigned to you, defines your role. It dictates
how much, and what type of system access you have.

78-16571-01 3-21
The CiscoWorks Server authentication scheme has five default roles. They are
listed here from the least privileged to most privileged:
• Help Desk
Can access network status information only. Can access persisted data on the
system and cannot perform any action on a device or schedule a job which
will reach the network.
• Approver
Can approve all tasks.
• Network Operator
Can do all Help Desk tasks. Can do tasks related to network data collection.
Cannot do any task that requires write access on the network.
• Network Administrator
Can do all Network Operators tasks. Can do tasks that result in a network
configuration change.
• System Administrator.
Can perform all CiscoWorks system administration tasks.
If you configure Common Services to use Non-ACS for authentication,
authorization services are provided by CiscoWorks Server.
In Non-ACS mode, you cannot change the roles, or the privileges assigned to
these roles. However, a user can be assigned a combination of these roles. See
“Setting up Local Users” section on page 3-6.
In ACS mode, you can create custom roles so that you can customize
Common Services client applications to best suit your business workflow and
needs.
That is, you can create a user, and assign the user with a set of privileges, that
would suit your needs. See “Assigning Privileges in ACS” section on page 3-38
and “Creating and Modifying Roles in ACS” section on page 3-39 sections for
details.

3-22 78-16571-01
Cisco Secure ACS Support for Common Services Client Applications
Cisco Secure ACS Support for Common Services

Client Applications
CiscoSecure ACS provides authentication, authorization, and accounting services
to network devices that function as AAA clients. CiscoSecure ACS uses the
TACACS+ and RADIUS protocols to provide AAA services that ensure a secure
environment.
Cisco Secure ACS supports Common Services client applications by providing
command authorization for network users who use the management application to
configure managed network devices.
Command authorization for client application users is supported using unique
command authorization set types for each client application configured to use
Cisco Secure ACS for authorization.
Cisco Secure ACS uses TACACS+ to communicate with client applications. For
a client application to communicate with Cisco Secure ACS, you must configure
it in Cisco Secure ACS as an AAA client that uses TACACS+.
Also, you must provide the client application with a valid administrator name and
password. When a client application initially communicates with
Cisco Secure ACS, these requirements ensure the validity of the communication.
Additionally, the administrator (used by the client application) must have the
Create New Device Command Set Type privilege enabled. When a client
application initially communicates with Cisco Secure ACS, it makes the
Cisco Secure ACS create a new device command set type.
This new device command set type appears in the Shared Profile Components
section of the HTML interface. It also dictates a custom service to be authorized
by TACACS+. The custom service appears on the TACACS+ page in the
Interface Configuration section of the HTML interface.
After the client application has dictated the custom TACACS+ service and device
command set type to Cisco Secure ACS, you can configure command
authorization sets for each role supported by the client application.
You can then apply those sets to user groups that contain network administrators
or to individual users who are network administrators.
For more information about configuring Cisco Secure ACS administrators, users,
and command authorization sets, see the User Guide for Cisco Secure ACS for
Windows Server Version 3.3 on Cisco.com, or the CiscoSecure ACS Online Help.

78-16571-01 3-23
Setting the Login Module to Non-ACS
Detailed information about the various configuration options appear in the

Cisco Secure ACS documentation.

The Login Module defines how authorization and authentication are performed.
To set the login module to Non-ACS mode:
AAA Mode Setup.
Step 2 Select the Non-ACS radio button.
The Login Module window displays the current login module, and the available
login modules. The available login modules are:
• CiscoWorks Local
• IBM SecureWay Directory
• KerberosLogin
• Local UNIX System
• Local NT System
• MS Active Directory
• Netscape Directory
• Radius
• TACACS+
The login username is case sensitive when you use the following Non-ACS login
modules:
• KerberosLogin
• Local UNIX System
• Netscape Directory
• Radius
• TACACS+

3-24 78-16571-01
Changing Login Module to CiscoWorks Local

To change the login module to CiscoWorks Local:
Step 1 Select the CiscoWorks Local radio button.

Step 2 Click Change.
The Login Module Options popup window appears.
Step 3 Set the Debug option to False.
Set it to True for debugging purposes, when requested by your customer service
representative.
Changing Login Module to IBM SecureWay Directory

The IBM SecureWay Directory login module implements Lightweight Directory
Access Protocol (LDAP). Before a user can log in, a user's account is set up in the
LDAP server. The user's account has two fields, Distinguished name and
password.
A Distinguished name is made up of three parts, Prefix, User login, and Usersroot.
Userroot is queried for the username during login and the Distinguished name is
automatically created.
If the user is not found, then the Distinguished name is created by appending
Prefix + login name + Usersroot.
For example, a Distinguished name could be represented as: uid=John ou=embu
o=cisco.com, where the Prefix is uid=, the login name is John, and the Usersroot
ou=embu, o=cisco.com).

78-16571-01 3-25
To change the login module to IBM SecureWay Directory:
Step 1 Select the IBM SecureWay Directory radio button.

The Login Module Options popup window appears with the following details:
Field Description
Selected Login Module IBM SecureWay Directory
Description CiscoWorks IBM LDAP module.
Server Default set to ldap://ldap.company.com.
Userroot Default set to ou=active, ou=employees,
ou=people, o=company
Prefix Default set to cn=
Debug Set to false. Set to true for debugging
purposes, when requested by your
customer service representative.
Login fallback options Set the option for fallback to the
CiscoWorks Local module if the
alternative service fails.
Step 3 Click OK.

3-26 78-16571-01
Changing Login Module to KerberosLogin

Kerberos provides strong authentication for client/server applications by using
secret-key cryptography.
To change the Login Module to KerberosLogin:
Step 1 Select the KerberosLogin radio button.

Field Description
Selected Login Module KerberosLogin Kerberos login module.
Description Kerberos login module.
Debug Set to False. Set to True for debugging
purposes, when requested by your customer
service representative.
Realm The Kerberos realm name. Although the realm
can be any ASCII string, the convention is to
make it the same as your domain name, in
upper-case letters.
For example, SERVER.COM.
KDC The Kerberos Key Distribution Center. For
example, my_kdc.server.com.
Login fallback options Set the option for fallback to the CiscoWorks
Local module if the alternative service fails.
Step 3 Click OK.

78-16571-01 3-27
Changing Login Module to Local Unix System

This option is available only on Unix systems.
To change the login module to Local Unix System:
Step 1 Select the Local Unix System radio button.

Field Description
Selected Login Module Local UNIX System.
Description CiscoWorks native Solaris module.
CiscoWorks Local module if the alternative
service fails.
Step 3 Click OK.

3-28 78-16571-01
Changing Login Module to Local NT System

This option is available only on Windows
To change the login module to Local NT System:
Step 1 Select Local NT System radio button.

Field Description
Selected Login Module Local NT System.
Description CiscoWorks native NT login module.
purposes, when requested by your
customer service representative.
Domain Set to localhost.
CiscoWorks Local module if the
alternative service fails.
Step 3 Click OK.
Changing Login Module to MS Active Directory

The MS Active Directory login module implements Lightweight Directory
Access Protocol (LDAP). Before a user can log in, a user's account is set up in the
LDAP server. The user's account has two fields, Distinguished name and
password.
The user login is appended when the user logs in so the Distinguished name is
Prefix+login name+Usersroot.

78-16571-01 3-29
For example, a Distinguished name could be represented as: cn=John dc=embu

dc=cisco, where the Prefix is cn=, the login name is John, and the Usersroot
dc=embu, dc=cisco).
To change login module to MS Active Directory:
Step 1 Select MS Active Directory radio button.

Field Description
Selected Login Module MS Active Directory.
Description CiscoWorks MS Active Directory module.
Usersroot Default set to cn=users, dc=servername,
dc=company, dc=com. If you are using
Windows 2003 Active Directory, you have
to provide the complete Usersroot
information. This is because Windows 2003
Active Directory implementation has
disabled anonymous search requests.
Prefix Default set to cn=
service fails.
Step 3 Click OK.

3-30 78-16571-01
Changing Login Module to Netscape Directory

The Netscape Directory login module implements Lightweight Directory Access
Protocol (LDAP). Before a user can log in, a user's account is set up in the LDAP
server. The user's account has two fields, Distinguished name and password.
Userroot is queried for the username during login and the Distinguished name is
automatically created. If the user is not found, then the Distinguished name is
created by appending Prefix + login name + Usersroot.
For example, a Distinguished name could be represented as: uid=John ou=embu
o=cisco.com, where the Prefix is uid=, the login name is John, and the Usersroot
ou=embu, o=cisco.com).
To change login module to Netscape Directory:
Step 1 Select Netscape Directory radio button.

Field Description
Selected Login Module Netscape Directory.
Description CiscoWorks Netscape LDAP module.
Usersroot Default set to ou=active, ou=employees,
ou=people, o=company.com.
Prefix Default set to uid=
Login fallback options Set the option for fallback to the CiscoWorks
Local module if the alternative service fails.
Step 3 Click OK.

78-16571-01 3-31
Changing Login Module to Radius

To change login module to Radius:
Step 1 Select Radius radio button.

Field Description
Selected Login Module Radius.
Description CiscoWorks Radius module.
Server Set to module type servername,
radius.company.com.
Port Set to 1645. Attempt to override it only if
your authentication server was configured
with a non-default port.
Key Enter the secret key.
service fails.
Step 3 Click OK.

3-32 78-16571-01
Changing Login Module to TACACS+

To change login module to TACACS+:
Step 1 Select TACACS+ radio button.

Field Description
Selected Login Module TACACS+.
Description CiscoWorks TACACS+ login module.
Server Set to module type tacacs.company.com
Port Set to 49. The listed port number is the
default for this protocol. Attempt to
override it only if your authentication server
was configured with a non-default port.
Secondary Server Set to module type tacacs.company.com.
This is the secondary fallback server.
Secondary Port Set to 49. The listed port number is the
Tertiary Server Set to module type tacacs.company.com.
This is the tertiary fallback server.
Tertiary Port Set to 49. The listed port number is the
Key Enter the secret key.

78-16571-01 3-33
Field Description
service fails.
Note The values true or false should not be entered in the Server, Secondary Server
and Tertiary Server fields, the corresponding Port fields or the Key field.
Step 3 Click OK.
After you change the login module, you do not have to restart CiscoWorks. The
user who logs in after the change, automatically uses the new module. Changes to
the login module are logged in the following directory:
$NMSROOT/MDC/Tomcat/logs/stdout.log

3-34 78-16571-01
Setting the Login Module to ACS
Understanding Fallback Options for Non-ACS mode

Fallback options allow you to access the software if the login module fails, or you
accidentally lock yourself or others. There are three login module fallback
options. These are available on all platforms. The Table 3-2 gives details:
Table 3-2 Login Module Fallback Options
Option Description
Allow all CiscoWorks Local users to All users can access CiscoWorks using
fall back to the CiscoWorks Local the Local login if the current login
login. module fails.
Allow only the following user(s) to fall Specified users can access CiscoWorks
back to the CiscoWorks Local login if using the Local login if the current
preceding login fails: username. login module fails. Use commas
between user names.
Allow no fall backs to the CiscoWorks No access is allowed if the current
Local login. login module fails.

The Login Module determines the type of authentication and authorization
Common Services uses. By default, the login module is set to local authentication
and authorization.
You can change this default value to use Cisco Secure ACS for user
authentication and authorization.
When you change login module to ACS ensure that:
• The CiscoWorks Server is added as an AAA client in the ACS server. For the
first time, it can be done at the Network Configuration UI in ACS server. You
can add the host (with IP Address), and configure the secret key there.
The same secret key should be entered in the AAA Mode Setup dialog box.
• The username you enter while logging in to CiscoWorks is a valid ACS user
name. In ACS mode, authentication takes place from the ACS server.

78-16571-01 3-35
To set login module to ACS:
AAA Mode Setup.
The AAA Mode Setup page appears with the AAA Mode Setup dialog box.
Step 2 Select the ACS radio button.
Step 3 In the Server details panel, enter:
• Primary IP Address/Hostname
• Secondary IP Address/Hostname
• Tertiary IP Address/Hostname
and the corresponding ACS TACACS+ port numbers.
The default port is 49. Secondary and Tertiary IP address/hostname details are
optional.
The values true and false will not be accepted in the Primary, Secondary, and
Tertiary IP Address/Hostname fields.
Step 4 In the login panel, enter:
• ACS Admin Name
• ACS Admin Password
• ACS Shared Secret Key
Also, re-enter the ACS admin password, and ACS shared secret key in the
Verify fields.
The values true and false will not be accepted in the above fields.
Step 5 Select the Register all installed applications with ACS to register all the
installed application with the ACS server.
Note In case an application is already registered with ACS, the current

registration will overwrite the previous one.
Step 6 Click Apply.

3-36 78-16571-01
Step 7 Restart the Daemon Manager:

On Windows:
a. Enter net stop crmdmgtd
b. Enter net start crmdmgtd
On Solaris:
a. Enter /etc/init.d/dmgtd stop
b. Enter /etc/init.d/dmgtd start
Select the Connect to ACS in HTTPS mode check box in the Login Module
dialog box, if ACS is in HTTPS mode.
Note You must enable ACS communication on HTTPS if ACS is in HTTPS

mode.
Primary, Secondary, and Tertiary servers should use the same protocol. All of
them should either operate in HTTP mode, or HTTPS mode.
The Primary, Secondary, and Tertiary servers must have the same configuration.
For Primary, Secondary, and Tertiary servers, the ACS Admin Name, the ACS
Admin Password, and the ACS Shared Secret Key should be the same.
AAA clients, Network Device Groups (NDGs), users, groups, registered
applications, and custom roles must be the same across Primary, Secondary, and
Tertiary servers.
Common Services supports SSL and non SSL modes of communication with ACS
server. TACACS+ is used for AAA requests. HTTP/HTTPS mode is used for
application registration, and device or device group import/export tasks.

78-16571-01 3-37
Assigning Privileges in ACS

You have to ensure that the user has been assigned the proper privileges in ACS
mode.
To assign the privileges to the user if ACS is configured to use group
authentication:
Step 1 In Cisco Secure ACS, go to Group Setup.

Step 2 Select the group to which the user belongs, from the Group drop-down list.
Step 3 Click Edit Settings.
A page appears with the group settings.
Step 4 Scroll down to CiscoWorks. There are three options:
• None: Authorization will fail for any task.
• Assign a Ciscoworks for any network device.
Select the desired role from the drop-down list. The user can execute the tasks
that are assigned to the chosen role, on every device.
• Assign a Ciscoworks on a per Network Device Group Basis.
Select the device group from the Device Group drop-down list. Choose the
role you want to associate with the group. The user can execute the tasks that
are assigned to the chosen roles on the chosen device groups.
Step 5 Select any of the options, based on the required security level.
To assign the privileges if ACS is configured to use user authentication:
Step 1 In Cisco Secure ACS, go to User Setup.

Step 2 Enter the user name and click Add/Edit.
Or,
Click List all Users and click the required user link from the User List.
A page appears with the user details and settings.

3-38 78-16571-01
Step 3 Scroll down to CiscoWorks. There are four options:

• None: Authorization will fail for any task.
• As Group: The privileges applicable to the group, the user is part of.
• Assign a Ciscoworks for any network device.
Select the desired role from the drop-down list. The user can execute the tasks
that are assigned to the chosen role, on every device.
• Assign a Ciscoworks on a per Network Device Group Basis.
Select the device group from the Device Group drop-down list. Choose the
role you want to associate with the group. The user can execute the tasks that
are assigned to the chosen roles on the chosen device groups.
Step 4 Select any of the options, based on the required security level.
Creating and Modifying Roles in ACS

In ACS, you can create new roles or modify existing roles.
To create a new role:
Step 1 Go to Cisco Secure ACS.

Step 2 Select Shared Profile Components > CiscoWorks Common Services. The
Shared Profile Components page appears.
Step 3 Click Add.
Step 4 Enter the name and description for the new role.

78-16571-01 3-39
Step 5 Select the required Common Services tasks that you need to associate with the
role.
Tasks are displayed as a checklist tree on the left pane of the ACS UI.
• If you select an expandable check box node, all check boxes within that node
are selected.
• If you select the first check box in the checklist tree, all check boxes in the
checklist tree are selected.
Step 6 Click Submit.
To edit an existing role:

Step 2 Select Shared Profile Components > CiscoWorks Common Services. The
Shared Profile Components page appears.
Step 3 Select the role you need.
The Shared Profile Components page displays the Edit dialog box.
Step 4 Select the Common Services tasks that you need to associate with the role.
If you want to remove any task associated with the role, deselect the check box
corresponding to the task.
Step 5 Click Submit.

3-40 78-16571-01
To delete a role:

Step 2 Select Shared Profile Components > CiscoWorks Common Services.
The Shared Profile Components page appears.
Step 3 Select the role you need to delete.
The Shared Profile Components page displays the Edit dialog box.
We recommend not to assign roles to DEFAULT device group. When DEFAULT

(unassigned device group) is selected, you can perform only Help Desk role,
irrespective of the roles chosen.
To assign the proper role, the network access server (NAS) should be added in the
device groups other than DEFAULT.
You should log in as a user that has been created on the ACS server. If you log in
as a user configured in Common Services, say admin, you will get authenticated.
However, if the user is not configured in the ACS server, authorization will fail.
In case of users other than Admin, even authentication will not happen.
If you add or change device information in the Network Device Group, the change
will not be immediately propagated to Common Services. For the changes to get
updated in Common Services (when in ACS mode) you have to re-login to
Common Services.
You can assign only one role to a user in ACS, to operate on the same NDG.
If a user requires privileges other than those associated with the current role, to
operate on an NDG, a custom role should be created. All necessary privileges to
enable the user operate on the NDG should be given to this role.
For example, if a user needs to have Approver and Network Operator privileges
to operate on NDG1, you can create a new role with Network Operator and
Approver privileges, and assign the role to the user so that he can operate on
NDG1.
We recommend that you have maximum 50 NDGs and 50000 devices in ACS. If
the number of NDGs or devices exceed these limits, performance may be affected.

78-16571-01 3-41
Resetting Login Module

If there is an authorization failure with ACS server, most of the Common Services
features will be disabled.
To recover, you have to reset the login module.
To do this:
Step 1 Stop the Daemon Manager using:

• net stop crmdmgtd (For Windows)
or
• /etc/init.d/dmgtd stop (For Solaris)
Step 2 Run the following script:
• NMSROOT/bin/perl ResetLoginModule.pl (For Windows)
or
• /opt/CSCOpx/bin/perl ResetLoginModule.pl (For Solaris)
Step 3 Start the Daemon Manager using:
• net start crmdmgtd (For Windows)
or
• /etc/init.d/dmgtd start (For Solaris)
This reset the login module to CiscoWorks local mode.
Multiple instances of same application using same ACS server will share settings.
Any changes will affect all instances of that application.
If an application is configured with ACS, and then the application is reinstalled,
the application will inherit the old settings.

3-42 78-16571-01
Understanding Fallback Options for ACS Mode

Fallback option in ACS mode is different from Non-ACS mode. Here, fallback is
provided only for authentication. If authentication with ACS fails, authentication
is tried with CiscoWorks local mode.
If it succeeds, you are allowed to change the login module to Non-ACS mode,
provided you have permission to do that operation in Non-ACS mode. You will
not be allowed to login if the authentication fails in CiscoWorks local mode.
If you log in using fallback mode, you will be presented with a dialog box with
instructions to change the login mode to CiscoWorks local.
To change the login mode:
Step 1 Go to Common Services > Server > Security > AAA Mode Setup >
CiscoWorks Local.
You need to have proper permission to change the login mode. Otherwise the
Change button will be disabled.
To add the fallback users in ACS, the admin should:
Step 1 Select Non-ACS mode.

Step 2 Select Tacacs+ and click Change.
Step 3 Specify the fallback users in Login fallback options field.
Step 4 Click OK.
Step 5 Select ACS mode.
Step 6 Enter the required values. See “Setting the Login Module to ACS” section on
page 3-35, for details.
Step 7 Click Apply.

78-16571-01 3-43
Managing Cisco.com Connection
Managing Cisco.com Connection

Certain Software Center features require Cisco.com access. This means that
CiscoWorks must be configured with a Cisco.com account which is to be used
when downloading new and updated packages.
Setting up Cisco.com User Account

To set up Cisco.com login account:
Cisco.com User Account Setup.
The Cisco.com Login dialog box appears.
Step 2 Enter the Username, and Password.
Step 3 Re-enter Password in the Verify Password field.
Step 4 Click Apply.
Setting Up the Proxy Server

You can update the proxy server configuration using the Proxy Server set up
option.
To update your proxy server configuration:
Step 1 In the Cisco Works Homepage, select Common Services > Server > Security >
Proxy Server Setup.
The Proxy Information dialog box appears.
Step 2 Enter the Proxy Server host name or IP address, and the port number.
Step 3 Click Apply.

3-44 78-16571-01
Generating Reports
Generating Reports
Common Services includes a Report Generator that provides detailed reports on
log file status, roles and privileges, users currently logged in, and processes that
are currently running.
The following reports are available:
• Log File Status Report
• Permissions Report
• Users Logged In Report
• Process Status Report
• Viewing Audit Log Report
The following sections describe how to launch these reports, and explain each
report.
Log File Status Report

The Log File Status Report provides information on log file size and file system
utilization.
To generate the log file status report:
Step 1 In the CiscoWorks Homepage, select Common Services > Server > Reports.
The Reports page appears.
Step 2 From the Available Reports pane, select Log File Status.

78-16571-01 3-45
Generating Reports
Step 3 Click Generate Report.

The Log File Status Report appears.
The Log File Status Report appears with the following details:
Item Description
Log File Name of the log file.
Location Location of the log file.
File Size Current size of the log file.
File size displayed in Red means the size has
exceeded the limit.
Size Limit Maximum size a log file can have.
File System Utilization File system utilization in percentage.
Value if displayed in Red means the size has
exceeded the limit.
Permissions Report
The Permissions Report provides information on roles and privileges associated
with the roles. It specifies the tasks that a user in a particular role can perform.
A privilege is a task or an operation defined within the application. The set of
privileges assigned to you, defines your role and dictates how much, and what
type of system access you have.
To generate the Permissions Report:
Step 2 From the Available Reports pane, select Permissions Report.

3-46 78-16571-01
Generating Reports

The Permissions Report appears.
The Permissions Report appears with the following details:
Item Description
Last Run Time Last time the report was run.
Duration Duration for which the report was run.
Device Scanned Devices that were scanned.
Average Scan Time Average time taken to scan each device.
Device with Changes Devices that has changed state.
Description Description of the task.
Task Path Navigational path.
Role Role required to perform the task.
Users Logged In Report

The Users Logged In Report provides information on users currently logged into
Common Services.
To generate the Report:
Step 2 In the Available Reports pane, select Who is Logged On.

78-16571-01 3-47
Generating Reports

The Users Logged In report appears.
The Users Logged In report appears with the following information:
Item Descriptions
Status Whether the user is online or offline.
User Name User name
Roles Shows the roles of the user.
IP address IP address
Last Active Date and time when the user was previously active.
Logged in Time when the user previously logged in
Process Status Report

The Process Status Report shows the status of the processes running on the
CiscoWorks Server.
To generate the Process Status Report:
Step 2 In the Available Reports pane, select Process Status.

3-48 78-16571-01
Generating Reports

The Process Status report is displayed.
The Process Status Report appears with the following information:
Item Description
Process Name Name of the process.
State Current state of the process.
Pid Process ID.
Start Time Time at which the process started.
Stop time Time at which the process stopped.
Viewing Audit Log Report

Audit log maintains the log of user logins into Common Services.
In non-ACS mode, audit log report provides information on user logins to
CiscoWorks Homepage and other applications launched from the Homepage.
In ACS mode, audit log reports log messages maintained by ACS.
Audit Logs are stored as comma-separated value lists (CSVs).
• If you are using local authentication, the files are stored on the local server.
• If you are using ACS authentication, the files are stored on the ACS server
and you can view them from within both ACS and CiscoWorks Common
Services.
To view Audit Log Report:
Step 1 Select Common Services > Server > Reports > Audit Log in the
CiscoWorks Common Services navigation tree.
The Audit Log Data Viewer appears with a list of audit logs.
The Audit Logs are listed in chronological order, with the most recent logs
appearing at the top of the list. The logs are named and listed by the date on which
they were created, for example Audit-Log-2004-10-27.csv.

78-16571-01 3-49
Generating Reports
Step 3 Click an Audit Log file link to view the audit log details.
Audit log report in Non-ACS mode:
Item Description
Date Date on which the activity is carried out.
Time Time at which the activity is carried out.
User The user who performed the activity.
Acct-Flags The status of the activity. For example start
Service The application that the user accessed.
Cmd The activity that was performed.
For example: Logout
Reason A description of the activity.
For example: User admin logged out of cwhp
Audit log report in ACS mode:
Item Description
Date Date on which the activity is carried out.
Time Time at which the activity is carried out.
User_Name The user who performed the activity.
Group_Name The group to which the user belongs.
Cmd The activity that was performed. For example:
Logout.
Priv_Lv1 The privilege level of the user in ACS.
Service The application that the user accessed. For
Common Services, the value displayed is cwhp.
NAS_Portname The NAS port name.
Task_Id The unique identifier for the task.
NAS_IP_Address The IP address of the CiscoWorks Server.
Reason A description of the activity. For example: User
admin logged out of cwhp

3-50 78-16571-01
Administering Common Services
If you are using local authentication, the files are stored on the local server. If you
are using ACS authentication, the files are stored on the ACS server and you can
view them from within both ACS, and Common Services.
In ACS, you can add additional fields to be logged in the Report.
This can be done at:
System Configuration > Logging > CSV TACACS+ Administration.
If a field added is of no relevance to CiscoWorks Common Services, it’s value
will not be displayed in the Report.
To view the Audit Logs from ACS:
Step 1 Click Reports and Activity in the ACS Navigation bar.

A list of report types appears.
Step 2 Click TACACS+ Administration.
A list of Audit Logs appears. The Audit Logs are listed in chronological order,
with the most recent logs appearing at the top of the list. The logs are named and
listed by the date on which they were created, for example an Audit Log created
on 14 October 2004 is named TACACS+ Administration 2004-10-14.
Note If you configure ACS to use Day/Month/Year format, an Audit Log

created on 14 October 2004 is named TACACS+ Administration
2004-14-10.csv.
Administering Common Services

Common Services includes several administrative features to ensure that the
server is performing properly. You can manage process, set up backup
parameters, update licensing information, collect server information, and manage
jobs and resources.

78-16571-01 3-51
Using Daemon Manager
Using Daemon Manager

The Daemon Manager provides the following services:
• Maintains the startup dependencies among processes.
• Starts and stops processes based on their dependency relationships.
• Restarts processes if an abnormal termination is detected.
• Monitors the status of processes.
The Daemon Manager is useful to applications that have long-running processes
that must be monitored and restarted, if necessary. It is also used to start processes
in a dependency sequence, and to start transient jobs.
Restarting Daemon Manager on Solaris

To restart Daemon Manager on Solaris:
Step 1 Log in as root.

Step 2 To stop the Daemon Manager, enter:
/etc/init.d/dmgtd stop
Step 3 To start the Daemon Manager, enter:

/etc/init.d/dmgtd start
Note Do not start the Daemon Manager immediately after you stop it. The ports used
by Daemon Manager will be in use for some more time even after the Daemon
Manager is stopped. Wait for at least a minute before you start the Daemon
Manager.
If the System resources are less than the required resources to install the
application, Daemon Manager restart displays warning messages.
You cannot start the Daemon Manager if there are Non-SSL compliant
applications installed on the server when SSL is enabled in Common Services.

3-52 78-16571-01
Managing Processes
Restarting Daemon Manager on Windows

To restart Daemon Manager on Windows:
Step 1 Go to Command Prompt.

Step 2 To stop the Daemon Manager, enter:
net stop CRMdmgtd
Step 3 To start the Daemon Manager, enter:

net start CRMdmgtd
Note Do not start the Daemon Manager immediately after you stop it. The ports used
by Daemon Manager will be in use for some more time even after the Daemon
Manager is stopped. Wait for at least one minute before you start the Daemon
Manager.
If the System resources are less than the required resources to install the
application, Daemon Manager restart displays warning messages that are logged
into syslog.log.
Managing Processes
CiscoWorks applications use back-end processes to manage application-specific
activities or jobs. The process management tools enable you to manage these
back-end processes to optimize or troubleshoot the CiscoWorks Server.

78-16571-01 3-53
Managing Processes
Viewing Process Details

To view Process details:
Step 1 In the CiscoWorks Homepage, select Common Services > Server > Admin >
Process.
The Process page appears.
Step 2 Click the Process link.
The Process Details popup window appears. The window provides information on
the path, flags, startup, and dependencies.
Starting a Process
To start a Process:
Process.
The process page appears.
Step 2 Select the check box corresponding to the process.
Step 3 Click Start.

3-54 78-16571-01
Backing Up Data
Stopping a Process
To stop a Process:
Process.
The Process page appears.
Step 2 Select the check box corresponding to the process.
Step 3 Click Stop.
Backing Up Data
You should back up the database regularly so that you have a safe copy of the
database. You can schedule immediate, daily, weekly, or monthly automatic
database backups.
You cannot back up the database while restoring the database. Common Services
uses multiple databases to store client application data. These databases are
backed up whenever you perform a backup.
Note Backup requires enough storage space on the target location for the backup to
start.

78-16571-01 3-55
Backing Up Data
To schedule a backup:
Backup.
The Backup page appears.
Step 2 Enter the appropriate information in the following fields:
Field Description
Backup Directory Location of the backup directory. We recommend that
your target location be on a different partition than the
CiscoWorks installation location.
Runtype Select the desired check box. You have options to
schedule immediate, daily, weekly, or monthly
backups.
Time From the drop-down lists, select the time and date.
• If you schedule a weekly backup, select the day of
the week from the drop-down list.
• If you schedule a monthly backup, select the day
of the month from the drop-down list.
Generations Maximum number of backups to be stored in the
backup directory.
Step 3 Click Apply.

3-56 78-16571-01
Backing Up Data
Backing up Using CLI

You can Backup data using CLI on Windows and Solaris, by running the
following command:
NMSROOT/bin/backup.pl BackupDirectory [LogFile] [Num_Generations]
where,
• BackupDirectory—Directory that you want to be your Backup directory.
• LogFile—Log file name.
• Num_Generations—Maximum backup generations to be kept in the backup
directory.
Data Backed up During CS 3.0 Backup

The following data is backed up:
• CiscoWorks User information
• Single Sign-on configuration
• Device and Credential Repository (DCR) configuration
• Peer Certificates and Self Signed certificates
• Peer Server Account information
• Login Module settings
• Software Center map files
• Licence data
• Core client Registry
• System Identity Account configuration
• Cisco.com User Configuration
• Proxy User configuration
• Database. Jobs and Resources data, DCR data, Groups data, and other data
stored in the database

78-16571-01 3-57
Restoring Data
Restoring Data
The new restore framework supports restore across versions. This enables you to
restore data from versions 2.1, and 2.2, in addition to Common Services 3.0.
The restore framework checks the version of the archive. If the archive is of
current version, then the restore from current version is executed. If the backup
archive is from older version, then the backup data is converted to Common
Services 3.0 format, if needed, and applied to the machine.
You can restore your database by running a script from the command line.
While restoring data, CiscoWorks is shut down and restarted.
In all backup restore scenarios, a back up is taken from a machine A, and the
backed up data, say Ab, is restored on the same machine A, or on a different
machine B.
Ensure that you do not run any critical tasks during data restoration. Otherwise,
you may lose the data for such tasks.
Note If you restore the database when CiscoWorks Server is SSL enabled, the backed
up Server Certificate and Private Key will also be restored. Your existing
Certificate and Private Key will be overwritten.
For details on effect of restore operation on DCR modes, and Groups, see Effects
of Backup-Restore on DCR and Effects of Backup-Restore on Groups.
Caution Restoring the database from a backup permanently replaces your database with
the backed up version.

3-58 78-16571-01
Restoring Data
Restoring Data on UNIX

To restore the data on UNIX:
Step 1 Log in as the superuser, and enter the root password.

Step 2 Stop all processes by entering:
/etc/init.d/dmgtd stop
Step 3 Restore the database by entering:

$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl [-t temporary
directory] [-gen generationNumber] [-d backup directory] [-h]
where NMSROOT is the CiscoWorks installation directory and,
• [-t temporary directory]—The restore framework uses a temporary directory
to extract the content of backup archive. By default the temporary directory
is created under NMSROOT as NMROOT/ tempBackupData. You can
customize this, by using this –t option, where you can specify your own temp
directory. This is to avoid overloading NMSROOT
• [-gen generationNumber]—Optional. By default, it is the latest generation.
If generations 1 through 5 exist, then 5 will be the latest.
• [-d backup directory]—Required. Which backup directory to use.
• [-h]—Provides help. When used with -d <backup directory> syntax, shows
correct syntax along with available suites and generations.
Step 4 To restore the most recent version, enter:
$NMSROOT/bin/perl $NMSROOT/bin/restorebackup.pl -d backup
directory
For example, -d /var/backup
Step 5 Examine the log file in the following location to verify that the database was
restored by entering:
/var/adm/CSCOpx/log/restorebackup.log
Step 6 Restart the system:

/etc/init.d/dmgtd start

78-16571-01 3-59
Restoring Data
Restoring Data on Windows

To restore the data on Windows:
Make sure you have the correct permissions.
At the command line:

net stop crmdmgtd
Step 2 Restore the database by entering:

NMSROOT\bin\perl NMSROOT\bin\restorebackup.pl [-t temporary directory]
[-gen generationNumber] [-d backup directory] [-h]
where NMSROOT is the CiscoWorks installation directory. See the previous

section for command option descriptions.
Step 3 To restore the most recent version, enter the following command:
NMSROOT\bin\restorebackup.pl -d backup directory
For example, -d drive:\var\backup\
Step 4 Examine the log file in the following location to verify that the database was
restored by entering:
NMSROOT\log\restorebackup.log
Step 5 Restart the system by entering:

net start crmdmgtd
While restoring using a backup taken from a machine that is in ACS mode, the
machine on which data is restored needs to be added as a client in ACS. Contact
ACS administrator to add the restored machine as ACS client. See also, “Setting
the Login Module to ACS” section on page 3-35.

3-60 78-16571-01
Restoring Data
Data Restored from Common Services 3.0 Backup Archive

The following data will be restored from a Common Services 3.0 backup archive:
• CiscoWorks User information.
• Single Sign-on configuration.
• Device and Credential Repository (DCR) configuration.
• Peer certificates.
• Self Signed certificate (based on your confirmation).
• Peer Server Account information.
• Login Module settings.
• Software Center map files (Will not overwrite existing data).
• Application and Link registrations.
• Log backup configuration.
• Licence data (Will not be restored. But will compare and display a warning
and ask for confirmation to continue, if licenses are different).
• ACS credentials.
• System Identity Account configuration.
• Cisco.com User Configuration.
• Proxy User configuration.
• Database. Jobs data, DCR data, Groups data, and other data stored in the
database.

78-16571-01 3-61
Restoring Data
Data Restored from Common Services 2.2 Backup Archive

The following data will be restored from Common Services 2.2 backup archive:
• CiscoWorks user information.
• Management Connection data.
• Database. Jobs data, and other data stored in database.
Though Common Services 2.2 supports ACS login module, restoring from a
Common Services 2.2 backup archive will not restore the ACS login module.
After restore, the login module of the machine will be non-ACS, TACACS+.
Data Restored from CD One 5th Edition Backup Archive

The following data will be restored from CiscoWorks2000 Server (CD One 5th
edition) backup archive:
• CiscoWorks user information.
• Database. Jobs data, and other data stored in the database.

3-62 78-16571-01
Effects of Backup-Restore on DCR

Data changes are a normal part of any restore from a backup. However, because
Device and Credential Repository (DCR) is a distributed system with varying
modes, it is also possible for any restored DCR to:
• Change modes.
For example, a Standalone DCR can be set after a backup to act as a Slave.
When the restore is performed, it will be reset to Standalone mode. It depends
on source machine’s DCR mode where backup was taken, and on the target
machine’s DCR mode on which the data was restored.
• Change master/slave relationships.
For example, a DCR Slave may be using Master A at the time a backup is
taken. Later, the domain may be changed to use Master B, and the Slave reset
to use Master B. When the restore is performed, the Slave will attempt to use
Master A.
For detailed information on DCR, see Chapter 4, “Managing Device and
Credentials”.
The following scenarios helps you understand the implications of Restore
operations on DCR.
Restoring data from a DCR Standalone

If you restore the data backed up from a machine in Standalone mode, on any
machine whose working mode is either Standalone, Master, or Slave, the end
mode will be Standalone.
Let X be a machine in standalone mode.
If you restore the data backed up from X, say Xb, on another Standalone machine
Y, or a Slave S, or a Master M, the end mode of Y, S, and M will be Standalone.
Also, any slave of M will switch to Standalone mode.
Further scenarios can be better explained based on the following DCR set up.
Let us assume there are two DCR domains.
• For Domain 1, you have M1 as Master, and S1, and S2 as Slaves.
• For Domain 2, you have M2 as Master, and S3, and S4 as Slaves.

78-16571-01 3-63
Restoring data from S1 on S1

Suppose you take a backup from S1. After sometime, you restore the backed up
data, say S1b, on S1. S1 will look for its Master M1, and the Master-Slave relation
between S1 and M1 will be intact, since M1 is available.
However, note that the restore on S1 will practically be of no effect since S1 and
M1 will synchronize after the restore on S1. The changes that have taken place
after the backup was taken from S1 will be reflected in S1, even if S1b is restored
on S1.
In the above example, if the restore on S1 is performed when Master M1 is down,
or has crashed, the end mode of S1 will be Standalone. This is because S1 will try
to contact M1, and will fail because M1 is down.
Restoring Data From S1 to M1

Suppose you take a backup from S1 and restore the backed up data, say S1b, on
M1. M1 will switch to Standalone mode because, after backup, it will not be able
to find a Master. S1 will also switch to Standalone mode.
At the time of backup, if there were 1000 devices in M1, the Slave S1 would also
have 1000 devices. Say more devices are added to M1 after the Backup. S1 will
have the up-to-date device list. But after restore on M1, M1 will have only 1000
devices. In other words, the data on S1 will be more recent than that on M1.
Restoring Data from S1 on M2

Suppose you take a backup from S1 and restore the backed up data, say S1b, on
M2, which is the master in the DCR Domain 2 in our example.
After the restore, the end mode of M2 will be Slave. That is, M2 will become a
slave of M1. Also, S3, and S4, which were slaves of M2, will switch to Standalone
mode.
Restoring Data From M1 on M1

Suppose you take a back up from M1. After the backup you would be performing
several operations that would bring about changes in the Master and the
corresponding Slaves; M1, S1, and S2 in our example.

3-64 78-16571-01
Now, say you restore the backed up data M1b, on M1 itself. The Master M1 will
now have data that is older than that in the Slaves, S1, and S2. In other words, the
Slaves will be having more recent data than that on the Master.
To avoid this, you must perform the restore operation in the following sequence:
Step 1 Back up data from the slaves, S1 and S2.

Step 2 Backup data from the Master, M1.
This is to ensure that the data backed up from M1 is more recent than the data
backed up from S1 and S2.
Step 3 Stop Daemon Manager on all three machines.
Step 4 Restore data on the Master, M1.
Step 5 Restart Daemon Manager on M1.
Step 6 After the Master is up and stable, restore data on S1, and S2.
Step 7 Restart Daemon Manager on S1, and S2.
This ensures that Master has more recent data than the Slaves.
Note To avoid disturbances to Master- Salve relationship, and to maintain consistency,

it is better to take a back up of all the machines at the same time.
Restoring Data From M1 to M2

Suppose you take a backup from M1, and restore the backed up data, say M1b, on
M2.
S3, and S4 which were slaves of M2, will switch to Standalone mode.

78-16571-01 3-65
Master -Slave Configuration Prerequisites and Restore Operations

DCR Master Slave setup requires you to perform certain tasks prior to
Master-Slave configuration, to enable proper, and secure communication between
them. This involves copying certificates, and setting up a valid system identity
user. For details, see “Master-Slave Configuration Prerequisites” section on
page 4-27.
Restore operations can affect Master-Slave relationships because it may modify
these pre-configured parameters.
For example, let M1 be the Master, and S1 its Slave. Let X be a standalone server.
Suppose you take a backup from S1, and restore the backed up data, say S1b on X.
Now, X has to be in Slave mode.
Since, M1 and S1 already shared a Master -Slave relationship, M1 will have the
peer certificate of S1, and S1 will have the certificate of M1.
After the restore operation, X will get the certificate of M1. However, if peer
certificate of X is not present on M1, X will not be able to have M1 as its Master.
So you have to ensure that the certificates of the peer machines are in place, before
you do a restore.
Other Master-Slave configuration prerequisites such as System Identity user
configuration and Peer Server Account user configuration might get affected by
restore operations.
For example: In M1 you have Joe as a Peer Server User and in S1 you add Joe as
a System Identity user. You take a backup from S1.
After you take the backup, say you change the Peer Server User and System
Identity User to Bob.
Now if you restore the backed up data, say S1b the system Identity User would
not be the Bob anymore. This will upset the Master-Slave relationship.
During restore you are prompted to confirm whether you need to overwrite the
SSL certificate.
SSL certificates are tied to individual machines. So if you take a backup on one
machine and restore it on another, you should be careful not to overwrite the SSL
certificate.
However, if you backup data from a machine and restore it to the same machine,
you may overwrite the SSL certificate.

3-66 78-16571-01
Effects of Backup-Restore on Groups
Effects of Backup-Restore on Groups

Backup- Restore operations have an implication on the way Groups will be
displayed in the Common Services (CS) UI. The changes in Groups behavior is
discussed in relation with the Device and Credential Repository (DCR) mode
changes explained in the above section.
If you perform a backup on machine A and restore the backed up data, say Ab, on
the same machine, the system defined groups, and the user defined groups created
after the data backup will be removed.
Restoring data from a DCR Standalone

The following scenarios have to be considered:
• Restore data from a Standalone machine A to another Standalone machine B:
The provider group name will change accordingly. That is, the provider group
CS @A will become CS@B.
• Restore data from a Standalone machine A to a Master M:
The Master will switch to Standalone mode. The provider group name will be
updated accordingly. The Slave groups will be removed from the Master.
Only the groups pertaining to Common Services and the applications
installed in the Standalone machine will be visible. All dependent Slaves of
M will become Standalone.
• Restore data from a Standalone machine A to a Slave S:
The Slave will switch to Standalone mode. The provider group name is
updated accordingly. The groups pertaining to other Slaves in the domain,
and the Master of S, will be removed from S. The groups UI will be enabled.
The subsequent sections are based on the scenarios discussed in the “Effects of
Backup-Restore on DCR” section on page 3-63.
Restoring data from S1 on S1

No impact on CS groups.
There may be applications installed on S1. Say you create 10 groups in the
Applications before you backup data from S1. After backup, say you create 10
more groups in the Applications. On restore, the 10 groups you created after
backup will not be present. This propagates to other Slaves in the domain also.

78-16571-01 3-67
Licensing CiscoWorks Applications

After restore, both S1 and M1 will switch to Standalone mode. Both will have
only those groups pertaining to Common Services and Applications installed on
the individual machines. Groups UI is enabled on S1. Also, the other slaves of M1
will switch to Standalone mode.

After restore, M2 will become Slave of M1. The Groups UI in M2 will be
disabled. M2 will pickup all the groups from M1. Groups in M2 will be
propagated to other Slaves in the domain. All the slaves of M2 (before restore)
will now switch to Standalone mode.
Restoring Data from M1 on M2

Slaves of M2, that is S3 and S4, will switch to Standalone mode. Groups
pertaining to S3 and S4 will be deleted from M2.
In all the cases the System Defined Groups, and the User Defined Groups, are
carried over and updated in the target machine.

You must register your software and obtain a product license before you start
using an application. You can obtain a product license and license your
application, view details of your current software license, or update to a new
license from the Licensing page.
Obtaining a License for CiscoWorks Applications

To obtain a product license for your CiscoWorks applications, register your
software at one of the following websites. You will need to provide the Product
Authorization Key (PAK), which is printed on a label affixed to the Bundle
sub-box.

3-68 78-16571-01
If you are a registered user of Cisco.com, use this website:

http://www.cisco.com/go/license
If you are not a registered user of Cisco.com, use this website:
http://www.cisco.com/go/license/public
The product license will be sent to the e-mail address you provide during
registration.
Retain this license with your CiscoWorks software records.
Licensing the Application

After you obtain the product license, perform these steps to license your software:
Step 1 Copy the new license file to the CiscoWorks Server, with read permission for
casuser/casusers.
Step 2 Select Common Services > Server> Admin > Licensing.
The License Information dialog box appears. The License Information page
displays the name, version, device limit, status and expiration date of the license.
Step 4 Enter the path to the new license file in the License field, or click Browse to locate
the new file.
Step 5 Click OK.
The system verifies whether the license file is valid, and updates the license. The
updated licensing information appears in the License Information page.
Otherwise an error message is displayed.

78-16571-01 3-69
Viewing License Information

To view details of your current software license select
Common Services > Server > Admin > Licensing.
The License Information page appears. The license name, license version, size
(device limit for the licensed application), status of the license, and the expiration
date of the license appear under License Information.
Updating Licenses
You can view details of your current software license, or update to a new license
from the License page.
To update to a new license from the Licensing page:
Licensing.
The License Information page displays the license name, license version, status
of the license, and the expiration date of the license.
Step 3 Enter the path to the new license file in the License field, or click Browse to locate
the new file.
Step 4 Click OK.
The system verifies whether the license file is valid, and updates the license. The
updated licensing information appears in the License Information page.
Otherwise, an error message is displayed.

3-70 78-16571-01
Collecting Server Information
Collecting Server Information

This feature helps you to get information about the server. It provides system
information, environment, configuration, logs, and web server information. This
information can be used for trouble shooting.
To collect server information:
Collect Server Information.
The Collect Server Information page appears.
Step 2 Click Create to collect the current server information.
The Collect Server Information pop-up dialog box appears with a list of options.
Step 3 Select the check boxes corresponding to the options you need, and click OK.
By default all the check boxes are selected.
Step 4 Click Server Information at the date time link.
The pop-up window displays the server information collected.
Step 5 View server information by clicking the corresponding link in the Table of
Contents.
To delete a Collect Server Information report, select the corresponding check box,
and click Delete.
You can also generate this information using CLI.

Enter the following command:
• On Windows:
NMSROOT\bin\collect.info
• On Solaris:
$NMSROOT/bin/collect.info
where NMSROOT and $NMSROOT are the directories where you installed
CiscoWorks, in Windows, and Solaris respectively.

78-16571-01 3-71
Collecting Self Test Information
Collecting Self Test Information

You can view self test reports using this option. Selftest feature helps to test
certain basic functions of the server.
Step 1 Select Common Services > Server > Admin > Selftest.
Step 2 Click Create to perform a self test and view the report.
Step 3 Click the Self Test Information at date time link.
A pop-up window displays the selftest information report.
To delete a Self Test Information report, select the check box and click Delete.
Messaging Online Users

You can use the Notify User feature in Common Services to broadcast messages
to online users. You can post messages to users with active CiscoWorks browsers.
The message will be received within 60 seconds.
To send a broadcast message:
Step 1 Select Common Services > Server > Admin > Notify Users.
The Logged in Users dialog box lists all the users currently logged in.
Step 2 Enter the message in the Message field and click Send.
The Status field displays the status of the message.
Note If you are using Microsoft Internet Explorer, make sure your browser is set to
check for updates on every visit to the page.

3-72 78-16571-01
Managing Jobs
Managing Jobs
Common Services provides a Job Browser for managing jobs. From the Job
browser you can view a listing of jobs, view details of each job, stop a job, and
also delete a job from the list.
Users in Help Desk, Approver, and Network Operator roles are not allowed to
stop and delete jobs.
All users (including Help Desk) can access the Job browser page. The Refresh
button in Job browser is available for all users.
Note When you are using the ACS login module, the System Identity User you
configure should have all the Job management related tasks enabled. The
job_browser, job_stop, and, job_delete tasks should be enabled.
To view the list of jobs:
Job Browser.
The Job Browser page appears.

78-16571-01 3-73
Managing Jobs
Item Description
Job ID Unique number assigned to this task at creation time.
This number is never reused. There are two formats:
• Job ID:
Identifies the task. This does not maintain a
history. For Example:
1001
• JobID.Instance ID:
Here, in addition to the task, the instance of the
task can also be identified. For Example:
1001.1, 1001.2
Type String that identifies the job type (SWIM, Config,

etc) and job subtypes. For example, SWIM:update.
Run Status Job states including:
• Running
• Removed
• Waiting for approval
• Scheduled (pending)
• Rescheduled
• Completed succeeded
• Failed
• Crashed
• Cancelled
• Rejected
• ERROR.
The start time, and end time of the task are also
shown.

3-74 78-16571-01
Managing Jobs
Item Description
Sched Type How often this job will run. This can be:
• Run immediately
• Run once
• Run on a calendar basis (periodic)
• Run on a time-start basis
• Run on a time-stop basis.
For time zone abbreviations and GMT offsets, see
your Release Notes.
Description Text string that describes the job.
Run Schedule Date and time the job was scheduled.
Status Current status of the job.
To view Job details:
Job Browser.
Step 2 In the Job Browser page, click Job ID.
The Job Details popup displays the job details.

78-16571-01 3-75
Managing Resources
To stop a Job:
Step 1 In the CiscoWorks HomePage, select Common Services > Server > Admin >
Job Browser.
Step 2 Select the check box corresponding to the Job you want to stop.
Step 3 Click Stop.
Normal jobs when stopped, prompt you to confirm whether the job needs to be
stopped or not.
However, when you stop jobs that have several instances, you are prompted to
specify whether you need to stop the current instance of the job alone, or the
current instance and all the future instances as well.
You can stop only one job at a time.
To delete a job, click Delete, after selecting the desired check box.
You can delete multiple jobs at a time. You cannot delete a running job.
All users (except Help Desk) can perform Stop and Delete operations in the job
browser.
Managing Resources
Common Services provides a Resource Browser for managing resources. You can
free locked resources, when necessary, if you have appropriate privileges. All
users (including those with Help Desk role alone) can access the Resource
browser page. The Refresh button in the Resource browser is available for all
users.
Note When you are using the ACS login module, the System Identity user you
configure should have all the Resource management related tasks enabled. The
resource_browser and free_resource tasks should be enabled.

3-76 78-16571-01
Managing Resources
To view Resource details:
Resource Browser.
The Resource Browser page displays the following details:
Item Description
Resource Name of the resource currently locked.
Job ID / Owner Number assigned to this task at creation time.
Identifies all related locked resources, and user
who locked the resource.
Time Locked Time this lock was established.
Expire Time Lock expiration time.
To free locked resources:
Resource Browser.
The Resource Browser page appears.
Step 2 Select the check box corresponding to the Job ID.
Step 3 Click Free Resources.
All users (except those with only Help Desk role) can perform the Free Resource
operation in the Resource browser.
To view updated resources, click Refresh.

78-16571-01 3-77
Maintaining Log Files

Log files can grow and fill up disk space. CiscoWorks includes a script that
enables you to control this growth.
Files maintained by this script include the following log files:
• Daemon manager
• Web server log files
Most log files are located in directories in the PX_LOGDIR directory.
On UNIX systems, this directory is /var/adm/CSCOpx/log and on Windows, it
is NMSROOT\log.
Caution As part of the file back-up procedure, CiscoWorks Daemon Manager is shut down
and restarted. To prevent loss of data, make sure you are not running any
critical tasks.
The following section provides information on maintaining log files n Unix, and
Windows:
• Maintaining Log Files on UNIX
• Maintaining Log Files on Windows
Maintaining Log Files on UNIX

To maintain log files on UNIX:
Step 1 Make sure the new location has sufficient disk space.
Step 2 Log in as the superuser, and enter the root password.
Step 3 Stop all processes, and enter /etc/init.d/dmgtd stop

3-78 78-16571-01
Step 4 Perform log maintenance by entering:

$NMSROOT/bin/perl $NMSROOT/cgi-bin/admin/logBackup.pl
[-force][-dir destination directory ]
where $NMSROOT is the CiscoWorks installation directory, [-force] allows

backup regardless of log file size, and [-dir destination directory] specifies the
full path of the destination directory.
The target directory must be owned by user casuser and group casusers. The user
must have read, write, and execute permissions, and the group must have at least
read permission.
Otherwise, the program will terminate with an error message, and the log files
will not be updated.
Without any options, the script backs up the log files to the default directory,
PX_LOGDIR/backup.
Step 5 Verify the procedure was successful by examining the contents of the log files in
this location:
/var/adm/CSCOpx/log/*.log
Only log files that reach 90% of their size limits are backed up, and the original
log file is emptied.
Step 6 Restart the system, and enter /etc/init.d/dmgtd start
Step 7 Select Server > Reports > Log File Status to view your log changes.

78-16571-01 3-79
Maintaining Log Files on Windows

To maintain log files on Windows:
Step 1 Make sure the new location has sufficient disk space.
Step 2 At the command line, make sure you have the correct permissions.
net stop crmdmgtd
Step 4 Perform log maintenance by entering:
NMSROOT\bin\perl NMSROOT\cgi-bin\admin\logBackup.pl
destination directory]
[-force][-dir
where NMSROOT is the CiscoWorks installation directory, [-force] allows

backup regardless of log file size, and -[-dir destination directory] specifies the
full path of the destination directory.
If there is a problem, the program will terminate with an error message, and the
log files will not be updated.
Step 5 Verify the procedure was successful by examining the contents of the log files in
the following location:
NMSROOT\log\
Only log files that reach 90% of their size limits are backed up, and the original
log file is emptied.
Step 6 Restart the system by entering:
net start crmdmgtd
Step 7 Select Server > Reports > Log File Status to view your log changes.

3-80 78-16571-01
Using Logrot
The logrot utility helps you manage the log files in a better fashion.
Logrot is a log rotation program that can:
• Rotate log when CiscoWorks is running.
• Optionally archive and compress rotated logs.
• Rotate log only when it has reached a particular size.
Logrot helps you add new files easily. Logrot should be installed on the same
machine where you have installed Common Services.
Configuring Logrot
To configure logrot:
Step 1 Enter NMSROOT\bin\perl.exe NMSROOT\bin\logrot.pl -c (On Windows)

Run /opt/CSCOpx/bin/logrot.pl -c (On UNIX)
The logrot configuration menu appears. You have the following options:
1. Edit variables.
2. Edit log files.
3. Quit and save changes.
4. Quit without saving change.
Step 2 Select Edit variables option to set your Backup Directory.
If you do not set a backup directory, each log will be rotated in its current
directory.
Step 3 Select Edit log files option to add log files you wish logrot to rotate.
You can specify log files using fully-qualified or relative paths. If a relative path
is specified, and the log file does not exist in that path, the default log file path for
your operating system will be added during rotation (for example,
/var/adm/CSCOpx/log on UNIX).
Step 4 Specify the number of archive revisions. If you do not want to keep any archives,
enter 0 (the default) for this option.

78-16571-01 3-81
Step 5 Specify the maximum file size. The log will not be rotated until this size is
reached. The unit is in kilobytes (KB). The default is 1024 KB or 1 MB.
Step 6 Specify the file compression type to be used. It can be:
• Z—UNIX
• gz—GNU gzip (available by default on Windows only)
• bz2—bzip2 (available by default on Solaris8 and above only).
When deleting logfiles, you can choose to delete an individual file, a list of files,
or a all files matching a certain pattern.
For example, 1-3 means delete files numbered 1 through 3. a list of
comma-separated file numbers, for example, 1,21, means delete files numbered 1
and 21. A pattern string *.log means delete all files that match the pattern *.log.
You can also specify the special pattern, *, which means delete all logfiles in the
configuration.
Running Logrot
To run Logrot enter either of the following:
On Windows:
Enter NMSROOT\bin\perl.exe NMSROOT\bin\logrot.pl
On Unix:
Run /opt/CSCOpx/bin/logrot.pl
You can schedule log rotation so that the utility works on a specified time and day.

3-82 78-16571-01
Modifying System Preferences
The following command line flags are accepted:

• -v options to get verbose messages.
• -s option shuts down dmgtd before rotating logs.
The Restart Delay variable controls the waiting duration (in seconds) before
proceeding, after dmgtd is shutdown. This option is only used if the -s
argument is given to logrot. The default delay is 60 seconds.
• -c option reruns the configuration tool.

You can configure system-wide information on the CiscoWorks Server using the
System Preferences option. It is a way to centrally locate information that is used
by CiscoWorks applications.
Field Description
SMTP Server System-wide name of the SMTP server used by
CiscoWorks applications to deliver reports. The default
server name is localhost.
CiscoWorks The CiscoWorks E-mail ID from which applications send
E-mail ID mail. There is no default E-mail ID.
RCP User Name used by network device when it connects to
CiscoWorks Server to run rcp. User account must exist on
UNIX systems, and should also be configured on devices as
local user in the ip rcmd configuration command. The
default RCP username is cwuser.

78-16571-01 3-83
To edit system preferences,
Step 1 Select Common Services > Server > Admin > System Preferences.
The System Preferences dialog box appears.
Step 2 Select one of the following tabs to enter information or to verify that the
configured information is correct:
• HTTP Proxy
• SMTP Server
• CiscoWorks E-mail ID
• RCP User
Set this information carefully. If you introduce errors, users may not be able to
log in.
Step 3 Click Apply after making the changes.
To apply the defaults already configured in the system, click Defaults.
To cancel the changes, click Cancel.

3-84 78-16571-01
C H A P T E R 4
Managing Device and Credentials
The Device and Credential Repository (DCR) is a common repository of devices,

their attributes, and credentials, meant to be used by various network management
applications. The Device and Credential Admin (DCA) provides an interface to
administer DCR.
DCR helps multiple applications share device lists and credentials using a
client-server mechanism, with secured storage and communications. The
applications can read or retrieve the information. The applications can also update
the information in DCR so that the updated information could be shared with
other applications.
DCR provides:
• A central place where you can add or import new devices.
• Easier and faster access to device and credential data.
• Secure data persistence, access and transport.
• Rationalized and controlled replication, with less user-level data
reconciliation.
• Better integration with third-party and Cisco network-management
applications.

78-16571-01 4-1
Chapter 4 Managing Device and Credentials
DCR also:
• Stores device attributes and credentials, permits dynamic creation of attribute
types, and permits default grouping and filtering.
• Supports proxy device attributes, unreachable devices, and pre-provisioning
of devices.
• Allows you to populate the repository via import from many sources, and to
export device data for use with third-party network management systems such
as HP Network Node Manager and Netview.
• Uses a unique Internal Device Identifier to access device details, and detects
duplicate devices based on specific attributes.
• Encrypts credential data stored in the repository. Access to device data is
permitted only by secured channel and client authentication.
• Supports IPv6 and SNMP v3.
Credentials are values that are used by applications to access and operate on
devices. It is typically an SNMP community string or a user ID and password pair.
A device credential is used to access a managed device such as a switch or router
Device attributes are unique to each device and they identify a device. The
following attributes are stored in the repository:
Table 4-1 Attributes and Description
Attribute Description
host_name Device Host name
domain_name Domain name of the device
management_ip_address IP address used to access the device. Both IPv4 and
IPv6 address types are supported.
device_identity Identifies pre-provisioning devices. The value would
be application specific.
display_name Device name, as you want it to be represented in
reports or graphical displays. Can be derived from
Host Name, Management IP address or Device
Identity.

4-2 78-16571-01
Table 4-1 Attributes and Description (continued)
sysObjectID sysObjectID value. It may be UNKNOWN in the
case the facility that is populating the repository
does not know the value.
mdf_type Normative name for the device type as described in
Cisco’s Meta Data Framework (MDF) database.
Each device type has a unique normative name
defined in MDF.
DCR Device ID Internally generated unique sequential number that
identifies the device record in the DCR database.
The DCR clients should remember the value to
access device details from the repository.
User Defined Fields DCA, by default, provides four user defined fields.
These fields are used to store additional user-defined
data for a device. You can add more User Defined
fields.
The mandatory attributes are:

• Management IP address or Host Name or Device Identity.
• Display Name.
Individual applications interact with the repository to get the device list, device
attributes, and device credentials.
The following credentials can be associated with a device in DCR:
Table 4-2 Credentials and Description
Credential Description
Standard Credentials
primary_username Primary user name used to access the device.
primary_password Password for the primary_username.

78-16571-01 4-3
Table 4-2 Credentials and Description (continued)
Credential Description
primary_enable_password Console-enabled password for the device. Allows you to make
configuration changes and provides access to a larger set of
commands.
Without the enable password, users are restricted to read-only
operations.
snmp_v2_ro_comm_string Device’s SNMP V2 read-only community string.
snmp_v2_rw_comm_string Device’s SNMP V2 read/write community string.
snmp_v3_user_id Device’s SNMP V3 user ID.
snmp_v3_password Device’s SNMP V3 password.
snmp_v3_engine_ID Device’s SNMP V3 engine ID.
snmp_v3_auth_algorithm SNMP V3 authorization algorithm used on the device. Can be
MD5 or SHA-1.
http_username Device’s HTTP-interface user ID.
http_password Device’s HTTP-interface password.
Additional Credentials for Cluster Managed Devices
dsbu_member_number Number of the Cluster member. This number represents the order
in which the device was added to the cluster.
parent_dsbu_id DCR Device ID of the parent Cluster device.
Auto Update Server Specific Credentials
aus_url URL for the AUS device.
aus_port Port number of the AUS service running on the AUS device.
aus_username User login providing access to the AUS device.
aus_password Password for the corresponding aus_username.
Auto Update Server Managed Device -Specific Credentials
aus_username User login providing access to the AUS-managed device.
aus_password Password for the corresponding aus_username.
parent_aus_id DCR Device ID of the managing AUS device.

4-4 78-16571-01
DCR Architecture
DCR supports Cisco Cluster Management Suites, Auto Update Servers and the
managed devices using a mix of standard and additional attributes and credentials.
• Clusters: All the attributes of the Cluster are the same as a normal DCR
device.
• Cluster Members: Each cluster member has its own Host Name, sysObjectID,
and MDF type, and uses the same Telnet credentials as the Cluster. Each
cluster member has the following additional attributes:
– Member Number: The number of the Cluster member. This number
represents the order in which the device is added into the cluster.
– Device ID of the parent Cluster record.
• Auto Update Server: The Auto Update Server has the following attributes and
credentials:
– URN
– Username
– Password
• Auto Update Server managed devices: Apart from having its own attributes
and credentials like normal DCR devices in DCR, each Auto Update Server
managed device has the following additional attributes:
– Device Identity: The string value that uniquely identifies this device in
the parent Auto Update Server.
– The DCR Device ID of the parent Auto Update Server record.
DCR Architecture
The sharing of device list and credentials among various network management
products is achieved through a Client-Server mechanism. The clients are network
management applications that use DCR. The server is called the DCR Server.
DCR works based on a Master-Slave model. DCR Server can also be in
Standalone mode.

78-16571-01 4-5
DCR Architecture
Master DCR
The Master DCR server refers to the master repository of device list and
credential data. The Master hosts the authoritative, or a master-list of all devices
and their credentials. All other DCRs in the same management domain which are
running in Slave mode normally shares this list.
There is only one Master repository for each management domain, and it contains
the most up-to-date device list and credentials.
Slave DCR
The Slave DCR refers to a repository that is an exact replica of the Master.
DCR Slaves are slave instance of DCR in other servers and provide transparent
access to applications installed in those servers.
Any change to the repository data occurs first in the Master, and those changes are
propagated to multiple Slaves. There can be more than one Slave in a management
domain.
The Slave:
• Maintains an exact replica of the data managed by the Master for the
management domain.
• Has a mechanism to keep itself in sync with the Master.
• Will first update Master and then update its own repository data. This is in
case of repository data updates.
Standalone DCR
In Standalone mode, DCR maintains an independent repository of device list and
credential data. It does not participate in a management domain and its data is not
shared with any other DCR. It does not communicate with or contain registration
information about any other Master, Slave, or Standalone DCR.
DCR running in Master or Slave mode always has an associated DCR Group ID
that indicates the Server's management domain. This Group ID is generated when
a DCR is set to Master mode, and communicated to all Slaves later assigned to
that Master.

4-6 78-16571-01
Using the Device and Credential Admin
Using the Device and Credential Admin

Device and Credential Admin (DCA) helps you in:
• Managing Devices
• Generating Reports in DCA
• Managing Auto Update Servers
• Administering Device and Credential Repository
Managing Devices
The Device Management option in DCA helps you manage the list of devices and
their credentials. Device Management helps you in:
• Adding Devices
• Deleting Devices
• Editing Device Credentials
• Importing Devices and Credentials
• Exporting Devices and Credentials
• Excluding Devices
• Viewing Devices List
To perform any of these management functions, select:
Common Services > Device and Credentials > Device Management.

78-16571-01 4-7
Managing Devices
Adding Devices
You can use this feature to add devices, device properties or attributes, and device
credentials to the DCA.
To add devices to the device list:
Step 1 In the CiscoWorks Homepage, select Common Services > Device and
Credentials > Device Management.
The Device Management page appears.
The Device Management UI helps you perform operations on Standard Devices,
Cluster Managed devices and Auto Update devices. Operations on Auto Update
Servers can be performed only at the Auto Update Server Management UI.
The Device Summary window displays the devices and groups in DCA.
Step 2 Click Add.
The Device Properties page appears. The Device Information dialog box provides
three device management types:
• Standard Type
• Auto Update Type
• Cluster Managed Type

4-8 78-16571-01
Managing Devices
Standard Type
You can add Routers, Switches, Hubs, and other devices using the Standard
management type.
To add devices and credentials using Standard type:
Step 1 Select the Standard radio button.

Step 2 Enter the Device IP address, the host name, domain name, the device display
name, and the device type in the corresponding fields.
To select the Domain Name and the DeviceType, click Select and choose from the
list.
DCR uses a device record to represent a Cluster. A Cluster can be added in the
Standard Management option by selecting the Device Type field as Cisco Cluster
Management Suite.
DSBU Clusters added this way, can then be selected in Cluster Managed Type,
for the field Cluster.
Step 3 Click Add to List
The device is added to the Added Device List in the window.
To remove the device from the Device List, select the device and click
Remove from List.
Step 4 Click Next.
The Standard Credentials page appears.
Step 5 Enter the credentials in the Add Credential Template. The following credentials
can be added:
• Primary Credentials (Username, Password, Enable Password)
• SNMP v2C credentials (Read-Only Community String, Read-Write
Community String)
• SNMPv3 Credentials (Username, Password, authentication Algorithm,
Engine ID)
• Rx Boot Mode Credentials (Username, Password)

78-16571-01 4-9
Managing Devices
Step 6 Click Next.

The Standard UDF dialog box appears.
Step 7 Enter your choices for User Defined Fields and click Finish.
DCA provides the option to define four attribute fields for a device. These fields
are used to store additional user-defined data for the device.
The attribute fields that appear here can be changed at Device and Credentials >
Admin > User Defined Fields.
Auto Update Type

You can use this feature to add, edit, and delete devices managed using Auto
Update Server. The CiscoWorks Auto Update Server is a web-based interface for
upgrading device configuration files and software images on firewalls that use the
auto update feature.
The Auto Update Server managed device has its own attributes and credentials
just like normal devices in DCR. In addition, it will have the following attributes:
• Device Identity: The string value that uniquely identifies the device in parent
Auto Update Server.
• The DCR Device ID of the parent Auto Update Server record.
To add devices and credentials using Auto Update type:
Step 1 Select the Auto Update radio button.

Step 2 Enter the Device Type, Display Name, Auto Update Device ID, Host Name,
Domain Name, and IP address in the corresponding fields.
To select Auto Update Server, Domain Name, and the Device Type click Select
and select from the resulting popup windows. For Auto Update Server managed
devices, Display Name and Device-Identity are enough for identity.
DCR uses a device record to represent an Auto Update Server. An Auto Update
Server can be added in the Auto Update Server Management UI. Auto Update
Server added this way can then be selected for the field Auto Update Server.

4-10 78-16571-01
Managing Devices
Step 3 Click Add to List.

The device gets added to the Added Device List in the window.
To remove the device from the Device List, select the device and click Remove
from List.
Step 4 Click Next.
The Credential Template dialog box appears.
Step 5 Enter the Auto Update Server managed device credentials (Username, Password)
in the corresponding fields and click Next.
The User Defined Fields dialog box appears.
Step 6 Enter your selections for User-defined fields and click Finish.
You can define four attribute fields for a device. These fields are used to store
additional user-defined data for a device.
Admin> User Defined Fields.
Cluster Managed Type

DCR supports Cisco Clusters and their member devices using a mix of standard
and additional attributes and credentials.
To add devices and credentials using Cluster Managed type:
Step 1 Select the Cluster Managed radio button.

Step 2 Enter Device Type, Display Name, Device IP address, Device Host Name,
Domain Name, Cluster, and Member Number in the corresponding fields. For
member devices, member number and display name are enough for identity.
The Member Number field is mandatory. The Member Number is the number of
the Cluster member. This number represents the order in which the device is
added into the cluster.
Also, Cluster needs to be added before a Cluster Managed device.
For example, if a device X belongs to cluster Y, first add the Cluster Y, and then
add the Cluster Managed device X.

78-16571-01 4-11
Managing Devices
Step 3 Click Add to List.

The device is added to the Added Device List in the window.
To remove a device from the Device List select the device and click
Remove from List.
Step 4 Click Next.
The Cluster Manager credentials dialog box appears.
Step 5 Enter the device credentials in the corresponding fields and click Next.
The User Defined Field dialog box appears.
Step 6 Enter your selections for User-defined fields and click Finish.
You can define four attribute fields for a device. These fields are used to store
additional user-defined data for the device.
Admin > User Defined Fields.
Deleting Devices
You can delete device information from DCR using this feature.
When a device is deleted, it will also get deleted in all the applications that use
DCR.
To delete devices:
Step 1 In the CiscoWorks Homepage, select Common Services >

Device and Credentials > Device Management.
Step 2 Select the device from the Device Summary dialog box and click Delete.
The device is removed from the device list. Also, all information about the
selected device will be removed from DCR.

4-12 78-16571-01
Managing Devices
Editing Device Credentials

You can edit device information using this feature.
To edit device information:
Step 2 Select one or more devices from the Device Summary List and click Edit.
The Device Properties page displays the Devices Information dialog box.
You can edit the attributes of individual devices here. The Devices column lists
all the selected devices.
From the Devices column, you should separately select each device that needs to
be edited, and make the required changes.
Step 3 Select the device for which you want to edit the device information, from the
device list.
The current attributes are automatically populated in the device information
fields.
Step 4 Edit the device information, on the right pane.
If you are done with your editing and do not want to proceed, click Finish.
Step 5 Click Next, if you want to edit device credentials.
The Credential Template dialog box appears. According to your requirement, you
can edit:
• Primary Credentials (Username, Password, Enable Password)
• SNMP v2C credentials (Read-Only Community String, Read-Write
Community String)
• SNMPv3 Credentials (Username, Password, authentication Algorithm,
Engine ID)
• Rx Boot Mode Credentials (Username, Password)
• Auto Update Server Managed Device credentials (Username, Password)
Any changes made here will apply to all devices selected in Step 2. This has one
exception.

78-16571-01 4-13
Managing Devices
If in Step 2, devices belonging to different device management types are selected,

the changes made will apply only to devices of the appropriate type. That is, if a
standard-device credential is changed, only the standard devices selected in Step
2 are affected.
If you have completed editing, and do not want to proceed, click Finish.
Step 6 Click Next, if you want to edit User Defined Fields.
The User Defined Fields dialog box appears. Make the required changes in the
user-defined fields, and click Finish.
The changes made here will apply to all devices selected in Step 2 (irrespective of
the device management type).
Auto Update Servers cannot be edited here. Even if they are selected in Step 2,
they will not be affected. See “Editing Auto Update Server” section on page 4-25
for details on editing Auto Update Server information.
Also, you cannot change the device management type using the edit flow. That is,
a standard device cannot be changed to a Cluster device.
Importing Devices and Credentials

You can import device lists, device properties or attributes and device credentials
to the DCR and populate DCR using this feature.You can:
• Import Using DCA Interface
or
• Import Using CLI

4-14 78-16571-01
Managing Devices
Import Using DCA Interface

To import devices using DCA Interface:
Step 2 Click Bulk Import.
The Import Devices popup window appears. You can import from any of the
following:
• File
• Local NMS (Network Management Station)
• Remote NMS
Importing From a File
To import from a file:
Step 1 Enter the file name.

Or,
Browse the file system and select the file using the Browse tab.
Step 2 Select CSV or XML file formats, as required.
Only CSV2.0 and CSV3.0 file formats are supported.
Step 3 Select either Use data from Import source or Use data from DCR, to resolve
conflicts during import.
• If you select Use data from Import source, the credentials from the import
source will be used, and credentials for the device in DCR will be modified.
• If you select Use data from DCR, the device credentials in DCR will be used.

78-16571-01 4-15
Managing Devices
Step 4 Schedule the task. To do this:

a. Select the RunType from the drop-down list.
You can schedule importing the devices immediately or schedule the import
for a later time. The scheduling can be periodic (daily, weekly, or monthly)
or for a single instance.
b. Select the date from the date picker.
Step 5 Enter the Job description in the Job Info field.
Step 6 Click Import.
Importing From Local NMS
To import from Local NMS:
Step 1 Select the Network Management System type from the NMS type drop-down list.
HPOV6.x and Netview7.x are supported.
Step 2 Enter the install location in the Install Location field.

4-16 78-16571-01
Managing Devices
Importing From Remote NMS
You should have permissions to log into the remote network management system
(NMS), without a password. Common Services uses remote login to log into the
Server and get device details.
The rhosts file should be modified to enable you to login without a password.
To import from a remote NMS:
Step 1 Select the Network Management System type from the NMS type drop-down list.
If you select ACS, enter:
• ACS Server Name or IP address in the Host Name field.
• ACS admin user name in the User Name field.
• ACS admin user password in the Password field.
• Port number (default is 2002) in the Port field.
Step 2 Select the Operating System type from the OS type drop-down list.
Step 3 Enter the Host name, User name, and Install location in the corresponding fields.
Step 6 Enter the Job description in the Job Information field.

78-16571-01 4-17
Managing Devices
Exporting Devices and Credentials

You can use this feature to export a list of device and their credentials into a file.
The device list can be obtained from the device selector, or from a CSV file.
You can edit the Export Format file located at
NMSROOT\objects\dcrimpexp\conf\Export_Format_CSV.xml or
Export_Format_XML.xml to specify the credentials you need to export.
To see the list of attributes that can be exported:
Step 1 At the command prompt, enter NMSROOT/bin/dcrcli -u username.

Step 2 Enter the password corresponding to the user name.
Step 3 Enter lsattr
The list of attributes and their description is displayed. You can include the
attributes you need to export, in the Export Format file.
You can:
• Export Using DCA Interface
or
• Export Using CLI

4-18 78-16571-01
Managing Devices
Export Using DCA Interface

To export device credentials using DCA Interface:
Step 2 Click Export.
The Device Export dialog box appears.
You can use either of the following device selection methods:
• Select from Device Selector
Select this option if you want to export devices from DCR to the file you
specify in the Output File Information field. You can select the required
devices from the Device Selector pane of the Device Export dialog box.
• Get Device List from File
Select this option if you want to export devices from a CSV file that is already
present in the server, to the file you specify in the Output File Information
field.
You can use this option when the CSV file contains only partial device
credentials, and you want to get the full list of credentials. The input CSV file
checks for data in DCR, and exports the data to the output file.
We recommend that you use this option to export upto a maximum of 1000
devices.
Selecting From Device Selector
To select from device selector:
Step 1 Enter the output file name.

Or
Browse the file system and select the file using the Browse tab.
Step 2 Select CSV or XML file formats, as required.

78-16571-01 4-19
Managing Devices
Step 3 From the Device Selector, select the devices for which you need to export
credentials.
You can schedule export immediately or schedule the export for a later time.
The scheduling can be periodic (daily, weekly, or monthly) or for a single
instance.
Step 6 Click OK.
Getting Device List From File
To get device list from file:
Step 1 In the Input File Selection panel, enter the input file name or select the input file
(in CSV format) to get device list from, using the Browse tab.
Step 2 In the Output File Information panel, enter the location for the output file or click
Browse to select the file you require.
Step 3 Select CSV or XML file formats radio buttons, as required.
You can schedule export immediately or schedule the export for a later time.
The scheduling can be periodic (daily, weekly, or monthly) or for a single
instance.
Step 6 Click OK.
You must populate DCR with devices before you export credentials from DCR
selecting devices from a file.

4-20 78-16571-01
Managing Devices
Excluding Devices
This feature allows you to specify a file that contains the list of the devices that
should not be added to DCR using the Add or Import operations.
During Add or Import operations, DCR makes sure that the device being added or
imported is not listed in the Exclude Device List.
A device can be excluded based on it's hostname+domainname, IP address and
device-identity fields.
To exclude devices from Add or Import operations:
Step 2 Click Exclude.
The Upload Exclude Devices File dialog box appears.
Step 3 Enter the file name or click Browse to browse the file system and select the file.
The file that needs to be uploaded must be in CSV format.
Step 4 Click Apply to upload the file.
A Sample CSV Exclude File

; This file is generated by DCR Export utility
Cisco Systems NM Data import, Source=DCR Export; Type=DCRCSV;
Version=3.0
;
;Start of section 0 - Basic Credentials
;
;HEADER:
management_ip_address,host_name,domain_name,device_identity,display_na
me,sysObjectID,dcr_device_type,mdf_type,snmp_v2_ro_comm_string,snmp_v2
_rw_comm_string,snmp_v3_user_id,snmp_v3_password,snmp_v3_engine_id,snm
p_v3_auth_algorithm,primary_username,primary_password,primary_enable_p
assword
;
,Dev1Hostname,,
10.1.0.60,,,

78-16571-01 4-21
Managing Devices
,,,AUSID1
,Dev2Hostname,cisco.com,
;
;Start of section 2 - AUS managed;
;HEADER: aus_device_identity,parent_aus_id
;
,
;End of CSV file
Viewing Devices List

You can view the devices in the Device List Report using this feature.
To view devices in the Device List Report:
Step 2 Select the devices you want from the Device Summary list and Click View.
The Device List Report dialog box appears.
Step 3 Select the device.
Step 4 Click View.

4-22 78-16571-01
Generating Reports in DCA
Generating Reports in DCA

You can use this feature to generate and view Device and Credential Admin
reports.
To generate reports:

Device and Credentials > Reports.
The Report Generator page appears.
Step 2 Select a report from the DCA Reports tree on the left panel to view a short
description, summary, or parameters of the report.
You can select any of the following reports:
• DCA Device List Report—Displays the complete device list in DCA.
• DCA Audit Report—Displays the complete device list in DCA within a
specified period of time.
• Excluded Devices Report—Displays the excluded devices list.
• Import Status Report—Displays the last imported device list.
• DCA devices that are not configured in ACS report—Displays the list of DCA
devices that need to be configured in ACS.
Step 3 Select the report link in the Available Report pane and click Generate Reports to
view the selected report.
You can export the report, or print the report.
To export the report:
Step 1 Click the Export Current Report button on top of the right hand side of the DCA
Report list.
Step 2 Select the required radio button to export the report either in pdf or in CSV format.
Step 3 Enter the number of rows to be exported and click OK.

78-16571-01 4-23
Managing Auto Update Servers

Auto Update Servers have the following credentials:
• Auto Update Server URL
• Username
• Password
Auto Update Server management feature helps you in:
• Adding Auto Update Server
• Editing Auto Update Server
• Deleting Auto Update Server
Adding Auto Update Server

To add Auto Update Server:
Credentials > Auto Update Server Management.
The Auto Update Server Management page appears.
Step 2 Click Add.
The Auto Update Server dialog box appears.
Step 3 Enter the Display Name, IP address, Host, Port, URN, User name, and password
in the corresponding fields. Re-enter the password in the Verify field.
DCR uses a device record to represent a Auto Update Server.
An Auto Update Server added in the Auto Update Server Management UI can be
selected for the field Auto Update Server when you add devices using the Auto
Update management type.
Step 4 Click OK.

4-24 78-16571-01
Editing Auto Update Server

To edit Auto Update Server:
Credentials > Auto Update Server Management.
Step 2 Select the device you want to edit from the list and click Edit.
The Auto Update Server dialog box appears.
Step 3 Edit Display Name, IP address, Port, URN, User name, and Password fields.
Step 4 Click OK.
Deleting Auto Update Server

To delete Auto Update Servers:

Device and Credentials > Auto Update Server Management.
Step 2 Select the device you want to delete from the list.

78-16571-01 4-25
Administering Device and Credential Repository

The DCA Admin feature allows you to do the following tasks:
• Changing DCR Mode
• Adding User-defined Fields
• Renaming User-defined Fields
• Deleting User-defined Fields
To perform these tasks, select CiscoWorks Homepage > Device and
Credentials > Admin. The Admin page appears with the current DCA settings.
You can change the Mode Settings or modify User Defined fields.
Changing DCR Mode

To change Mode Settings:

Device and Credentials > Admin.
The Admin page appears with the current DCA settings.
Step 2 Click the Mode Settings link.
The Mode Settings window appears.
Step 3 Click Change Mode to change the current mode.
The DCR Mode dialog box appears. You can select the required mode from this
dialog box.
• Changing the Mode to Standalone
• Changing the Mode to Master
• Changing the Mode to Slave

4-26 78-16571-01
Master-Slave Configuration Prerequisites

Before you set up the Master and Slave, you have to perform certain tasks to
ensure that secure communication takes place between the Master and Slave.
If machine M is to be the Master and S is to be the Slave:
Step 1 In M add a Peer Server User and password.

See “Setting up Peer Server Account” section on page 3-11 for details.
Step 2 In S add a System Identity user and password. This should be same as the Peer
Server User set up in M.
See “Setting up System Identity Account” section on page 3-13, for details.
Step 3 Copy the Self-Signed Certificate of S to M. Also, copy the Self-Signed Certificate
of M to S.
See “Creating Self Signed Certificate” section on page 3-9, for details on creating
Self-Signed Certificate.
See “Setting up Peer Server Certificate” section on page 3-14, for details on
copying Peer Certificate.
Step 4 Now configure S as Slave and M as Master.
Changing the Mode to Standalone
Step 1 Select the Standalone radio button.

Step 2 Click Apply to change mode.
The default DCR mode is Standalone.

78-16571-01 4-27
Changing the Mode to Master

Before you change the mode to Slave, ensure that Master-Slave Configuration
Prerequisites are in place.
Step 1 Select the Master radio button.

Step 2 Click Apply to change mode.
Changing the Mode to Slave

Before you change the mode to Slave, ensure that Master-Slave Configuration
Prerequisites are in place.
You need to perform the following tasks:
Step 1 Select the Slave radio button.

Step 2 Enter the hostname of the Master in the Master field.
Note This hostname should exactly match the Hostname field in the Master's
Self Signed Certificate.
Step 3 Specify the SSL port of the master. Default is 443.

• If the mode is changed from Master to Slave, select the Inform Current
slave(s) of new Master Hostname check box.
If you select this check box, all the slaves of the Master (whose mode you
currently changed to Slave) will be informed of the new master hostname.
That is, they will become the slaves of the new Master.
• If the Add new devices to Master check box is selected, the devices in Slave
will be added to the new Master. However, any duplicates will be discarded.
Step 4 Click Apply.

4-28 78-16571-01
Changing the hostname of a Master

Changing the hostname of a Master is equivalent to pointing Slaves to a new
Master.
When you point a Slave/Standalone to a new Master, DCR checks whether the
new Master has the same Domain ID as the current machine.
If Domain ID is the same, DCR displays an error message saying that Master
cannot be configured since the new Master has the same Domain ID.
In this case, you need to convert the Slave to Standalone, and then register the
machine with the new Master.
On re-registration, the applications on Slave will clean up the device list.
When you change the host name of the current Master, you need to change the
Slave's mode to Standalone, and then re-register the machine as a Slave by
providing the new Master hostname. However, when the machine is re-configured
as Slave, the applications will clean up the device list.
Let us say we have a Master M and Slave S. If M's hostname is changed, the Slave
S has to be made standalone. Then it has to be re-configured as Slave of M. But
when S is re-configured as Slave, the applications on S will clean up their device
lists.
Therefore, you have to be aware of the fact that while changing the hostname of
a Master, an application data is cleaned up on all Slaves.
Adding User-defined Fields

To add a user defined field:

The Admin page appears with the current settings.
Step 2 Click the User-defined Fields link.
The User-defined Fields page appears.
Step 3 Click Add to add a User-defined field.

78-16571-01 4-29
Step 4 Enter the field label and description in the corresponding fields.
Step 5 Click Apply to add the User-defined Field.
Renaming User-defined Fields

To rename a user-defined field:

Step 2 Click User-defined Fields link.
The User-defined Field dialog box appears
Step 3 Select the radio button corresponding to the User-defined Field you want to
rename.
Step 4 Click Rename.
The User-defined Field dialog box appears.
Step 5 Enter the field label and description in the corresponding fields.
Step 6 Click Apply.

4-30 78-16571-01
Sample CSV File
Deleting User-defined Fields

To delete a user-defined field:

Step 2 Click the User-defined Fields link in the TOC.
The User-defined Fields dialog box appears.
Step 3 Select a User-defined Field, then click Delete.
Sample CSV File

CSV 2.0 or CSV 3.0 file formats are supported for import.
A Sample CSV 2.0 File

;
; This file is generated by the export utility
; If you edit this file, be sure you know what you are doing
;
Cisco Systems NM data import, source = export utility; Version = 2.0;
Type = Csv
;
; Here are the columns of the table.
; Columns 1 and 2 are required.
; Columns 3 through 19 are optional.
; Col# = 1: Name (including domain or simply an IP)
; Col# = 2: RO community string
; Col# = 3: RW community string
; Col# = 4: Serial Number
; Col# = 5: User Field 1
; Col# = 9; Name = Telnet password
; Col# = 10; Name = Enable password

78-16571-01 4-31
Sample CSV File
; Col# = 11; Name = Enable secret

; Col# = 12; Name = Tacacs user
; Col# = 13; Name = Tacacs password
; Col# = 14; Name = Tacacs enable user
; Col# = 15; Name = Tacacs enable password
; Col# = 16; Name = Local user
; Col# = 17; Name = Local password
; Col# = 18; Name = Rcp user
; Col# = 19; Name = Rcp password
;
; Here are the rows of data.
;
172.20.118.156,public,,FHH080600dg,,,,,,,,,,,,,,,
172.20.118.150,public,,FHH0743W022,,,,,,,,,,,,,,,
A Sample CSV 3.0 File

Version=3.0
;
;
;HEADER:
me,sysObjectID,dcr_device_type,mdf_type,snmp_v2_ro_comm_string,snmp_v2
_rw_comm_string,user_defined_field_0,user_defined_field_1
;
10.77.202.40,Switch6009,cisco.com,,Switch2,1.3.6.1.4.1.9.1.281,0,26843
8100,public,private,field0,field1
10.77.202.10,Router7000,cisco.com,,Router1,1.3.6.1.4.1.9.1.8,0,2784644
10.77.202.30,Switch4006,cisco.com,,Switch1,1.3.6.1.4.1.9.5.46,0,268438
10.77.202.20,Router6400,cisco.com,,Router2,1.3.6.1.4.1.9.1.180,0,26921
;End of CSV file
Note For a complete list of attributes and their description, use the lsattr command
in dcrcli. See “Listing the Attributes” section on page 4-40 for usage details.

4-32 78-16571-01
Sample CSV File
Sample CSV 3.0 File for Auto Update Server Managed Devices
Version=3.0
;
;
;HEADER:
me,
sysObjectID,dcr_device_type,mdf_type,snmp_v2_ro_comm_string,snmp_v2_rw
_comm_string,
snmp_v3_user_id,snmp_v3_password,snmp_v3_engine_id,
snmp_v3_auth_algorithm,primary_username,primary_password,primary_enabl
e_password
;
1.1.1.1,ons_host1,cisco.com,AUS_ID,ONS1,1.3.6.1.4.1.9.1.406,0,27361289
2,,,,,,,,,
10.10.10.1,aus_server,cisco.com,,AUS_SERV1,UNKNOWN,3,UNKNOWN,,,,,,,,,
;
;Start of section 1 - AUS proxy
;
;HEADER:
me,aus_username,aus_password,aus_url
;
1.1.1.1,ons_host1,cisco.com,AUS_ID,ONS1,admin,admin,
10.10.10.1,aus_server,cisco.com,,AUS_SERV1,admin,admin,autoupdate/Auto
UpdateServlet
;
;Start of section 2 - AUS managed
;
;HEADER:
me,parent_aus_id
;
1.1.1.1,ons_host1,cisco.com,AUS_ID,ONS1,display_name=AUS_SERV1
;End of CSV file

78-16571-01 4-33
Sample CSV File
Sample CSV 3.0 File for Cluster Managed Devices

Version=3.0
;
;
;HEADER:
me,
sysObjectID,dcr_device_type,mdf_type,snmp_v2_ro_comm_string,snmp_v2_rw
_comm_string,
snmp_v3_user_id,snmp_v3_password,snmp_v3_engine_id,snmp_v3_auth_algori
thm,primary_username,
primary_password,primary_enable_password
;
1.1.1.1,ons_dev_1,cisco.com,,ONS1,1.3.6.1.4.1.9.1.406,0,273612892,,,,,
,,,,
10.10.10.1,host1,cisco.com,,cluster1,Unknown,1,278283831,,,,,,,,,
;
;Start of section 3 - DSBU managed
;
;HEADER:
me,
dsbu_member_number,parent_dsbu_id
;
1.1.1.1,ons_dev_1,cisco.com,,ONS1,1,display_name=cluster
;End of CSV file

4-34 78-16571-01
Sample CSV File
Mapping CSV 2.0 to CSV 3.0 Fields

The following table provides a mapping between the fields in CSV 2.0 and
CSV 3.0:
CSV 2.0 CSV 3.0

Name (including domain or host_name and display_name
simply an IP)
RO community string snmp_v2_ro_comm_string
RW community string snmp_v2_rw_comm_string
Serial Number Not used in CSV 3.0
User Field 1 user_defined_field_0
Telnet password primary_password
Enable password primary_enable_password
Enable secret primary_enable_password
Tacacs user primary_username
Tacacs password primary_password
Tacacs enable user Not used in CSV 3.0
Tacacs enable password primary_enable_password
Local user primary_username
Local password primary_password
Rcp user Not used in CSV 3.0
Rcp password Not used in CSV 3.0
Telnet password, Tacacs password, and Local password are matched to

primary_password.
The Enable password, Enable secret, and Tacacs enable password are matched to
primary_enable_password.

78-16571-01 4-35
Sample XML File
The Tacacs user and Local user are matched to primary_username.

The order of preference used to set these values in CSV 3.0:
• If Tacacs username, password, enable password are set, then these values will
be set as primary_username, primary_password and
primary_enable_password.
• If Local username and password are set, then the values will be set as
primary_username and primary_password.
• If Telnet password, Enable Password, and Enable Secret are set, then the
values will be set as primary_password, and primary_enable_password (for
both Enable Password, and Enable Secret).
Sample XML File

Sample XML File (Standard)
<?xml version="1.0"?>
<DEVICES>
<DEVICE>
<SET Name="Basic Credentials">
<DEVATTRIB
Name="management_ip_address">10.77.202.40</DEVATTRIB>
<DEVATTRIB Name="host_name">Switch6009</DEVATTRIB>
<DEVATTRIB Name="domain_name">cisco.com</DEVATTRIB>
<DEVATTRIB Name="display_name">Switch2</DEVATTRIB>
<DEVATTRIB
Name="sysObjectID">1.3.6.1.4.1.9.1.281</DEVATTRIB>
<DEVATTRIB Name="dcr_device_type">0</DEVATTRIB>
<DEVATTRIB Name="mdf_type">268438100</DEVATTRIB>
<DEVATTRIB Name="snmp_v2_ro_comm_string">public</DEVATTRIB>
<DEVATTRIB
Name="snmp_v2_rw_comm_string">private</DEVATTRIB>
<DEVATTRIB Name="primary_username">lab</DEVATTRIB>
<DEVATTRIB Name="primary_password">lab</DEVATTRIB>
<DEVATTRIB Name="primary_enable_password">lab</DEVATTRIB>
</SET>
</DEVICE>
</DEVICES>

4-36 78-16571-01
Sample XML File
Note For a complete list of attributes and their description, use the lsattr command in
dcrcli. See “Listing the Attributes” section on page 4-40 for usage details. Also,
see Attributes and Description and Credentials and Description.
Sample XML File for Auto Update Server Managed Devices

<DEVICES>
<DEVICE>
<DEVATTRIB
<DEVATTRIB Name="host_name">ons_host1</DEVATTRIB>
<DEVATTRIB Name="device_identity">AUS_ID</DEVATTRIB>
<DEVATTRIB Name="display_name">ONS1</DEVATTRIB>
<DEVATTRIB
</SET>
<SET Name="AUS proxy">
<DEVATTRIB Name="aus_username">admin</DEVATTRIB>
<DEVATTRIB Name="aus_password">admin</DEVATTRIB>
</SET>
<SET Name="AUS managed">
<DEVATTRIB Name="device_identity">AUS_ID</DEVATTRIB>
<DEVATTRIB
Name="parent_aus_id">display_name=AUS_SERV1</DEVATTRIB>
</SET>
</DEVICE>
<DEVICE>
<DEVATTRIB
<DEVATTRIB Name="host_name">aus_server</DEVATTRIB>
<DEVATTRIB Name="display_name">AUS_SERV1</DEVATTRIB>
<DEVATTRIB Name="sysObjectID">UNKNOWN</DEVATTRIB>
<DEVATTRIB Name="mdf_type">UNKNOWN</DEVATTRIB>
</SET>
<SET Name="AUS proxy">
<DEVATTRIB Name="aus_username">admin</DEVATTRIB>

78-16571-01 4-37
Sample XML File
<DEVATTRIB Name="aus_password">admin</DEVATTRIB>
<DEVATTRIB
Name="aus_url">autoupdate/AutoUpdateServlet</DEVATTRIB>
</SET>
</DEVICE>
</DEVICES>
Sample XML File for Cluster Managed Devices

<DEVICES>
<DEVICE>
<DEVATTRIB
<DEVATTRIB Name="host_name">ons_dev_1</DEVATTRIB>
<DEVATTRIB Name="display_name">ONS1</DEVATTRIB>
<DEVATTRIB
</SET>
<SET Name="DSBU managed">
<DEVATTRIB Name="dsbu_member_number">1</DEVATTRIB>
<DEVATTRIB
Name="parent_dsbu_id">display_name=cluster1</DEVATTRIB>
</SET>
</DEVICE>
<DEVICE>
<DEVATTRIB
<DEVATTRIB Name="host_name">host1</DEVATTRIB>
<DEVATTRIB Name="display_name">cluster1</DEVATTRIB>
<DEVATTRIB Name="sysObjectID">Unknown</DEVATTRIB>
</SET>
</DEVICE>
</DEVICES>

4-38 78-16571-01
Using DCR Features Through CLI

Using Command Line Interface, you can add, delete, and modify devices, and
change the DCR modes. You can also view the list of attributes that can be stored
in DCR, and view the current DCR mode. The dcrcli utility provided with
Common Services helps you perform these tasks using CLI.
Adding Devices Using dcrcli

To add devices using dcrcli:
Step 1 Enter NMSROOT/bin/dcrcli -u username.

Step 2 Enter the password corresponding to the username
Step 3 Enter add ip=value hn=value di=value dn =value -a attname=value
Enter either the IP address (ip), Hostname (hn), or Device Identity (di).
Enter the Display Name (dn) and the Attribute name (-a attname). The attribute
sysObjectID is mandatory. You can add multiple attributes. For example,
add ip=1.1.1.1 hn=device1 dn=cisco.com
-a sysObjectID=1.3.6.1.4.1.9.1.6
Deleting Devices Using dcrcli

To delete device using dcrcli:

Step 2 Enter the password corresponding to the username.
Step 3 Enter del id=value.
id is the Device ID. For example,

del id=54340

78-16571-01 4-39
Editing Devices Using dcrcli

To modify devices using dcrcli

Step 2 Enter the password.
Step 3 Enter mod id=value ip=value hn=value di=value dn=value -a attname= value
Enter the Device ID (id).

Enter either the IP Address (ip), Hostname (hn), or Device Identity (di).
Enter the Display Name (dn) and the Attribute name (-a attname). You can add
multiple attributes. For example,
mod id=54341 ip=2.2.2.2 dn=cisco.com -a display_name=new_name
Listing the Attributes

To view the list of all attributes:

Step 3 Enter lsattr
This lists Attribute Name, Attribute Description, and Attribute Type.
Attribute Type is a constant that identifies an Attribute Name.
Example:
Attribute Type 1072 identifies the attribute name display_name

4-40 78-16571-01
Viewing the Current DCR Mode Using dcrcli

To view the current DCR mode:

Step 3 Enter lsmode
It lists the DCR ID, the DCR Group ID, the current DCR mode, and the associated
Master/Slaves.
Viewing Device Details

To view device details using dcrcli:

Step 2 Enter the password corresponding to the username.
Step 3 Enter details id=DeviceID
This lists all the details about the device with the ID you have specified. For
example,
detail id=54341 lists the details for the device with device ID 54341.

78-16571-01 4-41
Changing DCR Mode Using dcrcli

To change mode to Master:

Step 3 Enter setmaster
The DCR mode gets changed to Master.
To change mode to Standalone:

Step 3 Enter setstand
The DCR mode gets changed to Standalone.
To change mode to Slave:

Step 3 Enter setslave master=value
You have to specify the Master for this slave.

The DCR mode gets changed to Slave. For example,
setslave master=1.2.1.3 port=443

4-42 78-16571-01
Import Using CLI

You can import using the Command Line Interface.

• To Import from file:
Enter impFile fn=file name ft=file type
fn—the file name
ft—the file type; CSV and XML are the valid values.
Example:
impFile fn=/opt/CSCOpx/test.csv ft=csv
• To Import from Local NMS:

Enter impNms nt=NMS type il=Installation location
nt—NMS type. Valid values are HPOV6.x and Netview7.x
il—Installation location of the NMS
Example:
impNms nt=HPOV6.x il=/opt/OV
• To import from Remote NMS:

Enter ImpRNms nt=NMS type hn=hostname un= Remote User Name
il= Installation location ot=OS Type
nt — NMS type. Valid values are HPOV6.x and Netview7.x

hn — Remote Host Name or IP address
un — Remote User Name
il — Installation location of the NMS
ot— OS Type; Valid values are HPUX, AIX, or SOL
Example:
impRNms nt=HPOV6.x hn=1.2.3.4 un=root il=/opt/OV ot=SOL

78-16571-01 4-43
• To import from ACS:

Enter ImpACS ot=OS Type hn=ACS Server Name or IP address un=ACS admin
user name pwd=ACS admin password prt=port number
ot— Operating System Type
hn — ACS Server Name or IP address
un — ACS admin user name
pwd— ACS admin password
prt — port number. Default is 2002.
Example:
impAcs ot=WIN2K hn=1.2.3.4 un=acsadmin pwd=acspwd prt=2002
Export Using CLI

You have the option to export using Command Line Interface.

Step 3 Enter exp fn=filename ft=filetype.
For filetype, CSV or XML are valid values. You can edit the Export Format file
located at NMSROOT\objects\dcrimpexp\conf\Export_Format_CSV.xml.
Or,
Export_Format_XML.xml to specify the credentials. For example,
exp fn=/opt/CSCOpx/test.csv ft=csv
Note For a complete list of attributes and their description, use the lsattr command
in dcrcli. See Listing the Attributes for usage details. Also, see Attributes and
Description and Credentials and Description.

4-44 78-16571-01
Implications of ACS Login Module on DCR

When Common Services is in ACS mode, you can perform operations in Device
and Credential Repository (DCR) based on role assignment in ACS.
See Setting the Login Module to ACS for details on ACS login module.
Note A device in DCR is mapped to a device in ACS based on IP address of that device
in DCR and ACS. If a device in DCR has no IP address, then it's display_name in
DCR is mapped to host-names available in ACS.
In DCR, you can see the buttons enabled or disabled, based on the role assigned
to you.
For example, if a user U1 is assigned Approver role in ACS, he can see only the
View button enabled in DCR. Further a user can see only those devices in DCR 's
device-selector for which he has View Devices task assigned in ACS.
When performing operations in DCR, evensong you select some devices and click
the appropriate button, the operation will not be performed on all selected devices
(unlike in CiscoWorks local mode). This is because the operation will be done
only on those devices for which the you has been assigned required privilege.
For example, a user U2 is assigned Helpdesk role for device D1 and System
Administrator role for device D2 in ACS. Now U2 is able to select both D1 and D2
in DCR. But when the user clicks on Delete, only device D2 will be deleted.
This is because U2 has Helpdesk role for D1. Helpdesk role does not have Delete
task.
Custom Roles and DCR

You can create new roles in ACS and assign a new combination of tasks to that
role. In ACS, if a Custom role is created, a few points should be considered for
DCR related tasks because certain DCR tasks have interdependencies. If certain
tasks are included in the custom role, there will be other tasks which must also be
assigned to the role to help you carry out the operations successfully.

78-16571-01 4-45
The following table gives the details.
Task Dependent Tasks

View Devices View Devices task. Necessary to see a
device in DCR device-selector. This
needs to be assigned for all tasks which
require device selection.
Add View Devices task is necessary for
seeing AUS or Cisco Cluster in Add
wizard.
Edit View Devices task is necessary to see a
device's details in Edit wizard.
Bulk import Add and Update tasks are necessary.
Export View Devices task is necessary.
Delete None.
Reports None.
Change Mode None.
Add User Defined Fields in DCR None.
Modify User Defined Fields in DCR None.
Delete User Defined Fields from DCR None.
Register/Unregister 3rd Party None.
Application in DCR

4-46 78-16571-01
C H A P T E R 5
Administering Groups
The Groups feature in Common Services helps you to group devices managed by
CiscoWorks applications. It helps in creating, managing, and sharing groups of
devices. The groups created using this feature are shared across applications. The
groups created in applications can also be viewed from Common Services too.
The following components constitute this feature:
• Group Server:
Manages groups of devices. It helps you to create, edit, delete, and refresh
groups. It interfaces with an application service adapter (ASA) to evaluate
group rules and retrieve devices of a particular group.
• Application Service Adapters (ASAs):
Application-specific information repository that serves as source of the
devices and attributes that are grouped by the Groups Server. For Common
Services, Device and Credential Repository (DCR) acts as the ASA. See
Chapter 4, “Managing Device and Credentials” for detailed information on
DCR.
• Group Admin:
Allows you to interact with the Group Server to create and manipulate groups
using Group Admin.

78-16571-01 5-1
Chapter 5 Administering Groups
Group Concept
Basic Concepts:
• Group Class:
Representation of a set of devices belonging to DCR.
• Group Object:
Device in a group class. Each device in the group will have a set of attributes
stored in DCR. Associated with every device is a unique and immutable
device ID.
• Group:
Named aggregate entity comprising a set of devices belonging to a single
class or a set of classes, with a common superclass. Groups can be shared
between users or applications, subject to access-control restrictions. The
membership of a group is determined by a rule.
• Group Rule:
Consists of one or more rule expressions combined by operators, which can
be AND, OR or EXCLUDE.
Group Concept
A group is a named set of devices. The group is characterized by a set of properties
such as an associated rule, name, description, type, and access permission.
The rule determines the membership of a group, which may change whenever the
rule is evaluated. Groups are hierarchical. Groups can be dynamic or static. They
can be Private or Public.
Group Hierarchy
Groups are managed in a hierarchical fashion that supports sub grouping. Each
child group is a subgroup of a parent group, and its group membership will be a
subset of its parent group.

5-2 78-16571-01
Group Concept
Dynamic Group
A dynamic group is a group for which the membership list is always up-to-date.
Whenever you view a dynamic group, it always displays the latest group
membership list.
Static Group
A static group is a group for which the membership is refreshed only when you
explicitly request it. Between re-evaluations, the Group Server stores the
membership list and group definition of the static group.
Whenever you view a static group, you get the membership list that the ASA
created the last time the group rule was evaluated.
Container Groups
Container groups are groups without a rule. The group membership is the union
of the membership of its sub-groups. If a container group does not have
sub-groups, the membership list will be blank.
System-defined and User-defined Groups

After you install Common Services, you get two predefined groups. They are:
• System Defined Groups
System Defined Groups are automatically created based on the device type
information in DCR. When you add devices to DCR, the devices appear under
the corresponding System defined groups.
Just in Time groups (JIT) are groups that are automatically created/deleted as
when devices are added/deleted/modified.
• User Defined Groups
You can create groups here based on device attributes in DCR. This is
possible only if you have administrator privileges.

78-16571-01 5-3
Group Concept
These pre-defined groups come under the Provider group (or the root group),
which, by default, is of the format CS@hostname. This Provider group is the
parent of all Common Services groups found in the server.
You can change the Provider group name by changing the CiscoWorks Home Page
Server Name. This can be configured at Common Services > HomePage >
Settings. See “Setting Up CiscoWorks Homepage” section on page 2-12, for
details.
You have to restart Daemon Manager after you change the Home page Server
name, for the Provider group name change to take effect. After this, the Provider
group name will be of the format CS@Homepage Server Name.
You can see these groups in Device and Credential Admin (DCA) and Device
Center, and perform operations on the members of the group.
JIT groups are created based on the device types that are currently available in
DCR. If all devices belonging to a single MDF type are deleted, the corresponding
JIT group also gets deleted.
Common Groups and Shared Groups

Common group is the Common Services (CS) groups that are seen in the Groups
UIs of Applications. Shared groups are the application groups other than the
application's local group, that can be seen from the Common Services, and Groups
UIs of Applications.
You have read-only access on shared groups. You can:
• Check group details
• Refresh group
To perform any operation on CS groups, you have to invoke the Groups UI from
Common Services. From the Common Services Group Admin UI, you cannot
perform create, edit, and delete operations on Application Groups.
For example, if you have a machine on which Common Services, RME, and
Campus Manager are installed. If you invoke the Groups UI from Common
Services, you can see three provider groups. They are:
• CS@hostname
• RME@hostname
• Campus@hostname

5-4 78-16571-01
Group Concept
The group CS@hostname is the local group.

The groups RME@hostname and Campus@hostname are shared groups.
If you invoke the Groups UI from RME, you will find three provider groups:
• CS@hostname
• RME@hostname
• Campus@hostname
Here, RME@hostname is the local group.
CS@hostname is the common group, and Campus@hostname is a shared group.
Similarly, in the Groups UI in Campus Manager, Campus@hostname is the local
group. RME@hostname is a shared group, and CS@hostname is the common
group.
Figure 5-1, a screen shot taken from the Group Administration UI in
Common Services, on a machine (machine name : bundle-pc3) that has Common
Services, Campus Manager, RME, and DFM installed, illustrates the concept.
Figure 5-1 Common Services Group Administration Window

78-16571-01 5-5
Secure Views
In the Group Selector pane in the Group Administration page, you can see:
• CS@bundle-pc3
• Campus@bundle-pc3
• RME@bundle-pc3
• DFM@bundle-pc
Here, CS@bundle-pc3 is the local group, and the rest are shared groups.
Secure Views
Secure Views allow access to devices of a group to be restricted. Secure Views
enables filtering of group membership based on user and the application task
context in which a request is made. Filtering will be performed only when
operating in ACS mode.
While operating in Non ACS mode, no filtering will be performed, and evaluating
a group results in all devices of that group being returned.
For example, if there are two users A and B configured in ACS with different set
of privileges such that A can operate on devices D1, D2, D3 and B can operate on
D4 and D5.
If B tries to perform any operation on the group to which all the above devices
belong, B will be able to see only D4 and D5. This is because B is authorized to
perform operations only on those two devices. For details on ACS login mode see
“Setting the Login Module to ACS” section on page 3-35.

5-6 78-16571-01
Groups in a Single-Server Setup
Groups in a Single-Server Setup

The devices you see in the Group Administration UI in applications depends on
whether the devices are being managed by that particular application or not.
For example, if we have Common Services, Campus Manager, and RME installed
on a server. You can see the following groups in the Groups UIs of Common
Services, Campus Manager, and RME.
• CS@hostname
• RME@hostname
• Campus@hostname
Say you add 100 devices to the subgroup Routers in Common Services. All the
100 routers you have added are listed whenever you perform any operation on the
group Routers, from the Groups UI in Common Services.
However, if you perform any operation on the subgroup Routers, from the Groups
UI in RME, you may not see all the 100 devices you have added to the group from
Common Services. Instead, only those devices that RME manages are displayed.
Say you create a subgroup in Campus Manager, based on subnets, and add 30
devices. When you perform any operation on this subgroup from the Groups UI
in RME, the number of devices you will see may be less than 30. This depends on
whether RME is managing those devices.
Groups in Multi-Server Setup

Groups you create in Common Services groups UI in the Master get synchronized
with the Slave. This does not happen in the case of applications.
If you create a sub group under CS@master hostname in one server, it will appear
under CS@slave hostname in the peer server.

78-16571-01 5-7
But, in the Master server, if you create a subgroup under

application@master hostname, it will always appear under application@\master
hostname\, in the Slave. That is, the subgroup created in the Master appear under
the application's shared group in the Slave.
Note You cannot create groups in Common Services if it is in Slave mode. But, for
applications, you can create groups even if the server on which they are installed
is in Slave mode.
For example, say we have two servers M and S, where M is in Master mode, and
S is in Slave mode. Let both the machines have Common Services and RME
installed.
In M, you can see the following groups:
• CS@\master hostname
• RME@master hostname
• RME@slave hostname
Figure 5-2 Common Services Groups Window in a Multi-server Setup
In Figure 5-2, you can see the groups displayed in the CS Groups UI, in a multi
server scenario.

5-8 78-16571-01
Note that the machine bundle-pc12 is the Master, and the machine
bundle-sun280r1 is the Slave, in the figure.
In the CS groups UI you can see:
• CS@bundle-pc12 (The local CS group of the Master)
• RME@bundle-pc12 (Application group pertaining to the Master)
• RME@bundle-sun280r1 (Application group pertaining to the Slave)
Similarly, in S you can see the following groups:
• CS@slave hostname
• RME@master hostname
• RME@slave hostname
Figure 5-3 Groups Window in Application in a Multi-server Setup
In Figure 5-3, you can see the groups displayed in the Application (RME) Groups
UI, in a multi server scenario.
Note that bundle-pc12 is the Master, and bundle-sun280r1 is the Slave, in the
figure.

78-16571-01 5-9
DCR Mode Changes and Group behavior
You can see:

• CS@bundle-sun280r1 (The local CS group of the Slave)
• RME@bundle-pc12 (Application group pertaining to the Master)
• RME@bundle-sun280r1 (Application group pertaining to the Slave)
Say you create a sub group under CS@master hostname. In S, you can see this
subgroup under CS@slave hostname.
However, if you create a sub group in M under RME@master hostname, this sub
group appears in S under RME@master hostname, and not under RME@slave
hostname.
In a cluster if you have M as the Master, and S1 and S2 as M’s slaves, and you
want to evaluate S1’s groups from S2, you need to import the certificate of S1 to
S2 and vice versa.

The DCR modes have a bearing on how groups are displayed in the Groups UI.
Also the DCR mode decides whether you can perform any operation on the
groups.
In Standalone mode, the groups you create in the CS Groups UI is propagated to
the application Group instances of the applications installed in the same machine.
To perform operations on application groups, you should launch Groups UI from
the application.
In Slave mode, the CS group admin UI is disabled. You cannot create any CS
groups when the machine is in Slave mode. The UI is enabled automatically when
the mode changes to Master or Standalone.
So, in a cluster that has several Slaves and a Master, if you need to create CS
group, you need to go to the CS Groups UI in the Master and create the group.
The group you create there will be synchronized with the Slaves.
The following table gives details of DCR mode changes and implications on
Groups.

5-10 78-16571-01
Table 5-1 DCR Mode Changes and Group Behavior
Mode Changed to:

The initial Standalone Slave Master
mode
Standalone Not applicable. Master will get all the No change in the Group
Slave groups. That is, if hierarchy.
Slave has App-1 installed,
Master will have all the
groups that belong to
App-1 on Slave. All these
groups appear under the
root group,
/App-1@Slave.
Also, Slave will get
Master’s groups. Group
UI gets disabled.

78-16571-01 5-11
Table 5-1 DCR Mode Changes and Group Behavior (continued)
Mode Changed to:

The initial Standalone Slave Master
mode
Slave Groups UI gets enabled. The Not applicable. Groups UI gets enabled.
groups pertaining to Master and Groups pertaining to the
Slaves will be removed. previous Master and the
The Slave’s groups will associated Slaves will be
disappear from the Master. removed.
The groups pertaining to the

Slave whose mode was changed
will disappear from other
Slaves in the cluster.
Master All dependent Slaves will If you select the Inform Not applicable.
switch to Standalone mode. All current Slaves of new
groups pertaining to other Master Hostname check
machines will be removed. box when you change the
Groups UI will be enabled on mode to Slave, all the
all machines in the cluster. Slaves in the domain,
switch to the new Master.
In this case, application
groups of all the Slaves in
the domain, and the
groups in the Master will
be seen in the new Slave.
The Groups UI will be
disabled.
If the check box is not
selected, the new Slave
will pickup the groups of
the new Master. Other
Slaves in the domain will
move to Standalone mode.

5-12 78-16571-01
Unregistering a Slave
Unregistering a Slave
The Unregister Slave utility helps you unregister a Slave which is no longer part
of the domain.
The utility is useful in the following scenarios:
• Change in Slave’s mode due to backup and restore. That is, if data is restored
from Standalone/Master belonging to a different domain.
• When you uninstall CiscoWorks from slave.
• Change in slave’s mode, when master is not reachable. If the Master is down
when the Slave’s mode changes, the Master will not be aware of the Slave’s
mode change, when it comes up.
The Master will not receive any data from the Slave, but the Slave information
will still be present in the its registry. A redundant group (such as CS@Slave) will
still appear in the Master’s Groups UI.
In the case of DCR, any device operation on Master will update the Slave list. But
the same does not happen in the case of Groups.
You can run the UnregisterSlave utility to remove any unwanted slave
information:
From the CLI, run:
NMSROOT /bin/perl NMSROOT/bin/UnregisterSlave.pl slave host name
You have to enter the hostname of the machine you want to unregister.
For information on effects of backup-restore on data, DCR modes, and Groups,
see “Effects of Backup-Restore on DCR” section on page 3-63 and “Effects of
Backup-Restore on Groups” section on page 3-67.

78-16571-01 5-13
Group Administration
The Group Administration and Configuration UI helps you to create, manage,
view, and delete groups.
Note Group Administration UI will be enabled only on servers in which DCR is in

Master or Standalone mode. The groups created in DCR master will be copied to
Group Administration instances on servers where DCR is in Slave mode.
The following sections provide information on how to perform group

administrative tasks in Common Services:
• Creating Groups
• Modifying Group Details
• Viewing Group Details
• Refreshing Groups
• Deleting Groups
Creating Groups
To create a new device group:
Step 1 In the CiscoWorks Homepage, select Common Services > Groups > Group
Admin.
The Groups Administration page appears.
The Group Administration and Configuration dialog box in the
Group Administration page provides a Group Selector pane.
The System Defined Groups shows sub groups only after Device and Credential
Admin (DCA) is populated.
The Group Selector field contains two groups:
• System Defined Groups
• User Defined Groups
These are the predefined (higher level) groups.

5-14 78-16571-01
Step 2 From the groups listed in Group Selector, select the group under which you want
to create the new group.
The group you select here is the parent group for the new group you are about to
create.
You can create a new group only under User Defined Group.
The default limit of User Defined Groups you can create is 100. If you try to create
more than 100 User Defined Groups, you will get a message saying that you have
exceeded the limit.
The Group Info fields on the right pane display details of the selected group.
You can change the parent group later, if required.
The following tasks have to be performed:
1. Specifying Group Properties
2. Defining Group Rules
3. Assigning Group Membership
While creating a new group you must complete all the three tasks in this sequence
to create a group.
If you exit the wizard at any stage by clicking Cancel, the details you have
specified will be lost and the group will not be created.
Specifying Group Properties

While specifying group properties, you can enter the properties such as name and
description, and modify the parent group, if required, and update membership,
and specify the visibility scope.
To complete the tasks in this phase:
Step 1 In the Group Administration and Configuration dialog box, click Create.
Step 2 In Properties:Create dialog box, enter a name for the group in the Group Name
field.
The group name should be unique within the parent group. However, it need not
be so across groups. The same group name cannot be used in the same group
hierarchy.

78-16571-01 5-15
For example, if you have a group /CS@servername/User Defined

Groups/MyView, you cannot create another group with the same name “MyView”
under /CS@servername/User Defined Groups.
Step 3 Click Select Group, if you want to copy attributes of an existing group.
The Replicate Attributes dialog box appears.
Step 4 From the Replicate Attributes list, select the desired group and click OK.
Step 5 Click Change Parent, to change the parent group.
The Group Selector page appears.
Step 6 From the Select Parent list, select the group.
Step 7 Click OK.
The Group Administration wizard changes the parent group to the one you
selected, and returns to the Properties:Create window.
Step 8 Enter a description for the group.
Typically, you can enter a detailed description of the group identifying its
characteristics in this field.
Step 9 Select the Membership Update mode for the group.
The modes of membership updates available are:
• Automatic:
The membership of the group is automatically recomputed each time the
group is invoked.
• Only Upon User Request:
The membership of the group is recomputed only when an explicit request is
made, using the Refresh option.
If you select Automatic, the group will be a Dynamic group. If you select Only
Upon User Request, the group will be a Static group.
Step 10 Select either Public or Private radio button to specify the visibility scope.
Step 11 Click Next to get to the Rule:Create dialog box.

5-16 78-16571-01
Defining Group Rules

In the Rules:Create dialog box, you can define the rules for the group. The rules
you define in this phase determine the contents of the group. The rules you specify
here determine the devices to be included in the group.
If you have created the group copying the attributes of another group, the rules
specified for that group appears in the Rule Text field. You can retain these and
add more rules, or delete these rules and create a new set of rules.
In the Rules:Create dialog box, you can either enter the rules directly in the Rule
Text field, or select the components of the rule from the Rule Expression fields,
and form a rule.
The rule expression has the following components:
Class.attribute operator value
The Rules:Create dialog box allows you to check the syntax in the Rules Text
field. You can use this facility to validate the rules you have created.
If you leave the rule blank, it creates a Container group.
Click View Parent Rules to display the rules defined for its ancestor groups.
You can select the parameters from Rule Expression fields to create a new set of
rules.
If you do not want to use the rules currently displayed in the Rule Text field, you
will have to create a new set of rules. To do so:
Step 1 Delete the rules displayed in the Rule Text field, and click any other field.
Step 2 Select appropriate parameters for Object Type, Variable, and Operator. See
System Defined and User Defined Attributes for details on the Variables.
Enter the value for the Variable you have selected.
Step 3 Click Add Rule Expression.
The Group Administration wizard creates the rule based on the parameters you
specified and adds the rule to the Rules Text field.
For example, the rule type:
:CMF:DCR:Device.DisplayName equals "joe"
will select the device with the DisplayName joe.

78-16571-01 5-17
The Rules:Create dialog box refreshes and displays the Boolean operator field
before the Object Type field in Rules Expression. You can form composite rules
using the OR, AND, or EXCLUDE options in the Boolean operator field.
The OR, AND, EXCLUDE drop down list appears only when there is at least one
rule expression in the text area.
You can validate rules that are entered directly into the Rules Text field or rules
formed using the Add Rules Expression option in the dialog box.
To check whether the syntax is valid, click Check Syntax.
To view the rules defined for the parent groups, click View Parent Rules.
Step 4 Click Next.
The wizard takes you to the Membership:Create dialog box, where you can further
refine the group definition by adding or deleting specific devices from the group.
Assigning Group Membership

To decide the devices available to the group you have created, the wizard uses the
details of the parent members and rules you have already specified.
These devices appear in Available Objects From Parent Group column based on
the properties and rules you have already specified.
To add devices to the group you have created:
Step 1 Select one or more devices in Available Objects From Parent Group column.
To select multiple devices, hold the Ctrl or Shift keys down and click.
Step 2 Click Add.
The selected devices are removed from Available Objects From Parent Group and
added to the Object Matching Membership Criteria column.

5-18 78-16571-01
Removing Devices
To remove devices from the group:
Step 1 Select one more devices in Object Matching Membership Criteria column.
To select multiple devices, hold the Ctrl or Shift keys down and click.
Step 2 Click Remove.
The selected devices are removed from the Object Matching Membership Criteria
column and added to Available Objects From Parent Group.
Step 3 Click Next.
The Summary:Create window appears. It displays the group name, the parent
group, description, the membership update type, group rules, and the visibility
scope of the group you created.
If you want to change the parameters, click Back to go back to the previous
windows and make changes.
Step 4 Click Finish to create the group based on the parameters specified.
Viewing Group Details

To view the details of a group:
Admin.
The Group Administration page appears.
Step 2 In the Group Administration and Configuration dialog box, select the group from
Group Selector.
The Group Info fields on the right side displays the high-level properties of the
selected group.

78-16571-01 5-19
Step 3 Click Details.

The Group Administration wizard displays the details of the group in
Properties:Details window.
• Click View Parent Rules to display the rules set for the parent group.
The rules set for the parent group are displayed in the Show Parent Rules
window.
• Click Membership Details to display a list of devices and their
corresponding object types.
The membership details are displayed in Membership:Details window.
In the Membership:Details window, you can:
– Click on the column headers to sort the entries in the table.
– Select the number of rows to be displayed in the table. To do this, select
the desired number of rows in Rows per page.
• Click Property Details to return to the Property:Details window.
Step 4 Click Cancel to return to the Group Administration and Configuration page.
Modifying Group Details

You can modify some of the details for a group using this feature.
To modify the details of a group:
Admin.
Group Selector.
The Group Info fields on the right side displays details of the selected group.
Step 3 Click Edit.
The Group Administration wizard guides you through the process of editing a
group. It displays the details of the group in Properties:Edit window.

5-20 78-16571-01
Step 4 Change the Group Name, Description, Membership Update, and Visibility Scope
in the Properties:Edit dialog box.
You cannot change the parent group or copy attributes from a different group in
Edit mode.
Step 5 Click Next.
The wizard takes you to the Rules:Edit window.
Step 6 Change the rules as required. For details on creating the rules, see “Defining
Group Rules” section on page 5-17.
Step 7 Click Next.
The wizard takes you to the Membership:Edit window.
Step 8 Add or remove devices from the list of objects in Objects Matching Membership
Criteria as required. For details on creating the rules, see “Assigning Group
Membership” section on page 5-18.
Step 9 Click Next.
The wizard takes you to the Summary window.
If you want to change the parameters specified, click Back to go back to the
previous windows and make changes to the properties or rules.
Step 10 Click Finish to modify the group.
Step 11 Click OK.
The Group Administration wizard copies the attributes of the selected group and
displays it in the corresponding fields in Properties:Create window.
Note that the parent group you have selected for the group does not change even
if you are copying attributes from a group that belongs to a different parent group.

78-16571-01 5-21
Refreshing Groups
You can recompute the membership of a group by re-evaluating the group's rule.
The membership of Automatic groups is recomputed dynamically.
The membership of Only-upon-user-request groups is recomputed only when
explicitly refreshed with this option.
To refresh a group:
Step 1 In the CiscoWorks Homepage, select Common Services > Groups >
Group Admin.
Group Selector.
The Group Info fields on the right pane displays details of the selected group.
Step 3 Click Refresh.
The Group Administration pop-up window prompts you for confirmation.
Step 4 Click Yes.
The selected group is recomputed and the window, refreshed.
Deleting Groups
You can delete a group from the Group Selector. When you delete a group, all the
child groups under the group are also deleted.
To delete a group:
Admin.
Step 2 Select the group from Group Selector.
The Group Info fields on the right pane displays details of the selected group.

5-22 78-16571-01
System Defined and User Defined Attributes

The Group Administration and Configuration dialog box prompts you for
confirmation.
Step 4 Click Yes.
The selected group is deleted.

The following table provides details on the System Defined attributes that are
available in Common Services. These are pre-defined attributes, available by
default.
DisplayName Device name, as you want it to be represented in
reports or graphical displays. Can be derived from
Host Name, Management IP address or Device
Identity.
ManagementIpAddress IP address used to access the device. Both IPv4 and
IPv6 address types are supported.
HostName Device Host name.
DomainName Domain name of the device.
DeviceIdentity Identifies pre-provisioning devices. The value would
be application specific.
SystemObjectID sysObjectID value. It may be UNKNOWN in the
case the facility that is populating the repository does
not know the value.
Category Category in which the device falls. The first level
entries in the Device Type tree in DCR Device
Management UI. For example, Routers is a category.

78-16571-01 5-23
Series Series to which the device belong. The second level
entries in the Device Type tree in DCR Device
Management UI. For example, Cisco 3100 Series
Routers, that falls under the category Routers .
Model Model of the device. The third level entries in the

Device Type tree in DCR Device Management UI.
For example, the model Cisco 3101 Router falls
under the Cisco 3100 Series Routers, which comes
under the category Routers.
MDFId Normative name for the device type as described in
Cisco’s Meta Data Framework (MDF) database.
Each device type has a unique normative name
defined in MDF.
The User Defined Fields available in the Variable drop-down list is taken from
DCR. You can create Used Defined Fields at Common Services >
Device and Credentials > Admin For details, see “Adding User-defined Fields”
If you create a User Defined Field which is similar to one of the predefined
System Defined attributes, an _UDF suffix is appended to the User Defined field
you add, to distinguish these two attributes.
For example if you create a User Defined Field called DisplayName (which is one
of the pre-defined attribute present in the Variable drop-down list), this will be
displayed as DisplayName_UDF.
Note You should not create a User Defined fields in the format
System Defined Field_UDF, where System Defined Field stands for any attribute
listed in the above table.
By default, four user defined fields are available. You can create 12 user defined
fields in DCR. The maximum number of user defined fields that can be added in
the Variable drop-down list is 16.

5-24 78-16571-01
C H A P T E R 6
Using Device Center
Device Center provides a one stop place where you can see a summary for a
device, and launch troubleshooting tools, management tasks, and reports for the
selected device. Since Device Center is based on a device-centric navigation
paradigm, it helps you to concentrate on device centric features and information
from a single location.
After launching Device Center, you can perform device-centric activities, such as
changing device attributes, updating inventory, and perform telnet on a device
selected from the Device Center Window.
You can also launch Element Management tools, reports, and management tasks.
Since all this information and reports for a single device are available from a
single location, Device Center helps you in troubleshooting devices.
Device Center caters to a broad variety of device centric features from a single
location. After launching Device Center, you can invoke many tools on the
selected device from a single location.
The various features in Device Center come from the CiscoWorks applications
installed on the server.
Device Center features and functions are available only from applications that
reside on the same server on which Common Services is installed. You cannot
launch tools, reports, and perform management tasks that pertain to applications
installed on a different server.

78-16571-01 6-1
Chapter 6 Using Device Center
Launching Device Center
The following sections of this chapter provide information on:

• Launching Device Center
• Invoking Device Center
• Using Device Center Functions
Launching Device Center

You can launch Device Center using any of the following options:
• From CiscoWorks Homepage.
Launch the Device Center main page from the CWHP and select a device.
To launch device center from CWHP select CiscoWorks Homepage >
Device Troubleshooting > Device Center.
• Bookmark the Device Center URL and launch directly from the browser
window.
• Launch Device Center for a device from one of the application functions such
as reports.
For example, you can launch Device Center by clicking the Device name from
RME Inventory Reports.
• From Third Party applications by passing the device context as a parameter.

6-2 78-16571-01
Invoking Device Center
Invoking Device Center

To invoke Device Center:
Step 1 Select CiscoWorks Homepage > Device Troubleshooting > Device Center.
The Device Center page appears with the Device Selector on the left pane and
Device Center overview information on the right pane.
Step 2 Enter the IP address or device name of the device and click Go.
Or,
Select a device from the list-tree, in the Device Selector field,.
The Device Summary, and Functions Available panes appear.
Step 3 Click any of the links under the Functions Available pane to launch the
corresponding application function.
The links are launched in a separate window.
If you enter the device name or IP address of a device not managed by any of the
applications installed on the Common Services server, the Functions Available
pane displays only the default connectivity tools from Common Services.
Using Device Center Functions

You can use the following Device Center modules to select devices, get a
summary on the devices, get reports, debug, and perform management tasks.
• Device Selector
• Device Summary
• Management Functions

78-16571-01 6-3
Using Device Center Functions
Device Selector
Device Selector displays the list of devices managed by applications installed on
Common Services. Device Selector populates the devices for device selection in
Device Center.
The devices shown in the Device Selector are those managed locally by
applications that are installed in local server have some information that can be
shown in Device Center.
Device Selector displays devices in groups. This is the entry point for the Device
Center page. You can view and select devices using the device selector.
Note After you select a device using Device Selector, you will get information on the
applications that manage the device.
Device Selector allows you to:

• Change device selection to see related information for the selected device.
• Troubleshoot or manage the device selected.
• Select a device from the list-tree or by entering in the IP address or device
name. Selecting a device displays Device summary and Functions Available
panes.
Device Summary
The Device Summary content in the Device Center displays a summary of the
device. You can see the IP Address, Device Type, OS version, and Last Reload
Date in the Device Summary content area.
The summary page displays information grouped on the basis of application
providing the information.

6-4 78-16571-01
Enabling Debugging Tools
Management Functions
The Management Functions dialog box in the Device Center Functions Available
page helps you to get the list of Debugging Tools, the list of Reports, and the list
of Management Tasks on a selected device.
You can launch the management functions (Tools, Tasks, Reports) by:
• Selecting a device from device selector.
• Entering a device IP address or device name in the text box provided and
clicking the button.
• Passing device context as parameters. Passing device context as parameter is
meant for applications only.
Management Functions helps you perform these tasks:
• Enabling Debugging Tools
• Displaying Reports
• Performing Management Tasks
Note You must have the required privileges to use some of the functions.

The Tools pane in the Device Center page displays the list of debugging tools that
are used with the device. This module helps to debug device related problems.
Tools enable you to test device connectivity, and troubleshoot nonresponsive
devices. They are available for all devices.

78-16571-01 6-5
Checking Device Connectivity

To troubleshoot problems with un-managed or non-responding devices, you can
check the device connectivity by protocol. The Management Station to Device
tool helps you diagnose Layer 4 (application) connectivity problems.
Layer 4 tests include the key services Essentials needs to manage network
devices: debugging and measurement tools (UDP and TCP), the web server
(HTTP), file transfer (TFTP), the terminal (Telnet), and read-write access
(SNMP).
If a hostname is entered instead of an IP address, the program always does a name
lookup to find out the address. The test will fail if it cannot find an address.
You can test:
• UDP (echo test, port 7)
Sends an echo request to UDP port 7.
• TCP (echo test, port 7)
Sends an echo request to TCP port 7.
• HTTP (availability test, port 80)
Sends an HTTP request to the HTTP port 80 of the destination device.
• TFTP (availability test, port 69; device must be configured as a TFTP server)
Sends a TFTP request to the TFTP port (69) of the destination device.
• Telnet (service test, port 23)
Checks whether Telnet is enabled on the device and if the destination device
responds to a Telnet request. It does not verify that the Telnet password in the
database works.
Since Telnet runs on top of TCP, when Telnet succeeds, it means TCP is
enabled on the device. If Telnet fails, there is no way to automatically
determine if TCP is enabled or not. Perform a TCP test to check whether TCP
is up or not.

6-6 78-16571-01
• SNMP (service test, port 161)

Sends an snmp get request to the destination device for an SNMP read test
(SNMPR). It also sends an snmp set request to the device to test SNMP write
(SNMPW). This protocol is supported for the versions of v1, v2c, and, v3.
• SSH (service test, port 22)
Checks whether SSH is enabled on the device. If the destination device
responds to SSH requests, this also tests whether CiscoWorks Server can
make SSH requests to that device. It does not verify the password in the
database.
If you launch Management Station To Device with Network Operator/Help Desk
privilege, device credential fetching fails and the fields of read/write community
strings of SNMP v1/v2c, read/write SNMPv3 credentials are set to default values.
You have to manually enter SNMP v1/v2c/v3 credentials.
To invoke Management Station to Device tool:
Step 1 Select Device Troubleshooting > Device Center.

Step 2 Enter the name or IP address, fully qualified domain name, or hostname of the
device you want to check in the Device Selector field and click GO.
Or
Select the device from the list tree.
The Summary and Functions Available panes appear.
Step 3 From the Functions Available pane, click Management Station to Device.
The Management Station to Device dialog box appears.
Step 4 Select the connectivity applications you want to select
All information you enter in the fields are case sensitive.
If you select SNMP v1/v2c, enter the following:
• The Read Community string.
• The Write Community string.
• Time out in seconds.

78-16571-01 6-7
If you select SNMP v3, enter the following.

• The Read User name.
• The Read Auth PassPhrase.
• The Read Auth Protocol. Select MD5 or SHA from the drop-down list.
• The Write Username.
• The Write Auth PassPhrase.
• The Write Auth Protocol. Select MD5 or SHA from the drop-down list.
• The Security Level (authNoPriv).
• Timeout (in seconds, the default is 2 seconds).
Step 5 Click OK.
The Interface Test Results popup appears with the results. The Interface Details
results screen shows the interfaces tested and the test results for each option.
Using Ping
Use the Ping tool to test whether the device is reachable. A ping tests an ICMP
echo message and its reply. Since ping is the simplest test for a device, use it first.
You can view the packets transmitted, and received, percentage of packet loss, and
round-trip time in milliseconds. If ping fails, try using traceroute.

Or,
Step 3 From the Functions Available pane, click Ping.
The Ping window appears with the results of the ping.

6-8 78-16571-01
Using Traceroute
Use the Traceroute tool to detect routing errors between the network management
station and the target device.
Traceroute helps you understand why ping fails or why applications time out. It
does this by diagnosing TCP/IP Layer 3 (transport) problems. You can view each
hop (or gateway) on the route to your device and how long each took.

Or
Step 3 From the Functions Available pane, click Traceroute.
The results of the trace appear in the Traceroute window.
Using SNMP Walk

SNMP Walk allows you to trace the MIB tree of a device starting from a given
OID for purposes of troubleshooting, or gathering information about a certain
device.
You should have System Administrator privileges to use this feature.

Or

78-16571-01 6-9
Step 3 From the Functions Available pane, click SNMP Walk.

The SNMP Walk dialog box appears.
Step 4 Enter the IP address or DNS name.
Step 5 For SNMP Version 1 and 2c (if it is a 64-bit counter, use SNMP v2):
• Enter the Read community string.
• Enter the starting OID (optional). If this field is left blank, the tool will start
from 1.
• Enter the SNMP Timeout.
• Select the check box to get output OIDs numerically.
For SNMP Version 3:
• Provide the SNMPv3 Username and password
• Specify the SNMP v3 Auth Protocol. Select either the MD5 radio button or
the SHA radio button.
• Enter the starting OID (optional). If this field is left blank, the tool will start
from 1.
• Enter the SNMP Timeout. The default is 10 seconds.
• Select the check box to get output OIDs numerically.
The fields are case sensitive.
Step 6 Click OK to get the results.
The results will be based on the parameters you entered. When the walk is
complete, you can save it as text. A full walk may take a long time.
If you launch SNMP Walk feature with Network Operator/Help Desk privilege,
device credential fetching fails and the fields of read/write community strings of
SNMP v1/v2c, read/write SNMPv3 credentials are set to default values.

6-10 78-16571-01
Using SNMP Set

You can use this option to set an SNMP object or multiple objects on a device for
controlling the device.

Or
Step 3 From the Functions Available pane, click SNMP Set.
The SNMP set dialog box appears.
Step 4 Enter the IP address or the DNS name.
Step 5 For SNMP Version 1 and 2c (if it is a 64-bit counter, use SNMP v2):
• Enter the ReadWrite community string.
• Enter the object ID that you are trying to set along with the instance ID or
number.
• Select the Object Type from the drop-down list. The values vary with the
SNMP version selected.
• Enter a new value. This will depend on the Object Type you specify.
For SNMP Version 3:
• Provide the SNMPv3 Username and password.
• Specify the SNMP v3 Auth Protocol. Select either the MD5 radio button or
the SHA radio button.
• Enter the object ID that you are trying to set along with the instance ID or
number.

78-16571-01 6-11
• Select the Object Type from the drop-down list.

• Enter a new value. This will depend on the Object Type you specify
Step 6 Click Next if you wish to add more SNMP objects on the device.
The SNMP Set dialog box appears.
Step 7 Fill in all required fields and click Next. Repeat this until you have added as many
objects as you want.
Step 8 Click OK to get the results.
The results will be based on the parameters you entered. When you have
completed setting the SNMP objects, you can save it as text and mail the output.
If you launch SNMP Set feature with Network Operator/Help Desk privilege,
device credential fetching fails and the fields of read/write community strings of
SNMP v1/v2c, read/write SNMPv3 credentials are set to default values.
Using Packet Capture

The Packet Capture tool can be used to capture live data from the CiscoWorks
machine to aid in troubleshooting.
Note WinPcap must be installed to use this feature on Windows machines. The
executable is available at: NMSROOT\objects\jet\bin\winpcap.exe
Step 1 Select Device Troubleshooting > Device Center

Or

6-12 78-16571-01
Step 3 From the Functions Available pane, click Packet Capture.

The Packet Capture dialog box appears.
A list of archived capture files is displayed. If no capture files are archived, then
this screen will indicate that there are no records.
Creating a New Packet Capture File
Step 1 Click Create in the Packet Capture dialog box.

The Packet Capture Inputs dialog that lets you configure packets to be captured
appears.
If you click OK with the default values (without setting any of the parameters) the
screen will try to capture for the next 60 seconds.
Then it terminates and displays the Packet Capture dialog box with the new packet
capture file added to the list of the archived capture files.
Click on the new packet capture file link to get a sniffer output of packets received
by the CiscoWorks Server.
Step 2 In the Packet Capture dialog box:
• Specify the interface.
• Specify the address.
This field accepts one or more addresses (separated by a single space) to
match when capturing.
You may select Protocol and Port if you know the number of the port. all protocols
not specified under Applications can be captured using this option.

78-16571-01 6-13
Step 3 Select the protocols, TCP, UDP, or ICMP.

Then, if required, fill in the list of ports to capture for TCP and UDP. The Port(s)
field accepts one or more TCP or UDP ports, separated by a single space. If you
specify port but not the address, it provides an output for that port for all the active
devices.
You can stop a capture cycle after:
• A certain period time.
• The filter has captured a certain amount of data.
• A certain number of packets have been captured.
By default, capture cycles stop after 60 seconds.
Step 4 Click OK.
The Packet Capture dialog box with the new packet capture file added to the list
of the archived capture files is displayed after the capture is performed.
Step 5 Click on the new packet capture file link to get the result.
While the capture is being performed, if you click OK, Packet Capture status
popup appears with the current status of the capture.
If you click Stop Capture in the popup, capture stops and packet capture
information till then is added in the Packet Capture dialogue box, among the
archive files.
The result can be opened in any sniffer application, like Ethereal. These files are
in binary libpcap format with a .jet extension.
You can download these files directly through your web browser, then email them
to the TAC for further analysis.

6-14 78-16571-01
Displaying Reports
Editing Device Credentials

You can edit device information for the selected device, using this feature. You
can select a device from the list-tree or enter the IP address or device name, and
click Go.
The Edit Device Credential link launches the Edit Credentials dialog box
(Device and Credentials > Device Management).
See “Editing Device Credentials” section on page 4-13 for details.
You need to have System Administrator or Network Administrator privileges to
use this feature.
If the IP address or the device name you enter is not present in Device and
Credential Repository (DCR), the Edit Credential link will not be displayed.
Displaying Reports
The Report pane in the Device Center page displays the list of the reports that can
be launched for a device.
The reports displayed in the Report pane depends on the applications installed on
the server.
Performing Management Tasks

The Tasks pane in the Device Center page displays the list of management tasks
that can be performed on the Device.
The management tasks displayed in the Management Task pane vary depending
upon the applications installed on the server.

78-16571-01 6-15
Performing Management Tasks

6-16 78-16571-01
C H A P T E R 7
Working With Software Center
Software Center helps you to check for software and device support updates,
download them to their server file system along with the related dependent
packages, and install the device updates.
Software Center allows you to look for software and device updates from
Cisco.com, and download them to a server location. You can install the updates
from this location. In the case of device updates, Software Center helps you to
install the updates using a web based user interface, wherever possible.
Most of the device family-based packages can be installed directly from the web
interface while the device support packages such as IDU have to be installed
based on the installation instructions documented in the respective readme files.
You may also uninstall a device support package. Software Center does not
support uninstallation of software updates.
To backup what is installed on the server, Software Center maintains a package
and device map in the installed packages directory of the respective applications.
The package map is a list of all device packages installed on the server and device
map is a list of all the supported devices on the server.
Software Center also provides a Command Line Interface to download device
updates and software updates, and install or uninstall device packages.
For downloads from Cisco.com to work, you should have access to Cisco.com.
For details on configuring Cisco.com credentials, See “Setting up Cisco.com User
Account” section on page 3-44.

78-16571-01 7-1
Chapter 7 Working With Software Center
Performing Software Updates
Software Center helps in:

• Performing Software Updates
• Performing Device Update
• Scheduling Device Package Downloads
• Viewing Activity Logs

The Software Updates link under Software Center takes you to the Software
Updates page. This page has two dialog boxes:
• The Bundles Installed dialog box that lists the bundles installed.
• Products Installed dialog box that lists the applications installed.
These dialog boxes display the bundle or product name, the version, and the date
on which the software was installed. To sort the table by version or date of
installation, click on the Version / Installed Date link.
You can click the product name links to view the Applications and Packages
Installed with the Product page that gives the details of the installed applications,
patches, and packages of the product.
The Software Updates page provides options to download updates and select
updates.
To download updates:
Step 1 In the CiscoWorks Homepage, select Common Services > Software Center >
Software Updates > Download Updates.
The Software Updates page appears.
Step 2 In the Products Installed dialog box, select the check box corresponding to the
product for which you want to download the update.
Step 3 Click Download Update, then click Next.
The Image Destination Location page appears.

7-2 78-16571-01
Step 4 Enter the location, or browse to the location using the Browse tab, then click
Next. The destination location should not be the location where CiscoWorks is
installed.
The Summary window shows a summary of your inputs.
Step 5 Click Finish to confirm the download operation.
To change the download location, click Back.
To cancel the download, click Cancel.
To select updates:
Software Updates.
The Software Updates page appears.
Step 2 In the Products Installed dialog box, select the check box corresponding to the
product for which you want to select update.
Step 3 Click Select Updates.
Step 4 Select the product you need to update, then click Next.
Step 5 Select a destination location, then click Next. The destination location should not
be the location where CiscoWorks is installed.
The Download Summary window appears.
Step 6 Click Finish to confirm installation of the selected packages.
If you do not want to add the selected packages, click Back to reselect packages
or click Cancel to exit.

78-16571-01 7-3
Performing Device Update

The Device Updates link under Software Center takes you to the Device Updates
page. It displays a count of devices supported for each product installed in the
system.
Click on the product name link to view a Package Map that lists all the installed
device support packages of the product, and the version of each package.
Package name identifies the device package. For example, the package name
AP350 represents Cisco Aironet350 Device Package.
You have to use the package name while specifying the download policy.
Package map is a snap shot of the currently installed device packages for a
Product. The backup-restore framework uses Package map during data backup.
Click on the device type count link to view the Device Map that lists the
SysObjectID, Device Name, Package Name, and Version.
To check for updates:
Device Updates.
The Device Updates page appears.
Step 2 Select the check box corresponding to the product for which you want to check
for updates, then click Check for Updates.
The Source Location page appears. You can check for updates at Cisco.com or at
a Server.
Step 3 Select the Cisco.com radio button to check for updates at Cisco.com.
Or
Check for update from a server:
a. Select the Enter Server Path radio button.
b. Enter the path or browse to the location using the Browse.

7-4 78-16571-01
Step 4 Click Next.

The Available Packages and Installed Packages page appears with the following
information:
• Package Name—Name of the package.
• Type—Type of the update. For example, whether the update is a device
package or IDU patch.
• Product Name—Product for which the update is available.
• Installed Version—Current version of that product installed in the server.
• Available version—Version of the product that is available (Other than the
installed version).
• Readme Details—Links to the Readme files associated with the update.
• Posted date—Date on which the update was posted on Cisco.com.
• Size—Size of the update.
Step 5 Select the check box corresponding to the package that you wish to update, then
click Next.
The Device Update page appears. You can either install device packages or
download device packages.
• To install device packages, select the Install Device Packages radio button.
• To download device packages, select the Download Device Packages radio
button.
If you select Download Device Packages:
a. Enter the folder in File Selection field or click Browse to select the folder.
b. Set the frequency of downloads, select the run type from the Run Type
drop-down list. You have the following options:
• Immediate
• Once
• Daily
• Weekly
• Monthly

78-16571-01 7-5
If you choose any of the options other than Immediate, set the date and time.
• Select the date from the date picker.
• Specify the time from the drop-down lists.
c. In the Job Description field, enter a description for the download job. This is
mandatory.
d. Enter the E-mail ID in the E-mail field.
e. Click Next.
The Summary window displays the details.
f. Click OK to confirm.
If you select Install Device Packages:
a. Click Next.
A summary of your inputs is displayed.
b. Click OK to confirm.
A warning appears informing you that the daemons are restarted.
c. Click OK to continue with installation.
Deleting Packages
You can also delete packages that are outdated or you no longer use.
To delete a package:
Device Updates.
Step 2 Select the check box corresponding to the product, then click Delete Packages.
The wizard displays a window that has the Package name, the Product name, and
the Installed version details.
Step 3 Select the check box corresponding to the Package you want to delete.

7-6 78-16571-01
Scheduling Device Package Downloads
Step 4 Click Next.

The Summary window displays the details of the Product and the Packages
selected.
Step 5 Click Finish to confirm deletion.
To make changes in the previous windows, click Back.
To cancel the operation, click Cancel.

You can schedule device package downloads and specify the time, frequency of
the downloads.
You can also specify download policies. Software Center supports the following
download policies:
• Download all latest device packages of products installed in the machine.
• Download newer versions of currently installed packages.
• Download the specified packages (comma separated).
You have to provide your Cisco.com credentials and the location to which the
packages should be downloaded.
To schedule downloads:
Schedule Device Downloads.
The Schedule Downloads dialog box appears.
Step 2 Specify the Cisco.com user credentials.
Step 3 Enter the location, or browse to the location using the Browse tab.

78-16571-01 7-7
Step 4 Select the radio button corresponding to the download policy you require.
To set the frequency of downloads, select the run type from the Run Type
drop-down list. The options are:
• Immediate
• Once
• Daily
• Weekly
• Monthly
If you select any of the options other than Immediate:
a. Select the date from the date picker.
b. Specify the time from the drop-down lists.
Step 5 In the Job Description field, enter a description for the download job. This is
mandatory.
Step 6 Enter the E-mail ID in the E-mail field.
Step 7 Click Apply.
Step 8 Click Accept in the confirmation popup dialog box, to put your settings into
effect.
To exit without making changes, click Cancel.

7-8 78-16571-01
Viewing Activity Logs

Activity Log logs the jobs in Scheduled Downloads and Device Updates. It
displays the activities that are carried out using Software Center.
In the CiscoWorks Homepage, select Common Services > Software Center >
Activity Log.
The Activity Log page displays:
• Scheduled Job Details—Displays the details of scheduled jobs in the software
center.
• Event Log—Displays the logs of events in the software center.
To view Scheduled Job Details, click Scheduled Job Details in the TOC.
The Scheduled Job Details page appears with the following information:
• Job—Job ID.
• Date—Time and the date on which the job was executed.
• Applicable Products—Products to which the download is applicable.
To view the Event Log, click Event Log in the TOC. The Event Log page appears
with the following information:
• Product Name—Name of the product.
• Description—Summary of the activity.
• Date—Date and time when the operations were carried out.
• Event Type—Shows one of the following:
– Device Package Downloads
– Software Download
– Install Device Packages / Uninstall Device Packages
• Status—Status of the event (Completed Successfully, Failed or executed).

78-16571-01 7-9

7-10 78-16571-01
C H A P T E R 8
Diagnosing Problems With
CiscoWorks Server
Use these tools and suggestions to diagnose problems with the

CiscoWorks server:
• Verifying Server Status
• Testing Device Connectivity
• Troubleshooting the CiscoWorks Server
• Troubleshooting Suggestions
Verifying Server Status

There are several tools that enable you to gather and analyze information about
your CiscoWorks Server. See Table 8-1 and Table 8-2.
Table 8-1 Server Status
Task Purpose Action

Administrative Tasks
Perform self test. Runs self-tests and generates a Select Server > Admin > Self Test.
report with the results.

78-16571-01 8-1
Chapter 8 Diagnosing Problems With CiscoWorks Server
Table 8-1 Server Status (continued)
Task Purpose Action

All Users
Check process status. Checks whether back-end Select
processes are in an interim Server > Admin > Processes.
state.
Collect server Provides system information, Select
information. environment, configuration,
Server > Admin > Collect Server
logs, and web server
Information
information.
or
Enter the following command:
• On Windows:
NMSROOT\bin\collect.info
• On Solaris:
$NMSROOT/bin/collect.info
where NMSROOT and $NMSROOT are the
directories where you installed CiscoWorks,
in Windows and Solaris respectively.

8-2 78-16571-01
Task Purpose Action

MDC Support The MDC Support utility For Windows go to,
collects log files, configuration
NMSROOT\MDC\bin and execute the
settings, memory info,
command:
complete system related info,
process status and host MDCSupport.exe
environment information.
The utility creates a tar file in
It also collects any other
NMSROOT\MDC\etc directory.
relevant data, into a deliverable
tar (compressed form) file to If \etc directory is full, or if you want to
support the MDCs installed. preserve the data collected previously by not
over writing the tar file, you may create
The MDC Support utility also another directory by running the following
queries CCR for any other command:
support utilities registered, and
run them. MDCSupport.exe Directory
Other MDCs need to register

their own support utilities that For Solaris,
will collect their relevant data. /opt/CSCOpx/MDC/bin and execute the
command:
./mdcsupport
The utility creates a tar file in

CSCOpx/MDC/etc directory.

78-16571-01 8-3
Testing Device Connectivity
Task Purpose Action

MDCSupport If \etc directory is full, or if you want to
(Continued) preserve the data collected previously by not
over writing the tar file, you may create
another directory by running the following
command:
./mdcsupport Directory
Before you close the command window,
ensure that the MDC Support utility has
completed its action.
If you close the window prematurely, the
subsequent instances of MDCSupport Utility
will not function properly.
If you happen to close the window, delete the
mdcsupporttemp directory from
NMSROOT\MDC\etc directory, for
subsequent instances to work properly.

The connectivity tools enable you to test device connectivity and reachability and
troubleshoot nonresponsive devices. Some connectivity tools require system
administrative-level privileges (see Connectivity Tools Tasks Table 8-2).

8-4 78-16571-01
Table 8-2 Connectivity Tools Tasks
Task Purpose Action

Traceroute. Detects routing errors between the Select
network management station and a
Device Center > Tools > Traceroute.
target device.
See “Using Traceroute” section on page 6-9,
for details.
Ping a Tests device reachability using an Select
device. ICMP echo message and its reply.
Device Center > Tools > Ping
See “Using Ping” section on page 6-8, for
details.
Check Checks the connectivity between the Select
Management CiscoWorks Server and a device.
Device Center > Tools > Management Station
Station to
to Device
Device
See “Checking Device Connectivity” section
on page 6-6, for details.
Packet Captures live data from the CiscoWorks Select
Capture. machine to aid in troubleshooting.
Device Center > Tools > Packet Capture
See “Using Packet Capture” section on
page 6-12, for details.
To set an Sets an SNMP object on a device for Select
SNMP object purposes of controlling the device.
Device Center > Tools > SNMP Set
on a device.
See “Using SNMP Set” section on page 6-11,
for details.
To walk the Walks the MIB tree of a device starting Select
MIB tree of a from a given OID for troubleshooting, Device Center > Tools > SNMP Walk
device. or gathering information about a
device. See “Using SNMP Walk” section on page 6-9,
for details.

78-16571-01 8-5
Troubleshooting the CiscoWorks Server
Troubleshooting the CiscoWorks Server

This section provides information on frequently asked questions (FAQs) and
suggestions for troubleshooting the CiscoWorks Server components.
If the suggestions do not resolve the error, check the Release Notes supporting
your platform for possible workarounds, or contact the Cisco TAC or your
customer support.
Frequently Asked Questions

• When I connect to the CiscoWorks Server in the secure mode (HTTPS) using
Netscape Navigator, the browser returns I/O errors and displays the message
Netscape has encountered bad data from the server. Why
does this happen?
• When I invoke CiscoWorks in the secure mode (HTTPS), there are too many
dialog boxes. This makes the process tedious. Is there a way to reduce the
number of dialog boxes and steps?
• When I invoke CiscoWorks, I'm unable to get to the login page directly.
Instead, I'm facing a security alert related to the site's security certificate. It
asks for my input to proceed further. Why?
• My server certificate for CiscoWorks has expired. What should I do?
• I installed CD One and got an error message that EDS was not registered with
the daemon manager. Did I do anything wrong?
• Which version of the Java Plug-in should I use for CiscoWorks to function
properly?
• Is there anything I should do before I invoke Netscape Navigator sessions in
UNIX systems to run CiscoWorks?
• Why do some CiscoWorks applications not appear in the product?
• Why can’t I start my CiscoWorks application?
• What kind of directory structure does CiscoWorks use when backing up data?
• I’m locked out of the CiscoWorks Server. Why did this happen, and how do I
regain access?
• What if the database is inaccessible?

8-6 78-16571-01
• How do I change the port for osagent in Windows?

• How do I change port for osagent in Solaris?
• How do I change the ESS port in Solaris?
• How do I change ESS port in Windows?
• I have configured the Active Directory Login Module but it does not work.
How can I analyze the problem?
• How do I change the IP Address of the CiscoWorks Server after installing it,
or after running it for a while?
• How do I change the Hostname of the CiscoWorks Server after installing it,
• How do I find out which devices are supported by a particular application?
• How do I verify if SSH is enabled or disabled on my device using CiscoWorks
Server?
• How do I verify if SSH is enabled or disabled on my device using CiscoWorks
Server?
• How to verify which version of SSH is running on my system?
• Is it possible to have both CiscoWorks and ACS on the same machine?
• How do I change the casuser password?
• How do I change the CiscoWorks user password?
• How do I enable/disable ACS Communication on HTTPS from CLI?
• How do I change web server port numbers?
• Ho do I increase Tomcat heap size?
• How do I enable debugging in MICE?
• What does cmf stand for?

78-16571-01 8-7
Q. When I connect to the CiscoWorks Server in the secure mode (HTTPS) using
Netscape Navigator, the browser returns I/O errors and displays the message
Netscape has encountered bad data from the server. Why does this
happen?
A. This problem occurs when you:
• Create a new server certificate using the same hostname
• Set the browser to accept the old server certificate, till it expires
Typically, this problem is fixed when you clear the entry for your old server
certificate from the browser.
Note The I/O errors in Netscape Navigator running in secure mode (HTTPS) is
often caused by configured certificates in the client computer.
Q. When I invoke CiscoWorks in the secure mode (HTTPS), there are too many
dialog boxes. This makes the process tedious. Is there a way to reduce the
number of dialog boxes and steps?
A. Yes. You have the following options:
• If you are using self-signed certificates:
– In Netscape Navigator, select the option Accept the Server Certificate
forever (until it expires) in the New Site Certificate wizard, if you are
confident about the identity of the server.
– In Internet Explorer, install the certificate in the browser’s trusted
certificate stores, if you are confident about the identity of the server.
• Use a server certificate issued by a prominent third party certificate authority
(CA).
• Configure the hostname in your server certificate properly, and use the same
hostname to invoke CiscoWorks.

8-8 78-16571-01
Q. When I invoke CiscoWorks, I'm unable to get to the login page directly.
Instead, I'm facing a security alert related to the site's security certificate. It
asks for my input to proceed further. Why?
A. CiscoWorks does not have any control over this behavior. This is an expected
browser behavior (Microsoft Internet Explorer or Netscape Navigator), to
ensure proper security.
This appears if one of the when one of the following conditions is not satisfied:
– The certificate of the server (CiscoWorks Server in this case) must be
issued by trusted Certificate Authority.
– The date of the certificate must be valid. (Each certificate is assigned a
validity period. It can range from 21 days to 5 years).
– The name of the certificate and name of the page (or the name typed in
the address bar of the browser) are the same.
To view the certificate information:
• Click View Certificate, in the alert box for Internet Explorer.
• Click Examine Certificate in the alert box for Netscape Navigator.
The server should be invoked with the name same as the Issued to' field of the
certificate.
To install the certificate in Internet Explorer:
Step 1 Click View Certificate in the alert box.

The Certificate dialog box displays the Certificate information.
Step 2 Click Install Certificate.
For Netscape Navigator, you may select the Accept this Certificate Permanently
radio button in the security alert dialog box.

78-16571-01 8-9
Q. My server certificate for CiscoWorks has expired. What should I do?

A. If you are using a self-signed certificate, you can create a new certificate
using the Create Self Signed Certificate option. For more information, see
“Creating Self Signed Certificate” section on page 3-9.
If you are using a third party issued certificate, you must contact the certificate
authority (CA) and renew the certificate. You can use a self-signed certificate till
you get the certificate renewed by the CA.
Note Before you perform any certificate management operations—creating or

modifying certificates, back up the certificate files, the server private key in
particular, and keep them in a safe location.
Q. I installed CD One and got an error message that EDS was not registered with
the daemon manager. Did I do anything wrong?
A. EDS is part of the CD One deliverable but is not enabled without Campus
Manager or Resource Manager Essentials. If you are going to install either of
these application suites, EDS will be automatically enabled after installation.
Q. Which version of the Java Plug-in should I use for CiscoWorks to function
properly?
A. CiscoWorks supports Java Plug-in 1.4.2_04 only in all the supported clients
and operating systems. We recommend that you do not install any other
Plug-ins other than this one, for CiscoWorks to function properly.
Q. Is there anything I should do before I invoke Netscape Navigator sessions in

UNIX systems to run CiscoWorks?
A. Yes. You must source the file /jpi.cshrc before invoking any Netscape session
in UNIX systems, so that the environment is set for the browser to function
properly on invoking CiscoWorks.

8-10 78-16571-01
Q. Why do some CiscoWorks applications not appear in the product?

A. The CiscoWorks Server represents a common set of management services
which are shared by multiple network management applications. These
services are enabled when a suite is installed and an application that relies on
a particular service enables it.
If a particular suite of applications does not use a particular service, the
service might not appear on the CiscoWorks Homepage. Applications and
application suites may not use these features at all, or to the fullest extent.
See the User Guide for your application suite to determine the extent to which
these features are used.
Q. Why can’t I start my CiscoWorks application?

A. If you cannot start your CiscoWorks application and get error messages
complaining that the WebServer might not be running. This may occur
although pdshow indicates that those processes are up and running. You
might need to check how your machine is resolving its server name and IP
address.
The CiscoWorks CORBA applications require name resolution to work
properly. Domain Name Service (DNS) is a must for CiscoWorks CORBA
applications to work properly.
Configure the name resolution mechanism and restart the CiscoWorks Server
to access the application correctly.
Q. What kind of directory structure does CiscoWorks use when backing up data?
A. CiscoWorks uses a standard database structure for backing up all suites and
applications. See Table 8-3 for sample directory structure for the CiscoWorks
Server.
Table 8-3 Sample Backup Directory
Directory Path Description Usage Notes

/tmp/1 Number of backups 1, 2, 3...
/tmp/2/cmf Application or suite Backs up CiscoWorks Server
applications.

78-16571-01 8-11
Table 8-3 Sample Backup Directory (continued)
Directory Path Description Usage Notes

/tmp/1/cmf/filebacku CiscoWorks Server Application data is stored in
p.tar application tar files the datafiles.txt which are
compiled into the tar file.
/tmp/1/cmf/database CiscoWorks Server Includes files for each
database directory database:
xxx_DbVersion.txt
xxx.db database files
xxx.log database log files
xxx.txt database backup
manifest file
Q. I’m locked out of the CiscoWorks Server. Why did this happen, and how do I
regain access?
A. There are several reasons why you might have been locked out. Most likely it
is due to the changes made using the Select Login Module option. You must
replace the incorrect login module with a default configuration, log into
CiscoWorks, and return to the login module to correct one or more of the
following:
• Session Time out
• Change from SSL mode to non-SSL mode
• Change from non-SSL mode to SSL mode
• Log out from any other CiscoWorks application
• Visit other sites and then return to CiscoWorks
Do not alter the existing technologies in the default configuration file.
If all of the parameters listed are correct, see the “Troubleshooting Suggestions”

8-12 78-16571-01
Q. What if the database is inaccessible?

A. If the server is not able to connect to the database, the database might be
corrupt or inaccessible. This can occur if processes are not running. Try the
following:
Step 1 Log in to CiscoWorks as admin.

Step 2 Select Server > Admin > Process to get a list of CiscoWorks back-end processes
that have failed.
Step 3 Select Server > Admin > Self Test.
• Click Create to create a report.
• Click Display to display the report.
Step 4 Select Server > Admin > Collect Server Information.
Step 5 Click the Product Database Status link to get detailed database status.
Step 6 Contact the Cisco TAC or your customer support to get the information you need
to access the database and find out details about the problem. After you have the
required information, perform the following tasks for detecting and fixing
database errors.
Depending upon the degree of corruption, the database engine may or may not
start. For certain corruptions, such as bad indexes, the database can function
normally until the corrupt index is accessed.
Database corruptions, such as index corruptions, can be detected by the dbvalid
utility, which requires the database engine to be running.
To detect database corruption:
Step 1 Log on as root (UNIX) or with administrator privileges (Windows).

Step 2 Stop the Daemon manager if it is already running:
• UNIX—/etc/init.d/dmgtd stop
• Windows—net stop crmdmgtd (enter this command in an MS-DOS window)

78-16571-01 8-13
Step 3 Make sure no database processes are running and there is no database log file. For
example, if the database file is /opt/CSCOpx/databases/rme/rme.db, the database
log file is /opt/CSCOpx/databases/rme/rme.log. This file is not present if the
database process shuts down cleanly.
Step 4 (UNIX only) Check if the database files(s) and the transaction log file (*.log) are
owned by user casuser. If not, change the ownership of these files to user casuser
and group casusers.
Step 5 Run the command:
cd NMSROOT/objects/db/conf
NMSROOT/bin/perl configureDb.pl action=validate dsn=<cmf>
The dbvalid command displays a list of tables being validated. The Validation
utility scans the entire table, and looks up each record in every index and key
defined on the table. If there are errors, the utility displays something like:
Validating DBA.xxxx
run time SQL error -- Foreign key parent_is has invalid or duplicate
index
entries 1 error reported
If the above command reports any error, you may try:

• Restoring from a previous good backup
or
• Reinitializing database
Caution All the current data will be lost.
To do this, you have to run the following command:

NMSROOT\bin\perl NMSROOT\bin\dbRestoreOrig.pl dsn=dsn
dmprefix=dmprefix
For Common Services, dsn is cmf and dmprefix is Cmf.

8-14 78-16571-01
Q. How do I ensure that jrm is running fine?

A. To check whether jrm is working on Windows, at the command prompt enter:
cwjava -cw NMSROOT com.cisco.nm.cmf.jrm.jobcli
To check whether jrm is working on Solaris, at the command prompt enter

cwjava -cw $NMSROOT com.cisco.nm.cmf.jrm.jobcli
• If you get a message Established connection with JRM, then EDS,

EDS-GCF and jrm are running.
• If you do not get the above message, contact the technical assistance center
with the error message.
• If your jrm in down or inaccessible, you’ll get a message while accessing the
UIs.
Q. How do I change the port for osagent in Windows?

A. To change the port for osagent in Windows:
Step 1 Backup your Windows registry.

Step 2 In the Registry Editor, navigate to HKEY_LOCAL_MACHINE > SOFTWARE
> Cisco > Resource Manager > Current Version > Daemon > RmeOrb
Step 3 Change the value of Args from -p 42342 to an unused port number, for example
-p 44444.
Step 4 Navigate to HKEY_LOCAL_MACHINE > SOFTWARE > Cisco > Resource
Manager > Current Version > Daemon > RmeGatekeeper
Step 5 Change the value of Args from
-DNMSROOT=NMSROOT -DORBagentPort=42342
com.visigenic.vbroker.gatekeeper.GateKeeper -props
NMSROOT\lib\visigenics\gatekeeper.cfg
to
-DNMSROOT=NMSROOT -DORBagentPort=44444
com.visigenic.vbroker.gatekeeper.GateKeeper -props
NMSROOT\lib\visigenics\gatekeeper.cfg
Step 6 Navigate to HKEY_LOCAL_MACHINE > SOFTWARE > Cisco > Resource
Manager > Current Version > Environment:

78-16571-01 8-15
Step 7 Change the value of OSAGENT_PORT and PX_OSA_PORT from

42342 to 44444.
Step 8 Open the file NMSROOT\lib\classpath\md.properties, in any plain text editor,
such as Notepad.
Step 9 Change the value of OSAGENT_PORT and PX_OSA_PORT from
42342 to 44444.
Step 10 Reboot the server.
NMSROOT is the installation directory for CiscoWorks Server.
Q. How do I change port for osagent in Solaris?

A. To do this:
Step 1 Stop daemons.

Step 2 Make sure that no CSCO processes are running.
Step 3 Make sure all ports used by CiscoWorks are free.
To do this, enter:
netstat -na | grep 423
If these ports are free, you will not see any output.
Step 4 Verify whether the port 44444 is free, using the following command:
If the port is free, you will not see any output.

Step 5 Back up $NMSROOT/objects/dmgt/dmgtd.conf file.

8-16 78-16571-01
Step 6 Edit the file dmgtd.conf using a text editor.

a. Change the line:
RmeOrb y - $NMSROOT/lib/vbroker/bin/osagent -p 42342 to RmeOrb y -
$NMSROOT/lib/vbroker/bin/osagent -p 44444
b. Change the port number for RmeGatekeeper from:
RmeGatekeeper y RmeOrb $NMSROOT/lib/vbroker/bin/rungk.sh 42342
to
RmeGatekeeper y RmeOrb $NMSROOT/lib/vbroker/bin/rungk.sh 44444
Step 7 Open the file /etc/services in a plain text editor such as vi.
Step 8 Comment out the entry for CSCOsa port and add the following entry:
cscoosa 44444/udp # CSCO NM osagent
Note The change is for the port number only.
Step 9 Open /var/sadm/pkg/CSCOmd/pkginfo in a plain text editor, such as vi.

• Change the entry from
OSAGENT_PORT= 42342
to
OSAGENT_PORT=44444
• Change the entry from
PX_OSA_PORT=42342
to
PX_OSA_PORT=44444
Step 10 Restart the daemons. We recommend that you also reboot the server.
Q. How do I change the ESS port in Solaris?

A. There are 4 ports related to ESS:
• ESS Service Port: 42350/udp
• ESS listening port: 42351/tcp
• ESS HTTP Port: 42352/tcp
• ESS Routing Port: 42353/tcp

78-16571-01 8-17
The ports mentioned above are default ports. The alternative ports defined for
these in CiscoWorks are 44350, 44351, 44352, 44353 respectively.
To change the ports:
Step 1 Open the file $NMSROOT/objects/ess/conf/essproperties.conf in a plain text

editor, such as vi.
Step 2 Change the port numbers as required.
Step 3 Reboot the system.
Q. How do I change ESS port in Windows?

A. To do this:
Step 1 Back up your Windows registry.

Step 2 In the Registry Editor, navigate to HKEY_LOCAL_MACHINE >SOFTWARE
> Cisco > Resource Manager > Current Version > Daemon > ESS
Step 3 Change the value of Args from
NMSROOT\objects\ess\conf\rvrd.conf -logfile
-store
NMSROOT\log\ess.log -listen 42351 -no-http
to
-store NMSROOT\objects\ess\conf\rvrd.conf -logfile NMSROOT\log\ess.log
-listen 42351 -no-http
Step 4 Change the corresponding entry in

NMSROOT\objects\ess\conf\essproperties.conf.
Step 5 Reboot the server.

8-18 78-16571-01
Q. I have configured the Active Directory Login Module but it does not work.
How can I analyze the problem?
A. To analyze the problem, enable the Debug mode for the Active Directory
Login module. To do this:
Step 1 Login as Admin.

Step 2 Go to Server > Security > AAA Mode Setup.
The Select Login Module dialog box appears.
Step 3 Select a login module from the Available Login Modules list box and Click on
Edit Options.
The Login Module Options dialog box appears.
Step 4 Select the radio button True and click on Finish.
This enables the Debug option. Enabling debug mode allows the login module to
add the detailed progress and failure information to log files. The log files are
located at:
CSCOpx/MDC/Tomcatlogs/stdout.log
For all failed login attempts, the log files contain LDAP error messages, which
specify the reason for the failure.
For example, if the Usersroot configuration is incorrect, then the login module
cannot match the complete DN string with any entries in the Active Directory
database.
It indicates which portion of the DN matched and which portion did not match.
You can verify your Active Directory setup and the entries for the Usersroot.
In some cases, the log file contains error messages with NameError. This indicates
that either you entered a wrong user Id or there is some spelling error in the
Usersroot configuration.

78-16571-01 8-19
Q. How do I change the IP Address of the CiscoWorks Server after installing it,
A. You can change the IP address on the server, and then access it using the new
IP address.
To change the IP address on Windows:
Step 1 Click Start > Settings > Network and Dial-up Connections > Local Area
Connection.
The Local Area Connection Status dialog box appears.
Step 2 Click Properties.
The Local Area Connection Properties dialog box appears.
Step 3 Select Internet Protocol (TCP/IP) and click Properties.
The Internet Protocol (TCP/IP) Properties dialog box appears.
Step 4 Select the radio button Use the following IP address.
Step 5 Change the IP address as required, in the IP Address field.
For the subnet mask and default gateway values, use the command ipconfig at the
command prompt.
The subnet mask and default gateway values appear.
Step 6 Enter these values in the subnet mask and default gateway fields.
Step 7 Click OK.
Step 8 Restart the server.
To change the IP address on Solaris, use the command ifconfig at the command
prompt to change the IP address of the required interface.
For example, at the command prompt, you can enter:
ifconfig interfacename inet ipv4address
where the variable interfacename represents the name of the interface and
ipv4address represents the new IP address.

8-20 78-16571-01
Q. How do I change the Hostname of the CiscoWorks Server after installing it,
A. To change the hostname of the CiscoWorks Server, you need to update several
files, and reboot the server:
Step 1 Change the hostname at My Computer > Properties > Network Identification
> Properties.
Step 2 Change the hostname in all the following files:
Bundle Solaris Windows

LMS Bundle • hosts • md.properties file
• hostname.hme0
• nodename
• md.properties
• pkginfo
For Solaris, the sys-unconfig command erases the hostname and IP addresses
pertaining to the Solaris system (not the LMS or SMS software) and guides you
through the server-renaming process.
You also do this when you change the hostname in the hosts, hostname.hme0, and
nodename files in the /etc directory.
Step 3 Change the hostname in registry entries in the CurrentControlSet.
Step 4 Change the hostname in regdaemon.xml ($NMSROOT/MDC/etc/regdaemon.xml)
Step 5 Create a file /NMSROOT/conf/cmic/changehostname.info, with the info of the
updated hostname in the format:
OldhostName:NewhostName
OldhostName—Previous Hostname as registered with CCR(regdaemon.xml)
NewhostName—Current Hostname as registered with CCR(regdaemon.xml)
Both are case sensitive.

78-16571-01 8-21
Step 6 Delete gatekeeper.ior file:

Windows—NMSROOT\www\classpath
Solaris—/opt/CSCOpx/www/classpath
Step 7 Reboot the Machine.
If the hostname of the machine changes, the stability of the system is not
guaranteed and it fails in some cases. See Release Notes for CiscoWorks Common
Services for details.
Q. How do I find out which devices are supported by a particular application?

A. Select Common Services > Software Center > Software Updates Under
Applications Installed, click the application name to see a list of the
supported devices.
Q. How do I verify if SSH is enabled or disabled on my device using CiscoWorks

Server?
A. To verify whether SSH is enabled or disabled using the CiscoWorks Server:
Step 1 Log on to the CiscoWorks.

Step 2 Select Common Services > Device Center >Tools > Management Station to
Device.
Step 3 In the Check Connectivity dialog box, enter the device name and select the SSH
check box.
If SSH enabled on the device, you will see:
SSH OK.
If SSH is not enabled on the device, you will see:

SSH failed.

8-22 78-16571-01
Q. How to verify which version of SSH is running on my system?

A. You can verify the SSH version that is running on your system using the
commands:
From the Command Line Interface, enter:
show ip ssh
or
show ssh
Q. Is it possible to have both CiscoWorks and ACS on the same machine?

A. No. This is because ACS mandates CiscoWorks to be configured as an
AAA client in it for CiscoWorks to avail AAA service. At the same time, ACS
does not allow itself to be configured as an AAA client, which is required
when ACS and CiscoWorks coexists. Hence the configuration required for
ACS integration will fail.
Q. How do I change the casuser password?

A. You can change the casuser password using resetCasuser.exe. It can be
executed only by an administrator or casuser. To change the casuser
password, do the following:
Step 1 At the command prompt, enter:

NMSROOT\setup\support resetCasuser.exe
You are provided with three options:

1. Randomly generate the password
2. Enter the password
3. Exit.
Step 2 Enter 2, and press Enter.
It prompts you to enter the password.

78-16571-01 8-23
Step 3 Confirm the password.
Note You must know the password policy. If the password entered does not
match the password policy, it exits.
Q. How do I change the CiscoWorks user password?

A. You can change the CiscoWorks user password using the CiscoWorks user
password recovery utility.
To change the user password on Solaris:
Step 1 Enter /etc/init.d/dmgtd stop to stop the Daemon Manager.

At the command prompt, enter NMSROOT\bin resetpasswd username
Step 2 A message appears:
Enter new password for username:
Step 3 Enter the new password.

Step 4 Enter /etc/init.d/dmgtd start to start the Daemon Manager.
To change the user password on Windows:
Step 1 Enter net stop crmdmgtd to stop the Daemon Manager.

Step 2 At the command prompt, enter NMSROOT\bin resetpasswd <username>
Step 3 A message appears:

Enter new password for username:
Step 4 Enter the new password.

Enter net start crmdmgtd to start the Daemon Manager.

8-24 78-16571-01
Q. How do I enable/disable ACS Communication on HTTPS from CLI?

A. To enable/disable ACS communication on HTTPS:
Step 1 Enter $NMSROOT /bin/perl $NMSROOT/bin/camssl.pl
The following message is displayed:

Usage:camssl.pl -enable | -disable
• To enable ACS communication on HTTPS:

Enter $NMSROOT/bin/perl $NMSROOT/bin/camssl.pl -enable
• To disable ACS communication on HTTPS:

Enter $NMSROOT/bin/perl $NMSROOT/bin/camssl.pl -disable
Step 2 Restart the Daemon Manager:

On Windows:
Enter net stop crmdmgtd
Enter net start crmdmgtd
On Solaris:
Enter /etc/init.d/dmgtd stop
Enter /etc/init.d/dmgtd start
Q. How do I change web server port numbers?

A. To change the web server port numbers, you must execute separate commands
for both Windows and Solaris.
On Solaris:
You can change the web server port numbers for the webservers. You can also
change both the HTTP and HTTPS port numbers. To change the port numbers you
must login as CiscoWorks Server administrator, and run the following command
at the prompt:
/opt/CSCOpx/MDC/Apache/bin/changeport

78-16571-01 8-25
If you run this command without any command line parameter, CiscoWorks
displays:
*** CiscoWorks Webserver port change utility ***
where
-s —Changes the SSL port instead of the default HTTP port
-f —Forces port change even if Daemon Manager detection FAILS.
instructs you to.

changeport 1744—Changes the CiscoWorks web server HTTP port to use 1744.
Or,
443 (HTTPS). Also port 80 is not allowed for SSL port and port 443 is not
utility checks for active listening ports and ports listed in /etc/services. If any
conflict is found it rejects the specified port.
outside this range and non-numeric values are not allowed.
• If port 80 or 443 is specified for any of the webservers, that webserver process
is started as root. This is because ports lower than 1026 are allowed to be used
only by root in Solaris.
However, according to Apache behavior, only the main webserver process
runs as root, and all the child processes will run as casuser:casusers. Only the
child processes serve the external requests.

8-26 78-16571-01
The main process which runs as root monitors the child processes. It does not
accept any HTTP requests. Owing to this, Apache ensures that a root process
is not exposed to the external world and thus ensures security.
• If you do not want CiscoWorks processes to run as root, do not use the ports
80 and 443.
When you execute the utility with the appropriate options, it displays
messages on the tasks it performs.
This utility lists out all the files that are being updated. Before updating, the
utility will back up all the affected files in /opt/CSCOpx/conf/backup and
creates appropriate unique sub-directories.
It also creates a new file index.txt. This text file contains information about
the changed port and a list of all the files that are backed up and their actual
location in the CiscoWorks directory.
A sample backup maybe similar to:
/opt
|
`--/CSCOpx
|
`--/conf
|
`--/backup
|
|--README.txt (Note the purpose of this directory as it is initially empty)
|
`--/AAAtpaG03_Ciscobak (Autogenerated unique backup directory).
|
|--mdc_web.xml (Common Services application config file)
|--regdaemon.key (Common Services config registry key file)
|--regdaemon.xml (Common Services config registry data file)
|--rootapps.conf (CiscoWorks daemons using privileged ports)
|--services (The system /etc/services file)
|--ssl.properties (CiscoWorks config elements for SSL mode)
`--vms_web.xml (Common Services application config file)
Note All the above files and the unique directories are stored with read only permission
to casuser:casusers. To ensure the security of the backup files, only the
CiscoWorks Server administrator has write permissions.

78-16571-01 8-27
The change port utility displays messages to the console during execution. These
stored. These messages are also logged to a file, changeport.log
/var/adm/CSCOpx/log/changeport.log
This file contains the date and time stamps to indicate when the log entries were
created.
On Windows:
You can change the web server port numbers for the Common Services
Webserver. You can also change both the HTTP and HTTPS port numbers.
To change the port numbers you must have administrative privileges. Run the
following command at the prompt:
CSCOpx\MDC\Apache\changeport.exe
If you execute this utility without any command line parameter, CiscoWorks
displays the following usage text:
*** Common Services Webserver port change utility ***
where:
-s —Change the SSL port instead of the default HTTP port
-f —Force port change even if Daemon Manager detection fails.
instructs you to.

8-28 78-16571-01

changeport 1744 —to change the CiscoWorks web server HTTP port to use 1744.
Or,
Note If you change the port after installation, CiscoWorks will not launch from Start
menu (Start > Programs > CiscoWorks > CiscoWorks). You have to manually
invoke the browser and specify the URL, with the changed port number.

443 (HTTPS). Also port 80 is not allowed for HTTPS port and port 443 is not
utility checks for active listening ports and if any conflict is found the utility
rejects the specified port.
There is no reliable way to determine whether any other service or application is
using a specified port. If the service or application is running and actively
listening on a port, it can be easily detected.
However, if the service is currently stopped, there is no way that the utility can
determine what port it uses. This is because on Windows there is no common port
registry equivalent to /etc/services as in UNIX.
The port number must be a numeric value in the range 1026 – 65000. Values
outside this range and non-numeric values are not allowed.
When you execute the utility with the appropriate options, it displays messages
on the actions it is performing.
It lists out all the files that are being updated. Before updating, the utility will back
up all the affected files in CSCOpx\conf\backup and creates appropriate unique
sub-directories.
It also creates a new file index.txt, which contains information about the changed
port and a list of all the files that are backed up and their actual location in the
CiscoWorks directory.

78-16571-01 8-29

[drive:]
|
`--\Program Files
|
`--\CSCOpx
|
`--\conf
|
`--\backup
|
|--README.txt (Notes the purpose of this dir as it is initially empty)
|
`--\skc03._Ciscobak (Autogenerated unique backup directory).
|
|--mdc_web.xml (Common Services application config file)
|--regdaemon.key (Common Services config registry key file)
|--regdaemon.xml (Common Services config registry data file)
|--ssl.properties (CiscoWorks config elements for SSL mode)
`--vms_web.xml (Common Services application config file)
Note All the above files and the unique directories are stored with read only
permissions. Only the administrator and casuser have write permissions, to ensure
the security of the backup files.
The change port utility displays messages to the console during execution. These
stored. These messages are also logged to a file, changeport.log.
NMSROOT\log\changeport.log
This log file contains the date and time stamps to indicate when the log entries
were created.

8-30 78-16571-01
Q. Ho do I increase Tomcat heap size?

A. To increase Tomcat heap size:
Step 1 Stop Daemon Manager.

• On Solaris:
Run /etc/init.d/dmgtd stop
• On Windows:
Run net stop CRMdmgtd
Step 2 Run $NMSROOT/bin/perl $NMSROOT/bin/ModifyTomcatHeap.pl max heap

in MB
Step 3 Start Daemon Manager.
• On Solaris:
Run /etc/init.d/dmgtd stop
• On Windows:
Run net start CRMdmgtd
If Tomcat is already configured for higher memory than what you specify when
you run the command, it displays message stating this, and exits.

78-16571-01 8-31
Q. How do I enable debugging in MICE?

A. To enable debugging in MICE:
Step 1 Go to NMSROOT/MDC/tomcat/webapps/classic/WEB-INF/web.xml.
You have to edit the following section of the file:
<context-param>
<param-name>DEBUG</param-name>
<param-value>false</param-value>
<description>mice debug enabling</description>
</context-param>
Step 2 Change <param-value>false</param-value> to
<param-value>true</param-value>
Q. What does cmf stand for?

A. The cmf acronym stands for Common Management Foundation. This phrase
describes the set of management services provided by the CiscoWorks Server.
cmf is synonymous with Common Services.

8-32 78-16571-01
Troubleshooting Suggestions
Use the suggestions in Table 8-4 to resolve errors or other problems with the
CiscoWorks Server.
Table 8-4 Troubleshooting Suggestions
Symptom Probable Cause Possible Solutions

Authorization Incompatible browser Verify that you have Accept all cookies enabled.
required. Please log causing cookie failure Refer to the installation documentation for
in with your username (unable to retrieve supported Internet Explorer and Netscape
and password. cookie). Navigator software and setup procedures.
Daemon Manager could The operating system Make sure all CiscoWorks processes are terminated
not start. The port has not yet reallocated (/usr/ucb/ps -auxww | grep CSCO). Wait five to
is in use.
the port. ten minutes, then try to restart the Daemon
Manager.
User has forgotten his Common Services A system administrator-level user must either
password. cannot recover change the password or delete and then add the user
forgotten passwords. again.
You are logged out of Changes in the login 1. Log on as root.
the CiscoWorks Server. module configuration
2. On Windows:
file might not be
correct. Run NMSROOT/bin/ResetLoginModule.pl
Authentication server On Solaris:
might be down and Run opt/CSCOpx/bin/ResetLoginModule.pl
there were no fallback
logins set. 3. Restart Daemon Manager.
The Log File Status Files need to be backed 1. Stop all processes.
window displays files up so that file size will
2. Enter the log file maintenance command:
that exceed their limit. be reset to zero.
a. On UNIX: $NMSROOT/cgi-bin/admin/
b. On Windows: NMSROOT\
cgi-bin\admin\
3. Restart all processes.

78-16571-01 8-33
Table 8-4 Troubleshooting Suggestions (continued)

Error message in the Device is not SSH 1. Check whether the device is up or not.
logfile: Connection enabled or the server is
2. Try connecting to the device with a commercial
Refused. Check the not authorized to
SSH client.
Device is SSH initiate SSH
supported or not. connection. If you are able to connect, go to step 3.
If you are not able to connect, check whether
the device is running SSH enabled (K2 or K9)
image.
• If it is not the correct image, download the
appropriate image to the device.
• If you have the correct image, then see
whether you have created RSA key pairs in
the device. Creating RSA keys will enable
SSH in the device.
3. Check whether your server or network is
authorized to initiate SSH connections to
device.

8-34 78-16571-01
Table 8-4 Troubleshooting Suggestions (continued)

After installation, while Found Non-SSL Disable SSL from CLI and then start the daemon
starting the daemon compliant products manager.
manager, the following that do not function in
error message is SSL enabled mode.
displayed:
Found Non-SSL
compliant
Applications. Please
disable SSL and then
start the Daemon
Manager
(Solaris only)
After installation, while Found Non-SSL Disable SSL from CLI and then start the daemon
starting the daemon compliant products manager.
manager, the following that do not function in
error message is SSL enabled mode.
displayed:
Service Not
responded in a timely
fashion

78-16571-01 8-35

8-36 78-16571-01
A P P E N D I X A
Understanding CiscoWorks Security
The CiscoWorks Server provides some of the security controls necessary for a
web-based network management system. It also relies heavily on the end user’s
own security measures and controls to provide a secure computing environment
for CiscoWorks applications.
The CiscoWorks Server provides and requires three levels of security to be
implemented to ensure a secure environment:
• General Security—Partially implemented by the client components of
CiscoWorks and by the system administrator.
• Server Security—Partially implemented by the server components of
CiscoWorks and by the system administrator.
• Application Security—Implemented by the client and server components of
the CiscoWorks applications.
For more information on security related features see “Setting up Security”
The following sections describe the general and server security levels.

78-16571-01 A-1
Appendix A Understanding CiscoWorks Security
General Security
General Security
The CiscoWorks Server provides an environment that allows the deployment of
web-based network management applications.
Web access provides an easy-to-use and easy-to-access computing model that is
more difficult to secure than the standard computing model that only requires a
system login to execute applications.
The CiscoWorks Server also provides security mechanisms (authentication and
authorization) used to prevent unauthenticated access to the CiscoWorks Server
and unauthorized access to CiscoWorks applications and data.
However, CiscoWorks applications can change the behavior and security of your
network devices. Therefore, it is critical to limit access to applications and servers
as follows:
• Limit access to personnel who need access to applications or the data that the
applications provide.
• Limit CiscoWorks Server logins to just the systems administrator.
• Limit connectivity access to the CiscoWorks Server by putting it behind a
firewall.
Server Security
The CiscoWorks Server uses the basic security mechanisms of the operating
system to protect the code and data files that reside on the server. The following
CiscoWorks Server security control elements apply:
• Server–Imposed Security
• System Administrator-Imposed Security
Server–Imposed Security
The CiscoWorks Server has many dimensions, such as:
• Files, File Ownership, and Permissions
• Runtime

A-2 78-16571-01
Server Security
• Remote Connectivity
• Access to Systems Other Than the CiscoWorks Server
• Access Control
Files, File Ownership, and Permissions

The following describes the file ownership and permissions.
• UNIX Systems—CiscoWorks must be installed by a user with root privilege.
It should be installed as the user, casuser with a casusers group. If the system
administrator needs to work on causer files, a user with a name chosen by the
system administrator, must be created and added to the causers group.
All files and directories are owned by casuser with group equal to casusers.
Temporary files are created as the user casuser with permissions set to
read-write for the user casuser and read for members of group casusers.
The only exception to this rule is the log files created by the CiscoWorks web
server and diskwatcher. The CiscoWorks web server and diskwatcher must be
started as root. Therefore, their log files are owned by the user root with
“group=casusers.”
• Windows Systems—CiscoWorks must be installed by the administrator and
must be installed as the user casuser.
– If it is a new installation, the system displays a Yes/No message
prompting you to either create or to cancel the process. You can enter the
password or can be generated.
– If it is not a new installation, the system displays a Yes/No message
prompting you to either continue resetting the password or to retain the
old password.
The CiscoWorks Server uses the password but the casuser user is never
intended as a general user of the Windows system. No user is required to log
on the Windows system as casuser.
All files and directories are owned by the user casuser. Read and write access
are restricted to the user casuser and the administrator. Temporary files are
created as the user casuser with permissions set to read-write for the user
casuser.

78-16571-01 A-3
Server Security
The CiscoWorks Server relies on the security mechanisms of the NTFS

filesystem to provide access control on Windows systems. If CiscoWorks is
installed on a FAT filesystem, most security assumptions made about
controlled access to files and network management data are not valid.
Runtime
This describes the runtime activities.
• UNIX Systems—Typically CiscoWorks back-end processes are executed
with permissions set to the user ID of the binary file.
For example, if user “Joe” owns an executable file, it will be executed by the
CiscoWorks daemon manager under the user ID of “Joe”).
The exception are files owned by the root user ID. To prevent a potentially
harmful program from being executed by the daemon manager with root
permissions, the daemon manager will execute only a limited set of
CiscoWorks programs that need root privilege.
This list is not documented to preclude any user from trying to impersonate
these programs.
All back-end processes are executed with a umask value of 027. This means
that all files created by these programs are created with permissions equal to
“rwxr-x,” with an owner and group of the user ID and group of the program
that created it. Typically this will be “casuser” and “group=casusers.”
CiscoWorks foreground processes (typically cgi-bin programs or servlets) are
executed under the control of the web server’s child processes or the servlet
engine, which all run as the user casuser.
CiscoWorks uses standard UNIX tftp and rcp services. CiscoWorks also
requires that user casuser have access to the directories that these services
read and write to.
The CiscoWorks Server must allow the user casuser to run cron and at jobs
to enable the Resource Manager Essentials Software Management
application to run image download jobs.

A-4 78-16571-01
Server Security
• Windows—CiscoWorks back-end processes are executed with permissions

set to the user casuser. Some of the special CiscoWorks Server processes are
run as a service under the localsystem user ID.
These processes include:
– Daemon manager
– Web server
– Servlet engine
– Rcp/rsh service
– Tftp service
– Corba service
– Database engine
CiscoWorks foreground processes (typically cgi-bin programs or servlets) are
executed under the control of the web server and the servlet engine which all
run as the user localsystem.
The local system user has special permissions on the local system but does
not have network permissions.
CiscoWorks provides several services for RCP, TFTP communication with
devices. These services are targeted for use by CiscoWorks applications, but
can be used for purposes other than network management.
The CiscoWorks Server uses the at command to run software update jobs for
the Resource Manager Essentials Software Image Manager application. Jobs
run by the at command run with system level privileges.
Remote Connectivity
The remote connectivity details for Windows and Solaris are:
• UNIX Systems—The CiscoWorks daemon manager only responds to
requests to start, stop, register, or show status for CiscoWorks back-end
processes from the CiscoWorks Server.
• Windows Systems—The CiscoWorks daemon manager only responds to
requests to start, stop, register, or show status for CiscoWorks back-end
processes from the CiscoWorks Server.

78-16571-01 A-5
Server Security
Access to Systems Other Than the CiscoWorks Server

The access details for Solaris and Windows are:
• UNIX Systems—Systems used by the CiscoWorks Server as remote sources
of device information for importing into the Resource Manager Essentials
Inventory Manager application must allow the user casuser to perform remote
shell operations on the user who owns the device information.
• Windows Systems—Systems used by the CiscoWorks Server as remote
sources of device information for importing into the Resource Manager
Essentials Inventory Manager application, must allow the user casuser to
perform remote shell operations on the user who owns the device information.
Access Control
The access control details are:
• UNIX Systems—The UNIX user casuser is a user ID that is not typically
enabled for login.
Using this user ID as the user ID under which to install the CiscoWorks
Server software simplifies the installation process and ensures limited access
to the CiscoWorks Server. This is because casuser is not a valid login ID as
there is no password assigned to it.
However, the casuser user on UNIX systems is capable of performing system
and possibly network-wide operations that could be harmful to the system or
the network.
• Windows Systems—The user casuser, created as part of the install process,
has no special permissions or considerations on a system so it is a “safe” user
ID under which to execute the CiscoWorks Server and application code. The
localsystem user can perform harmful system operations.
Therefore, consider that by using the localsystem user ID to run some of the
backend processes, the localsystem user ID cannot perform network
operations.
Note The system administrator should review and adopt the security recommendations
in “System Administrator-Imposed Security” section on page A-7.

A-6 78-16571-01
Server Security
System Administrator-Imposed Security

To maximize CiscoWorks Server security, follow these security guidelines:
• Do not allow users other than the systems administrator to have a login on the
CiscoWorks Server.
• Do not allow the CiscoWorks Server file systems to be mounted remotely
with NFS or any other file-sharing protocol.
• Limit remote access (for example, FTP, RCP, RSH) to the CiscoWorks Server
to those users who are permitted to log in to the CiscoWorks Server.
• Place your network management servers behind firewalls to prevent access to
the systems from outside of your organization.
• Change the database password after installation and periodically based on
your company’s security policies.
• Back up the security certificates in a safe location, if you are using SSL in
CiscoWorks Server.
Connection Security
CiscoWorks Server uses Secure Socket Layer (SSL) encryption to provide secure
connection between the client browser and management server, and Secure Shell
(SSH) to provide secure access between the management server and devices.
Security Certificates
Security certificates are similar to digital ID cards. They prove the identity of the
server to clients. Certificates are issued by Certificate Authorities (CAs) such as
VeriSign® or Thawte. A certificate vouches for the identity and key ownership of
an individual, a computer system (or a specific server running on that system), or
an organization. It is a general term for a signed document.
Typically, certificates contain the following information:
• Subject public key value.
• Subject identifier information (such as the name and e-mail address).
• Validity period (the length of time that the certificate is considered valid).

78-16571-01 A-7
Server Security
• Issuer identifier information.

• The digital signature of the issuer, which attests to the validity of the binding
between the subject public key and the subject identifier information.
A certificate is valid only for the period of time specified within it. Every
certificate contains Valid From and Valid To dates, which are the boundaries of
the validity period.
For example, a user's certificate verifies that the user owns a particular public key.
The server certificate for the server named myserver.cisco.com verifies that a
specific public key belongs to this server.
Certificates can be issued for a variety of functions such as web user
authentication, web server authentication, secure e-mail (S/MIME), IP Security,
Transaction Layer Security (TLS), and code signing.
CiscoWorks Server supports security certificates for authenticating secure access
between client browser and management server.
CiscoWorks supports the following:
• Self signed certificates: CiscoWorks provides an option to create self-signed
certificates. For more information, see “Creating Self Signed Certificate”
Terms and Definitions

The following explains the terms and corresponding definitions in CiscoWorks:
• Secure Socket Layer (SSL)
• Public Key, Private Key
• Secure Shell (SSH)
• PKCS#8
• Base64- Encoded X.509 Certificate Format
• Certificate Authority
• CiscoWorks TrustStore or KeyStore

A-8 78-16571-01
Server Security
Secure Socket Layer (SSL)
Secure Socket Layer (SSL) is an application-level protocol that enables secure

transactions of data through privacy, authentication, and data integrity. It relies
upon certificates, public keys, and private keys.
Public Key, Private Key
Public and private keys are the ciphers used to encrypt and decrypt information.
While the public key is shared quite freely, the private key is never given out. Each
public-private key pair works together. Data encrypted with the public key can
only be decrypted with the private key.
Secure Shell (SSH)
Secure Shell (SSH) is an application and a protocol that provide a secure

replacement to the Berkeley r-tools. The protocol secures the sessions using
standard cryptographic mechanisms, and the application can be used similarly to
the Berkeley rexec and rsh tools.
Two versions of SSH are currently available: SSH Version 1 and SSH Version 2.
Common Services 3.0 supports SSH Version 1.
PKCS#8
Public-Key Cryptography Standards (PKCS) are a set of standards for public-key

cryptography, developed by RSA Laboratories in cooperation with an informal
consortium, originally including Apple, Microsoft, DEC, Lotus, Sun and MIT.
The PKCS have been cited by the OIW (OSI Implementers' Workshop) as a
method for implementation of OSI standards.
The PKCS are designed for binary and ASCII data; PKCS are also compatible
with the ITU-T X.509 standard. The published standards are PKCS #1, #3, #5, #7,
#8, #9, #10, #11, #12, and #15; PKCS #13 and #14 are currently being developed.
PKCS #8 describes a format for private key information. This information
includes a private key for some public-key algorithm, and optionally a set of
attributes.

78-16571-01 A-9
Server Security
Base64- Encoded X.509 Certificate Format
X.509 certificate format is an emerging certificate standard. It is part of the OSI

group of standards. X.509 certificates are very clearly defined using a notation
called ASN.1 (Abstract Syntax Notation 1) which specifies the precise kinds of
binary data that make up the certificate.
ASN.1 can be encoded in many ways, but the emerging standard is an encoding
called DER (Distinguished Encoding Rules), which results in a compact binary
certificate.
For e-mail exchange purposes the binary certificate is often Base64 encoded,
resulting in an ASCII text document that looks like the following:
-----BEGIN CERTIFICATE-----
MIIC4jCCAkugAwIBAgIEA0E1UDANBgkqhkiG9w0BAQBhMC
VVMxCzAJBgNVBAgTAkNBMREwDwYDVQQHEwhTYNQ2lz
Y28gU3lzdGVtczENMAsGA1UECxMERU1CVTEqMCgG0ZXN0
MiBDZXJ0aWZpY2F0ZSBNYW5hZ2VyMB4XDTAyMDas3DA4
NTgwOVowgYIxCzAJBgNVBAYTAklOMQswCQYDVQQIQ2hl
bm5haTEMMAoGA1UEChMDSENMMQ0wCwYDVQQLEtzZGlu
YWthci1wYzEhMB8GCSqGSIb3DQEJARYSc2RpbmFrYXfMA0G
CSqGSIb3DQEBAQUAA4GNADCBiQKBgQDV1o9PyO7txr5vme
FU/f9tp5To/HaLIWHVx9zpihPnVuKaepp8kcEXO8Sed8crXeU8BP
9qHoIswGn1oJEGFXm9gs5uupJyAgeDd6O9eCuQbiSKgE1sFGFSL
xNGQJZbCrQIDAQABo2UwYzARBglghkgBhvhCAQEEB/BAQD
-----END CERTIFICATE-----
CiscoWorks requires the Certificates to be uploaded in this format.
Note Other certificate formats such as PKCS#7 also have similar formats. Hence it is
important that you confirm with the CA the format of the certificate, and request
specifically for Base64 Encoded X.509Certificates formats.

A-10 78-16571-01
Server Security
Certificate Authority
A certificate authority (CA) is an authority in a network that issues and manages

security credentials and public keys for message encryption.
As part of a public key infrastructure (PKI), a CA checks with a registration
authority (RA) to verify information provided by the requestor of a digital
certificate. If the RA verifies the requestor's information, the CA then issues a
certificate.
CiscoWorks TrustStore or KeyStore
CiscoWorks TrustStore or KeyStore is the location where CiscoWorks maintains

the list of Certificates that it trusts.
In Windows: NMSROOT\lib\web\conf
In Solaris: $NMSROOT/objects/web/conf

78-16571-01 A-11
Server Security

A-12 78-16571-01
I N D EX
applications
A
Application panels in CWHP 2-6
access applications on another server 2-6
connection security, understanding A-7 traditional applications 2-7
control, security and A-6 licensing 3-68
adding devices to the device list 4-8 licensing information, viewing 3-70
for AUS management 4-10 licensing procedure 3-69
for cluster management 4-11 obtaining a license 3-68
for standard management 4-9 updating licenses 3-70
using dcrcli 4-39 registering with CWHP 2-8
administering troubleshooting
Common Services 3-51 applications not appearing 8-11
Daemon Manager, using 3-52 audience for this document xiii
process details, viewing 3-54 audit logs, viewing 3-49
processes, managing 3-53 AUS (Auto Update Server)
processes, starting 3-54 managing 4-24
processes, stopping 3-55 adding 4-24
DCA 4-26 deleting 4-25
Master-Slave configuration, editing 4-25
prerequisites 4-27
setting up 4-10
mode, changing 4-26
user-defined fields, adding 4-29
user-defined fields, deleting 4-31
user-defined fields, renaming 4-30

78-16571-01 IN-1
Index
CiscoWorks TrustStore or KeyStore A-11

B
PKCS#8 A-9
backing up data 3-55 public key, private key A-9
back-up data SSH A-9
directory structure of 8-11 SSL A-9
sample CMF backup directory 8-11 understanding A-7
restoring data 3-58 Cisco.com connection, managing 3-44
using CLI 3-57 CiscoWorks Homepage (see CWHP) 2-1
Base64-encoded X.509 certificate format, CiscoWorks Server, troubleshooting 8-1
definition A-10
collecting information on 8-2
browser-server security (see SSL) 3-2
FAQs 8-6
buttons on CWHP, using 2-8
locked out of 8-12
MDC support 8-3
C process status, checking 8-2

self-test, performing 8-1
cautions CiscoWorks Trust Store or KeyStore,
significance of xiv definition A-11
cautions regarding cmf as part of database path, explanation
of 8-12
admin password, guest password 3-5
Common Services Server, overview of 1-3
backups, and the CiscoWorks Daemon
Manager 3-78 connection security, understanding A-7
data restoration from a backup 3-58 security certificates A-7
restarting Daemon Manager on Solaris 3-52 terms and definitions A-8
restarting Daemon Manager on Base64-encoded X.509 certificate
Windows 3-53 format A-10
CD One error message, troubleshooting 8-10 CA (certificate authority) A-11
certificates CiscoWorks TrustStore or KeyStore A-11
terms and definitions in A-8 PKCS#8 A-9
Base64-encoded X-509 certificate public key, private key A-9
format A-10
CA (certificate authority) A-11

IN-2 78-16571-01
Index
SSH A-9
D
SSL A-9
connectivity Daemon Manager, using 3-52
Connectivity Tools Tasks (table) 8-5 restarting on Solaris 3-52
tasks 8-1 restarting on Windows 3-53
checking process status 8-2 database
collecting server information 8-2 inaccessible, troubleshooting 8-13
MDC support 8-3 path includes "cmf," explanation 8-12
performing a self-test 8-1 DCA (Device and Credential Admin) 4-1
testing 8-4 administering 4-26
CWHP (CiscoWorks Homepage) 2-1 Master-Slave configuration,
prerequisites 4-27
Common Services panel 2-5
mode, changing 4-26
configuring 2-8
user-defined fields, adding 4-29
registering applications 2-8
user-defined fields, deleting 4-31
registering links 2-11
user-defined fields, renaming 4-30
setting up 2-12
architecture 4-5
invoking 2-2
Master DCR 4-6
normal mode (HTTP) 2-2
Slave DCR 4-6
SSL Enabled mode (HTTPS) 2-3
Standalone DCR 4-6
logging in to Common Services 2-4
AUS management
online help, using 2-13
adding devices 4-24
using 2-5
deleting AUS 4-25
Application panels 2-6
editing devices 4-25
CiscoWorks Product Updates panel 2-7
CSV file samples 4-31
Common Services panel 2-5
CSV 2.0 4-31
Device Troubleshooting panel 2-7
CSV 3.0 4-32
Resources panel 2-7
devices, managing 4-7
toolbar buttons 2-8
adding 4-8
web server port numbers, changing 2-14
deleting 4-12

78-16571-01 IN-3
Index
excluding 4-21 Device Center 6-1

exporting 4-18 debugging tools, enabling 6-5
importing 4-14 device connectivity, checking 6-6
viewing the device list 4-22 packet capture 6-12
reports, generating 4-23 Ping, using 6-8
XML file sample 4-36 SNMP Set 6-11
DCR (Device and Credential Repository) CLI SNMP Walk, using 6-9
interface, using 4-39
Traceroute, using 6-9
adding devices 4-39
invoking 6-3
CDR mode, changing 4-42
launching 6-2
deleting devices 4-39
management functions
editing devices 4-40
management tasks 6-15
exporting using 4-44
reports, displaying 6-15
importing using 4-43
using 6-3
listing attributes 4-40
Device Selector 6-4
viewing current DCR mode 4-41
Device Summary 6-4
viewing device details 4-41
management functions 6-5
deleting
reports 6-15
AUS (Auto Update Server) 4-25
devices, managing 4-7
device groups 5-22
(see also Groups, administering) 5-1
devices
(see also Software Center) 7-1
from DCA 4-12
adding 4-8
from groups 5-19
for AUS management 4-10
from the device list, using dcrcli 4-39
for cluster management 4-11
peer server certificates 3-15
for standard management 4-9
user-defined fields from DCA 4-31
credentials
users 3-8
editing 4-13
Device and Credential Admin (see DCA) 4-1
exporting 4-18
importing 4-14

IN-4 78-16571-01
Index
deleting 4-12 ESS (Event Service Software)

device list, viewing 4-22 changing the port for
excluding 4-21 in Solaris 8-17
exporting 4-18 in Windows 8-18
using CLI 4-44 excluding devices from the device list 4-21
using DCA user interface 4-19 expired server certificate, how to handle 8-10
importing 4-14 exporting devices and credentials 4-18
using CLI 4-43 using CLI 4-44
using DCA user interface 4-15 using DCA user interface 4-19
Device Troubleshooting panel of CWHP 2-7
diagnosing problems (see troubleshooting) 8-1
F
documentation xiv
additional online xvi file ownership, and permissions A-3
audience for this xiii
related to this product xvi
typographical conventions in xiii
G
Groups, administering 5-1

concepts 5-2
E
common 5-4
editing container groups 5-3
AUS (Auto Update Server) 4-25 dynamic groups 5-3
device credentials in DCA 4-13 group hierarchy 5-2
device group details 5-20 secured views 5-6
devices in the device list, using dcrcli 4-40 shared 5-4
local user profile 3-6 static groups 5-3
user profiles 3-8 system-defined, user-defined 5-3
EDS (Event Distribution Service), creating 5-14
troubleshooting 8-10

78-16571-01 IN-5
Index
deleting
I
devices from groups 5-19
groups 5-22 IBM SecureWay Directory, changing login
module to 3-25
details
importing devices and credentials 4-14
modifying 5-20
using CLI 4-43
viewing 5-19
using DCA user interface 4-15
editing 5-20
Group Administration 5-14
membership, assigning 5-18 J
multi-server setup 5-7
properties, specifying 5-15 Java Plug-in, version to use 8-10
refreshing 5-22 jobs
rules, defining 5-17 managing 3-73
single server setup 5-7 jrm, checking 8-15
syntax checking 5-18

system- and user-defined attributes 5-23 K
KerberosLogin, changing login module to 3-27

H
help L
CiscoWorks Product Updates panel of
CWHP 2-7 licensing CiscoWorks applications 3-68
online, using 2-13 license information, viewing 3-70
online documentation xvi licensing procedure 3-69
obtaining a license 3-68
updating licenses 3-70
links, registering with CWHP 2-11
locked out of CiscoWorks Server,

IN-6 78-16571-01
Index
log files, maintaining 3-78

M
Log File Status report, generating 3-45
on UNIX 3-78 managing
on Windows 3-80 Common Services jobs 3-73
logrot utility, configuring 3-81 Common Services resources 3-76
logrot utility, running 3-82 messaging online users 3-72
logrot utility, using 3-81 MS Active Directory, changing login module
to 3-29
login module
multi-server mode, and security 3-10
fallback options for, understanding
ACS 3-43
non-ACS 3-35 N
setting to ACS 3-35
setting to non-ACS 3-24 Netscape Directory, changing login module
to 3-30
CiscoWorks Local, changing to 3-25
Netscape Navigator on UNIX systems,
fallback options, understanding 3-35 troubleshooting 8-10
IBM SecureWay Directory, changing
to 3-25
KerberosLogin, changing to 3-27 O
local NT system, changing to 3-29
online users, messaging 3-72
Local UNIX system, changing to 3-28
osagent, changing the port for
MS Active Directory, changing to 3-29
Solaris 8-16
Netscape Directory, changing to 3-30
Windows 8-15
Radius, changing to 3-32
overviews of
TACACS+, changing to 3-33
CiscoWorks Common Services 1-1
logrot utility
Common Services Server information 1-3
configuring 3-81
time zone settings, understanding 1-3
running 3-82
what’s new in this release 1-2
using 3-81
Common Services Server 1-3

78-16571-01 IN-7
Index
restoring backed-up data 3-58

P
runtime security, understanding A-4
packet capture, using 6-12
peer server certificates
deleting 3-15
S
setting up 3-14 Secure Shell (SSH), definition A-9
Permissions report, generating 3-46 security
PKCS#8, definition A-9 access control, and A-6
port numbers for web servers, changing 2-14 certificates, understanding A-7
preferences for system, modifying 3-83 understanding A-1
private key, definition A-9 general A-2
Process Status report, generating 3-48 server A-2
public key, definition A-9 security, setting up 3-1
AAA mode, setting up 3-20
authentication, about 3-21
R
Cisco.com login, setting up 3-44
Radius, changing login module to 3-32 Cisco Secure ACS support 3-22
remote connectivity, security and A-5 login module
reports fallback options, understanding 3-35
Common Services reports 3-45 setting to ACS 3-35
audit logs, viewing 3-49 setting to non-ACS 3-24
Log File Status report 3-45 multi-server mode 3-10
Permissions report 3-46 peer server certificates
Process Status report 3-48 deleting 3-15
Users Logged In report 3-47 setting up 3-14
DCA reports, generating 4-23 proxy server, setting up 3-44
Device Center reports 6-15 security levels, understanding 3-5
resources, managing in Common Services 3-76 self-signed certificates, creating 3-9
Resources panel of CWHP 2-7 single server mode 3-1

IN-8 78-16571-01
Index
SSL 3-2 restoring data 3-58

enabling from the CiscoWorks Server 3-2 server information, collecting 3-71
enabling from the CLI 3-4 Common Services authentication, about 3-21
SSO (Single Sign-On) mode log files, maintaining 3-78
changing 3-18 on UNIX 3-78
enabling 3-15 on Windows 3-80
user management login module
about user accounts 3-4 setting to ACS 3-35
local user profile, modifying 3-6 setting to non-ACS 3-24
peer server, setting up 3-11 login module fallback options, understanding
user profiles, editing 3-8 for ACS mode 3-43
users, adding 3-7 for non-ACS mode 3-35
users, deleting 3-8 peer server certificates
self-test information, collecting 3-72 deleting 3-15
server, configuring 3-1 setting up 3-14
AAA mode, setting up 3-20 proxy server, setting up 3-44
applications, licensing 3-68 reports, generating 3-45
licensing information, viewing 3-70 audit logs, viewing 3-49
licensing procedure 3-69 Log File Status report 3-45
obtaining a license 3-68 Permissions report 3-46
updating licenses 3-70 Process Status 3-48
Cisco.com login, setting up 3-44 Users Logged In 3-47
Cisco Secure ACS support 3-22 security (see security, setting up) 3-1
Common Services, administering 3-51 self-signed certificates, creating 3-9
backing up data 3-55 SSO (Single Sign-On) mode
Daemon Manager, using 3-52 changing 3-18
jobs, managing 3-73 enabling 3-15
processes, managing 3-53 system preferences, modifying 3-83
resources, managing 3-76 user accounts, about 3-4

78-16571-01 IN-9
Index
user management Solaris, changing ports in

adding 3-7 for ESS 8-17
deleting 3-8 for osagent 8-16
local user profile, modifying 3-6 SSL, enabling on the server 3-2
peer server, adding 3-11 from the CiscoWorks Server 3-2
user profile, editing 3-8 from the CLI 3-4
users, local, setting up 3-6 SSL, definition A-9
server certificate for CiscoWorks, expiration, SSO (Single Sign-On) mode
how to handle 8-10
changing 3-18
server information, collecting (Common
enabling 3-15
Services) 3-71
starting CiscoWorks applications,
server security, understanding A-2
administrator-imposed A-7
connection A-7
security certificates A-7 T
terms and definitions A-8
TACACS+, changing login module to 3-33
server-imposed A-2
technical support
access control A-6
CiscoWorks Product Updates panel of
files, file ownership, permissions A-3 CWHP 2-7
other systems A-6 terms and definitions in security
remote connectivity A-5 certificates A-8
runtime A-4 Base64-encoded X.509 certificate

format A-10
SNMP Set, using 6-11
CA (certificate authority) A-11
SNMP Walk, using 6-9
CiscoWorks TrustStore or KeyStore A-11
Software Center 7-1
PKCS#8 A-9
activity logs, viewing 7-9
public key, private key A-9
device downloads, scheduling 7-7
SSH A-9
device updates, performing 7-4
SSL A-9
packages, deleting 7-6
time zone settings, understanding 1-3
software updates, performing 7-2

IN-10 78-16571-01
Index
toolbar buttons on CWHP, using 2-8 suggestions 8-33

troubleshooting UNIX systems, and Netscape Navigator 8-10
(see also debugging tools under Device typographical conventions in this
Center) 6-5 document xiii
applications not appearing 8-11
back-up data, directory structure of 8-11
U
CiscoWorks applications, starting 8-11
CiscoWorks Server 8-1 UNIX systems
device connectivity, testing 8-4 changing login module to local UNIX
FAQs 8-6 system 3-28
locked out of, diagnosing 8-12 invoking Netscape Navigator on,

server status, verifying 8-1
log files, maintaining on 3-78
Server Tools Tasks (table) 8-1
user accounts
database
about 3-4
inaccessability 8-13
setting up
path includes "cmf" 8-12
Cisco.com 3-44
devices, with the Device Troubleshooting
panel of CWHP 2-7 local 3-6
EDS not registered with daemon Users Logged In report, generating 3-47
manager 8-10
ESS port change
Solaris 8-17
V
Windows 8-18 verifying CiscoWorks Server status 8-1
FAQs list 8-6 viewing
Java Plug-in, which version to use 8-10 application license information 3-70
jrm 8-15 audit logs 3-49
Netscape Navigator on a UNIX system 8-10 device list 4-22
osagent port change group details 5-19
Solaris 8-16 process details 3-54
Windows 8-15 Software Center activity logs 7-9

78-16571-01 IN-11
Index
web server port numbers, changing 2-14

what’s new in this release 1-2
Windows 2000 or Windows NT systems
changing the port
for ESS 8-18
for osagent 8-15
ensuring that jrm is running 8-15
log files, maintaining on 3-80

IN-12 78-16571-01

Huong Dan Su Dung Cisco Work

Uploaded by

Copyright:

Available Formats

Huong Dan Su Dung Cisco Work

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Huong Dan Su Dung Cisco Work

Uploaded by

Copyright:

Available Formats

User Guide for CiscoWorks

Common Services 3.0

Customer Order Number: DOC-7816571

User Guide for CiscoWorks Common Services

CHAPTER 1 Overview 1-1

User Guide for CiscoWorks Common Services

CHAPTER 2 Interacting With CiscoWorks Homepage 2-1

CHAPTER 3 Configuring the Server 3-1

User Guide for CiscoWorks Common Services

Setting up Browser-Server Security 3-2

User Guide for CiscoWorks Common Services

Changing Login Module to Local Unix System 3-28

User Guide for CiscoWorks Common Services

Backing Up Data 3-55

User Guide for CiscoWorks Common Services

CHAPTER 4 Managing Device and Credentials 4-1

User Guide for CiscoWorks Common Services

Administering Device and Credential Repository 4-26

User Guide for CiscoWorks Common Services

Implications of ACS Login Module on DCR 4-45

CHAPTER 5 Administering Groups 5-1

User Guide for CiscoWorks Common Services

CHAPTER 6 Using Device Center 6-1

CHAPTER 7 Working With Software Center 7-1

User Guide for CiscoWorks Common Services

CHAPTER 8 Diagnosing Problems With CiscoWorks Server 8-1

APPENDIX A Understanding CiscoWorks Security A-1

User Guide for CiscoWorks Common Services

This document describes CiscoWorks Common Services 3.0 and gives an

Variables you enter italic screen font

User Guide for CiscoWorks Common Services

Table 1 describes the product documentation that is available.

User Guide for CiscoWorks Common Services

Table 1 Product Documentation

Document Title Available Formats

User Guide for CiscoWorks Common Services

Table 2 describes the additional documentation that is available.

Table 2 Related Documentation

Document Title Available Formats

Additional Information Online

User Guide for CiscoWorks Common Services

User Guide for CiscoWorks Common Services

Obtaining Technical Assistance

Cisco Technical Support Website

User Guide for CiscoWorks Common Services

Submitting a Service Request

User Guide for CiscoWorks Common Services

Definitions of Service Request Severity

Obtaining Additional Publications and Information

User Guide for CiscoWorks Common Services

• Packet magazine is the Cisco Systems technical user magazine for

User Guide for CiscoWorks Common Services

User Guide for CiscoWorks Common Services

CiscoWorks Common Services (Common Services) represents a common set of

User Guide for CiscoWorks Common Services

User Guide for CiscoWorks Common Services

• Support for IPv6.

Understanding Time Zone Settings

Learning More About the Common Services

User Guide for CiscoWorks Common Services