Information-Store Maintenance Concepts

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:

• Structural damage

• Content damage

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:

• Backup operations might not complete overnight, due to the sheer volume of data to be backed up.

• Contents analysis takes a very long time.

• QuickFinder indexing might take longer, and a QuickFinder index rebuild operation (executed from the POA console) will take much, much longer than you might have time for.

• Larger information-store databases impede POA performance, which will in turn mean that your users will observe poorer performance from the GroupWise client.

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:

• Sentimental reasons: If this is the case, invite your users to use the GroupWise archive. They will still have access to the items, but they will not be impacting performance on the master mailbox. GroupWise archives should not be allowed to grow too much either. Maintaining archives can become a big issue. You should consider a third-party archive solution such as those available from the following Web sites:

  www.messagingarchitects.com www.nexic.com www.intellireach.com

  
  

• Legal reasons: If email messages are considered legal documents in your company, consider writing your email policy in such a way that your backup tapes can be considered the legal record of these documents.

• As a reminder of important information: Any email message that is still being read regularly after 90 days should probably become a GroupWise document (in a GroupWise library) or should be on your company's internal web page.

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 office agent: Each POA has the GWCheck code built into it. The code is launched when one of the following occurs:

  • Mailbox/library maintenance is run from ConsoleOne.

  • A scheduled event runs.

  • The POA detects a problem with a database it is trying to work with and kicks off a GWCheck job.

• GWCHECK.EXE: Found in the Software Distribution Directory ADMIN\UTILITY\GWCHECK, this is the standalone GWCheck software. It runs as a Win32 application, so to run it you must have full file access to the information store from a computer with a Windows 32-bit operating system.

• gwcheck: This is the standalone Linux GWCheck. The RPM for the Linux GWCheck is found in the admin directory of a Linux Software Distribution Directory. When GWCheck is installed, it can be found at /opt/novell/groupwise/gwcheck/bin.

• The GroupWise client: The version of GWCheck built into the client does not fix a user's master mailbox, but it can fix archive, caching mode, and GroupWise remote message store databases.

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:

• Speed: Assuming that the POA runs on the same box where the information store is located, the POA can run the GWCheck routines at least twice as fast as GWCHECK.EXE. It can run the operation right "on the bus" rather than across a network connection.

• Stability: GWCHECK.EXE runs on the Windows platform and must run "across the wire." If something goes wrong on the workstation (GPF, blue screen of death, and so on), or if the LAN connection goes down, GWCHECK.EXE might do more harm than good. The POA is not as vulnerable in this way.

• Scheduling: The scheduled events (which can be enabled on the POA) are automatic GWCheck jobs that are performed by the POA. The standalone GWCHECK.EXE does not provide tools for automation. As an administrator, you need not manually launch regular maintenance operations if you enable scheduled events.

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:

• Low risk to the server: In cases where you suspect that a corrupt database is causing the POA to abend a NetWare server, you should try GWCHECK.EXE. If this routine dies while doing a database repair, it will not take the whole server with it. Fortunately, these cases are getting fewer and farther between.

• Ability to watch it work: Some administrators like to see what GWCheck is doing. The POA does not log GWCheck operations onscreen, but GWCHECK.EXE does. When troubleshooting is being done, or a one-user GWCheck is being done, this is fine. For regular maintenance routines, though, the server-based GWCheck routine is always better.

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:

1.	Highlight the domain object, right-click, and select Properties.
2.	From the Identification property page, click the button to the right of the Administrator field.
3.	Browse to your eDirectory user object and click OK.

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:

• Rights: For a GroupWise administrator to create or modify a scheduled event, or any of the listed actions, he or she must have supervisory rights to the primary domain object in eDirectory. If you need to control access to scheduled events, restrict administrators' access to the primary domain object.

• Administrative procedures: Although an administrator might be restricted from creating or modifying events or actions, even with object rights restricted, you will want to ensure that the right operations run on the right information stores. There are two ways to do this:

  • Create different scheduled events for each post office: Naming conventions are critical here. In this case, we recommend that administrators name their events using the name of the post office the event applies to.

  • Create standard events that work for all post offices: Again, naming conventions are important. Make sure that the name of the event describes the operation.

In the next section you are encouraged to create scheduled maintenance routines one post office at a time, naming the events appropriately.