Exchange Online

Before M365, organizations ran their own Exchange Server on physical servers they owned and maintained. Exchange Online is the same software but Microsoft runs the infrastructure.

ADMIN CENTER: admin.exchange.microsoft.com — where you manage everything Exchange-related.

You will create and manage shared mailboxes constantly. Understand them thoroughly.

CRITICAL: Convert to shared mailbox BEFORE removing the license during offboarding. If you remove the license first → mailbox is deleted → you can't convert it → data lost. Order: Convert to shared mailbox → THEN remove the license.

Email was designed in the 1970s with no security. Anyone can send email claiming to be from anyone. SPF, DKIM, and DMARC are the three DNS-based defenses against this.

THE PROBLEM: email spoofing When you get an email from "security@yourbank.com," nothing in the original email design prevents a criminal from putting any address they want in the From field. Without authentication, every email address is forgeable.

SPF (Sender Policy Framework) A DNS record listing which mail servers are authorized to send email for your domain. When an email arrives claiming to be from company.com, the receiving server checks company.com's SPF record: "is this message from an authorized server?" If not, it's suspicious.

Example: v=spf1 include:spf.protection.outlook.com -all "Emails from our domain come from Microsoft's Exchange servers. Reject anything else."

DKIM (DomainKeys Identified Mail) Adds a cryptographic signature to every outgoing email. The signature is verified using a public key in DNS. Proves: the email genuinely came from your domain AND wasn't modified in transit. Like a wax seal on an envelope — intact seal means it came from the right sender and wasn't opened.

Together: SPF says who's allowed to send. DKIM proves authenticity. DMARC enforces consequences for failure.

The most common request: "I accidentally deleted an important email. Can you get it back?" Here's exactly how deletion works and how to recover it.

THE THREE LAYERS:

Layer 1 — Deleted Items Folder When a user "deletes" an email, it moves to Deleted Items. Still fully visible, fully recoverable by the user themselves. Not actually gone at all.

Layer 2 — Recoverable Items (the hidden folder) When a user "permanently" deletes (empties Deleted Items or uses Shift+Delete), it doesn't disappear. It moves to a hidden folder called Recoverable Items that users can't see in normal Outlook.

Default retention: 14 days. After that, it's gone — unless a retention policy is active.

Layer 3 — Compliance Archive (Retention Policies) If your organization has a retention policy (common in regulated industries), emails are preserved regardless of what the user does. Even if deleted and aged out of Recoverable Items, it's still in the compliance archive.

To access: compliance.microsoft.com > Content Search > New Search Search by sender, recipient, subject, date, or keywords. Export results.

PRACTICAL ANSWER: If someone asks "can you recover this email?" — almost always yes, as long as policies exist. If no retention policy: 14-day window. With a 7-year retention policy: emails from 7 years ago are recoverable.

Mail flow rules (transport rules) apply to every email passing through the organization. Unlike inbox rules users set up for themselves, mail flow rules are admin-configured and users can't see or override them.

WHERE TO CONFIGURE: Exchange admin center > Mail Flow > Rules

After this rule is active, every email from outside your organization automatically gets "[EXTERNAL]" prepended to the subject. When a user sees an email that looks like it's from their CEO but has "[EXTERNAL]" in the subject — they know something is wrong immediately.

This single rule is one of the most effective anti-phishing technical controls you can deploy.

Goal: Create support@company.com — a shared inbox three support team members can all read and reply from.

Step 1 — Create the shared mailbox Exchange admin center > Recipients > Mailboxes Click "Add mailbox" > Shared mailbox Display name: Support Team Email address: support@company.com Click Save

Step 2 — Grant permissions to the three team members Click on the "Support Team" mailbox to open properties "Manage Full Access" > Add all three support staff > Save "Manage Send As" > Add the same three people > Save

Step 3 — Outlook picks it up automatically Within about an hour, the shared mailbox appears automatically in Outlook for users with Full Access. If it doesn't appear automatically: File > Account Settings > Exchange account > More Settings > Advanced > Add > type "Support Team"

Step 4 — Test it Have one team member send a test email from the shared mailbox. The From field should show support@company.com, not their personal email.

Step 5 — Managing access going forward When a team member leaves: click the shared mailbox > Manage Full Access > remove their name > Save. Also remove from Send As. They immediately lose access — no other changes needed.

Beyond Full Access and Send As (covered earlier), Exchange Online has a richer permission model worth understanding fully — especially the third permission type that trips people up constantly.

THE THREE MAILBOX PERMISSIONS:

Full Access Lets someone open and use another mailbox as if it were their own — read, reply, organize folders, everything except sending mail AS that address (that needs Send As too). This is what you grant a manager over an assistant's mailbox, or an admin over a shared mailbox.

Send As Lets someone send mail that shows the FROM address as the other mailbox — recipients see no difference between an email the actual owner sent and one sent by the delegate. No indication in the message that someone else sent it.

