MSCE French common mistakes
MSCE French · Understand the traps and how to avoid them.
Designing the database and storage layout (mailbox database per server, log placement, LUN sizing) before calculating IOPS from the user profile, then discovering the disk design cannot sustain the projected load.
Candidates jump straight to a familiar 'one database per 500 users, logs on separate spindles' pattern without first deriving the mailbox IOPS per user for the given profile (e.g. 0.15 IOPS for a light profile versus higher for heavy Outlook users), so the storage design is never validated against capacity and throughput requirements.
What to do instead
Start every storage answer with the workload: users per server, mailbox size, send/receive profile, then compute IOPS, capacity and log growth. Show how the database and log volumes are sized from those numbers and state the resulting design decision (number of databases, LUN layout, RAID choice). The exam rewards the derivation, not the pattern.
Placing the mailbox server role and the Client Access server role on the same machine in every design answer, including edge or perimeter scenarios, without justifying the consolidation.
Candidates memorise the 'multi-role server is supported' fact and apply it universally, forgetting that designs involving Internet-facing clients, load balancing, or a perimeter network usually require separating the Client Access role from the Mailbox role for security and availability reasons.
What to do instead
For each design, state the role placement explicitly and tie it to constraints: internal-only small deployment may consolidate; Internet-facing or load-balanced deployments should separate Client Access from Mailbox and describe the load-balancing method and certificate requirements for the CAS tier.
Choosing a certificate and namespace model that cannot survive a single server failure, e.g. a single name mapped to one CAS without a load balancer or with a certificate missing a SAN entry.
Candidates focus on getting Outlook to connect in the lab and overlook that the design must keep working when one CAS is offline; they also forget that every namespace used by clients (Autodiscover, Outlook Anywhere, OWA, ActiveSync, SMTP) must appear in the certificate SAN list.
What to do instead
Enumerate every client-facing namespace, verify each appears in the certificate SANs, and state the load-balancing mechanism (hardware or Windows NLB) with the health-check behaviour. Explicitly describe what happens to client connections when one CAS is removed from service.
Treating message hygiene as 'install an Edge Transport server and you are done', omitting recipient filtering, sender reputation, connection filtering and the anti-spam agent ordering on the transport pipeline.
Candidates learn the Edge Transport role as a single checkbox and do not study which agents run on the Edge versus the Hub Transport, nor the order in which they fire, so answers describe the role but not the layered filtering design the question asks for.
What to do instead
Describe the layered defence: connection filtering and sender reputation at the perimeter, recipient and sender filtering, content filtering, then transport rules. State which agents run on which server role and the order of evaluation, and explain how the Edge is synchronised with the internal organisation (EdgeSync) for recipient data.
Designing transport rules or journaling that silently fail to capture all required traffic because the rule scope, the journal recipient, or the alternative journal recipient is misconfigured.
Candidates conflate transport rules with journaling and forget that journaling requires a dedicated mailbox (and an alternative journal mailbox for undeliverable journal reports), that journaling captures envelope information, and that scoping rules to internal-only or a distribution group leaves gaps.
What to do instead
Separate the two mechanisms in the answer: journaling for archival/retention with a dedicated journal mailbox and alternative recipient, transport rules for policy (disclaimers, blocking, redirect). Verify the scope covers all senders and recipients required, and describe how journal reports that cannot be delivered are handled.
Answering a perimeter/security question with 'open port 25 to the Mailbox server' instead of placing an Edge Transport server or a subscribed perimeter host in the DMZ.
Candidates default to the simplest topology they know and do not consider that exposing internal Mailbox/Hub Transport servers directly to the Internet violates the intended security boundary the scenario describes.
What to do instead
For Internet mail flow, describe the Edge Transport server in the perimeter, the EdgeSync subscription to the internal Hub Transport, and the one-way communication direction. Explain how internal servers never accept anonymous SMTP from the Internet directly and how the Edge filters before relaying inward.
Designing high availability with a database availability group but forgetting the client-side and namespace requirements, so failover works on paper but clients cannot reconnect.
Candidates focus on the DAG, mailbox database copies and quorum, and omit that the Client Access layer must also be redundant and that the namespace must resolve to a surviving CAS; they also forget file-share or alternate-witness configuration for even-numbered members.
What to do instead
Pair every DAG answer with the CAS redundancy answer: load-balanced namespaces, certificates covering them, and the witness configuration (file share witness or alternate witness server) for even member counts. Walk through a single-server failure and state how clients reconnect and how quorum is maintained.
Confusing backup/restore with recovery: describing a tape backup schedule when the question asks about recovering a deleted mailbox, a deleted item, or a lost server.
Candidates treat 'recovery' as a single topic and do not distinguish item-level recovery (recover deleted items, retention), mailbox recovery (recovery database, dial-tone), and server recovery (restore or rebuild and reseed).
What to do instead
Classify the recovery scenario first: item-level (deleted item retention, recoverable items), mailbox-level (recovery database mounted from backup or from a database copy), server-level (rebuild and reseed from a DAG copy or restore). Give the specific mechanism and its prerequisites for each.
Designing retention policy tags and managed folders without mapping them to the compliance requirement, and without specifying how legal hold overrides deletion.
Candidates learn the mechanics of retention tags (retention policy tags, default tags, personal tags) but not how they interact with litigation hold, journaling and the recoverable items quota, so the design does not actually satisfy a stated retention or eDiscovery requirement.
What to do instead
Start from the requirement (retain all mail for N years, preserve on hold, allow eDiscovery search). Then state which mechanism satisfies it: journaling for the archive copy, retention tags for mailbox cleanup, litigation hold or in-place hold to prevent deletion, and the recoverable items quota to size the dumpster. Explain how hold overrides a delete tag.
Planning a migration as a single cutover without sequencing coexistence, namespace changes, free/busy, and mail flow between the old and new organisations.
Candidates describe the destination environment in detail but skip the transition state, forgetting that during coexistence users in both organisations must see each other's calendars, that Autodiscover and certificates must serve both, and that mail flow requires connectors and accepted domains on both sides.
What to do instead
Write the migration as phases: prepare destination, establish coexistence (connectors, accepted domains, free/busy federation or sharing, certificates covering both namespaces), migrate pilot batch, migrate remaining mailboxes, then decommission source. For each phase state what must be true before the next phase starts and how rollback works.