Novell is now a part of Micro Focus

Best Practices: Organizing and Managing your ZENworks Objects

Novell Cool Solutions: Tip

Digg This - Slashdot This

Updated: 3 Nov 2005

David P. wrote: We just installed ZENworks for Desktops 6.5 and I have some ideas on how organize the objects associated with ZENworks, (application, workstation objects, and policies packages.) I just changed jobs and my new boss is hesitant to implement my ideas without getting a third person's opinion.

I have administrated on ZENworks ever since version 2 came out, and have found the basics between versions 3.2, 4 and 6.5 to be the same. Typically I create multiple contexts for these objects. For example, under the school container we have an office context for office users, groups and other objects; a campus context for students and teachers; and a library context. Under the same container I plan to create three new contexts; applications context for the ZENworks app objects, printers context for NDS and NDPS print queues, and workstations context for the imported computer objects.

I would appreciate any opinions, advice, gotchas, validation, etc., on this plan.

OPEN CALL: Let's all pitch in and help David, and in the process we'll create a Best Practices guide to organizing and managing all your zillions of ZENworks objects. Fire when ready...


Pete Danner

David, overall, I would agree with you for wanting multiple contexts to help ease management of ZEN. Having been in a school environment before myself, there are a few recommendations that I would add to your proposed setup.

I found that having the following containers under each OU helped me: APPS, POLICIES, PRINTERS, WORKSTATIONS. I would also suggest having Teachers in their own OU and not have them with your students. (Your environment may be different than the one I came from, though.) It helped me due to the different access levels of various programs and the fact that I didn't lock down Teacher desktops as much as the student desktops. Hope this helps in your quest.

Chris Gotstein

I would agree with what David P. posted. I try to organize my objects by building, then by department. In our school settings, this means each school building has its own container. In that container is a Staff OU, a Student OU, ZEN OU, and a Workstation OU.

Inside the ZEN OU, I use ZEN folders to further organize the app objects for our users and our support team. In the future we will be installing high speed fiber between our buildings, which should reduce the number of duplicated ZEN apps. In that case I will create a container above the building level for ZEN objects that are the same for all buildings and users.

Heath Tennant

I would tend to agree with your administration and OU placement. The only thing I would recommend is to ensure that placement of OUs is relevant to physical location so that you're not importing workstations or running applications over a WAN link, etc.

Cade Carvell

We create a group object for every ZENworks application object. Then we associate group to app. This allows us to let the helpdesk administer the ZENworks applications in iManager, and bypasses some issues with file rights and the ZENworks app object. It also has the added benefit of allowing us to create several groups that point to a singular app object, and set show on desktop, force run, etc., differently for each group - a user could be member of multiple groups.

Scott McKenna

Here's our organization:

We have 13 separate WAN sites with their own NetWare 6 servers - so I have to replicate most of the structure to each site.


For each version of ZENworks - we are in the process of moving from 4 - 6.5 I create a new OU for the Application objects - then a separate OU for each type - ie:


  • MSI
  • SIMPLE - registry hacks, file additions, deletions etc.
  • SNAP - snapshots
  • WEB - URL delivery
  • TERMINAL - terminal services objects (CITRIX)

I match this structure in the Program volume at each location for the distribution of the AOT, AXT, MSI or files.

I try to build the APPS using either mapped drives (which will work at any site, since drives map to the local server by the same letter -- if necessary I grab the %FILE_SERVER variable from the Login script) OR use a prompted string macro for the staff to put in the correct server.

If it is just a simple registry hack or icon delivery I deliver it from a server in the center of or WAN star configuration.

Built this way I can duplicate Apps easily to other WAN sites.

I deliver the Apps by adding users to group 'OFFICE 2003 STD MSTb" group or using the Everyone.<SITE>.<ORG> group for each site - or for the whole organization Everyone.<ORG>. All templates make users members of these Everyone groups.


At each WAN server OU, I have a WORKSTATION.<SITE>.<ORG> container where all the workstations are imported for that site. The computer naming convention I use is:

  • 1 character = agency
  • 2,3 characters = local server
  • 4,5,6,7,8, characters = our inventory tag number
  • 9,10,1,12,13,14,15 characters = last 6 characters of objects serial number