Send on Behalf The one people forget exists. Similar to Send As, but the recipient sees "Delegate Name on behalf of Mailbox Name" in the From field — a visible indicator that someone else sent the message on the owner's behalf, rather than it looking identical to the owner sending it themselves.

WHY THE DISTINCTION MATTERS: Send As is invisible — good for shared team mailboxes like support@company.com, where you WANT every reply to look like it's uniformly from "the support team," not from whichever individual happened to answer. Send on Behalf is transparent — good for an executive assistant sending on a manager's calendar or mailbox, where accountability and traceability matter and hiding who actually hit send would be a problem, not a feature.

GRANTING THESE PERMISSIONS: All three are managed per-mailbox in the Exchange admin center (or via PowerShell for bulk operations). None of them require an additional license for the mailbox being granted permission TO — only the mailbox being accessed needs its own valid license (or qualifies as an unlicensed shared mailbox under 50GB).

FOLDER-LEVEL PERMISSIONS — GOING MORE GRANULAR: Full Access grants access to the entire mailbox. Sometimes you want finer control — access to just the Calendar, for instance, without exposing someone's entire inbox. This is set from within Outlook itself (right-click the folder → Properties → Permissions tab) rather than through the admin center, and supports levels like Reviewer (read-only), Editor (create/modify/delete items), and several others. This is the mechanism behind calendar delegation — letting an assistant manage a manager's calendar without granting Full Access to their whole mailbox.

Not every group in Exchange is about permissions — distribution groups exist purely to make sending email to many people at once simple, without anyone needing to know or type every individual address.

STANDARD DISTRIBUTION GROUPS: A named email address (like allstaff@company.com) that fans out to every member's individual mailbox when someone sends to it. Membership is a static, manually maintained list — you add and remove people explicitly, the same way you'd manage a security group.

Distribution groups have NO security function at all — they cannot be granted permissions to files, sites, or resources. Their only job is mail distribution. If you need both email distribution AND resource permissions from the same group, that's what a Mail-Enabled Security Group is for (covered in the M365 topic).

DYNAMIC DISTRIBUTION GROUPS — THE SELF-MAINTAINING VERSION: Instead of a manually maintained membership list, a dynamic distribution group's membership is calculated automatically every time a message is sent to it, based on a filter you define against user attributes — department, office location, job title, or any other Active Directory/Entra ID property.

Example: a dynamic group filtered on Department equals "Sales" automatically includes every current Sales employee, with zero manual maintenance. New hire joins Sales and gets their department attribute set correctly? They're automatically included in the next email sent to that group, no admin action required. Someone transfers out of Sales? They automatically stop receiving those emails. This eliminates the extremely common real-world failure mode of static distribution lists silently going stale — new employees never added, departed employees never removed — because there's no static list to go stale.

WHEN TO USE WHICH: Static distribution group — for lists that don't map cleanly to an attribute (a cross-department project team, a volunteer committee, an ad hoc event invite list). Dynamic distribution group — for anything that naturally maps to an organizational attribute someone's HR/directory data already tracks (all managers, everyone in a specific office, everyone with a specific job title). If the membership logic can be phrased as "everyone where X equals Y," it should almost always be dynamic rather than manually maintained.

MODERATION — CONTROLLING WHO CAN SEND: Both group types support moderation, where messages sent to the group are held for an approver's review before being distributed. Useful for large all-staff-style groups where you want to prevent accidental (or unwanted) messages from reaching the entire organization unchecked.

Every mailbox has a storage limit, and understanding how Exchange Online handles approaching and exceeding that limit — plus the tools for extending it without just buying more storage — is a routine part of the job.

THE DEFAULT QUOTA STRUCTURE: Exchange Online mailboxes come with generous default storage (commonly 50GB or 100GB depending on the license plan) and a THREE-STAGE warning system as a mailbox fills up:

Issue Warning — the user gets a notification email that they're approaching their limit, but everything still works normally. Prohibit Send — the user can no longer send new mail, but can still receive incoming mail and manage what's already there. This is the stage that actually starts causing real problems for someone's daily work. Prohibit Send/Receive — the mailbox is completely full. Incoming mail bounces back to senders with a non-delivery report, and the user can't send either. This is a genuine emergency for whoever's affected.

THE ARCHIVE MAILBOX — THE MAIN TOOL FOR MANAGING SIZE: Rather than making users manually delete old email to stay under quota (which risks losing things people actually needed), Exchange Online supports an In-Place Archive — a secondary mailbox, separate from the primary, used specifically for older items. Once enabled, users see it as an additional expandable node in Outlook, right alongside their normal mailbox, and can drag items into it or set up Retention Policies to move items there automatically based on age.

Depending on the license, the archive can be unlimited in size, meaning a user effectively never needs to worry about running out of space again as long as they're willing to let older mail live in the archive rather than the primary mailbox.

