Novell is now a part of Micro Focus

The Readers Have Spoken

Novell Cool Solutions: Feature

Digg This - Slashdot This

Posted: 22 Sep 1999

Thanks to all of you who voted, we now have a Reader's Choice winner in the ZENworks Tip Contest. As you may recall, this was a competition open only to Novell employees, and a panel of expert judges awarded 1st, 2nd, and 3rd prizes to them before they were released to the public. Then we ran the top five entries, unattributed, and posted a survey in which you in the Cool Solutions Community could vote for your favorite.

The votes came pouring in (thank you all very much), and we watched with great interest to see how you would vote compared with the judges on our panel. The excellent Entry B: Group Association of Policy Packages, was the grand prize winner. (It had been selected as the 2nd-prize winner by the judges. Like we always say, no one knows what you need like you do.) This highly practical, well-focused, jauntily written tip was authored by Patrice Clement, an Escalation Engineer in the Novell European Support Center.

Here you'll find the tips again, this time with their author's name and the prizes our judges awarded them. Interestingly, the top three prizes all went to people on the European Support Teams. Next time you call in to EMEA support, you should offer your congratulations to them. They've obviously assembled teams that really understand what customer concerns are, and these tips are a great example of the kind of practical info they dispense. In multiple languages, no less...

All five of the entries were well received and appreciated by Community members, inspiring comments like the following:

  • All five tips were excellent - good examples of the tips I like best. Although I learned something new from items A and C, I chose B because it addresses a problem experienced by many ZEN users (especially those who have only used NW3 and NT servers, who still use groups for everything). The problem is difficult to recreate and to troubleshoot - so I considered this tip best even though I already had read the info in an obscure Novell doc. That is my criteria for a good tip: tough problem, often encountered, not widely documented. All the entries were good examples, but I rate entry B highest.

  • Entry B took myself about 3 weeks to figure out by myself when I was implementing ZEN for a large customer. The customer needed to use groups for policies. The only solution available is to create "policy groups" only used to deliver different policies and make sure the user is member of only ONE group.

  • Just keep it all guys are the best...Novell rocks !!!

  • All the tips were most useful!!

  • I'd like more on NDS Design and ZENWorks. All of these tips were very good and gave me some things to consider though. Thanks.

  • Great job. It's things like that which make our lives easier. Thanks Novell.

  • Microsoft Printing has been the bane of my life. Until Now. Thank you.

  • I need more tips similar to Entry A which gives insight on tuning ZEN for performance. Since all the applications are being distributed using NAL it seems to take forever to login.

  • They are all very useful, would love to see more!

  • These are so good, I wonder about the ones that didn't make the cut. Am I missing any good ones? (Editor's Note: Other entries were rejected because they were either duplicates of winning content received earlier, did not meet the contest rules and guidelines, or failed in testing.)

In addition to these nice comments, the voters also supplied some excellent feedback in the survey, and we've harvested a whole list of topics you'd like to see more info about. We'll be supplying the requested info over the next few months, and if we run out of topics (hah), we'll be sure to ask for more.

BTW: In case you're wondering, we're going to mark all of these winners up into proper tips, and place them lovingly in the Tip Vault, so you can find them again in the future.

Top five entries

Top five entries

Entry A: Getting Excessive Tree Walking with ZENworks and don't know why?

by Peter Lambrechtsen

This entry was awarded 1st Prize by the judges. In fact, the Reader's Choice voting between this one and Entry B was very close, and several readers said they couldn't decide between Entries A and B. Peter is a Technical Support Engineer in EMEA - NTS, Netherlands.

There are two aspects of ZENworks that can do excessive tree walking if you are not careful.

Desktop Management:

If you do not create a "Search Policy" in a "Container Policy Package" in the container which holds the users, when the user logs in (by default without a search policy) Desktop Management will search all the way to the root of the tree. The solution is to create a Search Policy Package at the top of your NDS Partition for the current container, so that ZENworks will not search any higher in the tree.

Novell Application Launcher:

There are two parts of NAL that can conceivably do tree walking.

1) The Configuration Tree

By default NAL will also search all the way to the root (well, actually the Organization Object) of the tree for its configuration. If you do not set any configuration settings, each (and every) copy of NAL that is started up on a workstation will search up to the Org Object and then search each OU until it hits the User Objects configuration.

To change this, go into the details of the root of the partition, under the "Launcher Configuration" tab, and select Use as top of configuration tree. This will cause NAL to only search for its configuration to this point, and no higher.

2) Application Inheritance Level

Sometimes you would like NAL objects associated in the parent container to be in the user's available NAL applications. By default NAL will only search the current user, the groups the user is a member of, and the current container.

