| The steps in the preceding section could have taken care of a mailbox problem. If they did not, some very simple troubleshooting begins. Here is a systematic approach. Determining Whether the Problem Is Machine-Specific As the administrator, can you duplicate the problem from your own machine? Log in to the network as yourself and access the problem user's account by using the /@u-? switch. For troubleshooting purposes, have an extra GroupWise icon on your desktop. The icon should have a /@u-? switch after the GRPWISE.EXE. See Figure 23.3 for an example of this. Figure 23.3. An extra GroupWise troubleshooting program shortcut 
You must have GroupWise notify and the other GroupWise client software, such as the address book, unloaded in order to get into someone else's GroupWise account (the client suite can connect to only one account at a time). You will also need the user's password in order to enter the user's mailbox when using the /@u-? switch. Troubleshooting Machine-Specific Problems Suppose, however, that you can't duplicate the problem from your own machine. If this is the case, it's likely a machine-specific problem. Perhaps something has corrupted the GroupWise installation. At this point, we don't have a nice, numbered list of steps, but we do have a few suggestions, covered in the following sections. Uninstall/Reinstall One option is to try uninstalling and reinstalling a few components: Uninstall and then reinstall GroupWise. Reinstall Windows messaging. Windows messaging can be reinstalled from the GroupWise software distribution directory by running WMS.EXE from the CLIENT\WIN32\WMS\xx directory in your software distribution directory. For Windows 98 and ME, run WMS from the 95 directory. For Windows NT/2000 and XP, run WMS.EXE from the NT directory. Uninstall Windows messaging. This can be hard to do on some machines because, although Windows messaging is installed, there's no uninstall option in the Windows Control Panel. This might sound funny, but you might have to run WMS.EXE to install Windows messaging before the Windows Control Panel will allow you to uninstall it. Change Windows messaging profile information. Delete the GroupWise profiles and then add them back in. The Windows messaging profile information is typically in the Control Panel under the Mail or Mail/Fax option. Sometimes this option isn't available. If you can load the GroupWise client, go to the address book and choose File, Services.
Troubleshooting TCP/IP from the Workstation Perhaps the problem looks like a TCP/IP communication problem between the client and the POA (89xx-class errors). If so, try these steps: 1. | Ping the server running the POA. If you can't ping successfully, fix that problem before going further.
| 2. | Telnet to the POA. Run Windows Telnet by entering telnet from the Run prompt under the Start menu.
| 3. | When using Telnet, turn on Local Echo.
| 4. | Connect to the POA; the hostname should be the DNS name or IP address of the POA, and the port should be 1677, or whatever your client/server port is. Figure 23.4 shows a Telnet session.
Figure 23.4. A Telnet to the POA 
| 5. | Upon successfully connecting to the POA's client/server port, you should be allowed to type characters and press Enter several times. Also, after holding the Enter key for several seconds, you should be disconnected from the POA. If you can't get the connection to the POA at the client/server port, you've got some kind of a TCP/IP problem.
|
Tip If you get a connection to the POA, hold down the Enter key, and then never get disconnected, that's actually an indication of a TCP/IP problem (for some reason, the POA cannot talk back to the client in order to close the connection).
If there are TCP/IP problems, it is appropriate to verify the TCP/IP settings or reinstall the TCP/IP services on the user's workstation. Itmight also be a good idea to break out the LAN sniffer and determine whether there is a network problem on this network segment. Note When using a LAN sniffer to help troubleshoot and diagnose problems between GroupWise components, you will not be doing any Application layer troubleshooting. This is because all data between GroupWise agents are encrypted. You will be looking for layer 24 problems on the TCP/IP stack when using a LAN sniffer to troubleshoot communication issues. An exception to this is SMTP traffic that is usually not encrypted.
Troubleshooting User-Specific Problems If the problem can be reproduced on multiple machines, your problem is likely user-specific. Before you can classify a problem this way, however, you need to make sure that the problem isn't specific to the post office or network segment. A good test is to go to a machine on the same network segment, or on the same network switch as the machine that seems to be giving the user problems. From that machine, log in as a different user than the problem user, but one who is on the same post office as the problem user. Does the problem persist? If so, the problem really isn't user-specific, and it's not machine-specific. The problem is either post officespecific or network-specific. Components Specific to Users Imagine that a problem looks as though it really is user-specific. It is still ideal to troubleshoot the problem away from the user's machine. There are just a few things that are truly specific to a user: The user's object entry in the GroupWise directory: Only the user interfaces with his or her object entry in the WPHOST.DB file. The user's master mailbox: This consists of the USERxxx.DB database file in the GroupWise information store at the post office, and any other store files it references for item content. The user's caching mode or remote databases: If the user happens to use caching mode or remote mode, these files will be on the user's local drive. If you troubleshoot from a different workstation, GroupWise remote databases should not come into play. The user's archive databases: If the user is archiving to a local drive, troubleshooting from a separate workstation should isolate the problem.
Isolating GroupWise Archive Problems The GroupWise client interacts with the archive databases on three occasions: When the GroupWise client first loads When reading items from the Archive mailbox When archiving a message item
The simplest way to determine whether a problem is an archive problem is to rename the user's Archive directory. To determine a user's Archive directory, do the following: 1. | In the GroupWise client, go to Tools, Options, Environment, File Location.
| 2. | Write down the Archive directory path.
| 3. | Determine the user's three-character FID.
In the GroupWise client, this information can be found under Help, About GroupWise. It's the three characters in the parentheses following the user's name, as shown in Figure 23.5.
Figure 23.5. The GroupWise FID as shown from the GroupWise client 
The Archive directory is the file location of the archive plus OFxxxARC (in which xxx is the user's FID). If the Archive directory is C:\ARCHIVE and the user's FID is 123, then the Archive directory therefore the user is C:\ARCHIVE\OF123ARC.
Tip It is always a good idea to back up GroupWise archives before working with them. In fact, Novell recommends that GroupWise archives be placed on network drives so that they are backed up automatically. Do not use Novell's iFolder to manage GroupWise archive backups. Novell's iFolder can corrupt GroupWise archive databases. | 4. | Rename this directory.
|
If this approach solves the problem, you know that the problem was with the user's GroupWise archive. You can now name it as before, and start taking steps to repair it using the standalone GWCheck for Windows (GWCHECK.EXE). Tip The GroupWise client has GWCheck within it. If you want to run a GWCheck on an archive database, hold down the Ctrl and the Shift keys simultaneously, and then choose File, Open Archive.
Isolating GroupWise Master Mailbox Problems Generally, a problem is either in a user's database or in one of the message databases on the post office. The most likely culprit for problems is the user's USERxxx.DB file. Users can potentially destroy the contents of their USERxxx.DB files. For instance, a user can create a personal group with invalid addresses. If a user is complaining of a problem, and the problem is user-specific, begin by looking in the user's preferences and address book for clues about what is causing the problem. If you already ran a structural rebuild on this user's database and you've reached this point, you might want some additional confirmation that you are looking in the right place. One way to do this is by renaming the user's user database. This is a common troubleshooting step: 1. | Make sure that the user is out of GroupWise.
| 2. | Rename the user's USERxxx.DB file to USERxxx.OLD.
Note You might have to bring the POA down to release this file. Just unload the POA, and then while the POA is unloading, go to the NetWare Console prompt and immediately reload the POA. Users who are in GroupWise will automatically reconnect to the POA, and there is generally a negligible interruption of service. | 3. | Using the standalone GWCheck utility, specify the following, as shown in Figure 23.6:
- Database Type: Post Office.
- Database Path: Specify the path to the post office that the user is on.
- Post Office Name: Specify the name of the post office that the user is on.
- Object Type: User/Resource.
- User/Resource: The problem user's USERxxx.DB file.
- Action: Structural Rebuild (not Structure Analyze/Fix Databases).
- Databases: User.
Figure 23.6. Using GWCheck to drop a USERxxx.DB file from the guardian database 
| 4. | Click Run.
When GWCheck runs, it will report, among other things, an error 26. This error is good. It means that GWCheck will remove the registration of problem user's USERxxx.DB from the NGWGUARD.DB file. The system will now allow you to create a new USERxxx.DB file for this user.
Tip You might have to bring the POA down again. When you go to load the GroupWise client, you could get a C05D error. A C05D error indicates that the USERxxx.DB file is registered in the NGWGUARD.DB file but is not on the disk. You just unregistered the USERxxx.DB file from the NGWGUARD.DB file, but the POA has it cached in memory. Bringing down the POA and bringing it back up fixes this issue. | 5. | Run GroupWise as the problem user.
The email box will be empty. Do the same action that caused a problem before. Does the problem still exist? If not, you know that the problem was wholly contained in the USERxxx.DB file that was renamed to USERxxx.OLD. If the problem does still exist, you are looking at a problem with the post office database, or perhaps you have not correctly ruled out machine- or network-specific problems.
| 6. | Whether or not the problem was isolated to the user database you renamed, you should now rename the new USERxxx.DB file something else, and rename the USERxxx.OLD file back to USERxxx.DB.
Again, you might need to unload and reload the POA to force the release of the file.
|
The next section gives more ideas on how to proceed, now that you know that the problem is in the USERxxx.DB file. Fixing Master Mailbox Problems Suppose that in step 5 in the preceding section you isolated the problem to this user's database. Now what should you do? The following are some actions you can try: If you didn't synchronize the user object, do so now. If you didn't run a structural rebuild on the user's database, do so now. If you didn't run a contents check on the user's database, do so now. Run a Reset Client Options operation on this user from Tools, GroupWise Utilities, Mailbox/Library Maintenance. Run an index check on the user's database. Rid the user of the personal address book(s) and the entries in the frequent contacts address book list. You can export each of these books from the client, and then delete all the entries in each of these address books. When you have finished your testing and troubleshooting, you can reimport these entries. To export an address book, go into the GroupWise address book and choose File, Export. Make sure that you are not exporting the GroupWise system address book. Just export the frequent contacts and the user's personal address books.
If none of these steps resolves the problem, and the problem is really causing the user some headaches (which is to say, you cannot tell the user just to ignore the problem), you have two options: Use the Re-create User Database option. This routine could possibly fix the problem, but things will be pretty disorganized when the user goes back into his or her mailbox. All personal items will be thrown into the root of the mailbox Cabinet folder. The user's personal calendar items will also be lost. Archive everything. You can archive everything that the user has, and then give the user a new, empty user database. Then you need to unarchive the items into the new database.
|