AUTO-EXPANDING ARCHIVE: For extremely heavy mailboxes, Exchange Online can automatically grow the archive in increments once it approaches its own limit, rather than requiring an admin to manually intervene. This is typically an opt-in feature enabled at the organization level.

Retention in Exchange Online isn't just about compliance paperwork — it directly determines whether an email an employee tries to permanently delete is actually gone, or quietly recoverable months later. Understanding the layers here matters both for compliance and for everyday "can you get that email back" requests.

RETENTION POLICIES — RULES ABOUT HOW LONG TO KEEP THINGS: A retention policy defines how long content is retained (and what happens after that period — delete it, or just stop enforcing retention on it). Policies are built from Retention Tags, individually configured rules like "delete items in Deleted Items after 30 days" or "retain items in Inbox for 3 years, then delete."

Retention policies can apply organization-wide or be scoped to specific users, groups, or even specific types of content (all email mentioning certain keywords, for instance, in more advanced configurations). This is how organizations in regulated industries enforce "we must keep all email for 7 years" as an automatic, unbypassable system rule rather than relying on individual employees to remember and comply manually.

THE CRITICAL DISTINCTION — RETENTION VS. DELETION: A retention policy set to retain content does NOT stop a user from clicking delete. What it does is silently preserve a copy in the background regardless of what the user does in their own mailbox view. The user experiences normal delete behavior; behind the scenes, compliance has what it needs preserved regardless.

LITIGATION HOLD — THE STRONGER TOOL: When a specific legal matter requires preserving everything related to a particular mailbox — a lawsuit, an HR investigation, a regulatory inquiry — Litigation Hold goes further than a standard retention policy. It preserves ALL mailbox content, including items a user permanently deletes, edits, or that would otherwise have expired under a normal retention policy. Litigation Hold can be applied indefinitely or for a specific duration, and importantly, the user is typically NOT told their mailbox is under hold — informing them could itself constitute evidence tampering in some legal contexts.

WHY THIS MATTERS PRACTICALLY: When someone asks "can you recover this old email," the honest answer depends entirely on what retention or hold applies to that mailbox. No policy at all: standard 14-day Recoverable Items window, then genuinely gone. An active retention policy: likely recoverable for however long that policy specifies, sometimes years. An active Litigation Hold: essentially always recoverable, since deletion doesn't actually remove anything while the hold is active. Before ever telling someone "sorry, that's gone," check what's actually configured — it's almost always more recoverable than users assume.

Calendars in Exchange Online aren't just personal scheduling tools — they're a core piece of how organizations coordinate meetings, and understanding sharing levels plus resource mailboxes is essential admin knowledge.

CALENDAR SHARING LEVELS: Users can share their own calendar with colleagues at different visibility levels, from most to least restrictive: Availability only (Free/Busy) — others see only whether a time slot is free or busy, no details about what the meeting actually is. This is the DEFAULT visibility every user in the organization has into every other user's calendar automatically — no explicit sharing required. Limited details — free/busy status plus the subject and location, but not the full body or attendee list. Full details — everything, as if the person were looking at their own calendar. Editor — full details, plus the ability to create, modify, and delete calendar items on the person's behalf. This is what powers assistant/manager calendar delegation.

RESOURCE MAILBOXES — BOOKING ROOMS AND EQUIPMENT: A Room Mailbox represents a physical space (a conference room), and an Equipment Mailbox represents a bookable, shared physical asset (a projector, a company vehicle). Neither requires a license. Users book them the same way they'd invite a person to a meeting — by adding the resource's address as an attendee.

AUTOMATIC BOOKING PROCESSING: Resource mailboxes have a special setting called the booking policy, controlling how invitations are handled: Auto-accept — the resource automatically approves any booking request that doesn't conflict with an existing reservation, and automatically declines anything that does. This is the most common setup for straightforward meeting rooms, since it requires zero human involvement. Require approval — a designated resource delegate must manually approve or deny each booking request. Useful for high-demand or restricted resources (an executive boardroom, an expensive piece of shared equipment) where you don't want fully automatic booking.

CONFIGURING BOOKING LIMITS: Room mailboxes support additional constraints: maximum meeting duration, how far in advance bookings can be made, whether recurring meetings are allowed to claim the room indefinitely, and capacity limits (so the system can suggest alternate rooms if a meeting has more attendees than a room holds). These are configured via PowerShell using the Set-CalendarProcessing cmdlet, since the Exchange admin center's graphical interface doesn't expose all of these options directly.

Every phone, tablet, or third-party mail app connecting to a mailbox does so through a protocol called Exchange ActiveSync (EAS) — and controlling that access is a genuine security responsibility, not just a convenience feature.

WHAT ACTIVESYNC ACTUALLY DOES: ActiveSync is the synchronization protocol that lets a mobile device pull down email, calendar, and contacts, and push local changes back to the server — read receipts, sent replies, calendar edits made on the phone, all syncing bidirectionally. It's what makes a phone's mail app behave like a real-time window into the mailbox rather than a periodic, manual check.

