General System Configuration

There are several basic principles of GroupWise system design you should try to adhere to. If you cannot, you should at least understand why the principle is important so that you can knowledgeably work around the problems that your nonconformity introduces.

Email, Calendaring, and Document Management Are Mission-Critical

The first principle is a simple one. The system you are going to build (or you inherited) is going to be critical to the day-to-day work of your users. If GroupWise is down, your users will stop getting work done. If GroupWise performance is bad, your users will complain and will be less productive. If data is lost from the GroupWise system, that data will have to be re-created by users. These productivity hits will ultimately affect your bottom line. Your business will lose money when GroupWise is not running optimally.

The application of this principle is equally simple. If the system is mission-critical, if business cannot take place without it, you need to be prepared to spend money on the necessary infrastructure to support the system. This includes a solid LAN and/or WAN, a good Internet connection, and modern network file server hardware. That old NetWare 4.11 server running on the P100 box will run GroupWise, but not nearly as well as a NetWare 6.x server with a XEON or Pentium 4 processor.

Mesh Message Transfer on the LAN

Message transfer agents (MTAs) can communicate via TCP/IP as they transfer messages between post offices. If you have multiple GroupWise domains on your LAN, you should probably avoid a star or hub configuration for network links. Allow every domain on the LAN to connect directly to every other domain. This will prevent bottlenecks, accelerate message transfer, and reduce the amount of network traffic.

Match WAN Message Transfer to WAN Topology

If you have more than one facility, or your offices are connected via wide area network technology (T2 or slower links), make sure that your MTA links match your WAN topology. This means that GroupWise domains should exist at the borders between the LANs. Use indirect connections between domains on one LAN and domains on another, allowing only a single pair of domains to communicate across the WAN. This will reduce network traffic on the WAN and prevent certain kinds of MTA problems, including TCP timeout errors.

Treat the Internet as part of the WAN. After all, your users will be swapping email with Internet users with great frequency. You should dedicate a domain to this WAN link.

Applying System Configuration Principles in the Real World

This section looks at how the principles from the preceding sections can be put into practice by examining a hypothetical organization and designing a GroupWise system for that organization according to the outlined principles.

The Scenario

All-American Widgets has corporate offices in Newark, Detroit, and Salt Lake City. They have regional sales offices in Atlanta and San Francisco. They have more than 11,000 employees.

In Newark, there are 2,500 employees, most of whom are in the sales, marketing, and engineering departments. These users are all connected to a 100MB fiber network.

In Detroit, there are 7,200 employees, all of whom are in the manufacturing division. Only about 1,000 of these users (the management team and a few stray engineers) have computers, but there are another 500 kiosks that are used by the employees on the plant floor.

There are 1,400 employees in Salt Lake City, in the service and support division. All 1,400 of them have computers, and they have a LAN similar to the one in New Jersey.

Finally, there are 15 employees in Atlanta and another 20 in San Francisco. These salespeople all have mobile computers, and there's a solid network in their home office building. They do not, however, have a network administrator.

The Newark System

It should be pretty simple to arrive at a good design for the Newark portion of the system. All-American Widgets is not going to use caching mode on the GroupWise client in a broad manner. Newark has 2,500 users, so you should have five post offices, one for every 500 users. Each post office gets its own file server.

Newark will have three domains. One domain will own the five post offices. An auxiliary domain will own the GWIA and will handle communications with the other remote sites. The third domain will be an auxiliary domain for the WebAccess gateway and Web server. So Newark gets eight file servers, five post offices, three domains, a GWIA, and a WebAccess gateway.

The Detroit System

Detroit is a little more complex. Detroit has a much larger user base, but most of the users aren't regular computer users. The Detroit site creates three post offices and two domains. One domain will have all the post offices below it. Two post offices will be for the 1,000 management folk. The third post office will have 6,200 mailboxes on it. We are breaking a rule here, but for good reason. These folks won't be using their mailboxes much. There are only 500 kiosks from which they can connect; so performance won't be a problem, and there will not be that much mail for them.

To simplify things, all the kiosks run WebAccess. That way, users don't have to worry about logging in and out of Windows to ensure that GroupWise Registry settings are correct.

Detroit will need two domains. One domain will own three post offices. The second domain will be an auxiliary domain to house WebAccess. So Detroit gets five file servers; three post offices; two domains, one of which will house only the GroupWise WebAccess gateway; and the Web server.

The Salt Lake City System

Salt Lake City is going to look a lot like Newark, only smaller. The 1,400 users can be squeezed onto just two post offices in a single domain. Salt Lake City has its own Internet connection, and the repair technicians there will be sending a lot of Internet email to customers they are supporting. A separate domain will handle WAN message transfer and will host the GWIA. Another auxiliary domain and server will host WebAccess and the Web server.

From the discussion on Internet addressing in Chapter 16, "Internet Addressing," you can probably guess that All-American Widgets is going to use overrides here. The Salt Lake City users will get a different Internet domain name (probably user@support.allamericanwidgets.com) and will use the local GWIA as their default GWIA.

The Remote Sales Offices

There are a couple of good options for handling smaller offices. First, you can place a post office in each location but place the domain in the corporate office. This would give these users great client/server performance when they are in the office, but it would require that somebody at least know how to reboot the server and load the remote console software so that it can be maintained from the corporate office.

