MS-102: Tenant Administration Without Drift

A Microsoft 365 tenant can look orderly on the day it is deployed and become difficult to govern a year later. Employees move between teams, contractors retain guest access, administrators accumulate exceptions, licenses remain assigned after departures, and an acquired company brings a second directory with a different naming scheme. The work is not simply to configure Microsoft 365 once. It is to keep the administrative model accurate while services, people, and business expectations change.

Tenant deployment and management forms a major part of MS-102. Microsoft has announced that this examination retires on November 30, 2026; the material here describes the skills measured under the April 2026 outline, not a promise of indefinite exam availability. More important, the underlying administration discipline remains useful regardless of that deadline.

A tenant boundary is an ownership decision

Consider an engineering firm acquiring a regional consultancy. The acquiring company uses Microsoft 365 with established security controls, while the smaller firm has a different email domain, inconsistent group ownership, and several unsupervised guest accounts. A common mistake is to treat this as a purely technical domain-addition task. Before any configuration changes, decide who owns the directories, which identities may remain external, how mail routing will work, and who approves access to confidential projects.

Tenant information includes verified domains, organization settings, service subscriptions, and administrative roles. Custom-domain setup requires attention to DNS ownership, existing mail dependencies, and propagation. A rushed change to a domain’s records can disrupt communications that existed before the Microsoft 365 project began. Work in a controlled sequence, understand verification requirements, and document rollback options for any change that affects production mail.

A tenant is also a security boundary for policies, logs, and data services. Combining business units into one tenant can simplify common controls while concentrating privilege. Keeping separate tenants may preserve organizational separation but complicate identity collaboration and administration. The correct structure follows legal, security, operational, and migration needs rather than convenience in one admin center.

User and group lifecycle is where drift accumulates

The simplest user-provisioning workflow is not necessarily the safest. A new hire might require a mailbox, a Teams membership, access to one departmental SharePoint location, and an endpoint license. Giving them the same broad groups as their predecessor can import permissions accumulated over years. Provision from a role-based model, then handle exceptions with explicit approval and expiry.

Microsoft 365 groups, security groups, distribution lists, and shared mailboxes serve different functions. A Microsoft 365 group may provide a collaboration boundary across services; a distribution list exists primarily for message distribution; a shared mailbox supports a shared communication identity with delegated access. Choosing the wrong object type can complicate both user experience and access reviews. The association with MS-700 is relevant when collaboration administration becomes a dedicated responsibility, but a tenant administrator still needs to understand these cross-workload effects.

Departures need more than disabling an account. Transfer ownership of business documents, determine retention obligations, remove session access and active credentials as appropriate, review delegated mailbox rights, and reconcile subscriptions. External guests and application identities may have separate review cycles. A reliable joiner-mover-leaver process records the owner of each decision and tests whether obsolete privileges truly disappear.

Licensing should be explainable at group and user level

Licenses control access to capabilities, and some services depend on combinations of assignments and plans. An apparent service malfunction may be a missing license, a disabled service plan, a provisioning delay, or an access policy decision. Troubleshooting should inspect the effective assignment and the workload’s requirements before assuming the cloud platform is broken.

Group-based licensing can reduce repetitive work, but its results depend on group membership and assignment rules. A nested-group assumption or overlapping policy can create unexpected outcomes. Bulk changes should be previewed and verified, especially during acquisitions when hundreds of users may be remapped between licensing groups. Successful automation means the intended user gained the correct capabilities without retaining unneeded entitlements.

License optimization is not just reducing expense. Removing a service plan while a project depends on its compliance or protection features can create a governance gap. Finance and engineering need a shared understanding of which features support legal obligations, security controls, and business-critical applications. A lower subscription total is not a success if it quietly removes essential safeguards.

Delegated administration must be narrower than convenience

Global administrative access makes many tasks easy and nearly every mistake consequential. Define roles by function and assign them to people who need them. Support staff may require user reset capabilities without broad compliance access; endpoint operators need device-management roles rather than authority over retention settings; security analysts may need investigation rights without the ability to change every protection policy.

