January 2008 - Posts

• Workflows mit Visual Studio 2008 erstellen

  Das Erstellen von Workflows mit dem 'alten' Visual Studio 2005 war keine leichte Sache und ehrlich gesagt habe ich mich damit immer etwas schwer getan. Mit dem neuen Visual Studio 2008 ist das Erstellen von Workflows jetzt viel einfacher geworden. Dies beginnt bereits bei der Installation: einfach Visual Studio 2008 in einer Entwicklungsumgebung mit MOSS oder WSS installieren und darauf achten, dass die Visual Studio Tools for Office mitinstalliert werden. Empfehlenswert, aber nicht zwingend notwendig ist noch die Installation des .NET-Frameworks 3.5. Warum - dazu später mehr. Nachdem die Installation fehlerfrei durchgelaufen ist, kann man bereits damit beginnen, einen ersten Workflow mit Visual Studio 2008 zu erstellen. Dazu geht man wie folgt vor: 1) Anlegen eines neuen Projekts vom Typ Sequentieller Sharepoint-Workflow. Dabei sollte darauf geachtet werden, dass oben rechts in dem Projektauswahlfenster .NET Framework 3.5 ausgewählt ist.   2. Nachdem man einen Namen und einen Speicherort für das Projekt ausgewählt hat, startet der Wizzard mit seiner ersten Frage: wie soll der neue Workflow heißen und auf welcher lokalen Webseite soll der Workflow später getestet (Debugging) werden. An diesem Wizzard-Schritt sieht man schon, dass der Wizzard nicht für Remote-Debugging ausgelegt ist.   3) Im nächsten Schritt fragt der Wizzard nach der Liste, mit der der neue Workflow verknüpft werden soll und welche Verlaufs- und Aufgabenlisten verwendet werden sollen. Der Wizzard befüllt die Auswahlliste bereits mit den Listen, die er auf der Webseite aus dem 2. Schritt gefunden hat.   4) Im letzten Schritt fragt der Wizzard dann noch ab, wann der neue Workflow getriggert werden soll. Zur Auswahl stehen die bekannten manuellen und automatischen Trigger.   5) Wenn man im letzten Schritt auf den Button Fertig stellen klickt, dauert es nur kurz, bis der Wizzard ein erstes und lauffähiges (!) Grundgerüst für einen sequentiellen Sharepoint-Workflow erstellt hat.   Das dieses Grundgerüst bereits lauffähig ist, kann man ganz einfach ausprobieren: einfach F5 drücken und gespannt zusehen: Visual Studio 2008 wird zuerst den Code erstellen und danach das Deployment starten. Anschließend wird im Hintergrund ein IISRESET ausgeführt und danach wird der IE gestartet. Nach einer kurzen Wartezeit zeigt der IE die zuvor im Wizzard (Schritt 1) angegebene Webseite an. Nun kann man in der im zweiten Wizzard-Schritt angegebenen Liste einen neuen Eintrag hinzufügen. Hat man im letzten Wizzard-Schritt ein automatisches Triggern ausgewählt, wird der neue Workflow gestartet. Ansonsten muss man den neuen Workflow manuell durch das Kontextmenü des neuen Listeneintrags starten. Passieren wird natürlich noch nicht viel, aber man sollte bereits jetzt erkennen, dass der neue Workflow abgelaufen ist und erfolgreich beenndet wurde. Nun kann man damit beginnen, eigene Logik in den neuen Workflow zu integrieren. Nachdem ich jetzt schon ein paar Workflows mit dem neuen Visual Studio 2008 erstellt habe, muss ich zugeben, dass ich ziemlich begeistert bin. Das Erstellen eines Sharepoint-Workflows mit dem neuen Visual Studio 2008 ist jetzt fast so einfach geworden, wie das Erstellen eines Sharepoint-Workflows mit dem Sharepoint-Designer. Nachtrag: die Integration der Projekttypen für Workflows ist Microsoft gut gelungen. Schade finde ich aber, dass Microsoft keine Unterstützung für Sharepoint Webparts in das neue Visual Studio 2008 integriert hat. Hier wünsche ich mir, dass Microsoft bald Projekttypen für Sharepoint Webparts zur Verfügung stellt, die genauso einfach zu benutzen sind, wie die Projekttypen für die Sharepoint Workflows! Nachtrag 2: auf der deutschen SharePoint-Konferenz in Frankfurt hat Martin Vollmer einen inoffiziellen Workaround vorgestellt. Alles weitere dazu in seinem Blog.   Posted Jan 31 2008, 02:45 PM by Oliver Wirkus with 1 comment(s) Filed under: SharePoint, MOSS, MOSS 2007, SharePoint 2007, SharePoint 2007 Development