This allows me to easily browse the list to find a workstation if I need to remote in, etc. This is also useful for us in looking at DHCP tables (hostname) and Symantec Antivirus site listings.


Set up much like workstations with a PRINTERS OU. at each site - naming convention is:

  • Local location_makemodel_Inventorytag number ie: HSU1A_CAN6020i_LW4456

This allows me to differentiate printers in the OU.

I give users rights to the local site containers .<SITE.<ORG>
Managers (Tech staff) are in a group which gets Manager rights to all the printers.
Operators (LAN staff) are all in a group which gets Operator rights to all printers.
If I have admin staff which visit many sites they are put in the Manager's group and get universal USER rights.

David Field

We do a similar thing to the method you've described.

We have an OU that represents the office location which is the main OU for a site. Below that we split into OUs for some object types.

We split ZENworks into the following:


These store the relevant objects relating to ZENworks.

We then group our application objects by name to describe what it does, i.e.:

DA-XP-01 - Microsoft Office
Would be:
Run order 01

DR-2K-05 - User Registry Changes
Would be:
Run Always
Windows 2000
Run order 05

Would be:
Shortcut Only
Run order 01

This helps us quickly see what apps are doing from ConsoleOne and ensures we can see what order items are run in.

Crude, but it works for us.

Eric Ho

We have multiple contexts too. The way we organized our ZENworks for Desktops objects is to give us centralized control.

We are running ZENworks for Desktops 4.X. We have contexts for different departments. In addition, we have created a context "ZENWORKS" for all workstation objects, workstation policies and user policies. A workstation group "Default Workstation Grp" and a workstation policy "Default Workstation policy" are also created to manage workstations. We define the "Workstation Inventory Policy" within the "Default Workstation Policy" to scan inventory. We associate the "Default Workstation Grp" with the "Default Workstation Policy". In this case, all workstations will be scanned at the specified time that we defined in the "Workstation Inventory Policy".

The Server Package is located at our Root container, and the Import Policy is defined to target the "ZENWORKS" context. All workstations will be imported to the "ZENWORKS" context and will be members of "Default Workstation Grp", a group which is associated with the "Default Workstation Policy".

Multiple User Policies are also created in the "ZENWORKS" context. All policies are defined as "Dynamic Locate User". Other user group policies are defined accordingly.

We leave all Application Objects in our root context. We separate them from the "ZENWORKS" context.

The idea for this implementation is for centralized control. It fits in our organization and it has been working well. We don't have to maintain multiple user/workstation policies in multiple contexts. We define one policy and apply it to all.

Just remember that there will be no perfect solution or plan for this. It all depends on what you need to accomplish.

Erica Griffith

We too operate with multiple contexts. We have separate contexts based on geographical location, and in each we have a context for users with sub-containers for students, non-teaching staff and teaching staff and a context for resources with sub-containers including:

  • A context for groups which then have naming conventions based on a number for type (file rights, application, workstation policy etc) and then a meaningful name to what it is (eg name of the folder it gives rights to)
  • A context for servers, volumes and associated bits and pieces
  • A context for printers, printer agents, brokers etc. (these have a naming convention based on geographical location)
  • A context for workstation objects (again geographical plus assigned asset number based naming convention)
  • A context for application objects, and
  • A context for policies

Victor Galino

From my experience the best practice is to have the application object on a OU and the policies on the top of the containers. The restriction is the containers are organized for my WAN deployment.

For example, in this structure:


I think it is best to put the top container on the OU BARCELONA, MADRID AND TOKYO.

In this organization the applications are on the container or the wan limits.

For the other objects:

Policy --> On the top container and associated to the containers or groups A policy for the admin, for example, goes on the container they are in.

Imaging Objects go on the server or the top container.

It is best to put application launcher to read to the top container,(WAN CONTAINER).

You can put the location policy to read to the WAN container.

Put Workstations at your place, or in a WAN container (for example WORK.BARCELONA.TREE) or all in the same container. I prefer to put the top on WAN containers and define the same in the others.

Server policies and Workstation should be put at the level of the object or container.

Jim Redfearn

We use this approach. In fact we have an OU for each type of ZENworks Object.

  • ZENApplicactions
  • ZENPackages
  • ZENWorkstations

