Am Mittwoch dem 15.12.2009 wurde das Cumulative Update Dezember 09 für Windows SharePoint Services 3.0 und  Microsoft Office SharePoint Server 2007 veröffentlicht. Über die folgenden Links können sowohl das WSS 3.0 als auch das MOSS 2007 Full server package heruntergeladen werden.

WSS 3.0

• Full server package (977027): http://support.microsoft.com/default.aspx?scid=kb;EN-US;977027
• Hotfix Downloads: http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=977027&kbln=en-us

Das Paket beinhaltet die folgenden Hotfixes:

• 977022
• 977731
• 977732

MOSS 2007

• Full server package (977026): http://support.microsoft.com/default.aspx?scid=kb;EN-US;977026
• Hotfix Downloads: http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=977026&kbln=en-us

Das Paket beinhaltet die folgenden Hotfixes:

• 977023
• 977024
• 977028

Installation:

Nach erfolgter Installation des Service Pack 2 für MOSS und WSS können die Server packages 977026 & 977027 installiert werden.
Im Anschluss muss der Sharepoint Configuration Wizard ausgeführt werden.

Am 2. Dezember 2009 fand in Düsseldorf der 2.  iX Day rund um SharePoint statt. Nach dem Erfolg des ersten iX Tages im Juli sollte sich diesmal alles rund um Sharepoint, speziell Sharepoint 2010 drehen. In über 25 Sessions kam der ambitionierte Sharepointer voll auf seine Kosten. Das Themengebiet erstreckte sich von entwicklerlastigen Vorträgen, welche sich mit der API Unterstützten Programmierung von Sharepoint befassten über Vorträge der administrativen Art bis hin zur neuen Sharepoint Pie.

Artikel vollständig lesen »

Seit einigen Wochen findet sich auf der “Updates Resource Center for SharePoint Products and Technologies” Seite von Microsoft ein Verweis auf einen Artikel im Microsoft SharePoint Team Blog zum Thema “Install SharePoint Server 2007 on Windows Server 2008 R2“.

Da uns noch für einige Zeit der gute alte SharePoint 2007 erhalten bleibt, habe ich den Installationsweg auf einem Windows Server 2008 mit SQL Server 2008 evaluiert.

Artikel vollständig lesen »

Durch die Integration von PowerShell in SharePoint 2010 geht Microsoft endlich einen Weg in die richtige Richtung. Schon im Beta Status sind sehr viele STSADM Befehle entfernt und nur sehr wenige hinzugefügt wurden. Ungefähr 20 Befehle wurden entfernt und nur 6 hinzugefügt. Dies ist einfach nachzuvollziehen in dem

stsadm -help

jeweils auf einem Sharepoint 2007 System und auf einem Sharepoint 2010 System ausgeführt und anschließend die Ausgabe verglichen wird. Ich finde diesen Weg richtig cool. Wahrscheinlich weil ich mich mit STSADM nie so richtig anfreunden konnte.

PowerShell eröffnet dem geneigten Administrator oder Entwickler jetzt vollkommen neue Ansätze Sharepoint zu administrieren.

Jeder Entwickler , welcher mit dem Sharepoint Objekt Modell schon etwas vertraut ist, wird vermutlich wissen, dass Instanzen von SPSite, SPWeb oder im allgemeinen alle Klassen welche IDisposable implemtieren, sehr viele Ressourcen verbrauchen können. Gleich zum Start hat das Sharepoint Team nun zwei CMDLETS entwickelt welche den Umgang mit Disposable Objekten vereinfachen sollen und uns das Leben erleichtern.

Start-SPAssigment

Stop-SPAssigment

Es gibt drei Levels des Assignments.

• No Assignment
• Simple Assignment
• Advanced Assignment

No Assignment

Diesen Weg sollte jeder kennen. Es wird ein SPWeb Objekt erstellt, welches verarbeitet aber nicht mehr disposed wird.

$web = Get-SPWeb "http://localhost"
$web.Title = "Hallo SharePoint Usergroup"
$web.Update()

Simple Assignment

