Novell is now a part of Micro Focus

Using Search Policies Effectively in ZENworks

Novell Cool Solutions: Feature
By Shaun Pond

Digg This - Slashdot This

Posted: 18 Apr 2005

Search Policies are an extremely powerful part of ZENworks. Used correctly, Search Policies can help to minimize the time required to start up your PC and log in; used incorrectly, they can waste a lot of time and network bandwidth, annoying users and leading to potentially serious issues in the event of a WAN failure.

This article provides information not available in the online documentation, to help you use Search Policies more efficiently and avoid the main pitfalls. To illustrate the suggestions in this article, we have created the the fictitious ACME Corporation, which has a global tree spanning several continents, as shown below:

The examples in this article will refer to this tree.

how do search policies work?

Objects that can have policies applied to them need to search the tree, looking for policy package associations. (In the case of ZENworks Desktop Management, these objects include Users, Workstations, and Servers.) If the search isn't limited, it could go to the root of the tree unnecessarily, potentially wasting time and possibly crossing WAN links.

A Search Policy is part of a Container Policy Package. It is used to control how far up the tree object searches for Policy association should go. As soon as the object finds a container with a Search Policy associated with it, the object stops looking for more Search Policies. Note the word "association"; the association, not the policy itself, is what the object is searching for. Understanding and remembering this distinction is the key to avoiding the main pitfalls commonly associated with searches.

Where you place policies in the tree is almost irrelevant; where they are associated is what counts. (You must, however, take into account tree-walking for when the policy itself is read!)

Searches always go up the tree -- you cannot search down the tree or search siblings. (The single exception to this simple rule is where you use Groups -- their position in the tree is not relevant to the searching process.)

To determine where in the tree you need to associate policies, you need to understand your organization's needs. This topic is explored in How Complex Are Your Organization's Requirements?

setting up a search policy

This section discusses the options that are available in searching for policy associations; having different options allows you to tailor searching for Policy associations to your organization (see Good Design). The ultimate purpose of the settings in the Search Level tab (shown below) is to resolve to a single container -- this marks the limit of how far up the tree the User, Workstation, or Server object will search.

Search Level Tab

"Search for policy associations up to:"

Under "Search for policy associations up to," you can specify [Root], Object Container, Associated Container, Selected Container, or Partition. Each of these options is discussed below. You can specify a container, either explicitly or implicitly. The implications of changing the search level are discussed in the Search Level.


The [Root] option is the default search option, but it is not the most widely used search option; however, it does allow for settings in the other tabs (Search Level and Refresh Interval) to be used. For example, if myuser.users.Provo.West.Americas.ACME found this Search Policy setting, it would search up to [Root] for policy associations.

Object Container

The Object container option tells the object to search its container. For example, if myuser.users.Provo.West.Americas.ACME found this Search Policy setting, the search process would search up to users.Provo.West.Americas.ACME for policy associations because the object is in this Container.

Associated Container

The Associated container option tells the object to search the container with which the Container Policy Package is associated. For example, if myuser.users.Provo.West.Americas.ACME found this Search Policy setting in a Container Policy Package associated with Provo.West.Americas.ACME, it would search up to Provo.West.Americas.ACME for policy associations because this is the Container to which the Policy Package has been associated.

Selected Container

The Selected Container option tells the object to search the named container (you cannot type the name in; you must browse for it). For example, if myuser.users.Provo.West.Americas.ACME found this Search Policy setting, which specifies users.Provo.West.Americas.ACME, it would search up to users.Provo.West.Americas.ACME for policy associations, because that's the name of the Container in the Policy Package.


The Partition option tells the object to search as far up as the container that's at the top of the current eDirectory partition. This option is only available in ZENworks for Desktops 3.x (zfD3.X) because that version of ZENworks requires the Novell Client to do the tree walking. (In ZENworks for Desktops 4.x (ZfD4.x) and above, you can configure your workstations to work without the client, so the policy would be meaningless.)

search level

After a container has been identified from the "Search Up To" section, you can use the Search Level setting to amend it. A positive value tells the object to search further up the tree; a negative value reduces how far up the tree the object's search should go. For example, assume that Search Up To is set to "Associated Container," and this policy is associated to Provo.West.Americas.ACME. With Search Level set to 0 (the default), myuser.users. Provo.West.Americas.ACME would search up to Provo.West.Americas.ACME for policy associations.

With Search Level set to 1, myuser.users.Provo.West.Americas.ACME would search up to West.Americas.ACME for policy associations.

With Search Level set to -1, myuser.users.Provo.West.Americas.ACME would search to users.Provo.West.Americas.ACME. (It would search up as far as one level lower than the container identified in Search Up To.)

So-- what would happen if, in the above scenario, the Search Level was set to -2? Would the object search one level below users.Provo.West.Americas.ACME? Would it search as far as users.Provo.West.Americas.ACME? Would it search anywhere else? The answer is none of the above: if you think about what's being said here -- in effect, "search UP as far as two levels below Provo.West.Americas.ACME" -- the object is already higher in the tree than that point, so it doesn't search UP at all!

Search Order

Search Order determines the precedence given to Policy associations; the default says, in effect, "Policies found by association to a container can be overridden by Policies found by association to Groups, and both of these can be overridden by Policies associated to the object itself." This default allows for sensible management of Policies; for example, you can associate Policies higher in the tree and then make exceptions to the Policies associated to the object itself.


