Novell is now a part of Micro Focus

Exploring Search Policies

Novell Cool Solutions: Feature
By Edward Falzon

Digg This - Slashdot This

Posted: 25 Oct 2000

Edward Falzon is Managing Director at Performing PC's Pty Limited, creator of ZENith (, and a member of the ZENworks Cool Solutions Board of Review.


I've been presenting and training ZENworks for quite some time, in cities all over the world, and the most remarkable thing I've observed is that while everyone wants to know what they're going to get in ZENworks for Desktops 3, very few companies are making full use of their current version of ZENworks. In fact, most seem to be using only around 60%-70% of ZEN's features.

This article is the first in what will be a series of articles about the lesser-used, but very powerful, features of ZENworks.


When policies are used in any environment, the Workstation Manager (part of the Win32 client) checks for policies in the following order:

  1. First, the User object is examined to see if a User Policy Package has been associated directly to the user;
  2. All groups are then checked for Policy Package associations; and finally
  3. The Container that holds the User object is checked for a User Policy Package, then that Container's parent, then that container's parent and so on. The Container searching goes right up to the [root] of the tree.

Workstation policies are searched in the same way.

In almost every case, it's a terrible idea to allow Policy searching up to [root], for the following reasons:

  • Searching up to [root] takes time -- the more levels a tree has, the more time it's going to take for users to log in.
  • In WAN environments, it's almost guaranteed that the search process will have to span WAN links, which causes unnecessary traffic and takes even longer to log in.

The Search Policy is used to dictate how the tree is searched for Policies. It is not used to control searching for Application objects (see "Exploring Launcher Configuration", to be published soon).


The Search Policy is located in the Container Policy Package.

  1. Open NWAdmn32.
  2. Right-click the context in which to create the Policy; select create?; Highlight Policy Package and click [OK].
  3. From the list of Policy Packages, select Container Package; Click [Next >].
  4. Name the Package and specify the Context (which defaults to the highlighted context).
  5. Tick the box labeled "Search Policy" and click [Details?]. Configure the Search Policy as you like -- refer to Configuring, below.
  6. Associate the Package to one or more Container objects -- remember, it's a Container Policy Package, so you can't associate it to User or Workstation objects.
  7. Click [Create], and you're done.


Search Level

When it's time to check for policies at container-level, this tab dictates how far up the tree to search for policies.

By default, this value is set to [root], which is, in effect, the same as not having it at all. So we have a few options:

  • [root] -- Search all the way up the tree until there's nowhere else to search. As discussed, this is generally a bad idea, unless you have a very shallow tree, have no (or very fast) WAN links, or wish to be fired.
  • Partition -- Search up to the root of the partition, and no further. This is often a good choice, because it gives the flexibility to place policies at user and/or container level, and still ensures that WAN links aren't spanned (unless you have a partition that spans a link, which means you haven't read "NDS partitioning for Dummies").

  • Object Container -- This option limits the Container search to only the Container that's holding the user/workstation object. This is an excellent choice for companies that want to associate Policy Packages at Container level (which is generally a good idea), and at the same time minimize tree-walking.
  • Specified Container -- You can pick exactly which container is the limit of the search; enter the container in the text box that's directly under the Search option. If you have multiple sites in your environment, this option might not be a good idea, because you'd have to configure separate Search Policies for each site.

Under the Search option is a box marked Level. This specifies how far up or down the tree to set the search boundary, relative to the Search option. For example, if the Search option is set to Partition and the Level is set to "1", searching will go to the root of the partition, then one level more, possibly spanning a WAN link.

Note that you can use negative numbers here. For example, you can specify the Search option to be Selected Container of, say, au.PPCS, and the Level to "-1", which means users/workstations inside the context will search only to (one level lower than the Selected Container).

Search Order

The Search Order tab specifies which objects to check for Policy associations, and in which order. By default, the order is Object (user or workstation) first, then Group/s of which that object is a member, then Container/s, which, again, is the order used when no Search Policy is in effect.

In this tab, you can highlight any entry in the search order, and move it up or down, thus changing the search order. Or you can simply delete the objects that you don't want to search.

For example, you can have the Workstation Manager check the Containers first, followed by any user association, and skip Group searching altogether. Excluding Group object searching for users is generally a good idea, because:

  • If you have a lot of groups, it can take some time to check each one, thereby extending login time; and
  • More importantly, there's no way of specifying group priority. If a user is a member of 5 groups, each with a policy package assigned, the order of precedence is actually the order in which the user was added to the groups! This means that two users who are members of the same 5 groups might have different effective policies. This is bad.

However, if you're extremely careful, and you fully document everything you do, you could pull it off. If you use Workstation Group objects for each floor or department, but not much else, Workstation Groups are probably okay for associating Policies -- but if you overdo it, you'll get the same problems as with User Group objects.

Putting it all together

So all that needs to be done to instigate a Search Policy is to ensure that the Container Package is associated to the Organizations and Organizational Units where your users and/or workstations reside.

And there's no problem creating separate Search Policies (in different Container Packages, naturally -- there's no other way!) for your users and workstations, if you like.

Further Reading

TID:2942868 -- Search policy not used

TID:10022970 -- Novell Recommendations for Search Policies

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions.

© Copyright Micro Focus or one of its affiliates