PowerPivot Mid-Tier Process Account Does Not have Full Read

The account running the IIS Application Pool leveraged by the PowerPivot System Service requires Full Read on any Web Application with the PowerPivot Service Application Proxy. However, the health rule governing validating this is true does not function correctly. The error in Review Problems and Solutions is:

MidTier process account should have ‘Full Read’ permission on all associated SPWebApplications

Let’s dive in to why this is happening, and how to resolve it.

The first thing the Health Rule does is retrieve the process account name from the IIS Application Pool:

GeminiServiceApplication application2 = application as GeminiServiceApplication;
GeminiServiceApplicationAccount item = new GeminiServiceApplicationAccount {
	serviceApplicationName = application2.Name,
	serviceAcctName = application2.ApplicationPool.ProcessAccount.LookupName().ToUpperInvariant()

The equivalent PowerShell is:

$sa = Get-PowerPivotServiceApplication
$sa.ApplicationPool | Select ProcessAccountName


Once the Health Rule has the process account, the next step is to identify who has FullRead rights in the SPPolicy on the Web Application.

foreach (SPWebApplication application in service.WebApplications)
	foreach (SPServiceApplicationProxy proxy in application.ServiceApplicationProxyGroup.Proxies)
		flag = false;
		if ((proxy is GeminiServiceApplicationProxy) && string.Equals(proxy.Name, serviceApplicationName, StringComparison.OrdinalIgnoreCase))
			foreach (SPPolicy policy in application.Policies)

Now, here is where it fails.

if (string.Equals(policy.UserName, b, StringComparison.OrdinalIgnoreCase))
	if (policy.PolicyRoleBindings.ToString().Contains(SR.FullReadPermission))
		flag = true;

What the above code is doing is validating that the strings are equal. It is comparing the UserName on the SPPolicy to the Process Account running is the IIS Application Pool. In a claims-enabled environment, this is never true as the claims identifier on the SPPolicy isn’t equal to the Process Account.

As for a resolution, simply disable the rule and manually add the ProcessAccountName to the Web Application(s) with Full Read rights. This can be done via PowerShell:

$wa = Get-SPWebApplication
$wa.GrantAccessToProcessIdentity("domain\username", [Microsoft.SharePoint.Administration.SPPolicyRoleType]::FullRead)
Disable-SPHealthAnalysisRule -Identity MidTierAcctReadPermissionRule -Confirm:$false

What about the automatic repair, and why doesn’t that seem to work? Pretty simple, and the issue is along the same lines. What the automatic repair does it first look at a Web Application, then proceed to enumerate each User Policy on that Web Application. For each user, it adds Full Read rights (even though that user isn’t the one running the IIS Application Pool the PowerPivot Service Application is assigned to).

if (proxy is GeminiServiceApplicationProxy)
	foreach (SPPolicy policy in application.Policies)
		string username = SPHttpUtility.NoEncode(policy.UserName);
		application.GrantAccessToProcessIdentity(username, SPPolicyRoleType.FullRead);

The equivalent PowerShell code is:

$wa = Get-SPWebApplication http://webAppUrl
$wa.GrantAccessToProcessIdentity("i:0#.w|nauplius\s-sp2013svcapppool", [Microsoft.SharePoint.Administration.SPPolicy]::FullRead)
Disable-SPHealthAnalysisRule -Identity MidTierAcctReadPermissionRule -Confirm:$false
When it does this, it grabs the username (say “i:0#w domain\username”) and calls SPWebApplication.GrantAccessToProcessIdentity. This method is unable to translate the claim value into a Windows Identity, thus we receive the exception “Some or all identity references could not be translated” and the the repair process exits.

Trevor Seward is a Microsoft Office Apps and Services MVP who specializes in SharePoint Server administration, hybrid scenarios, and SharePoint Online. He has been working with SharePoint for 16 years from SharePoint 2003 on up, managing environments with terabytes of content for 150,000+ user organizations. Trevor is an author of Deploying SharePoint 2016 and Deploying SharePoint 2019. You can find him on Twitter and in /r/sharepoint.