Leveraging NDS in Your Environment: A Corporate Case Study
Articles and Tips: article
Manager, LAN Server Operations
Case Study Corporation
01 Dec 1998
Presents an in-depth look at how one large corporation has implemented NDS, along with ZENworks, Novell Replication Services (NRS), and other Novell technologies to facilitate their most common network management tasks.
- Introduction
- The Starting Point
- Case Study: The NDS Tree Design
- Easing Access to Applications
- Conclusion
Introduction
This AppNote presents a case study of one corporation's implementation of Novell Directory Services (NDS) and NDS-aware programs and utilities. The concepts and designs outlined in this study reflect the actual design of the NDS environment used by the company studied. Since the normal, day-to-day operations of companies vary to some degree, this document should not be considered a blueprint for every NDS design. It is intended to provide additional insight to those preparing to design or restructure their company's server environment.
While all of the concepts and methods detailed have been proven in a live production environment, some may not necessarily reflect the preferences set forth by Novell design engineers. The author has attempted to explain each concept in its real-life context to fully describe the purpose, benefits, and problems encountered.
The Starting Point
This AppNote details not only the environment that the case study company created to take advantage of NDS and the host of NDS-aware tools, but also the process used to achieve that environment. To understand the final outcome, it is important to understand the starting point—the design issues that were debated and the decisions that were made along the way.
Like many companies, CSC's server environment evolved from the design concepts normally associated with previous version of Novell's NetWare and Microsoft's Windows NT. This particular company maintained a NetWare server in each of the buildings at its corporate headquarters, as well as one in each of the other office locations worldwide, utilizing a mix of NetWare 3.x and 4.x servers. Each of these servers provided applications, personal and shared server storage, and network printer services to its respective building. When a user or department was physically relocated to another building, their user accounts, data, printers and any other related network services had to be relocated to the server in their new building. The company maintained similar server environments in a number of international locations. CSC also had a number of Windows NT servers, generally for specific software application purposes such as WinFrame.
The design of the NDS tree was also influenced by previous server OS versions, with each server in a separate partition directly off the company-level organizational unit (OU) in the tree. Each server was numbered, and the server partition OU naming convention contained the state or country abbreviation and the server number (see Figure 1). Each OU contained a server, named with the same number as the OU. For example, the OU named TX1 contained the server OS1, CA24 contained OS24, and so on.
Figure 1: The original NDS tree at CSC had a very flat design, with a server in each OU.
CSC administrators learned long ago that servers occasionally move from building to building, and that departments sometimes change names. By choosing to simply number each server rather than select a name that identifies a department or location, they eliminated the need to change a server name if it is relocated.
All of the buildings at the corporate headquarters are attached to a common fiber backbone. The other office locations are connected at a variety of speeds, depending on the availability and cost of access at each location (see Figure 2).
Figure 2: In the initial corporate server environment, remote sites were connected by a variety of WAN speeds.
Clinging to Old Concepts
Many corporate IS departments grew out of the consolidation of various "home-grown" IS groups from each department. By centralizing the IS duties, administrators and support personnel were able to standardize practices across the entire company, rather than each department developing their own process. Unfortunately, the servers maintained by these centralized IS departments often maintained their decentralized duties, each one serving its assigned department as it always had.
Given the protracted adoption rate of both NetWare 4 and Windows NT Server, it is easy to see why some administrators have held tightly to the Netware 3.x logic that each server should support a specific department or building. Many have built their entire NDS tree around that logic, in which server A lives in building A and supports department A, while server B is likewise dedicated. While the environment this logic creates is functional, it is far from efficient. As CSC continued to grow, the network administrators realized that a restructuring of the NDS tree was inevitable.
Designing a Network to Leverage NDS
A major goal of any network design should be to make maintaining that network as efficient as possible. It only takes a stroll through your user support team's offices to see what the most time consuming tasks are. What those tasks are at your site has a direct impact on the most effective tree design for your company. In the case of CSC, the corporate headquarters staff identified the following three items as their most daunting tasks:
User moves, adds and deletes. User moves, adds, and deletes are the most basic tasks of any system administrator. The larger the company, the more time consuming these tasks become. While creating new users and deleting those who have left is inevitable, moving the accounts of users who have either physically relocated within the company or have moved to another department (or both) is a task that can almost completely eliminated.
Maintaining corporate applications suite. CSC had already realized that applications are much easier to maintain if installed on the servers rather than on each of the more than 5000 PCs it owns. But even server-based applications require some files to be loaded on the desktop to function properly. While these desktop updates could be scripted to run during login, it requires a great deal of work to prepare each application.
The process of testing new applications and updates was also a challenge. To allow a user to test a new application installation typically required the tester to log into a test server in a separate NDS tree, eliminating all of the normal day-to-day business environment variables from the testing process. Often it is these normal environment issues that cause problems with new application deployments.
End-user support calls (help desk). It seems all corporate help desks experience similar problems. Unfortunately, the root of those problems lies in the impossibility of staffing one dedicated support person for each end-user in your company. Despite all of the help desk call trending analysis and user help tools available, the effectiveness of your help desk is determined by how quickly a technician can answer the phone call, resolve the user's problem, and move on to the next phone call.
CSC administrators knew they had to design a NDS tree that could eliminate the work involved in user moves and changes, automate the rollout of applications, and supplement the existing help desk support tools. It had to be flexible enough to encompass different sites around the world, yet maintain standards firm enough that one central help desk can easily support any user in the world. The designers had to give thought to the future, with a network that could take advantage of new products and enhancements without having to be restructured. And finally, the design had to be implemented without disrupting service to the end-users.
Identifying NDS-Aware Solutions
One key to effectively designing an NDS tree is to recognize the host of supporting NDS-based applications offered by Novell. NDS alone provides a central, multi-server, user administration database. The Novell tools that utilize NDS provide the ability to manage that environment.
The tools considered in the NDS design process for CSC included:
ZENworks (which includes the Novell Application Launcher)
NDS for NT
Novell Replication Services (NRS)
ManageWise
Novell Distributed Print Services (NDPS)
Other solutions considered for future enhancement included:
NDS for UNIX
Server clustering and shared data storage technologies
NetWare 5
Novell Storage Services (NSS)
Each of these products plays a major role in CSC's corporate server environment. Before diving into the new network design, let's briefly review the key points of each of these products.
ZENworks. This is a complete application menu and distribution package managed entirely within NDS. It provides a user workstation menu based on application object associations with the user's account, groups, or NDS container regardless of what workstation the user is logging in from. It provides a full application installation facility that can be both user driven or forced by the administrator. Also each application installation can be verified (or reinstalled) by the user at any time just in case they happen to delete or overwrite an important program file. CSC was one of the first companies to deploy ZENworks on a corporate scale.
The basic concept behind ZENworks is simple. To deploy a new shared application, the application is installed to the server from a standard load machine. A snapshot is taken of the machine before and after the product installation using a utility appropriately named "snAppShot". The changes made to that workstation are recorded into a data file and stored on a network directory, along with a copy of any files that were added or changed on the workstation. This information is used to update all of the workstations on which you want to deploy the new application.
Once the snapshot process is complete, the server administrator can use the NetWare Administrator utility (referred to generically as NWAdmin) to create a new Application object, utilizing the data file created during the snapshot. This Application object can contain the command line and any command line flags for the program, any changes made to the workstation during installation including files or registry settings, and any scripts or drive mappings required to run either before or after launching the application. An Application object can be created with or without the program installation snapshot data attached. The NDS Application object can be assigned to a single user, a group, or an entire container. Regardless of the assignment method, the new program icon will appear in the application menu for each user it is associated with.
When assigning the Application object, the administrator can determine if the program should be automatically launched during startup or launched manually by the user. The icon can be programmed to run at a specific time, to run only once, or to run every time the user logs in. Application icons can be made available to users based on PC operating system or machine characteristics. An Application object that includes the installation snapshot information can be reinstalled (or verified) by the user at any time, should a problem ever occur.
In short, ZENworks provides a full-featured application menu and software distribution system. The latest release of the product includes additional features such as a basic workstation hardware inventory, remote control and software metering. In addition, the application install verify feature saves countless hours of troubleshooting by the corporate help desk. ZENworks is perhaps the single most important addition to the new environment design at CSC. As the desktop menu system, it is the most visible feature available to end-users, and the software distribution system is as full-featured as any product on the market, combined with the convenience of NDS administration.
For more information on the use and features of ZENworks, visit the product home page on Novell's Web site at http://www.novell.com/products/nds/zenworks/. Another great resource is Kevin Prior's guide for using NAL which can be found at http://www.novell.com/programs/ncs/toolkit/nalguide.pdf.
NDS for NT. As the name implies, NDS for NT allows Windows NT servers and workstations to take advantage of NDS to manage users and groups. Best of all, you don't have to wait for Active Directory to be released. It is probably unrealistic to believe that any large company can operate totally on one server platform. Many find themselves with a mixed environment containing NetWare, Windows NT, and UNIX. Until NDS for NT, completely different tool sets were required for each server platform. By combining the NetWare and NT servers into the same NDS environment, administration tasks are centralized.
NDS for NT provides dual benefits for any company that has traditionally had to maintain an NT administration staff as well as a Novell administration staff. Allowing both groups to utilize NWAdmin to provide access to either environment, no duplication of user accounts is required. Pre-existing NT accounts can easily be imported into NDS to provide one single login account for each user that provides access throughout both the Novell and NT environment.
Novell Replication Services (NRS). In a perfect world, it would only be necessary to maintain a single copy of each application you use. However, in today's global corporations, a single application server is simply not possible. Even in a small company with only a few sites, the cost of maintaining multiple servers is usually less than the cost of obtaining higher speed WAN lines. And a local server for each location can be critical for operations should one of those WAN lines go down.
Using NRS is an effective way to provide multiple application servers and still only have to maintain one application server. Even with slow network lines, NRS provides a reliable data synchronization service between NetWare servers. CSC maintains all desktop applications on the server, simplifying user support by assuring that all users are running the same application installation. NRS is critical in providing applications consistently around the world, without spending any more time than it would take to update a single server.
ManageWise. ManageWise is Novell's network management suite, which provides extensive server and workstation management using NDS. By providing help desk and desktop support teams with an NDS-managed PC remote control, as well as extensive hardware and software inventory, primary user information is easily available from the same administration tools that support team members are already familiar with. By providing extensive server and network monitoring and reporting, the help desk can determine at a glance if there is a server or network problem that could be contributing to a user problem and helps the support personal avoid having to "guess" at possible server problems.
Novell Distributed Print Services (NDPS). NDPS provides a major advance from the traditional server-based print queue environment. It provides a desktop explorer style of printer selection with automated driver downloads when selecting a new printer type. Currently, not all network print server devices are NDS-aware and therefore cannot take full advantage of NDPS. Considering the benefits of NDPS and the low cost of new printer network interfaces, it may be time to consider replacing incompatible print devices.
NDS for UNIX. With the future release of NDS for UNIX slated, many companies will have the first real opportunity to maintain a single user account for all major network server platforms. The long-elusive myth of a single point of login may soon become a reality.
Server Clusters and Shared Data Storage. The concepts of server clustering and shared data storage played a major roll in the network design process for CSC. As the name implies, a server cluster consists of two or more servers working together as one. Should one server go down, the remaining ones carry the excess load automatically with no service interruption to the user. While there are several variations of the clustering concept, the basic feature is the ability for several physical machines to act as one logical server.
The concept of shared storage can be defined as the ability for more than one server to access the same mounted volume simultaneously. With the ability to provide two distinct servers that provide the same physical volume, load balancing can be introduced without having to separate user data on duplicate data volumes.
Novell Storage System (NSS). NSS is the new NetWare server volume file system which, by utilizing a new transaction tracking system, can mount any volume in only a few seconds. The traditional storage system could take an extremely long time depending on volume size and server speed.
By combining server clusters, shared data storage, and NSS, it is possible to provide multi-server cluster access to a single data volume. Meaning that a large number of users can access a single logical server (which may consist of any number of physical servers) to access a single volume (mirrored for volume redundancy) simultaneously. Either a drive array or a server may fail, be repaired, and brought back online without the users ever being aware of the problem. With new hardware technologies such as fiber channel storage (internal fiber network hard drive access rather than SCSI access), the mirrored volumes and physical servers can be distributed between two or more data centers some distance apart. By distributing a server cluster over two locations, even a major event such as a data center power failure could occur and be repaired without affecting the end users.
Case Study: The NDS Tree Design
After reviewing the major maintenance issues facing CSC and the host of NDS-aware tools readily available to resolve them, the next step was to create the new corporate NDS tree. As mentioned earlier, one of the major support issues facing the administrators and help desk is frequent user relocation and department changes which require moving the user's account and data to a different server, and configuring the user's desktop to log in to the new server. The majority of user moves occur within the corporate headquarters campus where about 3700 of the 5000 users are located. In the existing server environment, each of the 10 major buildings had its own server, which supported all users and departments located in that building. The challenge was to design the new server environment that "wouldn't care" where the users are located, either physically or within the NDS tree. The solution to this problem involved several conceptual changes.
First, the company already operated a central data center for other server platforms. When the existing servers were deployed, the PC desktop OS was primarily Windows 3.1, which ran from the server. The traffic load generated by running Windows over the network prevented these servers from being centrally located. By using tools such as ZENworks, it became possible to effectively support and manage users running Windows locally on the PC rather than shared from the server. The resulting reduction in traffic load made it possible to allow the physical server hardware to be located in the central data center. The resulting environment was comprised of PC desktops running Windows 3.1, Windows 95 or Windows NT locally, and accessing all corporate standard applications, shared data and personal data from centrally located servers.
Second, the migration to a centrally located server environment allowed the "specialization" of servers. While distributed among the buildings, each server had to support all functions required by that building. In a central environment, one group of servers could be dedicated to only provide applications, another group to only provide data storage space and printing services, and so on. This "specialization" allowed each server to be built and tuned toward its specific function, rather than all maintaining a generic design. Application servers typically don't require the large amount of drive space that a data storage server does. A database server can have file lock and file transaction settings tuned to the specific needs of the databases if supports. A data server might need multiple, load-balanced network connections to handle heavy file transfer load.
Finally, many of the standard NDS tree design concepts had to be carefully reexamined with the company's normal operating behavior in mind. With users frequently changing from one department to another, a design that segmented users by department would require a lot of administrative effort to keep up with the user moves. Since users frequently relocated from one building to another, the same administration headache would exist using a design based on physical office location. In addition, some departments in the company were spread over numerous cities and countries. Neither geography nor departmental structure supplied a very consistent NDS design basis. The solution involved a combination of both.
The Redesigned Tree
The top level organizational unit design separated the corporate headquarters into a single context, so that the frequent user move problem could be addressed without necessarily designing the entire corporate tree around that issue. The large number of sites in the North America were divided into containers based on functional department (manufacturing, research and development or sales). The numerous countries outside the United States were grouped based on geography (see Figure 3).
Figure 3: Top level organizational units in the redesigned NDS tree.
With the corporate headquarters occupying its own organizational unit, the user move problem could be addressed only within that one container. To avoid having to move user accounts with each user move, the HQ container design had to be as generic as possible, but still segment the 3700 users enough to be manageable. The resulting design placed each of the users within one of five generically named OUs, each containing a data server. Each user's home directory (personal, private storage space on the server) was located on the server within the user's respective OU. Departments were also divided among the five containers. The shared storage space for each department was located on the server within the assigned container (see Figure 4).
Figure 4: The HQ Organizational Unit was Subdivided into manageable containers.
Initially, the major corporate divisions were evenly distributed among the data servers based on number of users. Corresponding NDS Group objects were created in those containers. These Group objects granted file system rights to the appropriate shared data area on the data server (see Figure 5). Each User object was placed in the same container as the user's department, and each User object's home directory was created on that server.
Figure 5: While departments were assigned to specific servers, the server name remains generic. If the department merges or renames, no server name change is required.
Each data server contains two data areas: one for personal data and one for shared data. Each user maps a specific drive letter to their personal data area, defined as the home directory in NDS. In the case of CSC, each user maps drive U:\ to their personal data area and drive T:\ to the shared data area (see Figure 6).
Figure 6: Sample content of a data server at CSC.
The shared data area contains a division for departmental data and a division for public data which can be shared by all users on the server, regardless of department. Rights to the departmental data are granted to departmental NDS Group objects located in each OU.
Each of the user accounts located at the corporate headquarters was placed on one of five data servers, with a sixth data server reserved for database applications, and a seventh data server supporting only the IS department. All of the data servers were located in the central campus data center (see Figure 7).
Figure 7: The redesigned corporate headquarters (HQ) organizational unit.
By centrally locating all of the data servers, it is possible to utilize multiserver backup tape libraries rather than purchasing a backup unit for each server. A multiserver library typically requires less administration since the same tape library can serve several servers, and still provides the highest available backup speeds.
Administrative Relief
In summary, each user's account is placed in a container and assigned a home directory on the server located within that container. The user account is also assigned to the appropriate departmental group, which grants file system rights to the departmental shared data area on the same server. It sounds simple so far, but how does this design reduce the work involved with frequent user moves and department changes?
By assigning each department to a generic server and placing all servers in the central data center, it is no longer relevant where a user is physically located. An entire department can move from one building to another, and no account changes are required. The only network-related change that will occur during a departmental relocation is the assignment of a different IP address for the user's PC (which is automatic if the company uses a DHCP server).
The other administrative nightmare involved users changing departments. Under this generic tree design, there is no relationship required between the user's account context and the department that user resides in (although the initial distribution of users was arranged by department). If a user changes from one department to another, the user is simply added to the NDS Group object of the new department and removed from the Group object associated with the old department. If the new department is on a different data server, the user must also be added to a container group, which grants no file system rights but is referenced during the login script to determine where the user's shared data drive should be mapped.
For example, a user named John Smith is a member of the sales department. Upon employment, his NDS User object is placed in the HQ01.HQ.CSC container, is made a member of the Sales Group object, and is assigned a home directory on the server HQS10 (see Figure 8).
Figure 8: The User object for John Smith resides in the same container as his assigned department and data server.
After a while, Mr. Smith transfers to the Legal department. The Legal department's shared data area is located on server HQS20 located in the HQ02 container. In the old server environment, it would have been necessary to move the User object and all personal data to the new department's server, remove it from all related NDS groups in the old container, and assign it to the appropriate groups in the new container. In the new design, the administrator simply removes the user from the Sales group and adds him to the Legal Group. Since the Legal group is in a different context than John Smith's User object, he is added to the HQ02 container group to correctly map his T:\ drive to HQS20/VOL1:DATA. The container login script of HQ01 contains a short series of IF... THEN statements to map the T:\ drive to the appropriate server for any members of these outside container groups (see Figure 9).
Figure 9: The User object for John Smith does not move even when Mr. Smith transfers to a different department.
The entire administrative process consisted of removing the former data group membership, adding the new data group membership, and adding the container group membership, if required. Since the User object did not move, no server or NDS-based calendar or groupware products are impacted.
Easing Access to Applications
So far we have addressed how users access data storage, both personal and departmental. But users also require access to applications. In the old environment, each building or departmental server contained both data storage and applications. In the new design, the data and applications reside on different servers, allowing both types of server to be fine tuned to serve their respective service.
For CSC, which runs all applications from the server instead of installing them locally on each PC, the application server design is the most critical piece of the new design. Quite simply, if the users cannot run their applications, productivity ceases. The design had to provide high availability and reduce the maintenance effort required to distribute new applications and updates to existing applications, including any files updates or registry changes that are required on each of the user's PCS. In the process, CSC also hoped to reduce the amount of work required to test new applications. The final design implemented involves a combination of NDS design, ZENworks, and Novell Replication Services (NRS).
Application Server Design
To provide applications to all of the corporate headquarter users, CSC built three identical application servers. Each of these servers supports approximately 1250 users, supplying all of the applications licensed by the company. Until true load balancing and server clustering support is available, the user load is distributed by evenly distributing the six user containers among the three servers. In the event of a server outage, the login scripts for the user contexts can be adjusted to access one of the remaining two servers. Once server cluster technology is available, all three servers will act together as a single logical server, and a manual change will no longer be required if an outage occurs.
Since all end-users will run all applications from this new bank of application servers, it is important to define some common drive mappings to the application environment. While the drive letters mapped and the number of drive mappings required will vary for each company, the basic principle is the same. CSC settled on the arrangement shown in Figure 10.
Figure 10: Common drives mapped for all users.
The separation of "off-the-shelf" applications and internally-developed packages was made to better facilitate the testing of the internally-developed applications. It is important that developers and end-users be able to test application updates without changing the rest of their environment. Traditionally, testing a new application requires logging into a separate server built to emulate the normal operating environment. By segmenting the application development location, it is possible to change just that one drive mapping, leaving all other operating environment variables the same. By re-mapping drive P:\ to a development or test location, the developers can test the new application while still operating in the normal production environment (see Figure 11). Since no user has write access to the production software areas, there is no danger of affecting other users. An application menu icon can be provided to automatically remap the user's P:\ drive and any required search paths between the various environments.
Figure 11: Developers map only the in-house application drive to a development or test server, leaving all other drive mappings unchanged.
To simplify the process of changing between the various test, development, and production environments, ZENworks Application objects were created to automate the change. Each program development team requires rights to a different application testing and development area. The rights to each of those locations are assigned using NDS Group objects. These same application developer NDS groups were used to assign the appropriate test/development/ production environment change icons. Thus the groups created to grant rights to development and testing areas are also used to proved an automated way of changing between development, testing and production environments.
The naming convention used is as follows. Group names that begin with DEVELOPERS_ assign read access to each of the four development volumes. They also provide the environment change icons to allow programmers to easily change between environments. Group names that begin with DEVL_ assign write access to each of the specific application development directories on those non-production volumes.
The programmer is provided a group of color-coded menu icons to change between the different environments (green icon for production, yellow for testing, red for development, and so on). A colored icon appears in the programmer's desktop taskbar to identify which environment he or she is currently accessing.
Outside of the corporate headquarters, CSC has numerous sales, research and manufacturing locations. Since most of these locations have only one server, a "small server" design was created, which contains both user data and the application areas on one server.
Providing Applications to the End-Users
Providing the application servers is only a small part of the story. The real challenge is to make all of the applications installed on the application servers work for all users. To accomplish this task, CSC turned to Novell's ZENworks, which provides NDS-based application distribution, remote control, user profile support, and complete NT workstation support.
With well over 200 applications to support, CSC administrators identified three issues that had to be addressed for a central application server environment to work effectively:
A common desktop appearance is essential to be able to efficiently support the end-users or troubleshoot end-user problems.
The process of rolling out new applications or application updates had to be automated for the end-users, requiring a common distribution method that works for all end-user workstations.
The time it takes to thoroughly test new applications or updates had to be reduced.
ZENworks addresses each of these concerns. The primary function of ZENworks is to provide all users with a common application menu that can be managed completely within NDS. With ZENworks deployed, each users launches a standard menu application upon login. The items that appear are that menu are assigned using the NDS administration utilities.
To simplify the ZENworks menu, think of the applications menu utility as an NDS viewer for end-users. A user will see the groups and containers associated with his or her User object, along with the applications associated with those groups or containers. Our example user, John Smith, is a member of the Legal group and his User object is located in the HQ01 container. If the Legal Group object is associated with the Microsoft Office suite applications, John's application menu might look something like the one seen in Figure 12.
Sample applications menu showing the four MS Office application assigned to the Legal Group object, of which user JSMITH is a member.
Since many applications may be required by more than one department, CSC administrators chose not to use the department groups to provide applications. Instead, application-specific groups were created at the regional container level to support the users in all organizational units in that container. For example, John Smith received his "standard" applications from the container assignment of HQ01.HQ.CSC. To receive other applications, he must be made a member of the associated application group at the HQ.CSC level.
To roll out a new application, the system administrator must know all file changes and registry updates that are made to a PC during the normal installation of the application. Even though CSC runs all applications from the application server, there are still numerous file and registry changes to the individual PCS required to run each application. To accomplish these updates, the administrator uses ZENworks to install the application on a standard machine, capturing all of the changes made to the installation PC during the process.
ZENworks provides an excellent utility for the update capture process in the form of snAppShot. This is a utility that can capture a complete image of the PC before and after the new application is installed, and save those changes in a file format (.AOT), along with a copy of each of the updated files. The saved information can then be imported into an Application object to be distributed to the end-users. If a user should eventually make a change to his or her PC that impacts the new application, the user can verify the application and process the update again.
Locating Application Objects
The next problem facing the CSC system administrators was where to locate all of the new application objects. Since CSC owns a large number of applications and many have more than one executable file, there could be as many as 700-1000 Application objects required. These applications would have to be provided to users all around the world. Naturally, the administrators did not want to have to create multiple objects for the same application, but each site around the world would need a local replica copy of the OU containing these application objects to avoid having to access the objects over a WAN link.
After extensive discussions with Novell engineers, it was decided that the advantages of only having to create each application once outweighed the problems associated with having a single replica copy at all worldwide locations. In the future, it may be possible to automatically replicate and synchronize an OU container, which would still allow the administrators to only create the application objects once, but no longer require one OU replica to be placed at every corporate location.
The administrators at CSC created an Application object container at the top level of the NDS tree for all Application objects. A replica of this container was placed on at least one server in every CSC location, to provide users local access to the Application objects (see Figure 13).
Figure 13: The CSCAPPS container was created to hold all Applications objects to be accessed by the entire corporate user base.
Providing the Application objects is only half of the process. Each location must also maintain a copy of the application software volume. At one time, each of these servers had to be updated manually. When an application was rolled out, it had to be copied to each of the application servers worldwide—a process that sometimes could take several days. To streamline the installation process, CSC now relies on Novell Replication Services. By segmenting the applications into their own volumes, separate from user data, the application volumes should be identical on every server. Using NRS to maintain that synchronization, the administrators at CSC only need to install the application on one —master— server, and NRS distributes the update to all other servers (see Figure 14).
Figure 14: NRS replicates the application volumes from the master application server to all corporate servers worldwide.
We have now established that each site has a local copy of the Application objects, and that the software volumes on each site are updated nightly. We still have to associate the end users with the applications they should be allowed to run. CSC utilizes both container associations and group associations for this purpose. Standard business applications that everyone is required to use, such as word processing, spreadsheets, or presentation applications are assigned to containers, while limited access applications are provided via groups.
By assigning the standard applications to the containers, CSC avoids having to create extremely large groups, or numerous small groups to provide the same applications. Figure 15 outlines where the Application objects are associated to the end-users at the CSC corporate headquarters.
Figure 15: Application and data group are located at different levels of the tree.
Application groups are located at a higher level than the users, since users from all of the lower containers may require that application. The same concept is applied for all of the regional containers in the corporate tree, even at locations where the application directories reside on the same server as the user data (see Figure 16).
Figure 16: Application groups exist at each of the highest level OUs and provide applications for all users within the lower level contexts.
Conclusion
Using the NDS-aware tools currently available, CSC migrated from a decentralized, high-administration environment to a centralized, low- maintenance environment. Thanks to ZENworks and NRS, a small group of administrators is now able to provide and support applications to over 5000 users worldwide. By providing a common application menu and distribution, as well as synchronization of all application servers, the operating environment for all locations is identical, enabling a central help desk to support users form all over the world.
CSC was able to design the NDS tree around its own operations to reduce administration costs. By segmenting the headquarters into generic containers, administrators were able to eliminate the large amount of work previously required to handle departmental moves or changes. With NRS, the administrators only have to install applications updates once, rather than on all servers. Segmenting the in-house development applications allowed CSC to streamline the application development and testing process, reducing the time for application development. With the recent implementation of NDS for NT, it is now possible for users to authenticate to applications on NT servers via NDS, eliminating the administrative effort normally spent creating new users on each NT server.
By carefully planning the NDS tree design around the company's normal behavior, and by taking advantage of the host of tools and applications that use the existing NDS database, CSC was able to design an extremely efficient server environment. In addition, CSC is already prepared to take full advantage of future high availability technologies as they are released.
* Originally published in Novell AppNotes
Disclaimer
The origin of this information may be internal or external to Novell. While Novell makes all reasonable efforts to verify this information, Novell does not make explicit or implied claims to its validity.