Nun gut, Sander hat eine SharePoint-Page zur Messung verwendet, welche eine Liste von 350 Elementen zeigt. Die Liste umfasst 7 Spalten. Das sind für SharePoint-Verhältnisse viele Daten, welche so auf einer Seite dargestellt werden. Seine Ergebnisse sahen wie folgt aus:

Ohne diese Zahlen nun zu eng auszuwerten erkennt man aber doch einen gewissen Trend: Je neuer die Version, desto schneller auch das Rendering von SharePoint-Seiten. Im vorliegenden Fall konnte die Zeit von IE6 auf einen sechstel der Zeit herunter geborchen werden, indem die neueste Version vom Internet Explorer verwendet wurde.

In SharePoint gibt es ja bekanntlich die Meeting-Workspaces, welche direkt aus Outlook heraus erstellt werden können. In diesen Workspaces können für Meetings diverse Informationen festgehalten werden, welche dann für alle Teilnehmer sichtbar und bearbeitbar sind. Wenn ein Termin als Serie definiert ist, kann auf der linken Seite zwischen den einzelnen Terminen gewechselt werden.

Sobald man nun aber ein Custom-Design verwenden will, funktioniert diese linke Spalte plötzlich nicht mehr. Die Klicks auf die Termine ergeben nur noch Javascript Fehler, welche ein Problem mit g_instanceID melden. Wenn man versucht, wieder auf das Standard-Design zu wechseln, in dem man die Masterpage default.master wieder auswählt, verbessert sich die Lage aber auch nicht mehr.

Die Ursache liegt darin, dass ein Meetingworkspace per Default eine Masterpage verwendet, welche via Browser gar nicht selektiert werden kann. Sprich: Einmal geändert, gibts kein Zurück mehr (zumindest mir nicht bekannt). Man findet die besagte Masterpage im Verzeichnis …12/TEMPLATE/GLOBAL/ mit dem Namen mwsdefault.master.

Die Masterpage, welche verwendet werden soll (default.master, oder eine selbst Erstellte), muss nun mit Codeschnippsel aus der mwsdefault.master-Masterpage erweitert werden. Dann funktioniert der Meetingworkspace wieder in gewohnter Manier – auch im neuen Design.

In der Masterpage muss nun folgende Referenz hinzugefügt werden: <%@ Register Tagprefix="Meetings" Namespace="Microsoft.SharePoint.Meetings" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
Es gibt ja schon ein paar Register-Zeilen. Dort fügt man diese Zeile (kopiert aus der oben genannten mwsdefault.master-Datei) noch dazu. Am Einfachsten via SharePoint Designer. Das sieht dann etwa so aus (klick für grosse Version):

Dann muss noch der Property-Bag kopiert werden. Das wäre dies hier: <Meetings:PropertyBag runat="server"/>. Dies fügt man in der Masterpage irgendwo im Body ein. Ich habs hier rein gestellt (klick für grosse Version):

Und das war es dann auch schon. Sobald die Masterpage wieder eingecheckt und veröffentlicht wurde, wird der Meetingworkspace wieder normal funktionieren und es kann zwischen den einzelnen Terminen wieder gewechselt werden.

Ich habe dann das mal auf einem meiner SharePoint’s ohne Migrationshintergrund angeschaut. Völlig irritiert musste ich feststellen, dass sich so ein Filter wirklich nicht setzten lies. Damit starb meine anfängliche Vermutung, dass die SPS03-to-MOSS07 Migration das Problem war. Diverse Beiträge im Internet haben mir das nun auch bestätigt: In SharePoint 2007 Kalender kann man in einem View keinen Filter auf Start- oder/und End-Datum setzten. Eigentlich bin ich überrascht, dass ich über dieses Problem nicht schon eher angetroffen habe, ist dies ja nun wirklich nicht mein erstes SharePoint 2007 Projekt.

Variante 1: Calculated Fields