MOBILE DEVICE MAILBOX POLICIES: Admins can create policies enforced on any device connecting via ActiveSync — requiring a device PIN or biometric lock, enforcing minimum password complexity, setting an auto-lock timeout, and critically, enabling remote wipe capability. These policies apply the moment a device tries to connect; a device that doesn't meet the policy can be blocked from syncing entirely until it complies.

REMOTE WIPE — THE CRITICAL SECURITY TOOL: When a device is lost, stolen, or an employee leaves the organization, an admin can issue a remote wipe from the Exchange admin center or Entra ID. This can be scoped two ways: Full wipe — resets the entire device to factory settings, erasing everything, personal data included. Appropriate for company-owned devices. Selective wipe (via Intune/mobile device management, not plain ActiveSync alone) — removes only company data and the managed mail profile, leaving the user's personal photos, apps, and data untouched. This is the appropriate choice for personal devices under a Bring Your Own Device (BYOD) policy, where wiping someone's entire personal phone over a work email account would be a serious overreach.

BLOCKING ACTIVESYNC ENTIRELY: Organizations with stricter security requirements sometimes block ActiveSync access altogether, forcing mobile access through a managed app (like the Outlook mobile app under Intune App Protection Policies) instead of the native mail app on the device. This trades some user convenience for significantly more granular control — Intune App Protection can enforce things like "no copy-paste of company data into non-approved personal apps" that plain ActiveSync policies can't touch at all.

TROUBLESHOOTING A DEVICE THAT WON'T SYNC: Check the device's ActiveSync partnership in the Exchange admin center under the user's mailbox — it lists every device that has ever connected, along with last sync time and policy compliance status. A device stuck in "Pending" typically means it's waiting for admin approval (if quarantine mode is enabled) or failing to meet the mobile device policy requirements.

Moving mailboxes into Exchange Online — whether from an on-premises Exchange server, another cloud provider, or consolidating from an acquired company's environment — follows a small number of well-established migration patterns, each suited to different situations.

CUTOVER MIGRATION: Moves ALL mailboxes from an on-premises Exchange server to Exchange Online in a single batch operation. Simple and fast, but appropriate only for smaller organizations (Microsoft's practical guidance caps this around a few hundred mailboxes) since everything happens at once with limited ability to stage the rollout.

STAGED MIGRATION: Moves mailboxes in planned batches over time rather than all at once — useful for larger organizations that need to migrate department by department, or want to validate the process on a small pilot group before committing everyone.

HYBRID MIGRATION — THE MOST COMMON ENTERPRISE PATTERN: Rather than a one-time cutover, hybrid migration establishes an ongoing coexistence between on-premises Exchange and Exchange Online, with free/busy lookups, mail flow, and directory information working seamlessly across both environments during a transition period that can last months or indefinitely. This requires deploying Entra Connect (for identity sync) and the Hybrid Configuration Wizard, and is the standard approach for organizations too large for a cutover but that need users on both sides to keep working together normally throughout the migration — a Sales team already migrated to the cloud needs to still see accurate free/busy time and exchange mail seamlessly with a Finance team still on-premises.

IMAP MIGRATION: For moving from a non-Exchange mail system (older on-premises mail servers, some third-party hosted email providers) that supports the IMAP protocol. More limited than the Exchange-native migration types — it moves email itself, but not calendar items, contacts, or tasks, since IMAP as a protocol was never designed to carry that data.

THIRD-PARTY / CROSS-TENANT MIGRATION: For moving mailboxes between two separate Microsoft 365 tenants entirely (common after a company acquisition, where the acquired company's M365 tenant needs to be consolidated into the parent company's tenant) or from non-Microsoft cloud providers. These typically require a specialized third-party migration tool rather than Microsoft's built-in migration wizards, since neither tenant natively has visibility into the other's directory.

CHOOSING THE RIGHT APPROACH: Small organization, one-time full move, can tolerate some downtime → Cutover Larger organization needing a controlled, phased rollout → Staged Enterprise needing extended coexistence between cloud and on-premises → Hybrid Coming from a non-Exchange mail system → IMAP (with the caveat that calendar/contacts need separate handling) Merging two separate M365 tenants → Third-party cross-tenant migration tool

Before a single email ever reaches a mailbox, Exchange Online Protection (EOP) runs it through multiple layers of filtering — understanding this pipeline helps you troubleshoot both "why did legitimate mail get blocked" and "why is spam still getting through."

THE FILTERING PIPELINE, IN ORDER: Connection Filtering — the very first check, based purely on the SENDING SERVER's IP address, before any message content is even examined. Checks against IP allow lists, IP block lists, and real-time block lists maintained by Microsoft and third-party reputation services. A sending server with a bad reputation can be rejected here before the message content is ever evaluated at all.

Anti-Malware — scans attachments and message content for known malware signatures.

Anti-Spam (Content Filtering) — evaluates the actual message content, sender reputation, and dozens of other signals to calculate a Spam Confidence Level (SCL) score, determining whether the message is legitimate, likely spam, or definitely spam.

Anti-Phishing — specifically targets impersonation and phishing patterns: spoofed sender addresses, lookalike domains, suspicious links, and content patterns matching known phishing techniques.

WHAT HAPPENS BASED ON THE VERDICT: Depending on the confidence level and organization's configured policies, a message can be delivered normally, delivered to the Junk Email folder, quarantined (held for admin or user review before any delivery decision), or rejected outright with the sending server notified.

THE QUARANTINE — WHERE "MISSING" LEGITIMATE MAIL OFTEN HIDES: When a user says "I never got that email," quarantine is one of the first places to check, not just Junk Email. Microsoft Defender for Office 365's Quarantine page shows every message held for review, why it was flagged, and lets an admin (or, if permitted, the end user themselves) release a legitimate message that was incorrectly caught.

ALLOW AND BLOCK LISTS: Organizations maintain both organization-wide and per-user safe/blocked sender lists. An organization-wide allow entry for a trusted vendor's domain prevents their legitimate bulk email from repeatedly getting flagged. Be cautious with broad allow entries though — an allow-listed domain that later gets compromised becomes a direct, unfiltered path into every mailbox in the organization, since filtering is explicitly bypassed for anything on the list.

TUNING FALSE POSITIVES VS. FALSE NEGATIVES: Every anti-spam configuration is a tradeoff. Stricter filtering catches more real spam but risks blocking more legitimate mail (false positives); looser filtering lets more legitimate mail through cleanly but risks more spam reaching inboxes (false negatives). There's no setting that eliminates both risks simultaneously — tuning is about finding the right balance for your organization's actual risk tolerance and user complaint patterns.

Data Loss Prevention policies scan outgoing (and sometimes internal) email for sensitive information — and can automatically block, warn, or encrypt messages based on what they find, without relying on users to remember not to send sensitive data insecurely.

WHAT DLP ACTUALLY DETECTS: DLP policies use "sensitive information types" — built-in pattern-matching definitions for things like credit card numbers, Social Security numbers, bank account numbers, and dozens of other regulated data patterns, plus support for custom patterns an organization defines itself (a specific internal project code format, for instance). Detection isn't simple keyword matching; it uses pattern recognition and, for some types, checksum validation (a credit card number pattern that fails the checksum an actual credit card number would pass isn't flagged as a false match).

