| Most of what goes on in a GroupWise system also goes on at the post office. If you configure your GroupWise post offices correctly, your users will be far more satisfied with GroupWise. Email Policies Email policies might not seem technical, but they affect how you are going to configure elements of your post office. Your organization should have an email policy that establishes rules such as the following: How long messages can be retained Whether users have disk-space limits on their mailboxes The size of attachments that users can send within your organization and on the Internet Whether users can archive their mail messages Whether users can use POP3, IMAP4, or NNTP Whether users can share address books or folders with users outside their post office Whether users can send messages via S/MIME or PGP Whether there will be a standard disclaimer signature on all emails
By establishing an email policy, the GroupWise administrator can do the following: Set GroupWise client options to mirror email policies Do a better job of projecting the need for hardware resources Design the GroupWise GWIA to disallow huge-bandwidth-consuming attachments going on the Internet Set size restrictions on internal GroupWise links if needed Run reports to see who is hogging disk space, and encourage the abusers to delete certain sent- or received-mail items Automatically encourage users to curtail retaining too many messages
Tip Even if your organization will allow users to retain messages for a long time, we strongly advise that your organization create a large-file-attachment policy. You can control attachment size, right down to the post office level. So, for example, you might decide that users cannot send files over 25MB. Furthermore, you could have a policy that requires that all files over 10MB be saved or deleted within seven days of receipt. To control attachment sizes, go into ConsoleOne, highlight a domain or post office, and choose Tools, GroupWise Utilities, Client Options, Send, Disk Space Mgmt. You can also control attachment size through Link Configuration. The difference in these two approaches is in how the user is notified of the problem. When you use the client option, users get a notice when they click Send that the attachment is too large. When you're using link configuration, the user can send the message, but as soon as the message hits an agent (POA or MTA) that has a link configuration size limit imposed, this agent sends back an undeliverable message to the sender, letting the sender know that the message could not be sent because of the size limit.
Email policies have an important effect on performance and server design. A great resource in constructing an official email policy is the "Email Policy Configuration & Deployment Guide." At the time this book was written, this guide was available at http://www.messagingarchitects.com/epolicy. Post Office Design This section offers a few tips to consider when designing post offices for your GroupWise system. When and Where to Create a Post Office Every GroupWise post office has a certain amount of cost associated with its maintenance. A GroupWise post office will generally reside on a server by itself; that server should have a high-quality disk subsystem and be made by a reputable hardware manufacturer. A backup solution should also be implemented for this server. It is best to create GroupWise post offices only when it is really warranted. In the past, GroupWise administrators often had to make small post offices to service regional sites. With the advancements of the GroupWise WebAccess, and the GroupWise client in caching mode, it's feasible to move users from small regional post offices into centralized post offices. Where to Place Post Offices in eDirectory When a user logs into GroupWise and if the NetWare client is loaded, GroupWise will look in eDirectory to discover information about the user's post office and POA. Because of this, it is best to put the GroupWise post office object in proximity to the users associated with the post office. If the users associated with a post office are in multiple eDirectory contexts, place their post office in an eDirectory Organizational Unit (OU) that is in the same replica as the majority of the users on the post office. Users should have eDirectory browse, read, and compare rights to the post office object, as well as the POA associated with the post office. Note If you have LDAP authentication enabled, the Novell client is not used to query eDirectory, so these rules no longer apply. LDAP authentication effectively gives you more flexibility in designing the placement of your GroupWise post office objects in the eDirectory tree.
How Many Users to Place in a Post Office If you have a good server and a fast network, GroupWise can scale nicely. The online client/server mode of the GroupWise client can be taxing on the server when a post office has several power GroupWise users. A GroupWise post office can easily sustain thousands of mailboxes; it's the number of users logged in at the same time that scale back the practical numbers of users on a post office. Take a close look at whether it is feasible to move to a distributed processing model; by using the GroupWise client in caching mode, the GroupWise client is far less chatty and taxing on the GroupWise POA. The downside to caching mode is that users need enough disk space to accommodate a complete copy of the items in their master mailboxes on the server. Also, caching mode is less attractive in environments where users don't have their own workstation, so-called "roaming users" in environments with flexible work spaces, because a copy of the mailbox will be stored on the local hard drive. You need to consider other factors when determining the number of users per server. For example, does your organization have an email retention/expiration policy? If not, the message store is bound to grow and grow. Your servers might not have enough disk space to accommodate a message store for 1,000 users that just keeps growing. GroupWise is very efficient on disk space, but let's face it, email is the layman's FTP utility. When considering post offices, think about the people who will be on the post office and what their job functions are. Marketing departments are likely to have lots of presentation files. Engineering might have CAD files. Therefore, you might want to put only 250 of these kinds of employees on a post office. Production people might not deal with attachments at all, so perhaps you could put 750 of them on a single post office. Multiple Post Offices on a Server This is a subject that somehow stirs strong emotions among GroupWise specialists. GroupWise is flexible enough to allow more than one GroupWise post office to reside on a server. Many customers have experienced plenty of success with more than one post office on a server. Others have not had success using this model. Success or failure often comes down to usage patterns. If you have two 700-user post offices full of power GroupWise users on one server in client/server mode, you might have performance problems. When two GroupWise POAs are loaded on a server, they are not aware of each other, and they have a tendency to hog the CPU if they feel they must do so. The result is that, at certain times, one of the POAs will not have the CPU time that it might need to adequately service users. The GroupWise product suite is getting even more robust, with features such as document management and increased third-party integration. Because of this, users are more and more likely to be using GroupWise. This is goodproductivity is going up. Just make sure that having two post offices on a server is not degrading the potential for good productivity. In general, based on the factors discussed previously, we do not recommend having more than one Post Office on a single server. Configuring the POA Object for Optimum Performance and Functionality This section discusses some settings and their relationship to a successful POA configuration. If a setting has no bearing on regular performance or function in the GroupWise system, it is not mentioned. Agent Settings Property Page The Agents Settings property page is shown in Figure 19.1. The Agent Settings property page is where you fine-tune the POA. Figure 19.1. The POA Agent Settings property page allows you to fine-tune the POA 
Following are the parameters on the Agent Settings property page: Message File Processing: This should be set to All. In some cases, a GroupWise POA will be created for QuickFinder indexing. That POA would have message file processing set to Off. Don't set this to Low or High; if you do so, the POA will stop processing items in some of its queues. Message Handler Threads: Message handler threads should be set to about half the value of the TCP handler threads. If you have 16 TCP handler threads, the message handler threads should be set to 8. Enable TCP/IP (for Client/Server): Yep, you want this enabled for sure. TCP Handler Threads: This is a simple formula, as follows: A = Number of users B = The number of TCP handler threads that the POA should have allocated. The minimum value for B, though, should not go below six. B = A/25 So if a post office has 400 users, the POA should be configured with 16 TCP handler threads. If a post office has 50 users, the post office should have six threads, not two. The POA should not be configured with fewer than six TCP handler threads. If your post office supports a significant number of users of a WAN link, even in Caching mode, you might want to monitor your TCP handler threads. You might need to increase the TCP handler threads to accommodate TCP connections that persist for a longer period. Max Physical Connections: Allocate two physical connections for each member of the post office. This is generally plenty. Setting this value to four per user is not going to cause any problems either. Just don't set it to some astronomical number, which chews up more memory than necessary. Max App Connections: Allocate at least four application connections for each member of the post office. More is fine, but much more is not necessary. This is one of those situations in which not enough is bad, more than enough is fine, and much more than enough is not needed or helpful. Enable Caching: Caching mode can significantly improve POA performance. This setting allows the POA to cache various databases in server memory. The NGWGUARD.DB file is almost always a database that gets cached. The only time you should disable caching here is if your server is very unstable. Don't confuse this setting with the GroupWise client in Cache mode. This setting has nothing to do with whether users can use the client in cache mode. CPU Utilization: We personally like to set this to 90% to 95%. If the server crosses the CPU utilization threshold, it will not allocate more threads until the POA is below the threshold. If your POA is on a NetWare server, 95% is generally fine. The beauty of NetWare is that it uses the CPU very efficiently and can regularly spike in the 90s without users feeling any effect. Because GroupWise is mission-critical, it should get priority processinggreater than the default 85%. Having the value at 85% will probably be fine also, but it likely should be the bottom threshold. We don't generally recommend going below 85%. Delay Time: The delay time correlates with the CPU utilization option. If the CPU utilization threshold has been exceeded, the delay time is the amount of the time the POA's NLM will wait before trying to get another thread, if needed. The default of 100 milliseconds is generally more than enough. Max Thread Usage for Priming and Moves: The default of 20 is pretty low. We personally like to set this to 50%. Enable IMAP: Your Outlook and other IMAP client users can have a client/server-based connection with a GroupWise POA. We would recommend that if you allow your MS Outlook on users' desktops, you have a good virus-protection solution in place. A post officebased virus-scanning solution such as GWAVA (www.gwava.com) is a cost-effective solution to combat Microsoft Outlookbased viruses. Max IMAP Threads: The default is set at 50. That might seem high, and it is if you just have a few IMAP users. But if you have several users, 50 or more will be necessary. IMAP connections have more overhead because they are standards based, rather than proprietary. So the POA must accommodate inefficiencies in the IMAP protocol. Enable SOAP: Enable SOAP only if you have a third-party application that requires this protocol. Indicate the least number of default SOAP threads you may need, because SOAP threads can be resource intensive. Enable SNMP: If you are not using SNMP monitoring, turn off this option. It saves a little overhead. The GroupWise monitor piece is an SNMP monitoring device, so if you intend to use GroupWise monitor, do not turn this off. HTTP User Name and Password: You definitely want to set an HTTP username for your GroupWise POA's HTTP monitoring feature. There are powerful actions you can take from the POA's HTTP monitoring screen; you want to make sure that HTTP monitoring is secured.
Network Address Property Page Not all of these settings necessarily affect the performance of the POA, but they do enable features that are important when monitoring your POA and extending its capabilities: TCP/IP Address: The TCP/IP address can be an IP address or a DNS name. The advantage to a DNS name is that if at some time the IP address changes for a post office, the change simply needs to be made in the DNS. This change is transparent to the users. Proxy Server Address: You can define a public IP address as the proxy IP address for the post office. This proxy server address is not bound to the server where the POA is; it is bound to a "proxy server" that's accessible from the Internet. The proxy server performs network address translation (NAT) services from the public IP address and port to the internal IP address and port of the POA. This enables your remote and cache users to connect to the POA using the full GroupWise client from anywhere they have an Internet connection. They do not need to VPN in to your network first. Bind Exclusively to TCP/IP Address: Normally your POA will bind to all the IP numbers on your server and thus will offer its services on all of these IP addresses, even if you specified a (default) IP address in the field mentioned previously. In some cases, for example on clusters, this is not to be desired, and you might enable this option to make sure that the POA binds only to the IP number specified previously. This option was configurable only with earlier versions through the startup file. Message Transfer Port: Domain MTA to post office POA communication can be configured in two manners: using UNC or via TCP/IP. The UNC method is one in which the MTA moves files to the WPCSOUT queues off of a post office. Also, in UNC mode, the MTA fetches messages from a post office using a polling cycle. The POA looks in the WPCSOUT queues periodically to determine whether anything needs to be processed. The polling process is far less efficient, because the MTA and the POA are not really talking to each other; they are just dropping things off in queues. Each agent knows that the other will look at the queues eventually. TCP/IP communication between the MTA and the POA is optimal. When a POA has something for the MTA, it hands it right to the MTA, and the MTA acts on the item immediately. It's the same when the MTA needs to give something to the POA. Quick handoffs are particularly helpful in time-sensitive functions. For example, when a user does a busy search on the calendar of a user on another post office, the busy search must pass from the POA to the MTA. Because the POA speaks directly to the MTA rather than placing the busy search request in a queue, the end user has a far more interactive experience with the busy search. Even if a domain and a post office are on the same server, it is still optimal to configure the post office and domain to communicate via TCP/IP. The message transfer port (MTP) is the IP port that the POA listens on for messages from the parent MTA of the post office. The MTP port should be different from the HTTP port and the client/server port. HTTP Port: The HTTP port on the POA should be filled in. This enables the POA to be monitored from a Web browser. Some information is available from the HTTP monitoring of the POA that is not available from the POA's console screen, such as the names of users who are logged into the POA or the version of GroupWise client they are using. Even if you have the /HTTP switches in the startup file of the POA, you still should fill in the HTTP port here. The GroupWise Monitor program discovers the HTTP port of the POA from this field. HTTP SSL: If you intend to monitor your POA via a Web browser across the Internet, you will want to use this option for security reasons. Enabling SSL is covered in Chapter 27, "Securing Your GroupWise System via SSL." Local Intranet Client/Server Port: It's important that the POA is listening on a unique client/server port. The port used doesn't matter as long as it's unique. The default port is 1677. Internet Proxy Client/Server Port: This port allows you to use the same proxy server address for all of your POAs in your GroupWise system. This is helpful because the proxy server address should be a public IP address. This Internet proxy client/server port can then be used to uniquely identify each post office in your system, which facilitates all user access to their post office through a single public IP address (the proxy server address). If your proxy server address is the same for all post offices, it is important that each POA have a unique Internet proxy client/server port defined. It is also important to note here that there is some additional configuration to make the proxy server address and Internet proxy client/server port to function. You must bind the proxy server address to a Layer 4 switch or some device that supports address translation (NAT), and possibly port address translation (PAT). This device must be accessible from the Internet. The device is then configured to translate the data that hits the proxy server address on a particular port (the Internet proxy client/server port) into the internal address and port of the correct POA. IMAP Port: Most likely you will want to keep the default port (143). IMAP clients look for an IMAP server connection on port 143 by default. SOAP Port: This port will be used by third-party solutions such as the Nexic Synchronis Palm and PocketPC client (www.nexic.com) and Teamware Mobile (www.teamware.com), as well as by the Evolution connector for GroupWise. Most of these services look for a SOAP connection on port 7191 by default.
After you have configured your POA's ports, be judicious about making any changes. The changes are likely to affect users who connect to this post office. QuickFinder Property Page Let's look at how QuickFinder Indexing can affect the performance of your POA: Enabled QuickFinder Indexing: Make sure that this option is checked. QuickFinder indexing is critical to GroupWise performance. If you turn off this feature, your post office will slowly experience more and more utilization, because the POA will have to perform real-time QuickFinder indexing operations whenever users use the Find feature in GroupWise. Start QuickFinder Indexing HoursMinutes: This value should be set to however many hours after midnight you want the QuickFinder indexing to occur. In most cases you want this process to happen after-hours, because it can be a CPU-intensive process. Setting the value to 22 hours and 0 minutes causes QuickFinder indexing to start at 10 p.m. each night. Setting the value to 0 hours and 30 minutes causes QuickFinder indexing to start at 12:30 in the morning (30 minutes after midnight). We recommend making sure that QuickFinder indexing does not happen during backups. QuickFinder Interval: In most customer environments, the QuickFinder indexing should happen once every 24 hours and 0 minutes. We recommend you keep this default unless you have a legitimate reason to change it.
It's important that you have QuickFinder tuned, and always enabled. Maintenance Property Page Following is a discussion of the settings on the Maintenance Property Page: Enable Automatic Database Recovery: If the POA discovers damage in a message-store database, having this option enabled allows the POA to kick off an immediate GWCHECK on the database. Maintenance Handler Threads: The default is 4, and the most you can specify is 8. You can get yourself into real trouble if you set the maintenance handler threads to 8 and then issue a post officewide mailbox/library maintenance in the middle of the day. We did this once, and the maintenance handler threads were in a tug-of-war with the message handler threads to get access to the message store databases on the post office. So it's probably best to set this value to 4. If you then need more power for mailbox/library maintenance after-hours, crank this up to 8. You do not have to restart the POA when you change this setting; the POA will dynamically reread this setting. This gives you easy control over this feature. Perform User Upkeep: This should definitely be enabled. The Perform User Upkeep option performs seven tasks: Advances uncompleted tasks to the next day Deletes expired items from users' mailboxes Deletes mail, appointments, tasks, and notes that are older than what's defined in the "client options" section Empties the trash based on client cleanup options Synchronizes users' frequent-contacts books with the system's address book Cleans address book indexes Expires references from the document folder
Note When the POA actually executes the Perform User Upkeep code, the upkeep happens in two passes. In the first pass, the POA advances uncompleted tasks and synchronizes users' frequent-contacts books with the system address book. In the second pass, the POA deletes expired items from users' mailboxes, cleans address book indexes, and expires invalid references from the document folder (if you are using GroupWise document management).
Start User Upkeep: Start User Upkeep should always be set to sometime after midnight to be effective. The Start User Upkeep option determines when the user-upkeep tasks occur. If you enable user upkeep to occur before midnight, it will not advance task items to the next day. If task items aren't advanced to the next day, the client's load-up time takes longer when the users log in the next day. As mentioned earlier, make sure that User Upkeep does not run during your backup cycle, but rather either before or after the backup. Generate Address Book for Remote: You should definitely enable this setting. A better description for this is "Generate Address Book for Caching and Remote." If you have caching or remote mode users, you definitely want to enable this setting. This process creates a file called WPROF50.DB in the post office\WPCSOUT\OFS directory. This file is then used when users request the system address book while in caching or remote mode. If the WPROF50.DB file is more than 24 hours old (which happens only if you do not have this setting checked), the POA will create it again on-the-fly. Generating this file is a CPU-intensive task, so it is best to create the file after-hours. Start Address Book Generation: Set this option to some time after business hours. Disk Check Interval: Enable this to occur every five minutes. The Disk Check Interval value corresponds with any disk check event that you have defined in scheduled events on the POA. The POA looks at the scheduled disk check events. The POA takes the appropriate action specified in the disk check events, if the disk space threshold has been crossed. Disk Check Delay: Leave this at two hours. If the POA has discovered that disk space is low, it won't take the actions in the disk check event until two hours have passed. This gives you a chance to respond to the low-disk-space problem.
It is imperative that you make sure that Perform User Upkeep is always enabled. Log Settings Property Page The settings available on the Log Settings property page include the following: Log File Path: Just keep this value blank. The POA will create the files in the post office\WPCSOUT\OFS directory. Logging Level: The Verbose setting is tremendously helpful when troubleshooting. Max Log File Age: The default of seven days is generally sufficient. Max Log Disk Space: The default of 65MB might not be enough. Crank this up as high as it will go if you have the space. This setting will go up to 1GB. You can then generally go back into the logs for several days to find information. The POA logs information such as what users deleted because of the junk-mail feature. Having this information for a few days is good. If someone mentions that he or she didn't get a message from someone on the Internet, you can search the logs of the POA and determine whether the message was junked by the recipient 's junk-mail rules.
Note The Max Log File Age and the Max Log Disk Space settings work together. If your log files can grow to 50MB but you are storing only seven days' worth of logs, this means that even if your logs are taking up only 20MB, they will be deleted after the seven days. Conversely, if the log disk space is reached but logs are only five days old, the oldest log files will be deleted to make room for new log files. Also note that the Max Log Disk Space is cumulative of all the post office logs; it does not reflect how large one log file is. The POA cycles into the next POA log file when it reaches 1MB, or at midnight.
Log settings don't always have a direct impact on performance, but having correct log settings is very important for troubleshooting purposes. Scheduled Events Property Page Chapter 17, "Maintaining the GroupWise System," explains scheduled events and how to construct them. You definitely want to enable scheduled events for mailbox/library maintenance events. Chapter 17 does not discuss disk-space scheduled events though; that information is covered here instead. If you left your Disk Check interval set at five minutes back on the Maintenance property page, a disk check event is spawned every five minutes. Also, the disk check event is defined on the Scheduled Events property page. Think this through for a moment. When do you want the red flag waved that disk space is low on a post office? We personally would like to be notified when 30% of our disk space is remaining. Here's what you do to create a notification mechanism that tells you when a volume that houses a GroupWise post office has dropped below 30%: 1. | Make sure that the POA has the Disk Check interval set at a reasonable disk check number, such as five minutes.
The Disk Check interval is a setting on the POA's Maintenance property page. Make sure that the Disk Check Delay setting is set at two hours, or some other value that you think is good enough. The Disk Check Delay option means that, when the POA has hit the trigger to start the action on the disk check event mentioned in the next step, it will wait another two hours before it kicks off the disk check event.
| 2. | Go to the POA's Scheduled Events property page and create a new scheduled event or edit the Default POA Disk Check Event option that ships with GroupWise.
| 3. | To edit the disk check event, make sure that the following settings are in place:
- Type: Disk check.
- Trigger: 30%; don't use the Stop Mail Processing At option.
| 4. | To create an action for the scheduled event, do the following:
Click the Create button.
Give the action a name in the Name field.
In the Action drop-down box, select Expire/Reduce Messages.
Enable the Reduce Only check box, as well as the User and Message check boxes under the Databases tab.
Click the Results tab, and make sure that the results are sent to the administrator. You can also CC yourself if you are not defined at the administrator for the domain that owns this post office.
Click the Message button on the Results tab and compose a message that says something like The post office has dropped below 30% in disk space; you will receive a message every two hours until this problem is resolved.
| 5. | Make sure that someone is defined as an administrator for the domain that owns the post office for which you are activating this disk check event.
This person will get the message regarding low disk space. It's generally best to make the administrator a dummy user with rules that forward messages to several people in your IS department.
|
Now you have a low-tech mechanism for determining whether the volume that houses GroupWise is running low on disk space. Configuring the Post Office Object for Optimum Performance and Functionality This section discusses some settings and their relationship to a successful post office configuration. If a setting has no bearing on performance or function in the GroupWise system, it is not mentioned. Post Office Settings Property Page Figure 19.2 shows the Post Office Settings property page. Figure 19.2. The Post Office Settings property page 
Following are settings you can configure on the Post Office Settings property page: Software Distribution Directory: Chapter 12, "Administering the GroupWise Client," discussed the Software Distribution Directory. The value you fill in here is important, but see Chapter 12 for a full explanation of the Software Distribution Directory. Access Mode: This should be set to Client/Server Only. Don't allow users to connect directly to the post office via a UNC connection, because this will open the message store to a much higher likelihood of corruption. Disable Live Move: Don't check this option unless you have good reason to do so. Live move is used when moving users. Live move is explained in more detail in Chapter 13, "Moving Users."
Client Access Settings Property Page There is one simple setting that most customers will want to enable: Enable Intruder Detection. You can enable this setting anytime, and the POA will dynamically pick up the changes and apply them. You do not need to shut down the POA and restart it. Security Property Page This section offers a brief discussion of the most critical element of the Security property page. For the Security level option, you want it set to High, with either the LDAP or the eDirectory Authentication option checked. If you have users who do not have the Novell client installed, make sure that the users have a password on a GroupWise account or you'll need to enable LDAP authentication. The whole idea is that if the security level is high, GroupWise needs users to authenticate through a password-authentication process. The authentication will be either before the GroupWise client is started, which is the case with eDirectory authentication, or at the time GroupWise is loaded, which is the case with LDAP authentication or a GroupWise password. With LDAP authentication enabled, if a user does not have the Novell client, or a user is using GroupWise WebAccess through a Web browser, the user can still use an eDirectory password. The POA will query eDirectory via LDAP on behalf of the user. Your implementation of eDirectory must be version 8.5 or better, with LDAP services enabled and configured. Chapter 26, "Configuring GroupWise Authentication via LDAP," discusses enabling LDAP authentication, the best authentication solution. Default WebAccess Property Page The idea of a default WebAccess is important to the performance of WebAccess. But it's way too much to explain in this chapter; read Chapter 11, "Installing and Configuring GroupWise WebAccess," for more information. Configuring the GroupWise Client Options for Optimum Performance and Functionality The GroupWise client comes with a bunch of settings. Your organization might want to control some of these settings so that your email system is accomplishing its purposes. GroupWise allows you to set client preferences and control features available to GroupWise clients. These preferences can be set at a domain level and excluded right down to a user level. There are a few features that, if used incorrectly, can generate more traffic in your system than you might want. Here are three client preferences to pay particular attention to: Wildcard addressing Status tracking Junk-mail handling
The client preferences can be modified in ConsoleOne by selecting a domain, post office, or user object and choosing Tools, GroupWise Utilities, Client Options. Following is a discussion of the client preferences that affect performance: Wildcard addressing: Wildcard addressing is a great feature. With wildcard addressing, a user can send a message to all the recipients in a post office (that's the default), a domain, or even the GroupWise system and beyond that. The question then is whether you really want your users to have that kind of power. You can turn off all users' capability to use wildcard addressing at the post office level. Then for those users who should be allowed this functionality, you can enable it individually. You can configure wildcard addressing in ConsoleOne under Tools, GroupWise Utilities, Client Options, Send. Status Tracking: GroupWise has a great feature called status tracking. You can determine whether a message got to its recipient, and you can see when the recipient opened the message. Status tracking sets GroupWise apart from other groupware packages. Status tracking can be taken to the extreme, though. If your GroupWise system's client options for status tracking is set to track all information, you will be generating a tremendous amount of data that does not need to be tracked. By requiring the GroupWise system to track all information, you impact the following: GroupWise caching and remote users' downloads and uploads take longer. When a user purges a large number of messages from the trash, a tremendous amount of disk I/O is created. Status messages are generated for just about every action to a message item, and rarely do people need that information. Most customers will not want to enable all information. Check to see that this is not enabled somehow. Many customers will want to lock this feature down so that end users cannot change the option to track all information.
Tip It's helpful to simply browse through the client options and think about what settings you might want to configure or even which features you might want to turn off.
Now that we've told you all the evils of using too much status tracking, let's consider a different perspective. If your post office is using caching mode, it can be very helpful from a troubleshooting standpoint for you to set the status tracking to all, and then lock it. This will force this option to take effect on all user's mailboxes and caching mailboxes. For troubleshooting purposes, the status tracking can be invaluable. With the All Information option enabled, you can see when a user's caching or remote mode client actually downloaded the message. Tuning a NetWare Server for Optimum Performance and Functionality This section focuses on fine-tuning your NetWare server for optimum performance. These are the settings available: GroupWise Only Volume: When you place a GroupWise post office on a file server, it is best to create a volume that will only house the GroupWise post office. This just makes managing email simpler; for example, you'll have a good picture of just how much disk space is being taken on a post office. Compression: Do not enable compression on the NetWare volume dedicated for GroupWise. GroupWise already compresses the message store, and does so even better than NetWare does. It's redundant effort on the part of the NetWare operating system to try to compress files in the GroupWise message store. Immediate Purge: GroupWise deals with a whole lot of files passing through queues off of the WPCSOUT and WPCSIN directories. Set these directories so that they are purged immediately. This allows the NetWare server to free up memory resources to optimize other parts of the NetWare server. Server Set Parameters: The syntax on these settings has been confirmed for NetWare 4.x through NetWare 6.0. The values here are the minimum; if you currently have your NetWare server tuned to use higher or faster values, you don't need to decrease the values. The STARTUP.NCF file should have the following set parameters in it: Set TCP defend land attack = off Set minimum packet receive buffers = 2000
The AUTOEXEC.NCF file should have the following set parameters included in it: Set read ahead LRU sitting time threshold = 60 Set maximum file locks = 20000 Set minimum service processes = 100 Set maximum service processes = 1000 Set new service process wait time = 0.3 Set maximum packet receive buffers = 5000 Set new packet receive buffer wait time = 0.1
These set parameters will ensure that your server is more responsive than it would be otherwise. Tuning a SUSE Linux Server for Optimum Performance and Functionality This section focuses on fine-tuning your SUSE-based server for optimum performance. These are the settings available: GroupWise Only Partition: When you place a GroupWise post office on a file server, it is best to create a partition that will only house the GroupWise post office. This just makes managing email simpler; for example, you'll have a good picture of just how much disk space is being taken on a post office. File System Type: Use a Journaled file-system type. We suggest making the file system Reiser. And in the Reiser file system, disable Access Time logging. In YAST2 the check box on an OES server says No Access-time.
|
