The content processing component failed to process the security descriptor of the item. The input ACL is Invalid.

  • Article

Summary

A while back, one of my colleagues authored an internal article around this error that we sometimes see in the Crawl Logs within a customer environment

That error looks like this...

Within this article, it talks about the cause being due to some users that had claims that were migrated over at some point and there is no matching ID Provider for those claims.

While this is absolutely true, we have encountered additional cases and customers that run into this same error and it is not due to mismatch user claims.

The purpose of this article to expose that type of information and provide a method to discover those Invalid Users and to remove them

More Information

As I mentioned above, this is the error we will often see in the Crawl Logs, but what if your site does not have any migrated users with custom Claims or mismatched Claims? What if your site is using straight Windows Claims, but you still see this error?

What we have seen is this error can be thrown when there are users with "Invalid" ( "tp_SystemID" or "SystemUserKey" ) values..

This "tp_SystemId" is stored within the "UserInfo" table on the content database where the problematic Site\Web resides.

We are not 100% sure how these values become corrupt, but we suspect it is done by some 3rd party tool.

If you see this error, I would suggest doing the following:

  • Run the following PowerShell

    $outputFolder = Read-Host "Enter a location for the output file (For Example: C:\Temp)"

    $filename = "Check-InvalidSystemUserKey.csv"

    $outFile = $outputFolder + "\" + $filename

    $webAppUrl = Read-Host "Please enter the URL of the Web App you want to check ( Ex: https://sharepoint )"

    "SiteUrl~WebUrl~User~LoginName~InvalidSystemUserKey" | Out-File $outFile

    $wa = Get-SPWebApplication $webAppUrl

    foreach($site in $wa.Sites)

    {

    foreach($web in $site.AllWebs)

    {

    ""

    "Checking web: " + $web.Url

    $SPUsers = $web.SiteUsers | ?{$_.SystemUserKey -notmatch "c:" -and $_.SystemUserKey -notmatch "i:" -and $_.SystemUserKey -notmatch "s-1-"}

    if($SPUsers.Count -gt "0")

    {

    foreach($user in $SPUsers)

    {

    Write-Host ("Found user, " + $user.DisplayName + ", with an Invalid SystemUserKey ") -ForegroundColor Yellow

    $web.Site.Url + "~" + $web.Url + "~" + $user.DisplayName + "~" + $user.UserLogin + "~" + $user.SystemUserKey | Out-File $outFile -Append

    }

    }

    else

    {

    Write-host ("No Invalid SystemUserKey found within this set of Users... ") -ForegroundColor Green

    }

    }

    $web.Dispose()

    }

    $site.Dispose()

    ""

    "Finished Checking Web App..."

    "Please send the file created at '$outFile' to Microsoft Support"

  • This will prompt you for the directory ( this path, like 'C:\Temp' should already exist ) you want to save your file called "Check-InvalidSystemUserKeys.csv"

  • You will then get prompted for the URL of the Web App you want to check

  • It will then iterate through each Site Collection and Web within the Web App and check for users that have a "SystemUserKey" that does not look conventional ( like starting with "c:" , "i:" or "S-1-x" )

  • It will output on the console as it checks each SPWeb and report if it finds any "Invalid" users..

  • It will also put the info into this .csv file.. and that info will look like this:

    ** Note ** Often times, if a user is granted Perms at a Site Collection level ( Root Site )  and you have subsites that inherit permissions from the Root, then you will see this same user as "Invalid" throughout all the webs within that Site Collection..

  • You can then import this file into Excel, using the " ~ " as the delimiter and then sort and filter based on like the "SiteUrl" column if you need to..

  • If you see accounts with SystemUserKey info like above, this is likely your culprit to the errors you see in the Crawl Logs..

    • We have also seen where the "SystemUserKey" is actually "null" or "empty".
    • If this is the case, please refer to this article, because we suspect the errors in your Crawl Log and ULS logs will match this and it will fail on the mssdmn.exe process

  • Coming back to this issue..

How do we fix this?

  • You can run the following PowerShell to again iterate the Web Application, looking for "invalid" accounts and if found, it will remove them..

    $webAppUrl = Read-Host "Please enter the URL of the Web App you want to check ( Ex: https://sharepoint )"

    $wa = Get-SPWebApplication $webAppUrl

    foreach($site in $wa.Sites)

    {

    foreach($web in $site.AllWebs)

    {

    ""

    "Checking web: " + $web.Url

    $SPUsers = $web.SiteUsers | ?{$_.SystemUserKey -notmatch "c:" -and $_.SystemUserKey -notmatch "i:" -and $_.SystemUserKey -notmatch "s-1-"}

    if($SPUsers.Count -gt "0")

    {

    foreach($user in $SPUsers)

    {

    Write-Host ("Found user, " + $user.DisplayName + ", with an Invalid SystemUserKey ") -ForegroundColor Yellow

    Write-Host ("Removing User: " + $user.DisplayName) -ForegroundColor DarkYellow

    Remove-SPUser -Web $web -Identity $user -Confirm:$false

    }

    }

    else

    {

    "No Invalid SystemUserKey found within this set of Users... "

    }

    }

    $web.Dispose()

    }

    $site.Dispose()

    ""

    "Finished Checking Web App..."

  • After this, try your crawl again.

 

I hope this helps in resolving your issue!