WHAT DLP CAN DO WHEN IT FINDS SOMETHING: Depending on policy configuration, a DLP match can trigger a range of actions, from least to most restrictive: Notify only — the sender gets a policy tip warning them before sending, but the message goes through regardless if they proceed. Require justification — sender must provide a business reason before the message is allowed to send, creating an audit trail even for permitted exceptions. Block with override — the message is blocked, but the sender can override the block after acknowledging a warning (with the override itself logged for compliance review). Block outright — the message simply cannot be sent, no user override available at all. Automatically encrypt — rather than blocking, the message is sent but automatically wrapped in encryption (via Microsoft Purview Message Encryption), since the underlying business need to communicate the information is often legitimate, and encryption satisfies the compliance requirement without stopping the business process.

POLICY TIPS — CATCHING THE PROBLEM BEFORE IT HAPPENS: One of DLP's most valuable features is the Policy Tip that appears directly in Outlook while a user is composing a message, before they even hit send — flagging that the content they're about to send matches a sensitive pattern. This catches accidental oversharing (someone pasting a spreadsheet of customer SSNs into an email body without thinking about it) at the moment of the mistake, rather than after the fact.

WHERE DLP POLICIES APPLY: Beyond Exchange email, the same DLP framework in Microsoft Purview extends to SharePoint, OneDrive, Teams messages, and even endpoint devices under advanced licensing — meaning a well-designed DLP policy protects sensitive data consistently across every channel it might leak through, not just email specifically.

The Exchange admin center handles most day-to-day tasks, but PowerShell is where you go for bulk operations, advanced configuration options the graphical interface doesn't expose, and anything you need to script or automate.

CONNECTING TO EXCHANGE ONLINE POWERSHELL: Install-Module -Name ExchangeOnlineManagement Connect-ExchangeOnline -UserPrincipalName admin@company.com This installs Microsoft's official Exchange Online PowerShell module and establishes an authenticated session — after connecting, all the Exchange-specific cmdlets become available in that PowerShell session.

MAILBOX MANAGEMENT COMMANDS: Get-Mailbox -Identity user@company.com | Select DisplayName, PrimarySmtpAddress, ProhibitSendQuota Get-MailboxStatistics -Identity user@company.com | Select DisplayName, TotalItemSize, ItemCount Set-Mailbox -Identity user@company.com -ProhibitSendQuota 90GB New-Mailbox -Shared -Name "Support Team" -DisplayName "Support Team" -PrimarySmtpAddress support@company.com