Beim “simple assignment” werden alle Objekte dem “global assignment store” zugewiesen. Der Aufruf erfolgt per

Start-SPAssignment -Global

Das “Disposen” aller Objekte erfolgt beim Aufruf von

Stop-SPAssignment

Start-SPAssignment -Global
$web = Get-SPWeb "http://localhost"
$web.Title = "Hallo SharePoint Usergroup"
$web.Update()
Stop-SPAssignment -Global

Advanced Assignment

Beim “advanced assignment” werden alle Objekte einem “named store” zugewießen. Das “Disposen” erfolgt durch den Aufruf von Stop-SPAssignment  -Bezeichner

$gc = Start-SPAssignment
$site = $gc | Get-SPSite "http://localhost"
$site.Allwebs
$gc | Stop-SPAssignment

Zu beachten wäre noch dass beim Schließen der PowerShell alle Objekte “disposed” werden.

Vom 22 – 24.09.2009 hatte ich, dank meiner Firma, die Gelegenheit zur Shareconnect & Basta 2009 in Mainz zu fahren. Das ist zwar jetzt schon fast einen Monat her, jedoch will ich euch meine Eindrücke nicht vorenthalten.

Die Shareconnect findet im Rahmen der Basta statt und baut auf  den Sharepoint Days auf, welche seit 2007 parallel zur Basta stattfinden. In über 50 Sessions geben Experten Einblicke in die Sharepoint Welt sowohl aus Administratoren Sicht, als auch aus der Sicht von Entwicklern. Da durften auch die Experten von Communardo nicht fehlen.

Nach einem anstrengenen Flug und Bahnerlebnis und einem anschließenden Gewaltmarsch über die Theodor-Heuss-Brücke erreichte ich am 22.09 pünktlich zur ersten Session die Rheingoldhalle in Mainz. Begrüßt wurde jeder Teilnehmer mit dem Basta Survival Pack bestehend aus Rucksack, T-Shirt und allerlei Büromaterial ( Danke nochmal). Danach hat es mich direkt in den Vortrag von Oliver Sturm verschlagen, welcher bereits eifrig über die Zukunft von C# und .NET philosophierte, Co- und Kontravarianz erläuterte und die dynamischen Erweiterungen von .NET 4 vorstellte.

Gott sei dank habe ich mir im Vorfeld bereits die Sessions der Konferenz zusammengestellt, was gar nicht so einfach war.  Das Angebot umfasste rund 90 Sessions, wobei jeweils ca. 9 gleichzeitig liefen. Dank des tollen Zeitplaners konnte man aber den Überblick behalten und keine der Veranstaltungen verpassen.

Nach dem Vortrag von Oliver Sturm zog es mich direkt zu der ersten Sharepoint Session von Björn Schneider : “Planung und Aufbau von hochverfügbaren SharePoint-Infrastrukturen”.

Christian Glessner veranstaltete im Anschluss die Sharepoint Freak Show. Hier wurden richtig coole Ansätze gezeigt, Sharepoint mit jQuery, PowerShell, IronRuby oder IronPyhton zu erweitern. Seit Christians Demos, welche den Umgang  mit Powershell und Sharepoint zeigten, bin ich richtiger Fan der Powershell geworden.

Weiter ging es mit einer Demonstration wie extrem sich Sharepoint bezüglich seines User Interfaces verbiegen lässt. Michael Hofer zeigte anhand eines Fallbeispieles wie Sharepoint mit Hilfe von Bordmitteln zu einem Intranetportal ähnlich der Startseite von www.bbc.com umgebogen werden kann. Auch wenn die Technik an diesem Tag nicht mitspielte , anhand der Screenshots konnte man schon sehr gut erkennen welche Lesitung in diesem Customizing Projekt erbracht wurde.

Für die letzte Session des Tages habe ich mir “(Keine) Zeit für Herzrasen” von Torsten Weber gegönnt. Am besten ist dieses Thema durch Torstens eigene Worte beschrieben:

Es geht um Handlungsmaximen für eine ausgeglichene Work-Life-Balance, “Entschleunigung” für Fortbildung, Freiräume und Erfolg mit Werkzeugen wie MindManager oder Livescribe.

