|
|
United States-English | |
|
|
 |
|
HP 9000 Networking: NetWare Directory Services > Chapter 7 Planning NetWare Directory Services
Implementation
First Steps |
|
|
To begin planning your Directory tree, look first at your organization's structure, functions, geography, and needs. NetWare Directory Services is designed to reflect a hierarchical structure. Generally, this means that your Directory tree will be patterned according to some logical structure of your organization or locale, whether or not that structure is formal. Try to simplify the hierarchy as much as possible. For example, if your organization is formally divided into departments, you might decide to structure your Directory tree by departments as well. On the other hand, if people in several departments work together on long- term projects and need access to common resources, it might make more sense to divide your tree by project teams instead of departments. When planning your Directory tree, also consider who will be running the network. With NetWare 4™, you can centralize network administration so that a single person or small group of people control the entire network. You can also distribute administration so that many network supervisors throughout the enterprise or organization control their own portion of the Directory tree. If network administration will be distributed, everyone who will be administering the network must be involved in the planning. See Appendix C, "NDS Object Classes and Properties." We recommend creating two maps of the tree when planning. The first and most important is a logical map of the tree—in other words, names and placement of Organizational Units and other objects. The second is a physical map of the placement of replicas—in other words, a view of every server and what replicas are stored on each. The following illustration shows partial examples of these maps. Part of the process of developing the Directory tree maps is to determine names of objects. If there are standards in place for using NDS, then users can more fully navigate, use, and exploit the Directory tree. Searching and browsing rely heavily on the ability to do a lookup in the Directory based on criteria from the user. If object names follow a standard, then searching is simpler. For example, if all laser printers are named "LJuniquename," where uniquename is more descriptive, then a search for all printers named "LJ*" is feasible. See Appendix C "NDS Object Classes and Properties" for more information.
Naming standards detail the conventions you will use for naming Directory objects, including users, printers, print queues, and servers. Standards should also specify how you will enter property values (telephone numbers, addresses, etc.) for the objects. If you will use bindery services, make sure the names are compatible with standards for bindery-based versions of NetWare. (See Appendix C, "NDS Object Classes and Properties.) Consistent naming standards provide a guideline for network supervisors who will be adding file servers, creating users, modifying and moving objects, etc. Consistent standards also make it easy for users to identify the resources available to them in the Directory tree.
Make sure naming schemes are short, yet as descriptive as possible. For example, "Software Engineering" could be shortened to "SWEng." All Directory object names can contain up to 64 characters in their Name property (the name given when an object is created). The Distinguished Name of an object is limited to 256 characters (including name types, periods, and equal signs). However, concise (short) Organizational Unit names that are meaningful make it easier to use the Directory tree. Keeping names short reduces the amount of data going across the wire, simplifies logins, and makes names easier to remember. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 Printable version |
|
|
|
|
|
|||||||||||||||
|
|||||||||||||||