Associating policies with Groups needs to be approached carefully. When ZENworks searches for Policy Packages associated to Groups, it searches all the Groups to which the object belongs. If the object is a member of several Groups, the search can be time-consuming. Groups should not be used for Policy searches for users. See Good Design for tips regarding the use of Groups.

Other Changes - Beware

Ensure that you understand what you are doing if you change the order of the items in the list on the Search Order tab, or remove any option other than Groups. If you make the order Container -> Object, for example, this implies that any Policy Package associated to an object may be overridden by a Policy Package associated to the container the object is in, which would be contrary to the normal top-down inheritance and could be extremely confusing.

Refresh Interval

The Refresh Interval controls how often eDirectory is checked for policies. By default, the whole process of looking for a Search Policy and then searching for the effective policies, takes place once per hour; setting this policy will override that default. If you do a refresh from the Workstation Scheduler, then the timer will be reset and eDirectory will begin checking at one-hour intervals from the reset time. If you disable this option, then policies will only be read on system startup.

good design

How Complex Are Your Organization's Requirements?

When you begin planning the placement of Policy packages, you must first determine if your organization wants the same rules to apply to all user, workstation, and server objects. You can use the Tree hierarchy to help plan placement and associations of Policy Packages. Bear in mind that some Policies (such as Scheduled Action) are cumulative; more than one Policy may apply. Concentrate on finding the general rule and determining what the exceptions are.

Don't create more Policy Packages than you need to--the more Policy Packages that you have, the more you have to keep up to date. Look for common settings that you can apply across Policy Packages, and see if it would make more sense to place these in a common Policy Package, but always be aware of the implications for tree-walking, and never cross the WAN to read a Policy. Remember that many packages have a General tab which can be overridden by settings on the tab for the specific operating system.

Balancing Efficiency with Ease of Administration

  • As always, the most important factor with Policy placement is to avoid crossing the WAN, if at all possible.
  • Associate a Policy Package close to the object that's going to use it.
  • Ensure a local replica contains the policy itself.

Depending on the needs and size of your organization, you might want to place Policies in a dedicated container, make the container a separate partition, and then replicate it to each of your sites. If your organization is large, you could consider a hybrid approach, perhaps having a regional policy container that you replicate to the sites in a region. You can use the policy copy option in ConsoleOne (Tools | ZENworks Utilities | Copy Policy Packages) or the COPYPOL.EXE tool (in the ConsoleOne bin directory) to copy Policy Packages to the regional containers.

Consider Removing Groups

You need to carefully plan the use of Groups for policy association. Consider what will happen if, for example, a user is a member of two Groups which have different User Policy Packages associated to them and the User Policy Packages have two different settings for the Dynamic Local User Policy. Which DLU Policy will apply to this user?

Because there is no reliable way to know, Novell recommends that you not use Groups for policy association unless you're in an exceptionally well-controlled environment, where you can guarantee that a user will not find multiple overlapping policies because of the Groups to which the user is assigned.

The same warning applies to workstations, but because most organizations have relatively few Workstation Groups, a problem is less likely to occur.

If you do decide to use Groups for Workstations, you'll need to consider association of Container Packages carefully -- you will need to ensure that users and workstations find different Container Packages.

common pitfalls

Specified Container -- Rename

When you use "Specified Container" in the Search Up To selection, what's stored in the Policy is the string that you see on the screen. If the container is renamed, for example, then the specified container will not be found. This will result in the search continuing to the root each time, because the Search Policy is unable to limit the search. To avoid this problem, you should only consider using Specified Container in a tree in which container naming is strictly controlled.

Specified Container -- Sibling

The most common mistake in creating Search Policies is to do something like the following: In the sample tree, the Policy Packages have been created in Area Policies.West.Americas.ACME. The container has been made into a partition, replicated to all of the sites in that area (Portland, Provo, Salem, SF), and then associated to Provo.West.Americas.ACME (and the other "site" containers at that level).

To control searching, a Container Policy Package has been created; the package includes a Search Policy with 'specified Container.' Area Policies.West.Americas.ACME is specified to ensure that the policies are found in that container. The package is associated to Provo.West.Americas.ACME (and to the other 'site' containers at that level in the West).

What's Wrong with This Picture?

Everyone is happy that the correct policies are being applied, but users complain that login takes too long.

If you've been following this article so far, you should be able to work out why this is happening: The current Search Policy says to "search up as far as Area Policies.West.Americas.ACME." Well, if a user object searches up the tree, it will never find that container because it is not in a direct line between the user object and [root]. As a result, the user object searches to [root] looking for Policy Package Associations, possibly searching across WAN links and taking a long time. If you changed the Search Policy to "Associated Container," however, policy associations would then be found as far up as Provo.West.Americas.ACME.

Changes from ZENworks for Desktops 3.x

If you have a Search Policy set to "Partition Root" and you upgrade to ZENworks for Desktops 4.x or ZENworks 6.5 Desktop Management, this Search Policy will be treated as if it is set to "Associated Container."


Good documentation is a must -- you need to know what policies are applied at each point in your tree, so that you can be sure of the effect of associating a new Policy Package. If you know what the expected result is, you'll be in a much better position to determine if the actual result is correct.

Turn On Logging


This article has explained how Search Policies work, and has discussed what to do with them and what not to do with them.

For further reading, see the online documentation at

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

© Copyright Micro Focus or one of its affiliates