GW8(NW6.5) mig&upg to GW2014(OES) MTA link to POA closed

I hit the following problem during the migration from a Groupwise 8 server following excellent Danita's recipe for migrating and upgrading.

The source server is an all-in one : primary domain post-office GWIA Groupwise 8 running on Netware 6.5
The target server is an OES11 SP2 with groupwise 2014 software installed.
Using dbcopy, domain and post office data are transferred, using the migration interface, I migrate the domain and the post office in one step.

After migration, I update path, certificates, platform in the gwadmin console
I notice that I must change the certificate path in the poa config files : change in the admin console does not seem to be recognised
Also the MTP link in the POA has a strange effect : I have to set it in the POA Console.
I finally have a running POA, with MTP link open in both direction (inbound and outbound)
After some tuning with GWIA, (certificates, log path, platform, ip address) it also runs ok

The MTA is running fine except that the link to the POA is closed, with the error address incomplete.
Effectively, when I check the link address : the ip address is correct, but the port is set to 0 :confused:.

Double check in the gwadmin console, in the primary domain, under the object link to post office, the link is correctly defined as a TCP/IP link with ip and port.

Where does this 0 comes from ? Where does the MTA takes the connection address to connect to the POA ?

Following this problem, I had to go back to GW8, before the next attempt...
Any idea ?
Thanks in advance for your help
  • Hi,

    Do you had checked the POA configuration files ?
    Be careful : they were in poa.exe folder in GW 8 and now there are in po folder

    Laurent-Pascal Irovetz
  • Hi Laurent-Pascal,

    I edit the poa config files and set some parameters : certificate path, MTP addresses and ports, log level : all those parameters are correctly read from the POA, I can crosscheck their values using the POA console. the POA seems to work fine with these setting and now listen to port 7101 (MTP), 1677 (client), 7181 (admin), 7191 (soap)

    I just see an anomaly : my understanding is that the config files is just here to override some settings in the database, in my case, the configuration of the database seems to be incomplete (missing inbound ports for example) => in the POA console, under configuration, the Inbound MF Traffic value is written in red
    That is probably why the MTA does not get the information of the port and can not bind the POA.

    Thanks for sharing your knowledge
  • fzeller543 wrote:

    > The source server is an all-in one : primary domain post-office GWIA
    > Groupwise 8 running on Netware 6.5


    Is it possible that you were actually using "direct" links for the Domain/PO on
    NetWare? I ask, because those aren't supported on Linux (and I will admit my
    book didn't do a good job of explaining this, but is being fixed). If that's
    the case, then the link is simply "wrong" on Linux. I've honestly had to
    connect to the domain with ConsoleOne a couple of times to "fix" this, because I
    was having trouble with the Admin Console. That said, go into the POA Agent
    settings in the Admin Console and make certain there is an MTP port defined. If
    not, add it. Since you have the agents talking to each other, the change should
    get passed from the domain to the POA. If not, once the MTA shows that the POA
    is "open", you can rebuild the PO database to get the changes to it.

    --
    Danita
    Novell Knowledge Partner
    Are you a GroupWise Power Administrator? Join our site.
    http://www.caledonia.net/register

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

    > The source server is an all-in one : primary domain post-office GWIA
    > Groupwise 8 running on Netware 6.5


    Is it possible that you were actually using "direct" links for the Domain/PO on
    NetWare? I ask, because those aren't supported on Linux (and I will admit my
    book didn't do a good job of explaining this, but is being fixed). If that's
    the case, then the link is simply "wrong" on Linux. I've honestly had to
    connect to the domain with ConsoleOne a couple of times to "fix" this, because I
    was having trouble with the Admin Console. That said, go into the POA Agent
    settings in the Admin Console and make certain there is an MTP port defined. If
    not, add it. Since you have the agents talking to each other, the change should
    get passed from the domain to the POA. If not, once the MTA shows that the POA
    is "open", you can rebuild the PO database to get the changes to it.

    --
    Danita
    Novell Knowledge Partner
    Are you a GroupWise Power Administrator? Join our site.
    http://www.caledonia.net/register

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...
  • Hello Danita,
    Thanks for taking time for us.
    You're right, link between domain and post office was direct and that is probably the source of my issue.
    I double check the MTP port in the POA (Agent settings / Message Transfert Port) it is correctly set to 7101, with SSL enabled.
    The POA is running, with MTP Status open on the correct ports.
    But the MTA still have an incorrect link configuration : it shows a TCP link, with the correct ip address but a bad port ('0')
    Rebuild PO Database did not help.
    a) I did not get the point with Console One : should I use also C1 to manage the POA in GW2014 (and correct the link definition for instance) ?

    b) Probably there is an another issue with the MTA , because when checking the log with Novell support, we can see the message : Domain open failed, Closure reason: Cannot create directories.
    As groupwise runs as root on my server, I did not see a rights problem. but I should mention that I migrated to an NSS Volume => is the path given to the domain relevant ? (mounted like /groupwise/ or "brute" /dev/pool/..../groupwise/)
  • OK, a step further : The MTA and POA are now communicating, what really helped was to access with the good old Console One with groupwise snap in, pointing to the Domain database (yes I know, it is not recommended on a 1400 database, but ... that did the trick in my case).

    I could then correct the path which was still pointing to the Netware path.
    The MTA was probably running with a configuration partially broken. After that, it is like magic, MTA does connect the POA and the status is open.

    What I learned from this issue is
    firstly that you better have to set all possible values that you can predict using console one before you move from GW8 / Netware, after that the chances that your Linux / GW2014 will run are augmented !
    of course this make the "Go Back" scenario more treacky, but it is worth the time...
    and secondly, Novell should better document how the configuration is elaborated between, what is read from database (Domain or Post Office), what is taken from config file, and may be do some code review on the gwadmin-console and domain database update

    I think I'll wait for the GW2014 SP1 to retry the migration, it should not be so long to wait as I understood.
    Thx for the help !
  • fzeller543 wrote:

    > OK, a step further : The MTA and POA are now communicating, what really helped
    > was to access with the good old Console One with groupwise snap in, pointing
    > to the Domain database (yes I know, it is not recommended on a 1400 database,
    > but ... that did the trick in my case).


    Yep - it's not necessarly "recommended" but it definitely fixes the issue!

    Another option would have been to "delete" the POA object and create a new one
    in the Admin Console.

    --
    Danita
    Novell Knowledge Partner
    Are you a GroupWise Power Administrator? Join our site.
    http://www.caledonia.net/register

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