Case Studies/Richemont
Luxury / Consumer Goods

Exchange 2019 Hybrid Architecture — Multi-National Luxury Group

Designed and implemented Exchange 2019 hybrid architecture for Richemont, including connector hardening, OAuth rebuild, and region-by-region Autodiscover remediation.

RichemontJanuary 2023
Hybrid architecture stabilisedOAuth validated in productionCoexistence routing delivered without incidents
Exchange HybridMigrationOAuthAutodiscoverConnector HardeningMulti-National

Client Context And Challenge

Richemont's messaging environment reflected the operational reality of a multi-national group that had grown through acquisition: Exchange infrastructure distributed across multiple countries, DNS zones delegated independently per region, and an Exchange Online tenant that had been provisioned ahead of a hybrid deployment that was never fully completed. The hybrid configuration that existed at engagement start had been produced by an earlier attempt to run the Hybrid Configuration Wizard — the OAuth trust had been partially established but not validated end-to-end, the send and receive connectors were present but configured without TLS certificate enforcement, and Autodiscover service connection points were inconsistent between regions.

The connector security gap was the most operationally significant issue. The inbound connector from Exchange Online to on-premises was accepting connections without enforcing the Exchange Online Protection certificate — any SMTP source could present itself to the connector and deliver mail into the on-premises organisation. The outbound connector was routing through a smart host configuration that had been left over from a previous third-party mail hygiene product that was no longer in use. Mail flow was functional under normal conditions, but the connector configuration did not meet the security baseline expected for a financial and luxury group with regulatory exposure across multiple jurisdictions.

Autodiscover inconsistency across regions was causing intermittent profile provisioning failures for users in certain country subsidiaries. The root cause varied by region: in some cases, SCP records in Active Directory were pointing to on-premises Autodiscover endpoints that had since been retired; in others, public DNS records for the autodiscover subdomain had been updated to point to Exchange Online but the internal DNS zones had not been updated to match, causing domain-joined clients to resolve to the wrong endpoint. Outlook clients in affected regions were successfully authenticating but receiving incorrect EWS URLs in their Autodiscover response, which caused calendar and Free/Busy failures without producing a clear error visible to the end user.

OAuth configuration had been identified as a prerequisite for enabling several Exchange Online workloads the organisation wanted to use — in-place eDiscovery across the hybrid boundary, cross-premises calendar delegation for executive assistants, and compliance journal routing. None of these workloads were available without a validated OAuth trust between the on-premises Exchange organisation and Entra ID. The partial OAuth configuration from the earlier HCW run had left application registrations in Entra ID in an inconsistent state that could not be repaired incrementally — a clean rebuild was required.

Architecture Design

The hybrid architecture was designed with connector security as the foundational requirement, given the regulatory environment and the existing gap between the configured state and the expected security baseline. The send connector design specified Exchange Online Protection as the smart host, with TLS enforcement using the EOP certificate subject name and the connector restricted to the EOP IP ranges published in Microsoft's Office 365 URL and IP address documentation. The receive connector was scoped to accept connections only from the EOP IP ranges, with TLS required and the connector configured to validate the EOP certificate before accepting the session.

Exchange Hybrid Security Design
Richemont

The hybrid design prioritised secure connectors, validated OAuth, and regionally consistent Autodiscover so cross-border coexistence could support compliance, executive workflows, and stable user provisioning.

Cloud Layer
Exchange Onlinecalendar · eDiscovery · coexistence
EOPTLS-bound mail ingress/egress
Hybrid Trust
OAuthservice principals · modern auth
Hybrid ConnectorsTLS enforcement · IP restriction
Regional Service Discovery
Autodiscover SCPinternal client resolution
DNS Regionalpublic domain alignment
On-Prem Exchange
Exchange 2019regional coexistence routing

The OAuth design addressed the inconsistent Entra ID application registrations by scoping the rebuild to remove the partial configuration entirely before re-running the Hybrid Configuration Wizard in a controlled sequence. The HCW produces two application registrations in Entra ID — one for the on-premises Exchange organisation and one for Exchange Online — along with a service principal for each. The rebuild sequence required removing these objects from Entra ID, verifying the on-premises Exchange OAuth configuration was in a clean state, and then running the HCW to completion in a single maintenance window rather than allowing it to be interrupted. The OAuth validation procedure was defined in advance: a set of test operations — cross-premises Free/Busy, EWS impersonation, eDiscovery search across the hybrid boundary — that would confirm end-to-end OAuth function before the maintenance window was closed.

Autodiscover remediation required a region-by-region audit before any remediation could be designed. The audit used a combination of the Outlook Connectivity Test tool, the Remote Connectivity Analyser, and direct inspection of SCP records in Active Directory and public DNS records for each country domain. Each region was categorised into one of three remediation patterns: SCP correction only (where public DNS was correct but Active Directory SCPs were stale), DNS correction only (where SCPs were correct but public DNS had not been updated), or both (where neither layer had been correctly maintained). The remediation sequence was designed to update internal DNS and SCP records first, validate Autodiscover resolution for domain-joined clients, then update public DNS, validate for non-domain-joined clients, and confirm end-to-end profile provisioning before signing off each region.

Co-existence routing was designed to handle the full set of mail-flow scenarios across the hybrid boundary: on-premises to Exchange Online, Exchange Online to on-premises, external inbound to on-premises mailboxes, and external inbound to Exchange Online mailboxes routing through EOP. Each flow was mapped to its connector pair and validated independently in the test environment before being reproduced in production. The MX record strategy was defined per domain: primary MX records pointing to EOP for all domains, with the on-premises organisation receiving mail from EOP via the hybrid inbound connector rather than via a direct MX entry.

Delivery Approach

Connector hardening was executed first, ahead of the OAuth rebuild and Autodiscover remediation, because it addressed the highest-severity security gap and could be completed with a shorter maintenance window and lower rollback complexity than the other workstreams. The existing send and receive connectors were replaced — not modified — to ensure the resulting configuration matched the design document exactly. The new connectors were created and validated in parallel with the existing ones before the existing connectors were removed, ensuring mail flow was not interrupted during the transition. EOP IP range filtering was applied using the current published IP ranges and a monitoring alert was configured to flag any SMTP connection attempt that was rejected by the new IP restriction — to catch any legitimate mail source that had been missed in the IP range review.

OAuth rebuild ran in a single Saturday maintenance window. The partial application registrations were removed from Entra ID using the Exchange Management Shell and Azure AD PowerShell in sequence. The on-premises Exchange OAuth configuration was cleared using the Remove-AuthServer and Remove-PartnerApplication cmdlets, and the Entra ID application object for the on-premises Exchange organisation was deleted from the Entra ID portal before the HCW was run. The HCW completed without error in the clean environment. Post-HCW validation confirmed the OAuth token exchange for each of the three target workloads: cross-premises Free/Busy returned availability data for a test mailbox in both directions, EWS impersonation from the Exchange Online side resolved correctly, and an eDiscovery search targeting the on-premises content index returned results.

Autodiscover remediation ran across three weeks, one region grouping per week, following the pre-defined remediation pattern for each country. Internal DNS and SCP changes were deployed during business hours — the changes are non-disruptive to existing Outlook sessions, which cache Autodiscover results, and affected only new profile creations and profile updates. Public DNS changes were executed with a 300-second TTL applied 48 hours in advance, allowing rapid recovery if any change produced unexpected resolution behaviour. Each region was signed off using a combination of the Remote Connectivity Analyser Autodiscover test, a manual Outlook profile creation on a non-domain-joined test device in that region, and confirmation that Free/Busy and calendar delegation were functioning for the test accounts. All regions were remediated within the three-week window with no profile provisioning incidents reported after each regional sign-off.

Co-existence validation ran as a structured test pass across all defined mail-flow scenarios before the final cutover sequence was executed. The test matrix covered on-premises to Exchange Online delivery with header inspection, Exchange Online to on-premises delivery with connector logging enabled, external inbound delivery for both mailbox types, NDR handling for non-existent recipients on both sides, and out-of-office response routing. Each scenario was tested using dedicated test mailboxes with no production traffic, and results were logged against the test matrix. The production cutover — updating the MX records for the remaining domains that had not yet been pointed to EOP — was executed only after the test matrix was fully signed off.

Outcomes

The Exchange 2019 hybrid architecture reached a stable, documented, and security-baseline-compliant state across the full multi-national scope. The send and receive connectors operated with TLS enforcement and EOP IP restriction from the completion of the first maintenance window. No mail routing incidents were reported in the weeks following the cutover, and the monitoring alert for rejected SMTP connections produced no unexpected results — confirming that the IP range scoping had not excluded any legitimate mail source.

OAuth function enabled three workloads that had been blocked since the organisation's original Exchange Online provisioning. Cross-premises eDiscovery was immediately used by the compliance team to respond to a pending legal hold request that had required manual data extraction under the previous configuration. Calendar delegation for executive assistants across the hybrid boundary, previously managed through workarounds involving shared mailboxes, was replaced with direct delegation using native Outlook permissions. Both workloads have continued to operate without incident since the OAuth rebuild.

Autodiscover consistency was confirmed across all regions within the three-week remediation window. Profile provisioning on new devices — a process that had been generating service desk tickets in several countries — was reduced to a single Outlook prompt for credentials on first launch, with no additional configuration required from end users. Free/Busy reliability, previously intermittent in the affected regions, was confirmed consistent through two weeks of post-remediation monitoring.

The connector hardening, OAuth rebuild, and Autodiscover remediation were each documented with before-and-after configuration states, test results, and the rationale for design decisions — producing an architecture record that could be maintained by Richemont's internal Exchange administrators without ongoing dependency on the engagement. The co-existence configuration that was delivered had not existed in a documented form before the engagement; its absence had been a contributing factor in each of the original issues, as changes had been made to the hybrid topology without a clear picture of the intended state.

Operational / Business Value

For Richemont, the most important outcome was control over a previously ambiguous hybrid estate. Secure mail routing, validated OAuth, and regionally consistent Autodiscover gave the organisation a coexistence design that could support compliance, executive workflows, and regional support teams without relying on undocumented exceptions.

That operational clarity is what turned the engagement from remediation into a durable platform decision. Internal administrators now have a tested reference state for hybrid messaging, which lowers the risk of future regional changes and gives the group a more reliable foundation for broader cloud messaging strategy.

Start a similar project

Book a discovery call to discuss your Microsoft environment.

Start a similar project
Richemont — Exchange 2019 Hybrid Architecture — Multi-National Luxury Group | TakeItToCloud