Fix: “Use GroupWise user address as Mail From: for rule generated messages” checkbox in grayed out in ConsoleOne

November 10, 2008 — Julie

In my ConsoleOne 1.3.6f running Groupwise 7.0.3 snapins I was unable to select the “Use GroupWise user address as Mail From: for rule generated messages” option.  The check box was greyed out.  

To fix this, I had to view the properties of the GWIA object.  On the Groupwise Identification tab I manually changed the Database Version from 6.5 to 7.0.1.  Once I applied the change, the check box became selectable.
 
Still not sure why the GWIA database version did not adjust itself after our Groupwise 6.5.5 to 7.0.3HP1 upgrade.
Posted in Groupwise. Tags: , , . 1 Comment »

Fix: ConsoleOne error “GWIA Admin could not locate file exepath.cfg”

October 9, 2008 — Julie

The ConsoleOne error “GWIA Admin could not locate file exepath.cfg” when editing the GWIA object is generally caused because ConsoleOne cannot find the gwia.cfg file.  

Exepath.cfg is usually found in the domain\wpgate\gwia directory on the GWIA server.  This simple file should only contain the path to directory where gwia.cfg is located.  On Netware servers, this location is typically the sys:\system directory, so the exepath.cfg contents usually look like:
 
\\servername\sys\system
 
On occasion I have seen this path use a mapped drive letter instead of the UNC path.  If you are experiencing this problem, replacing the drive letter mapping with the UNC path should fix this error.
 
Today I received this “GWIA Admin could not locate file exepath.cfg” error when I tried to access one of my GWIA objects from ConsoleOne 1.3.6f.  I just upgraded GWIA from version 6.5.5 to 7.0.3, so I suspected that conversion may have altered the exepath.cfg file.  But to my suprise, the file was identical to the pre-upgrade version.
 
I was finally able to resolve this problem by mapping a drive on the workstation running ConsoleOne to the GWIA object’s domain directory.  This mapping seems to help ConsoleOne find the exepath.cfg file, which tells it where to locate the gwia.cfg file.
 
Incidentally, if you are receiving this error on Linux, you may want to refer to:
 
TID 10095505: GWIA Admin could not locate file ‘exepath.cfg’  which suggests verifying the case of the paths are all lower case, since Linux is case sensitive.  
 
TID 3458009: Error: “Could not open EXEPATH.CFG” when attempting to view GWIA properties in ConsoleOne suggests ensuring the UNC path is typed in a Linux friendly format.
Posted in Groupwise. Tags: , , , . Leave a Comment »

Fix for “LDAP login failed” error when trying to install Groupwise 7 Webaccess or GWIA on SLES Linux

August 29, 2008 — Julie

To fix the LDAP login failed error when trying to install Groupwise 7 Webaccess or GWIA on SLES Linux:

Go to LDAP Group object for the server (not LDAP server object).  On the General tab, uncheck Require TLS for simple binds with Password > OK

Goto LDAP server object for the server, and on the General tab press Refresh NLDAP Server now. 

Install GWIA or Webaccess, and when installation is complete re-enable Require TLS for simple binds with Password and Refresh NLDAP Server.
 
The reason why is detailed in section 9.3.3 of the Groupwise 7 installation instructions
 

During installation, the WebAccess Installation program requires access to eDirectory by way of LDAP authentication. The LDAP Group object includes an option named Require TLS for Simple Binds with Password, which is enabled by default. With this option enabled, you must provide the LDAP server’s Trusted Root Certificate, which must be exported from the LDAP server, in order for LDAP authentication to take place (typically on port 636) during installation of the WebAccess.

Unless you already have SSL set up, an easier alternative is to disable Require TLS for Simple Binds with Passwords in ConsoleOne, which allows LDAP authentication to take place using clear text (typically on port 389), during installation of WebAccess. After disabling the option, restart eDirectory, install WebAccess, then re-enable Require TLS for Simple Binds with Password and restart eDirectory again.

Posted in Groupwise. Tags: , , , . Leave a Comment »

Howto: Export Groupwise Classes of Service and SMTP Relay Rules

August 22, 2008 — Julie

Okay, maybe the title of this post is a bit misleading.

I’m in the process of upgrading my organization’s Groupwise from 6.5.5 to 7.0.3.  I wanted to create a new GWIA object during the upgrade so I could fall back to the previous version if something went awry.

