The device menu contains all device objects and device group objects that are registered at the ZENworks Configuration Management server. It is subdivided into Servers and Workstations, which are defaults that cannot be changed. In this document, only the Servers are discussed.
After a successful configuration of the ZENworks Configuration Management server, the Devices/Servers branch contains an object for the server itself and several dynamic server groups, as illustrated in Figure 11-7. For administrative purposes, you should introduce a folder structure below the Servers branch to represent your server environment. This helps to ease the administration of large infrastructures.
Figure 11-6 Devices Menu
Every device is represented in ZENworks Configuration Management by an object. Every device object can only exist in one place (folder) in ZENworks Configuration Management. This place can be the first folder level (Devices/Servers) in ZENworks Configuration Management, but it can also be at any other level within the ZENworks Configuration Management device folder structure.
The location of the device object should have no functional meaning. When a certain type of software (bundle, policy, and so forth) is assigned to folders, the assignment is inherited by all objects located below that folder, including any subfolder. However, this kind of assignment should be avoided; instead, you should use device group assignments for administrative reasons.
The folder structure itself does not depend on technical requirements. Novell Consulting recommends that you develop a folder hierarchy that is based on functional and organizational aspects of administration. If you are managing different operating systems, you might want to create a folder for each of them inside the Servers folder.
It is also a good practice to implement naming standards for any type of object that is created in ZENworks Configuration Management. Novell Consulting recommends that you name folders in all uppercase.
Figure 11-7 Device Folder Structure
The folders shown in this figure have the following purposes:
SERVERS: Every device that will be registered at the ZENworks Configuration Management server is represented as a unique object within the ZENworks Configuration Management framework. These objects are placed in the Devices/Servers/SERVERS branch.
NOKEYS: The Devices/Servers/NOKEYS folder collects devices registered accidentally with a key created for group assignment only.
GROUPS: Most configuration item assignments take place between groups of devices and certain objects like bundles and policies. For this reason, we have decided to create a parent GROUPS folder that collects all device group objects.
This folder is divided into subfolders for the DEV, TEST, and PROD environments. Each of these folders holds two folders for configuration and update objects.
The folder structure for devices is illustrated in the following sections:
The suggested structure of this branch combines functional aspects with an existing eDirectory tree or location structure. A new device is placed below the DEV, TEST, or PROD folder, depending on whether it is a development, production, or test machine.
Figure 11-8 SERVERS Folder
The device object is also placed in a folder representing its physical location (and its eDirectory context) and finally in a folder indicating its main function, such as an eDirectory server (EDIR) or a member of a specific cluster (DUSCL01). This structure is illustrated in the following figures:
Figure 11-9 PROD Folder in the Servers Menu
Figure 11-10 Location Folder in the Servers Menu
This folder serves as a container for all devices registered incidentally with a key that is not intended for registration but for group assignment. It is configured as a target folder to all keys that are intended only for group assignment. In an ideal scenario, this folder remains empty.
For the Server folder, the first level below the Groups folder represents the environment for which the server groups are intended:
Figure 11-11 GROUPS Folder in the Device Menu
Each of these environment folders has a folder to store group objects for configuration or update assignments:
Figure 11-12 CONFIG and UPDATE Folder in the Device Menu
Server groups are objects that represent multiple server objects. They are placed at folder level 5. You can use this object type to more easily handle associations between tasks, software, and devices.
For instance, if a certain bundle must be delivered to many servers, the task can be achieved by assigning the bundle group containing this bundle to every server object individually. However, if the assignment needs to be deleted later, you would need to touch every server object.
A much better solution is to make the appropriate server objects members of a server group and to assign the desired bundle group to this group. This delivers the bundle to all members of the server group, and if a bundle association is removed from the bundle group, it is automatically removed from all members of the device group.
Novell Consulting distinguishes between two different roles for device groups:
Update Groups: Servers that are on the same product, version and support pack, such as all SLES 11 SP1 servers, are combined into one server group. The following bundles are assigned to these groups:
Pool/core bundles for dependency resolution
Bundle group providing the frozen patch level
Figure 11-13 Server Groups below the UPDATE Folder
For more information, see Section 11.4.2, Bundles and Bundle Groups.
Configuration Groups: Devices with identical configuration requirements are combined into configuration device groups. Application packages such as antivirus software or configuration files such as multipath.conf are assigned to these device groups through a corresponding bundle group. Device group objects for dedicated eDirectory servers and Xen hosts are examples.
Figure 11-14 Server Groups below the CONFIG Folder
A configuration device group can have multiple bundle groups assigned. For example, eDirectory servers can be running either physically or virtually on VMware or XEN hosts. These servers must be a member of a group that provides configurations relevant to eDirectory, such as PROD_EDIR. They must also be a member of a group that provides software or configurations that are necessary to install or configure aspects of the virtual machine, such as the configuration group PROD_VMWARE that assigns VMware-Tools to VMware virtual machines.
Server groups should be placed below the Devices/GROUPS folder within their associated environment folder (DEV, TEST, or PROD). Depending on whether they are of the Update Group or Configuration Group type, they are placed into the corresponding folders.
In general, Novell Consulting distinguishes between two types of server groups and therefore uses two different naming schemes:
%ENVIRONMENT%_%PRODUCT%VERSION%SERVICE PACK%
Name |
Description |
---|---|
ENVIRONMENT |
DEV | TEST | PROD This part of a group name identifies the environment that is relevant for an update group. |
PRODUCT |
SLES | OES This part of the naming standard identifies the product for which the update group provides patches and dependency bundles. |
VERSION |
2 | 10 | 11 | ... This part of a group name identifies the product version for which the update group is intended. |
SERVICE PACK |
GA | SP1 | SP2 | SP3 | ... The final part of a group name identifies the service pack level that is installed on the members of the device group. If no service pack is installed, Novell Consulting recommends that you use the term GA, which stands for General Availability. |
%ENVIRONMENT%_%CONFIG_GROUP%
Name |
Description |
---|---|
ENVIRONMENT |
DEV | TEST | PROD This part of a group name identifies the environment that is relevant for a configuration group. |
CONFIG_GROUP |
EDIR | CLUST01 | XEN | ... This part of the key name identifies the function of the members of the configuration group. |
The necessary steps to create a server group are shown in the following figures:
Figure 11-15 Creating a Server Group
The server group names in the following figure include environment, product, and service pack:
Figure 11-16 Server Group Creation - Basic Information
There are no members added at this time. They will be added automatically via AutoYaST or they can be added manually in a later step.
Figure 11-17 Server Group Creation - Group Members List
The following figure shows a summary of all selections made to this point:
Figure 11-18 Server Group Creation - Summary
A message about the successful creation of the new server group appears in the final dialog box:
Figure 11-19 Server Group Creation - Success Message
Device objects are automatically created during the initial registration or agent deployment. It is not possible to manually create any device object .
Device objects are automatically named after their host name during registration. Although devices can be renamed and some prefixes or suffixes can be added, Novell Consulting recommends that you accept the default naming scheme.
The device object location depends on how the device has been registered:
The device was registered without a ZENworks Configuration Management key. If a registration without a key has been executed, the device object appears at the first level in the /Devices/Servers folder.
The device was registered with a ZENworks Configuration Management key. In this case, the device object is placed into the folder that was defined when the key was created.
The device was registered by one of the methods described above and moved manually to the destination folder.
Registration rules provide the ability to register a device at a certain folder and with certain groups without specifying a key. Device location and group assignments can be determined by filters instead of by keys.
Figure 11-20 Registration Rules - Filters
However, the provided filters are not specific enough to achieve the same goals as the registration keys introduced by Novell Consulting (see Registration Keys). Therefore, Novell Consulting has decided not to use registration rules, pending further investigation.
Registration keys play an important role in organizing where Linux devices are placed within ZENworks Configuration Management.
The first and mandatory purpose of a key is to place a device object during its first registration into a certain device folder. If a key is not specified, the device object is created in the Devices/Servers folder.
Although device objects can be manually moved within the ZENworks Configuration Management folder structure, Novell Consulting recommends that you use registration keys to determine the final location during initial registration. This type of key is called a “location key.” This assignment method allows for easier administration and supports automatic registration via AutoYaST during installation.
The second and optional purpose of a registration key is to subscribe the device to one or more server groups. This must be configured during key creation or by later editing a key object to determine the device group or device groups the device is assigned to.
Novell Consulting recommends that you distinguish between keys intended to determine the target folder of a device object and keys intended to register the device object to device groups. This simplifies administering and maintaining objects.
To avoid any confusion, you must be able to clearly identify the purpose for a key. Using the Novell Consulting naming scheme helps you to accomplish this.
Common Rules: The first component (%ENVIRONMENT%) applies to all ZCM keys and identifies the environment in which the managed device is operated:
Name |
Description |
---|---|
DEV |
Development system |
TEST |
Test system |
PROD |
Production system |
ZCM Location Keys: Novell Consulting recommends that you restrict the ZENworks Configuration Management location keys to the initial registration of managed devices. The naming scheme for location keys is defined as follows:
%ENVIRONMENT%_%LOCATION%_%FUNCTION%
Name |
Description |
---|---|
LOCATION |
LOC1 | LOC2 | LOC3 |... This part of the naming standard identifies the physical location of a managed device. This can be a room, a building, a branch office, or even a city. Each of these locations is represented by its own subfolder under the device menu of ZENworks Configuration Management. |
FUNCTION |
EDIR | CLUSTER01 | ... This part of a name indicates the primary function of a managed device, such as an eDirectory server or a member of a certain NCS cluster. This part of the key name also defines the name of the subfolder in the devices menu where the objects for the devices will be placed. In well-designed OES environments, this folder name typically matches the name of the corresponding OU in the eDirectory structure where the NCP Server objects for these devices are located. |
Novell Consulting suggests that you use the same naming standards for update and configuration group registration keys as defined for server groups in Naming Standards for Server Groups. This results in an easy-to-understand relationship between registration keys and the server groups to which they add the server objects.
Novell Consulting recommends the folder structure as shown in the following table. Level 2 folders must be created underneath each Level 1 folder. The structure is tightly related to the different key purposes as discussed earlier.
ZCM Key Folder for Novell Consulting
Name |
Folder Level |
Description |
---|---|---|
DEV |
1 |
Keys that are used within development environments |
TEST |
1 |
Keys that are used within test environments |
PROD |
1 |
Keys that are used within production environments |
CONFIG |
2 |
Keys that have configuration purposes and are used only for group assignment |
UPDATE |
2 |
Keys that have update/patch purposes and are used only for group assignment |
LOCATION |
2 |
Keys that are used only for initial registration at the ZENworks Configuration Management server; they determine where the appropriate devices object is placed |
The folder structure for registration keys is illustrated in the following figures:
Figure 11-21 Registration Keys Menu – Level 1
Figure 11-22 Registration Keys Menu – Level 2
The DEV and TEST folders have the same structure as displayed for the PROD folder in Figure 11-22.
The following table lists some possible registration keys that are based on the naming schema outlined in Naming Standards for Registration Keys:
Name |
Role |
Key Folder |
---|---|---|
PROD_DUS_EDIR |
Location Key |
/Keys/PROD/LOCATION |
DEV_DUS_DUSCL01 |
Location Key |
/Keys/DEV/LOCATION |
PROD_SLES11SP1 |
Update Group Key |
/Keys/PROD/UPDATE |
TEST_OES11GA |
Update Group Key |
/Keys/TEST/UPDATE |
PROD_EDIR |
Configuration Group Key |
/Keys/PROD/CONFIG |
TEST_XEN |
Configuration Group Key |
/Keys/TEST/CONFIG |
Select Registration Key from the New menu.
Figure 11-23 Key Creation
Name the key based on the naming scheme described in Naming Standards for Device Objects. Select the appropriate folder to store the registration key and enter a description explaining the purpose of the key as illustrated below.
Don't press the Generate button during this step of key creation. Doing this overwrites the inserted key name with a self-generated key name.
Figure 11-24 Key Creation - Basic Information
For update keys or configuration keys a device folder makes no sense, because these ZENworks Configuration Management keys should never be used for the initial registration of a device. However, because this step is required, devices that are accidentally registered with an update or configuration key are placed in the /Devices/Servers/NOKEY folder.
If a device object is found in the NOKEY folder, administrators know that a wrong registration key was used during initial registration of the device.
Figure 11-25 Key Creation - Device Folder
The information in the next three fields is not required for update and configuration keys. The fields can be left empty:
Figure 11-26 Key Creation - Device Fields
The next dialog box requires you to choose one or more groups for the device to become a member of if this key is used:
Figure 11-27 Key Creation - Group Membership
Finally, all selections are summarized:
Figure 11-28 Key Creation - Summary
The newly created key can be validated, edited, or deleted in the Configuration > Registration > Registration Keys > PROD > CONFIG folder:
Figure 11-29 New Key - Ready to Use