GroupWise 6 Deployment Guide - Appendix
Novell Cool Solutions: Feature
Digg This -
Posted: 29 Nov 2001
Table of Contents
Appendix: General Configuration Guidelines
If you are installing GroupWise for the first time, or if your existing GroupWise configuration is not meeting system demands, then review the following section for best practices information on Directory and system configuration.
General Principles for eDirectory Configuration
Because GroupWise 6 is built on NDS, full optimization begins with the tree. Efficient design and intelligent placement of objects within NDS enable you to get the most out of GroupWise.
The first objective in eDirectory configuration is to simplify administration. The Directory can make system administration easier and more efficient if you strategically use roles and containers to your advantage.
One way to leverage roles to your advantage is to create organizational roles for GroupWise administrators and grant administrative rights to that role. By granting all administrator rights to the role, you don't have to worry about managing rights at the individual User object level.
In managing users and network resources, the best way to leverage containers is using a containment model rather than organizational association. For example, if you have offices in New York and Los Angeles, do not create organizational containers, such as Marketing or Sales, and include users from every location in these containers (see the following diagram). This type of configuration creates problems because users and administrators in remote locations have long wait times as they attempt to log in or perform administration functions, or you consume tremendous amounts of bandwidth replicating the tree over the remote connection.
A better configuration is to first create containers for each geographical location and then create sub-containers based on the organizational units within each location, as illustrated below. You can then partition off the remote containers and simply replicate that portion of the tree to the remote server. This enables users and administrators to have local access (and consequently, faster access) to their associated NDS objects while minimizing the amount of information replicated across the remote connection. This model also facilitates ZENWorks distribution and it is more intuitive for new administrators.
Another point to consider in eDirectory configuration is the placement of GroupWise objects. In an attempt to facilitate GroupWise administration, many organizations are tempted to create a central GroupWise container and locate all GroupWise objects in that container as follows.
While this model does indeed facilitate system administration, it also degrades system performance. Because the system's User objects are still located throughout the tree, GroupWise has to walk the tree to locate any given post office's associated User objects. This problem is exacerbated if the system extends over a WAN.
Consequently, GroupWise containers should be one level above or in the same container as the users they service. Post office objects, in particular, should be in the same container as the users and resources they service to facilitate user authentication (see the following graphic). Along these same lines, domains, post offices, libraries, and distribution lists should be in the same partition as their users to facilitate replication.
A final point to consider in eDirectory configuration is rights management. To simplify trustee assignments, you should allow the GroupWise Snap-in to automatically grant NDS rights and enable NDS synchronization for each MTA. If sufficient NDS rights are granted, the MTA automatically synchronizes the domain data store with NDS. The MTA synch option ensures all changes made in NDS, particularly those changes implemented through NetWare Administrator or WebAdmin, are synced to GroupWise.
General Principles for System Configuration
GroupWise can be used in a LAN or WAN environment, but each environment has its own unique needs. The following sections identify general configuration principles specific to LAN and WAN environments.
When planning a LAN-based GroupWise system, following a few general design principles will help you cut administration costs and enhance system collaboration.
First and foremost, ensure client performance. It doesn't matter what system architecture you have in place, if you have poor client performance, your users will perceive the system as a failure. The central factor in client performance is the Post Office Agent (POA). While implementation of Caching mode enables the POA to outperform previous versions, overall POA performance is still very much processor-based. CPU speed and cache do more to enhance POA performance than RAM, network speed, or disk I/O speed.
A second point to keep in mind when designing a LAN-based GroupWise system is that domains are for routing. Domains should not mirror the Directory nor should they be used as organizational containers.
Rather, your primary consideration in creating a domain is message transfer points; that is, domains should mirror your system's physical links.
To optimize message transmission, all MTA's should be meshed; that is, every MTA should have a direct connection to every other MTA. The following example shows a non-meshed GroupWise system. This configuration is highly vulnerable to system failure because if one server goes down, service is interrupted for the entire messaging system.
The best configuration in a LAN environment is a meshed system. In the following example, every domain has a link to every other domain. If a server goes down, only the local post office is affected.
Another principle to follow in designing GroupWise systems on a LAN is to build for access. Wireless, WebAccess, GWIA, and Async services should be geographically as close to the user's post office as possible.
Important! For optimal system reliability, it is recommended that the WebAccess Agent be on a separate server than the user's post office.
The final principle to keep in mind when implementing GroupWise 6 on a LAN, is to support remote users with reliable, live connections. This means giving remote users the ability to connect directly to an MTA or POA in Online or Caching mode. Online and Caching mode provide faster service for remote users because they are client/server connections; client requests are directed to the POA hosting the user's mailbox rather than being forwarded as a batch request.
To provide Online or Caching mode connections for remote users, you must have an MTA outside the firewall or you must set up proxy addresses (via a firewall proxy server) for your post offices. For more information on configuring Internet Proxy Services, see "Internet Proxy Access" on page 25.
When designing GroupWise systems in WAN environments, the most important issue is to configure for stability. While LAN links should be meshed, WAN links should follow the WAN topology.
The following configuration illustrates a WAN with meshed links between LA and Houston. Meshing the connection between LA and Houston does not provide the advantages associated with meshing LAN links because the LA and Houston connection must still go through relay servers. Consequently, if one of the relay servers goes down, LA and Houston will not able to send messages back and forth, regardless of the "direct" link.
Another disadvantage of directly linking WAN sites is that the WAN connections are too long. Due to the distance between WAN sites, a server may time out while it is waiting for a message to transfer. You also run a greater risk of losing packets over long distance connections.
The best way to configure WAN connections is to simply use your existing links as illustrated below. By using the system's existing links, messages are transferred across shorter, more reliable distances and you don't spend money on a "direct" connection that doesn't actually provide any measure of fault protections.
Another principle to keep in mind when designing GroupWise systems in WAN environments is that there should only be one MTA and domain per server and, if necessary, create separate routing domains for GWIA, Async, and WebAccess.
Once you have established your high-level structure, apply the principles outlined for LAN environments to design your intra-site systems.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com