Erhöhung des Session Timeouts einer SharePoint Seite

Im täglichen Einsatz von SharePoint kann es häufig dazu kommen, dass man etwas auf einer SharePoint Site macht und diese danach für eine bestimmte Zeit offen lässt. Ist eine gewisse Zeit verstrichen und man möchte erneut etwas tun kommt es häufig dazu, dass man sich erneut anmelden muss, da die Session abgelaufen ist. Dies kann mitunter als unangenehm empfunden werden.

Die Lösung für dieses Problem findet sich in der Central Administration.
Über Application Management -> Manage Web Applications -> Web Application auswählen
und die General Settings kann man die Security Validation Expiration setzen.

Standardmäßig ist diese auf 30 Minuten gesetzt. Diese kann man hier erhöhen. Die Expiration auf "Never" zu setzen empfiehlt sich aus Sicherheitsgründen nicht.

Der Vorteil ist, dass man auf verschiedenen Web Applications unterschiedliche Durations setzen kann und so je nach Content die Sicherheit regeln kann.

SharePoint 2010: Unexpected Error bei User Profile Service Application

Bei einigen SharePoint Installationen kann es zu einem merkwürdigen Verhalten der User Profile Service Application kommen.

Folgendes Verhalten kann stellenweise auftreten:

In der Central Administration wird die User Profile Service Application unter Application Management -> Manage Service Applications ausgewählt.

Nach Klick auf die User Profile Service Application und einer kurzen Ladezeit erscheint die Meldung, dass ein unerwarteter Fehler aufgetreten ist.

Da diese Aussage nicht sonderlich hilfreich ist, findet sich der Fehler erst nach dem Durchsuchen der ULS Logs.

Filtert man hier auf UserProfileServiceApplication, trifft man auf folgende Fehlermeldung:

System.MissingMethodException: Method not found: 'System.String
Microsoft.Office.Server.UserProfiles.SynchronizationRunStatus.get_ConnectionName()'.at Microsoft.SharePoint.Portal.WebControls.UserProfileServiceImportStatisticsWebPart.
RenderSectionContents(HtmlTextWriter writer)at
Microsoft.SharePoint.Portal.WebControls.UserProfileServiceImportStatisticsWebPart.RenderWebPart(HtmlTextWriter writer)at Microsoft.SharePoint.WebPartPages.WebPart.Render(HtmlTextWriter writer)

Es gibt mehrere Möglichkeiten, dieses Problem zu lösen, allerdings sei hier erwähnt, dass nicht jede Möglichkeit zwingend zur Lösung führt, sondern einer dieser Ansätze das Problem behebt.

Die einfachste und schnellste Lösungsmethode ist die Durchführung eines IISReset über die Eingabeaufforderung.

Sollte dies nicht helfen, besteht die Möglichkeit, dass bei der Provisionierung der User Profile Service Application und der dazugehörigen Datenbanken kein Standardschema für den Farm Administrator zugewiesen wurde.

Dies kann durch ein SQL Statement auf die betreffenden Datenbanken

     - Profile Database
     - Synchronization Database
     - Social Tagging Database

nachträglich durchgeführt werden.

WICHTIG: Da ein Zugriff auf die Content DB's automatisch den Produktsupport seitens Microsoft aufhebt, sei an dieser Stelle gesagt, dass dies KEIN Eingriff in die Datenbank ist.

Das SQL Statement, um das Schema an den Benutzer zuzuweisen lautet wie folgt:

ALTER USER [Domain\Username] WITH DEFAULT_SCHEMA=dbo;

Allerdings kann es passieren, dass auch dieser Vorgang das Problem nicht behebt.

Die letzte Lösungsmöglichkeit, bevor man einen Microsoft Support Call eröffnet, ist die Installation des December 2011 Cumulative Update Paketes für SharePoint Server 2010.

Diese Installation hat in meinem Fall das Problem behoben und auch in diversen Foren und Newsgroups war zu lesen, dass die Installation des Cumulative Update Paketes dieses Problem löst.

Zu finden ist das Paket unter folgender Url: http://support.microsoft.com/kb/2597014

Nach der Installation des Paketes muss der Farm Configuration Wizard erneut ausgeführt werden, da alle Farm Komponenten dann upgedated werden.

Nach Abschluss des Wizard kann man dann versuchen, noch einmal die User Profile Service Application in der Central Administration zu öffnen.

In meinem Fall funktionierte dies dann ohne weitere Probleme.

Falls jemand noch andere Möglichkeiten zur Behebung des Fehlers findet, freue ich mich darüber, wenn er / sie mir diese Lösung mitteilt. Gerne veröffentliche ich sie auch hier.

Bug SharePoint 2010 Installation All-In One Virtual Machine

