Microsoft MS-102: Tenant Deployment and Management

Microsoft MS-102 currently measures the administrator who functions as the integrating hub across Microsoft 365 workloads. That role begins with tenant deployment and administration: organization settings, domains, service health, software updates, adoption, backup, users, groups, licensing, administrative roles, and the processes that keep those elements controlled.

MS-102 is current on October 6, 2026 and retires November 30, 2026 at 11:59 PM CST. This article explains the current tenant-management responsibility without presenting the exam as a long-term evergreen path.

Define tenant ownership and administrative boundaries

Tenant administration should identify which teams own identity, security, compliance, collaboration, endpoints, billing, and service operations, and how tenant-level changes are approved. Map the Microsoft 365 control plane and distinguish broad administrative rights from scoped roles and workload-specific ownership.

Tenant-boundary documentation should survive staff and organizational changes. Assign roles to durable responsibilities and record emergency ownership rather than depending on individual memory.

Tenant administration depends on documentation that survives staff changes. Domain ownership, privileged accounts, delegated roles, emergency contacts, service-health procedures, backup ownership, licensing rules, and automation credentials should not live only in one administrator’s memory. Build a lightweight runbook and test whether another administrator can understand the control plane.

Tenant documentation should survive staff changes. Domain ownership, privileged accounts, delegated roles, automation credentials, backup contacts, and service-health procedures need current owners and review dates rather than living in one administrator’s memory.

Manage domains and organization settings as production changes

Custom domains, organization profile settings, service preferences, and tenant configuration can affect multiple workloads. For a domain or organization-setting change, record dependencies, DNS or verification needs, impact, validation, rollback, and communication.

Domain and organization-setting changes need dependency and rollback notes because a small tenant control can affect identity, mail flow, collaboration, and third-party integrations.

Domains and tenant settings should be treated as shared infrastructure. A custom domain may affect identity, Exchange, Teams, third-party SaaS, and user sign-in. Organization settings can influence service behavior beyond the team making the change. Practice writing a change plan that includes upstream dependencies, downstream consumers, DNS or verification requirements, validation steps, and a rollback decision. This is the kind of cross-workload thinking that distinguishes tenant administration from isolated workload configuration.

Review changes through dependency rather than workload isolation. A licensing change can alter application access; a role change can affect security operations; a domain change can affect identity and mail flow. For one planned change, list upstream prerequisites and downstream consumers to make the integrating-hub responsibility concrete.

Run service health as an operating process

Service health, message center communications, network connectivity, and workload incidents require triage, impact assessment, communication, and escalation. MS-102 tenant configuration and lifecycle frames those events as ongoing operations rather than a list of settings: affected users, business impact, vendor status, workaround, owner, and closure evidence all matter.

Service-health operations should capture impact, Microsoft status, workaround, communication, and closure evidence. A platform incident is not automatically a configuration problem.

Service health requires an operating rhythm. Create a simple incident record containing detection time, affected users, impacted workloads, Microsoft status, internal symptoms, workaround, communications, owner, and closure evidence. The record should make it obvious whether the problem is tenant-specific or part of a wider service issue. During study, include at least one scenario where the correct administrative choice is to monitor and communicate rather than modify production settings.

For the tenant-administration capstone, create a current-state runbook another administrator could use during your absence. Include ownership, privileged access, domain dependencies, service-health procedures, automation, backup contacts, and retirement-aware exam notes. Any section you cannot document confidently identifies an operational gap.

Control users, groups, and licensing

User and group lifecycle affects access, application behavior, collaboration, compliance scope, and cost. Licensing adds service availability and entitlement considerations. For a joiner, role change, and leaver, define account state, group membership, licenses, administrative roles, data ownership, and cleanup.

User and group lifecycle is strongest when authoritative business events drive account state, licenses, roles, data ownership, and cleanup instead of ad hoc requests.

Tenant governance should also include review cadence. Some controls change frequently, such as licensing and group membership; others change rarely but carry high risk, such as emergency accounts, domains, global roles, and automation credentials. Create different review intervals based on risk and change frequency rather than one annual checklist. Record the owner, evidence, and action when a review finds stale or unjustified configuration. This produces an operational governance model that can scale as the tenant grows instead of relying on occasional cleanup projects.