We also have one called ZENApplicationsInstall. In here we create applications that are only intended to be chained to another application. For example we have the MSOffice MSI Install application object here and in ZENApplications we have the Word, Excel and Powerpoint applications; these are chained to the Install application.

We also use a naming convention that assists in identifying the applications. For example the MSOffice Install application is called "MSOffice2000Install_IS" the "I" denotes "Installs" the "S" denotes "Sub Application Of Chained" the Word application is named as "Word_XCU" The "X" denotes "Executable" the "C" denotes "Chained to another app" the "U" denotes "Associate to users not workstations". We use this process because we have a team that develops and delivers applications and another that manages assignments and so on. It also tells us how it is configured at a quick glance.

Our organisation is spread over a large geographical area we have an OU for each location and under each Area OU we have

  • ZENAppliactions
  • ZENPackages
  • ZENWorkstations
  • ZENApplicationsInstall

We find that this makes workstations, applications and policy packages easy to locate and manage.

Sergey Holodenko

We did it another way - we have a separate container for every department, and a subcontainer for that department's other divisions (if they have any). exists). Every container has its users, workstations, printers and sometimes applications if these apps are only used in this particular department.

This structure actually represents the location of physical offices. This is needed for proper printer assignments. Workstations can also be easily located in the tree for remote support.

Chad Miller

I also work in a school environment and have laid out our tree in a fairly similar way. We have an OU for all of our buildings and then under that OU are three more OUs: one for staff, one for students, and one for printers.

Under staff it breaks down into different departments or classes. Under Students are listed all the different classes, and under theCclass are listed the sessions if it's an AM or PM class. All my ZEN objects are listed in an OU called ZEN; under the ZEN OU are 3 more OUs: one for Workstations, one for Applications and one for workstation image objects.



For the most part this works pretty well. The only thing that can get confusing about this is that the workstations container can get very large. To combat that we have a naming convention for all of our computers. We use 2-letter combinations to distinguish building followed by a dash and the service tag of the computer.

Jeff Crawford

I take a slightly different approach then what has been recommended so far.

I have 1 Gbps and 2 Gbps links between my buildings, so replication or slow WAN links are not really a problem. I like to follow the "design by function" theory as opposed to the "design by location" theory. In my district, all students are created equal. Except for maybe a few group memberships, there is not a lot of difference between a 1st grader and a senior in high school. So I like to break my tree out like this:

     OU=ADMIN (secret Admin objects)
     OU=APPS (ZEN Objects)
     OU=BACKUP (Backup software and server)
     OU=DATA (Data Servers/Clusters)
     OU=EMAIL (GW stuff)
     OU=STAFF (Staff Users)
     OU=STUDENT (Student Users)

Then within OU=APPS I create organizational units for applications (based on OS - so 2K & XP) and workstations (based on lab or purpose - a lab would be something like HS-LMC or a purpose would be like TL [Teacher Laptop]). So it ends up looking something like this:


This design works very well for labs. In my organization we assign people to be responsible for the lab. All I need to do is give that person the proper privileges for that lab container (usually through a group within the container - HSLMCAdminsGroup.HS-LMC.APPS.EGRPS)and now they can assign applications, use remote control, work with printers, or even re-image a machine. The reason this is possible is because all of the objects are within that container. This also implements a fairly simple - yet effective - way to control the people responsible for a lab.

For example, they cannot deploy an app until I move it into the container for them. The actual privileges differ based on the individual's technical experience, but, because most people in my organization have little networking experience, they basically cannot do much.

Good luck with your design!

Supawat Pugkhem

I work with an IT consulting company in Thailand and have been working on ZENworks since 1.1 Starter Pack and now 4.01b. I have a similar setup to Chad Miller. Here is how I have extended our tree for ZENworks objects, which will keeps all ZENworks objects under one OU.

