Document Purpose

This technical bulletin explains the security model, permissions, and server configuration considerations for Add2Exchange and Add2Outlook deployments in Exchange 2007–2019, hosted Exchange, and Microsoft 365 environments. It also outlines which settings are recommended for full unattended automation, which settings can be reduced for tighter security, and the operational tradeoffs of doing so.

Executive Summary

The Add2Exchange Sync Service account is a powerful account by design and should always be protected with a strong password, restricted access, and appropriate server security controls. These elevated permissions are used to provide full unattended automation, including onboarding, permission assignment, relationship creation, and ongoing synchronization.

Permissions can be reduced. However, when permissions are reduced, full unattended automation is also reduced. In most cases, this means additional manual onboarding steps, greater administrative involvement, or the use of a separate elevated account to assign permissions on a scheduled or manual basis.

Common Security Question

Before installing the software, many organizations want to understand the security implications of several items referenced during planning or setup, including disabling UAC on the VM, allowing Outlook programmatic access, enabling macros, and granting Exchange administrative rights. The short answer is that not all of these are required in every environment. Some are recommended for consistency and full automation, while others are optional or only needed during installation, upgrades, or permission automation workflows.

1. Macros

Enabling Microsoft Office macros is not necessary for Add2Exchange or Add2Outlook operation. If your security policy disables macros, that does not prevent installation, evaluation, or normal synchronization.

2. Outlook Programmatic Access

Add2Exchange uses Outlook for Autodiscover so that the system is more fault tolerant, assuming DNS and Autodiscover are configured correctly. By relying on Outlook Autodiscover rather than hard-coded Exchange server names, the software can better support failover, hosted Exchange, and Microsoft 365 environments.

Outlook includes a security setting related to programmatic access. DidItBetter recommends allowing programmatic access for uninterrupted syncing. Although Add2Exchange uses a separate thread and does not require Outlook to remain open, Microsoft has historically introduced Outlook changes that intermittently affected this behavior until later fixes were released.

3. User Account Control (UAC)

UAC should be disabled during initial installation and setup so the Add2Exchange service can be properly configured to run under the intended Sync Service account.

After installation is complete and the environment is stable, UAC may be re-enabled if required by your security policy. However, when applying build updates, version upgrades, certain repair operations, or service reconfiguration tasks, UAC may need to be temporarily disabled again. The recommended process is to disable UAC, reboot the replication server, complete the upgrade or maintenance task, and then re-enable UAC if desired.

4. Exchange Administrative Permissions

The Sync Service account does not have to be an Exchange Organizational Administrator. The Sync Service account can be configured as only a Domain User, provided mailbox and folder permissions are granted through another method.

There are two general models. Model A uses stronger permissions for the Sync Service account so the system can fully automate onboarding, permission assignment, and relationship creation. Model B keeps the Sync Service account at lower privilege while another administrative account grants mailbox or folder permissions either manually or through scheduled PowerShell automation.

If a separate permissions account is used, that account must have the necessary Exchange administrative rights for the environment. In Microsoft 365 or Exchange Online, that generally means Exchange Administrator. In on-premises or hybrid Exchange, that generally means Exchange Administrator or Organizational Administrator, and in some on-premises scenarios local administrative rights on the CAS or management server may also be required.

5. Default Permission Model

By default, Add2Exchange typically uses Full Mailbox Access to the mailboxes being synchronized. This is normally granted automatically on a timed basis, by default every 6 hours, to members of the distribution list or lists being managed by the synchronization process.

This approach provides the highest level of automation and the simplest operational model. With Full Mailbox Access in place, newly added users can be onboarded automatically, relationships can be created automatically, synchronization can begin without manual intervention, and the same distribution list can support additional folder relationships without redesigning the permission routine.

6. Reduced / Granular Permission Model

Some organizations require a tighter security posture and do not want the Sync Service account to have Full Mailbox Access. This is supported.

In a reduced-permissions configuration, the Sync Service account only needs the permissions required for the specific folders involved in synchronization. In supported versions of Exchange 2007–2019, hosted Exchange, and Microsoft 365, when using Outlook for Autodiscover, the most reduced supported model is Folder Visible to the mailbox store and any parent folders in the path, Owner permission to the source and destination folder being synchronized, and Publishing Editor on the immediate parent folder if Add2Exchange will create the target subfolder automatically.

When a new user is onboarded in this model, the permissions script must be run after the mailbox exists, is fully provisioned, and is in its final location. This is manageable, but it introduces a manual or semi-automated dependency on IT staff or a scheduled permissions process.

7. Full Mailbox Access vs. Granular Permissions

Full Mailbox Access provides the simplest deployment model, the highest level of automation, automatic onboarding of new users in managed distribution lists, easier creation of new relationships, and fewer moving parts. The tradeoff is a broader permissions footprint.

Granular permissions provide a tighter security model, a smaller access scope for the Sync Service account, and a better fit for compliance-driven environments. The tradeoff is more administrative overhead, permission scripting or manual permission assignment during onboarding, and more complexity when adding users or new relationships.

8. Offboarding and Data Removal

