-
User Guide for CiscoWorks Common Services 3.3
-
Notices
-
Preface
-
Chapter 1 Overview of Common Services
-
Chapter 2 Interacting With CiscoWorks Home Page
-
Chapter 3 Using Common Services Home
-
Chapter 4 Configuring the Server
-
Chapter 5 Managing Device and Credentials
-
Chapter 6 Administering Groups
-
Chapter 7 Using LMS Setup Center
-
Chapter 8 Using Device Center
-
Chapter 9 Working With Software Center
-
Chapter 10 Diagnosing Problems With CiscoWorks Server
-
Appendix A Understanding CiscoWorks Security
-
Appendix B Acronyms Used in Common Services Documentation
-
Index
-
Table Of Contents
Groups - Components and Basic Concepts
Groups in Single-Server and Multi-Server Setup
Sample Export Groups Output File
Exporting Groups From User Interface
Importing Groups From User Interface
Using Group Administration Features Through CLI
DCR Mode Changes and Group Behavior
Administering Groups
The Groups feature in Common Services helps you to group devices managed by CiscoWorks applications. It helps you to create, manage, and share groups of devices.
The groups created using this feature in Common Services are shared across applications. Similarly, the groups created in applications can also be viewed from Common Services.
The section explains the following:
•
Groups - Components and Basic Concepts
•
•
Groups - Components and Basic Concepts
This section explains the components of a group and the basic concepts of a group.
Components
The following are the components of a group:
•
Manages groups of devices. It helps you to create, edit, delete, and refresh groups to be shared by the application. It interfaces with an application service adapter (ASA) to evaluate group rules and retrieve devices of a particular group.
•
Application-specific information repository that serves as source of the devices and attributes that are grouped by the Groups Server. It provides an interface between applications and Groups Server. For Common Services, Device and Credential Repository (DCR) acts as the ASA. See Managing Device and Credentials for detailed information on DCR.
•
Allows you to interact with the Groups Server to create and manipulate groups using Group Admin.
Basic Concepts
The following are the basic concepts of a group:
•
Representation of a set of devices belonging to DCR. In this context a device in Device and Credential Repository (DCR) is a single instance of a class. Each instance (device) will have a set of attributes and a unique device ID.
•
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.
•
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.
•
Consists of one or more rule expressions combined by operators, which can be AND, OR or EXCLUDE. A rule always evaluates to objects of a particular class defined in an application schema.
Group Concept
A group is a named set of devices. The group is characterized by a set of properties such as an associated rule, name, description, type, and access permission. The rule determines the membership of a group, which may change whenever the rule is evaluated.
Groups are hierarchical. Groups can be dynamic or static. They can be Private or Public.
This section explains the following:
•
•
Group Hierarchy
Groups are managed in a hierarchical fashion that supports subgrouping. Each child group is a subgroup of a parent group, and its group membership will be a subset of its parent group.
Dynamic Group
A dynamic group is a group for which the membership list is always up-to-date.
Whenever you view a dynamic group, it always displays the latest group membership list.
Static Group
A static group is a group for which the membership is refreshed only when you explicitly request it. Between re-evaluations, the Group Server stores the membership list and group definition of the static group.
Whenever you view a static group, you get the membership list that the ASA created the last time the group rule was evaluated.
Container Groups
Container groups are groups without a rule. The group membership is the union of the membership of its subgroups. If a container group does not have subgroups, the membership list will be blank.
System-Defined and User-Defined Groups
After you install Common Services, you get two predefined groups. They are:
•
These 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 or deleted, whenever you add, modify, or delete devices.
•
You can create groups, based on device attributes in DCR. This is possible only if you have administrator privileges.
These predefined groups come under the Provider group (or the root group).The Provider group name is in the format CS@hostname, by default. 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 Server name. You can configure the server name in the Home Page Settings page. See Setting Up CiscoWorks Home Page for details.
You have to restart Daemon Manager after you change the CiscoWorks Server name, for the change in the Provider group name to take effect. After this, the Provider group name will be in the CS@Home Page Server Name format.
You can see these groups in Device and Credential Repository Administration 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 that belong to a single MDF type are deleted, the corresponding JIT group also gets deleted.
Common Groups and Shared Groups
Common groups are the Common Services (CS) groups that are seen in the Groups UIs of Applications. Shared groups are the application groups except the application's local group which can be seen from the Common Services, and Groups UIs of Applications.
You have read-only access on shared groups. You can:
•
•
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:
•
•
•
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 see three provider groups:
•
•
•
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 6-1, is a screen shot taken from the Group Administration UI in Common Services, on a machine (machine name: idu-test-sf440-1) that has Common Services, Campus Manager, RME, and DFM installed, illustrates the concept.
Figure 6-1 Common Services Group Administration Window
In the Group Selector available in the Group Administration page, you can see:
•
•
•
Here, CS@bundle-sun280r2 is the local group, and the rest are shared groups.
Secure Views
Secure Views allow access to devices of a group to be restricted. Secure Views enables filtering of group membership based on the user and the application task context in which a request is made. Filtering will be performed only when the CiscoWorks Server is in ACS mode.
While operating in Non ACS mode, filtering is not performed. If you evaluate a group in Non ACS mode, all devices of that group are returned.
For example, assume there are two users A and B configured in ACS with different sets 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.
Note
Groups in Single-Server and Multi-Server Setup
This section has the following subsections:
•
•
Groups in Single Server Scenario
The devices you see in the Group Administration UI in applications depend on whether the devices are being managed by that particular application or not.
For example, if there are 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.
•
•
•
For example, if you add 100 devices to the subgroup Routers in Common Services, all 100 routers that 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 100 devices that you have added to the group from Common Services. Instead, only the devices that RME manages, are displayed.
Assume that 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 Scenario
Groups you create in Common Services groups UI in the Master get synchronized with the Slave. This does not happen in the case of applications.
If you create a subgroup under CS@Master hostname in one server, it appears under CS@Slave hostname in the peer server.
However, 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
For example, if you have two servers M and S, where M is in Master mode, and S is in Slave mode. Assume both the machines have Common Services, Campus Manager and RME installed.
In Server M, you can see the following groups:
•
•
•
•
•
Figure 6-2 Common Services Groups Window in a Multi-Server Setup
In Figure 6-2, you can see the groups displayed in the Common Services Groups UI, in a multi server scenario.
Note that the machine CSTEST-PC1 is the Master, and the machine Bundle-pc5 is the Slave, in the figure.
In the CS groups UI you can see:
•
•
•
•
•
Similarly, in Server S you can see the following groups from the applications groups UI:
•
•
•
•
•
Figure 6-3 Groups Window in Application in a Multi-Server Setup
In Figure 6-3, you can see the groups displayed in the Application (RME) Groups UI, in a multi server scenario.
Note that the machine CSTEST-PC1 is the Master, and the machine Bundle-pc5 is the Slave, in the figure.
In the applications groups UI you can see:
•
•
•
•
•
If you have created a subgroup under CS@Master hostname, in S, you can see this subgroup under CS@Slave hostname.
However, if you create a subgroup in M under RME@Master hostname, this subgroup 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.
Group Administration
The Group Administration and Configuration UI helps you to create, manage, view, and delete groups. The UI displays a Group Selector that contains the following predefined higher-level groups:
•
•
The System Defined Groups shows subgroups only after Device and Credential Repository is populated.
You can create subgroups only under User Defined Groups. You cannot create them under System Defined Groups. However, you can view the details of a subgroup under System Defined Groups and refresh the group.
Note
The following sections provide information on how to perform group administrative tasks in Common Services:
•
Creating Groups
You can create device groups using this feature.
To create a new device group:
Step 1
The Groups Administration page appears.
If LMS Portal is installed on the CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
The Group Administration and Configuration dialog box in the Group Administration page provides you a Group Selector.
Step 2
The Group Info fields on the right, display details of the selected group.
The group you select here is the Parent group for the new group that you are about to create. You can change the Parent group later, if required. You cannot create groups under System Defined Groups but you can view details and refresh the group.
Users in admin role have read-write access to User-Defined groups based on the visibility scope (Public or Private). If you have the required permissions, you can create subgroups under groups.
Step 3
The Group Administration Creation wizard is launched and guides you through the process of creating a new group.
Perform the following tasks using the Groups Create wizard.
a.
b.
c.
The first page in the wizard is the Properties:Create window. While creating a new group you must complete all of the above 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.
The default limit of User Defined Groups you can create is 200. If you try to create more than 200 User-Defined Groups, you will get a message that that you have exceeded the limit.
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
The Groups Administration page appears.
If LMS Portal is installed on the CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Properties:Create dialog box opens.
Step 3
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.
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 4
The Replicate Attributes dialog box appears.
Step 5
Step 6
The Group Selector page appears.
Step 7
Step 8
The Group Administration wizard changes the Parent group to the one you selected, and returns to the Properties:Create window.
Step 9
Typically, you can enter a detailed description of the group that identifies its characteristics in this field.
Step 10
The modes of membership updates available are:
•
The membership of the group is automatically recomputed each time the group is invoked.
•
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 11
•
The group created can be viewed only by user who creates the group.
•
The group created can be viewed by all users.
Step 12
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.
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"If you have created the group by copying the attributes of another group, the rules specified for that group appear in the Rule Text field. You can retain these and add more rules, or delete these rules and create a new set of rules.
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.
This section explains:
•
•
•
Defining a Group Rule
To create a group rule:
Step 1
Step 2
Step 3
•
•
The list of variables for creating groups are:
–
–
–
–
–
–
–
–
–
–
–
See System Defined and User Defined Attributes for details on the variables.
The device attributes listed in Variables list box are specific to Common Services only. The list of device attributes are different across CiscoWorks applications. The Group Administration windows of respective applications display the respective device attributes as variables
•
For the ManagementIpAddress variable, you can select the range operator other than the standard list of operators. See Using IP Address Range Operator for more information.
•
Step 4
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.
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. See Defining Composite Group Rules for more information.
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.
•
•
Step 5
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. See Assigning Group Membership for more information.
If you have entered an invalid IP Address range or invalid values in the Value field, an error message will be displayed. You should correct the values and then navigate to the Membership:Create dialog box.
Defining Composite Group Rules
Composite rule contain more than one rule expression separated by a Boolean operator.
The Boolean Operators OR, AND, or EXCLUDE appear in the Rules:Create dialog box only when you have entered at least one rule expression.
When the composite rule has more than two simple rule expressions, you can adjust priorities among the expressions using opening and closing parenthesis.
To create a composite rule:
Step 1
Step 2
Step 3
The Group Administration wizard creates the rule based on the parameters you specified and adds the rule to the Rules Text field.
The Rules:Create dialog box refreshes and displays the Boolean operator field before the Object Type field in Rules Expression.
Step 4
Step 5
Step 6
Step 7
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.
•
•
Step 8
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. See Assigning Group Membership for more information.
Using IP Address Range Operator
The range operator enables you to group the devices of the specified range of IP Addresses. You can select the range operator only for the ManagementIpAddress variable.
You should enter the range of IP Addresses in the Value field, to create a group rule based on IP Address ranges.
When you enter the IP Address range in the text field, you should:
•
The minimum limit in the range is 0 and the maximum limit is 255.
•
•
For example, you can enter 10.10.10.[0-255] or 10.10.[0-255].[0-255] in the Value field.
You should not:
•
•
•
See Behavior of IP Address Range Based Device Groups in Multi-Server Setup for more information on the IP Address Range based device groups in a multi-server setup.
Examples
This section contains:
•
•
•
Example to Create a Simple Group Rule
To create a group of all devices ending with the hostname Test, you should:
Step 1
a.
b.
c.
Step 2
The rule is added into the Rule Text.
You can also check the syntax of the group rule entered.
Example to Create a Composite Group Rule
If you may want to group all the devices in the network that matches all of the following criteria:
•
•
To create this composite rule:
Step 1
a.
b.
c.
Step 2
The rule is added into the Rule Text.
Step 3
a.
b.
c.
d.
Step 4
The rule is appended into the Rule Text.
Step 5
a.
b.
c.
d.
Step 6
The following composite rule is formed in the Rule Text Area:
Device.DisplayName contains "TestDevice" ANDDevice.Category equals "Routers" ORDevice.ManagementIpAddress startswith "10.77"Step 7
You should place two rule expressions together within an opening and a closing parentheses. Ensure that you leave a space between the parenthesis and the group expressions.
The edited composite rule is:
Device.DisplayName contains "TestDevice" AND( Device.Category equals "Routers" ORDevice.ManagementIpAddress startswith "10.77" )You can also check the syntax of the group rule entered.
Step 8
Example to Create a Group Rule Using Range Operator
To group all devices whose IP Addresses are within the range 10.10.0.207 to 10.10.212.247, you should:
Step 1
a.
b.
c.
Step 2
The rule is added into the Rule Text.
You can also check the syntax of the group rule entered.
System Defined and User Defined Attributes
The following table provides details on the System Defined attributes that are available in Common Services. These are predefined attributes, available by default.
The User-Defined Fields (UDFs) available in the Variable drop-down list is taken from DCR. You can create UDFs at Common Services > Device and Credentials > Admin. For details, see Adding User Defined Fields.
If you create a UDF 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 UDF called DisplayName (which is one of the predefined attribute present in the Variable drop-down list), this will be displayed as DisplayName_UDF.
Note
By default, four UDFs are available. You can create six UDFs additionally in DCR. The maximum number of UDFs that can be added in the Variable drop-down list is 10.
Assigning Group Membership
You can include more devices or exclude devices using this option. To decide which devices are 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 in the Properties:Create and Rule:Create dialog boxes. See Specifying Group Properties and Defining Group Rules for more information.
Note
To add devices to the group you have created:
Step 1
To select multiple devices, hold the Ctrl or Shift keys down and click on the devices.
Step 2
The selected devices are removed from Available Objects From Parent Group and added to the Object Matching Membership Criteria column.
To remove devices from the group:
Step 1
To select multiple devices, hold the Ctrl or Shift keys down and click on the devices.
Step 2
The selected devices are removed from the Object Matching Membership Criteria column and added to Available Objects From Parent Group.
Step 3
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
Viewing Group Details
You can view the details of a group using this feature.
To view the details of a group:
Step 1
The Group Administration page appears.
If LMS Portal is installed on the CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Group Info pane on the right side displays the high-level properties of the selected group.
Step 3
The Group Administration wizard displays the details of the group in Properties:Details window.
•
The rules set for the parent group are displayed in the Show Parent Rules window.
•
The membership details are displayed in Membership:Details window.
In the Membership:Details window, you can:
–
–
•
Step 4
Modifying Group Details
You can modify some of the details for a group using this feature.
To modify the details of a group:
Step 1
The Group Administration page appears.
If LMS Portal is installed on the CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Group Info fields on the right side displays details of the selected group.
Step 3
The Group Administration wizard guides you through the process of editing a group. It displays the details of the group in Properties:Edit window.
Step 4
You cannot change the Parent group or copy attributes from a different group in Edit mode.
Step 5
The wizard takes you to the Rules:Edit window.
Step 6
Step 7
The wizard takes you to the Membership:Edit window.
Step 8
Step 9
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
Step 11
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.
Refreshing Groups
You can recompute the membership of a group by re-evaluating the group's rule. The membership of Automatic groups is recomputed dynamically.
The membership of Only-upon-user-request groups is recomputed only when explicitly refreshed with this option.
Note
To refresh a group:
Step 1
The Group Administration page appears.
If LMS Portal is installed on the CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Group Info fields on the right pane displays details of the selected group.
Step 3
The Group Administration pop-up window prompts you for confirmation.
Step 4
The selected group is recomputed and the window, refreshed.
Whenever you delete devices from a group, refresh the group so that group membership is recomputed.
Deleting Groups
You can delete a group from the Group Selector. When you delete a group, all the child groups under the group are also deleted. You can also delete the stale groups (groups that are belonging to users removed from CiscoWorks).
To delete a group:
Step 1
The Group Administration page appears.
If LMS Portal is installed on the CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Group Info fields on the right pane displays details of the selected group.
Step 3
The Group Administration and Configuration dialog box prompts you for confirmation.
Step 4
The selected group is deleted.
Deleting Stale Groups Using CLI
You can delete groups that belonged to users removed from CiscoWorks. To delete a stale group, you must run the DeleteStaleGroups utility.
To run the DeleteStaleGroups utility:
On Windows:
Step 1
Step 2
On Solaris:
Step 1
Step 2
The explanation for these optional entries are as follows:
-user: Current user who has the necessary privileges to delete groups.
-pfile: Absolute Path of the text file with current user's CiscoWorks login password in one line.
-staleuser: The user whose group has to be deleted.
If you run the DeleteStaleGroups utility without specifying any of these optional entries, all the stale groups will be deleted.
Exporting Groups
This feature helps you to export a User-defined group hierarchy into a file.
You can export a selected User-defined group hierarchy or all User-defined groups from all applications in a CiscoWorks Server to an output file.
Private User-defined groups created by all user will not be exported. However, the privateUser-defined groups created by you will be exported.
You must have Network Administrator, System Administrator or Super Admin privileges to export groups.
In a Multi-server setup, you can export the User-defined groups from all applications installed in all CiscoWorks Servers of the same DCR domain. However, you can only do this from a DCR Master Server only.
Grouping Services supports exporting User-defined groups to a XML format only. CSV file formats are not supported.
See Sample Export Groups Output File for sample XML file generated by the Grouping Services export utility.
Note
You can:
•
or
•
This section explains:
•
•
Sample Export Groups Output File
<?xml version="1.0" encoding="UTF-8"?><!--This content is generated by OGS Import Export operations--><ogs-groups><server name="CS@server-name"><ogs-group-definition><name>/CS@server-name/User Defined Groups/CSDyna</name><description> </description><rule/><evaluation-type>2</evaluation-type><scope>PUBLIC</scope><tags><tag tag-name="__VIRTUAL_ROOT" tag-value="CS@server-name"/><tag tag-name="USER_DEFINED" tag-value="TRUE"/><tag tag-name="__GROUP_ID" tag-value="CS$216"/><tag tag-name="__GROUP_OWNER" tag-value="admin"/></tags></ogs-group-definition><ogs-group-definition><name>/CS@server-name/User Defined Groups/CSStat</name><description/><rule>:CMF:DCR:Device.DisplayName contains "77"</rule><evaluation-type>1</evaluation-type><scope>PUBLIC</scope><tags><tag tag-name="__VIRTUAL_ROOT" tag-value="CS@server-name"/><tag tag-name="USER_DEFINED" tag-value="TRUE"/><tag tag-name="__GROUP_OWNER" tag-value="admin"/><tag tag-name="__GROUP_ID" tag-value="CS$221"/></tags></ogs-group-definition></server></ogs-groups>Exporting Groups From User Interface
To export device groups from the user interface:
Step 1
The Group Administration page appears.
If LMS Portal is installed on the CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
Step 3
The Export Groups dialog box appears.
Step 4
•
Or
•
The browser-specific File Download window appears prompting you to open or save the output XML OGSExport.xml file.
Step 5
•
Or
•
Importing Groups
This feature helps you to import User-defined group hierarchies from an input XML file onto CiscoWorks Server.
You can import User-defined groups from selected applications or all User-defined groups from an input file to the CiscoWorks Server.
The private User-defined groups in the input XML file will be imported as your private User-defined groups in CiscoWorks Server. They will not be visible to other users.
You must have Network Administrator, System Administrator or Super Admin privileges to import groups.
In a Multi-server setup, you can do the import User-defined groups task from a DCR Master Server only.
The User-defined groups specified in an input XML file are imported to corresponding applications and servers in the Multi-server setup. The Common Services groups are imported to DCR Master Server and the application groups are imported to the respective applications in Master and Slave Servers.
Note
You can:
•
Or
This section explains:
•
Notes on Importing Groups
Read the following notes before importing User-defined groups:
•
For example, consider the CiscoWorks Server has the following applications installed:
–
–
–
But the input source XML file for import has the information of the following application groups:
–
–
–
Only CS and CM groups will be imported to the CiscoWorks Server. RME groups will not be imported as the RME application is not installed on the CiscoWorks Server.
•
•
You must launch the Groups Administration page again to view the newly imported groups.
To launch the Groups Administration page, go to the CiscoWorks home page and select Common Services > Groups > Group Admin.
•
–
–
–
Importing Groups From User Interface
To import device groups from the user interface:
Step 1
The Group Administration page appears.
If LMS Portal is installed on the CiscoWorks Server, you can also navigate to this page from the LMS Portal home page.
Step 2
The Import Groups - File Selection dialog box appears.
Step 3
The Import Groups dialog box appears with a list of import groups specified in the input XML file.
Step 4
You can also select multiple groups.
Step 5
You can select multiple Grouping Server locations or All to select all the Grouping Server locations.
This field is disabled on CiscoWorks Servers operating in the DCR Standalone mode.
Step 6
A message appears indicating whether the import of groups was successful or it failed.
See Notes on Importing Groups for the possible causes for the import groups job to fail.
Using Group Administration Features Through CLI
You can use OGSCli command line utility to:
•
•
You should have Network Administrator, System Administrator, or Super Admin privileges to use OGSCli command line utility.
OGSCli runs in only Batch mode. It runs the specified command and exits to the prompt after the command is run.
This section explains:
Exporting Groups Through CLI
To export groups through CLI:
Step 1
Step 2
•
Or
•
where,
NMSROOT is the directory where you have installed CiscoWorks.
CiscoWorks_Username is the login username of a CiscoWorks user.
For example, you can enter /opt/CSCOpx/bin/OGSCli.sh -u admin on Solaris systems.
The system prompts you to enter your CiscoWorks password.
Step 3
The system prompts you to enter a task name, import or export. The default task is export.
Step 4
The system prompts you to enter an output file name.
Step 5
If you do not enter file the name with its absolute path name, the export file will be stored on default CiscoWorks installation directory.
A warning message appears indicating that the selected file will be overwritten with the new information on exported groups.
The system uses the file name that you have entered to generate the output XML file irrespective of whether the file exists on the server.
You should have the required directory-level permissions where you want to save the output XML file.
You must either enter y to continue or n to exit.
The system prompts you to enter an export group hierarchy.
Step 6
Default value is All.
For example, you can enter the group hierarchy name as /CS@ doc-pc2/User Defined Groups/Group1.
The system generates an export format XML file and stores on the specified directory on the server.
Importing Groups Through CLI
To import groups through CLI:
Step 1
Step 2
•
Or
•
where,
NMSROOT is the directory where you have installed CiscoWorks.
CiscoWorks_Username is the login username of a CiscoWorks user.
For example, you can enter /opt/CSCOpx/bin/OGSCli.sh -u admin on Solaris systems.
The system prompts you to enter your CiscoWorks password.
Step 3
The system prompts you to enter a task name, import or export. The default task is export.
Step 4
The system prompts you to enter the input XML filename.
Step 5
The system lists the groups to be imported from the source XML file.
Step 6
You can enter one or more item numbers separated by comma.
The system lists the Grouping Server locations where you can import the groups.
Step 7
You can enter one or more item numbers separated by comma. You must enter 1 to import the selected groups to all listed servers.
A message appears indicating whether the import of groups is successful.
See Exporting Groups From User Interface for the possible causes for the import groups job to fail.
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 are 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.
Therefore, 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.
Unregistering a Slave
The Unregister Slave utility helps you unregister a Slave which is no longer part of the domain.
The utility is useful in the following scenarios:
•
•
•
The Master will not receive any data from the Slave, but the Slave information will still be in 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. However, this 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 and Effects of Backup-Restore on Groups.
Behavior of IP Address Range Based Device Groups in Multi-Server Setup
The range operator allows you to group devices within a specified range of IP addresses.
In a Master-Slave setup:
•
•
Even if you change the mode of Slave server to Standalone, the IP address range based device groups will remain as it was before in the Groups Server.
However, you cannot retrieve the device group information from the Standalone CiscoWorks Server to view them in the user interface. To retrieve and view the device group information, you should either:
–
Or
–