A second solution is to put the salespeople's mailboxes on post offices in Salt Lake City, Detroit, and/or Newark. These users would use the GroupWise client in caching mode all the time, which won't be an inconvenience, because caching mode is optimal for users who are also on the road. This second solution is more ideal.

System Administration

With corporate headquarters in Newark, it makes sense that system administration is done from there. On a system of this size, you probably want to have a primary domain that does not own post offices. This means adding another server, and another domain, to the Newark site. You do not necessarily have to dedicate a server just for the primary domain, but it does help that the primary domain functions primarily as the GroupWise Directory Services relay location. In a GroupWise system, all updates to the GroupWise directory must replicate through the primary domain. There is no way to offload or load-balance the primary domain's job. Because of this, it's best that the primary domain have no other functions, such as servicing a post office, or a gateway, or even links between domains. In this perfect-world scenario, the primary domain will have mesh links to all other Newark domains, and nothing else to do but replicate GroupWise Directory Services administrative messages. It will connect indirectly to domains in Detroit and Salt Lake City via the routing domain that owns the GWIA.

Now you see why it's best to plan ahead. When you create a GroupWise system, the first thing you do is create the primary domain. But you cannot know where the primary domain is going until after you have the rest of the system plotted out.

Planning Your GroupWise System

Now you know the principles involved and you've looked at how they applied to a fairly large (hypothetical) organization. You are ready to begin planning your system.

Here are the common steps to use when planning your GroupWise system:

First, identify how many users you are going to be providing services for. Does everyone have a computer? Will everyone get an account, regardless of whether they have a computer?

Divide your user base into groups, based on your network topology first, and then on their departmental or workgroup affiliations. If you have a department with users in two different remote sites, those users probably get grouped separately.

Take these groups of users and divide them into post offices of between 400 and 2,000 users. If you plan to put anywhere between 1,000 and 2,000 users on a single post office, plan to spend top dollar on file server hardware, and be prepared for backups to take a while. Also, if you plan on putting more than 1,000 users on a post office, it is highly recommended that the users in this post office run in cache mode. This is a must in order to support this number of users in a single post office.

You should now have a list of post offices, and a rough list of which users belong to them. You are ready to begin assigning domains. On LANs, one domain can serve at least 10 post offices. For systems of more than 2,500 users, though, I recommend at least three domains: one primary domain, one post office domain, and one gateway domain.

Determine where your LANs interface with WANs. Plan for a routing domain at each of these locations.

Begin drawing the links, and compare this to a map of your networks. Make sure that it makes sense. Remember, your network links should follow your WAN topology. If a packet moving from site A to site C must be transferred across a T1 line to site B, and then across a 56Kbps line to Site C, you will want to have three domains involved, one at each site.

Plan your gateways and assign them to domains accordingly. The most important of these is the GWIA. Make sure that you know which domain it is going to belong to, and where it is going to reside. Know what the foreign ID is (your Internet domain name).

The WebAccess application should be running on a server that is dedicated to just run the Web server and the WebAccess application. Multiple WebAccess agents should be running throughout your system. Those agents can be running on the same servers as the post offices. If WebAccess agents that are running in protected memory abend, no harm is done to the server.

Now begin assigning names. Remember the discussion on naming conventions in Chapter 16. Post office and domain names should have numerical characters in them to unquestionably distinguish them from usernames. Try to keep names of domains and post offices short. This will make things simpler to manage.

10.

Draw the system, complete with names, links, and user groups. Sleep on it. Run it by your boss. If you are the boss, run it by your spouse, significant other, fishing buddies, evil minions, or trusted lieutenants. Invite commentary and criticism. Listen.

11.

Develop a standard for ports. This should include message transfer ports (MTP) for message transfer agents (MTAs) and post office agents (POAs), as well as client/server ports for POAs. Also include live remote ports for MTAs and plan for HTTP ports for all agents. An example of this is to have all client/server ports end in 7, such as 1667, 1677, 1687, and so on. If you ever have two post offices on the same server, you already know which client/server ports they will be using. HTTP ports could end in 1, for example, 1671 or 1681. An example of MTA MTP ports might be that they all end in 0, as in 7100, 7110, 7120, and so on. Make all POA MTP ports end in 1, as in 1661, 1671, 1681, and so on. It is nice to have a standard document in relation to all the GroupWise ports that are involved in a GroupWise system. Table 19.1 represents this type of portnumbering scheme.

Table 19.1. Sample Port Number Scheme for GroupWise Agents
AGENT	MTP PORT	HTTP PORT	C/S PORT	POP PORT	IMAP PORT	CAP PORT	MTA LIVE REMOTE
MTA	7100, 7200	7101, 7201					7107, 7207
POA	1670, 1680	1671, 1681	1677, 1687		143	1026
WebAccess			7211, 7311				7205, 7305
GWIA		9850		110/995	143/993

Now that you have the basics of your GroupWise system design down, there are some other issues you must deal with, particularly issues that affect data management.

Chapter 25, "Configuring a Spam/Junk Mail Control System," discusses configuring GroupWise for Spam control. You must have a Spam solution in place.