Ett helt vanligt dokumentbibliotek i SharePoint 2010, ett synnerligen ovanligt problem. Ibland beter sig SharePoint oerhört märkligt, vilket hände oss nyligen när vi skulle testa versionshantering på ett fullständigt normalt dokumentbibliotek: Alla filer öppnades i skrivskyddat läge, Read-Only, trots att de inte var det.

Allt som beskrivs nedan hände i testmiljö, så ingen kom till skada.

Som sagt, ett helt vanligt SharePoint 2010-bibliotek:

Förväntat beteende när man öppnar en fil för andra gången, för att redigera den, är en dialogruta som frågar om man vill redigera filen ifråga. Den här dialogrutan kickar igång tack vare ett tillägg i Internet Explorer som heter SharePointOpenDocuments, som måste vara aktiverat. På så sätt öppnas filen i temp-mappen och laddas inte ner i Downloads, vilket är vad man vill när man ska göra versionsändringar i SharePoint.

Problemet var att man förvisso kunde öppna i redigera-läge i Word-klienten, men inte spara. Inga versionsändringar kunde sparas. Filen blev Read-Only andra gången den öppnades, helt enkelt. Inte bra. Man vill ju kunna ändra, se att ändringen sparas (laddas upp till SharePoint igen) och att dokumentet fått ett nytt versionsnummer. Man vill inte se detta:

Och då var det bara att börja felsöka. Intensivt, som det visade sig. Här följer våra bästa felsökningstips, lösningen finner du sist ifall du vill scrolla direkt till facit.

Vi kunde utesluta Office-klienten och Internet Explorer som syndare, allt fungerade som sig bör i andra SharePoint-miljöer. Vi var 99 procent säkra att det var något i testservern. Men vad?

Var det SharePoints content-databaser? Kunde de vara låsta eller satta till Read-Only. En snabb titt i Central Administration visade att så inte var fallet.

Kunde det vara webbplatssamlingarna, hade de någon Read-Only inställning som låste för versionsändringar? Vi kollade det också, med samma resultat. De var inte låsta.

Vi passade även på att kolla om Open Documents in Client Application-featuren var aktiverad på berörda webbplatssamlingar. Det var de, så felet berodde alltså inte på inställningen som gör att filer i SharePoint-bibliotek öppnas direkt i Office.

Det är nu man börjar undra på riktigt. Vad är det som pågår egentligen? Nästa steg var att ta fram SharePoint 2010 Management Shell och jämföra build-nummer på servern som strulade och på en som fungerade vad gäller versionsändringar på dokument. Det visade sig att de hade samma build-nummer: 7149. Hade SharePoints ULS-logg något vettigt att säga då? Nej, där loggades inget uppseendeväckande konstigt i samband med en dokument-sparning. Synd.

Ett annat intressant spår som vi följde var kvot-spåret. Det har hänt för andra att liknande problem uppstår når SharePoints diskutrymmeskvot nått sin maxgräns. Då är det stopp för ny data. Men så var inte heller fallet. Webbplatssamlingarna hade inga maxkvoter satta, så det kunde inte vara det.

Nu kändes som att vi hade tömt ut alla våra bästa idéer. Efter otaliga försök att tömma cachen i Internet Explorer, gjort iisreset på servern med mera så var vi nära att ge upp. Men då kom vi på att även kolla i Event Viewern på servern – och där såg det genast lovande ut. Massa errors.

Det som väckte vår nyfikenhet var följande:

WebHost failed to process a request, alltså. Nu var det bara att bekräfta att samma error loggades varje gång vi försökte spara en fil i biblioteket. Och det gjorde det. Med detta fynd, började vi undersöka serverns diverse web.config-filer. Närmare bestämt den i C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI, det vill säga 14-hiven.

Här märkte vi att web.config-filen såg annorlunda ut jämfört med motsvarande på en server där versionshantering fungerade. Helt plötsligt så hade vi en intressant divergens som vi kunde peka på. Web.config-filerna var olika. När vi sedan undersökte den gamla web.config.old-filen visade det sig att den filen minsann var exakt likadan som web.config-filen på miljön där allt fungerar. Nu var det bara dags ta ett modigt beslut, göra backup på config-filerna och ta bort den som avvek och ersätta den med den som såg rätt ut, web.config.old-filen. Efter en iisreset testade vi att redigera ett dokument, och då gick allt bra till allas stora glädje!

Vi misstänker att en gammal obskyr wsp-fil av någon anledning ändrat web.config-filen från roten, vilket resulterade i detta märkliga beteende med att filer endast öppnas som Read-Only.

Den här gången låg skatten gömd i serverns Event Viewer!