Special OU Just for ZENworks Objects
Novell Cool Solutions: Trench
Digg This -
Posted: 27 Jun 2001
We recently posted this in the Q&A and asked for reader comments. If you're looking for practical advice on ZEN tree design, you'll find a lot to think about here. If you have additional thoughts on this, chime on in.
SW wrote: I read in the ZENworks for Servers docs that it recommended a OU just for ZEN stuff for better management. I'm not sure if I'll install ZfS or not, but does anyone have their ZFD setup in its own OU? What are the pros and cons?
There are a couple of schools of thought out there. One expert who subscribes to the recommendation in the documentation says this:
"Yes, definitely create an OU for ZEN objects. If you use all of the features of ZfD, you more than likely will have a lot of objects added to NDS. It is much easier to manage these objects when they are separated from user objects and such. I've seen suggestions for making one OU for workstations, one OU for applications, one OU for policies, etc. That seems a bit much in my opinion. I think one OU named, for instance, "ZfD" works great. If you decide to create another OU for ZfS, then call it "ZfS". We named our ZEN OU, just plain old "ZEN". It's nice being able to select that OU and see only ZEN specific objects."
On the other hand, another opinion is:
"You need to be careful that the design you choose is the most flexible. A dedicated OU might be good for administration but then you're basing the NDS design around your requirements and not the end-user's. Placing your ZEN objects near your users is generally good practice."
- Gerda Kloos
- Mark Yount
- Jeff Wettlaufer
- Elliot Romero
- Dan Kirk
- Mark Arzillo
- Daniel Verbarg
- Jim Trotter
- Neil Stansbury
- Andrew Hutchison
- Pam Kulczyk
- Edward Falzon NEW
I hear this dispute a lot with customers. People keep trying to organize their NDS objects by type just because it looks nice. Of course you lose a lot of flexibility and performance.
In my opinion, planning your NDS is like building and furnishing your house. Would you think about having one room for tables, one for chairs, one for cupboards, one for bookshelves...? The point is: organize for best use, not for best look. You will always be able to see only of a certain type for management purposes - that is a matter of how you use your administration tools!
I also subscribe to a dedicated ZEN container. With hundreds of application objects and thousands of workstations, I have created dedicated subcontainers for applications, policies, workstations, etc. I have this ZEN tree branch partitioned off and replicated to ensure good performace. I've always been from the school that there are only a very few administrators vs. many users, so if I can make administration easier and not have the impact noticeable to the user, I design for the administrator.
To suggest a dedicated OU for ZEN has several merits: ease of administration, organization, skills transition, and bandwidth maximization (traffic reduction) to name only a few.
There are basic NDS design principles that apply to any ZfD deployment, and as we all know, NDS trees are like humans - they are all unique. I suggest that we take into consideration general NDS guidelines for the ZfD CX development on a site-by-site or project-by-project or customer-by-customer basis, and factor in variables such as object numbers (less and less with DS v8.x), tree complexity, WAN connections, server locations, user locations (from a CX perspective) and scalability. It is amazing how many NDS trees are migrated from old flat Bindery worlds, or were designed in the early releases of NDS where DS design principles were not as developed as they are now. As a result of this, Trees may not be designed in the best manner or suited for Directory level Applications like ZfD.
There will be server centric object creations in the NDS when the schema is extended at the point of ZfD install into the tree. Objects will be created within CX proximity to server objects, for example Inventory services objects and SLP services objects. (Note: the SLP object world is not created by default, it must be created manually.) The rest of the ZfD DS development is up to the Administrator. It must be kept in mind though, that if dedicated OU's are used (and in many cases I use them myself) these additional levels of complexity must be reflected in Search Policy development, and careful attention must be paid to minimizing resulting LAN/WAN DS traffic (and user performance degradation).
There are several questions one can ask when designing ZfD. To name a few:
- How flat is the tree? Is it already extremely elongated and lacking in NDS CX design? If so, this is a good reason to justify dedicating ZfD OU's, and adding NDS CX development.
- How many users are in the tree? If there are large numbers, spread across OU and CX's in the tree and LAN/WAN, consider locating object pockets within their localities. (Useful for WAN and site development).
- Who is administering the Tree? Not the best of considerations to base such a decision on, but it is important that Admin teams are comfortable with the day-to-day access to the ZEN world in the tree, especially for centralized activities such as Application deployment/support, Remote Control, etc. Much of ZfD configuration is one time only (such as policy development) and rarely are changes of a significant nature made. Day-to-day operations from a Help Desk perspective require ease of access, especially when there is a Help Desk telephone support situation, including Application objects, workstation objects, etc.
- How scalable does the customer want the ZEN world to be? If the Tree is smaller in size, with a small amount of users (possibly less than 500), it would be safe and efficient to allow objects like workstations to be created in the users containers. For larger sites, it may be beneficial to dedicate an OU for workstations. This OU could be located in multiple CX's. A sub OU in the Departmental or Site OU's, or an OU within the ZfD OU.
- What is the NDS partition replication strategy employed? It would be a good suggestion to incorporate this information into the decision making process for the ZfD CX design. Not only could one eliminate traffic with efficient ZEN design, but performance can be enhanced by ensuring issues such as Search Policy location reflect (or at least consider) the partition replica locations, as well as the boundaries defined.
- Where do you want to place Application objects, policy objects and ZEN services objects? This answer will be different for every site and every customer. It is safe to suggest that some service objects live within the server CX, but the rest will be defined by factors such as mentioned above.
Some suggestions I would make when considering what to do when the question of ZENworks CX development is asked by the customer or your manager.
- Don't let the existing tree define in absolute the ZEN world. ZEN is very object based even with ZfD v3. With the exception of overly complex NDS trees, it is never a bad idea to dedicate an OU for ZEN. Simply be aware of Tree depth.
- Watch the NDS partition replication. Launch NDS Manager and examine the NDS. ZEN is a directory level application, and relies heavily on both the DS partition structure and its health.
- Where are the users? All in one container? Multiple containers? Flat? Complex? Ensure Search Policies don't work too hard to reach between them and the ZEN world you are configuring, or the users will suffer.
- What's the plan of this Tree? Scalability is important. A dedicated ZfD OU is modular.
- What services are going to be employed? Allow for future growth and flexibility. Another good argument for modular ZEN OU's.
- Are there NDS standards for design? If there are multiple sites, a modular OU for ZEN will allow for easy replication of the design, ease of administration, and ease of future development. In multiple site situations, dedicated OUs are an excellent method of ensuring consistency. We like consistency, because we don't like surprises. (Room nodding in agreement).
If you have any questions you may contact Jeff at JWettlaufer@systems-group.net
If you choose to create a ZEN specific container, be careful how you partition and replicate. If you partition the ZEN objects onto other servers, and the servers that the users normally attach to do not contain replicas of ZEN objects, then the user will perform what is called "Tree Walking". While Tree Walking is a normal part of NDS, it should be minimized to provide users with the most efficient access to NDS objects. Be especially careful of placing ZEN objects across slow WAN links. This will cause a severe degradation in performance as users go across slow WAN links to access NDS information. This can bring most offices to its knees in a hurry.
While I can appreciate the added ease of administering NDS by creating ZEN specific containers (given all the new objects that ZEN introduces), I am hesitant in recommending a design structure that can possibly negatively impact the end user. I mean really, aren't they what it's all about?
If you have any questions you may contact Elliot at email@example.com
I am in the process of rolling out ZfD3 to 13 separate locations. We have made the decision, based on what we feel is good design practice, to include a separate OU for workstations. In our environment each OU is its own partition and the workstation OU is created directly under the existing one. This gives us ease of management of the objects and keeps them near the users. As some of our OUs have 1500+ objects already, adding an additional 400 objects would make management of the workstations problematic in ConsoleOne. All Application objects and policies are created in the users container with the exception of workstation policies.
If you have any questions you may contact Dan at firstname.lastname@example.org
I think the design really depends on your existing tree and your Organization as a whole. In my tree there is only one partition due to its small size (under 50 employees). I have a container for Users with the Workstation and Policy objects placed in it as well. The Applications are under an Apps container parallel to the Users container.
If my tree ever needed to span a WAN then I would create another Organization container with the same setup and partition accordingly. I never could understand why some people say it's better to have objects that a user might need close to the user object. If they are all in the same partition what difference does it make? I can see keeping all objects a user needs in the same partition the user is in but within the same partition I don't see the point.
For example how much faster would JohnDoe.Users.ABC get object MSWord.Users.ABS then he would get MSWord.Apps.ABC as long as both the Users and Apps container is in the same partition? Does anybody have any benchmarks for testing something like this?
If you don't design NDS with OUs for ZEN objects then you can filter your objects. There is a nice filter in ConsoleOne. (It could use some enhancements though, such as buttons to switch between Filters and maybe pre-made filters that say ZfD, ZfS, users, servers, security, etc.)
I like special containers just for App Objects (as well as workstations and policies). Unlike what you probably have in mind, I make my containers a child container of my user container so they stay near the users. This also gives me the option to partition them off if needed.
My company likes apps on the workstations instead of being run from the server, so as I build my ghost image I use the app objects to build the workstations so the GUIDs are written into the registry. I also duplicate as many app objects to other locations, then sync the GUIDs of like objects so I can then use my workstation image in all locations. Lastly I assign the apps to the workstations (via the workstation container or workstation groups), not users. For apps that run from the server, not the workstation, I link those objects to their counterparts in other locations using the application site list function. This will then launch the apps locally instead of dragging them across the WAN. The vast majority of sites use T-1 lines so speed is not really a problem at login.
Between both methods of assigning app objects, my users can wander freely between locations and have access to all their applications locally. They don't really even notice a difference as they wander from site to site.
If you have any questions you may contact Jim at Jim.A.Trotter@usdoj.gov
In principal I totally agree with Gerda Kloos on the OU container. In general it goes against the underlying philosophy on Directory Services, and is a right royal pain in the backside in applying rights and getting inheritance to work properly. We generally find it is used by people who are still thinking NetWare 3.12 and server-based resources, rather than role or function-based resources.
There is, however, a very nice compromise that we have used on a number of large sites, and have found it to work very well. The senario was as follows:
- 40 remote offices around the UK.
- 8 regional offices.
Each regional office had on average 5 remote offices in its region. Split as 1 OU for the regional office, with its 5 or so remote offices as subordinate OUs.
We didn't want to create 40 copies of all the application objects, or policy objects, as management and updating would be a nightmare, and we didn't want to create one container with everything in it as this would make a replica ring massive, and did not provide enough granularity.
So under each regional office, we created a ZEN container at the same level as the remote office OUs, and placed all application and policy objects (exc. search) in there - but NOT workstation objects. This ZEN container was then partitioned and replicated to all the remote office servers and the regional office server (replica ring of 6-7). Normally this would break NDS design rules, but the objects were rarely updated, and so created little synchronization traffic. We could also update one app or policy object, and have it automatically sync with all the remote offices. Instead of 40 copies of an app, we had 8 - a nice reduction.
The really cool part was, each ZEN container had a ZEN-based profile login script which every container called, and ZEN groups for assigning applications. Normally running login scripts and commands like if "member of group" would be a nightmare over a WAN. However, because each office had a local copy of the replica, the scripts and group memberships could all be resolved on their local server because of the local ZEN replica. So we effectively ended up with global login scripts - but local ones.
This was a justifiable approach because workstation objects were created in the correct remote office OU. This made sense because it was a resource particular to the user and office. The app and policy objects were regionally specific so it was justifiable to distribute them via the regional office. Search policies were the exception and were placed in every OU, with the ZEN OU in its search path.
We NEVER use UNC paths in our app objects for exactly that reason. Each office mapped a local drive (W: in our case) to their local servers, all objects were then referred via the global mapped drive. Until there is some kind of cool DNS name resolution process for getting a local object this is definitely the way to go. Hardcoding hosts into an app object is mad, and destined to cause headaches.
We had one client that created one OU for Win32 apps, another for Win16 apps, another the NT policies, another for Win95 policies and so and so on. This was an absolute nightmare, since everything had to be explicitly assigned (they even had a container for their server/volume objects). The Tree was (still is) a management nightmare, they have had to spend more money on pure NDS servers because of the strain of 5000 people logging in every morning - their container login scripts had 60+ "if member of groups"!
I guess what I'm saying is it's about balance. Pick the right design for the right job, and if it works for you - well hey, who are we to say don't? Just consider the consequences, make sure you understand Directory Services conceptually not just technically, and if you don't hire someone (like us!) to help you get you get it right the first time, a little time and money upfront can save hundreds of thousands of <your currency here>, and ensure the business gets the most out of NDS.
If you have any questions you may contact Neil at email@example.com
It's all about flexibility. I have a number of clients, varying in size and number of remotes, that have employed variations on the schemes posted. I have found it most productive to make a compromise between ease of administrative support and user performance (leaning more toward user performance). Both Elliot Romero and Jeff Wettlaufer explain this concept well in their postings.
My additional thought is to have a single ZEN container per physical location (assuming good NDS design and a separate OU for each locale that is partitioned). This keeps ZfD objects close to the user object (minimal tree walking), but reduces administrative burden since ZEN objects are easy to find and manipulate if in a separate container. However, I usually do not recommend placing workstation objects in the ZEN OU. Generally, placement of the workstation object should center on both your administration model and the "tree walking" issue.
I have found it most advantageous for help desk personnel, when performing remote control, to have the workstation objects placed in the same OU as the user. A user can call the help desk and be remote controlled with one of the RC-only utilities (ZEN WS Browser or Quick Remote Actions) in a manner of seconds. There is minimal tree walking when apps or policies are associated with the workstations and there is usually not an issue with the number of objects per partition recommendations (no issue with eDirectory).
The idea of a locale-level ZEN OU and workstation placement at the user level also lends itself well to the tiered help desk model. In other words, your first line of support would be granted minimal rights to DS (rights to change passwords and ability to perform ZEN RC). The second line of support would have more comprehensive NDS rights and these techs are more likely responsible for ZEN apps and policies.
Another thought. Why not create a ZEN-only tree? This is something I have considered, but not implemented. This may be an option for some if their tree is in bad shape or if they want to quickly implement ZfD 3 in what is currently a 4.x environment. This concept may give you an opportunity to migrate to eDirectory, upgrade your DS design and facilitate a move to pure IP. A ZEN-only tree might be the best solution when it comes to flexibility. What do you think?
Thanks for posting opinions on how to incorporate ZEN into the NDS. I'm working on an install for about 400 users at one location and wasn't exactly sure the best route to go with the tree setup. I feel confident after looking at others' scenarios that I will be able to set it up properly.
From an NDS design standpoint, I'm sure all would agree that minimizing the Tree-walking would be ideal, as would minimizing the Replication traffic. But these two things are not mutually exclusive. Just create ZEN objects in local partitions of every site! Done.
Now, traditionally, that would cause no end of administrative burden - but just download ZENith and have the best of both worlds! The Administrative burden is practically non-existent, because the Administrators can shoot out a bunch of Apps AND Policies in a single operation, with no pre-configuration requirements.
Even if the Apps being sent out all have different Group/Container associations, ZENith doesn't care, and ZENith also doesn't care if there's a different NDS Tree at every site. :-)
The only reason ZEN Tree design is discussed is to find a nice balance between performance/traffic and administrative burden. But ZENith pretty much removes the administrative burden, so there's no need to discuss Tree design anymore!
Check http://www.performingpcs.com to get more info about ZENith, and to get a 14-day free trial license.