Visio would display the following error when someone tried to check in a Visio file into a SharePoint 2010 Document Library:

Internal Error: #3400

Action 1787: Check in file

First try closing and reopening the file. Next try restarting Visio.

Cause:

One of the fields in the document library had been set to required and as no data had been put into that field the file wasn’t able to be checked-in.

Resolution:

In this case we were able to set the field to optional.

Part of the SharePoint extranet solution used ISA Server 2006 and my gut feeling was that somehow it was ISA 2006 that was causing the problem. I don’t have much experience with ISA 2006 and it is always easy to blame problems on the thing you know least about.

Fortunately I was investigating another SharePoint issue when I noticed that we didn’t have the output cache enabled in SharePoint. Turning on the output cache (Site Collection Administration, Output Cache Settings) and setting the Authenticated Cache Profile to Intranet (Collaboration Site) and now Extranet is performing as expected.

Looks like I will be spending a bit more time going through the SharePoint Cache documentation on Technet and its an important reminder that it easy to blame the thing you least know about when investigating an issue

Log Name:      Application
Source:        Microsoft-SharePoint Products-SharePoint Foundation
Event ID:      6398
Task Category: Timer
Level:         Critical
Description:
The Execute method of job definition Microsoft.SharePoint.Diagnostics.SPSqlBlockingReportDiagnosticProvider (ID e0c0213b-63fc-4ede-acc9-7a569ba95812) threw an exception. More information is included below.

You do not have permission to run ‘SP_TRACE_CREATE’.

and

Source:        Microsoft-SharePoint Products-SharePoint Foundation
Event ID:      6398
Task Category: Timer
Level:         Critical
Description:
The Execute method of job definition Microsoft.SharePoint.Diagnostics.SPSqlBlockingReportDiagnosticProvider (ID e0c0213b-63fc-4ede-acc9-7a569ba95812) threw an exception. More information is included below.
The blocking query diagnostics provider could not set the ‘blocked process threshold’ for the sql instance SPSQL01.  Blocking queries will not be captured in this instance.  Error Code: User does not have permission to perform this action.
You do not have permission to run the RECONFIGURE statement.
The configuration option ‘blocked process threshold’ does not exist, or it may be an advanced option.
You do not have permission to run the RECONFIGURE statement.

Solution

On the SQL server make sure the account specified in the username of the events has ALTER TRACE and ALTER SETTINGS enabled. You can do this through Management Studio by selecting the username and changing the securables.

The event details were:-

Source:        MsiInstaller
Event ID:      1001
Level:         Warning
Keywords:      Classic
User:          NETWORK SERVICE

Detection of product ‘{90140000-104C-0000-1000-1000000FF1CE}’, feature ‘PeopleILM’ failed during request for component ‘{1681AE41-ADA8-4B70-BC11-98A5A4EDD046}’

Source:        MsiInstaller
Event ID:      1015
Level:         Warning
Keywords:      Classic
User:          NETWORK SERVICE

Failed to connect to server. Error: 0×80070005

Resolution:

The resolution suggested by http://support.microsoft.com/kb/2473430 was to give the NETWORK SERVICE account access to the %programfiles%\Microsoft Office Servers\14.0 folder and sure enough that has done the trick.

The Problem

I have a document library with 16 documents in it.

3 documents have the reporting week set to Week 1
4 documents have the reporting week set to Week 2
5 documents have the reporting week set to Week 3
4 documents have the reporting week set to Week 4

As you can see below, the view is grouped by Reporting Week, sorted by Created and I have set the item limit to a low number just to recreate the problem without having to create 100s of documents.

Page 1.

The first page looks perfectly normal and the group total for Week 2 is correct so when I click the arrow to goto the next page I would expect to see the other 2 documents for Week 2 but instead I see…

Page 2.

Where have the rest of Week 2 gone? All I can see if the 5 documents for Week 3 – perhaps they are on the next page?

Page 3.

Nope. No Week 2 documents are on Page 3. I know I will click the arrow to go back to the previous page…

Page 2 again

Oh! Now one of the missing Week 2 documents has appeared – but I’m still missing one.

Anyway you get the idea – it’s in a right mucking fuddle with groups totals correct but documents missing and no wonder the poor users of this site are confused.

The Fix

The fix!

Uncheck the checkbox for “Sort only by specified criteria” and the views work correctly with all documents visible and no there aren’t any folders are permission inheritance issues.

Image 1

After creating an empty SharePoint 2010 solution in Visual Studio 2010 I added an Application Page to the project but compiling failed and gave me the following error:

The type or namespace name ‘LayoutsPageBase’ does not exist in the namespace ‘Microsoft.SharePoint.WebControls’ (are you missing an assembly reference?)

Image 2

Using the object browser in Visual Studio I could see that the namespace Microsoft.SharePoint.WebControls didn’t contain LayoutsPageBase (Image 1) but when I viewed the same Microsoft.SharePoint.dll outside of Visual Studio (in Red Gate Reflector) I could see (Image 2).

The reason for this was quite simple when I created the SharePoint Project I had chosen to deploy it as a Sandbox Solution and application pages are not supported in sandboxed solutions. Selecting the project properties and changing the Sandboxed Solution property to False and it compiled successfully.

Fortunately you can do the same thing with some simple powershell:-

Add-Type -Path "c:\program files\common files\microsoft shared\web server extensions\14\isapi\microsoft.office.server.dll"
$mySiteUrl = "http://yourmysitegoeshere"
$site = Get-SPSite $mySiteUrl
$context = Get-SPServiceContext $site
$upConfigManager = New-Object Microsoft.Office.Server.UserProfiles.UserProfileConfigManager($context)
$profilePropertyManager = $upConfigManager.get_ProfilePropertyManager()
$upConfigManager.GetProperties().SetDisplayOrderByPropertyName("NameOfProperty", OrderNumber)

The powershell method is a much easier way to re-order things I’m sure you will agree

The first error was shown when the excel spreadsheet was being displayed in the browser and you clicked on the Open In Excel button.

“To open this workbook, your computer must have a version of Microsoft Excel installed and your web browser must support opening files directly from Excel in the browser.”

The second error was seen when trying to Open in Excel from the Document Library view.

“The document could not be opened for editing. A Microsoft SharePoint Foundation compatible application could not be found to edit the document.”

Solution

The answer to the problem was that they were using some sort of quick launch application which was always executing the 64 bit version of IE and switching to the 32 bit version worked.

Opening the view in SharePoint 2010 I could see a ribbon option labeled Customize XSLT which enabled me to edit the way that the view was displayed by editing the XSL and in SharePoint Designer 2010 everything looked fine but the original version of the view always displayed in the web browser.

Eventually I remembered coming across the ddwrt:ghost attribute and changing it from ddwrt:ghost=”show” to ddwrt:ghost=”" resolved the issue.

Hopefully the Combined Knowledge Developer training I am doing in December will help reduce the amount of time I spend on these SharePoint oddities.