• Webpartwartungsseite - Hilfreich bei Problemlösungen

  Meist geschieht es, wenn man sehr viel an einer Seite gearbeitet hat. Man hat vielleicht hier und da ein Webpart hinzugefügt, es konfiguriert, es in eine andere Zone verschoben, gelöscht, wieder hinzugefügt und neu konfiguriert, ein anderes Webpart ausprobiert ... und irgendwann passiert es dann: die Seite läßt sich z.B. im Sharepoint-Designer nicht mehr öffnen. Stattdessen erscheint eine Fehlermeldung, die meist sinngemäß besagt, dass Probleme mit einem Webpart das Öffnen der Seite verhindern. Für solche Probleme ist die Webpartwartungsseite hilfreich. Hier werden alle Webparts aufgelistet, die jemals auf einer Seite eingebunden waren. Allerdings ist der Zugang zu dieser Wartungsseite gut versteckt. Ich möchte hier einen Weg aufzeigen, wie man an diese Wartungsseite für eine spezielle Seite kommt: zuerst läßt man sich die betroffene Seite im Browser anzeigen nun klickt man auf Websiteaktionen -> Alle Websiteinhalte einblenden es wird nun eine Seite angezeigt, in der alle Website-Inhalte (Biliotheken, Listen, ...) angezeigt werden. Hier klickt man nun auf Seiten. nun wird eine Bibliothek mit alle Seiten der aktuellen Website angezeigt. In dieser Bibliothek sucht man sich die problembehaftete Seite aus und wählt in deren Kontextmenü Eigenschaften bearbeiten. nun wird eine ausführliche Ansicht aller Parameter der aktuellen Seite angezeigt. Ganz unten auf der Seite findet man den gesuchten Link: Webpartseite in Wartungsansicht öffnen. Klickt man auf diesen Link, bekommt man die gewünschte Übersicht aller jemals auf dieser Seite verwendeten Webparts. Oftmals ist es so, dass ein früher eingefügtes, aber mittlerweile von der Seite entferntes Webpart Grund für die Fehlermeldung ist. Diese nicht mehr benutzten Webparts erkennt man daran, dass sie in der Spalte Geöffnet auf Seite? ein Nein stehen haben. Sofern man diese Webparts nicht mehr benötigt, kann man sie markieren und anschließend löschen. Meist löst das Löschen von alten, nicht mehr benötigten Webparts die Probleme beim Anzeigen der Seite im SharePoint-Designer. Hier ein Beispiel einer Webpartwartungsseite:   Posted Jan 24 2008, 12:49 PM by Oliver Wirkus with 2 comment(s) Filed under: SharePoint, MOSS, MOSS 2007, SharePoint 2007, SharePoint 2007 Development

• Ereignisanzeige / DCOM-Fehler mit ID 10016 / Win2k3 SP1

  Ich habe gerade eine neue virtuelle SharePoint-Umgebung für eine Vorführung erstellt. Nach Fertigstellung der virtuellen Umgebung habe ich als Test die SharePoint-Zentraladministration geöffnet. Es dauerte zwar ein wenig, aber schließlich öffnete sich diese Anwendung. Danach habe ich einen Blick in die Ereignisanzeige gewofen und dort einen Hinweis auf einen Fehler gefunden. Es handelte sich um einen DCOM Fehler mit der ID 10016. Offensichtlich ist dieser Fehler schon länger bekannt und hängt mit dem SP1 vom Windows Server 2003 zusammen. Es gibt aber eine einfache Vorgehensweise, wie man diesen Fehler wieder korrigieren kann. Hier der Link zum entsprechenden Artikel bei Admin's Tipps. Nachtrag: Link zu den Admin's Tipps wurde aktualisiert!   Posted Jan 14 2008, 01:35 PM by Oliver Wirkus with 2 comment(s)