I has one daunting problem that stood in my way – the crazy amounts of Classes of Service that are used, along with a wide array of SMTP relay rules.  I knew I could recreate the rules by hand, but the sheer volume of entries meant I was looking at several hours of manual labor, hoping I didn’t typo on any of the entries.

I looked for a method to export these settings, but couldn’t find one.  I did some research and found out these settings are kept in GWIA’s gwac.db file.  I tried viewing the contents of this database file with notepad and a few free database viewers, but either I never found the right viewer or the contents are encrypted.

I finally found a suggestion that said to copy the gwac.db file from the old GWIA’s installation directory to the new GWIA’s installation directory, then validate and recover the database.  I did that, and all my access control rules appeared in ConsoleOne – Classes of Service, SMTP Relay, you name it.

Everything is running fine now, and using a Grouwpise 6.5 gwac.db file on a Groupwise 7.0.3 server doesn’t seem to be an issue.

Posted in Groupwise, howto. Tags: , , , , , . Leave a Comment »

Troubleshooting when Groupwise GWIA won’t send out mail

January 15, 2008 — Julie

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.

Posted in Groupwise, troubleshooting. Tags: , , , , , , . Leave a Comment »

Identifying and Clearing Groupwise GWIA Queues of Corrupt Messages

January 8, 2008 — Julie

When the Groupwise GWIA gateway has problems sending or receiving mail, it’s often the result of a corrupt message clogging up a queue. The easiest way to troubleshoot the problem and restore mail flow is often to down the GWIA and rename the queue folders.

To accomplish this on a Netware server you can stop the GWIA and MTA by pressing F7. Once they have unloaded, browse to the domain\wpgate\gwia directory and rename the following directories:

  • 000.PRC
  • DEFER
  • GWHOLD
  • GWPROB
  • RECEIVE
  • RESULT
  • SEND
  • WPCSIN
  • WPCSOUT

Restarting the GWIA and MTA will recreate these folders. If mail starting flowing again, you can bet that the cause of the problem was a bad message in one of the renamed folders. Move a few messages at a time from the renamed folders to their corresponding new folder. The message flow should continue until you find the corrupt message, which is often the oldest message.

Once the corrupt message is identified, delete it or move it to a different location. This should allow mail flow to resume as expected.

For additional details, see TID 10075205, TID 10054298 and TID 10008353.

In a worst case scenario you may need to delete and reinstall GWIA per TID 3674238. Don’t forget to apply any applicable patches.

Posted in Groupwise, troubleshooting. Tags: , , , , , . 1 Comment »

Groupwise 7.0.2 and problems sending attachments

December 19, 2007 — Julie

For the past month or so some of our Groupwise users have been reporting problems sending email attachments. The most common complaints included:

  • The recipient could see the attachment but it had no file extension following the file name
  • The attachment would have an extension like .001 rather than .doc, .xls, etc.

This problem was only reported with attachments sent to Internet addresses while messages sent inside our Groupwise system could be viewed as expected. This behavior was found in messages created in both the Groupwise Client for Windows and WebAccess.

Our entire Groupwise system runs on Netware and was patched up to GroupWise 702 Agent Hot Patch 2 Rev 1 SP2, which is currently (as of 12-19-2007) the most recent recommended patch level.

I decided to try out the beta GWIA agent, GroupWise 7.0.2 GWIA Post HotPatch 1a – Rev B. 7.0.2HP, even though nothing in the associated readme lead me to believe this would fix my issues. I just suspected since the problem was only seen with Internet email, GWIA must be the culprit.

I installed the patch per the readme and restarted GWIA and was temporarily able to send out attachments without any problem – most of the time. I was still hearing reports of sporadic problems with attachments, but the attachments sent properly from my machine every time.

Karen from the NGWlist gave me a few ideas where to look for the solution to my attachment troubles. Her first thought was MIME encoding:

“It could be the Mime-Encoding setting on the clients (Tools | Options | Send) We had the same issue with external e-mails being garbled, it was caused by the upgrade to GroupWise 7, the clients settings for Mime-Encoding was changed to UTF-8 where GW6.5.7 clients do not like this, we forced a change to all the user.db’s and set the Mime-Encoding to ISO, this helped with our problem.”