PERMISSIONS COMMANDS: Add-MailboxPermission -Identity "Support Team" -User jsmith@company.com -AccessRights FullAccess Add-RecipientPermission -Identity "Support Team" -Trustee jsmith@company.com -AccessRights SendAs Get-MailboxPermission -Identity "Support Team" | Where-Object {$_.User -n"NT AUTHORITY/SELF"}

DISTRIBUTION GROUP MANAGEMENT: New-DistributionGroup -Name "All Sales" -PrimarySmtpAddress sales@company.com Add-DistributionGroupMember -Identity "All Sales" -Member jsmith@company.com Get-DistributionGroupMember -Identity "All Sales"

MAIL FLOW AND MESSAGE TRACE: Get-MessageTrace -SenderAddress jsmith@company.com -StartDate (Get-Date).AddDays(-2) -EndDate (Get-Date) Get-TransportRule | Select Name, State, Priority

BULK OPERATIONS — WHERE POWERSHELL GENUINELY SHINES: # Set out-of-office for a departed employee across their whole mailbox Set-MailboxAutoReplyConfiguration -Identity jsmith@company.com -AutoReplyState Enabled -InternalMessage "No longer with the company. Contact manager@company.com" -ExternalMessage "No longer with the company. Contact manager@company.com"

# Convert every mailbox in a specific OU-derived list to shared mailboxes Get-Content "departed_users.txt" | ForEach-Object { Set-Mailbox -Identity $_ -Type Shared }

# Find every mailbox over 40GB for capacity planning Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics | Where-Object {$_.TotalItemSize -gt 40GB} | Select DisplayName, TotalItemSize

WHY THIS MATTERS BEYOND CONVENIENCE: Anything you'd need to do to 5, 50, or 500 mailboxes at once is realistically only practical through PowerShell — the graphical admin center is built around one-mailbox-at-a-time workflows. Comfort with these basic patterns is what separates being able to handle routine single-user requests from being able to handle organization-wide changes efficiently.

Not every IT staff member managing Exchange Online needs — or should have — the same level of access. Role-Based Access Control (RBAC) lets you assign exactly the permissions someone needs for their actual job, nothing more.

THE RISK OF OVER-PRIVILEGED ADMIN ACCESS: If every helpdesk technician is made a full Exchange Administrator just so they can reset a user's password or unlock a mailbox, you've handed them the ability to also delete any mailbox, modify organization-wide mail flow rules, or export any user's entire email — vastly more access than their actual job requires. RBAC exists specifically to avoid this kind of unnecessary privilege sprawl.

BUILT-IN ADMIN ROLES: Exchange Administrator (Global level, via Entra ID) — full control over the entire Exchange Online organization, equivalent to what most people picture as "Exchange admin." Helpdesk Administrator — can perform common support tasks (password resets, some mailbox configuration) without the ability to touch organization-wide mail flow settings, compliance configuration, or delete mailboxes. Recipient Administrator — manages mail-enabled objects (mailboxes, groups, contacts) without access to compliance, mail flow rules, or organization-wide settings. Compliance Administrator — manages retention policies, DLP, and eDiscovery, without needing the ability to modify mailboxes or mail flow at all. Security Reader — read-only visibility into security-related configuration and reports, appropriate for auditors or security team members who need visibility without change authority.

CUSTOM MANAGEMENT ROLES — WHEN BUILT-IN ROLES AREN'T GRANULAR ENOUGH: For organizations with more specific needs, Exchange Online supports fully custom management role groups, built from individual management role entries (each entry grants a specific, narrow set of cmdlets and parameters). This lets you construct, for instance, a role that can view mailbox statistics and reset out-of-office messages but genuinely cannot do anything else — a level of precision the built-in roles don't offer.

ADMINISTRATIVE UNITS — SCOPING BY ORGANIZATIONAL BOUNDARY: For larger organizations (a university with separate IT teams per college, a company with regional IT staff), Administrative Units let you scope an admin role to only a specific subset of users or mailboxes — a regional helpdesk admin can be granted Helpdesk Administrator rights, but scoped ONLY to the mailboxes belonging to their region, with zero visibility or access to mailboxes elsewhere in the organization.

THE PRACTICAL PRINCIPLE — LEAST PRIVILEGE APPLIED TO ADMIN ROLES: The same "give only what's needed for the job" logic that applies to regular user permissions applies doubly to admin roles, since admin accounts are higher-value targets and cause more damage if compromised. Before granting someone Exchange Administrator by default because it's the familiar option, it's worth asking whether Helpdesk Administrator or a scoped custom role would actually cover what their job requires.

Your organization just finished renovating a conference room and needs it available for booking through Outlook, with automatic approval for standard requests but manual review for anything unusually long.

Step 1 — Create the room mailbox Exchange admin center > Recipients > Rooms & equipment > Add room Display name: "Executive Conference Room" Email address: execroom@company.com Capacity: 12