------CN=ManamentGroup <--------- Group to assign to ZENworks object Management users
------CN=RestrictedGroup <--------- Group to assign to ZENworks object restricted users
------CN=UnrestrictedGroup <--------- Group to assign to ZENworks object unrestricted users
----OU=Applications <--------- contains all ZENworks Application objects
------CN=ApplicationsFolder <--------- to organize structure when using NAL
--------CN=Paint <----------- for Microsoft Paint Brush
--------CN=Notepad <----------- for Notepad
--------CN=Calculator <----------- for Calculator
--------CN=AutoCAD <----------- for AutoCAD
--------CN=Adobe Photoshop
--------CN=MSExcel2000/XP <----------- for Microsoft Excel 2000
--------CN=MSExcel97 <----------- for Microsoft Excel 2003
--------CN=MSWord2000/XP <----------- for Microsoft Word 2000
--------CN=MSWord97 <----------- for Microsoft Word 2003
--------CN=Acrobat Reader <----------- for Adobe Acrobat Reader
--------CN=WinZip <----------- for WinZip
----OU=Policies <--------- contains Policy Packages and some Application objects
------CN=ManagementPackage  <----------- for all User Policies including Dynamic User, GPO, ...
------CN=RestrictedPackage  <----------- for all User Policies including Dynamic User, GPO, ...
------CN=UnrestrictedPackage  <----------- for all User Policies including Dynamic User, GPO, ...
------CN=RestrictedWorkstationPackage  <----------- for Import, Inventory, ...
------CN=UnrestrictedWorkstationPackage  <----------- for Import, Inventory, ...
------CN=ContainerPackage:General:Search Policy
------CN=RestrictedRegistries <----------- This is an Application Object that add/del some registry entries to PC
------CN=UnrestrictedRegistries <----------- This is an Application Object that add/del some registry entries to PC
----OU=Workstations <--------- contains Workstation objects


  • There are groups for ZENworks association under OU=Groups

  • There is VOL1:Applications to keep AOT/AXT ZENworks Application objects
    • VOL1:ZENworks\Application\MSOffice97 for keeping Microsoft Office 97 files
    • VOL1:ZENworks\Application\MSOffice2000 for keeping Microsoft Office 2000 files

  • There is VOL1:ZENworks\Policies to keep GPO
    • VOL1:ZENworks\Policies\Managers for keeping Manager GPO
    • VOL1:ZENworks\Policies\Restricted for keeping Restricted GPO
    • VOL1:ZENworks\Policies\Unrestricted for keeping UnRestricted GPO

  • There is VOL1:ZENworks\Utilities to keep all ZENworks tools such as ZENworks Browser, etc.

  • For Microsoft Office applications, we use system requirements to deploy the correct version of the object to PCs between 97 and 2000/XP version. Then, on 2000/XP version, we use Fault Tolerance for objects to point to the correct EXE location.

  • For Application Objects that involve doing Policies such as Registry Modification, we place them under the Policies Container. These Application objects do things that are not available on GPO/ZENworks policies, such as DragHeight, DragWidth, Compress Old Files, etc.

  • There are three levels of policy.
    • UnrestrictedPackage for Admin, helpdesk users
    • RestrictedPackage for normal users
    • ManagerPackage for managerial position [or notebook], which will be able to see some more such as Desktop, Local Drive

  • For Workstations Container, I used to create a Workstation Group to classify the PC priority, but I prefer to move the PC to each associated OU.

C. Posner

I'm in a school environment too. Something we school admins have to deal with that our corporate brethren do not (usually) is massive turnover of users every year.

David, I like the layout you have and have a suggestion for you. If you want all your student and teacher accounts in your Campus context, I'd suggest putting the teachers in the root of that container, and making subcontainers named for year of graduation for your student users (the home directories should also be organized by YOG). This has two advantages: first, getting rid of all the graduated students' accounts is easy, just delete their container and the folder of home directories for that year ... Click! Buh-bye!

Second, it's much more efficient to associate app objects to containers rather than groups - that way no machine has to read a member list of some huge catch-all group to see if this user is a member. It's also easier for you as the admin. Let's say you have apps that only the seniors and juniors should have access to but not the other grades. Rather than keeping track of which students are in which group (which may change every year), associate the apps to the YOG containers and you're done.

Good luck in your new job. :)

Mark Baldwin

