Many people want to "granularly" add permissions rather than run the Preinstaller, which gives the Add2Exchange service account permissions to the stores. This may be necessary as part of Hiipa compliance. Which permissions can you modify and "ratchet down"?
First of all, the Add2Exchange Service account is a powerful account and its login and password should be highly guarded because of the permissions, no matter if you reduce the permissions. If this account were relegated in this way, the power it has is safe. In fact, much of this power is required for it to do the job it does and there are some things we can’t get around.
Why does the Add2Exchange Service account need to be part of the Built-in Administrators Group? It may not have to be if you allow for the permissions you are gaining by adding it to the group. The Add2Exchange Service account normally is part of the local administrators group of the machine it is installed on (to install software, run services and use WMI over RPC) and also part of the local Administrator's group of any exchange server it connects or that server replicates to. This is normally handled by being part of the Administrators Group, but not the Domain Admins Group.
Note: This can be modified by granularly specifying to allow the Add2Exchange Service Account to log on to the replication server, start and stop a service (interact with operating system) and to allow for RPC calls for the service account. This is not necessary to the Exchange server(s), but must be able to do WMI calls over RPC in the local security policy of the replication server and Exchange Servers.
TIP: Be careful assigning these kinds of permissions because once specified, the default permissions do not apply anymore. Be sure to add other Administrator accounts and Service accounts which enjoy these permissions "by default".
This is required so the Service account can start and stop services, log on locally (replication server) and do RPC calls (Remote Procedure) and WMI (Windows Management Instrumentation) over RPC so it can test for the Exchange store availability. Again, this permission can be gotten around by changing the Local Security policy on the machine to add the Add2Exchange Service account on the machine(s) to enable RPC and WMI through the local machine's policies. Again, use caution when changing a default or unspecified policy.
The second requirement is to create a security group and add the service account to that group (Exchange 2003). In Exchange 2007 and 2010, we user command shell scripts. We suggest adding the security group to the top of the store so it makes it easy to add other relationships, but you don’t have to. In 2007 and 2010, the script adds it to the top of the public folders and mailbox stores, but you can add it to the individual mailboxes and public folders instead of the entire store for administrative permissions. In all three environments it is required that you give the Service account ownership and folder contact on any public folders.
In Exchange 2007 and 2010 we suggest you add the Service account to Exchange organizational administrators and public folder administrators, but this is also unnecessary in a granular environment. Again, this is only necessary if you do not run the Preinstaller tool to add the permissions to the entire organization. If you do not use the tool you will have to run the command shell scripts every time you want to create a relationship to the new folder in the source or destination folder. With some careful application of Powershell, the scripts will allow it to be added granularly. Manual Exchange 2007/2010/2013 Configuration
blog comments powered by Disqus