“PermissionMask Check Failed” and Other Search Errors That Go Bump in the Dark

I recently consulted with a Microsoft partner who was experiencing some very odd WSS search issues (not MOSS search, which is an entirely different animal).  To begin with, they were running SPS 2003 and WSS v3.0 on the same box, which is not something I wouldn’t normally recommend doing in production.  But after hours of troubleshooting we determined that nothing in this dual configuration was at fault; instead, the search crawler, which was running in a user context that happened to be highly privileged administrator account, would simply not index content, despite the fact that the search accounts could login to the target sites with Site Owner permissions.

 

After checking and rechecking the crawl accounts, removing and re-applying user permissions, and generally trying everything we could think of, the logs continued to display a "PermissionMask Check Failed" error.  In addition, the MSSCrawlURLLog table was showing a value of 13 in the ErrorID column with a description of "The parameter is incorrect".  Further investigation revealed that the database server was upgraded sometime between creating the farm SSP and creating the root site collection but there was no indication that this was the cause of the errors.

 

In a last ditch effort to save the client from having to create an entirely new web application and manually recreate the site structure and content, I suggested that they backup and restore the site to a new site collection.  Bam!  Everything started working again.

 

Here are the exact steps they took to resolve the issue:

 

• Backup my current site collection – stsadm -o backup -url http://<root application url> -filename filename.dat
• Delete the web application with the uncrawlable content database (including the IIS site and content databases).
• Recreate the web application and corresponding site collection (you can choose to point at the existing search server at this point)
• Restore the backup over the newly created site collection with the overwrite switch. – stsadm -o restore -url http://<new application url> -filename filename.dat -overwrite

 

Who knows what the root cause of the issue might have been but the tipoff was the PermissionMask error, which indicated that the crawl account permissions – even though they were the same accounts used prior to the crawl failure – had somehow become corrupted.  If you’re having these issues, try backing up and restoring the site collection.  It might save you hours of frustration.