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-CriticalThe 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 LANMessage 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 TopologyIf 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 WorldThis 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 ScenarioAll-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 SystemIt 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 SystemDetroit 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 SystemSalt 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 OfficesThere 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 AdministrationWith 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 SystemNow 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:
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. |