We are a large high school (1900+ students) and break down our OUs as follows:

  • Students: Ten OUs established, named "0" through "9", and students are added to one based upon the last digit (#) their expected graduation year. This reduces the number of special userIDs resulting from same-names, and also makes it very easy to delete the outgoing senior class (including their data files on the server).
  • Teachers all go in a "T" OU.
  • Staff go in an "S" OU.
  • Students simply log on with as "UserID.#", teachers log on as "teacherID.T", etc.
  • Printers have their own OU: "P".

Workstations are placed in one of three OUs: "W" for Win-2000 student workstations, and "WT" for Win-XP teacher workstations, "WA" for Admin stations. Each has different workstation policies, stored in their respective OU.

"Applications" is an OU, but has several branch OUs: "All Users", "Teachers", "Students", "Admins". This helps keep track of the 180+ applications offered.

There are several other OUs set up for unique groups where it makes sense to keep the related objects together.

Paul Crew

We are doing something a little different with our ZENworks Application deployments.

Instead of replicating ZENworks objects around the location based OU's in our tree, we have created a ZENG (Zen Global) context immediately below the ORGANISATION object, in which we place our application objects. This enables us to achieve excellent standardisation across the enterprise, as all users will use the same application object for their application distributions.

For ZENworks Policies, we are still using a ZENL (Zen Local) OU, but moving towards the ZENG OU on a location by location basis.

During user login, the script tests the IP address and determines the physical location based on the IP address. Once the location is known, then we assign %NALSRVR% and %NALVOL% variables to point to the nearest server which contains the application source. Here's a small example. (We also use this methodology to set other useful variables not discussed here.)

REM Detecting XYZ network ( -

Now we can use the Application Source path of
for the source path on a global application.

The Application source needs to be replicated around the servers that will hold the applications, but this is pretty much the norm no matter how you configure your objects.

We have found this approach to be very productive.

Rod Goessling

Here's an addition to Paul Crew's suggestion (Paul is a colleague).

The ZENG Container is partitioned and replicated to all sites. All users have the appropriate rights to the NALAPPS directory on all Servers.

To have the same functionality with MSIs requires a little more work:

  1. Create the Application based on the MSI as normal. The Application will then typically point to a UNC path for the location of the MSI. For example:
    Once the Application has been created you can't change this information.
  2. Now export this Application as an AXT file.
  3. Edit the AXT file and replace "MyServer" with "%NALSRVR%" and replace "MyVolume" with "%NALVOL%".
  4. Then create a new Application based on this AXT file. You will get errors when you open this Application, indicating that it can't open the MSI file, but you can manage other aspects about the Application, ie Associations, Availabilty etc.

While this requires a little more effort it certainly provides a standard approach and it also avoids the issue of having many applications and synching the GUIDS which is always risky.

Travers van Lierop

I won't bore you all with the setup we here at RMIT use, as it is still really a living, breathing setup that changes with our changing needs. I've been using ZENworks since Novell were kind enough to release 1.0 and I found out I could turn my boss's desktop into that lovely "High Contrast #2" Colour Scheme (hehehehe - that still makes me laugh).

In short, we use a combination of the Central Apps OU sitting directly under the O, and then school-based apps and workstation containers. This gives the greatest flexibliity for the 1,794 apps throughout the tree. (ie Corporate Apps from the central container and school-based apps from their local containers.)

We then use a combination of APP_Users groups for those people to install/run the apps and also use normal IT_Support groups managed at local sites to associate the app. The groups for association live with the apps ( This design occurs similarly at the top, right down to the bottom.

I have found it to be the best practice to have user and workstation policies sit in the containers with the users. This makes them easy to find and will help with possible search policy blocks to help with tree walking, and ensures the users can actually log in and get the right policies.

Since our tree is structured to replicate the Organisation Structure, we classify our users under the School (staff, undergrads, postgrads etc), and typically do such with most other items (printers, groups, groupwise, servers). This helps with the diversity of users and saves us using a myriad of groups.

Another good idea I am trying to implement here is to ensure that all your User Policies are "Dymnamic Local Loser" (oops I mean User...really...) that are Volatile, Don't Manage Existing Accounts and have only USER rights. This may increase support time for configuring, say, a staff member's PC to give them say POWER USER rights, but means that all your users traversing your organisation won't stuff up anyone else's PC.

Hope this helps your ZENworks Cause, and feel free to contact me, as I would be willing to show you copies of our Networking Standards Documentation to help you on your journey :)

Matthew Sprout

I'm in a school environment also. I agree with trying to create OUs for the different ZENworks objects. In addition to this we structured our OU for students differently. We have a school district of about 4,500 students and all of these user objects are in the same OU. Note: The schools are all connected by fiber with the servers in a central location.

To be LDAP compliant all user objects must be unique so we have a naming convention that a user gets in Kindergarten and keeps throughout their school career (first four letters of their last name plus the four last numbers of their student ID). There are still some conflicts but only a few that we have to revise.

Also by putting the user objects in the same container we only have one login script to manage and based on their group membership (year of graduation) they get specific applications.

Our tree appears this way:


This also keeps us from having to rebuild the student accounts every year.

Kris Sulzberger

In our college environment, application association is determined based on classes taught in each room and machines authenticate as the room #. So the tree breaks down the instructional part of the network into each actual room. Then in each room you have your user, printers and a workstations OU, with the applications for instruction at the base of the instructional container. Policies, print manager and broker all reside at the base OU of the initial subgroup. Like so:

--OU=Support Staff
--OU=Administrative Staff
++ADM User Policy
++ADM Workstation Policy
++ADM Print Manager
++ADM Broker
--OU=Workstations (one pc in room)
+++Zenworks Images
---OU=<Each Computer Lab #>
++INS User Policies
++INS Workstation Policy
++INS Print Manager
++INS Broker
++Application Licensing Meters
++IS Staff

While it's probably a lot more up front work to make an OU for each Lab, I like it from the basis of organizing workstation objects and printers. For rooms that only have one machine, like an instructor station, the user and workstation container reside at the base of the INS OU. Probably the biggest issue with this setup I can recall is having to grant ADM users rights to printers in INS so they can use them when they login as themselves in a room to teach, which will be something you'll want to think about depending upon how you handle authentication.

Erik van Leeuwen

We have just about 500 Application Objects. We have ordered them as follows:

The Apps container is for the applications that most people use in our organisation.

  • Forced-run for applications that startup during startup of NAL
  • Consulting applications for our consulting department
  • Access database for Access applications
  • Backoffice for our main system

Lisa Deger

We have over 470 ZENworks applications. All applications are in the ZENworks OU so we don't have to search all over the tree for applications. I do have a Discontinued Products OU for staging old applications. To identify the applications we have used several naming conventions:

Department applications are prefixed with department name:

  • FIN - Finance
  • IT - Information Technology
  • HR - Human Resources
  • MKTG - Marketing

This way the deparment applications all sort together.

  • FIN-CreditCardApp-LNK-L1
  • FIN-BTaxrcap2-L2
  • FIN-Collections-DB1

I use other naming conventions to determine the type of application:

  • LNK - Browser Link
  • SCR - Installation Script
  • CFG - Applications Configuration (files, reg settings)
  • REG - Reg settings only
  • DB - Database Link
  • MSI - MSI Application

Ending Descriptive Codes determines several things - Network/Local/Icon and Version

  • N1 - Network Application
  • L1 - Local Application
  • A1 - Icon Only
  • A2 - Second Version (used a lot when we were converting from NT to XP)

Sample Application Names:

  • SLS-CallReports-A1 - Sales Department - Icon Only Application
  • MSAccess-WrkGrp-REG-L1 - Microsoft Access Workgroup Admin Registry Settings - First Version
  • MSOffice2000Std-NET-MSI-N2 - Office 2000 Standard - Network Installation - MSI - Second Version (desktop)
  • MSOffice2000Std-LOC-MSI-L2 - Office 2000 Standard - Local Installation - MSI - Second Version (laptop)
  • MSIE6SP1-SCR-L1 - Microsoft IE6 Scripted Installation - Local Installation - First Version
  • MKTG-NewCustomer-DB1 - Marketing Database

Darrell Eddy

I have a situation where I need to restrict users' access to workstations. For instance, students need access to workstations in the labs, and any other common area. Faculty members need admin access to their own PCs, and to PCs in common areas like the classrooms, and a couple of stations in the research library.

I was considering arranging the systems into OUs under our workstation OU like LAB 217, Library. etc. That way in the Dynamic Local User Policy in the user package, I can add a container holding the PCs to the Excluded or Included Workstations list under login restrictions.

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

© Copyright Micro Focus or one of its affiliates