Anonymous_User Absent Member.
Absent Member.

Unable to communicate with GroupWise WebAccess Agent

We are experiencing an intermittent problem with GroupWise WebAccess. When users attempt to login there is a significant delay, up to a minute or so, then an alert that WebAccess is "Unable to communicate with GroupWise WebAccess Agent".

The WebAccess agent is running on a NetWare 6.5 server alongside the PostOffice, Domain, and Internet agents. WebAccess itself is on a SLES server located in a perimeter network.

In the WebAccess logs we're seeing a lot of the following errors:

14:02:33, <GWAP>, -, ERROR, username, Connection failed ( Unable to communicate with GroupWise WebAccess Agent: Possibly invalid encryption key in commgr.cfg

A packet capture, as well as a test with netcat, show that the WebAccess server is able to connect to the agent port on tcp/7205. The packet capture shows the TCP handshake completing as expected. Following that we see a packet from WebAccess that the agent never responds to. This results in the timeout symptom we are seeing.

We have verified that the commgr.cfg file on the WebAccess server is identical (same SHA1 hash) as the file on the NetWare server. We also tried to regenerate this file per TID 10051447 to no effect.

No patches or configuration changes have been made recently to either system. Does anyone have any thoughts on where to go next with troubleshooting this? We are having some health issues with the eDirectory tree as well. Could that be related?

Any help would be appreciated.

Pertinent versions:

GroupWise 8.0.3 Hotfix 3
NetWare 6.5 (GroupWise agents)
SLES 11 SP2 x86_64 (WebAccess server)
Labels (2)
1 Reply

Re: Unable to communicate with GroupWise WebAccess Agent

This is the observed behavior when then webaccess agent's worker threads are all busy. You can implement GW Monitor and monitor the thread usage over time, and get alerts when its unresponsive. You can also look at the thread usage when the problem is occurring. We have seen this when the webaccess is under attack as well, so check the gwinter logs to see if there is any clues during the outages.

Since you say the problem is intermittent, it us unlikely the security keys is an issue - as they would not change from moment to moment.

It is worth noting that webaccess login consumes a thread until the process is complete. So if you have an issue with the POA or authentication, GWINTER can spin waiting for this to fail, holding all of the workers in a busy state. So sure, if you are using LDAP authentication on the POA, or the POA is busy, webaccess can present this problem, but it will recover automagically after a while when these sessions time out. If the gwinter never recovers, its likely to be another issue.

IF you don't have LDAP authentication on the POA, eDirectory plays no part in the process, you will be using the native GW authentication.

Hope that helps isolate the issue.

-- Bob
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.