Today is June 25, 2024, and I am writing this post after a week of troubleshooting the Outlook mobile application. To make a long story short, let’s get straight to the point. There was an Exchange Server 2019 with Exchange Online Hybrid.
I had to integrate Exchange Online with an on-premise DLP system for one of my customers. The goal was that all messages delivered to the Internet must go through a deployed on-premise DLP server.
By default, even if a classical hybrid is deployed, all messages sent to the Internet by cloud mailboxes are delivered by Exchange Online directly to the recipient server. To achieve my goal, I had to override the standard logic.
The logic had to be:
The centralized mail transport option can help with this; this option can be enabled during HCW setup.
With centralized mail transport, you can route all mail from mailboxes in the Exchange Online organization through the on-premises organization before they’re delivered to the Internet.
Setting up a hybrid environment for Exchange can sometimes be a tricky process, especially when dealing with certificates. Recently, I encountered a problem during the Exchange Hybrid Configuration Wizard setup where the certificate from a public certificate authority (CA) was not available for selection. Here’s a detailed account of how I diagnosed and resolved the issue.
While running the Hybrid Configuration Wizard, I noticed that the online certificate I needed wasn’t available for selection, despite having signed certificates displayed. A quick search suggested that the commercial certificate might be incorrectly installed.
This led me to check the certificate using PowerShell and specifically focus on the RootCAType property.
The RootCAType property is crucial in identifying the kind of CA that issued the certificate:
Before diving into the story, let’s cover some essential theory. The domain name is not just a formality; it’s a key element in forming User Principal Names (UPNs) and email addresses. If you’re not planning to use the default domain onmicrosoft.com, you must add your actual domain name in Entra ID (Azure AD). This step is crucial for proper user management and authentication.
However, a domain can only be part of one tenant at a time. If you need to move a DNS domain name between tenants, you must first delete the domain name from the source tenant. The most common reason for such a move is company reorganization, where some groups need to migrate data and resources to a new tenant, bringing their existing domain name with them.
I encountered a similar situation recently.
Here was our starting point:
domain.com as part of their UPN.domain.com registered, allowing users to authenticate with it.temp.com.