You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Description of the new feature - must be an in-depth explanation of the feature you want, reasoning why, and the added benefits for MSPs as a whole.
It would be nice to see a report that would allow us to view any email forwards enabled on a tenant. This would be very beneficial to us as an MSP, in allowing us to have a broad overview of what accounts are being forwarded and to whom they are being forwarded. Often times clients request an email account be forwarded to another, after termination of an employee, or when someone goes on sick leave etc. Then often it is forgotten on both ends that the forward is occuring, and one user may receive something like a notification from Microsoft about an expiring 365 Family or personal license that has information like the last 4 digits of the payment method. When the user on the forward see's this, it leads to a security escalation or report, as they believe they are being phished, when it was really just an email not meant for them. Currently, the only way I've noticed to be able to discovered forwarded accounts is to individually go through each mail box in the exchange admin portal, and view if they are forwarded, and to whom they are forwarded. This is time consuming! Even Microsoft seems to only offer an external auto forward report, but I am not seeing any tools or utilities to view this status for internal mail flow.
PowerShell commands you would normally use to achieve above request
N/A
The text was updated successfully, but these errors were encountered:
This issue is stale because it has been open 10 days with no activity. We will close this issue soon. If you want this feature implemented you can contribute it. See: https://docs.cipp.app/dev-documentation/contributing-to-the-code . Please notify the team if you are working on this yourself.
If I understand correctly, this is already possible via the Email & Exchange -> Mailboxes page. You can add the rows ForwardingsmtpAddress and IntemalForwardingAddress and see where all mailboxes are forwarding to. :)
Forwards via mailbox rules can be found via Email & Exchange -> Mailbox rules.
This issue is stale because it has been open 10 days with no activity. We will close this issue soon. If you want this feature implemented you can contribute it. See: https://docs.cipp.app/dev-documentation/contributing-to-the-code . Please notify the team if you are working on this yourself.
Description of the new feature - must be an in-depth explanation of the feature you want, reasoning why, and the added benefits for MSPs as a whole.
It would be nice to see a report that would allow us to view any email forwards enabled on a tenant. This would be very beneficial to us as an MSP, in allowing us to have a broad overview of what accounts are being forwarded and to whom they are being forwarded. Often times clients request an email account be forwarded to another, after termination of an employee, or when someone goes on sick leave etc. Then often it is forgotten on both ends that the forward is occuring, and one user may receive something like a notification from Microsoft about an expiring 365 Family or personal license that has information like the last 4 digits of the payment method. When the user on the forward see's this, it leads to a security escalation or report, as they believe they are being phished, when it was really just an email not meant for them. Currently, the only way I've noticed to be able to discovered forwarded accounts is to individually go through each mail box in the exchange admin portal, and view if they are forwarded, and to whom they are forwarded. This is time consuming! Even Microsoft seems to only offer an external auto forward report, but I am not seeing any tools or utilities to view this status for internal mail flow.
PowerShell commands you would normally use to achieve above request
N/A
The text was updated successfully, but these errors were encountered: