-
User Guide for CiscoWorks Common Services 3.0.3
-
Preface
-
Overview
-
Interacting With CiscoWorks Homepage
-
Configuring the Server
-
Managing Device and Credentials
-
Administering Groups
-
Using Device Center
-
Working With Software Center
-
Diagnosing Problems With CiscoWorks Server
-
Understanding CiscoWorks Security
-
Acronyms Used in Common Services Documentation
-
Index
-
Feedback
Table Of Contents
Managing Security in Single Server Mode
Setting up Browser-Server Security
Enabling Browser-Server Security From the CiscoWorks Server
Enabling Browser-Server Security From the Command Line Interface (CLI)
Creating Self Signed Certificate
Working With Third Party Security Certificates
Uploading Third Party Security Certificates to CiscoWorks Server
Using the SSL Utility Script to Upload Third Party Security Certificates
Managing Security in Multi-Server Mode
Setting up Peer Server Account
Setting up System Identity Account
Setting up Peer Server Certificate
Navigating Through the SSO Domain
Launching a New Browser Instance
Changing the Single Sign-On Mode
About Common Services Authentication
Cisco Secure ACS Support for Common Services Client Applications
Setting the Login Module to Non-ACS
Changing Login Module to CiscoWorks Local
Changing Login Module to IBM SecureWay Directory
Changing Login Module to KerberosLogin
Changing Login Module to Local Unix System
Changing Login Module to Local NT System
Changing Login Module to MS Active Directory
Changing Login Module to Netscape Directory
Changing Login Module to Radius
Changing Login Module to TACACS+
Understanding Fallback Options for Non-ACS mode
Setting the Login Module to ACS
Creating and Modifying Roles in ACS
Understanding Fallback Options for ACS Mode
Setting up Cisco.com User Account
Restarting Daemon Manager on Solaris
Restarting Daemon Manager on Windows
Data Backed up During CS 3.0/3.0.3 Backup
Data Restored From Common Services 3.0/3.0.3 Backup Archive
Data Restored From Common Services 2.2 Backup Archive
Data Restored From CD One 5th Edition Backup Archive
Effects of Backup-Restore on DCR
Master -Slave Configuration Prerequisites and Restore Operations
Effects of Backup-Restore on Groups
Licensing CiscoWorks Applications
Obtaining a License for CiscoWorks Applications
Collecting Self Test Information
Maintaining Log Files on Windows
Effects of Third Party Backup Utility and Virus Scanner
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.
The following sections give details on configuring the server, and managing security and data:
•
Managing Security in Single Server Mode
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Setting up Security
Common Services provides security mechanisms that help to prevent unauthenticated access to the CiscoWorks Server, CiscoWorks applications, and data. Common Services provides features for managing security when operating in single-server and multi-server modes.
You can specify the user authentication mode using the AAA Mode Setup. You can create user accounts on Cisco.com using the Cisco.com Connection Management UI.
Managing Security in Single Server Mode
You can set up browser-server security, add and modify users, and create self signed certificate using the features that come under Single-Server Management link in the Security Settings UI.
For details, see:
•
•
Setting up Browser-Server Security
Common Services provides secure access between the client browser and management server. 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.
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.
Irrespective of the Browser-Server security mode, the login pages are always rendered in SSL.
CiscoWorks Server uses certificates for authenticating secure access between the client browser and the management server.
•
•
Enabling Browser-Server Security From the CiscoWorks Server
To enable Browser-Server Security:
Step 1
The Browser-Server Security Mode Setup dialog box appears.
Step 2
Step 3
Step 4
Step 5
On Windows:
a.
b.
On Solaris:
a.
b.
Step 6
When you restart the CiscoWorks session after enabling SSL, you must enter the URL with the following changes:
•
•
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.
Enabling Browser-Server Security From the Command Line Interface (CLI)
To enable Browser-Server Security from CLI:
Step 1
Step 2
Step 3
Step 4
About User Accounts
Several CiscoWorks network management and application management operations are potentially disruptive to the network or to the applications themselves, and must be protected.
To prevent such operations from being used accidentally or maliciously, CiscoWorks uses a multi-level security system that only allows access to certain features to users who can authenticate themselves at the appropriate level.
Common Services provides two predefined login IDs:
•
•
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.
However, as an administrator, you can create additional unique login IDs for users at your company.
Note
Understanding Security Levels
System administrators determine user security levels when users are granted access to CiscoWorks. When users are granted logins to the CiscoWorks application, they are assigned one or more roles.
A role is a collection of privileges that dictate the type of system access you have. A privilege is a task or operation defined within the application. The set of privileges assigned to you, defines your role and dictates how much and what type of system access you have.
The user role or combination of roles, dictates which tasks are presented to the users. Table 3-1 shows the security levels.
Table 3-1 Security Levels
0
Help Desk
1
Approver
2
Network Operator
4
Network Administrator
8
System Administrator
16
Export Data
For information on tasks that can be performed with each role, see the "Permissions Report" section.
See also "About Common Services Authentication" section.
Other roles are displayed, depending on your applications.
Setting up Local Users
Local User Setup feature helps you in:
For information on tasks that can be performed with each role, see the "Permissions Report" section.
Modifying Your Profile
To edit your profile:
Step 1
The Local User Setup page appears.
Step 2
Step 3
Step 4
Step 5
Step 6
Adding a User
You can add further users into CiscoWorks as required. To add a user:
Step 1
The Local User Setup page appears.
Step 2
The User Information dialog box appears.
Step 3
By default, the minimum character limit for CiscoWorks local username is 5 characters. To add a local username with less than five characters, change the entry for "validateUser" to "false" in NMSROOT/lib/classpath/ss.properties file.
Step 4
Step 5
Step 6
Step 7
The following roles are available:
•
•
•
•
•
•
See "About Common Services Authentication" section for more details.
Editing User Profiles
You can edit the user profiles to modify the roles assigned to the users.
To edit user profiles:
Step 1
The Local User Setup page appears.
Step 2
The User Information dialog box appears.
Step 3
Step 4
Step 5
Step 6
In the Roles pane, select or deselect the check box corresponding to the role to change the role to be assigned to the user.
Deleting a User
To delete a user:
Step 1
The Local User Setup page appears.
Step 2
Step 3
A confirmation dialog box appears.
Step 4
Creating Self Signed Certificate
CiscoWorks allows you to create security certificate used to enable SSL communication between your client browser and management server.
Self signed certificates are valid for five years from the date of creation. When the certificate expires, the browser prompts you to install the certificate again from the server where you have installed CiscoWorks.
Note
To create a certificate:
Step 1
The Certificate page appears.
Step 2
Step 3
The process generates the following files:
•
•
•
•
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.
Working With Third Party Security Certificates
CiscoWorks provides an option to use security certificates issued by third party certificate authorities (CAs). You may want to use this option in cases where your organizational policy prevents you from using CiscoWorks self-signed certificates or requires you to use security certificates obtained from a particular CA.
You can use these certificates to enable SSL when you need secure access between CiscoWorks Server and your client browser.
Uploading Third Party Security Certificates to CiscoWorks Server
You can upload Third Party Security Certificates using the SSL Utility Script.
This utility is available at:
•
•
This utility has the following options:
Using the SSL Utility Script to Upload Third Party Security Certificates
To upload the certificates:
Step 1
On Windows:
•
On Solaris:
•
Step 2
On Windows:
a.
b.
On Solaris:
a.
b.
Step 3
Step 4
The script verifies if the server certificate is valid. After the verification is complete, the utility displays the options.
Note
Step 5
Select option 6, if you have a certificate chain to upload, that is if you have a server certificate and intermediate certificates.
Note
Step 6
SSL Utility uploads the certificates, if all the details are correct and the certificates meet CiscoWorks requirements for security certificates.
Step 7
Note
See Understanding CiscoWorks Security, for related information.
Managing Security in Multi-Server Mode
Communication between peer servers part of a multi server domain has to be secure. In multi-server mode the server is configured as DCR Master/Slave or SSO Master/Slave. In a multi-server scenario, secure communication between peer CiscoWorks Servers is enabled using certificates and shared secrets.
You must copy certificates between the CiscoWorks Servers. You should also 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).
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
Peer server Account Setup helps you create users who can programmatically login to CiscoWorks Servers and perform certain tasks. These users should be set up to enable communication between multiple CiscoWorks Servers. Users created using Peer Server Account Setup can authenticate processes running on remote CiscoWorks Servers.
In ACS mode, the user created with Peer Server Account Setup needs to be configured in ACS, with all the privileges that user has in CiscoWorks.
See "Master-Slave Configuration Prerequisites" section 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
Step 2
The Peer Server Account Setup page appears.
Step 3
Step 4
Step 5
Step 6
To edit User information:
Step 1
Step 2
The Peer Server Account Setup page appears.
Step 3
Step 4
Step 5
To delete a User:
Step 1
The Peer Server Account Setup page appears.
Step 2
Step 3
The confirmation dialog box appears.
Step 4
Setting up System Identity Account
Communication between multiple CiscoWorks Servers is enabled by a trust model addressed by certificates and shared secrets. System Identity setup helps you to create a "trust" user on servers that are part of a multi-server setup. This user enables communication between servers that are part of a domain.
There can only be one System Identity User for each machine.
The System Identity User you configure must be a Peer Server User.
In Non-ACS mode, the System Identity User you create must be a Local User, with all 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.3, for details.
However, you can create a System Identity User from the Common Services UI too (Common Services > Server > Security > System Identity Setup).
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:
•
•
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.
See "Master-Slave Configuration Prerequisites" section and "Enabling Single Sign-On" section to know more on the usage of this features.
To add a System Identity user:
Step 1
Step 2
Step 3
Step 4
Step 5
Setting up Peer Server Certificate
You can add the certificate of another CiscoWorks Server into it's trusted store. This will allow one CiscoWorks Server to communicate to another. If a CiscoWorks Server needs to communicate to another CiscoWorks Server, it must possess the Certificate of the other server. You can add Certificates of any number of peer CiscoWorks Servers to the trusted store.
Ensure that there are no mismatches in the date and time settings between the servers. In case you find any date/time mismatch, you need to correct it before proceeding.
If you change the date/time of the peer server, you must regenerate the self signed certificate of the peer server.
To add peer CiscoWorks Server certificates:
Step 1
The Peer Server Certificate page appears with a list of certificates imported from other servers.
Step 2
Step 3
Step 4
Step 5
The default Non-SSL(HTTPS) Port of the peer CiscoWorks Server is 443.
Deleting Peer Certificates
To delete peer certificates:
Step 1
Step 2
You can also view the details of the client certificates. For this, select the check box corresponding to the certificate and click View.
Enabling Single Sign-On
With Single Sign-On (SSO), you can use your browser session to transparently navigate to multiple CiscoWorks Servers without authenticating to each of them. Communication between multiple CiscoWorks Servers is enabled by a trust model addressed by Certificates and shared secrets.
The following tasks need to be done initially:
•
•
•
The SSO authentication server is called the Master, and the SSO regular server is called the Slave.
The following tasks should be performed if the server is either configured as Master or Slave.
•
•
Single Sign On is used only for authentication and not for authorization. In Single Sign On, authentication always takes place from the SSO Master server. Authorization happens at the server that is being accessed.
The privileges for the logged in user in any server within the SSO domain will depend upon the user's roles configured in that server. If the user is present only in SSO authentication server and not in regular server, then that user gets authenticated according the credentials in authentication server, but has only have HelpDesk privileges in regular server.
We recommend that you:
•
•
•
To set up System Identity User:
Step 1
Step 2
Step 3
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 Common Name (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 Domain
The Authentication Server and all Regular Servers that are configured on this Authentication Server forms an SSO domain. If you login to any of the servers that are part of the same SSO domain, you can launch any other server that is part of the domain.
You can navigate through the SSO domain in two ways:
•
Registering Server Links
You can register the links of servers part of the SSO domain, in any of the servers, using the Link registration feature. See "Registering Links With CWHP" section.
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.doIf ABC is running in HTTPS mode, you have to specify the URL as:
https://ABC:443/cwhp/cwhp.applications.doIn the above example, clicking on the registered link will launch the CiscoWorks Homepage of server ABC.
Launching a New Browser Instance
After logging in to any of the servers part of the SSO domain, you can open a new browser instance from that server, and provide the URL of any other server part of the SSO domain, to which you need to navigate to.
Note
Suppose ABC and XYZ are part of an SSO domain.
Step 1
Step 2
Step 3
This launches the CiscoWorks Homepage of XYZ, directly.
Changing the Single Sign-On Mode
The Common Services server can be configured for Single Sign-On (SSO). It can also be configured to be in Standalone mode (Normal mode, without SSO).
When the server is configured for SSO, it can either be in:
•
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.
•
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:
•
•
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.
To change the SSO mode to Standalone:
Step 1
The Single Sign-On Configuration page shows the current Single Sign-On mode.
Step 2
Step 3
Step 4
To change the SSO mode to Master:
Step 1
The Single Sign-On Configuration page shows the current Single Sign On mode.
Step 2
Step 3
Step 4
To change the SSO mode to Slave:
Step 1
The Single Sign-On Configuration page shows the current Single Sign-On mode.
Step 2
Step 3
Step 4
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.
Step 5
It checks whether:
•
•
•
In case these checks fail, you are prompted to perform these steps, before proceeding.
Setting up the AAA Mode
The CiscoWorks Server provides mechanisms used to authenticate users for CiscoWorks applications.
CiscoWorks login modules allow administrators to add new users using a source of authentication other than the native CiscoWorks Server mechanism (that is, the CiscoWorks Local login module). You can use Cisco Secure ACS services for this purpose (see Setting the Login Module to ACS).
However, many network managers already have a means of authenticating users. To use your current authentication database for CiscoWorks authentication, you can select a login module (Kerberos, TACACS+, Radius, and others).
After you select and configure a login module, all authentication transactions are performed by that source.
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.
CiscoWorks Common Services supports two AAA modes:
•
•
To use this mode, you must have a Cisco Secure ACS (Access Control Server), installed on your network. Common Services 3.0.3 supports the following versions of Cisco Secure ACS:
–
–
–
–
–
–
–
We recommend that you install the Admin HTTPS PSIRT patch, if you are using ACS 3.2.3.
To install the patch:
•
•
See "Setting the Login Module to Non-ACS" section and "Setting the Login Module to ACS" section for details on usage of the login modules.
About Common Services Authentication
By default, CiscoWorks Common Services uses CiscoWorks Server authentication (CiscoWorks Local) to authenticate users, and authorize them to access CiscoWorks Common Services applications.
After authentication, your authorization is based on the privileges that have been assigned to you.
A privilege is a task or an operation defined within the application. The set of privileges assigned to you, defines your role. It dictates how much, and what type of system access you have.
The CiscoWorks Server authorization scheme has five default roles. They are listed here from the least privileged to most privileged:
•
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.
•
Can approve all tasks.
•
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.
•
Can do all Network Operators tasks. Can do tasks that result in a network configuration change.
•
Can perform all CiscoWorks system administration tasks.
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).
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.
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 and "Creating and Modifying Roles in ACS" section sections for details.
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 specifies 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 specified 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, and the various configuration options see the User Guide for Cisco Secure ACS for Windows Server Version 3.3 on Cisco.com, or the CiscoSecure ACS Online help.
Setting the Login Module to Non-ACS
The Login Module defines how authorization and authentication are performed.
To set the login module to Non-ACS mode:
Step 1
Step 2
The Login Module window displays the current login module, and the available login modules. The available login modules are:
•
•
•
•
•
•
•
•
•
The login username is case sensitive when you use the following Non-ACS login modules:
•
•
•
•
•
Changing Login Module to CiscoWorks Local
To change the login module to CiscoWorks Local:
Step 1
Step 2
The Login Module Options popup window appears.
Step 3
Set it to True for debugging purposes, when requested by your customer service representative.
Changing Login Module to IBM SecureWay Directory
The IBM SecureWay Directory login module implements Lightweight Directory Access Protocol (LDAP). Before a user can log in, a user's account is set up in the LDAP server. The user's account has two fields, Distinguished name and password.
A Distinguished name is made up of three parts, Prefix, User login, and Usersroot. Userroot is queried for the username during login and the Distinguished name is automatically created.
If the user is not found, then the Distinguished name is created by appending Prefix + login name + Usersroot.
For example, a Distinguished name could be represented as: uid=John ou=embu o=cisco.com, where the Prefix is uid=, the login name is John, and the Usersroot ou=embu, o=cisco.com).
To change the login module to IBM SecureWay Directory:
Step 1
Step 2
The Login Module Options popup window appears with the following details:
Step 3
Changing Login Module to KerberosLogin
Kerberos provides strong authentication for client/server applications by using secret-key cryptography.
To change the Login Module to KerberosLogin:
Step 1
Step 2
The Login Module Options popup window appears with the following details:
Step 3
Changing Login Module to Local Unix System
This option is available only on Unix systems.
To change the login module to Local Unix System:
Step 1
Step 2
The Login Module Options popup window appears with the following details:
Step 3
Changing Login Module to Local NT System
This option is available only on Windows
To change the login module to Local NT System:
Step 1
Step 2
The Login Module Options popup window appears with the following details:
Step 3
Changing Login Module to MS Active Directory
The MS Active Directory login module implements Lightweight Directory Access Protocol (LDAP). Before a user can log in, a user's account is set up in the LDAP server. The user's account has two fields, Distinguished name and password.
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.
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
Step 2
The Login Module Options popup window appears with the following details:
Step 3
Changing Login Module to Netscape Directory
The Netscape Directory login module implements Lightweight Directory Access Protocol (LDAP). Before a user can log in, a user's account is set up in the LDAP server. The user's account has two fields, Distinguished name and password.
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
Step 2
The Login Module Options popup window appears with the following details:
Step 3
Changing Login Module to Radius
To change login module to Radius:
Step 1
Step 2
The Login Module Options popup window appears with the following details:
Step 3
Changing Login Module to TACACS+
To change login module to TACACS+:
Step 1
Step 2
The Login Module Options popup window appears with the following details:
Note
Step 3
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
Understanding Fallback Options for Non-ACS mode
Fallback options allow you to access the software if the login module fails, or you accidentally lock yourself or others. There are three login module fallback options. These are available on all platforms. The Table 3-2 gives details:
Setting the Login Module to ACS
The Login Module determines the type of authentication and authorization Common Services uses. By default, the login module is set to local authentication and authorization.
You can change this default value to use Cisco Secure ACS for user authentication and authorization.
When you change login module to ACS ensure that:
•
The same secret key should be entered in the AAA Mode Setup dialog box.
•
CiscoWorks uses HTTP port 2002 to communicate with ACS.
To set login module to ACS:
Step 1
The AAA Mode Setup page appears with the AAA Mode Setup dialog box.
Step 2
Step 3
•
•
•
and the corresponding ACS TACACS+ port numbers.
The default port is 49. Secondary and Tertiary IP address/hostname details are optional.
Step 4
•
•
•
Also, re-enter the ACS admin password, and ACS shared secret key in the Verify fields.
The ACS administrator configured in Common Services must have atleast the following privileges in ACS:
•
•
•
Step 5
When you select the Register all installed applications with ACS checkbox, you will be prompted to confirm whether you want to proceed with the registration.
When you confirm this, all installed applications are registered with ACS, but any custom role created in ACS will be lost.
To register an application with ACS without overwriting the custom roles created for other applications, use AcsRegCli.pl command line script. See Using AcsRegCli Script for details.
Step 6
Step 7
On Windows:
a.
b.
On Solaris:
a.
b.
The application registration with ACS fails due to any of the following reasons:
•
•
•
–
–
–
Select the Connect to ACS in HTTPS Mode check box in the Login Module dialog box, if ACS is in HTTPS mode.
Note
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.
TACACS+ is used for AAA requests. HTTP/HTTPS mode is used for application registration, and device or device group import/export tasks.
Note
Using AcsRegCli Script
You can use the AcsRegCli.pl command line script to register an application without affecting the registration status of other applications. The script is located at NMSROOT/bin.
You can run AcsRegCli.pl only when the CiscoWorks server is in ACS mode.
You can login to the CiscoWorks server using the ACS log in module.
AcsRegCli.pl does the following:
•
•
•
•
Running the Script
To get a list of available options, run the script AcsRegCli.pl without specifying any option.
The following options are listed:
•
•
•
To know this value, run AcsRegCli.pl with the option -listRegApp or -listNotRegApp.
•
For Example:
/opt/CSCOpx/bin/perl /opt/CSCOpx/bin/AcsRegCli.pl -register rme
This registers RME with ACS.
•
•
You will be prompted for confirmation even when you have not registered the application from the current server. If you have already registered the application with ACS from another server and if you confirm and proceed after the warning message, any custom roles you have created in ACS for this application will be lost.
Assigning Privileges in ACS
You have to ensure that the user has been assigned the proper privileges in ACS mode.
To assign the privileges to the user if ACS is configured to use group authentication:
Step 1
Step 2
Step 3
A page appears with the group settings.
Step 4
•
•
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.
•
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
To assign the privileges if ACS is configured to use user authentication:
Step 1
Step 2
Or,
Click List all Users and click the required user link from the User List.
A page appears with the user details and settings.
Step 3
•
•
•
Select the desired role from the drop-down list. The user can perform the tasks that are assigned to the chosen role, on every device.
•
Select the device group from the Device Group drop-down list. Choose the role you want to associate with the group. The user can perform the tasks that are assigned to the chosen roles on the chosen device groups.
Step 4
Creating and Modifying Roles in ACS
In ACS, you can create new roles or modify existing roles.
To create a new role:
Step 1
Step 2
Step 3
Step 4
Step 5
Tasks are displayed as a checklist tree on the left pane of the ACS UI.
•
•
Step 6
To edit an existing role:
Step 1
Step 2
Step 3
The Shared Profile Components page displays the Edit dialog box.
Step 4
If you want to remove any task associated with the role, deselect the check box corresponding to the task.
Step 5
To delete a role:
Step 1
Step 2
The Shared Profile Components page appears.
Step 3
The Shared Profile Components page displays the Edit dialog box.
Step 4
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.
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
•
or
•
Step 2
•
or
•
Step 3
•
or
•
This resets the login module to CiscoWorks local mode.
Multiple instances of same application (for example, Common Services) using the same ACS server will share the settings. Any change affects all instances of the application. If the application is configured with ACS and then the application is reinstalled, the application inherits the old settings.
Understanding Fallback Options for ACS Mode
Fallback option in ACS mode is different from Non-ACS mode. Here, fallback is provided only for authentication. If authentication with ACS fails, authentication is tried with CiscoWorks local mode.
If it succeeds, you are allowed to change the login module to Non-ACS mode, provided you have permission to do that operation in Non-ACS mode. You will not be allowed to login if the authentication fails in CiscoWorks local mode.
If you log in using fallback mode, a dialog box appears with instructions to change the login mode to CiscoWorks local.
To change the login mode follow the procedure described in Resetting Login Module section.
To add the fallback users in ACS, the admin should:
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Step 7
Managing Cisco.com Connection
Certain Software Center features require Cisco.com access. This means that CiscoWorks must be configured with a Cisco.com account which is to be used when downloading new and updated packages.
Setting up Cisco.com User Account
To set up Cisco.com login account:
Step 1
The Cisco.com Login dialog box appears.
Step 2
Step 3
Step 4
Setting Up the Proxy Server
You can update the proxy server configuration using the Proxy Server set up option.
To update your proxy server configuration:
Step 1
The Proxy Information dialog box appears.
Step 2
Step 3
Generating Reports
Common Services includes a Report Generator that provides detailed reports on log file status, roles and privileges, users currently logged in, and processes that are currently running.
The following reports are available:
The following sections describe how to launch these reports, and explain each report.
Log File Status Report
The Log File Status Report provides information on log file size and file system utilization.
To generate the log file status report:
Step 1
The Reports page appears.
Step 2
Step 3
The Log File Status Report appears with the following details:
Permissions Report
The Permissions Report provides information on roles and privileges associated with the roles. It specifies the tasks that a user in a particular role can perform.
A privilege is a task or an operation defined within the application. The set of privileges assigned to you, defines your role and dictates how much, and what type of system access you have.
To generate the Permissions Report:
Step 1
The Reports page appears.
Step 2
Step 3
The Permissions Report appears with the following details:
Users Logged In Report
The Users Logged In Report provides information on users currently logged into Common Services.
To generate the Report:
Step 1
The Reports page appears.
Step 2
Step 3
The Users Logged In report appears with the following information:
Process Status Report
The Process Status Report shows the status of the processes running on the CiscoWorks Server.
To generate the Process Status Report:
Step 1
The Reports page appears.
Step 2
Step 3
The Process Status Report appears with the following information:
Process Name
Name of the process.
State
Current state of the process.
Pid
Process ID.
Start Time
Time at which the process started.
Stop time
Time at which the process stopped.
Viewing Audit Log Report
Audit log provides information on:
•
•
•
•
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).
•
•
To view Audit Log Report:
Step 1
Step 2
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.
Step 3
Audit log report in Non-ACS mode:
Audit log report in ACS mode:
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, its value will not be displayed in the Report.
If you want to view Audit Logs for Local UserManagement operations in ACS mode, you must select the Log Update/Watchdog Packets from this AAA Client checkbox for the CiscoWorks server added as a AAA client in the ACS server.
If you do not select the reason field in CSV TACACS+ Administration in ACS, you will not be able to view the status of the operations.
To enable this option:
Step 1
Step 2
The AAA Client Setup For CiscoWorks Server appears.
Step 3
Step 4
The Audits logs for Local UserManagement operation are logged in the Reports and Activity: TACACS+ Administration reports.
To view the Audit Logs from ACS:
Step 1
A list of report types appears.
Step 2
A list of Audit Logs appears.
In Cisco Secure ACS for Windows server, 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. Whereas, Cisco Secure ACS for Appliance maintains a single log until its size exceeds 10MB.
Administering Common Services
Common Services includes several administrative features to ensure that the server is performing properly. You can manage process, set up backup parameters, update licensing information, collect server information, and manage jobs and resources.
Using Daemon Manager
The Daemon Manager provides the following services:
•
•
•
•
The Daemon Manager is useful to applications that have long-running processes that must be monitored and restarted, if necessary. It is also used to start processes in a dependency sequence, and to start transient jobs.
Restarting Daemon Manager on Solaris
To restart Daemon Manager on Solaris:
Step 1
Step 2
/etc/init.d/dmgtd stop
Step 3
/etc/init.d/dmgtd start
Note
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.
Restarting Daemon Manager on Windows
To restart Daemon Manager on Windows:
Step 1
Step 2
net stop CRMdmgtd
Step 3
net start CRMdmgtd
Do not start the Daemon Manager immediately after you stop it. The ports used by Daemon Manager will be in use for some more time even after the Daemon Manager is stopped. Wait for at least one minute before you start the Daemon Manager.
If the System resources are less than the required resources to install the application, Daemon Manager restart displays warning messages that are logged into syslog.log.
Managing Processes
CiscoWorks applications use back-end processes to manage application-specific activities or jobs. The process management tools enable you to manage these back-end processes to optimize or troubleshoot the CiscoWorks Server.
Viewing Process Details
To view Process details:
Step 1
The Process page appears.
Step 2
The Process Details popup window appears wit h information on the path, flags, startup, and dependencies.
Starting a Process
To start a Process:
Step 1
The process page appears.
Step 2
Step 3
Stopping a Process
To stop a Process:
Step 1
The Process page appears.
Step 2
Step 3
Backing Up Data
You should back up the database regularly so that you have a safe copy of the database. You can schedule immediate, daily, weekly, or monthly automatic database backups.
You cannot back up the database while restoring the database. Common Services uses multiple databases to store client application data. These databases are backed up whenever you perform a backup. Backup requires enough storage space on the target location for the backup to start.
To schedule a backup:
Step 1
The Backup page appears.
Step 2
Step 3
Backing up Using CLI
To Backup data using CLI on Windows and Solaris:
On Windows, run:
NMSROOT/bin/perl NMSROOT/bin/backup.pl BackupDirectory [LogFile] [Num_Generations]
On Solaris, run:
/opt/CSCOpx/bin/perl /opt/CSCOpx/bin/basckup.pl BackupDirectory [LogFile] [Num_Generations]
•
•
•
Data Backed up During CS 3.0/3.0.3 Backup
The following data is backed up:
•
•
•
•
•
•
•
•
•
•
•
•
•
Restoring Data
The new restore framework supports restore across versions. This enables you to restore data from versions 2.1, 2.2, and 3.0, in addition to Common Services 3.0.3
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, the backup data is converted to Common Services 3.0.3 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.
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 Data on UNIX
To restore the data on UNIX:
Step 1
Step 2
/etc/init.d/dmgtd stopStep 3
/opt/CSCOpx/bin/perl /opt/CSCOpx/bin/restorebackup.pl [-t temporary directory] [-gen generationNumber] [-d backup directory] [-h]
•
•
•
•
Step 4
/opt/CSCOpx/bin/perl /opt/CSCOpx/bin/restorebackup.pl -d backup directory
For example, -d /var/backup
Step 5
/var/adm/CSCOpx/log/restorebackup.log
Step 6
/etc/init.d/dmgtd start
Restoring Data on Windows
To restore the data on Windows:
Make sure you have the correct permissions.
At the command line:
Step 1
net stop crmdmgtd
Step 2
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
NMSROOT\bin\restorebackup.pl -d backup directoryFor example, -d drive:\var\backup\
When you restore the backup taken from a CS2.2 server, on a CS3.0 server, restore might fail if the backup archive has any file or folder with a long path name.
The following error message will be displayed:
ERROR: Restore cannot proceed. Seems you are hitting the bug CSCec01327To workaround this problem, you have to install the patch cmf2.2-win-CSCec013271.tar on the CS2.2 server, before taking the backup.
The patch is available at:
http://www.cisco.com/cgi-bin/tablebuild.pl/cw2000-cd-one
Note
Step 4
NMSROOT\log\restorebackup.log
Step 5
net start crmdmgtdWhile 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.
Data Restored From Common Services 3.0/3.0.3 Backup Archive
The following data will be restored from a Common Services 3.0/3.0.3 backup archive:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Data Restored From Common Services 2.2 Backup Archive
The following data will be restored from Common Services 2.2 backup archive:
•
•
•
•
•
•
Though Common Services 2.2 supports ACS login module, restoring from a Common Services 2.2 backup archive will not restore the ACS login module. After restore, the login module of the machine will be non-ACS, TACACS+.
Data Restored From CD One 5th Edition Backup Archive
The following data will be restored from CiscoWorks2000 Server (CD One 5th edition) backup archive:
•
•
•
•
•
Effects of Backup-Restore on DCR
Data changes are a normal part of any restore from a backup. However, because Device and Credential Repository (DCR) is a distributed system with varying modes, it is also possible for any restored DCR to:
•
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.
•
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 "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.
•
•
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.
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
Step 2
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
Step 4
Step 5
Step 6
Step 7
This ensures that Master has more recent data than the Slaves.
Note
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.
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.
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.
Effects of Backup-Restore on Groups
Backup- Restore operations have an implication on the way Groups will be displayed in the Common Services (CS) UI. The changes in Groups behavior is discussed in relation with the Device and Credential Repository (DCR) mode changes explained in the above section.
If you perform a backup on machine A and restore the backed up data, say Ab, on the same machine, the system defined groups, and the user defined groups created after the data backup will be removed.
Restoring data From a DCR Standalone
The following scenarios have to be considered:
•
The provider group name will change accordingly. That is, the provider group CS @A will become CS@B.
•
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.
•
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.
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.
Restoring Data From S1 on M1
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.
Restoring Data From S1 on M2
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 Applications
You must register your software and obtain a product license before you start using an application. You can obtain a product license and license your application, view details of your current software license, or update to a new license from the Licensing page.
Obtaining a License for CiscoWorks Applications
To obtain a product license for your CiscoWorks applications, register your software at one of the following websites. You will need to provide the Product Authorization Key (PAK), which is printed on a label affixed to the Bundle sub-box.
If you are a registered user of Cisco.com, use this website:
http://www.cisco.com/go/license
If you are not a registered user of Cisco.com, use this website:
http://www.cisco.com/go/license/public
The product license will be sent to the e-mail address you provide during registration.
Retain this license with your CiscoWorks software records.
Licensing the Application
After you obtain the product license, perform these steps to license your software:
Step 1
Step 2
The License Information dialog box appears. The License Information page displays the name, version, device limit, status and expiration date of the license.
Step 3
Step 4
Step 5
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.
Viewing License Information
To view details of your current software license select Common Services > Server > Admin > Licensing.
The License Information page appears. The license name, license version, size (device limit for the licensed application), status of the license, and the expiration date of the license appear under License Information.
The license version shows the major version of the applications. To know the version with patch level, go to the Software Center > Software Updates page.
Updating Licenses
You can view details of your current software license, or update to a new license from the License page.
To update to a new license from the Licensing page:
Step 1
The License Information page displays the license name, license version, status of the license, and the expiration date of the license.
Step 2
Step 3
Step 4
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.
Collecting Server Information
This feature helps you to get information about the server. It provides system information, environment, configuration, logs, and web server information. This information can be used for trouble shooting.
To collect server information:
Step 1
The Collect Server Information page appears.
Step 2
The Collect Server Information pop-up dialog box appears with a list of options.
Step 3
By default all the check boxes are selected.
Step 4
The pop-up window displays the server information collected.
Step 5
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:
•
NMSROOT\bin\collect.info•
NMSROOT/bin/collect.infowhere NMSROOT is the directory where you installed CiscoWorks.
Collecting Self Test Information
You can view self test reports using this option. Selftest feature helps to test certain basic functions of the server.
Step 1
Step 2
Step 3
A pop-up window displays the selftest information report.
To delete a Self Test Information report, select the check box and click Delete.
Messaging Online Users
You can use the Notify User feature in Common Services to broadcast messages to online users. You can post messages to users with active CiscoWorks browsers. The message will be received within 60 seconds.
To send a broadcast message:
Step 1
The Logged in Users dialog box lists all the users currently logged in.
Step 2
The Status field displays the status of the message.
Note
Managing Jobs
Common Services provides a Job Browser for managing jobs. From the Job browser you can view a listing of jobs, view details of each job, stop a job, and also delete a job from the list.
Users in Help Desk, Approver, and Network Operator roles are not allowed to stop and delete jobs.
All users (including Help Desk) can access the Job browser page. The Refresh button in Job browser is available for all users.
Note
To view the list of jobs:
Step 1
The Job Browser page appears with the following details:
To view Job details:
Step 1
The Job Browser page appears.
Step 2
The Job Details popup displays the job details.
To stop a Job:
Step 1
The Job Browser page appears.
Step 2
Step 3
Normal jobs when stopped, prompt you to confirm whether the job needs to be stopped or not.
However, when you stop jobs that have several instances, you are prompted to specify whether you need to stop the current instance of the job alone, or the current instance and all the future instances as well.
You can stop only one job at a time.
To delete a job, click Delete, after selecting the desired check box.
You can delete multiple jobs at a time. You cannot delete a running job.
All users (except Help Desk) can perform Stop and Delete operations in the job browser.
Managing Resources
Common Services provides a Resource Browser for managing resources. You can free locked resources, when necessary, if you have appropriate privileges. All users (including those with Help Desk role alone) can access the Resource browser page. The Refresh button in the Resource browser is available for all users.
Note
To view Resource details:
Step 1
The Resource Browser page displays the following details:
To free locked resources:
Step 1
The Resource Browser page appears.
Step 2
Step 3
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.
Maintaining Log Files
Log files can grow and fill up disk space. CiscoWorks includes a script that enables you to control this growth.
Files maintained by this script include the following log files:
•
•
Most log files are located in directories in the following locations:
•
•
Caution
The following section provides information on maintaining log files n Unix, and Windows:
•
•
Maintaining Log Files on UNIX
To maintain log files on UNIX:
Step 1
Step 2
Step 3
Step 4
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
/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
Step 7
Maintaining Log Files on Windows
To maintain log files on Windows:
Step 1
Step 2
Step 3
net stop crmdmgtd
Step 4
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
NMSROOT\log\
Only log files that reach 90% of their size limits are backed up, and the original log file is emptied.
Step 6
net start crmdmgtd
Step 7
Using Logrot
The logrot utility helps you manage the log files in a better fashion.
Logrot is a log rotation program that can:
•
•
•
Logrot helps you add new files easily. Logrot should be installed on the same machine where you have installed Common Services.
Configuring Logrot
To configure logrot:
Step 1
Run /opt/CSCOpx/bin/logrot.pl -c (On UNIX)
The logrot configuration menu appears. You have the following options:
1.
2.
3.
4.
Step 2
If you do not set a backup directory, each log will be rotated in its current directory.
Step 3
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
Step 5
Step 6
•
•
•
When deleting logfiles, you can choose to delete an individual file, a list of files, or a all files matching a certain pattern.
For example, 1-3 means delete files numbered 1 through 3. a list of comma-separated file numbers, for example, 1,21, means delete files numbered 1 and 21. A pattern string *.log means delete all files that match the pattern *.log.
You can also specify the special pattern, *, which means delete all logfiles in the configuration.
Running Logrot
To run Logrot enter either of the following:
On Windows:
Enter NMSROOT\bin\perl.exe NMSROOT\bin\logrot.pl
On Unix:
Run /opt/CSCOpx/bin/logrot.pl
You can schedule log rotation so that the utility works on a specified time and day.
The following command line flags are accepted:
•
•
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.
•
Modifying System Preferences
You can configure system-wide information on the CiscoWorks Server using the System Preferences option. It is a way to centrally locate information that is used by CiscoWorks applications.
To edit system preferences:
Step 1
Step 2
•
•
•
Set this information carefully. If you introduce errors, users may not be able to log in.
Step 3
Effects of Third Party Backup Utility and Virus Scanner
Sometimes, the CMF database fails to run and throws the following Sybase Assertion error message:
*** ERROR *** Assertion failed: 100909 (9.0.0.1383).100909 is the Assertion ID.Following are the scenarios where Assertion Error might appear:
1.
This is because some of the database pages that have been modified will be in the database server cache, so the database file will be in an inconsistent state.
2.
The reason is, Adaptive Server Anywhere performs many reads and writes other than the normal I/O operations, which contribute to the good performance of Adaptive Server Anywhere. However, anti-virus software might detect this as a potential problem and quarantine the file. This becomes hazardous if the .log or temporary files are quarantined, and it may cause corruption by interfering with the normal functions of the database. Poor performance can also occur if the anti-virus software is checking all I/O operations performed by the database server.
We recommend that you do not use third-party backup software for backing up a running database.
We also recommend that you configure your anti-virus software so that it must not scan the NMSROOT/databases directory.
NMSROOT is the directory where you have installed CiscoWorks.
Configuring TFTP
This is applicable on Solaris only.
The TFTP (Trivial File Transfer Protocol) daemon shipped by CiscoWorks Common Services supports TCP (Transmission Control Protocol ) Wrappers.
If the TCP Wrapper support is not configured properly in the server where CiscoWorks is installed, the jobs requiring TFTP may fail.
To ensure that TFTP works properly, check the following configuration files:
•
•
•
Note
