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.

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.

After checking that I was using Cached Exchange Mode and that Search was working I ran pstscan and sure enough there were some errors. Deleting my .ost file and restarted Outlook  and as if by magic suddenly everything worked.

Hurrah!

That’s odd I thought I had already done that and a visit to the web.config in c:\inetpub\wwwroot\wss\VirtualDirectories\80 showed that this was the case.

A can of coke and a cup of coffee later I worked out that there is also a web.config in c:\program files\common files\microsft shared\web server extensions\14\TEMPLATE\LAYOUTS and a quick change to that web.config and the error details were now displaying.

After lots of messing around I realised where I had gone wrong and thought I would blog about it in case anyone else made the same mistake - you might find that you have installed SharePoint 2010 as a standalone server in which case User Profile Synchronization doesn’t work. Reinstall as a farm server and you will probably find configuring the User Profile Synchronization service suddenly becomes so much easier.

Exception occurred during request processing. (User: MOSSDEV86\Administrator, Form Name: , IP: , Request:  Form ID: , Type: InfoPathLocalizedException, Exception Message: The specified form cannot be found.)

Looking in Central Administration > Application Management > Manage Form Templates I could see my workflow, status ready and workflow enabled but I still kept getting “The form has been closed”. After a reasonable amount swearing and pulling out of hair I realised that the Form ID specified in Manage Form Templates was different to the one I used in my workflow.xml file. HOW?????

Well, I was saving my InfoPath form and look at the properties to get the URN and then publishing the file to get deployed with my code. What I hadn’t realised was that when you publish the form you then get a different URN!

REMEMBER: Use the URN from the published form and not from the saved one!!!