Data Structures

The Configuration Manager deals with three different hierarchical structures, also known as trees. To understand the Configuration Manager user interface, it is important to distinguish between the three trees:

The first two trees are the organization and domain trees. The organization tree represents relationships between organizational units, such as sub-organizations and users (the first level of the tree being the organization itself, subsequent levels, for instance the departments and sub-departments, and the last level the members of these departments). The domain tree represents relationships between elements of the network such as domains or hosts (the first level of the tree being the overall network, subsequent levels, for instance the various subnets, and the last level the actual machines in these subnets).

In the Configuration Manager, these trees are obtained by interpreting the contents of an LDAP server, which is the typical repository for corporate organizational structure. Each location within the organization tree in LDAP is called an entity. Entries in the LDAP server are mapped to the organizational entities recognized by the Configuration Manager, namely "Organization", "Role", "User", "Domain" and "Host". For further information about this process, please refer to the Java Desktop System Configuration Manager Release 1.1 Installation Guide.

The third tree is the configuration policies tree, which is used to organize the configuration settings in order to browse and edit them conveniently. The first level of that hierarchy is generally the application, with subsequent levels corresponding to the various components or modules (and sub-components and sub-modules) of that application and the last level being actual configuration settings. A similar presentation can be seen in many configuration systems dealing with many settings, such as the settings from StarOffice^TM or Mozilla^TM, where, for instance, the HomeUrl setting would be found under Mozilla/Navigator/HomeUrl in the Preferences dialog.

Configuration policies can be assigned to any element in the organization or domain structure, resulting in two "trees of trees", one being an organization tree containing policies trees and the other a domain tree containing policies trees. A graphical representation of that structure can be seen in Figure 1–1.

The general structure of the Configuration Manager interface allows the administrator to select an element of the organization or domain tree and then assign policy groups to it or edit its policies.

The concepts for working with the organization tree and the domain tree are the same. The main difference between the two is that the organization tree consists of users and the domain tree consists of hosts. Having users and hosts in two separate trees enables the Configuration Manager to provide user-based and host-based configuration. Due to the similarities between the two trees, most sections in this document focus on the organization tree and only mentions the domain tree when differences exist between the organization tree and the domain tree.

Figure 1–1 Trees

Generating Configuration Settings

Figure 1–2 Merging

The configuration settings for a given entity are obtained by merging all the configuration policies that are applicable to that entity. This includes the configuration policies of the entity itself and those of its parent entities. For instance, the settings for a user take into account the policies assigned to that user and those assigned to the organizations that the user belongs to. The merging works by inheritance, that is, the user inherits the settings specified in the upper levels of the organization structure, and those settings can be modified at the user level by the policies assigned to the user. This process is illustrated in Figure 1–2, which shows how the settings of the "Marketing" organization are inherited by one of its members, user "jclarke" and how the policies of user "jclarke" override some of these inherited settings.

Figure 1–3 Protection

The overwriting of inherited settings by lower levels of the hierarchy can be prevented by protecting some of the elements of a policy. This allows the administrator to define mandatory settings which cannot be modified in subsequent policies or in the managed application running on the desktop. This process is illustrated in Figure 1–3, where a setting associated to the "Marketing" organization is protected, therefore forcing the merging to disregard the value specified in the policies of user "jclarke" and exposing a read-only value for use in the desktop application.

The settings obtained from the policies are integrated with the client application local configuration according to the following rule:

• Non-protected policy settings are used as defaults if no local user setting exists.

• Protected policy settings are enforced if no local mandatory setting exist.