GroupWise Messenger 18.1 users get a D202 error upon attempting to search Messenger archive conversations

  • 7023613
  • 04-Jan-2019
  • 04-Jan-2019

Environment

GroupWise Messenger 18

Situation

When GroupWise Messenger Archiving is setup correctly, Messenger 18.1 client users are logged into Messenger and Click on FILE, Search Archive, they get a "D202" error at the Messenger client, and because of this error they cannot search the Messenger archived conversations.

Resolution

Workaround:  ( not a permanent solution )
The affected Messenger users were disassociated from eDirectory and a new Messenger password was given.  Once this was done and the Messaging Agent (gwm-nmma) and the Messaging Archive Agent (gwm-nmaa) was restarted then the affected users could successfully click on File , Search Archive and find archived conversations.

Steps to disassociate Messenger users:
1.  will update soon ...

Cause

When you are logged into GroupWise Messenger and then click on File, "Search Archive", you are authenticating, thru the Messenger Archive Agent to the eDirectory server, it is failing the authentication.  Currehntly it is not known why this fails.  At Development.

Additional Information

- Confirmed in the GW18.1 Admin Console, Messenger object, Messenger Service, Settings tab, Archive Settings, they have the proper users listed in the Archive ACL list

 - Confirmed in the GW18.1 Admin Console, Messenger object, Messenger Service, Policy object, Default Policy, "Archive Message Sessions" is checked off and the MA and AA were restarted.

 - Confirmed in the Arango database (in browser port 8320), GroupWise, ACL, The user who fails for the Archive Search is listed here.  Have screenshot with FILES section below.

 - Looked at AA log and it shows, at same time as failed archive search attempt in Messenger 18.1 client :

eDirectory login: <UserID> to <ldapServerIPAddress>
13:17:23 700 APL Login failed [0xD202]: <userID> -

Somehow the AA log shows that there is a failed attempt to login to a valid eDirectory server, when it should be successful.

This issue has been reported to Development.