Search code examples
powershellexchange-server

O365 Set-Mailbox with DeliverToMailboxAndForward

Background

Working in a small O365 environment that recently upgraded from E3 to E5.

Issue

The audit log shows that a user enabled DeliverToMailboxAndForward on their mailbox with the Set-Mailbox operation.

Questions

  1. Is PowerShell the only way to issue Set-Mailbox or can it be done through the GUI somehow?

  2. Is there a way to disable/prevent users from settings this (i.e. do the end users have too many permissions)?

  3. When I query Get-Mailbox user | fl name,forwardingSMTPAddress,delivertomailboxandforward the ForwardingSmtpAddress is empty and DeliverToMailboxAndForward is False. Is this the only way to ensure the action is disabled? Does the disable action appear in any event/audit log?

Solution
    1. Is PowerShell the only way to issue Set-Mailbox or can it be done through the GUI somehow?

    As an Exchange admin, you can use the Exchange Admin Center (EAC) to go to the Mailbox properties -> Mailbox Features -> Under Mail Flow, select View details -> Check the Enable forwarding, and Browse to the recipient.

    Configure email forwarding for a mailbox

    1. Is there a way to disable/prevent users from settings this (i.e. do the end users have too many permissions)?

    From a user perspective they can forward using the Outlook GUI:

    Forward email from Office 365 to another email account

    When I query Get-Mailbox user | fl name,forwardingSMTPAddress,delivertomailboxandforward the ForwardingSmtpAddress is empty and DeliverToMailboxAndForward is False. Is this the only way to ensure the action is disabled? Does the disable action appear in any event/audit log?

    You can use either the PowerShell script to query, or navigate through ECA console to verify. The disable action should appear in the audit if it is set up.

    On to the issue,

    The audit log shows that a user enabled DeliverToMailboxAndForward on their mailbox with the Set-Mailbox operation.

    Typically most users don't have access to the Exchange Management Console, and the ability to run PowerShell operations. That makes this audit entry "seem" odd. But then digging through the docs I come up to this entry:

    Cmdlets that are run directly in the Exchange Management Shell are audited. In addition, operations performed using the Exchange admin center (EAC) are also logged because those operations run cmdlets in the background.

    Administrator audit logging in Exchange Server

    So what you are likely seeing is an entry that is a GUI running a cmdlet in the background, without the user actually having direct Exchange Management Shell access. As for permissions, I'm not sure about explicit permissions to deny this specific action without denying a lot of other stuff (i.e. it's like denying permissions to forward messages) unless you have a business need to do this.