Update 4/23/2024: We have now released April 2024 Hotfix Updates which address known issues in March 2024 SU updates.
Microsoft has released Security Updates (SUs) for vulnerabilities found in:
...
Updated Apr 23, 2024
Version 8.0
Blog Post
Hello All,
Regarding my last post, I was eventually able to resolve the issue with the mobile app. It was a combination of things actually:
1. The client had used a self-signed cert for the exchange server's IIS for many years and previously, the outlook app allowed us to skip the cert warning. However, with the authentication flow now proxying through the cloud, it no longer works despite the app still giving the option to "Login anyway". After installing a 3rd party cert on the internet facing server, it was able to connect by leaving the domain blank and using the matching UPN/email as the username. However, it did not work for other users because of this next point.
2. We found that the client is slowly getting on O365 and they are using it just for specific cases for now--mainly teams standalone. However, we do not have control over the O365 tenant since the parent is in control. We are only in control of this branch's exchange server which is independent from the parent. From what I observed, I figured the local AD UPNs seemed to be colliding with the ones in O365. In order to get around this, I did the following:
- Set the user's AD UPN to be different than the O365 UPN. It could be simple as removing/adding a dot depending on your email naming convention. For example, if the O365 UPN is J.Doe at contoso.commailto:email address removed for privacy reasons, set the local AD UPN to JDoe at contoso.com (without the dot).
- Add that UPN to the proxyAddresses attribute as an alias (smtp:JDoe at contoso.com). This is so the app can find the mailbox.
- In the outlook app, opt to configure the account manually for exchange and manually set the exchange server to connect to.
I hope this helps anyone in this scenario.