I was recently working on an e-mail migration from an IMAP server to Microsoft 365 and came across this error: “IMAP server check failed, reason: invalid IMAP server configure.” [sic] I was not able to directly overcome it, but I was able to work around the issue and came to some conclusions as to what may have caused it. In an effort to prevent a DenverCoder9 situation I am posting my findings.

Microsoft offers a well-documented path to migrate IMAP e-mail to M365. In fact, the G Suite migration from Gmail uses IMAP migration. So, this is typically a relatively simple operation. I gathered the needed credentials and information and came across this error. The slightly off wording immediately put me on alert, but this wouldn’t be the first time I’ve come across a strange error message from a Microsoft product. So, I plowed on gathering more information to double-check the settings. The error also didn’t point to having the wrong credentials, but something wrong with the server settings.

The client was migrating from register.com Professional e-mail, which is a classic cpanel webmail to IMAP service, not very modern, but low-cost and serviceable. Opening up their knowledge base redirects to web.com, showing that it’s most likely a single provider running several sites that offer the same service, not a problem, but worrisome. The IMAP KB article showed that we had the correct settings for the migration, but it still wasn’t working. As a sanity check I used the PowerShell command “Test-NetConnection mail.domain.com -port 143” to check that the server was listening at that port, and it was, as well at the other standard ports 993 and 587. So, there was a server there listening, just M365 could talk to it. This also revealed that the responding server did not have the same name as we used to access, there was a CNAME lookup to point to the actual mail server. Using the real mail server name did not work either. I tried various permutations of the available settings to no effect.

As a next step I went to sync the client’s e-mail with my local Outlook 2019 to confirm that IMAP could be coaxed into working. This led to, perhaps, the least helpful set-up guide I have ever read. So I moved onto their Outlook 2010 instructions to see the detailed setup configuration. Good old reliable Outlook 2010, back when you could set the configuration how you want it instead of trying to coax the auto-configure to do the right thing. Fortunately, this classic mail configuration screen can still be accessed in the Control Panel – View By: Icons: Mail (Microsoft Outlook) -Email Accounts… This is where the real trouble comes out; this vendor recommended no encryption on the e-mail or password transfer for IMAP. That’s right, a company in 2021 will gladly charge you to send your e-mail and passwords in plain text over the internet.

This is probably the cause of why Microsoft 365 IMAP transfer would not work. M365 assumes some form of encryption is available, there is no way to set none, only SSL or TLS. If you are getting the mystery error, try different settings to match your vendor’s encryption standards. If you have control of the IMAP server, update it, and install the needed security protocols. At one point during the Outlook setup process, I was also prompted to accept an invalid server certificate due to a domain name, mismatch. Perhaps M365 couldn’t trust a mismatched cert as well, so be sure you are using a publicly trust certificate with the correct name for your domain.

How did I resolve these errors and continue the client e-mail migration? Sadly, I could never resolve this error, but Office 365 offers several ways to upload your email into the system. Since there were only a few mailboxes involved and about a dozen gigabytes total, I switched to a manual PST backup and restore to M365. This involved using a local IMAP client to download the historical mail and creating a PST for each account to be migrated. I then used the Azure Storage AzCopy to upload the PSTs to a temporary location and run the available import job. Given the nature and time that this job took to complete, it is more tailored for situations where hundreds of mailboxes and terabytes of e-mail need to be uploaded, rather than just a handful of accounts, but it still worked.

What are some of the lessons learned? There are several. If you are looking for a system to host your company’s data, legacy systems will have legacy problems and as time marches on and tech-debt piles on these systems, it becomes increasingly difficult to modernize them. So, don’t put off your infrastructure upgrades. Also, with infrastructure projects you get what you pay for. Using a bottom-basement vendor may save cost in the short run, but they may be lacking basic security and investment in keeping their systems up to date. This can leave you holding the bill later or even with huge security breaches. If you are a system administrator, always be prepared for interruptions in your deployments. As nineteenth-century Prussian military commander Helmuth von Moltke is often quoted as saying ‘no plan survives contact with the enemy.’ Have a backup strategy and be willing to adapt if you meet with unexpected roadblocks.