Unreadable content was found in this item - PerformancePoint 2007 to 2010 Migration

This little chestnut caused me no end of fun, and there is not a whole lot out there about it.

The Problem:

When you run the Import PerformancePoint 2007 Content wizard, using a valid account to connect to SQL server, and a valid BI Center as the target locations (which the wizard very kindly automatically identies and selects for you), you still receive the following message in each section.

"Unreadable content was found in this item".

There are two possibilities for this problem:

When it happens to all sections of the import (data sources, indicators, KPIs, Report views, score cards, dashboards):

The likely reason here is that the server needs to communicate with itself using a web service URL, and the (cursed) loopback adapter check is on. For this to be solved, the server must be able to access the target web application (e.g http://myintranet.company.com) from the local machine. This is easy to test. Open your browser from the server and see if you can. The following steps will resolve this issue:

1. Remove the loopback adapter check using the following powershell:
   
   
   

   # Disable the Loopback Check
   #This setting usually kicks out a 401 error when you try to navigate to sites that resolve to a loopback address e.g.  127.0.0.1
   New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck"  -value "1" -PropertyType dword

2. 
   

   Ensure that a host entry exists for the site, either by DNS (for already in production systems), or, if you are in testing, or don't have access to DNS, via adding the hosts entry to your hosts file at c:\windows\system32\drivers\etc\hosts, e.g.
   
   127.0.0.1 myintranet.company.com

References: http://social.technet.microsoft.com/Forums/en/sharepoint2010setup/thread/306c59e0-c74c-4f37-9df3-2b1202cef54e, http://sptwentyten.wordpress.com/2010/03/06/disable-the-loopback-check-via-powershell/

When it only happens to data sources and scorecards

My problem continued to persist past the first problem above. On further investigation of the SharePoint ULS logs, you should see messages similar to:

Failed to look up string with key "Section2TitleResource", keyfile osrvcore. edb1db92-2bd9-4dab-b772-b3b36b293e99

Unreadable content was found in this item. System.Collections.Generic.KeyNotFoundException: The given key was not present in the dictionary. at System.ThrowHelper.ThrowKeyNotFoundException() at System.Collections.Generic.Dictionary`2.get_Item(TKey key) at Microsoft.SharePoint.Administration.SPScenarioContext.RetrieveDataFromSessionState(String key) at Microsoft.PerformancePoint.ImportUtility.UI.WebPages.ScenarioPageBase.Page_Init(Object sender, EventArgs e) edb1db92-2bd9-4dab-b772-b3b36b293e99

Now, this might lead you to think that something has not installed correctly, as it is complaining about resource files, but like nearly all problems in SharePoint, it comes back to permissions, and user context. The key issue in my case? I had created my own web service application pool to run the PerformancePoint service application under. The managed account for the application pool was a low privilege account (not the farm account for example).

The key thing I had missed was, that I needed to run the following PowerShell to provide my service account with appropriate object access to run the wizard successfully.

$w = Get-SPWebApplication("http://myintranet.company.com")
$w.GrantAccessToProcessIdentity("dev\svc_PPServices")

To be fair, Microsoft do list this in technet, but as with so many MS articles, they fail to tell you why, or how to recognise when you have not done this step.

references: http://technet.microsoft.com/en-us/library/ee748643.aspx

SharePoint 2010 Capacity Guidelines updated for SP1

Major changes seem to be more qualification on IOPS for large content databases, plus some more detailed understanding of the real limits of DB sizes in particular scenarios. Of particular interest is the idea that individual DBs could be up to 4TB in size (though why you would plan for one 4TB database rather than a number of more manageable ones is a different question)

http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?pID=988

Membership & BDC import status hangs with infinite items (SharePoint 2007)

This was a bit of an odd one I came across, caused by a transaction log filling up. Take the following scenario

1. The log file for SharePoint_SSP_Search (the SSP Search database) becomes full, and cannot grow further. The database stops responding
2. The Office Search Service , then the SharePoint timer service throws an error as it cannot contact the database. This causes an error when the crawler tries to pause, and the object cache becomes corrupted (slight speculation here).
3. The SharePoint services continually attempt to communicate with the SQL Server (every second), the net result being that the server is too busy to serve RDP requests (not ideal if doing remote support!)
4. Someone “resolves” the database log size, and restarts all the SharePoint services, including IIS, the Timer Service and Office Search (or server reset)
5. Office Search and Timer resumes, persisting the corrupted object cache data to the database. This has a knock on impact on the “Membership and BDC Import”, which gets stuck in some form of infinite loop (last count, over “56,000” AD records had been imported, in an AD of less than 2,000!)
6. This fills up the transaction log at the rate of a few 100MB a minute, quickly reaching the max log file size again, causing SharePoint to stop responding once more.

The route cause of all this was that the transaction log for the search database was full. In this scenario the reasons was:

1. The log file had been capped at 5GB. This is not necessarily unreasonable, but if it does reach the limit, this triggers the issue.
2. The database is in simple recovery mode
3. The log file will grow with each SharePoint content crawl, or user profile import.
4. The database backup for SharePoint_SSP_Search appears to not be on a daily schedule (last backup was more than 10 days previous). This means that the log file has significantly more time to grow, and shrinking the log nightly has no impact, due to the fact that the database (despite being in simple mode recovery) has not been backed up, and the transaction log space has not been freed for deletion.

To resolve the problem, you can take the following steps:

1. Manually backup/shrink the search database. Note, if your database is maxed on the log file, you may need to allocate more log file space before you can succeed in a manual backup/shrink
2. Created a particular maintenance plan for this database, which backs up nightly, then shrinks the log file. (this stops the trigger for the issue from occurring under "normal" conditions.
3. Stop the troublesome “Membership and BDC Import”
4. Reset all crawled content, which clears out the corrupted data from the search database
5. Started a full user profile import and confirm success.
6. Initiated a full crawl on “Local Office SharePoint Server Sites”, and confirm success

I hope this helps someone else out. If you find a more definitive route cause or fix, please let me know.