in der philosophie von microsoft verwendet man meeting workspaces, um alle infos rund um das meeting zentral beisammen zu haben:
- es wird die agenda und dokumente, die für das meeting relevant sind, abgelegt. alle teilnehmenden personen sind ebenfalls ersichtlich
- nach abschluss des meetings soll der output ersichtlich sein: das protokoll, vielleicht im rahmen des meetings erstellte dokumente, unter umständen z.b. auch eine tasklist um die identifizierten tasks zu verfolgen
Was ist nun zu tun, um die meeting workspaces verwenden zu können?
im sharepoint muss es natürlich zumindest einen bereich geben, in dem die workspaces abgelegt werden – jeder workspace ist dabei anschließend eine eigene site. die config der outlook clients erfolgt per group policy – man benötigt dazu die adm files für outlook 2007 (download), die settings finden sich dann unter "user configuration\administrative templates\microsoft office outlook 2007\meeting workspace":
das wichtigste setting ist hier "default servers and data for meeting workspaces" in dem genau definiert wird, wo mit welchen templates in welcher sprache workspaces angelegt werden können.
das feld besteht aus 6 teilen, die durch "|" getrennt sind: Server URL, Server friendly name, TemplateLCID, TemplateID, TemplateName und OrganizerName – wenn es mehrere server gibt, so können diese einfach angehängt werden. z.B. könnte ein eintrag wie folgt aussehen: http://meetings.demo.internal|T-Systems Meeting Workspace|1033|MPS#0|Basic Meeting|Name
sobald die group policy zugewiesen wurde, gibt es bei der erstellung einer neuen besprechungsanfrage einen neuen bereich:
nachdem es in diesem beispiel nur einen server in der config gibt (und das group policy setting "disable user entries to server list" aktiviert wurde), gibt es für den anwender nichts weiter zu konfigurieren – ein klick auf erstellen legt den workspace nun an
… dies funktioniert aber nur, wenn der ersteller site owner ist (und da haben wir bereits einen großen nachteil der sache…)! verfügt man nicht über ausreichende rechte, so erscheint eine authentifizierungsanforderung. per default hat jeder benutzer genau solch einen bereich: die mysite!
sobald die erstellung abgeschlossen ist, fügt outlook in den body der einladung einen kleinen absatz ein, indem auch ein link auf den workspace vorhanden ist:
der link muss aber nicht unbedingt verwendet werden – auch nach einem rechtsklick auf die besprechung im kalender kann der workspace geöffnet werden:
ändert man etwas in dem kalendereintrag während man offline ist, so wird diese auch tatsächlich (meistens) an sharepoint übertragen, sobald man wieder online ist – dazu gibt es auch einen netten hinweis:
folgende infos werden aus outlook nach sharepoint übertragen: die teilnehmer, der ort, start und ende. und das auch nur, wenn man nach einem update "senden" klickt – nur speichern führt zu keinem erfolg. umgekehrt wird nichts übertragen – d.h. alle änderungen direkt am meeting workspace werden nicht ins outlook übertragen.
alle teilnehmer werden automatisch auf der site mit berechtigungen versehen, auch jene, die nachträglich hinzugefügt werden. es werden sogar die berechtigungen wieder entzogen, wenn man eine person von der teilnehmerliste entfernt. nur, wenn man direkt auf der site manuell berechtigungen vergibt – was man, da man ja owner sein muss ohne probleme machen kann – passieren bei änderungen der teilnehmer in der einladung eigenartige dinge. es benötigt bis zu einigen minuten, bis die berechtigungen tatsächlich vergeben sind; d.h. mitunter will jemand bereits auf einen workspace zugreifen und hat aber noch keine berechtigung dazu…
zuguterletzt kann man die verknüpfung manuell entfernen:
in diesem fall ist dies auf dem meeting workspace ersichtlich:
dies ist auch dann der fall, wenn eine besprechung abgesagt wurde, denn ein meeting workspace wird niemals wieder automatisch gelöscht.
fazit: die meeting workspaces können nicht losgelöst von einer firmenweiten sharepoint implementierung eingeführt werden. es gibt aufgrund der notwendigen berechtigungen aus meiner sicht nur 3 möglichkeiten:
- die mysite. dort haben die workspaces imho überhaupt nichts verloren, aber immerhin sind die berechtigungen auf jeden fall vorhanden
- einen eigens dafür geschaffenen bereich, z.b. meetings.demo.internal. auch hier kann man dafür sorgen, dass die notwendigen rechte vorhanden sind (es liegt aber in der natur der sache, dass somit natürlich jeder dort beliebige sites erstellen kann…), und vor allem erreicht man den vorteil, dass alle workspaces zentral abgelegt und erreichbar sind. durch die zentrale ablage ergeben sich weitere vorteile: man kann zentral eigene templates erstellen, den bereich z.b. ins internet publishen, etc – aber auch nachteile: mit der zeit entsteht ein gigantischer datenfriedhof, und der content wird getrennt – hier liegen informationen des meetings, alles andere nicht (sondern z.b. auf einem fileshare, etc)
- im jeweiligen bereich, d.h. z.b. in einem project workspace, im bereich der jeweiligen abteilung etc. dies bringt auf der einen seite den großen vorteil, dass alle informationen beisammen sind – also z.b. alle meetings eines projektes direkt im jeweiligen project workspace. auf der anderen seite können damit natürlich nicht alle ablageorte per policy vorgegeben werden – somit müssen die organisatoren der besprechungen manuell die entsprechende config vornehmen. die wenigsten werden site owner sein, damit sind support calls schon mal sicher.
sinnvoll bleibt damit also nur die 3te lösung, und diese kann eben nur teil eines großen konzeptes einer sharepoint einführung sein.