MS-102Chapter 66 of 104Objective 1.4

Exchange Mobile Device Policies (OWA)

This chapter covers Exchange mobile device policies, specifically those applied through Outlook on the web (OWA). For the MS-102 exam, understanding how to manage mobile device access via OWA mailbox policies is critical because it appears in approximately 5-8% of questions under Tenant Management (Objective 1.4). You will learn the exact settings, default values, and enforcement mechanisms that the exam tests, including how these policies differ from Mobile Device Management (MDM) and ActiveSync policies. Mastery of this topic ensures you can configure and troubleshoot mobile access in Exchange Online environments.

25 min read
Intermediate
Updated May 31, 2026

OWA Policies as Security Bouncers for Mobile Email

Imagine a high-security corporate building with a single public entrance. Employees can enter through that door (OWA) from anywhere in the world, but the building has strict rules about what they can bring inside. The building manager (Exchange Admin Center) posts a list of policies at the door: no devices without a passcode, no devices older than 90 days, and no devices that allow copying data to external drives. A security bouncer (the OWA mailbox policy) checks every employee's device against this list before they can enter. If a device fails a policy—say, it has no screen lock—the bouncer either blocks entry (block access) or allows entry but confiscates the device's ability to save attachments (block download). The bouncer also enforces rules about what employees can do once inside: they can read emails but cannot forward them to external addresses or use the 'reply all' feature. If an employee tries to bypass the bouncer by using a different entrance (e.g., a mobile app), the bouncer still checks the same policy list because all entrances are linked. The policy is applied to the entire building, not per employee, so everyone sees the same rules. This analogy mirrors how OWA mailbox policies in Exchange Online apply settings like 'Require device encryption', 'Max inactivity time lock', and 'Allow external recipients' to all users assigned the policy, enforced at the protocol level when accessing mail via OWA or mobile devices.

How It Actually Works

What Are OWA Mailbox Policies and Why Do They Exist?

OWA mailbox policies are a set of configuration rules applied to user mailboxes that control the features and security behaviors of Outlook on the web (formerly Outlook Web App). They exist because organizations need to enforce security and compliance policies on web-based email access, especially from mobile devices and unmanaged browsers. Unlike full MDM solutions, OWA policies are lightweight and apply at the Exchange Online level, requiring no device enrollment. The MS-102 exam focuses on these policies as a key tenant management tool.

How OWA Mailbox Policies Work Internally

When a user accesses their mailbox via OWA (https://outlook.office.com), the Exchange Online front-end server evaluates the OWA mailbox policy assigned to that user. The policy is stored as an object in Exchange Online and contains a set of Boolean, integer, and string parameters. The evaluation occurs at the start of each OWA session, and the policy settings dictate what UI elements are visible and what actions are permitted. For example, if the parameter -AllowExternalSenders is set to $false, the OWA interface will not show the option to add external recipients in the To field. The policy is retrieved from the user's mailbox properties via the Get-CASMailbox cmdlet, which shows the OwaMailboxPolicy property. The default policy is named "Default" and is applied to all users who do not have a custom policy.

Key Components, Values, Defaults, and Timers

OWA mailbox policies contain dozens of parameters. The MS-102 exam tests the following critical ones: - -AllowExternalSenders: Default $true. When $false, users cannot send email to external (non-tenant) recipients via OWA. - -BlockExternalImages: Default $true. When $true, external images in HTML emails are blocked by default; users can click to download. - -AllowCopyContactsToDeviceAddressBook: Default $true. When $false, users cannot sync OWA contacts to their mobile device's address book. - -OWALightEnabled: Default $true. Controls whether the light version of OWA is available for slow connections. - -DefaultTheme: String specifying the theme name. Default is blank (no custom theme). - -LogonAndErrorLanguage: Integer for language locale. Default is 0 (system default). - -UseGB18030: Default $false. Affects character encoding for Chinese users. - -AllowOfflineOn: Options: NoComputers, AllComputers. Default is AllComputers. Controls whether cached offline mode is allowed. - -SetPhotoAvailable: Default $true. When $false, users cannot see or set their mailbox photo. - -GroupCreationEnabled: Default $true. When $false, users cannot create distribution groups or Microsoft 365 groups via OWA. - -NotesEnabled: Default $true. Controls the Notes feature in OWA. - -RecoverDeletedItemsEnabled: Default $true. When $false, users cannot recover deleted items from the Recoverable Items folder via OWA. - -InstantMessagingEnabled: Default $true. Controls integration with Teams/Skype for Business. - -TextMessagingEnabled: Default `$true. Controls SMS text messaging features. - -ForceSaveAttachmentFiltering: Default `$false`. When `$true`, forces attachment scanning. - -AllowUserVoiceMail: Default `$true. Controls voice mail options. - -PublicFoldersEnabled: Default $true. When $false, public folders are not accessible via OWA.

There are no specific timers associated with OWA policies; they are session-based and evaluated at login. However, policy changes take effect immediately for new sessions; existing sessions may need to refresh or log out/in.

Configuration and Verification Commands

OWA mailbox policies are managed via Exchange Online PowerShell (EXO V2 module). The key cmdlets are: - Get-OwaMailboxPolicy - lists all policies. - New-OwaMailboxPolicy - creates a custom policy. - Set-OwaMailboxPolicy - modifies policy parameters. - Remove-OwaMailboxPolicy - deletes a policy. - Set-CASMailbox - assigns a policy to a user. - Get-CASMailbox - shows which policy a user has.

Example: Create a new policy named "RestrictExternal" that blocks external senders and disables contact sync:

New-OwaMailboxPolicy -Name "RestrictExternal"
Set-OwaMailboxPolicy -Identity "RestrictExternal" -AllowExternalSenders $false -AllowCopyContactsToDeviceAddressBook $false

Assign to user:

Set-CASMailbox -Identity user@domain.com -OwaMailboxPolicy "RestrictExternal"

Verify:

Get-CASMailbox -Identity user@domain.com | Select-Object OwaMailboxPolicy

Note: The default policy cannot be deleted. Custom policies can be assigned to multiple users. If a user has no explicit policy, they get the default.

Interaction with Related Technologies

OWA mailbox policies interact with: - Mobile Device Management (MDM): MDM policies (via Intune) are device-level and require enrollment. OWA policies are mailbox-level and do not require enrollment. They can complement each other; for example, MDM can enforce device encryption, while OWA policies can block external recipients. - ActiveSync Policies: ActiveSync policies apply to devices using the Exchange ActiveSync protocol (native mail apps on iOS/Android). OWA policies apply only to the web interface. However, many settings overlap (e.g., allow external recipients). The exam tests that OWA policies do not affect ActiveSync clients unless specifically configured via other means. - Conditional Access Policies: Azure AD Conditional Access can enforce MFA or block access based on location or device compliance, but it does not control OWA features like external recipients. OWA policies are more granular for feature control. - Compliance Policies: Data loss prevention (DLP) and retention policies operate at the message level, not the UI level. OWA policies can prevent users from performing actions (like forwarding to external) that would bypass DLP.

Default Policy and Custom Policies

The default OWA mailbox policy is named "Default" and is applied to all mailboxes that do not have a custom policy. You cannot delete it, but you can modify its settings. However, best practice is to leave the default as-is and create custom policies for specific user groups. The exam often tests that custom policies override the default when assigned.

Exam-Relevant Details

The parameter -AllowExternalSenders is often tested: setting it to $false blocks all external recipients, including replies to external senders.

The parameter -BlockExternalImages defaults to $true, meaning images are blocked unless user allows.

The parameter -OWALightEnabled defaults to $true; if set to $false, users on slow connections may have issues.

The parameter -AllowOfflineOn has options NoComputers and AllComputers. NoComputers disables offline caching on all devices.

The cmdlet Set-CASMailbox is used to assign the policy; do not confuse with Set-Mailbox.

Policy changes are not instant for existing sessions; users must log out and back in.

Common Misconfigurations

Setting -AllowExternalSenders to $false but not realizing it also blocks replies to external users.

Forgetting to assign a custom policy after creating it; users remain on default.

Assuming OWA policies affect mobile apps (they do not; only OWA web interface).

Using Set-OwaMailboxPolicy on the default policy without realizing it affects all unassigned users.

Verification Steps for Troubleshooting

1.

Check which policy is assigned: Get-CASMailbox -Identity user | fl OwaMailboxPolicy.

2.

Check policy settings: Get-OwaMailboxPolicy -Identity "PolicyName" | fl *.

3.

Test by logging into OWA and attempting the restricted action.

4.

If changes not visible, ask user to clear browser cache or use InPrivate mode.

Summary of Key Exam Points

OWA mailbox policies control the web interface only.

They are separate from ActiveSync and MDM policies.

Default policy applies to all users without explicit assignment.

Use Set-CASMailbox to assign a policy.

Key parameters: AllowExternalSenders, BlockExternalImages, AllowCopyContactsToDeviceAddressBook, AllowOfflineOn.

Policy changes require new session to take effect.

Detailed Parameter Reference

Below is a list of commonly tested parameters with their default values and effects:

| Parameter | Default | Effect when set to $false | |-----------|---------|---------------------------| | AllowExternalSenders | $true | Cannot send to external recipients | | BlockExternalImages | $true | External images blocked by default | | AllowCopyContactsToDeviceAddressBook | $true | Cannot sync contacts to device | | OWALightEnabled | $true | Light version disabled | | AllowOfflineOn | AllComputers | Offline mode disabled on all computers | | GroupCreationEnabled | $true | Cannot create groups | | NotesEnabled | $true | Notes feature hidden | | RecoverDeletedItemsEnabled | $true | Cannot recover deleted items | | InstantMessagingEnabled | $true | IM integration disabled | | TextMessagingEnabled | $true | SMS features disabled | | PublicFoldersEnabled | $true | Public folders not accessible |

Note: Some parameters like -SetPhotoAvailable and -ForceSaveAttachmentFiltering are also tested occasionally.

How OWA Policies Differ from ActiveSync Policies

ActiveSync policies are applied to devices using the Exchange ActiveSync protocol. They include security settings like password requirements, device encryption, and inactivity lock. OWA policies are for the web interface. The exam often includes a question where you must choose which policy to modify to block external recipients in OWA (answer: OWA mailbox policy) versus blocking external recipients on mobile devices (answer: ActiveSync policy or mail flow rule).

Interaction with Mail Flow Rules (Transport Rules)

Mail flow rules can also block external recipients, but they work at the transport level, not the UI level. OWA policies prevent the user from even composing a message to an external recipient, while mail flow rules reject or redirect messages after they are sent. The exam may test that OWA policies provide a proactive block versus reactive block.

PowerShell Best Practices

When creating custom policies, always use descriptive names. Use Get-OwaMailboxPolicy to view all settings before modifying. To see the current policy for a user, use Get-CASMailbox. To see all users with a specific policy, use:

Get-CASMailbox -ResultSize Unlimited | Where-Object {$_.OwaMailboxPolicy -eq "PolicyName"}

Troubleshooting

If a user reports that a setting is not working: 1. Confirm the policy is assigned correctly. 2. Check if the user is accessing OWA from a mobile browser (some settings may behave differently, but OWA policies still apply). 3. Ensure the user is not using a third-party app that bypasses OWA. 4. Clear browser cache and cookies. 5. Verify that the policy has not been overridden by a higher-level policy (e.g., Conditional Access or MDM).

Exam Scenarios

Scenario 1: A company wants to prevent users from sending emails to external domains via OWA. Solution: Set -AllowExternalSenders $false on the OWA mailbox policy.

Scenario 2: A company wants to disable offline access in OWA. Solution: Set -AllowOfflineOn NoComputers.

Scenario 3: A user complains they cannot see the Notes feature. Check if -NotesEnabled is set to $false.

Scenario 4: A user cannot recover deleted items. Check -RecoverDeletedItemsEnabled.

Conclusion

OWA mailbox policies are a lightweight but powerful way to control the OWA experience. They are a core part of tenant management in MS-102. Understanding the exact parameters, defaults, and how to assign them via PowerShell is essential for the exam. Remember: OWA policies apply only to the web interface, not to mobile apps or desktop Outlook.

Walk-Through

1

Identify Business Requirements

Before configuring OWA mailbox policies, determine which features need to be restricted or enabled for different user groups. For example, executives may need external sending, while interns may not. Document the desired settings for each group. This step is crucial because the exam tests that you choose the correct policy type (OWA vs. ActiveSync vs. MDM) based on the requirement. For instance, if the requirement is to block external recipients in OWA, you need an OWA policy; if it's to require device encryption, you need an MDM policy.

2

Create Custom OWA Mailbox Policy

Using Exchange Online PowerShell, create a new OWA mailbox policy with `New-OwaMailboxPolicy -Name "PolicyName"`. Then configure the specific settings using `Set-OwaMailboxPolicy`. For example, to block external senders and disable offline mode: `Set-OwaMailboxPolicy -Identity "PolicyName" -AllowExternalSenders $false -AllowOfflineOn NoComputers`. The exam may ask which cmdlet to use: answer is `New-OwaMailboxPolicy` and `Set-OwaMailboxPolicy`. Remember that the default policy cannot be deleted.

3

Assign Policy to Users

Use the `Set-CASMailbox` cmdlet to assign the custom policy to individual users or groups. For example: `Set-CASMailbox -Identity "user@domain.com" -OwaMailboxPolicy "PolicyName"`. You can also assign to multiple users using a loop or by piping from `Get-Mailbox`. The exam tests that you use `Set-CASMailbox`, not `Set-Mailbox`. If you assign a policy that doesn't exist, PowerShell will throw an error.

4

Verify Policy Application

After assignment, verify that the policy is applied using `Get-CASMailbox -Identity "user@domain.com" | Select-Object OwaMailboxPolicy`. To confirm the settings within the policy, use `Get-OwaMailboxPolicy -Identity "PolicyName" | Format-List`. The exam may ask how to check which policy a user has; the correct answer is `Get-CASMailbox`. Additionally, you can ask the user to log into OWA and attempt the restricted action to confirm enforcement.

5

Test and Troubleshoot

Have the user log out of OWA and log back in to ensure policy takes effect. If the policy does not apply, check for browser caching issues, or verify that the user is not assigned to another policy that overrides (only one policy can be assigned). Also check that the user is accessing OWA via a supported browser. The exam may present a scenario where a user reports that a setting is not working; common troubleshooting steps include clearing cache and verifying policy assignment. Remember that policy changes are not retroactive for existing sessions.

What This Looks Like on the Job

In a large enterprise with 10,000 users, the IT team implemented OWA mailbox policies to meet compliance requirements. The company needed to prevent all users from sending emails to external domains via OWA to reduce data exfiltration risk. They created a custom policy named "NoExternal" with -AllowExternalSenders $false and assigned it to all users via a PowerShell script that looped through all mailboxes. However, they discovered that executives needed to send external emails, so they created a second policy "Executives" with -AllowExternalSenders $true and assigned it to a security group. The challenge was that the default policy still applied to any new users not in the script, so they set the default policy to also block external senders. This worked, but they had to ensure that the executive policy was assigned before the default policy took effect. At scale, performance is not an issue because policies are stored in the mailbox database and evaluated per session. A common misconfiguration is forgetting to assign the policy after creation, leaving users on the default. Another scenario involved a healthcare organization that needed to disable offline access to patient data. They set -AllowOfflineOn NoComputers on all OWA policies. However, they also had ActiveSync policies for mobile devices, and some users complained they could still access offline data via mobile apps. This was because OWA policies do not affect ActiveSync; they had to configure mobile device policies separately. The lesson: OWA policies are only for the web interface. In a third scenario, a university wanted to allow students to use OWA but block them from creating groups. They set -GroupCreationEnabled $false on the student policy. However, students could still create groups via Teams or Outlook desktop. The IT team realized that OWA policies only prevent group creation via the OWA interface; they had to use other controls for other clients. This highlights the importance of understanding the scope of OWA policies. When misconfigured, users may experience unexpected behavior, such as being unable to reply to external emails because -AllowExternalSenders also blocks replies. The exam often tests this nuance.

How MS-102 Actually Tests This

The MS-102 exam tests OWA mailbox policies under Objective 1.4: Manage tenant management settings. Specifically, you need to know how to configure and assign OWA mailbox policies using PowerShell. The exam does not test the GUI method (Exchange Admin Center) because Microsoft is moving to PowerShell-centric administration. Common wrong answers include: (1) Using Set-Mailbox instead of Set-CASMailbox to assign the policy. Candidates choose Set-Mailbox because it's familiar, but Set-Mailbox does not have an -OwaMailboxPolicy parameter. (2) Confusing OWA mailbox policies with ActiveSync policies. When a question asks to block external recipients in OWA, some candidates incorrectly choose to modify the ActiveSync policy or create a mail flow rule. (3) Thinking that the default policy cannot be modified. It can be modified, but it cannot be deleted. (4) Assuming that policy changes take effect immediately for all users. They only take effect on new sessions; existing sessions must log out and back in. The exam often includes a question with a scenario where a user complains that a setting is not working after policy change; the correct answer is to have the user log out and log back in. Specific numbers and terms: The parameter -AllowExternalSenders appears verbatim. The cmdlet Set-CASMailbox is tested. The default value for -BlockExternalImages is $true. The option NoComputers for -AllowOfflineOn is a specific value. Edge cases: If a user is assigned a custom policy and then the custom policy is deleted, the user falls back to the default policy. The exam may ask what happens. Also, if you modify the default policy, all users without a custom policy are affected. Another edge case: You cannot assign a policy to a mail user or mail contact; only to mailboxes. The exam may present a scenario with a shared mailbox; OWA policies apply to shared mailboxes as well if accessed via OWA. To eliminate wrong answers, focus on the mechanism: OWA policies control the web interface only. If the requirement involves mobile devices or desktop Outlook, it's not an OWA policy. Also, remember that PowerShell is the primary tool for configuration; the EAC is available but limited. Finally, know that the -AllowExternalSenders parameter blocks sending to any domain not in the tenant's accepted domains, which includes replies. This is a common trap: candidates think it only blocks new messages, but it blocks all external recipients.

Key Takeaways

OWA mailbox policies control the web interface only; they do not affect desktop or mobile clients.

Use `New-OwaMailboxPolicy` and `Set-OwaMailboxPolicy` to create and configure policies.

Use `Set-CASMailbox -OwaMailboxPolicy` to assign a policy to a user.

The default policy applies to all users without a custom policy; it can be modified but not deleted.

Setting `-AllowExternalSenders $false` blocks all external recipients, including replies.

Policy changes require a new OWA session to take effect; existing sessions must log out/in.

Common exam parameters: -AllowExternalSenders, -BlockExternalImages, -AllowOfflineOn, -GroupCreationEnabled.

OWA policies are separate from ActiveSync and MDM policies; each has its own scope.

The cmdlet `Get-CASMailbox` shows the assigned OWA mailbox policy for a user.

Custom policies override the default only when explicitly assigned.

You cannot assign a policy to mail users or contacts; only to mailboxes.

The `-AllowOfflineOn` parameter accepts values `NoComputers` or `AllComputers`.

OWA policies do not enforce device-level security; use MDM for that.

If a custom policy is deleted, users assigned to it fall back to the default policy.

Easy to Mix Up

These come up on the exam all the time. Here's how to tell them apart.

OWA Mailbox Policies

Apply to Outlook on the web (browser) only.

Managed via `*-OwaMailboxPolicy` cmdlets.

Control UI features like external senders, offline mode, notes, etc.

No device enrollment required.

Assigned to mailboxes via `Set-CASMailbox -OwaMailboxPolicy`.

ActiveSync Policies

Apply to devices using Exchange ActiveSync (native mail apps).

Managed via `*-MobileDeviceMailboxPolicy` cmdlets.

Control security settings like password requirements, encryption, inactivity lock.

Devices may need to be quarantined or blocked if non-compliant.

Assigned to users via `Set-CASMailbox -ActiveSyncMailboxPolicy`.

Watch Out for These

Mistake

OWA mailbox policies apply to all email clients including Outlook desktop and mobile apps.

Correct

OWA mailbox policies only apply to Outlook on the web (the browser interface). They do not affect Outlook desktop, mobile apps (iOS/Android), or other IMAP/POP clients. Each client has its own policy mechanism (e.g., ActiveSync policies for mobile).

Mistake

The default OWA mailbox policy cannot be modified.

Correct

The default policy can be modified using `Set-OwaMailboxPolicy -Identity "Default" ...`. However, it cannot be deleted. If you modify it, all users without a custom policy will be affected. Best practice is to leave the default as-is and create custom policies.

Mistake

Setting `-AllowExternalSenders $false` only blocks new emails to external recipients, but allows replies.

Correct

Setting `-AllowExternalSenders $false` blocks all external recipients in the To, Cc, and Bcc fields, including replies and forwards. Users will not be able to send any email to an external domain via OWA. This is a common exam trap.

Mistake

OWA mailbox policy changes take effect immediately for all users.

Correct

Policy changes take effect immediately for new OWA sessions. Users who are already logged in must log out and log back in to see the changes. Clearing browser cache may also be required. The exam loves to test this with a scenario where a user reports no change after policy update.

Mistake

You can assign an OWA mailbox policy using the Exchange Admin Center (EAC) without PowerShell.

Correct

While the EAC allows you to create and edit OWA mailbox policies, assigning a policy to a user is not directly available in the EAC for individual users. You must use PowerShell (`Set-CASMailbox`) or modify the user's mailbox properties via EAC (which is cumbersome). The exam expects you to know the PowerShell cmdlet.

Do You Actually Know This?

Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.

Frequently Asked Questions

How do I assign an OWA mailbox policy to a user in Exchange Online?

Use the `Set-CASMailbox` cmdlet with the `-OwaMailboxPolicy` parameter. For example: `Set-CASMailbox -Identity "user@domain.com" -OwaMailboxPolicy "PolicyName"`. You must use Exchange Online PowerShell; this cannot be done via the Exchange Admin Center for individual users. The policy must already exist. If the policy name contains spaces, enclose it in quotes.

What is the difference between OWA mailbox policies and ActiveSync policies?

OWA mailbox policies apply to Outlook on the web (browser) and control UI features like external recipients, offline mode, and notes. ActiveSync policies apply to devices using the Exchange ActiveSync protocol (native mobile mail apps) and control security settings like password requirements and device encryption. Both are assigned via `Set-CASMailbox` but with different parameters (`-OwaMailboxPolicy` vs `-ActiveSyncMailboxPolicy`). They are independent; a user can have both.

Does setting `-AllowExternalSenders $false` block replies to external senders?

Yes. Setting `-AllowExternalSenders $false` blocks all external recipients in the To, Cc, and Bcc fields, including replies and forwards. Users cannot send any email to an external domain via OWA. This is a common exam trap: candidates think it only blocks new messages, but it blocks all outbound external email.

How long does it take for an OWA mailbox policy change to take effect?

Policy changes take effect immediately for new OWA sessions. Users who are already logged in must log out and log back in to see the changes. Clearing browser cache may also be necessary. There is no replication delay because the policy is stored in the mailbox database and evaluated at session start.

Can I modify the default OWA mailbox policy?

Yes, you can modify the default policy using `Set-OwaMailboxPolicy -Identity "Default" ...`. However, you cannot delete it. Modifying the default policy affects all users who do not have a custom policy assigned. Best practice is to leave the default as-is and create custom policies for specific groups.

What happens to users if I delete a custom OWA mailbox policy that is assigned to them?

If you delete a custom policy that is assigned to users, those users will automatically fall back to the default OWA mailbox policy. The assignment is not removed; it's just that the policy no longer exists. To avoid this, reassign users to another policy before deletion.

Can OWA mailbox policies control mobile device security?

No. OWA mailbox policies only control the web interface. To enforce mobile device security (e.g., require encryption, password), you need Mobile Device Management (MDM) via Intune or Exchange ActiveSync policies. OWA policies cannot enforce device-level settings.

Terms Worth Knowing

Ready to put this to the test?

You've just covered Exchange Mobile Device Policies (OWA) — now see how well it sticks with free MS-102 practice questions. Full explanations included, no account needed.

Done with this chapter?