They've removed the option to start the agent with an interface in 18.5 for Linux, but it might still be available under Windows. See

https://www.novell.com/documentation/groupwise18/gw18_guide_install/data/inst_create_agents_windows.html#inst_create_agents_windows_start_stop

in the "manually starting the windows agents as applications for troubleshooting" section.

Without knowing more details I suggest to check your GroupWise certificates (not the public ones but internal certificates). You will see a lot of posts around here.

By upgrading to GW18.4 and newer certificates were the main problem for many of us. GW18.4 insists on SH256 certificates and agent certs have to contain ip address and dns information.

If you're not getting any log files, the GWIA has not reached the point where it can start logging.   What you would notice, if you could watch the visual screen when it starts, is that it will go through some initialization phases and then get to a point where it throws it's hands in the air and says Sorry, can't go on and it aborts.  But that error is what you need to see to know why it's failing. If you can get the agent to load manually with the --show directive, that will most likely give you what you need to solve the problem. 

That said, it's not uncommon to have to work through this type of issue when moving a server to a new system.  I find that in most cases, the problem is a path or filename in a config (That you should be able to see in the GW Administration Console) that is invalid on the new system..  For example, log files, certificate files, etc..    If you didn't move the certificates when you did the move, this could cause this issue.  Since you're going from 18.1 already, you're going to most likely find that your certificates from the old system aren't adequate, and you'll need to redo them anyway with 18.5 code.   So what I would do is just clear out the old cert configuration and/or regenerate a new cert/key file on the GWIA object. This gives you new cert plus it would ensure the filename/path of the cert is correct.

Like Mathias mentioned, you can use the --show directive at the command line.  I just confirmed that this still works on Windows server. The reason it's gone on linux is due to some linux libraries that have been deprecated.  Still good on Windows. Here's a screenshot showing you how to do it. This system is gw18.5 on Windows 2019.

I have gone in each agent and created new certificates. I am pretty sure I have each agent with the correct IP address of the new server. 

I have tried to start the GWIA from the Admin Console, via gwsc commands and get nothing. 

I tried Manually Starting the Windows Agents As Applications via the documentation from above and get getting errors.

I tried via  marvhuffaker approach and get teh GroupWise Internet Agent box opening up with a error message that says "Message Transfer Agent Directories do not exist."   When I hit OK I get another one that says "Please run the GroupWise Message Transfer Agent"  I have looked and it shows the agent is running.

Doing reading as to figure out why getting the "Message Transfer Agent Directories do not exist."

Did you check your gwia.cfg if all directory entries have valid information? Sometimes entries contain default values after upgrade which do not work obviously. Usually these entries are at the bottom of the file ...

I have a lot of follow up thoughts..... So stick with me.. 

I believe you're heading in the right direction. Whether you realize it or not, that "Message Transfer Agent Directories do not exist" is most likely the exact info you need to solve this..   That is why it's not starting when you attempt to start it via the services.  We need to figure out why your MTA directories don't exist.  

The problem could actually be with your MTA not with your GWIA.

Diethmar mentioned gwia.cfg... Go in that file and make sure the path to your GWIA directory is correct.  The GWIA.CFG file is under {domain}\wpgate\gwia\gwia.cfg.   And the path is generally the same as the location of the gwia.cfg file.  You'll find a "/home- parameter with the path. 

But I've also seen this same issue in cases of migrated systems and it's possible the domain itself has not created certain directories that it needs/requires.  When you DBCOPY a system to migrate, it doesn't copy some of the directories because they're just temporary..   The GWIA and MTA work together to read/write files to/from some of the directories. So if they're not there it cannot do it's job. I'm pasting a folder structure of an MTA that is working correctly, compare yours with this and see what's missing. It's probably a top level folder such as WPCSOUT.   

If you're missing folders in the domain directory, that's where you need to troubleshoot. 

And also here is a screenshot of what your GWIA folder should look like:

There's also a slight possibility that GWIA is configured for the wrong folder.   Go to your GWIA properties in the GroupWise administration console, and look at the "Subdirectory" field.  While it's not really obvious, and it's probably grayed out, the "gwia" should match the folder name in the wpgate folder under your domain. It could be something other than GWIA, so just make sure they match. If they don't match, that's another clue.

Sometimes the gwia.cfg gets overwritten with a default one which obviously would contain invalid path (and other) settings.

This is true and if the path is wrong, it could prevent the GWIA from finding the MTA folders it is looking for. 

Yea, Problem Solved!!

There were a lot of directories that were missing in the wpgate directory.

I first went through the list of files that were posted above and added the ones that were missing.  

Tried to start server and same message. "Message Transfer Agent Directories do not exist."

Then went to my old working server and started digging down deeper in directories. Found lots of sub directories missing.  Add them.  Tried starting gwia again and it started.

As an exit note. I had not used dbcopy to do the copy for the new server. I have been using Cloudberry backup and thought it was doing a perfect job.I was using it since it was backing up open files. I guess it was good at copying files, just not at creating empty directories on restore. 

I prefer rsync in Linux environments and robocopy in Windows environment. But there are two versions of robocopy - one seems to work unreliable - similar to your tool