Skip to main content
Group Mailbox Limitations and Workarounds

Group Mailbox Limitations and Workarounds

Updated this week

Overview

Group Mailbox protection is now available with Group configuration. Please review the limitations and considerations outlined below for Group Mailbox protection.

๐Ÿ“NOTE: The Group Mailbox backup is also utilized to back up Planner comments.

Backup Flow

API Limitations:

  • Due to API limitations, voting data, custom app-specific content such as polls and Loop components, and group mailbox settings cannot be backed up.
    โ€‹

  • Due to API limitations, several group mailbox settings are excluded from backups, including custom views, rules, 'Follow inbox' and 'Stop following inbox' settings, and custom folders where conversations are manually or automatically moved by rules. As a result, these custom folders and the conversations within them are not backed up.
    โ€‹

  • Due to API limitations, the historical content of forwarded messages cannot be backed up; only newly added content is included.

Restore Flow

๐Ÿ“NOTE: During a granular restore of group mailbox conversations, a maximum of 50 conversations can be selected and restored at once.

App Admin Added & Removed as Owner of the Group

During the restore process, the admin account used for the Druva M365 app configuration will be temporarily added as an owner to the restored group and then removed. This action will have the following effects:

  • Teams Access: If the group has an associated team, the admin will briefly gain access to it.

  • Email Access: After the restore operation, the admin will have access to the restored emails within the group mailbox. The restored messages will appear in the admin's personal mailbox (Sent Items).

  • Audit logs: Adding and removing the admin as a group member generates an event in the Azure logs.

Workaround: Create a dummy user with Global Admin privileges, then perform the OAuth process for the Druva App using this admin account. This step ensures that unwanted "Teams access" and "email access" are not granted.

Ownerless Group

While Microsoft doesn't officially support ownerless groups, they can occur if the app administrator is removed. To facilitate data restoration from these groups, the app administrator is added to the group during the restore process. This administrator is then permanently retained after the operation is completed.

Workaround: If you prefer not to reinstate the original administrator, you can assign a placeholder user (dummy user) as the app administrator and designate them as the group's owner.

API Limitations

  • Due to API limitations, recipients initially listed in the CC field cannot be restored to that field. Consequently, these recipients will be added to the โ€˜TOโ€™ recipient field in the restored items.
    โ€‹
    โ€‹

  • Restored posts will be sent from the Admin account that set up the Druva application, timestamped with the restore API trigger time. The restored post will include metadata such as the original sender and delivery time in the body of the restored posts.


    โ€‹

  • When a post is first restored (Restore 1), a metadata block with information like the 'Original sender' and 'Delivered on' is added.
    An additional metadata block is added if this post (now containing one metadata block) is restored again after an incremental backup (Restore 2). This new block will show the 'Original sender' as 'admin' (the one who restored it) and the 'Delivered on' as the time of the first restoration.
    โ€‹
    For example, if an email originally sent by 'User A' on August 1st is first restored by the admin on August 3rd, the metadata will display 'Original sender: User A' and 'Delivered on: August 1st.'
    If the email is restored again on August 5th after an incremental backup, a new metadata block will be added, showing 'Original sender: admin' and 'Delivered on: August 3rd.

  • During an in-place restore, for the deleted post(s) from the original conversation, a new conversation with the same topic/subject line as the original conversation will be created/restored.
    โ€‹

  • Multiple metadata blocks can appear due to incremental backups of restored conversations and repeated restorations of deleted items. In these cases, the oldest metadata block offers the most accurate details about the original sender and delivery time.

๐Ÿ“Note: Refer to the Microsoft documentation for Exchange Online limitations.

Duplicate Restorations

In the event of multiple (n times) in-place restore operations of a conversation, the restored conversation will contain 'n' duplicate copies.

Did this answer your question?