8.4 Servers and Server Groups

We recommend to organize the folder structure to accommodate server objects and server group objects representing Linux servers in three folders:

Figure 8-1 Device Folder Structure

The folders shown in this figure have the following purposes:

The Folder SERVERS

One important aspect of the folder structure for servers objects are the staging areas. Most customers besides their production environment are using a test environment. Some customers even maintain additional development systems.

Very typically these environments use different sets of updates and the first level of the folder structure for the server objects is designed to accommodate this requirement.

In this example the server objects for all systems that are part of the build environment are placed in the folder _Infrastructure. Typically this will be your AutoYaST server, any repository server and possibly your ZENworks Primary Servers.

Figure 8-2 The SERVERS Folder

The other three folders are intended to accommodate the server objects representing systems from the development environment, from the test environment and from the production environment respectively.

Obviously you can adjust this level of the folder structure to meet your needs. Sometimes customers that do not (yet) have a test environment tend to skip this level of the folder structure. However, if they should later on discover that they need this level, re-organizing the folder structure of their ZCM zone can be a cumbersome and error prone process. Therefore we highly recommend to implement this level of the folder hierarchy even if it (initially) should only consist of a single folder representing the production environment.

There are many ways to organize the next level of the folder structure. In smaller environments it is not unusual that this folder is not sub-divided any further and all server objects are simply put into the folder representing a staging area.

Some customers put the server objects into folders that represent the physical location of the systems.

Most commonly server objects are put into folders based on the services provided by a system.

Figure 8-3 Server Folders for the Production Environment

In the above example servers are organized in three folders based on the function of the servers:

• Branch – The server objects for all Branch Office servers are collected in this folder. This approach is typically used by customers that have a main office and a number of mostly small remote offices where a single server provides all the services needed by the users in the location.

• Cluster 1 – Even so there is no strict technical requirement to do so many customers tend to place the server objects representing the nodes of a given NCS cluster into a separate folder.

• eDir – Another group of servers that often is put into a separate folder are all kinds of dedicated eDirectory servers. The first server typically found in this folder is the eDirectory Master / Certificate Authority host server of an eDirectory tree. Other servers placed in this folder are those that are configured to handle all user logins or to service LDAP request. iManager servers are also common in this folder.

Customers that only have a few but larger locations might create a folder for each location and then create the above folder structure for each location.

In very large environments that use different build environments for their staging areas it might even make sense to have a folder _Infrastructure for each staging area instead of the global folder depicted here.

The possibilities are endless and you need to decide which folder structure does make the most sense in your situation.

The Folder GROUPS

It is possible to assign bundles and bundle groups to folders so that the bundles become effective on every device who’s server object ends up in the folder that has the bundles or bundle groups assigned.

However, as discussed in The Folder SERVERS above there are many ways how customers may organize the server objects of their systems into folders. This variability is one of the reasons why we have decided to assign bundle groups to server groups and not to folders.

Figure 8-4 The GROUPS Folder

Just like the folder SERVERS the folder GROUPS is sub-divided in one folder for each staging area and a folder for your infrastructure servers. Again we highly recommend that this layer of the folder structure be implemented even if there only should be a production environment, at the time when the initial folder structure is created.

Figure 8-5 Server Group Folders for the Production Environment

Each of the folders for server groups is divided into two folders – CONFIG and UPDATE. These folders contain the server group objects that will be used to assign configuration bundles and update bundles to the devices.

Server groups are objects which represent multiple server objects. By using this object type associations of tasks and software to devices can be handled more easily.

For instance, if a specific bundle has to be deployed to many servers this could be achieved by assigning the bundle to every server object individually. If the assignment would need to be deleted at a later time this again would require to touch every server object individually.

It is much more efficient to make the appropriate server objects a member of a server group and to assign the desired bundle to this group. This will deliver the bundle to all members of the server group and in turn if a bundle association is removed from the group it is removed from all members of the group automatically.

For the assignment of multiple bundles we recommend to make the bundles a member of a bundle group and assign this bundle group to the server group (see Bundle Groups below).

We distinguish between the following two types of server groups:

The following table provides an example for a naming scheme for Configuration Server Groups:

The server groups in the CONFIG folder depicted below consist of server objects for systems from the production environment with the exact same configuration requirements.

Figure 8-6 Server Groups for the Assignment of Configuration Bundles

In this example we see server groups for Branch Office Servers, for the nodes of NCS cluster Cluster1, for dedicated eDirectory servers, for eDirectory servers that have iManager installed, and for eDirectory servers that have iManager installed and are configured as SLP Directory Agent. Bundle groups holding the configuration bundles required by these systems are assigned to the server groups in this folder.

As certain server types may not exist in all environments the corresponding CONFIG folders do not necessarily contain the same set of server groups. For instance a test environment may only require the server groups TST_Branch and TST_eDir-iMan-DA.

The following table defines the naming scheme used for update server groups.

The server groups in this UPDATE folder encompass server objects for systems from the production environment running the same release and support pack of SLES or OES.

Figure 8-7 Server Groups for the Assignment of Update Bundles

Bundle groups holding update bundles for these releases and support packs are assigned to the server groups in this folder.

The UPDATE folders for different environments only contain the server groups for the releases and support packs that are used in those environment.

The first step to integrate a device into a ZENworks Management Zone is its registration. By default the device object will be named with its hostname and the resulting server object will be placed in the folder > Devices > Server.

This process can be modified by use of registration keys. The first and mandatory purpose of a registration key is to create a device object during its first registration and to place it into a certain device folder.

Although server objects can be manually moved within the ZENworks Configuration Management folder structure, we recommend that you use registration keys to determine the final location during initial registration.

The second and optional purpose of a registration key is to add the server object to one or more server groups. To simplify administration we recommend that you use separate registration keys to determine the target folder of a device object and to add the server object to server groups. You only should add a server object to one server group with each registration key. This simplifies the administration.

When the ZENworks Adaptive Agent (ZAA) is installed as one of the last steps of the automated deployment the device is registered with the ZCM zone using the registration keys (see The Post-Installation Script zcm-install.sh):

These registration keys are created as described in Creating a Registration Key in the “ZENworks Discovery, Deployment, and Retirement Reference” and placed in three folders in the Registration Keys area of the ZCC.

Figure 8-8 Registration Key Folders

To avoid any confusion, you must be able to clearly identify the purpose for a registration key. Using the Micro Focus Consulting naming scheme will help you to accomplish this. The registration keys should be named and defined as follows:

Location Registration Keys: We recommend that you restrict the location keys to the initial registration of devices and do not use them to assign any server group memberships. Obviously, you will need one registration key for each folder where you want to place server objects.

Server Group Registration Keys: We suggest that you use the same naming standards for update and configuration group registration keys as defined for the corresponding server groups in Configuration Server Group and Update Server Group.

This will result in an easy-to-understand relationship between registration keys and the server groups to which they add the server objects.