huong dan su dung cisco work

Corporate HeadquartersCisco Systems, Inc.170 West Tasman DriveSan Jose, CA 95134-1706USAhttp://www.cisco.comTel: 408 526-4000

800 553-NETS (6387)Fax: 408 526-4100

User Guide for CiscoWorks Common Services 3.0CiscoWorks

Customer Order Number: DOC-7816571Text Part Number: 78-16571-01

http://www.cisco.com

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.

User Guide for CiscoWorks Common ServicesCopyright © 1998-2005 Cisco Systems, Inc. All rights reserved.

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)

78-16571-01

C O N T E N T 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

C H A P T E R 1 Overview 1-1

New Features 1-2

Understanding Time Zone Settings 1-3

Learning More About the Common Services 1-3

iiiUser Guide for CiscoWorks Common Services

Contents

C H A P T E R 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

C H A P T E R 3 Configuring the Server 3-1

Setting up Security 3-1

Managing Security in Single Server Mode 3-1

ivUser Guide for CiscoWorks Common Services

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

vUser Guide for CiscoWorks Common Services

78-16571-01

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

viUser Guide for CiscoWorks Common Services

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

viiUser Guide for CiscoWorks Common Services

78-16571-01

Contents

C H A P T E R 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

viiiUser Guide for CiscoWorks Common Services

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

ixUser Guide for CiscoWorks Common Services

78-16571-01

Contents

Implications of ACS Login Module on DCR 4-45

Custom Roles and DCR 4-45

C H A P T E R 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

xUser Guide for CiscoWorks Common Services

78-16571-01

Contents

C H A P T E R 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

C H A P T E R 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

xiUser Guide for CiscoWorks Common Services

78-16571-01

Contents

C H A P T E R 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

A P P E N D I X 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

IN D E X

xiiUser Guide for CiscoWorks Common Services

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.

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

ConventionsThis 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

xiiiUser Guide for CiscoWorks Common Services

78-16571-01

Preface Product Documentation

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.

Product 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 1 describes the product documentation that is available.

Selecting a menu item in paragraphs Option > Network Preferences

Selecting a menu item in tables Option > Network Preferences

Item Convention

xivUser Guide for CiscoWorks Common Services

78-16571-01

Preface Product Documentation

Table 1 Product Documentation

Document Title Available Formats

Release Notes for CiscoWorks Common Services 3.0

• Printed document that was included with the product.

• On Cisco.com at:http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/cw2000_d/comser30/relnotes/index.htm

Installation Guide for CiscoWorks Common Services 3.0 on Windows

• PDF on the product CD-ROM.

• 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

1. See the “Obtaining Documentation” section on page xvi

Installation Guide for CiscoWorks Common Services 3.0 on Solaris


• On Cisco.com at:http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/cw2000_d/comser30/ig_sol/index.htm


User Guide for CiscoWorks Common Services 3.0 (this document)


• On Cisco.com at:http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/cw2000_d/comser30/usrguide/index.htm


Context-sensitive online help • Select an option from the navigation tree, then click Help.

• Click the Help button in the dialog box

xvUser Guide for CiscoWorks Common Services

78-16571-01

http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/cw2000_d/comser30/relnotes/index.htm

http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/cw2000_d/comser30/ig_win/index.htm

http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/cw2000_d/comser30/ig_sol/index.htm

http://www.cisco.com/univercd/cc/td/doc/product/rtrmgmt/cw2000/cw2000_d/comser30/usrguide/index.htm

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.

Additional Information OnlineTo 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 DocumentationCisco 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.

Table 2 Related Documentation

Document Title Available Formats

Quick Start Guide for LAN Management Solution 3.0

• Printed document that was included with the product.


• On Cisco.com at:

xviUser Guide for CiscoWorks Common Services

78-16571-01

Preface Obtaining Documentation

Cisco.comYou 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:


You can access international Cisco websites at this URL:

http://www.cisco.com/public/countries_languages.shtml

Ordering DocumentationYou 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).

xviiUser Guide for CiscoWorks Common Services

78-16571-01

http://www.cisco.com/univercd/home/home.htm


http://www.cisco.com/public/countries_languages.shtml

http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm

http://www.cisco.com/en/US/partner/ordering/index.shtml

Preface Documentation Feedback

Documentation FeedbackYou can send comments about technical documentation to [email protected].

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 SystemsAttn: Customer Document Ordering170 West Tasman DriveSan Jose, CA 95134-9883

We appreciate your comments.

Obtaining Technical AssistanceFor 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 WebsiteThe 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

xviiiUser Guide for CiscoWorks Common Services

78-16571-01

http://www.cisco.com/techsupport


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 RequestUsing 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 55USA: 1 800 553-2447

For a complete list of Cisco TAC contacts, go to this URL:

http://www.cisco.com/techsupport/contacts

xixUser Guide for CiscoWorks Common Services

78-16571-01


http://www.cisco.com/techsupport/servicerequest


Preface Obtaining Additional Publications and Information

Definitions of Service Request SeverityTo 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.

Obtaining Additional Publications and InformationInformation 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

xxUser Guide for CiscoWorks Common Services

78-16571-01


http://www.cisco.com/go/marketplace/

http://cisco.com/univercd/cc/td/doc/pcat/



• 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

xxiUser Guide for CiscoWorks Common Services

78-16571-01


http://www.cisco.com/packet

http://www.cisco.com/go/iqmagazine

http://www.cisco.com/ipj

http://www.cisco.com/en/US/learning/index.html


xxiiUser Guide for CiscoWorks Common Services

78-16571-01

User G78-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.

1-1uide for CiscoWorks Common Services

Chapter 1 Overview New Features

New FeaturesThe 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-2User Guide for CiscoWorks Common Services

78-16571-01

Chapter 1 Overview Understanding Time Zone Settings

• Support for IPv6.

• HTML based Online help.

Understanding Time Zone SettingsCommon 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 ServicesYou 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

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.


78-16571-01

User G78-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


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

Invoking CiscoWorks HomepageYou 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.


78-16571-01

Chapter 2 Interacting With CiscoWorks Homepage Invoking CiscoWorks Homepage

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

Chapter 2 Interacting With CiscoWorks Homepage 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 CiscoWorksIf 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.


78-16571-01

Chapter 2 Interacting With CiscoWorks Homepage 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 CWHPCiscoWorks 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 PanelThe 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


Application PanelsEach 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.


78-16571-01


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 PanelThe Device Troubleshooting panel provides a launch point to the Device Center. See Chapter 6, “Using Device Center” for details.

Resources PanelResources 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 PanelCiscoWorks 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

Chapter 2 Interacting With CiscoWorks Homepage 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 ItemsThree 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 CWHPThe 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 CWHPUsing 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.


78-16571-01


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


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.


78-16571-01


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 CWHPYou 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


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


78-16571-01

Chapter 2 Interacting With CiscoWorks Homepage 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 HelpEach 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

Chapter 2 Interacting With CiscoWorks Homepage 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.

Changing Web Server Port NumbersTo 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.


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


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.


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 ***Usage: changeport <port number> [-s] [-f]

where:


-s—Change the SSL port instead of the default HTTP port

-f—Force 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.


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



• Port numbers less than 1025 are not allowed except 80 (HTTP) and 443 (HTTPS). Also port 80 is not allowed for HTTPS 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 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 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.


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). | |--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) |--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 messages contain information about the directory where the backup files are being 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



78-16571-01

User G78-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 SecurityCommon 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 ModeYou 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.


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

Setting up Browser-Server SecurityCommon 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 ServerTo 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.


78-16571-01

Chapter 3 Configuring the Server Setting up Browser-Server Security

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

Chapter 3 Configuring the Server 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 AccountsSeveral 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.


78-16571-01

Chapter 3 Configuring the Server 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 LevelsSystem 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.

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.

Table 3-1 Security Levels

Level Description

0 Help Desk

1 Approver

2 Network Operator

4 Network Administrator

8 System Administrator

16 Export Data


78-16571-01

Chapter 3 Configuring the Server Setting up Local Users

Setting up Local UsersLocal 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 ProfileTo edit your profile:

Step 1 In the CiscoWorks Homepage, select Common Services > Server > Security > 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.


78-16571-01


Adding a UserYou can add further users into CiscoWorks as required. To add a user:



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


Editing User ProfilesYou can edit the user profiles to modify the roles assigned to the users.

To edit user profiles:



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 UserTo delete a user:



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.


78-16571-01

Chapter 3 Configuring the Server Creating Self Signed Certificate

Creating Self Signed CertificateCiscoWorks 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:

Step 1 In the CiscoWorks Homepage, select Common Services > Server > Security > 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

Chapter 3 Configuring the Server Managing Security in Multi-Server Mode

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 ModeCommunication 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).

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.

Field Usage Notes


78-16571-01

Chapter 3 Configuring the Server 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

Setting up Peer Server AccountPeer 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:

Step 1 In the CiscoWorks Homepage, select Common Services > Server > Security > Peer Server Account Setup.

Step 2 Click Add.

The Peer Server Account Setup page appears.




Step 6 Click OK.


78-16571-01

Chapter 3 Configuring the Server Setting up Peer Server Account

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.


78-16571-01

Chapter 3 Configuring the Server Setting up System Identity Account

Setting up System Identity AccountCommunication 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

Chapter 3 Configuring the Server 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:

Step 1 In the CiscoWorks Homepage, select Common Services > Server > Security > System Identity Setup




Step 5 Click Apply.

Setting up Peer Server CertificateYou 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.


78-16571-01

Chapter 3 Configuring the Server 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-OnWith 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

Chapter 3 Configuring the Server 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.

Navigating Through the SSO DomainThe 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


78-16571-01

Chapter 3 Configuring the Server Navigating Through the SSO Domain

Registering Server LinksYou 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 InstanceAfter 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

Chapter 3 Configuring the Server 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.

Changing the Single Sign-On ModeThe 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.


78-16571-01

Chapter 3 Configuring the Server Changing the Single Sign-On Mode

To change the SSO mode to Standalone:

Step 1 In the CiscoWorks Homepage, select Common Services > Server > Security > 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:


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:


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

Chapter 3 Configuring the Server 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 ModeThe 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.


78-16571-01

Chapter 3 Configuring the Server 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.

About Common Services AuthenticationBy 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

http://www.cisco.com/kobayashi/sw-center/ciscosecure/cs-acs.shtml

Chapter 3 Configuring the Server About Common Services Authentication

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.


78-16571-01

Chapter 3 Configuring the Server 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

Chapter 3 Configuring the Server Setting the Login Module to Non-ACS

Detailed information about the various configuration options appear in the Cisco Secure ACS documentation.

Setting the Login Module to Non-ACSThe Login Module defines how authorization and authentication are performed.

To set the login module to Non-ACS mode:

Step 1 In the CiscoWorks Homepage, select Common Services > Server > Security > 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+


78-16571-01


Changing Login Module to CiscoWorks LocalTo 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 DirectoryThe 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


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:

Step 3 Click OK.

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.


78-16571-01


Changing Login Module to KerberosLoginKerberos 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.



Step 3 Click OK.

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.



78-16571-01


Changing Login Module to Local Unix SystemThis 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.



Step 3 Click OK.

Field Description

Selected Login Module Local UNIX System.

Description CiscoWorks native Solaris module.




78-16571-01


Changing Login Module to Local NT SystemThis option is available only on Windows

To change the login module to Local NT System:

Step 1 Select Local NT System radio button.



Step 3 Click OK.

Changing Login Module to MS Active DirectoryThe 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.

A Distinguished name is made up of three parts, Prefix, User login, and Usersroot. The user login is appended when the user logs in so the Distinguished name is Prefix+login name+Usersroot.

Field Description

Selected Login Module Local NT System.

Description CiscoWorks native NT login module.


Domain Set to localhost.



78-16571-01


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.



Step 3 Click OK.

.

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=




78-16571-01


Changing Login Module to Netscape DirectoryThe 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.

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

To change login module to Netscape Directory:

Step 1 Select Netscape Directory radio button.



Step 3 Click OK.

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=




78-16571-01


Changing Login Module to RadiusTo change login module to Radius:

Step 1 Select Radius radio button.



Step 3 Click OK.

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.




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 default for this protocol. Attempt to override it only if your authentication server was configured with a non-default port.

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 default for this protocol. Attempt to override it only if your authentication server was configured with a non-default port.

Key Enter the secret key.


78-16571-01


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



Field Description


78-16571-01

Chapter 3 Configuring the Server Setting the Login Module to ACS

Understanding Fallback Options for Non-ACS modeFallback 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:

Setting the Login Module to ACSThe 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.

Table 3-2 Login Module Fallback Options

Option Description

Allow all CiscoWorks Local users to fall back to the CiscoWorks Local login.

All users can access CiscoWorks using the Local login if the current login module fails.

Allow only the following user(s) to fall back to the CiscoWorks Local login if preceding login fails: username.

Specified users can access CiscoWorks using the Local login if the current login module fails. Use commas between user names.

Allow no fall backs to the CiscoWorks Local login.

No access is allowed if the current login module fails.


78-16571-01


To set login module to ACS:

Step 1 In the CiscoWorks Homepage, select Common Services > Server > Security > 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.


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


Assigning Privileges in ACSYou 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.


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 ACSIn 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


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.


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


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.


78-16571-01


Understanding Fallback Options for ACS ModeFallback 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

Chapter 3 Configuring the Server Managing Cisco.com Connection

Managing Cisco.com ConnectionCertain 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 AccountTo set up Cisco.com login account:

Step 1 In the CiscoWorks Homepage, select Common Services > Server > Security > 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 ServerYou 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.


78-16571-01

Chapter 3 Configuring the Server Generating Reports

Generating ReportsCommon 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 ReportThe 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


Step 3 Click Generate Report.

The Log File Status Report appears.

The Log File Status Report appears with the following details:

Permissions ReportThe 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.

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.


78-16571-01



The Permissions Report appears.

The Permissions Report appears with the following details:

Users Logged In ReportThe 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.

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.


78-16571-01



The Users Logged In report appears.

The Users Logged In report appears with the following information:

Process Status ReportThe 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.

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


78-16571-01



The Process Status report is displayed.

The Process Status Report appears with the following information:

Viewing Audit Log ReportAudit 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.

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.


78-16571-01


Step 3 Click an Audit Log file link to view the audit log details.

Audit log report in Non-ACS mode:

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

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


78-16571-01

Chapter 3 Configuring the Server 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 ServicesCommon 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

Chapter 3 Configuring the Server Using Daemon Manager

Using Daemon ManagerThe 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 SolarisTo 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.


78-16571-01

Chapter 3 Configuring the Server Managing Processes

Restarting Daemon Manager on WindowsTo 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 ProcessesCiscoWorks 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

Chapter 3 Configuring the Server Managing Processes

Viewing Process DetailsTo 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 ProcessTo start a Process:


The process page appears.

Step 2 Select the check box corresponding to the process.

Step 3 Click Start.


78-16571-01

Chapter 3 Configuring the Server Backing Up Data

Stopping a ProcessTo stop a Process:


The Process page appears.

Step 2 Select the check box corresponding to the process.

Step 3 Click Stop.

Backing Up DataYou 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


To schedule a backup:

Step 1 In the CiscoWorks Homepage, select Common Services > Server > Admin > Backup.

The Backup page appears.

Step 2 Enter the appropriate information in the following fields:

Step 3 Click Apply.

.

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.


78-16571-01


Backing up Using CLIYou 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 BackupThe 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

Chapter 3 Configuring the Server Restoring Data

Restoring DataThe 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.


78-16571-01


Restoring Data on UNIXTo 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


Restoring Data on WindowsTo 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.


78-16571-01


Data Restored from Common Services 3.0 Backup ArchiveThe 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


Data Restored from Common Services 2.2 Backup ArchiveThe 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 ArchiveThe 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.


78-16571-01

Chapter 3 Configuring the Server Effects of Backup-Restore on DCR

Effects of Backup-Restore on DCRData 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


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.


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


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.


78-16571-01

Chapter 3 Configuring the Server Effects of Backup-Restore on Groups

Effects of Backup-Restore on GroupsBackup- 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

Chapter 3 Configuring the Server 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.

Licensing CiscoWorks ApplicationsYou 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 ApplicationsTo 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.


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 ApplicationAfter 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

http://www.cisco.com/go/license

http://www.cisco.com/go/license/public


Viewing License InformationTo 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 LicensesYou 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:

Step 1 In the CiscoWorks Homepage, select Common Services > Server > Admin > 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.


78-16571-01

Chapter 3 Configuring the Server Collecting Server Information

Collecting Server InformationThis 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:

Step 1 In the CiscoWorks Homepage, select Common Services > Server > Admin > 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

Chapter 3 Configuring the Server Collecting Self Test Information

Collecting Self Test InformationYou 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 UsersYou 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.


78-16571-01

Chapter 3 Configuring the Server Managing Jobs

Managing JobsCommon 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:

Step 1 In the CiscoWorks Homepage, select Common Services > Server > Admin > Job Browser.

The Job Browser page appears.


78-16571-01


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.


78-16571-01


To view Job details:

Step 1 In the CiscoWorks Homepage, select Common Services > Server > Admin > Job Browser.


Step 2 In the Job Browser page, click Job ID.

The Job Details popup displays the job details.

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.

Item Description


78-16571-01

Chapter 3 Configuring the Server 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 ResourcesCommon 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.


78-16571-01

Chapter 3 Configuring the Server Managing Resources

To view Resource details:

Step 1 In the CiscoWorks Homepage, select Common Services > Server > Admin > Resource Browser.

The Resource Browser page displays the following details:

To free locked resources:

Step 1 In the CiscoWorks Homepage, select Common Services > Server > Admin > 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.

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.


78-16571-01

Chapter 3 Configuring the Server Maintaining Log Files

Maintaining Log FilesLog 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 UNIXTo 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


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


Maintaining Log Files on WindowsTo 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 [-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.

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.


78-16571-01


Using LogrotThe 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 LogrotTo 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


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


78-16571-01

Chapter 3 Configuring the Server 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.

Modifying System PreferencesYou 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 E-mail ID

The CiscoWorks E-mail ID from which applications send 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

Chapter 3 Configuring the Server Modifying System Preferences

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.


78-16571-01

User G78-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.


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.


78-16571-01


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:

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.

Table 4-1 Attributes and Description (continued)


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


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.

Table 4-2 Credentials and Description (continued)

Credential Description


78-16571-01

Chapter 4 Managing Device and Credentials 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 ArchitectureThe 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

Chapter 4 Managing Device and Credentials DCR Architecture

Master DCRThe 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 DCRThe 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 DCRIn 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.


78-16571-01

Chapter 4 Managing Device and Credentials Using the Device and Credential Admin

Using the Device and Credential AdminDevice and Credential Admin (DCA) helps you in:

• Managing Devices

• Generating Reports in DCA

• Managing Auto Update Servers

• Administering Device and Credential Repository

Managing DevicesThe 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

Chapter 4 Managing Device and Credentials Managing Devices

Adding DevicesYou 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


78-16571-01


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


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.


78-16571-01


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.

The attribute fields that appear here can be changed at Device and Credentials > 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


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.

The attribute fields that appear here can be changed at Device and Credentials > Admin > User Defined Fields.

Deleting DevicesYou 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 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.


78-16571-01


Editing Device CredentialsYou 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


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 CredentialsYou 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


78-16571-01


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


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.









78-16571-01


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


Exporting Devices and CredentialsYou 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


78-16571-01


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


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.


78-16571-01


Excluding DevicesThis 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 utilityCisco 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_name,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_enable_password;,Dev1Hostname,,10.1.0.60,,,


78-16571-01


,,,AUSID1,Dev2Hostname,cisco.com,;;Start of section 2 - AUS managed;;HEADER: aus_device_identity,parent_aus_id;, ;End of CSV file

Viewing Devices ListYou 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.


78-16571-01

Chapter 4 Managing Device and Credentials Generating Reports in DCA

Generating Reports in DCAYou can use this feature to generate and view Device and Credential Admin reports.

To generate reports:

Step 1 In the CiscoWorks Homepage, select Common Services > 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

Chapter 4 Managing Device and Credentials Managing Auto Update Servers

Managing Auto Update ServersAuto 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:

Step 1 In the CiscoWorks Homepage, select Common Services > Device and 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.


78-16571-01

Chapter 4 Managing Device and Credentials Managing Auto Update Servers

Editing Auto Update Server To edit Auto Update Server:



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 ServerTo delete Auto Update Servers:



Step 2 Select the device you want to delete from the list.



78-16571-01

Chapter 4 Managing Device and Credentials Administering Device and Credential Repository

Administering Device and Credential RepositoryThe 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 ModeTo change Mode Settings:

Step 1 In the CiscoWorks Homepage, select Common Services > 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


78-16571-01


Master-Slave Configuration PrerequisitesBefore 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


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.


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 FieldsTo 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


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


78-16571-01

Chapter 4 Managing Device and Credentials Sample CSV File

Deleting User-defined FieldsTo 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 FileCSV 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# = 6: User Field 2; Col# = 7: User Field 3; Col# = 8: User Field 4; Col# = 9; Name = Telnet password; Col# = 10; Name = Enable password


78-16571-01


; 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

; This file is generated by DCR Export utilityCisco 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_name,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,268438100,public,private,field0,field110.77.202.10,Router7000,cisco.com,,Router1,1.3.6.1.4.1.9.1.8,0,278464493,public,private,field0,field110.77.202.30,Switch4006,cisco.com,,Switch1,1.3.6.1.4.1.9.5.46,0,268438086,public,private,field0,field110.77.202.20,Router6400,cisco.com,,Router2,1.3.6.1.4.1.9.1.180,0,269214543,public,private,field0,field1

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


78-16571-01


Sample CSV 3.0 File for Auto Update Server Managed Devices

; This file is generated by DCR Export utilityCisco 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_name,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_enable_password;1.1.1.1,ons_host1,cisco.com,AUS_ID,ONS1,1.3.6.1.4.1.9.1.406,0,273612892,,,,,,,,,10.10.10.1,aus_server,cisco.com,,AUS_SERV1,UNKNOWN,3,UNKNOWN,,,,,,,,,;;Start of section 1 - AUS proxy;;HEADER: management_ip_address,host_name,domain_name,device_identity,display_name,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/AutoUpdateServlet;;Start of section 2 - AUS managed;;HEADER: management_ip_address,host_name,domain_name,device_identity,display_name,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


Sample CSV 3.0 File for Cluster Managed Devices

; This file is generated by DCR Export utilityCisco 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_name,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_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: management_ip_address,host_name,domain_name,device_identity,display_name,dsbu_member_number,parent_dsbu_id;1.1.1.1,ons_dev_1,cisco.com,,ONS1,1,display_name=cluster;End of CSV file


78-16571-01


Mapping CSV 2.0 to CSV 3.0 FieldsThe following table provides a mapping between the fields in CSV 2.0 and 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.

CSV 2.0 CSV 3.0

Name (including domain or simply an IP)

host_name and display_name

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


78-16571-01

Chapter 4 Managing Device and Credentials 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>


78-16571-01


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

<?xml version="1.0"?><DEVICES> <DEVICE> <SET Name="Basic Credentials"> <DEVATTRIB Name="management_ip_address">1.1.1.1</DEVATTRIB> <DEVATTRIB Name="host_name">ons_host1</DEVATTRIB> <DEVATTRIB Name="domain_name">cisco.com</DEVATTRIB> <DEVATTRIB Name="device_identity">AUS_ID</DEVATTRIB> <DEVATTRIB Name="display_name">ONS1</DEVATTRIB> <DEVATTRIB Name="sysObjectID">1.3.6.1.4.1.9.1.406</DEVATTRIB> <DEVATTRIB Name="dcr_device_type">0</DEVATTRIB> <DEVATTRIB Name="mdf_type">273612892</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> <SET Name="Basic Credentials"> <DEVATTRIB Name="management_ip_address">10.10.10.1</DEVATTRIB> <DEVATTRIB Name="host_name">aus_server</DEVATTRIB> <DEVATTRIB Name="domain_name">cisco.com</DEVATTRIB> <DEVATTRIB Name="display_name">AUS_SERV1</DEVATTRIB> <DEVATTRIB Name="sysObjectID">UNKNOWN</DEVATTRIB> <DEVATTRIB Name="dcr_device_type">3</DEVATTRIB> <DEVATTRIB Name="mdf_type">UNKNOWN</DEVATTRIB> </SET> <SET Name="AUS proxy"> <DEVATTRIB Name="aus_username">admin</DEVATTRIB>


78-16571-01


<DEVATTRIB Name="aus_password">admin</DEVATTRIB> <DEVATTRIB Name="aus_url">autoupdate/AutoUpdateServlet</DEVATTRIB> </SET> </DEVICE></DEVICES>

Sample XML File for Cluster Managed Devices

<?xml version="1.0"?><DEVICES> <DEVICE> <SET Name="Basic Credentials"> <DEVATTRIB Name="management_ip_address">1.1.1.1</DEVATTRIB> <DEVATTRIB Name="host_name">ons_dev_1</DEVATTRIB> <DEVATTRIB Name="domain_name">cisco.com</DEVATTRIB> <DEVATTRIB Name="display_name">ONS1</DEVATTRIB> <DEVATTRIB Name="sysObjectID">1.3.6.1.4.1.9.1.406</DEVATTRIB> <DEVATTRIB Name="dcr_device_type">0</DEVATTRIB> <DEVATTRIB Name="mdf_type">273612892</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> <SET Name="Basic Credentials"> <DEVATTRIB Name="management_ip_address">10.10.10.1</DEVATTRIB> <DEVATTRIB Name="host_name">host1</DEVATTRIB> <DEVATTRIB Name="domain_name">cisco.com</DEVATTRIB> <DEVATTRIB Name="display_name">cluster1</DEVATTRIB> <DEVATTRIB Name="sysObjectID">Unknown</DEVATTRIB> <DEVATTRIB Name="dcr_device_type">1</DEVATTRIB> <DEVATTRIB Name="mdf_type">278283831</DEVATTRIB> </SET> </DEVICE></DEVICES>


78-16571-01

Chapter 4 Managing Device and Credentials Using DCR Features Through CLI

Using DCR Features Through CLIUsing 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 dcrcliTo 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 dcrcliTo 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


Editing Devices Using dcrcliTo 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 AttributesTo 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


78-16571-01


Viewing the Current DCR Mode Using dcrcliTo 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 DetailsTo 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


Changing DCR Mode Using dcrcliTo 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


78-16571-01


Import Using CLIYou 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


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


78-16571-01

Chapter 4 Managing Device and Credentials Implications of ACS Login Module on DCR

Implications of ACS Login Module on DCRWhen 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 DCRYou 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

Chapter 4 Managing Device and Credentials Implications of ACS Login Module on DCR

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 Application in DCR

None.


78-16571-01

User G78-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.


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 ConceptA 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 HierarchyGroups 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.


78-16571-01


Dynamic GroupA 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 GroupA 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 GroupsContainer 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 GroupsAfter 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


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 GroupsCommon 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


78-16571-01


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

Chapter 5 Administering Groups 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 ViewsSecure 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.


78-16571-01

Chapter 5 Administering Groups Groups in a Single-Server Setup

Groups in a Single-Server SetupThe 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 SetupGroups 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

Chapter 5 Administering Groups Groups in Multi-Server Setup

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.


78-16571-01

Chapter 5 Administering Groups Groups in Multi-Server Setup

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

Chapter 5 Administering Groups 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.

DCR Mode Changes and Group behavior 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.


78-16571-01


Table 5-1 DCR Mode Changes and Group Behavior

Mode Changed to:

The initial mode

Standalone Slave Master

Standalone Not applicable. Master will get all the Slave groups. That is, if 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.

No change in the Group hierarchy.


78-16571-01


Slave Groups UI gets enabled. The groups pertaining to Master and Slaves will be removed.

The Slave’s groups will disappear from the Master.

The groups pertaining to the Slave whose mode was changed will disappear from other Slaves in the cluster.

Not applicable. Groups UI gets enabled. Groups pertaining to the previous Master and the associated Slaves will be removed.

Master All dependent Slaves will switch to Standalone mode. All groups pertaining to other machines will be removed. Groups UI will be enabled on all machines in the cluster.

If you select the Inform current Slaves of new Master Hostname check box when you change the mode to Slave, all the 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.

Not applicable.

Table 5-1 DCR Mode Changes and Group Behavior (continued)

Mode Changed to:

The initial mode

Standalone Slave Master


78-16571-01

Chapter 5 Administering Groups Unregistering a Slave

Unregistering a SlaveThe 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

Chapter 5 Administering Groups Group Administration

Group AdministrationThe 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 GroupsTo 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.


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


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.


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


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.


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 DetailsTo view the details of a group:


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


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 DetailsYou can modify some of the details for a group using this feature.

To modify the details of a group:




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.


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


Refreshing GroupsYou 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:




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



Step 2 Select the group from Group Selector.

The Group Info fields on the right pane displays details of the selected group.


78-16571-01

Chapter 5 Administering Groups 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.

System Defined and User Defined AttributesThe 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

Chapter 5 Administering Groups System Defined and User Defined Attributes

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” section on page 4-29.

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.

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.



78-16571-01

User G78-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.


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


78-16571-01

Chapter 6 Using Device Center Invoking Device Center

Invoking Device CenterTo 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 FunctionsYou 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

Chapter 6 Using Device Center Using Device Center Functions

Device SelectorDevice 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 SummaryThe 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.


78-16571-01

Chapter 6 Using Device Center Enabling Debugging Tools

Management FunctionsThe 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.

Enabling Debugging ToolsThe 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


Checking Device ConnectivityTo 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.


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


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


78-16571-01


Using TracerouteUse 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 WalkSNMP 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


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.

You have to manually enter SNMP v1/v2c/v3 credentials.


78-16571-01


Using SNMP SetYou 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


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

You have to manually enter SNMP v1/v2c/v3 credentials.

Using Packet CaptureThe 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




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


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.


78-16571-01

Chapter 6 Using Device Center Displaying Reports

Editing Device CredentialsYou 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 ReportsThe 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 TasksThe 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

Chapter 6 Using Device Center Performing Management Tasks


78-16571-01

User G78-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.


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

Performing Software UpdatesThe 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.


78-16571-01

Chapter 7 Working With Software Center Performing Software Updates

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:

Step 1 In the CiscoWorks Homepage, select Common Services > Software Center > 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

Chapter 7 Working With Software Center Performing Device Update

Performing Device UpdateThe 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:

Step 1 In the CiscoWorks Homepage, select Common Services > Software Center > 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.


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


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 PackagesYou can also delete packages that are outdated or you no longer use.

To delete a package:

Step 1 In the CiscoWorks Homepage, select Common Services > Software Center > 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.


78-16571-01

Chapter 7 Working With Software Center 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.

Scheduling Device Package DownloadsYou 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:

Step 1 In the CiscoWorks Homepage, select Common Services > Software Center > 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

Chapter 7 Working With Software Center Scheduling Device Package Downloads

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.


78-16571-01

Chapter 7 Working With Software Center Viewing Activity Logs

Viewing Activity LogsActivity 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

Chapter 7 Working With Software Center Viewing Activity Logs


78-16571-01

User G78-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 StatusThere 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 report with the results.

Select Server > Admin > Self Test.


Chapter 8 Diagnosing Problems With CiscoWorks Server Verifying Server Status

All Users

Check process status. Checks whether back-end processes are in an interim state.

SelectServer > Admin > Processes.

Collect server information.

Provides system information, environment, configuration, logs, and web server information.

Select

Server > Admin > Collect Server 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.

Table 8-1 Server Status (continued)

Task Purpose Action


78-16571-01

Chapter 8 Diagnosing Problems With CiscoWorks Server Verifying Server Status

MDC Support The MDC Support utility collects log files, configuration settings, memory info, complete system related info, process status and host environment information.

It also collects any other relevant data, into a deliverable tar (compressed form) file to support the MDCs installed.

The MDC Support utility also queries CCR for any other support utilities registered, and run them.

Other MDCs need to register their own support utilities that will collect their relevant data.

For Windows go to,

NMSROOT\MDC\bin and execute the command:

MDCSupport.exe

The utility creates a tar file in NMSROOT\MDC\etc directory.

If \etc directory is full, or if you want to preserve the data collected previously by not over writing the tar file, you may create another directory by running the following command:

MDCSupport.exe Directory

For Solaris,

/opt/CSCOpx/MDC/bin and execute the command:

./mdcsupport

The utility creates a tar file in CSCOpx/MDC/etc directory.


Task Purpose Action


78-16571-01

Chapter 8 Diagnosing Problems With CiscoWorks Server Testing Device Connectivity

Testing Device ConnectivityThe 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).

MDCSupport (Continued)

If \etc directory is full, or if you want to 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.


Task Purpose Action


78-16571-01

Chapter 8 Diagnosing Problems With CiscoWorks Server Testing Device Connectivity

Table 8-2 Connectivity Tools Tasks

Task Purpose Action

Traceroute. Detects routing errors between the network management station and a target device.

Select

Device Center > Tools > Traceroute.

See “Using Traceroute” section on page 6-9, for details.

Ping a device.

Tests device reachability using an ICMP echo message and its reply.

Select

Device Center > Tools > Ping

See “Using Ping” section on page 6-8, for details.

Check Management Station to Device

Checks the connectivity between the CiscoWorks Server and a device.

Select

Device Center > Tools > Management Station to Device

See “Checking Device Connectivity” section on page 6-6, for details.

Packet Capture.

Captures live data from the CiscoWorks machine to aid in troubleshooting.

Select

Device Center > Tools > Packet Capture

See “Using Packet Capture” section on page 6-12, for details.

To set an SNMP object on a device.

Sets an SNMP object on a device for purposes of controlling the device.

Select

Device Center > Tools > SNMP Set

See “Using SNMP Set” section on page 6-11, for details.

To walk the MIB tree of a device.

Walks the MIB tree of a device starting from a given OID for troubleshooting, or gathering information about a device.

Select

Device Center > Tools > SNMP Walk

See “Using SNMP Walk” section on page 6-9, for details.


78-16571-01

Chapter 8 Diagnosing Problems With CiscoWorks Server Troubleshooting the CiscoWorks Server

Troubleshooting the CiscoWorks ServerThis 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?


78-16571-01

Chapter 8 Diagnosing Problems With CiscoWorks Server Frequently Asked Questions

• 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, or after running it for a while?

• 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


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.


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


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.


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


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” section on page 8-33.

/tmp/1/cmf/filebackup.tar

CiscoWorks Server application tar files

Application data is stored in the datafiles.txt which are compiled into the tar file.

/tmp/1/cmf/database CiscoWorks Server database directory

Includes files for each database:

xxx_DbVersion.txt

xxx.db database files

xxx.log database log files

xxx.txt database backup manifest file

Table 8-3 Sample Backup Directory (continued)

Directory Path Description Usage Notes


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


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.


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


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.


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 42342toRmeGatekeeper 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 fromOSAGENT_PORT= 42342 toOSAGENT_PORT=44444

• Change the entry from PX_OSA_PORT=42342toPX_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


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

-store NMSROOT\objects\ess\conf\rvrd.conf -logfile 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.


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


Q. How do I change the IP Address of the CiscoWorks Server after installing it, or after running it for a while?

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.


78-16571-01


Q. How do I change the Hostname of the CiscoWorks Server after installing it, or after running it for a while?

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:

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.

Bundle Solaris Windows

LMS Bundle • hosts

• hostname.hme0

• nodename

• md.properties

• pkginfo

• md.properties file


78-16571-01


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.


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


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.


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


If you run this command without any command line parameter, CiscoWorks displays:

*** CiscoWorks Webserver port change utility ***Usage: changeport <port number> [-s] [-f]

where


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


changeport 1744—Changes the CiscoWorks web server HTTP port to use 1744.

Or,



• 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 any conflict is found 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 runs as root, and all the child processes will run as casuser:casusers. Only the child processes serve the external requests.


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


78-16571-01


The change port utility displays messages to the console during execution. These messages contain information about the directory where the backup files are being 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 ***Usage: changeport <port number> [-s] [-f]

where:


-s—Change the SSL port instead of the default HTTP port

-f—Force port change even if Daemon Manager detection fails.

Note Do not use this option by default. Use it only when CiscoWorks instructs you to.


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.


• Port numbers less than 1025 are not allowed except 80 (HTTP) and 443 (HTTPS). Also port 80 is not allowed for HTTPS 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 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



[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). | |--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) |--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 messages contain information about the directory where the backup files are being 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


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


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.


78-16571-01

Chapter 8 Diagnosing Problems With CiscoWorks Server Troubleshooting Suggestions

Troubleshooting SuggestionsUse 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

required. Please log

in with your username

and password.

Incompatible browser causing cookie failure (unable to retrieve cookie).

Verify that you have Accept all cookies enabled. Refer to the installation documentation for supported Internet Explorer and Netscape Navigator software and setup procedures.

Daemon Manager could not start. The port is in use.

The operating system has not yet reallocated the port.

Make sure all CiscoWorks processes are terminated (/usr/ucb/ps -auxww | grep CSCO). Wait five to ten minutes, then try to restart the Daemon Manager.

User has forgotten his password.

Common Services cannot recover forgotten passwords.

A system administrator-level user must either change the password or delete and then add the user again.

You are logged out of the CiscoWorks Server.

Changes in the login module configuration file might not be correct.

Authentication server might be down and there were no fallback logins set.

1. Log on as root.

2. On Windows:

Run NMSROOT/bin/ResetLoginModule.pl

On Solaris:

Run opt/CSCOpx/bin/ResetLoginModule.pl

3. Restart Daemon Manager.

The Log File Status window displays files that exceed their limit.

Files need to be backed up so that file size will be reset to zero.

1. Stop all processes.

2. Enter the log file maintenance command:

a. On UNIX: $NMSROOT/cgi-bin/admin/

b. On Windows: NMSROOT\cgi-bin\admin\

3. Restart all processes.


78-16571-01


Error message in the logfile: Connection Refused. Check the

Device is SSH

supported or not.

Device is not SSH enabled or the server is not authorized to initiate SSH connection.

1. Check whether the device is up or not.

2. Try connecting to the device with a commercial SSH client.

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.

Table 8-4 Troubleshooting Suggestions (continued)



78-16571-01


After installation, while starting the daemon manager, the following error message is displayed:

Found Non-SSL compliant Applications. Please disable SSL and then start the Daemon Manager

(Solaris only)

Found Non-SSL compliant products that do not function in SSL enabled mode.

Disable SSL from CLI and then start the daemon manager.

After installation, while starting the daemon manager, the following error message is displayed:

Service Not responded in a timely fashion

Found Non-SSL compliant products that do not function in SSL enabled mode.

Disable SSL from CLI and then start the daemon manager.

Table 8-4 Troubleshooting Suggestions (continued)



78-16571-01



78-16571-01

User G78-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” section on page 3-1.

The following sections describe the general and server security levels.

A-1uide for CiscoWorks Common Services

Appendix A Understanding CiscoWorks Security General Security

General SecurityThe 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 SecurityThe 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-2User Guide for CiscoWorks Common Services

78-16571-01

Appendix A Understanding CiscoWorks Security 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


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.


78-16571-01


• 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


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.


78-16571-01


System Administrator-Imposed SecurityTo 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 SecurityCiscoWorks 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


• 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” section on page 3-9.

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


78-16571-01


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


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-----MIIC4jCCAkugAwIBAgIEA0E1UDANBgkqhkiG9w0BAQBhMCVVMxCzAJBgNVBAgTAkNBMREwDwYDVQQHEwhTYNQ2lzY28gU3lzdGVtczENMAsGA1UECxMERU1CVTEqMCgG0ZXN0MiBDZXJ0aWZpY2F0ZSBNYW5hZ2VyMB4XDTAyMDas3DA4NTgwOVowgYIxCzAJBgNVBAYTAklOMQswCQYDVQQIQ2hlbm5haTEMMAoGA1UEChMDSENMMQ0wCwYDVQQLEtzZGluYWthci1wYzEhMB8GCSqGSIb3DQEJARYSc2RpbmFrYXfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDV1o9PyO7txr5vmeFU/f9tp5To/HaLIWHVx9zpihPnVuKaepp8kcEXO8Sed8crXeU8BP9qHoIswGn1oJEGFXm9gs5uupJyAgeDd6O9eCuQbiSKgE1sFGFSLxNGQJZbCrQIDAQABo2UwYzARBglghkgBhvhCAQEEB/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.


78-16571-01


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



78-16571-01

User Guid78-16571-01

I N D E X

A

access

connection security, understanding A-7

control, security and A-6

adding devices to the device list 4-8

for AUS management 4-10

for cluster management 4-11

for standard management 4-9

using dcrcli 4-39

administering

Common Services 3-51

Daemon Manager, using 3-52

process details, viewing 3-54

processes, managing 3-53

processes, starting 3-54

processes, stopping 3-55

DCA 4-26

Master-Slave configuration, prerequisites 4-27

mode, changing 4-26

user-defined fields, adding 4-29

user-defined fields, deleting 4-31

user-defined fields, renaming 4-30

applications

Application panels in CWHP 2-6

applications on another server 2-6

traditional applications 2-7

licensing 3-68

licensing information, viewing 3-70

licensing procedure 3-69

obtaining a license 3-68

updating licenses 3-70

registering with CWHP 2-8

troubleshooting

applications not appearing 8-11

audience for this document xiii

audit logs, viewing 3-49

AUS (Auto Update Server)

managing 4-24

adding 4-24

deleting 4-25

editing 4-25

setting up 4-10

IN-1e for CiscoWorks Common Services

Index

B

backing up data 3-55

back-up data

directory structure of 8-11

sample CMF backup directory 8-11

restoring data 3-58

using CLI 3-57

Base64-encoded X.509 certificate format, definition A-10

browser-server security (see SSL) 3-2

buttons on CWHP, using 2-8

C

cautions

significance of xiv

cautions regarding

admin password, guest password 3-5

backups, and the CiscoWorks Daemon Manager 3-78

data restoration from a backup 3-58

restarting Daemon Manager on Solaris 3-52

restarting Daemon Manager on Windows 3-53

CD One error message, troubleshooting 8-10

certificates

terms and definitions in A-8

Base64-encoded X-509 certificate format A-10

CA (certificate authority) A-11

IN-2User Guide for CiscoWorks Common Services

CiscoWorks TrustStore or KeyStore A-11

PKCS#8 A-9

public key, private key A-9

SSH A-9

SSL A-9

understanding A-7

Cisco.com connection, managing 3-44

CiscoWorks Homepage (see CWHP) 2-1

CiscoWorks Server, troubleshooting 8-1

collecting information on 8-2

FAQs 8-6

locked out of 8-12

MDC support 8-3

process status, checking 8-2

self-test, performing 8-1

CiscoWorks Trust Store or KeyStore, definition A-11

cmf as part of database path, explanation of 8-12

Common Services Server, overview of 1-3

connection security, understanding A-7

security certificates A-7

terms and definitions A-8

Base64-encoded X.509 certificate format A-10



PKCS#8 A-9


78-16571-01

Index

SSH A-9

SSL A-9

connectivity

Connectivity Tools Tasks (table) 8-5

tasks 8-1

checking process status 8-2

collecting server information 8-2

MDC support 8-3

performing a self-test 8-1

testing 8-4

CWHP (CiscoWorks Homepage) 2-1

Common Services panel 2-5

configuring 2-8

registering applications 2-8

registering links 2-11

setting up 2-12

invoking 2-2

normal mode (HTTP) 2-2

SSL Enabled mode (HTTPS) 2-3

logging in to Common Services 2-4

online help, using 2-13

using 2-5

Application panels 2-6

CiscoWorks Product Updates panel 2-7

Common Services panel 2-5

Device Troubleshooting panel 2-7

Resources panel 2-7

toolbar buttons 2-8

web server port numbers, changing 2-14

78-16571-01

D


restarting on Solaris 3-52

restarting on Windows 3-53

database

inaccessible, troubleshooting 8-13

path includes "cmf," explanation 8-12

DCA (Device and Credential Admin) 4-1

administering 4-26

Master-Slave configuration, prerequisites 4-27

mode, changing 4-26

user-defined fields, adding 4-29

user-defined fields, deleting 4-31

user-defined fields, renaming 4-30

architecture 4-5

Master DCR 4-6

Slave DCR 4-6

Standalone DCR 4-6

AUS management

adding devices 4-24

deleting AUS 4-25

editing devices 4-25

CSV file samples 4-31

CSV 2.0 4-31

CSV 3.0 4-32

devices, managing 4-7

adding 4-8

deleting 4-12


Index

excluding 4-21

exporting 4-18

importing 4-14

viewing the device list 4-22

reports, generating 4-23

XML file sample 4-36

DCR (Device and Credential Repository) CLI interface, using 4-39

adding devices 4-39

CDR mode, changing 4-42

deleting devices 4-39

editing devices 4-40

exporting using 4-44

importing using 4-43

listing attributes 4-40

viewing current DCR mode 4-41

viewing device details 4-41

deleting

AUS (Auto Update Server) 4-25

device groups 5-22

devices

from DCA 4-12

from groups 5-19

from the device list, using dcrcli 4-39

peer server certificates 3-15

user-defined fields from DCA 4-31

users 3-8

Device and Credential Admin (see DCA) 4-1


Device Center 6-1

debugging tools, enabling 6-5

device connectivity, checking 6-6

packet capture 6-12

Ping, using 6-8

SNMP Set 6-11

SNMP Walk, using 6-9

Traceroute, using 6-9

invoking 6-3

launching 6-2

management functions

management tasks 6-15

reports, displaying 6-15

using 6-3

Device Selector 6-4

Device Summary 6-4

management functions 6-5

reports 6-15

devices, managing 4-7

(see also Groups, administering) 5-1

(see also Software Center) 7-1

adding 4-8

for AUS management 4-10

for cluster management 4-11

for standard management 4-9

credentials

editing 4-13

exporting 4-18

importing 4-14

78-16571-01

Index

deleting 4-12

device list, viewing 4-22

excluding 4-21

exporting 4-18

using CLI 4-44

using DCA user interface 4-19

importing 4-14

using CLI 4-43


Device Troubleshooting panel of CWHP 2-7

diagnosing problems (see troubleshooting) 8-1

documentation xiv

additional online xvi

audience for this xiii

related to this product xvi

typographical conventions in xiii

E

editing

AUS (Auto Update Server) 4-25

device credentials in DCA 4-13

device group details 5-20

devices in the device list, using dcrcli 4-40

local user profile 3-6

user profiles 3-8

EDS (Event Distribution Service), troubleshooting 8-10

78-16571-01

ESS (Event Service Software)

changing the port for

in Solaris 8-17

in Windows 8-18

excluding devices from the device list 4-21

expired server certificate, how to handle 8-10

exporting devices and credentials 4-18

using CLI 4-44


F

file ownership, and permissions A-3

G

Groups, administering 5-1

concepts 5-2

common 5-4

container groups 5-3

dynamic groups 5-3

group hierarchy 5-2

secured views 5-6

shared 5-4

static groups 5-3

system-defined, user-defined 5-3

creating 5-14


Index

deleting

devices from groups 5-19

groups 5-22

details

modifying 5-20

viewing 5-19

editing 5-20

Group Administration 5-14

membership, assigning 5-18

multi-server setup 5-7

properties, specifying 5-15

refreshing 5-22

rules, defining 5-17

single server setup 5-7

syntax checking 5-18

system- and user-defined attributes 5-23

H

help

CiscoWorks Product Updates panel of CWHP 2-7

online, using 2-13

online documentation xvi


I

IBM SecureWay Directory, changing login module to 3-25

importing devices and credentials 4-14

using CLI 4-43


J

Java Plug-in, version to use 8-10

jobs

managing 3-73

jrm, checking 8-15

K

KerberosLogin, changing login module to 3-27

L

licensing CiscoWorks applications 3-68

license information, viewing 3-70




links, registering with CWHP 2-11