Nun gut, dem Kunde nützt kein Feedback, dass es nicht geht. Er will eine Lösung dafür – zumal es ja in der Vorgängerversion funktioniert hat. Im Internet findet man hierzu häufig die Lösung, dass man nun zwei weitere Felder hinzufügt. Beides sind calculated Fields, welche jeweils einfach die Werte der Originalfelder übernehmen (=[EndDate]). Diese berechneten Felder lassen sich dann bei der Filterdefinition verwenden.

Bei dieser Lösung berichten Andere aber davon, dass es Probleme mit der genauen Filterung von ganztägigen Ereignissen gibt. 

Variante 2: SharePoint Designer

Ich habe aber nun einen anderen Weg verfolgt: Da die gefragten Views in meinem Fall vom Setup her eher statisch sind (Filter und Feldauswahl ändern sich nicht), hab ich den View im SharePoint Designer 2007 editiert. Hier mein Vorgehen dazu:

1. Im besagten Kalender einen neuen View erstellen (oder sich den Namen des zu bearbeitenden Views merken). 
2. In diesem View einen Filter auf ein verfügbares Feld vom Typ DateTime setzen (z.B. “Erstellt”). 
3. Den Vergleichsoperator und den Vergleichswert setzt man schon analog dem Endergebnis. Da ich alle Ereignisse anzeigen will, welche in der Vergangenheit liegen, lautet meine Filterdefinition “Erstellt ist kleiner als [Heute]“.
4. Nun öffnet man den SharePoint Designer 2007, öffnet die entsprechende Site, geht zum Kalender und findet dort seinen View (ie. “Done.aspx”). Diesen öffent man nun in der Code- oder Split-Ansicht.
5. Beim KalenderwebPart findet man nun den View-HTML-Code (all das, was mit < und > grosszügig vermischt ist)
6. Jetzt sucht man am einfachsten nach “Where”. Der erste Treffer solle zu etwa diesem Abschnitt führen:

<Query><Where><Lt><FieldRef Name="Created"/><Value
Type="DateTime"><Today/></Value></Lt></Where></Query>

7. Wenn man nun einfach den FieldRef Name auf “EndDate” (oder “EventDate”) ändert und speichert, ist es das auch schon gewesen.

WICHTIG: Wenn man diesen View nun via SharePoint wieder ansehen geht, erscheint dort etwa folgendes:

Sprich, wenn ich den View irgendwie dort nun verändere, wird die Anpassung in der Filter-Field Selektion überschrieben und das Ergebnis ist wieder filterlos.

Bewertung der Varianten

Beide Varianten haben ihre Vor- und Nachteile. Bei der ersten Variante gibt es über die Contenttypes natürlich die Möglichkeit, dass man nicht jeden Kalender nachpflegen muss, sondern die neuen Felder einmal definiert und diese dann auf alle Kalender angewendet werden. Wenn Kalendereinträge bearbeitet werden, erscheinen diese berechneten Felder auch nicht. Aber es gibt einfach 2 Felder, welche nur zu Filterzwecken existieren und sonst keine Daseins-Berechtigung haben und die Probleme mit ganztägigen Ereignissen gilt es auch zu berücksichtigen.

Die SharePoint Designer-Variante ist dazu genau das Gegenteil: Es gibt keine weiteren Felder. Es kann aber auch nicht mit Contenttypes eine Vorlage editiert werden. Diese Anpassung muss für jeden Kalender gemacht werden. Auch ist hier die Gefahr gross, dass Benutzer diese Anpassung durch ein Bearbeiten des Views überschreiben.

Schlussendlich muss jeder situativ entscheiden, welche diese (mir bis heute bekannten) Varianten sich besser eignet.

Das sind schon ein paar nette Features drin. In meinem Umfeld wird sicher Super-Lists, MDM, die FAST-Suche und die Claims-based Authentication interessant sein. 

Super-Lists und MDM werden helfen, Daten effizient in SharePoint verwalten zu können, wobei ich echt auf relationale Listen hoffe. Die Sache also, welche wir bis anhin nur dank Bamboo-Solutions verwirklichen konnten.