Obwohl dieser Vortrag so rein gar nichts mit Programmierung oder IT zu tun hat, habe ich es genossen Torstens Worte zu folgen. Wer mehr zu dem Vortrag erfahren möchte kann ihn hier nochmal nachlesen.

So ging er zu Ende dieser erste Tag der Shareconnect & Basta in Mainz. Zwischen den Sessions wurde man durch das Konferenz Team mit reichlich Kaffee, Kuchen, Brötchen und warmen Mahlzeiten am Mittag versorgt. Ganz nebenbei konnte ich nette Kontakte knüpfen und Produkte von Firmen bestaunen. Es gab sogar die Möglichkeit sich massieren zu lassen.

Pünktlich 8:30 ging es dann am Mittwoch mit Bus und Bahn zur Reingoldhalle, zum zweiten Tag der Basta. Nach einer kurzen Auffrischung meiner Webpartentwicklungs – Kentnisse mit Renè Hèzser verschlug es mich zu Manfred Steyers Session “Codequalität mittels Code Contracts und PEX”.  Da meine Interessengebiete in Codequalität und Clean Code Development liegen, war ich sehr interessiert daran wie Code mittels Code Contracts besser und sicherer gestaltet werden kann. Zunächst entwickelte Manfred Steyer eine unscheinbare C# Klasse, welche ein Taschengeldkonto verwalten kann. Nach und nach wurden Mängel und Lücken im Quellcode aufgedeckt und anschließend erläutert, wie diese durch Code Contracts und PEX verhindert werden können. Für mich eine der besten Sessions der Basta.

Die letzten drei Sessions für diesen Tag waren sehr von Silverlight 3 geprägt. Los ging es mit Christian Wenz, welcher alle prägnanten Neuigkeiten in Silverlight 3 präsentierte. Dazu gehören Features wie Element Data Binding, 3D Unterstützung oder das legendäre Out Of Browser Funktionalität
Oliver Scheer schloss sich den Ausführungen von Christian Wenz fast nahtlos an und erläuterte wie Silverlight 3 für Enterprise Business Aplikationen verwendet werden kann. Silverlight 3 bringt dazu schon einiges an Funktionalität mit, wie etwa die eben genannte Out Of Browser Fähigkeit, smooth streaming oder die neuen RIA Services. Obwohl Olivers Vortrag eher sehr multimedialastig gehalten war und ich den Enterprise Aplikations Teil ein wenig vermisst habe war die Darbietung von Oliver wie immer sehr genial. Jörg Krause beendete den Tag mit einem Überblick der Methoden um Webparts in Kombination mit Silverlight zu verwenden.

Selbst den Abend konnte man auf der Basta verbringen indem man sich beispielsweise direkt auf das BASToberfest gesellte.

Der dritte und somit letzte Tag der Basta war für mich komplett von Silverlight und WPF geprägt. So ging es pünktlich 8:30 mit Oliver Scheer und seinen Ausführungen zu “Design the next RIA Generation” los. Nach diesem Vortrag sollte auch der Letzte alle neuen Features von Silverlight 3 kennen Ob Ton, Bild, Streaming ,Styling oder Skinning.
Markus Egger zeigte in den nachfolgenden 2 Sessions wie WPF & Silverlight Business Applications gestylet und anschließend in wiederverwendbare Komponenten ausgelagert werden werden können.  Auch diese beiden Tracks kann ich mit gutem Gewissen zu meinen persönlichen Highlights der Basta zählen. Anhand eines aktuellen Projektes erklärte er wie mit Hilfe von Styling und Skinning die Performance und Usablity einer Applikation gesteigert werden kann. Anschließend zeigte er auf welche Art und Weise Silverlight Komponenten ausgelagert und somit zu wiederverwendbaren Komponenten gewandelt werden können. Auch aus diesen Erläuterungen konnte ich sehr viel für mich mit nach Hause nehmen. Die für mich letzte Session der Basta verbrachte ich bei Jan Blessenohl von Telerik und seinen Ausführungen zu Silverlight und dem RIA Framework.