Administrative hygiene is part of normal operations. Stale groups, unused domains, abandoned applications, old automation, and unjustified roles increase complexity and risk. Remove them through an evidence-based process with an owner and rollback path.

Delegate administration with least privilege

Microsoft 365 roles, Entra roles, role groups, administrative units, and privileged-access processes provide different ways to delegate. For each administrative team, identify required actions, durable scope, activation needs, emergency path, and review cadence.

Delegation review should compare administrative convenience with blast radius. Broad roles are easy to assign and harder to justify, monitor, and contain after compromise.

Tenant administration begins with an ownership model. Broad administrative roles may be necessary for a small number of emergency scenarios, but most recurring work can be delegated more narrowly. Build a role matrix that lists task, scope, frequency, required privilege, activation method, approval if any, and review cadence. The exercise makes least privilege concrete and helps expose situations where a team was given a broad role simply because the exact administrative responsibility was never documented.

Connect tenant management to identity

Tenant operations depend on authentication, synchronization, Conditional Access, and user access. Review Microsoft 365 identity and secure access when a tenant problem crosses into sign-in or policy evaluation. Distinguish tenant configuration ownership from deeper identity design so the right team receives the right evidence.

When tenant operations cross into identity, include sign-in and policy evidence with the handoff. A user complaint alone is not enough technical context.

Close the tenant-operations model by connecting administration to user experience. Service changes, license assignments, identity problems, and security controls all appear to users as availability or access issues. A strong administrator can translate that complaint into tenant state, evidence, owner, and next action without making unnecessary changes. Practice writing concise support notes that explain both the technical state and the business impact. That communication skill is part of operating Microsoft 365 well, even though it is not represented as a single portal feature.

Make backup and recovery explicit

Microsoft 365 administration includes protected content, backup scope, recovery objectives, restore permissions, testing, and communication. Choose a high-value data set and define what loss scenario backup addresses, how restore is requested, how long it may take, and who validates the restored state.

Backup planning should name the loss scenario, restore authority, expected recovery time, validation owner, and evidence that recovered content is usable.

Review the tenant runbook after major changes so it reflects current roles, dependencies, automation, and recovery contacts. A document that is accurate only when written is not a control; a maintained runbook is part of reliable administration.

Recovery planning should identify who can request a restore, who authorizes it, which data is in scope, and how the restored state is validated. A successful backup job is only evidence that a copy exists; it does not prove the tenant can recover the right information within the required time.

Use automation without hiding risk

PowerShell and Microsoft Graph can scale tenant operations, but permissions, error handling, idempotency, logging, and change control matter. Automate one bounded task and document what happens when the script runs twice, encounters a partial failure, or operates on the wrong input set.

Automation should be treated like a privileged administrative system: least privilege, logging, safe retries, owner, and emergency stop matter as much as script logic.

Automation also belongs in the tenant control plane. A script that changes licenses or group membership can have consequences across applications, compliance, and cost. Test automation for incorrect input, partial failure, duplicate execution, expired credentials, and insufficient permission. Log enough information to reconstruct what changed. If the script fails halfway through, the recovery procedure should be known before the workflow is trusted for routine administration.

Operate the current role with the retirement date visible

Tenant-management skills remain useful beyond an exam code, but candidates must plan around the actual availability of MS-102. Review the current April 28 blueprint and November 30 retirement date before building a long preparation timeline; preserve notes around durable tenant responsibilities.

Keep exam retirement separate from tenant skill. MS-102 has an end date; the need for well-governed Microsoft 365 operations continues.

Finally, run a tenant hygiene review. Look for stale administrative assignments, unused domains, abandoned groups, old automation credentials, legacy applications, unnecessary licenses, and policies without clear owners. Removing obsolete configuration is part of administration because accumulated exceptions make the tenant harder to secure and troubleshoot. Document the evidence required before removal and monitor for unexpected dependency failures. That discipline remains useful regardless of the MS-102 retirement date.

Keep retirement scheduling separate from tenant operations. The exam has an end date, but reliable ownership, service health, least-privilege administration, backup, automation, and change management remain ongoing responsibilities.