Offboarding works similarly in both the Full Mailbox Access and Granular Permission models. To remove replicated data, the usual process is to remove the user from the managed distribution list, allow the automation cycle to process the change or manually trigger the system, and then let the data dereplicate automatically.

After dereplication is complete, the organization may proceed with other offboarding actions such as hiding the account from the GAL, removing the license, tombstoning the account, or deleting the account. This behavior is especially important in BYOD environments, where organizations want synchronized data removed promptly when a user is offboarded.

9. Modern Requirement for Local and AD Administrative Rights

For modern environments using Microsoft 365, hosted Exchange, or Exchange environments using Outlook for Autodiscover, the Sync Service account does not need to be a local administrator on the Exchange server itself. It also does not need to be in the Active Directory Built-in Administrators group solely for mailbox synchronization.

What it does need is the proper mailbox and folder permissions for the folders being synchronized, and local administrative rights on the replication server where the Add2Exchange service runs. Historically, broader rights were needed for remote permission assignment in on-premises Exchange environments, but those requirements have been significantly reduced in modern Autodiscover-based deployments.

10. Replication Server Requirements

The Sync Service account must be a local administrator on the replication server and must be able to log on as a service.

If the replication server uses a local SQL Express instance, the account may also need the default rights typically required for SQL installation and operation, including Back up files and directories, View debug logs, and Manage auditing and security log. These are local server requirements, not Exchange mailbox permissions.

11. Replication Server Group Policy and Management

The replication server may be joined to the domain or off-domain. Either model is supported.

For stable operation, the replication server should generally be treated as a dedicated application server with minimal interference from restrictive Group Policy. A practical baseline is Windows 10, Windows 11, or Windows Server, on physical or virtual hardware, with at least 2 virtual processors, approximately 200 GB storage, and ideally 8 GB RAM or more.

The server should have limited Group Policy restrictions where possible. Windows Updates can be managed remotely through the organization's management tools, but best practice is to stop the Add2Exchange service, apply updates, reboot the server, and then restart and verify synchronization.

Antivirus is supported. Where antivirus is used, proper exclusions should be configured for the specific Add2Exchange installation paths, databases, and working files.

12. Legacy Installations

In older environments, especially Exchange 2003, 2007, 2010, and some Exchange 2013 deployments using CDO rather than Outlook, broader permissions were often required. In those models, the service account sometimes needed local administrative rights on the Exchange server, Exchange server names were often hard-coded, and the configuration was less fault tolerant.

Since approximately 2012, Add2Exchange has increasingly relied on Outlook Autodiscover, which allows lower required permissions, improved resiliency, better support for hosted Exchange and Microsoft 365, and less dependency on specific Exchange server names.

13. Older Documentation References

Older documentation sometimes referenced adding a security group such as A2ESecurity at the top of the mailbox store to simplify relationship expansion. That approach is no longer required and is not part of the reduced-permissions model. For current supported environments, the preferred approach is to grant only the mailbox and folder rights needed for the actual synchronization design.

14. Permission Automation Options

To support both full-access and granular-access models, DidItBetter provides automated PowerShell-based support utilities, including the DidItBetter Support Menu.

These utilities can automate Full Mailbox Access permissions, automate granular folder permissions, apply permissions to a single account or distribution list, run on a schedule, and be executed from systems other than the replication server.

The account used to assign permissions does not have to be the Sync Service account. However, it must be an account with sufficient administrative rights for the target environment, and its credentials must be securely maintained and updated if changed.  If MFA is assigned to the "permissions giving" account, then there can be no automation, as a user has to grant access through MFA,  Permissions can be given with the scripts below during offboarding and the sync service account can be demoted to just a "domain user" account.  For complete automation, and without requiring MFA authentication, some installations exclude the account from MFA and set conditional access policies to tighten security.  

15. Granular Permission PowerShell Examples

For environments that want only Calendar or Contact access rather than Full Mailbox Access, the following examples illustrate the permission model. Replace zadd2exchange@domain.com with your actual Sync Service account.  These scripts can be run on onboarding, when adding new users to the sync.

Bulk Example - Calendar Access:

For Contact synchronization, replace Calendar with Contacts. If Add2Exchange is creating a subfolder automatically, the service account must also have Publishing Editor or Owner rights to the parent folder.

Individual Example:

16. Final Recommendation

For the most reliable and fully automated deployment, the recommended configuration is strong protection of the Sync Service account, local administrative rights on the replication server, UAC disabled during setup and upgrade events, Outlook programmatic access allowed, and either Reduced or Full Mailbox Access where operationally acceptable.

This configuration provides the greatest consistency, the least manual effort, and the highest degree of unattended automation.

For organizations with stricter security or compliance requirements, reduced-permission deployments are fully possible. However, those environments should expect harder troubleshooting, potentially more administrative coordination.  Both strategies can be obtained by automatic permissions applications.

17. Support Guidance

If your organization has security requirements that call for a reduced-permissions design, or if you need clarification on installation prerequisites, hardening options, or permission models, please open a support ticket so a DidItBetter technical specialist can review the environment and recommend the best configuration.