O365 Set-Mailbox with DeliverToMailboxAndForward - powershell

Question

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
Is PowerShell the only way to issue Set-Mailbox or can it be done
through the GUI somehow?
Is there a way to disable/prevent users from settings this (i.e. do the end users have too many permissions)?
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?

Answer 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
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.

Answer 2

This question may get a better response in an Office 365 forum, but I'll try to answer your questions:
The GUI/Web UI is executing PowerShell commands on the back end when users change their configuration. In order to be allowed to change a setting in the GUI, the same permission needs to exist for the PowerShell cmdlets.
This permissions is a default included in the MyBaseOptions management role for Office 365 mailbox users. This role includes many other permissions which users require to manage their own mailbox, such as permissions to create inbox rules or update their picture. You can see all the actions included in this role with this command:
Get-ManagementRole -Identity mybaseoptions |Select -Expand roleEntries
The easiest way to audit current mailbox settings is likely running the command as you have done. A more efficient way to query all your mailboxes for just those with specific settings is to use the -Filter parameter on the Get-Mailbox command like this:
Get-Mailbox -Filter {DeliverToMailboxAndForward -eq $true -and ForwardingSMTPAddress -ne $null}
I hope that helps answer your questions!