Note-to-self: Exchange recipient administration rights in ILM/FIM/MIM

Another great post to bookmark, using the blog as my external memory again:
Check Paul Williams’ post at :

“What am I talking about?  Reducing the privilege required to perform Exchange recipient provisioning using the Active Directory Domain Services Management Agent (ADMA).  The default documentation on the subject clearly states that in order to provision mailbox-enabled users or linked mailboxes the ADMA account needs to be a member of the Recipient Administrators role group.  Now, while it’s true membership in that group will allow you to run Update-Recipient and successfully invoke the RUS after creating a user and stamping the mandatory Exchange attributes that same membership also grants you access to perform a multitude of recipient administration tasks that the account doesn’t need to perform.”

And also :

#FIM 2010 Quicktip: Troubleshooting the FIM 2010 portal loading a blank page

Working on a case where a FIM configuration has moved from development to production.
The customer’s production environment is a highly secured environment with a server security lockdown. The customer is using a custom tool for server profiling and local security lockdown.

After installing and configuring FIM, the FIM portal was loading blank.


The Application Pool account had changed. When adding the Application pool account to the local administrators group, the portal loaded again…

So we needed to investigate what was going wrong.

Some references we got from our Sharepoint colleagues…

Plan for administrative and service accounts (Office SharePoint Server)

How to change service accounts and service account passwords in SharePoint Server 2007 and Windows SharePoint Services 3.0

They also advised to run a security reset on the SharePoint portal, see: Command-line reference for the SharePoint Products and Technologies Configuration Wizard (Office SharePoint Server)

secureresources Performs SharePoint Products and Technologies resource security enforcement on the server. For example, security is enforced on files, folders, and registry keys.


psconfig.exe -cmd secureresources

Although very useful to reset the security, it didn’t change the behaviour on the portal (still loading blank page).

Using procmon (, we found out that we had quite some errors.
Just a hint: exclude ‘success’ messages and filter on the targeted application pool account.

We first checked the default WSS group memberships for the AppPoolAccount.

For reference:


Just to double check, during troubleshooting we removed the WSS_WPG group from the FIM Portal application pool (default Sharepoint Application pool).

This is the result:

HTTP Error 500.19 – Internal Server Error

The requested page cannot be accessed because the related configuration data for the page is invalid.


So that made the situation even worse.

Back to the procmon results, as procmon threw errors on the impersonation of the application pool account we checked the local security policy. And the AppPool account appeared to be removed from the setting or was not member of the groups referenced in the setting.


Do not make the Application pool account member of the local admins.

Make sure the Application Pool account has the “Impersonate a client after authentication” right in the local Security Policy.



Need more information? Check these articles …

Account permissions and security settings in SharePoint 2013

Plan for administrative and service accounts (Office SharePoint Server)