Step 2 — Configure the booking policy Since most bookings should auto-approve, but you want manual review for meetings longer than 4 hours (to prevent one team from monopolizing the room all day), this requires PowerShell since the graphical interface doesn't expose duration-based conditional approval:

Set-CalendarProcessing -Identity execroom@company.com -AutomateProcessing AutoAccept -BookingWindowInDays 180 -MaximumDurationInMinutes 240 -AllowRecurringMeetings $false

This sets: automatic acceptance for meetings up to 4 hours (240 minutes), bookable up to 180 days in advance, and blocks recurring meetings from claiming the room indefinitely.

Step 3 — Designate a delegate for exceptions For anything exceeding the auto-accept limits, designate someone to manually review and approve on a case-by-case basis:

Set-CalendarProcessing -Identity execroom@company.com -ResourceDelegates "facilities@company.com"

Step 4 — Test the booking flow Have a test user create a meeting invite, add "Executive Conference Room" as a resource. For a normal 1-hour meeting, confirm it auto-accepts within a few minutes. For a 5-hour meeting, confirm it goes to the delegate for manual approval instead of auto-accepting.

Legal has notified IT that an employee is involved in litigation, and their entire mailbox — including anything they delete going forward — must be preserved starting immediately. The employee should not be informed.

Step 1 — Verify the request through proper channels Confirm this request is coming through your organization's actual legal/compliance process, not an informal request — litigation holds have real legal weight and should never be applied casually based on an unverified request.

Step 2 — Apply Litigation Hold to the mailbox Exchange admin center > Recipients > Mailboxes > select the user > Manage litigation hold (or via PowerShell for a more precise, scriptable action):

Set-Mailbox -Identity jsmith@company.com -LitigationHoldEnabled $true -LitigationHoldDuration Unlimited

Setting duration to Unlimited means the hold remains active until someone explicitly removes it — appropriate when the litigation timeline isn't yet known.

Step 3 — Confirm the hold applied correctly Get-Mailbox -Identity jsmith@company.com | Select LitigationHoldEnabled, LitigationHoldDuration

Step 4 — Do NOT modify the user's normal experience The user continues working normally — sending, receiving, organizing, even deleting email exactly as before. Litigation Hold works silently in the background; there's no visible indicator in their Outlook that anything has changed, which is intentional. Do not mention the hold to the employee unless legal specifically instructs otherwise.

Step 5 — Document the action Record who requested the hold, when it was applied, the legal matter it relates to (in general terms, not necessarily case specifics if that's sensitive), and confirmation it was successfully verified as active. This creates the audit trail legal/compliance will likely need later.

Step 6 — When the matter concludes Legal will eventually notify IT the hold can be released. At that point: Set-Mailbox -Identity jsmith@company.com -LitigationHoldEnabled $false Only remove the hold on explicit instruction from legal/compliance — never proactively, even if it seems like the matter should be over, since IT typically doesn't have full visibility into a legal case's actual status.

Multiple users report that a legitimate weekly newsletter from a trusted vendor keeps landing in Junk Email instead of the inbox, despite it being a real business communication they want to receive.

Step 1 — Check where it's actually landing Confirm it's genuinely in Junk Email (spam filtering catching it) rather than being quarantined entirely (a stronger block) — these require different fixes. Check the Microsoft Defender Quarantine page to rule out quarantine first.

Step 2 — Check the sender's authentication Look up the vendor's domain and verify their SPF, DKIM, and DMARC records are properly configured. Sometimes the actual root cause is on the SENDER's side — their email isn't properly authenticated, making it look suspicious to any receiving mail system, not just yours. If that's the case, the real fix is asking the vendor to fix their own email authentication, and a local allow-list entry is only a temporary workaround.

Step 3 — Add an organization-wide allow entry (if the sender is legitimately trustworthy) Microsoft 365 Defender > Policies & rules > Threat policies > Anti-spam policies > edit the inbound policy > Allowed and blocked senders/domains > add the vendor's sending domain

Step 4 — Consider a mail flow rule as a stronger override If the anti-spam allow list alone doesn't fully resolve it (sometimes multiple filtering layers each need addressing), a transport rule can be set to bypass spam filtering entirely for messages from that specific verified domain: Exchange admin center > Mail flow > Rules > New rule Condition: sender domain is [vendor's domain] Action: Set the spam confidence level (SCL) to -1 (this value tells the filtering system to treat the message as definitely not spam, regardless of what other signals might suggest)

Step 5 — Be deliberate about scope Only allow-list the specific sending domain actually in question — resist the temptation to broadly allow-list an entire email provider (like all of a bulk email service) just because one legitimate sender uses it, since that same infrastructure could easily be used by unrelated spam senders too.

Step 6 — Confirm and monitor Have affected users watch for the next scheduled newsletter to confirm it now lands in the inbox. Periodically review allow-list entries over time — a domain that was legitimate when added can be compromised or repurposed later, so allow-lists shouldn't be treated as "set once, forget forever."

