GWIA is not authenticating to relay host.

Hi,

Since GW7 through to 2012 our gwia has worked without a problem to our relay host authenticating using a gwauth.cfg file. However, now that we have upgraded to GW2014 from GW2012, the relay no longer works using the same gwia.cfg and gwauth.cfg files. We keep getting this error: MSG xxxxxx Response: 550 You must authenticate to use XXXX Standard SMTP.

The agents run on SLES11SP3 (OES11SP2), and the gwauth.cfg file is correct.

Any thoughts?

Thanks,
Brent

Tags:

  • In article <rbalcorn.6dkllz@no-mx.forums.novell.com>, Rbalcorn wrote:
    > Since GW7 through to 2012 our gwia has worked without a problem to our
    > relay host authenticating using a gwauth.cfg file. However, now that we
    > have upgraded to GW2014 from GW2012, the relay no longer works using the
    > same gwia.cfg and gwauth.cfg files. We keep getting this error: MSG
    > xxxxxx Response: 550 You must authenticate to use XXXX Standard SMTP.
    >
    > The agents run on SLES11SP3 (OES11SP2), and the gwauth.cfg file is
    > correct.
    >

    Just in case there has been a drift in how it is handled, have you run
    through the relevant docs ? The mechanism looks just like it was in 2012.
    https://www.novell.com/documentation/groupwise2014/gw2014_guide_admin/data
    /adm_gwia_switches_smtp_mime.html

    I'd be tempted to do some packet captures to ensure the right data is
    going out to where it is supposed to go. If it is hitting the correct
    host, then part of the process is working correctly. Perhaps recreate the
    gwauth.cfg file incase something funny has happened to it. Also confirm
    that there wasn't a password reset at the other end at the same time as
    Murphy could have struck while you were upgrading.



    Andy of
    KonecnyConsulting.ca in Toronto
    Knowledge Partner
    http://forums.novell.com/member.php/75037-konecnya
    If you find a post helpful and are logged in the Web interface, please
    show your appreciation by clicking on the star below. Thanks!

  • Hi Andy,

    Thanks for the reply.

    I did go through the docs and it doesn't seem like anything has change. I have opened an SR and I am currently working with the support team to try and resolve.

    What we did find out, is that if I point to a different relay host it works! Strange thing is that the original relay host is the one I have been using for years and it was working fine in GW2012.

    I did the obvious, and I can manually login to the relay host and send a message.

    We turned off STARTTLS and it doesn't make any difference and I do have packet captures of the handshaking which the support team is reviewing.

    I post back with any updates.

    Thanks,
    Brent
  • rbalcorn wrote:

    > I post back with any updates.


    Thanks - it will be useful to find out just what is up here!

    --
    Danita
    Novell Knowledge Partner
    Upgrading to GroupWise 2014? We've got you covered
    http://www.caledonia.net/store

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...
  • Update - Fixed:

    Unfortunately I don't have an exact reason for the failure, but, at the very least there was an erroneous UNC path found in the upgraded GWIA. This path appears to be one that was used on our old NW system years ago! Somehow it was promoted by a number of upgrades over the years and never caused a problem; until GW2014.

    Therefore the easiest, and possibly the cleanest, solution was to create a new GWIA and switch over to it.

    The system is working fine now.

    Cheers,
    Brent
  • rbalcorn <rbalcorn@no-mx.forums.novell.com> wrote:
    > Update - Fixed:
    >
    > Unfortunately I don't have an exact reason for the failure, but, at the
    > very least there was an erroneous UNC path found in the upgraded GWIA.
    > This path appears to be one that was used on our old NW system years
    > ago! Somehow it was promoted by a number of upgrades over the years and
    > never caused a problem; until GW2014.
    >
    > Therefore the easiest, and possibly the cleanest, solution was to create
    > a new GWIA and switch over to it.
    >
    > The system is working fine now.
    >
    > Cheers,
    > Brent
    >


    Thanks for that! I actually ran into this at another site (not the
    authentication issue, but the path). GW 2014 is proving very picky about
    such things.

    --
    Danita - http://www.caledonia.net/register

  • For future reference, you can run this command to fix up the gwia directory. Then you don't have to delete/recreate GWIA. Just substitute the appropriate data for your system



    curl -k --user gwadmin:gwpassword -H "Content-type: application/json" -X PUT https://10.10.10.10:9710/gwadmin-service/domains/mydomain/gwias/GWIA --data "{\"gatewaySubDirectory\":\"gwia\"}"



    --Morris





    >>> Danita Zanre<dzanre@no-mx.forums.novell.com> 5/16/2014 7:36 AM >>>



    rbalcorn <rbalcorn@no-mx.forums.novell.com> wrote:

    > Update - Fixed:
    >
    > Unfortunately I don't have an exact reason for the failure, but, at the
    > very least there was an erroneous UNC path found in the upgraded GWIA.
    > This path appears to be one that was used on our old NW system years
    > ago! Somehow it was promoted by a number of upgrades over the years and
    > never caused a problem; until GW2014.
    >
    > Therefore the easiest, and possibly the cleanest, solution was to create
    > a new GWIA and switch over to it.
    >
    > The system is working fine now.
    >
    > Cheers,
    > Brent
    >


    Thanks for that! I actually ran into this at another site (not the
    authentication issue, but the path). GW 2014 is proving very picky about
    such things.

    --
    Danita - http://www.caledonia.net/register

  • For future reference, you can run this command to fix up the gwia directory. Then you don't have to delete/recreate GWIA. Just substitute the appropriate data for your system



    curl -k --user gwadmin:gwpassword -H "Content-type: application/json" -X PUT https://10.10.10.10:9710/gwadmin-service/domains/mydomain/gwias/GWIA --data "{\"gatewaySubDirectory\":\"gwia\"}"



    --Morris





    >>> Danita Zanre<dzanre@no-mx.forums.novell.com> 5/16/2014 7:36 AM >>>



    rbalcorn <rbalcorn@no-mx.forums.novell.com> wrote:

    > Update - Fixed:
    >
    > Unfortunately I don't have an exact reason for the failure, but, at the
    > very least there was an erroneous UNC path found in the upgraded GWIA.
    > This path appears to be one that was used on our old NW system years
    > ago! Somehow it was promoted by a number of upgrades over the years and
    > never caused a problem; until GW2014.
    >
    > Therefore the easiest, and possibly the cleanest, solution was to create
    > a new GWIA and switch over to it.
    >
    > The system is working fine now.
    >
    > Cheers,
    > Brent
    >


    Thanks for that! I actually ran into this at another site (not the
    authentication issue, but the path). GW 2014 is proving very picky about
    such things.

    --
    Danita - http://www.caledonia.net/register
  • Thank you Morris.

    I've been watching this thread with great interest. So glad that there is a better work around :)

    Cheers,
  • "Morris Blackham" wrote:

    > For future reference, you can run this command to fix up the gwia directory


    By the way, in my experience, most Windows servers don't have curl, so you have
    to go hunt it down!

    --
    Danita
    Novell Knowledge Partner
    Upgrading to GroupWise 2014? We've got you covered
    http://www.caledonia.net/store

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...
  • Thanks for the tip!

    Aside from the bad path we actually uncovered a bug as well. If you put a host name or ip address in the field "Forward Undeliverable Inbound Messages to Host:", under the "SMTP/MIME" tab; the gwia will not send via the relay host. Instead, it will try to send directly to the domain in the "TO" field.

    Novell is working on a fix for this.

    Thanks,
    Brent