• Großes Zeitfenster beim Ändern des Passworts in einem ActiveDirectory

  Ein Mitarbeiter eines unserer Kunden rief mich vor kurzem an, um mir ein ungewöhnliches Verhalten beim Ändern seines Passwortes zu schildern. Nachdem er sein Passwort mit Hilfe eines unserer WebParts geändert hatte, konnte er sich dennoch weiterhin mit seinem alten Passwort anmelden. Eine Fehlermeldung beim Ändern seines Passworts habe es nicht gegeben. Daraufhin habe er versucht, sich mit seinem neuen (also dem geänderten) Passwort anzumelden und auch mit diesem konnte er sich anmelden. Da er sich sowohl mit altem, als auch mit neuem Passwort anmelden konnte, vermutete er nun einen Fehler in unserem Passwort-Ändern-WebPart. Unser WebPart zum Ändern von Passwörtern greift auf ein ActiveDirectory zu. Und genau hier liegt die Erklärung zu diesem ungewöhnlichen Verhalten. Nach dem Einspielen des SP1 für Windows Server 2003 verlängert sich das Zeitfenster in dem sowohl das alte, als auch das neue Passwort gültig sind, auf 1 Stunde. Dies bedeutet, dass das alte Passwort unter Umständen noch eine Stunde gültig bleibt, nachdem es bereits vom Benutzer geändert wurde. Dieses Zeitfenster läßt sich aber durch Änderungen an einem Registry-Key auf 1 Minute verkürzen. Microsoft hat die nötigen Änderungen hier beschrieben: http://support.microsoft.com/kb/906305/en-us Dieses Problem lies sich also schnell lösen - auch deswegen, weil diese Änderung keinen Neustart des Servers erfordert!   Posted Jan 10 2008, 02:23 PM by Oliver Wirkus with no comments Filed under: SharePoint, MOSS, MOSS 2007, SharePoint 2007, SharePoint 2007 Development

• Absturz im IE bei Zugriff auf Dokumente in einer Dokumentbibliothek

  Das neue Jahr 2008 hat für mich gleich mit einem interessanten SharePoint-Problem begonnen. Einer unserer Kunden berichtete mir von Abstürzen im Internet Explorer, wenn auf Dokumente (im vorliegenden Fall waren es PDF-Dateien) in einer SharePoint-Dokumentbibliothek geklickt wurde. Allerdings würden diese Abstürze nicht bei allen PCs, sondern nur bei einigen wenigen PCs auftreten. Ich habe mir die Sache also vor Ort angesehen und tatsächlich war es so. Beim Linksklick auf eine beliebige Datei in einer beliebigen Dokumentbibliothek kam es zu einer unbehandelten Exception im Internet Explorer und für den Benutzer sah es wie ein Absturz des IE aus. Betroffen waren übrigens sowohl IE6 als auch IE7. Und auch die zweite Aussage lies sich nachvollziehen: das geschilderte Problem trat nur bei einigen wenigen PCs auf. Die meisten der PCs vor Ort zeigten dieses Problem dagegen nicht. Nach einigem Recherchieren und einem genaueren Blick auf die betroffenen PCs fand ich dann aber doch die Ursache des Problems: auf allen PCs war Office 11 installiert, auf den betroffenen PCs zusätzlich noch eine Komponente aus dem aktuellen Office 12 - SharePoint Designer bzw. Groove. Diese Office 12-Komponenten registrieren im Internet Explorer ein AddOn (OWSSUPP.DLL), welches offensichtlich die geschilderten Probleme verursacht. Es gibt nun mehrere Lösungsmöglichkeiten: deaktivieren des AddOns im Internet Explorer (möglicherweise aber dadurch Verlust an SharePoint-Funktionalität) verwenden der OWSSUPP.DLL aus Office 11 (dazu muss diese aber systemweit registriert werden. Näheres dazu findet sich hier) Einspielen eines Patches von Microsoft. Hier der Link dazu: http://support.microsoft.com/kb/938888 Damit waren in meinem Fall die Probleme gelöst, allerdings nicht ohne noch eine Office-11 Reparatur durchzuführen! Ich werde das geschilderte Problem aber weiter beobachten und ggf. weitere Erkenntnisse an dieser Stelle posten.   Posted Jan 08 2008, 09:41 AM by Oliver Wirkus with 4 comment(s) Filed under: SharePoint, MOSS, MOSS 2007, SharePoint 2007, SharePoint 2007 Development