Is AutoMigration only triggered by webmail?

Just wondering if the only option for the AutoMigration trigger is webmail, is it not triggered by an Outlook client imap/pop fetch mail event ?

Hello @bhiggs

The Auto Migration process is triggered by any service whether via Webmail, IMAP, or POP3, including Outlook client. It’s not limited to Webmail access.

Regards,
Florin

1 Like

Thanks for this, that helps us know we’re not crazy at least :slight_smile:

What we’re seeing in the everything.txt log is; “Cannot continue automigration for xxxxx: not plain authentication type”, and we’re a bit stumped on how to solve it :slight_smile:

I can post the full IMAP log if you like for that users session if that helps?

Thanks,
Brad.

It works via Webmail exclusively, and i’m pretty sure it did work via the outlook client previously but after some additional configs for SSL it stopped working, could it be that its forcing an SSL connection but the remote end is expecting plaintext, and the Webmail client can handle that use case but the direct outlook client can’t ?

Cheers,
Brad.

Did you want me to create a new thread for the automigration error? we have a License ID if you need a reference point :slight_smile:

What we’re seeing in the everything.txt log is; “Cannot continue automigration for xxxxx: not plain authentication type”, and we’re a bit stumped on how to solve it

Hello,

Yes, this is the expected behavior for accounts that are not already present on the Axigen side.

Only when the session is authenticated via an unsecured method, Axigen will have the opportunities to 1/ extract the password and 2/ to validate the password to the legacy email service from which the migration should be done.

Thus, we highly recommend to use only only SSL enforced listeners (for example only :993 for your IMAP service) and disable all secured methods, at least during the migration time.

HTH,
Ioan

Well it works via Webmail but we couldn’t get it to work via client connections, so we had to pull the trigger regardless and just deal with the migration overhead.

The bigger problem ended up being the migration process itself, it keeps getting snagged on folders and crashing out without detail citing: " user ‘xxxxxx’ has been migrated with errors ", and we can delete those offending files on the source server in some cases and migration continues but sometimes it snags regardless and can’t be mitigated. Migration source is postfix and legacy going back 20 years in some cases so any possible recommendation on tools to solve that would be great :slight_smile:

Thanks guys!
Brad.