Microsoft Exchange, Active Directory & SQL
Exchange emergency? Get a call within 1 hour
Exchange, Active Directory and SQL Server built redundant, backed up and recoverable, and engineers on call when they fail.
Mail, sign-in and data are the three things a company cannot work without, and in most US businesses they run on Microsoft Exchange, Active Directory and SQL Server. Our engineers have designed and operated all three at scale: a Microsoft Exchange platform of more than 100,000 mailboxes across three regions, a 150 TB SQL Server database live in two data centers, and the Active Directory and hybrid Exchange of a global conglomerate's US offices. We bring that experience to companies whose mail or directory is down or under attack, and to companies that want them built so they do not go down.
We show our standard through method and record rather than rankings. The methods are on this page: failover tested by failing things on purpose, patches applied on a published cadence, backups an attacker cannot reach, and restores that are timed. The record is on the track record page, where the Exchange platform, the SQL Server database and recovery cases are described in detail.
At a glance
Our engineers have built and run Microsoft Exchange, Active Directory and SQL Server for global enterprises, a 100,000‑mailbox email platform and a 150 TB risk database. We deliver them fully redundant with tested backups, manage them for you, and respond when they fail or are attacked.
The problem
Exchange, Active Directory and SQL Server sit under everything: mail, sign-in and the data the business runs on. When one fails, or an attacker takes it, the whole company stops, and the people who can fix it are rare. Most outages we are called to have familiar causes: a failed cumulative update, an expired certificate, a database copy nobody monitored, a directory with no tested forest recovery, or privileged accounts that let one stolen password reach everything. We design these systems so that a single failure is a non-event, and we step in when it is already an emergency. If your company has an Exchange or directory emergency right now, use our emergency line at /emergency/.
Exchange emergencies follow patterns. A cumulative update fails and leaves services stopped. A certificate expires and mail flow breaks on a Friday. A single-server deployment loses its disk. An unpatched on-premises server is compromised, as happened across the industry in 2021 with the ProxyLogon and ProxyShell vulnerabilities. Each is recoverable in the hands of engineers who have seen it, and each is far worse if the response is improvisation or a hasty rebuild that destroys evidence.
Active Directory is the same story with a larger blast radius. Whoever controls the directory controls every domain-joined machine, and most attacks that end in ransomware pass through it. Recovery needs a clean directory, rotated Kerberos keys and a redesigned administration model, not only restored servers.
What we deliver
- Exchange DAG design: database copies across two or three sites, a witness placement that survives a site loss, and automatic database failover tested by pulling a server
- Mail flow design: connectors, SPF, DKIM, DMARC and TLS, hybrid routing and certificate lifecycle with automated renewal
- Exchange patching process: security updates and cumulative updates staged, tested and applied on a published cadence
- Exchange migrations: to Exchange Server Subscription Edition, to Exchange Online or hybrid, and from other platforms
- Emergency recovery after compromise, a failed update or database corruption, with a clean rebuild and verification before mail returns
- Active Directory health check: replication, DNS, time, SYSVOL, trusts, FSMO roles, schema and certificate services reviewed, with a ranked fix list
- Privileged access: tiered administration, separate admin accounts, protected admin groups, LAPS and group managed service accounts
- Active Directory compromise recovery: eviction, double reset of the krbtgt account, rebuild of domain controllers and a documented forest recovery runbook
- Group Policy review and cleanup, forest and domain migrations, and Entra ID hybrid identity with sign-in hardening
- SQL Server Always On availability groups with synchronous replicas for failover and asynchronous replicas for disaster recovery
- Backups with point-in-time restore: full, differential and log backups, integrity checks and timed restore tests
- Performance reviews and migrations for SQL Server, PostgreSQL, MySQL and MariaDB, Oracle Database and MongoDB
- A runbook for each platform and a recovery time and point per system, linked to your disaster recovery plan
For Exchange we design for failure. A database availability group keeps several copies of each mailbox database on different servers and, for critical systems, in different sites, with a witness that survives the loss of a site. Redundant mail flow and load-balanced client access remove the single front door. Our three-region platform failed over databases automatically, and the way to prove it is the same on any scale: take the server offline and time what happens.
Backups are a separate design problem. Exchange and SQL Server databases need application-aware backups that truncate logs and can be restored to a point in time, kept in an immutable or offline copy that ransomware cannot alter, and restored on a schedule to prove they work. The diagram on this page shows how recovery point and recovery time targets decide what that design costs.
For Active Directory we start with a health check, because most directories that fail were already unhealthy: replication errors, broken time sync, stale trusts, old domain controllers and sprawling administrator groups. We then separate administration into tiers so a stolen workstation credential cannot reach a domain controller, and we write and rehearse a forest recovery runbook before it is needed. Entra ID and hybrid sign-in are hardened with multi-factor authentication and conditional access.
For SQL Server we build Always On availability groups with synchronous replicas for local failover and asynchronous replicas for another site, with log backups that allow restore to a chosen moment. The same discipline of replication, backups and timed restores applies to PostgreSQL (streaming replication and write-ahead log archiving), MySQL and MariaDB (replication and binary logs), Oracle Database (Data Guard and RMAN) and MongoDB (replica sets), all of which we have operated.
If your company has an Exchange, directory or database emergency, start at our emergency page at /emergency/. Our shop at /shop/ lists fixed-scope assessments for the same systems.
Packages
Microsoft Exchange
Exchange Server Subscription Edition, Exchange Online and hybrid: DAG design with database copies across sites, mail flow, certificates, patching cadence, migrations and emergency recovery after compromise or a failed update.
Active Directory and Entra ID
Health checks, tiered administration, privileged access, Group Policy, forest and domain migrations, Entra ID hybrid identity, and recovery of a directory an attacker has controlled.
Microsoft SQL Server
Always On availability groups, backups with point-in-time restore, performance tuning and migrations, designed to a recovery point and time you choose.
Other databases
PostgreSQL, MySQL and MariaDB, Oracle Database and MongoDB: replication, backups, restore tests and upgrades, run to the same standard.
Emergency response
For an Exchange outage, a directory compromise or a database failure, a security engineer calls you back and takes the incident through containment, recovery and a written debrief. Start at /emergency/.
Managed and redundant by design
We can run the platform for you under our managed services, with monitoring, patching and restore tests on a calendar, or hand over a documented build your team runs.
Mail that keeps flowing
Incoming mail is authenticated and scanned before it reaches anyone, mailboxes are copied across three regions so a server failure goes unnoticed, and outgoing mail leaves signed and encrypted.
Every sign-in, verified
Staff sign in once, but behind the scenes the device, the identity, a phone approval and your access policy are all checked before any app opens, and strangers are turned away.
Backup tiers: data lost versus time to recover
Recovery point objective (RPO) is how much recent data a restore loses; recovery time objective (RTO) is how long the restore takes. Faster tiers sit close to the production system and share its fate; slower tiers survive ransomware and site loss. The scale is logarithmic. Illustrative figures.
Failover in under a second
ISP A fails at 300 ms. BFD (RFC 5880) with a 50 ms interval and multiplier 3 declares the session down 150 ms later, BGP withdraws the routes, and the forwarding table repoints to ISP B. Traffic is back at full rate in well under a second; without BFD the router would wait for the 90 s BGP hold timer. Illustrative figures.
Our process
- 1
Assess
We inventory servers, versions, databases, domains, certificates and dependencies, and measure how long a restore really takes.
- 2
Design
Redundancy across sites, backup copies an attacker cannot alter, and recovery times and points agreed per system.
- 3
Build or migrate
We build the platform, or move you to a supported version, in stages with a rollback at each step.
- 4
Prove
We fail a server, a site and a restore on purpose, time each, and write down what we find.
- 5
Run
Monitoring, patching on a cadence and scheduled restore tests, with a named engineer who knows the environment.
Each stage ends with evidence: a health report, a failover test with timings, a restore log, a runbook that someone other than its author has followed. That evidence is what an insurer, auditor or client security team asks for after an incident, and what the business needs on the day it is required.
Frequently asked questions
Direct answers to the questions we hear most. Something else on your mind?
Send us a messageWe have a Microsoft Exchange emergency. What do we do?
Use our emergency page at /emergency/ or call (800) 767-8566. A security engineer calls you back, asks what is down and what changed, and begins containment. If you suspect compromise, leave servers powered on and do not delete logs; evidence is lost when systems are rebuilt in a hurry.
Can you deliver a fully redundant Exchange environment?
Yes. We design database availability groups with copies across sites, redundant mail flow, load balancing and certificates, and we test failover by taking servers offline. Our track record includes a three-region platform with automatic database failover for more than 100,000 mailboxes.
Should we stay on-premises, go to Exchange Online or run hybrid?
It depends on compliance, mailbox size, integrations and who administers it. Many firms keep a hybrid server for management and some mail flow. We lay out the options with their trade-offs during assessment and then migrate in stages.
Can you recover an Active Directory domain after an attacker controlled it?
Yes. Recovery follows Microsoft's forest recovery guidance: contain, identify what the attacker changed, reset the krbtgt account twice, rebuild or restore domain controllers from a known clean state, rotate privileged credentials and re-tier administration. Backups must predate the intrusion, which is why we test them.
Do you manage SQL Server and other databases?
Yes. We run SQL Server with Always On availability groups and tested point-in-time restores, and we also work with PostgreSQL, MySQL and MariaDB, Oracle Database and MongoDB.
How do you know a database backup works?
By restoring it. Each backup chain is checked for integrity and restored to a separate server on a schedule, and the restore time is recorded against the recovery objective.
How do you show you are best in class?
We point to work rather than rankings: the platforms described in our case studies, the methods on this page and the tests we run and report. Ask to speak with the engineers who would do your work.