Administrative units can help delegate rights over scoped populations where the product and role support that scope. Privileged Identity Management provides options for controlled activation and review of elevated roles, depending on licensing and configuration. A role assignment should be tested from the viewpoint of the delegated administrator: which users and objects can they actually manage? Do not assume that a role name alone proves least privilege.

Emergency access deserves careful design. Accounts intended for recovery must be protected, monitored, regularly tested, and separated from failure conditions they are supposed to survive. Making a permanent exception that nobody reviews is not resilient administration. Document how emergency use is authorized, how it is investigated afterward, and how the tenant returns to ordinary privilege controls.

Service health and adoption tell different stories

A service health alert can reveal a provider-side incident affecting a workload, while a complaint from one employee may stem from device configuration, identity policy, networking, or licensing. Administrators should compare the user experience with current service advisories and their own change records. Microsoft 365 service health and notifications are useful, but they cannot diagnose every tenant-specific problem by themselves.

Network connectivity insights provide another perspective when users experience slow or unreliable access to cloud services. Identify whether the issue is localized to an office, route, DNS resolver, proxy, or client population. A blanket statement that ‘Microsoft 365 is slow’ is not actionable. Evidence about where the path degrades allows a proportionate response and prevents unnecessary global policy changes.

Adoption and usage reports measure behavior, not automatically business value. A rise in Teams activity may reflect productive collaboration or extra meetings. An inactive license may be legitimate for a temporary leave, a service account, or a retention-related operational need. Combine quantitative reports with ownership and business context before changing entitlements or claiming that a deployment succeeded.

PowerShell and Graph turn repeatable intent into controlled action

Manual editing is feasible for a few users; it is fragile for a migration involving thousands. Microsoft Graph PowerShell and relevant Entra tools can help enumerate objects, compare state, and perform bulk changes. Automation should begin with a read-only discovery phase, explicit change inputs, scoped permissions, and an output log that allows the operator to reconcile what changed.

Review how scripts are authorized as well as how they are written. A deployment operator should not need broad permanent directory privileges merely to read licensing status. Use role assignments that fit the task, maintain a change record, and ensure someone other than the author can review consequential updates. When automation fails halfway through a batch, reconciliation reports should distinguish users already changed from those still pending. Blindly rerunning the entire input set can create duplicate objects or reverse earlier corrections.

A script that ‘creates all missing groups’ is dangerous if names collide, required owners are unknown, or it interprets a transient API error as proof that an object does not exist. Design for retries, pagination, throttling, and idempotence. Keep secrets out of source files and limit service identities. Prefer a small test population before executing in production. The team’s rollback method must account for changes that cannot simply be reversed without side effects.

Version changes also matter. Cmdlets, endpoint permissions, and service behavior evolve, so scripts should be maintained against supported interfaces rather than copied indefinitely from an old study exercise. Logging inputs and results makes it possible to distinguish a programming defect from an authorization failure or an external service condition.

An operating model should also say how tenant settings are reviewed after a migration or major policy rollout. Assign an owner to each cross-workload setting, define what constitutes an unauthorized deviation, and decide how exceptions expire. A monthly review of privileged roles, orphaned groups, unused service identities, and license-assignment failures can reveal problems that individual support requests never surface. This is a more effective safeguard than assuming the migration is finished because users can send email.

Recoverability depends on data ownership and testing

Microsoft 365 backup and retention capabilities have different purposes and service requirements. Backup addresses defined recovery needs; retention governs how specified information is preserved or disposed of under policy. A retention rule is not automatically a complete replacement for operational backup, and a restored object may not recreate every permission, integration, or business process that depended on it.

Plan for accidental deletion, malicious changes, service disruption, and loss of administrative access. Test representative restores with correct permissions and demonstrate who can request them. For an acquired company, verify that newly migrated information is protected under the intended retention and recovery settings before declaring the migration complete.

An MS-102 candidate should learn to trace a tenant task from request through object change to evidence. A sound answer says who is permitted to make the change, what it affects, how it will be tested, and how mistakes will be contained. That discipline prevents a cloud tenant from drifting into an arrangement nobody fully understands.