MS-721 common mistakes
MS-721 · Understand the traps and how to avoid them.
Picks a single PSTN connectivity option for the whole tenant (for example Microsoft Calling Plans at every site) early in the design, before checking number availability, number portability, or the carrier and SBC contracts that already exist at each site.
The four PSTN options are easy to revise as a comparison table, so candidates reproduce the table instead of deriving the design from the scenario's per-site constraints. Exam scenarios usually contain at least one site that cannot use the 'native' option.
What to do instead
Build a site-by-site matrix first: country/region, user count, existing carrier or SBC, number availability for Calling Plans and Operator Connect, and emergency-calling obligations. Then assign an option per site and document where Direct Routing, Operator Connect, and Calling Plans legitimately coexist in one tenant.
Designs the voice and meeting workload without mapping network regions, sites, and subnets, and without a QoS or media-bypass plan, then validates the design only from one well-connected client.
Network design feels like infrastructure work rather than Teams administration, and in a lab tenant everything works from a single subnet, so the missing topology stays invisible until location-based routing or dynamic emergency calling is switched on.
What to do instead
Model regions, sites, and subnets with New-CsTenantNetworkRegion, New-CsTenantNetworkSite, and New-CsTenantNetworkSubnet; run the Network Planner and the Teams network assessment; define DSCP markings plus media bypass on the SBC path; and state explicitly which subnets are trusted versus which home and VPN ranges are not.
Treats emergency calling as a post-go-live switch-on, relying on the default emergency address and never building emergency locations, per-site routing, or a notification and conference policy.
Emergency calling is a small slice of the objectives and the blades sit under Voice in the Teams admin centre, so candidates assume the default address is sufficient and a test call from a correctly addressed admin account gives a false pass.
What to do instead
Enumerate buildings and floors into validated emergency locations, decide dynamic versus static locations based on whether subnets can be mapped reliably, design the emergency calling policy (notification recipients, conference join) and the emergency call routing policy per site, and schedule an end-to-end test call from a standard client before cutover.
Changes a value in the tenant-wide Teams meeting settings or in the Global meeting policy and assumes every user's behaviour changed, without checking whether users were granted a custom meeting policy or a policy package.
Tenant settings and the Global policy are the first things you see in the admin centre, and in a small test tenant the Global policy is the only one in effect, so the assumption survives until a pilot with real users.
What to do instead
For every meeting change, check the effective policy per user (Get-CsOnlineUser -Identity | Select-Object TeamsMeetingPolicy), list the custom meeting policies and policy packages in the tenant, change the policy that actually applies, and re-verify after policy propagation.
Chooses the event type out of habit, scheduling an interactive all-hands as a regular meeting or a registration-driven session as a standard meeting, and only discovers during rehearsal that attendee capacity, attendee moderation, registration data, or organiser licensing do not match the requirement.
Meetings, webinars, and town halls share the same scheduling surface and look nearly identical to the organiser, so the choice is made before capacity, interactivity, registration, presenter control, and recording requirements are written down.
What to do instead
Write the requirements first: expected attendees, whether attendees speak or only watch, whether registration and lead capture are needed, who presents, and what must be recorded. Map that to meeting versus webinar versus town hall, confirm the licensing each type requires for the organiser, and rehearse with a small pilot event before the real one.
Creates an auto attendant or call queue and assigns it a phone number, but skips one of the prerequisites: the Microsoft Teams Phone Resource Account licence on the application instance, a number assigned to that resource account, or the association between the resource account and the auto attendant or call queue.
The resource account is a separate object from the call-flow object, and in the wizard-driven admin centre it is easy to build the call flow and never open the account behind it. The number then rings nowhere, or the object cannot be enabled.
What to do instead
For every auto attendant and call queue, confirm the resource account exists, holds the Microsoft Teams Phone Resource Account licence, has a number assigned with Set-CsPhoneNumberAssignment, and is associated with the call-flow object. Then dial the number from an external line rather than from inside the tenant.
Writes dial plan normalisation rules and tests them with a single number format, usually the fully qualified or E.164 form, then deploys, so users who dial a short extension, a local number, or an international prefix match no rule at all.
Normalisation is a set of regular expressions evaluated in order, and the person testing usually knows the correct format. The failure only appears with the untidy formats real users actually dial.
What to do instead
Enumerate every format users will dial (short extension, local, national, international, with and without leading access digits), confirm each is matched by a rule and normalised to E.164, check rule ordering and the dial plan actually granted to the user, and repeat the test on a desk phone and a mobile client.
Builds each routing object separately, creating a PSTN usage, a voice route, and a voice routing policy, but never confirms that the usage is referenced by the route, the route is listed in the policy, and the policy is granted to the users who need it.
Every cmdlet or blade succeeds in isolation, so nothing surfaces as an error until a user dials and the call has no route. Candidates also verify against the Global policy instead of the user's effective policy.
What to do instead
Trace the chain in order (usage, then route, then voice routing policy, then grant) and read the user's effective policy with Get-CsOnlineUser instead of assuming Global applies. Extend the same end-to-end check to the SBC with Get-CsOnlinePSTNGateway, verifying FQDN, certificate name match, and signalling IPs, then place test calls per site in both directions.
Creates the Teams Rooms or shared-device account like a normal user, leaving it inside Conditional Access policies that require multi-factor authentication and a compliant device and under a standard meeting policy, then troubleshoots the hardware when sign-in or meeting join fails.
The account is an ordinary user object in Entra ID, so it inherits every tenant-wide and group-scoped policy, and a multi-factor prompt cannot be answered on a meeting room console.
What to do instead
Give room and shared-device accounts their own group and exclude that group from user-focused Conditional Access policies (or author a dedicated policy), assign the correct Teams Rooms licence (Pro versus Basic) and a meeting policy that permits the required meeting features, then confirm calendar and mailbox access works before the device ships to site.
Provisions and configures each device individually through the device's own settings menu, with no configuration profile, no device tag or grouping, and no update ring, so every settings change means physically visiting or remoting into each room or phone.
Manual setup works for the first device in a pilot and the device list in the admin centre invites one-off edits. The cost, and the inability to roll back, only appears at scale or when a setting must be reverted across the estate.
What to do instead
Define configuration profiles in the Teams admin centre and assign them by device tag or account, use the Teams Rooms Pro Management portal for inventory, health, and update scheduling, and push settings and firmware to a pilot group before the rest of the estate.