Für Demonstrationszwecke bei Kunden und als Spielwiese ist eine virtualisierte SharePoint 2010 Installation eine gute Lösung.

Allerdings gibt es einige Dinge, die hierbei zu berücksichtigen sind.

Abgesehen davon, dass genug Arbeitsspeicher zur Verfügung stehen sollte, um flüssig arbeiten zu können, sollte man im Hinterkopf behalten, dass sich in diesem Fall dann alle Funktionen auf einer virtuellen Maschine zusammengefasst befinden.

Das heißt, folgende Dinge, befinden sich in der VM:
    
     - Betriebssystem (Windows Server 2008 R2 64 Bit)
     - Domain Controller
     - Application Server
     - Mail Server
     - Web Server
     - SharePoint Server 2010
     - SQL Server 2008 R2

Zusätzlich zu diesen Dingen, werden auch die SharePoint Services (z.B. Excel Services, etc.) und auch der User Profile Import zur Synchronisation zwischen AD und MySite auf dieser Maschine durchgeführt.

Speziell, wenn diese Maschine als Domain Controller fungiert gibt es bei der Installation von SharePoint als non-standalone Installation Probleme.

Wenn die SharePoint Setup Routine ausgeführt wird, hat man normalerweise nach der Eingabe des Product Keys die Möglichkeit, auszuwählen, ob die Installation als Standalone (inklusive SQL 2008 Express Edition für die Content Datenbank) oder als Server Farm durchgeführt werden soll.

Befindet sich der Domain Controller nun auf der selben Maschine, bekommt man diese Auswahlmöglichkeit NICHT, sondern es wird auomatisch eine Standalone-Installation durchgeführt, was eindeutig als Bug zu werten ist, auch wenn die Installation sowohl von SQL Server 2008 R2, als auch von SharePoint 2010 auf einem Domain Controller nicht empfohlen wird.

Da es allerdings oft gewollt ist, seine Umgebung auf diese Art und weise aufzubauen (weil z.B. ein normaler SQL Server verwendet werden soll, oder möglicherweise eine weitere Maschine zu einem späteren Zeitpunkt die Farm joinen soll), gibt es eine Möglichkeit, diesen Bug zu umgehen:

Die Lösung ist eine Silent Installation über die Eingabeaufforderung und die Konfiguration in einer Config-Datei zu hinterlegen.

Das Kommando für die Installation lautet wie folgt:

setup.exe /config c:\<location of the config.xml>

Die Konfigurationsdatei, die man an einem beliebigen Ort ablegen kann, gestaltet sich wie folgt:

<Configuration>

    <Package Id="sts">
        <Setting Id="LAUNCHEDFROMSETUPSTS" Value="Yes"/>
        <Setting Id="REBOOT" Value="ReallySuppress"/>
        <Setting Id="SETUPTYPE" Value="CLEAN_INSTALL"/>
    </Package>

    <Package Id="spswfe">

        <Setting Id="SETUPCALLED" Value="1"/>
        <Setting Id="REBOOT" Value="ReallySuppress"/>
        <Setting Id="OFFICESERVERPREMIUM" Value="1" />
    </Package>

    <Display Level="none" CompletionNotice="Yes" />

    <PIDKEY Value="{MSDN KEY FOR EDITION OF SHAREPOINT 2010}" />
    <Setting Id="SERVERROLE" Value="APPLICATION"/>
    <Setting Id="USINGUIINSTALLMODE" Value="0"/>
</Configuration>

Die Installationskonfiguration gibt an, dass es sich um mehrere Packages handelt, die installiert werden sollen.

Eine detaillierte Referenz zu den Möglichkeiten der Installationskonfigurationen befindet sich im Microsoft Technet, erreichbar unter http://technet.microsoft.com/en-us/library/cc261668.aspx

Am wichtigsten sind in diesem Fall folgende Zeilen:

<Setting Id="SERVERROLE"Value="APPLICATION"/>
<Setting Id="USINGUIINSTALLMODE" Value="0"/>

Die 1. Zeile sagt aus, dass der Server als Application Server installiert werden soll, sprich eine neue Serverfarm wird aufgebaut.
Die 2. Zeile sagt aus, dass kein GUI für die Installation verwendet werden soll.

Überprüfen lässt sich der Abschluß der Installation entweder durch folgende Zeile

<Display Level="none" CompletionNotice="Yes" />

In diesem Fall bekommt man nach Abschluss der Installation die Benachrichtigung, dass der Configuration Wizard noch ausgeführt werden soll.

Eine weitere Möglichkeit ist es, den Task Manager zu starten und so lange abzuwarten, bis kein msiexec Prozess mehr ausgeführt wird, wobei ich die CompletionNotice bevorzuge.

Danach wird dann noch der Configuration Wizard ausgeführt und die Installation der Farm ist erfolgreich abgeschlossen.