Mapi profile corrupted after Adding domain on Microsoft 365
Question asked by Matteo - 9/29/2022 at 1:58 AM
my customer registered the domain on microsoft 365, and the Outlook clients configured in Mapi stopped working.
If I try to create a new profile automatically it asks me to access with the Microsoft 365 account.

But the old profiles are corrupt, is it not possible to restore them somehow? I have many PCs to reconfigure


10 Replies

Reply to Thread
This is a BUG (or maybe a feature requested by Microsoft?) in Outlook - if you register your domain on Microsoft 365, Outlook Autodiscover for MAPI ALWAYS tries to connect to Microsoft 365 and won't connect to other services.

You can avoid this with a mod in the Windows registry that tells Outlook NOT to use Microsoft 365 with the Autodiscover service.

At the moment I don't have a tutorial to do it, I will post it later if I can (but you can find it by searching the community ...)

Gabriele Maoret - Head of SysAdmins at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)
Kyle Kerst Replied
Employee Post
Hey Matteo, sorry to hear you're having trouble with this, and I hope we can save you some time here! I believe you may be able to get those existing profiles open with a couple of modifications to those client PCs beforehand. First, you'll want to implement the registry key change outlined here:

That tells Outlook to prefer the XML it gets back from SmarterMail. Next, you can add an entry like the one below to the client PC's C:\Windows\System32\Drivers\etc\hosts file:        outlook.office365.com
Once you get that added to the file, save it to the desktop (it won't let you save directly to that path) then copy the replacement (with no file extension) in to replace the original. Finally, give the PC a reboot to force the changes into place. That change will tell the PC to redirect calls to outlook.office365.com back to the local results it got from SmarterMail. Can you give this a shot and let us know if it helps?
Kyle Kerst System/Network Administrator SmarterTools Inc. (877) 357-6278 www.smartertools.com
Tim Uzzanti Replied
Employee Post Marked As Answer
Appreciate Kyle chiming in!

Microsoft is doing a VERY poor job cleaning up Office365 data which is intentional and to their benefit.   It is forcing people to make configuration changes, like what Kyle provided.

In addition, Microsoft is also introducing man in the middle servers that all your email will flow through on its way to Microsoft Outlook (so they have access to everything), even if you don't use Microsoft mail servers.  

Microsoft is giving users a lot of reasons NOT to use Microsoft Outlook and why SmarterTools is working very close with a number of companies who make email clients.

More information to come!
Tim Uzzanti CEO SmarterTools Inc. (877) 357-6278 www.smartertools.com
Stefano Replied
That's the commands that I usually run

reg add HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover /t REG_DWORD /v PreferLocalXML /d 1
reg add HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover /t REG_DWORD /v ExcludeExplicitO365Endpoint /d 1
Lee Tinch Replied
Does anyone have a fix for this I've tried everything above and still can't get this to work? Thanks.
M.G. Wallace Replied
Thank you @Tim for the update... WOW! Some of my clients refuse to use MS Outlook for many reasons! Now knowing that Microsoft will be able to gain access to All Emails, even not being on their servers, that is a breach in company security for so many companies!

Please do let us know about email clients to replace MS Outlook!

Thank you!
Do you have any technical evidence to back it up then I would be very glad to see it :) This is potentially a #gdpr violation if its true.
Brian is right!

If there're evidences, we can sue Microsoft to the GDPR European Commission
Gabriele Maoret - Head of SysAdmins at SERSIS Currently manages 6 SmarterMail installations (1 in the cloud for SERSIS which provides services to a few hundred third-party email domains + 5 on-premise for customers who prefer to have their mail server in-house)
Douglas Foster Replied
Setup a Smartrmail account on the cell phone version of Microsoft Office.   Send an email from the phone app to another account.   View Raw Content and look at the Received headers.   The message goes from the phone to a Microsoft server and then to your server   Your server will see it as an authenticated login, which means that the Microsoft server has your credentials AND has had access to your message content.   When I did this several years ago, Microsoft also added 9 minutes of unexplained delay.  Have not tried again recently. 

The aurodiscover process also offers your credentials to Microsoft, unless you use the registry keys to bypass the O365 connection attempt   We can hope that Microsoft does not keep credentials for failed connections. 
Howell Dell Replied
I had a very similar IF not the exact same issue and tried these various Regedit fixes and they did not solve anything for me. The issue it seems to be that Microsoft assumes too much, in their favor, if your M365 login is x@<customer-domain> but is really y@<customer-domain> for SmarterMail then the latest version of Outlook 365 does not prompt for password it uses the password for x@<customer-domain> instead for a login to y@<customer-domain> which fails.

Tomorrow, I am going to try this at the customer and will see if what I discovered will fix the issue. Worst case I will create new z@outlook.com accounts share the retail license to another Outlook.com account just for this purpose.

The commercial version of M365 has a totally different behavior and uses Microsoft Azure AD for user authentication. I have another client using Azure AD with a <customer-identifier>.onmicrosoft.com eMail Address which solves that problem for now. Eventually, I see I will need to implement Azure AD "sync" or whatever it's called these days with on the premises AD. But that is a topic for another day.

I worked on this for over a week and came up with a solution that works out of the "box" for me based upon my testing:

  • Upgraded SmarterMail from Build 8025 (Dec 21, 2021) to Build 8451 (Feb 20, 2023) as latest retail version of Outlook is different from commercial version of Outlook and AutoDiscover issues prevail plus new versions of Outlook require an updated Version of MAPI on the SmarterMail side
  • changed autodiscover.<customer-domain> to use an A Record
  • changed webmail.<customer-domain> to use an A Record
    (or whatever you call the MRS Web UI)
  • Updated SRV record to point to autodiscover.<customer-domain>
  • added autodiscover.<customer-domain> with SSL Cert
  • added webmail.<customer-domain> with SSL Cert
  • I have a global rewrite rule for http to https, however, I need to correct this for this client (have not done this yet), however, they can enter https://webmail.<customer-domain>; and this prevents redirection
  • FYI: I use CertifyTheWeb to Maintain these two Certs as a "bundle" in one Cert file for IIS MRS Binding

Reply to Thread