In the first article of this series, we explained how server-side synchronization (SSS) is able to connect and process a user’s Microsoft Exchange items. This article will cover how you can restrict or limit the scope of information being processed by SSS.
As discussed in the previous article, the default connection between SSS and Microsoft Exchange Online uses a first-party trust and because of that, there are limitations on what restrictions can be made on the default access between these two services. Below are some common suggestions to help customers limit what SSS is able to do with Microsoft Exchange Online.
1. Prevent any sort of synchronization – This one is simple. For the synchronization to start for a mailbox, that mailbox has to be approved, as mentioned in the first article of this series. If you want to take this a step further, you can deactivate the mail server profile for the default Microsoft Exchange Online (default) profile. This will, essentially, sever the connection between SSS to Exchange.
2. Restrict user mailbox self-approval – Most organizations using SSS do not require restrictions on a user’s Dataverse mailbox record. Meaning, by default, a user could determine what they want to synchronize (incoming email, outgoing email, or appointments, contacts, and tasks) from their Microsoft Exchange mailbox to Dataverse by making some configuration changes on their Dataverse mailbox. Then when the user Test & Enable their mailbox, SSS will pick up those changes on the next synchronization cycle without additional oversight from an administrator.
However, as mentioned in the next point, there are organizations that need to control and restrict what changes a user can make to their mailbox record in Dataverse. Organizations that would like to require administrators to approve changes of a Dataverse mailbox record will want to disable the RequirePrivilegeToSelfApproveEmailAddress OrgDBOrgSetting (which is the default). Disabling this setting will require approval on changes to the Dataverse mailbox record by users with the appropriate security role permissions. Additionally, ensure that the user's security role does not have the permission enabled for "Approve Email Addresses for Users or Queues". Additional information about this can be found here:
Approve your own user mailbox
3. Prevent synchronization of specific actions (incoming email, outgoing email, or appointments, contacts, and tasks) – This is a configuration at a mailbox level and defaults can be defined within the email settings in the Power Platform Admin Center. The defaults can be changed and then, at the mailbox level, can be applied to selected mailboxes or all within the view.
Prevent updates to Dataverse mailbox - By default, users need to have read/write access to their user mailbox in Dataverse for SSS to be able to write back the results of the synchronization cycle to the mailbox record. This means that a user can update their Dataverse mailbox record to change things like their email address or what information is being synchronized (incoming email, outgoing email, and appointments, contacts and tasks). However, any time a change is made to that mailbox record, the Dataverse mailbox needs to be approved by a user with the appropriate permissions as outlined previously. To prevent a user from making changes, you would need to write custom synchronous logic, via a plug-in, or you can revert changes through an asynchronous action using something like Power Automate. Below is a screenshot of a Power Automate trigger where, if a mailbox was modified and the default synchronization methods were not set to our defaults, then it would update the mailbox record back and send an email to the user saying they should not be making changes to their Dataverse mailbox record. For this example, our default settings are:
| ¤ |
Incoming Email: Server-Side Synchronization or Email Router |
| ¤ |
Outgoing Email: Server-Side Synchronization or Email Router |
| ¤ |
Appointments, Contacts, and Tasks: Server-Side Synchronization |
Additional details regarding the Dataverse mailbox table can be found here:
mailbox EntityType
4. Prevent users from tracking all emails – Users have the ability to make a change in their personal options that can cause all of the emails within their Exchange mailbox to be synchronized into Dataverse. This could lead to unexpected communications being exposed within the Dataverse environment. One of the best recommendations is to remove the options for users to make these changes easily. A colleague of mine, Cody Dinwiddie, did a great job writing up the impact of this setting and what to do about it in this article:
Server-Side Synchronization Series Part 5: Automatic Incoming Email Promotion
One additional setting you can consider is overriding the user’s personal option of tracking incoming email by setting the SSSForceFilteringMethodForUserMailboxes at an organizational level. This is an OrgDBOrgSetting and you can find more information about it here:
OrgDBOrgSettings for server-side synchronization
5. Restrict access of SSS to Exchange – With the default Exchange Server Online profile, there is no opportunity to restrict the permissions SSS has to a user's Exchange mailbox. This is because of the first-party app registration. However, you can accomplish this if you create and use your own Azure AD App Registration to connect SSS to Exchange. This is done by creating your own Exchange Online server profile in Dataverse. This configuration supports cross-tenant authentication but works within the same tenant as well. We will cover this option in more detail in the 4th article of this series.
In this article, we showcased how a Dynamics 365 admin could implement some additional constraints to limit Microsoft Exchange activities by configuring different settings for server-side synchronization.
In the next article, we cover how you can monitor the activity of server-side synchronization within a user’s Exchange mailbox.
See the other articles of this blog series:
