Hybrid Exchange 2019 lab from scratch: the full plan
Nine phases, the order that binds them, what you need before you start, and the six traps that cost an evening. With the step-by-step build manual.
Building a hybrid Exchange 2019 lab — two mailbox servers in a DAG, perimeter transport in a DMZ, a load balancer, synchronisation to Microsoft 365 — takes a week of evenings and nine phases that must happen in order.
This guide is the plan: what you need before starting, why the order is what it is, and the six traps that cost you dearly. Every command lives in the build manual.
What you need before the first command
| Item | Requirement |
|---|---|
| Hypervisor | Proxmox VE 9, 32 GB of RAM, SSD storage |
| Memory | 38 GB at full tilt — you work in power-on groups |
| Licences | None: Exchange in Standard Evaluation, Windows in evaluation |
| Tenant | Microsoft 365 with a verified public domain, to carve a subdomain from |
| Time | A week of evenings. The hybrid is the long part |
The nine phases, and why that order
Each phase exists because the next one needs it. Jumping ahead breaks things that look completely unrelated.
- Host and machines. Isolated bridges, sizing, CPU limits. And the time zone, which goes in immediately.
- Firewall. Before everything else: without routing between segments, no machine sees any other.
- Domain. Forest, DNS, Active Directory recycle bin, UPN suffix, time hierarchy.
- Identity. Organisational units and attributes must be settled before creating users.
- Exchange. Schema, first server, second server, databases, DAG, connectors.
- Perimeter. Needs Exchange installed and the clock aligned.
- Load balancer. Needs both Exchange servers listening.
- Hybrid. Needs everything else, plus a verified domain.
- Verification. The power-on order and the checklist.
Two points in that order are not negotiable.
Identity before users. Moving objects between organisational units after synchronisation is live generates deletions in the cloud: to Entra Connect, an object leaving the scope is indistinguishable from an object that has disappeared.
The time zone before anything. It is the cheapest step in the plan and the most expensive to recover from.
The six traps
Each cost real time during the build, and none announces itself with an error that names it.
1. The guests’ time zone
The hypervisor presents Windows guests a clock expressed in the host’s local time. A guest configured for a different zone deduces the wrong UTC, and does so again at every reboot.
It breaks certificates, Kerberos and the DAG, and the error you see talks about authentication. The full story: Nine hours off.
2. Disk drivers during Windows setup
Setup cannot see the disk unless you give it the second CD-ROM with the VirtIO drivers. This is where you get stuck on the first attempt, before installing anything at all.
3. The five-database limit counts copies too
The Standard edition allows five mailbox databases per server, and the limit counts databases present, copies included.
Worse: installing the second server creates its own default database, consuming a slot. Remove it before creating your own, otherwise the fourth will not fit and the error arrives halfway through the job.
4. A CN that differs from the samAccountName
Add-MailboxPermission resolves by samAccountName, Add-ADPermission by object name. If the two diverge, the first works and the second fails with wasn't found: you get a script that assigns half the permissions without stopping.
Settle it when you create the first user, because fixing it later means renaming already-synchronised objects. The other two surprises hiding in the scripts are in Three assumptions an Exchange script never states.
5. The three pfSense boxes
Block private networks and Block bogon networks on the WAN discard administrative traffic before any rule, when the “WAN” is really a private LAN. The DNS Hostname field must stay empty: putting an IP address there breaks resolution even though routing is fine. And Filter rule association set to None performs the NAT and blocks the traffic.
Three settings, three faults that look like they have other causes.
6. The scheduler that switches itself off
In the Entra Connect wizard, leaving the Start the synchronization process when configuration completes box unticked makes the program disable the scheduler. It happens on every run of the wizard, and it happened three times during the build.
From the outside it looks as though synchronisation is broken. Re-enable it by hand:
Set-ADSyncScheduler -SyncCycleEnabled $trueThe two design choices that change everything
The rest is execution; these two decide whether the lab is worth anything.
Routed /29 segments, not one flat network. In production the load balancer and the Exchange servers sit on different networks, and that is the condition making SNAT mandatory — with the consequence that Exchange cannot see the real sender’s address. On a flat network the phenomenon does not exist, and a lab that fails to reproduce it cannot be used to study it.
Load balancing at layer 4, not 7. In TCP mode the TLS handshake crosses the balancer intact and reaches Exchange. In HTTP mode the balancer would terminate the connection, and the TLS phenomena under study would disappear.
What not to reproduce, and why
A useful lab declares its gaps. Three things were left out on purpose:
The Hybrid Configuration Wizard, if the tenant carries real mail: it writes organisation-level connectors. Skipping it means giving up part of the hybrid behaviour, and it is the right call.
An internal PKI, if in production the service certificate comes from a public CA: it would reproduce something that does not exist.
The service certificate, unobtainable for a lab domain. Certificates stay self-signed, and this must be declared when reading results: “the browser complained” and “it did not work” are different outcomes, and only one of them is a fault.
Lab built with the support of Ilie.