Exchange Online enforces limits on message size and sending volume — understanding these prevents confusing "why won't this send" tickets and helps you set realistic expectations for bulk email needs.

MESSAGE SIZE LIMITS: By default, Exchange Online caps individual message size (including attachments) at 150MB, though the practical usable limit is often lower once you account for the roughly 33% size increase that happens when attachments are base64-encoded for email transport — a 100MB attachment can actually consume significantly more of that limit than its raw file size suggests.

These limits exist at multiple levels: organization-wide, per-connector (for specific mail flow paths, like a connector to a partner organization), and per-recipient in some configurations. A message can be rejected at any of these levels even if it satisfies the others, so troubleshooting an oversized-message rejection means checking all the applicable limits, not just the most obvious one.

WHY LARGE FILES SHOULD GO THROUGH ONEDRIVE/SHAREPOINT INSTEAD: Rather than raising size limits to accommodate large attachments, Outlook automatically offers to upload large files to OneDrive and insert a sharing link instead of an actual attachment, once a file crosses a certain size threshold. This is genuinely the better solution in most cases — recipients get a link rather than a bulky attachment clogging their own mailbox quota, the file stays centrally managed and editable, and it sidesteps size limit issues entirely.

RECIPIENT AND RATE LIMITS — PREVENTING ABUSE AND ACCIDENTS: Exchange Online enforces limits on how many recipients a single message can be sent to, and how many messages/recipients an account can send within a rolling 24-hour period. These exist primarily to prevent a compromised account from being used to blast spam to thousands of recipients, but they also catch honest mistakes — someone accidentally sending a company-wide announcement to a personal contact list with thousands of external addresses would hit these same limits.

WHAT HAPPENS WHEN AN ACCOUNT HITS SENDING LIMITS: An account that exceeds normal sending patterns can be automatically throttled (temporarily restricted from sending further mail) or in more severe cases, flagged for review as a potentially compromised account — a legitimate reason a user's ability to send mail can suddenly and mysteriously stop working, tracing back to unusual sending volume rather than any configuration change. Checking the account's recent sign-in activity and sent mail volume is a standard troubleshooting step whenever a user reports sending suddenly not working with no apparent cause.

WHEN LEGITIMATE BULK EMAIL NEEDS EXCEED THESE LIMITS: Organizations with genuine legitimate need for large-scale outbound email (marketing newsletters, mass customer communications) should use a purpose-built bulk email service rather than relying on individual mailbox sending limits, which are deliberately not designed for that use case. Trying to work around throttling limits for legitimate bulk mail from a regular mailbox is the wrong tool for the job, not just against the rules.

Some organizations — particularly in regulated industries like finance and healthcare — need a complete, tamper-evident copy of all email flowing through the organization, sent to a separate system entirely independent of what individual mailboxes contain. This is what journaling exists for.

WHAT JOURNALING ACTUALLY DOES: A journal rule automatically sends a copy of every message matching its scope — sent, received, or both — to a designated journaling mailbox or, more commonly in mature compliance setups, to an external third-party archiving and eDiscovery platform. This happens completely independently of whatever the actual sender or recipient does with their copy of the message; even if they immediately delete it and it's genuinely gone from their mailbox forever, the journaled copy already exists elsewhere, untouched by anything the end user does.

WHY JOURNALING IS DIFFERENT FROM RETENTION POLICIES: Retention policies (covered earlier) preserve content within the user's own mailbox structure. Journaling creates an entirely separate, independent copy the moment a message is sent or received, routed to a different destination altogether. Organizations sometimes use both together — retention policies for general internal compliance, journaling for a completely independent, external record that satisfies stricter regulatory requirements (financial services regulations often specifically require this kind of independent, tamper-evident record).

JOURNAL RULE SCOPE: Journal rules can be scoped globally (every message in the organization), to a specific journaling mailbox recipient group, or even to internal-only or external-only message flows depending on what a specific regulation actually requires being captured.

THIRD-PARTY ARCHIVING PLATFORMS: Many regulated organizations route journaled mail to specialized third-party compliance archiving platforms (rather than an internal journaling mailbox) that provide additional capabilities Exchange Online's native tools don't fully cover — long-term immutable storage guarantees, specialized eDiscovery search tools built for legal review workflows, and audit trails proving the archive itself hasn't been tampered with. Exchange Online's journal rules are typically configured to forward journaled content to these external systems via a dedicated connector, rather than replacing them.

THE PRACTICAL TAKEAWAY: If you're supporting an organization in a regulated industry and notice a "journaling mailbox" or unfamiliar compliance-related mail flow rule, don't disable or modify it without understanding what regulatory requirement it satisfies first — these configurations often exist specifically because of legal/regulatory obligations, not just organizational preference, and disabling one without proper authorization could create real compliance exposure.