Skip to content
BytePath
BytePath v0.0.35

Microsoft 365 Administration

Cloud administration pathAvailable

Design and change a small Microsoft 365 tenant through identity, policy, collaboration, device, and audit decisions.

Difficulty
Intermediate
Time
180 min
Practice
Pilot an MFA policy safely
Assessment
Knowledge check

Before you start

Who is this for?

For aspiring Microsoft 365 administrators who want to understand dependencies instead of clicking through isolated portal blades.

Prerequisites

  • Basic identity and networking concepts
  • A non-production test tenant with appropriate licensing

What you'll be able to do

  • Distinguish Entra identity from application data
  • Plan MFA and Conditional Access pilots
  • Explain Exchange, Teams, SharePoint, OneDrive, and Intune roles
  • Use audit and sign-in logs
  • Define rollback and emergency access

Practical outcome

You can design a small, documented tenant change with a pilot group, evidence, and rollback path.

Microsoft 365 is a set of services connected by identity, policy, data, and device state. A change to authentication can affect Exchange, Teams, SharePoint, mobile access, and automation. Treat the tenant as an environment with dependencies, not as a collection of unrelated apps.

1. Identity and Entra ID

Section titled “1. Identity and Entra ID”

Users, groups, devices, applications, roles, and sign-in policies live in the identity plane. Use groups to express scope and avoid assigning broad administrator roles when a delegated role is sufficient. Keep an inventory of test accounts, emergency access accounts, owners, and expiry dates.

2. MFA and Conditional Access

Section titled “2. MFA and Conditional Access”

MFA adds an authentication factor; Conditional Access evaluates signals such as user, device, location, application, and risk before applying a control. Start in report-only or equivalent evaluation mode, use a small pilot group, test expected and denied paths, and keep an emergency access process that is monitored and deliberately excluded where appropriate.

A policy is not successful because it saved in the portal. Check sign-in logs, client compatibility, and the user experience, then document rollback.

3. Exchange Online

Section titled “3. Exchange Online”

Mail flow has senders, recipients, connectors, transport rules, authentication, DNS, and filtering. A message can be accepted by a client but fail later in transport or policy. Use message trace and headers to separate client, DNS, transport, and recipient issues. Avoid broad allow rules when a scoped exception is possible.

4. Teams and collaboration

Section titled “4. Teams and collaboration”

Teams combines identity, membership, meetings, messaging, files, policies, and external access. SharePoint sites and OneDrive storage underpin many files. Define ownership, lifecycle, guest access, retention expectations, and the difference between sharing a link and granting a durable permission.

5. Intune and devices

Section titled “5. Intune and devices”

Device management depends on enrollment, identity, platform support, compliance policy, configuration profiles, applications, and conditional access. Pilot with known devices. A device can be enrolled yet non-compliant, configured yet not receiving a profile, or compliant while an application still fails.

6. Protection and audit

Section titled “6. Protection and audit”

Use audit, sign-in, device, alert, and message evidence according to the licenses and services available. Minimise retention and access to logs, protect sensitive data, and document who reviews alerts. Security controls are only useful when owners respond to their results.

7. Safe change model

Section titled “7. Safe change model”

For every tenant change, record:

  1. purpose and affected identities;
  2. prerequisites, licence assumptions, and dependencies;
  3. pilot scope and expected result;
  4. positive and negative tests;
  5. monitoring evidence;
  6. rollback command or policy change;
  7. owner, review date, and expiry.

Practical scenario

Section titled “Practical scenario”

In a test tenant, create two test users and a pilot group. Apply an MFA policy in evaluation mode, test a normal sign-in and a blocked condition, inspect sign-in logs, and document how you would disable the policy. Do not use real users or production data.

What you should be able to do now

Section titled “What you should be able to do now”

You should be able to explain how identity, policy, application, device, and audit state interact, and plan a tenant change that can be tested and reversed.