Vor der täglichen  Mittagspause fanden sogenannte KeyNotes statt in denen Sprecher wie Tony Lanni oder aber auch Frank Fischer von Microsoft die Zuschauer unterhielten.Tonny Lanni erklärte in seiner KeyNote “What can Sharepoint do for you” wie sehr er die Sharepoint Fee mag und diese Figur in seiner Firma wiederspiegelt. Hier nochmal für alle das Video

[youtube]http://www.youtube.com/watch?v=lw-OHO3UMco&feature=PlayList&p=328055501A304058&playnext=1&playnext_from=PL&index=36[/youtube]

Abschließend kann ich feststellen, dass sich die Shareconnect und Basta 2009 für mich persönlich sehr gelohnt hat. Ich konnte viele für mich neue Gesichter kennenlernen und auch viele Anregungen mit nach Hause nehmen.

Heute habe ich versucht, über ein Nutzerinterface (GUI) eine Site Collection (Websitesammlung) anzulegen, welche über eine eigene Url erreichbar ist (Host Named Site Collection). Wie erwartet ging dies nicht ohne jegliche Komplikationen über die Bühne.

Um eine Host Named Site Collection anzulegen, stehen dem Entwickler zwei Varianten zur Verfügung. Die erste und von mir bevorzugte ist die programmatische:

Mit der folgenden Methode (z.B. in einer Konsolenanwendung) kann eine Host Named Site Collection angelegt werden:

void createHostNamedSC(string siteUrl,string siteName,string siteDescription)
{
SPWebApplication webApp = SPWebApplication.Lookup(new Uri(SPContext.Current.Web.Url));
SPSiteCollection sites = webApp.Sites;
SPSite Site = null;
Site = sites.Add(siteUrl, siteName, siteDescription, 1033, “STS#0″, “Domain\\Administrator”, “Owner_Display_Name”, “Owner_Email”, “Domain\\Administrator”, “Secondary_Owner_Display_Name”, “Secondary_Owner_Email”, true);
}

Die zweite Variante wird über stsadm realisiert:
Dazu wird in der Console folgender Aufruf gestartet:

stsadm.exe -o createsite
-url http://hnsc.webapplication.com
-ownerlogin Domain\Administrator
-owneremail Administrator@webapplication.com
-hhurl http://www.webapplication.com

Die Webapplication stellt dabei der Eintrag hinter -hhurl (http://www.webapplication.com) dar.
Unter -url wird die gewünschte URL der neuen Site Collection angegeben.

Hat man sich für eine der beiden Methoden entschieden und diese ausgeführt, müssen noch die Hostheader für die Webapplikation angepasst werden. Das Hinzufügen der Hostheader kann einerseits über die Sharepoint Zentral-Administration erfolgen oder aber über den Internet Information Services (IIS) Manager.
Ich habe mich dabei für die Einstellung innerhalb des IIS entschieden.

Dazu öffnet man den IIS Manager und öffnet über das Kontext-Menü die Einstellungen (Properties) der Webapplikation.

• Anschließend wählt man Advanced
• Menüpunkt Add wählen
• Als letzter Schritt muss der Port und die Domain noch eingetragen werden
• Alles bestätigen und einen IIS Reset durchführen (ggf. host Datei Domain eintragen)

Nach diesen Schritten sollte die eben erstelle Site Collection unter ihrer Domain aufrufbar sein.

Nachdem ich diese Schritte alle erfolgreich ausgeführt hatte, versuchte ich mich nun an meiner neuen Host Named Site Collection anzumelden. Obwohl ich augenscheinlich alle Credentials ordnungsgemäß eingegeben hatte, bekam ich folgende Seite zu sehen:

HTTP 401.1 – Nicht autorisiert: Fehler bei der Anmeldung

Nachdem ich schon fast anfangen wollte, mir die Haare auszureißen, fand ich eine Bugbeschreibung von Microsoft unter

Fehler 401.1 beim Aufrufen einer Website

Update:

Spencer Harbar weißt auf seinem Blog, in einen interessanten Artikel,  darauf hin, dass dieser Bugfix nicht auf Produktiv – Maschinen eingesetzt werden sollte. Für den externen Zugriff auf die Site Collection tritt dieses Problem in der Regel nicht auf. Deshalb richtet sich dieser Fix nur an Entwickler welche auf der selben Maschine mit mehr als einer Host Named Site Collection arbeiten.

Laut Microsoft tritt dieser Fehler nur auf, wenn die Website integrierte Authentifizierung verwendet und ihr Name der lokalen Loopbackadresse zugeordnet ist. Wenn dann noch Windows Server 2003 mit SP1 installiert ist, schlägt der Fehlerteufel zu. Demnach schlägt die Authentifizierung fehl, wenn der Domänenname oder der benutzerdefinierte Hostheader nicht mit dem lokalen Computernamen übereinstimmen.

Um den Bug zu beheben, müssen folgende Schritte ausgeführt werden.

• Registry Editor öffnen mit “regedit”
• Schlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa suchen
• auf LSA mit rechter Maustaste drücken ->Neu->DWORD
• Name DisableLoopbackCheck vergeben und Wert 1 eintragen
• Computer neu starten

Nach dem Neustart war ich in der Lage, die Site Collection unter ihrer Domain aufzurufen.

Da ich gerade einige Zeit in Grundlagenforschung (in Form von Googlen und viiiel Ausprobieren…) zum Thema Site Variations investiert habe, hier meine gesammelten Erkenntnisse am Stück:

Der MOSS bietet die Möglichkeit, sogenannte Site Variations anzulegen. Diese sind (nicht nur, aber vor allem) eine Grundlage für mehrsprachige Systeme.

Site Variations sind standardmäßig deaktiviert. Zur Aktivierung geht man wie folgt vor:

1. -> Site Settings -> Modify All Site Settings aus dem Site Actions Menü auswählen
2. Auf der Site Settings Seite den Link Variations unter der Gruppe Site Collection Administration auswählen

Standardeinstellungen für Variations

Wenn die Standardeinstellungen für Variations (s. Screenshot) verwendet werden, gilt folgendes:

• Automatic Creation
  • Wenn eine Site oder Page in der Quellvariation erzeugt und dort publiziert wird, wird sie automatisch in jeder Zielvariation erzeugt und ist dort für Administratoren und Approver sichtbar
    • Für normale Nutzer ist sie in einer Zielvariation per Default nicht sichtbar, es kommt “Access denied”, wenn man direkt auf die Url geht.
    • Damit sie in einer Zielvariation auch für normale Nutzer sichtbar ist, muss sie noch von einem Approver oder Administrator in der Zielvariation publiziert werden.
• Recreate Deleted Target Page
  • Wenn in einer Zielvariation eine Sites oder Seite gelöscht wird, wird diese automatisch in der Zielvariation erneut erstellt, sobald in der Quellvariation eine Änderung an der Site bzw. Seite vorgenommen und publiziert wurde.
  • Sie ist dann für Administratoren und Approver sichtbar und muss in der Zielvariation publiziert werden, damit sie für alle Nutzer sichtbar ist.
• Update Target Page Web Parts
  • Wenn in einer Seite in der Quellvariation Webparts hinzugefügt oder gelöscht oder Eigenschaften oder Content (!) geändert werden und die Änderung publiziert wird, wird die Änderung automatisch in jeder Zielvariation angewendet und ist dort für Administratoren und Approver sichtbar.
    • Evtl. in einer Zielvariation vorgenommene Änderung (insbesondere geänderter Content, z.B. übersetzter Text in einem Content Editor Webpart oder im bei Verwendung von Page Layouts verfügbaren Content Editor Control direkt auf der Seite) wird durch die aktuelle Änderung gnadenlos überschrieben!
    • Für normale Nutzer ist die Änderung in einer Zielvariation per Default nicht sichtbar, es wird weiterhin die bis dahin gültige Version angezeigt.
    • Damit die Änderung in einer Zielvariation auch für normale Nutzer sichtbar wird, muss sie noch von einem Approver oder Administrator in der Zielvariation publiziert werden.
  • Es ist möglich, dass ein Approver in einer Zielvariation unabhängig von der Quellvariation Änderungen vornimmt (neue Seite, Änderungen an Webparts, Content) und diese Änderungen durch Publizieren für alle Nutzer dieser Variation sichtbar macht.
    • Man sollte sich aber dabei dessen bewusst sein, dass diese Änderungen (zumindest für alle Approver und Administratoren) in der Standardeinstellung durch Anpassungen an der Quellvariation wieder überschrieben werden.

Im Folgenden wird beschrieben, wie man an den Standardeinstellungen schrauben kann und was genau das Ändern jeder einzelnen Einstellung bewirkt.

Gelöschte Seiten nicht neu anlegen

Die Einstellung „Recreate Deleted Target Page” kann jederzeit geändert werden. Eine Änderung der Einstellung wirkt sich auf alle zukünftigen Anpassungen an Seiten aus.

Wenn die Option “Do not recreate a new target page when the source page is republished” ausgewählt ist, gilt folgendes:

• Wenn in einer Zielvariation eine Sites oder Seite gelöscht wird, wird diese nicht erneut in der Zielvariation erneut erstellt, wenn in der Quellvariation eine Änderung an der Site bzw. Seite vorgenommen und publiziert wurde.
• Wenn die Option wieder geändert wird auf “Recreate a new target page when the source page is republished”, dann wird eine in einer Zielvariation gelöschte Seite nach der nächsten Anpassung der Seite in der Quellvariation und Publikation auch in der Zielvariation erneut erstellt.

Webpart-Änderungen nicht anwenden

Die Einstellung „Update Target Page WebParts” kann jederzeit geändert werden. Eine Änderung der Einstellung wirkt sich auf alle zukünftigen Anpassungen an Seiten aus.

Wenn die Option “Do not update Web Part changes to target pages when variation source page update is propagated” ausgewählt ist, gilt folgendes:

• Wenn in einer Seite in der Quellvariation Webparts hinzugefügt oder gelöscht oder Eigenschaften geändert werden und die Änderung publiziert wird, wird die Änderung nicht in den Zielvariationen angewendet.
• Wenn in einer Seite in der Quellvariation Content direkt (nicht in einem Webpart) geändert wird (z.B. Textbausteine oder Text in einem Content Editor) und die Änderung publiziert wird, wird die Änderung trotzdem automatisch in jeder Zielvariation angewendet und ist dort für Administratoren und Approver sichtbar. Evtl. gleichzeitig oder vorher vorgenommene Änderungen an Webparts werden trotzdem nicht angewendet.
• Alle Aussagen zur Erstellung von Seiten und Sites gelten wie bei den Standardeinstellungen beschrieben. Insbesondere gilt:
  • Wenn eine Seite in der Quellvariation erstellt und vor dem ersten Publizieren Webparts hinzugefügt und konfiguriert werden (z.B. ein Content Editor Webpart mit eingefügtem Inhalt in der Quellsprache), dann wird die komplette Seite incl. aller Webparts/Inhalte beim Publizieren in der Zielvariation erzeugt.
  • Wenn nach dem ersten Publizieren Änderungen bzgl. Webparts vorgenommen werden, werden diese nicht mehr angewendet.
• Wenn die Option geändert wird auf “Update Web Part changes to target pages when variation source page update is propagated”, dann werden nach der nächsten Anpassung einer Seite in der Quellvariation und Publikation auch Änderungen in der Zielvariation angewendet, die vorgenommen wurden, während die Option auf „Nicht anwenden“ eingestellt war.

Variation Labels

Den Abschluss meines kleinen Exkurses sollen die folgenden Erläuterungen zu Variation Labels bilden:

• Ein Variation Label entspricht einer Variation, also z.B. einer Sprache.
• Quell- und Zielvariationen
  • Es gibt genau eine Quellvariation und n Zielvariationen.
  • Die Rollen als Quell- und Zielvariation können nicht nachträglich getauscht werden!
• Genehmigungsworkflow
  • Beim Erstellen der Quellvariation muss ausgewählt werden, ob eine Publishing Site mit oder ohne Workflow als Template verwendet werden soll. Diese Einstellung ist nicht nachträglich änderbar.
  • Es ist möglich, eine Publishing Site ohne Workflow auszuwählen und manuell den MOSS-Standard-Approval-Workflow oder einen angepassten Workflow in der Pages-Dokumentenbibliothek zu aktivieren.
  • Wenn ein Genehmigungsworkflow aktiviert ist, werden Änderungen in der Quellvariation beim Publizieren nicht unmittelbar in der Zielvariation angewendet, sondern der Genehmigungsworkflow startet und erst wenn dieser erfolgreich beendet wurde, werden (abhängig von den Grundeinstellungen für Variationen) die Änderungen in der Zielvariation angewendet.
• Hierarchien erzeugen
  • Das Erstellen der Hierarchie erzeugt die Infrastruktur (Sites und Seiten) für die einzelnen Variationen. Bevor eine Hierarchie erstellt werden kann, müssen zumindest eine Quellvariation und eine Zielvariation vorhanden sein.
  • Es können nachträglich weitere Zielvariationen hinzugefügt werden. Damit diese physisch angelegt werden, muss die Hierarchie erneut erstellt werden.

Das ein oder andere Projekt erfordert die Aktivierung von Websiteverwendungsberichten unter Sharepoint. So auch aktuell bei einem unserer Projekte. Verwendungsberichte (Usage Reports) ermöglichen es Administratoren Statistiken über die Verwendung der Website oder Websitesammlungen (Sitecollections) zu erstellen und einzusehen.

Grundsätzlich müssen zum Aktivieren der Verwendungsberichte drei aufeinander aufbauende Komponenten aktiviert und konfiguriert werden.

• Windows Sharepoint Services Verwendungsprotokollierung

• SSP Verwendungsberichtsdienst

• Berichtserstellungsfeature innerhalb der Webseite oder Webseitensammlung

Problematisch kann es werden, wenn man eine Website mit aktiviertem Websiteverwendungsbericht über seine IP-Adresse aufrufen will (NullReferenceException). Weiter unten im Beitrag erfahren Sie mehr über das Problem und dessen Lösung.

Doch kommen wir zunächst erst einmal zur Konfiguration, hier gibt es schon den ersten Fallstrick.

Aktivierung der Verwendungsprotokollierung unter WSS

1. Gehen Sie innerhalb der Zentraladministration auf Vorgänge
2. Innerhalb der Vorgänge Übersicht auf Verarbeitung der Verwendungsanlayse
3. Setzen Sie die Häkchen bei “Protokollierung aktivieren” und “Verarbeitung der Verwendungsanalyse aktivieren” (Wichtig!!!!!!!!!!!)

Etwas irreführend ist die Tatsache, dass beide Optionen gesetzt sein müssen. Sind nicht beide Optionen gesetzt wird folgende Fehlermeldung generiert.

Englisch: “Both Windows SharePoint Services Usage logging and Office SharePoint Usage Processing must be enabled to view usage reports.”
Deutsch: “Windows SharePoint Services Usage Logging-und Office SharePoint Usage Verarbeitung muss aktiviert sein…”

Wird eine der beiden Meldungen ausgegeben ist dies der erste Ansatzpunkt um nachzuschauen.

SSP Verwendungsberichtsdienst aktivieren

1. Gehen Sie Innerhalb der Shared Service Provider Homepage (SSP) auf Office SharePoint-Verwendungsbericht und
   anschließend auf Verwendungsbericht.
2. Menüpunkt “Verarbeitung der Verwendungsanalyse konfigurieren”
   
3. Häkchen bei Verarbeitungseinstellungen und Suchabfrageprotokollierung aktivieren setzen

Berichtserstellungsfeature aktivieren

Nach der Aktivierung der Dienste innerhalb der Farm und des SSP kann das eigentliche Feature der Webseiten oder Webseitensammlungen aktiviert werden.

1. Navigieren Sie zu der Webseite oder Webseitensammlung
2. Rufen Sie die Webseiteneinstellungen unter Webseitenaktion auf
3. Rufen Sie im Abschnitt Websitesammlungsverwaltung die Websitesammlungs-Features auf (Site Collection Features)
4. Aktivieren Sie die das Feature Berichterstellung

Führen Sie am Ende einen Reset der Internet Information Services durch (IIS Reset).

NullReferenceException : Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt

Falls Sie,wie ich, nach dem Reset des IIS folgende Fehlermeldung bekommen, hilft folgende Vorgehensweise.
Dieser Fehler tritt nur auf, falls eine Seite über ihre IP Adresse aufgerufen wurde. Grund dafür ist der fehlende Eintrag der IP Adresse innerhalb der
Alternativen Zugriffsordnungen (Alternate Access Mappings).

Vorgehensweise:

1. Öffnen Sie die Zentraladministration und rufen Sie den Punkt Vorgänge auf
2. Rufen Sie innerhalb des Vorgängebereichs den Punkt “Alternative Zugriffsordnungen”
3. Klicken Sie auf “Interne URLs hinzufügen”
   
4. Tragen Sie im nachfolgenden Dialog die URL ein unter welcher die Seite später erreichbar sein soll. Wählen Sie die Zone sowie die Sammlung aus
   die für die IP Adresse gelten sollen.
   

Nach diesen Änderungen sollte die Seite sowohl über die IP Adresse, als auch über den Namen aufgerufen werden können.

Standardmäßig ist anonymer Zugriff in Sharepoint nicht aktiviert. Um Sharepoint für den anonymen Zugriff zu konfigurieren, sind mehrere Schritte an verschiedenen Stellen (und in dieser Reihenfolge!) erforderlich:

Zuerst muss in der Sharepoint Zentraladministration der anonyme Zugriff aktiviert werden:

• Zentraladministration öffnen
• Klickpfad: Application Management -> Application Security -> Authentication providers
• Rechts oben im Dropdown die gewünschte Web Application auswählen
• Zone: Default
• Checkbox “Enable anonymous access” aktivieren

Nun sollte im IIS Manager kontrolliert werden, ob dort (durch die eben getätigte Änderung in der Zentraladministratio) die Zugriffsberechtigungen entsprechend angepasst wurden:

• IIS Manager öffnen
• Kontextmenü der Sharepoint Web Application: Properties -> Kartenreiter: Directory Security
• Auswahl von “Edit Authentication and access control”
• Checkbox “Enable anonymous access” muss aktiviert sein

Sollte “Enable anonymous access” nicht aktiviert sein, kann unter Umständen ein IISRESET helfen, ansonsten unbedingt kontrollieren, ob die Änderungen in der Zentraladministration wirklich (und auch in der richtigen Web Application) gespeichert wurden!

Last but not least muss der anonyme Zugriff noch in der Sharepoint Web Application erlaubt werden:

• Als Administrator an der Web Application anmelden und zur gewünschten Website navigieren (bzw. die Top Level Site verwenden, wenn der anonyme Zugriff für die gesamte Web Application möglich sein soll)
• Klickpfad: Site Actions -> Site Settings -> Modify All Site Settings -> Users and Permissions -> Advanced Permissions
• Im Settings-Menü “Anonymous Access” auswählen
• Anonymen Zugriff erlauben (je nach gewünschten Berechtigungen “Entire Web site” oder “Lists and libraries”)

Beim Umhängen eines MOSS 2007 Servers in eine andere Domäne funktionieren natürlich die Servicekonten nicht mehr, die man bei der Konfiguration des SharePoint Servers angegeben hat. Bevor man jetzt manuell überall die Credentials ändert (IIS, SQL Server), und auch nach einiger Zeit immer wieder über nichtssagende Fehlermeldungen des MOSS stolpert (ich sag nur: An unexpected error has occured), hier ein praktischer Befehl des stsadm.

Stsadm.exe –o updatefarmcredentials –userlogin –password

Danach auf jeden Fall iisreset /noforce aufrufen.