If you set the "Application Inheritance Level" to 2, then NAL will search the user's context, and it will also search the user's parent context. If you set the AIL to 0 it will not search any contexts at all (and only search the specific user object and groups that the user is a member of) and if you set it to -1, then NAL will search from the root of the tree.

Return to list of entries

Entry B: Group Association of Policy Packages

by Patrice Clement

This entry won the Reader's Choice Award, the grand prize of this competition. This entry was also awarded 2nd-prize by the judges in a very close race with Entry A. Patrice is an Escalation Engineer in the Novell European Support Center.

Applies to any version of ZENworks (including ZENworks 2).

In ZENworks, a policy package can be associated directly to the object itself (user or workstation object), to a container object, and to a group object (user group or workstation group).

A previous Cool Solutions article described how ZENworks was determining which policy is effectively used when several policies coming from different packages are associated directly or indirectly to an object. However, this article didn't cover an odd behavior of ZENworks related to group associations: which policy will be effectively used by ZENworks when a user (or a workstation) is member of several groups and those groups are associated to different policy packages?

To better understand what's happening in such a case, let's take an example. Let's say that user Joe is a member of two different groups: UserGroup and AdminGroup. In addition to that, we have two different User Policy Packages: Restricted_Package and Unrestricted_Package. The Restricted_Package implements a Dynamic Local User Policy where the user is only a member of the NT User Group. The Unrestricted_Package implements a Dynamic Local User Policy where the user is not only a member of the NT User Group but also a member of the NT Administrator Group. The Restricted_Package has been associated to the UserGroup and the Unrestricted_Package has been associated to the AdminGroup. Since user Joe is a member of both groups, both Dynamic Local User policies are indirectly associated to him. However, the Dynamic Local User policy is a singular policy, meaning that only one such policy can be effectively applied to the user. Now, the question is: which policy will be effectively applied to user Joe?

Well, sadly enough, the answer is: it depends! Indeed, we first have to remember that the main rule regarding effective policies is: the first (singular) policy found is the one that will be effectively applied. In our case, to find out which Dynamic Local User Policy will be effectively applied we have to remember that the group membership list of a user will be read in an "historical" manner. Meaning that the first group read will be the first group the user was made a member of, the second group read will be the second group the user was made a member of, and so on. So if the user Joe was first made a member of the UserGroup, we will get the DLU policy from the Restricted_Package. On the other hand, if he was first made a member of the AdminGroup, we will get the DLU policy from the Unrestricted_Package!

So, the important factor here is the order in which the user was made member of the different groups. This has very bad consequences for the administrator:

  • The group order is user related. Two users who are members of the same two groups might end up with different effective policies if they were made members of those groups in a different order.
  • The group order cannot be easily seen. Going into the group membership section of the user object with NWAdmin doesn't help because the groups are listed alphabetically, not historically.
  • Removing a user from a group and putting him back will change the group order and, therefore, can change his effective policies! Even though he is still a member of exactly the same groups.

Practically, all this means that effective policies can very quickly become unmanageable when associating Policy Packages to groups. Here are a few tips to help you alleviate this problem (sorted from the most effective tip to the least effective tip):

  1. Activate a Search Policy through the Container Package and remove the group objects from the Search Order section. This way, you are sure that policies associated to groups will not be taken into account.

  2. Don't associate Policy Packages to groups. Associate them to the containers or to the objects themselves.

  3. If you have to associate Policy Packages to groups, make sure that the different Policy Packages have different policies activated. For example, one package would have the DLU policy and another package would have the Printer policy. This way, it doesn't matter in which order those policies are applied.

  4. Do not make a user a member of groups associated to conflicting Policy Packages (like the UserGroup and AdminGroup in our example).

  5. In the worst case scenario (Policy Packages with conflicting policies), use DSView or DS Snoop (can be downloaded from the Novell Consulting Web Site) to find out in which order the user was made a member of the various groups

Return to list of entries

Entry C: Printer Configuration Window in NT 4.0

by Paul Thompson

This entry was awarded 3rd-prize by the judges. Paul is a support engineer in the Novell EMEA Premium Services Department in Bracknell, UK.

In NT 4.0 it is difficult to use the Printer configuration Window under two circumstances:

  1. When the NAL is used as a shell there is no access to the Printers settings tab.
  2. When you use the ZEN features or a policy to hide the settings folder in the Start menu.

The solution NCCPP32.EXE from Novell Consulting does work fine under normal circumstances but not in these two circumstances. The solution is that you create a Folder at the Desktop or wherever you like and name that folder:


C:/WINNT/Profiles/Administrator/ StartMenu/Printers.{2227A280-3AEA-1069-A2DE-08002B30309D}

A customer in Germany is using the NAL as a shell, so we created following application:


The call to the APPLICATION is:

The Parameter is:

With this application the Printers directory is created and called even if users delete this directory. (L: is the Homedirectory Drive mapping.) If you want to call the Printers menu in a two-panel view, add the command line parameter [/e,] to the explorer.exe call.

You can deliver even more with NAL:

  • Control Panel.{21EC2020-3AEA-1069-A2DD-08002B30309D}
  • Network Neighborhood.{208D2C60-3AEA-1069-A2D7-08002B30309D}
  • Dial-Up Networking.{a4d92740-67cd-11cf-96f2-00aa00a11dd9}
  • My Computer.{20D04FE0-3AEA-1069-A2D8-08002B30309D}
Return to list of entries

Entry D: Workstation Registration in ZENworks 2.0

by Santhi S

Santhi is a senior software engineer in Novell's India Development Center in Bangalore.

How to find out if you've registered a workstation properly

After you've run the registration program, your workstation entry, even if imported, might not show up in the Workstation Registration page of the container. This might be due to wrong registration. That is, the Workstation might be registered to some other tree and server.

Right-clicking the ?Novell Desktop Management' icon on the system tray provides NDS information. This information can be verified for the correctness of the tree and the workstation object DN. From this, it can be concluded whether the workstation is properly registered or not.

How to run the Workstation Registration program

  1. Right-click the ?Novell Desktop Management' icon and select Display schedule.
  2. Run Registration agent.

Through Application Explorer (NAL), the application object for workstation registration is created and imported at the time of ZEN installation. It can be run for registration.

It can be run manually by executing wsreg32.exe/wsreg16.exe for 32 /16 bit workstations respectively.

Things to consider

  • Always select the context/container for which workstation registration rights have been set up and then import the workstations that are registered under that container.
  • If policy settings are changed/deleted accidentally during the remote management session, it will be effective only for the next session. Let us assume that the console is remotely controlling a workstation. During the session, if the console user accidentally disables the remote control option for that particular workstation, then the current session with that workstation will not be affected. But if the console user wants to initiate a new remote control session with that workstation, it may not be possible.
  • If protocol setting is changed (say, from IP to IPX) during the remote management session, Remote Management agent has to be restarted. Otherwise, changes will not be reflected on the subsequent session.
  • During the remote management session, if the Display agent icon to users option in Workstation Remote control Policy settings is changed (i.e. enabled or disabled), then it will be effective only if the remote management agent is restarted. It will not be effective for the current session. That is, if the display option is enabled previously and during the session it is disabled, the agent icon will be visible on the system tray, until the agent is restarted.
  • Two consoles cannot initiate a remote control session for the same workstation at a time.
  • A single console can initiate more than one remote management session (Ping, file transfer, etc.) with more than one workstation at a time.
  • During Registration and importing, the server and tree where ZEN is loaded should be set as primary. Otherwise, that workstation will be registered to whichever tree and server is set as primary at that point in time.
  • In the remote control policy for workstation and user, the time interval for visible or audible signal can be set. If in the workstation policy, the value set is x seconds and in the user policy, the value set is y seconds, then the minimum of the two(z) will be effective. The user at the managed workstation will hear the audible signal every z seconds and will see the visible signal (name of the user controlling) every z seconds.
  • Even if the Permission required option is disabled in workstation policy settings, the user's permission is still required when a remote management session is restarted. This is because the Permission required option might be enabled in user policy settings. If this option is enabled in any one of these (Workstation policy settings or user policy settings), it will be effective, and will prompt users for permission.
  • All the remote management operations can be performed only if the remote management agent is running on that particular workstation.
  • If a user who has logged into the workstation wants to unregister from the tree, then he can run ?unreg32.exe / unreg16.exe' under sys:\public directory. The workstation has to be rebooted after running this exe.
  • When a workstation is being remotely controlled by one console, remote control operation of the same workstation by another console is not possible.
  • When a console remotely controls a workstation, any other console including the one that is controlling it cannot remotely view it.
  • When a console remotely controls a workstation, if a user who doesn't have remote control rights logs into that workstation, that remote control session will not be affected. But when remote control is invoked again for that workstation, it will not be possible to initiate the session. To initiate the session again, the user with remote control rights should login to that workstation.
Return to list of entries

Entry E: Settings in NT 4.0

by Paul Thompson

This is another entry from Paul Thompson, the 3rd-prize winner. He is still a support engineer in the Novell EMEA Premium Services Department in Bracknell, UK.

To call special settings applications like DISPLAY or System in NAL:
The call for settings is CONTROL.exe.

NT provides for every setting a .CPL file which can be added as startparameter so if you create a application with the control.exe and the CPL file as startparameter you can call a specific setting.


This calls the DISPLAY.

You can be even more specific and can call it with a specific TAB.


Which will call the SYSTEM with the tab ENVIRONMENT.

Return to list of entries

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

© Copyright Micro Focus or one of its affiliates