One of my clients uses GWAVA for spam filtering on their Netware 6.5.7 / Groupwise 7.0.2 server.  After upgrading from GWAVA 3 to version 4 they kept experiencing problems where no one would receive their daily digests.  The GWAVA support staff diagnosed the corruption in qms_digest.db as the cause of why the digests were not being released.  Their initial throught was some anti-virus program was scanning the database configuration file and was causing the corruption, but the problem persisted even after excluding the pertinent files and directories from the scan.

I was finally able to track the cause of the corruption down to a scheduled nightly reboot of the Groupwise/GWAVA server.  It seems that not unloading the Groupwise MTA before unloading GWAVA was causing the problem when the server auto-restarted.

Here’s my gwreset.ncf file that unloads the MTA, unloads GWAVA, then restarts the server without causing the corruption in the qms_digest.db file.

# begin gwreset.ncf script to restart Groupwise/GWAVA server gracefully
unload gwmta
# delay.nlm waits x number of seconds before continuing
load delay.nlm
delay 30
# gwavadn.ncf unloads all GWAVA4 components in the correct order
GW:\opt\beginfinite\gwava4\assets\bin\gwavadn.ncf
delay 60
reset server -f
# end gwreset.ncf script to restart Groupwise/GWAVA server gracefully

Another problem I was experiencing was using nogwava.ncf instead of gwavadn.ncf to unload the GWAVA components.  nogwava.ncf was the proper script for GWAVA3, while gwavadn.ncf is the correct one to use for GWAVA4.

Last Wednesday I upgraded a GWAVA 3.72 installation on a Netware 6.5 SP7 Groupwise 7.0.2 server to GWAVA version 4.0. The upgrade seemed to go just fine, but users were unable to send or receive Internet email, even after rebooting the server.

The GWAVA installation guide said to ensure the /smtphome switch in the sys:\system\gwia.cfg file reflected the correct path to the GWIA third directory. My path was set correctly in the following format:

/smtphome-\\ServerName\VolumeName\domaindirectory\wpgate\gwia\3rd

where servername is the name of the Groupwise server running the GWIA, VolumeName is the volume the gwia software is loaded on, and domaindirectory is the directory the Groupwise Domain is located in.

I removed the \\ServerName\ portion of the path and added a colon after the volume name which changed my smtphome path to:

/smtphome-VolumeName:\DomainDirectory\wpgate\gwia\3rd

and restarted my Groupwise server. Mail was then able to be sent and received from the Internet, and GWAVA was functioning properly.

Note that in Groupwise 7, the gwia.cfg overrides gwia object settings configured in ConsoleOne. Also, your gwia.cfg file may be located in a directory other than it’s default sys:\system. You can verify the path to the corerct gwia.cfg file by viewing the contents of your sys:\system\gwia.ncf file.

The other day my Netware 6.5.7 / Groupwise 7.0.2 server decided to stop sending out email for no apparent reason. Some of the things I tried during the troubleshooting process were:

1) Checked the GWIA log files, which didn’t show any errors occurring even with verbose logging enabled. As a matter of fact, the logs didn’t show the messages ever getting to the GWIA for processing! The MTA and POA log files did show the messages being processed, though.

2) Cleared all the GWIA queue directories, but mail still wasn’t sending out even after restarting the server.

3) I toggled the GWIA subdirectory per TID 10091741

4) I reinstalled GWIA per TID 3674238

5) I created a route.cfg file per TID 10010997

6) I made sure nothing weird was happening with DNS lookup on the Groupwise server.

7) I went through each step in TID 10061085, ” How to troubleshoot GWIA”

8 ) As a last ditch effort, I disabled Gwava (version 3.72), which we use as an inbound spam scanner. As soon as Gwava was disabled, mail started leaving the network. I was pretty stunned, since we only scan incoming mail, and we don’t use Gwava as a virus scanner. I verified in the Gwava config outgoing mail wasn’t set to be scanned. I then re-enabled Gwava, and the mail started piling up again. I had found the culprit, but not the cause of the holdup.

I checked over the server’s Gwava log files and console screens and didn’t see any errors, but did notice a message regarding NGW-VSCAN-CONTROLLER when unloading the MTA. That led me to TID 10069173, which pointed to a corrupt message being stuck in the \domain\MSlocal\gwvscan directory. I unloaded GWIA, GWAVA, and the MTA, and renamed the \domain\mslocal directory. I restarted the server, which recreated the previously renamed directory, and mail started flowing out again.

In my case, I had a bad message stuck in the \domain\MSlocal\gwvscan\4 directory. I moved a few files at a time from the renamed directory to the new \domain\MSlocal\gwvscan\4 directory until mail stopped processing. I then downed Gwava and the MTA, deleted the problem message, then reloaded the MTA and Gwava, and mail flow returned to normal.