Things you should know about GWCHECK
(Last modified: 19Nov2001)
This document (2940100) is provided subject to the disclaimer at the end of this document.
The following Technical Information Document is taken from a posting to the Novell Premium Service, GroupWise Listserver.
Audience: GroupWise 5.x Administrators
GWCHECK versions & variations
How GWCHECK is normally run
Alternative (little known ways) of running GWCHECK
Common Questions & Answers
Other GWCHECK TIDs
I'm going to use some terminology throughout this TID that is important to understand when reading this TID. See below.
When I refer to GWCHECK I am not referring to an actual program per-se, I am actually referring to a routine, or a set of code. GWCHECK is the message store checking routines for a GroupWise 5 message store. The GWCHECK routines are embedded in three different places:
1. The GroupWise Post Office Agents (POAs)
2. The stand-alone GWCHECK utility, which I will refer to as GWCHECK32
3. The GroupWise 32-bit Windows client
There are three different locations for a GroupWise 5 message store. They are:
1. A GroupWise 5 Post Office
2. A GroupWise 5 User's Archive message store
3. A GroupWise 5 Remote Client message store
I often get customers that ask me, "what version of GWCHECK should I run?" The answer is generally simple, . . . "use the latest GWCHECK code."
The GWCHECK code is embedded in:
1. The stand-alone GWCHK32.EXE code
2. The GroupWise Post Office Agents
3. The GroupWise 32-bit Windows client
In most cases I suggest that they issue a GWCHECK job from NetWare Administrator/GroupWise Administration. The reasoning is this: When you issue the GWCHECK job from Administration, the GWCHECK job is spooled up to the GroupWise POA.
The stand-alone version of GWCHECK is still handier for doing certain functions, such as specifying a certain message database to fix, for example. The stand-alone GWCHECK is also useful for running GWCHECK on GroupWise Remote and GroupWise Archive message stores.
[HOW GWCHECK IS NORMALLY RUN]
The most common, and usually the best way to run GWCHECK on a user is by doing the following:
1. Load NetWare Administrator
2. Highlight the user on whom you need to run GWCHECK
3. Select Tools|GroupWise Utilities|Mailbox/Library Maintenance
4. Make the selections for the actions you would like to be done on the user. You are defining what GWCHECK job you want done on this user.
5. Select the RUN button
Once you select the RUN button this is what happens.
1. The GWCHECK job that you defined is created into a file placed in the Domain you are attached to in the Domain Directory\WPCSIN\5 directory.
2. The GWCHECK job is routed to the post office that the user is on who you highlighted when selecting the GWCHECK job under Mailbox/Library Maintenance.
3. The POA for the user's post office performs the GWCHECK using the GWCHECK embedded in itself.
NOTES: This is my preferred method for running GWCHECK. The reasons are this:
(a.) It's executed by an NLM, so it's fast. Now if your POA is running on NT, it's running using the NT POA vs. the NLM, but still, in general it's faster to have the NT POA run the GWCHECK job on it's local hard drive then having a client hitting the NT server running a stand-alone GWCHECK job from a workstation.
(b.) The processing is done locally by the POA vs. as a client across the network. This simply reduces the likelihood (although it just may be slight) that you will damage a database when accessing it across the network. If your post office is across a WAN, you are even more likely to cause damage to the message store when running GWCHECK if your WAN links are not reliable.
(c.) You are using an NLM vs. Windows, and as for myself, I would rather have an NLM running GWCHECK vs. a Windows machine. Granted, the newest versions of Windows aren't necessarily unstable, but it's all the stuff that administrators have running on their machine that can make it unstable. Case and point: I was at a customer's site. We were getting all kinds of strange errors when administering through NetWare Administrator. When we turned off the workstation based virus checker on the administrator's machine, the problems went away.
[ALTERNATIVE WAYS OF RUNNING GWCHECK]
I want to share with you some little-known facts on running GWCHECK from the GroupWise client; vs. using the stand-alone GWCHECK (GWCHK32.EXE) or the GWCHECK code embedded in the POA.
Both of these options that I show to you, issue a structural rebuild of the message store databases, that's all. But that's fine, because most of the time the problems with GroupWise databases are structural problems.
To issue a GWCHECK job on the archive databases from the GroupWise 32-bit client do the following.
1. Be logged into the GroupWise 5.x 32-bit client as the problem user with access to the archive databases
2. With the Ctrl and Shift keys depressed together, select File|Open Archive
3. A dialog box will come up that says "GroupWise has encountered a problem with your mailbox. GroupWise can rebuild your mailbox to avoid further problems. Rebuild now (this may take several minutes)?"
4. Select the "Yes" button
This is a nice way for your help desk to fix someone's archive by just instructing them to take these steps. The key advantage, is that no one had to go to the end user's desk, or determine their archive path etc. Perhaps you have misgivings about giving users this kind of ability to fix their archive. It's really harmless! If a user has fun using this feature, let them do it. Structure and contents checking doesn't have any hazards, but please note that if a database is rebuilt due to corruption, it will create a permanent backup file. The GWCHECK job actually does 2 passes. The first pass does a structural check/fix and the second pass does a content check/fix. If there is a structural corruption detected during the first pass, then it will rebuild the database, but otherwise the databases will not be rebuilt.
There are two ways to issue a GWCHECK job on the Remote GroupWise databases. Here they are:
1. When loading the GroupWise remote client, have the Ctrl and Shift keys depressed together while GroupWise is loading into GroupWise remote. GWCHECK will kick off, but without prompting the user if they would like to rebuild the remote databases.
2. To issue a GWCHECK job on the Remote GroupWise databases, from the GroupWise 32-bit client through a registry command do the following:
a. Run the Windows Registry Editor
b. Go to the following spot in the registry:
c. Add a new key named "Database Rebuilds"
d. In the Database Rebuilds key add a new Binary Value with the name being the path to the remote (or archive) database. For example, the name might be "c:\remote\rofdata"
e. Once you've added that key, then the next time the remote client is started, it will kick-off a gwcheck routine. A dialog box will come up that says "GroupWise has encountered a problem with your mailbox. GroupWise can rebuild your mailbox to avoid further problems. Rebuild now (this may take several minutes)?"
f. Select the "Yes" button
Upon doing this, when the GWCHECK job is finished, the Binary Value with the path you defined will be removed but the "Database Rebuilds" key will remain.
AUTOMATION OF THE REMOTE GWCHECK REGISTRY IDEA
For those of you that are familiar with the Windows registry, you might just want to take this concept a step further. You can make a *.REG file saved to the Windows desktop or some directory, so that a remote user can run the *.REG file periodically to spawn structural maintenance on their remote databases.
The registry file would look like the following
NOTE: There should be a carriage return after the last line. If there is not, the information will not be imported into the windows registry correctly.
If you saved the GWCHECK.REG file to your desktop you would do the following to run GWCHECK on your remote databases (if they were in C:\REMOTE\ROFDATA).
1. Double click on the GWCHECK.REG file on the desktop.
2. A information message will come up that says something like "Information in C:\WINDOWS\DESKTOP\GWCHECK.REG has been successfully entered into the registry." This information dialog is actually from Registry Editor or REGEDIT, but the user doesn't have to even load the registry editor. Select the "OK" button.
3. The user will be prompted to rebuild their remote databases the next time they load up GroupWise remote.
QUESTIONS & ANSWERS
QUESTION: Can I run GWCHECK against a GroupWise 4 or GroupWise 6 Post Office.
ANSWER: No, you should not. Let's qualify this though, if you go into NetWare Administrator and you use the "Mailbox/Library Maintenance" you can perform a "Mailbox/Library Maintenance" option on a 4.x user. NetWare Administrator realizes that the user is on a GroupWise 4 post office, so it creates an OFCHECK request vs. a GWCHECK request.
QUESTION: A user is showing up wrong in the address book, should I run GWCHECK on them?
ANSWER: GWCHECK is a GroupWise Message Store Database fixing utility. The GroupWise Address Book is not part of the GroupWise Message Store, it is part of the GroupWise Directory. To fix a problem with a user in the address book focus on synchronizing the user, or rebuilding the WPHOST.DB(s) that show incorrect information about a user.
QUESTION: One of my users is having problems with their archive. I went into Tools|Mailbox/Library Maintenance and issued a GWCHECK job on the user, but that didn't fix things. What should I do?
ANSWER: When you issue a GWCHECK job from Administration, you cannot run GWCHECK on a user's archive. Even if the archive is on the network, the POA will not access a user's personal archive. In order to fix a user's archive databases, you must run GWCHECK32 (The stand-alone GWCHECK), or use the suggestions above to fix a user's archive.
QUESTION: I called tech support and they said I should rebuild a post office database. Should I do that with GWCHECK?
ANSWER: NO! There are basically two kinds of databases at a post office level. It's important to understand the difference. The WPHOST.DB is a GroupWise Directory database, or Address Book database. All other databases off of a post office are message store databases. GWCHECK only has to do with the message store. To rebuild a post office do the following:
1. Highlight the post office that you want to rebuild in NetWare Administration and ....
2. Select Tools|GroupWise Utilities|System Maintenance
3. Select Rebuild database
4. Select the RUN option
NOTE: Doing this will require that you have exclusive access to the WPHOST.DB for the post office you are rebuilding.
|Document Title:||Things you should know about GWCHECK|
|Novell Product Class:||Groupware|
The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.