I checked the client settings on my machine (which had no sending problems), and they were set to UTF-8. I used GWcheck to change the MIME-Encoding settings for our entire post office by following this procedure:

1. Start GWCheck
2. Under Database Type, select Post Office.
3. In the Database Path field browse to and select the post office directory.
4. Under Object Type, select User/Resource.

If you want to perform the conversion on all user and resource databases in the post office, specify ALL in the User/Resource field.

5. In the Action drop-down list, select Reset Client Options.
6. In the Support Options field on the Misc tab, type setmimeencoding=number, where number is one of the following character set numbers:

a. Windows default
b. ISO default
c. UTF-8

Click Run to perform the conversion of user and resource databases from UTF-8 to the selected character set.

Unfortunately the problem persisted. I had no idea what else to try, and the client was not too happy.

I was scouring support.novell.com for possible solutions, and came across TID 10100678. This TID didn’t describe the symptoms of my problem, but it did mention systems were affected once they upgraded from Groupwise 6.5 to 7. I was desperate, so I gave it’s fix a try:

From ConsoleOne, in the GWIA properties | SMTP/MIME Tab | Settings – Click the ‘Use 7-bit encoding for all outbound messages‘ box.

If this does not work, edit the gwia.cfg and add the following switch: /force7bit

I made this change and reloaded the agent, and my users were once again able to send attachments without any issues.

I was unfamiliar with the differences between 7 and 8-bit encoding, so I checked out the Groupwise 7 documentation. I found that

“By default, the Internet Agent uses 8-bit MIME encoding for any outbound messages that are HTML-formatted or that contain 8-bit characters. If, after connecting with the receiving SMTP host, the Internet Agent discovers that the receiving SMTP host cannot handle 8-bit MIME encoded messages, the Internet Agent converts the messages to 7-bit encoding.

With this option selected, the Internet Agent automatically uses 7-bit encoding and does not attempt to use 8-bit MIME encoding. You should use this option if you are using a relay host that does not support 8-bit MIME encoding. This setting corresponds with the Internet Agent’s /force7bitout switch.”

Posted in Groupwise. Tags: , , , , , , . 4 Comments »

When GWIA won’t unload and the server hangs

June 14, 2007 — Julie

I updated my NW65SP6 Groupwise 7.0.1 server to 7.0.2 Hot Patch 1a yesterday, and my gwia kept abending when I tried to restart it or exit it. It didn’t matter if gwia was loaded in protected memory or not, it would just lock the system console. I was unable to down the server, spawn a new process, or restart the server from Netware Remote Manager. I had to walk down to the server room and physically restart the machine to regain access to it.

I found that you can enable the kill threads on exit or restart option in ConsoleOne from the gwia object’s SMTP/MIME settings page. This forces the gwia to terminate all current threads and exits almost immediately without locking up the server. You’ll have to cycle the gwia for this setting to take effect, and killing threads without a proper shutdown can theoretically lead to data loss.

You could specify this setting in both eDirectory and the gwia.cfg file in versions of Groupwise prior to 7.0.1, but now ConsoleOne moves the gwia.cfg file settings into the wpdomain.db file. You can still use the gwia.cfg file to override the ConsoleOne settings, but it didn’t work for me, so good luck.

Confused?

Here’s Novell’s Explanation from the Groupwise 7 installation guide (accurate as of 06-14-2007):

Consolidated Configuration Information (v7.0.1)

Before GroupWise 7 SP1, Internet Agent configuration information was stored both in eDirectory, as properties of the Internet Agent object, and in the Internet Agent configuration file (gwia.cfg). Starting in SP1, all primary configuration settings have been consolidated into the properties of the Internet Agent object. Secondary settings are still available only through the startup file.

When you update an Internet Agent to GroupWise 7 SP1 and access the Internet Agent object in ConsoleOne, all primary configuration settings are moved from the startup file into eDirectory. ConsoleOne no longer writes configuration settings to the startup file. Switches in the startup file can be used to override the settings in ConsoleOne.

Please note that the under the Internet Agent Fixes section of the readme for Groupwise 7 SP2 it states:

The /killthreads startup switch immediately kills all Internet Agent threads

so does that mean if you’re using a pre 7.0.2 gwia, this switch doesn’t work?

Posted in Groupwise. Tags: , , , , . Leave a Comment »