Die FAST-Suche lässt mich hoffen, dass die Unzulänglichkeiten der bisherigen Suche dann Geschichte sind. Dass damit dann also Wildcard-Suchen möglich werden, dass Userprofile effizienter indexiert sind (gelöschte User sollte man nicht mehr finden dürfen) und dass der Index sich stärker an der Arbeitsweise Inhaltsquelle orientiert (Berechtigungen auf Filesystem, MOSS zeigt Files an, welche im Explorer nicht geöffnet werden können).

Und mit der Claims-based Authentication scheint es dann einfacher zu werden, wenn es gilt externe User auf eine Extranet-Umgebung zugreiffen zu lassen. Bisher sind dazu mit FBA und der SQL-DB in meinen Augen zuwenig flexible Instrumente zur Verfügung.

Dieser Migrationsprozess wurde 2-3 mal vom Kunde selbst getestet und validiert. Stets verlief alles einwandfrei. Bloss eben gestern – am effektiven GoLive – nicht. 

Die Fehlermeldung bestand stets darin, dass beim Import die Meldung erschien, dass die Parent-Site noch nicht existiere. Eigentlich hat dies bei jedem Test STSADM beim Importieren gemacht. Die Site muss von STSADM als erstes erstellt werden, bevor Inhalte darin abgelegt werden können.

Internetrecherchen ergaben, dass diese Meldung erscheint, wenn der User, welcher den Import durchführen will, nicht als Site-Collection-Administrator definiert ist. Von der Site her war er aber drin… aber in der Zentraladministration fehlte er noch (sonderbar, ich weiss). Also rein mit ihm. Der erneute Import aber scheiterte wieder mit der selben Meldung. 

Dann wollte ich das Problem weiter eingrenzen. Ich exportierte abermals eine einzelne Site vom WSS und wollte diese in eine neu erstelle SiteCollection auf dem WSS importieren. Scheiterte aber ebenfalls. Gleiche Übung auf dem MOSS war aber erfolgreich. Ok, das Problem konnte langsam eingegrenzt werden. 

Was war bloss anders, als an den Tests, welche vorgängig gemacht worden sind? Warum liesen sich diese Sites nicht mehr importieren? Nun, nicht der User war das Problem, sondern die Quell-SiteCollection: Damit kein User während der Migration auf einer WSS-Site noch arbeitet, haben wir diese SiteCollection in einen Read-only-Betrieb geschaltet.

Also haben wir den SC-Lock testhalber kurz aufgehoben und nochmals eine Site exportiert und den Import auf MOSS-Seite erneut gestartet und siehe da: es funktionierte. 

Hm… aber dass ein SC-Lock auf Exportierte Sites einen Einfluss hat, war mir bis heute nicht bekannt. Falls es  jemand gibt, der mir das erklären kann,… bitte gerne.

Nun vorher kommt dies? In diesem Blog habe ich bis anhin nur Privates geblogg. Da sind Dinge über Filme, Games und sonstigen Reviews zu lesen. Leider aber gab es in den vergangenen Monaten fast kein Privatleben mehr. Der Job nimmt mich aktuell etwas zu sehr in Anspruch, so dass ich froh bin, wenn ich in meiner Freizeit nicht auch noch vor nem Bildschirm sitze.

Dafür aber lerne und erfahre ich im Berufsleben öfters mal was neues. Daher habe ich mich entschieden, dass dieser Blog fortan sich öffnet und über alles bloggt, was ich so zu bloggen habe. Sprich: natürlich wird es wieder Posts geben, welche über Filme, Games oder Ausflüge schreiben – aber es wird neu auch Berichte geben, welche aus meinen Berufsleben als SharePoint- und BizTalk- Entwickler und Consultatnt handeln.

Als erster Eintrag wird in den nächsten Tagen wohl ein Post über eine SharePoint Konfiguration in einem NLB-Setup erscheinen. Warum? Nun, ich habe dies erst kürzlich zum ersten Mal machen müssen, konnte im Internet aber kaum Informationen finden, wie dies geht – nur andere SharePointler, welche nach dem selben suchten.

Und ach ja: Blogsprache bleibt Deutsch. Übersetzter ins Englische sind aber willkommen ;-)