Zur Zeit wird gefiltert nach: wss
Filter zurücksetzen
Anwenderhilfe 2.0 mithilfe eines Wikis auf SharePoint-Basis
Grundsätzlich hält die Wiki-Funktionalität von Microsoft SharePoint 2007 oft nicht alles, was man sich von ihr verspricht. Bei der Anwendung im Rahmen eines verteilten Wissensmanagements im Unternehmen stößt man in der Praxis schnell an Grenzen. Microsoft hat dies auch erkannt – die Wiki-Funktionalität der neuen Version von SharePoint 2010 macht einen erwachsenen Eindruck.
Nichtsdestotrotz ist die Wiki-Funktion in SharePoint 2007 eine interessante Option – für einen unseren Kunden sind wir in Sachen Anwenderhilfe neue Wege gegangen und haben das vorhandene Anwenderhandbuch (ein mehr als 150 Seiten langes Dokument) durch ein SharePoint-Wiki abgelöst. Damit ist es möglich die Inhalte im Web darzustellen sowie Aktualisierungen und Ergänzungen (z. B. Best Practices) durch alle Anwender umsetzen zu lassen.
Wie sind wir vorgegangen?
Das umfangreiche Handbuch wurde nach Themengebieten in kleine, handlichere Teile zerlegt. Jedes Thema wurde als einzelner Wiki-Beitrag in einer flachen Liste gesammelt.
Jeder Wiki-Beitrag wird zudem durch spezifische Attribute ergänzt (wie z. B. betroffenes System, relevante Benutzerrolle und Themengebiet).
Über diese Attribute kann der Endanwender alle Wiki-Beiträge filtern, gruppieren bzw. sortieren, um gezielt auf die jeweils relevanten Artikel zugreifen zu können. Zudem können die Wiki-Artikel mit anderen SharePoint-Listen verknüpft werden.
In diesem Fall wird beispielsweise eine kombinierte "Issue and Change Management"-Liste verwendet, in der Issues und Change Requests erstellt und deren Lösung bzw. Umsetzung überwacht werden, sowie eine Q&A-Liste. So kann ein Wiki-Beitrag auf relevante Issues, Change Requests sowie Q&A- Einträge verweisen – und umgekehrt. Mit einem Klick gelangt man so zu den verwandten Einträgen.
Diese einfache Umsetzung eines traditionellen Handbuchs mit modernen Hilfsmitteln schafft Transparenz für den Endanwender und erleichtert die Arbeit eines zentralen Administrators bzw. Redakteurs.
Windows SharePoint Services 3.0: Massen-Check-In von ausgecheckten Dokumenten per STSADM
- Abbildung 1: Ausgecheckte Dokumente nach Drag & Drop Upload
Dokumentenbibliotheken gehören erfahrungsgemäß zu den am häufigsten genutzten Grundfunktionalitäten von WSS 3.0. – beispielsweise werden diese in den integrieren Projektarbeitsbereichen von Microsoft Project Server verwendet.
In der täglichen Praxis können verschiedene Situationen auftreten, in denen es notwendig werden kann, fälschlicherweise ausgecheckte Dokumente in SharePoint-Dokumentenbibliotheken administrativ einzuchecken.
Beispielsweise kann es beim Hochladen von Dokumenten unter Verwendung der anwenderfreundlichen Drag & Drop-Funktionalität in der Explorer-Ansicht dazu kommen, dass die erfolgreich hochgeladenen Dokumente nicht eingecheckt sind (siehe Abbildung 1). Dies passiert, wenn die Option "Require Check Out" in den Versionierungseinstellungen der Dokumentbibliothek aktiviert ist. Somit ist es notwendig die Dokumente einzuchecken, damit diese für andere Nutzer sichtbar und verwendbar werden. Da in den Administrationsmasken von WSS 3.0 jedoch keine Funktionalität zum Massen-Check-In existiert, müsste jedes Dokument einzeln manuell eingecheckt werden.
- Abbildung 2: Option "Require Check Out" in den Versionierungseinstellungen einer Dokumentenbibliothek
Zur Vermeidung der beschriebenen Problemstellung empfehlen wir vor dem Hochladen vieler Dokumente die Option "Require Check Out" in den Versionierungseinstellungen der Dokumentenbibliothek (siehe Abbildung 2) temporär zu deaktivieren und diese direkt nach dem erfolgreichen Hochladen wieder zu aktivieren, sofern der Anwender dazu die Berechtigung hat:
Sollte es dennoch zu der Situation kommen, dass ein Massen-Check-In notwendig wird, hat sich folgendes Vorgehen als Lösungsmöglichkeit bewährt:
- Abbildung 3: Übersicht "Checked Out Files"
In dieser Übersicht "Checked out files" ist nun (die entsprechenden Berechtigungen vorausgesetzt) zunächst per "Take Ownership of Selection" der Besitz über die betreffenden Dokumente zu übernehmen (siehe Abbildung 3).
Hinweis: Die Übernahme von einer Anzahl an Dokumenten > 1.000 (ungefährer Erfahrungswert) führt zu einer Fehlermeldung. Der Befehl scheint mit dieser Anzahl von Dokumenten nicht ausführbar zu sein.
Um die Dokumente nach Übernahme des Besitzes anschließend im Batch-Verfahren einzuchecken, muss zunächst noch die Erweiterung WSS Only STSADM Extensions (x86, x64) für den STSADM-Befehl heruntergeladen und auf dem Applikationsserver installiert werden.
Die Installation dieser Erweiterung erfolgt über die angegebenen Konsolenbefehle, die im selben Ordner ausgeführt werden müssen, in dem die Installationsdatei der Erweiterung liegt.
Der eigentliche Massen-Check-In per Batch-Befehl kann nun über den folgenden Konsolenbefehl gestartet werden:
- Stsadm.exe –o gl-publishitems –url <URL der Dokumentenbibliothek> -scope Liste
[die URL kann aus dem geöffnetem Browser kopiert werden und in die Konsole eingefügt werden]
- Abbildung 4: Erfolgreich eingecheckte Dokumente per STSADM
Nun startet der automatisierte Check-In aller Dokumente der entsprechenden Dokumentenbibliothek (Siehe Abbildung 4).
Vorsicht: Sollten sich in der Bibliothek weitere Dokumente befinden, die gerade aktiv bearbeitet werden und daher korrekterweise ausgecheckt sind, werden auch sie eingecheckt, sofern der ausführende Benutzer ebenfalls Besitzer dieser Dokumente ist.
Abschließend sollte die Übersicht "Checked out files" in den Settings der Dokumentenbibliothek keines der betroffenen Dokumente mehr enthalten.
Fazit: Der beschriebene Lösungsweg ist für eine Anzahl von ca. 20 bis maximal etwa 1.000 ausgecheckten Dokumenten, die keine zuvor eingecheckte Version aufweisen, hilfreich und schnell durchzuführen. Voraussetzung ist die Verfügbarkeit bzw. der Zugriff auf die STSADM-Befehle. Mitunter existieren für diesen Anwendungsfall auch Zusatz-Tools, die aber oft kostenpflichtig sind.
SharePoint/Project Server: Druckberichte aus verteilten Datenquellen
Microsoft Project Server bietet auf Basis der Funktionen des SQL Servers (insbesondere Reporting Services) eine Vielzahl von Möglichkeiten um spezifische Auswertungen und Berichte zum Projekt zu erstellen.
Hierzu werden in der Regel quantitative Informationen ausgewertet, die direkt mit dem Projekt verknüpft sind. Beispiele sind Enterprise Felder sowie zugehörige Ressourcen und Kostensätze.
Microsoft Project Server bietet zudem die Möglichkeit, zu jedem Projektplan einen Arbeitsbereich (Project Workspace) zur Projektarbeit im Team zu erstellen, basierend auf der SharePoint-Technologie.
Innerhalb eines solchen SharePoint Arbeitsbereiches können vielfältige Projektmanagement-Prozesse abgebildet werden. Beispielhaft sind bereits Listen für das Risiko und Issue Management im Standard enthalten. Vielfach werden diese SharePoint-Arbeitsbereiche auch spezifisch angepasst und erweitert, um die im Unternehmen gültigen Projektmanagement-Prozesse (beispielsweise in Anlehnung an das PMBOK) abzubilden.
Das Resultat sind eine Vielzahl von SharePoint-Listen mit wichtigen Informationen zum Projekt.
Zwar können die Informationen aus solchen SharePoint-Listen in die oben genannten Auswertungen und Berichte integriert werden, oft besteht aber schlicht der Wunsch die Listen auszudrucken. Und häufig entspricht das Resultat der Druckfunktion im Internet Explorer nicht den Vorstellungen der Anwender.
Unsere Lösung mit dem CS Print WebPart führt nun die Informationen aus Projektplan und dem zugehörigem SharePoint-Arbeitsbereich in einen Druckbericht (beispielsweise als PDF) zusammen. Mit einem Klick aus dem Arbeitsbereich heraus werden Daten aus der SharePoint-Liste in ein druckfähiges Format gebracht und automatisch um die zugehörigen Kopfdaten des Projektes ergänzt.
Auf diese Art und Weise können standardisiert und optisch ansprechend Inhalte von SharePoint-Listen im Kontext der zugehörigen Projekte dargestellt werden.
Globale und einheitliche Navigation in SharePoint
In SharePoint (hier Version 2007) wird die Navigation innerhalb einer Site Collection definiert. In einem Umfeld mit mehreren Site Collections hat das folgende Nachteile:
- Die Navigation ist inkonsistent (die aktuelle Site Collection wird zum Beispiel immer an erster Stelle angezeigt)
- Der Administrationsaufwand erhöht sich pro zusätzlicher Site Collection
- Der Aufwand um die Navigation über alle Site Collections einheitlich zu pflegen ist immens
Eine schlanke Lösung für diese Problematik besteht in der Ausnutzung des Delegate-Prinzips: Hierbei wird das Objekt, welches die Navigationsdaten liefert, dynamisch überschrieben. Eine Lösung besteht aus den folgenden Bestandteilen:
- Ein Feature auf Web Application-Ebene, welches einen neuen Navigation Provider registriert: Dieser verwendet als Basis für die Navigationsstruktur eine xml-Datei
- Ein Feature auf Web-Ebene, welches für das dynamische Überschreiben des Navigations-Objekts sorgt
Vorteile einer solchen Lösung:
- Die einheitliche Navigation muss nur noch an einer zentralen Stelle (in der xml-Datei) gepflegt werden
- Anpassungen an Masterpages, Themes etc. sind nicht notwendig
- Per Aktivierung/Deaktivierung des Web-Features kann jederzeit von der alten auf die neue Lösung umgeschaltet werden
- Die Lösung kann sowohl im Umfeld WSS 3.0/SharePoint Server 2007, als auch im Umfeld SharePoint Foundation/SharePoint 2010 angewendet werden
Synchronisation zwischen Microsoft Outlook 2003/2007 und Microsoft Office SharePoint Server 2007/WSS 3.0 (MOSS)
MOSS ermöglicht es dem Anwender verschiedenste Inhalte, die sich auf SharePoint-Seiten befinden, mit seinem persönlichen PC zu synchronisieren. Diese Inhalte stehen ihm somit auch zur Verfügung während er einmal "offline" ist – also nicht mit dem Internet/Intranet verbunden und somit ohne Möglichkeit direkt auf MOSS zuzugreifen.
Die verschiedenen Inhaltstypen wie Dokumentenbibliotheken, Aufgabenlisten, Teamkalender etc. werden dabei als Kopie innerhalb von Microsoft Outlook auf dem Client-Rechner abgelegt.
Sofern im Unternehmen nun verschiedene Versionen von MOSS und Outlook verwendet werden, bestehen Unterschiede hinsichtlich der Synchronisationseigenschaften. Die folgenden Tabellen zeigen dies für den Fall, dass MOSS 2007 mit Outlook 2003 bzw. 2007 eingesetzt wird:
Outlook 2003
Inhaltstyp | Synchronisation |
Kontaktlisten | Nur unidirektional* MOSS -> Outlook |
Kalender | Nur unidirektional* MOSS -> Outlook |
Dokumente | Nicht möglich |
Listen | Nicht möglich |
*Bei der unidirektionalen Integration kann der Benutzer offline getätigte Änderungen nicht direkt nach MOSS zurückspeichern.
Outlook 2007
Inhaltstyp | Synchronisation |
Kontaktlisten | Bidirektional |
Kalender | Bidirektional |
Dokumente | Bidirektional |
Aufgabenlisten | Bidirektional |
Listen | Nicht möglich |
Ausblick: Mit SharePoint 2010 wird es einen dedizierten Offline-Client unabhängig von Outlook geben. Mithilfe dieser so genannten "SharePoint Workspaces" werden die Funktionen und Möglichkeiten zur Offline-Arbeit und Synchronisation mit dem Server erheblich erweitert.
