Novell GroupWise 7 Administrator Solutions Guide
The GroupWise information storethe collection of databases and directory structures discussed in Chapter 4, "Understanding the GroupWise Information Store"is susceptible to damage, just like any other set of files on a server. The information store is written to thousands of times each day, and although the odds of any individual transaction failing are astronomically low, after enough reads and writes the odds begin to add up in favor of an occasional problem. For the purposes of this discussion, really only two kinds of damage or corruption are possible:
It is easiest to explain these categories using an analogy. Suppose that you have a filing cabinet, and each file in each drawer contains not only its own information but also references to other files. Then one day, a herd of rampaging elephants being chased by a swarm of mosquitoes charges through your office and dents the filing cabinet. One of the drawers will not open any more. This is structural damage. Now, suppose that you fix the cabinet by transferring all the files you could get to from the dented cabinet into a new one. Unfortunately, you could not recover any of the files from the dented drawer. Later, when reading a file in one drawer, you see a cross-reference to a file in another drawer. You follow the cross-reference, but that referenced file is not there. This is content damage. As you can see, structural damage can lead to content damage if not properly repaired. It's important for you to understand and remember this when dealing with the GroupWise message store. Structural Maintenance
Your greatest concern regarding the GroupWise information store should be the structural health of the GroupWise databases. If there is a herd of elephants running around denting your databases, you need to know about it. You should take steps to ensure that all user and message databases on a post office are structurally analyzed and fixed every day. This is done via the Scheduled Events tab on the POA (Post Office Agent) object. Content Maintenance
The contents of the GroupWise information store need to be verified on a weekly basis. The contents analysis ensures that the pointers from one record to another record are valid. The contents check-and-fix also ensures that master records (as discussed in Chapter 20, "Troubleshooting Message Flow") have pointers to the other supporting records for a message. The Relationship Between Structure and Contents
As was illustrated in the example of the filing cabinet and the herd of elephants, one common reason for content-related problems is structural damage. Consider this scenario, for example: USERA's USER123.DB file has a pointer to record #286 in MSG17.DB. Unfortunately, a large block of MSG17.DB is damaged (for example, the server abended while the file was being written to). The next time the POA works with this file, it detects the damage and the file is rebuilt. The damaged block could not be recovered, though, and record #286 is lost from MSG17.DB. USERA's USER123.DB file now has a contents inconsistency. The contents analyze-and-fix routine will take the pointer in USERA's USER123.DB file and tie it off so that it points nowhere. This, in effect, makes the received item a posted item. USERA can still read the subject line and see who sent the message, but the message contents and any attachments are lost. USERA can contact the sender, having him or her resend or recompose the message, if necessary. Contents Analysis Is Time-Consuming
Contents analysis can take a long time, especially if your post office is a large one, or if your users retain their messages indefinitely. If your information store is large, you will want to run your contents analysis over a weekend. We have encountered organizations whose GroupWise information stores were so large that a contents analysis for a single post office took well over 24 hours to run. Email Expiration
Based on what you just learned, you can see part of the logic behind not allowing your users to keep their email forever. Thus, we strongly recommend that you implement an email expiration policy. You might choose to expire all email messages after they are 90 days old, but allow appointments to stay on the system for a full year. You might also decide to purge all deleted items (items in the trash) early each morning. Justification for Email Expiration
The downsides to allowing a GroupWise information store to grow too large are the following:
These downsides are real! The time required to run a Mailbox/Library Maintenance on a post office with a large message store makes the operation so time-consuming that you may find that maintenance cycles cannot complete before regular business hours have resumed. Overcoming Hurdles to Email Expiration
There are really only three reasons to keep an email message longer than 90 days:
It is important to know why users want to keep their email for a long time. Knowing this will help you suggest alternatives. In short, if you approach the problem from the right direction, you should be able to implement an email expiration/archive policywith the blessing of your user community. GWCheck/GroupWise Message Store Check
The software used to maintain and repair the GroupWise information store is commonly called GWCheck. This software actually resides in four places:
The post officebased GWCheck can be automated to run GWCheck jobs on a scheduled maintenance routine. The standalone and client-based GWCheck cannot be automated. Benefits of Running GWCheck on the POA
We often encourage our customers to use the POA-executed GWCheck. Here are some very good reasons to run mailbox/library maintenance, or to use scheduled events, instead of running the GWCHECK.EXE:
The benefits of running POA-based GWCheck jobs far outweigh the fact that you cannot see the GWCheck log as it is being created, as the standalone GWCheck allows you to do. The standalone GWCheck is best saved for one-off operationsfor example, issuing a structural rebuild on a MSGXX.DB file. If a post office is on the Linux platform, the standalone Linux GWCheck can be run right on the server that hosts the post office. So it does not need to run over the wire as the Windows GWCheck does against a NetWare server. Benefits of Running GWCHECK.EXE
If there were no circumstances under which you might need the standalone GWCheck, Novell would not have written the tool. Here are a few cases in which GWCHECK.EXE is preferred over the POA's routines:
There are many times when the standalone GWCheck is helpful; however, if it's a decision of whether to use the standalone GWCheck versus the POA-based GWCheck, use the server-based GWCheck if possible. Getting GWCheck Log Files
It is always a good idea to review GWCheck logs, even if you don't want to watch the operation work. To receive a GWCheck log from the POA, make sure that you are set up as the administrator of the domain that owns the post office against which you are running GWCheck. The steps to do this are listed here:
Tip The eDirectory user object you select must be grafted to a GroupWise mailbox. Also, the visibility of this mailbox should be set to system.
The next time the POA runs a GWCheck operation, the log file will be emailed to the user defined as the Administrator of the domain that owns this post office. Tip If you are not able to change the defined administrator of the domain that owns the user you want to run GWCheck on, you can click the Results tab before running the GWCheck operation, and then specify that the log file (or the results) be sent to your GroupWise mailbox. This way, you never have to change the domain administrator, but you can still get the GWCheck log files. You can also send the results to the user if you want. Most of the time, the user has no idea what he or she just received, so we rarely use this option unless we are running a mailbox statistics type of GWCheck and we want the user to see these types of results. Understanding Scheduled Events for Post Office Maintenance
Every POA object has a Scheduled Events property page. This page is used to create, schedule, and edit events for the POA. Every scheduled event has two parts: the event and the associated action or actions. The event is the record that tells the POA what triggers to use. The actions are the operations that the POA will perform when the triggers have been set. Triggers can include low disk space (for the disk check event type) or a particular day of the week and time of day (for the mailbox/library maintenance event type). Actions can include analyze/fix mailboxes or expire/reduce. Events and actions created from one POA are visible by (and can be executed by) every other POA on the system. Tip Even though events and actions can be used by multiple post offices, we suggest making events and actions specific to each post office in your system. We've seen problems occur when an administrator of one post office modifies a scheduled event that has an action that is catastrophic for another post office.
Managing Scheduled Event Creation and Modification
It should be obvious (especially to administrators of large systems) that you will want to manage how administrators create and modify scheduled events. The following are considerations you should take into account when creating scheduled events:
In the next section you are encouraged to create scheduled maintenance routines one post office at a time, naming the events appropriately. |