Zur Zeit wird gefiltert nach: MS SharePoint
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.
PR-Abteilung von Campana & Schott organisiert sich über SharePoint-Intranetportal neu
Wie kommt man innerhalb von nur einem Jahr von 34 (2009 gesamt) auf bereits 28 Veröffentlichungen im ersten Vierteljahr 2010. Und wie gewährleistet man gleichzeitig Präsenz in einer ausgewogenen Vielfalt an qualitativ hochwertigen Medien?
Mit unserer vergleichsweise schlank aufgestellten PR-Abteilung blicken wir inzwischen auf über 300 Publikationen seit Beginn der Pressearbeit bei C&S zurück. In einem Unternehmen, das sich im Kern um Effizienzsteigerung bei seinen Kunden kümmert, liegt die ständige Selbstreflektion in Sachen Effizienz auf der Hand. Laufend versuchen auch wir unsere eigenen Prozesse zu optimieren. Deshalb wollten wir auch nicht einfach nur weiter darüber berichten, was bei unseren Kunden alles mit der SharePoint-Technologie möglich ist.
Eat-your-own-dogfood – Befolge selbst was du predigst, nutze die Produkte, die du verkaufst
Anfang 2009 suchten wir nach einer Möglichkeit, die Flut der Themen strukturierter bearbeiten zu können, die bei Campana & Schott PR-technisch aufzugreifen und zu bearbeiten sind. - Warum also nicht einfach auch in der PR-Abteilung die Technologie anwenden, die unsere Berater-Kollegen täglich unseren Kunden anpreisen? Tatsächlich entschlossen wir uns nach Gesprächen mit unseren SharePoint-Experten dazu, sämtliche Arbeitsprozesse über unser internes SharePoint-Portal CaeSar abzubilden. Von der ersten Idee für einen Artikel, über Auftragserteilung, Briefings und Review-Schleifen zwischen den fachlich Verantwortlichen und der PR-Abteilung bis hin zum Mailverkehr mit den Redaktionen und zur Veröffentlichung, - alle Schritte laufen nunmehr über SharePoint ab bzw. werden dort zu jedem Artikel dokumentiert.
Aufbauend auf die Erfahrung unserer SharePoint-Experten und nach einer Schulung haben wir ausgewiesene Nicht-Teckies innerhalb von ca. zwei Monaten die Standard-Funktionalität von SharePoint relativ leicht auf unsere PR-Zwecke angepasst. Die Umgewöhnung fiel leicht, denn die Vorteile sind täglich spürbar: Es ist ein Pressebereich entstanden, der über individuelle Rechte interne von Firmenweit öffentlichen Arbeitsbereichen trennt. Kollegen sehen nur, was für sie wichtig ist. Alle an einer Veröffentlichung Beteiligten können auf zentral im Arbeitsbereich abgelegte Briefings, Planungs- und Erstellungsdaten zugreifen und diese bearbeiten – auch von unterwegs aus, das ist ein unschlagbarer Vorteil.
Ab mit alten Zöpfen
Vorbei die Zeiten, in denen ich wöchentliche Archivierungswarnungen meines Outlook-Postfaches erhielt, weil manche Review-Schleife und jeder neu eingereichte Artikel Grafik-Attachments mit mehreren Megabytes bedeutete. Heute versenden wir Links und keine Mail-Anhänge.
Vorbei die Zeiten, in denen sich Mails mit verschiedenen Überarbeitungsständen überkreuzten und mühselig über Dokumentenvergleich der aktuelle Stand rekonstruiert oder zusammengefügt werden musste. Heute arbeitet jeweils nur einer an einem Dokument und währenddessen ist es ausgecheckt. Kein anderer kann dann daran arbeiten und dadurch Verwirrung stiften.
Adieu lokale Dateiablage jedes einzelnen Überarbeitungsstandes in vielfältigen Unterordnern. Die historisierte Ablage auf CaeSar lässt mich heute jeden Überarbeitungsstand nachverfolgen und kommentieren. Zu jeder Zeit ist mit ein paar Mausklicks für die PR-Abteilung klar ersichtlich, wer gerade am Zug ist, welche Artikel aktuell bearbeitet werden, wie viele sich derzeit im Planungsstatus befinden und welche Deadlines näher rücken etc..
Die Public Relations Abteilung von Campana & Schott ist SharePoint-Anwender-Pionier
Inzwischen dürfen wir uns zu den erfolgreichen SharePoint-Anwender-Pionieren von Campana & Schott zählen und können auch der Presse viel besser aus eigener Praxis berichten. Nicht nur darüber, dass unsere Arbeit Dank SharePoint auf ganz neuem technischen Niveau strukturiert ist, und dass die vielen Möglichkeiten Informationen zu vernetzen, zu filtern und auszuwerten sehr verlockend sind. Die Möglichkeiten sind so vielversprechend, dass wir aufpassen müssen, wie detailliert wir den zugegeben deutlich gestiegenen Pflegeaufwand im Detail betreiben.
Umstellung hat sich gelohnt
Bereits im ersten Vierteljahr 2010 konnten wir die Zahl der veröffentlichten Artikel und Newsmeldungen um ein Vielfaches erhöhen. Übrigens, auch das Ergebnis der gemeinsamen Mühen findet sich elektronisch auf dem Firmenportal CaeSar: Excel Adieu! Die stetig wachsende Veröffentlichungsliste heißt bei uns jetzt CaeSar-Publikationsliste und ist damit für alle Mitarbeiter jederzeit zugänglich.
PS: Was machen wir mit dem gewonnenen Freiraum? – Die genannten Zahlen sprechen für sich: Wir arbeiten an noch mehr Veröffentlichungen. Und zusätzlich findet sich dann und wann neuerdings die Kapazität, auch internationale Medien mit interessanten Inhalten zu versorgen. Welche? Das sehen Sie hier.
Windows SharePoint Services 3.0: Massen-Check-In von ausgecheckten Dokumenten per STSADM
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.
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:
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]
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.
Kontextsensitive Dropdowns in webbasierten Formularen mit SharePoint und InfoPath 2010
In SharePoint und InfoPath 2007 war es ohne Code Behind nicht möglich verschachtelte Dropdowns (also die kontextsensitive Reduzierung einer Dropdown-Auswahl auf Basis einer vorhergehenden Dateneingabe/-auswahl) zu gestalten. Das wird mit SharePoint und InfoPath 2010 wesentlich einfacher.
Einleitend ein kurzer Exkurs in die Welt von Lookups und SharePoint. In SharePoint zeichnen sich Lookups (also die Verwendung von Informationen aus anderen SharePoint-Listen) dadurch aus, dass die Verknüpfung über die ID erfolgt während die Darstellung über den Displaynamen realisiert ist. Dies hat den Vorteil, dass bei einer Änderung des Auswahlwertes bzw. des Displaynamens auch alle bereits bestehenden Einträge mit dem neuen Displayname aktualisiert werden. Dieses Verhalten machen wir uns bei verschachtelten Dropdowns zu Nutze.
Typische Aufgabenstellung: Es soll eine verschachtelte Auswahl umgesetzt werden, bei der zunächst eine Rolle und im Anschluss daraus eine spezifische Person ausgewählt werden. Folgende Voraussetzungen sind hierfür notwendig:
- Eine SharePoint-Liste (hier "Roles" genannt), die alle zur Verfügung stehenden Rollen umfasst
- Eine SharePoint-Liste, die jedem Mitarbeiter eine Rolle zuordnet (hier "Employees" genannt)
- Beide Listen sind mit Daten befüllt, wobei die Liste "Employees" mittels Lookup auf die Liste "Roles" verweist
In SharePoint 2010 gibt es verschiedene Möglichkeiten um ein Formular zu erstellen:
- Der klassische Weg, wie er schon aus der 2007er Version bekannt ist, indem man mit InfoPath startet und alle Felder anlegt oder
- man erstellt zunächst eine Liste in SharePoint mit allen benötigten Feldern (inklusive der Dropdown-Felder) und klickt dann auf "Customize Form"
Das weitere Vorgehen unterscheidet sich nicht wesentlich:
- InfoPath 2010-Designer öffnen
- Ein neues Template anlegen
- Zwei eingehende Datenverbindungen anlegen (siehe Abbildung 1):
- Zur Liste "Roles" – hier wird die ID und das Feld Role eingelesen
- Zur Liste "Employees" – hier werden die Felder ID, Name und Role eingelesen
- Nun wird das erste Dropdown-Feld erstellt, in dem künftig zunächst die Rolle ausgewählt werden soll:
- Als eingehende Datenquelle wird die Liste "Roles" ausgewählt
- Der Wert des Auswahlfelds wird auf die ID gesetzt
- Der Displayname wird auf das Feld "Role" der Liste gelegt
- Als nächstes wird das zweite Dropdown-Feld erstellt, welches die zur ausgewählten Rolle zugehörigen Mitarbeiter anzeigen soll:
- Als eingehende Datenquelle wird die Liste "Employees" ausgewählt
- Der Wert des Auswahlfelds wird auf die AccountID des "Person or Group"-Felds gesetzt
- Der Displayname wird auf das Feld "DisplayName" des "Person or Group"-Elements gelegt (siehe Abbildung 2)
- Anschließend muss noch der entsprechende Filter gesetzt werden:
- Das Feld "SelectRole" im Formular anwählen und das Menü "Rules" aufrufen
- Eine neue Regel anlegen (z. B. "preset employee choice")
- Die Aktion "set a field’s value" auswählen
- Als zu setzendes Feld wird in der Datenverbindung auf die Liste "Employees" unter dem Punkt "QueryFields" das Feld "Role" ausgewählt (siehe Abbildung 3)
- Als Wert wird der Eintrag des Felds "SelectRole" übergeben
- Zusätzlich muss in diese Regel noch eine weitere Aktion aufgenommen werden um die Datenverbindung auf die Liste "Employes" mit den nun gesetzten Filterkriterien erneut abzurufen
- Aktion "Query for data" auswählen und die Datenverbindung zur Liste "Employees" angeben
- Abschließend ist das Formular zu speichern, zu veröffentlichen und zu testen (siehe Abbildung 4).
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.




