locked out of CiscoWorks Server, troubleshooting 8-12

78-16571-01

Index

log files, maintaining 3-78

Log File Status report, generating 3-45

on UNIX 3-78

on Windows 3-80

logrot utility, configuring 3-81

logrot utility, running 3-82

logrot utility, using 3-81

login module

fallback options for, understanding

ACS 3-43

non-ACS 3-35

setting to ACS 3-35

setting to non-ACS 3-24

CiscoWorks Local, changing to 3-25

fallback options, understanding 3-35

IBM SecureWay Directory, changing to 3-25

KerberosLogin, changing to 3-27

local NT system, changing to 3-29

Local UNIX system, changing to 3-28

MS Active Directory, changing to 3-29

Netscape Directory, changing to 3-30

Radius, changing to 3-32

TACACS+, changing to 3-33

logrot utility

configuring 3-81

running 3-82

using 3-81

78-16571-01

M

managing

Common Services jobs 3-73

Common Services resources 3-76

messaging online users 3-72

MS Active Directory, changing login module to 3-29

multi-server mode, and security 3-10

N

Netscape Directory, changing login module to 3-30

Netscape Navigator on UNIX systems, troubleshooting 8-10

O

online users, messaging 3-72

osagent, changing the port for

Solaris 8-16

Windows 8-15

overviews of

CiscoWorks Common Services 1-1

Common Services Server information 1-3

time zone settings, understanding 1-3

what’s new in this release 1-2

Common Services Server 1-3


Index

P

packet capture, using 6-12

peer server certificates

deleting 3-15

setting up 3-14

Permissions report, generating 3-46

PKCS#8, definition A-9

port numbers for web servers, changing 2-14

preferences for system, modifying 3-83

private key, definition A-9

Process Status report, generating 3-48

public key, definition A-9

R

Radius, changing login module to 3-32

remote connectivity, security and A-5

reports

Common Services reports 3-45


Log File Status report 3-45

Permissions report 3-46

Process Status report 3-48

Users Logged In report 3-47

DCA reports, generating 4-23

Device Center reports 6-15

resources, managing in Common Services 3-76

Resources panel of CWHP 2-7


restoring backed-up data 3-58

runtime security, understanding A-4

S

Secure Shell (SSH), definition A-9

security

access control, and A-6

certificates, understanding A-7

understanding A-1

general A-2

server A-2

security, setting up 3-1

AAA mode, setting up 3-20

authentication, about 3-21

Cisco.com login, setting up 3-44

Cisco Secure ACS support 3-22

login module

fallback options, understanding 3-35

setting to ACS 3-35


multi-server mode 3-10


deleting 3-15

setting up 3-14

proxy server, setting up 3-44

security levels, understanding 3-5

self-signed certificates, creating 3-9

single server mode 3-1

78-16571-01

Index

SSL 3-2

enabling from the CiscoWorks Server 3-2

enabling from the CLI 3-4

SSO (Single Sign-On) mode

changing 3-18

enabling 3-15

user management

about user accounts 3-4

local user profile, modifying 3-6

peer server, setting up 3-11

user profiles, editing 3-8

users, adding 3-7

users, deleting 3-8

self-test information, collecting 3-72

server, configuring 3-1

AAA mode, setting up 3-20

applications, licensing 3-68

licensing information, viewing 3-70




Cisco.com login, setting up 3-44

Cisco Secure ACS support 3-22

Common Services, administering 3-51

backing up data 3-55


jobs, managing 3-73

processes, managing 3-53

resources, managing 3-76

78-16571-01

restoring data 3-58

server information, collecting 3-71

Common Services authentication, about 3-21

log files, maintaining 3-78

on UNIX 3-78

on Windows 3-80

login module

setting to ACS 3-35


login module fallback options, understanding

for ACS mode 3-43

for non-ACS mode 3-35


deleting 3-15

setting up 3-14

proxy server, setting up 3-44

reports, generating 3-45


Log File Status report 3-45

Permissions report 3-46

Process Status 3-48

Users Logged In 3-47

security (see security, setting up) 3-1

self-signed certificates, creating 3-9


changing 3-18

enabling 3-15

system preferences, modifying 3-83

user accounts, about 3-4


Index

user management

adding 3-7

deleting 3-8

local user profile, modifying 3-6

peer server, adding 3-11

user profile, editing 3-8

users, local, setting up 3-6

server certificate for CiscoWorks, expiration, how to handle 8-10

server information, collecting (Common Services) 3-71

server security, understanding A-2

administrator-imposed A-7

connection A-7

security certificates A-7

terms and definitions A-8

server-imposed A-2

access control A-6

files, file ownership, permissions A-3

other systems A-6

remote connectivity A-5

runtime A-4

SNMP Set, using 6-11

SNMP Walk, using 6-9

Software Center 7-1

activity logs, viewing 7-9

device downloads, scheduling 7-7

device updates, performing 7-4

packages, deleting 7-6

software updates, performing 7-2


Solaris, changing ports in

for ESS 8-17

for osagent 8-16

SSL, enabling on the server 3-2

from the CiscoWorks Server 3-2

from the CLI 3-4

SSL, definition A-9


changing 3-18

enabling 3-15

starting CiscoWorks applications, troubleshooting 8-11

T

TACACS+, changing login module to 3-33

technical support

CiscoWorks Product Updates panel of CWHP 2-7

terms and definitions in security certificates A-8

Base64-encoded X.509 certificate format A-10



PKCS#8 A-9


SSH A-9

SSL A-9

time zone settings, understanding 1-3

78-16571-01

Index

toolbar buttons on CWHP, using 2-8

troubleshooting

(see also debugging tools under Device Center) 6-5

applications not appearing 8-11

back-up data, directory structure of 8-11

CiscoWorks applications, starting 8-11

CiscoWorks Server 8-1

device connectivity, testing 8-4

FAQs 8-6

locked out of, diagnosing 8-12

server status, verifying 8-1

Server Tools Tasks (table) 8-1

database

inaccessability 8-13

path includes "cmf" 8-12

devices, with the Device Troubleshooting panel of CWHP 2-7

EDS not registered with daemon manager 8-10

ESS port change

Solaris 8-17

Windows 8-18

FAQs list 8-6

Java Plug-in, which version to use 8-10

jrm 8-15

Netscape Navigator on a UNIX system 8-10

osagent port change

Solaris 8-16

Windows 8-15

78-16571-01

suggestions 8-33

UNIX systems, and Netscape Navigator 8-10

typographical conventions in this document xiii

U

UNIX systems

changing login module to local UNIX system 3-28

invoking Netscape Navigator on, troubleshooting 8-10

log files, maintaining on 3-78

user accounts

about 3-4

setting up

Cisco.com 3-44

local 3-6

Users Logged In report, generating 3-47

V

verifying CiscoWorks Server status 8-1

viewing

application license information 3-70

audit logs 3-49

device list 4-22

group details 5-19

process details 3-54

Software Center activity logs 7-9


Index

W

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


78-16571-01

huong dan su dung cisco work

Documents